国产大模型与国产算力深度适配：MoE推理部署全链路优化实践

1. 从"模型等算力"到"算力追模型"：这次适配到底改变了什么

过去两年，做大模型应用的人都有一个共同体会：模型迭代的速度远远快过算力适配的速度。一个新模型发布，团队最头疼的往往不是模型本身好不好用，而是"我手里的硬件能不能跑得动、跑得好"。尤其是当模型参数从百亿级迈向千亿级、MoE架构成为主流之后，推理侧的显存占用、通信带宽、算子效率，每一个环节都可能成为压垮部署方案的最后一根稻草。

这次国产大模型与国产算力平台的深度适配，核心价值就在于把"模型发布"和"算力可用"这两件事之间的时间差大幅压缩了。它不是一个简单的"能跑起来"的兼容性声明，而是从底层算子、通信库、并行策略到推理框架的全链路打通。换句话说，以前是模型发布之后，硬件厂商再花几个月去追着做适配；现在变成了模型和算力平台在设计和优化阶段就互相"对表"，让算力真正追上了模型的迭代节奏。

这篇文章适合三类人看：一是正在做私有化部署、被硬件选型困扰的工程团队；二是关注国产算力生态、想搞清楚技术细节的开发者；三是需要向团队或客户解释"为什么这次适配值得关注"的技术负责人。我会从适配的技术本质、MoE架构带来的特殊挑战、实际部署中的关键参数、以及踩坑经验几个角度，把这件事讲透。

需要先说明一点：本文涉及的具体性能数据均来自公开技术资料的合理推断和行业常见实践，不同硬件配置、不同模型版本、不同并发场景下结果会有差异，请以实际压测为准。

2. 适配不是"装个驱动"：拆解全链路打通的四个层次

很多人对"模型适配硬件"的理解还停留在"装个驱动、跑个demo"的阶段。实际上，一个千亿参数级别的MoE模型要在国产算力平台上达到可用甚至好用的状态，需要打通至少四个层次。这四个层次任何一层没做好，最终表现出来的都是"能跑但慢得没法用"或者"跑着跑着就崩了"。

2.1 算子层：那些被忽略的"非矩阵乘"开销

大家聊大模型算力，第一反应都是矩阵乘法、FLOPs、算力峰值。但真正做过推理部署的人知道，矩阵乘往往不是瓶颈，瓶颈藏在那些"看起来不起眼"的算子里。

以MoE架构为例，每个token经过路由网络后，会被分发到不同的专家（Expert）上。这个分发过程涉及大量的gather、scatter、index_select等操作。这些算子在GPU上通常有成熟的CUDA实现，但迁移到其他算力平台时，如果只是用通用算子拼凑，性能会断崖式下跌。原因很简单：这些操作本质上是内存密集型而非计算密集型，对显存带宽和访存模式极其敏感。

这次适配的一个关键工作，就是针对这类"非矩阵乘"算子做了深度优化。具体来说，包括把多个小算子融合成一个大算子以减少kernel launch开销，针对特定硬件的访存特性重新设计数据排布，以及在路由分发环节引入更高效的排序和分组策略。这些优化单独看可能只提升几个百分点，但叠加起来，在MoE模型的端到端推理中可能就是百分之二三十的差距。

提示：如果你在做自己的部署方案，评估算力平台时不要只看矩阵乘的峰值算力，一定要拿真实的MoE模型跑端到端推理，重点观察路由分发、KV Cache管理、以及专家并行的通信开销。

2.2 通信层：专家并行下的"隐形税"

MoE模型之所以难部署，很大程度上是因为它天然需要专家并行（Expert Parallelism）。简单说，不同的专家被放在不同的设备上，每个token需要跨设备去访问它被路由到的专家。这就带来了大量的All-to-All通信。

在传统稠密模型里，通信主要发生在张量并行和流水线并行的边界上，模式相对固定。但MoE的All-to-All通信是动态的、不规则的——每个token去哪个专家取决于路由结果，负载可能严重不均。如果通信库没有针对这种场景优化，就会出现"有的设备忙死、有的设备闲死"的情况，整体吞吐被最慢的那个设备拖垮。

这次适配在通信层做了几件实事：一是针对All-to-All通信做了拓扑感知的路径优化，让数据尽量走带宽更高的链路；二是引入了动态负载均衡策略，在路由阶段就考虑各设备的当前负载，避免热点；三是把通信和计算做了一定程度的overlap，让设备在等待通信时也能干点活。

2.3 并行策略层：TP、EP、PP怎么组合才不打架

有了好的算子和通信库，还需要一套合理的并行策略把它们组织起来。这里面的门道很深，因为张量并行（TP）、专家并行（EP）、流水线并行（PP）各有各的适用场景和代价，组合不好就会互相拖累。

一个常见的误区是"并行度越高越好"。实际上，并行度越高，通信开销越大，而且每个设备上的计算量变小，算力利用率反而可能下降。这次适配给出的参考配置里，针对不同规模的模型和不同的硬件互联带宽，给出了TP/EP/PP的组合建议。比如在互联带宽有限的情况下，优先用EP而不是TP，因为EP的通信模式虽然复杂但总量可控；而在带宽充足时，适当增加TP可以降低单设备的显存压力。

2.4 推理框架层：调度、批处理与显存管理

最上面一层是推理框架。模型和硬件都准备好了，但如果框架的调度策略不合理，照样跑不出好性能。这里的关键点包括：连续批处理（Continuous Batching）怎么实现、KV Cache怎么分页管理、prefill和decode阶段怎么分配资源。

MoE模型在这方面的特殊之处在于，不同专家的计算量可能差异很大，如果框架按统一节奏调度，就会出现"快专家等慢专家"的情况。这次适配在框架层引入了专家感知的调度策略，根据每个专家的历史耗时动态调整批处理大小，让整体吞吐更平稳。

3. MoE架构为什么是这次适配的"硬骨头"

如果说适配一个稠密模型是"常规难度"，那适配一个MoE模型就是"困难模式"。这一章我想专门讲讲MoE带来的特殊挑战，因为这是理解这次适配技术含量的关键。

3.1 专家路由：一个看似简单实则致命的环节

MoE的核心思想是"用多个专家分别处理不同类型的输入，每次只激活其中一小部分"。听起来很优雅，但工程实现上有几个致命细节。

首先是路由的负载均衡问题。如果训练时没有做好负载均衡，推理时就会出现"某些专家被绝大多数token选中，另一些专家几乎闲置"的情况。这直接导致两个后果：一是被选中的专家所在设备成为瓶颈，二是闲置设备的算力被浪费。更麻烦的是，这种不均衡是动态的，随着输入内容变化而变化，没法用静态方案解决。

其次是路由决策的开销。路由网络本身是一个小的线性层加softmax，计算量不大，但它需要读取每个token的隐藏状态，然后产生路由决策，再根据决策去gather对应的专家参数。这个过程中涉及多次显存读写，如果实现得不好，路由环节的开销可能占到总推理时间的相当比例。

3.2 专家并行的通信模式：All-to-All为什么这么贵

前面提到过All-to-All通信，这里展开说说为什么它贵。

在标准的张量并行里，通信是All-Reduce，模式规整，可以用ring或者tree等高效算法。但MoE的All-to-All是"每个设备把不同的数据发给不同的设备"，数据量和目标都是动态的。在最坏情况下，通信量正比于"设备数×每设备token数×隐藏维度"，而且因为负载不均，实际有效带宽利用率可能很低。

更棘手的是，All-to-All通信和计算很难overlap。因为计算必须等通信完成才能开始（你得先拿到专家参数才能算），而通信又必须等路由完成才能开始。这个串行依赖链让优化空间很有限。这次适配的一个亮点，就是通过把路由和部分通信提前，以及把不同层的通信和计算交错，部分打破了这种串行依赖。

3.3 显存墙：专家参数怎么放才不爆

MoE模型的参数量通常很大，但每次推理只激活一小部分。这带来一个显存管理上的两难：如果把所有专家参数都放在显存里，显存占用太高；如果放在内存里按需加载，又会有严重的加载延迟。

常见的做法是"专家参数常驻显存，但通过量化压缩"。比如把专家参数从FP16量化到INT8甚至INT4，显存占用直接减半或更多。但量化会带来精度损失，需要在推理质量和显存占用之间找平衡。这次适配在量化方面也做了工作，支持了多种量化策略，并且针对MoE的特点做了分层量化——对精度敏感的层用高精度，对精度不敏感的层用低精度。

4. 实际部署时，这几个参数和配置最容易被搞错

理论讲完了，这一章聊点实在的。如果你真的要在国产算力平台上部署一个MoE大模型，下面这些参数和配置细节是我踩过坑或者见别人踩过坑的地方。

4.1 批处理大小：不是越大越好

很多人觉得批处理大小（batch size）越大，吞吐越高。在稠密模型上这基本成立，但在MoE模型上不一定。

原因是MoE的专家激活是稀疏的，batch size增大时，被激活的专家数量也会增加，但增加的速度不是线性的。当batch size大到一定程度，几乎所有专家都被激活了，这时候MoE就退化成了稠密模型，失去了稀疏性的优势。更糟的是，大batch还会加剧负载不均——某些专家被大量token选中，成为瓶颈。

我的经验是，MoE模型的batch size要结合专家数量和路由分布来定。一个实用的起点是：让平均每个专家处理的token数在几十到一百这个量级。太小了算力利用率低，太大了负载不均严重。具体数值需要压测确定。

4.2 KV Cache管理：分页是必须的

KV Cache是推理显存的大头，尤其是长上下文场景。MoE模型因为参数量大，留给KV Cache的显存更紧张，所以KV Cache的管理必须精细。

分页（PagedAttention）是目前的主流方案，把KV Cache切成固定大小的块，按需分配。但MoE场景下有个特殊问题：不同专家的KV Cache可能在不同设备上，如果分页策略不考虑这一点，就会出现跨设备访问KV Cache的情况，延迟很高。

这次适配在KV Cache管理上做了专家感知的优化，尽量让同一个专家的KV Cache留在同一设备上，减少跨设备访问。如果你自己实现，也要注意这一点。

4.3 量化策略：分层量化比统一量化更靠谱

前面提过量化，这里补充一个实操细节：不要对所有层用同一种量化精度。

MoE模型里，路由网络和注意力层的精度通常比较敏感，量化到INT8可能就有明显质量下降；而专家层的FFN部分相对鲁棒，量化到INT4甚至更低也能接受。所以推荐的做法是分层量化：路由和注意力用高精度，专家FFN用低精度。这样能在显存和质量之间取得更好的平衡。

注意：量化后的模型一定要做质量评估，不能只看困惑度（perplexity），还要看实际任务上的表现。有些量化方案在困惑度上看起来没问题，但在具体任务上会出现明显的退化。

4.4 并行度配置：从保守开始，逐步调优

并行度配置（TP/EP/PP的组合）是部署中最容易调错的地方。我的建议是：从保守配置开始，逐步增加并行度，观察吞吐和延迟的变化。

具体来说，先确定单设备能放下的最大模型分片，然后根据设备数量和互联带宽决定并行策略。如果互联带宽高（比如同一节点内），可以多用TP；如果带宽低（跨节点），优先用EP和PP。每次调整后都要跑完整的压测，不要凭感觉。

5. 从"能跑"到"好用"：性能调优的完整排查链路

部署完成只是第一步，真正的工作量在调优。这一章我按排查顺序，把从"能跑但慢"到"跑得稳且快"的完整链路梳理一遍。

5.1 第一步：定位瓶颈在计算还是通信

拿到一个跑得慢的部署，第一件事是搞清楚瓶颈在哪。最直接的方法是看时间分布：计算占多少，通信占多少，等待占多少。

如果计算占比高，说明算子效率有问题，需要看是不是有算子没有针对硬件优化，或者是不是batch size太小导致算力利用率低。如果通信占比高，说明并行策略或通信库有问题，需要看是不是All-to-All太频繁，或者是不是通信和计算没有overlap。如果等待占比高，说明负载不均，需要看路由分布和调度策略。

5.2 第二步：检查路由分布是否均衡

MoE模型调优，路由分布是必查项。具体做法是统计一段时间内每个专家被选中的次数，如果发现某些专家的选中次数远高于其他专家，那就是负载不均。

负载不均的原因可能是训练时没有做好均衡，也可能是推理时的输入分布和训练时差异大。解决办法包括：在路由阶段引入温度参数让分布更平滑，或者在调度阶段对热点专家做请求排队和分流。

5.3 第三步：验证通信是否被正确overlap

通信和计算overlap是提升MoE推理性能的关键手段。验证方法是看通信时间是否被计算时间"掩盖"了。如果总时间约等于计算时间加通信时间，说明没有overlap；如果总时间接近两者中的较大值，说明overlap做得不错。

如果发现没有overlap，检查点包括：通信是否在独立的流（stream）上执行，计算是否依赖通信结果导致无法并行，以及框架是否支持异步通信。

5.4 第四步：压测不同并发下的表现

最后一步是压测。MoE模型的性能对并发数很敏感，低并发和高并发下的瓶颈可能完全不同。低并发时可能是延迟受限，高并发时可能是吞吐受限。所以要在多个并发级别下测试，找到性能拐点。

压测时要注意：不要只测平均值，要看P99延迟。MoE模型的延迟分布往往比稠密模型更分散，因为路由的不确定性会导致某些请求特别慢。P99延迟才是用户体验的真实反映。

6. 这套适配方案适合谁用，以及几个现实约束

聊了这么多技术细节，最后说说适用场景和现实约束，免得大家看完觉得"什么都能干"。

6.1 最适合的场景：私有化部署和中高并发推理

这套适配方案最直接的价值场景是私有化部署。很多企业对数据安全有要求，不能把模型调用发到外部，必须自己部署。这时候国产算力平台加国产大模型的组合，就是一个可控性很高的选择。

另一个适合的场景是中高并发推理。MoE模型的稀疏性在中高并发下才能充分发挥——并发太低时专家激活不充分，算力浪费；并发高时专家利用率高，吞吐优势明显。所以如果你的业务是面向大量用户的在线服务，这套方案比较合适。

6.2 不太适合的场景：极低延迟的单次推理

如果你的场景是"单次请求、要求极低延迟"，比如某些实时交互应用，那MoE模型可能不是最优选择。因为MoE的路由和通信开销在单次推理中无法被摊销，延迟可能比同等质量的稠密模型更高。这种情况下，稠密模型或者更小的模型可能更合适。

6.3 现实约束：生态成熟度还在爬坡

必须承认，国产算力生态的成熟度相比国际主流方案还有差距。这个差距主要体现在：工具链的完善程度、社区资源的丰富程度、以及遇到问题时可参考的案例数量。这次适配是一个重要的里程碑，但不代表所有问题都解决了。

我的建议是：如果你现在要上这套方案，做好"遇到问题需要自己啃"的心理准备，同时积极和平台方、模型方沟通，很多问题他们已经有解决方案，只是还没形成公开文档。

6.4 一个容易被忽略的点：模型版本和硬件版本的匹配

最后提醒一个实操中很容易忽略的点：模型版本和硬件平台的适配是有版本对应关系的。不是任意版本的模型都能在任意版本的平台上跑出最优性能。部署前一定要确认版本兼容性矩阵，不要想当然。

我在实际项目中见过因为版本不匹配导致性能只有预期一半的情况，排查了很久才发现是适配层版本对不上。这个坑希望大家能避开。

整体来看，这次国产大模型和国产算力平台的深度适配，标志着生态从"各自为战"走向"协同优化"。对于做应用的人来说，这意味着多了一个可控、可预期的部署选项。至于这个选项是否适合你的具体场景，还是要拿真实业务负载去压测，数据说话。