Tool
LiteLLM
專注 LLM 的 API Gateway 與 provider translation layer，讓應用用一致介面存取 LM Studio、OpenRouter 與其他 AI model API。
我在這套架構中怎麼使用
LiteLLM 不放在 Home Gateway 最外層，也不接手所有 api.yihua.app route。只有與 LLM 有關的 API request，才由 APISIX 轉交 LiteLLM。
LiteLLM 再依對外公布的 model name、routing policy 與 backend availability，把請求送到：
- 家中或區域網路裡由 LM Studio 提供的本機模型 API
- OpenRouter 等外部 AI model API service
- 未來加入的其他 OpenAI-compatible 或原生 provider API
應用端因此不需要知道每個 provider 的 base URL、API key、model identifier 與 request 差異，只需要呼叫 api.yihua.app 上約定好的 LLM API。
為什麼不直接用 APISIX AI Gateway
APISIX 的 AI plugin 已經能處理多個 LLM provider、fallback 與 token rate limiting。若需求很單純，直接用 APISIX 確實可能減少一個 hop。
我選擇保留 LiteLLM，是因為這一層的主要問題不是公開 API ingress，而是 LLM provider abstraction：model alias、OpenAI-compatible interface、provider-specific translation、fallback、usage 與 cost tracking。把這些 model-aware 邏輯留在 LiteLLM，可以避免通用 API Gateway 的 route 設定直接綁定每個 AI provider。
這不是說 LiteLLM 一定比 APISIX 更強，而是讓兩者各自負責自己最接近的 domain。
LM Studio 與 OpenRouter 的角色
LM Studio 可以在本機或區域網路提供 OpenAI-compatible endpoint；OpenRouter 則提供外部多模型 API。LiteLLM 可以把兩者放在同一份 model routing 設定下，但不代表兩者具有完全相同的可用性、隱私與成本特性。
實際 routing policy 可以依需求區分：
- 隱私或本機資料優先的工作先送 LM Studio。
- 本機模型未啟動、能力不足或資源忙碌時，才 fallback 到 OpenRouter。
- 需要特定商用模型或更大 context window 時，直接選指定的 OpenRouter model。
- 對外只暴露穩定的 model alias，不讓 client 綁死 provider model name。
安全與維運注意事項
- LM Studio backend 不應直接暴露到 Internet；只允許 LiteLLM 所在的可信任網路存取。
- LiteLLM 持有 OpenRouter 等 upstream credential，APISIX 與 client 不需要取得這些 key。
- 從 client 到 LiteLLM 的 authentication context 必須有明確傳遞規則，避免內外兩層 virtual key 混用。
- streaming、tool calling、structured output、embeddings 與 Responses API 要逐一做 end-to-end compatibility test，不能只用一般 chat completion 判定整條鏈可用。
- fallback 要區分可重試的 provider error 與 client request error，避免同一個昂貴請求被重複送出。