Day 18｜OpenAI 相容 API 層：地端 AI 多模型常駐好助手

2026 iThome 鐵人賽

DAY 18

AI Engineering

128GB 統一記憶體的三十天：DGX Spark 地端 LLM 與生成式 AI 部署實戰系列第 18 篇

18th鐵人賽

ivanusto

2026-08-31 18:22:56

251 瀏覽

分享至

第三週的摘要

盤點一下這台機器現在的住戶。引擎有三家常設（llama.cpp、vLLM、ds4），模型庫裡目前有 gpt-oss-120b、Qwen3.8-27B、Ornith 兩個版本的檔案、DeepSeek V4 Flash，還有其他要開發的新模型等等。如果每個上層應用都去設定直連特定引擎的特定連接埠，這個環境常常會碰到改版的問題，換一款模型就要改一輪所有工具的設定。

解法呢，在 Day 6 就先寫好伏筆了：所有引擎殊途同歸，都提供 OpenAI 相容 API。今天我會把這個解耦講完整，這是我們要同步使用這些模型的最佳橋梁。

為什麼是 OpenAI 相容

它是這個 AI 時代的 POSIX。不是因為設計最優雅，是因為所有 AI 程式的客戶端都會說、所有推論引擎都聽得懂的 API。本系列測過的每一個服務端（llama-server、vLLM、trtllm-serve、Ollama、ds4-server）全部提供 /v1/chat/completions，考卷 repo 能用同一支腳本考五個配方，靠的就是這件事。

解耦的價值，會在我們改變目前要用的模型時浮現。上層工具只要記一個 base URL 加一個 model 名字，底下把 Qwen 3.8 27B 換成 Ornith 1.5、或者是把 llama.cpp 換成 vLLM，應用程式一行不改。Day 11 說過選推論引擎的決策永遠可以反悔，而當我們採用 API 層來處理服務，這即為反悔權的技術保障。

多模型共存的三種架構

機器上同時要活著多個模型時，路線有三種，複雜度依序遞增。

第一種，各開各的埠。
llama-server 開 8080、vLLM 開 8000、ds4-server 開 8888，客戶端自己記誰在哪。優點是零額外組件，缺點是妳會需要記下埠號清單，而且沒有統一的認證與日誌。適合單人、服務三個以內的階段，我第二週的文章就是這樣辛苦地渡過。

第二種，統一閘道。
在所有引擎前面放一個反向代理或 LLM 閘道（開源選項不少，LiteLLM 是最常見的一款），對外只開放一個端點，靠請求裡的 model 欄位路由到後面的引擎。優點是單一入口、統一金鑰、統一日誌與用量統計，換後端只改閘道設定。代價是多一層元件要維運，以及多一跳的延遲（區網內通常是毫秒級，可接受）。

第三種，閘道加排程。
閘道不只管理路由，也管理服務的使用，比方說冷門模型的服務平時不跑，有 API 請求進來才拉起來，記憶體不夠時，主動卸掉最久沒用的模型，把記憶體空間釋放出來。這是把 128GB 當彈性資源池用的玩法，Ollama 內建類似機制，自組環境則要自己寫或借助現成的模型管理器。適合模型多、記憶體吃緊、又不想手動起停服務的階段。

我目前的答案是選擇第二種，統一閘道，理由是它剛好跨過「換模型不改客戶端」的門檻，又還沒把複雜度堆到需要多花時間去照顧。第三種的自動起停留，可以在模型數量再翻倍或更大規模的公司內佈署時應用。

實作：一個閘道的最小可用狀態

以 LiteLLM 為例，一份設定檔把三個引擎收進同一個匝道內使用：

model_list:
  - model_name: daily            # 日常主力
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: http://127.0.0.1:8888/v1
  - model_name: agent            # agent 工作
    litellm_params:
      model: openai/ornith-bf16
      api_base: http://127.0.0.1:8010/v1
  - model_name: zh-writer        # 繁中寫作
    litellm_params:
      model: openai/qwen38-27b-q8
      api_base: http://127.0.0.1:8080/v1

注意 model_name 那一欄的取名哲學，用途命名，不用模型命名。客戶端從此只認 daily、agent、zh-writer 三個名字，哪一顆模型在背後值班是閘道層的事。下次 Ornith 2.0 出了，改一行 api_base，所有工具無感升級，這個小技巧是今天文章中我覺得很值得採用的。

閘道起來後，所有客戶端（聊天介面、IDE 外掛、自動化腳本、下週的 agent 框架）一律指向閘道的位址。防火牆上只需要開放閘道的埠，引擎的埠全部收回 loopback，順手把攻擊面縮到最小，也可以說是資安職業病。：P