云厂商转售模型和自己开账号，价格到底差在哪？

很多公司采购云服务时顺手就在 Azure、Bedrock 上开了模型，觉得反正能用、走同一张云账单省事。但真到对账，会发现同一批调用和官方直连的价格对不上，差额来自计费单位、区域、承诺折扣和结算币种，不是简单的贵一点。这篇不报具体数字，只给一套口径对齐的顺序，让你在下单前知道该翻哪几页、问哪几个问题，把两条路的账算到同一个基准上。

很多公司采购云服务时顺手就在 Azure、Bedrock 上开了模型，觉得反正能用、走同一张云账单省事。但真到对账，会发现同一批调用和官方直连的价格对不上，差额来自计费单位、区域、承诺折扣和结算币种，不是简单的贵一点。

这篇不报具体数字，只给一套口径对齐的顺序，让你在下单前知道该翻哪几页、问哪几个问题，把两条路的账算到同一个基准上。下面按「先对齐单位、再过隐藏成本、再定顺序、最后验证」四步走。

先对齐计费单位，不然比的是两回事

云转售渠道常按自己的计量单位记账，比如调用次数、计算单元、区域单价；官方直连通常按输入输出 token 分开计价。如果直接拿两边的标价对比，很容易得出错误结论，因为一个数字覆盖的范围可能完全不同。

计量单位

转售渠道可能按调用次数或计算单元，直连按 token 数，先确认单位再换算

输入输出拆分

直连一般把输入、输出、缓存读写分开列，转售页面有时合并成一个数字

折扣触发条件

批量、异步、预留容量在两条路上的名字和门槛不一样，别拿一家的折扣价去比另一家的标价

换算时至少要做三件事：确认单位是否一致、确认覆盖范围是否包含缓存和重试、确认折扣是否已生效。这三项任何一项没对齐，后面的比较都没有意义。

具体数字到 /official-api 和 /official-api/providers/azure、/official-api/providers/amazon-bedrock 看当时的计价项，别用记忆里的数字。

隐藏成本逐项过一遍

挂牌价只是起点，真正让月度账单对不上的往往是隐藏成本。下面这张表把常见项目列清楚，采购时逐项确认是否已包含在报价里。

除了表里的四项，还要问清楚：重试请求是否重复计费、缓存命中是否单独定价、失败请求是否收费。这些在两条路上的规则不一样，最容易造成月度差额。

如果公司已经有云合同，先确认模型调用是否被算进承诺消费。很多采购吃亏在这一点：以为走云账单省事，结果年度承诺被模型调用占掉，其他服务反而没额度可用。

采购决策的顺序：先划场景，再选通道

价格差多少不是唯一变量，先按场景划边界，再决定走哪条路。下面这个顺序是从合规到成本逐步收敛的，适合企业采购对照使用。

1. 第一步：划合规边界数据必须留在某个云的内网或合规区时，转售渠道的合规优势可能盖过价差，先满足合规再谈省钱
2. 第二步：看调用阶段调用量小、验证阶段，直连更容易小额试、随时停；转售渠道往往有开通流程和最低承诺，不适合先试水
3. 第三步：算量大稳定后的折扣量大且稳定时，把承诺折扣、预留容量算进去再比，别只比挂牌单价；到 /price-watch 看历史变动节奏
4. 第四步：判断是否混合走核心数据流走合规转售，非敏感批量任务走直连，前提是两边都能出对账用的用量记录

混合走法不适用的情况要说清楚：如果团队没有分账能力，混着走反而对不清账，这时候宁可选一条路走到底，把账做简单。

• 合规优先：数据不能出某个云或区域时，先选能满足这条的通道
• 试水优先：验证阶段选开通简单、能随时停的通道
• 规模优先：量大稳定时再比承诺折扣和预留容量
• 对账优先：两边都要能导出用量明细，否则混合走是给自己找麻烦

下单后怎么验证没被多算

下单不是结束，第一个完整账期就要做验证。方法不复杂：两边都导出用量明细，按同一时间窗、同一模型口径对齐，看差异落在单价还是落在计量单位上。

把重试、失败请求、缓存命中单独列出来。这些在两条路上的计费规则不同，是最容易造成月度差额的地方。比如直连可能不计失败请求，转售渠道按调用次数计就可能重复算。

固定每月对一次账，差异超过阈值就回头查区域、承诺量和封装层，而不是直接怀疑涨价。参考 /usage 和 /monthly-billing-reconcile 的记录方法，把核对做成固定动作。

价格差不是问题，口径没对齐才是问题；对账做在第一个账期，比事后追差额省事得多。