高并发与负载均衡

高并发 LLM 服务 = 在有限 GPU 算力下支撑目标 QPS,同时满足延迟预算(TTFT、TBT/TPOT、端到端延迟的 P50/P95)的容量规划与流量治理工程。核心机制: ① 容量估算与延迟预算: 单卡 decode 吞吐有限(约 1-2K tokens/s,受 HBM 带宽约束),由「单卡峰值吞吐 × 平均输出长度 × 延迟预算」反推单副本最大并发;例: 单卡 2000 tokens/s、平均输出 500 token、TBT 预算 20ms(50 token/s/请求)→ 单请求占 50 token/s,单卡并发上限约 $2000/50 = 40$ 并发,再乘副本数得集群容量;超出即违反延迟预算(排队时间随利用率非线性上升)。② 限流 (rate limiting): 令牌桶算法 —— 桶容量 $C$ = 允许的最大突发(即一个瞬间能放行的请求数),补充速率 $r$ = 长期平均 QPS 上限;每个请求消耗一个令牌,桶空则拒绝/排队。③ 排队与背压 (backpressure): 每个实例维护有界请求队列,队列满时拒绝(503)或让客户端退避重试;背压信号从下游(慢的副本)传到上游(网关/客户端),使其降速,防止「重试风暴 → 队列全满 → 雪崩」;超时熔断避免无限等待。④ 多副本路由: 网关按 least-connections / 最小排队长度路由(比 round-robin 更抗慢副本),需要前缀缓存亲和时用一致性哈希(同一会话/前缀固定打到同副本,提高 prompt cache 命中率);副本级健康检查摘除故障节点。⑤ 优雅降级: 优先级队列(付费用户/高优任务插队)、请求超时截断输出、降级到小模型、拒绝低价值流量 —— 保证 P95 预算不因尖峰被击穿。

生产 LLM API 网关与容量管理;面试高频“给 QPS 与延迟预算做容量规划”“令牌桶参数怎么设”“队列满怎么办”“多副本怎么路由”。

LLM 推理是非线性资源(显存 + 算力 + KV 缓存)且吞吐受带宽约束,不加治理时峰值流量会让队列无界增长、P95 飙升、雪崩重启。限流/排队/背压把流量整形到容量之内,多副本路由加前缀亲和提升缓存命中与利用率,优雅降级保证核心用户在过载时仍守延迟预算 —— 数值上排队论 (M/M/c 近似) 显示利用率超 80% 后等待时间呈指数恶化,容量规划目标通常设在 60-70% 峰值利用率并保留缓冲。

容量规划手算: 单卡 2000 tokens/s、平均输出 500 token、TBT 预算 20ms,算出单副本最大并发($2000/50 = 40$)与给定目标 QPS 所需副本数;解释为什么利用率超过 ~80% 后延迟恶化。

令牌桶限流: 桶容量 $C$(突发)与补充速率 $r$(平均 QPS)如何设定;突发请求与平滑流量的处理差异;超过时拒绝还是排队,依据是什么。

排队与背压: 队列为什么必须有界;队列满时的选择(503 拒绝、退避重试、降级);背压如何防止重试风暴与雪崩,超时熔断的作用。

多副本路由策略: round-robin vs least-connections vs 一致性哈希;为什么前缀缓存亲和需要一致性哈希(会话固定副本),副本故障时如何摘除。

延迟预算体系与优雅降级: TTFT/TBT/P95 如何分解预算;优先级队列、输出截断、降级到小模型等过载策略分别牺牲什么保住什么。