在线服务中如何做 LLM 的负载均衡？为什么简单轮询不够？

参考答案

**为什么简单轮询（round-robin）不够**： - LLM 请求的成本差异巨大：一个短请求 vs 一个 128K 上下文的长请求，计算量差几个数量级。 - 轮询按请求数均分，但不均衡实际负载 → 有的实例被长请求打爆（KV Cache 满、抢占、延迟飙升），有的实例空闲。 - 还忽略了 prefix cache 命中：把本可命中缓存的请求路由到没有该缓存的实例，浪费。 **更好的负载均衡策略**： 1. **Token 感知 / 负载感知路由**：按实例当前的 KV Cache 使用率、排队 token 数、活跃序列数来分配，而非请求数。把新请求发给"最空"的实例。 2. **Prefix-aware 路由（缓存亲和）**：把共享相同前缀（如同一 system prompt、同一会话）的请求路由到已缓存其 KV 的实例，最大化 prefix cache 命中（SGLang、Mooncake 的思路）。 3. **长短请求分离**：按预估长度把长请求和短请求分流到不同池，避免长请求阻塞短请求。 4. **SLO 感知 + 准入控制**：结合 TTFT/TPOT 目标做准入、排队和降级。 **实践**：网关维护各实例的实时指标（cache usage、队列深度），用加权/最小负载策略，并对会话做粘性路由以复用缓存。