基准

针对模拟 OpenAI 端点的 LiteLLM 网关（代理服务器）的基准测试。

设置模拟 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"

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

主要发现

将实例从 2 个增加到 4 个会将中位数延迟减半：200 毫秒 → 100 毫秒。
高百分位数延迟显著下降：P95 630 毫秒 → 150 毫秒，P99 1,200 毫秒 → 240 毫秒。
将 worker 设置为 CPU 数量可获得最佳性能。

`/realtime` API 基准测试

针对模拟实时端点测试的 /realtime 端点的端到端延迟基准测试。

性能指标

指标	值
中位数延迟	59 毫秒
p95 延迟	67 毫秒
p99 延迟	99 毫秒
平均延迟	63 毫秒
RPS	1,207

测试设置

类别	规范
负载测试	Locust：1,000 个并发用户，500 个逐步增加
系统	4 vCPU，8 GB RAM，4 个工作线程，4 个实例
数据库	PostgreSQL (未使用 Redis)

用于测试的机器规格

部署 LiteLLM 的每台机器的规格如下

4 CPU
8GB RAM

配置

数据库：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

提示

为了获得约 80 RPS 的更好性能，请使用 redis_host、redis_port 和 redis_password 代替 redis_url。

扩展： 数据库连接数随实例数线性扩展。对于超过 5K RPS 的情况，请考虑 PostgreSQL 只读副本。

有关详细的最佳实践，请参阅生产配置。

Locust 设置

1000 用户
500 用户逐步增加

如何测量 LiteLLM 开销

来自 litellm 的所有响应都将包含 x-litellm-overhead-duration-ms 标头，这是 LiteLLM 代理添加的毫秒级延迟开销。

如果您想在 locust 上测量它，可以使用以下代码

Locust 代码用于测量 LiteLLM 开销
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 RAM | 负载：1k 并发用户、500 逐步增加 版本： Portkey v1.14.0 | LiteLLM v1.79.1-stable
测试时长： 5 分钟

多实例（4×）性能

指标	Portkey（无数据库）	LiteLLM（带数据库）	评论
总请求数	293,796	312,405	LiteLLM 较高
失败请求数	0	0	相同
中位数延迟	100 毫秒	100 毫秒	相同
p95 延迟	230 毫秒	150 毫秒	LiteLLM 较低
p99 延迟	500 毫秒	240 毫秒	LiteLLM 较低
平均延迟	123 毫秒	111 毫秒	LiteLLM 较低
当前 RPS	1,170.9	1,170	相同

对于延迟指标，数值越低越好；对于请求和 RPS，数值越高越好。

技术见解

Portkey

优点

内存占用量低
延迟稳定，峰值最小

缺点

CPU 利用率限制在 ~40% 左右，表明未充分利用可用计算资源
经历了三次 I/O 超时中断

LiteLLM

优点

充分利用可用 CPU 容量
强大的连接处理能力和初始预热峰值后的低延迟

缺点

初始化和每个请求期间内存使用量高

日志回调

GCS Bucket Logging

使用 GCS Bucket 对延迟、RPS 没有影响，与 Basic Litellm Proxy 相比

指标	Basic Litellm Proxy	带有 GCS Bucket Logging 的 LiteLLM Proxy
RPS	1133.2	1137.3
中位数延迟 (ms)	140	138

LangSmith logging

使用 LangSmith 对延迟、RPS 没有影响，与 Basic Litellm Proxy 相比

指标	Basic Litellm Proxy	带有 LangSmith 的 LiteLLM Proxy
RPS	1133.2	1135
中位数延迟 (ms)	140	132

设置模拟 OpenAI 端点​

2 个实例 LiteLLM 代理​

性能指标​

4 个实例​

主要发现​

/realtime API 基准测试​

性能指标​

测试设置​

用于测试的机器规格​

配置​

基础设施建议​

PostgreSQL​

Redis（推荐）​

Locust 设置​

如何测量 LiteLLM 开销​

LiteLLM 与 Portkey 性能比较​

多实例（4×）性能​

技术见解​

日志回调​

GCS Bucket Logging​

LangSmith logging​

设置模拟 OpenAI 端点

2 个实例 LiteLLM 代理

性能指标

4 个实例

主要发现

`/realtime` API 基准测试

性能指标

测试设置

用于测试的机器规格

配置

基础设施建议

PostgreSQL

Redis（推荐）

Locust 设置

如何测量 LiteLLM 开销

LiteLLM 与 Portkey 性能比较

多实例（4×）性能

技术见解

日志回调

GCS Bucket Logging

LangSmith logging