超算级LLM部署实战：256节点3072副本的调度与运维

1. 当"256节点3072副本"摆在面前，先搞清楚它到底在解决什么问题

第一次看到"ExaServe"这个方案描述的时候，我脑子里冒出来的第一个念头不是"好厉害"，而是"这得烧多少钱"。256个计算节点、3072个模型副本，这个量级已经远远超出了普通企业做推理服务的范畴，它瞄准的是超算级别的LLM部署场景。但抛开数字带来的视觉冲击，我们得先弄明白一件事：为什么需要这么多副本？

大模型推理和传统Web服务的本质区别在于，它的瓶颈不在CPU、不在内存带宽，而在GPU显存和计算吞吐。一个70B参数的模型，即使用FP16精度加载，光权重就要吃掉140GB显存，这还没算KV Cache和中间激活值。单卡放不下就得切分，切分之后通信开销又上来了。而当你面对的是千亿参数级别的模型、要求毫秒级首Token延迟、还要同时服务成百上千的并发请求时，单节点方案根本撑不住。

副本机制在这里扮演的角色，跟数据库读写分离里的从库有点像，但又不完全一样。数据库从库主要是为了分担读压力，而LLM副本除了分担并发，还要解决几个更棘手的问题：一是故障隔离，一个副本崩了不能影响其他副本继续服务；二是灰度更新，新版本模型可以先在部分副本上验证效果；三是地理亲和性，不同区域的请求最好由就近的副本处理，减少网络往返。

3072这个数字也不是随便拍脑袋定的。256节点乘以每节点12个副本，刚好凑出这个数。为什么是12？这通常跟单节点的GPU数量有关——一台8卡或16卡的机器，通过张量并行加流水线并行把模型切开后，剩下的显存余量刚好能塞下若干个独立副本。具体能塞几个，取决于模型大小、序列长度、批处理策略和精度格式，后面我会展开算这笔账。

ExaServe这个方案最值得关注的地方，不在于它堆了多少硬件，而在于它怎么把这些硬件组织成一个可调度、可观测、可恢复的整体。这才是超算级部署和"堆机器"之间的分水岭。很多团队也能凑出几百张卡，但跑起来之后发现利用率不到30%，故障频发，扩缩容基本靠重启，那就谈不上方案，只能叫事故现场。

提示：如果你正在评估类似规模的部署方案，先别急着看它支持多少节点，先问三个问题——调度器是什么、故障恢复的粒度是什么、副本之间怎么做一致性保证。这三个问题的答案，基本决定了方案的上限。

2. 副本数量背后的显存账本：3072是怎么算出来的

2.1 单副本的显存占用拆解

要理解3072这个数字，得先学会算一笔账。假设我们部署的是一个70B参数的模型，采用INT8量化，权重占用约70GB。KV Cache这块，按序列长度4096、批大小8来算，每层每个Token的KV占用大约是2乘以隐藏维度乘以精度字节数。以Llama 2 70B为例，隐藏维度8192，80层，FP16精度下每个Token的KV Cache约2.6MB，4096个Token就是10.6GB，批大小8就是85GB左右。再加上中间激活值和框架本身的开销，单副本跑起来大概需要170GB到180GB显存。

一张H100 80GB的卡，放不下这个副本。两张卡做张量并行，160GB，还是紧张。三张卡240GB，勉强够用但余量不多。四张卡320GB，就比较从容了。所以单副本至少需要4张H100。一台8卡H100的节点，理论上能跑2个副本。256节点乘以2，是512副本，离3072差得远。

那3072是怎么来的？这里的关键变量是模型规模和精度。如果部署的是13B级别的小模型，INT4量化后权重只要7GB左右，KV Cache也小得多，单张H100能跑好几个副本。一台8卡节点跑12个副本完全可行，256乘以12就是3072。所以这个数字对应的很可能是一个中等规模模型的高密度部署场景，而不是单一大模型的部署。

2.2 副本密度与吞吐的权衡

副本密度不是越高越好。副本多了，单副本能分到的显存就少，能支持的序列长度和批大小就受限。序列长度直接决定了模型能处理多长的上下文，批大小决定了吞吐量。如果你把12个副本塞进一台8卡节点，每个副本平均只能分到0.67张卡，这显然不可能——副本必须独占GPU资源，不能跨副本共享。

所以更合理的解释是：每个副本占用一定数量的GPU，节点内通过NVLink或NVSwitch做高速互联，副本之间通过PCIe或网络通信。比如每副本占用2张GPU，一台8卡节点跑4个副本，256节点就是1024副本。要凑到3072，要么节点数更多，要么每副本占用的GPU更少。

我倾向于认为ExaServe的方案里，3072是一个逻辑副本数，而不是物理副本数。逻辑副本可以理解为服务实例，多个逻辑副本可能共享同一组GPU资源，通过时间片轮转或动态批处理来复用。这种设计在推理框架里很常见，比如Triton Inference Server就支持一个模型实例对应多个执行实例，底层共享GPU但上层表现为多个并发单元。

2.3 显存超分与副本调度的配合

还有一种可能是用了显存超分技术。就像操作系统可以用硬盘当虚拟内存一样，推理框架也可以把不常用的权重或KV Cache换出到主机内存甚至NVMe盘上。这样单卡能"看起来"跑更多副本，但代价是延迟会抖动。对于延迟不敏感的场景，比如离线批量推理，这种方案是可行的；但对于在线服务，换入换出的开销可能让P99延迟直接爆炸。

ExaServe如果真能做到3072副本稳定运行，那它的调度器一定做了很精细的显存管理。我猜测它可能采用了分层调度策略：热副本常驻显存，温副本部分换出，冷副本完全在主机内存里待命，收到请求再加载。这种策略在vLLM的PagedAttention和SGLang的RadixAttention里都有影子，但要做到256节点级别的全局调度，复杂度是指数级上升的。

这张表能帮你快速估算不同配置下的副本容量。实际数字会因框架开销、序列长度、批大小而浮动，但量级不会差太多。

3. 256节点组网：超算级部署的通信骨架怎么搭

3.1 节点内互联：NVLink和NVSwitch不是可选项

到了256节点这个规模，通信架构的设计比单机优化重要得多。节点内如果用的是PCIe 4.0，GPU之间的带宽只有32GB/s左右，做张量并行时通信会成为严重瓶颈。NVLink 4.0能提供900GB/s的双向带宽，NVSwitch则能让节点内所有GPU全互联，任意两张卡之间的通信延迟都在微秒级。

ExaServe的方案里，节点内大概率是全NVSwitch互联。这意味着8张H100之间可以任意组合做张量并行，不需要担心拓扑约束。有些方案为了省钱会用混合拓扑，比如4张卡一组NVLink，组间走PCIe，这种在跑大模型时会出现明显的负载不均——组内通信快，组间通信慢，导致快的卡等慢的卡，整体利用率下降。

3.2 节点间网络：InfiniBand还是RoCE

256个节点之间的通信，靠以太网是不够的。万兆以太网延迟在几十微秒，带宽也就10Gbps，做AllReduce的时候会成为灾难。InfiniBand NDR提供400Gbps的单口带宽和亚微秒级延迟，是目前超算级部署的主流选择。RoCEv2也能做到类似性能，但需要无损网络配置，对交换机的PFC和ECN调优要求很高，运维复杂度大。

ExaServe如果定位是"超算级"，那InfiniBand几乎是必然选择。但这里有个坑：InfiniBand的 subnet manager 配置不当会导致路由震荡，表现就是训练或推理任务间歇性卡顿。我见过一个案例，256节点的集群因为一个交换机端口的MTU配置不一致，导致整个AllReduce超时，任务跑了三天才定位到问题。

3.3 副本间通信：AllReduce、AllGather和点对点

副本之间的通信模式取决于并行策略。如果是纯数据并行，每个副本持有完整模型，副本间只需要做梯度AllReduce（训练时）或结果聚合（推理时）。如果是张量并行加流水线并行，副本内部就有大量AllReduce和点对点通信。

3072个副本如果全部做AllReduce，通信量是惊人的。假设每个副本每步要同步1GB的数据，3072个副本就是3TB的通信量。InfiniBand NDR的单口400Gbps，也就是50GB/s，跑完一轮要60秒。这显然不可接受。所以ExaServe大概率采用了分层通信策略：节点内先做NVLink AllReduce，节点间再做InfiniBand AllReduce，最后跨机架做全局同步。这样通信量能压缩一个数量级。

注意：分层通信的代价是编程复杂度上升。你需要自己实现通信域的划分和归约树的构建，不能直接用NCCL的默认配置。NCCL虽然支持多级拓扑，但默认参数在256节点规模下往往不是最优的。

4. 调度器设计：3072个副本怎么管才不乱

4.1 副本生命周期管理

3072个副本，每个都有自己的生命周期：创建、加载模型、预热、就绪、服务、降级、销毁。如果没有一个强力的调度器，光是副本的创建和销毁就能把运维拖垮。ExaServe的方案里，调度器需要做到几件事：

第一，副本亲和性调度。同一个模型的副本尽量分散在不同节点、不同机架上，避免单点故障导致某个模型整体不可用。第二，资源碎片整理。副本销毁后释放的GPU显存可能不连续，调度器要能识别并合并这些碎片，否则新副本可能因为显存碎片而无法创建。第三，滚动更新。新版本模型上线时，不能一次性替换所有副本，要按批次逐步替换，每批替换后观察一段时间再继续。

4.2 请求路由与负载均衡

请求进来之后，怎么决定发给哪个副本？最简单的做法是轮询，但在LLM场景下这远远不够。不同请求的输入长度、输出长度、计算量差异巨大，轮询会导致某些副本过载而另一些空闲。

更合理的做法是基于实时负载做路由。调度器需要收集每个副本的当前队列深度、GPU利用率、显存占用、最近一段时间的P99延迟，然后根据这些指标计算一个综合得分，把请求发给得分最高的副本。这听起来简单，但实现起来有几个坑：指标收集本身有延迟，等你收集到的时候负载已经变了；不同指标的权重很难调，调不好会出现震荡。

ExaServe可能采用了预测式路由。根据请求的特征（输入长度、模型类型、优先级）预测计算量，再结合副本的当前状态做匹配。这种方案在Google的Pathways和微软的DeepSpeed-MII里都有类似实现，效果比纯反应式路由好不少。

4.3 故障检测与自愈

256个节点、3072个副本，硬件故障是常态而不是异常。每天坏一两张卡、一两个节点，在这个规模下太正常了。调度器必须能快速检测故障并自动恢复。

故障检测的粒度很关键。如果只做节点级心跳，那GPU挂了但节点还活着的情况就检测不到。如果做GPU级健康检查，那检查频率高了会影响性能，频率低了故障发现慢。我见过比较靠谱的做法是分层检测：节点级心跳每5秒一次，GPU级健康检查每30秒一次，推理请求的超时和错误率作为补充信号。三者结合，能在10秒内发现大部分故障。

自愈策略也要分情况。如果是单个副本挂了，直接在其他节点上重建副本就行。如果是整个节点挂了，那节点上的所有副本都要迁移，这时候要考虑目标节点是否有足够的资源，以及迁移过程中如何保证服务不中断。ExaServe的方案里，副本迁移应该是热迁移，即先在新节点上创建副本并预热，预热完成后再把流量切过去，最后销毁旧副本。

5. 实测中会遇到的坑：从纸面方案到稳定运行的距离

5.1 显存碎片导致的副本创建失败

这是我在实际部署中遇到最多的问题。GPU显存不像CPU内存那样有成熟的分页机制，频繁创建和销毁副本会产生大量碎片。表现就是：nvidia-smi显示还有20GB空闲显存，但新副本就是创建失败，报OOM。

解决办法有两个：一是预分配显存池，启动时就把显存全部申请下来，副本创建时从池子里分配，销毁时归还给池子，不走CUDA的malloc/free。二是定期整理碎片，在低峰期把所有副本迁移到其他节点，然后重启节点上的推理服务，让显存重新变得连续。第一种方案更优雅，但需要框架层面的支持；第二种方案简单粗暴，但会造成服务中断。

5.2 网络抖动引发的副本假死

InfiniBand网络虽然快，但也不是绝对稳定。交换机固件bug、光模块老化、线缆接触不良，都会导致网络抖动。表现就是副本的心跳突然断了，调度器以为副本挂了，开始迁移，结果迁移到一半网络恢复了，旧副本又活过来了，造成双主脑裂。

解决这个问题的关键是心跳超时时间要合理。太短了容易误判，太长了故障恢复慢。我的经验是：心跳间隔2秒，超时阈值设为10秒，即连续5次心跳丢失才判定为故障。同时，副本被判定故障后不要立即销毁，先进入"疑似故障"状态，观察30秒，如果期间心跳恢复就取消故障标记，否则再执行迁移。

5.3 模型加载时的IO瓶颈

3072个副本，如果同时加载模型，存储系统的IO压力是巨大的。一个70B的INT8模型大约70GB，3072个副本就是210TB的读取量。即使存储能扛住，网络也扛不住。所以必须做模型缓存：每个节点本地缓存一份模型文件，副本加载时从本地读，而不是从中心存储读。

本地缓存也有坑。节点本地盘容量有限，不可能缓存所有模型。需要做一个缓存淘汰策略，比如LRU，把最久未使用的模型文件删掉。但删的时候要小心，如果有副本正在使用这个文件，删了会导致副本崩溃。所以缓存淘汰要和副本调度联动，确保被淘汰的模型没有活跃副本。

5.4 副本间的数据一致性

如果多个副本共享一些状态（比如会话历史、缓存结果），那就要考虑一致性问题。强一致性会带来同步开销，弱一致性可能导致用户看到不一致的结果。ExaServe的方案里，我猜测它采用了最终一致性模型：每个副本本地维护一份状态，通过异步复制同步到其他副本。用户请求如果命中了状态较旧的副本，可能会看到稍旧的数据，但延迟更低。

这种取舍在LLM场景下通常是可接受的，因为LLM的输出本身就有随机性，用户很难察觉状态不一致。但如果你的场景对一致性要求很高，比如金融风控，那就需要强一致性方案，代价是延迟会上升。

6. 从ExaServe看超算级LLM部署的选型逻辑

6.1 什么场景真的需要256节点

不是所有LLM部署都需要256节点。如果你的日请求量在百万级别以下，模型规模在70B以下，单节点或几个节点就够了。256节点级别的部署，通常对应的是以下几种场景：

一是超大规模模型的在线服务。比如千亿参数以上的模型，单副本就要跨多节点，整体规模自然就上去了。二是极低延迟的全球服务。为了把首Token延迟压到100毫秒以内，需要在全球多个区域部署副本，每个区域又需要多个副本做冗余，总数就大了。三是多模型多版本的混合部署。一个平台同时服务几十个模型，每个模型又有多个版本，副本总数很容易突破千。

如果你的场景不在上述范围内，那ExaServe的方案可能过度设计了。过度设计的代价不只是硬件成本，还有运维复杂度和故障面。每增加一个节点，就多一个可能出故障的点；每增加一个副本，就多一份需要管理的状态。

6.2 自建还是采购：成本账怎么算

256节点H100集群，按每节点8卡算，就是2048张H100。一张H100按25万人民币算，光GPU就是5个亿。加上服务器、网络、存储、机房、电力、 cooling，总投资奔着10个亿去了。这还没算运维团队的人力成本。

自建的好处是可控性高，可以针对自己的业务做深度优化。坏处是前期投入大、周期长、风险高。采购云服务的好处是弹性，用多少付多少，不用操心硬件运维。坏处是单价高，长期跑下来总成本可能超过自建。

我的建议是：如果你的业务量稳定且可预测，自建更划算；如果业务量波动大或者还在探索期，先用云服务验证方案，等模式跑通了再考虑自建。ExaServe的方案更适合已经有稳定大规模推理需求、且对成本敏感的场景。

6.3 开源方案与自研的边界

ExaServe这个名字听起来像是一个自研方案，但它大概率站在了开源巨人的肩膀上。vLLM、TensorRT-LLM、DeepSpeed、Ray Serve这些开源项目已经解决了大部分基础问题，自研的部分应该集中在调度层和运维层。

调度层需要自研，因为开源调度器很少能原生支持256节点、3072副本的规模。运维层也需要自研，因为开源的监控告警工具在超大规模下往往性能不足。但推理引擎本身，除非你有非常特殊的模型结构或硬件，否则没必要从头写。用vLLM做基础推理，在上面套一层自研的调度和路由，是性价比最高的路径。

提示：自研调度器的时候，先把单节点多副本的场景跑通，再逐步扩展到多节点。不要一上来就搞256节点，那样出了问题根本定位不到是调度逻辑的问题还是网络的问题。

7. 如果我要复现类似方案，会从哪几步开始

7.1 先做小规模验证：8节点64副本

别一上来就搞256节点。先用8个节点、64个副本做验证。这个规模足够暴露大部分问题：显存碎片、网络抖动、调度延迟、故障恢复。而且成本可控，8节点H100集群的投入在可接受范围内。

验证阶段要重点观察几个指标：副本创建成功率、请求P99延迟、GPU利用率、网络带宽利用率、故障恢复时间。这些指标达标了，再考虑扩大规模。如果8节点都跑不稳，256节点只会更糟。

7.2 压测方案的设计

压测不是简单地发请求。你需要模拟真实场景的请求分布：输入长度有长有短，输出长度有长有短，请求到达有突发有平稳。我通常会用三个压测场景：稳态压测（固定QPS跑1小时）、峰值压测（逐步增加QPS直到系统崩溃）、混沌压测（随机杀副本、随机断网、随机加负载）。

混沌压测最能暴露问题。我见过一个方案，稳态和峰值都跑得很好，但一做混沌压测就原形毕露——副本被杀后重建要5分钟，期间请求全部超时。这种问题在真实生产环境里迟早会遇到，早发现早解决。

7.3 监控体系的搭建

256节点的监控，不能用传统的Prometheus单实例方案。指标量太大，单实例扛不住。需要用分层采集：每个节点本地采集，聚合后上报到区域聚合器，区域聚合器再上报到全局。查询的时候也分层查询，先查区域聚合数据，需要细节再下钻到节点。

告警策略也要分层。节点级告警发给运维团队，副本级告警发给业务团队，全局性告警发给架构团队。告警阈值要根据历史数据动态调整，不能用固定阈值。比如GPU利用率，白天80%可能是正常的，凌晨80%可能就是异常。

7.4 灰度上线与回滚

新方案上线一定要灰度。先切1%的流量到新方案，观察24小时。没问题再切10%，再观察。逐步扩大到100%。灰度期间要准备好回滚方案，一旦发现异常，能在5分钟内切回旧方案。

回滚方案不能只是"把流量切回去"，还要考虑状态的一致性。如果新方案已经处理了一些请求，产生了状态，回滚后这些状态怎么处理？我的做法是：灰度期间新方案只处理无状态请求，有状态请求继续走旧方案。等新方案稳定了，再把有状态请求也切过去。

8. 一些容易被忽略的细节

8.1 时钟同步

256个节点，如果时钟不同步，日志的时间戳会对不上，排查问题的时候根本理不清因果关系。NTP在局域网内能做到毫秒级同步，但对超算级部署来说不够。PTP（精确时间协议）能做到微秒级，但需要硬件支持。ExaServe的方案里，大概率用了PTP或者至少是经过调优的NTP。

8.2 电源和散热

2048张H100，满载功耗超过1.4兆瓦。这还不算CPU、内存、网络设备的功耗。机房要能提供足够的电力，还要有冗余。散热也是大问题，H100的散热需求远高于普通服务器，风冷可能不够，需要液冷。这些基础设施的投入，往往被低估。

8.3 模型版本管理

3072个副本，可能同时运行着多个版本的模型。版本管理混乱会导致用户请求被路由到错误版本的副本。需要一个版本注册中心，记录每个副本运行的模型版本，路由时根据请求的版本要求做匹配。版本升级时，要确保新旧版本能共存，且路由规则能正确区分。

8.4 安全隔离

多租户场景下，不同用户的请求可能被路由到同一个副本。如果副本没有做好隔离，一个用户的请求可能影响到另一个用户。隔离的粒度可以是请求级、会话级或副本级。请求级隔离最细，但开销最大；副本级隔离最粗，但最安全。ExaServe的方案里，我猜测它支持副本级租户隔离，即每个租户独占一组副本，互不干扰。

9. 关于成本优化的一些实战心得

9.1 混合精度与量化

FP16是默认选择，但INT8和INT4能显著降低显存占用和计算量。INT8量化后，模型精度损失通常在1%以内，但显存占用减半，吞吐量提升30%到50%。INT4量化更激进，显存占用降到四分之一，但精度损失可能达到3%到5%，需要根据业务场景权衡。

量化的坑在于校准数据的选择。校准数据分布和实际推理数据分布不一致时，量化后的模型在实际数据上表现会差很多。我的做法是用真实业务数据做校准，而不是用公开数据集。校准数据量不用太大，几千条就够，但分布要覆盖实际场景。

9.2 动态批处理

动态批处理能把多个请求合并成一个批次一起推理，显著提升GPU利用率。但批处理会引入延迟，因为要等凑够一批才能开始推理。延迟和吞吐的权衡，取决于你的SLA。如果SLA是P99小于500毫秒，那批处理窗口最多设100毫秒；如果SLA宽松，窗口可以设大一些。

ExaServe的方案里，动态批处理应该是标配。但批处理策略需要根据模型和硬件调优。批大小太大，显存不够；批大小太小，吞吐上不去。我通常会用自适应批处理：根据当前队列深度和GPU利用率动态调整批大小，队列深就加大批，队列浅就减小批。

9.3 副本的弹性伸缩

不是所有时候都需要3072个副本。低峰期可以缩容到几百个副本，高峰期再扩容。弹性伸缩的关键是快速扩容。副本从创建到就绪，如果模型加载要几分钟，那扩容根本来不及。解决办法是预热池：始终保持一定数量的空闲副本，扩容时直接从池子里取，不用等加载。

预热池的大小取决于扩容速度要求和成本预算。池子越大，扩容越快，但闲置成本越高。我的经验是：预热池保持在峰值副本数的10%到20%比较合理。

10. 写在最后：一些个人体会

搞超算级LLM部署这些年，最大的感受是：规模每上一个数量级，问题的性质就变一次。单节点的时候，优化的是模型和框架；几十节点的时候，优化的是网络和调度；几百节点的时候，优化的是运维和自动化。ExaServe的256节点方案，本质上是在解决"如何让几千个副本像一台机器一样工作"的问题。

这个问题没有银弹。每个方案都是在成本、延迟、吞吐、可靠性之间做取舍。ExaServe的取舍是什么，从公开信息里看不全，但可以确定的是，它一定在调度和运维上下了很大功夫。因为到了这个规模，硬件和框架的差距已经不大，真正的壁垒在于怎么管。

如果你正在规划类似规模的部署，我的建议是：先把小规模跑稳，再逐步扩大。不要被数字迷惑，256节点不是目标，稳定服务才是。另外，多和同行交流，很多坑别人已经踩过了，没必要自己再踩一遍。这个领域变化很快，今天的先进方案明天可能就过时了，保持学习的心态比什么都重要。