按量付费时，很多人只看单价，以为推理专用模型单价高就一定更贵。实际上输出 token 更多，而且简单任务会被绕远路，账单反而翻倍；反过来，如果把本该用推理模型的活交给通用模型，重试几次也照样烧钱。这篇不报具体数字，只讲清楚费用差由哪几项构成、怎么用站内工具算自己的账，以及哪些情况下这套判断不适用。
按量付费的时候，很多人选模型只看单价那一列，觉得推理专用模型单价高就一定更贵，通用模型便宜就闭眼用。实际账单经常相反：推理模型输出里带着一长串思考内容，同样一个最终答案可能多写好几百个 token；而把本该推理的活丢给通用模型，答一次错一次、重试两三次，钱照样烧。所以「哪个更省钱」不是一个固定答案，而是一套要按你自己的调用数据算一遍的方法。
这篇不报任何具体数字，只讲清楚费用差由哪几项构成、怎么按任务类型分派、以及怎么用站内工具把自己的账算出来。最后还会说清楚这套判断在哪些情况下不成立，免得你拿一个并不适合自己业务的方法去做决定。
先拆开：一份账单里到底有哪几笔钱
按量付费实际花的钱，是输入 token 数乘输入单价，加上输出 token 数乘输出单价，两项加起来。只比单价那一列会严重误判，因为两个模型的输出长度根本不是一个量级：推理专用模型的输出往往包含大量思考内容，同样的最终答案要多写不少 token，单次调用的花费可能翻上去。
通用模型这边还有一笔隐性成本容易被忽略：答不对就重试、反复改提示词、人工核对结果，这些都要计入总账。一笔调用便宜但要做三次才靠谱，和一笔调用贵一次就对，谁更划算要看任务，不能拍脑袋。
| 费用项 | 推理专用模型 | 通用模型 |
|---|---|---|
| 输入 token | 按输入单价计 | 按输入单价计 |
| 输出 token（含思考过程） | 通常明显更多 | 通常更少 |
| 重试与改写提示词的调用 | 较少 | 视任务难度可能较多 |
| 人工核对时间 | 较少 | 任务越绕越多 |
| 延迟带来的时间成本 | 较高 | 较低 |
具体做法是：把候选模型的单价抄下来，再按你自己业务里真实的平均输入长度、平均输出长度各算一遍。比例不同，结论可能整个反过来。到 /tools/cost-calculator 按自己的数据填一遍，别直接用默认值。
按任务类型分：哪些活通用模型就够了
改写、摘要、翻译、格式转换、关键词抽取这类任务，答案空间很窄，正确写法基本就那几种。让模型在脑子里绕一大圈再输出，绕的那部分 token 全是白花的。这类活通用模型直接给结果，通常又快又便宜。
分类和简单判断也是同理。提示词写清楚、给几个例子之后，通用模型的正确率一般够用，出错也是偶发的，重跑一次的成本往往低于让模型长时间思考。判断标准可以简单点：如果你自己看一眼输入就能写出答案，那这个任务大概率不需要模型显式思考。
- 改写、润色、摘要、翻译：通用模型优先
- 格式转换、字段抽取、关键词提取：通用模型优先
- 简单分类、意图识别：提示词写清楚后通用模型够用
- 带条件分支的规则套用：先小样本测通用模型，错得多就换
- 多步计算、代码调试：别在通用模型上硬试
不适用的情况也要说清楚：任务要求可解释的推导链，或者出错代价远高于 token 成本，比如合同条款归并、财务报表口径核对这类，这时候该偏向推理模型，省下的不是 token 钱而是返工钱。
哪些活交给推理模型才真省
多步计算、带条件的规则套用、代码调试这类任务，通用模型答错的概率明显更高。一次答错加上两三次重试，成本就追上推理模型了，还没算你人工核对的工夫。这种任务上交钱给推理专用模型，反而是省的那一方。
评估方法不能靠感觉。从自己的历史调用里挑一批典型请求，用两种模型各跑一遍，统计「最终答对所需的调用次数 × 单次 token 量」，这才是两边可比的口径。只看单次调用谁便宜，等于只看一个回合定胜负。
| 任务特征 | 优先考虑 | 理由 |
|---|---|---|
| 有唯一标准答案、步骤固定 | 通用模型 | 思考过程用不上 |
| 需要多步推导、条件判断 | 推理专用模型 | 减少重试次数 |
| 实时对话、延迟敏感 | 通用模型 | 响应更快 |
| 出错代价高、需可解释 | 推理专用模型 | 推导链能拿来复核 |
还有两个容易踩的坑。一是延迟：思考型模型在简单任务上响应更慢，实时对话场景里时间成本也要算进总账。二是格式：输出格式要求极严、模型常把思考过程写进最终答案时，先调提示词再比较，否则你比出来的是格式问题，不是模型差异。
实操：用站内工具给自己的业务算一笔账
上面讲的是判断逻辑，落到你自己身上要跑一遍流程。下面这四步按顺序做，做完基本能定主力模型。全程用的都是站内页面，数据以你打开时看到的为准。
- 抄单价到 /api-pricing 把候选模型的输入、输出单价记下来，注意区分是否单独给思考 token 计价。
- 按自己比例算用 /tools/token-price 和成本计算器，按日志里的平均输入长度、平均输出长度跑一遍，别用默认比例。
- 确认是否调过价翻 /price-watch 看最近有没有调价，别拿半年前的印象做决策。
- 小流量灰度挑一部分流量同时跑两种模型，对比真实账单和正确率，再定主力模型和省钱模型的分工。
什么情况下这套算法不成立
这套算法成立的前提是按量计费、按 token 定价。一旦前提变了，结论就可能完全反过来，所以先确认自己属于哪种计费方式，再决定要不要按上面的方法算。
- 有免费额度或包月套餐：单价不是主要成本，该看额度和限流
- 走中转站：计费口径可能和官方不同，倍率、是否计思考过程都会影响结论
- 本地部署或自建推理：成本变成显卡和电费，token 单价这套账直接失效
- 输出极短的任务：思考 token 占比被放大，单价对比的意义下降
走中转站的话，先到 /rankings 和 /sites 核对该站的计费说明和可信度记录，别拿官方单价直接套中转站账单。折扣背后如果计费口径不一样，算出来的省钱可能是假象。
常见问题
推理模型单价那么高，是不是一定更贵？
不一定。贵不贵要看「答对一次总共花多少」，也就是调用次数乘单次 token 量。任务难的时候通用模型反复出错，重试几次的总花费常常追平甚至超过推理模型；任务简单的时候推理模型会写一大堆思考过程，那就明显更贵。
怎么快速判断一个任务该用哪种？
先问自己：让一个没背景知识的同事看输入，他能不能直接写出答案。能，就用通用模型，提示词写细一点就行；不能，并且错一次的代价明显高于 token 钱，就上推理模型。中间地带的任务用两种模型各跑一批真实请求对比。
通过中转站调用，会比官方更省钱吗？
要看具体倍率和计费口径，不能一概而论。有些站把思考过程也算进计费，有些有隐藏限流。下单前先去站内中转站排行榜和全部中转站页面看检测结果，再用小流量试一周，看真实账单，别只看宣传的折扣。
