DeepSeek DeepInfer 是什么？自部署门槛与 API 选型指南

DeepInfer 是 DeepSeek 开源的推理框架，负责运行模型；它不是新模型，也不是拿来就能调用的托管 API。 对正在选择 DeepSeek 使用方式的开发者，首先要确认自己是否需要运营推理后端。如果任务是尽快交付应用，应把托管 API 与一套需要自己建设、维护的完整服务作比较。

本文依据 2026 年 10 月 22 日核对的官方文档。我们没有在受支持的加速器上部署 DeepInfer，也没有复现官方性能图。下文的部署检查表和成本模板是选型工具，数字算例全部使用明确的假设。Ofox 提供 API 服务，也是本文发布方；我们会说明两条路径各自适用的条件，不预设所有读者都应该选择托管服务。

DeepInfer、模型和 deepseek-recipe 分别负责什么

部署一个模型包含几种不同职责。把它们混为一谈，容易算错成本，也会让排错偏离真正的问题。

DeepInfer 官方 README 当前列出的支持模型是 DeepSeek-V4.1-Flash，默认检查点为 deepseek-ai/DeepSeek-V4.1-Flash-1017。模型版本变化可看 1017 更新解读；本文讨论的是运行模型的引擎和部署选择。

独立的 deepseek-recipe 仓库 负责转换 Chat Completions、Responses 和 Messages 等格式。调用方仍需提供模型推理、工具执行和 HTTP 传输。仓库中的 Python、Rust 服务器示例使用的是模拟推理，看到示例返回 JSON，并不表示真实模型已经生成了答案。

对应用开发者，这意味着三项检查应分开进行：HTTP 能否返回、提示是否正确渲染、真实模型能否生成。任何一项通过，都不能自动证明另外两项正常。

安装前，先确认硬件是否在支持范围内

当前 README 列出 NVIDIA SM100 GPU 与华为 Ascend 950 NPU，基础环境为 Linux、GCC 13 或以上版本、Python 3.12。NVIDIA 路径要求 CUDA 13，Ascend 路径要求 CANN 9.2。这是核对当日的文档支持范围，不是对未来移植版本的承诺。

RTX 4090、H100 不在这份已列出的目标中。但不能因此写成“DeepSeek 模型永远无法在这些设备上运行”：通过其他引擎运行模型，是另一项兼容性判断。同样，社区有人提交适配 PR，也不等于当前发行内容已经支持该设备。

估算安装工作量之前，先记录精确的设备架构、驱动与工具链版本、模型检查点和引擎代码版本。前提不满足时，先完成兼容性评估，不应仅为了试试一个未获支持的组合能否编译，就租用昂贵设备。

需要区分三个问题：

1. 是否支持：这个引擎版本的文档是否列出你的平台？
2. 能否运行：所选配置是否容得下模型，并正确完成推理？
3. 是否高效：在预期负载下，能否达到吞吐和延迟目标？

官方部署问答 在其推荐的生产设计中，把 64 张预填充 GPU 加 64 张解码 GPU 描述为最小的高效部署单元。这不是所有离线测试的绝对最低卡数。README 中预填充和解码性能测试所用的配置也不同，不能把其中任一数字直接变成通用的“最低硬件采购清单”。

从离线推理到在线 API，还需要补什么

公开 README 明确列出完整服务仍需要的三部分：KV 缓存系统、VE/Prefill/Decode 分离，以及数据并行副本之间的负载均衡。VE 指视觉编码器；Prefill 和 Decode 分别是预填充与解码阶段。文档同时说明，分离所需的大部分引擎功能已经实现。这里要分清：具备底层功能，不等于完整在线服务已经组装好并有人负责运营。

规划项目时，应给每项服务职责指定负责人，并写出验收方法：

这是本文建议的运营验收表，不表示 DeepInfer 随软件交付了左列的每一项服务。尤其需要注意，自行持有硬件并不会自动解决隐私问题：机器、日志、备份和提示缓存的访问权限，仍由部署方负责。

选择托管 API 时，也应向供应商核对对应问题。端点名称兼容，不代表工具行为、缓存计费和保留条款完全一致。如果只是想接入编程客户端，可以先看已有的 Codex 配置教程或 Claude Code 配置教程，确认当前路由支持后，再判断是否需要新增基础设施。

用同一份负载和服务目标比较成本

峰值 tokens/s 图表不能直接换算成你的月账单。先定义有代表性的负载：输入长度分布、输出长度、重复前缀比例、是否含图片、并发量和每天的峰谷。再规定请求完成率、输出质量、首 token 延迟和流式输出速度目标。价格低但达不到这些要求的服务，不是同等替代项。

估算 API 成本时，分别填写未命中缓存的输入、命中缓存的输入和输出费率。缓存写入、存储、平台费等，只有供应商确实按该项收费时才加入。未知费用应标记为待确认，不能按零处理。token 数量按供应商的计费定义统计，适用时包括推理 token。DeepSeek API 价格指南介绍了相关计费问题，实际采购前仍需取得精确路由的当前报价。

下面统一用百万计费 token 为单位：

API 月成本 =
  未命中缓存的输入百万 token × 未缓存输入费率
  + 命中缓存的输入百万 token × 缓存输入费率
  + 计费输出百万 token × 输出费率
  + 其他适用的月度费用

自部署月成本 =
  加速器租赁费，或分摊后的硬件折旧
  + 主机、网络与存储
  + 未包含在租金中的电力
  + 运维与支持人员成本
  + 冗余及恢复容量
  + 随实际负载变化的费用

同一台加速器不要既计租金又计折旧。租赁已经包含电力时，不要再加一次电费。共享人员的投入时间也要明确分摊。对于未知项，应获取报价或测量，并给出范围，不要把不确定因素藏在一个看似精确的总数里。

可复算示例：这些数字不是 DeepInfer 报价

假设一个负载单元包含 1 亿输入 token 与 2,000 万计费输出 token，其中 60% 输入按缓存命中计费。仅为演示，设未缓存输入 0.80 美元/百万 token、缓存输入 0.20 美元/百万 token、输出 2.00 美元/百万 token。这些是构造的算例输入，不是 DeepSeek 或 Ofox 的当前价格。

每单元 API 可变成本为 40 × 0.80 + 60 × 0.20 + 20 × 2.00 = 84 美元，再假设每月另收 16 美元平台费。自部署则假设每月固定成本 50,000 美元，每个负载单元额外产生 20 美元可变成本。后两项也不代表真实 DeepInfer 硬件方案的报价。

在这些假设下，两者相等时 84x + 16 = 50,000 + 20x，得到 每月 781 个负载单元。但算式成立，不代表应该采购。固定配置必须确实能在目标延迟与可靠性下承载这个量。如果 781 个单元需要再加一套集群，就要重算固定成本，原先的平衡点可能随之消失。

把缓存命中比例从 60% 降到 20%，本例 API 单元可变成本会从 84 美元升至 108 美元。自部署侧的成本和容量也可能因复用减少而变化，不能人为固定一侧，再宣称某个精确的省钱比例。低谷、常态和峰值月份应分别计算。

做一次能淘汰不合适方案的试点

考虑自部署的团队，应在承诺生产投入前走完以下过程：

1. 定义负载与合格标准。保留有代表性、经过适当脱敏的样本。选择方案之前，先确定质量、延迟、失败率和数据处理要求。
2. 确认平台兼容性。记录受支持加速器、软件环境、检查点和代码版本。操作以仓库当前示例为准，不依赖博客中没有版本标识的安装命令。
3. 验证离线正确性。在目标环境运行适用的官方示例和评估检查，保存成功与失败结果。编译通过不等于生成质量合格，更不能代替协议兼容性验证。
4. 测试真实服务路径。替换所有模拟后端，再验证一次完整请求和一次流式请求。需要工具时，分别检查生成的参数与应用侧执行。还要测试非法输入、超时、客户端取消和服务过载。
5. 测量真实负载。包含长短提示、冷热缓存、空闲期和并发突增。记录完成的工作量、延迟分布、失败情况和全部计费资源。
6. 与托管路由比较。尽量保持模型版本与请求行为可比。量化精度、推理设置、缺失功能等无法对齐的差异，须明确记录。
7. 重算费用并决策。准备回退路径，指定运营负责人。某方案不满足硬性要求时，不能用一个有利的平均成本替它过关。

试点失败后，先分类再投入更多资源：编译错误应检查构建环境；内存不足需要分析模型和运行时容量；有效的模拟响应只是测试工具结果；工具参数不符合要求则需要检查协议与模型处理路径。这些现象都不能单独证明换一个 API Key 或租更大的机器就能解决问题。

选择团队真正能够运营的路线

需求尚不确定、调用间歇发生、交付时间紧，或没有人负责加速器运维时，可以把托管 API 作为优先验证的候选。同时核对供应商的限制与条款，不要假设所有托管路由都能互换。

已经有兼容基础设施、有能力运营完整服务、需求长期稳定，或者有现有托管选项无法满足的明确要求时，自部署值得做试点。已有硬件也不等于项目免费，还需计入硬件的其他使用机会和支持人员的投入。

决策前，填完下面这份记录：

应用任务与精确模型版本：
必须满足的质量、延迟和数据要求：
常态／低谷／峰值月负载：
测得的缓存行为与计费 token 分类：
自部署平台与运营负责人：
托管路由、尚未确认的合同或功能问题：
两条路线各自的全口径月成本范围：
支撑费用估算的容量证据：
试点结论、回退路径与决策日期：

DeepInfer 的价值在于公开了大量推理工程实现，但采用它的决策，最终仍应落到可运营的服务和与你的负载对应的费用估算。代码开源本身，既不能证明你的 API 账单马上降低，也不能单独成为重建现有应用后端的理由。