文章总结： 本文剖析DeepSeek-V4的C4压缩注意力架构与DSpark半自回归投机解码：C4将4个token压缩为1个使KV总量降至1/4，C4Indexer支持FP4量化并固定top-512选择，Hadamard旋转保护极低比特量化质量，HiSparse实现热点KV近存交换；DSpark以并行骨干加MarkovHead修复后缀衰减，并按请求置信度动态调度验证长度，单用户延迟提升57-85%，配套DeepSpec开源训练框架，SGLang尚未集成，文中给出集成路径与代码入口。 综合评分： 81 文章分类： 其他
Token 的一生：DSV4 架构与 DSpark
原创
zouyee zouyee
DCOS
2026年9月17日 00:00 江苏
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
理解 DeepSeek-V4 的 C4 压缩注意力架构（DSV4），以及 DSpark 半自回归投机解码的设计原理与 SGLang 集成状态。
Summary
本篇介绍 DeepSeek-V4 的最新架构创新与 DSpark 投机解码方案。内容涵盖：C4 压缩器将每 4 个 token 压缩为 1 个，KV 总量降至 1/4；C4Indexer 的 FP4 量化支持与固定 top-512 压缩 token 选择；Hadamard 旋转在 FP4 极低比特量化下保护质量的作用；HiSparse 多级稀疏与热点 KV 近存储交换；DSpark 的半自回归草稿生成（Parallel Backbone + Sequential Markov Head 修复后缀衰减）；置信度调度验证（按请求动态调整验证长度，避免过猜/欠猜）；DeepSpec 开源训练框架；SGLang 集成状态与代码入口点；以及 DSA/DSV4/DFlash/DSpark 四者在”减少 forward 次数”和”减少 KV 读取量”两个正交维度上的协同关系。
1. 从 DSA 到 DSV4：更激进的压缩
第10篇介绍了 DSA（Dynamic Sparse Attention）：用 Indexer 选 top-k KV，只读少数关键 token。
DeepSeek-V4 在此基础上走得更远，提出了 C4 压缩——在存入 KV Cache 之前，先把 token 序列按 4 倍压缩，再做 top-k 稀疏注意力。
DSA（V3 架构）：
seqlen 个 raw token → Indexer 选 top-k → 稀疏注意力（读 k 个 raw token 的 KV）
DSV4（V4 架构）：
seqlen 个 raw token → C4 压缩器 → seqlen/4 个 compressed token
→ Indexer 选 top-512 compressed token → 稀疏注意力（读 512 个压缩 KV）
每压缩 token 代表 4 个 raw token 的信息
1M seqlen → 250K 压缩 token → top-512 → 只读 512 个
官方数据（来自 HuggingFace model card）：
| 模型 | 相对 V3.2 的 FLOPs | 相对 V3.2 的 KV 内存 | | — | — | — | | DeepSeek-V4-Pro | 27%（1M context） | 10% | | DeepSeek-V4-Flash | 10%（1M context） | 7% |
2. C4 压缩器（Compressor）
2.1 什么是 C4？
“C4” = “Compressed by 4″：将每 4 个相邻 token 的 hidden states 压缩成 1 个压缩 token。
# python/sglang/srt/layers/attention/dsv4/compressor.py（概念示意）
class Compressor(nn.Module):
"""
把 raw hidden states 按 4 倍压缩：
输入：[seqlen, hidden_size]（每步只对新 token 做压缩）
输出：[seqlen // 4, compressed_hidden_size]（写入 C4 KV cache）
具体实现：当 raw position 是 4 的倍数 - 1 时（如 3,7,11,...），
触发一次压缩，把位置 [4k, 4k+3] 的 4 个 token 压缩成 1 个
"""
# 压缩方式：可以是简单的 linear projection，也可以是小型 Transformer block
2.2 C4 KV Cache 的尺寸
压缩后的 KV Cache（”C4 KV Cache”）大小约为原始的 1/4：
# python/sglang/srt/layers/attention/dsv4/metadata.py
class PagedIndexerMetadata:
page_size: int = 256 # DSV4 使用更大的 page size（vs DSA 的 64）
page_table: torch.Tensor # [bs, num_pages]，物理页表
c4_seq_lens: torch.Tensor # 压缩后的序列长度 ≈ raw_seqlen // 4
@property
def c4_page_size(self):
return self.page_size // 4 # 256 // 4 = 64（C4 页内的压缩 token 数）
3. C4Indexer：FP8/FP4 量化的索引查询
DSV4 的 Indexer（C4Indexer）与 DSA 的 Indexer 原理相同，但有两个关键差异：
3.1 FP4 量化支持
DSV4 的 index K cache 支持 FP4 量化（而 DSA 是 FP8），进一步压缩内存：
# python/sglang/srt/layers/attention/dsv4/indexer.py
class C4Indexer(nn.Module):
use_fp4_indexer: bool # 是否使用 FP4（需要 SM120/B200 支持）
def compute_q(self, q_lora, positions, weights):
if self.use_fp4_indexer:
# FP4 量化的 Q + head gate 权重融合
q_fp4, q_sf = fused_q_indexer_rope_hadamard_fp4_quant(
q, weights_raw, q_scale_gate, freqs_cis, positions
)
return (q_fp4, q_sf), weights
else:
# FP8 量化（与 DSA 一致）
q_fp8, weights = fused_q_indexer_rope_hadamard_quant(
q, weights_raw, q_scale_gate, freqs_cis, positions
)
return q_fp8, weights
3.2 Top-512 变换（硬编码）
DSV4 固定选 top-512 个压缩 KV（对应 ~2048 个 raw token），使用高度优化的 topk_transform_512 kernel：
def topk_transform_512(
logits, # [bs, c4_seqlen] 相似度分数
c4_seq_lens, # [bs] 压缩后的序列长度
page_table, # [bs, num_pages]
c4_sparse_page_indices, # 输出：[bs, 512] top-512 的物理页索引
c4_page_size, # 64
raw_indices, # 可选：原始索引（供 HiSparse 使用）
):
# 高度专用化的 CUDA kernel：固定 k=512，充分利用 SM 并行性
# 比通用 fast_topk 快约 2-3x（因为 k 固定，tile 大小可以编译期确定）
4. Hadamard 旋转：为什么 DSV4 多了一步
DSA 的 index K 经过 k_norm + RoPE，而 DSV4 在此基础上额外做了一次 Hadamard 旋转：
# fused_q_indexer_rope_hadamard_quant（融合 kernel，DSV4 专用）：
# Q: rope → hadamard → FP8 量化
# K: rope → hadamard → FP8/FP4 量化 → 写入 index K cache
Hadamard 旋转的作用：把 BF16 张量的能量分散到所有维度，使得量化到 FP8/FP4 时误差均匀分布（类似随机量化的效果）。对于 FP4（4-bit）这种极低比特量化，Hadamard 预处理对质量保持至关重要。
5. HiSparse：多级稀疏与 KV 热点交换
DSV4 还有一个高级特性：HiSparse（Hierarchical Sparse），通过 hisparse_coordinator 管理：
# DeepseekSparseAttnBackend
self.hisparse_coordinator = model_runner.hisparse_coordinator
hisparse_decode = (hisparse_coordinator is not None
and forward_batch.forward_mode.is_decode())
if hisparse_decode:
# 把本步"最重要的 top-512 压缩 token"换入高速存储（类 L2 cache）
# 供下一步优先访问，无需重新从 L3/HBM 读取
core_metadata.c4_sparse_page_indices = hisparse_coordinator.swap_in_selected_pages(
req_pool_indices=forward_batch.req_pool_indices,
compressed_seq_lens=indexer_metadata.c4_seq_lens,
top_k_result=raw_indices,
layer_id=compress_layer_id,
)
HiSparse 的思路：热点 KV（被频繁选为 top-k 的）保持在近存储，降低下一步的访问延迟。这对长文档问答（同一段落被反复关注）场景效果显著。
6. DSpark：置信度调度的半自回归投机解码
6.1 背景与定位
DSpark（论文 arxiv:2606.19348，2026-06-27，DeepSeek + 北京大学）是针对 DeepSeek-V4 系列的投机解码框架，与 DFlash 是竞争关系：
| 对比维度 | DFlash（SGLang 已实现） | DSpark（SGLang 待集成） | | — | — | — | | 草稿生成方式 | 非自回归 （MASK Token 并行展开，一次 forward 生成整个 block） | 半自回归 （并行骨干 + 顺序 Markov Head） | | 验证调度 | 固定 block size | 置信度调度 （按请求动态调整） | | acceptance length | 基准 | 比 DFlash 高 16.3–30.9% | | 单用户延迟提升（vs MTP-1） | — | V4-Flash: 60–85%，V4-Pro: 57–78% |
6.2 半自回归草稿生成
传统投机解码的草稿生成面临两难：
- 完全并行（如 MASK Token）：快，但 block 内各位置相互独立，后缀 token 质量衰减（suffix decay）
- 完全自回归：质量好，但速度慢
DSpark 的解法：两阶段草稿生成
第一阶段（并行骨干，Parallel Backbone）：
输入：[当前 token, MASK, MASK, ..., MASK] (block_size 个)
草稿模型一次 forward，并行输出 block_size 个 draft hidden states
→ 快！但 suffix 质量差
第二阶段（顺序模块，Sequential Markov Head）：
对并行输出做 block 内顺序修正：
h̃₁ = markov_head(h₁)
h̃₂ = markov_head(h₂, h̃₁) ← 引入对前驱的依赖
h̃₃ = markov_head(h₃, h̃₂)
...
→ 修复后缀衰减，同时保持接近并行的速度（Markov Head 很轻量）
“后缀衰减”（suffix decay）：在纯并行草稿中，position 1 的草稿比 position N 准确得多，因为 position N 的草稿没有看到 position 1~N-1 的预测结果。Markov Head 用上一步的修正隐状态作为条件，让后缀 token “看到”前面的预测。
6.3 置信度调度验证
DSpark 最关键的系统级创新是动态调整每个请求的验证长度：
传统固定 block size（N=16）：
所有请求都猜 16 个草稿 → 验证 16 个
问题：
- 高置信度请求（草稿接受率 0.9）：浪费了——应该猜更多
- 低置信度请求（草稿接受率 0.3）：浪费了——猜太多，大部分被拒
DSpark 置信度调度：
估算每个请求的"前缀存活概率"P_survive(k)：
P_survive(k) = P(token_1 被接受) × P(token_2 被接受 | token_1) × ...
≈ 基于历史 acceptance rate 或 softmax 置信度估算
设定验证长度 N_i = argmax_N{ E[accepted_tokens(N)] / (T_draft(N) + T_verify) }
→ 每个请求根据自己的置信度曲线选最优 N
系统收益：通过动态匹配请求的”难度”与验证长度，避免了固定 block size 的过猜（低置信度浪费验证时间）和欠猜（高置信度留下潜力）。
6.4 与 DeepSpec 的关系
DSpark 与 DeepSpec（MIT 开源训练框架）一起发布：
DeepSpec（训练框架，MIT 开源）：
- 为 Qwen3、Gemma 等开放模型训练 DSpark 草稿模型
- 支持：蒸馏训练、验收规则的选择（greedy vs sampling）
- 提供已训练好的 DSpark 草稿模型（作为 HuggingFace checkpoint 的附件）
DeepSeek-V4-Pro-DSpark / DeepSeek-V4-Flash-DSpark：
- 不是新模型，是"原始 checkpoint + DSpark 草稿模块"的打包
- 草稿模块作为附加组件存储（类似 DFlash 的 speculative_draft_model_path）
6.5 SGLang 集成状态
截至本文写作（2026-06-29），SGLang 主干尚未合并 DSpark 支持。
从代码角度，集成 DSpark 需要：
- 在
SpeculativeAlgorithm枚举里新增DSPARK - 实现
DSParkWorkerV2（参考DFlashWorkerV2，主要修改草稿 forward 逻辑） - 实现半自回归的 draft forward（Parallel Backbone + Markov Head）
- 实现置信度调度器（修改
prepare_for_decode中的 block_size 动态计算）
跟踪方式：关注 SGLang 仓库的 python/sglang/srt/speculative/ 目录和相关 PR。
7. 三种方案的协同关系
理解 DSV4 的架构后，DSA / DSV4 / DFlash / DSpark 的关系就清晰了：
图 1：架构与流程示意（点击图片查看原图）
小结
| 组件 | 核心机制 | 关键参数 | | — | — | — | | C4 压缩器 | 4 倍 token 压缩，减少 KV 总量 | compress_ratio=4 | | C4Indexer | FP8/FP4 量化，top-512 KV 选择 | topk=512, page_size=256 | | Hadamard 旋转 | 量化前能量均匀分散，保护 FP4 质量 | 自动开启（DSV4 专用） | | HiSparse | 热点压缩 KV 的近存储交换 | 部署级优化 | | DSpark 半自回归 | 并行骨干 + Markov Head，修复后缀衰减 | block_size 自适应 | | DSpark 置信度调度 | 按请求动态选最优验证长度 | P_survive(k) 估算 |
系列总结（第8–11篇）
| 篇章 | 核心问题 | 解决方案 | | — | — | — | | 第8篇 | Decode 为什么慢？投机解码的全貌 | 内存带宽瓶颈 → 草稿-验证框架，lossless | | 第9篇 | DFlash 怎么生成高质量草稿？ | 借用目标隐状态 + 滑窗/全注意力混合层 + MASK Token 并行 | | 第10篇 | 超长上下文如何降低 KV 带宽？ | DSA Indexer + top-k 稀疏注意力 + FP8 index K cache | | 第11篇 | V4 如何同时压缩 FLOPs 和 KV？ | C4 压缩 + FP8/FP4 Indexer + DSpark 半自回归投机解码 |
深入阅读建议：
- DFlash Worker:
python/sglang/srt/speculative/dflash_worker_v2.py - DFlash Model:
python/sglang/srt/models/dflash.py - DSA Backend:
python/sglang/srt/layers/attention/dsa_backend.py - DSA Indexer:
python/sglang/srt/layers/attention/dsa/dsa_indexer.py - DSV4 Indexer:
python/sglang/srt/layers/attention/dsv4/indexer.py - DSV4 Compressor:
python/sglang/srt/layers/attention/dsv4/compressor.py - DSpark 论文: arxiv:2606.19348（2026-06-27）
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：DCOS zouyee zouyee《Token 的一生：DSV4 架构与 DSpark》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论