Lazu 與其他 LLM 閘道的比較
這一頁裡的每個專案都是在多家模型供應商前面放一個統一入口。它們的差別在於給誰用，以及怎麼處理錢。這裡只說每個專案是做什麼的，不排名。事實於 2026 年 11 月 2 日對照各專案的儲存庫和文件核對，之後會過時。
Lazu 是做什麼的
Lazu 是給團隊、實驗室或公司用的模型帳戶：每個人、每個 Agent 一把 Key，各有各的預算；每個請求留下一筆用量紀錄，Key 的主人自己能查。閘道、帳本、主控台和這個文件站打包成一個可部署的產品，AGPL-3.0 授權。它源自 New API，New API 源自 one-api；路由、計費和用量這三層按書面合約重寫過。
當你要回答的問題是「誰在哪個模型上花了多少錢，能不能證明」，選 Lazu。當你需要的是嵌進自己服務裡的函式庫、不用自己跑伺服器的託管 Key，或是給已經在跑的閘道加個外掛，選別的。
並排看
| 形態 | 給誰用 | Key 與預算 | 用量紀錄 | 授權 | |
|---|---|---|---|---|---|
| Lazu | Go 閘道 + 帳本 + 主控台 + 文件站，一套 Docker 堆疊 | 給人和 Agent 開模型帳戶的團隊 | 使用者、團隊、專案；按 Key、按成員設預算；預付先預留，按上游計數結算 | 每個請求一筆紀錄，標明每個數字的來源和計費明細；Agent 工作階段；離線核對腳本 | AGPL-3.0 |
| LiteLLM | Python 代理 + SDK，YAML 設定，管理介面 | 給內部服務統一入口的平台團隊 | 虛擬 Key、使用者、團隊、組織；各層級預算可定期重置 | 花費統計和日誌；部分報表屬企業版 | MIT；enterprise/ 目錄另行授權 |
| New API | Go 閘道 + 主控台 | 用一套部署服務很多使用者的營運者 | 使用者、群組、令牌額度、訂閱、儲值 | 用量和稽核日誌、成本核算 | AGPL-3.0 附署名條款 |
| one-api | Go 閘道 + 主控台 | 想要一個 OpenAI 格式入口的自建者 | 使用者、群組、令牌額度、兌換碼 | 額度明細 | MIT 附頁尾署名；最後一次發布是 2025 年 2 月 |
| Bifrost | Go 閘道 + 介面 | 平台團隊，有企業版 | 虛擬 Key、團隊、客戶；美元預算可重置 | 日誌、Prometheus 指標、追蹤 | Apache-2.0 |
| Portkey Gateway | TypeScript 閘道，按請求設定 | 應用開發者；預算、RBAC 和觀測在託管平台裡 | 託管方案裡有預算 | 本機主控台看日誌；保留期按方案 | MIT；儲存庫自 2026 年 5 月起停更 |
| Helicone | 觀測平台，前面帶一個閘道 | 先要日誌和追蹤的 AI 工程師 | 按請求數或花費限流；沒有按 Key 的預算 | 每個請求的費用、延遲和 token | Apache-2.0（平台） |
| Kong AI Gateway | Kong 上的外掛 | 已經在跑 Kong 的企業 | 按消費者群組設 token 額度和費用預算，企業版 | 透過 Kong 計量 | 核心 Apache-2.0，企業外掛閉源 |
| OpenRouter | 僅託管 | 要一把 Key、不想跑伺服器的開發者 | 可開子 Key 並設額度 | 活動頁和按請求查費用的介面 | 不開源 |
預算用完會怎樣
預算好不好，看它攔下請求的那一刻。幾個專案原則一致，機制各異。
- Lazu 在呼叫上游之前從預付餘額裡預留資金，呼叫完之後按上游自己回報的用量計數結算。Key、專案或帳戶付不起的請求在到達上游之前就被拒絕。失敗且沒有可計費輸出的請求釋放預留。上游沒回報計數的，紀錄裡如實標註；不編數字，也不悄悄透支（計費說明、計費合約）。
- LiteLLM 在 Key、使用者、團隊或客戶超過
max_budget後攔截，可以按週期重置；預算預警屬企業版。 - New API 和 one-api 在令牌或使用者額度用完後回傳
403 insufficient_user_quota。 - Bifrost 回傳
402 budget_exceeded，可臨時加額。 - Kong 攔的是超過費用上限的那個請求的下一個請求。
- Portkey 在託管企業版裡讓 Key 過期；Helicone 按時間窗按費用限流，但沒有 Key 預算。
一個請求留下什麼
Lazu 為每個完成的請求保存標準化的 token 維度、其中哪些是上游測量的、哪些是本機估算的、計費明細和公開的耗時；發起請求的 Key 可以按請求 ID 取回（請求詳情）。程式代理發來的請求按工作階段歸組，儲存庫裡帶了一個腳本，不印出提示詞就能核對匯出的工作階段。其他專案也記請求和費用；差別在於 Lazu 的紀錄是書面合約的一部分，付錢的人自己能讀，不只是營運者能看。
協定
Lazu、LiteLLM、New API 和 Bifrost 都原生接受 OpenAI、Anthropic Messages 和 Gemini 格式的請求，並在上游說另一種格式時做轉換。one-api 只接受 OpenAI 格式。Kong 開源的 ai-proxy 從 OpenAI 格式轉換，或把原生格式原樣透傳。Lazu 多了一條別人沒有明說的規則：只在無損時才轉換；請求用到上游承載不了的功能時，在呼叫上游之前就回傳點名該功能的 400（設計說明）。
更新的專案
2025 到 2026 年出現了三個值得知道的可自建閘道：gpt-load（Go，MIT；一把管理 Key 後面放通道群組和 Key 池，沒有按人的帳戶）、AxonHub（Go；任意 SDK 到任意供應商，按請求算成本，RBAC）和 mozilla-ai 的 otari（Python；虛擬 Key、預算和用量統計）。這一頁只看了它們的 README。