# DeepSeek 开源 DeepInfer：引擎能跑，服务还得自己拼

**Summary:** DeepInfer 放出了 DeepSeek 的推理引擎，但 KV cache、prefill/decode 分离和负载均衡这些服务层仍要运维方自己补。我会先把集成成本算进去，再在延迟目标下测有效输出，然后才考虑租生产集群。

- Canonical: https://markhuang.ai/zh/news/deepinfer-missing-serving-system
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-20
- Section: News
- Tags: DeepInfer, DeepSeek, 大模型推理, AI 基础设施, 推理基准, 自建部署
- Source: [DeepSeek on GitHub](https://github.com/deepseek-ai/DeepInfer)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一个发光的计算核心，周围散落着断开的服务模块和裸露的光纤接口](https://cdn.markhuang.ai/news/deepinfer-missing-serving-system/hero.webp)

*DeepInfer 发布边界的概念图：计算引擎已经可用，完整的服务系统仍需集成。*

DeepSeek 开源了 [DeepInfer](https://github.com/deepseek-ai/DeepInfer)，按它的说法，这套推理框架支撑着自家大规模生产服务。项目以 Apache 2.0 许可证发布，目前能为 DeepSeek-V4.1-Flash 提供离线推理。README 给出的基准是：prefill（处理输入）用 4 张 NVIDIA SM100，decode（生成输出）用 64 张，两种配置都没有跨出单个 scale-up 域。README 还点明了想跑成完整服务，眼下缺的是哪些东西。

真到租硬件那一步，我会先从这份清单看起。能亲自翻一翻 DeepSeek 线上服务背后的引擎，这本身就是好事；但部署预算里得把缺失的基础设施算进去。光看引擎吞吐，我算不出一套完整服务在我的流量和延迟要求下要花多少钱。

如果团队正打算用自建集群替掉 API 账单，这次发布值得研究一下。不过它把不少服务层的集成工作留给了运维方，我会先跑出一个能用的试点，再谈硬件预算。

## 引擎本身值得认真看

README 列了几项关键能力：优化过的 kernel；draft token 解码，验证时机按置信度来调度；还有异步调度，让 CPU 侧的批次调度和设备执行重叠进行。引擎也能按正则、JSON Schema 或 EBNF 文法约束结构化输出。想研究推理性能的团队，现在既有公布的结果，也有代码可以翻。

最让我在意的是 batch-invariant inference：DeepSeek 说不论一批里混进哪些请求，模型结果都保持一致。文档里说，这个选项只支持 NVIDIA。对比输出时，我总想分清：结果变了，是模型本身的原因，还是同批其他请求的影响。这个特性值得在实际部署环境里测一测。

支持的硬件范围很窄：NVIDIA SM100 GPU 和华为 Ascend 950 NPU。要是打算换别的加速卡，我会先确认兼容性。另外，64 卡 decode 只是基准测试的配置，并不等于官方提出的最低硬件配置。

## 缺的那几块，用户最终感受得到

DeepSeek 明确列出了完整推理服务还缺的三样东西：KV cache 系统；视觉编码器、prefill、decode 三者分离；数据并行副本之间的负载均衡。这次发布都没包含。README 同时提到，分离所需的大部分引擎功能其实已经实现。底层的活做了不少，剩下的系统集成还得运维方自己补完。

我更愿意把这理解成一条集成边界：开源放出来的是引擎，服务层还得自己接上。我并不是说引擎内部完全没有缓存。上线前我会问清楚：服务级缓存归谁管，请求怎么落到对应的 prefill 和 decode 副本上。这些问题该和加速卡一起算进预算。

[vLLM 关于分离式预填充的文档](https://docs.vllm.ai/en/latest/features/disagg_prefill/)解释了这件事对用户的意义：把 prefill 和 decode 拆开后，首 token 的耗时和输出 token 之间的间隔，运维方可以各调各的。文档里还讲了怎么压尾延迟。这让我大致明白缺的那部分集成有多要紧，不过它并没有测 DeepInfer。在承诺“体验更快”之前，这两个延迟都得在拼好的整套服务上量一遍。

## 给输出定价之前，先看清吞吐是怎么算的

[基准测试文档](https://github.com/deepseek-ai/DeepInfer/blob/main/examples/README.md)里有个细节，看性能图时我会一直记着。原始 decode 吞吐指标按“全部接受”的口径统计：每个请求的每一步都把主 token 加上配置的 draft token 全算进去，不管实际接受率是多少。

项目的[绘图代码](https://github.com/deepseek-ai/DeepInfer/blob/main/examples/sweep/plot_pareto.py)则另外需要一个 draft 接受率作输入，用它修正自己支持的那种固定 draft 配置下的 decode 曲线。看图上的结果之前，我会先确认这个输入值，再拿有代表性的请求实测接受率。只看原始指标或者只看图，都只看到了实验的一半。

我算成本，只认在应用延迟目标内真正送到调用方的有效输出——排队时间、整套系统的缓存行为，都得一起算进去。DeepSeek 的基准配置给了运维方一个复现的起点。要给自己负载定价，还是得另做一次实验。

## 这套服务得先证明自己配得上这些卡

[Hacker News 上的早期讨论](https://news.ycombinator.com/item?id=50163277)集中在这次发布和推理的经济账上。我去看的时候只有三条评论，还远不足以看出社区怎么看它能不能真正部署。有位评论者贴了 [SemiAnalysis 的 InferenceX 利润估算器](https://inferencex.semianalysis.com/profit-estimator)，里面可以调缓存命中率、每用户 p90 token 速率目标、token 价格，以及总成本按什么基准算。这些输入能说明一个成本结论到底依赖什么。这个估算器并不会独立复现 DeepInfer 的结果。

对我这份谨慎，最有力的反驳也确实站得住：开源推理引擎没义务给每个人一套成品服务。已经有合适基础设施的团队，可能马上就能用上。我会按这个范围来评价，也得承认 DeepSeek 把缺了什么写得明明白白。

如果是全新部署，我的试点会拿有代表性的请求在拼好的系统上回放，记录有效输出和尾延迟，再把补那几层服务的运维成本算进去。比较对象是我正考虑替掉的 API 服务。只有运行成本确实更低，或者确实需要自己掌控部署，这笔活才值得干。在那之前，集群先租小一点，够跑出结论就行。