系列说明：这是 DeepSeek V4 深度解析系列的第三篇。前两篇我们讲了"是什么"和"为什么能做到"——百万上下文、CSA/HCA 的压缩原理、KV Cache 降到 10%。这一篇，我们走进工程师的世界，看看把这一切真正跑起来，需要打哪些仗。
⚔️ 序章：理论和现实之间，有一条战壕
1944年，盟军的诺曼底登陆计划，在沙盘上演练了无数次。
每一个登陆点，每一条进攻路线，每一个时间节点，都精确到分钟。
但当第一批士兵踏上奥马哈海滩的那一刻，所有的计划都开始崩溃。
沙盘上的"海滩"，变成了真实的泥沙、铁丝网和炮火。
理论和现实之间，永远有一条战壕。
DeepSeek V4 的架构设计，在理论上已经足够优雅——CSA+HCA+DSA，KV Cache 降到 10%，计算量降到 27%。
但当这套架构真正要在数百张 GPU 上跑起来，要同时服务成千上万个用户，要在毫秒级别响应百万 token 的请求时——
理论的优雅，遇上了工程的残酷。
这一篇，我们讲的不是算法，而是战争。
🗺️ 一、战场地图：你的一次请求，经历了什么？
在讲具体的工程挑战之前，先建立一张战场地图。
当你向 DeepSeek V4 发送一个包含100万 token 的请求时，这个请求经历了什么？
第一阶段：Prefill（预填充）
模型读取你输入的所有 token，理解上下文，计算出每个 token 的 KV Cache。
这个阶段的特点：计算密集，一次性完成。
100万 token 的 Prefill，需要处理100万个 token 的注意力计算。
即使有 CSA+HCA+DSA 的加持，这仍然是一个巨大的计算任务。
第二阶段：Decode（解码）
模型开始逐个生成输出 token。
每生成一个新 token，都需要回头看一遍所有历史 token 的 KV Cache。
这个阶段的特点：内存密集，逐步进行。
每一步都要读取那份庞大的 KV Cache，然后生成一个 token，然后再读，再生成……
💡 技术深扒：Prefill 和 Decode 的本质区别
想象你在做一道数学题。
Prefill = 读题：把题目的所有条件都读一遍，理解题意，在脑子里建立模型。
Decode = 解题：一步一步写出解题过程，每写一步都要回头看一下题目条件。
读题（Prefill）是一次性的，但很耗脑力。解题（Decode）是逐步的，每一步都不太耗脑力，但需要频繁翻看题目。
对于 GPU 来说：
- Prefill 是"计算瓶颈"——GPU 的算力被充分利用
- Decode 是"内存瓶颈"——GPU 的显存带宽成为限制因素
这两种瓶颈，需要完全不同的优化策略。这就是为什么 V4 必须把 Prefill 和 Decode 物理分离。
⚙️ 二、第一场战役：Prefill/Decode 分离
为什么必须分离？
如果 Prefill 和 Decode 在同一批 GPU 上运行，会发生什么？
在 Prefill 阶段，GPU 在全力计算，算力利用率接近 100%。
但在 Decode 阶段，GPU 大部分时间在等待显存读取，算力利用率可能只有 10-20%。
这意味着：如果混合运行，GPU 在 Decode 阶段有 80-90% 的算力在空转。
这是一种极大的浪费。
更糟糕的是，当一个用户在 Decode 阶段占用 GPU 时，另一个用户的 Prefill 请求就必须排队等待。
对于百万上下文的场景，一次 Prefill 可能需要几十秒。
如果所有请求都在同一个队列里，系统的吞吐量会急剧下降。
💡 技术深扒：Prefill/Decode 分离的工程实现
分离之后，系统变成了两个独立的集群：
Prefill 集群：专门负责"读题"
- 配置：算力强、显存相对小
- 优化目标：最大化 GPU 算力利用率
- 特点：接到请求后全力计算，完成后把 KV Cache 传给 Decode 集群
Decode 集群：专门负责"解题"
- 配置：显存大、显存带宽高
- 优化目标：最大化显存带宽利用率
- 特点：接收 KV Cache，逐步生成 token
两个集群之间，需要一个高速的 KV Cache 传输通道。这个传输通道的带宽，直接决定了系统的整体延迟。对于100万 token 的 KV Cache（即使压缩到 10%，仍然有数 GB），传输本身就是一个挑战。
Prefill/Decode 分离，解决了 GPU 利用率的问题。
但它带来了一个新问题：
那份庞大的 KV Cache，要住在哪里？
💾 三、第二场战役：KV Cache 的显存战争
这是整个工程战争中最残酷的一场。
先来算一笔账。
💡 技术深扒：100万 token 的 KV Cache 有多大？
我们来做一个粗略的估算（以 V4-Pro 为例）：
标准 Transformer 的 KV Cache 大小：
假设：模型层数约 60 层，每个 KV 向量维度约 7168，数据精度 FP16（每个数字 2 字节），上下文长度 100万 token
KV Cache = 100万 × 60层 × 2（K+V）× 7168维 × 2字节
≈ 1.72 TB
一张 H100 GPU 的显存是 80 GB。
1.72 TB ÷ 80 GB ≈ 22 张 H100。光是存 KV Cache，就需要 22 张 H100。
V4 压缩到 10% 之后：
1.72 TB × 10% ≈ 172 GB，172 GB ÷ 80 GB ≈ 3 张 H100
从 22 张降到 3 张。按 H100 市价约 30 万元/张，每个推理节点节省约 570 万元的硬件成本。这就是 KV Cache 压缩的真实工程价值——不是一个百分比数字，而是少买 19 张 H100。
但即使压缩到 172 GB，这仍然是一个巨大的数字。
而且，这只是一个用户的 KV Cache。
如果同时有 100 个用户在进行百万上下文的对话，KV Cache 的总量就是 17.2 TB。
这些数据，必须实时存储、实时读取、实时更新。
这就是显存战争的核心矛盾：
KV Cache 太大，放不进显存；
但如果放到内存或硬盘，读取速度又太慢，会严重影响生成速度。
V4 的解决方案，是一套精密的 KV Cache 分层调度系统。
💡 技术深扒：KV Cache 分层调度
类比计算机的存储层次结构：
| 存储层级 | 速度 | 容量 | 对应 KV Cache 策略 |
|---|---|---|---|
| GPU 显存（L1） | 极快 | 小（80GB/卡） | 当前活跃的 KV Cache |
| CPU 内存（L2） | 快 | 中（数百GB） | 近期不活跃的 KV Cache |
| NVMe SSD（L3） | 较慢 | 大（数TB） | 长期不活跃的 KV Cache |
这套系统的难点在于：预测哪些 KV Cache 即将被需要，提前把它们从低层级搬到高层级。预测错了，就会出现"缓存缺失"——GPU 需要等待数据从内存或 SSD 加载，生成速度急剧下降。
显存战争，打的是调度的精度。
但还有另一场战争，打的是网络的速度。
🌐 四、第三场战役：384 个专家的路由战争
V4-Pro 有 1.6 万亿参数。
这些参数，分布在 384 个专家（Expert）上，每一层都有 384 个专家，每次推理只激活 6 个。
问题来了：
1.6 万亿参数，放不进一张 GPU，甚至放不进一台服务器。
它必须分布在数十台、甚至数百台服务器上。
这就是分布式推理的挑战。
💡 技术深扒：V4-Pro 需要多少张 GPU？
粗略估算：V4-Pro 总参数 1.6 万亿（1600B），每个参数用 FP8 精度存储（1 字节）：
模型大小 = 1600B × 1字节 = 1600 GB = 1.56 TB
所需 GPU 数量 = 1600 GB ÷ 60 GB ≈ 27 张 H100
实际部署中，考虑到冗余和效率，通常需要 32-64 张 H100 来运行一个 V4-Pro 实例。这意味着：每次推理，都需要 32-64 张 GPU 协同工作。每一个 token 的生成，都是一次跨越数十张 GPU 的分布式计算。
分布式推理的核心挑战，是 MoE 路由。
每个 token 进来，系统需要决定：把这个 token 交给哪 6 个专家处理？
这个决策，必须在毫秒级别完成。
而且，这 6 个专家可能分布在不同的 GPU 上，甚至不同的服务器上。
决策完成后，token 的数据需要通过网络传输到对应的 GPU，计算完成后再传回来。
这个过程，叫做"All-to-All 通信"。
它是分布式 MoE 推理中最大的性能瓶颈。
💡 技术深扒：All-to-All 通信的代价
想象一个有 32 台服务器的集群，每台服务器上有 8 张 GPU。
一个 token 进来，需要找到它的 6 个专家。这 6 个专家可能分布在 6 台不同的服务器上。
于是：
- token 数据从当前服务器，通过网络发送到 6 台服务器
- 6 台服务器各自计算
- 计算结果通过网络发回当前服务器
- 合并结果，生成输出
这个过程，每生成一个 token 都要重复一次。网络通信的开销可能占到总推理时间的 20-30%。
这就是为什么 DeepSeek 在 V4 中专门优化了专家路由策略——减少跨服务器的通信，尽量让同一个 token 的专家集中在同一台服务器上。
路由战争，打的是通信的效率。
但还有一场战争，是关于硬件本身的。
🔧 五、第四场战役：昇腾 950 的登场
V4-Pro 目前处于预览期，产能受限。
官方的说法是： "Pro 版限高端算力产能，预计下半年昇腾 950 批量上市后价格会大幅下调。"
这句话背后，有一个很多人没有注意到的信息：
V4-Pro 的推理，将主要依赖昇腾 950，而不是英伟达 H100。
这是一个重大的战略选择。
💡 技术深扒：为什么选择昇腾 950？
背景：2023年以来，美国对中国的 AI 芯片出口管制持续升级。H100、H800、A100……一批又一批的高端 GPU，被列入出口限制名单。
对于 DeepSeek 这样的中国 AI 公司，这意味着无法大量采购最新的英伟达 GPU，现有的 GPU 库存有限，必须极度高效地使用。
这也是为什么 DeepSeek 在算法层面如此极致地追求效率——不是因为他们不想买更多 GPU，而是因为他们买不到。
昇腾 950 与 H100 对比：
| 指标 | 昇腾 950 | H100 |
|---|---|---|
| 算力（FP16） | 约 900 TFLOPS | 约 989 TFLOPS |
| 显存 | 96 GB HBM3 | 80 GB HBM3 |
| 出口管制 | 不受限制 | 受限 |
昇腾 950 的算力和显存，已经接近 H100 的水平。更重要的是：昇腾 950 不受出口管制，可以大量采购。
昇腾 950 批量上市，对 V4-Pro 的意义是：
从"算力受限"到"算力充裕"。
当算力充裕时，V4-Pro 可以扩大推理集群规模，支持更多并发用户；降低 API 价格（官方已明确预告）；提供更低的首 token 延迟。
这场战役，不是技术战，而是供应链战。
它的结果，将直接决定 V4-Pro 能否真正大规模商用。
⏱️ 六、战场上的时钟：延迟是怎么炼成的？
所有的工程优化，最终都要落到一个数字上：
延迟。
用户发出请求，到收到第一个 token，这段时间叫做 TTFT（Time To First Token，首 token 延迟） 。
对于百万上下文的场景，TTFT 是最关键的用户体验指标。
💡 技术深扒：百万上下文的延迟拆解
一次百万 token 请求的延迟，由以下几部分组成：
| 阶段 | 耗时来源 | 优化手段 |
|---|---|---|
| 网络传输（输入） | 100万 token ≈ 约 4MB，约 0.1s | 压缩传输 |
| Prefill 计算 | 最大头，取决于算力 | CSA+HCA+DSA 降低计算量 |
| KV Cache 传输 | Prefill → Decode 集群，约 0.1-0.5s | 高速互联 |
| Decode 首步 | 读取 KV Cache，生成第一个 token | KV Cache 分层调度 |
V4-Pro 的实际 TTFT（估算）：
- V3.2 的 TTFT：约 2-5 秒（10万 token 输入）
- V4-Pro 的 TTFT：约 20-60 秒（100万 token 输入）
这个延迟，对于实时对话是不可接受的。但对于分析整个代码库、处理一本书这类任务，等待 30 秒换来深度理解，是完全值得的。
延迟的问题，揭示了一个重要的产品设计原则：
百万上下文，不是为了"更快的对话"，而是为了"更大的任务"。
它的目标用户，不是在聊天框里打字的普通用户，而是需要处理海量文档、分析整个代码库、理解超长报告的专业用户。
🏗️ 七、战争的全貌：一张系统架构图
现在，我们可以把所有的战役串起来，画出 V4 推理系统的全貌。
💡 技术深扒：V4 推理系统架构
用户请求（100万 token）
↓
┌─────────────────────────────────────┐
│ 负载均衡层 │
│ （路由请求到合适的 Prefill 集群） │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Prefill 集群（计算密集） │
│ - 多台服务器，每台 8×H100/昇腾950 │
│ - 运行 CSA+HCA+DSA 注意力计算 │
│ - 输出：压缩后的 KV Cache（~172GB）│
└─────────────────────────────────────┘
↓ 高速传输（InfiniBand/HCCL）
┌─────────────────────────────────────┐
│ Decode 集群（内存密集） │
│ - 多台服务器，大显存配置 │
│ - KV Cache 分层调度（显存/内存/SSD）│
│ - MoE 路由（384专家，激活6个） │
│ - All-to-All 通信优化 │
└─────────────────────────────────────┘
↓
逐步输出 token（流式返回给用户）
这套系统的每一个环节，都是一场独立的工程战役。任何一个环节出现瓶颈，整个系统的性能都会受到影响。
🌊 八、战争的代价：为什么 Pro 版产能受限？
现在，我们可以回答一个很多人都在问的问题：
V4-Pro 为什么产能受限？
答案，就藏在上面这张架构图里。
运行一个 V4-Pro 推理实例，需要：
- Prefill 集群：约 32-64 张高端 GPU
- Decode 集群：约 32-64 张高端 GPU，且需要大显存
- 高速互联网络：InfiniBand 或等效方案
- KV Cache 存储：数 TB 的高速存储
这意味着，每增加一个 V4-Pro 推理实例，就需要投入约 64-128 张高端 GPU。
按 H100 的市价，这是约 2000-4000 万元的硬件投入。
而且，这些 GPU 还买不到。
出口管制的限制，让 DeepSeek 无法大量采购 H100。
现有的 GPU 库存，必须在训练和推理之间分配。
这就是 V4-Pro 产能受限的真实原因：不是技术问题，而是硬件供应问题。
💡 技术深扒：昇腾 950 上线后会发生什么？
昇腾 950 批量上市后，DeepSeek 可以大量采购国产 GPU，不受出口管制限制。
预期影响：
- 产能方面：推理集群规模可以快速扩大，支持更多并发用户
- 价格方面：官方已明确预告"价格会大幅下调"，目前 V4-Pro 输出价格 24元/百万token，预期可能降至 8-12元
- 延迟方面：更多的推理节点，意味着更短的排队等待时间
- 稳定性方面：产能充裕后，Pro 版可以正式进入生产环境推荐列表
这场供应链战争的结果，将在 2026 年下半年揭晓。
🎯 九、工程战争的启示：效率是被逼出来的
讲到这里，我想说一个更深的东西。
DeepSeek 在工程上的极致追求，不是因为他们天生喜欢折磨自己。
是因为他们没有选择。
算力受限，所以必须把每一个 FLOP 用到极致。
显存受限，所以必须把 KV Cache 压缩到 10%。
GPU 买不到，所以必须在软件层面弥补硬件的差距。
限制，是创新最好的催化剂。
这让我想起了阿波罗13号。
1970年，阿波罗13号在飞往月球途中发生爆炸，宇航员面临生死危机。
地面控制中心的工程师们，用飞船上现有的材料——胶带、塑料袋、纸板——拼凑出了一个 CO₂ 过滤器，把三名宇航员从太空带了回来。
他们没有更好的材料。
所以他们用现有的材料，做出了最好的方案。
DeepSeek 的工程师们，也是这样。
💡 技术深扒：DeepSeek 的"约束驱动创新"
回顾 DeepSeek 的技术演进，几乎每一个重大创新，都来自于某种约束：
| 约束 | 创新 |
|---|---|
| 算力受限 | MLA → CSA/HCA，把计算量降到极致 |
| 显存受限 | KV Cache 压缩，从 100% 降到 10% |
| GPU 买不到 | 适配昇腾，不依赖单一供应商 |
| 训练成本高 | Muon 优化器，提升收敛速度 |
| 网络通信慢 | 专家路由优化，减少 All-to-All 通信 |
每一个约束，都催生了一个创新。当你无法用钱解决问题时，你只能用智慧。
🎬 十、写在最后：战争还没有结束
百万上下文的工程战争，打了很多场。
Prefill/Decode 分离，解决了 GPU 利用率的问题。
KV Cache 分层调度，解决了显存容量的问题。
MoE 路由优化，解决了分布式通信的问题。
昇腾 950 的登场，将解决硬件供应的问题。
但战争还没有结束。
因为还有一个问题，我们还没有回答：
工程跑通了，V4 的 Agent 能力为什么突然变强了？
SWE Verified 80.6%，Terminal Bench 2.0 67.9%，Toolathlon 51.8%……
这些数字，不只是"更大的模型"带来的。
背后有一套专门针对 Agent 场景的优化——工具调用的稳定性、多步规划的一致性、思考模式的深度……
这些，才是 V4 真正让工程师们兴奋的地方。
刘慈欣在《三体》里写过一句话：
"弱小和无知不是生存的障碍，傲慢才是。"
DeepSeek 的工程师们，从来不傲慢。他们知道自己的约束，所以他们在约束里寻找出路。他们知道自己的差距，所以他们用效率弥补规模。
这场工程战争，他们打赢了。
下一场战争，是 Agent 的战争。
那才是真正决定 V4 命运的战场。
