专家直接回答： DeepSeek 大模型推理成本的通用算法是「Token 用量 → 目标并发吞吐 → 卡数与月租 → 分摊隐性开销」。核心只有三句话：输入和输出 Token 单价必须分开算；单卡吞吐必须用目标模型、目标量化精度实测，不能抄理论值；最后要把峰值冗余、跨境网络重试、存储 IO 和运维一起计入总拥有成本。把这条链路算完，就能得到可用于预算和定价的「每千次请求成本」，并与 API 调用单价做盈亏平衡比较。
本文按四层成本结构展开，每层都给公式、示例和常见误差来源，方便你直接套用到自己的业务量上。
先分清：你在算哪一种成本？
预算算错，多数不是公式错，而是口径混了。实际工作中至少有三种口径：
| 成本口径 | 适用场景 | 算法 | 最常见的误差 |
|---|---|---|---|
| 按次/按量计费成本 | 调用第三方 API、对外报价 | 输入 Token 单价 × 输入量 + 输出 Token 单价 × 输出量 | 输出 Token 被低估 |
| 每 Token 自营成本 | 自部署推理服务的内部核算 | 算力月成本 ÷ 实际处理 Token 总量 | 忽略利用率折损 |
| 每千次请求成本 | 方案对比、产品定价 | 单请求全成本 × 1000 | 忽略峰值冗余与隐性开销 |
如果你调用的是 API，只看第一行就够；如果你自己部署模型，就必须把后两种口径都算出来。下文主要解决自部署场景，同时给出与 API 对比的判断方法。
四层成本结构：钱到底花在哪？
把推理成本拆成四层，每层单独核算、最后相加，是避免遗漏的最稳做法：
| 成本层 | 包含内容 | 占比特征 | 典型风险 |
|---|---|---|---|
| 一、算力层 | GPU/服务器月租、电力、托管 | 通常占比最高 | 按理论吞吐估算，结果偏乐观 |
| 二、Token 层 | 输入预填充 + 输出逐 token 生成 | 决定单位成本 | 输入输出合并计价 |
| 三、冗余与波动层 | 峰值余量、空闲时段、排队超时 | 弹性大 | 低估峰值，高峰期 SLA 崩 |
| 四、隐性开销层 | 网络重试、存储 IO、运维人力、监控 | 单项不大，合计可观 | 完全不计入 |
大部分团队只算了第一层和第二层，算出来的成本通常比实际低 20%–40%（具体幅度取决于流量波动和网络质量）。
计算链路：从业务量到每千次请求成本
整条链路是固定的四步，顺序不能颠倒。
第一步：统计 Token 用量，输入输出分开
至少采集四项业务数据：
- 日均请求数，以及工作日高峰的请求倍数
- 平均输入 Token（系统提示词 + 检索片段 + 历史对话）
- 平均输出 Token（回答长度上限与实际均值）
- 上下文长度分布（长上下文请求要单独统计）
日均 Token 量 = 日均请求数 ×（平均输入 Token + 平均输出 Token）。
为什么必须分开？自回归模型的输入侧是一次性预填充计算，输出侧是逐 token 生成，两者消耗的算力节奏完全不同，单位输出 Token 的成本通常明显高于输入侧。如果按「总 Token × 单一均价」估算，代码生成、长文档总结这类输出占比高的业务会被系统性低估。
第二步：实测单卡有效吞吐，而不是抄规格书
这是成本模型里最容易出错的一环。任何 GPU 的理论峰值吞吐都不能直接进预算，必须在目标模型版本、目标量化精度、目标推理框架下压测，至少拿到三个数：
- 目标并发下的稳定吞吐（用于算成本，单位 token/秒）
- 单请求首 token 延迟与端到端延迟（用于定 SLA，不直接进成本公式）
- 峰值并发下的吞吐衰减与排队延迟（用于定冗余）
量化是这一步的关键变量。在精度评测可接受的前提下，INT8/INT4 量化配合连续批处理（Continuous Bending 常见于 vLLM、TensorRT-LLM 一类框架），同一块卡的有效吞吐与全精度可能相差数倍。但量化后必须回归测试业务精度，吞吐数字不能单独做决策依据。
第三步：算卡数与月成本
公式链如下：
- 月有效处理能力 = 单卡稳定吞吐 × 86,400 × 30 × 有效利用率
- 所需卡数 =（日均 Token 需求折算的 TPS × 峰值系数）÷ 单卡稳定吞吐，向上取整
- 每 Token 算力成本 = 服务器月租 ÷ 月有效处理能力
其中「有效利用率」不是满载，而是长期平均值。流量平稳的服务可以按较高值估算；流量波动剧烈、GPU 频繁空闲时，利用率可能只有百分之几十，单位成本会被空闲时间成倍拉高。峰值系数一般取 1.2–1.3 起步，最终以压测曲线为准。
第四步：补齐冗余与隐性开销，汇总
- 峰值冗余： 在满足 SLA 的前提下预留约 20%–30% 算力余量。冗余过高推高固定成本，过低则高峰排队、超时。
- 存储与加载： 模型权重加载、向量库检索的 IO 速度直接影响首 token 延迟，进而影响 GPU 有效利用率。
- 网络： 跨境部署时，链路抖动和丢包会导致超时重试，等于同一笔 Token 被算了两次钱。
- 软件与运维： 推理框架维护、监控告警、备份、人工投入，计入总拥有成本。
汇总公式：
> 每千次请求成本 =（单请求算力成本 + 单请求分摊的冗余、存储、网络、运维成本）× 1000
一个可复核的演算示例
以下数字只用于演示算法，实际项目必须替换成自己的压测和业务数据：
| 演算项 | 示例取值 | 逻辑 |
|---|---|---|
| 日均请求数 | 80,000 次 | 业务统计 |
| 平均输入 Token | 600 | 提示词 + 检索片段 |
| 平均输出 Token | 400 | 回答长度 |
| 单请求 Token 量 | 1,000 | 输入 + 输出 |
| 日均 Token 量 | 80,000,000 | 80,000 × 1,000 |
| 平均吞吐需求 | ≈926 token/秒 | 80,000,000 ÷ 86,400 |
| 含峰值系数 1.3 后 | ≈1,204 token/秒 | 冗余后需求 |
| 单卡实测稳定吞吐 | 假设 400 token/秒 | 量化 + 批处理压测 |
| 所需卡数 | 4 卡 | 1,204 ÷ 400 向上取整 |
| 输出 Token 成本权重 | 单独计价 | 输出侧单位成本更高 |
建议输出两列成本：一列按平均负载，一列按 2 倍峰值负载。两列差距越大，说明你的业务越依赖冗余，预算越要留弹性。
隐性成本专项：为什么网络会直接改变你的成本
推理服务的成本不只是「卡跑了多少 token」。当你的用户在国内、推理节点部署在海外时，跨境链路质量会直接改写账单：
- 延迟与抖动影响流式输出的连贯性，重传和超时重试会让同一请求重复消耗算力；
- 路由绕行会在高峰期放大延迟，表现为白天正常、晚间卡顿，实测成本与体验双双劣化；
- 丢包重传对长上下文、批量任务尤其致命，一次断流意味着整个任务重跑。
换句话说，线路差价往往比重试浪费更便宜。这也是为什么跨境 AI 调用场景普遍优先考虑双向优化线路，而不是只看服务器硬件规格。需要具体对比线路差异时，可以参考跨境 AI 调用卡顿与精品 CN2 线路的实测分析。
同理，硬件形态的选择也直接影响成本结构：轻量 VPS 适合量化小模型的调试和低并发原型，成本低但算力上限固定；GPU 服务器月租更高，但算力独享、可扩容，适合把单位 Token 成本摊薄到可预测的水平。两种形态的取舍边界，在 VPS 与 GPU 服务器的对比分析里有按场景划分的说明。
盈亏平衡：什么时候自部署比调 API 划算
判断标准只有一条：找出「两种方案单位成本相等」的调用量。
- 低频、用量不稳： 按量调用 API 通常更省心，不承担固定算力开销。
- 用量稳定、利用率高： 自部署的单位 Token 成本随规模快速下降，固定成本被摊薄。
- 峰值波动大： 若利用率维持不上去，账面便宜会被空闲成本吃掉。
实操做法：把两种方案都折算成「每千次请求成本」，再做三档敏感性分析——调用量为预估的 50%、100%、200%。只有在 100% 和 200% 两档都明显占优时，迁移自部署才比较稳妥；只在 200% 档占优，说明方案对增长过于依赖。
落地清单：算成本前要准备的数据
- 输入/输出 Token 分布，而不是单一平均值
- 日均与高峰请求量，以及高峰持续时长
- 目标模型版本、量化精度、推理框架三个变量锁定后的压测吞吐
- 目标并发下的延迟曲线（首 token、端到端）
- 有效利用率的历史估计值，或至少一周的流量曲线
- 峰值冗余系数与延迟 SLA 的绑定关系
- 网络重试率、超时率（跨境场景必测）
- 存储 IO 与模型加载时间
- 运维人力与监控、备份的月度分摊
这九项凑齐，成本模型才有决策价值；缺任何一项，记得在预算里标注为「待验证」，不要用假设值掩盖。
常见问题
DeepSeek 推理成本里占比最大的是哪部分？
通常是算力层（GPU/服务器月租），在中高并发场景下往往占总成本的六成以上。因此降本的第一杠杆是提高单卡有效吞吐和利用率，其次才是网络与存储。网络和存储常被低估：重试造成的重复算力消耗、IO 不足导致的加载延迟，都会通过拉低利用率间接推高单位成本。
输入 Token 和输出 Token 为什么必须分开算？
因为计算模式不同。输入侧是预填充，一次算完；输出侧是逐 token 自回归生成，单位算力消耗更高。合并估算会让输出占比高的业务（长文写作、代码生成、报告总结）成本被系统性低估，也看不清量化和批处理在两侧带来的收益差异。
没有压测条件，能先估一个数吗？
可以，但只能当初值。用「日均 Token 量 ÷ 86,400」得到平均吞吐需求，乘 1.2–1.3 的峰值系数，再按候选硬件的公开吞吐范围估算卡数。进入采购、扩容或定价决策前，必须用真实模型、真实量化精度、真实并发压测替换这个初值——初值偏差在采购环节会被放大成真金白银。
提高批处理大小一定能降本吗？
不一定。加大批处理能提高吞吐、摊薄单请求成本，但会拉长排队等待、抬高首 token 延迟。正确做法是在延迟 SLA 内寻找最大可行批处理规模，用压测数据定位成本与体验的平衡点，而不是单纯追求吞吐数字。
成本模型多久重算一次比较合理？
建议至少每季度重算一次，或在三种事件发生时立即重算：模型版本升级、推理框架更换、硬件/线路调整。这三项任一变化都会显著改变单卡吞吐与有效利用率，沿用旧数据会让预算和实际账单持续偏离。
结论
DeepSeek 大模型推理成本的计算，本质是一条固定链路：业务 Token 量 → 实测吞吐 → 卡数与月成本 → 冗余与隐性开销 → 每千次请求成本。四个关键动作是：输入输出 Token 分开计价、用实测吞吐替代理论值、给峰值留出可控冗余、把网络重试和运维计入总拥有成本。做完这四步，你的成本表才能同时用于预算、定价和「API 还是自部署」的迁移判断。
如果你的项目还在原型验证阶段，可以先用轻量方案控制试错成本，把预算花在压测和 Token 用量摸底上；进入中高并发的商业化阶段后，再评估独享算力、支持扩容与稳定跨境线路的 GPU 服务器方案，把成本结构从「按次不可控」转为「按月可规划」。
下一步建议：把本文的九项数据清单填完，再用 50%/100%/200% 三档敏感性分析做一次迁移决策演练。如果你正在评估具体算力方案，可以把你压测出来的吞吐数据和目标 SLA 一并列出来，与包括 RakSmart 在内的候选服务商逐项核验配置、线路和扩容条款，再下采购决定。