--- slug: litellm-one-api-company-governance title: 公司需要 One API 嗎？用 LiteLLM 管理模型、部門、成本與敏感資料 status: published excerpt: 從 LiteLLM、One API、New API 到 managed gateway，整理公司如何統一多家模型供應商、切分部門與專案、控制預算和用量，並用 DLP、遮罩與資料分級降低敏感資料外送風險。 category: AI tags: [ai, llm, litellm, api-gateway, security, governance, self-hosted] author: Seer author_role: Author read_time: 14 min cover: "/static/litellm-one-api-company-governance-cover.png" closing_note: "模型越多，入口越要清楚；治理做得好，團隊才敢把 AI 放進真正的流程。" published_at: "2026-08-21T12:45:00Z" updated_at: "2026-08-21T12:45:00Z" --- 公司開始同時使用 OpenAI、Claude、Gemini、Azure OpenAI、Bedrock、DeepSeek、Qwen 或本地模型後，最先出現的問題通常落在管理： - 每個服務各自保存一把供應商 API key - 每個部門都用自己的模型名稱和 SDK - 財務月底才知道哪個團隊花了多少錢 - 測試環境把正式模型打爆 - 開發者把客戶資料、原始碼、合約或資料庫內容直接貼給模型 - 某家供應商限流時，整個產品跟著停擺 這就是公司需要 One API 或 LLM Gateway 的原因。 這裡的 One API，不只代表同名的開源專案，也泛指放在公司應用程式與多家模型供應商之間的統一入口。它讓公司用一組內部 API 介面管理模型存取、權限、路由、成本、資料政策與稽核紀錄。 ## 先講主角：LiteLLM 是什麼位置 [LiteLLM](https://github.com/BerriAI/litellm) 的核心定位，是用統一介面呼叫多家 LLM 供應商。官方文件描述它提供 100+ LLM 的統一介面，並列出 OpenAI、Anthropic、Vertex AI、Bedrock、Ollama、Azure OpenAI 等使用路徑。它也提供自架的 Proxy Server，搭配 virtual keys、團隊與使用者預算、成本追蹤、管理介面、路由與 fallback。[1][3] LiteLLM 在公司裡適合放在這個位置： ```text 員工、內部工具、產品後端、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](https://github.com/songquanpeng/one-api) 的定位是把多家模型 API 統一成 OpenAI API 格式，並提供 channel、token、使用者群組、channel 群組、模型清單、負載平衡、額度與管理介面。官方 README 也描述 Docker 部署、多機部署、MySQL、Redis、token 管理與群組化設定。[4] 原始 One API 採 MIT License。[5] [New API](https://github.com/QuantumNous/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 變數、聊天機器人設定或每個開發者的本機檔案裡。 比較好的方式是： ```text 供應商 key ↓ 只放在 gateway secret store 或雲端 secret manager Gateway ↓ 發給內部服務一組受限制的 virtual key 應用程式 ``` 內部 key 要能撤銷、過期、限制模型、限制環境、限制部門，並且可以追溯到服務帳號或負責團隊。 ### 2. 把模型名稱改成公司的能力名稱 應用程式不要直接把供應商名稱寫死在商業邏輯裡： ```text gpt-4.1-mini claude-sonnet-4-5 某個供應商的 preview model ``` 可以改成內部模型別名： ```text company-general-fast company-general-quality company-long-context company-vision company-embedding company-local-private ``` Gateway 再把別名映射到實際模型。換模型時，應用程式不必重新改 SDK、部署與權限。 ### 3. 讓 fallback 有明確規則 例如： ```text company-general-quality → primary: Anthropic Claude → fallback: OpenAI GPT → emergency: Azure OpenAI ``` Fallback 不代表所有模型的輸出可以直接互換。公司要先定義： - 哪些錯誤可以切換 - 哪些錯誤要直接回報 - 是否允許從高品質模型降級 - 降級後是否要通知產品或客服 - 工具呼叫、JSON schema、視覺輸入是否相容 - 是否要在回應 metadata 標記實際使用的模型 ## 部門、團隊與環境要怎麼切 我會建議至少使用五個維度： ```text 公司 → 部門 → 專案 → 環境 → 服務帳號 / 使用者 ``` 例如： | 維度 | 範例 | 主要用途 | | --- | --- | --- | | 部門 | 工程、客服、行銷、財務、研究 | 預算歸屬與政策 | | 專案 | 客服 Copilot、內容生成、內部搜尋 | 看清楚哪個產品在花錢 | | 環境 | dev、staging、production | 避免測試打到正式資源 | | 身分 | 使用者、服務帳號、CI job | 授權與稽核 | | 資料等級 | 公開、內部、機密、受限制 | 決定允許哪類模型 | ### 部門切分的實作方式 每個部門建立一個 workspace 或 team： ```text 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，把可用模型明確列出： ```text 一般員工 → 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] ### 建議的資料分級 | 等級 | 範例 | 預設處理 | | --- | --- | --- | | L0 公開 | 官網內容、公開文件 | 可送一般核准模型 | | L1 內部 | 內部流程、非敏感程式碼 | 送核准的商業或自架模型 | | L2 機密 | 未公開產品、客戶紀錄、合約草稿 | 先遮罩，限企業路由 | | L3 受限制 | 密碼、API key、信用卡、健康資料、完整個資 | 預設阻擋，必要時走特別核准流程 | ### 一個可落地的防護流程 ```mermaid 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： | Provider | 不用於訓練的條件 | 預設保留 | 區域 | ZDR / 私網 | 可處理資料等級 | | --- | --- | --- | --- | --- | --- | | OpenAI API | 依 API 與組織設定 | 依 endpoint | 查官方文件 | 需確認資格 | 由法務與資安核准 | | Azure / Foundry | 依 Azure 服務條款與部署 | 依服務設定 | 可選區域 | 依方案 | 由法務與資安核准 | | Anthropic API | 查商業條款與資料保留文件 | 查官方文件 | 查區域 | 查資格 | 由法務與資安核准 | | 本地模型 | 公司自管 | 公司自訂 | 公司內部 | 由公司控制 | 仍要防內部權限濫用 | ## 用量限制怎麼設才有用 只設一個月度預算通常不夠，因為失控可能在一天內發生。建議至少有三層： ### 個人或服務層 - 每日花費上限 - 每小時 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] ### 預算不要只設硬阻擋 建議設三個門檻： ```text 70%：通知部門負責人 85%：限制高成本模型與批次任務 100%：阻擋或切換到核准的低成本模型 ``` 緊急 fallback 要有獨立政策，避免所有流量一起切到最貴的模型。 ## 用量監控要看什麼 公司至少要收集以下欄位： ```json { "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 上的一個數字直接當成會計帳。 ## 架設方式比較 | 方案 | 供應商彈性 | 權限與部門 | 預算與用量 | 資料控制 | 架設難度 | 管理成本 | | --- | --- | --- | --- | --- | --- | --- | | 直接用供應商 API | 低到中 | 每家各自管理 | 每家各自看 | 依供應商 | 低 | 中，會分散 | | LiteLLM Proxy | 高 | key、user、team、model policy | 強，需資料庫與監控 | 可自架，仍要自己做 DLP | 中 | 中到高 | | One API | 中到高 | token、user group、channel group | quota、token、channel 統計 | 可自架，治理深度看客製 | 低到中 | 中 | | New API | 中到高 | token group、model restriction、user management | 額度與模型管理較完整 | 可自架，需自行補企業治理 | 中 | 中到高 | | Portkey 類 managed gateway | 高 | workspace、key、policy | 多層 budget、token、rate limit | 交給 managed service，需審查資料流 | 低 | 低到中，費用與供應商依賴較高 | | Cloudflare AI Gateway | 中到高 | gateway、應用層政策 | rate limit、analytics、成本觀測 | 可做 log payload 控制與 DLP，仍要設計身分層 | 低到中 | 中 | 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 | | 多供應商、想自架、需要 routing、fallback、budget | LiteLLM Proxy | | 重視 token、channel、群組與額度管理介面 | One API 或 New API | | 不想維護 gateway 基礎設施、需要多層 policy | Portkey 類 managed gateway | | 已經在 Cloudflare、重視 analytics、rate limit、cache、DLP | Cloudflare AI Gateway | | 企業有 SSO、DLP、SIEM、資料區域與稽核要求 | 企業 managed gateway 或自建 control plane | | 高敏感資料且需要最小外送 | 本地模型加內部 gateway，必要時只開核准雲端路由 | | 高流量產品 | LiteLLM 或企業 gateway 叢集，搭配獨立 rate-limit store、metrics 與 fallback | 我的預設建議是： - 小團隊先直接用供應商 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