AWS区域定价没有统一倍率：同一区域模型价差可达1.6倍

你一直用来估算云成本的"区域倍率"，可能根本不存在

如果你曾估算过法兰克福或东京部署一个模型的成本，大概率和我一样：取 us-east-1 的价格，乘一个区域系数，结束。几乎所有我见过的云成本模型，都把区域当作基础费率的乘数。

但有人做了一件更扎实的事：逐一读取 Amazon Bedrock 全部 1,586 个按需、区域内的 token 计费项，并与各自的 us-east-1 价格做对比。结果是——其中 1,424 个具有可比性，覆盖 32 个区域，共产生 123 个不同的倍率。

如果区域真的是一个倍率，那最多只该有 32 个。多出来的 91 个，说明"区域倍率"这个心智模型本身出了问题。

Amazon Bedrock 是 AWS 提供的全托管生成式 AI 服务，开发者可通过统一 API 调用 Anthropic Claude、Meta Llama、Mistral、Amazon Nova 等多家厂商的基础模型。其定价采用按需 token 计费：输入 token 与输出 token 分别计价，且不同模型单价差异可达数百倍。所谓"区域内"（in-region）部署，指推理请求完全在用户指定区域的数据中心内完成；与之相对的是"跨区域推理"（cross-region inference），即请求可能被路由到其他区域处理，两者使用独立的价目表。文中反复出现的 1,586 个"计费项"，即指每个模型、每个方向（输入/输出）、每个区域组合下的一条独立价格记录。理解这一颗粒度是理解全文结论的前提：倍率之所以如此之多，正是因为计费项本身就被拆得如此之细。

倍率分布：三分之一完全同价，最高冲上 1.7

先看整体分布：

• 30.3% 的计费项与 us-east-1 完全相同
• 第一四分位数（Q1）：×1.000
• 中位数：×1.183
• 第三四分位数（Q3）：×1.200
• 最低：×0.964
• 最高：×1.700

接近三分之一的计费项，在海外区域的价格和弗吉尼亚一模一样。区间顶部是圣保罗，Mistral 7B 的输出价格从 $0.20 涨到 $0.34。

有意思的是，有四个计费项在 us-east-1 之外更便宜——us-west-2 中两个 Nova Sonic 模型的输入和输出，倍率分别为 ×0.967 和 ×0.964。幅度很小，但足以说明：这个"上浮"连 1.0 的地板都不存在。

四分位数是描述一组数值分布位置的统计量。将全部倍率从小到大排列后：Q1（第一四分位数）表示有 25% 的倍率低于该值，Q3 表示有 75% 的倍率低于该值，中位数则是 50% 分位点。这里 Q1 = 1.000、中位数 = 1.183、Q3 = 1.200 的含义是：至少四分之一的计费项与 us-east-1 完全同价，一半的计费项涨幅不超过 18.3%，四分之三的涨幅不超过 20%。但最高值 ×1.700 说明分布存在明显的长尾。用中位数做预算，等于假设你的用量恰好落在分布的中间——而实际账单是各计费项的加权和，尾部的高倍率项一旦用量大，就会主导总成本。

伦敦：一个区域，25 个不同倍率

伦敦是最能说明问题的案例。以下是 eu-west-2 输入价格相对弗吉尼亚同款模型的倍率：

倍率	模型	价格变化
×1.000	Kimi K3	$3.300 → $3.300
×1.000	Grok 4.7	$2.200 → $2.200
×1.300	Llama 3 8B	$0.300 → $0.390
×1.333	Mistral 7B	$0.150 → $0.200
×1.412	Nova Pro	$0.800 → $1.130
×1.500	Gemma 3 4B	$0.040 → $0.060
×1.533	Qwen3 32B	$0.150 → $0.230
×1.550	Devstral	$0.400 → $0.620
×1.600	Ministral 3B 3.0	$0.100 → $0.160

这只是伦敦 47 个可比输入计费项中的 9 个；如果算上输入和输出两个方向，它共有 94 个计费项和 25 个不同倍率。

两个模型与弗吉尼亚同价，其余大多贵出五成。"伦敦贵 55%"这句话在同一张表里同时为真又为假，你拿到哪个答案，取决于你恰好选了哪个模型。

放到全部 32 个区域看，只有 9 个区域收取单一一致的倍率——而这 9 个里有 7 个每个仅有 4 个计费项，那是一个样本，不是一项政策。真正有覆盖度的只有两个：us-east-2（129 个计费项，全部 ×1.000）和 me-central-1（13 个计费项，全部 ×1.000）。

换句话说：32 个区域中有 23 个，对不同模型给出了不同的相对弗吉尼亚定价。

Azure 的对照：第一根轴不是区域

Azure 是很有用的对照，因为它的组织方式与 AWS 完全不同。

一个 Global Standard 部署只有一个价格。不是每个区域一个价格，而是就一个价格，适用于 Azure 列出的所有区域。要把同一个模型固定到某个区域或数据区，才需要额外付费：

• 区域部署：中位数 ×1.100，区间 1.100–1.320，10 个不同倍率
• 数据区部署：中位数 ×1.100，区间 1.100–1.200，6 个不同倍率

所以在 Azure 上，问题是"我是否把它固定到某个地理范围"，答案通常是统一上浮 10%。而在 AWS 上，问题是"哪个模型，在哪个区域"，有 123 个答案。

Azure 也并非完全统一——21 个具有区域定价的模型中，有 18 个在不同区域间会变化。但在相近数量的计费项下，10 个不同倍率对 AWS 的 123 个，是种类上的差异，而非程度上的差异。

Azure 的部署类型是理解其与 AWS 差异的关键。Global Standard 是默认部署方式，模型权重托管在微软全球基础设施上，请求可能由任意区域处理，因此只有一个统一价格，区域选择不影响账单。区域部署（Regional）将模型固定到某一具体区域，数据不出境，需额外付费。数据区部署（Data Zone）介于两者之间，模型固定在某地理范围（如欧洲或美国）内，付费幅度低于区域部署。Azure 的定价逻辑因此是"先选部署类型，再看区域"，而 AWS Bedrock 的区域内定价则没有这层部署类型维度（standard、Batch、Flex、Priority 是另一套正交的服务层级）。两者的成本轴顺序不同，直接套用同一套区域倍率模型会失效。

实际该怎么做

不要用参考价估算区域价格。 这是最实际的结论，也是整篇文章要说的核心。没有任何一个系数能对超过一小部分模型目录成立。请直接读取你实际调用的模型、在你实际调用的区域中的那个数字。

检查你最常用的两个模型，而不是平均值。 中位数 ×1.183 对预算几乎没用：你的账单是你实际命中的那些计费项的加权和，而那些计费项的范围是 ×0.964 到 ×1.700。

在 Azure 上，先给部署类型定价。 如果你用的是 Global Standard，区域对你来说根本不是成本轴，区域间迁移对账单毫无影响。在为一个 sprint 投入精力之前，值得先搞清楚这一点。

测量方法与第一次踩过的坑

数据范围限定为 Bedrock 按需 standard 层级、仅 区域内 部署。Batch、Flex 和 Priority 是独立的表，跨区域推理也是。

这个排除项就是全部方法论，之所以强调，是因为第一次时忽略了它。不锁定部署类型就做分组，会得出一个漂亮的大标题——"Nova 2.0 Lite 在某些区域贵 6.16 倍"——实际上是拿一个区域的 Flex 对比另一个区域的 Priority。没有捏造任何数据，行都是真实的，只是回答了一个没人问过的问题。一张包含四个层级的价目表，只要你放任它，就会塞给你一个戏剧性的数字。

只有当一个模型和方向在两个区域同时存在时，才计入一个计费项，因此某区域缺失的模型贡献为零，而非无限比值。价格一律读取供应商公布的表格，绝不从参考数字推导——这正是本文主张你也不该做的事。

数据截止 2026-10-11。逐区域表格（含区域切换器和页面上的口径说明）见 aichangewatch.com/aws/pricing。

云成本建模的一个常见假设被这次全量核对推翻：区域不是乘数，模型才是变量。对任何需要跨区域做预算决策的团队来说，把"区域倍率"从估算公式里删掉，换成对具体计费项的核对，是更靠谱的第一步。

AWS Bedrock 的服务层级是容易混淆之处：Standard 为默认的按需推理；Batch 面向大批量异步任务，价格通常更低；Flex 和 Priority 分别对应可容忍更长延迟和需要更高优先级的两类请求，价格也各不相同。这四个层级各自维护独立的价目表，同一模型在不同层级下的单价可能相差数倍。因此，将不同层级的计费项混入同一组倍率计算，会人为放大或缩小区域间差异，产生看似惊人但无实际意义的数字。本文强调"锁定部署类型"，正是为了确保每一对比较都发生在同类服务之间，使倍率真正反映区域差异而非层级差异。