百万token成本暴降90%!DeepSeek-V4揭秘:混合压缩注意力+流形约束超连接,重构大模型长上下文架构

当上下文窗口扩展到百万级 token 时,大模型的底层架构正经历一场静默重构。DeepSeek-V4 通过融合混合注意力机制、受约束的残差连接、创新优化器以及极致的工程手段,将长上下文处理成本压缩了 90%。围绕这场架构变革,有人在 XHS 上算了一笔具体的账:DeepSeek-V4-Pro 的预训练计算量约为 1e25 FLOPs,如果以 OpenAI 的十万台 GB200(有效利用率 30%)来算,完成同等训练仅需约 19 小时,算力鸿沟之巨大可见一斑。

然而,大模型训练的核心成本在于反复试错,充足算力的真正价值在于并行消融验证、避免流程阻塞——正是在这种劣势下,DeepSeek 依然交出高质量的开源模型,其技术含金量尤为突出。

也有用户实测发现,V4-Flash 版本性能接近 Claude Sonnet 4.6,支持百万级超长上下文,性价比直接拉满:百万 token 仅需一元,后续 Pro 版算力完善后还会进一步降价。未来的选型思路也因此逐渐清晰:接入 Claude Code,用 GLM5.1 对标复刻 Claude Opus,DeepSeek 平替 Claude Sonnet,Minimax 则定位 Claude Haiku。不少国产卡都宣布 Day 0、Day 1 适配,但性能对比结果尚待验证。

  • DeepSeek-V4:Towards Highly Efficient Million-Token Context Intelligence
  • https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf
  • 开源链接:https://huggingface.co/collections/deepseek-ai/deepseek-v4

本周,DeepSeek 发布了 DeepSeek-V4 系列模型,不仅参数规模飙升至 1.6T,还直接打开了原生百万 token 上下文的大门。

更令人震惊的是,在处理 100 万 token 时,单 token 的推理计算量仅为上一代 DeepSeek-V3.2 的 27%,KV 缓存占用更是只有后者的 10%。

DeepSeek-V4 系列与 DeepSeek-V3.2 的推理浮点运算次数和键值缓存大小对比图揭示了这一成就的核心:通过混合压缩注意力机制,V4-Pro 在百万级上下文场景下,仅消耗 V3.2 27% 的推理 FLOPs 和 10% 的 KV 缓存。这种数量级的效率跃升并非通过简单的量化实现,而是根本性地重构了长序列的计算依赖图。它使得原本因计算成本过高而不可行的长程任务变得经济可行,为测试时计算扩展和复杂的智能体工作流铺平了道路。

这样的效率奇迹从何而来? 答案藏在全新的混合注意力架构(CSA + HCA)、受流形约束的超连接(mHC)、Muon 优化器,以及从训练到推理的一整套基础设施革新里。

图 2:DeepSeek-V4 系列总体架构。在注意力层使用混合的压缩稀疏注意力和重度压缩注意力,在前馈网络层使用 DeepSeekMoE,并用流形约束超连接来增强传统的残差连接。模型保留了 Transformer 骨架和多 token 预测,但关键的修改重塑了其能力边界。混合 CSA 与 HCA 的引入是应对长文本效率瓶颈的核心对策,它打破了传统自注意力随序列长度平方级增长的 FLOPs 魔咒。同时,mHC 并非简单的残差连接替代品,它通过约束在双随机流形上的变换矩阵,从数学上保证了信号在前向和反向传播中的稳定性,为训练极深网络提供了可能。结合 DeepSeekMoE,整个架构在不牺牲模型表达能力的前提下,实现了对计算与内存资源的精细化管理,是系统工程与算法理论有机结合的范本。

但技术报告的迷人之处,不只在于它展现了有多强,更在于它暴露了设计者内心的 “既要……又要……” 和那些尚未被完美解答的底层难题。

我们不妨从六个关键的问题切入,看看 V4 是如何在刀尖上跳舞的。

unsetunset本文目录unsetunset

  • 本文目录
    • 问题 1:把上下文“压碎”再“挑着看”,模型会彻底忘掉跨越压缩块的遥远线索吗?
    • 问题 2:用数学约束“驯服”残差流,会不会反而掐死了模型对突变的表达力?
    • 问题 3:Muon 优化器 + MoE,会把专家参数“修偏”然后连锁搞崩路由吗?
    • 问题 4:FP4 量化“无损还原”听起来很玄,真实推理时到底赚到的是存储,还是算力?
    • 问题 5:KV 缓存搞出“压缩态”“滑动窗口态”“磁盘态”三套班子,会不会把省下的算力全送给 I/O 调度器?
    • 问题 6:前摄路由和 SwiGLU Clamping 这些“补丁”的存在,是不是反证了 V4 底层架构根本没法自己稳定收敛?
  • 尾声:效率革命是一场坦率的冒险

交流加群请在 NeuralTalk 公众号后台回复:加群

问题 1:把上下文“压碎”再“挑着看”,模型会彻底忘掉跨越压缩块的遥远线索吗?

如果要读一本一百万字的小说,但被规定:每读完 4 页(CSA 压缩),只能写一行摘要,或者每 128 页(HCA 压缩)才总结一次。回头查找时,还得从所有摘要里“挑一小撮”看。如果一个关键伏笔在第 100 页埋下,到第 500 页才揭晓,那么经过几十轮“压缩-筛选”,这条线索还存在吗?

DeepSeek-V4 的混合注意力,由“压缩稀疏注意力”(CSA)和“重度压缩注意力”(HCA)交错构成。具体来说:

  • CSA 把每 4 个 token 的 KV 缓存压成 1 个,再用稀疏注意力只选前 512 或 1024 个压缩块参与计算;
  • HCA 更狠,每 128 个 token 压成 1 个,走密集注意力。

这势必让人担心:信息在跨压缩块的边界上会不会出现系统性遗忘?

报告里的答案 非常清醒——他们用三个相互咬合的机制来硬抗这个问题:

机制 1. 滑动窗口“兜底”防止就近失忆

CSA/HCA 只看得到前面的压缩块,一个 query 看不到自己块内其他 token 的信息。为此,每一层都加了一条滑动窗口注意力分支(窗口大小 128),完整保留最近 128 个 token 的未压缩 KV 。这保证至少局部上下文的依赖是绝对精确的,绝不丢失分毫。

核心架构一:CSA(压缩稀疏注意力)

CSA的核心思路在于将键值(KV)条目数量压缩至原来的1/m,随后借助DeepSeek稀疏注意力机制实现进一步加速。此外,它还整合了少量滑动窗口内的KV条目,以强化对局部细粒度依赖关系的捕捉。其精髓可概括为“先压缩,后稀疏”。具体而言,通过一组可学习的压缩权重,模型能够将连续m个token的KV缓存聚合为一个压缩后的条目。这一过程在保留长程信息的同时,极大地削减了存储开销。紧接着,一个名为Lightning Indexer的组件会在网络中动态且非均匀地挑选出与当前查询最相关的前k个压缩块,并仅对这些块执行核心的注意力计算。这种设计巧妙地化解了全局注意力计算量过大的难题,而额外引入的滑动窗口分支则有效弥补了因压缩而丢失的局部上下文信息。CSA的设计理念表明,高效的注意力机制并非简单地丢弃信息,而是通过学习识别哪些信息值得被保留和关注,从而在序列的全局结构与局部细节之间达成一种动态平衡。

核心架构二:HCA(重度压缩注意力)

HCA采用了更为激进的压缩策略,将每m‘个(m’远大于m)token的KV条目合并成一个单一的压缩条目。同样地,它也额外引入了一小部分滑动窗口内的KV条目,以增强对局部细粒度依赖的表达。HCA追求极致效率,与CSA侧重精准稀疏选择的思路形成了鲜明互补。HCA将压缩率m‘设定为远大于CSA的m(例如128),从而将长序列信息极度浓缩,因此其更多地依赖于压缩块所提供的概括性上下文。由于HCA会保留所有压缩块执行稠密注意力计算,省去了稀疏选择所需的索引开销,因此在处理对局部精确性要求不高,但需要全局视野的任务时,它具备显著优势。V4系列模型通过在层间交替使用CSA和HCA,构建了一套巧妙的混合策略:CSA层负责细粒度、筛选式的信息交互,而HCA层则提供粗粒度、全局性的信息背景。这种分工协作使得模型能在不同的抽象层级上处理信息,从而在保证效率上限的同时,维持了强大的长文本理解能力。

机制 2:重叠压缩,模糊块边界

在CSA的压缩过程中,设计了一个精密的信息传递机制:每个压缩单元的生成,不仅依赖于当前m个token的KV,还融合了上一个压缩块的部分token信息。

报告将这一设计称为“索引存在重叠”。这种做法在不增加最终KV缓存条目数量的前提下,让相邻的压缩块共享了部分原始信息,极大地增强了块与块之间的语境连续性,从而有效缓解了硬性分块可能带来的信息割裂问题。

机制 3:Attention Sink,赋予模型“谁都不理”的权力

V4引入了Attention Sink机制——每个注意力头都配备了一个可学习的汇点logit,并将其累加到注意力分母的计算中。

其中:
* 表示指数函数。
* 表示第i个注意力头的可学习汇点logit。
* 对所有被选中的压缩KV块求和。

这意味着每个注意力头都有一个可学习的、固定的“注意力回收站”(Sink)。它的作用是调节注意力分布的稳定性:模型可以将部分无用的、多余的注意力权重“倒入”这个Sink,从而避免被迫将过高的注意力集中在少数相关性不高的token上,让真正有效的注意力权重分布更加合理、平滑。这在根本上避免了微弱但关键的长程信号被噪声淹没。

在1M token的MRCR(多针检索)测试中,DeepSeek-V4-Pro在128K长度内表现出了惊人的稳定性,即便扩展到1M长度,其成绩依然碾压Gemini-3.1-Pro。实证证明,这条“压缩–选择”流水线至少在事实检索式的长程依赖任务上没有失效。

问题 2:用数学约束“驯服”残差流,是否会扼杀模型对突变的表达能力?

如果规定自己每走一步,步子不能比上一步大,那确实永远不会摔跤,但紧急关头需要跳过一个水坑时,你就被锁死了。mHC给每一层的残差连接绑上了“非扩张”约束,这是否是以牺牲深层网络的剧烈表征变化能力为代价换来的稳定?

DeepSeek-V4用Manifold-Constrained Hyper-Connections (mHC)替代了传统的残差连接。其核心是让残差变换矩阵落在“双随机矩阵”这个流形上,保证,从而让信号在前向和反向传播中都不会爆炸。

但报告明确指出了一条关键路径:约束只施加在残差状态的混合方式上,而层内变换的表达力原封不动。

具体是如何实现的?mHC先将残差流的宽度从扩展为(相当于复制了4份),然后利用和进行输入输出的重组合。无论如何受限,喂给MoE层或注意力层的真实输入始终是维,这些层内部的非线性计算完全没有打折。

这里的关键在于,mHC的设计哲学是将“信息传输的稳定性”与“模型计算的表达力”彻底解耦。 约束施加的对象,只作用于那条被扩增了维度的“超空间”残差流,负责稳定地混合和传递历史信息。而真正负责核心计算的MoE层和注意力层,其输入和输出的维度依旧是,其内部的非线性变换能力和学习能力原封不动、毫发无损

mHC的约束非但没有牺牲能力,反而通过这个更精细的双通道设计,为在极深网络中实现稳定且强大的训练奠定了基础。

更巧妙的是,、、都不是写死的,而是根据输入实时生成的。用报告的话说就是“动态参数化”——同一个模型在处理不同token时,会组合出不同的残差混合策略,这使得表达力富富有余。

问题 3:Muon优化器 + MoE,会导致专家参数“修偏”进而连锁搞崩路由吗?

V4 Pro有384个路由专家,每次都只激活6个。Muon优化器要求对整个参数矩阵做正交化再更新,为了省内存又不得不东切西分,还用BF16压缩梯度通信。这会不会导致不同专家收到的更新有效精度不一致,冷热不均,最终路由彻底混乱?

这确实戳到了MoE与Muon结合的“七寸”。报告原文也摆出了两道防线:

  • 逻辑上绝不割裂专家。 工程师将展平所有MoE专家的下投影、上投影、门控矩阵,然后顺序填充、切分给不同的rank,保证“无需切分任何逻辑上独立的矩阵”。这意味着,每个专家的参数矩阵作为Muon正交化的单位是完整的,绝不会出现半个专家被正交化、另一半没处理的诡异情况。

  • All-to-All + 本地FP32求和,挽救量化精度。 为了将跨rank的梯度通信量减半,他们确实把梯度量化成了BF16,但立刻补充了一句:“为避免低精度累加器引入的累积误差,我们用一个两阶段方法取代了传统的树状或环状reduce-scatter”——先用all-to-all把各rank的梯度交换,然后每个rank自己在 FP32下执行求和。这样既节省了通信量,也保住了累加精度。

此外,还有一个更直接、且被验证为无损的数值稳定技巧(问题6会具体讲):SwiGLU Clamping。报告明确指出,将SwiGLU激活值直接截断在的范围内,能够在不损害模型性能的前提下,有效消除异常值,从而抑制由其引发的训练尖峰。 这与前摄路由相辅相成,共同构成了稳定训练的防线。

DeepSeekV4的全专家并行方案及相关工作的示意图。该图深入解读了V4在系统层面实现高效训练的秘诀——细粒度的通信-计算重叠。传统方案如Comet仅实现粗粒度的重叠,仍有大量时间浪费在等待上。V4的方案通过“波次”调度专家,将计算与跨节点的分发、合并通信切分成更细的流水线步骤,让通信完全隐藏在计算背后。这一设计的精妙之处在于,只要计算-通信比满足条件,即使降低互联带宽也不会显著影响性能。这意味着V4可以在更廉价的网络硬件上运行,对降低大规模MoE模型的部署成本和推动异构算力集群的发展具有深远意义,体现了算法和硬件的协同设计思想。

问题 4:FP4量化“无损还原”听起来很玄,真实推理时到底赚到的是存储,还是算力?

报告说FP4的权重可以“无损”地转回FP8参与计算。这就像把一份缩印件用高精度扫描仪数字化——扫描过程确实没再损失,但缩印时丢掉的细节是一去不返的。V4的’无损’指的是反量化过程,而非原始精度 。但丢了的画面细节是一去不复返的。V4的FP4优势到底有多少是存储层面,有多少是实实在在的算力翻倍?

报告坦率地承认,目前的主要收益来自存储和内存带宽的节省,算力层面的提升需要等待新一代硬件。引言中已明确指出:“尽管 FP4×FP8 操作的峰值 FLOPs 在当前硬件上与 FP8×FP8 一致,但理论上它们可以在未来硬件上实现。”这意味着,今天使用 FP4 运行 V4,计算吞吐量并未提升,但模型权重占用更少,每次从显存搬运数据的负担减轻——这对 KV 缓存和超长上下文解码尤为关键。

那么,“无损”是如何实现的?FP4 采用 E2M1 格式,而 FP8 是 E4M3,后者多出 2 个指数位,动态范围更宽。只要一个 128×128 的 FP8 量化块内,各 1×32 的 FP4 子块的尺度因子不超过某个阈值,反量化回 FP8 时就能吸收这些细粒度信息,不会产生额外舍入。因此,“无损”指的是转换过程,而非原始精度。

团队还做了一件非常坦诚的事:推理和 RL rollout 时,直接使用真实的 FP4 权重,不进行模拟。这确保了部署行为与训练对齐,没有任何粉饰。总结来说,FP4 让 V4 的存储效率大幅提升,但算力红利需等待硬件更新。报告没有画饼,而是将前景清晰地摆在了桌面上。

问题 5:KV 缓存引入“压缩态”“滑动窗口态”“磁盘态”三套方案,会不会将省下的算力全部消耗在 I/O 调度上?

好比发明了一套极简的速记法,笔记薄了 90%,但格式特殊,管理员每次找资料都得拼凑碎片、跑好几间档案室,等找到时,省下的读书时间早已被等待时间耗尽。

V4 的混合注意力机制产生了异构的 KV 缓存:CSA/HCA 的压缩缓存、滑动窗口的未压缩缓存,以及用于共享前缀的磁盘持久化缓存。这种复杂性对系统调度是巨大挑战。如果 I/O 延迟成为新瓶颈,架构的算力优势可能在实际部署中被抵消。

报告提到,他们正通过硬件-内核-算法的协同设计来破解这一困境,而非被动接受。

  • 首先,他们没有采用通用方案将就。报告直接指出,像 PagedAttention 这样的统一缓存管理在此处会碰壁,因此设计了双轨制
    • 滑动窗口和压缩尾 token 作为“状态缓存”,预分配固定空间;
    • 压缩缓存采用经典块管理,并借助稀疏注意力内核的协同设计,使不同层的缓存块能自然对齐(以压缩比的最小公倍数为块大小),不牺牲内核性能。
  • 其次,多 Token 预测(MTP)从源头上降低了对 KV 缓存的访问频率。一次生成多个 token,就减少了反复加载巨型缓存的次数。
  • 最后,对于磁盘存储,他们提供了三种策略:全量存储、每 p 个 token 设置检查点、完全不存储滑动窗口 KV。用户可根据硬件特性,自由选择用算力换取 I/O 或反之。这种可配置性揭示了设计者对 I/O 瓶颈的深刻预估和主动规避。

问题 6:前摄路由和 SwiGLU Clamping 这些“补丁”的存在,是否反证了 V4 底层架构本身无法稳定收敛?

一架设计极为复杂的飞机,试飞时总莫名抖动。工程师找到两个办法:用上次飞行记录来校准这次的控制(前摄路由),以及硬性限定方向舵最大偏角(Clamping)。抖动消失了,但我们必须追问:最初的气动设计是否存在根本的、理论上未知的缺陷?

这可能是整篇报告最触及灵魂的部分。DeepSeek 团队以一种罕见的坦诚,承认了训练不稳定,给出了工程解决方案,然后直言“理论还没搞明白”。

万亿参数 MoE 模型训练存在稳定性挑战,简单回滚无法根治损失尖峰问题。研究发现,尖峰与 MoE 层异常值相关,路由机制还会加剧该问题。团队从打破路由循环、抑制异常值两方面入手,找到了两种实用方法保障训练稳定,并公开分享以推动社区进一步探索。

报告描述了万亿参数 MoE 训练时遭遇的损失尖峰,并定位到:“异常值的出现始终与 MoE 层相关,且路由机制本身似乎加剧了这些异常值的出现”。也就是说,MoE 的动态路由与 SwiGLU 非线性耦合后,会形成自我强化的反馈循环。

  • 前摄路由(Anticipatory Routing)的思路是:用上一次的路由索引(而非当前)来计算路由索引,打破骨干网络和路由网络同步更新带来的强耦合。他们因此承担了约 20% 的额外时钟时间开销,但仅在检测到尖峰时动态开启,过后恢复到普通训练。这就像一种“免疫风暴期间的紧急治疗方案”。
  • SwiGLU Clamping 则更直接:将激活值截断在 [-64, 64] 范围内。报告直言这 对性能无损害,且能有效消除异常值。

在结论部分,他们再次重申:“尽管前摄路由和 SwiGLU 截断已被证明能有效缓解训练不稳定,其底层机制仍未充分理解。我们将积极研究训练稳定性的基础问题,力求一种更原则性、可预测的方法。” 这完全不是遮遮掩掩,而是将问题本身作为下一阶段的研究主题。因此,补丁的存在恰恰说明 V4 是一个在理论边界上硬闯出来的工程奇迹,它实用、强大,但它的创造者比任何人都更想知道背后的“为什么”。

尾声:效率革命是一场坦率的冒险

DeepSeek-V4 的六个技术博弈,勾勒出一个团队在“极致效率”道路上的取舍逻辑:

  • 压缩与稀疏:通过重叠、滑动窗口和注意力汇聚,守住长程依赖的底线。
  • mHC 约束:将稳定性锁定在残差混合上,把爆发力留给层内计算。
  • Muon + MoE:通过逻辑完整性、高精度累加和强制压制,在悬崖边踩出一条路。
  • FP4:在存储上极致省钱,对计算收益实事求是,把未来留给硬件革新。
  • 异构缓存:用协同设计和多策略选择消化系统复杂性。
  • 训练不稳定承认知识盲区,用工程手段止血,并公开募集理论突破。

V4 不是一篇只报喜不报忧的 PR 论文,而是一份边展示武功边标注“尚未参悟”的技术手稿。正因如此,它所开启的百万 token 上下文时代,才让人既感到震撼,又心生期待——期待那些被坦诚记录下来的开放问题,能在不远的将来催生出更优雅、更可解释的下一代模型。

毕竟,真正的技术领导力,不是宣称拥有一切答案,而是敢于把最难的那些问题,写进论文,昭告天下。


关注“鲸栖”小程序,掌握最新AI资讯

本文来自网络搜集,不代表鲸林向海立场,如有侵权,联系删除。转载请注明出处:https://www.itsolotime.com/archives/32236

(0)
上一篇 19小时前
下一篇 19小时前

相关推荐

  • A2UI协议:开启AI原生交互新时代,让智能体“说”出动态界面

    Google 最近开源了一个名为 A2UI 的项目,旨在解决一个实际问题:AI 智能体如何安全地生成丰富的用户界面? 传统上,智能体只能返回文本,用户需要通过多轮对话才能完成任务。而 A2UI 允许智能体直接生成表单、按钮、日期选择器等交互式组件,用户只需点击几下即可完成操作。 从固定界面到动态生成的转变 传统的智能体交互主要基于文字聊天——用户提问,AI …

    2025年12月25日
    80400
  • Python开发者的内部工具构建指南:7大神器打造高效企业应用

    立即构建仪表盘、追踪器与工作流。 对于有经验的 Python 开发者而言,经常会遇到这样的需求:管理层希望快速构建一个内部仪表盘或工具。虽然这听起来颇具挑战,但事实是,企业运营确实离不开各类内部工具,如数据看板、审批流程、KPI 追踪器和自动化机器人。Python 凭借其丰富的生态系统,正是构建这类应用的理想选择。 在经历了多年为不同团队构建内部系统的实践后…

    2025年12月18日
    32300
  • OpenAI重磅升级:Responses API引入WebSocket模式,复杂任务性能提升40%

    OpenAI 发布了一项针对长时间运行、大量工具调用场景的重要更新:Responses API 现已支持 WebSocket 模式。 此功能专为需要频繁进行模型-工具交互的工作流设计,例如代码自动化或需要反复调用工具的智能体编排任务。 核心改进:从对话到关系 核心改进在于连接方式的转变。在传统的 HTTP 模式下,每次交互都需要重新发送完整的上下文,如同每次…

    2026年2月24日
    58200
  • 跨越模态边界:构建真正理解图像、表格与文本的多模态RAG系统

    构建多模态 RAG 系统的终极指南 三个月前,我们新开发的 AI 应用在诸多看似简单的问题上频频“翻车”。问题根源并非 AI 不够智能或数据不足,而是因为答案蕴含在一张图片里,而当时的系统仅能处理文本。 这一时刻迫使我直面一个在构建 RAG 系统时长期回避的核心问题:我们花费数年时间教 AI “阅读”文字,却忽略了人类同样通过图像、表格、公式和流程图来“表达…

    2025年12月16日
    47400
  • DualCamCtrl:双分支扩散模型革新视频生成,几何感知让相机运动误差降低40%

    本研究的共同第一作者是来自香港科技大学(广州)EnVision Research 的张鸿飞(研究助理)和陈康豪(博士研究生),两位研究者均师从陈颖聪教授。 你的生成模型真的「懂几何」吗? 当前众多视频生成模型虽宣称具备「相机运动控制」能力,但其控制信号通常仅依赖于相机位姿。近期工作虽通过逐像素射线方向(Ray Condition)编码了运动信息,但由于模型仍…

    2025年12月21日
    35000