先看证据
公开的是推理框架，不是完整线上服务
DeepSeek公开了DeepInfer，这是支撑其V4.1-Flash线上推理的框架，面向大规模模型服务中的吞吐、延迟和调度问题。仓库还包含API处理相关组件，并支持分布式推理、推测解码、SWA Bounded Replay和结构化输出，可运行于NVIDIA与华为昇腾平台。DeepSeek也表示，未来的模型推理实现和优化会继续放入这个仓库。
但“开放推理框架”不等于“开放整套生产服务”。仓库说明DeepInfer主要基于vLLM构建，并借鉴了SGLang、TensorRT-LLM等项目；更关键的是，线上服务依赖的KV缓存管理、阶段拆分和负载均衡并未完整开放。读者面对的不是一份从硬件到流量调度都能照搬的部署蓝图，而是一组可以检查和使用的引擎代码，以及仍需自己补齐的系统边界。
推理的瓶颈从单次计算转向状态复用
理解DeepInfer的效率思路，先要把一次生成拆成不同工作：视觉编码和Prefill处理输入，Decode再逐步生成输出。三者的计算特征和资源需求不同，DeepSeek的生产设计因此把它们分开部署，并按负载分别调度。这样做的目标不是让某一块GPU在所有阶段都达到峰值，而是避免不同阶段争抢资源，并让各自能够独立扩缩容。
更重要的变量是KV cache，即模型处理过的上下文状态。长会话或重复前缀如果能够复用已有状态，就不必每次从头计算；DeepSeek报告的生产方案将持久KV放在共享存储中，让请求不必回到最初处理它的节点。对短生命周期的SWA状态，SWA Bounded Replay只回放最近128个token来重建状态，工程报告称这使总预填充计算量接近减半。系统优化的重点由此不只是“每秒能生成多少token”，还包括哪些计算能够免做、缓存状态如何跨请求保存。
155万亿日token，首先是一个缓存数据
DeepSeek报告的生产数据很醒目：单集群每天服务155万亿token，输入缓存命中率为96%，平均首token延迟400毫秒，生成速度为230 token/s，编码任务可达300 token/s。报告还给出按GPU拆分的数字：每张预填充GPU每秒处理约150万缓存计入的输入token，每张解码GPU每秒生成约1.4万token。这些数字分别描述输入处理与输出生成，不能混成一个适用于任意业务的“模型吞吐”。
96%的缓存命中率尤其重要。它意味着155万亿这个总量很大程度上反映了系统对重复输入和已有状态的复用能力，而不是同等规模的全新提示词都被完整计算了一遍。DeepSeek还报告持久KV缓存使用约100 PiB SSD，并按流量类型设置不同保留时间：Agent流量为3天，聊天机器人为7天。对有大量重复上下文的服务，这些机制可能显著改变成本；对缓存复用少、提示词高度多样的负载， headline 数字就不能直接当作容量规划依据。
利润和回本速度是模型推算，不是审计结果
围绕DeepInfer的讨论，还把吞吐换算成了商业账：材料根据非高峰价格、每卡每小时约5至8美元的全成本，以及DeepSeek报告的收入数据，估算推理毛利率可超过80%，并推导出约81天的回本周期。每瓦算力对应的收入和回本速度，确实会影响模型服务商如何判断扩容是否划算；但它们是基于公开价格和成本假设的估算，不是经审计的经营结果。
这个推算对缓存表现和利用率非常敏感。缓存命中率下降，会增加需要实际计算的输入；不同模型、硬件、流量时段和计费方式，也会改变收入与卡时成本。材料中的集群和每GW回报外推因此更适合被理解为一种情景测算，而不是DeepInfer部署到其他组织后可以直接兑现的回报承诺。技术团队在评估时应把吞吐、成本和命中率放在同一组测试条件里，而不是单独引用利润率或回本天数。
引擎性能接近时，系统边界才是差异所在
vLLM团队称，在匹配配置的GB200对比中，其解码吞吐与DeepInfer公布的结果相差不到6%。这不是足以证明两套系统在所有场景等价的独立评测，但它提示了一种值得技术负责人重视的变化：如果引擎层的差距已经不大，优势可能来自引擎之外的缓存、阶段编排、负载均衡和数据中心运行条件，而不只是换一个推理框架名称。
这也解释了为什么开放代码和复现生产表现是两件事。使用者可以评估DeepInfer公开的推测解码、结构化输出和回放机制，却仍需自行设计未完整开放的缓存与调度层，并确认这些组件如何适配现有基础设施。若业务主要是长会话、重复前缀或Agent调用，共享KV和状态保留可能值得优先验证；若缓存命中率低，或者缺少相应的存储与编排能力，报告中的吞吐和成本优势就未必能复制。实际判断应从自家流量的缓存命中率和端到端成本出发，再决定是否迁移，而不是先追逐一个集群纪录。