概述
如果做得好，它可以减少延迟和成本；如果做得不好，就会导致超时和 GPU 空闲。
深入探讨
大规模为 LLM 提供服务意味着在许多 GPU 上运行许多副本，并且推理流量是突发性且不均匀的——提示的长度和难度差异很大。路由器位于前面，使用比经典循环更丰富的信号选择目的地。现代 LLM 感知路由器会考虑队列深度、KV 缓存占用情况以及副本是否已持有匹配的提示前缀（前缀缓存亲和性），以便后续请求到达其缓存所在的位置。一些路由器还选择使用哪种模型——将简单的查询发送到便宜的小模型，将困难的查询发送到大模型（模型路由）。然后，负载平衡均衡副本之间的压力，以避免热点、遵守速率限制并保持较低的尾部延迟，同时最大化总体吞吐量和 GPU 利用率。
现实世界的实施
聊天机器人平台将每个对话固定到保存其 KV 缓存的副本，因此后续回合会命中前缀缓存并更快地响应。
RouteLLM 风格的系统将简单的问题发送给小型廉价模型，并仅将困难的问题升级为前沿模型，从而在质量损失很小的情况下降低成本。
Kubernetes Gateway API Inference Extension 通过实时 GPU 队列深度和缓存状态进行路由，而不是跨 Pod 进行简单的循环。
LiteLLM 跨 OpenAI、Anthropic 和自托管模型代理流量，并在一个提供商限制时提供回退和速率限制感知平衡。
LLM 推理路由和负载平衡的未来
路由正在成为一流的、可学习的组件。 Kubernetes 的网关 API 推理扩展、vLLM 的生产堆栈和基于 LiteLLM/Envoy 的路由器等项目标准化了缓存感知和成本感知调度。预计会有更多基于语义和难度的模型路由（RouteLLM 风格）、SLA 驱动的优先级队列、多区域和现货实例感知以及随着模型、价格和流量变化实时平衡延迟、吞吐量和美元成本的强化学习策略。
付诸实践
为什么这很重要
- 成本与预算. 多年来，架构决策决定着性能和运营成本。
- 更清晰的判决. 技术教育帮助团队选择正确的堆栈，而不仅仅是最新的堆栈。
- 质量控制. 更好的工程选择可以减少生产中的可靠性事故。
留意
- 优化一项基准测试可以隐藏更广泛的系统弱点。
- 基础设施和维护成本常常被低估。
- 随着系统变得更加复杂，安全性和可观察性差距可能会扩大。
后续步骤
- 在实施之前定义延迟、质量和成本目标。
- 在实际负载和数据条件下进行基准测试。
- 仪器监控错误、漂移和用户影响。
- 在扩展之前准备回滚和事件响应路径。
不断探索
常见问题
什么是 LLM 推理路由和负载平衡？
控制层决定哪个模型副本、GPU 或后端应处理每个传入的 LLM 请求，以及如何分散流量，以免单个服务器不堪重负。如果做得好，它可以减少延迟和成本；如果做得不好，就会导致超时和 GPU 空闲。
为什么普通循环法对于 LLM 推理来说通常是一个糟糕的负载平衡策略？
LLM 请求在长度/成本方面差异很大，并且副本的 KV 缓存使会话具有粘性，因此盲目循环后端会忽略缓存关联性和实际负载。
“前缀缓存关联”路由试图实现什么目标？
如果副本已经保存了共享前缀的 KV 缓存，则后续路由将重用该缓存，而不是重新计算它，从而节省计算和延迟。
在基于难度的模型路由中，简单查询通常会发生什么？
像 RouteLLM 这样的模型路由器将简单的查询发送到便宜的小型模型，并为困难的模型保留昂贵的前沿模型，从而以最小的质量损失降低成本。
哪种实时信号对于支持 LLM 的负载均衡器最有用？
真实的后端遥测（待处理令牌、批次填充度、缓存占用率）比简单的请求计数更好地反映了真实负载。
像 LiteLLM 这样的工具在多提供商设置中提供什么？
LiteLLM 充当跨提供商（OpenAI、Anthropic、自托管）的路由代理，添加后备和速率限制感知平衡。