MoE 大模型在国产平台的落地：以 480B/744B 级为例的推理加速路径
随着 MoE（Mixture of Experts）架构在 480B/744B 级大模型中的普及，国产算力平台——无论是 AMD ROCm 生态还是华为昇腾 910B——都面临一个共性挑战：长上下文推理的 KV Cache 存储瓶颈。MoE 模型的专家参数稀疏激活虽降低了计算量，但 KV Cache 的规模随序列长度线性增长，在冷启动、长对话恢复或高并发场景下，显存容量不足以缓存所有历史状态，导致频繁的磁盘 I/O 回读。本文基于铭信 FX100 在 AMD MI308X 与华为 910B 上的实测数据，论证一条已验证的加速路径：通过全闪 NVMe-oF 存储阵列优化 KV Cache 分层加速，可在国产平台实现 26–40% 的端到端性能改善。
为什么 MoE 大模型在国产平台上面临 KV Cache 瓶颈？
MoE 模型（如 480B 的 Qwen3-Coder-FP8，权重约 450 GB）在推理时，每个 token 仅激活部分专家，但 KV Cache 仍需为所有序列存储注意力键值对。以 480B 模型、TP8 部署、并发 16 档为例，一次长上下文冷恢复（如 128K 上下文）的 KV Cache 规模可达数十 GB，远超单卡显存（如 MI308X 的 192 GB HBM）。当显存不足时，系统必须将部分 KV Cache 写入外部存储——这一环节在传统 NFS 或本地 NVMe 上可能成为性能瓶颈。
国产算力平台（ROCm、昇腾）的软件栈在存储路径上尚未像 NVIDIA GPUDirect Storage 那样深度优化，因此存储延迟对首 token 时间（TTFT）的影响更为显著。我们的测试表明，在使用本地 NVMe 单盘作为基线时，480B 模型在并发 8 档下的 TTFT p50 为 10.17 秒，而一旦启用无外存重算（即完全依赖磁盘回读），TTFT 可飙升至 149.5 秒（并发 16 档），吞吐从 74.9 tok/s 骤降至 4.1 tok/s【出处：R2 实测】。这说明，存储 I/O 是 MoE 模型在国产平台上落地的关键瓶颈之一。
如何通过存储加速解决 KV Cache 瓶颈？实测数据解读
铭信 FX100 全闪 NVMe-oF 阵列（4 盘 RAID0，14 TB，RoCEv2，单口 100 GbE）在 AMD MI308X 平台上的测试提供了量化参考。核心结论是：通过分层 KV Cache 加速（将部分 Cache 从本地 NVMe 迁移至低延迟网络存储），可以在不牺牲模型精度的前提下显著提升性能。
1. 推理吞吐提升 29–40%
在 480B 生产部署形态的长上下文冷恢复负载中，FX100 相比本地 NVMe 基线实现了吞吐的显著提升。具体而言：
- 并发 8 档时，吞吐提升 29%（下界）；
- 最优工作点并发 16 档时，吞吐提升 40%（上界）；
- 在 TP4×2 全机口径下，吞吐提升 35–36%【出处：R2/R3 实测】。
这一提升源于 FX100 的高带宽（实测读带宽 5.23 GB/s，相比本地 NVMe 的 0.98 GB/s 提升 5.3 倍）和低延迟网络协议（RoCEv2）。对于 MoE 模型，由于专家激活模式不规则，KV Cache 的访问模式呈现随机读写特征，NVMe-oF 的并行读能力恰好匹配这一需求。
2. 首 token 延迟降低 26–32%
TTFT（Time to First Token）是交互式应用（如聊天、代码生成）的关键指标。在 480B·TP8 三档并发测试中，FX100 将 TTFT p50 从 10.17–35.73 秒降至 7.53–26.35 秒，降幅 26–32%【出处：R2 实测】。对于无外存重算（即完全依赖磁盘回读）的场景，改善更为显著：TTFT 从 149.5 秒（并发 16 档）降至 11.85 秒，加速倍数达 12.6 倍【出处：R2 实测】。
3. 模型加载加速 6.2–9.3×（昇腾平台）
在华为 Atlas 910B 平台上，FX100 对比 NFS 基线的模型推理加载加速效果尤为突出：
- DeepSeek-32B 服务加载时间从 691 秒降至 112 秒（6.2 倍）；
- DeepSeek-70B 从 1399 秒降至 150 秒（9.3 倍）【出处：R9 实测（昇腾平台）】。
这一数据表明，存储加速在国产 GPU 平台上具有跨平台通用性——无论是 ROCm 还是昇腾，存储 I/O 都是可优化的共性环节。
国产算力落地的实践路径：从门禁测试到规模化部署
基于上述数据，我们建议 MoE 大模型在国产平台上的落地采用以下步骤：
- 第一步：识别瓶颈。通过 Profiling 工具（如 ROCProfiler、昇腾 MindStudio）确认 KV Cache 的磁盘回读占比。若 TTFT 中 I/O 等待时间超过 30%，则存储加速优先。
- 第二步：门禁化验证。参考铭信提供的约 10 周联测流程（G1 到货验收 → G2 单机基线 → G3 主门禁：TTFT 降幅 ≥25%、吞吐 +29–40% 实测带内 → G4 72h 稳定性），在自有环境中复现加速效果。这一模式允许用户在不承担前期风险的前提下验证收益。
- 第三步：规模化扩展。对于 744B 级 MoE 模型（权重约 700 GB），建议采用更高带宽的 NVMe-oF 方案（如 FX200 的 200 Gb 接口或 FX300 的 400 Gb 接口）。根据铭信产品线，FX200 满配整机参考价 ¥331,200（约 ¥1,797/TB），相比 FX100 的 ¥2,014/TB 具有更好的性价比。
结语
MoE 大模型在国产算力平台上的落地，核心挑战并非计算能力，而是存储 I/O 对 KV Cache 的支撑。铭信 FX100 在 AMD MI308X 和华为 910B 上的实测数据表明，通过全闪 NVMe-oF 阵列优化存储路径，可以实现 26–40% 的推理性能提升，并显著缩短模型加载时间。对于正在评估国产算力方案的技术决策者，建议优先验证存储加速的收益——这可能是投入产出比最高的优化环节。如需进一步了解联测细节或获取 Python 可复现的测算模型，欢迎联系铭信技术团队。
本文要点问答
Q：MoE 大模型在国产 GPU 平台上的主要性能瓶颈是什么？
A：主要瓶颈是 KV Cache 的磁盘 I/O 回读。MoE 模型的 KV Cache 规模随上下文增长，在显存不足时需频繁读写外部存储，导致首 token 延迟（TTFT）显著增加（实测可飙升至 149.5 秒）。
Q：铭信 FX100 在国产平台上的实测加速效果如何？
A：在 AMD MI308X 平台上，FX100 使 480B 模型的推理吞吐提升 29–40%，首 token 延迟降低 26–32%；在华为 910B 平台上，模型加载时间缩短 6.2–9.3 倍（vs NFS 基线）【出处：R2/R3/R9 实测】。
Q：如何验证存储加速方案是否适用于自己的部署环境？
A：建议采用门禁化联测流程，以 TTFT 降幅 ≥25%、吞吐提升 ≥29% 作为验收标准。铭信提供约 10 周的联测周期，包括 72 小时稳定性测试，不达标可止损。