基准
针对假 OpenAI 端点测试的 LiteLLM 网关（代理服务器）基准测试。
LiteLLM 网关在 1k RPS 下具有 8ms 的 P95 延迟（参见基准测试 此处）
用于测试的机器规格
部署 LiteLLM 的每台机器规格如下
- 4 核 CPU
- 8GB 内存
配置
- 数据库：PostgreSQL
- Redis：未使用
2 实例 LiteLLM 代理
在这些测试中，基准延迟特性是针对假 OpenAI 端点进行测量的。
性能指标
| 类型 | 名称 | 中位数 (ms) | 95% 分位数 (ms) | 99% 分位数 (ms) | 平均值 (ms) | 当前 RPS |
|---|---|---|---|---|---|---|
| POST | /chat/completions | 200 | 630 | 1200 | 262.46 | 1035.7 |
| 自定义 | LiteLLM 开销持续时间 (ms) | 12 | 29 | 43 | 14.74 | 1035.7 |
| 聚合 | 100 | 430 | 930 | 138.6 | 2071.4 |
4 个实例
| 类型 | 名称 | 中位数 (ms) | 95% 分位数 (ms) | 99% 分位数 (ms) | 平均值 (ms) | 当前 RPS |
|---|---|---|---|---|---|---|
| POST | /chat/completions | 100 | 150 | 240 | 111.73 | 1170 |
| 自定义 | LiteLLM 开销持续时间 (ms) | 2 | 8 | 13 | 3.32 | 1170 |
| 聚合 | 77 | 130 | 180 | 57.53 | 2340 |
关键发现
- 将 LiteLLM 实例从 2 个增加到 4 个，中位延迟减半：200 ms → 100 ms。
- 高百分位延迟显著下降：P95 630 ms → 150 ms，P99 1,200 ms → 240 ms。
- 将工作进程数 (workers) 设置为与 CPU 核心数相同可获得最佳性能。
使用网络模拟 (Network Mock) 设置基准测试
对代理开销进行基准测试的最快方法是使用 network_mock 模式。这会在 httpx 传输层拦截出站请求并返回预设响应，无需设置模拟提供程序。
1. 创建代理配置
model_list:
- model_name: db-openai-endpoint
litellm_params:
model: openai/gpt-4o
api_key: "sk-fake-key"
api_base: "https://api.openai.com"
litellm_settings:
network_mock: true
callbacks: []
num_retries: 0
request_timeout: 30
general_settings:
master_key: "sk-1234"
2. 启动代理
litellm --config benchmark_config.yaml --port 4000 --num_workers 8
3. 运行基准测试脚本
python scripts/benchmark_mock.py --requests 2000 --max-concurrent 200 --runs 3
获取基准测试脚本 此处
这测量的是热路径上的纯代理开销，不包含到真实或假提供程序的任何网络延迟。
设置假 OpenAI 端点
对于负载测试和基准测试，可以使用假的 OpenAI 代理服务器。LiteLLM 提供：
- 托管端点：使用我们免费托管的假端点
https://exampleopenaiendpoint-production.up.railway.app/ - 自托管：使用 github.com/BerriAI/example_openai_endpoint 设置您自己的假 OpenAI 代理服务器
使用此配置进行测试
model_list:
- model_name: "fake-openai-endpoint"
litellm_params:
model: openai/any
api_base: https://exampleopenaiendpoint-production.up.railway.app/ # or your self-hosted endpoint
api_key: "test"
/realtime API 基准测试
针对假实时端点测试的 /realtime 端点端到端延迟基准测试。
性能指标
| 指标 | 值 |
|---|---|
| 中位数延迟 | 59 ms |
| p95 延迟 | 67 ms |
| p99 延迟 | 99 ms |
| 平均延迟 | 63 ms |
| RPS | 1,207 |
测试设置
| 类别 | 规范 |
|---|---|
| 负载测试 | Locust：1,000 个并发用户，500 个逐步增加 |
| 系统 | 4 vCPU，8 GB RAM，4 个工作线程，4 个实例 |
| 数据库 | PostgreSQL (未使用 Redis) |
基础设施建议
基于基准测试结果和 API 网关部署的行业标准给出的推荐规格。
PostgreSQL
用于身份验证、密钥管理和使用情况跟踪。
| 工作负载 | CPU | RAM | 存储 | 连接数 |
|---|---|---|---|---|
| 1-2K RPS | 4-8 核 | 16GB | 200GB SSD (3000+ IOPS) | 100-200 |
| 2-5K RPS | 8 核 | 16-32GB | 500GB SSD (5000+ IOPS) | 200-500 |
| 5K+ RPS | 16+ 核 | 32-64GB | 1TB+ SSD (10000+ IOPS) | 500+ |
配置： 设置 proxy_batch_write_at: 60 以批量写入并减少数据库负载。总连接数 = 池限制 × 实例数。
Redis（推荐）
在这些基准测试中未使用 Redis，但它在生产环境中具有显著优势：可减少 60-80% 的数据库负载。
| 工作负载 | CPU | RAM |
|---|---|---|
| 1-2K RPS | 2-4 核 | 8GB |
| 2-5K RPS | 4 核 | 16GB |
| 5K+ RPS | 8+ 核 | 32GB+ |
要求： Redis 7.0+，开启 AOF 持久化，allkeys-lru 驱逐策略。
配置
router_settings:
redis_host: os.environ/REDIS_HOST
redis_port: os.environ/REDIS_PORT
redis_password: os.environ/REDIS_PASSWORD
litellm_settings:
cache: True
cache_params:
type: redis
host: os.environ/REDIS_HOST
port: os.environ/REDIS_PORT
password: os.environ/REDIS_PASSWORD
使用 redis_host、redis_port 和 redis_password 代替 redis_url 可获得约 80 RPS 的性能提升。
扩展： 数据库连接数随实例数线性扩展。超过 5K RPS 时，请考虑使用 PostgreSQL 只读副本。
参见 生产配置 以获取详细的最佳实践。
Locust 设置
- 1000 用户
- 500 用户预热启动
如何衡量 LiteLLM 开销
来自 litellm 的所有响应都将包含 x-litellm-overhead-duration-ms 标头，这是 LiteLLM 代理添加的延迟开销（以毫秒为单位）。
如果您想在 locust 上衡量这一点，可以使用以下代码
import os
import uuid
from locust import HttpUser, task, between, events
# Custom metric to track LiteLLM overhead duration
overhead_durations = []
@events.request.add_listener
def on_request(request_type, name, response_time, response_length, response, context, exception, start_time, url, **kwargs):
if response and hasattr(response, 'headers'):
overhead_duration = response.headers.get('x-litellm-overhead-duration-ms')
if overhead_duration:
try:
duration_ms = float(overhead_duration)
overhead_durations.append(duration_ms)
# Report as custom metric
events.request.fire(
request_type="Custom",
name="LiteLLM Overhead Duration (ms)",
response_time=duration_ms,
response_length=0,
)
except (ValueError, TypeError):
pass
class MyUser(HttpUser):
wait_time = between(0.5, 1) # Random wait time between requests
def on_start(self):
self.api_key = os.getenv('API_KEY', 'sk-1234567890')
self.client.headers.update({'Authorization': f'Bearer {self.api_key}'})
@task
def litellm_completion(self):
# no cache hits with this
payload = {
"model": "db-openai-endpoint",
"messages": [{"role": "user", "content": f"{uuid.uuid4()} This is a test there will be no cache hits and we'll fill up the context" * 150}],
"user": "my-new-end-user-1"
}
response = self.client.post("chat/completions", json=payload)
if response.status_code != 200:
# log the errors in error.txt
with open("error.txt", "a") as error_log:
error_log.write(response.text + "\n")
LiteLLM 与 Portkey 性能对比
测试配置： 每实例 4 核 CPU，8 GB 内存 | 负载：1k 并发用户，500 预热启动 版本： Portkey v1.14.0 | LiteLLM v1.79.1-stable
测试持续时间： 5 分钟
多实例 (4×) 性能
| 指标 | Portkey（无数据库） | LiteLLM（有数据库） | 备注 |
|---|---|---|---|
| 总请求数 | 293,796 | 312,405 | LiteLLM 更高 |
| 失败请求数 | 0 | 0 | 相同 |
| 中位延迟 | 100 ms | 100 ms | 相同 |
| P95 延迟 | 230 ms | 150 ms | LiteLLM 更低 |
| P99 延迟 | 500 ms | 240 ms | LiteLLM 更低 |
| 平均延迟 | 123 ms | 111 ms | LiteLLM 更低 |
| 当前 RPS | 1,170.9 | 1,170 | 相同 |
延迟指标越低越好；请求数和 RPS 越高越好。
技术见解
Portkey
优点
- 内存占用低
- 延迟稳定，波动极小
缺点
- CPU 利用率上限约为 40%，表明可用计算资源未被充分利用
- 出现过三次 I/O 超时故障
LiteLLM
优点
- 充分利用了可用的 CPU 容量
- 连接处理能力强，在初步预热波动后延迟极低
缺点
- 初始化期间和每个请求的内存占用较高
日志记录回调
GCS 存储桶日志记录
使用 GCS 存储桶对延迟和 RPS 没有影响（与基础 LiteLLM 代理相比）
| 指标 | 基础 LiteLLM 代理 | 带有 GCS 存储桶日志的 LiteLLM 代理 |
|---|---|---|
| RPS | 1133.2 | 1137.3 |
| 中位延迟 (ms) | 140 | 138 |
LangSmith 日志记录
使用 LangSmith 对延迟和 RPS 没有影响（与基础 LiteLLM 代理相比）
| 指标 | 基础 LiteLLM 代理 | 带有 LangSmith 的 LiteLLM 代理 |
|---|---|---|
| RPS | 1133.2 | 1135 |
| 中位延迟 (ms) | 140 | 132 |