DeepSeek静默换模型：KV缓存算术才是真公告

DeepSeek 在没有任何变更日志、没有邮件通知的情况下，把 deepseek-flash API 端点背后的模型换成了新检查点 DeepSeek-V4.1-Flash-1017。同一个名字、同一个价格，周五和周六调用同一个端点，对话的其实是两个不同的模型。这件事在 Hacker News 上冲到了 903 分，但真正值得看的不是排行榜数字，而是那份公开的 config.json 里藏着的缓存算术。

DeepSeek 静默替换 Flash 模型

同一端点，两个检查点

DeepSeek^广告官方把这次更新称作“minor update”，但它自己发布的基准表并不支持这个形容词：11 项基准全部上涨，Terminal-Bench 4.0 提升 11.1 分，ProgramBench 提升 8.8 分。这些是厂商在自己的测试框架上跑出的数字，外部无法复现 DeepSWE 之类的评测。

可以复现的是另一部分：新权重以 MIT 协议挂在 Hugging Face 上，48 个 safetensors 分片，总大小 510,296,708,312 字节，约 510.3 GB（475.3 GiB）。模型仓库创建于 2026-10-17。检查点名字里的 -1017 就是日期，这意味着自托管路径完全可复现——真正被悄悄挪动的，只有那个叫 deepseek-flash 的便利别名。

KV 缓存（Key-Value Cache） 是 Transformer 推理时最占显存的结构之一。自回归生成时，每生成一个新 token 都要对之前所有 token 的注意力 Key 和 Value 做加权求和；若每次都重算，开销随上下文长度平方增长。缓存就是把历史 Key/Value 存下来复用，代价是显存占用随上下文线性膨胀。传统多头注意力（MHA）中，每层、每个 KV 头都要独立存一份，1M token 上下文的缓存动辄上百 GB，这是长上下文推理成本的主要来源。文章后面反复出现的“每 token 缓存字节数”“共享 KV 头”“滑动窗口”“KV 压缩”，本质上都是在回答同一个问题：如何在不让效果崩掉的前提下，把这块缓存压到可服务的规模。理解这一点，才能读懂为什么 config.json 里的几个字段比基准分数更值得看。

config.json 里的三个关键设计

拉取官方 config 后，几个字段决定了整个缓存故事：

num_hidden_layers      40
len(compress_ratios)   43        <- 比层数多三个
compress_ratios        {0: 5 层, 2: 18 层, 1: 20 层}
num_attention_heads    64
num_key_value_heads    1
head_dim               512
sliding_window         128
max_position_embeddings  1,048,576
kv_source_layer_ids    [2, 8, 14, 20]   <- 只有四层提供长程 KV
index_topk             512

三件事在真正干活：单一的共享 KV 头；128 token 的滑动窗口，意味着窗口层的缓存到 128 个位置后就不再增长，无论上下文多长；以及只有四层源层供给长程 KV，且每层还叠加了压缩比。再加上 index_topk: 512 的稀疏索引，模型只关注它存储内容中被选中的子集。

多头潜在注意力（MLA, Multi-head Latent Attention） 是 DeepSeek 系列模型降低 KV 缓存的核心手段，其思路是把 Key/Value 投影到一个低维 latent 空间再存储，推理时按需上投影回原维度，从而用远小于 MHA 的显存保存同等长度的历史。与之配套的还有 分组查询注意力（GQA） 与 多查询注意力（MQA）：前者让多个 Query 头共享一组 KV 头，后者极端到只保留一个 KV 头。文章 config 中 num_key_value_heads: 1 就是 MQA 形态的共享 KV 头。head_dim: 512 则说明单头维度远大于常见的 128，是在头数极少时维持表达力的补偿设计。compress_ratios 按层指定压缩比，kv_source_layer_ids 只挑四层供给长程 KV，这些都不是标准 Transformer 字段，而是该架构为缓存压缩定制的调度策略。

每 token 缓存字节数不是常数

流传甚广的说法是“每 token 890 字节缓存”，论文标题也叫《Pushing the Limits of KV Cache Compression》。但从 config 出发算一遍，会发现这个数字被引用的方式本身就有问题。

在明确假设下给出三个边界：

[A] 所有层都存 512 维 latent KV，bf16：  44,032 字节/token -> 1M token 时 46.2 GB
[B] 同宽度原版 MHA：                    880,640 字节/token -> 923.4 GB
[C] 仅 4 个源层、按 2 压缩：              2,048 字节/token -> 2.15 GB
[流传值] 890 字节/token：                              -> 0.93 GB

890 这个数甚至低于最激进的边界 [C]，说明 bf16 以下还有量化、外加稀疏索引在补足差额。合理，也说得通。但覆盖报道里没人提的一点是：对这个架构来说，每 token 字节数不是常数，把它当常数引用是范畴错误。 一个窗口为 128 的层，无论 prompt 是 8000 token 还是一百万 token，成本都是 128 个位置。做个摊销：

仅窗口层的等效字节/token：
ctx = 8,192       688.0
ctx = 131,072      43.0
ctx = 1,048,576     5.4

同一个模型、同一份代码，“每 token”缓存成本会因为测量上下文长度不同而相差两个数量级。890 的出处是某个特定长度、某种特定层混合下的测量结果，而数字传播时把这两个前提都丢了。这不代表它错，而是它不完整——不完整的方式和基准分数一样，但至少它附带一份可以核对的 config 文件。

滑动窗口注意力（Sliding Window Attention） 指每个 token 只关注前 W 个 token，而非全部历史，W 即 sliding_window。它的关键性质是：窗口层用于注意力的 KV 缓存上限固定为 W 个位置，超过 W 的旧 token 被移出窗口，缓存不再增长。这正是文章摊销表里窗口层“等效字节/token”随上下文变长而急剧下降的原因——总缓存近似恒定，除以越来越长的上下文，单位成本自然摊薄。也正因如此，把某个上下文长度下测得的“每 token 字节数”当作模型固有常数，在滑动窗口架构上并不成立。稀疏索引（index_topk: 512）则是另一层机制：模型不在全部存储中做稠密注意力，而是先选出得分最高的若干位置再计算，进一步限制了实际参与运算的 KV 规模。

价格表是另一半论文

DeepSeek 当前公布的 API 价格：未缓存输入每百万 token 0.15 美元，输出每百万 0.60 美元，缓存读取每百万 0.003 美元。

缓存输入比未缓存输入便宜 50 倍

50 倍的缓存读取折扣，本质上是厂商用价格告诉你：它的缓存服务成本确实极低。KV 压缩的工作体现在费率卡上，而不是新闻稿里。DeepSeek 自己的 DeepSWE 图表显示，新模型在最高设置下每任务略低于 0.20 美元，而竞品在同一图表上是 2 到 10 美元，相差 10 到 50 倍——厂商自己的图表、厂商自己的框架，看的时候心里要有数。但方向与 config 一致，而 config 是公开的。

这次发布还包含 Search 和 Fetch API，每 1000 次成功请求 0.75 美元，在 DeepSeek Harness、Claude Code 和 Codex 的服务端工具中免费使用，直到 10 月 31 日 16:00 UTC 开始计费。DeepSeek 卖的不再只是模型，还有智能体的眼睛。

真正该警惕的是交付方式

以上都不是问题所在。问题是交付机制：在模型名不变的情况下静默替换。你上周针对 deepseek-flash 跑过的所有评测，描述的都是一个如今已经不再服务流量的检查点。

DeepSeek 确实发布了权重和带日期的检查点名，自托管路径完全可复现。被悄悄挪动的只有 API 别名这条便利路径。如果你给数据库和基础镜像锁版本，却让模型在厂商别名上浮动，这次发布就是这种策略的账单：不是模型变差了——按所有公开指标它都更好——只是它不再是你测试过的那个。

锁定检查点，读 config。算术本身就是公告。

模型别名（model alias） 指 API 中以固定名称（如 deepseek-flash）对外暴露的端点，厂商可在后台把它指向任意检查点，调用方无感知。与之相对的是带版本号的检查点名（如 DeepSeek-V4.1-Flash-1017）或固定权重哈希，二者可精确复现。在工程实践中，这对应两类策略：一类追求“永远用上最新最好的模型”，接受行为漂移；另一类把模型当作基础镜像一样锁版本，保证评测、回归与线上行为一致。静默别名切换正是两类策略冲突的典型场景——它让依赖固定端点的评测、A/B 实验和合规审计全部失去参照系。业界常见缓解手段包括固定检查点名、记录权重哈希、在 CI 中对模型输出做快照回归测试，以及要求厂商提供变更日志与弃用窗口。