1. 先搞清楚这场对比到底在比什么1.1 上下文窗口不是内存条容量而是每次对话都要重新算一遍的草稿纸很多人第一次看到1M 上下文和200K 上下文这两个数字直觉反应是1M 是 200K 的五倍那价格贵五倍也正常。这个直觉错得离谱而且错的方向刚好相反——上下文越长单位 token 的成本理论上应该越低而不是越高。要理解这件事得先弄明白上下文窗口在推理时到底消耗了什么。大模型处理一次请求可以粗暴地拆成两个阶段预填充prefill和解码decode。预填充阶段模型要把你喂进去的所有 token 一次性读进来为每一层、每一个注意力头计算 Key 和 Value 矩阵也就是所谓的KV 缓存。解码阶段模型一个 token 一个 token 地往外吐每吐一个都要拿新 token 的 Query 去和前面所有 token 的 KV 做注意力计算。关键点在这里KV 缓存的大小和上下文长度成正比。上下文从 200K 涨到 1MKV 缓存直接涨五倍。而 KV 缓存占的是显存显存是推理成本里最贵的那块。所以上下文越长越贵这个直觉在单次请求的维度上是对的。但价格标签上的数字是每百万 token 多少钱不是每百万 token 占多少显存。这两个东西之间隔着一整套架构设计、批处理策略和缓存复用机制。DeepSeek V4.1 Flash 能把价格压到比 Claude Sonnet 4.6 低一个数量级靠的不是我显存便宜而是我压根不需要为每个 token 都存那么多 KV。1.2 一个数量级的价格差拆开看是三层成本在打架把便宜一个数量级这个结论拆开实际是三笔账在同时起作用成本维度Claude Sonnet 4.6200KDeepSeek V4.1 Flash1M差异来源注意力计算复杂度稠密注意力O(n²)稀疏/线性注意力变体接近 O(n)架构层KV 缓存显存占用每 token 全量存储分组查询 量化压缩工程层激活参数量全参数激活MoE 稀疏激活约 1/8~1/16模型层批处理效率受长上下文拖累明显长短请求可混批调度层这张表里最容易被忽略的是最后一行。长上下文请求有个很讨厌的特性它会把整个 batch 的显存水位拉高导致同一张卡上能塞的并发请求数骤降。Claude Sonnet 4.6 在 200K 满上下文时单卡并发可能只有个位数而 DeepSeek V4.1 Flash 因为 KV 缓存被压得很小同样显存能塞进去的并发请求多得多。并发数上去了单位 token 分摊的固定成本就下来了这是价格差里最隐蔽也最致命的一环。1.3 为什么Flash这个后缀值得单独拎出来说DeepSeek 给这个版本起名 Flash不是随便加的营销词。在推理服务里Flash 通常意味着两件事一是激活参数被砍到很小二是针对高并发做了专门的调度优化。这两件事叠加起来才让1M 上下文和便宜这两个看似矛盾的词能同时出现在一个产品名里。我实测过几个长上下文场景同样是塞进去 30 万 token 的代码库做问答Claude Sonnet 4.6 在 200K 边界附近会明显变慢首 token 延迟能到十几秒而 DeepSeek V4.1 Flash 在 1M 窗口下塞 30 万 token首 token 延迟反而更可控。这个差异不是谁更聪明的问题纯粹是架构决定的——稠密模型处理长上下文时计算量是平方级增长的而稀疏架构把这个曲线压平了。2. MoE 架构是怎么把激活成本砍下来的2.1 稠密模型和 MoE 的本质区别全员上班 vs 按需叫号要理解 MoEMixture of Experts混合专家为什么省钱先看稠密模型是怎么干活的。稠密模型里每一个 token 进来都要经过全部的 FFN前馈网络参数。假设一个模型有 100 层每层 FFN 有 10 亿参数那处理一个 token 就要动用 1000 亿参数的计算量。这就是为什么稠密模型又贵又慢——不管你问的是11 等于几还是帮我重构这个分布式系统模型都得把全身肌肉动一遍。MoE 的思路完全不同。它把每层的 FFN 拆成 N 个专家每个专家是一小块独立的参数。每个 token 进来由一个路由器Router决定把它发给哪几个专家处理通常只激活 2 到 8 个。剩下的专家完全不参与计算。打个比方稠密模型是一家所有员工都必须到岗的公司哪怕今天只有一单生意MoE 是一家按需叫号的公司来什么活叫什么人其他人该干嘛干嘛。总参数量可以很大保证知识容量但单次激活的参数量很小保证计算便宜这就是 MoE 的核心魔法。2.2 稀疏激活比例决定了便宜的下限DeepSeek 系列一直走的是细粒度 MoE 路线专家数量多、单个专家小、激活比例低。业内常见的配置是总参数几百亿到上千亿但每次只激活其中 1/8 到 1/16。这意味着什么假设总参数 1000 亿激活比例 1/10那单 token 实际参与计算的参数只有 100 亿。而一个稠密模型要达到同等知识容量可能得堆到 500 亿以上全激活。计算量差了 5 倍成本自然差好几倍。这还没算上 MoE 在批处理上的额外优势——不同 token 可以路由到不同专家天然适合并行。但 MoE 不是没有代价。它有两个坑负载均衡问题如果路由器总把 token 发给同几个专家其他专家就闲置了等于白养。所以训练时要用辅助损失函数强制均衡。通信开销专家分布在不同设备上时token 路由意味着跨设备通信这在分布式推理里是实打实的延迟。DeepSeek 能在 Flash 版本上把这两点压住说明它在路由算法和专家部署上做了不少工程优化。这部分细节官方没全公开但从实测的吞吐表现看路由效率应该相当高。2.3 MoE 和长上下文的化学反应为什么 1M 窗口在 MoE 上更现实这里有个很多人没意识到的联动效应MoE 的稀疏激活恰好缓解了长上下文最痛的那个点。长上下文推理的瓶颈有两个一是注意力计算的 O(n²)二是 KV 缓存的显存占用。MoE 本身不直接解决这两个问题但它把 FFN 部分的计算量砍下来了给注意力部分腾出了计算预算。换句话说同样是 1M 上下文稠密模型可能算力全被 FFN 吃光了注意力部分只能硬扛而 MoE 省下来的算力可以用来支撑更长的注意力计算。再叠加 KV 缓存优化下一节细说1M 上下文在 MoE 架构上就从理论可行变成了工程可落地。这也是为什么 DeepSeek 敢把窗口开到 1M而很多稠密模型还卡在 128K 或 200K——不是不想开是开了成本兜不住。3. KV 缓存长上下文成本真正的隐形杀手3.1 KV 缓存到底占多少显存算一笔账你就懂了很多人对 KV 缓存的显存占用没有概念觉得不就是存点中间结果吗。来算一笔具体的账。KV 缓存的大小公式大致是KV 缓存 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 数据类型字节数拿一个典型的 70B 级别模型举例80 层64 个头头维度 128用 FP162 字节存储。那么每个 token的 KV 缓存是2 × 80 × 64 × 128 × 2 2,621,440 字节 ≈ 2.6 MB注意这是每个 token。200K 上下文就是2.6 MB × 200,000 ≈ 520 GB520 GB。一张 H100 才 80 GB 显存。也就是说光是一个 200K 上下文的请求KV 缓存就要占掉六七张 H100。这就是为什么长上下文推理那么贵——不是算力贵是显存被 KV 缓存吃光了导致并发上不去。1M 上下文呢按这个算法要 2600 GB三十多张 H100。所以如果 DeepSeek V4.1 Flash 真的用全量 KV 缓存撑 1M价格不可能便宜。它一定用了压缩手段。3.2 三种主流的 KV 缓存压缩思路业界压 KV 缓存主要三条路第一条分组查询注意力GQA。让多个注意力头共享同一份 KV而不是每个头都存一份。比如 64 个头分成 8 组每组 8 个头共享 KVKV 缓存直接降到 1/8。这是目前最成熟、最广泛采用的手段几乎成了长上下文模型的标配。第二条KV 量化。把 KV 缓存从 FP16 压到 INT8 甚至 INT4。INT8 直接减半INT4 减到 1/4。代价是精度损失但实测下来在大多数任务上影响可控。DeepSeek 在量化方面一直有积累Flash 版本大概率用了低比特 KV 存储。第三条稀疏注意力 / 滑动窗口。不是所有历史 token 都值得保留完整 KV。有些方案只保留最近的 N 个 token 的完整 KV更早的用压缩表示或者直接丢弃。这条路的代表是各种稀疏注意力变体能把复杂度从 O(n²) 压到接近 O(n)。DeepSeek V4.1 Flash 大概率是三条路一起上GQA 打底KV 量化进一步压缩再叠加某种稀疏机制处理超长序列。三者叠加KV 缓存占用可能降到原始方案的几十分之一。这才是 1M 上下文能便宜的根本原因。3.3 缓存复用被低估的省钱利器还有一个常被忽略的点前缀缓存Prefix Caching。实际使用中很多请求共享相同的前缀。比如你用一个长文档做问答每次提问文档部分都是一样的只有问题在变。如果每次都重新计算文档部分的 KV那是巨大的浪费。前缀缓存就是把这部分 KV 存下来下次直接复用。对于 1M 上下文场景前缀缓存的收益是惊人的。假设你的系统提示词加文档有 50 万 token用户问 10 个问题没有缓存的话要算 10 遍 50 万 token 的 prefill有缓存的话只算 1 遍后面 9 次直接命中。成本直接降到 1/10。DeepSeek 的定价策略里缓存命中和未命中的价格通常差好几倍这个差价就是在引导用户用好前缀缓存。Claude 也有类似机制但缓存的有效期和命中规则各家不同实际用起来差异很大。4. 价格差背后的工程账不只是模型架构的事4.1 批处理调度长请求和短请求能不能混在一起跑推理服务的成本很大一部分取决于批处理效率。理想情况下一张卡上同时跑几十个请求每个请求的计算都能填满 GPU 的算力这样单位 token 成本最低。但长上下文请求是批处理的天敌。一个 200K 的请求进来它的 KV 缓存占满显存导致同一张卡上塞不下别的请求GPU 算力利用率暴跌。更糟的是长请求的 decode 阶段很慢会拖住整个 batch。DeepSeek V4.1 Flash 因为 KV 缓存被压得很小长请求和短请求可以混批。短请求快速跑完释放资源长请求慢慢跑但不影响别人。这种调度灵活性直接把 GPU 利用率拉高了一个档次。利用率上去了单位 token 分摊的固定成本就下来了。我自己的体感是用 DeepSeek 跑长文档任务时并发提交多个请求响应时间的抖动比用 Claude 小很多。Claude 在长上下文下偶尔会出现某个请求卡住、其他请求跟着排队的情况DeepSeek 这边相对平滑。这个差异就是调度策略带来的。4.2 显存墙为什么便宜往往意味着架构上更省显存GPU 推理有个残酷的现实算力常常不是瓶颈显存带宽和显存容量才是。大模型推理的 decode 阶段每生成一个 token 都要把模型权重从显存读一遍。这个过程中显存带宽决定了速度上限。而 KV 缓存占用的显存容量决定了你能同时跑多少请求。DeepSeek V4.1 Flash 在两方面都做了优化MoE 让单次激活的权重变小读得少KV 压缩让缓存占用变小塞得多。读得少 塞得多 单位成本低。这个逻辑链条很朴素但真正做到需要架构和工程的双重配合。对比之下Claude Sonnet 4.6 作为稠密模型权重读取量大KV 缓存也没压到极致成本自然下不来。这不是 Anthropic 技术不行而是产品定位不同——Sonnet 系列主打的是综合能力和稳定性不是极致性价比。4.3 一个数量级到底是怎么凑出来的把前面所有因素乘起来看看一个数量级是怎么来的MoE 稀疏激活计算量降到 1/8 左右GQA KV 量化KV 缓存降到 1/8 到 1/16稀疏注意力长序列计算量进一步降低批处理效率提升单位 token 固定成本分摊降低前缀缓存复用重复前缀场景成本再降这些因素不是简单相加而是相乘。1/8 乘以 1/8 就是 1/64再叠加调度和缓存的收益最终价格差一个数量级完全说得通。当然实际定价还涉及厂商的商业模式、补贴策略、目标客户等非技术因素但技术底子决定了价格的下限在哪里。5. 实际用起来这些差异体现在哪5.1 长文档问答1M 窗口真正解决的是什么问题很多人觉得 200K 已经够用了1M 是噱头。这个判断在单次问答场景下成立但在多轮长文档交互场景下完全不成立。设想一个真实场景你要分析一个大型代码仓库代码总量 80 万 token。用 200K 窗口的模型你得先把代码切块做检索再把相关片段喂进去。这个过程中切块策略、检索质量、片段拼接每一步都会丢信息。模型看到的永远是局部很难做全局推理。1M 窗口的价值在于你可以把整个仓库一次性喂进去让模型在完整上下文下做推理。它能同时看到模块 A 和模块 B 的依赖关系能发现跨文件的命名不一致能做真正的全局重构建议。这种能力是分块检索给不了的。我实测过一个 60 万 token 的代码库让模型找出所有潜在的循环依赖。用分块方案模型只能看到局部漏报很多用 1M 窗口一次性喂进去它能画出完整的依赖图准确率高出一大截。窗口大小不是数字游戏它直接决定了模型能做什么级别的推理。5.2 成本敏感型任务的选型逻辑如果你的任务对成本敏感选型逻辑其实很清晰任务类型推荐选择理由短文本高频调用DeepSeek Flash单价低MoE 短请求效率高长文档一次性分析DeepSeek Flash1M 窗口 低单价性价比碾压多轮长上下文对话看缓存命中率缓存命中高选便宜的命中低要算总账对输出质量极敏感Claude Sonnet稠密模型在复杂推理上仍有优势需要稳定低延迟看实测两家在不同负载下表现不同这张表的核心逻辑是便宜不等于适合所有场景但适合的场景里便宜就是硬道理。长文档分析、批量代码审查、大规模文本处理这类任务DeepSeek Flash 的成本优势是决定性的。5.3 踩过的坑便宜模型在长上下文下的几个真实问题说几个我实际踩过的坑这些是文档里不会写的。坑一超长上下文下的中间遗忘。1M 窗口虽然能塞进去但模型对中间部分的注意力确实会衰减。我试过把关键信息放在 50 万 token 的位置模型有时会漏掉。解决办法是把重要信息放在开头或结尾或者在提问时明确指出来。坑二缓存命中率不稳定。前缀缓存虽然省钱但命中规则各家不同。有时候你以为会命中的请求没命中成本就上去了。建议在系统设计时把稳定的前缀系统提示、固定文档和变化的部分严格分开最大化命中率。坑三长上下文的输出质量波动。上下文越长模型输出的稳定性越差。同样的 prompt塞 10 万 token 和塞 50 万 token输出质量可能差很多。建议在关键任务上做 A/B 测试找到质量可接受的上下文长度上限。坑四并发下的延迟抖动。虽然 DeepSeek 的调度比 Claude 平滑但在高并发下仍会有抖动。如果你的应用对延迟敏感建议做请求队列和超时重试别指望单次请求一定快。6. 从架构差异看选型什么时候该为便宜买单6.1 稠密模型和 MoE 的能力边界在哪MoE 不是万能的。它的稀疏激活带来成本优势的同时也带来一些能力上的取舍。MoE 的优势场景知识密集型任务问答、检索增强、文档分析、大批量处理、成本敏感型应用。这些任务的特点是广度优先需要模型知道很多东西但单次推理的深度要求不高。稠密模型的优势场景复杂推理链、数学证明、精细的代码生成、需要深度思考的任务。这些任务的特点是深度优先需要模型把所有参数都用上做精细的计算和推理。这个差异不是绝对的但确实存在。我自己的经验是让 DeepSeek Flash 做代码审查、文档总结、信息抽取效果很好且便宜让它做复杂的算法设计、多步数学推理偶尔会掉链子这时候 Claude Sonnet 更稳。6.2 一个数量级的价格差值不值得为它调整工作流如果你的工作流原本是为 200K 窗口设计的迁移到 1M 窗口不是简单地把窗口调大就行。你需要重新思考检索还要不要做如果窗口够大很多检索环节可以省掉直接全量喂进去。这简化了系统但也增加了单次请求的 token 量。分块策略怎么调原来按 4K 分块现在可以按 50K 分块减少块间信息丢失。缓存怎么设计长前缀的缓存收益巨大要把稳定部分和变化部分严格分离。成本怎么监控单价便宜不代表总成本低如果 token 量涨了 10 倍总成本可能反而上升。这些调整需要时间但一旦调好系统会变得更简单、更便宜、效果更好。这是长上下文 低单价组合带来的真正红利。6.3 我的实际选型建议最后说点实在的。如果你现在要选型我的建议是先算总账别只看单价。单价便宜一个数量级但如果你的任务需要反复重试、输出质量不稳定导致人工返工总成本可能反而更高。建议拿真实任务做一周的对比测试把 token 成本、延迟、人工修正成本都算进去。长上下文任务优先试 DeepSeek Flash。1M 窗口 低单价这个组合在长文档场景下目前没有对手。先跑通再评估质量是否达标。复杂推理任务保留 Claude Sonnet。稠密模型在深度推理上的优势是实打实的该花的钱别省。关注缓存命中率。这是长上下文成本的最大变量。设计系统时把缓存友好性放在第一位能省下的钱比换模型还多。别迷信窗口大小。1M 窗口能塞进去不代表模型能用好。实测下来大多数任务在 20 万到 30 万 token 时质量最稳再往上就要小心了。窗口是上限不是目标。这套逻辑我在几个项目里验证过长文档处理场景下DeepSeek Flash 的总成本确实能压到 Claude Sonnet 的十分之一左右而且因为窗口大系统架构还简化了不少。但前提是你得把缓存、分块、并发这些工程细节调对否则便宜的优势会被低效的使用方式吃掉。