大规模可靠LLM推理

在Databricks，我们构建了一个独特的推理平台，服务于从Kimi、Qwen等开源模型到OpenAI、Gemini、Claude等专有模型的几乎所有前沿模型。我们为全球一些最大的智能体应用提供推理能力，包括Superhuman、Yipit Data、Fox Sports等。目前，我们每月处理超过120万亿个令牌。

大规模LLM推理的难点在于可靠性。随着智能体成为工作和生活的主要界面，推理需求呈指数级增长。我们观察到极其尖峰的需求曲线，在工作时间达到峰值。

扩展LLM推理的挑战 可靠的推理平台意味着什么？表面上，可用性是指请求能否被处理。但实际上，不同用例对延迟的要求差异很大，这影响了可用性。最先进的智能体无法容忍p95首次令牌时间（TTFT）和每秒输出令牌数（OPTS）的下降。在多租户LLM服务系统中，同时实现可靠性和延迟是一项挑战。

可靠性方面，前沿性能需要最新GPU和高带宽互联用于KV缓存传输。这些计算设置本质上不如传统CPU系统可靠，且成本高昂。由于需要全对全通信，单个节点的故障需要重新配置多个其他节点。最高带宽网络要求单个物理机架内的单脊连接（如NVL72系统）。这意味着单个数据中心机架内特定系统的故障可能导致大范围中断。分布式系统中的标准技巧（如多可用区或备用实例类型）意味着保持昂贵的备用GPU闲置，成本过高。过度配置是另一个经典技巧，但鉴于计算供应紧张，这极其昂贵且不切实际。因此，系统必须在重压下保持运行。

同时，在这些约束下，交付速度必须保持高水平——我们的推理需求每年增长多个数量级，在保持增长的同时还要推出创新功能。图像、视频和安全分类等特性需要不同的预处理系统，这些系统都必须独立扩展。

最后，实现最佳性能和支持新模型架构需要从自定义内核到专有推理引擎的各种优化。随着架构微妙变化，新的低级软件常常引入，这些软件可能在大规模下以不透明的方式失败，导致难以调试的场景，如服务器挂起或GPU崩溃。

延迟方面，在多样化负载模式下控制延迟是一项挑战。这是因为服务请求的成本高度可变且难以预先估计。即使是健康的服务器在更重负载下也会更慢地处理所有请求，从而在吞吐量（因此成本效率）和产品所需的最快延迟之间做出权衡。这也可能表现为可靠性问题，因为基于分配给服务器的请求组合，服务器可能迅速进入不健康状态。

此外，延迟主要受输出令牌生成支配，但预先估计成本很困难，因为很难预测模型会输出多少内容。因此，低延迟服务需要复杂的容量管理、负载均衡和请求优先级系统。

整体架构 在数据平面，推理运行时（开源和专有内部引擎）部署在前沿GPU上。为了处理跨模型部署的流量，数据平面运行一个名为Axon的路由器，它在同一模型的副本之间平衡负载，以及一个自动缩放器来调整副本数量。在控制平面，请求在到达数据平面之前经过速率限制。基于请求指标，容量管理算法确定每个工作负载获得多少GPU容量，然后由自动缩放器强制执行。

掌控容量 我们需要大致推理容量——我们有多少、卖了多少以及客户用了多少。为此，我们引入了一个称为“模型单元”的抽象。如果我们假设一个副本每分钟可以处理固定数量的模型单元（例如100个），我们可以做出以下假设：输入或输出较长的请求消耗更多模型单元，因为相同时间窗口内能完成的更少。预填充和解码具有不同的吞吐特性，因此输出长的请求比输入长的请求成本更高。

因此，我们使用多维函数对请求成本建模，如：成本 = α × 输入令牌数 + β × 输出令牌数 + γ × 其他因素。系数α、β、γ通过每个模型在每个硬件类型上的自动基准测试确定。模型单元可以进一步为前缀缓存等优化进行调整，并且必须考虑多模态等特性。这种估计在结构上并不完美，但它帮助我们打破多租户系统，使其更像可管理的云虚拟机。虚拟机具有可预测性能并分配给特定客户的可取属性。对于生产级智能体工作负载，提供低延迟和容量的保证很重要，没有这样的分配系统，我们只能提供“尽力而为”的容量，如果太多客户使用系统，这种容量可能被收回。

基于成本的负载均衡和自动缩放 由于请求对服务器的影响高度可变，做出近乎最优的路由决策至关重要。一般来说，负载均衡倾向于依赖统计方法，如P2C（两种选择的力量），它基于队列大小估计负载并利用采样来减少了解所有可能目标的内存和延迟开销。然而，LLM延迟较高，服务器数量少于横向扩展的CPU系统，并且错误路由的代价很高。因此，LLM服务需要不同的方法。

目前，我们使用Databricks的自动分片器Dicer在工作负载之间动态路由。没有负载感知的路由，长上下文请求会导致个别服务器成为热点，而其他服务器利用率不足。我们将模型单元与Dicer集成，使路由决策基于服务器负载（以模型单元为单位），而不是传统的基于请求的启发式。Dicer还提供有状态会话，使请求路由具有粘性。一个工作负载的请求只发往一部分服务器，这提高了缓存命中率（对延迟敏感的编码智能体至关重要）并限制了爆炸半径。

在自动缩放中也存在类似问题。待处理请求数量本身并不反映真实负载。长上下文请求的尖峰看起来与短请求的尖峰相同，CPU和内存指标也与实际GPU利用率不相关。使用模型单元，我们的自动缩放器可以根据模型单元利用率比率决定是否扩展或缩减。当推理引擎接近其最大模型单元的某个百分比（由硬件类型和工作负载形状决定）时，它接近峰值吞吐量，触发扩展。反之则触发缩减。这种方法无需为每个模型手动调整自动缩放规则，实现了模型无关的缩放基础设施。

基于LLM推理模式构建自动缩放使我们不必总是扩展到最大副本数。对于流量突发的模型，自动缩放将副本数保持在接近实际需求的水平，与静态配置峰值相比，节省了80%以上的GPU。

运行时可靠性 智能路由和缩放提供了良好的基础，但并不能防止引擎级别的故障。无论我们部署哪种推理引擎（内部引擎或流行的开源引擎），在生产规模下都会出现边缘情况和资源争用。我们需要机制来自动检测和恢复故障。

检测和恢复静默故障：我们遇到的一种故障模式是静默挂起。涉及边缘情况（结构化输出、多模态输入）的请求可能触发推理引擎多进程架构中的未处理错误，导致服务器停止响应而不显示错误。我们通过定期黑盒健康检查来检测：当最近没有实际请求完成时，发送最小的端到端请求。如果健康检查失败，Kubernetes存活探针会重启服务器。这适用于所有引擎，无论内部实现如何。然而，在高负载下，健康检查本身可能超时，导致存活探针杀死实际上健康的服务器，这有级联故障的风险。为了解决这个问题，我们赋予健康检查请求最高调度优先级，确保即使在重负载下也能完成。通过优先级健康检查，检测到挂起、杀死不健康服务器和恢复的完整周期不到5分钟。误报存活探针失败从每周几次降至零。

处理多模态请求带来的意外负载：当大批多模态请求到达时，我们看到错误率和超时激增，来源完全不同。调查显示，请求甚至没有到达推理引擎的核心进程。服务图像请求比纯文本请求消耗更多资源，不仅是因为额外的视觉编码器在GPU上运行，还因为CPU密集型的图像处理。对于某些模型，图像处理非常慢，完全阻塞了事件循环。将阻塞操作移入单独的线程和进程并没有解决问题；在高图像负载下，请求仍然堆积。因此，我们分析了Python进程并发现：在所有CPU图像操作中，图像处理（调整大小和归一化）比其他操作（如base64解码）慢10倍。一些Hugging Face模型默认使用基于PIL的图像处理器，而其他模型使用更快的Torchvision处理器。