DeepSeek 大模型推理成本怎么算：六步算出每千次请求的真实账单

直接结论： DeepSeek 推理成本没有统一答案，但有一套通用算法。先拆分输入 Token 与输出 Token（两者单价不同），再用目标 GPU 实测单卡有效吞吐（TPS），除以 GPU 月租得到「每 Token 成本」，最后加入峰值冗余、利用率折损、存储网络等固定开销，就能算出每千次请求的真实成本。判断自部署是否划算，用「API 单价 × 预计调用量」与「总拥有成本 ÷ 预计 Token 量」做盈亏平衡比较即可。

先明确你在算哪一种成本

很多预算算错，是因为把三种不同的成本口径混在了一起：

本文主要回答后两种：当你自己部署 DeepSeek 模型时，推理成本怎么一步步算出来。如果是先用 API 验证、流量稳定后再迁移，也建议两种口径同时算，才能判断迁移节点。

六步计算法：从 Token 量到每千次请求成本

第一步：统计日均与峰值 Token 量

先把业务量拆成两个维度：日均总量决定平均成本，峰值决定需要多少算力冗余。至少记录四项：

• 每日请求数（日均、工作日峰值）
• 平均输入 Token（提示词、知识库检索片段、历史对话）
• 平均输出 Token（回答长度，通常比输入更短，但单位算力消耗更高）
• 上下文长度分布（长上下文会显著放大输入侧成本）

典型表达是：日均 Token 量 = 日均请求数 ×（平均输入 Token + 平均输出 Token）。

第二步：把输入与输出分开算

这是最容易被忽略的一步。DeepSeek 这类自回归模型，输入侧主要是一次性的预填充计算，输出侧需要逐 token 生成，显存占用与计算节奏完全不同。因此在核算时应拆成两条线：

• 输入成本 = 输入 Token 数 × 单位输入 Token 成本
• 输出成本 = 输出 Token 数 × 单位输出 Token 成本

单位输出 Token 成本通常高于输入侧。若只按「总 Token 数 × 一个平均单价」估算，长回答业务（代码生成、长文档总结）的成本会明显偏低。

第三步：实测单卡有效吞吐，而不是照搬理论值

任何 GPU 的理论峰值 TPS 都不能直接用于成本计算，必须在目标模型版本、目标量化精度、目标推理框架下做压测。压测至少覆盖三种情况：

• 单请求延迟（衡量体验，不用于算成本）
• 目标并发下的稳定吞吐 TPS（用于算成本）
• 峰值并发下的吞吐与排队延迟（用于定冗余）

量化是这一步的关键杠杆。在精度损失可接受的前提下，INT8/INT4 量化配合 vLLM、TensorRT-LLM 一类推理框架的连续批处理（Continuous Batching），同一块 GPU 的有效吞吐可能与全精度相差数倍。但量化后必须复测精度，不能只看吞吐数字。

第四步：计算 GPU 有效成本与每 Token 成本

有了压测数据，算力部分就可以落地：

• GPU 月有效处理能力 = 单卡稳定 TPS × 3600 × 24 × 有效利用率 × 30 天
• 每 Token 算力成本 = GPU 月租 ÷ GPU 月有效处理能力
• 单请求算力成本 =（输入 Token × 输入侧单价 + 输出 Token × 输出侧单价）

有效利用率不是满载，而是长期平均值。业务平稳时可按较高值估算，流量波动剧烈、GPU 频繁空闲时，利用率可能只有百分之几十，单次请求分摊的固定成本会成倍上升。因此建议按「目标并发压测值 × 利用率折损系数」建模，而不是按平均值乐观估计。

第五步：加入峰值冗余与非算力开销

算完算力成本，还要补上常被低估的部分：

• 峰值冗余： 建议在满足 SLA 的前提下预留 20%–30% 算力余量。冗余过高会拉高固定成本，过低则高峰期排队、超时。
• 存储： 模型权重加载、临时缓存、向量库检索的 IO 速度会直接影响首 token 延迟，间接影响 GPU 有效利用率。
• 网络： 若服务国内用户而部署在海外，跨境链路质量会影响重传与超时重试。稳定的双向优化线路能减少无效调用，这部分属于隐性成本节约。可参考精品 CN2 线路对跨境 AI 调用的实测差异。
• 软件与运维： 推理框架、监控、容器平台、备份与人工投入，虽然占比不高，但需要计入总拥有成本。

第六步：汇总成每千次请求成本

把以上结果合并：

每千次请求成本 =（每请求算力成本 + 分摊的存储/网络/软件成本）× 1000

再除以 1000，就是单请求成本；乘以日请求量，就是日成本；乘以 30，就是月度预算。建议输出一张成本表，分别列出「按平均负载」「按 2 倍峰值」两列，便于做预算敏感性判断。

一个可复核的演算示例

以下数字仅用于演示计算方法，实际结果必须以你自己的压测数据替换：

计算顺序是固定的：业务量 → TPS 需求 → 卡数 → 月成本 → 单请求成本。任何一步用错数据，后面的结论都会失真，所以每一步都要能复核。

盈亏平衡：自部署什么时候比调用 API 更划算

判断标准很简单：找出「单位成本相等」的调用量。

• 低用量、低频场景： 按次调用 API 通常更省心，不必承担固定算力开销。
• 用量稳定且利用率高： 自部署的单位 Token 成本会快速下降，因为固定成本被大量 Token 摊薄。
• 峰值波动大： 若无法把利用率维持在较高水平，自部署的账面便宜可能被空闲成本抵消。

实际决策时，先算出两种方案的「每千次请求成本」，再做三档敏感性分析：调用量 50%、100%、200%。只有在 100% 与 200% 档都明显占优时，迁移才比较稳妥。

成本控制清单：先做哪几步最划算

• 重新统计输入/输出 Token 分布，不要用单一平均值估算
• 在目标硬件上做真实压测，记录延迟、吞吐与并发三条曲线
• 优先测试 INT8/INT4 量化，并用精度评测验证可用性
• 调整连续批处理参数，在延迟 SLA 内提高吞吐
• 把长上下文请求单独分池，避免少数长请求拖垮整体成本
• 监控 GPU 利用率、排队长度、超时重试率，作为扩容与缩容依据
• 按流量规律规划资源：平稳负载用固定配置，波动大时评估弹性升降级
• 每季度重算一次单位成本，因为模型版本、框架与硬件组合都会变化

常见问题

DeepSeek 推理成本里哪部分占比最大？

通常是 GPU 算力成本，占比可达总成本的六成以上，因此控制成本的核心是提高 GPU 有效利用率与单位 Token 吞吐。其次是常被低估的网络与存储：网络抖动导致的重试、存储 IO 不足导致的加载延迟，都会通过降低利用率间接推高成本。

输入 Token 和输出 Token 为什么要分开算？

因为两者的计算模式不同。输入侧是一次性预填充，输出侧需要逐 token 自回归生成，单位输出 Token 的算力消耗通常更高。合并估算会让长回答业务的成本被系统性低估，也无法准确反映量化和批处理带来的收益差异。

没有压测条件，能快速估算成本吗？

可以，但结果只能作为初值。先用「日均 Token 量 ÷ 86,400 秒」得到理论 TPS，乘以 1.2–1.3 的峰值系数估算需求，再按候选 GPU 的公开吞吐范围估算卡数。进入采购或扩容决策前，务必用真实模型与真实并发压测替换这个初值。

提升批处理大小一定能降本吗？

不一定。加大批处理能提高吞吐、摊薄单次请求成本，但会增加排队等待时间，可能拉高首 token 延迟。正确做法是在延迟 SLA 内寻找最大可行批处理规模，用压测数据确定成本与体验的平衡点。

什么时候应该换模型版本或量化方案？

当单位 Token 成本连续两个月无法通过参数调优改善时，就该重新评估。新版本模型或更激进的量化方案，可能在同等硬件上显著提升吞吐；但必须同步做精度回归测试，确认业务质量没有明显退化。

结论

DeepSeek 大模型推理成本的计算，本质是一条固定链路：业务 Token 量 → TPS 需求 → 算力配置 → 月成本 → 每千次请求成本。先拆分输入与输出 Token，再用压测数据校准吞吐，最后补齐峰值冗余与隐性开销，得到的数字才具备决策价值。

如果你的项目处于原型验证阶段，可以先用轻量方案控制试错成本；进入中高并发的商业化阶段，再选择独享算力、支持扩容与灵活网络选项的 GPU 服务器方案，把成本结构从「按次不可控」转为「按月可规划」。具体选型思路可参考 VPS 与 GPU 服务器在大模型场景下的取舍分析。

如果预算表已经成型，建议下一步把「延迟 SLA」和「峰值利用率」写进验收指标，让成本核算与性能验收用同一套数据闭环。

下一步可将 RakSmart 与其他候选服务商一并评估，并根据当前公开资料逐项核验实际需求。