deepseek-v3怎么收费的

很多人第一次用 DeepSeek-V3，是拿一个任务跑完才发现账单和心里估的差一截——单价到底是按什么单位收、缓存命中省在哪、月中对账该看哪几栏，都不太清楚。这篇按「先对齐口径、再算自己的量、最后核对」的顺序讲一遍，单价和折扣力度一律不写死，直接去站内页面看当时的数字。

不少人第一次接触 DeepSeek-V3 的计费，是任务跑完之后才回头看账单，然后发现跟心里估的差了一截。差在哪往往不是单价本身，而是口径没对齐：到底按什么单位收、输入输出是不是一个价、缓存命中的部分算不算折扣，这几件事没搞清，估算就会偏。

这篇按「先对齐口径、再按自己的用量倒推、最后每月核对一次」的顺序讲一遍。单价和折扣力度这里一个数字都不写，全部让你到站内页面去核对当时的报价，因为这类数字变动很频繁，写死了反而误导。

先分清它按什么收：输入、输出、缓存三类量

DeepSeek-V3 走的是按 token 计费，账单里通常会把「输入」和「输出」分开列。输出单价一般高于输入，所以同一段对话里模型回得越长，花得越多。很多人估成本只记了一个「每百万 token」的单价，结果实际差出一大截，问题就出在输入输出被混成了一锅。

还有一类最容易被忽略的量：缓存命中与缓存写入。命中缓存的那部分输入按折扣口径计，没命中的按原价走，两者通常会出现在同一张账单的不同列里。判断自己有没有被缓存影响，看账单结构比看总金额快——先看有没有单独列出缓存相关项，再看输入那一列是不是被拆成了两段。

输入 token

你发给模型的那部分内容，包括系统提示、历史对话、贴进去的文档

输出 token

模型生成返回给你的那部分，单价通常高于输入

缓存命中

请求前缀跟之前重复、被系统复用到的输入量，按折扣口径计

缓存写入

第一次把这段前缀写进缓存时产生的量，是否计费看站内当时的说明

如果你的调用方式根本不带缓存机制，比如每次请求都拼一段全新、不重复的上下文，那缓存折扣这块对你就是零。别人晒出来的折扣比例别直接往自己身上套，口径不一样，比出来的数没有意义。各类计费项的当时口径，去 /price-watch 对一遍最稳。

缓存折扣只在这些情况下才真的省到钱

缓存能省的前提是「前缀重复」：同一段系统提示、同一份长文档、同一套工具定义被反复带进请求，系统才有东西可命中。每次换一段全新上下文，命中率自然上不去。命中率本身不是你能直接设的参数，但它跟你的请求构造方式强相关。

• 固定不变的内容尽量放前面：系统提示、角色设定、长文档这类每次都一样的东西前置，变化的部分后置。
• 同一份长上下文要多次提问时，尽量在同一个会话或短时间窗口里连问，别隔很久重新拼一遍。
• 定期看账单里命中量占输入总量的比例，这个比例上不去，说明请求构造还有优化空间。
• 短对话、一次性任务、上下文几乎不重复的批处理，缓存带来的差异可能小到可以忽略，硬去改造反而增加维护成本。

算成本时要分开估：命中部分的输入量按折扣口径算，未命中部分按原价算，两者相加才是总输入成本，再叠加上输出成本。只用一个输入单价乘总量，估出来的一定偏——偏多还是偏少，取决于你的命中率高不高。

用自己的用量倒推花费，而不是记单价

1. 先统一单位去站内页面把当时的单价口径对一遍，注意它标的是每千 token 还是每百万 token，统一成同一个单位再动手算。
2. 拉出自己的用量从平台用量页或自己的调用日志里导出最近一段时间的记录，至少要能分出输入 token 和输出 token 两项。分不出来的话，先按经验比例估一版，再逐步把日志字段补上。
3. 把缓存单独列一栏把「缓存命中的输入量」单独拎出来，命中部分和未命中部分各乘对应单价后相加，这才是你下个月大概要花的钱。
4. 和上月账单对一遍把算出来的数跟实际账单比，差在两成以内说明口径基本对齐；差得远，多半是漏了缓存列或把输入输出混在一起了。

每月一次的核对清单：三步把账对平

1. 对量账单上的输入、输出 token 数，和平台用量页对不对得上？对不上先查是不是有多个 key 或多个项目在同时跑。
2. 对价拿账单里的分项除以对应的 token 量，反推出实际生效的单价，再和站内当时公布的口径比一遍，看有没有偏差。
3. 对钱把充值记录、赠送额度的抵扣顺序、实际扣费三者排成一条时间线，看有没有哪一段对不上。这一步能顺带发现是不是有渠道在中途加价。

核对频率一个月一次、十分钟就够，不用天天盯。出现明显偏差时先别急着下结论，把当期有没有改过模型别名、有没有切过中转渠道这两件事查一遍，多数异常都出在这两处。