2026 年，中国两个最具技术深度的 AI 团队在同一季度交出了对"Transformer 之后"的不同答卷。
4 月，DeepSeek 发布 V4：1.6T 总参、49B 激活、百万 token，KV Cache 压到上一代 10%。7 月，月之暗面发布 K3：2.8T 总参、104B 激活、百万 token，2.5x 训练效率提升。两个模型都在 Arena 盲测上杀入第一梯队。K3 一度登顶 Frontend Code Arena，DSV4 的 Token 周调用量全球第一。
但它们走向这个位置的技术路径几乎完全不同。
苏剑林在 K3 架构文章里写了一句诚实的话："Linear+Full 路线 vs Sparse 路线，谁能走更远目前不得而知。"这句话背后是一个真实的开放问题：当 Transformer 的原始注意力撑不住百万 token 上下文时，有两条路可以走，但没人知道哪条路的天花板更高。
这两条路各自付出了什么代价？先看 K3。
一、K3：在约束中精打细算
K3 的架构公式：KDA + Gated MLA + Stable LatentMoE + AttnRes。苏剑林对每个选择背后的逻辑做了完整的公开阐述。读完最大感受：K3 的每个组件都是在具体约束下做的取舍，选的是当前条件下最不差的那条路。
注意力：69 层"压缩记忆" + 24 层"原始档案"
百万 token 的上下文，标准 Attention 算不过来。即便用 MLA 压缩 KV，内存仍随序列线性增长。这个约束对所有长上下文模型都一样。
K3 的解法是把 93 层中的 69 层换成 KDA（线性递归注意力）。KDA 不为每个历史 token 保留 KV，而是把所有历史不断"写"进一个固定大小的递归状态矩阵 S。每来一个 token，按"遗忘 → 修正 → 写入"三步更新这个矩阵。序列无论多长，矩阵大小不变。
每层 KDA 的状态矩阵多大？K3 有 96 个注意力头，每头维护一个 d_head × d_head 的矩阵。d_head = 128（K3 技术报告 Table 1，独立超参数）：
96 × 128² × 2 bytes = 3,145,728 bytes ≈ 3.0 MB/层
69 层合计约 207 MB。无论上下文是 1K 还是 1M，这个数字不变。这是 K3 在 69 层上的内存常数。
但线性递归有一个绕不开的代价：信息损失。固定大小的状态像一个只能装这么多东西的抽屉——新东西不断塞进来，旧的就得不断挤出去。80 万 token 之前定义的某个函数名，线性记忆可能已经找不回来了。而精确的内容寻址（"我记得在那个位置见过这个词"）恰恰是代码、长文档检索、Agent 工具调用的刚需。
所以 K3 每 3 层 KDA 后保留 1 层 Gated MLA（近似 3:1 交替，末层强制 MLA 补位）。24 层 MLA 做全局 token-to-token 交互，能精确回查任意历史位置。分工：KDA 是"持续更新的工作记忆"，MLA 是"翻原始档案"。
这个 3:1 比例的智能化代价：模型在 75% 的层上做的是有损压缩，只有 25% 的层能做精确检索。K3 选择用 24 层 MLA 的全局注意力来补偿。而且最后一层必须是 MLA，保证输出前做一次全局汇聚。但对于极细粒度回溯任务（比如在 80 万 token 的代码库里精确定位某个变量定义），24 层 MLA 够不够用？技术报告没有给出不同 KDA:MLA 比例的消融实验。
NoPE 的条件性
K3 的 MLA 层不用 RoPE。这在纯 MLA 模型里行不通：K2 去掉 RoPE 会明显变差。苏剑林解释：KDA 本身隐含了位置信息。DeltaNet 的递归运算不可交换（先做 A 再做 B 跟先做 B 再做 A 结果不同），顺序天然在运算里。加上通道级衰减提供不同时间尺度的近因偏好，KDA 替代了 RoPE 的功能。
这是一个典型的约束驱动选择：不是 NoPE 更好，而是有了 KDA 之后 NoPE 变得可行，省掉了从 256K 扩窗到 1M 时调 RoPE base 或做 NTK 插值的工程麻烦。
硬件适配：让算法长成 GPU 喜欢的形状
苏剑林改 KDA 衰减参数下界的理由很直接：如果单步 retention 接近 0，连乘后倒数在 BF16 下溢出，迫使使用低效的特殊 kernel。设了 g_min = -5 的下界后，每步 retention ≥ e⁻⁵ ≈ 0.0067，单个 16×16 tile 内累计 log-decay 上界为 -80（16 × (-5)），倒数仍在 BF16 范围内。对角 tile 就能用 Tensor Core 的稠密矩阵乘法。
这个下界在理论上不需要，但 BF16 的动态范围和 Tensor Core 的计算偏好逼着算法接受它。苏剑林的原则：算法必须在 GPU 上跑得快才有价值。
Stable LatentMoE：驯服极端稀疏的 MoE
896 个路由专家选 16 个，另加 2 个始终激活的共享专家，总激活率约 2.0%。对比 DSV4 的 256 选 8（3.1%）、Mixtral 的 8 选 2（25%），K3 的稀疏度最极端。
极端稀疏最先暴露的是数值异常。SwiGLU 的门控和 up 两路无界激活相乘，输出方差急剧膨胀。K3 的对策是 SiTU：用 softcap（β=4 限门控 + β=25 限线性）封顶异常值。GPT-OSS 和 DSV4 在这里用 Hard Clip，苏剑林发现在相同界限下 softcap 效果更好——Hard clip 在边界处梯度不连续，softcap 过渡更平滑。
数值稳住了，尺度问题紧接着浮出来。LatentMoE 先降维（7168→3584）做 MoE 再升维（3584→7168），4 矩阵连乘的方差漂移极难控制。消融实验指向一个极简方案：升维之前加一个 RMS Norm。只加这一个，连乘的尺度就稳住了，还意外收获了等效深度的提升。
数值和尺度都安顿好，最后一个对手是路由不均。896 选 16 意味着热门专家会被反复选中，冷门专家白占参数。QB（分位数均衡） 用 1000 bin 直方图近似全局分位数，利用分布可加性以极低通信量跨机器聚合均衡。1000 bin 和 10000 bin 实测没区别——精度不是瓶颈，通信效率才是。
二、DSV4：同一个 MLA，另一个方向
DSV4 也从 MLA 出发，但选择了完全不同的改造路线。它不引入线性注意力，而是把全部层的注意力做压缩。
CSA + HCA：放大镜和望远镜
DSV4 的注意力由两种压缩策略交替工作，每种都有完整的工程实现。
CSA（压缩稀疏注意力） 三件套配合：
- KV Compressor：每 4 个 token 的 KV 通过注意力池化合并成 1 个压缩条目（4:1）。这是有损压缩——4 个 token 的细粒度信息被平均进一个向量，但换来了 4 倍的 KV Cache 节省。
- Lightning Indexer：压缩后条目仍然可能很多（1M 上下文压缩后约 250K 条目），不可能全看。Indexer 用双编码器架构做近似最近邻搜索，为每个 query 筛选 top-k 个最相关的压缩条目。Pro 模型 k=1024，Flash 模型 k=512。
- Sliding Window：维护最近 128 个 token 的未压缩 KV。语言模型对最近上下文高度依赖，压缩后的条目在这里信息损失最大，Sliding Window 保留了局部精度。
HCA（重度压缩注意力） 更激进：128:1 压缩率。128 个 token 浓缩成 1 个条目，粒度极粗。但压缩后条目数量很少（1M 上下文仅约 7,800 条目），query 直接看全部，不需要 Lightning Indexer。同样有 Sliding Window 128 补局部。
两者交替叠加在各层中。CSA 做精确定位（放大镜），HCA 做全局感知（望远镜），让模型在不同距离尺度上看上下文。叠加效果：1M 上下文下 KV Cache 仅 V3.2 的 10%，单 token FLOPs 仅 27%。
残差和路由：mHC 与工程细节
mHC（流形约束超连接） 把残差流从 1 条扩展到 4 条（hc_mult=4）。每层通过矩阵 B 动态混合多条残差流，让信息传递有了多条并行通道。原始 HC（Kimi 团队提出）经常数值不稳定，mHC 加了流形约束把奇异值稳定在 1 附近。每层 attention/mlp 前后各一次 mHC：先把多条流压成一条输入 sublayer，再把输出分发回多条流并动态混合。
对比 K3 的 AttnRes（让每层主动选择从哪个深度读取信息），mHC 是结构性的——所有层都获得额外的信息通道，但不做主动选择。前者更灵活，后者更稳定。
其他工程细节：路由激活函数从 Sigmoid 换成 Sqrt(Softplus(·))（更平滑的梯度）；前几层 dense FFN 换成 Hash routing 的 MoE 层（减少早期层的计算瓶颈）；DualPipe 从 V3 继续使用，针对 mHC 做了调度调整；Muon 优化器替代 AdamW（从 Kimi 那边借鉴，两个团队在优化器上收敛到同一选择）。
智能化角度：两条路各自丢了什么
K3 和 DSV4 的注意力改造，在智能化上付出的是不同形态的代价。实际 benchmark 可以验证这个理论判断：
| 维度 | K3 | DSV4-Pro |
|---|---|---|
| FrontierSWE（软件工程） | 81.2 | ~70 |
| Program Bench | 77.8 | ~72 |
| Arena Frontend Code | #1（1679 分） | #3 |
| 综合能力定位 | 全球第三（仅次于 Fable 5、GPT-5.6 Sol） | 接近 Claude Opus 4.8 |
| 输出价格（API） | ¥100/百万 token | ¥6/百万 token |
| 生成速度 | 较慢（104B 激活） | 较快（49B 激活） |
数据来源：Arena.ai、Artificial Analysis、官方定价（2026-07）。
K3 在需要精确长程回溯的复杂编程任务上领先。FrontierSWE 81.2 分超过 GPT-5.6 Sol 的 71.3，说明 24 层 MLA 在编程场景下足够支撑精确检索。K3 登顶 Frontend Code Arena 更是因为原生多模态能力能做"vision in the loop"——写完代码看截图再修改，这是纯文本的 DSV4 做不到的。
DSV4 在成本敏感的通用场景上更优。全层压缩的精度损失在实际任务中可接受——性能接近 Opus 4.8，编码对标 GPT-5.6 Sol，但输出价格只有 K3 的 1/16。对于不需要极端长程回溯的日常代码助手、Agent 执行、中文任务，DSV4 的"一直半精确"足够好用。
K3 的代价：精确检索的频次降低。 75% 的层做有损压缩记忆，只有 25% 的层能做精确的全局 token-to-token 查询。对于需要频繁回溯远距离上下文的任务（长代码库重构、多文档交叉引用），K3 的 24 层 MLA 是唯一的精确检索通道。够不够用取决于任务的信息密度。如果需要回查的位置分布稀疏，24 层足以覆盖；如果需要同时关注大量分散的细节，可能不够。
DSV4 的代价：注意力的分辨率下降。 所有层都做了压缩，但 CSA 的 4:1 和 HCA 的 128:1 意味着 query token 看到的是被压缩过的近似值，而非原始 KV。CSA 的稀疏选择靠索引器预测，索引器预测不准时会漏掉相关信息。HCA 的 128:1 压缩更激进，远距离的细粒度信息在压缩中被平均掉了。
哪种更好，取决于任务的注意力模式：需要偶尔的精确回溯选 K3，需要持续的半精确全局感知选 DSV4。
后训练提升空间：DSV4 Flash 0731 的启示
DSV4 Flash 0731 提供了一个绝佳的自然实验：同一个底座（284B/13B 激活），架构完全不变，仅重做后训练。结果：
| Agent 基准 | Flash Preview | Flash 0731 正式版 | 提升幅度 |
|---|---|---|---|
| Terminal Bench 2.1 | ~70 | 82.7 | +18% |
| DeepSWE | 7.3 | 54.4 | +645% |
| Toolathlon Verified | 52.8 | 70.3 | +33% |
| Cybergym | 57.7 | 76.7 | +33% |
9 项 Agent 基准全部反超自家大哥 V4-Pro Preview（1.6T/49B，体量大 4 倍）。这是行业"后训练比预训练更重要"论点的最强证据。
从架构看，两个模型的后训练提升空间不对称。
DSV4 的后训练空间更大，原因有三：
-
稀疏压缩注意力的精度损失可以靠后训练弥补。CSA 的 Lightning Indexer 预测不准时会漏掉相关信息，HCA 的 128:1 压缩会平均掉远距离细节。后训练可以优化 Indexer 的路由策略，让它在特定任务上学会更精准的选择。Flash 0731 的 DeepSWE 从 7.3 飙到 54.4，很可能就是后训练让 Indexer 在代码任务上学会了更准的定位。
-
49B 激活的"欠拟合"底座更容易被后训练拉起来。DSV4 Pro 只有 49B 激活，每 token 做的计算少，预训练阶段可能"没学透"。后训练（RL + SFT + 多教师蒸馏）可以在不增加推理成本的前提下，把底座的潜在能力逼出来。K3 的 104B 激活每 token 做更多计算，预训练阶段已经"学得更深"，后训练的边际收益相对小。
-
K3 的核心限制不在后训练能解决的范围内。K3 的瓶颈是 69 层 KDA 的信息损失——线性递归记忆的遗忘是架构固有的。K3 在编程任务上已经很强（FrontierSWE 81.2），说明 24 层 MLA 足够支撑精确检索。但要进一步提升，瓶颈是"MLA 层数不够多"，这是架构问题不是训练问题。
K3 的后训练空间在哪里： K3 技术报告的后训练目标是"训练完整的 Agent 闭环"——三个任务域 × 三档 reasoning effort 分别做 RL，再多教师在线策略蒸馏合并。还有空间的方向是：更好的 Agent 工具调用策略、更好的长程任务规划（K3 技术报告展示过 24 小时连续工作的 GPU 内核优化案例）、vision-in-the-loop 的代码迭代能力。
一个可验证的预测： 如果 DSV4 Pro 正式版也做同等级别的后训练升级，其 Agent 能力提升幅度大概率超过 K3 做同等后训练的幅度。原因：DSV4 的底座更大但激活更小，后训练的"杠杆效应"更强——少量高质量后训练数据就能撬动大参数底座的未开发潜力。K3 的 104B 激活已经把底座"用"得更充分，后训练边际效应递减。
苏剑林的观察：DSV4 没有真正"放弃"MLA
DSV4 看起来换了完全不同的注意力，但苏剑林指出一个被多数人忽略的细节：DSV4 用的是 head_dim=512、K=V 共享的 MQA，这正是 MLA 的 Decoding 等价形态。DSV4 为了保证效果用了 MLA 的等价形态（苏剑林推测），但训练成本暴涨，为此引入了 Sparse 和 Compress 来弥补。
两条路线殊途同归。K3 用线性注意力替换大部分层（Linear+Full 混合），DSV4 用稀疏压缩全部层（Sparse+Compress）。出发点都是 MLA，终点都是"KV Cache 必须大幅压缩"。
三、架构代价的工程兑现
架构分歧到了推理阶段，直接变成一张硬件采购清单。
KV Cache：两条路的分叉点
先看最大的开支项：KV Cache。（以下按 FP8 量化部署、KV Cache 用 BF16 计算。）
K3 的 24 层 MLA： 每 token 每层 KV Cache = 640 维 latent × 2（K/V 双 latent，Gated MLA 区别于标准 MLA 的单 latent 设计）× 2 bytes（BF16）= 2,560 bytes。24 层合计每 token 61.4 KB。1M 上下文单请求：61.4 GB。
加上 69 层 KDA 的固定状态 207 MB，单请求总计约 61.6 GB。KDA 的固定贡献占 0.3%——3/4 的层几乎"免费"，瓶颈完全在 1/4 的 MLA 层。
DSV4 的全部压缩层： V3.2 标准 MLA 每 token 约 122 KB（61 层 × 2,048 bytes/层）。DeepSeek 声称 V4 的 KV Cache 压到 V3.2 的 10%，V4 每 token 约 12.2 KB。1M 上下文单请求：12.2 GB。
K3 单请求的 KV Cache 是 DSV4 的约 5 倍。万并发：K3 约 616 TB，DSV4 约 122 TB。
这个 5 倍差距直接来自架构选择。K3 用减少 MLA 层数（93→24）来省内存，但每层 MLA 的 latent dim 更大（640 vs 512），抵消了一部分减少。DSV4 用全层压缩，等效压缩率更高。
GPU 需求：KV Cache 吃掉一切
4,390 vs 877。这是 K3 与 DSV4 在 H200（141 GB）上满足万级并发所需的 GPU 数量差距。把权重和 KV Cache 拆开看：
K3：权重 2.8 TB（20 卡）+ KV 616 TB（4,369 卡）≈ 4,390 卡
DSV4：权重 1.6 TB（12 卡）+ KV 122 TB（865 卡）≈ 877 卡
权重仅占总需求的 0.5%~1.3%。GPU 差距 5.0 倍（4,390/877），几乎完全由 KV Cache 决定。
部署架构：从模型结构推导并行策略
前面的数字是"裸显存"估算——假设显存可以完美分配。实际部署中，每张卡需要同时装权重和 KV Cache，两者的权衡决定了真实并发能力。以下参考 SGLang 团队在 96 张 H100 上部署 DeepSeek V3 的公开实践（LMSYS 2025-05），从 K3 和 DSV4 的架构参数出发推导并行配置。
硬件基础： HGX H200 服务器，8 × H200 SXM，单卡 HBM3e 141 GB，带宽 4.8 TB/s，节点内 NVLink 4 聚合带宽 900 GB/s，节点间 IB 400 Gb/s。
第一步：选择并行策略
大模型推理有三种并行方式。Tensor Parallel（TP）切分层内权重，但每层需要 all-reduce，受 NVLink 域限制。Data Parallel Attention（DP Attention）让每卡独立处理不同请求子集，KV Cache 不跨卡复制。Expert Parallelism（EP）把 MoE 专家分布到多卡。
怎么选？关键看模型结构。
Attention 层：两个模型都选 DP Attention。 原因：K3 的 24 层 MLA 的 KV Cache 被压缩到 640 维 latent（2,560 bytes/token/层），DSV4 全层 CSA+HCA 压缩到 12.2 KB/token。两者 KV Cache 都很小，DP Attention 的每卡独立复制成本可以接受。相比之下 TP 在 attention 层的收益不大（矩阵不够大），反而增加通信。
MoE 层：两个模型都选 EP。 这是 MoE 扩展到多节点的唯一可行方式。关键问题是 EP 规模。
Dense FFN：都选 DP。 K3 有 1 层 dense FFN，DSV4 有 3 层（V4 把前几层换成了 Hash routing MoE）。TP 在大 intermediate_dim 下碎片化严重，DP 更优。
K3 独有：KDA 层零跨卡同步。 69 层 KDA 使用 DP Attention 时，每卡维护自己的递归状态矩阵。状态更新是纯本地计算，不需要任何跨卡通信。这是 K3 架构在部署上的一个隐藏优势。
第二步：推导 EP 规模
EP 的核心约束：每张卡必须装下分配到的专家权重，还要留出 KV Cache 空间。这需要先算每专家多大。
K3 的 896 路由专家：
K3 总参数 2.78T。减去 attention（约 0.5T）和 embedding（约 0.1T），MoE 部分约 2.2T。896 路由 + 2 共享 = 898 个专家：
每路由专家 ≈ 2.2T / 898 ≈ 2.45T × 1 byte (FP8) = 2.45 GB
逐级试 EP 规模，直到单卡能装下：
| EP 规模 | 节点数 | 专家/卡 | 权重/卡 | H200 剩余 | 可行？ |
|---|---|---|---|---|---|
| 8 | 1 | 112 | 274 GB | 不够 | ❌ |
| 16 | 2 | 56 | 137 GB | 4 GB | ❌（KV Cache 空间不足） |
| 32 | 4 | 28 | 69 GB | 67 GB | ✅ |
K3 的 LatentMoE 降维（7168→3584）在这里起了作用：每 token 发送给 16 个专家的数据是半宽的 3584 维，路由通信量减半。但 896 选 16 的路由在 EP=32 时，每 token 平均要向 16/32 = 50% 的节点发送数据，路由通信密度仍然很高。
K3 最小可行部署：EP=32，4 节点 32 卡。 每卡 69 GB 权重，剩余 67 GB 给 KV Cache。
DSV4-Pro 的 256 路由专家：
每路由专家 ≈ (1.6T - 0.3T) / 256 ≈ 5.1 GB（FP8）
| EP 规模 | 节点数 | 专家/卡 | 权重/卡 | H200 剩余 | 可行？ |
|---|---|---|---|---|---|
| 8 | 1 | 32 | 163 GB | 不够 | ❌ |
| 16 | 2 | 16 | 82 GB | 56 GB | ✅ |
DSV4 可用 EPLB（负载均衡器）将 256 专家扩展到 288（加 32 冗余副本），允许更灵活的分布。这是 DeepSeek 团队的开源方案，已在 SGLang 中实现。
DSV4 最小可行部署：EP=16，2 节点 16 卡。 每卡 82 GB 权重，剩余 56 GB 给 KV Cache。
第三步：PD 分离设计
Prefill（计算密集）和 Decode（带宽密集）的通信模式和 batch 特征完全不同。SGLang 在 DeepSeek V3 上的实践证明，PD 分离可以将 decode 吞吐提升约 5×。
PD 分离的核心机制：P 节点接收请求执行 prefill（大 batch，Normal Dispatch 模式最大化吞吐），完成后 KV Cache 通过 RDMA 传输到 D 节点，D 节点执行 decode（小 batch，Low-Latency Dispatch + CUDA Graph 最小化延迟）。
K3 的 PD 分离有一个独有开销：KDA 递归状态的传输。 标准 Transformer 只需传 KV Cache。K3 还需要传 69 层 KDA 的状态矩阵（207 MB/请求）。但 207 MB 在 IB 400 Gb/s（50 GB/s）链路上约需 4 ms，相对 prefill 阶段数秒到数十秒的时间可以忽略。
KDA 状态在 D 节点上的行为不同于 KV Cache——它是固定大小的，不随序列增长。每个请求在 D 节点上的内存占用：
207 MB（KDA 固定状态）+ 61.4 KB/token × 当前序列长度（MLA 层 KV Cache）
平均上下文 500K token 时：207 MB + 30.7 GB ≈ 30.9 GB/请求。KDA 状态占 0.7%。
DSV4 的 PD 分离更简单： 全部层都是压缩 KV Cache，500K 平均上下文下 6.1 GB/请求，RDMA 传输约 0.12 s。
第四步：D 节点并发能力
D 节点的并发能力决定了万级并发需要多少节点。计算方法：每部署单元可用于 KV Cache 的总显存 ÷ 单请求平均 KV 大小 = 并发请求数。
K3 on H200（EP=32，4 节点/部署单元）：
每卡可用于 KV Cache = 141 - 69（权重）- 5（attention/embedding）= 67 GB
32 卡部署单元 KV Cache 总量 = 67 × 32 = 2,144 GB
单请求平均 KV（500K 上下文）= 30.9 GB
并发请求/单元 = 2,144 / 30.9 = 69 请求
万并发需要 10,000 / 69 = 145 个 D 部署单元 × 4 节点/单元 = 580 个 D 节点
加上 P 节点（经验比 P:D = 1:2.5，参考 SGLang 实践）：580 / 2.5 ≈ 232 P 节点
K3 on H200 总计：~812 节点（6,496 卡）
DSV4 on H200（EP=16，2 节点/部署单元）：
每卡可用于 KV Cache = 141 - 82 - 3 = 56 GB
16 卡部署单元 = 56 × 16 = 896 GB
单请求平均 KV = 6.1 GB
并发/单元 = 896 / 6.1 = 147 请求
万并发 = 10,000 / 147 = 68 个 D 部署单元 × 2 节点/单元 = 136 个 D 节点
P 节点：136 / 2.5 ≈ 54
DSV4 on H200 总计：~190 节点（1,520 卡）
| 部署维度 | K3 on H200 | DSV4 on H200 |
|---|---|---|
| EP 规模 | 32（4 节点/单元） | 16（2 节点/单元） |
| 权重/卡 | 69 GB（28 专家） | 82 GB（16 专家） |
| KV Cache 可用/卡 | 67 GB | 56 GB |
| 并发/D 单元 | 69 请求 | 147 请求 |
| D 节点（万并发） | ~580 | ~136 |
| P 节点（1:2.5） | ~232 | ~54 |
| 总节点 | ~812 | ~190 |
| 总 GPU | ~6,496 | ~1,520 |
| 节点比 | 4.3× | 基准 |
对比之前"裸显存"估算的 5.0×，实际部署的节点比降到 4.3×。原因是 DSV4 的每卡权重更大（82 GB vs K3 的 69 GB），留给 KV Cache 的比例更少，缩小了一部分差距。
第五步：HiCache Offload 修正
上面的推导假设所有并发请求的 KV Cache 同时驻留 GPU 显存。这是上界估算。实际部署中，不是所有请求都在同时 decode。
多级缓存体系。 SGLang 的 HiCache 把 KV Cache 组织成三级（CSDN 实战数据）：
- L1（GPU 显存）：当前正在 decode 的请求的 KV Cache
- L2（CPU pinned memory）：近期用过、暂时不在 decode 的请求 KV
- L3（SSD/分布式存储）：更久没用或跨实例共享的 KV
请求在 decode 时才需要 KV Cache 在 GPU 上。API 响应返回后，如果用户不马上发下一条（multi-turn），KV Cache 被 offload 到 L2/L3。下一次请求来了再从 L2/L3 换回 L1。
Agent 场景的命中率。 清华+北大联合 DeepSeek 的 DualPath 论文（2026-02）指出，Agent 工作负载的 KV Cache 命中率通常 >95%。这意味着绝大多数请求的 KV 可以从缓存命中，不需要重新 prefill。但同时，这也意味着系统需要管理大量缓存 KV——不是在 GPU 上就是在 CPU/SSD 上。
用占空比分析推导 GPU 驻留比例。 上面的推导假设所有并发请求的 KV Cache 同时在 GPU 上。实际上，不是所有请求都在同时 decode——有些在等用户输入、等工具返回、或在 offload 状态。可以用时间分片的占空比（duty cycle）精确推导 GPU 显存中 KV Cache 的实际驻留比例。
占空比公式：ρ = W_decode / W_total（单请求 decode 时间占总生命周期比例）。应用到推理服务：
GPU 驻留比例 ρ = W_decode / W_total
W_decode = 单请求所有 decode 步骤的总 GPU 时间
W_total = W_decode + W_idle（等待用户/工具响应的空闲时间）
W_decode 取决于输出长度和 decode 速度。假设平均输出 1,000 tokens，DSV4 量级的 decode 速度约 200 tokens/s（K3 因 104B 激活更大，实际可能 100-150 tokens/s，ρ 会更高）：
W_decode = 1,000 / 200 = 5 秒
W_idle 取决于交互模式。参考 DualPath 论文（清华+北大联合 DeepSeek，2026-02，arXiv:2602.21548）的 Agent 负载实测数据——平均 157 轮交互、每轮追加 429 tokens——可以推导三种场景：
| 场景 | W_decode | W_idle | ρ = W_decode/(W_decode+W_idle) |
|---|---|---|---|
| 高交互 Agent（连续多轮、短间隔） | 5s | 5s | 50% |
| 标准 API（用户思考几秒再回复） | 5s | 15s | 25% |
| 低频批处理（定时任务、长间隔） | 5s | 40s | 11% |
高交互 Agent 的间隔短（工具执行结果几乎立即返回），GPU 驻留比例接近 50%。标准 API 用户每轮思考 10-20 秒，ρ 约 25%。低频批处理的大部分时间在等待调度，ρ 可低至 10%。
取三种场景的中位值 ρ = 25% 作为标准估算。这个比例跟社区实践数据吻合——行业部署报告显示 HiCache 开启后 GPU 显存占用可减少约 78%（即 GPU 仅承载约 22% 的 KV Cache，与 ρ=25% 接近；来源为社区分享，非严格基准测试）。
修正后的 D 节点数（按 ρ=25% 估算）：
| 部署方案 | 上界估算 | ρ=25% 修正 | ρ=50% 高交互 |
|---|---|---|---|
| K3 on H200 | ~580 D 节点 | ~145 D 节点 | ~290 D 节点 |
| DSV4 on H200 | ~136 D 节点 | ~34 D 节点 | ~68 D 节点 |
| K3 on B300 | ~180 D 节点 | ~45 D 节点 | ~90 D 节点 |
| DSV4 on B300 | ~38 D 节点 | ~10 D 节点 | ~19 D 节点 |
加上 P 节点（1:2.5），总节点：
| 总节点（含 P+D） | 上界 | ρ=25% 标准 | ρ=50% 高交互 |
|---|---|---|---|
| K3 on H200 | ~812 | ~203 | ~406 |
| DSV4 on H200 | ~190 | ~48 | ~95 |
| K3 on B300 | ~252 | ~63 | ~126 |
| DSV4 on B300 | ~53 | ~14 | ~27 |
节点比在所有场景下保持 4.3×（H200）——HiCache 对两个模型等比例缩减，不改变相对差距。但绝对节点数受负载模式影响很大：K3 on H200 在标准 API 场景（ρ=25%）需要约 203 个节点，在高交互 Agent 场景（ρ=50%）需要约 406 个。
关键发现：负载模式与架构选择对节点数的影响在同一量级。 同一个 K3 模型，高交互 Agent（ρ=50%）需要的节点是低频批处理（ρ=11%）的约 4.5 倍；而 K3 与 DSV4 的架构差距是 4.3 倍。两者的影响幅度接近，意味着推理成本优化需要同时关注架构选择和运营策略（offload 调度、prefix caching、batch 策略）。
B300 单卡 288 GB HBM3e，带宽 8 TB/s。DGX B300 节点 8 卡总显存 2,304 GB，NVLink 5 聚合带宽 14.4 TB/s。
同样推导：
K3 B300（EP=32，每卡权重仍 69 GB）： KV 可用 = 288 - 69 - 5 = 214 GB。32 卡 = 6,848 GB。并发/单元 = 6,848 / 30.9 = 222。万并发 = 45 D 单元 × 4 = 180 D 节点 + 72 P 节点 = ~252 节点
DSV4 B300（EP=16，每卡权重 82 GB）： KV 可用 = 288 - 82 - 3 = 203 GB。16 卡 = 3,248 GB。并发/单元 = 3,248 / 6.1 = 532。万并发 = 19 D 单元 × 2 = 38 D 节点 + 15 P 节点 = ~53 节点
| B300 | K3 | DSV4 | 节点比 |
|---|---|---|---|
| 总节点 | ~252 | ~53 | 4.8× |
| 总 GPU | ~2,016 | ~424 | 4.8× |
| vs H200 改善 | 3.2× | 3.6× | — |
B300 对 K3 的改善幅度（812→252，3.2×）略小于对 DSV4 的改善（190→53，3.6×）。原因是 K3 的 EP=32 需要 4 节点/单元，B300 的显存翻倍主要让每卡能承载更多 KV Cache，但 EP 规模不变。DSV4 的 EP=16 只需 2 节点/单元，B300 的显存翻倍让每卡的 KV Cache 余量从 56 GB 暴增到 203 GB（3.6×），并发能力直接跳升。
50ms TTFT：不是瓶颈
先说结论：50ms 的首 token 延迟，两个模型都能满足。K3 在 H200 上 decode 约 28 ms（104 GB 激活权重 / 4.8 TB/s + 30.7 GB 平均 KV / 4.8 TB/s），余量 44%。DSV4 更宽裕，约 11.5 ms，余量 77%。
延迟不是卡点，显存才是。KV Cache 的大小决定能用多大 batch size，batch size 决定吞吐量，吞吐量决定单位成本。
B300：K3 的硬门槛
为什么 K3 比 DSV4 更需要 B300？答案在激活权重的显存占比。K3 的 104B 激活在 H200 上占 74%（104/141 GB），留给 KV Cache 的空间极少。B300（288 GB）把这个比例压到 36%（104/288 GB），才有实际可用的余量。B300 的 2× 带宽也把 decode 从 28ms 降到 17ms。
DSV4 的 49B 激活在 H200 上只占 35%，有充足余量。对 DSV4 来说，H200 已经可行；对 K3 来说，B300 才刚刚够用。
缓解手段
以上是"裸"成本。生产部署会用 PagedAttention（减碎片 10-15%）、KV Cache Offload（不活跃请求的 KV 转到 CPU/SSD）、Prefix Caching（前缀相同复用 KV）。
K3 的 KDA 固定状态天然适合 offload：207 MB 的递归状态可以在 GPU 和 CPU 之间高效切换。DSV4 的 KV 更小（12.2 GB/请求），但仍然随上下文线性增长，在极端长上下文（10M+）时 offload 收益不如 KDA 的固定状态。
单位推理成本
综合权重加载和 KV 读取，DSV4 的单位推理成本约为 K3 的 40%（基于 decode 带宽消耗比 (49+6.1)/(104+30.7) ≈ 0.41）。主要驱动因素：激活参数减半 + KV Cache 更小。
但 K3 在能力上换回了东西：2.8T vs 1.6T 的总参数意味着更大的知识容量，104B vs 49B 的激活意味着每 token 做更多计算。加上 K3 原生支持视觉输入（多模态），DSV4 仍是纯文本。成本差距是真实的，能力差距也是真实的。
四、判断
一、DSV4 的推理成本优势是结构性的。 激活参数减半加 KV Cache 压到 1/5，同等集群规模下服务更多并发。K3 的 104B 激活是真实的成本代价，换来的是更大的知识容量和多模态能力。如果你只做文本推理，DSV4 更经济；如果你需要多模态 + 长上下文 Agent，K3 有独特价值。
二、K3 的 KDA 路线在极端长上下文（10M+）下有理论优势。 KDA 固定状态不随序列增长，DSV4 的 CSA/HCA 仍线性增长。当上下文从 1M 扩到 10M 甚至 100M 时，K3 的内存上界更低。但今天这个优势还是理论性的，1M 已经是极限场景。
三、B300 比 H200 更适合 K3。 大激活模型需要大显存，这是硬性门槛。DSV4 在 H200 上已经可行，K3 在 B300 上才有余量。这对硬件采购决策有直接影响。
四、架构选择正在被 GPU 显存约束倒逼。 两个团队都选择了混合注意力而非纯 Full Attention——这不是巧合，是百万 token 场景下 KV Cache 显存压力的必然结果。K3 选 Linear 混合、DSV4 选 Sparse 压缩，背后是同一个约束：标准注意力的 KV Cache 在百万 token 下不可承受。苏剑林的"不得而知"是诚实的。两条路线都通过了当前验证，但在百万 token + 万级并发的生产规模下，真正的压力测试才刚开始。
数据来源：苏剑林"简单谈谈 K3 的 MoE 和 Attention"（科学空间 blog，2026-08-04）、Kimi K3 技术报告（47 页，2026-07-27 开源，Table 1：93 层 / 69 KDA + 24 MLA / hidden 7168 / 96 heads）、DeepSeek V4 技术报告（58 页，2026-04-24 开源）、心智观察所 DSV4 拆解（百家号 2026-04-29）、知乎 DSV4 技术报告解读（2026-04-29）、新浪科技 DSV4 推理成本数据（2026-08-05）、NVIDIA H200 / B300 官方规格。KV Cache 和推理成本基于公开架构参数推导。本文不构成投资建议。数据截至 2026 年 8 月 6 日。