GoModel 評測：Go 寫的 AI Gateway，用相容層換掉 LiteLLM 的部署成本

GoModel 要解的是「多供應商之後」才出現的那批問題

單一供應商、單一金鑰的場景不需要 gateway。真正開始痛，通常是在第二家、第三家模型供應商接進來之後：金鑰散在好幾個地方，用量與花費要到各家後台分別撈，某一家回應變慢或掛掉時沒有自動退路，而每個應用團隊又各自寫了一份呼叫邏輯。GoModel 的定位就是把這一層抽出來，讓應用端只認一個位址。README 列出的供應商清單相當長，從 OpenAI、Anthropic、Google Gemini、xAI、Groq、Cohere、DeepSeek、Azure OpenAI，到自架的 Ollama、vLLM、SGLang、llm-d，以及 Amazon Bedrock。它的目標讀者不是單一開發者，而是要在組織內統一模型存取、同時被要求回答「這個月 AI 花了多少錢」的基礎設施或平台團隊。README 對自身的描述是「最後一個你會需要的 AI gateway」，並把自己定位成 LiteLLM 的替代品。這種行銷語氣可以忽略，但底下的功能清單說明了它想覆蓋的範圍：快取、成本追蹤、預算、速率限制、虛擬模型、session 黏著、failover。

兩個相容端點，是它最實際的設計決定

GoModel 接受兩種請求格式：OpenAI 相容走 /v1，Anthropic 相容走 /v1/messages。這件事的價值在於官方 SDK 不需要改程式碼，只要換 base URL。README 給的對應關係是：OpenAI SDK 設成 http://localhost:8080/v1，Anthropic SDK 設成 http://localhost:8080，因為該 SDK 會自己接上 /v1/messages。這代表既有專案從直連供應商改成走 gateway，改動範圍通常只有環境變數那一行。反過來說，如果你的程式碼依賴某家 SDK 的特有欄位或非標準端點，這個相容層就未必接得住，README 只承諾了這兩種格式，並沒有承諾覆蓋所有供應商的全部原生參數。請求進來之後，gateway 依設定的目標決定要轉去哪個供應商，並在這一層掛上快取、預算、速率限制與用量記錄。文件另有一份 per-provider 的功能矩陣，說明每個供應商支援哪些能力，這份矩陣在採用前應該先看，因為「支援某供應商」和「支援該供應商的全部功能」是兩件事。

設定解析順序與啟動方式

GoModel 的設定解析順序在 README 寫得很明確：良好的預設值，然後是 config.yaml，然後是 .env，最後是已匯出的環境變數，越往右優先權越高。範例設定檔在 config/config.example.yaml，完整環境變數清單在 .env.template。這個順序有個實務後果：如果你在容器裡同時掛了 .env 又用 -e 傳環境變數，環境變數會蓋掉檔案內容，除錯時要先確認到底是哪一層生效。啟動方式有三種。macOS 與 Linux 是 curl -fsSL https://gomodel.enterpilot.io/install.sh | sh 然後執行 gomodel。Windows PowerShell 是 irm https://gomodel.enterpilot.io/install.ps1 | iex。Docker 則是 docker run --rm -p 8080:8080 -e OPENAI_API_KEY="your-openai-key" enterpilot/gomodel。啟動後 dashboard 在 http://localhost:8080/admin/dashboard。README 的驗證請求打的是 /v1/responses，body 帶 model 與 input 兩個欄位。要注意的是，把安裝腳本直接管線進 shell 是常見做法，但這等於信任該網域當下回傳的內容，在受管環境裡通常會改成先下載再檢查。若要用 Docker Compose，README 區分兩種：只起基礎設施（Redis、PostgreSQL、MongoDB、Adminer）用 docker compose up -d 或 make infra；連應用與 Prometheus 一起起，則用 docker compose --profile app up -d 或 make image。這裡可以看出它預設會用到 Redis 與 PostgreSQL 這類外部依賴，不是一個純記憶體、零依賴的單檔代理。

快取、預算與 session 黏著，這三項才是省錢的地方

README 把省錢拆成幾個機制。快取分為 exact 與 semantic 兩種，文件說法是重複的 prompt 不再產生費用。語意快取意味著相似但不完全相同的輸入可能命中同一份回應，這在客服或問答類場景有效，但在需要嚴格一致性的場景是風險，因為你拿回的答案對應的是另一個 prompt。成本追蹤提供每筆請求的成本估算，以及 dashboard 上的用量分析與花費拆分。預算是針對 user、team 或 key 設硬性上限，超過就擋。速率限制則可按 requests、tokens 與 concurrency 三個維度，分別針對 user path、provider 或 model 設定。這三者疊起來的實際效果是：一個失控的迴圈或一把外洩的金鑰，傷害會被預算上限截斷，而不是等到月底帳單才發現。session keeping 是比較少見的一項：偵測用戶端 session 並把它釘在同一個目標與供應商金鑰上。README 給的理由是讓供應商端的 prompt cache 保持有效，同時讓稽核日誌讀起來像一條條對話串。這對長對話的延遲與成本有實際影響，但代價是負載會集中在被釘住的那個目標上。

虛擬模型與 failover 的取捨

虛擬模型讓你在穩定名稱後面掛別名與負載平衡，README 列出 round-robin 與 cost-based 兩種策略。這解決的是模型名稱硬編碼在應用裡的問題：要換供應商時改 gateway 設定，不用重新部署應用。cost-based 策略聽起來理想，但它的判斷基礎是成本估算，而估算本身依賴各供應商的定價資料是否即時更新，README 沒有說明這份資料的維護方式，這是採用前值得向維護者確認的一點。failover 是自動改道到備援供應商，並搭配 retries 與 circuit breakers。這裡有個必須自己想的問題：不同供應商的模型能力不對等，自動改道之後回應品質可能改變，而應用端通常不會知道這次請求其實走了另一家。如果你的場景對輸出一致性敏感，failover 應該只設在能力相近的目標之間，而不是把所有供應商串成一條鏈。另外，README 提到的 Hacker News 討論與 demo 連結屬於外部佐證，不是功能說明，不應作為技術判斷依據。

什麼情況下 GoModel 是錯的工具

第一，只有一家供應商、一把金鑰、一個應用。這種規模下 gateway 只會多一個要維護的服務與一個要監控的故障點。第二，需要供應商原生 API 的完整能力。GoModel 承諾的是 OpenAI 相容與 Anthropic 相容兩種格式，任何超出這兩種格式的原生功能，例如某家特有的工具呼叫格式或檔案 API，都不在相容層的保證範圍內。第三，團隊沒有能力維運 Redis 與 PostgreSQL。從 Docker Compose 的基礎設施清單可以看出，完整功能會用到這些外部元件，這不是一個單一 binary 就能收工的部署。第四，對版本穩定性要求高的環境。最近的發布是 v0.1.90、v0.1.89、v0.1.88，時間集中在 2026 年 9 月 6 日到 8 日之間，這個節奏說明專案仍在快速變動期，v0.1.x 的版號本身也代表尚未進入 1.0。密集發布不等於不穩定，但意味著升級需要有人跟 release notes。第五，如果你的痛點其實是延遲而不是管理複雜度，那 gateway 是增加一跳，不會讓請求變快。README 對效能的說法是導向其自稱可自行重現的 benchmark 頁面，本文沒有實際執行，無法驗證任何數字。

與 LiteLLM 的實際差異在哪

README 直接把 LiteLLM 當成對照對象，並提到 Portkey 在 GitHub 上已不再維護。撇開這些說法，兩者最實在的差別是實作語言與隨之而來的部署形態。LiteLLM 以 Python 實作，生態成熟、供應商覆蓋廣、社群範例多，代價是執行環境較重，通常需要 Python 執行環境與對應的套件管理。GoModel 以 Go 實作，編譯後是單一 binary，也可以用 Docker 映像部署，對已經在用 Go 的團隊來說，維運面與團隊既有技能重疊。這個差異在資源占用與啟動時間上通常有意義，但本文沒有實測數據，只能說這是語言選擇帶來的結構性差異，不是量測結論。功能面上，兩者都提供多供應商路由、成本追蹤與快取這類能力，因此選擇的關鍵通常不在功能清單，而在於你的團隊比較能維護哪一種執行環境，以及你是否需要 LiteLLM 那些更長期累積下來的供應商細節處理。另一個差異是設定模型：GoModel 的優先權順序是預設值、config.yaml、.env、環境變數，並且提供 dashboard 直接改重要設定。dashboard 可改設定對日常操作方便，但也意味著設定來源可能不只檔案一處，需要確認變更是否會落回檔案、以及是否會被下次部署覆蓋，README 沒有交代這點。

授權與升級成本

GoModel 的授權是 MIT，這在實務上屬於寬鬆授權，通常允許商業使用與修改，但這不是法律意見，採用前應自行核對倉庫內的 LICENSE 檔案與其完整條文，尤其是你要把它包進自家產品再散布時。升級成本方面，材料能支持的判斷有三點。第一，版號在 v0.1.x 且發布密集，代表介面與行為仍可能調整，升級前讀 release notes 是必要動作，而不是可選動作。第二，設定有三層來源會互相覆蓋，升級後若出現行為改變，排查順序應該是先確認環境變數，再看 .env，再看 config.yaml，最後才是預設值，這個順序本身就是除錯路徑。第三，README 指向 config/config.example.yaml 與 .env.template 兩份參考檔，這兩份檔案在升級時應該一併比對差異，因為新增的設定項通常會先出現在這裡。至於長期維護的人力，取決於你啟用了多少功能，只做轉發與只做轉發加快取加預算加 failover，是兩種完全不同的維運負擔。

編輯結論

如果你的團隊已經在用多個供應商，而且痛點是「用量與花費散落在各家後台、又要自己維護一套 Python 代理」，GoModel 值得先花半小時在測試環境跑一次 docker run，把 OPENAI_API_KEY 與一個 Ollama 端點接上，確認 dashboard 的 token 與成本數字和供應商帳單對得上。反過來說，如果你的需求只是單一供應商、單一金鑰的轉發，或是你已經有一套運作中的 LiteLLM 且沒有維運人力問題，換過來不會帶來對應的收益。採用前必須先確認三件事：授權條款是 MIT，但請自行核對倉庫內的 LICENSE 檔案內容；版本號仍在 v0.1.x 且發布節奏密集，升級前先讀 release notes；以及你的告警與日誌系統是否吃得下它輸出的格式。

官方來源

1. ENTERPILOT/GoModel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases