deepseek v3.2 api价格

准备接 DeepSeek V3.2 的人最常卡在两步：一是官方页面上那一串单价到底怎么对应到自己的调用上，二是算出来的预估和月底账单对不上。这篇不报具体数字，只讲计价口径怎么读、用量怎么倒推成本、上线后按什么顺序核对，最后给一份能直接抄的成本控制清单。

接一个模型之前先算账，比接完再补救省事得多。DeepSeek V3.2 的价格页面本身不长，但真正让开发者算不准的，往往不是单价本身，而是「这条请求到底算输入还是输出」「缓存算不算命中」这类口径问题。把口径对齐了，再去填用量，预估值和月底账单才有可能对上。

这篇不讲某个具体数字，只讲怎么读计价结构、怎么从自己的日志倒推出月度成本、上线后按什么顺序检查。如果你只是想抄一个报价，这篇帮不上；如果你要负责一个会持续跑量的调用方，下面这套顺序能直接用。

先把计费口径拆成四项：输入、输出、缓存写、缓存读

很多人以为一次请求就是一个单价乘总 token，实际不是。输入和输出分开计价，缓存命中的那一段又走另一档。所以判断成本之前，先确认自己这次调用落在哪几档里，再去官方页面看当时的单价，路径是 /official-api/providers/deepseek。

输入 token

你发给模型的全部内容，包括系统提示、历史对话、检索到的资料

输出 token

模型生成并返回给你的内容，通常单价结构和输入不同

缓存写

把一段可复用的前缀存进缓存，这一档的价格口径和普通输入不一样

缓存读

后续请求命中缓存、直接读取那一段，成本结构又不同于普通输入

缓存的实际意义在于命中率。同一段系统提示或固定知识前缀被反复复用，命中率就高，整体单价结构会往便宜那档偏；反过来，每轮 prompt 都重写一遍，命中率接近零，就按普通输入来估算更接近真实。

从用量记录倒推月成本：三步公式与参数取值

1. 统计四个量从你自己的调用日志或平台用量页，分别取输入 token、输出 token、缓存写 token、缓存读 token。别凭感觉拍，至少取一个有代表性的一周数据。
2. 分别乘单价再相加把每个量乘以官方页面当时的对应单价，路径 /official-api/providers/deepseek。先看输出侧占总成本的比例，决定后面优化往哪个方向使劲。
3. 乘日调用量再乘 30得到月度区间，同时留一段缓冲，用来覆盖重试、失败调用和流量波动，别按理论最低值做预算。

如果日志里字段不全，先补日志再算。字段缺了就算不准，算出来也只是自我安慰。字段齐了以后，可以拿 /tools/model-cost-calculator 代一遍，互相验证；用量口径不清楚的，去 /usage 看真实用量榜是怎么统计的。

读官方价格表时该抓哪几栏，哪些先别看

官方价格表一眼看过去信息很多，但真正影响你估算的只有几栏。抓错了单位，后面全错；抓多了参考项，反而干扰判断。建议按下面这个优先级看。

• 第一栏看计价单位：是每百万 token 还是每千 token，单位差一个量级，整张表就白算了
• 第二栏看是否区分标准价、批量价、错峰价，不同口径不能混着加总
• 第三栏看缓存相关的两档有没有单独列出，有就说明命中确实走另一档
• 限速和并发上限不是价格，但会决定你需要不需要多账号或走中转，成本口径要一起考虑
• 其余细项先跳过，等主账算完再回来查，避免一开始就被细节带偏

走中转的情况要单独想。官方单价只是基准，实际支出还要按渠道倍率折算。多一层渠道，账变复杂，但通常换来的是可用性和接入速度。选渠道之前，先到 /sites 看各个中转的说明和可信度记录，别只看价格数字。

上线后的成本控制清单与核对顺序

前面是算账，这一节是控账。跑起来之后，成本失控通常不是因为单价涨，而是因为调用方式失控：输出没上限、重试没刹车、批量没攒。下面这份清单可以直接按顺序落地。

对账这一步值得单独说。顺序是先导出用量，再按当时单价复算，然后比对实际扣费，最后定位差异项。差异大多来自没算进去的重试调用、缓存命中率低于预期、以及输出被控制在预算外的场景。复算口径的具体方法，token-cost 那篇已经讲透，这里不重复。

• 先看输出侧成本占比，占比高就先压输出长度
• 再看缓存命中率，命中率低就检查前缀是不是每次都变
• 最后看重试与失败调用，这部分常被漏算，却最容易把月度预算顶穿
• 调整后不要只看一天数据，至少观察一个完整周期再判断是否真的降下来