AI模型多少钱？采购与开发者必看的价格构成与价位区间

很多人第一次做模型预算，是拿着一句「大概多少钱」去问供应商，回来发现报价单上的数字根本对不上自己的用法。问题不在于贵不贵，而在于你没先拆开价格构成：输入、输出、缓存、多模态、工具调用、并发与限流，每一项都单独计价。这篇把成本拆成可对照的几块，给出价位分档的判断依据和一套从需求到预算的走法，具体数字到站内对应页面核对当时的行情。

很多人第一次做模型预算，是拿着一句「大概多少钱」去问供应商，回来发现报价单上的数字根本对不上自己的用法。问题不在于贵不贵，而在于你没先拆开价格构成：输入、输出、缓存、多模态、工具调用、并发与限流，每一项都单独计价，把它们揉成一个单价去砍价，基本谈不明白。

这篇不讲玄学，只做两件事：把成本拆成可对照的几块，再给一套从需求到预算的走法。凡是涉及具体数字的部分，一律到站内价目与追踪页面核对当时的行情，因为各家调价频率不低，写死在文章里的数字第二天就可能过期。

一份模型报价单，钱到底分成哪几块

先建立一个习惯：任何报价先别看总价，先看它由几个价目拼成。多数供应商的价目结构是「基础调用 + 附加能力 + 用量条件」三层，基础调用里最常见的拆分就是输入与输出分开计价，且输出通常更贵。

• 输入与输出分开计价是常态，别拿一个笼统单价去乘总字数；
• 缓存写、缓存读、批量、离线任务往往是独立价目，重复性高的场景先看这一项；
• 多模态输入按自己的单位算，不按文本 token 折算；
• 工具调用、联网、重排、向量化这些外挂环节多数单独收费，容易在预算里漏掉；
• 把上面这些项列成一张表，让供应商逐项填，比问「你们多少钱」有效得多。

按 token、按次、按字符、按分钟：计价单位先对齐再谈贵贱

单位不同的两家人，直接比单价是没有意义的。按 token 计价的适合长文本、长输出；按次计价的适合请求短、频次固定的场景。你要做的是把自家任务量换算成同一个口径，再回头看谁便宜。

按 token

按实际送进和生成的量算，适合输入输出量波动大的任务。

按次

每个请求一口价，适合请求短、调用次数可预测的任务。

按字符

多见于翻译、转录类接口，和 token 口径不能直接换算。

按分钟

语音、实时对话类常见，按连接时长计价。

按结果量

检索、重排、向量化常见，按条数或向量维度计价。

判断口径的实操方法：写下你的任务一个月跑多少次、每次平均输入多少、输出多少、重试比例多少，再把这份用量分别套进不同单位的报价里。哪一步换算不过来，说明这家不适合你的任务形态，而不是它贵。

• 先写下月调用次数、平均输入量、平均输出量三组数；
• 算一个重试系数，把失败请求也计入；
• 按同一份用量分别向两三家询价，要求对方按你的口径报总价；
• 对不上的地方逐项追问，别接受一个模糊的总数；
• 拿到报价后到站内价目页核对当时的单价区间，确认没有被多加环节。

价位区间怎么分档：从轻量档到旗舰档的判断依据

不写具体数字，只讲分档依据。判断一个任务该用哪一档，看的不是任务听起来高不高级，而是「做错了要不要紧」和「重试一次贵不贵」。

一个常见误区是「全站统一用一个模型」。更省钱的做法是分层：容错高的任务走轻量档，容错低的走中高档，再给关键链路单独配一个兜底模型。具体每一档的单价区间，去站内价目与追踪页面看当时的数字，别用印象里的旧价做决策。

• 把任务按容错高低分成三组：随便错、错了能发现、错了会出事；
• 轻量档承接第一组，中档承接第二组，旗舰档只留给第三组；
• 给关键链路配一个兜底模型，主模型异常时自动切换；
• 每季度复查一次分层，用量结构变了档位也该跟着变。

单价之外，真正把账单撑起来的几处

预算超支很少是因为单价贵，多半是因为这几处没算进去。它们不体现在首页单价上，但会实打实出现在月结账单里。

• 重试与失败请求照样计费，不稳定模型的真实成本远高于标价；
• 上下文越长，单次成本涨得越快，长对话与长文档要先做裁剪或摘要；
• 并发上不去意味着你要么排队、要么买更贵的档位换吞吐；
• 对账差距大多出在缓存命中率、分组倍率和阶梯折扣上，别只看首页单价；
• 日志、存储、向量库这些周边服务也可能产生费用，容易在预算外。

1. 拉一份真实账单拿最近一个月的实际用量和账单，按模型、按接口拆分，找出金额最高的前三项。
2. 对照价目逐项核对把账单里的每一项对应到站内价目页的价目项，确认没有未知收费。
3. 找出隐性项检查重试次数、平均上下文长度、缓存命中率三个指标，看哪一项在拖成本。
4. 定优化动作针对命中率低的做缓存，针对上下文长的做裁剪，针对重试高的换档位或加兜底。

从需求到预算：一张可落地的估算顺序表

下面这套顺序适用于自研团队和采购方，核心思路是「用账单反推模型，而不是用模型猜账单」。每一步都留下书面记录，方便后面复盘。

1. 定任务清单把要做的事拆成几类，每类标出容错高低和大概调用频次，形成一张任务表。
2. 定模型档位按容错高低把任务映射到轻量 / 中档 / 旗舰，别一刀切用一个模型。
3. 折算用量按调用次数、平均输入输出长度、重试比例算出月度量，写清每个假设。
4. 留冗余预算按估算上浮一档，同时配上用量上限与告警，防止单点跑飞。
5. 小规模实测拿真实任务跑一轮，把实测账单和估算对比，修正假设再放大。

第三到第五步是最容易敷衍的地方。用量折算里如果没写清假设，估算出来的数字对采购没有说服力；实测阶段如果拿的是玩具数据，得出的结论也不能代表生产环境。建议把每一步的输入和输出都存档，后面调价或换模型时直接复用。

拿到一份报价，怎么判断它合不合理

拿到报价别急着砍价，先做一次口径审查。很多报价看起来便宜，是因为它没覆盖你的任务形态，或者把附加项藏在了别处。

什么情况下不适用这套方法：如果对方给的是打包年费或席位制，单价对比法就失效，得换成总成本口径，把年费、席位、超额、运维一起算。具体单价区间到站内价目库核对当时的数字，别只信报价单。

• 先要分项价目表，不接受只给一个总价；
• 用你的真实用量套一遍，而不是用对方给的样例用量；
• 和站内价目页做一次横向核对；
• 把超额、缓存、工具调用三项单独问清；
• 打包年费的场景改用总成本口径重算一遍。

什么时候不该只看价格

价格是采购的一个维度，不是唯一维度。以下几类场景，单看单价会做出错误决策，判断方式是把「省钱」和「省事」分别打分，选总分高的那家。

• 数据敏感场景，便宜的公共接口可能根本不能用，先过合规再谈钱；
• 稳定性差导致的返工成本，往往比单价的差距更大；
• 需要长期维护的项目，接口变更、限流调整、停服风险都是成本的一部分；
• 对时延有硬要求的场景，排队等待的时间成本要算进去；
• 已经深度集成的技术栈，换供应商的迁移成本也要计入总账。

单价最低不等于账最省，把返工、迁移、合规和排队时间一起算进去，才是真实成本。