deepseek-chat价格

打算把 deepseek-chat 接进项目的人，通常会卡在两件事上：一是价格表上的输入、输出、缓存几栏到底怎么对应自己的调用；二是接完之后账单跟心里那个数对不上。这篇不背数字，只讲计费结构怎么看、哪些变量会改变你的单次成本，以及从查价到月度核对的完整动作。

打算把 deepseek-chat 接进项目的人，卡点通常不在接口调通，而在两个更靠后的问题上：价格表里的输入、输出、缓存几栏，到底怎么对应自己代码里的一次调用；接上线之后，账单跟心里估的那个数又对不上。这两件事其实是一件事——你没把计费口径和自己的调用习惯对齐。

这篇不背任何数字，也不给「便宜多少」这种结论。只讲 deepseek-chat 的计费结构该怎么看、哪些变量会改变你的单次成本，以及从查价、测算、控本到月末核对的一整条动作链。数字一律以站内当期页面为准，因为价格会变，写死的数字第二天就可能过期。

先把计价单位对齐：deepseek-chat 的钱是按什么算的

看懂价格表的第一步，是承认它按 token 计费，不按请求条数，也不按你敲进去多少个汉字。请求条数只决定你调了多少次接口，真正扣钱的是这些请求带进去和吐出来的 token 总量。理解这一点，后面所有栏位才有意义。

价格表一般把输入和输出拆成两栏，且输出通常比输入贵。这意味着同样是一千次调用，做短摘要和做长文生成，成本结构完全不是一回事。你在做预算时，不能只估「大概调多少次」，得估「每次喂进去多少、产出多少」。

缓存相关的栏位是独立计价项，别想当然地把它等同于输入价。它有自己的命中条件和单价，只有你的调用模式满足「大量重复前缀」时，命中率才上得去。一次性问答、每次提示都不一样的场景，基本蹭不到这块。

• 按量计费的基本盘是 token，请求次数和字数都只是中间量，不能直接拿去算钱
• 输入与输出分栏计价，输出占比高的任务，总价天然更高
• 缓存是独立栏位，需单独确认命中规则和单价，不要默认它等于输入价
• 拿 deepseek-chat 跟别家模型比价前，先确认双方分栏口径一致，口径不齐的对比结论无效

查价只看官方那一页，别用二手截图

价格是决策依据，所以来源必须是当期官方页。二手文章、群里转的报价截图，最大的问题是时效——改价之后旧数字还会长期流传，你照着它做预算，最后对不上账还以为是平台算错了。要核对 deepseek-chat 的当期单价，直接去 官方 API 的 DeepSeek 页面（/official-api/providers/deepseek）看当时的数字，这是唯一该作为依据的来源。

如果你想横向看别家模型在对应档位上的情况，用 官方 API 资料库（/official-api）和 推理服务导航（/inference）做同口径对照，别把不同计价口径的数字直接摆在一起比。价格变动比较频繁的时候，记单点数字没多大意义，去看 价格追踪（/price-watch）的走势，比记某一天的数字有用得多。

决定你一个月花多少的四个变量

同一个模型，两家团队用出来的月账单可能差很多，差别就在下面这四个变量上。把这四个先搞清楚，比记住任何单价都管用。第一是调用量，注意它是请求条数乘以平均 token 数，多轮对话会把历史上下文反复带上，每一轮都重新计费，容易超预期。

第二是输入输出比例。同样的调用次数，输出多的任务总价明显更高。第三是缓存命中，命中部分和未命中部分单价不同，命中率一掉，账单曲线立刻变陡。第四是上下文长度，长文档、长代码库这类场景，输入 token 会被整段计入，跟短提示完全不是一个量级。

接入前先做一次小规模测算，别等月底才发现

接入前花半小时做一次测算，能省掉月底对账时的很多困惑。做法很简单：从真实业务里抽一批有代表性的请求，跑一遍，把每次的输入 token 和输出 token 记下来，看清楚分布情况。别用「我觉得大概」来估，要拿实际数字外推到一个月的量。

1. 抽样从真实业务里取一批典型请求，覆盖长短两种极端，别只挑平均案例。
2. 记录把每次请求的输入 token、输出 token、是否命中缓存分别记下来，形成分布。
3. 换算用 Token 与价格换算工具（/tools/token-price-calculator）或 模型成本测算工具（/tools/model-cost-calculator）把 token 量换成金额，避免心算出错。
4. 外推与留档按日均调用量外推到月度，峰值和均值分开算，测算结果留档，作为日后对账的基准线。

能立刻落地的几件降本动作

降本不是单纯换便宜档位，大多数浪费发生在提示词和调用结构上。下面这几件事，改起来不需要重新设计架构，当天就能验证效果。做的时候记得一次只改一项，否则你分不清是哪项起了作用。

• 缩短输入：压缩固定的系统提示，裁掉不必要的历史轮次，长文档先分块再送，不要整篇塞入
• 控制输出：在提示里明确约定输出长度和格式，避免模型自由发挥出一大段没人看的解释
• 按任务分层：简单分类、抽取类任务先测便宜档位够不够用，不必一律上最贵的
• 缓存策略对齐调用模式：只有重复前缀多的场景缓存才有意义，一次性问答别指望它

判断某项值不值得做，标准是「它能不能同时降低 token 量和降低出错率」。如果只是把输入砍短却让模型开始理解错、输出变长补偿，那这项改动就是白忙。改动前后各测一批请求，用同一套测算工具对比，才看得出来到底有没有省。

给项目设一条花钱的红线

预算要分两层做：月预算是上限，日观察是发现异常的速度。只设月预算，等你发现超了的时候，往往已经烧了半个月。要有日维度的观察指标，才能在两三天内看出不对劲。设阈值告警的思路上，可以参考 预算告警的分层闸口做法（/guides/budget-alert-five-gates），把提醒和硬拦截分成不同层级。

另一个常被忽略的动作，是把开发环境和线上环境的 key 分开。调试流量混进生产账单，是月末对不上账的常见原因之一。分开之后，两类流量各自可查，出了问题也能定位到具体环境。

但预算不是越紧越好。阈值压得太低，会影响正常的重试逻辑和业务峰值，反而带来别的问题。合理的做法是先按真实测算给出上限，再往上留一段缓冲，而不是一上来就卡死。

月末核对：三步把账和用量对上

对账不是查有没有被多扣钱，而是验证你当初的测算假设还成不成立。做法分三步。第一步，拿出平台的用量明细，按接口或按 key 分组，跟你自己日志里的请求条数对上，看数量级是否一致。

第二步，挑出金额最高的那几条记录，回看这批请求的输入输出长度是不是异常，往往问题就集中在这几条上。第三步，把差异归因到具体变量：是调用量涨了、输出变长了，还是缓存命中率掉了。归因不清的差异，记录下来，下次测算时修正假设。

价格数字会变，计费结构不会天天变。把结构搞清楚，改价时才不用重学一遍。