——把「复用到哪一步」拆成有证据的四层
摘要：判断跨平台生态是否成熟，可检验的问法是：迁移第二个模型、升级一次框架、更换一代硬件时，能复用多少已有成果。本文把复用拆成四层：
- 接口形状：API 对齐有公开依据，但能力清单有缺口；
- 实现代码：全部公开，各自条件下的成绩可查；
- 测试与验证方法：成体系的测试可继承，但验证的是组件，不是使用者的组合；
- 运行环境：成绩所用的 HDK 尚未公开发行。
维护的对象是多组组合；把各自的验证结果整理成可交换的清单，是生态从发布走向积累的途径。
前六篇评估的都是「这一次迁移」：资源怎么算，性能怎么比，正确性怎么验，成本怎么算。最后一篇换一个问题：这一波开源建立起来的东西，下一次迁移、下一次升级能继承多少？其中有多少是今天就能讲清楚的？
如果「生态成熟」只用来形容仓库数量、发布热度或者一次成功的演示，它就无法被检验。可以检验的问法是：同一个团队迁移第二个模型、升级一次框架、更换一代硬件时，能复用多少已有成果？
回答这个问题要分层。复用不是一个非开即关的开关，接口形状、实现代码、测试与验证方法、运行环境是四层不同的东西，每一层都有各自的公开依据和边界。目前这四层能拿出的公开依据并不一样。把它们混在一起谈「成熟」或「不成熟」，最后只会得到口号。
一、版本变更怎样传导：一个真实样本
先看生态必须扛住的第一种压力：版本变更。
第一个样本来自 FlashMLA 的变更记录。2026 年 9 月 30 日发布的版本移除了对 Hopper 架构和部分旧模型（DeepSeek V3、V3.2、V4.0）的支持，并修改了 FP8/FP4 KV 缓存的格式。仍需要旧支持的用户，要切换到指定的历史提交（见 FlashMLA README）。
收窄支持范围本身是正常的工程选择，目的是把力量集中在当前最重要的模型和硬件组合上。对部署方来说，关键是按依赖关系分析这类变更的影响，不能笼统地认为「全都坏了」，也不能认为「全都没事」。下表以这次变更为例（这是本文的分析，不是官方的影响说明）：
| 变更项 | 影响哪条依赖 | 需要复核什么 | 不受影响的部分 |
|---|---|---|---|
| 修改 FP8/FP4 KV 缓存格式 | 缓存的写入方和读取方：量化路径、索引解释、注意力内核对格式的假设 | 写入和读取两侧是否同步更新；旧的缓存数据是否需要迁移或作废 | 不经过这种缓存格式的路径 |
| 移除 Hopper 和 V3/V3.2/V4.0 支持 | 使用这些模型或架构的组合 | 切换到指定的历史提交，或冻结旧版本继续运行 | 已经冻结旧版本运行旧模型的部署，不会因为主线收窄而自动受影响 |
所以，工程负担不只是「装一次能不能跑通」，更在于要长期同时维护多组模型、硬件、框架和量化配置的有效组合。每次遇到变更，都可以照这张表问四个问题：改了什么？影响哪条依赖？要复核什么？哪些部分可以原样保留？
二、复用的四层，以及各层的公开依据
第一层：接口形状。
DeepEP 公开的 buffer API 与 NVIDIA 版保持一致，DeepGEMM 沿用了同一个包名和同一套 API，所以上层调用代码有机会少改一些。这一层的证据最扎实：接口对齐是仓库明确写出的，接口约束（例如 do_expand 必须为 True、路由索引必须是 int64）也都公开写明了。
但第一篇已经列过：接口形状相同，不等于能力相同。负载均衡通信只提供了 API，内核还没有实现；图捕获也不支持。这些缺口都藏在接口层的下面。
第二层：实现代码。
五个仓库——DeepGEMM-Ascend、DeepEP-Ascend、FlashMLA、TileKernels、DeepJIT，即第一篇的五个仓库——的实现代码全部公开，各自给出的成绩如下：
- DeepGEMM 的 GEMM 给出峰值利用率 99.8%；FlashMLA 的稀疏注意力给出 95%/83%；
- DeepEP 和 MegaMoE 给出了各自条件下的带宽和整段基准；
- DeepJIT 是编译运行时，不属于给出峰值成绩的组件。
这些成绩只在各自声明的条件下成立，不能从部分组件推广到整个服务。
对优化者来说，这些代码是可以拆开研究的参照；对二次开发者来说，它们是可以适配的起点。TileKernels 用 TileLang 双后端自动选择，让同一套 Python API 跑在两种硬件上，就是一个现成的例子。不过，适配时要按照昇腾的布局和流水线语义重做（见第二、四篇），不是零成本的搬运。
第三层：测试与验证方法。
这是最容易被低估的一层。各仓库在交付代码的同时，也交付了成体系的测试：
- DeepEP 的测试覆盖专家对齐为 1 和 128 两种情况，并检查专家区间和填充区域；
- DeepGEMM 用 aclnn 参考实现做交叉验证，并提供确定性开关；
- 布局转换有单独的 stride 检查。
这些测试和用例本身就是可以继承的资产。第五篇那条验收路径的每一个环节都建立在它们之上，后来者不需要从零开始设计验收方法。
这一层的边界也要讲清楚：这些测试验证的是各个组件在声明条件下的行为，验证的不是使用者自己的组合。「组件测试通过」和「我的组合验证过」是两回事，后者要每个团队自己积累。
第四层：运行环境。
DeepEP 公布的成绩是在手工配置的 PoC HDK 上测出来的，这个 HDK 不是公开发行版。根据 README，商用版本预计在 10 月中旬由厂商发布，具体以实际发布为准（见 DeepEP README）。
在商用版本公开之前，「代码能读到」和「成绩能复现」之间还隔着配置环境这一步。使用者在自己环境里测到的数字可能比 README 表格里的低。差距到底来自配置还是来自实现，要按已知的配置要求逐项排查，不能默认实现没有问题。
另外，V3.2-Exp 的发布材料中提供了 SGLang 的 NPU 镜像入口。这条路径是给上一代型号用的现有框架方案，不代表这一批 950 新内核已经全部集成进去，也不代表这条路径用不了。这两件事各自成立，不能互相担保。
四层合起来，才是对「这次开源提供了什么」的完整回答：
- 接口层：可以复用；
- 代码层：可以研究，也可以适配；
- 验证层：可以继承验证方法；
- 环境层：还缺一个公开发行版。
这四层的证据都在前六篇出现过。分层的意义在于，把「生态成熟」从一个形容词变成一张可以逐项核对的检查表。
三、要维护的是组合，要积累的是清单
组件一多，要维护的就不再是单个组件，而是它们之间的组合。
假设一个部署团队要维护 3 个模型版本、2 种硬件、4 个框架版本和 3 套量化配置，全部组合起来就有 3 × 2 × 4 × 3 = 72 种。这是本文构造的分析框架，不需要逐一穷举，多数团队实际只会用到其中一部分。任何一个组件升级，所有包含它的组合都可能受到影响，需要重新验证。第一节的那次版本变更，就是一个真实的例子。
所以，比「支持某平台」更有用的交付是一份清单，写明：
- 哪些组合已经验证过；
- 每个组合覆盖哪些请求范围；
- 哪些变化需要重新验证；
- 保留了哪些已知可用的组合和回退方法。
目前公开可查的「已验证组合」，是厂商的组件测试和 MegaMoE 这类整段基准覆盖的配置。这里还要区分两件事：「有可以运行的测试」和「有一份在指定环境下执行通过的公开报告」。前者随仓库一起交付；后者在本次公开材料中还没有，至少没有一份完整的生产框架组合验收报告。使用者那一边已经有多少公开的验证结果，本文没有穷尽检索。把各自的验证结果整理成可以互相交换的清单，正是生态从「发布」走向「积累」的途径。
第二次迁移的工作量可以拆成四部分：
W_第二次 = W_新增适配 + W_重复定位 + W_验证 + W_部署
生态建设要压缩的是其中的「重复定位」。如果生态在起作用，后来者就不需要：
- 重新弄清 UE8M0 的排布方式（第二篇）；
- 重新摸索编译参数和缓存签名（第五篇）；
- 重新确认哪些接口只是占位；
- 重新走一遍已经解决过的版本冲突路径（第一节）。
四、对部署者：分两个阶段判断
第一阶段：看功能和环境，决定能不能进入试点。
满足以下两个条件的组合，就可以进入技术评估和试点：
- 必需功能在当前支持范围内：不依赖图捕获，不依赖负载均衡通信内核，不需要 Bucket 的 reduce-scatter 和 all-reduce；
- 环境可以获得：有 950 系列硬件和对应版本的 CANN，HDK 按官方指引配置。
试点阶段可以做的事情包括：跑通各个组件、研究实现代码、按第五篇的路径搭建验收流程，并把 MegaMoE 和组合式两条路线都纳入测量。
第二阶段：看验证结果，决定能不能用于生产。
进入生产之前，还要为这个组合完成三项工作：正确性验证、服务性能测量和升级回归。具体来说：
- 在自己的负载形状下做实测（第二、三、四篇）；
- 做组合验证和服务级测量（第五、六篇）；
- 复核版本变更的影响范围（第一节）。
这些工作没有人能替你完成。公开的组件测试和 MegaMoE 整段基准只是各自范围内的起点，不能证明整套框架组合已经验证过，所以生产采用前的这一步验证不能省略。
关于缺口，要准确判断它是否构成阻塞：只有当方案依赖的能力出现在缺口清单上，而且没有经过验证的替代路径时，它才是这个方案的阻塞项。不依赖这些能力的部署，不需要等待。
还要校准一个预期：商用 HDK 公开发布之后，下载下来测到的数字也不一定和 README 表格一致。排查环境差异仍然是部署方自己的工作。本系列做到的是：列出的每一项，要么有公开依据可以查证，要么标明了缺口和适用条件。
五、对生态建设者：清单就是路线图
这批组件把「跨平台推理栈长什么样」的参照公开了出来，不同角色各有收获：
- 框架方：得到了可以集成的算子和接口；
- 工具链方：得到了两条编译路线（DeepJIT 和 TileLang）的实际案例；
- 平台方：得到了一份明确的差距清单。本次公开材料中缺少的，正是框架集成、图捕获、负载均衡通信内核和等价的运行环境。
要补什么、按什么顺序补，这份清单本身就提供了依据。测试与验证方法（第三层）积累和公开得有多快，很大程度上决定了后来者要做多少重复劳动。
结语
对这组项目，可以给出一个准确的判断：这批组件把可以复用的接口、实现代码和测试方法公开了出来，成为后来者可以直接使用的积累；运行环境还要等待公开发行版。下一次迁移能不能因此少做重复工作，取决于三点：接口在版本升级后能否保持稳定（第一节），运行环境能否以等价的方式获得（第四层），测试与验证方法能否持续公开。
检验方法很简单：去问一个刚刚完成第二次迁移的团队，时间是花在新增适配上，还是花在重新发现别人早已知道的事情上？答案就反映了生态的成熟度。
对部署团队来说，这批组件让每个环节都有了可以核对的参照和可以继承的验证方法；自己要完成的，是在实际负载形状下实测、做组合验证和升级回归。具体做法是：
- 遇到版本变更，按第一节的影响表把依赖关系过一遍；
- 评估方案时，按第四节的两个阶段判断：功能和环境都满足的组合先进入试点，生产采用前补齐这个组合的正确性验证、服务性能测量和升级回归；
- 看到「兼容」「接近峰值」「生态成熟」这类说法时，逐项核对三件事：它声明支持的范围是什么？成绩是在哪种模型、硬件、软件版本和负载下测出来的？有没有在实际的服务组合里验证过？
系列回顾
- 第一篇：描绘系统全景，梳理迁移涉及的实体；
- 第二篇：从 API 兼容深入到数据布局和形状；
- 第三篇：完整走通一次专家并行的往返；
- 第四篇：拆解 95% 利用率背后的一连串取舍；
- 第五篇：给出可以复现的验收路径；
- 第六篇：把技术选择换算成单位有效产出的成本；
- 第七篇（本篇）：把复用拆成四层，给出维护组合的判断依据。
资料与计算说明：本文依据各项目的公开仓库和文档撰写，资料核验截至 2026 年 10 月 7 日。
- 以下内容均来自各项目的官方 README：FlashMLA 2026 年 9 月 30 日的版本变更；DeepEP 的能力分层、PoC HDK 手工配置和商用版本计划（预计 2026 年 10 月中旬发布，以厂商实际发布为准；若发布时 HDK 已公开，本节相应表述以实际状态为准）；DeepGEMM 的 API 兼容和 aclnn 交叉验证；TileKernels 的双后端自动选择。
- SGLang NPU 镜像入口来自 V3.2-Exp 的发布材料。它和本次 950 内核的集成情况，公开材料中没有说明，本文不做判断。
- 以下内容是本文构造的分析框架：四层复用框架、第一节的变更影响表（不是官方影响说明）、72 种组合（3 × 2 × 4 × 3）、第二次迁移的工作量分解、部署者的两阶段判断，以及对两类读者的判断。
- 厂商的组件测试和 MegaMoE 基准，只在各自的范围内提供公开验证的起点。框架级组合的公开验收报告，本文没有穷尽检索，也没有见到完整的清单。
本文没有做硬件实测，也不包含市场或商业预测。本文是「DeepSeek 昇腾开源系列」的第七篇，也是最后一篇。