公司需要 One API 嗎？用 LiteLLM 管理模型、部門、成本與敏感資料

公司開始同時使用 OpenAI、Claude、Gemini、Azure OpenAI、Bedrock、DeepSeek、Qwen 或本地模型後，最先出現的問題通常落在管理：

• 每個服務各自保存一把供應商 API key
• 每個部門都用自己的模型名稱和 SDK
• 財務月底才知道哪個團隊花了多少錢
• 測試環境把正式模型打爆
• 開發者把客戶資料、原始碼、合約或資料庫內容直接貼給模型
• 某家供應商限流時，整個產品跟著停擺

這就是公司需要 One API 或 LLM Gateway 的原因。

這裡的 One API，不只代表同名的開源專案，也泛指放在公司應用程式與多家模型供應商之間的統一入口。它讓公司用一組內部 API 介面管理模型存取、權限、路由、成本、資料政策與稽核紀錄。

先講主角：LiteLLM 是什麼位置

LiteLLM 的核心定位，是用統一介面呼叫多家 LLM 供應商。官方文件描述它提供 100+ LLM 的統一介面，並列出 OpenAI、Anthropic、Vertex AI、Bedrock、Ollama、Azure OpenAI 等使用路徑。它也提供自架的 Proxy Server，搭配 virtual keys、團隊與使用者預算、成本追蹤、管理介面、路由與 fallback。[1][3]

LiteLLM 在公司裡適合放在這個位置：

員工、內部工具、產品後端、Agent
                ↓
        公司 LLM Gateway
                ↓
  權限、模型 allowlist、DLP、限流、預算
                ↓
        Router / Fallback
                ↓
OpenAI / Anthropic / Google / Azure / Bedrock / 本地模型

應用程式只需要知道公司的 gateway URL 與內部模型名稱。供應商 API key、路由規則和成本資料由平台團隊集中管理。

LiteLLM 的價值不在於把所有模型變成完全相同。不同模型仍然會有上下文長度、工具呼叫、視覺輸入、JSON schema、推理參數、串流格式與價格差異。Gateway 做的是統一主要呼叫路徑，並把差異集中在一個可管理的位置。

公司 One API 應該管理哪些供應商

第一層：主流閉源模型供應商

常見包含：

• OpenAI
• Anthropic
• Google Gemini 與 Vertex AI
• Azure OpenAI
• AWS Bedrock
• xAI
• Mistral
• Cohere
• DeepSeek

這些供應商適合處理公司主要的文字、視覺、工具呼叫、長上下文與高品質生成工作。供應商的合約、區域、資料保留政策、速率上限和模型可用性要逐家確認。

第二層：雲端模型平台與聚合服務

例如：

• Amazon Bedrock
• Google Vertex AI
• Azure AI Foundry
• OpenRouter
• Replicate
• Together AI
• Hugging Face Inference

這類平台常把多個模型放在同一個雲端帳號或同一個端點後面。公司可以用它們簡化帳務、區域、私網、雲端權限或模型取得方式，但要注意平台轉接層可能改變 API 欄位、計費方式與可用功能。

第三層：自架模型與 OpenAI-compatible endpoint

常見包含：

• vLLM
• Ollama
• SGLang
• LM Studio Server
• llama.cpp server
• NVIDIA NIM
• 公司的內部模型服務

LiteLLM 官方 provider 清單也包含許多 OpenAI-compatible endpoint、自架推理服務、模型平台與工具型服務。[3]

這一層適合：

• 低敏感資料的內部摘要
• 大量 embedding 或分類任務
• 對成本敏感的批次工作
• 需要固定模型版本的產品功能
• 不希望每次請求都離開公司網路的流程

One API 與 New API 的位置

原始 One API 的定位是把多家模型 API 統一成 OpenAI API 格式，並提供 channel、token、使用者群組、channel 群組、模型清單、負載平衡、額度與管理介面。官方 README 也描述 Docker 部署、多機部署、MySQL、Redis、token 管理與群組化設定。[4]

原始 One API 採 MIT License。[5]

New API 是另一條活躍的產品路線，延續 One API 的 API 聚合與管理概念，並加入較多模型介面、轉換、token 群組、模型限制與使用者管理能力。它目前採 AGPLv3，和原始 One API 的授權條件不同，企業導入前要讓法務確認使用方式與散布義務。[6][7][16]

簡單說：

• LiteLLM 偏向「模型路由與平台工程 gateway」
• One API 偏向「模型 API 管理、帳號、token、額度與分發平台」
• New API 偏向「功能擴充較多的 One API 路線」

三者都能放在公司入口層，但管理介面、模型轉換範圍、授權、升級節奏與企業資安整合方式不同。

公司為什麼要統一入口

1. 把真正的供應商 key 從應用程式拿掉

應用程式不應該把 OpenAI、Anthropic 或雲端帳號的正式 key 寫在前端、CI 變數、聊天機器人設定或每個開發者的本機檔案裡。

比較好的方式是：

供應商 key
   ↓ 只放在 gateway secret store 或雲端 secret manager
Gateway
   ↓ 發給內部服務一組受限制的 virtual key
應用程式

內部 key 要能撤銷、過期、限制模型、限制環境、限制部門，並且可以追溯到服務帳號或負責團隊。

2. 把模型名稱改成公司的能力名稱

應用程式不要直接把供應商名稱寫死在商業邏輯裡：

gpt-4.1-mini
claude-sonnet-4-5
某個供應商的 preview model

可以改成內部模型別名：

company-general-fast
company-general-quality
company-long-context
company-vision
company-embedding
company-local-private

Gateway 再把別名映射到實際模型。換模型時，應用程式不必重新改 SDK、部署與權限。

3. 讓 fallback 有明確規則

例如：

company-general-quality
  → primary: Anthropic Claude
  → fallback: OpenAI GPT
  → emergency: Azure OpenAI

Fallback 不代表所有模型的輸出可以直接互換。公司要先定義：

• 哪些錯誤可以切換
• 哪些錯誤要直接回報
• 是否允許從高品質模型降級
• 降級後是否要通知產品或客服
• 工具呼叫、JSON schema、視覺輸入是否相容
• 是否要在回應 metadata 標記實際使用的模型

部門、團隊與環境要怎麼切

我會建議至少使用五個維度：

公司
  → 部門
    → 專案
      → 環境
        → 服務帳號 / 使用者

例如：

部門切分的實作方式

每個部門建立一個 workspace 或 team：

engineering
  - monthly_budget: [TEAM_BUDGET]
  - allowed_models: company-general-fast, company-coding, company-local-private
  - data_level: internal

customer-success
  - monthly_budget: [TEAM_BUDGET]
  - allowed_models: company-general-fast, company-vision
  - data_level: customer-content-with-redaction

finance
  - monthly_budget: [TEAM_BUDGET]
  - allowed_models: company-local-private, approved-enterprise-provider
  - data_level: restricted

實際金額不應直接複製這個草稿的 placeholder。公司要依月度預算、模型價格、尖峰流量、是否含圖片或音訊、是否含批次工作計算。

人員 key 與服務 key 分開

• 人員 key：給內部使用者或短期測試，設定有效期限、低額度與模型 allowlist
• 服務 key：給後端服務，綁定專案、環境、來源網段與固定模型
• CI key：只允許測試模型、每日小額度與固定 request rate
• 高成本模型 key：額外審批，不能和一般模型共用

對產品後端來說，最好使用服務身分，集中管理 key 與服務設定。這樣離職、轉組或權限變更時，不會影響正式流量，也容易查責任歸屬。

權限控制要分成四層

第一層：誰可以呼叫

• SSO 或公司 IdP 登入管理介面
• 服務帳號與使用者分開
• key 有效期限與撤銷
• 管理員、部門管理者、一般使用者分級
• production 與 development 分開
• 管理 API 只能從內部網路或 VPN 存取

第二層：可以呼叫哪些模型

用 model allowlist，把可用模型明確列出：

一般員工
  → fast、cheap、internal models

工程部門
  → coding、reasoning、embedding

客服
  → fast、vision、approved customer-data models

財務與法務
  → approved enterprise route、local private route

高成本模型可設定成：

• 預設關閉
• 需要主管或平台團隊開通
• 只能由特定服務帳號使用
• 每次請求都要有 project、cost_center、purpose metadata

第三層：可以送什麼資料

模型 allowlist 只能控制「送去哪裡」，不能完整判斷「送了什麼」。資料治理要另外做：

• MIME type allowlist
• 檔案大小與頁數上限
• PII、信用卡、憑證、秘密、原始碼識別
• DLP 規則
• 個資遮罩或 tokenization
• prompt template 限制
• request body 是否寫入 log
• 特定資料等級禁止出境

第四層：可以花多少錢和打多快

同一把 key 要同時設定：

• 每日預算
• 每月預算
• RPM，requests per minute
• TPM，tokens per minute
• 最大並行數
• 單次最大 input tokens
• 單次最大 output tokens
• 高成本模型的獨立上限

LiteLLM 官方文件支援 key、user、team 等層級的預算與 rate limit，並提醒預算需要資料庫才能可靠執行。沒有資料庫的部署不能拿來當正式的預算防線。[2]

怎麼避免危險資料上傳

這件事要先改掉一個錯誤期待：裝上 gateway 之後，系統不會自動理解所有商業機密，也不能保證所有敏感資料都被攔下來。

OWASP 把 Sensitive Information Disclosure 列為 LLM 應用的重要風險。對公司來說，真正有效的做法是資料分類、身份政策、DLP、遮罩、供應商政策、log 控制與人工審核一起運作。[12]

建議的資料分級

一個可落地的防護流程

flowchart TB
  R["Request"] --> A["身份與專案驗證"]
  A --> D{"資料分類與 DLP 掃描"}
  D -->|L3| X["阻擋並通知"]
  D -->|L2| M["遮罩後送指定 provider"]
  D -->|L1 / L0| P["Approved model route"]
  M --> O["輸出掃描與敏感內容檢查"]
  P --> O
  X --> L["只保留必要 metadata"]
  O --> L

必須特別擋的內容

• API key、access token、password、private key
• connection string
• 信用卡號、銀行帳號
• 身分證號、護照號碼、電話與 Email 組合
• 客戶完整資料表
• 未公開財務報表
• 受 NDA 保護的資料
• 未經授權的原始碼與第三方資料

文章、prompt、測試與設定檔都不要放真實憑證，統一使用 [REDACTED]。

Log 也可能變成資料外洩點

Gateway 常會記錄 prompt、response、model、provider、token、成本、延遲與錯誤。Cloudflare AI Gateway 官方文件就明確列出 request log 可能包含 prompt、response、provider、token usage、cost、duration，並提供關閉 payload 儲存、只保留 metadata 的設定。[10]

公司的預設策略可以是：

• L0：保留完整 request/response，短期即可
• L1：保留 metadata，payload 只在除錯時暫時開啟
• L2：只保留遮罩後 payload 或 hash
• L3：不保存原文，保留阻擋事件、規則 ID、服務、使用者與時間

供應商資料政策要逐家查

例如 OpenAI API 文件說明，API 資料預設不拿來訓練模型，但 abuse monitoring logs 可能包含 prompt、response 與衍生 metadata，預設保留最長 30 天，Zero Data Retention 也有資格與 endpoint 限制。[13]

Azure 的官方資料隱私文件則說明，Models sold by Azure 的 prompts、completions、embeddings 與 fine-tuning data，在沒有客戶許可或指示的情況下，不用來訓練 foundation models。[14]

這些政策不能直接推廣到其他供應商，也不能推廣到每個 endpoint。導入前至少要建立一張 provider policy matrix：

用量限制怎麼設才有用

只設一個月度預算通常不夠，因為失控可能在一天內發生。建議至少有三層：

個人或服務層

• 每日花費上限
• 每小時 request 上限
• 最大並行數
• 單次 token 上限

團隊或部門層

• 每月預算
• 每個模型的月度上限
• production 與 staging 分開計算
• 批次任務與互動請求分開計算

公司與供應商層

• 全公司每家 provider 的硬上限
• provider rate limit 的 70% 到 80% 作為內部警戒線
• 高成本模型保留緊急額度
• fallback 不得無限重試

Portkey 的官方文件示範了 API key、workspace、provider integration、usage policy 與 rate limit policy 多層限制，也把 budget、token、request count 和 rate limit 分開處理。[8]

Cloudflare AI Gateway 也提供 gateway 層級的固定或 sliding window rate limit，超過限制時回傳 429。[11]

預算不要只設硬阻擋

建議設三個門檻：

70%：通知部門負責人
85%：限制高成本模型與批次任務
100%：阻擋或切換到核准的低成本模型

緊急 fallback 要有獨立政策，避免所有流量一起切到最貴的模型。

用量監控要看什麼

公司至少要收集以下欄位：

{
  "request_id": "[REQUEST_ID]",
  "timestamp": "[TIMESTAMP]",
  "department": "engineering",
  "project": "customer-copilot",
  "environment": "production",
  "service_account": "svc-copilot",
  "requested_model": "company-general-quality",
  "actual_provider": "[PROVIDER]",
  "actual_model": "[MODEL]",
  "input_tokens": 0,
  "output_tokens": 0,
  "latency_ms": 0,
  "status": "success",
  "estimated_cost_usd": 0,
  "data_classification": "L1",
  "payload_logged": false
}

監控 dashboard 可以分成：

• 財務：部門、專案、provider、模型、環境的預估成本
• 平台：RPM、TPM、延遲、錯誤率、429、fallback 次數
• 資安：DLP 命中、阻擋、遮罩、敏感資料上傳趨勢
• 產品：成功率、使用者回饋、模型品質、重試率
• 維運：gateway CPU、memory、資料庫、Redis、queue 與 provider health

Gateway 成本不一定等於供應商帳單

Gateway 的 token 計數、provider 回傳的 usage、供應商帳單、cache hit、圖片與音訊計費可能有差異。公司的財務報表應該分成：

1. gateway 估算成本
2. provider 回傳 usage
3. provider 實際帳單
4. 內部部門歸因

每月做 reconciliation，找出差異原因。不要把 dashboard 上的一個數字直接當成會計帳。

架設方式比較

LiteLLM 官方文件偏向平台團隊使用的自架 gateway，包含 virtual keys、team/user budgets、logging、guardrails、caching 與 admin UI。[1]

Portkey 的官方文件則提供 API key、workspace、provider integration 與 policy 多層限額，適合希望少維護基礎設施、直接使用 managed control plane 的團隊。[8]

Cloudflare AI Gateway 的定位更靠近邊緣流量與 AI 應用控制層，官方功能包含 analytics、logging、caching、rate limiting、retry、fallback 與多家 provider 連線。[9]

不同公司情境該選哪套

1. 5 人以下的小團隊，只有一到兩個模型

建議：直接使用供應商 API，加一層簡單的內部 config 與 secret manager。

條件：

• 只有一個產品
• 不需要跨部門 showback
• 沒有高敏感資料
• 供應商切換頻率低

先不要為了追求完整管理介面，提早養一套 gateway 叢集。至少要做到 key 不進前端、production 與 development 分開、每月有帳單警報。

2. 10 到 50 人，多個產品共用兩到五家模型

建議：LiteLLM Proxy 或 New API。

• 工程與平台團隊熟悉 Docker、Postgres、Redis、監控：選 LiteLLM
• 需要快速提供 token、群組、額度、channel 管理介面：選 New API
• 公司要用原始 One API：先確認目前維護狀態、授權與安全修補流程

這個階段最重要的是建立部門、專案、環境與服務帳號的成本標籤。

3. 有正式資安、法務、SSO 與稽核要求的公司

建議：企業 managed gateway、雲端 AI gateway，或 LiteLLM 前面再接公司自有 policy gateway。

選型條件：

• 是否支援 SSO、SCIM、RBAC
• 是否能接 SIEM 或 audit log
• 是否能關閉 payload log
• 是否有 DLP 與 PII 偵測
• 是否能指定區域與私網
• 是否有供應商資料處理附約
• 是否可以把管理權限與模型供應商權限分開

LiteLLM OSS 可以做出很多能力，但企業導入時要把「文件已有的功能」與「公司還要自行補的身份、DLP、稽核、備份、升級、災難復原」分開估算。

4. 高流量 AI 產品

建議：gateway 叢集加上獨立資料庫、Redis、metrics、queue 或 rate-limit store，必要時放到邊緣 gateway 後面。

必須先驗證：

• gateway 單節點與多節點行為
• rate limit 是否跨節點一致
• budget 是否可能延遲或超賣
• provider timeout、retry、fallback 是否會放大流量
• streaming 連線與反向代理設定
• log 儲存量與刪除策略
• provider billing 與 gateway usage 是否能對帳

高流量不等於直接把所有請求送到最快模型。需要用模型路由、快取、批次化、低成本模型與明確的失敗策略一起設計。

5. 研究團隊或模型實驗室

建議：LiteLLM 或直接使用模型平台，再加上嚴格低額度與隔離環境。

研究環境可以允許更多模型，但要限制：

• 每個實驗 project 的 budget
• 每日與每小時 token
• 可使用的 provider
• 是否可上傳檔案
• 是否可呼叫外部工具
• 是否能把實驗資料寫入長期 log

研究自由度和公司正式資料政策要分開，不要讓「只是測試」成為高敏感資料繞過治理的理由。

6. 客服、法務、財務等高敏感流程

建議：先做資料遮罩與企業路由，再決定模型。

可採用：

• L2 以上資料先由內部服務去識別化
• 只允許 approved provider 或本地模型
• 關閉 raw prompt/response log
• 所有 request 帶 project、data classification 與 purpose
• 特定模型需要人工核准
• 輸出也要過敏感資料與權限檢查

如果沒有完成資料分類與 DLP，先不要把「公司有 gateway」當成可以上傳客戶資料的理由。

我會怎麼安排導入順序

Phase 1：先統一入口

• 建立一個內部 gateway URL
• 只接兩家供應商
• 只開三個模型別名
• 所有 key 放 secret manager
• 所有 request 帶部門、專案、環境 metadata

Phase 2：加入成本與權限

• 建立 team、project、service account
• 設定每日與每月 budget
• 設定 RPM、TPM、最大並行數
• 開始做 provider bill reconciliation
• 建立模型 allowlist

Phase 3：加入資料治理

• 定義 L0 到 L3 資料分類
• 加 DLP 與 PII 掃描
• 對 L2 做遮罩
• 對 L3 預設阻擋
• 關閉敏感 payload log
• 寫 provider policy matrix

Phase 4：加入可靠性

• 加 retry 與 timeout
• 設計有上限的 fallback
• 監控 429、5xx、延遲與 fallback 次數
• 建立 provider outage runbook
• 做多節點與資料庫備份演練

Phase 5：才擴大模型範圍

• 接本地模型與 embedding
• 接更多 provider
• 做模型品質評測
• 對比成本、延遲與成功率
• 逐步開放高成本模型

最後的選型建議

可以先用這張簡化版決策表：

我的預設建議是：

• 小團隊先直接用供應商 API，先把 key、環境與帳務管好
• 多供應商公司從 LiteLLM Proxy 或 New API 做 POC
• 有企業資安要求時，把 DLP、SSO、SIEM、資料保留與人工審批列成選型門檻
• 高敏感資料先完成資料分類，再決定要不要送雲端模型
• 任何 gateway 都先用測試資料與 [REDACTED] 做 POC
• POC 必須測品質、延遲、成本、限流、fallback、log payload、權限撤銷與供應商帳單對帳

One API 的終點，是公司可以回答：誰用了哪個模型、為哪個專案使用、送了哪一類資料、花了多少錢、遇到故障時怎麼切換，以及出了問題後能不能追溯與停止。

查核日期：2026-08-21。供應商支援清單、版本、授權與管理功能會隨 repo、文件與方案變更，正式導入前要再查一次官方文件與合約。

Sources

• [1] https://docs.litellm.ai/docs — LiteLLM
• [2] https://docs.litellm.ai/docs/proxy/users
• [3] https://docs.litellm.ai/docs/providers
• [4] https://raw.githubusercontent.com/songquanpeng/one-api/main/README.en.md
• [5] https://raw.githubusercontent.com/songquanpeng/one-api/main/LICENSE
• [6] https://github.com/QuantumNous/new-api
• [7] https://raw.githubusercontent.com/QuantumNous/new-api/main/LICENSE
• [8] https://docs.portkey.ai/docs/guides/use-cases/enforcing-limits-and-budgets
• [9] https://developers.cloudflare.com/ai-gateway
• [10] https://developers.cloudflare.com/ai-gateway/observability/logging
• [11] https://developers.cloudflare.com/ai-gateway/features/rate-limiting
• [12] https://owasp.org/www-project-top-10-for-large-language-model-applications
• [13] https://developers.openai.com/api/docs/guides/your-data
• [14] https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy
• [16] https://raw.githubusercontent.com/QuantumNous/new-api/main/README.en.md

<!-- citation-verify [1] https://docs.litellm.ai/docs — LiteLLM [2] https://docs.litellm.ai/docs/proxy/users [3] https://docs.litellm.ai/docs/providers [4] https://raw.githubusercontent.com/songquanpeng/one-api/main/README.en.md [5] https://raw.githubusercontent.com/songquanpeng/one-api/main/LICENSE [6] https://github.com/QuantumNous/new-api [7] https://raw.githubusercontent.com/QuantumNous/new-api/main/LICENSE [8] https://docs.portkey.ai/docs/guides/use-cases/enforcing-limits-and-budgets [9] https://developers.cloudflare.com/ai-gateway [10] https://developers.cloudflare.com/ai-gateway/observability/logging [11] https://developers.cloudflare.com/ai-gateway/features/rate-limiting [12] https://owasp.org/www-project-top-10-for-large-language-model-applications [13] https://developers.openai.com/api/docs/guides/your-data [14] https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy [16] https://raw.githubusercontent.com/QuantumNous/new-api/main/README.en.md -->