麻涌做网站手机终端网站

麻涌做网站,手机终端网站,asp网站介绍,巴中网站建设开发公司本文整理自 2025 年 12 月 14 日的「百度百舸 X SGLang Meetup 北京站」的同名主题分享。在公众号回复「SGLangV5」#xff0c;可以获得此次 Meetup 上半场的 4 个演讲主题材料。#x1f4dd;百度百舸新一代大规模分布式推理基础设施#xff0c;以三大核心支柱破解大模型部署…本文整理自 2025 年 12 月 14 日的「百度百舸 X SGLang Meetup 北京站」的同名主题分享。在公众号回复「SGLangV5」可以获得此次 Meetup 上半场的 4 个演讲主题材料。百度百舸新一代大规模分布式推理基础设施以三大核心支柱破解大模型部署困局通过自动化编排将分布式实例「原子化」大幅简化跨节点管理复杂度创新「静默实例」技术实现秒级资源激活灵活应对潮汐流量依托高性能流量调度与「班车调度」算法极致压榨集群性能。这套架构不仅彻底解决传统部署的规模、弹性、效率痛点更实现 TTFT 降低 30-40%、吞吐量提升 15-20% 的显著增益为千亿级大模型落地提供坚实算力底座1. 引言破解超大模型时代的不可能三角随着大语言模型进入千亿乃至万亿参数规模的时代其推理部署正面临一个严峻的不可能三角困境——在基础设施层面我们必须在模型规模Scale、成本与弹性Cost/Elasticity以及效率与稳定性Efficiency/Stability这三个相互制约的目标之间寻求平衡。传统的云原生架构在这一新范式下已触及其极限暴露出三大核心挑战。模型规模的极限单机多卡已远不足以承载巨型模型分布式推理成为必然。架构从张量并行TP演进到更复杂的专家并行EP与数据并行DP混合模式对基础设施的管理能力提出了前所未有的要求。弹性部署的失效巨型模型的冷启动过程极为耗时包括镜像拉取、权重加载、分布式组网和图编译等步骤总时长长达近十分钟。这使得传统的水平 Pod 自动伸缩HPAHorizontal 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 SplitServiceP/D 分离架构的统一编排视图现代高性能 LLM 推理普遍采用 PrefillP和DecodeD阶段分离的架构。Prefill 阶段负责处理用户提示词其特性是计算密集型compute-intensive而 Decode 阶段负责逐个生成 token其特性是对延迟高度敏感且受内存带宽限制latency-sensitive and memory-bandwidth-bound。这种架构虽能提升性能但也带来了新的编排挑战Prefill 实例组和 Decode 实例组是两个独立的、但又需要紧密协作的分布式集群。如何对它们进行统一管理涉及协同变更、位置感知、负载感知等一系列复杂问题。为应对这一挑战百度百舸设计了 SplitService它为 P/D 分离架构提供了一个单一的服务视图Single Service View从而实现了对两个角色的统一编排。SplitService 将底层的 Prefill-ReplicaSet 和 Decode-ReplicaSet 聚合在一个统一的抽象层之下对外暴露为一个逻辑上的整体服务。这种设计带来了四大核心优势按比例协同伸缩与变更 SplitService 允许用户根据业务需求按预设的 P/D 比例进行整体的伸缩或版本更新。例如当需要扩容时SplitService 会协同地、按比例地创建新的 Prefill FedInstance 和 Decode FedInstance确保两者配比始终最优。通过网络亲和性优化 KV Cache 传输 Prefill 和 Decode 阶段之间需要高效传输大量的 KV Cache。SplitService 在调度时能够感知 P/D 实例的部署位置通过网络亲和性策略尽可能将相互通信的 P、D 实例放置在同一物理机或同一机架内大幅降低跨节点传输 KV Cache 带来的网络延迟。采用 Binpack 调度减少资源碎片 P 实例和 D 实例对资源的规格需求往往不同。SplitService 采用 Binpack箱式打包调度策略智能地将不同规格的 P、D Pod 打包到物理节点上最大限度地提高资源装箱率减少因资源规格不匹配而产生的碎片。基于真实负载动态调整 P/D 配比 SplitService 能够感知 P、D 实例组的真实负载情况。当系统检测到 Prefill 阶段成为瓶颈时可以动态地、在线地调整 P/D 实例的配比增加更多 Prefill 资源从而实现基于真实负载的自适应优化。通过将分布式实例原子化自动化编排从根本上解决了巨型模型部署和管理的难题。然而仅仅能够稳定部署还不够下一个挑战是如何让这个庞大的资源池具备极致的弹性以应对动态变化的业务负载。3 SplitServiceP/D 分离架构的统一编排视图在 LLM 推理服务中业务流量往往呈现明显的潮汐效应高峰和低谷的差距可能达到数倍甚至数十倍。如果始终保有满足峰值需求的资源将导致惊人的成本浪费。因此智能弹性伸缩能力对于提升资源利用率和控制成本至关重要。本章将探讨百度百舸如何从传统的 HPA 演进到一套全时自适应的智能伸缩体系将资源响应时间从分钟级压缩至秒级。3.1 Adaptive HPA基于预测与仿真的智能决策闭环传统的 Kubernetes HPA 主要依赖 CPU、内存等单一的实时指标进行被动扩缩容这种模式无法应对 LLM 推理场景的复杂性。模型的冷启动时间长被动扩容远水解不了近渴同时仅凭单一指标也无法精确判断系统是否需要调整 Prefill 和 Decode 实例的配比。为此百度百舸研发了 Adaptive HPA一个基于预测与仿真的智能决策闭环系统。Adaptive HPA 的核心是一个由三大子系统构成的智能控制环路多维输入与智能决策 决策系统不再依赖单一指标而是综合分析多元化的输入信息。这包括基于 Prophet 等时间序列模型的流量预测能够提前预判未来负载趋势实时指标监控如首 token 延迟TTFT、每秒输出 token 数TPOT等关键性能指标运营计划如市场活动预案以及预设的 SLO 约束。规划与仿真 接收到决策指令后智能规划系统会利用一个高速仿真器进行推演。该仿真器内置了模型的性能基准数据能够实时计算在不同 P/D 配比和不同实例数量下的系统性能表现。它利用动态规划算法来寻找考虑了未来预测流量的最优伸缩决策序列路径而不仅仅是响应当前时刻的状况从而制定出安全、灰度的伸缩计划避免因激进调整导致服务抖动。高效执行最终自适应 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 算力底座。其核心成果可总结为以下四点稳定性与规模化借助 FedInstance 和 SplitService能够可靠地部署和管理超越单机规模的、架构复杂的巨型模型为业务的规模化扩展提供了坚实保障。极致弹性与效率革命性的静默实例技术将集群扩容时间从传统的 10 分钟以上戏剧性地缩短至 30 秒以内在从容应对流量洪峰的同时大幅提升了昂贵算力资源的利用率。卓越性能通过 SBS 智能调度实现了首 Token 延迟TTFT降低 30-40% 和系统吞吐量提升 15-20% 的显著性能增益直接提升了用户体验和服务的承载能力。全时自动化以自适应 HPA 和高速仿真为核心系统实现了从被动、手动的运维模式到主动预测、智能规划的跨越式升级显著降低了运维成本。综上所述百度百舸构建的这套新一代推理基础设施不仅系统性地解决了当前大模型部署在规模、成本、效率和性能方面的系列核心挑战更为未来 AI 应用的持续爆发和创新提供了一个坚实、敏捷且具备成本效益的算力底座。