Reliable LLM Inference at Scale

URL 源: https://www.databricks.com/blog/reliable-llm-inference-scale

发布时间: 2026-05-27T20:20:00+0000

Markdown 内容: 在 Databricks，我们构建了一个独特的推理平台，服务于各种前沿模型，包括开源模型如 Kimi 和 Qwen 以及专有模型如 OpenAI、Gemini 和 Claude。我们为世界上一些最大的代理应用程序提供推理服务，包括 Superhuman、Yipit Data、Fox Sports 等。目前，我们每月处理超过 120T 令牌。

大规模 LLM 服务的难点在于可靠性。随着代理成为我们工作和生活的接口，推理需求呈指数增长。我们看到的需求曲线非常尖锐，在工作时间内达到峰值。

图 1：我们最大的客户之一在 LLM 服务上的两天流量。在几小时内，我们看到流量出现剧烈波动。

大规模运行 LLM 推理的挑战

什么是可靠的推理平台？合同看起来很简单。可用性是指请求是否可以被处理。但在实践中，不同的用例对延迟的要求差异很大，这影响了可用性。最先进的代理无法承受 p95 时间到第一个令牌（TTFT）和每秒输出令牌（OPTS）下降。

在多租户的 LLM 服务系统中，同时实现可靠性和低延迟具有挑战性。

可靠性

前沿性能需要最新带有高带宽互连的 GPU 进行 KV 缓存传输。这些计算设置本质上比传统的 CPU 系统更不可靠，并且昂贵。由于需要全对全通信，单个节点的停机需要重新配置多个其他节点在分散的预填充/解码设置中。最高带宽网络需要单脊连接在单个物理机架中（例如 NVL72 系统）。这意味着单个数据中心机架中的特定系统故障可能导致广泛的故障范围。分布式系统中的标准技巧，如多 AZ 或利用备份实例类型，意味着让昂贵的备份 GPU 闲置，这是一个成本 prohibitive 的选项。过度配置是另一个经典技巧，但由于计算供应如此有限，这既昂贵又不实际。因此，系统必须在重负荷下保持运行。

在这些约束下，交付速度也必须保持高——我们的推理需求每年按数量级增长，而推动这种增长的同时交付创新功能具有挑战性。像图像、视频和安全分类这样的功能各自需要不同的预处理系统，所有这些系统都必须独立扩展。

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

延迟

在具有 _多样_ 负载模式的情况下控制延迟具有挑战性。这是因为 服务请求的成本高度可变且难以预先估计。即使在负载较重的情况下，健康服务器也会处理所有请求的速度更慢，暴露了吞吐量（从而提高成本效率）和产品需要处理的最快延迟之间的权衡。这也可能表现为可靠性问题，因为服务器可能会根据分配给它们的请求混合快速进入不健康状态。

图 2：基于大型客户客户支持代理工作负载的真实并发度与延迟基准测试。

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

整体架构

在深入探讨如何解决这些问题之前，让我们概述一下我们的服务基础设施。

在数据平面，

• 推理运行时（开源和专有内部引擎）部署在前沿 GPU 上
• 为了处理跨模型部署的流量，数据平面运行一个 路由器，我们称之为 Axon，它在相同模型的副本之间平衡负载，并且一个 自动缩放器 调整副本数量。

在控制平面，

• 请求在到达数据平面之前经过速率限制。
• 根据请求指标，容量管理 算法确定每个工作负载获得多少 GPU 容量，然后自动缩放器强制执行。

控制容量

我们需要能够 _大致_ 推理容量——我们有多少、我们卖了多少以及客户使用了多少。为此，我们引入了一个称为“模型单位”的抽象。如果我们预测一个副本每分钟可以处理固定数量的模型单位（例如 100），我们可以做出以下假设：

• 输入或输出较长的请求消耗更多的模型单位，因为相同的时间窗口内可以完成的请求数较少。
• 预填充和解码具有不同的吞吐量特性，因此输出较长的请求比输入较长的请求成本更高。

图 3：请求的成本以非线性和复杂多维方式变化，取决于输入和输出令牌分布。这与经典 AI 系统形成鲜明对比，在经典 AI 系统中，每个请求的延迟大致均匀分布。

因此，我们使用多维函数来建模请求成本，例如：

系数 α、β、γ 通过自动化基准测试为每种模型和硬件类型确定。模型单元可以进一步调整以优化前缀缓存等功能，并且必须考虑到多模态等特性。

这样的估算在结构上是不完美的，但它们为我们提供了一种方法，将多租户系统分解成更易于管理的类似云虚拟机的东西。虚拟机具有可预测性能的优点，可以分配给特定客户。对于生产代理工作负载，确保低延迟和容量是非常重要的，如果没有这样的分配系统，我们所能做的最好的就是提供“尽力而为”的容量，如果太多客户使用该系统，可能会被回收。

基于成本的负载均衡和自动扩展

由于请求对服务器的影响高度可变，因此重要的是要做出几乎最优的路由决策。通常，负载均衡依赖于统计方法，如 P2C（二的幂次选择），它根据队列大小估计负载，并利用采样来减少理解所有可能目标的内存和延迟开销。然而，LLM 的延迟较高，服务器数量少于扩展的 CPU 系统，并且错误路由的成本严重。因此，LLM 服务需要不同的方法。

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

我们还可以调整负载指标，并在未来根据更高精度的成本指标使用更优化的路由系统，随着我们学习的深入。

图 4：路由器和自动扩展器都消耗服务器负载，因此少量昂贵的长上下文请求可能会触发与许多便宜的短请求不同的路由和扩展决策。

自动扩展中也存在类似的问题。仅等待请求计数并不能反映真正的负载。长上下文请求的峰值看起来与短请求的峰值相同，CPU 和内存指标也与实际的 GPU 利用率无关。

使用模型单元，我们的自动扩展器可以根据 模型单元利用率比例 决定是向上还是向下扩展。当推理引擎运行接近其最大模型单位的某个百分比（由硬件类型和工作负载形状决定）时，它接近峰值吞吐量，这会触发扩展。相反，这会触发缩减。这种方法允许我们使用模型无关的扩展基础设施，而不是手动调整每个模型的自动扩展规则。

在 LLM 推理模式的基础上构建自动扩展，使我们避免总是扩展到最大副本。对于突发流量的模型，自动扩展保持副本数量接近实际需求，与静态配置相比，在峰值时节省了 超过 80% 的 GPU 资源。

运行时可靠性

智能路由和扩展提供了一个很好的基础，但它不能防止引擎级别的故障。无论我们部署哪种推理引擎（我们自己的引擎或流行的开源选项），在生产规模下边缘情况和资源争用都会出现。我们需要机制来自动检测和恢复故障。

检测和恢复静默故障

我们遇到的一种故障模式是 静默挂起。涉及边缘情况（结构化输出、多模态输入）的请求可以在推理引擎的多进程架构中触发未处理的错误，导致服务器停止响应而不显示错误。

我们通过定期的黑盒健康检查来检测这种情况：在最近没有完成任何真实请求时发送最小的端到端请求。如果健康检查失败，Kubernetes 存活性探测会重启服务器。这适用于所有引擎，无论内部实现如何。

然而，在高负载下，健康检查本身可能会超时，导致存活探测杀死实际上健康的服务器，这可能导致级联故障。为了解决这个问题，我们将 健康检查请求分配最高的调度优先级，确保即使在高负载下也能完成。通过优先级健康检查，检测挂起、杀死不健康的服务器和恢复的整个周期少于 5 分钟。虚假存活探测失败从 每周几个降到零。

处理来自多模态请求的意外负载

当大量多模态请求到达时，我们看到了来自完全不同来源的错误率和超时峰值。

调查发现，请求甚至没有到达推理引擎的核心进程。服务图像请求比纯文本请求更耗资源，不仅因为运行在 GPU 上的附加视觉编码器，还因为 CPU 密集型图像处理。对于某些模型，图像处理非常缓慢，完全阻塞了事件循环。

将阻塞操作移到单独的线程和进程中并没有解决问题；在高图像负载下，请求仍然堆积。因此，我们分析了 Python 进程并发现了几个发现：

• 在所有图像处理的 CPU 操作中，图像处理（调整大小和归一化）比其他操作（如 base64 解码）慢 10 倍。
• 有些 Hugging Face 模型默认使用基于 PIL 的图像处理器，而其他模型则使用更快的 基于 Torchvision 的处理器。
• 在容器化环境中，OMP_NUM_THREADS（控制 Torch 进行 CPU 操作时使用的 OpenMP 线程数）默认为主机机器上的 vCPU 数量。在多租户设置中，这个默认值很糟糕：主机可能有 192 个 vCPU，但容器只能访问 12 个。结果是运行的线程数远多于可用的核心数。这导致 CPU 使用率超过容器的限制并触发了节流。

通过切换到基于 Torchvision 的图像处理器并正确配置 OMP_NUM_THREADS，我们维持了更高的 QPS 并充分利用了 GPU。修复上线后，每秒完成的请求数在相同的副本和负载下提高了 >3 倍。CPU 节流消失，服务器运行在一个更健康的状态。

图 5：优化图像处理瓶颈后的每秒请求数

结论

在大规模可靠地提供 LLM 需要在推理堆栈的每一层进行工作。我们已经介绍了围绕 LLM 工作负载设计的自动扩展和负载均衡基础设施，以及无论引擎或工作负载如何都能保持稳定的运行机制。还有很多其他内容：快速的容器启动、在 GPU 集群中的安全滚动发布、跨云和区域的 GPU 容量管理。如果你想要解决这些问题，我们正在招聘!