--- title: "基準測試" url: "/docs/benchmarks" canonical_url: "https://docs.litellm.ai/docs/benchmarks" type: "docs" last_updated: "2026-10-08" related: - "/docs/agent_resources" - "/docs/completion/input" --- # 基準測試 > Index of all LiteLLM docs: https://docs.litellm.ai/llms.txt LiteLLM Gateway（Proxy Server）針對假的 OpenAI endpoint 進行的基準測試。 LiteLLM Gateway 在 1k RPS 下具有 **8ms P95 延遲**（請參閱 [此處](#4-instances) 的基準測試） ## 高吞吐量設定檔：50K 到 100K token 提示詞下達到 3,000 RPS {#high-throughput-profile-3000-rps-with-50k-to-100k-token-prompts} 大型提示詞會帶來與短篇聊天請求不同的閘道工作負載。Token 計數、預算檢查、支出追蹤與指標收集，都會在模型提供者呼叫之前或之後發生，並且在高請求量下可能成為瓶頸。 此基準測試比較了[高吞吐量部署設定檔](./proxy/high_throughput.md)與 `v1.101.0`。此設定檔結合了 Rust token 計數、共用資料庫連線、隔離的指標與支出處理，以及依流量自動擴縮。 :::info[夜間基準測試] 高吞吐量設定檔仍在開發中，並可於 nightly builds 中使用。這些結果使用的是完整設定檔可取得的最早版本。 ::: ### 結果 {#results} | 類別 | 指標 | 高吞吐量設定檔 | `v1.101.0` | 變化 | |---|---|---:|---:|---:| | 部署 | Gateway pods | 33 | 132 | 少 4 倍 | | | 每個 pod 的 worker 數 | 4 | 1 | | | | 總 worker 數 | 132 | 132 | 相同 | | 吞吐量 | Requests/sec | 3.00K | 0.19K | 16x | | | Tokens/sec | 224.61M | 6.92M | 32x | | | 預估 tokens/30 天 | 582.20T | 17.94T | 32x | | 可靠性 | HTTP 200 rate (Locust) | 100.00% | 92.07% | | | 請求延遲 | p50 | 30.581 ms | 6.950 s | 227x | | | p95 | 54.029 ms | 27.451 s | 508x | | | p99 | 91.645 ms | 29.826 s | 325x | | 首個 token 的時間 | p50 | 31.667 ms | 9.400 s | 297x | 此設定檔以 100% 的客戶可見成功率達到完整 3,000 RPS 目標。基準組穩定在接近 190 RPS，且 92.07% 的請求回傳成功回應。 ### 測試設定 {#test-setup} | 測試面向 | 設定 | |---|---| | 負載產生器 | 分散式 Locust，1 個 master 與 30 個 workers | | 流量 | 3,000 名模擬使用者，每人每秒 1 個請求 | | 請求混合 | 50K、75K 與 100K-token 提示詞，各佔相同比例 | | 串流 | 50% 的請求 | | 端點 | `/v1/chat/completions` 搭配 `max_tokens: 16` | | 驗證 | 帶有預算的虛擬金鑰，因此會執行 admission token 計數與預算保留 | | 模型 | 內建 mock model，且停用回應快取 | | 網路路徑 | 公開 AWS Application Load Balancer | | 用戶端逾時 | 60 秒 | | 執行時間 | 高吞吐量設定檔：24m 22s。基準組：5m 7s。 | 此 mock model 移除了提供者成本與提供者延遲，同時保留閘道請求路徑的運作。測試仍包含驗證、預算、token 計數、支出追蹤與指標。 兩個部署都執行了 132 個閘道 worker，並請求了 528 GiB 記憶體。高吞吐量設定檔使用 33 個 pod、每個 pod 4 個 worker，並請求 132 vCPU。基準組使用 132 個 pod、每個 pod 1 個 worker，並請求 264 vCPU。 ### 造成差異的因素 {#what-made-the-difference} 以下每項變更都先單獨量測，之後才測試完整設定檔。 | 變更 | 客戶影響 | 量測結果 | |---|---|---| | Rust admission token 計數 | 減少在分派前計算大型提示詞所耗費的 CPU。 | 50K / 75K / 100K 計數從 46 / 53 / 100 ms 降至 4.9 / 6.8 / 10.2 ms。 | | 每個 pod 一個 PgBouncer | 避免資料庫連線隨著每個 worker 成倍增加。 | Postgres 在 11 到 29 個 pod 間維持 86 到 175 個連線，且沒有等待中的 PgBouncer client。 | | 支出收集 sidecar | 將支出處理與推論 worker 分離。 | 在 700 RPS 時，p99 從 1.8 s 降至 830 ms。總計算量大致相同。 | | 指標 sidecar | 將 Prometheus scrape 與推論 worker 分離。 | 在 700 RPS 時，sidecar 每個 pod 約使用 2 millicores。 | | 更高的 CPU burst limit | 避免同一個 pod 中所有 worker 一起被 throttling。 | 在 700 RPS 時，p99 從 830 ms 降至 670 ms。 | | Gateway keep-alive | 在擴縮期間維持 load balancer 連線有效。 | 在 200 RPS 測試中，ALB 產生的 502 回應從 15 個降至 0。 | | RPS 與 TPS 自動擴縮 | 在 CPU 飽和前對流量做出反應。 | 在 200 使用者負載階梯後約 48 秒新增了一個副本。 | | Admission token-count 重用 | 避免在 mock 測試中對相同的大型串流提示詞重複計數。 | 串流 mock 請求在約 30 ms 內完成，與非串流請求相當。 | ### 如何解讀指標 {#how-to-read-the-metrics} - 每秒請求數、每秒 token 數、預估 token 數與請求延遲來自閘道的 Prometheus 指標。 - 首個 token 的時間來自 Locust，衡量從送出請求到收到第一個串流事件的時間。它包含請求上傳、load balancer 與閘道 admission 工作。 - HTTP 200 rate 來自 Locust，因為它包含從未到達閘道的失敗。 `v1.101.0` 執行有 5,118 個客戶可見失敗：4,546 個客戶逾時或連線中斷、457 個 HTTP 504 回應，以及 115 個 HTTP 502 回應。閘道沒有收到這些請求，因此其自身的成功指標顯示 100%，而 Locust 顯示 92.07%。 閱讀 Locust 吞吐量時請使用 `POST` 列。每個串流請求也會建立一列 `TTFT`，因此在啟用串流時，Locust 的 `Aggregated` 列所計數的項目會比真實請求更多。 ### 基準範圍 {#benchmark-scope} 這是完整設定檔的前後比較，而不是單一變數測試。這些部署使用了不同的 pod 形狀，且執行時間也不同。上表中的個別效果來自 200 到 1,000 RPS 的獨立 A/B 測試。 內建 mock model 排除了提供者延遲。這些結果衡量的是此特定流量形狀下的閘道容量，不應被視為通用的生產規模配置指南。在選擇 worker 數、pod 資源與 HPA 目標之前，請先量測具代表性的工作負載。 以下各節使用在 4 CPU / 8 GB 機器上，對假 OpenAI 端點發出的短請求本文。它們無法直接與此大型提示詞基準測試相比。 ## 用於測試的機器規格 {#machine-spec-used-for-testing} 每台部署 LiteLLM 的機器具有以下規格： - 4 CPU - 8GB RAM ## 設定 {#configuration} - 資料庫：PostgreSQL。請參閱[資料庫容量規劃](./proxy/db_sizing.md)了解如何規劃您的配置 - Redis：未使用。建議在 production 中使用；請參閱[Redis 容量規劃](./proxy/redis_sizing.md) - 負載產生器：Locust，1,000 名使用者，每次請求間有 0.5s 到 1s 的思考時間。在將這些數字與您自己的執行結果比較前，請參閱[Locust 設定](#locust-settings)。 ### 2 個 LiteLLM Proxy 執行個體 {#2-instance-litellm-proxy} 在這些測試中，基準延遲特性是針對 fake-openai-endpoint 量測。 #### 效能指標 {#performance-metrics} | **類型** | **名稱** | **中位數 (ms)** | **95%ile (ms)** | **99%ile (ms)** | **平均值 (ms)** | **目前 RPS** | | --- | --- | --- | --- | --- | --- | --- | | POST | /chat/completions | 200 | 630 | 1200 | 262.46 | 1035.7 | | Custom | LiteLLM Overhead Duration (ms) | 12 | 29 | 43 | 14.74 | 1035.7 | | | 彙總 | 100 | 430 | 930 | 138.6 | 2071.4 | {/* ## **Horizontal Scaling - 10K RPS** ## Related pages - [代理程式資源](https://docs.litellm.ai/docs/agent_resources.md) - [completion()](https://docs.litellm.ai/docs/completion/input.md)