LLM推理服务中的乘法组合调度器设计与优化
1. LLM推理服务中的请求调度挑战
在大型语言模型（LLM）推理服务场景中，请求调度策略的质量直接影响系统吞吐量和延迟表现。当用户向部署了LLM的服务集群发送请求时，调度器需要决定将请求分配给哪个计算实例进行处理。这个看似简单的决策背后，隐藏着两个相互制约的优化目标：
KV$缓存感知（KV$-awareness）：现代LLM推理引擎（如vLLM）采用KV$缓存机制存储已计算的键值对。当新请求与实例缓存中的内容存在重叠时（例如相同系统提示词或对话历史），可直接复用缓存结果，显著减少预填充阶段的计算量。理想情况下，调度器应尽可能将请求路由到缓存命中率高的实例。
负载均衡（Load Balancing）：过度依赖KV$缓存可能导致热点问题——某些实例因缓存命中率高而持续接收新请求，其批处理大小（Batch Size, BS）不断增长，最终因GPU计算资源竞争导致延迟上升。良好的调度策略需要平衡各实例的负载。
传统解决方案主要采用两种思路：
- 线性组合法：将KV$命中率和负载指标（如批处理大小）加权求和，如
Score = λ·KV_hit + (1-λ)·Load。这种方法需要繁琐的超参数（λ）调优，且不同工作负载下最优参数差异显著。 - 仿真模拟法：使用VIDUR等模拟器预测请求在各实例的TTFT（Time To First Token），选择预估延迟最低的实例。虽然性能较好，但需要为每个模型架构和硬件配置开发专用模拟器，工程成本高昂。
实测数据显示，在Qwen3-30B模型的聊天机器人场景中，未经调优的模拟器会导致TPOT（Time Per Output Token）尾部延迟增加79.7%。而线性组合方法即使用最优超参数，其TTFT仍比仿真方案高15-20%。
2. 乘法组合调度器的设计原理
2.1 核心算法与数学直觉
我们提出了一种基于乘法运算的调度评分算法，其伪代码如下：
def schedule(req): # 计算各实例的新预填充令牌数（考虑KV$命中） p_tokens = [estimate_new_tokens(req, instance) for instance in instances] # 获取各实例当前批处理大小 batch_sizes = [get_batch_size(instance) for instance in instances] # 计算乘法评分并选择最小值的实例 scores = [p * b for p, b in zip(p_tokens, batch_sizes)] selected = instances[scores.index(min(scores))] forward_request(req, selected)为什么乘法有效？从数学角度看：
- 当某个实例的KV$命中率高时，其
p_tokens值较小（需要新计算的内容少） - 当实例负载较低时，其
batch_size值较小 - 乘法运算使这两个指标相互制约：即使某实例KV$命中率极高（p_tokens→0），如果其负载已经很重（batch_size很大），乘积仍可能大于其他实例
2.2 指标选择的工程考量
KV$感知指标：预填充新令牌数（P-token）
相比直接使用KV$命中率（1-KV_hit），P-token具有以下优势：
- 更准确的成本建模：直接反映实际需要计算的令牌数量
- 隐含负载感知：已排队预填充请求多的实例会自动获得更高p_tokens值
- 实测数据：在ChatBot工作负载中，使用P-token比KV$命中率降低P95 TTFT达42.8%
# P-token计算示例（考虑KV$命中） def estimate_new_tokens(req, instance): total_tokens = len(req.prompt) hit_tokens = instance.kv_cache.get_hit_length(req.prompt) return max(total_tokens - hit_tokens, 0) # 确保非负负载均衡指标：批处理大小（BS）
相比使用实例总令牌数，BS更能反映解码阶段的真实负载：
- 解码阶段特性：解码时间主要取决于批处理大小而非上下文长度
- 硬件友好：GPU的矩阵计算效率与批量大小强相关
- 数据佐证：图19显示BS与解码延迟的相关系数达0.91，优于总令牌数的0.76
3. 实现优化与生产环境适配
3.1 性能关键路径优化
在实际部署中，我们使用Rust重写了调度器核心路径，相比原Python实现：
- 调度延迟从15ms降至0.8ms
- 支持并行评估数百个实例
- 内存占用减少60%
关键优化点包括：
- 无锁缓存查询：为每个实例维护独立的KV$元数据缓存
- 批量评分计算：利用SIMD指令并行处理乘法运算
- 增量更新：BS变化时只重新计算受影响实例的评分
3.2 KV$热点检测与熔断
虽然乘法组合在大多数场景表现良好，但极端KV$偏斜（如某些实例持续命中高频前缀）仍可能导致负载不均。我们设计了两阶段检测器：
graph TD A[阶段1:统计检测] -->|x/̄x > \|M\|/\|̄M\|| B(触发预警) B --> C[阶段2:连续路由检测] C -->|连续2×\|M\|次选择| D(过滤热点实例)其中：
- x/̄x：热点请求占总请求比例
- |M|/|̄M|：有缓存实例占比 当同时满足两个条件时，临时将热点实例移出候选池
4. 实测性能与对比分析
4.1 实验配置
- 测试平台：16台A100 GPU服务器
- 工作负载：
- ChatBot：对话式交互（Qwen3-30B）
- API：短文本处理（Qwen2-7B）
- Coder：代码生成任务
- 对比方案：
- vLLM（仅负载均衡）
- ai-Dynamo（线性组合）
- llm-d（模拟器方案）
- BAILIAN生产调度器
4.2 延迟指标对比
| 方案 | TTFT均值 | TPOT P99 | KV$命中率 |
|---|---|---|---|
| 乘法组合 | 35ms | 68ms | 92% |
| llm-d | 38ms | 82ms | 91% |
| ai-Dynamo | 42ms | 100ms | 89% |
| vLLM | 83ms | 110ms | 62% |
关键发现：
- 在ChatBot场景实现92% TTFT降低（相比vLLM）
- TPOT尾部延迟比次优方案(llm-d)低13%
- 负载均衡度提升40%（实例间预填充时间差异从5.2s降至3.1s）
4.3 资源效率提升
图：不同QPS下的延迟-吞吐量曲线
当QPS达到系统上限时：
- 乘法组合的吞吐量比线性组合高35%
- 99分位延迟增长斜率更平缓
- 无超参数振荡现象（对比ai-Dynamo）
5. 工程实践建议
5.1 部署注意事项
监控指标：
- 各实例的P-token/BS乘积方差（反映均衡度）
- KV$命中率分布（检测偏斜）
- 调度器自身延迟（应<1ms）
参数调优：
- 热点检测窗口建议设为1分钟
- 对于超长上下文场景，可对P-token取对数平滑
容灾方案：
- 当检测器连续触发时，自动切换至轮询调度
- 设置BS上限防止单个实例过载
5.2 适用场景扩展
该方法经适配后可应用于：
- MoE模型：将专家选择概率纳入P-token计算
- 多租户场景：为不同SLO添加权重系数
- 边缘计算：结合网络延迟指标
在实际部署到阿里云BAILIAN系统后，客户端的平均响应延迟降低28%，同时GPU利用率提升19%。这主要得益于乘法组合避免了人工调参的不稳定性，其自适应的特性能够应对多样化的真实工作负载。