国产训推一体卡完成超大规模MoE模型Day-0适配：从模型发布到推理服务打通

大模型权重开源与硬件适配之间的时间差，一直是推理部署环节的固定成本。过去，一个数千亿级参数的模型从权重公布到能在特定加速卡上稳定输出 token，往往需要数周甚至更久的迁移、调试与算子补齐。而当参数规模跨入三万亿级、上下文长度逼近百万级、注意力机制改为稀疏结构时，这条链路上的每一个环节都会被放大。本文以一次“权重公布当日即完成基础推理链路打通”的适配实践为样本，拆解超大规模混合专家（MoE）模型在国产训推一体智算卡上的工程落地方法，重点讨论软件栈兼容、稀疏注意力接入、低精度专家权重处理与显存布局四个技术要点。

一、问题背景：当模型架构变化快于硬件适配周期

本次适配的目标模型属于三万亿级参数规模的 MoE 架构，支持百万级 token 上下文，并在后训练与强化学习阶段针对代码生成、3D 内容创作、金融研究、知识问答及长程智能体任务做了专项优化。从公开的基准表现看，其在终端操作类与长程代码类评测上已达到或接近顶尖闭源模型的水平，这也意味着这类模型会较快进入实际生产推理队列。

对硬件与软件栈而言，这类模型带来三重压力：

1. 参数规模与显存压力。三万亿级参数即使以低精度存储，也对单卡显存与多卡互联带宽提出极高要求，专家并行的切分策略必须与卡间通信拓扑匹配。
2. 注意力结构复杂化。模型采用稀疏注意力（DSA）与线性注意力类状态管理机制并存的混合结构，传统稠密注意力的 KV 缓存布局与计算路径无法直接复用。
3. 权重精度异构。专家权重采用 MXFP4 这类低精度块浮点格式，而算子库与计算单元往往以 FP8 或 BF16 为高效工作精度，二者之间需要一条低开销的转换通路。

所谓“Day-0 适配”，指的正是权重公布当日即完成模型加载、服务启动以及文本与图片基础推理链路的打通——它不是完整意义上的性能调优完成，而是“能跑通、能出结果、可作为后续优化基线”的工程里程碑。

二、适配总体思路：以兼容软件栈承接上游实现

快速适配的前提不是从零重写模型，而是尽可能复用上游社区已经验证过的模型实现。整体策略可概括为三层：

• 框架层：基于成熟的高吞吐推理框架承接上游模型代码，保留其并行策略、调度逻辑与采样流程，避免在模型语义层面做侵入式改动。
• 算子与编译层：通过自研算子库、类 Triton 的算子编程前端、面向特定领域的张量编程语言以及自研编译器，将新架构中的关键计算路径映射到目标硬件。
• 运行时与通信层：覆盖设备运行、框架执行与多卡通信，使迁移后的计算图能够在多卡环境下稳定执行。

这种分层设计的价值在于：新增计算路径只需在算子层补齐，框架层的调度与并行逻辑可以整体复用；而算子层又通过成熟接口对外暴露，降低了适配工作的耦合度。用伪代码描述这一承接关系，大致如下：

# 概念示意：框架层承接上游模型定义，算子层按后端派发
from sglang_backend import Runtime, ModelLoader
model = ModelLoader.load(
    arch="moe_sparse_attn",      # 上游已注册的模型结构
    weights="model_weights/",     # 权重目录，含低精度专家权重
    dtype="bf16",                # 激活与主干计算精度
    ep_size=8,                   # 专家并行度，与卡数对齐
)
runtime = Runtime(
    backend="musa",               # 目标硬件后端
    kv_cache_layout="paged_dsa", # 稀疏注意力的分页缓存布局
    comm="allreduce_ep",         # 专家并行通信原语
)
runtime.serve(model, tasks=["text", "image"])

三、关键技术点一：稀疏注意力与混合注意力链路的打通

该模型的注意力部分并非单一机制，而是由稀疏注意力（DSA）、状态管理模块、跨层残差连接以及视觉注意力共同组成的混合执行链路。适配工作需要在以下三个层面同时落地：

索引选择（Index Selection）。稀疏注意力的核心是先判定哪些历史 token 参与当前计算。适配时需将索引选择逻辑实现为可在目标硬件上高效执行的算子，避免因索引阶段引入额外的全局同步而拖慢 Prefill。

KV 缓存布局。稀疏结构下 KV 缓存不再是简单的连续张量，而需要按块（block）组织并支持按索引稀疏访问。工程上通常采用分页缓存布局，并为 Prefill 与 Decode 两个阶段分别设计访问模式：Prefill 阶段偏向批量稠密写入，Decode 阶段偏向按索引的稀疏读取。

Prefill 与 Decode 路径分离适配。两个阶段的计算特征差异显著——前者是长序列的并行计算，后者是逐 token 的增量计算。适配中分别对两条路径接入稀疏注意力算子，并与状态管理、跨层残差及视觉注意力串联，形成完整执行链路。任何一环缺失，都会表现为输出质量下降或长上下文下结果不一致，而非直接报错，因此链路完整性验证需要配合长上下文一致性测试。

四、关键技术点二：MXFP4 专家权重的在线转换与工作区复用

MoE 模型的参数量主要沉淀在专家层。本次模型的专家权重采用 MXFP4 格式，其优势是存储开销低，但计算单元通常以 FP8 为高效工作精度。常规做法是离线预生成一份完整的 FP8 权重副本，但这会带来两个问题：一是额外占用与专家权重规模相当的显存或存储空间，二是转换过程拉长了从权重公布到服务可用的时间。

适配方案采用在线转换 + 跨层复用 FP8 工作区的方式：

• 专家权重保持 MXFP4 原始格式驻留，加载阶段不做全量反量化；
• 计算前将所需专家块在线转换为 FP8，写入一块预先分配的 FP8 工作区；
• 该工作区在不同层之间复用，避免为每一层单独分配转换缓冲区。

这一设计的工程收益是显存占用与部署准备时间同时下降，代价是每次专家计算前引入一次转换开销。因此实际部署中需要关注转换与计算的流水重叠：将下一批专家的转换与当前批的计算安排在不同流上并发执行，可显著掩盖转换延迟。以下为概念性示意：

# 概念示意：在线转换 + 工作区复用
workspace = alloc_fp8_workspace(max_expert_tokens)  # 全局复用，按层轮转
for layer in decoder_layers:
    for expert_batch in schedule(layer.experts):
        w_fp8 = convert_mxfp4_to_fp8(expert_batch, out=workspace)  # 在线转换
        y = moe_gemm(x, w_fp8)                                     # 专家计算

需要强调的是，在线转换对数值一致性有直接影响。工程上应建立转换前后的一致性校验流程，在固定输入下比对输出分布，确认转换精度损失在可接受范围内，再进入性能调优阶段。

五、关键技术点三：显存布局与多卡通信的协同设计

三万亿级参数无法在单卡容纳，必须依赖专家并行与张量并行的组合切分。适配中需要处理三个协同问题：

并行切分与互联拓扑对齐。专家并行的 all-to-all 通信量与时延对整体吞吐影响显著，切分方案应尽量使专家分布与卡间互联带宽的分组结构一致，减少跨组通信。

KV 缓存与专家权重的显存争用。百万级上下文意味着 KV 缓存本身占用可观，而专家权重又需要常驻。工程上通常将 KV 缓存按分页方式动态分配，并把专家权重与转换工作区纳入统一的显存池管理，避免静态划分导致的碎片化。

转换工作区与通信缓冲区的隔离。在线转换的 FP8 工作区与通信缓冲区若共享同一段显存，可能在高负载下产生读写冲突。适配中应将二者分离，并为通信缓冲区预留固定配额。

六、验证清单：Day-0 适配完成的判定标准

“打通基础推理链路”需要可验证的判定条件，建议至少覆盖以下五项：

1. 模型加载完整性：全部层与专家权重加载成功，无缺省替换；
2. 服务启动稳定性：连续多次启动无显存溢出与初始化失败；
3. 文本推理正确性：固定 prompt 下输出与参考实现的一致性在可接受阈值内；
4. 图片推理链路可用：视觉编码器与文本解码器的拼接路径正常，图文混合输入可返回结果；
5. 长上下文一致性：在接近上下文上限的输入下，稀疏注意力索引选择与缓存复用不产生明显退化。

以上五项通过后，方可进入吞吐、时延与并发能力的性能调优阶段。Day-0 适配的意义正在于此：它把“能否运行”的问题在权重公布当日解决，把“运行得多快”的问题留给后续持续优化。

七、小结

超大规模 MoE 模型的硬件适配，本质上是三条链路的并行打通：框架层承接上游模型实现以复用调度逻辑，算子与编译层补齐稀疏注意力与低精度专家计算等新增路径，运行时层保障显存布局与多卡通信的稳定执行。其中，稀疏注意力的 Prefill/Decode 分离适配、MXFP4 专家权重的在线转换与工作区复用，是本次实践中两个最具代表性的工程决策。对于面向生产环境的推理部署团队，建议将上述验证清单固化为适配流程的准入门槛，并在 Day-0 基线之上建立可持续的性能回归体系。