各类大模型api接口价格表

很多人拿到账单才发现，同样是调接口，不同厂商的计费口径根本不是一回事：有的把输入输出分开算，有的把缓存命中单独折价，有的把推理过程也计进输出。这篇不讲协议怎么接，只讲怎么把价格表读懂、把额度算清、把成本控制住。看完你会知道该去哪几个站内页面核对当时的数字，以及哪些口径差异最容易被忽略。

很多人拿到账单才发现，同样是调接口，不同厂商的计费口径根本不是一回事：有的把输入输出分开算，有的把缓存命中单独折价，有的把推理过程也计进输出。这篇不讲协议怎么接，只讲怎么把价格表读懂、把额度算清、把成本控制住。看完你会知道该去哪几个站内页面核对当时的数字，以及哪些口径差异最容易被忽略。

本文对标的场景是：你手里有好几路调用，想横向比较成本，但每次打开报价页都被单位、档位、额度说明绕晕。下面按「先看什么、再算什么、最后怎么关进笼子」的顺序走一遍，每一步都给出可以马上做的动作。具体金额一律不写，动手前去站内对应页面拉一份当时的表。

先分清：价格表上到底在卖什么单位

读报价页的第一件事不是看数字，而是看单位。同一个模型，输入和输出的单价往往不同，缓存命中的部分又是另一个价。你只记一个数，月底对账一定对不上。最稳的做法是给每个模型建三行记录：常规输入、常规输出、缓存命中，后面所有估算都基于这三行展开。

输入 token

你发过去的内容，包括系统提示词、历史对话、检索回来的资料，全部计入

输出 token

模型生成的内容；有的平台把推理思考过程也算在这里，有的单独列

缓存命中 token

前缀重复被复用的部分，单价通常低于常规输入，但要看平台是否支持

非文本计量

图片按张、音频按秒或按字符，这类别和文本 token 混在同一张表里比

为什么要单独记缓存命中？因为长系统提示词、固定知识库这类场景，命中的比例可能很高，混着算会高估成本。反过来，如果你的请求每次内容都不一样，命中率接近零，就不用为这一行纠结。判断标准很简单：把最近一周的请求抽样，看前缀重复的比例，低于某个你自己定的阈值就别费劲优化了。

• 把每个在用的模型列成一张表，字段包括模型名、接入渠道、计费单位、是否有缓存价
• 标出哪些平台把推理过程计入输出、哪些单列，这决定同一句话的费用差
• 非文本接口单独建表，不要塞进文本可比表里
• 每张表头部写清「数据以站内页面为准，核对时间自己填」

读一张价格表的顺序：先看单位，再看档位

单位看错是低级错误，但发生频率极高。有的页面写每百万 token，有的写每千 token，差三个数量级，直接把估算放大或缩小一千倍。养成习惯：拉到报价页先找单位说明那一行，找不到就在页面里搜「token」这个词，看清楚它前面挂的是什么量词。

档位这块值得多说一句。很多平台按上下文长度分档，短请求便宜、长请求贵。如果你的业务里有少量超长请求，用平均长度去估会严重偏低。做法是把请求按长度分桶，比如短、中、长三桶，分别乘对应档位的单价，加起来才是接近真实的月度估算。

1. 确认单位在报价页找到量词，明确是每千还是每百万 token，记在表格最上面
2. 确认档位看是否按上下文长度或批处理方式分档，把你业务的实际分布代进去
3. 确认渠道确认你走的是官方直连还是聚合中转，两条路径的价格表要分开看
4. 确认时效在表格里写下核对时间，报价变动后旧表作废，去站内价格页重新拉

额度、免费额度和价格是三件不同的事

额度用完不会自动停，这是最容易被忽略的一条。多数平台的免费额度到期或用完后，请求并不会被拒绝，而是转为按量计费继续跑。如果你没设提醒，等发现时已经产生了一笔没预算的账单。所以拿到额度先做两件事：记下有效期，设一个用量提醒阈值。

订阅制套餐也是同理。它给的额度是按折算价算的，不是无限量；超额后要么限速，要么另走按量计费。判断划不划算，不能只看标称单价，要把额度折算口径和超额的计费方式一起看。如果你每月用量波动很大，固定订阅反而可能不划算。

• 免费额度：记有效期、并发上限、是否自动转按量
• 订阅额度：问清折算比例与超额处理方式
• 按量计费：确认是否有最低消费或结算周期
• 余额预警：设一个低于你心理线的提醒阈值，别等欠费短信

什么情况下不用管这么细？如果团队调用量很小，一个月账单在你自己定的「不值得管」阈值以下，那就人工抽查即可，别为了省一点接入一整套监控。管成本的投入本身也是成本，这条在所有优化里都成立。关于各家当前的额度口径，可以直接到站内对应页面核对当时的说明。

两个最容易被忽略的省钱口径：缓存与批量

缓存命中的逻辑是：请求前缀重复时，平台复用之前的计算结果，这部分按更低的价计。适合的场景很明确——固定的长系统提示词、反复使用的知识库片段、多轮对话里不变的开头部分。如果你的请求前缀每次都不同，这条基本用不上，不用花时间折腾。

批量接口是另一条路。非实时任务走批量通道通常有折扣，代价是延迟从秒级拉长到小时级。它适合离线打标、批量摘要、历史数据清洗这类场景；对交互式应用、需要立刻返回结果的接口，基本不适用。判断标准是：这个任务能不能等，等一小时会不会影响业务。

换模型之后账怎么对：口径变了，数量级也可能变

换模型的坑在于：单价便宜不代表总成本低。有的模型输出话多、爱补充，单价看着低，但同样一条业务请求消耗的输出 token 明显更多，算总账反而更贵。所以换模型前后，要分别记录同一条业务请求的输入输出 token 数，而不是拿旧账单直接乘新单价。

1. 固定样本挑几条有代表性的业务请求作为对照样本，覆盖短、中、长三种长度
2. 换前记录记录每条样本在新旧模型下的输入输出 token 数，别只记总费用
3. 换后复测切换后用同样样本跑一遍，对比 token 消耗和输出长度差异
4. 算总账把 token 数乘以站内价格页当时的单价，得到可比的总成本再判断

复测频率建议按周做一次抽样，不用全量。抽样的意义是发现趋势：输出变长、重试变多、上下文失控，这三类问题都会先在抽样里冒头。站内通常有成本核算类工具，把 token 数填进去就能得到基于当时单价的估算，省得自己算错单位。

把成本关进笼子：几个能落地的工程动作

前面讲的是「看懂」，这一节讲「管住」。最有效的动作往往不是换更便宜的模型，而是给每个业务线设独立的 key 和预算上限。一个实验脚本忘了关，跑一晚上就可能把整月额度烧掉；独立 key 能把损失限制在一条线上，不影响其他业务。

• 按业务线拆分 key，各自设预算上限和告警阈值
• 记录每次请求的输入输出 token 数与耗时，保留一段时间便于复盘
• 对长对话做裁剪或摘要，控制上下文长度，这是最直接的一招
• 对失败重试设次数上限，重试是隐性成本大户
• 定期清理不再调用的旧 key，避免遗忘的脚本在跑

如果团队调用量很小，上面这套监控的搭建成本可能超过你能省下的钱，那就先只做一条：记录关键业务的 token 消耗。等账单规模上来了再逐步加。判断标准是，维护这套东西的人力时间乘以你的时薪，是否明显低于预期能省下的金额。

数字会变，去哪核对当时的报价

价格是动态的，本文刻意不写任何具体数字，就是因为写死的数一定过期。动手前，先去站内官方 API 价格页拉一份当时的表，再把你在用的模型逐个对上去；如果你走的是中转或聚合平台，报价要到站内目录页另看一份，两条渠道的价格表不能混着比。

对账时把报价页和用量页放在一起看：报价页告诉你标价，用量页告诉你实际摊到每百万 token 的支出。两者差在哪，通常能从缓存命中比例、失败重试、输出长度这三个方向找到答案。想横向比各家的可信度和价格变动趋势，站内的价格追踪和排名页面可以直接对照。

价格表是给你做判断用的，不是给你背的；记住口径，数字每次现查。