在普通 HTTP API 中，我们通常只需要限制“每分钟请求数”。但对于大模型接口，仅限制请求数量远远不够：一次请求可能只消耗几十个 Token，也可能消耗数万个 Token。

因此，一个实用的 AI 网关通常需要同时支持：

• RPM（Requests Per Minute）：每分钟请求数。
• TPM（Tokens Per Minute）：每分钟 Token 数。
• 按租户、API Key、模型或套餐分别计费。
• 多个 Envoy 实例共享同一份额度。
• 在高并发条件下避免各实例独立计数造成额度放大。
• 返回统一的 429 Too Many Requests 和剩余额度信息。

本文介绍如何使用 envoyproxy/ratelimit、Redis 和 Envoy 构建一套分布式 AI 限流系统。

为什么不能只使用 Envoy Local Rate Limit

Envoy 提供了 Local Rate Limit Filter，但它的计数器默认位于当前 Envoy 进程中。

假设我们有 4 个 Envoy 实例，并为某个租户配置：

RPM = 100

如果每个 Envoy 都独立维护 100 RPM，那么整个集群实际上可能放行：

4 × 100 = 400 RPM

这显然不是我们想要的结果。

Envoy 的 Global Rate Limit Filter 可以把限流请求发送给外部 Rate Limit Service。envoyproxy/ratelimit 正是 Envoy 官方生态中常用的全局限流服务实现，它将计数器存放在 Redis 中。

整体架构如下：

这里增加了一个很薄的 AI Quota Adapter，主要用于解决两个问题：

1. 从请求体中解析模型、租户和 Token 数量。
2. 分别使用不同的 hits_addend 检查 RPM 和 TPM。

为什么 AI TPM 需要额外的适配层

Envoy 的普通限流规则通常把一次 HTTP 请求视为一次命中：

hits_addend = 1

这适合 RPM，但不适合 TPM。

例如下面两个请求：

请求 A：消耗 200 Token
请求 B：消耗 20,000 Token

如果两者都只增加一次计数，TPM 就没有意义。TPM 必须让一次请求按照 Token 数增加计数器：

hits_addend = token_cost

例如：

RPM 请求：hits_addend = 1
TPM 请求：hits_addend = 3200

Rate Limit Service 的 hits_addend 通常作用于整个 RateLimitRequest，因此 RPM 和 TPM 需要使用两次限流调用，或者由自定义适配服务组合处理。

推荐的处理顺序是：

1. 检查并增加 RPM，hits_addend=1。
2. RPM 允许后，再检查并增加 TPM，hits_addend=token_cost。
3. 任意一个返回 OVER_LIMIT，适配层向 Envoy 返回 429。

这种模式下，每个维度都由 Redis 原子计数，多个 Envoy 实例不会各自放大额度。

需要注意：两次调用并不是跨计数器事务。RPM 已增加后，TPM 可能拒绝请求。因此要提前明确计数语义：

• RPM 统计所有进入限流流程的请求尝试；或者
• 自行扩展服务，使用一段 Redis Lua 脚本同时检查 RPM 和 TPM。

多数系统接受第一种语义，因为它更简单，也能避免恶意用户通过大量超大请求免费消耗网关资源。

设计限流 Descriptor

限流维度通常包括：

• tenant：租户、组织或 API Key。
• model：模型名称。
• metric：rpm 或 tpm。

最终生成的 Descriptor 可以表示为：

tenant = tenant-a
model  = gpt-4.1
metric = rpm

以及：

tenant = tenant-a
model  = gpt-4.1
metric = tpm

这样可以实现：

tenant-a + gpt-4.1 -> 60 RPM
tenant-a + gpt-4.1 -> 100,000 TPM

如果不希望按模型拆分额度，也可以只保留：

tenant + metric

例如所有模型共享同一份租户额度。

配置 envoyproxy/ratelimit

创建 config/config.yaml：

domain: ai-gateway

descriptors:
  - key: tenant
    descriptors:
      - key: model
        descriptors:
          - key: metric
            value: rpm
            rate_limit:
              unit: minute
              requests_per_unit: 60

          - key: metric
            value: tpm
            rate_limit:
              unit: minute
              requests_per_unit: 100000

这里 tenant 和 model 没有指定固定值，可用于根据请求中的 Descriptor 值进行分桶。实际部署前，应使用所选 ratelimit 版本提供的配置校验工具检查配置。

适配层发送 RPM Descriptor：

[
  {"key": "tenant", "value": "tenant-a"},
  {"key": "model", "value": "gpt-4.1"},
  {"key": "metric", "value": "rpm"}
]

发送 TPM Descriptor：

[
  {"key": "tenant", "value": "tenant-a"},
  {"key": "model", "value": "gpt-4.1"},
  {"key": "metric", "value": "tpm"}
]

Descriptor 的顺序必须与配置中的嵌套路径一致。

不同套餐额度

如果不同租户拥有不同额度，可以增加套餐维度：

tenant -> plan -> model -> metric

例如：

domain: ai-gateway

descriptors:
  - key: tenant
    descriptors:
      - key: plan
        value: standard
        descriptors:
          - key: model
            descriptors:
              - key: metric
                value: rpm
                rate_limit:
                  unit: minute
                  requests_per_unit: 60

              - key: metric
                value: tpm
                rate_limit:
                  unit: minute
                  requests_per_unit: 100000

      - key: plan
        value: enterprise
        descriptors:
          - key: model
            descriptors:
              - key: metric
                value: rpm
                rate_limit:
                  unit: minute
                  requests_per_unit: 1000

              - key: metric
                value: tpm
                rate_limit:
                  unit: minute
                  requests_per_unit: 2000000

请求中的 tenant 用于隔离计数器，plan 用于选择额度。

不要只使用 plan 作为计数维度，否则所有 Standard 用户可能共享同一个计数器。

五、使用 Docker Compose 部署

下面是一个简化示例：

services:
  redis:
    image: redis:7-alpine
    command:
      - redis-server
      - --appendonly
      - "yes"
    volumes:
      - redis-data:/data
    ports:
      - "6379:6379"

  ratelimit:
    image: envoyproxy/ratelimit:<固定版本号>
    command: /bin/ratelimit
    environment:
      LOG_LEVEL: info

      REDIS_SOCKET_TYPE: tcp
      REDIS_URL: redis:6379

      RUNTIME_ROOT: /data
      RUNTIME_SUBDIRECTORY: ratelimit
      RUNTIME_WATCH_ROOT: "false"

      USE_STATSD: "false"
    volumes:
      - ./config:/data/ratelimit
    ports:
      - "8081:8081"
      - "6070:6070"
    depends_on:
      - redis

volumes:
  redis-data:

生产环境不要直接使用 master 或浮动标签，应固定到经过验证的 release 版本。

不同版本的镜像端口和环境变量可能存在差异，因此部署时应以对应版本仓库中的示例配置为准。

启动：

docker compose up -d

查看日志：

docker compose logs -f ratelimit

生产环境可以运行多个 ratelimit 副本：

ratelimit-1 ─┐
ratelimit-2 ─┼── Redis
ratelimit-3 ─┘

ratelimit 服务本身可以保持无状态，只要所有副本：

• 使用相同的配置。
• 指向同一个 Redis 逻辑集群。
• 使用一致的 Redis Key 前缀或命名空间。

AI Quota Adapter 的核心逻辑

适配层可以实现为 Envoy ext_authz 服务。它接收 Envoy 转发过来的请求信息，完成身份识别、Token 计算和额度检查。

下面是简化后的 Go 伪代码：

func CheckAIQuota(
    ctx context.Context,
    tenant string,
    model string,
    tokenCost uint32,
) error {
    // 第一次调用：RPM
    rpmResp, err := rateLimitClient.ShouldRateLimit(
        ctx,
        &ratelimitv3.RateLimitRequest{
            Domain: "ai-gateway",
            Descriptors: []*ratelimitv3.RateLimitDescriptor{
                {
                    Entries: []*ratelimitv3.RateLimitDescriptor_Entry{
                        {Key: "tenant", Value: tenant},
                        {Key: "model", Value: model},
                        {Key: "metric", Value: "rpm"},
                    },
                },
            },
            HitsAddend: 1,
        },
    )
    if err != nil {
        return err
    }

    if rpmResp.OverallCode ==
        ratelimitv3.RateLimitResponse_OVER_LIMIT {
        return ErrRPMExceeded
    }

    // 第二次调用：TPM
    tpmResp, err := rateLimitClient.ShouldRateLimit(
        ctx,
        &ratelimitv3.RateLimitRequest{
            Domain: "ai-gateway",
            Descriptors: []*ratelimitv3.RateLimitDescriptor{
                {
                    Entries: []*ratelimitv3.RateLimitDescriptor_Entry{
                        {Key: "tenant", Value: tenant},
                        {Key: "model", Value: model},
                        {Key: "metric", Value: "tpm"},
                    },
                },
            },
            HitsAddend: tokenCost,
        },
    )
    if err != nil {
        return err
    }

    if tpmResp.OverallCode ==
        ratelimitv3.RateLimitResponse_OVER_LIMIT {
        return ErrTPMExceeded
    }

    return nil
}

实际代码中的 protobuf 包名和字段类型应以项目锁定的 Envoy API 版本为准。

适配层的完整处理流程如下：

1. 从 Authorization/API Key 中识别 tenant
2. 从 JSON 请求体中读取 model
3. 使用模型对应的 tokenizer 计算 input_tokens
4. 根据策略计算 token_cost
5. 调用 RLS 检查 RPM
6. 调用 RLS 检查 TPM
7. 都允许：返回 OK
8. 任意超限：返回 429

在 Envoy 中接入适配层

如果适配层实现 Envoy 的 ext_authz gRPC 协议，可以在 Envoy 中配置：

http_filters:
  - name: envoy.filters.http.ext_authz
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz

      transport_api_version: V3

      grpc_service:
        envoy_grpc:
          cluster_name: ai_quota_adapter
        timeout: 0.5s

      with_request_body:
        max_request_bytes: 1048576
        allow_partial_message: false
        pack_as_bytes: true

      failure_mode_allow: false

  - name: envoy.filters.http.router
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

对应的 Cluster：

clusters:
  - name: ai_quota_adapter
    type: STRICT_DNS
    connect_timeout: 0.25s

    http2_protocol_options: {}

    load_assignment:
      cluster_name: ai_quota_adapter
      endpoints:
        - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: ai-quota-adapter
                    port_value: 9000

因为 Token 计算需要读取 JSON 请求体，所以需要配置 with_request_body。

注意限制最大请求体，避免攻击者提交超大 Prompt 导致 Envoy 或适配层内存压力。

TPM 应该如何计算

RPM 的定义比较简单，一次请求增加 1。

TPM 更复杂，因为请求发出时通常只知道输入 Token，尚不知道模型最终会产生多少输出 Token。

方案一：只计算输入 Token

token_cost = input_tokens

优点：

• 请求开始前就能精确计算。
• 实现最简单。
• 非流式和流式接口都适用。

缺点：

• 无法限制输出 Token。
• 用户可能通过很短的 Prompt 请求大量输出。

适合将 TPM 定义为“输入 Token 配额”的系统。

方案二：预留最大输出 Token

token_cost = input_tokens + requested_max_output_tokens

例如：

input_tokens = 1200
max_tokens   = 4096
token_cost   = 5296

优点：

• 在调用模型前就能做严格准入控制。
• 不会因为输出 Token 未知而突破额度。
• 适合流式响应。

缺点：

• 实际只输出 300 Token 时仍预留了 4096 Token。
• 如果不实现退款，额度利用率会偏低。

这是最容易实现“严格不超额”的方案。

网关必须对 max_tokens 设置服务端上限，不能完全信任客户端：

effective_max_tokens = min(client_max_tokens, server_model_limit)

否则客户端可以提交异常大的 max_tokens，让自己或整个租户迅速耗尽配额。

方案三：先预留，再按实际用量结算

完整思路是：

1. 请求开始时预留：

input_tokens + max_output_tokens

2. 响应结束后得到实际输出 Token。
3. 退还未使用部分：

refund = max_output_tokens - actual_output_tokens

但 envoyproxy/ratelimit 的标准限流调用主要面向正向增加计数，并不天然提供完整的“预留—提交—退款”事务模型。

如果业务必须支持精确退款，通常需要：

• 在适配层实现额外的 Redis Lua 脚本。
• 使用独立的预留记录和过期时间。
• 请求结束后进行 commit/refund。
• 使用请求 ID 保证幂等。

此时 envoyproxy/ratelimit 仍可负责 RPM 或基础 TPM，但结算逻辑已经属于定制配额服务。

方案四：流式增量扣费

对于流式输出，可以：

1. 请求开始时扣除输入 Token。
2. 每生成一批输出 Token，再增加一次 TPM 计数。
3. 一旦超过额度，终止上游流。

例如每 32 或 128 个 Token 扣一次。

这种方式需要能观察响应流，因此仅靠请求阶段的 ext_authz 不够，需要：

• Envoy ext_proc；
• Wasm Filter；
• 自定义 HTTP Filter；
• 或由 AI Gateway 自身代理并读取流式响应。

增量批次越小，控制越精确，但 gRPC 和 Redis 调用次数也越多。

多 Envoy 实例如何保证共享额度

假设一个租户拥有：

RPM = 100
TPM = 200,000

请求可能随机落到不同 Envoy：

Request 1 -> Envoy A
Request 2 -> Envoy B
Request 3 -> Envoy C

但所有限流请求最终都会访问同一套 Redis 计数器：

ai-gateway / tenant-a / gpt-4.1 / rpm
ai-gateway / tenant-a / gpt-4.1 / tpm

因此额度是整个集群共享的，而不是每个 Envoy 各有一份。

可以横向扩展的部分包括：

• Envoy。
• AI Quota Adapter。
• envoyproxy/ratelimit。

不能随意拆分的是同一个配额 Key 的计数状态。如果使用多个完全独立的 Redis，则必须确保相同租户、模型和指标始终路由到同一个分片，否则额度又会被放大。

返回标准限流响应

发生超限时，适配层应向 Envoy 返回 429：

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 12

响应体可以采用 OpenAI 风格：

{
  "error": {
    "message": "Rate limit exceeded for tenant tenant-a",
    "type": "rate_limit_error",
    "code": "tpm_limit_exceeded"
  }
}

建议分别暴露 RPM 和 TPM 信息：

X-RateLimit-Limit-Requests: 60
X-RateLimit-Remaining-Requests: 12
X-RateLimit-Reset-Requests: 18

X-RateLimit-Limit-Tokens: 100000
X-RateLimit-Remaining-Tokens: 24580
X-RateLimit-Reset-Tokens: 18

为了避免客户端形成同步重试风暴，SDK 应使用带随机抖动的指数退避：

sleep = random(0, min(cap, base × 2^retry_count))

“精准限流”需要明确的边界

使用 Redis 共享计数器可以解决多实例额度放大的问题，但“精准”仍然需要明确具体含义。

1. 它通常是固定时间窗

配置：

unit: minute

通常表示分钟级固定时间窗，不等同于严格的滑动窗口。

用户可能在一个窗口结束前发送 100 次请求，并在新窗口开始后立刻再发送 100 次。从任意连续 60 秒观察，流量可能接近配置值的两倍。

因此，该方案能够保证：

所有 Envoy 实例共享同一个固定时间窗计数器。

但它不自动等于：

任意连续 60 秒都绝不超过限制。

如果业务要求严格滑动窗口，需要使用 Redis Sorted Set、滑动窗口计数器或专门的配额算法。

2. 输出 Token 在请求开始时未知

如果 TPM 包含输出 Token，则无法在生成之前知道最终消耗量。

所谓严格控制通常意味着：

• 使用 max_tokens 预留；或者
• 在流式生成过程中增量扣费。

单纯在响应结束后上报实际 Token，只能用于计费和统计，不能阻止当前请求突破 TPM。

3. RPM 和 TPM 不是一个原子事务

标准 RLS 请求中的 hits_addend 是统一的，而 RPM 和 TPM 需要不同增量，因此通常需要两次调用。

如果必须保证“RPM 和 TPM 同时检查、同时增加、任意失败都不修改”，需要定制服务并使用单个 Redis Lua 脚本完成事务。

生产环境中的关键问题

1. 请求重试和重复扣费

Rate Limit Service 的计数调用通常不是业务级幂等操作。

如果适配层因为超时重试同一个请求：

第一次调用已经写入 Redis，但响应丢失
第二次调用再次增加计数

就会产生重复扣费。

建议：

• 限流调用不要盲目自动重试。
• 使用 Envoy 的 x-request-id 或业务请求 ID。
• 对严格计费场景，在适配层中实现请求幂等记录。
• 幂等记录过期时间至少覆盖限流窗口和最大请求时长。

2. 故障时 Fail Open 还是 Fail Closed

当 Redis 或 ratelimit 服务不可用时，可以选择：

Fail Open：

限流系统不可用时继续放行

优点是可用性高，缺点是可能导致成本失控。

Fail Closed：

限流系统不可用时拒绝请求

优点是保护成本，缺点是限流组件故障会影响业务。

AI 推理通常成本较高，面向外部用户的付费 API 更适合 Fail Closed。内部低风险环境可以考虑短时间 Fail Open，并配合熔断和告警。

3. Tokenizer 必须与模型匹配

不同模型的 Tokenizer 可能不同。不能使用简单的字符数除以固定比例来实现严格 TPM。

应该维护：

model -> tokenizer

例如：

gpt-family       -> cl100k/o200k 类 tokenizer
llama-family     -> 对应 SentencePiece/BPE tokenizer
自定义模型        -> 模型实际 tokenizer.json

如果 tokenizer 不可用，可以做保守估算，但必须预留误差：

estimated_tokens = ceil(raw_estimate × safety_factor)

4. 规范化模型名称

客户端可能使用：

gpt-4.1
gpt-4.1-2025-04-14
my-gpt-alias

限流前应将它们映射到统一的配额名称：

my-gpt-alias -> gpt-4.1

否则用户可能通过切换别名绕过同一模型的额度。

5. 不要信任客户端提供的 Token 数

不能让客户端直接提交：

X-Token-Cost: 1

然后按该值扣费。

Token 数必须由可信组件计算，或者由上游模型返回后进行校验。客户端声明只能作为参考，不能作为计费依据。

6. 配置发布必须一致

如果多个 ratelimit 副本加载了不同配置，可能出现：

副本 A：RPM 100
副本 B：RPM 200

即使 Redis 相同，结果也会变得不可预测。

生产环境应：

• 使用固定版本配置。
• 进行启动前校验。
• 滚动发布时保持向后兼容。
• 为配置添加版本号和监控指标。

监控指标

至少应监控：

Envoy

• ext_authz 调用次数。
• ext_authz 超时和失败次数。
• HTTP 429 数量。
• 上游请求数和并发数。
• 请求体缓冲失败次数。

AI Quota Adapter

• RPM 允许和拒绝次数。
• TPM 允许和拒绝次数。
• Token 计算耗时。
• RLS gRPC 延迟。
• Tokenizer 加载失败次数。
• 按模型和租户聚合的 Token 消耗。
• 重复请求或幂等命中次数。

Ratelimit

• OK、OVER_LIMIT、错误数量。
• Redis 请求延迟。
• Redis 连接池使用率。
• 配置加载状态。
• 各限流规则命中次数。

Redis

• CPU 和内存。
• 命令延迟。
• 连接数。
• Key 数量。
• Key 过期速率。
• 主从复制延迟。
• Failover 次数。

高基数租户 ID 不适合直接作为 Prometheus Label。否则租户数量较多时会产生严重的指标基数问题。按租户的详细用量更适合写入日志、ClickHouse 或专门的计量系统。

推荐的最终实现

对于大多数 AI API 网关，可以采用下面的组合：

Envoy
  └── ext_authz
        └── AI Quota Adapter
              ├── 解析租户和模型
              ├── 使用可信 tokenizer 计算 input_tokens
              ├── 规范化并限制 max_tokens
              ├── RPM：RLS hits_addend = 1
              └── TPM：RLS hits_addend =
                       input_tokens + max_output_tokens
                        └── envoyproxy/ratelimit
                              └── Redis

这一方案具备以下特征：

• 多 Envoy 实例共享统一额度。
• RPM 和 TPM 分别计数。
• 支持按租户、模型、套餐隔离。
• 在请求进入模型服务之前完成准入控制。
• 通过预留最大输出 Token，保证不会因为流式输出突破 TPM。
• Envoy、适配层和 ratelimit 服务都可以横向扩展。

如果还需要按照实际输出 Token 精确结算，则在此基础上增加：

预留记录 + 响应用量采集 + commit/refund + 请求幂等

此时系统已经从“限流服务”演进为一套完整的“分布式 AI 配额与计量服务”。

总结

envoyproxy/ratelimit 非常适合解决多 Envoy 实例之间的全局共享限流问题。它通过 Redis 集中维护计数器，避免每个网关实例独立计算额度。

对于 AI 场景，需要在标准 HTTP 限流之上增加 Token 感知能力：

• RPM 使用 hits_addend=1。
• TPM 使用 hits_addend=token_cost。
• 使用租户、模型和指标构建 Descriptor。
• 请求阶段通过输入 Token或最大输出 Token预留完成准入。
• 多 Envoy、多个适配层和多个 RLS 副本共享同一个 Redis 计数空间。

需要特别注意的是，分布式共享计数、固定时间窗、RPM/TPM 组合事务以及实际输出 Token 结算是四个不同问题。理解这些边界，才能构建一套既能保护模型成本、又能在高并发环境中稳定运行的 AI 限流系统。

在大模型应用快速落地的过程中，推理服务的工程化能力往往比模型本身更复杂：模型调度、路由策略、限流、灰度发布、网关治理等问题，都需要真实的推理接口进行验证。然而，大模型推理依赖 GPU 和高成本算力资源，使得开发和测试门槛居高不下。

如果你希望在没有 GPU 或资源受限的环境中验证推理架构设计，那么这个工具值得关注：

llm-d-inference-sim GitHub 项目

本文将系统介绍这个工具的能力、设计思路，以及它在实际工程中的应用价值。

工具定位：为推理工程而生的“模拟器”

llm-d-inference-sim 是一个专门用于模拟大模型推理服务的工具，其核心能力包括：

• 提供与真实 LLM 推理服务一致的接口（如 OpenAI-style API）
• 接收推理请求（prompt / messages）
• 按配置生成“模拟响应”
• 支持多实例、多模型模拟部署

简单来说，它并不真正执行模型推理，而是：

模拟“推理服务行为”，而非“推理计算本身”

为什么需要推理模拟？

在真实项目中，我们经常遇到以下问题：

1. 推理资源昂贵

• GPU 成本高（A100 / H100）
• 推理服务部署复杂（vLLM / TensorRT-LLM / SGLang）
• 测试环境难以复刻生产规模

2. 工程验证依赖真实服务

很多关键能力必须依赖推理接口验证，例如：

• API 网关路由策略（Envoy / Istio）
• 多模型调度与 fallback 机制
• embedding + intent routing
• 限流 / 熔断 / 超时控制
• 灰度发布与 A/B testing

但这些能力并不依赖模型“正确性”，只依赖：

“是否有一个行为类似 LLM 的服务存在”

llm-d-inference-sim 的核心价值

1. 零 GPU 依赖

开发者可以在以下环境直接使用：

• 本地 MacBook
• CI/CD 环境
• Kubernetes 测试集群
• 云主机（无 GPU）

无需部署任何真实模型。

2. 高度可控的响应模拟

可以模拟：

• 固定响应（用于稳定测试）
• 延迟（模拟推理耗时）
• Token 生成节奏（Streaming）
• 错误返回（测试容错）

这使它非常适合：

压测、容错测试、链路验证

3. 支持多模型实例

你可以快速部署多个“模拟模型”：

• gpt-4 模拟服务
• embedding 模型模拟
• 不同延迟 / 不同性能 profile

用于验证：

• 多模型路由策略
• 智能网关（AI Gateway）
• fallback 逻辑

4. 与真实 API 兼容

接口风格通常兼容：

• OpenAI API（/v1/chat/completions）
• streaming 输出

这意味着：

可以无缝替换真实模型服务

典型使用场景

场景 1：AI 网关 / 服务网格验证

例如使用 Envoy / Istio 构建 AI Gateway：

• 基于路径或 header 路由不同模型
• embedding-based routing
• Canary 发布

问题：没有真实模型怎么办？

使用 llm-d-inference-sim 模拟多个模型后端，即可验证完整链路。

场景 2：多模型调度系统开发

在做类似以下系统时：

• vLLM-aware scheduler
• KV Cache aware routing
• 模型负载均衡

你需要：

• 多个模型 endpoint
• 不同响应延迟
• 可控行为

模拟器可以快速构造这些环境。

场景 3：CI/CD 自动化测试

真实模型服务难以接入 CI：

• 成本高
• 不稳定
• 启动慢

使用模拟器：

• 启动快速
• 行为可预测
• 支持 mock response

非常适合集成测试（integration test）

场景 4：产品演示 / Demo 环境

在售前或内部 Demo 中：

• 不需要真实模型
• 只需要“看起来能跑”

使用模拟器可以：

• 快速部署多个模型服务
• 构造稳定演示环境
• 避免 GPU 成本

工作原理简析

llm-d-inference-sim 的设计可以理解为：

请求流程

1. 接收 HTTP 请求（如 /v1/chat/completions）
2. 解析输入（prompt/messages）
3. 根据配置规则生成响应
4. 返回 JSON 或 streaming 输出

模拟能力通常包括

• Response 模板

  • 固定文本
  • 参数化生成

• Latency 注入

  • 模拟推理耗时（如 200ms / 2s）

• Streaming

  • 分块返回 token
  • 模拟真实 LLM 输出节奏

• 错误注入

  • 500 / timeout
  • 测试重试机制

与真实推理服务的关系

模拟器 ≠ 替代模型，而是补齐工程验证环节

最佳实践建议

1. 与网关结合使用

推荐组合：

• Envoy / Istio
• AI Gateway
• llm-d-inference-sim

构建完整推理流量链路

2. 构造多模型拓扑

例如：

• model-a（低延迟）
• model-b（高质量，高延迟）
• model-fallback

验证智能路由策略

3. 注入异常场景

主动模拟：

• timeout
• 高延迟
• 错误返回

提升系统鲁棒性

4. 用于开发早期阶段

在以下阶段优先使用模拟器：

• 架构设计
• API 设计
• 路由策略验证

等到后期再接入真实模型。

总结

llm-d-inference-sim 解决的是一个被低估但关键的问题：

在没有模型的情况下，如何推进大模型工程化？

它的核心价值不在于“模拟模型”，而在于：

• 降低开发门槛
• 提升验证效率
• 解耦算力与工程

对于正在构建 AI 基础设施（AI Gateway / 推理平台 / 多模型调度系统）的团队来说，这是一个非常实用的工具。

然而，用多张卡跑模型并不是一个简单的资源堆叠问题。在实践中，工程团队很快会发现：不同的拆分方式，带来的性能表现差异可能是数量级的。有的配置 TTFT 极低，却在高并发下迅速失速；有的方案吞吐惊人，却难以满足在线服务对延迟的要求；还有一些组合在理论上看似合理，却在真实硬件拓扑下被通信成本完全吞噬。

在训练与推理阶段，业界逐步沉淀出四类核心并行策略：

• TP（Tensor Parallelism，张量并行）
• DP（Data Parallelism，数据并行）
• PP（Pipeline Parallelism，流水线并行）
• EP（Expert Parallelism，专家并行，主要用于 MoE）

大语言模型四种核心并行策略基础

Tensor Parallelism（TP）：算子级拆分

核心思想：将单层内部的矩阵计算（如 Linear / Attention）沿维度切分到多张 GPU 上并行计算。

典型拆分方式：

• Linear 层按 hidden_size 或 num_heads 切分
• Attention 的 Q / K / V 或 FFN 的中间层拆分

优点：

• 单层显存占用显著下降
• 单 token 延迟较低（适合推理）

代价：

• 每一层都需要 All-Reduce / All-Gather
• 通信频繁，对 NVLink / IB 依赖高

适用场景：

• 单模型过大但层数不多
• 对 TTFT（Time To First Token）敏感的在线推理

Data Parallelism（DP）：请求级复制

核心思想：模型完整复制到多张 GPU，每张 GPU 处理不同请求或 batch。

优点：

• 实现简单
• 无模型内部通信
• 吞吐线性扩展

代价：

• 显存需求最高（每卡一整模型）
• 单请求延迟不变

适用场景：

• 模型能放进单卡
• 离线推理 / 高并发吞吐

Pipeline Parallelism（PP）：层级切分

核心思想：将模型按层切分到多张 GPU，请求在 GPU 间流水线式流动。

优点：

• 几乎无层内通信
• 显存效率高（比 DP 好）

代价：

• pipeline bubble（气泡）带来空转
• 小 batch 下延迟显著升高

适用场景：

• 超深模型（如 70B+）
• 长序列推理或训练

Expert Parallelism（EP）：MoE 专属并行

核心思想：在 MoE（Mixture of Experts）模型中，不同 Expert 分布在不同 GPU 上，仅被激活的 Expert 参与计算。

优点：

• 参数规模大但计算稀疏
• 性能/参数比极高

代价：

• Token 路由与负载不均
• 通信模式复杂

适用场景：

• MoE 模型（如 Mixtral、DeepSeek-MoE）
• 高参数规模、可接受一定调度复杂度

并行策略并非互斥，而是可组合的

在真实系统中，并行策略通常组合使用：

问题不在于能不能用，而在于：不同组合，在真实推理负载下，性能表现差异极大。

这正是 vLLM 非常适合做验证的原因。

vLLM 中的并行能力概览

vLLM 是一个面向高性能 LLM 推理的引擎，其核心优势包括：

• 高效 KV Cache 管理（PagedAttention）
• 原生支持 TP / PP
• 对 DP 友好（多实例、多副本）
• MoE 模型中支持 EP（依赖模型实现）

在 vLLM 中，并行配置主要通过启动参数 + 资源拓扑控制。

基于 vLLM 的并行策略配置示例

Tensor Parallelism（TP）

vllm serve meta-llama/Llama-2-70b-hf \
  --tensor-parallel-size 4

含义：

• 模型每一层被拆分到 4 张 GPU
• 适合单请求低延迟验证

Pipeline Parallelism（PP）

vllm serve meta-llama/Llama-2-70b-hf \
  --pipeline-parallel-size 2 \
  --tensor-parallel-size 2

含义：

• 2-stage pipeline
• 每 stage 内 2-way TP
• 总 GPU 数 = 4

Data Parallelism（DP）

vLLM 本身不显式声明 DP，而是通过多实例部署实现：

# GPU 0-3
CUDA_VISIBLE_DEVICES=0,1,2,3 vllm serve ...

# GPU 4-7
CUDA_VISIBLE_DEVICES=4,5,6,7 vllm serve ...

再通过上层负载均衡（如 Kubernetes / Gateway）实现 DP。

Expert Parallelism（EP）

对于 MoE 模型（如 Mixtral）：

vllm serve mistralai/Mixtral-8x7B-Instruct \
  --tensor-parallel-size 4

vLLM 会自动将 Expert 分布到 TP 组内 GPU（模型内部实现 EP）。

如何在 vLLM 中“验证”并行组合的真实性能

核心评测指标

建议至少关注以下指标：

推荐对比实验矩阵

以 8 GPU 为例：

通过固定输入长度与请求并发，对比上述方案即可得到清晰结论。

实际经验结论（常见规律）

• TP 越大，TTFT 越低，但通信越重
• PP 提升显存利用率，但对小 batch 极不友好
• DP 是吞吐的唯一线性放大手段
• MoE 的 EP 在低并发下可能反而变慢

总结

并行策略没有最优解，只有最适解，TP / DP / PP / EP 并不是竞争关系，而是：

在模型规模、请求模式、硬件拓扑三者约束下的工程权衡。

vLLM 提供了一个极其适合做并行策略验证与对比实验的平台。真正有价值的工作不是“支持了什么并行”，而是：

• 在你的模型
• 在你的硬件
• 在你的真实请求负载下

验证哪种组合，才是最优解。

注意：本译文已获得的原文作者翻译授权，为避免广告嫌疑，本文中移除了特定产品和品牌的商业宣传内容，仅保留技术特性及企业级产品功能描述，相关内容请以原文为准。

随着各组织从大语言模型（LLM）的试验阶段迈向生产部署，选择哪种推理平台就成了一项关键的业务决策。这个选择不仅影响性能，也影响灵活性、成本优化，以及应对快速变化业务需求的能力。

对于技术人员和方案架构师在评估 LLM 推理平台时，应该重点考虑以下三大因素：

1. 架构灵活性：能否在不同硬件加速器和混合云环境间部署，而不会被某一家厂商锁定。
2. 运行可扩展性：支持从单 GPU 部署扩展到分布式多节点的高级部署模式。
3. 生态开放性：对最广泛的模型与内核支持，以及能与各种企业软件生态系统整合。

vLLM 在开源基础、先进内存管理能力，以及即将推出的分布式部署蓝图方面，独特地满足这些需求。与专有或硬件专用方案不同，这套组合提供了在成本、性能和运营需求上随时优化调整的自由。

本文将深入分析为何 vLLM 在其技术架构与能力上（尤其是其 KV-Cache 管理、并行策略，以及未来的 llm-d 分布式能力）提供了最可持续的生产级 LLM 部署路径。

开源优势

社区驱动的大规模创新

LLM 推理的发展，根本上受到开源创新的推动。过去一年半以来 vLLM V1: A Major Upgrade to vLLM’s Core Architecture | vLLM 博客（英文版），vLLM 在支持多样模型、功能和硬件后端方面取得显著成绩，从伯克利大学的研究项目成长为开源 AI 生态中的事实标准之一 vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。

vLLM 社区发展参考链接

vLLM 现在隶属于 PyTorch 基金会托管项目（GitHub — vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs），这保证了其长远的可持续性和治理机制。

企业支持与开源结合

许多企业及产品及解决方案对 vLLM 的态度类似于其对 Linux/OpenStack/Kubernetes 的策略：在社区驱动创新基础上，加入企业级支持、安全性和运维工具。这样模型即可部署在本地、公有云或混合云中，避免绑定。

这种方式带来的好处包括：

• 无厂商绑定：用户可自由选择部署环境
• 透明开发：安全漏洞与缺陷公开追踪与快速修复
• 社区贡献共享：一个组织开发的功能惠及整个生态
• 可定制性：源代码开放，可针对特定需求修改

此外，vLLM 在以下方面具备战略优势：

• 硬件无关性：不局限于 NVIDIA，支持 AMD、Intel、TPU 等多种平台（GitHub — vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs）
• 快速功能迭代：vLLM v1 对其核心模块（调度器、KV 缓存管理、worker、采样器、API 服务等）进行了全面重构（vLLM V1: A Major Upgrade to vLLM’s Core Architecture | vLLM 博客（英文版））
• 生态整合：原生兼容 Hugging Face、OpenAI API、Kubernetes 生态
• 成本优化：可以为不同工作负载选择最具性价比的硬件

架构灵活性与并行化策略

理解并行化（Understanding Parallelization）

大型语言模型带来了特殊的扩展挑战。例如：一个拥有 70B 参数 的模型，仅其权重（使用 FP16 精度）就需约 140GB 内存，这远远超过单一卡片的容量。基于 vLLM 及相关产品和解决方案通过四种互补的并行化策略来应对这些挑战，每一种策略都解决不同类型的扩展问题。

数据并行（Data Parallelism, DP）：跨请求扩展

数据并行是最简单的一种扩展模式：在多个服务器上运行完整模型的多个副本，每个副本处理不同的请求批次。在这种模式下：

• 维护完整模型：每个加速器／服务器保存整个模型的权重。
• 分配请求：请求由负载均衡器分发给不同的副本。
• 支持线性扩展：增加服务器数目可以线性提升吞吐量。
• 简化部署：部署相对简单，不需要对模型进行切分（sharding）。

          [负载均衡器]
               |
    ------------------------
    |          |           |
[Server1]  [Server2]  [Server3]
[Model A]  [Model A]  [Model A]
    |          |           |
[Batch 1]  [Batch 2]  [Batch 3]

关键：每台服务器都有完整的模型副本并行处理不同的请求

此模式与基于 KServe 的 Replica-Sets 用于模型副本服务很好的契合，能自动根据请求负载进行扩展，同时保有模型服务的简单性。

流水线并行（Pipeline Parallelism, PP）：按层分配

流水线并行将模型按照层（layers）分拆，不同的加速器处理不同的网络层：

• 顺序处理：请求在 GPU 间依次通过模型层进行处理。
• 内存均衡：内存需求在多个设备间较为均匀分布。
• 灵活部署：部署灵活，可以跨多个节点，不一定依赖特别高速的互联。
• 微批处理：通过微批处理（micro-batching）来保持 GPU 利用率。

Request → [GPU1:NN-Layers 1-8] → [GPU2:NN-Layers 9-16] → [GPU3:NN-Layers 17-24] → Response
             ↓                     ↓                      ↓
          [Memory]              [Memory]               [Memory]
          
时间线：请求按顺序流经 GPU

但流水线并行在现代 LLM 应用中也面临一些限制：

• “流水线气泡”（pipeline bubble）效率低下：某些 GPU 在等待上游阶段的数据时处于空闲状态。
• 通信开销高：阶段间数据传输成为瓶颈。
• 延迟敏感：每个阶段都会增加延迟，对“第一个 token 的时间”（time-to-first-token）有负面影响。
• 对 MoE（Mixture of Experts，混合专家模型）不友好：MoE 模型中只激活某些专家（非密集执行），这样无法很好地映射到按层划分的流水线结构中。

因为这些限制，很多生产环境更倾向于将张量并行（Tensor Parallelism）用于节点内部扩展，将数据并行（Data Parallelism）用于跨节点扩展。尽管如此，在内存受限或与其他并行策略组合使用的场景中，流水线并行仍然有价值。

张量并行（Tensor Parallelism, TP）：切分模型权重

当模型太大，单个加速器无法容纳其所有权重时，就使用张量并行来将模型权重拆分到多个 GPU 上：

• 水平层拆分：每次矩阵乘法操作被分配到多个 GPU，按部分计算。
• 同步计算：GPU 之间通过高速互联（如 NVLink、Infinity Fabric 等）进行同步和数据交换。
• 内存效率：可使得模型可服务的规模比单个 GPU 容量大出约 4～8 倍。
• 低延迟：如果硬件条件合适，通信开销低的话，张量并行还能保持较低的延迟。

Original Matrix Operation:
[Large Weight Matrix] × [Input] = [Output]

With Tensor Parallelism:
[Weight Part 1] → GPU1 ↘
[Weight Part 2] → GPU2 → [Combine] → [Output]
[Weight Part 3] → GPU3 ↗

关键：单矩阵运算跨 GPU 拆分，需要高速互连（NVLink）

vLLM 的张量并行实现是硬件无关的，支持多种互联技术和不同类型的加速器。

专家并行（Expert Parallelism, EP）：MoE 模型中的专家分布策略

对于混合专家模型（MoE），专家并行把不同的专家（experts）分配给多个 GPU 或多个节点，而不是让每个 GPU 都保存所有专家，由一个路由层（router layer）动态地将 token 分发给需要的专家：

• 分布式专家分片：专家（experts）被分片（shard）分布在不同的 GPU／节点，使拥有上百个专家的模型能扩展到远超过单设备的内存容量。
• 动态 token 路由：每个 token 只被发送到它应使用的一个或多个专家，以减少计算开销。
• 专家并行负载平衡（Expert Parallel Load Balancing, EPLB）：防止某些热门专家／专家组被频繁调用导致不均匀负载，通过动态复制或分布专家，以分散负载。
• 分层调度（Hierarchical Scheduling）：在多节点集群中，路由与复制先在节点间协调，再在节点内部的 GPU 间协调，确保整体利用率均衡且减少跨节点通信。
• 性能收益：对大型的 MoE 模型，这种专家并行在具有高速互联（NVLink、InfiniBand 等）的环境中可以实现接近线性扩展的吞吐效率。

               [Router Layer]
                      |
        ---------------------------------
        |          |          |         |
      GPU1        GPU2       GPU3      GPU4
    [Exp 1,2]   [Exp 3,4]  [Exp 5,6]  [Exp 7,8]
    
令牌流：路由器 → 选定专家 → 输出

vLLM 的统一策略

vLLM 的区别与优势在于它能够无缝结合这些并行策略，为分布式推理提供高度灵活性，使组织能够：

1. 混合使用策略：例如，在节点内部用张量并行，在节点间用流水线并行。
2. 根据硬件特性调整：基于可用的互联速度、GPU 内存、延迟敏感性等因素做最优规划。
3. 动态扩展：可以从单节点部署起步，随着需求增长扩展到多节点／多 GPU。
4. 保持 API 的一致性：无论使用哪种并行策略，道线路径、调用接口等对使用者尽量透明，不需要因为并行方式不同而改很多逻辑。

这种灵活性在混合云环境中尤其关键，因为不同环境（本地、云端、不同厂商硬件）之间的配置可能大不相同。

Hybrid TP+PP+EP+DP Deployment (MoE Model):

Pipeline Stage 1:               Pipeline Stage 2:              Pipeline Stage 3:
Node 1 (Attention Layers)       Node 2 (MoE FFN Layers)        Node 3 (Output Layers)
[Attn Part A] ←→ [Attn Part B]  [Router + Experts Subset]      [Out Part A] ←→ [Out Part B]
    GPU1           GPU2          GPU3: Experts 1-4                  GPU5            GPU6
         ↕ NVLink ↕              GPU4: Experts 5-8                       ↕ NVLink ↕
                                     ↕ NVLink ↕

Expert Distribution Detail (Node 2):
            [Router]
         GPU3  |  GPU4
        -------|-------
        Exp1   |  Exp5
        Exp2   |  Exp6  
        Exp3   |  Exp7
        Exp4   |  Exp8

Request Flow: → [Attention] → [MoE Layer/Router] → [Output] → Response
                              ↓
                    [Route to specific experts]

Parallelization Breakdown:
- Tensor Parallel (TP): Attention and Output layers split within nodes.
- Pipeline Parallel (PP): Different model stages across nodes .
- Expert Parallel (EP): MoE experts distributed across GPUs in Node 2.
- Data Parallel (DP): Entire pipeline can be replicated for more throughput.

更好的内存管理：KV-Cache（Key-Value 缓存）

在 LLM 推理中理解 KV-Cache

KV-Cache（键-值缓存）是 LLM 推理优化中最关键的特性之一。在注意力计算期间，模型必须访问先前 token 的表示 —— 随着序列长度增长，这个过程变得非常消耗内存。

高效的 KV-Cache 管理能决定同一硬件上能同时服务 10 个并发用户或 100 个并发用户，因为缓存复用将计算换成内存利用率。

(Q * K^T) * V computation process with caching

Step 1 (Prefill Phase)
                    Keys Transpose
                          ↓
    Queries              Keys              Values            Results
       |                  |                  |                  |
    [  Q  ]      ×     [  K  ]      →    [Scores]     ×    [  V  ]    →    [Output]
       |                  |                  |                  |
      64                 64                                    64              64
                          ↓                                     ↓
                    [Storing K]                           [Storing V]
                          ↓                                     ↓
                    ←── Cache memory (stores both K and V) ──→

Step N (Decode Phase)
                    Keys Transpose
                          ↓
    Query              Cached K            Cached V          Results
       |                  |                  |                  |
    [  q  ]      ×   [K₁...Kₙ]      →    [Scores]     ×   [V₁...Vₙ]   →    [output]
    (new)             (from cache)                         (from cache)       (new)
       |                  |                  |                  |
       1                 64                                    64               1
                          ↑                                     ↑
                    ←── Reading from cache (both K and V) ──→

Key Points:
- Prefill: Computes K and V for all input tokens, stores both in cache
- Decode: For each new token, reads ALL previous K and V values from cache
- Both K and V matrices must be cached (not just V)
- Cache size grows with sequence length

Prefill 阶段 vs Decode 阶段：两个截然不同的阶段

LLM 推理包含两个本质不同的阶段：

Prefill 阶段（Prompt 处理阶段）

• 并行处理所有输入 token。
• 计算密集型，GPU 利用率高。
• 为 prompt 中的所有 token 生成初始的 KV-Cache 条目。
• 延迟与 prompt 长度成正比。
• 大批量（larger batch sizes）带来好处。

Decode 阶段（Token 生成阶段）

• 一个 token 一个 token 顺序生成。
• 此阶段受限于内存带宽（memory-bandwidth bound）。
• 每新增一个 token，都要读取整个 KV-Cache 来自缓存的所有先前的 K 和 V。
• 延迟与输出 token 数量成正比。
• 依赖高效的缓存管理。

PagedAttention：vLLM 的内存革命

vLLM 引入 PagedAttention，这是一种在 KV-Cache 管理方面的突破性设计，它将 GPU 内存视为类似操作系统中的虚拟内存（virtual memory）来处理，其关键设计包括：

• 非连续存储（Non-contiguous Storage）：KV-Cache 块可以存储在 GPU 内存的任意地方，不必是连续的。
• 动态分配（Dynamic Allocation）：随着序列长度增长时才分配内存。
• 内存共享（Memory Sharing）：完全相同的 prompt 前缀（prompt prefixes）可以共享 KV-Cache 块。
• 几乎零浪费（Near-Zero Waste）：消除静态分配中常见的内部碎片问题。

这种设计让 vLLM 可以维持更大的批量大小、更高的并发性、以及比那些依赖静态、大型 KV-Cache 缓冲区的系统更好的 GPU 利用率。

连续批处理（Continuous Batching）：最大化 GPU 利用率

vLLM 的连续批处理机制带来了几个举措：

• 动态请求加入：新的请求可以在 decode 步骤之间加入正在运行的 batch。
• 提前完成处理：已经完成的序列立即释放资源。
• GPU 使用最优化：通过混合处理 prefill 与 decode 操作以保持高利用率。
• 支持抢占（Preemption）：可以暂停低优先级的请求以优先处理紧急请求。

在部署中的实际意义

这些内存管理上的创新在实际部署中带来了具体的效益：

1. 更高的并发性：在相同硬件上服务更多用户。
2. 更佳的成本效率：大幅减少基础设施需求。
3. 改善延迟：通过高效调度缩短 time-to-first-token。
4. 灵活性：可以处理变长的序列长度，而无需重新配置系统。

KV-Cache 优化在即将推出的 llm-d 分布式架构中变得尤为关键，因为高效的内存使用使得过去因内存约束而无法实现的新部署模式成为可能。

使用 llm-d 扩展：Kubernetes 原生的分布式推理

超越单服务器部署

虽然 vLLM 自身是高性能推理引擎，但在大规模生产环境中，还需要复杂的编排和智能请求调度。2025 年 5 月，红帽、Google Cloud、IBM 研究院、NVIDIA 和 CoreWeave 联手推出 llm-d，构建在 vLLM 之上的 Kubernetes 原生分布式推理栈。

llm-d 并不是 vLLM 的内置功能，而是一个补充的编排层。可以把它比作 Linux 与 Kubernetes 的关系：vLLM 负责推理引擎，llm-d 负责跨实例的调度与编排。它结合了三项开源技术：vLLM、Inference Gateway（AI 路由层）和 Kubernetes。

KServe 也在集成 llm-d，通过新的 LLMInference CRD，实现统一的服务接口，简化生成式 AI 的企业上手路径。

llm-d 将三大基础开源技术集成到一个统一的服务栈中：

• vLLM - 执行模型推理的高性能推理引擎。
• 推理网关（IGW） - 一个官方 Kubernetes 项目，通过 AI 感知路由扩展了 Gateway API。
• Kubernetes - 用于部署和扩展的行业标准编排平台。

通过整合这些技术，llm-d 使企业能够在混合云环境中大规模部署 LLM 推理，并实现最快的价值实现时间和极具竞争力的性价比。

三项关键创新

传统的负载均衡采用简单的轮询（round-robin）路由，对所有服务器一视同仁。llm-d 的 vLLM 感知调度程序能够做出智能决策，将请求路由到具有匹配缓存前缀的实例，根据实例是处理计算密集型预填充操作还是内存密集型解码操作来分配负载，并使用来自 vLLM 的实时可观测数据来避免实例过载，同时优先处理低延迟路径。这种智能路由可将基础设施成本降低 30% 到 50%，同时保持延迟 SLO。

解耦式服务（Disaggregated Serving）

llm-d 在生产规模上协调 vLLM 的本机分解服务（通过 KVConnector API），将预填充和解码分离到专门的工作节点中：

• 预填充工作节点：负责计算密集型的提示处理，使用高性能 GPU（如 H100、MI300X），并可根据需求独立扩展。

• 解码工作节点：专注于受内存带宽限制的 token 生成任务，使用具成本效益的 GPU（如 A100、L40S），并根据并发会话数进行弹性扩缩。

• KV 缓存传输：使用 NVIDIA NIXL 通过 UCX 提供高效的缓存移动，支持卸载到存储后端（未来交付）以及跨集群的全局缓存感知。

这允许适当规模的基础设施：昂贵的 GPU 仅用于预填充，成本优化的硬件可为数千个并发用户提供服务。

分布式前缀缓存（Distributed Prefix Caching）

llm-d 将 vLLM 的前缀缓存扩展到多个实例之间，通过两种方式实现：

• 本地缓存：在每个实例上将缓存卸载（offload）到内存或磁盘，几乎没有运维成本。

• 共享缓存（计划中）：通过实例之间的 KV 传输实现共享，并使用全局索引实现集群范围的缓存感知。

部署模式（Deployment Patterns）

llm-d 支持多种先进的企业部署模式：

• 异构硬件：根据工作负载混合 GPU 供应商和代数——用于预填充的高端 GPU、用于解码的成本优化 GPU 或用于低频请求的 CPU 集群。

• 动态扩缩：在高峰时段独立调整预填充容量，同时保持活动会话的稳定解码容量，并具有自动资源分配和故障转移功能。

• 地理分布（规划中）：在主数据中心部署集中式预填充工作者，并在用户附近部署边缘解码工作者，以实现低延迟响应。

多加速器与混合云支持

摆脱硬件锁定

AI 加速器快速演进，使市场变得多样化。专优化 NVIDIA 的方案如 TensorRT-LLM 虽然性能优秀，但容易导致锁定。vLLM 的硬件中立设计则允许用户自由选择最适合的加速器。

广泛硬件支持

vLLM 支持 NVIDIA GPU（针对 H100 进行一流的优化，支持 V100 及更新版本的所有 NVIDIA GPU）、AMD GPU（MI200、MI300 和 Radeon RX 7900 系列）、Google TPU（v4、v5p、v5e 和最新的 v6e）、AWS Inferentia 和 Trainium（trn1/inf2 实例）、Intel Gaudi（HPU）和 GPU（XPU）以及支持 x86、ARM 和 PowerPC vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。

这种广泛支持带来以下战略优势：

成本优化

• 选择 AMD MI300X，在特定工作负载下实现高性价比。
• 使用 AWS Inferentia，在 AWS 上进行经济高效的推理。
• 在低吞吐量用例中，可部署在现有 CPU 基础架构上。

供应链弹性

• 避免依赖单一 GPU 供应商的可用性。
• 通过多种选择协商更优惠的价格。
• 根据区域硬件可用性进行调整。

工作负载匹配

• NVIDIA H100 可实现最佳性能。
• AMD GPU 适用于开源部署。
• TPU 适用于 Google Cloud 部署。
• Intel Gaudi 适用于特定企业协议。

混合云部署模式

在企业级产品及解决方案中，vLLM 支持真正的混合云：

本地核心

• 在本地基础架构上处理敏感数据。
• 满足合规性要求的工作负载。
• 可预测的基线负载容量。

云爆发式扩展

• 利用云资源处理峰值负载。
• 试用新硬件（H100s、TPU v6e）。
• 无需基础设施投资即可实现地域扩展。

边缘推理

• 部署在适合边缘计算的硬件上。
• CPU 或更小的 GPU 推理。
• 与集中管理集成。

统一运维跨环境

借助企业级产品的相关功能，用户可从单一控制平面管理全部部署（公有云 + 私有云），主要从一下几个方面考虑。

• 单一控制平面：通过统一界面管理所有部署。
• 一致的 API：跨环境实现相同的应用程序集成。
• 统一监控：跨混合部署的聚合指标。
• 策略执行：一致的安全和合规策略。

模型生态与兼容性

支持广泛的开源模型体系

随着人工智能“淘金热”步伐的加快，vLLM 已发展到支持超过 100 种模型架构的高性能推理：涵盖几乎所有著名的开源大型语言模型（LLM）、多模态模型（图像、音频、视频）、编码器-解码器模型、推测解码模型、分类模型、嵌入模型和奖励模型。vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。与专注于有限模型系列的专业解决方案相比，这种全面的支持具有根本性的优势。

不只是传统 LLM

vLLM 的架构支持更多样的模型类型：

语言模型

• Llama 系列。
• Mistral 和 Mixtral 多模态模型。
• Google 的 Gemma 模型。
• IBM 的 Granite 系列。
• 阿里巴巴的 Qwen 模型。

多模态模型

• 视觉-语言模型（LLaVA, Qwen-VL）。
• 文档理解模型。
• 音频-语言模型。
• 视频理解能力。

专用架构

• 状态空间语言模型的生产支持，探索非 Transformer 语言模型的未来。vLLM 2024 Retrospective and 2025 Vision | vLLM 博客（英文版）。
• 混合专家（MoE）模型。
• 编码器-解码器架构。
• 嵌入和重排序模型。

模型集成简易流程

将新模型加入 vLLM 通常包括以下步骤：

1. 模型架构定义：使用熟悉的 PyTorch 模式实现。
2. Attention 后端集成：利用现有的优化内核。
3. Tokenizer 支持：兼容 Direct Hugging Face。
4. 配置映射：基于标准 YAML 的配置。

这样的标准化流程意味着组织能更快将新模型投入生产。例如，在 2025 年 8 月 GPT-OSS 发布后不久，vLLM 的 v0.11.0 版本就加入了对其生产部署的支持。

与 Hugging Face 生态整合

vLLM 与 Hugging Face 的原生兼容带来了便捷性：

直接模型加载

• 直接从 Hugging Face Hub 和/或兼容 S3 的对象存储后端（例如 MinIO）加载模型。
• 支持私有模型库。
• 自动权重转换处理。

分词器兼容性

• 使用现有的分词器实现。
• 支持自定义分词器。
• 快速分词器优化

配置保存

• 尊重特定于模型的配置。
• 支持自定义模型参数。
• 兼容经过微调的变体。

生产级模型管理

在一些企业级产品和方案中增加了模型生命周期的企业功能：

模型注册集成

• 已部署模型的版本控制。
• A/B 测试功能。
• 回滚机制。

模型监控

• 每个模型的性能跟踪。
• 使用情况分析和成本归因。
• 偏差检测功能。

面向未来的模型支持

模型创新速度极快，推理平台必须具备适应能力：

社区贡献

• 活跃的社区不断添加新模型。
• 供应商中立的开发流程。
• 快速集成突破性架构。

灵活的架构

• 模块化设计支持新的模型范式。
• 不受特定模型假设的约束。
• 为后转型架构做好准备。

企业验证

• 企业的测试和认证流程。
• 模型工件的安全扫描。
• 跨硬件性能验证。

这种全面的模型支持确保组织能够在新模型出现时立即采用它们，而无需进行平台迁移或架构更改，这是人工智能领域持续快速发展的一项关键能力。

使用企业级产品进行企业部署

从第一天起就是生产级

大多数企业级产品提供了一个灵活、可扩展的 MLOps 平台，提供构建、部署和管理 AI 应用的工具。它采用开源技术构建，为团队提供值得信赖且操作一致的功能，用于实验、模型服务和交付创新应用。了解更多关于企业级产品如何应对这一挑战的信息。

与 KServe 的整合：智能模型服务

在许多产品和方案中对 vLLM 与 KServe 的集成提供了企业级服务功能：

GenAI 功能

• 使用 vLLM 服务运行时进行多节点/多 GPU 推理。
• 通过 vLLM + LMCache 集成卸载键值缓存。
• 通过模型缓存高效重用模型。
• 集成 KEDA，允许基于外部指标自动扩缩。
• 通过与 Envoy AI Gateway 集成实现速率限制和请求路由。
• 通过 LLMInferenceService CRD 访问 llm-d 功能。

高级自动扩缩

• 基于请求的扩缩，实现资源利用率优化。
• 缩减​​至零功能，实现成本优化。
• 基于流量模式的预测性扩缩。
• 多指标扩缩（GPU 利用率、队列深度、延迟）。

流量管理

• 金丝雀部署，确保模型更新安全。
• 蓝绿部署，实现即时回滚。
• A/B 测试，用于模型比较。
• 影子流量，用于验证。

服务网格集成

• 使用 Istio 进行端到端加密。
• 高级路由和负载均衡。
• 熔断和重试逻辑。
• 用于调试的分布式跟踪。

自动化运维

• 健康检查和自动恢复。
• 资源优化建议。
• 自动化证书管理。
• 日志聚合和分析。

安全与合规

在企业部署中，必须重视安全：

访问控制

• RBAC 与企业身份提供商集成。
• 模型级访问权限。
• API 密钥管理。
• 所有操作的审计日志记录。

数据保护

• 静态和传输中加密。
• 私有端点选项。
• 网络策略实施。
• 合规性报告工具。

供应链安全

• 签名容器镜像。
• SBOM（软件物料清单）生成。
• 漏洞扫描。
• 基于策略的部署控制。

MLPerf 验证的性能

一些企业级解决方案和产品与众多知名服务器原始设备制造商（OEM）合作，使用搭载 NVIDIA GPU 和 vLLM 推理运行时的产品发布了令人印象深刻的 MLPerf 推理结果，在应对这一挑战方面取得了重大进展。加速生成式 AI 的采用，这些结果验证了：

• 规模化生产级性能。
• 高效的资源利用率。
• 负载下一致的延迟。
• 多实例协调能力。

集成可观测性

无需额外工具即可进行全面监控：

指标和仪表板

• 预建 Grafana 仪表板，用于 vLLM 指标。
• 预建 Grafana 仪表板，用于驱动路由决策的请求调度程序指标。
• 令牌生成率和延迟。
• GPU 利用率和内存使用率。
• 队列深度和拒绝率。

警报和响应

• SLA 违规自动警报。
• 与企业监控系统集成。
• Runbook 自动化功能。
• 容量规划洞察。

成本管理与优化（未来交付）

专为企业成本控制设计的功能：

• 计费/显示：按团队或项目跟踪使用情况。
• 资源配额：防止成本失控。
• 竞价型实例支持：降低批量工作负载的成本。
• 空闲检测：自动缩减未使用的资源。

这个企业级平台将 vLLM 从高性能推理引擎转变为完整的生产解决方案，可用于关键任务部署。

特性对比：vLLM vs TGI vs TensorRT-LLM

✓ = 全面支持，◐ = 部分/有限支持，✗ = 不支持

企业级产品与开源 vLLM 的主要区别

• 硬件灵活性：最广泛的加速器支持，包括 AMD、Intel、Google TPU 和 CPU。
• 模型生态系统：支持超过 100 种模型架构，而其他替代方案仅有 25-40 种。
• 分布式架构：即将推出的 llm-d 支持分解式预填充/解码和系统级 kv-cache 路由，以实现分布式最优扩展。
• 企业集成：企业级产品集成 KServe 自动扩展。
• 内存效率：先进的 PagedAttention 和 KV-Cache 管理。
• 开放开发：PyTorch 基金会项目，社区创新迅速。

如何作出正确选择

文中给出一个简单的决策框架：对每个判断点打 “Yes”：

• 0–2 个 “Yes”：可考虑专用方案（若其满足你的特定需求）
• 3–5 个 “Yes”：vLLM 在你的场景中将提供显著优势
• 6+ 个 “Yes”：基于 vLLM 的企业级产品是战略性选择

每个决策点都涉及基本的架构约束：

• 灵活性要求决定您是否需要与硬件无关的解决方案。
• 运营复杂性评估简化的运营是否值得采用开源技术。
• 模型与创新评估快速发展是否需要一个适应性强的平台。
• 长期可持续性考虑总体拥有成本和战略风险。

战略推荐

如果你对多个维度都倾向 “Yes”，那 vLLM + 企业级产品将提供：

• 最大的灵活性：可在任何受支持的硬件上部署。
• 优秀的运维体验：企业级平台，复杂性极低。
• 面向未来的能力：支支持新兴模型和架构。
• 成本优化：为每种工作负载选择最佳硬件。
• 风险控制：开源基础，提供企业级支持。

这些因素的融合使得 vLLM 成为构建可持续人工智能基础设施的组织的战略选择。

采纳步骤建议

立即阶段

• 在开发环境部署 vLLM + 企业级产品
• 用自己的模型和工作负载进行测试
• 验证硬件灵活性与性能

短期阶段

• 实施 KServe 的自动扩缩能力
• 建立监控与可观察性体系
• 培训团队操作流程

中期阶段

• 设计生产部署架构
• 若需要，实施混合云模式
• 为 llm-d 分布式架构做准备

长期阶段

• 优化成本（选硬件、资源调度）
• 引入更高级部署模式
• 将自己的改进贡献给社区

总结

选择 LLM 推理平台代表着一项战略承诺，它将影响您组织未来几年的人工智能能力。

我们的分析表明，企业级产品上的 vLLM 独特地满足了企业 LLM 部署的三个关键要求：

1. 灵活性：可在任意硬件与混合云环境部署
2. 可扩展性：先进内存管理与 llm-d 架构使资源利用效率提升 10–100 倍
3. 可持续性：开源基础 + 企业支持，避免陷入锁定

虽然 TensorRT-LLM 提供了 NVIDIA 专属优化，TGI 也提供了 Hugging Face 集成，但“只有 vLLM 能够提供快速发展的 AI 领域所需的架构灵活性”。 凭借对 100 多种模型架构的支持、与硬件无关的设计以及 PyTorch 和 Linux 基金会的支持，->“搭载 vLLM 的企业级产品为长期成功奠定了最坚实的基础”。

VibeVoice 是 Microsoft Research 发布的一套面向长篇、多说话人、对话式语音合成的研究框架，目标场景例如整集播客、有声剧或访谈：能在单次生成中维持说话人一致性并处理自然的换手（turn-taking）。模型家族包含多个规模（例如 1.5B、7B 等），并在 Hugging Face 上以 microsoft/VibeVoice-1.5B 形式开放（模型卡、模型文件、model card 中有安装/使用与责任使用说明）。

它解决了传统 TTS（Text-To-Speech）系统的一些痛点，比如：

• 难以维持长时间对话的语音一致性（speaker consistency）；
• 多说话人的切换自然性（turn-taking）差；
• 效率低 — 长文本 + 多说话人时，资源消耗大。

核心创新与架构

VibeVoice 有几个比较新的或者关键的技术设计：

架构图如下：

优点和局限

优点

1. 长篇幅对话能力 — 能生成近 90 分钟的连续对话，并维持说话人一致性。
2. 多说话人支持 — 最多支持 4 个不同说话人的切换，且对话流程自然。
3. 压缩效率高 — 用 7.5 Hz 帧率的 speech tokenizer，音频被高度压缩但仍保证质量。
4. 语义 + 声学分离 — 语义 tokenizer（semantic）负责内容，声学 tokenizer（acoustic）负责声音细节，两者协同。

局限

1. 语言支持有限 — 目前主要是英语与中文，跨语言能力还在研究中。
2. 背景音乐 / 音效不支持 — 当前专注纯语音合成，没有加入背景音或重叠说话人（speaker overlap）。
3. 仓库暂时关闭 — 官方声明因 “部分用途超出初衷 / 不符合责任使用” 的情况，仓库暂时被 disable。意味着可能无法立即拿到源码或全部功能。
4. 硬件要求 / 资源消耗 — 虽然压缩效率高，但生成长篇语音 + 多说话人 + 高保真度仍需要较好的 GPU 资源。
5. 潜在滥用风险 — 用来做语音克隆、假扮、deepfake 等可能的恶意用途。官方在文档中也提到要谨慎。

快速上手

下面给出具体实现步骤及上手流程。注意：由于官方仓库目前不包含完整脚本，实际推理通常依赖社区实现或 Hugging Face Spaces / Colab 示例。所列步骤已参考 Hugging Face 模型页与社区示例仓库。

先决条件

• Python 3.8+；建议在隔离虚拟环境（venv / conda）中操作。

• GPU：带 CUDA 的 NVIDIA GPU（具体 VRAM 与性能见第 5 节）。若使用 Apple Silicon / macOS，可参见社区讨论与专门脚本。

• 安装工具（示例）：

  • pip install huggingface_hub transformers accelerate torch soundfile torchaudio numpy einops
  • 本地需要 ffmpeg（用于音频切分/拼接与格式转换）。

  具体版本请按 PyTorch 官网或社区脚本说明选择（不同 CUDA 版本的 wheel 不同）。参考社区仓库的 requirements 列表以确保兼容。

下载模型权重

from huggingface_hub import snapshot_download
model_dir = snapshot_download("microsoft/VibeVoice-1.5B")
print("模型已下载到", model_dir)

注意：snapshot_download 会把 HF 模型文件和模型卡同步拉取到本地；若模型文件较大，请确保磁盘与网络条件。

使用社区推理脚本

很多社区仓库或 Hugging Face Spaces 提供了 demo/inference_from_file.py 之类的脚本。示例命令：

# 在 Colab / 本地环境中操作
git clone https://huggingface.co/technicalheist/vibevoice-1.5b
cd vibevoice-1.5b
# 安装 Python 依赖（按模型页 “Requirements” 部分）
pip install torch transformers soundfile ffmpeg-python  # plus 其他必要包

# 创建一个 transcript 文件，比如 transcript.txt
echo "Speaker 1: Hello, how are you doing?
Speaker 2: I'm good, thanks. What about you?" > transcript.txt

# 用 demo 脚本生成语音
python demo/inference_from_file.py \
  --model_path /path/to/technicalheist/vibevoice-1.5b \
  --txt_path transcript.txt \
  --speaker_names "Alice,Bob"

社区实现（例如 technicalheist/vibevoice-1.5b、shijincai/VibeVoice 等）提供了可运行的示例与依赖说明；使用前请仔细阅读其 README 并依据其中的依赖和指引来配置环境。示例脚本名与参数在不同实现中可能不同，请以具体仓库中的文档为准。

简单示例

Speaker 1: Hello, welcome to our podcast.
Speaker 2: Thanks — happy to be here. Let's talk about VibeVoice.
Speaker 1: Sure, start with the key idea...

将上面保存为 transcript.txt 并传入 --txt_path 即可（脚本会解析说话人标记并输出对应音轨）。社区脚本通常会把每个说话人的音色/说话风格作为参数或示例内置。

结论

微软的 VibeVoice 是当前 TTS / 语音合成领域一个非常令人兴奋的进展。它在长篇幅语音 + 多说话人上取得了突破，尤其是在对话流畅性和说话人一致性方面，技术设计（如低帧率的双 tokenizers + next-token diffusion + LLM 架构）也很前沿。

如果你正在做播客、有声书或者对话剧本的语音合成，这可能是一个非常有用的工具／研究基础。不过在商业部署或者包含敏感语音身份／法律边界用途时，需要格外注意责任使用，以及是否有完整的许可与风险评估。

SGLang 简介

SGLang 是一款面向大语言模型（LLM）和视觉语言模型（VLM）的高性能推理框架，通过精心设计的后端运行时与前端语言协同工作，使模型交互更加高效且可控。其核心优势包括：

• 高效后端运行时：采用创新的 RadixAttention 技术实现前缀缓存，支持跳跃式受限解码、零开销 CPU 调度、连续批处理、令牌注意力（分页注意力）、张量并行、FlashInfer 内核、分块预填充以及多种量化技术（FP8/INT4/AWQ/GPTQ），显著提升推理效率。
• 灵活前端语言：提供直观且强大的 LLM 编程接口，支持链式生成调用、高级提示工程、复杂控制流、多模态输入、并行处理及外部系统交互。
• 广泛模型兼容性：支持多种主流生成式模型（Llama、Gemma、Mistral、QWen、DeepSeek、LLaVA 等）、嵌入模型（e5-mistral、gte）及奖励模型（Skywork），并提供简便的新模型扩展机制。
• 活跃开源生态：拥有蓬勃发展的社区支持，已获得广泛业界认可（截至 2025 年 3 月 17 日，GitHub 累计星标超过 12,000）。

其技术架构如下：

除此之外，对于初学者，需要了解其以下特性：

• OpenAI 兼容 API：直接用 openai Python SDK 或 cURL 调用，不用改你的上层业务代码。
• 高吞吐与低延迟：结合连续批处理与前缀缓存等技巧，让相同前缀的请求复用计算。
• 生产友好：支持多并发、流式输出、可与 Hugging Face 模型库直接对接。

环境准备

工欲善其事必先利其器，要完成本文的新手实验，需准备如下环境：

• 操作系统：建议 Linux（常用为 Ubuntu 20.04+）。WSL2 也可尝试。
• Python：建议 3.10 或 3.11。
• GPU：建议 NVIDIA 显卡，24GB 显存可跑 7B/8B 级（如 Llama 3.1 8B）。没有 GPU 也能跑小模型或量化模型，但性能有限。
• 模型来源：Hugging Face（如 meta-llama/Llama-3.1-8B-Instruct）或本地路径。

安装 SGLang

环境就绪后，使用 pip 安装 SGLang（确保已安装 pip、可选创建虚拟环境）。

pip install sglang openai huggingface-hub

如果你需要从 Hugging Face 自动下载私有或受限模型，请先登录或设置 Token：

huggingface-cli login
# 或
export HF_TOKEN=您的Token

启动 SGLang 服务

可以通过以下两种启动方式进行 SGLang 服务的启动。不同版本的 SGLang 命令行参数可能略有差异，如果出现参数名称不匹配，先执行 –help 查看本机版本支持的参数。

通过 launcher 启动

python -m sglang.launcher \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --host 0.0.0.0 \
  --port 30000 \
  --tp 1 \
  --max-model-len 8192

其中常用参数说明如下：

• –model：Hugging Face 模型名称或本地模型权重路径
• –host/–port：服务监听地址与端口
• –tp：Tensor Parallel 并行度（单卡设为 1；多卡可根据需要设为 2、4 等）
• –max-model-len：上下文最大长度

另外需要注意以下两点：

• 如果使用的是 Hugging Face 模型，首次运行会下载模型权重，请确保网络通畅。
• 如果显存吃紧，可优先尝试更小模型，或减少 –max-model-len。

通过 sglang 命令启动

如果您使用的版本提供 sglang serve 命令，也可使用如下命令进行启动：

sglang serve -m meta-llama/Llama-3.1-8B-Instruct --host 0.0.0.0 --port 30000

快速验证

服务启动后，OpenAI 兼容接口即可使用：

curl http://127.0.0.1:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer EMPTY" \
  -d '{
    "model": "meta-llama/Llama-3.1-8B-Instruct",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "用两句话介绍一下你自己。"}
    ],
    "max_tokens": 128,
    "temperature": 0.2
  }'

如果运行正常，将返回标准的 ChatCompletion JSON 响应。

使用 Python OpenAI SDK 进行调用

非流式调用（最简单的问答）：

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:30000/v1",
    api_key="EMPTY"  # 本地服务通常不校验
)

messages = [
    {"role": "system", "content": "You are a helpful assistant who answers in Chinese."},
    {"role": "user", "content": "请用三句话介绍帕累托最优。"}
]

resp = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=messages,
    temperature=0.2,
    max_tokens=256
)

print(resp.choices[0].message.content)

流式输出（边生成边打印）：

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:30000/v1", api_key="EMPTY")

messages = [
    {"role": "system", "content": "You are a helpful assistant that speaks Chinese."},
    {"role": "user", "content": "简述 Transformer 的核心思想，并给出一个现实类比。"}
]

stream = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=messages,
    temperature=0.2,
    max_tokens=300,
    stream=True
)

for chunk in stream:
    if chunk.choices and chunk.choices[0].delta:
        delta = chunk.choices[0].delta.content
        if delta:
            print(delta, end="", flush=True)

print("\n[Done]")

通过以上两种方式，我们可以构建自己的推理服务应用，也可以通过市面上开源的软件来接入您部署的推理服务，如 Open-WebUI 等。

常见问题与排错

• 启动时报显存不足（CUDA OOM）
  • 尝试更小的模型（如 7B/8B）、减小 --max-model-len、或降低并发。
  • 如果有多卡，增加 –tp 并用多卡分摊显存。
• 拉取模型失败或速度慢
  • 先执行 huggingface-cli login；或提前手动把模型权重下载到本地路径，并在 --model 里填本地路径。
• API 报 Unknown argument
  • 不同版本的命令行参数可能有差异。请运行：python -m sglang.launcher --help
  • 根据你安装的版本调整参数名，如 --model / --model-path、--tp / --tensor-parallel-size 等。
• Python 客户端 401/Key 错误
  • 本地服务通常不校验 Key，只要带上一个占位即可（如 EMPTY）。
• 流式输出不打印
  • 确认传了 stream=True；迭代 chunk 时取 choices[0].delta.content。
• 并发性能不达预期
  • 尝试用 Async 客户端并发请求；避免在单线程里串行等待。
  • 检查 GPU 利用率；确认没有 CPU/GPU 数据传输瓶颈。

总结

至此，你已经完成了：

• 安装与启动 SGLang 服务
• 用 OpenAI 兼容接口进行非流式与流式推理

祝你上手顺利，玩得开心！如果遇到命令行参数或 API 的小差异，参考本地版本的 –help 与官方文档进行快速适配即可。