真实面经题目 · 原创解析

LLM 推理服务如何做流量调度，兼顾模型副本、队列长度、KV 资源和延迟 SLO？

这题考 LLM 推理服务的请求路由和服务治理。回答要围绕模型副本选择、prefill/decode 队列、KV cache 资源、batching、优先级、SLO 和故障降级展开，避免泛泛而谈负载均衡。

出现于：阿里巴巴 · C/C++
大语言模型 大模型推理 负载均衡 性能排查 服务治理
01

60 秒回答模板

我会把 LLM 推理流量调度分成入口路由、实例内调度和反馈控制三层。入口路由先按模型、版本、租户、区域和能力标签把请求路由到可服务的副本池，再根据健康状态、队列长度、预估 token 数、当前 KV cache/显存余量、GPU 利用率和历史延迟选择具体实例。实例内调度要区分 prefill 和 decode：prefill 计算重、适合形成 batch；decode 持续占用 KV cache 和调度槽，影响后续 token 延迟。调度策略要兼顾吞吐和 SLO，可以使用 continuous batching、优先级队列、最大等待时间、长短请求隔离、限流、超时和抢占/中断策略。反馈控制层根据 TTFT、TPOT、P95/P99、queue time、OOM、失败率和副本负载动态调整权重、扩缩容、熔断和降级。回答时要强调不能只按请求数轮询，因为 LLM 请求的输入长度、输出长度、KV 资源和生成时间差异很大。

考点 能力匹配
难度 真实面经题
回答目标 讲清推理流量调度和 SLO 保护
02

深入解析

01

先做能力匹配路由

入口层不能直接轮询所有 GPU。请求先要按模型名、版本、精度、上下文长度、租户、区域、灰度策略和硬件能力匹配到可服务的副本池。不同模型或不同上下文窗口消耗的显存、KV cache 和计算能力不同，路由必须先保证能跑。

02

负载不能只看请求数

LLM 请求的成本差异很大，短 prompt 短输出和长 prompt 长输出不是同一种负载。调度时要看排队长度、已排 token、预估输入输出 token、GPU 利用率、KV cache 占用、显存碎片、当前 batch 状态和实例最近的 TTFT/TPOT，而不是简单 least-connections。

03

Prefill 和 Decode 要分开理解

Prefill 主要处理输入上下文，计算密集且适合批处理；decode 是逐 token 生成，会持续占用 KV cache 和调度槽。一个实例如果已经有很多长输出 decode 请求，即使当前 GPU 利用率不高，也可能无法满足新请求的延迟 SLO。

04

实例内调度兼顾吞吐和延迟

Continuous batching 可以把不同请求的生成步骤动态合批，提高吞吐；但过度等待 batch 会拉高 TTFT。工程上通常要设置最大排队时间、batch token 上限、优先级队列、长短请求隔离、上下文长度限制和取消/超时处理，在吞吐和尾延迟之间取平衡。

05

SLO 驱动反馈控制

调度系统要持续观测 queue time、TTFT、TPOT、P95/P99、GPU/显存/KV cache、OOM、超时和错误率。当某个副本池接近 SLO 失守时，可以调低权重、限流、扩容、转移流量、拒绝超长请求或降级到较小模型。反馈控制比静态负载均衡更适合推理服务。

06

异常和多租户要有治理

生产环境还要处理热点租户、突发流量、模型冷启动、实例故障、部分 GPU OOM、网络抖动和版本灰度。常见手段包括配额、优先级、熔断、重试预算、幂等取消、请求 admission control 和隔离队列，避免少量长请求拖垮整池延迟。

03

易错点

  • 把流量调度答成普通 Web 服务负载均衡，只讲轮询、随机和 least connections。
  • 只看 GPU 利用率，不看队列 token、KV cache、显存和 decode 中请求数量。
  • 没有区分 prefill 和 decode，无法解释 TTFT 与持续生成延迟的不同来源。
  • 只追求吞吐最大化，忽略最大等待时间、优先级和 P95/P99 SLO。
  • 没有 admission control，超长上下文或突发流量会把副本池打到 OOM。
  • 不设计反馈闭环，调度权重、限流、扩容和降级都停留在静态规则。
04

面试官追问

为什么传统轮询负载均衡不适合 LLM 推理？

因为不同请求的输入长度、输出长度、KV cache 占用和生成时间差异很大。轮询只均分请求数，可能把多个超长请求打到同一实例，造成尾延迟和 OOM。

TTFT 和 TPOT 在调度里分别有什么用？

TTFT 反映排队和 prefill 体验，TPOT 反映生成阶段每个 token 的速度。调度既要控制首 token 等待，也要避免 decode 阶段长期拥塞。

KV cache 为什么会影响流量调度？

每个生成中的请求都会占用 KV cache，长上下文和长输出会持续占显存。即使 GPU 算力还有余量，KV 资源不足也可能导致新请求无法进入或触发 OOM。

长短请求应该混排还是隔离？

要看目标。混排可以提高资源利用率，但超长请求可能拖慢短请求尾延迟。常见做法是按长度、优先级或租户做队列隔离，同时保留一定共享池提高利用率。