DeepSeek Flash缓存命中价降60%，输出价却只降11%。这篇从三条价格线出发，拆解KV Cache、prefill和decode三段成本的差异，再用三类业务和一份真实Token结构重算降价后的账单。

模型权重没有更新，回答质量仍可能明显下降。两份Anthropic复盘、一次GPT-5路由事故和一组Kimi部署测试表明，路由、推理预算、上下文管理、系统提示词与推理实现都会改变用户实际拿到的能力。

本文是「术语解构」系列之一。上一篇拆了KV Cache，这一篇换个模态，拆视频模型的计量单位：视频token。 文中价格与参数查证时间：2026年9月10日。视频模型定价变动频繁，请以火山方舟官网当日信息为准。 20帧/秒，字节也开始做实时视频了 据彭博援引知情人士报道，字节跳动正在准备一款基于Seedance路线的实时空间视频生成模型，目标约20帧/秒、约50毫秒延迟，面向直播、短剧、游戏和Pico头显，最快下个月发布。 基于这则消息推测： 第一，这不是正式发布的产品。没有公开演示，没有技术报告，也没有分辨率、GPU配置和价格。 第二，20帧/秒和50毫秒很可能是同一件事的两种说法。1÷20刚好等于0.05秒，也就是每50毫秒出一帧。它是帧间隔，还是你转头到画面变化的完整延迟，报道没说。 第三，实时不是新门槛。Google的Genie 3在2025年8月就做到了720p、24帧/秒的实时可交互世界；字节自己的Seaweed APT2在2025年6月也展示过24帧/秒的流式生成——8B模型在单张H100上跑736×416，升到1280×720要用8张H100。这次的新意，是字节把这条路线接到了Seedance和云端视频业务上。 那这条消息为什么还值得聊？ 因为视频一旦从“生成完再播放”变成“边生成边交互”，算力账就变了。 新闻里没有价格，但字节已经公开了视频怎么收钱：Seedance 2.0纯文生视频，720p大约1元1秒。同一家公司的文本模型，写一千字不到一分钱。 视频到底贵在哪？是每个token都贵得离谱，还是token太多？ 相对于单价和数量来说，单价只差几倍，数量差了几百倍。 一、一个视频token，等于1024个像素 一个视频token到底是什么 《token是什么》那篇讲过，文本模型的token大致对应一个字、半个词或一小段字符。视频模型的计费token不是这种语言单位。 火山方舟给出的估算公式是： 1 视频token用量 =（输入视频时长 + 输出视频时长）× 宽 × 高 × 帧率 ÷ 1024 这个估算公式的意思是，把每一帧画面切成一个个1024像素的小方块，一块算一个token——你可以把它想成一块32×32的小拼图。 文本token是切字，视频token是切图。 先划一条边界：这是计费上的折算关系，不代表Seedance内部真的把画面切成32×32的小块送进模型。模型内部还有视频编码器、潜空间压缩、patch划分这些环节，官方计费公式没有透露实现细节。顺便说明一下，本文后面所有token数字，说的都是计费口径。 拿Seedance 2.0的官方示例算一遍。生成一条15秒、720p、24帧/秒的视频，火山方舟的720p实际按1248×704计算： 1 15 × 1248 × 704 × 24 ÷ 1024 = 308,880 token 拆到更小的单位： 一帧：1248×704÷1024≈858个token 一秒（24帧）：858×24≈20,592个token 换成传闻里的20帧/秒：858×20≈17,160个token 这就是视频成本的起点——文本模型一次吐一个token，视频模型每秒要持续更新两万块画面。 有一点要先说明白：视频token是平台定的计费单位，一个视频token和一个文本token承载的信息完全不是一回事，不能拿两者比“信息量”。但计费单位既然定了，就可以比价格。 二、贵的不是单价，是数量 先看单价（查证于2026年9月10日，火山方舟价格页）： 模型 计费模式 单价 Seedance 2.0 纯生成（不含视频输入） 46元/百万token Seedance 2.0 视频编辑（含视频输入） 28元/百万token Seedance 2.0 Fast 纯生成 37元/百万token Seedance 2.0 Mini 纯生成 23元/百万token（720p约0.5元/秒） DeepSeek V4 Pro（文本，平时时段） 输出 6元/百万token Seedance 2.5的70元和42元目前只查到媒体对火山引擎公告的转述，没在价格页直接核到，所以后面的计算全部以Seedance 2.0为准。 ...

Astra的幻觉评测数字反复修改，问题延伸到了成绩背后的测试条件。从推理档位、工具框架到评分规则，看懂公开跑分能够支持什么判断，再决定怎样验证自己的工作流。

Astra的单价是Sol现行促销价的2.5倍，但不同任务的费用变化并不一致。沿着价格、用量和人工返工三笔账，判断模型升级是否值得。

前面这篇讲开源模型文件大小的时候提过，下一篇打算专门讲讲长上下文这件事——这两天把DeepSeekV4和Gemini3.5两家的官方资料翻了一遍，发现比预想的更有意思：两家都说自己能处理百万token上下文，但你要是想知道这个百万token是怎么算出来的，两家给你的答案完全不是一回事。 一家把压缩算法、参数规模全部摊开给你看；另一家官方文档翻遍了，架构只字未提，能查到的是精确到具体token数的输入输出上限、一套token计数工具，还有一份自己测出来的检索精度评测。两边都亮出了检索精度会随长度下降的数字，但用的不是同一把尺，也不能直接拿来比高低。 这篇不重复讲“标称窗口为什么会变笨”，也不重复讲“长上下文值不值得多付钱”，这两个问题在之前的文章中已经讲透了，也已经算过账。这一篇只问一件事：同样喊出百万token，这两家各自是怎么把这个数字做出来的。 DeepSeekV4：把压缩算法摊开给你看 DeepSeekV4的百万token上下文，是靠一套新的混合注意力架构换来的，官方模型卡把这套架构的名字、压缩比、代价都写清楚了。 V4系列有两个版本。V4-Pro总参数1.6万亿（1.6T），每个token激活49B；V4-Flash总参数284B，每个token激活13B。两个版本都支持100万token上下文。参数总量和激活参数量分开看这件事，V4能把百万token这件事扛下来，靠的不是激活参数堆得多，而是下面这套新注意力机制。 V3.2版本用的是多头潜在注意力（MLA）。V4把这套机制换成了两种压缩注意力交替使用的混合架构： 压缩稀疏注意力（CSA）：把KV条目压缩4倍，再配一个轻量级索引器，从压缩后的块里挑出跟当前token最相关的那部分去算，不是每块都算。 重度压缩注意力（HCA）：压缩比拉到128倍，但对所有压缩块做稠密计算，不做筛选，负责打底、抓全局粗粒度信息。 V4-Pro一共61层，前两层用HCA打底，后面的层里CSA和HCA交替搭配。两种机制都单独保留一个滑动窗口分支，专门处理最近几十到上百个未压缩的token，确保离得近的字不会被压缩糊掉——说白了就是“近的东西看原文，远的东西看压缩摘要，且摘要本身还分粗读和细读两档”。 DeepSeekV4 如何用 CSA + HCA 扛住 100 万 token 上下文 存储精度上也做了配合：大部分KV条目用FP8存，RoPE维度保留BF16精度，CSA里那个轻量索引器则跑在FP4精度上。压缩比和存储精度这两层叠加，才换来了官方给出的这组数字：跟V3.2比，V4-Pro单token推理FLOPs降到27%，KV Cache占用降到10%；V4-Flash的FLOPs降到10%，KV Cache降到7%。跟标准的8头分组查询注意力（GQA）比，V4所需的KV Cache大约只有2%。KV Cache这笔账具体是怎么吃显存的，《KV Cache：每读1个token，就要交一笔“显存税”》讲过原理，这里的2%就是这套压缩架构交出的成绩单。 压缩换来的代价：官方自己给出的检索精度衰减 这套账最难得的地方，是DeepSeek没有只报喜不报忧。官方用MRCR（一种在长文本里埋入多条语义相近的目标，测试模型能不能把每一条都分别精准检索出来，而不是随便捞中一条就算过关的测试）做了8-needle检索测试：256K token时，精度维持在0.82以上；到了100万token，精度降到0.59。 标称窗口不等于有效窗口：长上下文越接近顶端，检索精度越打折 这组数字很关键。它等于官方自己承认：标称窗口是100万，但窗口用到顶端的时候，检索能力是打了折扣的。这跟036讲的“标称窗口≠有效窗口”是同一类现象，只是这次不用靠第三方跑测试去发现，DeepSeek自己把这条曲线画出来了。换句话说，V4的百万token上下文，压缩换来的不只是显存省了，检索精度这笔代价也是明码标价的。 V4的这套架构还专门为Agent场景做了优化：多轮工具调用的对话里，会保留完整的推理历史，覆盖所有轮次；工具调用用专门的|DSML|特殊token加XML格式，减少解析出错的概率。这两条跟长上下文架构关系不大，但能看出官方设计这套压缩机制时，心里装的场景就是长链路Agent任务，不是单纯的一次性长文档问答。 Gemini3.5：数字给得很精确，机制一个字不说 翻Gemini3.5这边的资料，画风完全不一样——不是不给数字，是给的数字层级不一样。 先说确定的数字：Gemini3.5 Flash于2026年5月19日发布，输入上限1,048,576token，输出上限65,536token，知识截止到2026年1月。这两个数字不是随便凑的整数：1,048,576正好是2的20次方（也就是二进制里常说的1Mi），65,536是2的16次方。DeepSeekV4这边官方口径是1M输入、384K最大输出，写法上更接近产品宣传的“整数口径”。同样叫百万token，一个精确到二进制位，一个四舍五入到人类好记的整数——这本身就是两种“怎么算出来”的写法差异，字面意义上的。 架构层面，我把Google官方的模型列表页、模型卡、长上下文说明文档都翻了一遍，没有一处提到参数规模、dense还是MoE、用的什么注意力机制。这一点和DeepSeek形成明显反差。 但Gemini不是什么都不给。官方发布了一份专门的模型评测文档，里面用MRCR v2（同样是多针检索类测试，测的是模型能不能在长文本里把多条语义相近的目标分别精准找出来）测过长上下文检索能力：128K区间平均得分77.3%，扩展到1M token时，得分掉到26.6%。这个数字和DeepSeek自己报的“1M时0.59”用的不是同一套测试协议，样本、评分方式都不同，不能直接拿来比谁的模型更强，但能确认一件事：两家官方都承认，标称窗口用到顶端时，检索能力会明显打折，只是Google选择用自家的评测集把这个折扣量化出来，没有解释背后是什么机制导致的衰减。 Google官方还提供了一套token计数工具：调用前可以用countTokens先算出输入会占多少token；调用后返回的usage_metadata里，输入、输出、缓存内容、“思考”过程各自消耗了多少token都分开列出，连thinking token都单独计费统计。这套工具解决的是“我这次请求到底用了多少配额”，跟DeepSeekV4那套CSA/HCA混合注意力要解决的“这么长的历史怎么用更少的算力处理”，压根不是一回事——前者是计量工具，后者是压缩机制。Gemini的透明度，停在了计量这一层，没有再往下一层的机制说明。 context caching（上下文缓存）也在Gemini这边，标准档位下缓存写入每百万token 0.15美元，存储费每百万token每小时1美元；标准输入输出价格是每百万token 1.5美元和9美元。但这不是Gemini独有的招数——DeepSeek自己也有前缀缓存，V4-Flash缓存命中价是标准输入价的1/50 。所以“靠缓存省钱”不是两家的差异点，两家都有；真正的差异点，还是回到架构披露本身：DeepSeek解释了压缩机制怎么把计算量降下来，Gemini没有解释。 值得一提的是，Google不是从来不披露架构。2024年的Gemini1.5技术报告里，官方白纸黑字写过：1.5 Pro是稀疏MoE架构，top-2路由；1.5 Flash是从Pro蒸馏出来的稠密（dense）模型。这份报告是公开的一级信源，说明这类细节Google不是说不出来，只是3.x这一代选择不说了。至于Gemini3.5 Pro，目前官方模型列表里还查不到它的条目，第三方渠道流出的“200万token上下文+Deep Think模式”等说法，没有官方定价或规格页佐证，只能算未经证实的预览信息，不纳入这篇的确定性结论。 两本“怎么算出来”的账，对比着看 维度 DeepSeekV4 Gemini3.5 Flash 标称输入上限 100万token（官方口径，整数） 1,048,576 token（2的20次方） 最大输出 384K token 65,536 token（2的16次方） 注意力机制是否披露 披露：CSA+HCA混合注意力，替代V3.2的MLA 未披露 参数规模是否披露 披露：Pro 1.6万亿（49B激活）/ Flash 284B（13B激活） 未披露 KV Cache占用是否披露 披露：较V3.2降至7%~10%，较标准GQA约2% 未披露 长上下文检索精度评测 官方MRCR 8-needle：256K时≥0.82，1M时0.59 官方MRCR v2：128K时77.3%，1M时26.6%（协议不同，不可直接对比） 前缀/上下文缓存 有，V4-Flash缓存命中价为标准输入价的1/50 有，标准档缓存写入0.15美元/百万token+按小时存储费 Token计数工具 官方tokenizer，英文字符约0.3token、中文字符约0.6token 官方countTokens接口+usage_metadata，输入/输出/缓存/思考token分开计 DeepSeekV4 和 Gemini3.5：两本不同的百万 token 账 这对实际使用意味着什么 如果你要自建部署或者拿这两个数字去反推硬件门槛，两边能验证的东西不一样。 ...

国产办公Agent正在沿着办公生态、组织上下文和工程化Harness三条线同时演进。本文梳理WorkBuddy、DuMate、千问办公、豆包工作与Codex、Claude Code之间的路线差异。

前几天有个读者在后台丢给我两个数字，问我这俩是不是写错了。 一个是Qwen3.8-27B，权重文件55.6GB。另一个是Qwen3.8-Flash-Next，权重文件360GB。她说，都叫“开源模型”，怎么能差出这么多？是不是后者故意堆参数糊弄人？ 我先说结论：没写错，这俩数字都对，而且这个反差比表面看起来还要更反直觉——因为Flash-Next虽然文件是27B模型的六倍还多，但它每处理一个字，实际要算的参数反而比27B模型少得多。 这就是这篇要讲的事。开源、开放权重，这几个词只说明你能拿到权重文件，不说明你的电脑能不能跑，也不说明这个文件到底代表多大的计算量。文件大小、参数总量、实际算力，是三本不同的账，很多人下载模型前根本没意识到自己在算哪本账。 同样叫开源，文件大小先差在存储精度 权重文件说到底就是一堆数字，每个参数用几个比特存，直接决定文件多大。最粗但最好用的公式是： 模型权重体积 ≈ 参数量 × 每个参数占用字节数 常见精度可以这么估，我顺手把10B参数当基准算了一遍，方便对照： 格式 每个参数大约占用 10B参数大约多大 FP32 4字节 40GB FP16/BF16 2字节 20GB FP8 约1字节 约10GB GGUFQ8_0 约1.0字节（约8.5bit） 约10~11GB GGUFQ5_K_M 约0.7字节（约5.7bit） 约7GB GGUFQ4_K_M 约0.550.6字节（约4.54.9bit） 约5.5~6GB 这里需要注意的是，Q4不等于“精确4bit”。GGUF里的K-quant是混合精度，同一个模型里不同张量会用不同位宽，注意力层可能给得比前馈层更高。所以你会看到两个网站对同一个Q4_K_M模型报出来的体积对不上，不一定是谁算错了，很可能是量化配置本身就不完全一样，统计口径也不同。 精度换体积 4GB模型从哪来 标题里的4GB不是随便举的例子，它对应的是7B级模型的Q4_K_M量化文件——这一点必须先说清楚，因为它和后面要讲的360GB根本不是同一个模型的两个版本，是两种完全不同规模的模型分别在讲自己的量化区间，读到后面别把这两条线接错了。 拿一个7B模型算：FP16原始权重大约13.5到14GB，Q8_0量化后大约7到7.2GB，Q4_K_M量化后大约4到4.5GB。标题里的4GB，就是这么来的。代入前面那个公式对一下：7B乘以Q4_K_M大约0.55到0.6字节，约等于4GB，数字对得上。 这不是压缩包魔法，是用精度换体积，代价也很实在。量化越狠，文件越小，显存压力越低，但输出质量、长上下文稳定性、工具调用可靠性都可能受影响。聊天、摘要、轻量写作，4bit通常够用；代码、数学、结构化输出、长链路Agent任务，低比特量化的波动会更明显——这条不是绝对规则，但足够作为“要不要用更低量化”的第一道筛选标准。 所以严格说，“4GB的开源模型”这句话本身不太准确——准确的说法是“某个7B模型被量化到Q4_K_M之后是4GB”。模型本身没有一个固定体积，同一个模型换个精度存，体积能差出三倍多。 dense模型的文件大小，就是它的真实计算量 把这套账本套到Qwen3.8-27B上。 官方模型卡显示这是一个27B参数的语言模型，权重用BF16存储，HuggingFace上是18个分片，我直接用HuggingFace的文件列表接口把这18个分片的体积加了一遍，合计约55.6GB——和“27B乘以BF16的2字节约等于54GB”这个估算基本对得上，中间的零点几GB差异来自配置文件和一些非权重的小文件。 Qwen3.8-27B是个dense模型，处理每一个字的时候，27B个参数全都要参与计算。对dense模型，你可以先建立一个简单直觉：文件越大，通常参数越多；参数越多，每个字要算的矩阵乘法也越多；显存、速度、成本，基本是同步往上走的。关于dense和MoE的架构区别，账号之前在《本地模型别只看总参数：稠密和稀疏差别很大》中专门讲过，这里不重复。 这本账简单、直接，也符合大多数人对“模型越大越费资源”的第一直觉。麻烦的是下一节。 MoE模型的体积和计算量会分开 Qwen3.8-Flash-Next就是打破这个直觉的样本，而且打破得相当彻底。 官方口径：125B参数的主模型，另外还有51B的N-gram Embedding，每处理一个字只激活6B参数。这句话在Qwen官方GitHub仓库、官方X账号、LMSYS/SGLang官方技术博客三处表述一致。 架构上再细一层：这个MoE层一共有512个专家，每个token走top-10路由专家再加1个共享专家——这条数字在RadixArk的量化模型卡、LMSYS官方博客、以及第三方技术媒体CometAPI三处相互印证，可以采信。 125B加51B，官方通常说合计176B，但如果你去看HuggingFace模型卡的safetensors文件头，写的是180B。多出来的这4B，是打包进checkpoint里的一个叫MTP（Multi-Token Prediction，多token预测）的小模块，官方对外宣传时一般不把它算进主参数量，但它确实躺在权重文件里，占体积。所以176B和180B两个数字都没错，只是统计口径不一样。 再看体积。按vLLM官方部署文档，Flash-Next的BF16权重合计335.28GiB，FP8官方版本172.78GiB。这里提醒一个坑：GiB是1024进制，GB是1000进制，335.28GiB换算成十进制GB约360GB，你看到335GB和360GB两个说法，讲的是同一件事，不是两个版本，单位没统一而已。 关键在6B这个数字。文件里躺着176B（或180B）个参数，但每处理一个字，真正参与矩阵乘法的只有6B。剩下的参数去哪了？一部分是没被路由选中的“专家”，另一部分是那51B的N-gram Embedding。 Dense与MoE的计算差异 N-gram Embedding本质是一张查表，根据最近几个字做哈希查找，取出预先算好的向量，不涉及矩阵乘法。因为是查表不是计算，官方部署文档明确说这部分可以offload到host内存（也就是普通内存，不是显存），异步预取，并且给出了具体门槛：至少51GB host内存起步，再加运行余量。这个数字和51B参数按BF16存对应的体积基本吻合，也说明官方是把整张表原样放进了内存，不是又做了一轮压缩。这就是体积和算力脱钩的物理原因——它更像仓库里一整排档案柜，柜子占地方，但你查一份文件的时候不用把整排柜子都搬到桌上。 怎么从文件名反推自己的机器够不够 下载模型前，可以先做一个粗判断： 看到的格式 粗略估算 F16/BF16 每10B参数约20GB FP8 每10B参数约10GB GGUFQ8_0 每10B参数约10~11GB GGUFQ4_K_M 每10B参数约5.5~6GB MoE模型 总权重看下载/加载门槛，激活参数看单token计算量 这个表只够做第一眼判断，真正跑起来还有几块开销这张表没算进去。 ...

Qwen3.8-Flash-Next公布125B主体、51B N-gram Embedding和6B激活参数，看起来又是一次参数量对不上。核验官方模型卡、技术报告和SGLang/vLLM实现资料后发现：这次不是简单的命名游戏，而是要把参数拆成存储容量、激活计算量和查表记忆三本账。

拆解「一次AI提问=一瓶水/一度电」的真实出处，用Google首份官方实测报告、IEA最新数据重新算账：单次对话多便宜，训练和推理差多少，以及为什么便宜本身才是数据中心电力紧张的真正原因。