大家好，我是PaperAgent，不是Agent！
就在刚刚，DeepSeek官方发文，正式开源大规模云服务推理框架 DeepInfer，以及生产级 Token 编解码组件 deepseek-recipe。
这不是又丢一个模型权重，而是把支撑 DeepSeek V4.1 Flash 线上服务的整套推理家底摊开给你看：怎么部署、怎么调度、怎么省钱，全写了。
这次的诚意：
框架支持英伟达 + 华为昇腾双平台； 未来新模型的推理代码和性能优化，都会在 DeepInfer 持续开源； 官方直接公布了线上真实的吞吐、延迟、命中率和收入数据。
先看账本：155 万亿 Tokens/天，每卡每小时 38 美金
最能说明问题的永远是数字。官方晒出的线上实测：
几个关键数字，感受一下量级：
Prefill：不含缓存命中每卡 60K tps，算上缓存命中后每卡 1.5M tps；平均输入长度 77K tokens，输入缓存命中率 **96%**；TTFT 平均 400ms，P99 仅 1000ms。 Decode：每卡 14K tps，吐字速度 230 tps（代码场景 300 tps）。 KVCache：不活跃后仍保留 72 小时。
更狠的是经营数据：单一集群吞吐 155 万亿 Tokens/天，整体收入平均每卡每小时 38 美金（按谷价），实际部署 P:D 接近 1:1。
这套账本是 DeepSeek API 敢打价格战的底气所在。
cluade code最佳AI原生工程实践
整体架构：PD 分离 + Wide-EP，四件套负载均衡
系统的优化目标很朴素：更大的吞吐、更低的延迟。打法是三板斧：
节点内专家并行（EP）：增大 batch size，提高矩阵乘效率； Vision Encoder / Prefill / Decode 分离部署：分别优化 TTFT 和 TBT； 并行策略按阶段定制： Prefill：EP2~8，用常见的 8 卡机器，显存够用就用尽量小的 EP/DP； Decode：EP64~128 的 Wide-EP，跑 64~128 卡超节点，卡够就尽量开大； Vision Encoder：单卡即可，用最便宜的卡。
并行切大了，负载均衡就是生死线。DeepSeek 为此做了四个负载均衡器：Prefill / Decode / Vision Encoder / Expert-Parallel。以 Prefill 为例，实现分四层：按输入长度分桶（<16K / 16-64K / 64-256K / ≥256K）、DP 组间按剩余算力拉取、组内发给负载最低的 rank、单卡内用拟合的二次代价模型 cost(q, c) 反解 chunk size。
EP 均衡则靠冗余专家 + 动态重排：Prefill 每卡多备 4 个冗余专家，实测负载不均度（最慢 rank / 均值）压到 1.03~1.06；Decode 每卡 1 个冗余专家，实测 1.09。相当漂亮的数字。
离线基准：P 和 D 各自的性能曲线
光有线上数据还不够，官方还给了离线基准，方便社区复现对标。
Prefill 侧（EP4DP4、384+32 专家、131K 上下文）：
batch 拉到 16K tokens/rank 后，每卡吞吐就站上 85K tps 以上的平台期，且延迟控制在 200ms/step 量级。
Decode 侧（EP64DP64、投机解码 per-token 接受率 75%）：
曲线揭示了经典的吞吐-体验权衡：每用户 100 tps 时单卡吞吐可达 26K tps；要保证 300+ tps 的极速体验，吞吐就降到 10K 以下。线上取的 230 tps 正是这条曲线上的甜点。
三个最硬核的技术点
1. KVCache 分层存储：100 PiB 的记忆仓库
这是全文信息密度最高的部分。V4.1 的 KVCache 分两类：
3FS 集群提供约 100 PiB SSD 容量，峰值聚合读带宽 10 TiB/s、写带宽 850 GiB/s，按 112 KiB 的 block 粒度做了随机读写优化； agent 流量 KVCache 留 3 天，chatbot 留 7 天； 命中路径三段式：匹配（关键路径）→ 取 KV（异步搬进 shm）→ 换入（GDR 直传 HBM，与前向计算重叠，不占 SM）。
2. SWA Bounded Replay：只重算 128 个 token
V4 时代 SWA KVCache 落盘占了近一半容量，却只在分钟级窗口内被复用，极不划算。V4.1 的做法：不落盘，缺了就只重算最近 128 个 token，注意力窗口截断在重算段内，代价变成与上下文长度无关的常数。Decoder 侧同样只重算 prompt 末尾 128 个 token，总 prefill 计算量近乎减半。线上 SWA KVCache TTL 约 180 秒，命中率 98% 以上。
3. DSpark 变长验证 + 零开销调度
DSpark 投机解码：用 Confidence Head 预测每个 draft token 的接受率，把验证算力分给边际收益最高的 token，比固定验证 5 个 token **吞吐再提 6%**； Asynchronous Scheduling：CPU 调度和 GPU 前向完全流水重叠，GPU 全程无空转； 配套开源的 deepseek-recipe（Rust 实现）统一适配 Chat Completions / Responses / Messages 三种 API 协议，还解决了 special token 注入安全和超长文本 tokenize 加速的问题。
最后
值得注意：KVCache 管理和负载均衡组件因与内部基础设施耦合太深，代码暂未完整开源，但这次把设计细节几乎和盘托出。
家底都亮出来了，接下来就看社区能接得住多少了。
DeepInfer: https://github.com/deepseek-ai/DeepInfer
deepseek-recipe: https://github.com/deepseek-ai/deepseek-recipe
https://zhuanlan.zhihu.com/p/2095560295930508953