长上下文的竞争焦点已经从「支持多长」转成「每个 token 摊多少字节」

2024年5月的公开技术报告中，一组对比数据引发关注：相较于同系列的稠密基准模型，该系列模型的训练成本降低42.5%，KV缓存占用减少93.3%，最大生成吞吐提升至5.76倍。两年四个月后，2026年9月的最新版本报告给出了更精细的量化结果：常驻高速显存的全局KV缓存压缩至每个token 890字节，仅为上一代产品的四分之一；若计入固态硬盘或主机内存中的持久化缓存部分，这一比例更是低至八分之一。

两组数据的统计口径和基线并不一致，无法直接放在同一张表格中对比，但它们共同回答了同一个核心问题：在固定的算力与带宽预算下，模型的能力上限还能拓展到什么程度？这条技术路线在近三年间经历了多轮架构与后训练方法的迭代，每一次版本更新都在重新核算三项核心成本。

本文将按技术演进脉络梳理这条路线的发展历程，拆解每一代版本的优化方向，以及至今仍未完全解决的技术挑战。

早期基础架构的搭建（2023-2024年初）

这条技术路线公开的第一批权重是代码专用模型。官方仓库在2023年10月上线，完整技术报告到2024年1月才正式发布，报告覆盖1.3B到33B的参数规模，基于2万亿token的从零训练数据，还提出了16K上下文窗口的跨文件补全训练目标，将该任务直接纳入预训练环节而非留到微调阶段。

同一个月发布的两项工作为后续发展奠定了基础。其一通过缩放定律实验确定了7B和67B两个基础配置，预训练数据约2万亿token，后训练采用SFT加DPO的两段式流程，报告显示67B模型在代码、数学与推理等多个基准上表现超过同规模的其他同类模型。其二针对专家分工问题提出优化方案：传统的Top-K路由机制会导致每个专家学习到的知识关联性不足，改进方案将专家切分为mN个单元，每次激活其中mK个单元，并隔离Ks个共享专家来承载通用知识。对照实验显示，2B量级的改进模型与专家参数和计算量达到其1.5倍的同类模型表现相当。

这项针对专家路由的改进后来成为系列模型的核心架构基础，后续的236B总参数版本、671B总参数版本以及多模态模型的语言主干，均采用了这套切分逻辑。

2024年2月发布的数学专用模型值得单独关注，其公开时最引人注目的数据是在MATH基准上单次采样51.7%的准确率，64次自洽采样后准确率提升至60.9%，且全程未使用外部工具或投票机制。但该模型留下的更长期贡献是提出了GRPO算法：一种移除价值网络、通过组内相对比较来估计优势的PPO变体，从2024年的Prover-V1.5到2025年的R1系列，后续的强化学习后训练基本都基于这套算法框架展开。

架构优化的第一波落地（2024年中至2024年底）

2024年5月发布的版本是该路线首次将三项核心成本转化为可对比数据的节点。该版本总参数236B，每个token实际激活21B参数，支持128K上下文窗口，预训练语料规模达到8.1T token。两个核心结构同时到位：改进的专家路由机制负责摊薄计算量，多头潜在注意力机制负责压缩KV缓存。同一份报告中的三组对照数据——训练成本降低42.5%、KV缓存减少93.3%、最大生成吞吐提升5.76倍——基线均为同系列的67B稠密模型。

多头潜在注意力机制是该路线上最稳定的架构资产，从2024年5月到2026年V4版本发布前，主线的注意力机制优化都在该框架上进行调整，很少完全推翻重做。其核心逻辑是将键值投影到低维潜在向量，推理时仅缓存该潜在向量，需要时再还原出完整键值，以此降低每token的常驻显存占用，代价是增加一次投影计算。这也解释了后续版本很少直接改动该机制的原因：缓存成本与计算成本可以分开优化，优先解决哪一项取决于当时的资源约束。

这个阶段还有两条并行支线：其一针对形式化数学领域，将竞赛题翻译成Lean 4语句、过滤低质样本、合成推导过程，构建800万条带推导过程的训练数据，微调对象为数学专用7B模型，在相关基准上取得了超过同类模型的成绩；其二围绕训练基础设施，提出了基于PCIe设备的训练集群方案，在接近高端集群性能的前提下，成本仅为其一半，能耗降低40%，相关存储组件后续也独立开源成为推理与智能体训练的基础设施。

同一阶段，代码模型基于该版本的中间检查点继续预训练6万亿token，编程语言支持从86种扩展到338种，上下文窗口从16K提升至128K，验证了领域模型大多是通用基座的下游产物，而非从零开始训练的独立模型。

规模与后训练的双重升级（2024年底至2025年初）

2024年底到2025年初的四个月内，这条路线同时完成了两次关键升级。

第一次升级聚焦训练侧：总参数提升至671B，每个token实际激活37B参数，预训练token数达到14.8万亿。相较于模型规模的提升，报告中更值得关注的是两处工程优化：负载均衡不再依赖辅助损失，改为通过调整偏置项实现；训练目标中加入多token预测机制。报告给出的训练总成本为2.788M H800 GPU小时，并明确声明整个训练过程未出现不可恢复的损失波动，也没有回滚训练进度。将训练稳定性作为对外交付的指标，在此前的大模型技术报告中并不常见。

第二次升级聚焦后训练侧：核心主张是推理能力可以通过纯强化学习激励实现，无需人工标注的推理轨迹；训练过程中出现了自省、验证与策略切换等行为，其中一部分是训练的直接结果。该报告还提到一个容易被忽略的结论：大模型上涌现的推理模式可以系统地蒸馏给更小的模型，这意味着可以将昂贵的强化学习训练集中在少数大模型上，再将学习到的行为传递给一批小模型，比让每个尺寸的模型单独进行强化学习更具成本效益，后续该系列小尺寸模型的推理能力大多基于该逻辑实现。

同期的多模态支线也完成了方法升级：将理解与生成两条路径的视觉编码解耦，保持主干网络统一，理由是两类任务对视觉信息粒度的要求不同，共用编码器会影响理解侧的表现；后续进一步将整流流纳入语言模型框架，证明生成式建模可以直接在主干网络内训练，无需专门修改架构。到2024年12月发布的多模态模型，语言侧的专家路由与多头潜在注意力机制被完整迁移到视觉语言模型中，视觉侧改为动态切图处理不同长宽比的高分辨率输入，三个变体的激活参数分别为1.0B、2.8B与4.5B。

稀疏化技术的全面落地（2025年）

2025年这条路线同时在两个方向推进：一边持续优化稀疏化技术，一边扩展可验证的奖励信号来源。稀疏化方向分为三条互不重叠的技术轴，其中两条在这一年完成落地；奖励信号方向则更换了两种供给方式。

第一条技术轴是上下文稀疏化：2月发布的方案提出可以在预训练阶段端到端训练的稀疏注意力机制，将粗粒度的token压缩与细粒度的token选择结合为层级结构，算法设计与硬件特性对齐。该方案的核心卖点不是性能提升，而是在不降低通用基准、长上下文任务与指令推理表现的前提下，节省算力与带宽。与多头潜在注意力机制不同，该机制优化的是每个token需要参与的计算量：跳过注意力矩阵中无关的位置，无需进行相关计算，节省算力与内存带宽。两者结合才是长上下文推理变得可负担的完整原因：一条负责压缩缓存占用，一条负责减少计算量。稀疏注意力的工程难点在于跳过的位置不规整，需要配套的内核实现将不规则内存访问转化为高效的批量操作，这也是该报告强调“按硬件特性对齐”的原因。

该技术在2025年9月正式落地产品，官方发布说明显示其在原有版本基础上引入该稀疏注意力机制，训练配置与上一代保持一致，验收标准为相同配置下模型质量不下降，同时API价格下降50%以上。到同年12月的更新版本中，稀疏注意力正式成为主干网络的一部分，该版本的三项核心变化为：稀疏注意力机制、可扩展的强化学习框架、大规模智能体任务合成管线。

奖励信号方向的第一个升级是奖励扩展：通用问题没有标准答案，无法像数学题那样使用可验证的奖励，因此提出逐点生成式奖励建模加SPCT训练方法，通过并行采样与元奖励模型投票消耗推理算力。报告显示这种扩展方式可以优于单纯扩大训练算力的方案，同时也承认部分任务仍存在难度。第二个升级是将“可验证”的标准向上提升一层：不再奖励最终答案，而是训练一个评判推导质量的验证器，用其作为奖励模型来训练出题与推导模型，并通过扩展验证算力持续生产高难度样本。报告成绩显示，该模型在相关国际赛事中达到金牌水平。

形式化推理线的发展更能体现这一趋势：基于Lean的可验证反馈进行强化学习，在相关基准上取得较高准确率；后续更换为递归推导流水线合成冷启动数据，再训练统一的推理模型，准确率进一步提升，同时发布了包含325道形式化题目的测试集。

精细化单位成本控制（2026年）

进入2026年，这条路线的度量标准发生了变化：以前关注的是上下文窗口长度，现在转向每个token需要分摊的FLOPs与字节数。

1月发布的方案将稀疏化技术拓展到计算之外：将N-gram查询升级为可扩展的条件记忆模块，与专家路由机制并列成为第二条稀疏化技术轴，并给出两者容量分配的U型缩放规律。在相同参数与FLOPs约束下，扩展后的模型在多个基准上取得明显提升，长上下文检索的准确率也得到显著改善。机制分析显示，将局部依赖交给查询模块后，注意力容量被释放给全局上下文，浅层网络也无需再重建静态模式。

4月发布的预览版同时提升了模型规模与上下文窗口：Pro版本总参数1.6T，每个token激活49B参数；Flash版本总参数284B，每个token激活13B，均支持百万token上下文窗口，预训练token数超过32T。架构上进行了三处改进：混合注意力机制、流形约束的超连接、新型优化器，分别对应长上下文处理、残差连接的表达能力与训练稳定性，收益来自多处改进的叠加而非单点突破。效率对照显示，在百万token设置下，Pro版本的单token推理FLOPs仅为上一代的27%，KV缓存占用仅为10%。

9月发布的更新版本将成本核算细化到字节级别：主干网络552B参数，解码时每个token激活16B参数，预填充时仅激活8B参数，同一模型可根据负载形态动态分配算力；KV缓存侧采用两层压缩技术，跨层复用加低精度缓存，将常驻高速显存的占用压至每个token 890字节，预训练语料为45T token的多模态数据。

这两代版本的差距还有一个容易被忽略的来源：训练与评测环境本身。9月发布的报告详细介绍了智能体训练的沙箱平台：单个生产单元约160个节点，每天服务约300万个沙箱，支持超过38万个并发沙箱与每秒5000次以上的创建；沙箱可保留长交互的状态，将rollout执行与可抢占的GPU训练解耦，镜像按需从分布式文件系统加载。报告明确将智能体越界行为列为需要缓解的问题。同期发布的开源智能体框架则提示了该路线2026年的重心：模型的交付形态中增加了一层执行框架。

多模态技术的并行探索

除语言主干外，这条路线还长期并行发展多模态技术，几代版本之间的核心问题指向非常明确：视觉信息应该以何种粒度进入模型。

理解侧的优化方向是细化输入粒度：训练数据覆盖网页截图、PDF、OCR与图表，用真实场景的用例分类体系构建指令微调数据，视觉编码器采用混合结构处理1024×1024输入，在分辨率与算力之间寻找平衡。后续版本将语言侧的专家路由与多头潜在注意力完整迁移到视觉语言模型中，视觉侧改为动态切图，不同长宽比的图片不再被强制压缩为统一比例，而是按内容切分为若干块分别编码，三个变体的激活参数分别为1.0B、2.8B与4.5B，验证了按需分配算力的思路。

生成侧的优化方向是解耦两件任务：认为理解与生成对视觉信息的粒度要求不同，共用编码器会影响理解侧表现，因此将编码路径解耦但保持主干网络统一；后续进一步将整流流纳入语言模型框架，用连续生成替代离散token自回归，证明生成能力可以在同一主干网络中训练，无需单独构建架构。2025年1月的更新版本未修改架构，仅放大了训练策略、数据规模与模型参数。

后期还出现了第三条技术路径：将长文本渲染为图像，再用视觉token解码，压缩比与解码精度之间存在明确的量化关系。后续版本更换了编码器的行为方式，让视觉token按图像语义重排而非固定逐行扫描，从成本角度解决了上下文中文本的token表示问题。

三项核心成本的整体演进

回顾五阶段的成本数据，可以看到一条并不平滑的演进曲线。训练成本在2024年5月首次以相对值形式公布，2024年底以绝对值形式明确，之后不再单独作为核心卖点。KV缓存的改进幅度最大：2024年5月相对基准模型减少93.3%，2026年4月相对上一代降至10%，2026年9月更是给出了每token 890字节的量化指标。生成吞吐仅在2024年5月出现过一次明确的倍数对比，之后被整合到长上下文与部署成本的叙述中。

三项成本的可见度差异较大，背后的原因可能是报告的受众需求不同：2024年的读者需要被说服稀疏架构的价值，因此成本数据是核心卖点；2026年的读者已普遍接受稀疏架构，卖点回归能力档位，成本被压缩为少数效率指标。

但直接横向对比这三项成本是不准确的，它们的基线分别为同系列67B模型、上一代V3.2版本与V4-Flash版本，对应的上下文长度、批次与硬件均不相同。它们能体现的是同一条路线内部的趋势：每一代版本都在缩小“每个token的成本”这一分母，再用节省下来的预算换取更长的上下文窗口、更多的后训练算力或更大的模型规模。

将27%与10%这两个比例拆解来看会更清晰：在百万token的设置下，单token推理FLOPs降至上一代的四分之一左右，KV缓存占用降至十分之一。两者的下降幅度并不一致，缓存压缩的效果更明显，这说明压缩缓存比压缩计算更容易见效——无需修改模型的输出逻辑，仅需调整存储内容即可。

至于节省的预算具体转化为哪些能力，有两次公开的转换节点：一次是V4版本将上下文窗口从128K级提升至百万级；另一次是V3.2版本将算力投入到后训练与智能体数据合成。这两次都属于“用效率换取能力”的操作，但论文未拆分效率增益与能力增益的因果关系，仅能确认时间上的关联性。

奖励信号的演进路径

如果仅关注模型规模，2025年的路线更像是稀疏化的一年；但单独看待后训练部分，其实是在解决另一个核心问题：奖励信号从何而来。

最早的奖励信号来自人类标注的推理轨迹。数学专用模型通过GRPO算法在数学题上进行强化学习，奖励来自可自动判定的答案，该逻辑在数学领域成立，因为答案的对错可以被快速验证。R1系列将该逻辑推广到通用推理场景：训练信号来自可验证任务的结果，无需人工编写思维链。但该主张的代价也很明确：仅在可验证任务上有效。

接下来的两年间，该路线一直在扩展“可验证”的边界。奖励建模方法补充了不可验证的通用问题：先让模型学会生成原则与批评，再通过并行采样与投票消耗推理算力。自验证方法将评判标准从最终答案转移到推导过程：训练一个能识别推导缺陷的验证器，并随着生成器的能力提升扩大验证算力。形式化推理路线则更为彻底，Lean 4本身就是验证器，人类仅需提供定理描述。到V3.2与沙箱平台版本，扩展的对象转向执行环境：合成的智能体任务、可反复回放且不泄露状态的沙箱，都让“对错”可以被自动判定。

将这些方法放回训练目标中来看，该路线的后训练其实一直在弥补同一个短板：验证信号的供给。数学、代码与形式化推理是可验证任务最集中的三个领域，这也是该路线在这些方向上报告最多的原因，但代价是这些成绩对通用任务的代表性有限。

观察GRPO算法可以更清晰地看到该转向的逻辑：传统PPO需要价值网络来估计基线，价值网络本身需要训练并占用显存；而GRPO通过对同一问题采样多组答案，用组内得分的相对高低作为优势信号，直接省去了价值网络。节省的资源可以用于更多采样、更多训练数据与更长的训练周期。该路线的算法改进几乎都朝着同一个方向：用可自动判定的样本替代人工成本与额外模型。

现有研究的未解决局限

本文中的所有数据均来自公开报告与发布说明，这决定了它们能回答的问题范围。以下几个方向，该路线至今未提供公开证据。

首先，没有跨厂商的同协议对照。部分报告声称自身表现与其他顶级模型相当，甚至超过后者，但所有评测设置均由发布方设定，无法进行独立验证。其次，没有公开的复现材料：数据配方、强化学习环境、评测脚本均未公开，仅公布了参数规模、token数与GPU小时数，无法完整复现训练过程。第三，没有失败统计：所有报告仅发布最终指标，未提及失败率与失败模式，仅少数报告提到了需要缓解的问题，间接说明实际系统中存在优化缺口。第四，没有跨规模外推：多数改进的验证仅停留在特定参数规模，未给出更大或更小规模上的验证结果。第五，未拆分工程技巧与能力提升：推理期的自洽采样、树搜索、测试时扩展等手段，常与模型本身的能力出现在同一组数据中，无法明确区分哪些提升来自模型架构，哪些来自推理优化。

还有一个口径问题值得单独说明：该路线的报告习惯将自家上一代版本作为基线，“提升”与“不降”的结论常出现在同一张表格中。例如某版本的验收标准为相同配置下模型质量不下降，这是一次成功的技术替换而非能力跃升，若误读为性能提升会误判该版本的实际价值。

总结

将这条路线简单理解为“三年发布十几次模型”会忽略其内在结构。根据公开证据梳理，该路线更像是三个同时推进的工程：

架构侧负责降低每个token的成本：多头潜在注意力管理缓存占用，专家路由管理计算量，稀疏注意力与跨层复用管理上下文开销，条件记忆模块将部分知识从计算中剥离，每一项技术都对应一项核心成本的优化，共同缩小单位token的成本分母。

后训练侧负责扩大可验证任务的供给：从GRPO算法到纯强化学习，从生成式奖励建模到自验证，从环境沙箱到智能体任务合成，所有手段都在让更多任务可以被自动判定对错。

基础设施侧负责支撑前两项工程的规模化落地：训练集群、低精度训练栈、分布式文件系统、沙箱平台等技术，虽未直接出现在能力榜单中，但却是前两项工作的前置条件。

这三条路线并不总是同步：2024年架构侧的成本优化先落地，后训练方法在2025年初才完成换代；2025年后训练算力的扩张反过来对基础设施提出新要求，推动了沙箱与调度系统的发展。将三条线分开梳理，比按发布时间排队更能看清每篇报告的核心目标。

三者之间是接力而非替代的关系：稀疏化只有在专用内核与集群配套到位时才能兑现价值；后训练的规模只有在rollout环境能支撑时才能成立。这也解释了为什么该路线的报告中总有一篇看似“跑题”的系统论文。

至于未来的发展方向，本文能给出的唯一明确判断是：长上下文的竞争点已经从“支持多长”转向“每个token摊多少字节”，V4.1-Flash的890字节与沙箱平台的并发指标都属于这类工程指标。至于这些指标能否转化为外部可验证的能力提升，还需要等待独立的评测材料出现才能确认。

将三条路线结合来看，还有一个容易被忽略的推论：该路线的技术选择高度依赖自身的工程条件。多头潜在注意力与稀疏注意力的收益需要专用内核兑现，KV缓存的极致压缩需要自建的推理栈承接，智能体后训练需要自研的沙箱平台支撑。这些做法能否在其他场景复制，取决于对方是否具备同等的系统级投入，而非仅取决于论文的文字描述，这也是本文区分“机制可读”与“可复现”的现实依据。

参考资料

[1] DeepSeek-V2: https://arxiv.org/abs/2405.04434

[2] DeepSeek-Coder: https://arxiv.org/abs/2401.14196

[3] DeepSeek LLM: https://arxiv.org/abs/2401.02954

[4] DeepSeekMoE: https://arxiv.org/abs/2401.06066

[5] DeepSeekMath: https://arxiv.org/abs/2402.03300

[6] DeepSeek-Prover: https://arxiv.org/abs/2405.14333

[7] Fire-Flyer AI-HPC: https://arxiv.org/abs/2408.14158

[8] DeepSeek-Coder-V2: https://arxiv.org/abs/2406.11931

[9] DeepSeek-V3: https://arxiv.org/abs/2412.19437

[10] DeepSeek-R1: https://arxiv.org/abs/2501.12948

[11] Janus: https://arxiv.org/abs/2410.13848

[12] JanusFlow: https://arxiv.org/abs/2411.07975

[13] DeepSeek-VL2: https://arxiv.org/abs/2412.10302

[14] Native Sparse Attention: https://arxiv.org/abs/2502.11089

[15] DeepSeek-V3.2-Exp: https://api-docs.deepseek.com/news/news250929

[16] DeepSeek-V3.2: https://arxiv.org/abs/2512.02556

[17] DeepSeek-GRM: https://arxiv.org/abs/2504.02495

[18] DeepSeekMath-V2: https://arxiv.org/abs/2511.22570

[19] DeepSeek-Prover-V1.5: https://arxiv.org/abs/2408.08152

[20] Prover-V2: https://arxiv.org/abs/2504.21801

[21] Insights into DeepSeek-V3: https://arxiv.org/abs/2505.09343

[22] DeepSeek-OCR: https://arxiv.org/abs/2510.18234

[23] Engram: https://arxiv.org/abs/2601.07372

[24] DeepSeek-V4: https://arxiv.org/abs/2606.19348

[25] V4.1-Flash: https://arxiv.org/abs/2609.19969

[26] DSec: https://arxiv.org/abs/2609.22978

[27] DeepSeek Harness: https://github.com/deepseek-ai/deepseek-harness

[28] DeepSeek-VL: https://arxiv.org/abs/2403.05525

[29] Janus-Pro: https://arxiv.org/abs/2501.17811

[30] DeepSeek-OCR 2: https://arxiv.org/abs/2601.20552