Tool
Apache APISIX
放在 api.yihua.app 後方的通用 API Gateway，集中管理 route、authentication、rate limit、observability 與 API plugin。
我在這套架構中怎麼使用
APISIX 是 api.yihua.app 後方的通用 API Gateway。外部請求先由 Home Gateway 上的 HAProxy 接入，再由 HAProxy 把這個 hostname 的流量轉給 APISIX。
APISIX 不需要接手所有公開網站；它專注於 API traffic，負責：
- 依 hostname、path、method 或 header 決定 upstream
- 驗證 API key、JWT 或 OIDC identity
- 套用 consumer / route 的 rate limit 與存取規則
- 統一 access log、metrics、tracing 與 request ID
- 對一般 API 直接轉送，對 LLM API 再轉交 LiteLLM
例如 /v1/chat/completions、/v1/responses 或其他約定的 AI route 可以送往 LiteLLM；非 LLM 的 application API 則直接送到各自的 backend service。
和 HAProxy 的差異
兩者都有 L7 routing 和 load balancing 能力，但 HAProxy 在這裡是「Home Gateway 的公開入口」，APISIX 則是「api.yihua.app 內部的 API policy layer」。
HAProxy 先處理 TLS、hostname 與不同服務間的粗粒度分流；APISIX 再處理 consumer、route、quota、plugin 與 observability。這樣能避免 Home Gateway 的 edge 設定被每一支 API 的 lifecycle 綁住。
和 LiteLLM 的差異
APISIX 目前也提供 AI Gateway plugin，包括 multi-provider proxy、retry / fallback 與 token-based rate limiting，所以它和 LiteLLM 並不是完全沒有重疊。
在我的用途上，我仍把兩者分開：
- APISIX 管「誰可以呼叫哪一支公開 API，以及可以呼叫多少次」。
- LiteLLM 管「這個 model name 最後要交給 LM Studio、OpenRouter 或其他 AI provider，以及如何統一 provider 差異」。
若未來 APISIX 的 AI plugin 已能完整涵蓋實際 provider、model alias、cost tracking 與 fallback 需求，可以重新評估是否減少一層；目前先以清楚的責任邊界換取可維護性。
Policy 放在哪一層
同一條規則不要無意間在 APISIX 與 LiteLLM 重複實作。
| Policy | 建議主要負責層 | 理由 |
|---|---|---|
| 公開 API authentication | APISIX | 一般 API 與 LLM API 共用一致的入口身分 |
| HTTP request rate limit | APISIX | 以 consumer、route 或 application 管理 |
| model alias 與 provider routing | LiteLLM | 需要理解 model 與 provider |
| token / spend budget | LiteLLM | 最接近實際 model usage 與 provider cost |
| edge connection protection | HAProxy | 最靠近公開網路入口 |
APISIX 若也要做 token limit，應把它視為 public API 的上限或防線，並明確區分 LiteLLM 的 project / model budget，避免兩邊都回傳難以判讀的 429。