DeepSeek 端点换模后的缓存成本核算

10 月 17 日，DeepSeek 替换了 deepseek-flash API endpoint 背后的模型。名称没变，价格没变，也没有一条需要你去查看的更新日志——如果你的 Agent 在周五和周六分别调用了一次 deepseek-flash，它对话的其实是两个不同的 checkpoint，而且没人为此给你发过邮件。

新的 checkpoint 是 DeepSeek-V4.1-Flash-1017，已在 Hugging Face 上以 MIT 许可证发布，也是今天早上 Hacker News 的头条（我查看时有 903 分）。DeepSeek 称其为“一次小更新”。但它自己的 benchmark 表格并不支持“小”这个形容词：公布的 11 项 benchmark 全部上涨，Terminal-Bench 4.0 提升了 11.1 分，ProgramBench 提升了 8.8 分。这些是 DeepSeek 在自家评测框架上跑出的数字，我坐在自己的工位上没法复现 DeepSWE。我能做的是拉取第一手产物——实际的 config.json 和实际的文件大小——核查这件事里可以用算术验证的部分：KV cache 论文的标题是《将 KV Cache 压缩推向极限》，而相关报道里一直流传着“每个 token 的缓存占用为 890 字节”这个数字。所以，我根据 config 算了一遍。

config 到底写了什么

curl -s https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017/raw/main/config.json

关键字段如下：

num_hidden_layers      40
len(compress_ratios)   43        <- three more than the layer count
compress_ratios        {0: 5 layers, 2: 18 layers, 1: 20 layers}
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]   <- only four layers source long-range KV
index_topk             512
n_routed_experts       384,  num_experts_per_tok  6

权重大小则是根据 Hugging Face 上各个 blob 的大小加总得到的，没有采用任何人的汇总数据：

48 safetensors shards
510,296,708,312 bytes total = 510.3 GB (475.3 GiB)
downloads at fetch time: 10,233   likes: 1,216   created: 2026-10-17T02:40Z

其中，真正起作用的是三点。第一，只有一个共享的 KV head。第二，sliding window 为 128 个 token，这意味着无论上下文有多长，采用窗口机制的层，其缓存增长到 128 个位置后就会停止。第三，只有四个源层提供长距离 KV，在此基础上，每层还应用了各自的压缩比。

把假设摆出来，再算缓存

下面是完整的实验。以下每个数字都是在明确假设下得到的界限值，因为 config 告诉你的是结构尺寸，而不是推理服务栈的精确内存布局：

L = 43            # len(compress_ratios) from the config
head_dim = 512

# [A] every layer stores its own 512-dim latent KV per token, bf16
A = L * head_dim * 2
# [B] a vanilla MHA transformer of the same width, for scale
B = L * 64 * 80 * 2 * 2     # 64 heads x 80 dim, K and V, bf16
# [C] only the 4 kv_source layers store long-range KV, ratio-2 compressed
C = 4 * head_dim * 2 // 2

[A] every layer, 512-dim latent, bf16:  44,032 bytes/token -> 46.2 GB at 1M tokens
[B] vanilla MHA, same width:           880,640 bytes/token -> 923.4 GB at 1M tokens
[C] only 4 source layers, compressed:   2,048 bytes/token -> 2.15 GB at 1M tokens
[claim] 890 bytes/token:                                    -> 0.93 GB at 1M tokens

流传的 890 字节甚至低于我在最激进假设下算出的界限值，这意味着剩余的压缩效果来自低于 bf16 的量化精度，以及稀疏索引（index_topk: 512——模型只关注选中的一部分内容，而不是它存储的所有内容）。可以，听起来合理。但有一点，所有报道都没提到：对这种架构来说，每个 token 的字节占用不是常数，把它当作常数引用，是概念上的错误。对于采用 128 大小窗口的层，无论你的 prompt 是 8,000 个 token 还是 100 万个 token，它都只需要为 128 个位置付出缓存开销。把这笔开销摊一下：

window-only effective bytes/token at ctx=8,192:     688.0
window-only effective bytes/token at ctx=131,072:    43.0
window-only effective bytes/token at ctx=1,048,576:   5.4

同一个模型，同一套代码，“每个 token”的缓存开销却会因为测量时的上下文长度不同，相差两个数量级。得出 890 这个数字的人，一定是在某个特定长度、某种特定的层组合下测量的，而这个数字传播时，这两个条件都丢了。这并不意味着它是错的，而是说，它和 benchmark 分数一样，缺少必要的上下文——至少，这个数字还附带了一份可供核对的 config 文件，比那 11 行 benchmark 数据提供的信息更多。

价格是这篇论文的另一半

我今天核对了 DeepSeek 公布的 API 价格：未命中缓存的输入每百万 token 为 0.15 美元，输出每百万 token 为 0.60 美元，读取已缓存的输入每百万 token 为 0.003 美元。最后这个价格比例透露了关键信息：

1M uncached input: $0.15 | 1M output: $0.60 | 1M cached input: $0.003
cached input is 50x cheaper than uncached input

缓存读取便宜到五十分之一，说明厂商正在用定价告诉你：它提供缓存服务的成本确实很低——KV 压缩的成果体现在了价目表上，而不只是新闻稿里。DeepSeek 自己的 DeepSWE 图表（这里依据 The Decoder 的汇总）显示，新模型在最高设置下，每个任务的成本略低于 0.20 美元，同一张图表上的竞品则是 2～10 美元，相差 10～50 倍。这是厂商自己的图表、自己的评测框架，解读时要把这一点考虑进去。但这个方向与 config 所呈现的信息一致，而且 config 是公开的。

这次发布还带来了 Search and Fetch API，每 1,000 次成功请求收费 0.75 美元。在 10 月 31 日 16:00 UTC 开始计费之前，通过 DeepSeek Harness、Claude Code 和 Codex 的服务端工具使用可免费。DeepSeek 卖的已经不只是模型，也在卖 Agent 的眼睛。

我真正不喜欢的部分

上面这些都不是问题。问题出在交付方式：模型名称不变，背后的模型却悄悄换了。你上周针对 deepseek-flash 跑过的所有评测，如今描述的都是一个已经不再承接请求的 checkpoint。DeepSeek 确实发布了权重，也提供了带日期的 checkpoint 名称——仓库名里就写着 ...-1017——所以，固定版本并自行部署的路线完全可以复现。发生变化的只是那条方便的路线：你脚下的 API 别名指向变了。如果你会固定数据库和基础镜像的版本，却让模型跟着厂商的别名浮动，这次发布就展示了这种策略的代价：你得到的不是一个更差的模型——按所有已公布的指标来看，它都更好——而是一个与你测试过的模型不同的模型。

固定 checkpoint。读 config。算术本身就是这次发布的公告。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。