AREX Feed Article
vLLM 称 DeepSeek-V4.1-Flash 按 TCO 折算每美元 13 亿 token
10 月 17 日，DeepSeek 发布 DeepSeek-V4.1-Flash-1017（）。约 1 小时 43 分钟后，vLLM 项目的官方 X 账号发帖祝贺，并给出一组数字：在 SemiAnalysis AgentX 基准上，DeepSeek-V4.1-Flash 每 1 美元总拥有成本（TCO）对应 13 亿 token；在每用户 100 tok/s 的条件下，单 GPU 吞吐 83 万 tok/s（）。
帖文把缓存命中、输入和输出三类 token 加在一起，称这是「第一章」——自 Day 0 起 agentic 吞吐提升 5 倍，「下一章即将到来」。5 倍的说法来自 vLLM 10 月 7 日的 ：三周内 5.3 倍的吞吐提升，数据止于 10 月 2 日，比 -1017 的发布早半个月。
图 1：vLLM 公布的 SemiAnalysis AgentX 曲线，数据源标为 SemiAnalysis InferenceX。9 月 11 日至 10 月 2 日，GB300 NVL72，纵轴为每 chip 吞吐，横轴为 P90（90 分位）交互性；图中标注了每用户 155 tok/s 下 5.3 倍吞吐提升，以及最高交互性 1.9 倍提升。
一条祝贺帖里的四组数字
DeepSeek 的发布帖称：更强的基准表现、更快的任务完成、更短的输出，合起来是性能与成本上的帕累托改进。模型已上线网站、App 和 API，并针对 DeepSeek Harness、腾讯 CodeBuddy、WorkBuddy 做了优化；Harness 需要升级到 v0.2.1-rc.1 或更高版本。
vLLM 的帖子强调「输出更短」：基准分数更好、输出更短，适合长 agent 循环；让每一步变快，则是推理服务端的工作。帖文随后给出四组数字，分别回答每美元能处理多少 token、单 GPU 能推多快、每个用户能拿到多快，以及比 Day 0 快了多少。
跟帖把消除掉队者的工作拆成三层：GPU 侧的 wide-EP（大范围专家并行）与 EPLB（专家并行负载均衡器），CPU 侧的 all-reduce，前端侧的 NVIDIA Dynamo + Sidecar 与 KV 感知路由。
从 9 月 11 日到 10 月 2 日的那条曲线
writeup 的摘要给出了两组对比：在 DeepSeek-V4.1-Flash 发布后的三周里，Inferact 与 vLLM 社区把低并发下的速度提到此前的 1.9 倍，把 150 TPS（每秒 token 数）约束下的吞吐提到此前的 5.3 倍。曲线从 9 月 11 日，也就是图里的 Day 0，画到 10 月 2 日；在 GB300 NVL72 上，每用户 155 tok/s 的工作点处，每 chip 吞吐从 2.7 万升到 14.4 万 tok/s，曲线最右端（低并发）的最高交互性从每用户 311 升到 599 tok/s。
图表标题里标为 552B 的 DeepSeek V4.1 Flash 采用因果编码器-解码器（CED）架构，解码时每个 token 激活 160 亿参数，预填充只激活 80 亿；全局 KV 压到每 token 890 字节，滑动窗口 KV 以 FP8 保存每层最后 128 个位置。
vLLM 的滑动窗口注意力（SWA）有界重放在命中前缀时只重跑最后 128 个 token，解码时第 21～39 层也只处理这 128 个位置，长提示下跳过近一半模型；配合 CUDA graphs，预填充计算时间缩短 30%～40%。DeepSeek 放出的 MegaAttention、Mega-mHC、Mega-Gate、DeepSelect 被接进 vLLM，后者又做了一批融合，例如把 Mega-Gate 的 router 计算合成一次 launch，在中等 batch 下快 1.18～1.31 倍。
低延迟配置是 TP4 加 FlashInfer attention，高吞吐配置切到 DEP2：DP attention，专家分片到不同 GPU，会话亲和（session affinity）保住跨轮次的前缀缓存局部性。writeup 说，整个基准过程不需要把 KV cache 卸载到 CPU。
同一批优化也压低了首 token 时间。在 9.4 万 tok/s/chip 的吞吐下，P90（90 分位）的首 token 时间（TTFT）从 1.86 秒降到 0.32 秒，降幅 83%，图注称 5.8 倍。
图 2：同一数据窗口的 P90 首 token 时间与吞吐。9.4 万 tok/s/chip 处，TTFT 从 1.86 秒降到 0.32 秒，图注称 5.8 倍。
大头是缓存过的前缀
AgentX 的负载是多轮编码 agent 会话，基于真实的 agent trace 构建。vLLM 在时给出的数字是：会话中位数 43 轮，输入中位数 14.2 万 token，输出中位数 444 token，前缀缓存命中率高于 96%。每一轮都把最新的工具结果追加到上下文，再把整段内容发回模型。
这决定了 83 万该怎么读。帖文明确把缓存命中（cached）、输入（input）和输出（output）三类 token 相加；在这个负载里，绝大多数 token 是命中缓存的前缀，不是新生成的输出。每用户 100 tok/s 是生成速度，83 万是单块 GPU 每秒处理的缓存前缀、输入与输出之和。
TCO 用的是同一套口径。AgentX 把吞吐换算成「每 1 美元 TCO 的 token 数」，TCO 是建模的每 GPU 小时拥有成本，不是 API 报价。vLLM 在另一篇 AgentX 文章里举过具体数：SemiAnalysis 为 AMD Instinct MI355X 和 NVIDIA HGX B300 建模的 TCO 分别是 1.50 和 2.26 美元/GPU 小时，再据此把每小时吞吐折成每美元 token 数（）。
把两组数字放在一起回算：83 万 tok/s 运行一小时约 30 亿 token；若每美元要换到 13 亿，对应的每小时成本约 2.3 美元，和 B300 的 2.26 美元同一量级。这个数是按 GPU 小时成本折算出的每美元 token 数，不是标价。这些数字由 vLLM 一方测量并发布，基准来自 SemiAnalysis；上面的回算只校验两组数字是否自洽。
但 5 倍和 83 万不是同一个工作点：前者对应每用户 155 tok/s 的 10 月 2 日曲线，后者对应每用户 100 tok/s。帖文在给出这组数字时写的是「On DeepSeek-V4.1-Flash」，用的是不带日期的型号名。
三层栈上的掉队者
vLLM 文档说，混合专家（MoE）模型训练时通常会让每个专家拿到相近的 token 数，但实际推理中，token 在专家间的分布可能高度倾斜；EPLB 在每次前向时收集负载统计，定期把专家映射重新分配到 EP rank 上，把负载摊平。它还可以配置冗余专家，代价是占用显存（）。
在 EP 或 DEP（数据并行加专家并行）下，一次 batch step 要等最慢的 rank。某个专家分到的 token 过多，整批都会被它拖住；wide-EP 把专家铺到更多 GPU 上，摊薄单个 rank 的压力。帖文说，wide-EP 配 EPLB 后，「没有一块 GPU 拖住整批」。
CPU 侧的问题在 DEP 横向扩展时出现：帖文说，优化过的 CPU all-reduce 负责消除 CPU 掉队者。前端是第三层：NVIDIA Dynamo + Sidecar 接在 vLLM 原生 Rust 前端上，把 Python 的输出处理移出关键路径；KV 感知路由让请求落到持有相同前缀的实例上，减少重复预填充。
帖文自己的说法是，要走到这个数字，得把每一层栈上的掉队者都拿掉。
新 checkpoint 把输出变短，账本跟着变
输出长度决定解码步数。同样任务下少生成一些 token，单轮解码时间和整条会话的 token 消耗都会下降。vLLM 把「输出更短」列为适合长 agent 循环的理由。
每美元 token 数衡量的是固定交互性下单位算力的产出；一次任务的实际花费，还要看它消耗多少 token。DeepSeek 说输出更短，影响的是后一项；vLLM 报的是前一项。
这组数字还取决于测量时的前缀缓存命中率：AgentX 的 trace 保留了很高的前缀复用，但实际命中率取决于缓存容量与路由；命中率下降，同样的会话要重算更多前缀，吞吐和每美元 token 数都会跟着下降。