最便宜的大模型 API 盘点：性价比排行与选型建议
“最便宜”不等于”单价最低”——用一个便宜但需要 3 倍 token 才能完成任务的模型，实际花费反而更多。真正的性价比衡量标准是：完成同一任务的实际总 token 成本。
声明：以下所有价格描述均为截至 2026-06 的定性判断，仅供参考，以各厂商官方定价页面为准。
单价低 ≠ 成本低：两个容易踩的坑
| 陷阱 | 描述 | 实际影响 |
|---|---|---|
| 便宜模型需要更多轮次 | 能力弱时需要反复追问才得到可用答案 | 多轮对话累计成本超过一次旗舰调用 |
| 便宜模型输出冗余 | 部分轻量模型”废话”更多，输出 token 偏多 | 输出贵于输入，冗余输出直接加价 |
正确做法：针对你的核心任务做 A/B 测试，比较”一次成功完成任务”的总 token 数，再乘以单价。
一个演算例子：便宜模型为什么可能更贵
下面这组数字是方法论演示，不是任何厂商的真实报价，只是想让你直观看清”单价×次数”这笔账怎么算——具体价格你换成自己实测拿到的数字就行。
假设你在做一个”从客户邮件里抽取工单类型”的任务：
- 轻量模型单价是旗舰模型的 1/10，但对复杂措辞的邮件经常抽错类型，你的重试逻辑平均要追问 2.5 次才能拿到能用的结果；
- 旗舰模型单价贵 10 倍，但一次就能抽对，几乎不需要重试。
按”每次调用的 token 数量差不多”这个简化假设来算：轻量模型的实际成本 = 单价 × 2.5 次，旗舰模型的实际成本 = 单价×10 × 1 次。两边一比，轻量模型反而贵了 4 倍。这就是为什么你不能只看价目表上的单价，得看你的任务在这个模型上平均要跑几轮才能收敛。
反过来，如果你的任务本身简单（比如判断一条评论是好评还是差评），轻量模型基本一次就对，这时候单价低就是真省钱，没必要为了”保险”上旗舰模型。先测准确率，再算总成本，顺序不能反。
国产 vs 海外：定性价格层级
国内主流厂商
国内厂商在价格竞争上整体积极，轻量模型往往有 免费额度或极低起步价，适合以下场景：
- 中文内容生成、摘要、分类
- 对延迟不极端敏感的批量任务
- 初创项目冷启动阶段控制成本
定性特征：
- 轻量模型：价格极具竞争力，部分接近免费
- 标准对话模型：比同级海外模型便宜，通常低一个量级
- 旗舰模型：与海外旗舰差距缩小，但仍有一定优势
海外主流厂商（OpenAI / Anthropic / Google）
- 旗舰模型能力仍在多数评测中领先
- 价格相对较高，但 Batch API 机制可在非实时场景提供约 50% 折扣
- Prompt Caching 机制成熟，重复系统提示场景下实际成本大幅下降
- 适合对输出质量要求极高的场景：法律文书、代码生成、复杂推理
Batch API 为什么便宜、什么时候不能用：厂商把 Batch 请求放进一个异步队列，不占用实时推理的算力资源，通常几分钟到 24 小时内出结果，正因为不用”随叫随到”，才能给你折扣。代价是你拿不到实时响应——用户在线等结果的场景（客服对话、代码补全）用不了，但离线批量任务（夜间跑完一批文档摘要、给历史工单打标签、生成第二天要用的报告）非常合适。实操上你需要把任务攒成一个批次一次性提交，而不是循环单条调用再等，否则拿不到折扣价，还会因为你自己写了个”伪实时”的轮询逻辑而白白消耗请求配额。
Prompt Caching 为什么便宜、坑在哪：厂商会把你提交的 prompt 前缀（通常是较长的 system prompt、少样本示例、固定知识库片段）缓存一段时间，命中缓存的部分只收极低费用甚至不收费，你只要为”变化的那一小段”付费。这里的坑是前缀必须逐字节完全一致，哪怕你在 system prompt 里插了一个当天日期变量，缓存就整体失效，你以为省了钱，实际每次都在全价计费。另外缓存有 TTL（通常几分钟到几十分钟），调用间隔太长缓存会过期，高频调用的场景才划算，偶尔调一次基本吃不到红利。建议把”会变的内容”（用户输入、时间戳）放在 prompt 末尾，“不变的内容”（角色设定、规则、知识库）放在前面，这样命中率才高。
按场景推荐的选型思路
| 场景 | 推荐档次 | 理由 |
|---|---|---|
| 关键词分类、意图识别 | 轻量模型 | 简单任务，准确率够用，成本低 |
| 普通问答、客服 Bot | 标准对话模型 | 平衡质量与成本 |
| 长文档摘要（批量） | 标准模型 + Batch API | 非实时可大幅折扣 |
| 复杂代码生成 | 旗舰模型 | 错误成本远高于 token 成本 |
| 多步推理、数学证明 | 推理模型（谨慎） | 按需使用，成本高但不可替代 |
推理模型：最贵的那一档
o3、R1 等推理模型的”思考过程”也算 token，单次调用成本可能是普通模型的 5–20 倍。
使用建议：
- 不要把推理模型当默认模型
- 只在普通模型反复失败的任务上切换
- 设置输出长度上限，避免思考链无限展开
“思考链无限展开”具体是什么现象：你会看到调用耗时明显变长（几秒变几十秒），返回的 usage 里 reasoning/thinking 相关的 token 数远超你预期的输出长度，账单上这次调用的花费比你估的高出好几倍。常见诱因是任务描述本身模糊，模型在”思考”阶段反复自我推翻、绕圈子——这时候不是加钱能解决的，回头把任务拆得更具体、把约束写清楚，往往比单纯加大 token 上限更有效。如果只是想止损，先把输出长度上限设住，超限直接截断报错，好过账单失控。
性价比评估实操步骤
- 确定你的核心任务（分类/生成/摘要/推理）
- 准备 20–50 个代表性样本，尽量覆盖简单和刁钻的边界情况，别只挑好回答的样本，不然线上遇到难样本时你的成本估算会失真
- 同时跑 2–3 个候选模型，记录每次的 input/output token
- 按各厂商当前定价算出”每个样本的实际成本”
- 结合输出质量评分，得出性价比排名
统计 token 时最容易踩的坑：不要自己用字符数或者第三方分词器估算 token 数再去乘单价，不同厂商、不同模型的分词方式不一样，估出来的数字跟账单对不上。以 API 响应里返回的 usage 字段（input_tokens / output_tokens，或者 prompt_tokens / completion_tokens）为准，这才是厂商真正计费的口径。如果你的调用链路里有工具调用（function calling）或者多轮上下文拼接，注意 usage 里往往会把历史上下文也算进 input，跑批量测试时容易漏算这部分，导致你以为很便宜、实际线上跑起来账单蹭蹭涨——这也是为什么要用真实的多轮场景去测，而不是只测单轮的”标准问答”。
命中 Prompt Caching 的调用，usage 里通常会单独拆出一个”缓存命中的 token 数”字段（不同厂商命名不同），这部分按更低的价格计费。做成本估算表的时候记得把这一列单独列出来，不然会把命中缓存的低价请求和没命中的全价请求混在一起算平均，得出一个既不代表最好情况也不代表最坏情况的错误均值。
建议配合 价格对比表 实时查当前报价，用 token 计算器 估算 prompt 大小。
隐藏成本：重试和限流也在偷偷花钱
真实生产环境里，除了正常调用的 token 费用，还有一块很多人算漏的支出：因为报错而重复调用的钱。
- 429（触发限流）：厂商对你的账号或 API Key 设了 QPS/TPM（每分钟 token 数）上限，超了就直接拒绝这次请求。如果你的重试逻辑是”立刻重试”而不是带退避的重试，很可能第二次、第三次还是 429，你等于在空转——请求没跑成，但排队、鉴权这些前置开销一样发生，高并发场景下这类无效请求的量可能相当可观。正确做法是指数退避（比如首次等 1 秒，失败再等 2 秒、4 秒，加一点随机抖动避免多个请求同时重试撞车），并且把并发数主动控制在厂商给的限额之内，而不是撞了墙再退。
- 超时：网络抖动或者模型生成时间超过你设的客户端超时阈值，请求会被你自己的代码判定为失败发起重试，但厂商那边可能已经在正常生成、马上就要返回结果了——你的重试请求和原请求一起算钱，等于为同一个任务付了两份钱。这里的取舍是把超时阈值设得比你观察到的 P99 响应时间稍长一点，而不是照抄一个默认的短超时值。
- 上下文超限（context 超限）报错：把过长的历史对话或文档一次性塞进 prompt，超过模型的上下文窗口会直接报错拒绝执行，这次调用等于白打——你付出了拼接、发送的成本，却什么结果都没拿到。排查思路是提前用 token 计算器估算 prompt 长度，超限前主动做截断或摘要压缩，而不是等报错了才手忙脚乱地砍内容。
这三类”隐藏成本”平时不显眼，但在高并发或者长时间运行的服务里，累积起来可能占到总账单的一个不小比例。建议在你的调用层加一层统计：记录每次调用是”首次成功""重试后成功""重试耗尽失败”，定期看这三类的占比，占比高说明你的并发控制或者超时参数设置得不合理，该调的是工程参数，不是模型档位。
常见问题
国产模型中文效果更好吗？
中文任务上国产模型通常有优势，且价格更低，是中文业务场景的首选。英文重度任务则需要实测对比。
有没有完全免费的大模型 API？
部分厂商提供有限免费额度（如每日调用次数上限），适合开发测试。生产环境建议使用付费计划以保证稳定性和 SLA。
价格会变吗？
大模型定价变动频繁，竞争激烈时常有降价。建议定期用 价格对比表 复核，并在代码中做好模型切换的抽象层。
Batch API 提交后多久能拿到结果？
不同厂商的 SLA 不一样，从几分钟到 24 小时都有可能，具体以官方文档承诺为准。设计流程时不要假设它是”稍等一下就好”的准实时接口，要按异步任务的思路做——提交后轮询状态或者等回调通知，业务上给自己留够缓冲时间，别把强实时性的需求塞进 Batch 里。
为什么我测出来的成本比官方价目表算出来的高很多？
八成是漏算了上面提到的隐藏成本：多轮重试、上下文越滚越长导致的 input token 膨胀、没吃到 Prompt Caching 折扣却按全价统计。建议把”实际账单总额 ÷ 成功完成的任务数”作为你最终的性价比口径，这个数字比拿单价乘以理论 token 数更接近真实情况。
延伸阅读：
- 计费原理全解：大模型 token 计费完全指南
- 省钱技巧大全：大模型 API 成本优化 10 招
- 缓存命中省钱：Prompt Caching 省钱原理与实践
- 实时价格查询：价格对比表工具
- Token 用量估算：Token 计算器
- token 成本专题：成本话题 Hub
- 降低接入运维负担：加入候补