大模型推理服务的负载均衡策略：从轮询到智能调度
大模型推理服务的负载均衡策略：从轮询到智能调度 大模型推理服务与传统Web服务有本质区别：请求处理时间长（秒级而非毫秒级）、资源消耗大（GPU而非CPU）、请求间差异大（短问答和长文本生成的处理时间可能差100倍）。这些特性使传统负载均衡策略表现不佳，需要设计专用的调度算法。 传统负载均衡的局限 经典的负载均衡算法——轮询、最少连接、加权轮询——在LLM推理服务中面临挑战： 轮询调度：不考虑请求复杂度，一个简单查询和一个2000字长文生成被同等对待。结果是某些Worker被长请求阻塞，而空闲Worker在等待轮询到自己。 最少连接：看起来合理，但"连接数"不能反映真实负载。一个Worker可能只有1个连接但正在处理一个30秒的长请求，而另一个Worker有5个连接但都是短请求。按连接数调度反而会把新请求送到已经过载的Worker。 加权轮询：权重是静态配置的，无法适应请求模式的变化和Worker性能的动态波动。 请求感知调度 我们的核心创新是请求感知调度——根据请求的预期复杂度来路由。 请求复杂度预测 在请求进入调度器时，我们快速预测其处理成本： 输入长度：token数量直接影响prefill时间 输出长度预测：基于Prompt类型和历史数据预测生成长度 模型选择：不同模型的计算量不同 工具调用可能性：可能触发工具调用的请求需要更长处理时间 预测模型是一个轻量的梯度提升树，推理延迟<1ms，预测误差在可接受范围内（±20%）。这个精度足以做出合理的调度决策。 多级队列设计 我们设计了基于优先级的多级队列： P0（交互式）：用户正在等待的实时对话，延迟敏感 P1（半交互式）：Agent工具调用、短文档分析 P2（批处理）：长文档翻译、批量摘要等非实时任务 P3（后台）：模型预热、数据集预处理 调度策略是严格优先级 + 同级内最短预计处理优先（SJF）。SJF策略能最小化平均等待时间，但可能导致长任务饥饿。我们引入了aging机制——等待时间超过阈值后优先级自动提升。 模型路由：异构模型的智能调度 在硅基AGI平台中，我们部署了多个不同规模的模型。小模型（7B级）处理简单请求，大模型（70B+级）处理复杂任务。路由策略： 分类器路由 训练一个轻量分类器，根据请求的复杂度自动路由到合适的模型。分类器特征包括：Prompt长度、问题类型（事实问答vs复杂推理）、是否包含代码、历史对话轮次等。 准确率约85%，对于误分类的情况，小模型处理不了的请求会自动升级到大模型。 级联推理 更激进的策略是级联推理：先用小模型处理，如果置信度低于阈值，再升级到大模型。这种策略在平均情况下节省大量推理成本，但增加了系统复杂度和尾部延迟的不确定性。 实践中的经验：级联推理在事实问答类任务上效果最好（简单问题的置信度判断准确），在创意写作类任务上效果较差（“好"的标准不明确，置信度信号弱）。 GPU层面的优化 负载均衡和GPU层面的调度密切相关。几个关键实践： Continuous Batching 传统批处理需要等一个batch全部完成才能处理下一个，而Continuous Batching在每一步都可以有新请求加入和已完成请求离开。这极大提高了GPU利用率，从传统批处理的40%左右提升到80%+。 KV Cache管理 KV Cache是大模型推理中显存的主要消耗。我们实现了PagedAttention式的分页管理，将KV Cache按固定大小分页，允许不同请求的KV Cache共享物理内存页面。这使得显存利用率从30%提升到75%。 Prefix Caching 很多请求共享相同的系统Prompt前缀。我们将常用前缀的KV Cache缓存，新请求只需计算差异部分。对于系统Prompt很长的场景，这可以减少30-50%的prefill计算。 容错与降级 负载均衡层也是容错的第一道防线。我们的设计： 健康检查：每5秒检查Worker健康状态，连续3次失败标记为不可用 优雅降级：当所有大规模模型Worker不可用时，自动降级到小模型，保持服务可用性 熔断机制：当Worker错误率超过10%时触发熔断，请求路由到其他Worker 限流策略：基于令牌桶的限流，保护系统不被突发流量压垮 监控指标 负载均衡效果需要细粒度监控。关键指标： 指标 目标值 说明 P50延迟 <800ms 中位数响应时间 P95延迟 <3s 95%请求的响应时间 P99延迟 <8s 尾部延迟 GPU利用率 >70% 平均GPU计算利用率 请求丢弃率 <0.1% 因过载被拒的请求比例 Worker负载均衡度 >0.8 最小/最大负载比 负载均衡度是最需要关注的指标——如果10个Worker中9个利用率30%而1个是90%，说明调度出了问题。 ...
