DeepSeek-V4：公开事实、长上下文架构与真实部署代价

1. 先给结论：哪些已经证实，哪些没有

这条边界很重要。模型卡能证明 checkpoint 的架构和接口，vLLM 代码能证明某种实现路径，API 定价页能证明在线产品当前暴露的模型名；三者都不能单独证明未披露的训练基础设施或下一版本计划。

2. 必要前置：为什么推理要同时算权重和 KV 两本账

decoder-only Transformer 的一次请求分成 prefill 和 decode。Prefill 并行处理整段 prompt，为每一层建立历史 token 的 key/value 状态；decode 每次只产生少量新 token，却需要读取已有历史。权重是相对静态的，KV cache 会随着序列长度和并发请求动态增长。

MoE 又引入第三本账：总参数决定要存放多少权重，激活参数决定一个 token 实际经过多少 expert 计算。一个 1.6T 总参数、49B active 的模型，并不意味着只需装入 49B 权重；未被当前 token 选中的专家仍要在某处可访问。

3. DeepSeek-V4 要解决的核心问题

把上下文从几十万扩大到一百万，不能只修改 RoPE scaling。即使已有 MLA，把每个 token 的状态保留一百万份，单请求 KV 仍可能占用数十 GiB；即使 cache 放得下，每个 decode token 扫描全部历史也会产生巨大读带宽和 attention 计算。

V4 同时组合了共享 K/V、跨 token 压缩、top-k 稀疏选择和短窗口局部注意力。runtime 必须管理由此产生的异构状态，只说“稀疏注意力”会漏掉大部分实现负担。

4. 官方已公开的两个模型

vLLM 的文章把 Flash 四舍五入写成 285B；模型报告和官方模型卡写 284B。本页以官方报告为准。官方还披露两者预训练超过 32T token。post-training 采用两阶段思路：先通过 SFT 与 GRPO 分别培养领域专家，再通过 on-policy distillation 把能力整合进统一模型。

官方提供 non-think、Think High、Think Max 三种推理强度。它们是推理预算和接口行为，不是三个不同的基础架构。Pro-Max、Flash-Max 是最大推理预算下的运行模式，也不应被误写成额外开放的基础 checkpoint。

5. 从输入到输出：V4 的完整数据流

技术报告把总体设计称为 CSA 与 HCA 的混合注意力；vLLM 实现说明用 c4a 和 c128a 描述两类压缩路径。为了不把实现命名擅自等同于论文中每个抽象模块，本页引用各来源自己的名称：可以确认它们共同承担“较细粒度稀疏检索”和“极高比例历史压缩”，但具体层级定义应以技术报告和模型配置为准。

6. 第一步：共享 key 和 value 为什么能省内存

常规 attention 为每个历史位置保存 K 和 V 两组向量。V4 的设计让 key/value 共享表示，直接减少一组缓存。但 RoPE 通常只作用于 key，不作用于 value；把旋转后的 key 同时当作 value，会把绝对位置旋转带进输出。

vLLM 文档因此引入 inverse RoPE。它的作用是在共享 K/V 后保留平移不变的相对位置语义，并非简单扩大窗口。

7. 第二步：c4a、c128a 与局部窗口怎样协作

c4a 用重叠的 8-token 聚合、stride 4 生成压缩条目，因此一百万原生位置约变成 25 万压缩位置。仅压缩到四分之一仍很长，所以再由 DSA 风格 indexer 选择 top-k；vLLM 公布的默认 k 为 512。

c128a 每 128 个 token 生成一个压缩条目。一百万 token 最多约 8192 个条目，默认 k 也是 8192，因此实现上可以统一成稀疏接口，实际却覆盖了全部压缩历史。省下来的成本来自把每 128 个 token 压成一个状态，而非少看一部分历史。

压缩存在完成边界：位置 100 的 query 不能读取包含 0–127 的第一个 c128a 条目，否则会看到未来 token 101–127。128-token short sliding window 为尚未形成完整压缩块的当前位置提供未压缩局部历史，也保留细粒度邻近信息。

8. mHC、Muon 与 post-training：公开到什么程度

V4 报告明确列出 Manifold-Constrained Hyper-Connections（mHC），用于增强传统 residual connection 的信息混合和信号传播稳定性。可以把普通 residual 写成 x_next = x + F(x)；hyper-connection 维护多路表示并学习它们之间的混合，而 manifold constraint 限制混合映射，使深层传播更稳定。

但这一概念描述不等于可以凭空写出 V4 的全部 mHC 超参数。本页不声称每层分支数、约束求解细节或训练 schedule，读者应在官方 PDF 的 mHC 章节核对具体矩阵定义。

Muon 是官方确认的 optimizer，目标是更快收敛与更稳训练；报告同时确认预训练数据量超过 32T token。公开资料没有给出足以独立复现训练的完整数据混合、清洗规则、学习率曲线、集群规模和 wall-clock，因此“可下载权重”不等于“可从零复刻训练”。

9. MoE、低精度与多卡并行如何连起来

V4 的 post-trained 权重把 MoE experts 放在 FP4，而大部分其他参数采用 FP8。这样做的直接系统含义是：专家权重体积下降，但 router、shared modules、attention、norm 以及量化尺度仍要由 runtime 单独处理；不能把整个模型简单视为均匀 4-bit 文件。

一次 token 只激活 49B 或 13B 参数，主要降低计算；全部 experts 仍需分布在 GPU 组里。expert parallel 让不同 rank 持有不同 experts，router 决定 token 发往哪里，随后发生 all-to-all/dispatch/combine。数据并行 rank 也可以与 expert parallel 复用，但通信拓扑和负载均衡会决定实际吞吐。

10. vLLM 如何管理五种不同状态

不同层可能使用 c4a、c128a 或纯 SWA，并额外保留 indexer 与 compressor residual。若每一种状态都建立独立 page pool，会产生碎片，并让 prefix cache、CUDA graph 和 PD transfer 各自维护一套边界。

vLLM 选择统一的 256 个原生 token 逻辑块：c4a 一个逻辑块物理保存 64 个压缩条目，c128a 保存 2 个。scheduler、prefix hit 和 slot mapping 都按相同的 256 原生位置计算。8-token 或 128-token 的未完成 compressor 状态则复用 sliding-window KV abstraction。

再通过调整 block size、compression ratio 和 entry size，把五类 cache 映射进三个 page-size bucket。这样 allocation 是 bucket lookup，不需要运行时重分区；prefix caching 和 PD transfer 也能沿用统一 block 语义。

11. KV cache 数字是怎样算出来的

vLLM 给出一个 61 层、1,048,576 token、BF16 cache 的对照算例。V3.2 风格每 token 每层包含 1152 bytes MLA state 和 256 bytes indexer state，共 1408 bytes，61 层约 83.9 GiB。

9.62 GiB 是 BF16 结构估算，不是整台服务的总显存。实际还要加模型权重、CUDA workspace、activation、router buffer、communication buffer 和并发请求。vLLM 在 indexer 使用 FP4、attention cache 使用 FP8 后，声称相对该 BF16 估算还能大致再减半。

12. kernel fusion 和 multi-stream 为什么仍然重要

算法减少了 FLOPs 和 cache，不代表 GPU 自动变快。压缩、RoPE、norm、量化、cache insert 都是小算子；逐个 launch 会受 kernel-launch 和中间读写开销限制。vLLM 把 compressor + RoPE + cache write，以及 Q norm + KV RoPE + K insert 等路径融合，报告相对朴素未融合 kernel 提升 10–20×。

在 c4a layer 中，indexer pipeline、main-KV compression 和 local-window insertion 具有部分独立性，可放到不同 CUDA stream 重叠。vLLM 在低 batch 下观察到 5–6% 端到端延迟下降。这个数字是特定实现结果，不应被改写成“DeepSeek-V4 普遍快 6%”。

13. 一个 1M 代码 Agent 请求的工作例子

1. 用户提交大型仓库、构建日志和历史工具轨迹。tokenizer 得到数十万到近百万 token。
2. prefill worker 分块执行 attention 和 MoE；最近 128 token 进入 local path，较旧历史逐步形成 c4a/c128a compressed entries。
3. c4a indexer 为每次 query 选取相关压缩位置；c128a 提供高度汇总的全局历史。二者都不能替代局部窗口。
4. 若采用 PD 分离，prefill 完成后传送主 KV、indexer cache 和边界状态。统一 block 语义避免额外的 side-buffer 协议。
5. decode 每步路由到少量 experts。若启用 MTP，可先草拟多个 token，再由目标模型验证。
6. 工具调用暂停生成后，session 的 prefix/KV 仍可能被缓存；下一轮追加工具结果，再从命中边界继续 prefill。

这解释了为什么“1M 模型”同时是模型架构、GPU kernel、cache allocator、scheduler、专家通信和网络传输问题。

14. 官方性能数字应该怎样阅读

架构层最可比较的官方数字是：在 1M context 下，Pro 相对 V3.2 只需 27% 单 token inference FLOPs 和 10% KV cache。模型报告还公布大量知识、代码、推理和 Agent benchmark，但这些是模型方自报结果，且不同闭源模型可能使用不同 harness、推理预算和工具环境。

leaderboard 无法直接证明模型在具体业务中“绝对更强”。V4 的公开 checkpoint、模型配置和 vLLM 实现足以核对结构；业务效果仍需在相同 prompt、输出预算、工具与 SLO 下重跑。

15. 部署：官方可执行路径与资源含义

vLLM 给出的单节点原型示例：Pro 运行在 8×B200 或 8×B300，Flash 运行在 4×B200 或 4×B300，并启用 FP8 KV、256 block、expert parallel、FP4 indexer cache、V4 tokenizer/tool/reasoning parser。它们是推荐测试配置，不是“最低卡数”的数学证明。

Pro 核心参数示意：
--kv-cache-dtype fp8
--block-size 256
--enable-expert-parallel
--data-parallel-size 8
--attention_config.use_fp4_indexer_cache=True

Flash 的示例把 data-parallel-size 调为 4。

上线前还需决定：是否 PD 分离、expert placement、最大并发、可接受的 prefix-cache 占用、MTP、故障恢复和网络带宽。当前 vLLM 说明主要面向 NVIDIA Hopper/Blackwell；Ascend 和 MLU 由各自插件实现支持。

16. 局限与尚未公开的部分

• 这是 Preview。模型行为、接口、kernel 和部署 recipe 仍可能变化。
• 1M context 是容量上限，不自动意味着一百万 token 上的稳定检索、无遗忘或工具轨迹正确性。
• 压缩历史会改变信息保真方式。短窗口、稀疏检索和高压缩全局状态各有盲点。
• 官方没有公开足够数据让外部从零复现 32T+ 预训练及完整 post-training。
• 8×B200/4×B200 是 vLLM 示例，不代表其他硬件或更大集群的最优拓扑。
• vLLM 当时仍把 DeepGEMM MegaMoE 和 paged prefill kernel 列为 planned work；现状应以具体 commit 和 release 重新核对。

17. 最小复现与验证清单

1. 固定官方模型 repo、revision SHA、tokenizer revision 和推理引擎版本。
2. 先用短 context 做 logits/生成一致性 smoke test，再逐级测试 32K、128K、256K 和 1M。
3. 记录静态权重显存、每请求 KV、并发数、TTFT、TPOT、吞吐和 expert-load 分布。
4. 分别关闭/开启 FP4 indexer、FP8 KV、MTP、CUDA graph，避免把多项优化归因给一个开关。
5. 验证 prefix hit 后的输出，与无 prefix cache 的同请求比较；PD 分离时额外测试 abort、超时和重试。
6. 长上下文质量必须使用可定位证据的任务，不只做“needle 找到了”这一项。

18. 一手来源