理解 DeepSeek，最容易停在模型卡这一层。更能长期反映 AI-China 的信号，已经下沉到下一层：DeepSeek 正在公开部分运行时底座，而这些底座让它的大型 MoE 与稀疏注意力模型具备实际部署条件。FlashMLA、DeepEP 和 DeepGEMM 不是面向消费者的产品。它们是内核级产物，指向注意力、专家路由和低精度矩阵乘法这些位置；在那里，一个模型究竟只是令人印象深刻，还是能够真正上线运行，会被直接决定。

因此，这更像是一篇堆栈与供应链更新，而不是另一则基准测试札记。中国 AI 竞争通常按模型名称讲述：Qwen、DeepSeek、GLM、Kimi、Hunyuan、ERNIE、InternLM。可生产采用越来越取决于这些名称之下的隐藏层。稀疏注意力模型需要专门的注意力内核。混合专家模型需要通信路径，把 tokens 送往专家，同时避免整块 GPU 被浪费在等待与搬运上。FP8 占比很高的服务栈，需要矩阵内核承受不寻常的形状、分组布局、预热行为和硬件约束。DeepSeek 给出的有效信号，是把这些部分作为可复用基础设施暴露出来，而不是留在一次训练运行的封闭内部。

注意力层正在成为产品边界

FlashMLA 是最清晰的入口，因为它直接点名了注意力问题。DeepSeek 将其描述为一组优化注意力内核库，用于支撑 DeepSeek-V3 和 DeepSeek-V3.2-Exp，并为 prefill 与 decoding 提供稀疏和稠密实现。[3] 稀疏一侧尤其重要，因为 V3.2-Exp 引入了 DeepSeek Sparse Attention，这是一种面向长上下文效率的做法，核心在于选择更少的 token 交互，而不是每次都支付完整稠密注意力的成本。[4]

性能数字需要谨慎阅读。FlashMLA 仓库报告了 H800 SXM5 上的一些结果，例如在内存受限配置下，稠密 MLA decoding 最高可达 3000 GB/s；在计算受限配置下，最高可达 660 TFLOPS；在其声明的 CUDA 配置下，使用 FP8 KV cache 的 token 级稀疏 MLA decoding 可达 410 TFLOPS。[3] 这些是第一方内核主张，并非通用部署保证。不过，战略重点并不依赖每个数字都能原样迁移。足够重要的是，DeepSeek 正在把注意力行为当作内核分发问题处理。

这对 AI-China 是一个实质变化。若一个模型的优势依赖某种注意力变体，而该变体只在私有栈里运转，外部团队就更难验证、服务或改造这个模型。相关内核一旦公开，采用问题随之改变。工程团队可以检查假设、测试硬件边界、对照自己的服务路径，并判断模型的效率主张在 DeepSeek 自有环境之外是否仍然成立。

专家并行是 MoE 进入运行状态的位置

DeepEP 面向一个光环较少但同样重要的 MoE 问题：把 tokens 送到专家，再合并输出，同时避免通信消耗过多时间或占用过多流式多处理器资源。仓库把 DeepEP 介绍为一套用于机器学习训练和推理的高性能通信库，重点放在专家并行上，包含用于 MoE dispatch 与 combine 的 all-to-all GPU 内核，并支持包括 FP8 在内的低精度格式。[2]

V2 笔记更值得看。DeepEP 称，这次重构转向更轻量的 NCCL Gin 后端，把高吞吐和低延迟 API 统一到 ElasticBuffer 接口下，支持最高 EP2048 的 scale-up 与 scale-out 域，并在保持等效或更好性能的同时，把 V3 类 legacy training 的 SM 使用量从 24 降到 4-6。[2] 这同样是第一方表述。但主张的形状才是重点：DeepSeek 试图让专家并行从定制训练技巧，走向带有命名 API、buffer 和资源取舍的库边界。

这一点重要，是因为 MoE 模型容易被欣赏，却很难被运行。标题里的参数量会遮住路由成本。DeepSeek-V3 技术报告描述的模型总参数为 671B、每个 token 激活 37B；只有当 active experts 能被高效且可预期地抵达时，这样的模型才具备经济意义。[5] DeepEP 就是试图让这种路由行为变得可读的供应链组件。

DeepGEMM 在矩阵内核层补上闭环

DeepGEMM 位于算术核心。DeepSeek 将其描述为一套面向现代 LLM primitives 的统一 tensor-core 内核库，覆盖 FP8、FP4 和 BF16 GEMMs、带通信重叠的 fused MoE、MQA scoring，以及运行时 JIT 编译，因此安装时不需要 CUDA 构建步骤。[1] 它的硬件边界也写得很明确：SM90 或 SM100 NVIDIA 架构、CUDA 版本要求、PyTorch 要求，以及 FP8 scaling factors 的布局规则。[1]

关键细节在于 DeepGEMM 如何向上连接。它的 README 表示，masked grouped GEMM 可以消耗来自 DeepEP 低延迟内核的输出；vLLM 的 DeepSeek-V3.2-Exp recipe 则称 DeepGEMM 用在两个位置：MoE 与 MQA logits computation。[1][4] 这就是缩小版的堆栈故事。DeepEP 在专家之间移动 tokens。DeepGEMM 处理由专家决策塑造出来的矩阵计算。FlashMLA 处理注意力路径。同时，vLLM 暴露了面向生产的现实：在受支持的 Hopper 或 Blackwell 数据中心 GPU 上服务 V3.2-Exp，需要具体的安装与运行时选择，单独下载模型还不够。[4]

需要观察的事项，并不是 DeepGEMM 能否在每一种工作负载里胜过所有调优库。它做不到。真正需要观察的是，更多中国模型发布是否会带着这类内核级透明度一起出现。若 Qwen、DeepSeek、GLM、Kimi、Hunyuan 以及相邻模型家族继续走向长上下文、MoE 路由、稀疏注意力、多模态输入和低精度服务，公共产物集合就必须超过权重和基准表。它必须包含运行路径。

这为什么改变 AI-China 的读法

DeepSeek 的内核发布，让中国开放模型策略更难被概括成“便宜的模型权重”。真正输出的是把效率拆解为可检查部件的方式。FlashMLA 说明，注意力效率是内核问题。DeepEP 说明，专家并行是通信问题。DeepGEMM 说明，低精度算术是形状与布局问题。随后，vLLM 的 DeepSeek recipe 展示这些部件进入更广的服务体系，而不是只留在 DeepSeek 自有代码库内。[1][2][3][4]

这个论点有边界。这些产物仍然很专门。它们依赖现代 NVIDIA 数据中心 GPU、底层 CUDA 假设和模型特定设计选择。它们不会自动解决国产加速器可移植性、企业可观测性、成本核算，或混合工作负载下的可靠性。团队应把已发布性能主张视为工作负载特定结果，直到在自己的服务包络内完成复现。

但方向已经清楚。前沿模型不再是唯一值得观察的对象。在 AI-China 里，更强的信号来自让前沿模型可用的堆栈：内核、通信库、服务 recipe、模型卡、量化路径、评测 harness，以及硬件特定运行时支持。DeepSeek 的内核层重要，是因为它把效率从私有主张变成其他工程师可以测试的产物。

Sources

  1. deepseek-ai, DeepGEMM GitHub repository - official README covering FP8/FP4/BF16 GEMMs, JIT compilation, Mega MoE, hardware requirements, grouped GEMM layouts, and MIT license.
  2. deepseek-ai, DeepEP GitHub repository - official README covering expert-parallel communication, MoE dispatch/combine, JIT compilation, V2 refactor notes, EP2048 scale note, and SM-resource claims.
  3. deepseek-ai, FlashMLA GitHub repository - official README covering sparse and dense MLA kernels, DeepSeek-V3 / V3.2-Exp linkage, and stated H800 / B200 kernel performance figures.
  4. vLLM Recipes, "DeepSeek-V3.2-Exp Usage Guide" - deployment recipe noting sparse-attention model behavior, DeepGEMM usage in MoE and MQA logits computation, supported GPU class, and serving examples.
  5. DeepSeek-AI et al., "DeepSeek-V3 Technical Report" - arXiv paper describing the 671B-total / 37B-activated MoE model, MLA and DeepSeekMoE architecture choices, training-token scale, and H800 GPU-hour claim.
  6. Wikimedia Commons, "File:Datacenter Server Racks (22370909788).jpg" - Carl Lender's real 2015 data-center photograph, transferred from Flickr and reviewed as CC BY 2.0.