1. LLM推理服务调度优化概述
大型语言模型(LLM)推理服务面临的核心挑战之一是如何高效调度用户请求。当多个用户同时向部署在GPU集群上的LLM服务发送请求时，调度系统需要决定将每个请求分配给哪个计算实例。这个决策直接影响两个关键性能指标：首令牌延迟(TTFT)和每令牌输出延迟(TPOT)。
TTFT衡量从发送请求到收到第一个输出令牌的时间，主要取决于预填充阶段的计算量。TPOT则反映后续每个令牌的生成速度，与解码阶段的批处理大小密切相关。优化这两个指标需要同时考虑KV$缓存命中率和计算负载均衡：
- KV$缓存：存储历史请求的注意力键值对，当新请求与缓存内容相似时可直接复用，避免重复计算。例如，聊天场景中用户追问"为什么？"时，系统可以复用之前对话的上下文。
- 负载均衡：确保各GPU实例的计算负载均衡分布，避免某些实例过载而其他实例闲置。例如，突发流量可能导致某些实例堆积大量解码请求。
传统调度方案如vLLM仅考虑负载均衡，而类似llm-d的模拟预测方法虽然能兼顾两者，但存在实现复杂、需针对不同硬件调优的问题。我们的乘法组合方法通过精心选择的指标乘积，以极简设计同时优化这两个维度。
2. 核心指标设计与原理分析
2.1 KV$感知指标：预填充令牌数(P-token)
P-token表示考虑KV$命中后，实例需要实际处理的新令牌数量。其计算方式为：
P-token = 请求的提示令牌数 - KV$命中令牌数例如，某请求包含100个提示令牌，目标实例的KV$缓存已包含其中60个，则P-token=40。选择P-token而非KV$命中率作为指标的原因在于：
- 负载感知更强：如图18实验所示，P-token能自动规避堆积大量预填充请求的实例，即使这些实例有较高的KV$命中率。这避免了传统方法可能导致的"热点集中"问题。
- 计算更高效：实时统计KV$命中率需要复杂的前缀匹配计算，而P-token只需简单的令牌计数。
实际部署时，我们为每个实例维护一个前缀树(Trie)来高效追踪KV$状态。当请求到达时，路由器会并行查询各实例的Trie，统计可复用的令牌数量。
2.2 负载均衡指标：批处理大小(BS)
BS表示目标实例当前正在处理的请求总数（包括预填充和解码阶段）。选择BS而非总令牌数的原因包括：
- 解码阶段主导：在持续服务场景中，解码请求通常占计算资源的70%以上。BS直接反映解码阶段的负载压力。
- 稳定性更好：如图19所示，不同令牌数的请求在相同BS下解码时间差异不大，而相同令牌数在不同BS下的延迟差异显著。
我们实际测量了Qwen-30B模型在A100 GPU上的表现：当BS从1增加到8时，每个令牌的解码时间从15ms线性增长到120ms，而令牌数量变化对单请求延迟影响不超过10%。
3. 乘法组合的调度算法
3.1 核心算法实现
算法伪代码如下（完整实现约200行Rust代码）：
fn schedule(req: Request) -> Instance { let instances = cluster.get_instances(); instances.par_iter() // 并行查询各实例 .map(|inst| { let p_token = req.prompt_len() - inst.kv_cache.hit_count(&req); let score = p_token * inst.batch_size(); (inst, score) }) .min_by_key(|(_, score)| *score) .unwrap().0 }关键优化点包括：
- 并行查询：使用Rayon库实现多线程并行，将16实例的查询延迟从15ms降至3ms
- 增量更新：BS采用原子计数器，避免每次调度时的全局同步
- 批处理：每10ms处理一批请求，减少路由器的IPC开销
3.2 乘法特性的优势分析
相比线性组合λ·KV + (1-λ)·LOAD，乘法KV×LOAD具有两大优势：
- 无超参数：如图17(a)所示，乘法自动保持两项指标的平衡。当P-token减半时，需要BS加倍才能保持相同得分，这与GPU的实际计算能力线性扩展特性一致。
- 非线性惩罚：对高负载实例的调度会呈现指数级抑制。例如当BS=8的实例比BS=2的实例需要高4倍KV$命中率才会被选中。
我们在Qwen-30B上的测试显示，乘法组合在ChatBot工作负载下比最佳调参的线性组合降低14%的P99延迟。
4. 异常处理与边界条件
4.1 KV$热点检测
虽然乘法组合在大多数情况下表现良好，但极端KV$倾斜场景仍可能导致负载不均。我们设计了两阶段检测器：
# 第一阶段：请求分类监控 for window in sliding_windows(60s): for prefix in top_k(kv_hit_rate, 5): # 监控TOP5热点 x = request_ratio(prefix) M = instances_with_prefix(prefix) if x/(1-x) > len(M)/(16-len(M)): # 公式(2) alert_stage1(prefix) # 第二阶段：连续路由检测 if consecutive_routes(prefix, M) > 2*len(M): activate_mitigation(prefix)在AgentTool工作负载中，该检测器成功识别出仅占0.3%请求但导致3%延迟波动的异常模式。
4.2 冷启动处理
新实例加入或缓存失效时，我们采用渐进式预热策略：
- 前5分钟：设置BS上限为平均值的一半
- 动态调整P-token权重：
score = (p_token+10)*BS - 后台预加载高频前缀（如系统提示词）
实测显示这可将冷启动对TTFT的影响从300ms降至50ms以内。
5. 性能评估与生产部署
5.1 实验环境配置
我们在16台A100-80G服务器上部署测试集群，工作负载包括：
- ChatBot：模拟200并发用户的对话场景
- Coder：代码补全请求，平均长度128令牌
- API：短请求突发流量模式
- AgentTool：复杂多跳推理任务
每种工作负载运行30分钟，逐渐增加QPS直到饱和点。
5.2 关键性能指标
| 指标 | vLLM | llm-d | 本方案 |
|---|---|---|---|
| TTFT均值(ms) | 352 | 89 | 48 |
| TTFT P99(ms) | 1250 | 320 | 285 |
| TPOT均值(ms) | 42 | 28 | 27 |
| TPOT P99(ms) | 215 | 165 | 142 |
| KV$命中率 | 0% | 68% | 72% |
特别在AgentTool负载下，我们的方案TPOT P99比llm-d降低30%，证明乘法组合对复杂工作负载的适应性更好。
5.3 生产实践经验
在BAILIAN平台部署时，我们总结了以下经验：
- 监控埋点：实时追踪
P-token×BS的分布，设置>95百分位的告警 - 动态调节：当整体负载>70%时，自动降低BS权重因子
- 混合部署：对TTFT敏感型(如ChatBot)和TPOT敏感型(如Batch处理)请求采用不同权重策略
目前系统日均处理超过2亿请求，相比原调度器节省23%的GPU资源。
6. 扩展讨论与优化方向
6.1 多目标权衡
实际部署中常需要平衡多个SLO：
- 严格延迟约束：对
P-token设置上限阈值 - 公平性保障：引入每用户令牌配额
- 成本控制：与spot实例协同调度
我们正在开发基于强化学习的动态权重调整模块，预计可进一步提升15%的综合效益。
6.2 硬件适配优化
不同GPU架构需要微调实现：
- H100：利用TMA加速KV$查询
- MI300X：优化原子操作吞吐
- TPU：适配SparseCore特性
这些优化可使跨平台性能差异从30%降至10%以内。
