Twinkle x 昇腾，率先实现 Deepseek-V4 系列模型高效训练

沄森™2026-05-20

　　2026 年 4 月 24 日，DeepSeek-V4 发布。284B 到 1.6T 参数的 MoE 模型，混合注意力 CSA / HCA、流形约束超连接 mHC、Hash-MoE 静态路由 ——DeepSeek-V4 不是一个渐进式升

　　2026 年 4 月 24 日，DeepSeek-V4 发布。284B 到 1.6T 参数的 MoE 模型，混合注意力 CSA / HCA、流形约束超连接 mHC、Hash-MoE 静态路由 ——DeepSeek-V4 不是一个渐进式升级，而是一次架构重构。相较于推理适配，训练对精度要求更高，且流程更复杂，涉及到前向反向等多个环节，而训练涉及到的算力资源更多，资源调度与通信操作复杂性提升，让训练适配变得难上加难。

　　对于金融等行业的 AI Infra 团队来说，这个差异尤其关键。监管要求数据不出域，API 调用的路走不通。要在自有集群上微调 DeepSeek-V4，就必须完整解决 MoE 分布式训练的一系列工程问题。

　　某头部股份制银行 AI Infra 团队率先基于 Twinkle+ 昇腾 Atlas 800 A3 风冷超节点在 FSDP2 后端上完成了 DeepSeek-V4 的 SFT / LoRA 训练适配，实现了一套与 FSDP2 深度集成的 Expert Parallelism（EP）方案，并启用高效的昇腾 NPU 融合算子，和针对 DeepSeek-V4 开发的专属融合算子提升训练吞吐。

　　一、DeepSeek-V4 模型结构适配

　　DeepSeek-V4 使用了完全自研的 chat template，无法复用 HF 的 apply_chat_template。我们参考官方 encoding_dsv4.py，在 Twinkle 中实现了完整的编码模版。具体的，我们实现了如下的功能：

　　完整支持三种模式：chat、thinking（

　　DeepSeek-V4 特有 Tool Calling 调用格式支持：解析 DSML 格式的 <｜dsml｜invoke> 标签；

　　不同 Thinking Mode 支持：包括 reasoning_effort 控制、drop_thinking 策略；

　　在 DeepSeek-V4 上做 Agent 训练的团队不需要自己处理 tool call 的编码解码，Twinkle 框架通过适配好的模版直接提供。

　　二、FSDP2-4D 并行引擎适配

　　DeepSeek-V4-Flash 的完整模型加载需要超过 500GB 显存，单卡无法容纳。分布式训练是唯一的路径。FSDP2（Fully Sharded Data Parallel v2）是 PyTorch 原生的分布式训练方案，通过将模型参数、梯度、优化器状态分片到多张 GPU 上来降低单卡显存占用。

　　此前我们已经在 Twinkle 中实现了 EP, 专家并行（Expert Parallel, EP）的核心思路是：不让每张卡都持有全部专家，而是把专家参数按 EP rank 切分；前向时 router 仍然为每个 token 选择全局 expert id，然后通过 all-to-all 把 token 分发到对应专家所在 rank，本地专家计算完成后再 all-to-all 回收并按 routing weight 合并结果。

　　本次我们主要在之前 FSDP2-4D 并行引擎基础上兼容 Deepseek-V4 的 HashRouter。在 DeepSeek-V4 中，MoE router 有两种形式：普通 TopKRouter 和 HashRouter。当前 EP 适配没有为两者写两套 dispatch 逻辑，而是在 router 接入层做兼容：

　　对 TopKRouter：router 根据 hidden states 计算 logits，再选择 top-k experts，返回 router_logits / routing_weights / selected_experts 。

　　对 HashRouter：expert 选择不是动态 top-k，而是通过 tid2eid [input_ids] 查表得到固定 expert id；同时仍然用 gate logits 计算这些专家的 routing weights 。

　　Twinkle 的 EP patch 会保留 DeepSeek-V4 原生 router 的输出。如果 router 的 forward 支持 input_ids，就把上层传入的 input_ids 透传给 router，因此 HashRouter 可以正常执行 tid2eid [input_ids]。随后，无论 selected experts 来自普通 top-k 还是 hash table，都会被当作全局 expert id 构造 expert_mask，进入统一的 token dispatch 流程。

　　实测在开启 ep_fsdp 并行策略后，可进一步提升 40% 的训练效率。

　　三、显存、内存优化

　　284B 模型的训练，显存是贯穿所有环节的硬约束。Twinkle 在显存、内存等多方面展开了优化。

　　FSDP2 原本的模型初始化假设所有 rank 执行同样的 `from_pretrained` 加载。对于 284B 的模型，每张卡如果加载完整的模型权重，那么加载的权重会在占用 284*2Gi*world_sized 的内存，假设使用 16 路 fsdp2, 即 8.875TB 的内存。

　　为解决超大模型在 FSDP2 场景下的初始化内存问题，Twinkle 实现了 rank-aware 的模型初始化机制。具体流程如下：

　　训练启动时，Rank0 负责加载完整预训练权重，其他 Rank 仅基于 config 构建空模型，从而避免所有设备重复加载整份权重带来的巨大内存开销。随后，Twinkle 在 FSDP2 包裹和模型切分完成后，利用 rank0 广播机制将分片权重分发到各个 Rank，并进一步同步非 persistent buffer。最终，每个 Rank 仅持有自身所需的本地模型分片，在显著降低初始化内存占用的同时，完成训练前的模型恢复与对齐。

　　四、昇腾算力深度适配

　　为保障 Twinkle 框架在昇腾平台高效稳定训练 DeepSeek-V4，我们联合华为小巧灵团队，基于昇腾 Atlas 800 A3 风冷超节点完成多维度深度工程适配与性能优化。

　　1．通用 NPU 融合算子适配

　　在 NPU 算子适配工作中，我们针对昇腾 AI 处理器的硬件架构特性，重点实现了 GEMM（通用矩阵乘法）、RMSNorm（均方根归一化）、RoPE（旋转位置编码）等核心算子的高效迁移与深度优化。通过充分挖掘 NPU 的并行计算能力与融合指令集，确保计算精度无损的同时实现高效率训练。经过实测，开启 NPU 融合算子后，整网训练吞吐提升 13%+。

　　2．DeepSeek-V4 专属高性能 NPU 融合算子适配

　　针对 DeepSeek-V4-Flash 的 Attention 核心结构，昇腾 CANN 设计并实现了 4 个在训练场景下使用的高性能 Ascend C 算子，提升核心计算模块的性能并优化显存，Twinkle 训练框架深度适配了这 4 个高性能融合算子。

　　● LightningIndexer (LI) 算子基于一系列操作得到每一个 token 对应的 Top-k 个位置，输出 Top-k 位置的索引，供 SparseAttnSharedkv 作为输入完成计算。

　　● SparseAttnSharedKV (SAS) 算子旨在完成 Attention 计算，根据输入 cmp_ratio 不同支持 3 种 Attention 计算，分别为 Sliding Window Attention (SWA)、Compressed Attention (CFA) 以及 Sparse Compressed Attention (SCFA)。

　　● SparseAttnSharedkvGrad (SASG) 是 SAS 的反向算子，计算过程分为 3 个阶段。阶段一根据不同 cmp_ratio 场景，对输入 ori_kv 与 cmp_kv 进行选择，阶段二计算 P、dP、dS，阶段三计算 dQ, dKV, dSinks。

　　● SparseLightningIndexerGradKLLoss 算子，由于 LI 模块进行 Loss 计算时存在巨大显存开销 (序列的平方级别，需要计算 Main Attention score）。SparseLightningIndexerGradKLLoss 算子将 Main Atttion score 计算、LI 的反向、以及 Loss 计算过程融合，减少中间显存占用，优化显存和性能。