跳到主要内容

什么是分布式推理?

分布式推理(distributed inference)通过将推理计算分散到多台互联机器上,改善了 AI 系统处理生产工作负载的方式。系统不是把所有请求都压在一台服务器上,而是协调多个工作节点(worker),使任何单一设备都不会成为瓶颈。

这种方法使推理系统能够在流量增长时平稳扩展,在单个组件发生故障时保持韧性,并在延迟、吞吐量和资源使用方面提供清晰的可见性。

理解分布式推理​

根据视角的不同,分布式推理可以描述系统的不同层级。

全局分布式推理架构​

在宏观层面,分布式推理指的是高层次的部署与拓扑决策:

在这个层面,团队在地理上分布推理以减少延迟、满足数据驻留要求、提高容错能力,或利用特定区域更便宜或更易获得的 GPU 容量。

理想情况下,分布式推理系统会将所有这些计算资源视为一个逻辑服务层。传入流量根据延迟、当前负载、成本或 GPU 可用性等因素路由到最佳可用位置。这也意味着它能够在不影响用户体验的情况下实现多区域路由、无缝故障切换和弹性扩展。

宏观层面的分布式推理主要关注推理在哪里运行:位置、GPU 来源以及大规模故障域。

推理并行化与运行时优化​

在微观层面,分布式推理指的是将单个推理请求或一批请求的工作拆分到多个工作节点、节点或 GPU 上的底层优化技术。

这些技术专注于并行化推理内部机制本身,并推动了近期大规模 LLM 服务中大部分效率提升。

常见示例包括:

微观层面的分布式推理主要关注推理如何高效运行,与基础设施部署在哪里无关。

为什么应该运行分布式推理?​

随着模型变得越来越大、流量越来越难以预测,分布式推理从一种优化手段变成了一种实际需要。

以下是团队在生产系统中采用分布式推理的关键原因。

超越单块 GPU 或单台机器进行扩展​

单块 GPU 在吞吐量、内存和并发方面有硬性限制。分布式推理允许系统通过添加更多工作节点进行水平扩展,而不是迫使所有流量通过一个设备。

这对以下情况尤其重要:

  • 高并发的聊天或智能体(agent)工作负载
  • 高吞吐量的批量推理流水线
  • 具有长上下文窗口和大型 KV 缓存的模型

容量不会撞上固定上限,而是随着你的基础设施一起增长。

服务放不进单块 GPU 的更大模型​

许多现代 LLM 超过了单块 GPU 的内存容量,即使经过量化(quantization)也是如此,尤其是当考虑到 KV 缓存的增长时。随着模型参数量增加,推理的内存和计算需求也随之增加。

分布式推理通过将模型拆分到多块 GPU 甚至多个节点上,使服务这些模型成为可能。这让团队能够运行更大的模型、支持更长的上下文,并避免那些否则会使生产部署无法实现的内存不足(OOM)故障。

提高可靠性与容错能力​

生产推理系统必须容忍故障。GPU 会崩溃,节点会离线,整个区域也可能不可用。有了分布式推理:

  • 当工作节点发生故障时,流量可以自动重新路由
  • 区域级中断不会导致整个服务宕机
  • 容量可以在故障期间动态重新平衡

这使推理从脆弱的单点故障变成一个有韧性、生产级的服务。

通过更智能的资源利用降低成本​

分布式推理可以在不牺牲性能的情况下优化成本。团队不必过度配置一台强大的机器,而是可以更精确地分配资源。

常见的成本节约策略包括:

  • 针对不同推理工作负载混用不同类型的 GPU
  • 在非高峰时段缩减容量
  • 将流量路由到成本更低的区域或提供商
  • 卸载诸如 KV 缓存等内存密集的组件

结果是更高的 GPU 利用率和更低的每次请求成本。

总的来说,当出现以下情况时,你需要分布式推理:

  • 流量不可预测或呈突发性
  • 模型很大或内存密集
  • 正常运行时间和延迟很重要
  • GPU 成本和利用率需要主动优化

到那时,扩展单台服务器已不再足够。分布式推理将成为你服务架构的基础。

分布式推理的挑战​

在超越单节点部署之前,理解以下权衡非常重要。

网络通信开销​

分布式推理依赖工作节点、GPU 和节点之间的频繁通信。模型分片、预填充-解码分离、KV 缓存移动以及跨节点协调都会引入网络开销。

这可能导致:

  • 由于 GPU 间或节点间通信导致的端到端延迟增加
  • 对网络带宽和抖动敏感
  • 如果互连缓慢或不可靠,性能下降

随着推理越来越分布式,网络往往成为瓶颈,而不是原始计算力。

构建与运维复杂性​

分布式系统天生就比单节点设置更复杂,无论是构建还是运维。团队必须管理多个活动部件,包括编排、自动扩缩容、路由、健康检查和可观测性。

常见挑战包括:

  • 协调跨集群或区域的部署
  • 管理环境之间的配置漂移
  • 确保扩展事件期间行为一致

如果没有强大的工具和专业化知识,运维复杂性很快就会超过性能收益。

统一的可观测性与成本可见性​

随着推理分布到多个工作节点、GPU、集群和区域,维护系统行为的统一视图变得明显更加困难。

团队常常面临以下困境:

  • 关联跨分布式组件的延迟、吞吐量和错误
  • 在全局层面理解 GPU 利用率和内存压力
  • 将成本归因于特定模型、工作负载或租户
  • 检测诸如闲置 GPU 或流量不均等低效问题

如果没有集中式可观测性和成本可见性,分布式推理系统可能变得不透明。这使得优化性能和排查问题变得困难。

状态管理与一致性​

许多推理工作负载是有状态的。聊天会话、智能体工作流、流式响应和 KV 缓存复用都依赖于在请求之间保留状态。

在分布式环境中,这引发了如下问题:

  • 会话状态或 KV 缓存应该放在哪里
  • 状态如何在工作节点之间共享、复制或迁移
  • 当持有关键状态的工作节点发生故障时会发生什么

糟糕的状态管理可能导致重复计算、缓存未命中或延迟恶化。

设计并运行分布式推理系统​

构建分布式推理系统不仅仅是增加更多 GPU。它要求你协调计算、智能地调度工作、管理状态,并在异构资源池中高效地路由流量。

在高层面上,生产级分布式推理系统需要以下组件。

智能调度与请求路由​

分布式推理的核心是一个调度器,它决定每个请求应该在何处运行。这个决定取决于多个因素:

  • GPU 可用性和内存压力
  • 当前负载和队列深度
  • 请求特征,如提示词长度、批大小和流式行为
  • 缓存状态,如 KV 缓存大小和局部性
  • 延迟或成本约束

一个朴素的轮询(round-robin)调度器在规模扩大时会很快失效。现代推理系统依赖动态的、感知状态的调度来维持吞吐量和可预测的延迟。

分布式推理运行时​

大多数团队并不会从头构建分布式推理。相反,他们依赖实现了核心推理技术(如并行化和前缀感知路由)的专用运行时。

在实践中,团队通常在 Kubernetes 上运行 vLLM、SGLang 和 llm-d 等推理运行时。从某种程度上说,它们确实有助于处理微观层面的推理运行方式,但并没有完全解决 LLM 工作负载在宏观层面的关切,如多区域路由、自动扩缩容或运维可见性。

编排、扩展与可观测性​

要在生产环境中运行分布式推理,团队还必须集成:

  • 跨 GPU 池的自动扩缩容策略
  • 健康检查与故障恢复
  • 对延迟(如 TTFT 和 ITL)、吞吐量、GPU 利用率和错误的统一可观测性
  • 跨模型、区域和工作负载的成本归因

这个编排层通常是工程投入最多的地方,尤其是在跨多个集群或云运行时。

使用平台而非一切自己构建​

对许多团队来说,在内部构建和维护所有这些层会成为一个长期的运维负担。这时,生产推理平台可以显著降低复杂性。

我们的推理平台为分布式推理提供了生产级基础,集成了:

与其自己东拼西凑一切,基于平台的方法让团队能够专注于模型和应用,而分布式推理系统作为一个内聚的层被统一管理。