什么是分布式推理？

分布式推理通过将推理计算分散到多台互联机器上， 提升 AI 系统处理生产负载的能力。系统不会把所有请求都压到单台服务器上， 而是协调多个 worker，使任何单个设备都不会成为瓶颈。

这种方式使推理系统能够在流量增长时平滑扩展，在个别组件故障时保持韧性， 并清晰呈现延迟、吞吐量和资源使用情况。

理解分布式推理

从不同视角看，分布式推理可以描述系统中的不同层次。

全局分布式推理架构

从宏观层面看，分布式推理指的是高层级的部署与拓扑决策：

• 在多个地理区域运行同一个模型或它的多个副本
• 在具有不同硬件配置的异构 GPU 集群上承载流量
• 在以下环境之间编排推理： 多个云（或 NeoCloud）提供商， 以及本地数据中心

在这一层面，团队会按地理位置分布推理，以降低延迟、满足数据驻留要求、 提升容错能力，或利用特定区域中更便宜、或更容易获取的 GPU 容量。

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

宏观层面的分布式推理主要关注推理在何处运行： 位置、GPU 资源来源以及大范围故障域。

推理并行与运行时优化

从微观层面看，分布式推理指的是一些底层优化技术， 它们会将单个推理请求或一批请求的工作拆分到多个 worker、节点或 GPU 上。

这些技术聚焦于将推理内部机制本身并行化， 并推动了近年来大规模 LLM 服务中大部分效率提升。

常见示例包括：

• Prefill–decode disaggregation. 将 prefill 和 decode 工作拆开，使每个阶段都能运行在专门的硬件上。
• KV cache offloading。将 KV cache 数据迁移到 CPU 内存或远程存储，以降低 GPU 内存压力和计算成本。
• Inference routing。将请求路由到 持有有用缓存或具备足够容量的 worker，以减少重复计算并提升吞吐量。
• Parallelism。 当大型模型无法装入单个设备时，将其拆分到多个 GPU 上。它可以采用多种形式， 例如单节点多 GPU 和多节点多 GPU。

微观层面的分布式推理主要关注推理如何高效运行， 而不取决于基础设施部署在何处。

为什么要运行分布式推理？

随着模型越来越大、流量越来越不可预测，分布式推理不再只是优化选项， 而逐渐成为实际必需。

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

扩展到单个 GPU 或单台机器之外

单个 GPU 在吞吐量、内存和并发方面都有硬性上限。分布式推理允许系统通过增加 更多 worker 来横向扩展，而不是把所有流量都强行塞进一个设备中。

这对以下场景尤为重要：

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

这样一来，容量不再受固定上限约束，而是会随着基础设施一起增长。

服务无法放入单个 GPU 的更大模型

即使进行了量化，许多现代 LLM 的内存需求依然会超过单个 GPU 的容量， 尤其是在将 KV cache 增长考虑进去之后。随着模型参数量增加， 推理所需的内存和计算资源也会随之增长。

分布式推理通过将这些模型拆分到多个 GPU 甚至多个节点上， 使其具备可服务性。这使团队能够运行更大的模型、支持更长的上下文， 并避免原本会让生产部署无法实现的 out-of-memory 故障。

提升可靠性与容错能力

生产级推理系统必须能够容忍故障。GPU 会崩溃，节点会离线， 整个区域也可能不可用。使用分布式推理后：

• 当某个 worker 故障时，流量可以自动重路由
• 区域级故障不会拖垮整个服务
• 容量可以在事故期间动态重新平衡

这使推理从一个脆弱的单点故障源， 转变为一个具备韧性的生产级服务。

通过更聪明的资源使用降低成本

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

常见的节省成本策略包括：

• 为不同推理工作负载混用不同类型的 GPU
• 在低峰时段缩减容量
• 将流量路由到成本更低的区域或供应商
• 将 KV cache 等内存密集型组件卸载出去

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

---

一般来说，以下情况下你需要分布式推理：

• 流量不可预测或波动明显
• 模型较大或内存密集
• 可用性和延迟很重要
• GPU 成本与利用率需要持续优化

到了这个阶段，仅仅纵向扩展单台服务器就不够了。 分布式推理会成为你的服务架构基础。

分布式推理的挑战

在从单节点部署迈向更复杂架构之前，理解以下权衡非常重要。

网络通信开销

分布式推理依赖 worker、GPU 与节点之间的频繁通信。 模型切分、prefill–decode disaggregation、KV cache 移动以及跨节点协调， 都会引入网络开销。

这可能导致：

• 由于 GPU 间或节点间通信而增加端到端延迟
• 对网络带宽和抖动更敏感
• 如果互连较慢或不稳定，则性能下降

随着推理变得更加分布式，网络往往会成为瓶颈， 而不是原始算力。

构建与运维复杂性

与单节点部署相比，分布式系统在构建和运维上天然更复杂。 团队必须管理许多相互联动的部分，包括编排、自动扩缩容、路由、 健康检查和可观测性。

常见挑战包括：

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

如果缺少强大的工具链和专业能力，运维复杂性很快就会抵消性能收益。

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

随着推理分散到多个 worker、GPU、集群和区域， 维护系统行为的统一视图会变得明显更加困难。

团队经常会在以下方面遇到困难：

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

如果缺少 集中式可观测性 和成本可见性，分布式推理系统就会变得不透明， 从而难以优化性能和排查问题。

状态管理与一致性

许多推理工作负载都是有状态的。聊天会话、agent 工作流、流式响应， 以及 KV cache 复用，都依赖于在请求之间保留状态。

在分布式环境中，这会引出一些问题，例如：

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

状态管理不佳会导致重复计算、缓存未命中或延迟恶化。

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

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

从高层看，一个生产级分布式推理系统需要以下组件。

智能调度与请求路由

分布式推理的核心是一个调度器，它决定每个请求应该在哪里运行。 这一决策取决于多个因素：

• GPU 可用性与内存压力
• 当前负载与队列深度
• 请求特征，例如 prompt 长度、batch size 和流式行为
• 已缓存的状态，例如 KV cache 大小和局部性
• 延迟或成本约束

简单的轮询调度器在规模上来后很快就会失效。 现代推理系统依赖动态的、具备状态感知能力的调度机制， 以维持吞吐量和可预测的延迟。

分布式推理运行时

大多数团队不会从零开始构建分布式推理。 相反，他们会依赖专门的运行时来实现并行化、 prefix-aware routing 等核心 推理技术。

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

编排、扩缩容与可观测性

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

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

这一编排层往往是大部分工程投入所在， 尤其是在跨多个集群或云环境运行时。

使用平台，而不是自行构建一切

对于许多团队来说，在内部构建并维护所有这些层， 最终会变成长期的运维负担。这时，生产级推理平台就能显著降低复杂性。

我们的 Inference Platform 为分布式推理提供了可用于生产的基础能力，集成了：

• 智能请求路由与调度
• 诸如 prefill-decode disaggregation 这样的高级推理优化技术
• 多 GPU、跨区域和多云部署
• 自动扩缩容、容错能力与统一可观测性

与其自行把所有部分拼接在一起，基于平台的方案能让团队专注于模型和应用， 而将分布式推理系统作为一个整体一致的层来管理。

联系我们