大模型定价，3种计费口径先分清

大模型定价这件事，贵不贵排在第二位，第一位是你拿哪种口径跟哪种口径比。同一家服务商，按 token 报的数、按调用次数报的数、按算力占用报的数，能差出一大截。你拿 A 家的 token 单价去怼 B 家的包月价，得出的结论必然是错的——不是 B 贵，是你把两种尺子摞在一起量了。

大模型定价的三套算法，混着比就没意义

先把三套算法摆出来。一套按用量计费，主流写法是每百万 token 多少钱，输入输出分开算；一套按调用次数，一次请求、一次会话、一次任务各是一口价；还有一套按资源占用，GPU 卡时、实例时长或者预留并发，本质是你租了一段时间的机器，用不用都收钱。这三套东西的计量单位都不一样，一个是流量表，一个是次数表，一个是租金表。

混着比最常见的翻车是这样的：某家 token 单价看着低，但你的场景输出特别长，一出就是一整篇报告，而输出单价通常比输入贵，账单反过来比那家按次收费的还高。另一种是反过来，按次的单价看着漂亮，结果你的请求超时多、重试多，一次变成三次，实际单价立刻翻倍。所以我认为，在比较单价之前，先把自己的用量形状画出来更重要。

按 token 计费：输入和输出是两张价目表

按 token 这套最容易看错的地方，是很多人只记一个数：每百万 token 多少。实际价目表通常是分档的：输入一个价，输出另一个价，输出普遍比输入贵，贵多少各家不一样，以官方价目页为准。上下文长度也可能分档，你塞进去的长文档越长，单价未必还是那一档。有的还做缓存命中折扣，重复的系统提示词、固定的知识库前缀命中缓存后便宜不少，但前提是你要真把提示词结构设计成可缓存的，才吃得到这个折扣。

估自己的用量，有个笨办法够用：中文大致按字数和 token 的换算关系往上浮一点，把系统提示词、历史对话、检索回来的资料全算进输入。多轮对话尤其要注意，每问一句都要把前几轮重新带上，输入是滚雪球，不是线性增长。输出侧看你的回答长度，客服短答和长文生成完全是两种账单。

按次调用：一次到底指什么，得问清楚

按次的合同看着最省心，一口价，好算。问题全在「一次」的定义上。一次 HTTP 请求算一次？一轮完整对话算一次？中间调了两次工具、解析了一个附件，算几次？超时重试算不算第二次？流式输出中途断了重连，账单上记几笔？这些不问清楚，月底对账就有得聊。我见过最离谱的情况是文档里只写「按调用计费」，具体粒度全靠客服口头解释，这种根本没法做预算。

所以签之前或者开通之前，把这几句问出来：计费粒度是什么、重试和失败请求收不收、附件和图片怎么算、有没有最低消费和阶梯折扣。这类问题服务商一般都有文档，以官方页面说明为准，别信转述。

按资源占用：包月健身房的逻辑

第三套是按资源占用，典型是私有化部署或者专属实例，按 GPU 卡时、按实例运行时长、按预留并发收费。这套逻辑跟健身房年卡一模一样：你天天去，单次摊下来便宜得很；办了卡一个月去两回，那就是纯亏。算这套账必须算真实利用率：峰值并发和平均并发差多少、夜间有没有量、能不能弹性缩容。有的方案支持按需启停，用的时候开机、闲的时候释放，这种对波动大的业务友好很多。

选哪套，看业务形状不看单价

低频少量的场景，比如内部工具、偶尔生成几篇文案，按量最划算，用多少付多少，没有闲置成本。量稳定、QPS 可预测的在线业务，包量或者按次的折扣能压下来。数据敏感、要求不出内网、还要做微调的，基本只能走资源占用那条路，这时候比价意义不大，比的是运维能力和合规。中间还有一种混搭：常规请求走外部 API，峰值和敏感任务走自己的实例，这套组合不少人用。

账面之外，几笔容易漏的成本

光看模型单价会漏东西。检索增强里的向量化要把文档重新算一遍 embedding，那是另一笔；向量库的存储和查询要钱；上下文拉长带来的额外输入要钱；失败重试要钱；前面如果挂了网关或者 CDN，出口流量也在账单里。还有一层是代理和中间平台加的价，有的报价单里看不出来，得问清楚是直连官方还是转售。安全这块也别当零成本：密钥怎么保管、调用外部接口会不会把业务数据带出去，这些是要走评估的。

价格会变，别把单价写死在代码里

大模型行业这一年的价目表调整挺频繁，新版本上来、老版本降价或者下线都是常事，具体调了什么以官方公告为准。做预算的时候留点余量，别拿今天的单价乘十二个月就当年度成本。技术上更实在的一条：把模型调用封一层，计价单位、模型名、超时重试策略都放进配置，换供应商时改配置不改业务代码，这比省下来的那点单价差价值钱得多。

真要动手算，顺序大概是这样：先统计自己流量的输入输出比例和平均上下文长度，再把「一次」的定义逐条问清，然后按三种口径分别算一遍月账单，最后挑那个和你业务形状最贴的。三份数字摆在一张纸上，谁贵谁便宜一目了然，比在群里问「哪家便宜」靠谱多了。