DeepInfra 价格与收费：三档价怎么读，月成本差十几倍
同样是在 DeepInfra 上调 DeepSeek，模型那一栏填 V4-Pro 还是 V4-Flash，月账单能差出十几倍。
不是修辞。按官方定价页的挂牌价，V4-Pro 是输入 $1.30、输出 $2.60（每百万 token），V4-Flash 是输入 $0.09、输出 $0.18。两档相除，输入和输出都是约 14.4 倍——同样的调用量、同样的提示词、同样的输出长度，仅仅因为模型那一行字符串不同，月成本就差 14 倍多。
而我见过的项目里，相当一部分任务根本用不上 Pro：分类打标、字段抽取、意图识别、格式改写，这些活儿的难点在提示词准不准、schema 严不严，不在推理深度，跑在 Pro 上就是为用不到的能力按次付费。
所以谈 DeepInfra 省钱，顺序是反的：先选型，再缓存，最后才是压缩 token。选型这一刀是十几倍，缓存那一刀是几倍，压缩提示词通常只有百分之几十，还往往牺牲效果。下面逐个算清楚。
官方挂牌价：五个模型的三档价
以下是官方定价页上的数字，单位 $ / 1M tokens，以官方定价页为准（价格会调整，本文只做结构分析，不承诺时效）：
| 模型 | 输入 | 缓存输入 | 输出 |
|---|---|---|---|
| DeepSeek-V4-Pro | $1.30 | $0.10 | $2.60 |
| DeepSeek-V4-Flash | $0.09 | $0.018 | $0.18 |
| DeepSeek-V3.2 | $0.26 | $0.13 | $0.38 |
| DeepSeek-V3.1-Terminus | $0.27 | $0.13 | $0.95 |
| DeepSeek-V3.1 | $0.25 | $0.13 | $0.95 |
计费单位统一是每 100 万 token，区分输入 / 缓存输入 / 输出三档。三档这个结构，比表里任何一个绝对数字都重要。
三档价怎么读：两个派生比率
绝对价看不出门道，两两相除就清楚了。下面两列是我从上表算出来的，不是官方另给的数字：
| 模型 | 输出 ÷ 输入 | 输入 ÷ 缓存输入 |
|---|---|---|
| DeepSeek-V4-Pro | 2.0 倍 | 13 倍 |
| DeepSeek-V4-Flash | 2.0 倍 | 5 倍 |
| DeepSeek-V3.2 | 约 1.46 倍 | 2 倍 |
| DeepSeek-V3.1-Terminus | 约 3.52 倍 | 约 2.08 倍 |
| DeepSeek-V3.1 | 3.8 倍 | 约 1.92 倍 |
第一列告诉你「让模型少废话」值多少钱。 输出比输入贵是惯例，但贵多少各模型差很远：V4 两档是整 2 倍，V3.1 是 3.8 倍——多吐 100 个输出 token，代价相当于多读 380 个输入 token。所以「输出控制」的收益跟模型绑定：在 V3.1/V3.1-Terminus 上，把「直接给结论、不复述问题」写进系统提示词、把自由文本换成结构化输出，是实打实的降本；在 V3.2 上（1.46 倍）同样动作收益小得多。两档价的通用权衡见输入和输出为什么分开计价。
第二列告诉你「吃缓存」值多少钱，差异大得离谱。 V4-Pro 的普通输入是缓存输入的 13 倍，Flash 是 5 倍，V3.2 只有 2 倍，V3.1 不到 2 倍。同样是「把请求前缀做稳」这件工程活，在 V4-Pro 上等于把输入侧砍掉 92%，在 V3.1 上只能省下不到一半。
还有个容易被忽略的点：缓存输入是独立的第三档，不是「输入价打折」的说法，账单上是单独一个量。成本模型必须从两项变成三项，否则按两档价推的月预算，在命中率高时会系统性高估，命中率低时又让人误以为还有大量优化空间。
按业务形态算月成本
下面三组数字全部是我为了说明结构而设定的算例，不是任何真实项目的实测数据，只是照着官方标价做的算术演示。你要做的是把 token 假设换成自己的量级重算一遍——方法比结果重要。
形态 A：高频短问答
典型长相：客服首答、意图识别、审核前置过滤。请求数极大，单次输入输出都很短，系统提示词是一段固定不变的规则。
设定：系统提示词 1500 token 固定，每次用户输入 100 token，输出 120 token，每天 10 万次，按 30 天算即月请求 300 万次，用 V4-Flash。
- 输入总量 = (1500 + 100) × 3,000,000 = 4,800M token，其中固定前缀 4500M，变动部分 300M
- 输出总量 = 120 × 3,000,000 = 360M token
| 口径 | 输入侧 | 输出侧 | 月合计 |
|---|---|---|---|
| 前缀完全不命中缓存 | 4800 × $0.09 = $432 | 360 × $0.18 = $64.8 | $496.8 |
| 前缀全部命中缓存 | 4500 × $0.018 + 300 × $0.09 = $81 + $27 = $108 | $64.8 | $172.8 |
差额 $324，降幅约 65%；折成单价是每万次 $1.656 降到 $0.576。
特征一眼可见：输入里 4500/4800 = 93.75% 是那段一字不变的系统提示词。缓存收益在这种形态下最大，而且几乎不牺牲效果——只要那 1500 token 逐字节稳定，不塞时间戳、用户 ID、每次重排的示例。
档位判断：这种形态应该待在最便宜的档位上。任务简单、上下文短，Pro 的推理深度用不上，而请求基数大意味着单价上每一分差异都被放大 300 万倍。
形态 B：长文档处理
典型长相：合同摘要、论文提炼、长报告结构化抽取。单次输入极大，每份文档都不一样，前缀不重复。
设定：每次输入 80,000 token（一整份文档），输出 1,500 token（结构化摘要），每天 400 次，30 天即 12,000 次/月。输入总量 = 960M token，输出总量 = 18M token。
| 模型 | 输入侧 | 输出侧 | 月合计 | 单次成本 |
|---|---|---|---|---|
| V4-Flash | 960 × $0.09 = $86.4 | 18 × $0.18 = $3.24 | $89.64 | 约 $0.0075 |
| V3.2 | 960 × $0.26 = $249.6 | 18 × $0.38 = $6.84 | $256.44 | 约 $0.0214 |
| V4-Pro | 960 × $1.30 = $1248 | 18 × $2.60 = $46.8 | $1294.8 | 约 $0.108 |
最该注意的是输出侧几乎不影响结果：V3.2 那行输出只占总成本 2.7%。你花一整天优化摘要模板、把输出从 1500 压到 1000 token，省下两美元多一点；而输入侧动一动档位，是几百上千美元的量级。
缓存在这里基本吃不到——每份文档都是新的，前缀不重复，第三档价形同虚设。所以长文档处理纯粹拼输入单价，成本结构最接近按 token 称重卖。
档位判断取决于抽取难度，但有一条明确：在这个形态下选 Pro，理由必须是「准确率确实需要」，而不是「反正 Pro 更强」。Pro 的溢价会被 80,000 token 的输入量顶格放大，是所有形态里最贵的一种误选。要控成本又保准确率，可以拆两步——便宜档做初筛和切片定位，只把可疑片段交给强档复核。
形态 C：长对话 Agent
典型长相：多轮工具调用的 Agent、带完整历史的助手会话。历史随轮次不断变长，输出也不短。
设定：系统提示词 2000 token；每轮用户输入 200 token、模型输出 800 token；一个会话 20 轮；每天 2000 个会话，30 天即 6 万会话/月。
关键在于第 k 轮输入包含之前全部内容：第 k 轮输入 = 2000 + 200 + (k−1) × (200 + 800) = 2200 + (k−1) × 1000，从 2,200 涨到第 20 轮的 21,200。
- 单会话输入 = 20 × (2200 + 21200) ÷ 2 = 234,000 token；月量 234,000 × 60,000 = 14,040M
- 单会话输出 = 20 × 800 = 16,000 token；月量 960M
先记住这个比值：输入是输出的 14.6 倍。历史被反复重新计费，是长对话最容易被低估的一笔账——你觉得模型「只说了 16,000 字」，账单按 234,000 收。
再看缓存能吃到多少。每轮请求的前缀正是上一轮结束时的全部内容，只有本轮新增的 200 token 是全新的。可缓存部分 = 20 × (2000 + 21000) ÷ 2 = 230,000 token，新增 = 234,000 − 230,000 = 4,000 token（正好 20 轮 × 200）。月量：可缓存 13,800M，新增 240M。
| 模型 / 口径 | 输入侧 | 输出侧 | 月合计 |
|---|---|---|---|
| V4-Flash，不命中 | 14040 × $0.09 = $1263.6 | 960 × $0.18 = $172.8 | $1436.4 |
| V4-Flash，前缀全命中 | 13800 × $0.018 + 240 × $0.09 = $248.4 + $21.6 = $270 | $172.8 | $442.8 |
| V4-Pro，不命中 | 14040 × $1.30 = $18252 | 960 × $2.60 = $2496 | $20748 |
| V4-Pro，前缀全命中 | 13800 × $0.10 + 240 × $1.30 = $1380 + $312 = $1692 | $2496 | $4188 |
「全命中」是理想上界，实际拿不到这么满：命中与否取决于平台的缓存机制和前缀是否逐字节一致，会话中途插入摘要、裁剪历史、改写系统提示词都会打断前缀。真实命中率只能看自己账单里的 usage 统计，别拿这个上界做预算。前缀怎么设计、什么动作会打断命中，见提示词缓存怎么省钱。
这个形态最有意思的一点：缓存吃满之后，成本重心从输入侧翻转到输出侧。V4-Flash 全命中那行输出占 172.8 ÷ 442.8 ≈ 39%，V4-Pro 全命中那行占到 2496 ÷ 4188 ≈ 59.6%。也就是说缓存这刀砍完之后，继续降本的抓手换成「让每轮输出更短」——限制回复长度、冗长解释改要点、工具参数用紧凑 schema。而在缓存优化之前做这些，效果会被输入侧的噪声淹没。
档位判断：长对话 Agent 由输出价与上下文增长共同定价，两头都要管。选档位时要同时看输出价和缓存折扣力度——V4-Pro 的缓存折扣 13 倍、Flash 5 倍，这个差异会直接改变两者的账单倍数。
同一份工作量，换个模型的账单差多少
还是形态 C 的量，把 Pro 和 Flash 摆一起：
| 口径 | V4-Pro | V4-Flash | 差额 | 倍数 |
|---|---|---|---|---|
| 都不命中缓存 | $20748 | $1436.4 | $19311.6 | 约 14.44 倍 |
| 都是前缀全命中 | $4188 | $442.8 | $3745.2 | 约 9.46 倍 |
一年下来的差额分别是约 $231,739 和约 $44,942。这不是「省一点」，是预算量级的问题。
倍数从 14.44 掉到 9.46，原因值得单独说一句：普通输入价和输出价的 Pro/Flash 都是 14.44 倍，但缓存输入价 $0.10 对 $0.018 只有约 5.56 倍。缓存吃得越狠，两个档位之间的价差被压缩得越多。 反过来说，场景已经把缓存吃满时，降档能省的比例会比按挂牌价拍脑袋估的小；吃不到缓存时（比如形态 B），降档省下的就是完整的 14.4 倍。做选型评估务必在自己的缓存命中率下重算，别拿裸挂牌价的倍数去汇报。估算表怎么搭见怎么估算一个 AI 功能的月成本。
什么时候这个便宜不能占
降档不是无条件的，但「不能占」的边界要说清楚，不能停在「复杂任务用大模型」这种废话上。
先把 token 层面的账算完。假设降到 Flash 后有 15% 的请求结果不合格、需要重跑一遍完整会话，形态 C 的月成本从 $442.8 涨到 $442.8 × 1.15 = $509.22，相对 Pro 的 $4188 仍是约 8.22 倍的差距。重试率提到 50% 也才 $664.2，还是 Pro 的 1/6 左右。结论很硬：单纯的自动重试几乎不可能吃掉十倍的档位差。 谁用「小模型要重试所以不划算」反对降档，让他把重试率算出来。
真正吃掉差价的是人和不可重试的错误：
- 需要人工复核或返工的任务。 上面 $3745.2 的月度差额，用你团队的实际人力成本去除就知道每月能买多少工时；降档新增的人工核对工时超过这个数，降档就是亏的。各家答案不同，但它是可算的，别凭感觉拍。
- 错误代价不对称的任务。 财务金额抽取、医疗与法律文本、对外自动发送的内容，错一次的代价不是重跑的 token 钱，是赔偿、信誉、合规风险。这类任务的成本函数里 token 根本不是主项。
- 多步链条上的早期节点。 Agent 第一步判错，后面十步全白跑，还可能调用真实工具产生副作用。这种错误会被放大的位置值得单独上贵档，其余步骤该降就降。
- 提示词还没调好的时候。 很多「小模型不行」其实是提示词含糊、没给 schema、没给少样本示例。先把输出约束做扎实再判断模型够不够，否则一次失败的对照实验会让你为错误结论长期多付十几倍。
务实做法是分层而不是一刀切：按「错了会怎样」把任务分两三级，便宜档跑量、贵档兜住高风险节点，再用离线评测集把降档后的准确率量出来，别靠几次手工试用下结论。判断框架见小模型什么时候够用。
省钱清单：按「收益 ÷ 改动成本」排序
- 提高前缀稳定性，把缓存价吃满。 收益最大且基本不牺牲效果：系统提示词、工具定义、少样本示例固定在最前面且逐字节不变，时间戳、用户 ID、会话 ID、随机排序的示例统统挪到后面。改动量常常只是重排几段字符串，V4-Pro 上对应输入侧 13 倍的价差。
- 按任务分档，别全站一个模型。 分类、抽取、改写走便宜档，需要深推理的节点才上贵档。改动是在网关或调用层加一层模型路由，一次性工作，收益十几倍量级。
- 给输出加硬约束。 要求直接给结论、不复述问题，能结构化输出就别用自由文本，并设最大输出长度。在输出/输入比 3.5 倍以上的模型上（V3.1 系），这条收益接近选型级别。
- 长对话做历史裁剪，但保住前缀。 从中段裁，保留固定的头部前缀，别把开头的系统提示词一起改了——那会连缓存一起打掉，反而更贵。
- 把 usage 的 token 统计打进日志，按天、按模型、按接口聚合。 这条本身不省钱，但没有它前四条你都不知道有没有生效。重点看三个数：缓存输入占总输入的比例、输出/输入比、单位业务动作的成本。
- 给每个接口设成本上限和告警。 单次请求 token 上限、单用户日限额、单接口月度预算告警。防的不是常态成本，是异常——一个死循环的 Agent 能在几小时内烧掉一个月预算。
- 上线前用小批量跑出自己的单位成本。 挂牌价只是单价，你要的是「每个业务动作多少钱」。拿几百次真实流量跑一遍用账单反推，比任何估算表都准。
前四条是降本，后三条是防失控，顺序别倒过来。我见过团队花两周做模型路由，因为没有告警，一次线上循环调用把省下的钱一晚上还了回去。更多结构性手段见大模型 API 成本优化实战。
诚实边界：本文不写限速与免费额度
本文不给出 DeepInfra 的任何速率限制数值，也不说它有没有免费额度或注册赠送。
原因是这两项我没有拿到可核实的官方来源，编一个「大概多少 RPM」对你没有任何好处——你会拿它做容量规划，然后在生产环境里发现是错的。请以官方控制台和官方文档为准。
但这件事必须在成本文章里点出来，因为限速会直接影响成本估算，而且是往上影响：撞限会触发重试，重试是真实成本。429 之后的退避重试，如果请求已经把输入发出去了，那部分 token 有没有计费、怎么计费，得你自己在账单上核实；更常见的是，为了绕开撞限，团队会把请求拆小、把批处理改成单条，结果每条都要重新带上完整的系统提示词——同样的业务量，输入 token 总量凭空涨一大截。我见过并发策略一改、输入量翻倍却没人察觉的情况，因为大家只盯「调用次数」，没盯「token 总量」。
限速未知时怎么稳妥起步，是一套比具体数字更耐用的通用方法（数字会变，方法不会）：低并发起步，先确认在明显安全的水位下功能全部正常；把状态码分布、耗时分布、429 频次埋好再阶梯式加压，找 429 开始零星出现的那个点，那是你这个账号、这个模型、这个时段的真实水位；退避重试提前备好并单独计数进监控——重试次数就是你多花的钱，必须可见；并发数和 QPS 上限做成按模型可热改的配置项，别写死。
最重要的一条是：与其纠结理论峰值，不如先用小批量把「每个业务动作实际花多少钱、实际消耗多少 token」测出来。有了单位成本，任何容量目标都能直接换算成预算，容量规划才有意义。
最后回到开头。DeepInfra 的三档价里，真正决定账单量级的是模型那一栏填了什么，其次是请求前缀稳不稳，最后才是提示词写得长不长。这个顺序反过来做，就是最常见的那种局面：花两周精简提示词省下 8%，而旁边那个一直没人质疑的模型选型，白白多付了十几倍。