本文整理自 2025 年 12 月 14 日的「百度百舸 X SGLang Meetup 北京站」的同名主题分享。在公众号回复「SGLangV5」，可以获得此次 Meetup 上半场的 4 个演讲主题材料。

百度百舸新一代大规模分布式推理基础设施，以三大核心支柱破解大模型部署困局！通过自动化编排将分布式实例「原子化」，大幅简化跨节点管理复杂度；创新「静默实例」技术实现秒级资源激活，灵活应对潮汐流量；依托高性能流量调度与「班车调度」算法，极致压榨集群性能。这套架构不仅彻底解决传统部署的规模、弹性、效率痛点，更实现 TTFT 降低 30-40%、吞吐量提升 15-20% 的显著增益，为千亿级大模型落地提供坚实算力底座！

---

1. 引言：破解超大模型时代的不可能三角

随着大语言模型进入千亿乃至万亿参数规模的时代，其推理部署正面临一个严峻的不可能三角困境——在基础设施层面，我们必须在模型规模（Scale）、成本与弹性（Cost/Elasticity）以及效率与稳定性（Efficiency/Stability）这三个相互制约的目标之间寻求平衡。

传统的云原生架构在这一新范式下已触及其极限，暴露出三大核心挑战。

• 模型规模的极限：单机多卡已远不足以承载巨型模型，分布式推理成为必然。架构从张量并行（TP）演进到更复杂的专家并行（EP）与数据并行（DP）混合模式，对基础设施的管理能力提出了前所未有的要求。

• 弹性部署的失效：巨型模型的冷启动过程极为耗时，包括镜像拉取、权重加载、分布式组网和图编译等步骤，总时长长达近十分钟。这使得传统的水平 Pod 自动伸缩（HPA，Horizontal Pod Autoscaler）机制完全失效。同时，线上流量普遍存在显著的潮汐效应，若采用固定资源部署，将在流量低谷期造成巨大的算力浪费。

• 运维管理的复杂性：一个分布式推理任务可能涉及跨越多台物理机的数十个 Pod。如何将这些离散的单元作为一个逻辑上的原子单元进行统一的生命周期管理、故障恢复和灰度发布，是传统运维体系难以解决的难题。

为破解这一困境，百度百舸构建了新一代的 LLM 推理基础设施，其核心由三大支柱构成：自动化编排、智能弹性伸缩和高性能流量调度。这套体系旨在从根本上解决上述挑战，为超大模型提供稳定、高效且具备成本效益的运行环境。

2. 自动化编排 —— 将分布式推理实例原子化

在管理跨越多台物理机的大规模分布式推理任务时，自动化编排扮演着至关重要的战略角色。其核心目标是将一个由数十个 Pod 组成的、物理上分散的复杂集合，在逻辑上抽象为一个单一、内聚、可管理的原子单元。这不仅简化了运维的复杂度，更是实现可靠部署、快速恢复和敏捷变更的基石。

随着千亿、万亿参数模型的普及，单台 8 卡服务器已无法满足部署需求，这使得标准的 Kubernetes 负载（如 Deployment）在管理这种跨节点、强依赖的分布式应用时力不从心。标准的 Deployment 只能管理独立的 Pod 副本，无法理解一个完整的推理实例需要多个 Pod 协同工作的内在逻辑。

2.1 FedDeployment：为巨型模型量身打造的 K8s 原生负载

为了解决这一问题，百度百舸通过自定义资源（CRD）的方式，在 Kubernetes 之上打造了专为巨型模型设计的 FedDeployment 负载。其核心是引入了一个全新的逻辑抽象单元 —— Fed-Instance。

如图所示，Fed-Instance 是一个逻辑单元，它将一个完整分布式推理实例所需的所有 Pods（可能分布在物理节点 A、B、C 上）聚合为一个整体。基于这一核心抽象，FedDeployment 构建了一套分层控制器模型，其结构类似于原生的 Deployment -> ReplicaSet -> Pod，演进为 FedDeployment -> FedReplicaSet -> FedInstance。

这种分层设计带来了显著的管理优势：

• 统一的生命周期管理： FedDeployment 控制器作为用户的主要接口，负责管理整个应用的生命周期。运维人员只需操作 FedDeployment 资源，控制器便会自动协调下层的 FedReplicaSet 和 FedInstance，完成实例的创建、更新或删除，将复杂的分布式操作封装为原子化的单一指令。

• 副本保持与伸缩： FedReplicaSet 确保了指定数量的 Fed-Instance 副本始终处于健康运行状态。当需要扩缩容时，只需调整 FedReplicaSet 的副本数，系统就能自动地、原子化地增加或减少整个分布式实例，而无需手动管理每一个 Pod。

• 原生支持金丝雀发布：该分层模型天然支持高级发布策略。例如，可以通过创建两个不同版本的 FedReplicaSet（一个指向旧版本 v1，一个指向新版本 v2-canary），轻松实现流量的灰度切换和版本验证，极大地提升了部署的稳定性和可靠性。

通过 FedDeployment，我们成功地扩展了 Kubernetes API，为分布式工作负载提供了一种声明式的、应用感知的抽象，从根本上解决了巨型模型部署和运维的核心管理难题。

2.2 Gang Scheduling：保障多机协同的 All or Nothing

分布式推理系统有一个刚性约束：构成一个实例的所有 Pod 必须同时就绪，才能开始协同工作。任何一个 Pod 的调度延迟或启动失败，都会导致整个实例悬挂、不可用，并白白占用其他已就绪 Pod 的资源。因此，实现 All or Nothing 的成组调度（Gang Scheduling）是保障系统稳定性的关键。
百度百舸通过一种轻量级且可靠的机制，结合了 Init-Barrier Container 和共享 ConfigMap，实现了高效的 Gang 调度与服务发现。

其工作流程清晰地分为以下几个步骤：

• 状态同步与等待：每个 Pod 在主容器启动前，会先运行一个 Init-Barrier Container。所有属于同一个 Fed-Instance 的 Pod 会通过一个共享的 ConfigMap 来同步状态。只有当所有成员 Pod 都成功调度并更新了它们在 ConfigMap 中的状态后，屏障（Barrier）才会打开，允许所有 Pod 的主容器同时开始执行，确保了 All 的原子性。

• 服务发现信息收集： Pod 被成功调度后，会立即将自己的 IP 地址和在分布式环境中的唯一标识（RANK）等关键信息写入到共享的 ConfigMap 中。

• 组网信息注入：上层的 FedInstance Reconciler 持续监控这个 ConfigMap。一旦收集齐所有成员 Pod 的信息，Reconciler 就会将完整的成员列表编译成一个环境变量，并将其注入回该实例的所有 Pods 中。这样，当主容器启动时，它就能通过环境变量轻松发现所有其他成员，完成后续的 NCCL 通信组网，实现了可靠的自动服务发现。

这套机制巧妙地利用了 Kubernetes 的原生组件，以一种声明式的方式解决了分布式应用协同启动的核心痛点，确保了资源不会因部分 Pod 失败而被无效占用。

2.3 SplitService：P/D 分离架构的统一编排视图

现代高性能 LLM 推理普遍采用 Prefill（P）和Decode（D）阶段分离的架构。Prefill 阶段负责处理用户提示词，其特性是计算密集型（compute-intensive）；而 Decode 阶段负责逐个生成 token，其特性是对延迟高度敏感且受内存带宽限制（latency-sensitive and memory-bandwidth-bound）。这种架构虽能提升性能，但也带来了新的编排挑战：Prefill 实例组和 Decode 实例组是两个独立的、但又需要紧密协作的分布式集群。如何对它们进行统一管理，涉及协同变更、位置感知、负载感知等一系列复杂问题。

为应对这一挑战，百度百舸设计了 SplitService，它为 P/D 分离架构提供了一个单一的服务视图（Single Service View），从而实现了对两个角色的统一编排。

SplitService 将底层的 Prefill-ReplicaSet 和 Decode-ReplicaSet 聚合在一个统一的抽象层之下，对外暴露为一个逻辑上的整体服务。这种设计带来了四大核心优势：

1. 按比例协同伸缩与变更： SplitService 允许用户根据业务需求，按预设的 P/D 比例进行整体的伸缩或版本更新。例如，当需要扩容时，SplitService 会协同地、按比例地创建新的 Prefill FedInstance 和 Decode FedInstance，确保两者配比始终最优。

2. 通过网络亲和性优化 KV Cache 传输： Prefill 和 Decode 阶段之间需要高效传输大量的 KV Cache。SplitService 在调度时能够感知 P/D 实例的部署位置，通过网络亲和性策略，尽可能将相互通信的 P、D 实例放置在同一物理机或同一机架内，大幅降低跨节点传输 KV Cache 带来的网络延迟。

3. 采用 Binpack 调度减少资源碎片： P 实例和 D 实例对资源的规格需求往往不同。SplitService 采用 Binpack（箱式打包）调度策略，智能地将不同规格的 P、D Pod 打包到物理节点上，最大限度地提高资源装箱率，减少因资源规格不匹配而产生的碎片。

4. 基于真实负载动态调整 P/D 配比： SplitService 能够感知 P、D 实例组的真实负载情况。当系统检测到 Prefill 阶段成为瓶颈时，可以动态地、在线地调整 P/D 实例的配比，增加更多 Prefill 资源，从而实现基于真实负载的自适应优化。

通过将分布式实例原子化，自动化编排从根本上解决了巨型模型部署和管理的难题。然而，仅仅能够稳定部署还不够，下一个挑战是如何让这个庞大的资源池具备极致的弹性，以应对动态变化的业务负载。

3 SplitService：P/D 分离架构的统一编排视图

在 LLM 推理服务中，业务流量往往呈现明显的潮汐效应，高峰和低谷的差距可能达到数倍甚至数十倍。如果始终保有满足峰值需求的资源，将导致惊人的成本浪费。因此，智能弹性伸缩能力，对于提升资源利用率和控制成本至关重要。本章将探讨百度百舸如何从传统的 HPA 演进到一套全时自适应的智能伸缩体系，将资源响应时间从分钟级压缩至秒级。

3.1 Adaptive HPA：基于预测与仿真的智能决策闭环

传统的 Kubernetes HPA 主要依赖 CPU、内存等单一的实时指标进行被动扩缩容，这种模式无法应对 LLM 推理场景的复杂性。模型的冷启动时间长，被动扩容远水解不了近渴；同时，仅凭单一指标也无法精确判断系统是否需要调整 Prefill 和 Decode 实例的配比。

为此，百度百舸研发了 Adaptive HPA，一个基于预测与仿真的智能决策闭环系统。

Adaptive HPA 的核心是一个由三大子系统构成的智能控制环路：

1. 多维输入与智能决策： 决策系统不再依赖单一指标，而是综合分析多元化的输入信息。这包括：基于 Prophet 等时间序列模型的流量预测，能够提前预判未来负载趋势；实时指标监控，如首 token 延迟（TTFT）、每秒输出 token 数（TPOT）等关键性能指标；运营计划，如市场活动预案；以及预设的 SLO 约束。

2. 规划与仿真： 接收到决策指令后，智能规划系统会利用一个高速仿真器进行推演。该仿真器内置了模型的性能基准数据，能够实时计算在不同 P/D 配比和不同实例数量下的系统性能表现。它利用动态规划算法来寻找考虑了未来预测流量的最优伸缩决策序列（路径），而不仅仅是响应当前时刻的状况，从而制定出安全、灰度的伸缩计划，避免因激进调整导致服务抖动。

3. 高效执行：最终，自适应 HPA 控制器（Adaptive HPA Controller）负责高效地执行伸缩决策。它不仅能进行传统的实例增删，更能指挥实例进入或退出休眠状态，实现资源的快速唤醒与回收，从而达成极致的响应速度。

3.2 静默实例：实现秒级资源激活的关键技术

线上业务的流量高峰往往在秒级内形成，而一个分布式推理实例的冷启动时间却长达约 9 分钟。这形成了一个尖锐的矛盾：按需拉起完全不可能，预先保有又造成巨大浪费。

为了打破这一僵局，百度百舸引入了一项关键技术——静默实例（Silent Instances）：实例的计算进程暂停，GPU 进入低功耗模式，最关键的是，通过 CPU Offload 技术，将占用大量空间的模型权重和 KV Cache 从昂贵的 HBM 中卸载到成本更低的服务器主内存（DRAM）中。此时，GPU 的 HBM 被完全释放，但实例的核心上下文依然保留。

静默实例的核心优势如下：

入场（激活）< 30秒： 当流量高峰来临时，只需将权重从 DRAM 快速加载回 HBM 即可激活实例。由于无需重新组网/组图，整个过程被压缩至 30 秒以内。

退场（休眠）< 10秒： 当流量回落时，将HBM中的数据卸载至 DRAM 的过程更快，可在 10 秒内完成，迅速释放宝贵的 GPU 资源。

通过静默实例技术，系统可以在流量低谷期保有大量处于低成本静默状态的实例。一旦流量激增，这些实例能在秒级响应并投入服务，完美解决了冷启动慢和资源浪费的核心矛盾。

智能伸缩体系通过预测和静默实例解决了资源效率和响应速度的问题。然而，即使资源充足，如何通过高效的流量调度来进一步压榨集群性能，是通往极致优化的最后一公里。

4. 高性能流量调度 —— 极致压榨集群性能

在由多种并行模式构成的复杂分布式推理集群中，流量调度策略直接决定了系统的延迟（TTFT）和吞吐量。一个优秀的调度器能够智能地引导请求流，消除并行计算中常见的瓶颈。本章将聚焦于百度百舸的 Staggered Batched Scheduler （SBS），它通过创新的调度算法，最大化 GPU 的有效利用率。

4.1 班车调度：消除引擎内排队的隐秘问题

传统的调度模式通常是先进先出（FCFS），即请求一到达，就立即分发给下一个可用的推理实例。这种看似公平的模式，在 LLM 推理场景下却会导致严重的引擎内排队（In-Engine Queuing）问题。

由于推理引擎内部也存在批处理（batching）机制，当所有空闲实例被迅速占满后，后续到达的请求虽然被调度器分发出去了，但实际上是在目标实例的引擎内部等待前一个请求处理完成。这导致请求的 TTFT 急剧恶化，因为它包含了不必要的排队等待时间。

为了根除这一问题，SBS采用了创新的班车调度（Staggered Batch Scheduling）机制。

班车调度是其直观的名称，其核心思想是变立即分发为按节奏的批量分发，工作流程分为两步：

• 批处理（Batching）：调度器不再是来一个请求就发送一个，而是在一个极短的时间窗口内将这期间到达的多个请求聚合成一个 batch。

• 交错调度（Staggering）：调度器会精准地预测哪个推理实例即将完成当前任务。然后，它会将整个 batch 的请求调度给这个即将空闲的实例，通过精确的时间控制，确保当 batch 到达时，引擎正好处理完上一批任务，可以立即开始处理新请求。

这种班车模式，通过在调度器层面进行短暂的聚合和智能的错峰分发，从根本上消除了请求在引擎内部的无效等待时间，实现了 TTFT 的显著降低。

4.2 DP 均衡：消除数据并行中的计算气泡

在数据并行（DP）架构下，一个推理请求会被广播到多个 DP 单元上并行处理。然而，不同请求的计算负载往往存在差异。如果采用简单的 FCFS 调度，很容易导致 DP 单元之间的负载不均。

如图所示，当 DP 单元接收到负载不均的请求时，部分单元会提前完成任务并进入空闲等待状态，直到所有单元都完成，才能开始下一轮。这些空闲等待的时间段，就像计算流中的气泡，严重降低了 GPU 的整体有效利用率。

为了消除这些并行气泡，SBS 利用了批处理调度带来的时间窗口，实现了 DP 间的负载均衡：

• 利用全局信息：在批处理（batching）时间窗口内，调度器能够拿到本次待调度的一组请求的全局信息。例如，调度器可以根据每个请求的提示词长度（prompt length）和请求的输出 token 数来预估其计算负载。

• 贪心算法实现均衡分配：掌握了全局信息后，调度器可以运行一个简单的贪心算法，将这批请求在各个 DP 单元之间进行最优化的组合分配，目标是让每个 DP 单元分配到的总计算负载尽可能地接近。

通过这种简单而高效的均衡策略，系统能够有效消除并行气泡，确保所有 GPU 核心都在最大程度上被利用，从而显著提升了整个集群的吞吐量。

自动化编排、智能伸缩与高性能调度，这三大支柱从不同层面协同工作，构成了一套有机的、完整的解决方案。下一章我们将总结它们如何共同重塑 LLM 的分布式并行推理基础设施。

5. 总结：重塑 LLM 分布式并行推理基础设施

百度百舸通过自动化编排、智能弹性伸缩与高性能流量调度这三大支柱，成功重塑了 LLM 分布式并行推理基础设施。这套体系并非三个独立技术的简单叠加，而是一个从底层抽象到顶层智能决策、层层递进、协同工作的完整架构。
其整体架构蓝图可以归纳为四个协同工作的层次：

• 工作负载抽象层（Foundation Layer）：这是整个系统的基石。通过 FedInstance 这一核心抽象，将物理上分散的多个 Pod 封装为逻辑上统一的原子化多机工作负载。

• 服务编排层（Orchestration Layer）：在原子化工作负载之上，SplitService 提供了更高层次的服务视图，统一编排 Prefill 和 Decode 两种角色的实例池，实现了协同变更、亲和性调度和动态配比调整。

• 性能与效率层（Performance & Efficiency Layer）：这一层聚焦于最大化算力价值。Staggered Batched Scheduler （SBS）通过班车调度和 DP 均衡等算法消除调度阻塞和计算气泡。同时，静默实例技术以秒级激活的能力，提供了极致的资源弹性和效率。

• 智能决策层（Intelligence Layer）：作为系统的大脑，以 Adaptive HPA 为核心的智能决策层通过流量预测、多维指标分析和高速仿真器，自动生成并执行最优的资源伸缩决策，实现了全时自动化运维。

这套精心设计的架构带来了显著的、可量化的业务价值，成功打造了一个稳定、高效、智能的 AI 算力底座。

其核心成果可总结为以下四点：

1. 稳定性与规模化：借助 FedInstance 和 SplitService，能够可靠地部署和管理超越单机规模的、架构复杂的巨型模型，为业务的规模化扩展提供了坚实保障。

2. 极致弹性与效率：革命性的静默实例技术，将集群扩容时间从传统的 10 分钟以上戏剧性地缩短至 30 秒以内，在从容应对流量洪峰的同时，大幅提升了昂贵算力资源的利用率。

3. 卓越性能：通过 SBS 智能调度，实现了首 Token 延迟（TTFT）降低 30-40% 和系统吞吐量提升 15-20% 的显著性能增益，直接提升了用户体验和服务的承载能力。

4. 全时自动化：以自适应 HPA 和高速仿真为核心，系统实现了从被动、手动的运维模式到主动预测、智能规划的跨越式升级，显著降低了运维成本。

综上所述，百度百舸构建的这套新一代推理基础设施，不仅系统性地解决了当前大模型部署在规模、成本、效率和性能方面的系列核心挑战，更为未来 AI 应用的持续爆发和创新，提供了一个坚实、敏捷且具备成本效益的算力底座。

欢迎了解百度百舸