Claude 企业采购对比：新加坡与马来西亚的 Bedrock、直购与经销商容量

选哪条路，取决于三件事落在谁头上：合同跟谁签、推理数据留在谁的边界里、容量按用量买还是按承诺买。Anthropic 直购、AWS Bedrock、Claude Platform on AWS 和经销商预购容量这几种走法，公开能核对到型号、区域、端点前缀与基础费率这一层；发票主体、付款账期、支持责任和退出条件要到询价阶段逐家拿书面答复。

四条采购路径分别是谁在卖、谁在开票？

先确定合同相对方，再谈模型和价格。同一套 Claude，可能由 Anthropic 直接卖给你，可能由 AWS 卖给你，也可能由一家经销主体卖给你；发票开给谁、出故障时第一通电话打给谁，都跟着这个主体走。

先分清三个角色：模型方、云平台、经销方

模型方、云平台、经销方是三个不同的售卖主体。Anthropic 直购是直接向模型方拿服务和账单；Amazon Bedrock 由 AWS 运营托管，用量并入 AWS 服务账单，可按标签与成本分摊类别归集到团队或项目；Claude Platform on AWS 由 Anthropic 处理请求，但走现有 AWS 账号、IAM 治理与 AWS Marketplace 计量；经销商路径由经销主体与你签约，发票与付款条件看它拿出来的合同。

经销方这一层容易被看成转手买卖，其实它承担的是供应合约。经销主体先从上游取得供应与容量，再以自己的合同向你提供服务。发票开立方、一级支持责任方，还有退出条款的谈判对手，都会落在同一个主体身上。这就是经销商路径和云平台路径最实质的差别。

角色和账单落点对齐之后，价格之外的比较项才排得上队。下表把几种走法的运营方、账单落点和计价单位放进同一行，方便你拿去和各家报价对照。

同一句「我们在用 Claude」，在运维、财务和法务眼里是三份不同的清单。运维关心端点和凭据怎么管，财务关心发票开给谁、用哪种币别，法务关心数据经过哪些实体。有些团队就卡在这一步，因为想让同一个人把三份都签掉；先定下谁签哪一份，比先比价格有用。

Claude Platform on AWS 和 Bedrock 各服务一种优先顺序

Claude Platform on AWS 出现之后，Bedrock 并没有被取代，两条路服务的是不同的优先顺序。把治理、安全与成本控管放在首位的团队继续用 Bedrock，Claude 可以放进 IAM 权限、CloudTrail 审计与既有数据边界里，多模型策略的调用规范也统一。需要第一时间拿到 Anthropic 原生新功能的团队，才会去评估 Platform on AWS。

具体一点：一个团队已经跑了一年 Bedrock，IAM 角色、VPC 配置和 CloudWatch 日志都在位。如果只是为了新版模型早几周可用，整套搬迁的代价通常高于它换来的时间。真正值得动的情况，是某条只在原生平台上线、而产品又必须用的能力卡住了节奏。

两条路并行也不少见，代价落在财务这一侧。

同一批 Claude 用量会分散到两种账单机制上，团队、项目和环境的归集方式要提前对好，否则季度结算时要人工拆一次。

Claude 型号在各渠道和地区现在能买到哪些？

这个问题要落到型号加区域这一格。按国家或按「亚太」概括会漏掉关键条件：旧版 ARN 表与当前 Messages API 是两套清单，采购前得按你实际调用的那一套去查。

下面的前缀表只适用于旧版 ARN-versioned Bedrock integration。Opus 4.6、Sonnet 4.6、Sonnet 4.5 默认使用带 global. 前缀的全球端点，把前缀换成 us.、eu.、jp.、apac，就变成限定地理区域路由的区域端点。区域端点的定价比全球端点高出 10%，反映的是专用区域容量的基础设施成本。

这张表不能直接代表当前 Messages API 的新型号清单。

旧版 ARN 表中，同一个模型在不同区域栏里可能是「是」也可能是「否」

在这份旧版 Bedrock 表里，Sonnet 4.6 的 global、us、eu、jp 四栏都是「是」，apac 一栏是「否」；Sonnet 4.5 情况相同。所以「亚太能不能用」这种问法得不到可执行的答案，得落到具体型号的具体区域栏。

「是」只说明能不能调用，不说明额度够不够。

区域端点贵出的那部分买的是区域内的专用容量，跟每分钟能发多少请求是两回事，后一项要到配额页面另看。

当前 Messages API 的 Bedrock 文件是另一套表。较新的 Claude Fable 5.1、Fable 5、Opus 5.5、Opus 5、Sonnet 5、Opus 4.8 与 Opus 4.7 等型号，按 US、EU、JP、AU 等 geography profile 另行核对，不能沿用旧表的 apac 栏。当前端点还把 structured outputs 列为不支持功能。

要用结构化输出或新型号，先按现行端点的 model ID、profile 与功能清单重做一次验证。

AWS 的官方支持模型与区域文档，是核对某型号在某区域是否可用的第一手入口。

模型与区域可用性会调整，这一步要在递交采购申请之前重做一次。拼推理配置 ID 的规则是基础模型 ID 加前缀，例如 us.anthropic.claude-sonnet-4-5-20250929-v1:0，也可以用完整的推理配置 ARN。部分较新的模型不接受基础模型 ID 走按需吞吐的调用方式，会直接返回 HTTP 400，提示改用推理配置。如果你正在把示例代码从直购改到 Bedrock，这种报错往往出现在第一次联调。

型号的生命周期日期由运营平台各自设定，可能与 Claude API 的时程不一致，两条渠道的清单要分别核对，尤其在下单前刚好跨过一次模型更新的时候。

还有两层限制跟区域无关。部分型号提供 1M token 的上下文窗口，其余型号是 200k；Bedrock 同时把请求负载限制在 20 MB，传大文件或批量图片时可能先撞到这一层，还没到 token 上限就被拒绝。

Vertex AI 上的 Claude 要按 Google 的文档另查

Vertex AI 上的 Claude 通过 partner models 文档说明接入方式，区域和模型版本以 Google 官方文档与定价页当日内容为准。AWS 的端点前缀结论套不到 Vertex AI 上，两个云平台的区域行为各自独立。如果你同时用 AWS 和 GCP，两边的区域条件要各查一遍，别互相套用。

按 token 计费和预购容量，买的是两件不同的事

按 token 计费买的是实际用量，单价随模型与端点变化；预购容量买的是吞吐的可预测性，谈的时候要给出承诺量、容量单位与合约期。两者不能按单价换算，一边是可变量，一边是承诺。

先把比较的基准统一

Anthropic 官方定价页按模型列出输入与输出的 token 单价，这是直购和云平台比价时的计价基准。跨区域端点附加费、批处理与缓存折扣不在这个基准里，要单独加回或扣除。

比价前先固定三件事：

• 模型
• 端点类型：全球端点还是区域端点
• 用量结构：输入与输出的比例

其中任何一项换掉，两份报价就不再可比，后面算出来的折扣幅度也没有意义。

有效成本不只基础单价

基础单价只是起点。

有效成本还要叠加区域端点附加费、批处理折扣、缓存、预购容量、企业折扣和集成运营的人力。这些项随模型、区域、用量与合同条件变化，报价单上要能看见，否则很容易出现两份报价看起来差很远、实际账单却差不多的情况。反过来也有：便宜的那一栏，可能因为你用不上批处理而变贵。

能不能吃到批处理折扣，往往比单价差更能决定月度成本。如果你的负载里有三成可以等一天出结果，那部分就该单独算一行；全是实时交互的话，这一项直接归零，谈判时也就没有用这项换让步的空间。

云平台的配额是另一层上限

现行 Messages API 端点（bedrock-mantle）按模型分别限制 input TPM 与 output TPM 两项，不设 RPM 配额，限流只看这两项 token 配额；它与旧版 bedrock-runtime 端点的配额互相独立。bedrock-mantle 的配额在 Service Quotas 里能看到，但提升申请目前不经 Service Quotas 控制台处理，要通过 AWS Support 的 limit increase 表单提交。AWS 与 Anthropic 的现行 Messages API 文件没有给出固定的一到三个工作日审查承诺。

提交表单时选 Amazon Bedrock，并写明端点 bedrock-mantle、区域、模型、配额名称（input TPM 或 output TPM）和目标值，是否批准取决于现有用量。当前文件列出的默认值是每分钟 200 万 input TPM，并可申请到 500 万 input TPM 与 50 万 output TPM，且不需要额外的 Anthropic 核准。支持超长上下文的版本配额更紧，同样一份文档量放到 1M 上下文版本上，可用的每分钟额度会明显更低。

这是云侧的额度，跟经销商的预购容量不是同一个数字，也不能互相换算。

做容量规划时把它单独列一行；高峰期按哪个上限限流、超了会返回什么，写进需求说明里比事后排查省事。

要谈承诺量，先准备三个数字：峰值 token 速率、峰值能持续多久、可接受的平均利用率。承诺量按容量单位计价，跟按月账单不是同一行，用一个月的用量反推该签多少，通常签出来不是过大就是不够。对方一般还要先看历史用量曲线，把过去几个月的峰值与波动按同一套算法给出，谈判会直接进入条件层面。

账单落在谁那里，决定了付款和折扣怎么谈

账单落在谁那里，你就跟谁签约、把钱付给谁、折扣也跟谁谈。直购的账单来自 Anthropic，以美元按信用卡或发票结算；Bedrock 的用量并入 AWS 账单，可以按标签和成本分摊类别归集到团队或项目；Claude Platform on AWS 经 AWS Marketplace 计量；经销商路径看经销主体的合同条款。

折扣的谈判对象也跟着账单走：AWS 侧的优惠挂在 AWS 的合约体系里，直购的优惠挂在与 Anthropic 的合约里，两者通常不能互相引用或转移。如果你听到「云平台的折扣更好」这类说法，要追问是哪一层的折扣，以及你的用量够不够得上那一层的门槛。

折扣能不能叠加也是常见分歧点。多个优惠同时生效时按哪一项计算、有没有互斥关系，都要在报价单上写明，写清了才谈得上核对。

基础费率对齐，差别在有效成本

按需 token 的基础费率两边基本对齐。Sonnet 5 的输入每百万 token 2 美元、输出每百万 token 10 美元，这是 Anthropic 定价页的现行标准价。Sonnet 5 发布时标注为 8 月 31 日前的推广价，现已确定成为标准价，原定 9 月 1 日调到每百万 token 输入 3 美元、输出 15 美元的计划不会执行。折扣、端点与账单条件仍按采购当天的报价核对。既然单价不是唯一分水岭，注意力该放到区域端点、折扣可用性和集成运营上。

计价币种和账单落点是两件事

页面价格以美元显示，不做本地币种换算，也不自行加入汇率或地方税务计算。

拿本地货币数字直接比价，比出来的差异大多来自汇率算法，之后再去核对各条路径反而更绕。询价前先到 MixRoute 当前的储值级距与付款说明核对购买条件；模型按需费率仍要回到对应供应商当日 API pricing 页，再用同一套算法去比各条路径。

MixRoute 的一般 API 呼叫按供应商官方定价计费、0% 平台加价；Smart Routing 也全面免费，不收路由服务费，只需支付实际选用模型的用量费用。这条路径的成本，主要看承诺量、折扣与退出条件怎么谈。

付款方式上，银行电汇、发票与弹性账期是企业采购里常见的谈法。付款条件谈得越早，财务流程越好排。等到合同定稿才问账期，就要重走一遍审批。

发票主体与税务处理页面上看不到，要按所在地与方案跟销售确认，页面不会写成支持某个市场的在地发票、税务文件或币种。把它放进同一份询价清单里，比签约后再补条款省事。

数据留在谁的边界里

推理由谁处理，数据边界就落在哪里。Bedrock 由 AWS 运营推理，数据在 AWS 边界内处理，权限、审计与加密沿用 AWS 原生体系；Claude Platform on AWS 用 AWS 账号做身份与治理，但底层请求由 Anthropic 运维处理，数据会进入 Anthropic 的环境；直连同样由 Anthropic 处理。

如果你的监管要求、客户合同或内部政策要求推理数据留在单一处理器边界内，这一条就是选型的分界线，权重高过单价和功能上线速度。

把合规要求写成合同里的条款

平台页面上的描述替代不了合同条款，跨境与行业要求要落在数据处理条款里。银行、保险和医疗类客户在供应商评估里会问数据经过哪些实体、在哪一层被记录、留存多久，这时候能拿出来的应该是合同里写明的条款。

问的时候把「在新加坡有节点」这种回答往下追一层：

• 请求由哪个实体处理
• 落在哪一层的存储
• 保留多久
• 谁能调取

这几句能答到条款级别，合规评审才走得下去。

记录能力也是这一环的一部分。Bedrock 提供调用记录服务，可以记录与用量相关的提示与完成内容；接入文档建议至少以 30 天滚动方式保留活动记录，用来了解用量、调查潜在的滥用情形。记录能留下什么、留多久，直接决定审计时你手上有什么证据，所以这一项要和留存条款一起问。

场景上更容易判断：如果审计部门已经要求所有生产数据不出某个云边界，那么把 Claude 请求路由到由模型方运维的环境，就需要额外的审批和记录；如果内部政策只要求可审计、可追溯，四条路径都能谈，差别落在谁提供日志和留存期限上。

新加坡和马来西亚企业最容易漏掉的确认点

能核对的是型号、区域、端点前缀和基础费率。付款方式与账期、发票与税务主体、支持责任与响应标准、数据处理条款、折扣能不能叠加、承诺量的退出与调整方式，这些在页面上都看不到，要在询价阶段一次拿到书面答复。

这些问题适合一次交给对方

问的时候带上三个数字：峰值 token 速率、目标区域，以及能接受的切换或停服窗口。对方的答复会随这三个数字变化，笼统地问多少钱，只能拿回一页标价。

支持责任这一栏值得单独追一句：账单落在哪家，一级故障响应通常也在那家；路径里一旦出现经销方，谁接第一通电话、多久给答复，要写明是经销方还是上游。故障当天的排查顺序，就取决于这句话有没有写进合同。

清单一次交出去，也便于判断谁真的能在你所在的市场履约。把四条采购路径的确认清单交给销售逐项答复，比在几个渠道之间来回转述同一组问题快得多。

用量稳定之后，容量路径怎么谈

只有当团队能给出稳定峰值和持续时间时，预购容量才值得谈。用量还在爬坡、或者月度波动超过一倍的项目，先用按需计费把曲线摸清楚更划算。等峰值稳定两三个月再谈承诺量，议价位置也更从容。

签字之前要谈定的五件事

这几件事按顺序谈：

• 可用型号范围
• 容量单位
• 承诺周期
• 未用满的处理方式
• 中途能不能调整

承诺量写进合同之后，调整空间通常比价格更难谈。

所以这一条要放在签字之前问清楚。合同期越长，中途的调整机制越要写明白。签下去之后，账单上会多出一行按承诺计的容量费用，跟按量计费的用量分开。财务要能分别归集这两行，才判断得出容量买得值不值；两行混在一起，利用率就没法算，下一次续约也没有依据。

MixRoute 的高速率专属额度是一条并行的采购方式

MixRoute 以预购 provisioned throughput 的形式提供高速率专属额度，跟按 token 计费并行，买的是容量的可预测性。它属于企业版套餐的权益，定价页写明每月消费满 20,000 美元或单次充值满 30,000 美元就有使用资格；可用型号、容量单位与合约期，按实际用量与销售确认。公开的容量数字只覆盖两款图像模型，不要把它推到 Claude 或 GPT 的 TPM 上。要看这条路径的条件，可以到高速率专属额度的开放条件说明。

FAQ

我们公司在新加坡或马来西亚，现在能从 Bedrock 上用 Claude 吗？

要看具体型号和区域，「新加坡能不能用」这样概括得不到可执行的答案。旧版 ARN 表里，Sonnet 4.6 和 Sonnet 4.5 的 apac 一栏是「否」，Opus 4.6 五栏都开，Haiku 4.5 的 jp 和 apac 都是「否」。当前 Messages API 另有一套型号清单，按 US、EU、JP、AU 等 geography profile 核对，不能沿用旧表的 apac 栏。

Anthropic 直购和 Bedrock 上的 Claude，单价一样吗？

按需 token 的基础费率两边基本对齐，真正拉开差距的是有效成本。区域端点要在全球端点基础上多加 10%，批处理和缓存折扣另算，AWS 侧的优惠通常也不能跟 Anthropic 的合约互相引用或转移。Sonnet 5 输入每百万 token 2 美元、输出每百万 token 10 美元，是 Anthropic 官方定价页现行的标准价，折扣与端点另算。自己算月账单时，把输入输出比例、端点类型和能不能走批处理一起放进去，比单看单价准得多。

Claude Platform on AWS 是不是就等于 Bedrock？

不是。Bedrock 的控制面由 AWS 提供，Claude 被放进 AWS 原生的治理与多模型框架，推理也在 AWS 边界内完成。Platform on AWS 走 Anthropic 原生的平台控制面，用 AWS 账号做身份验证、经 AWS Marketplace 计费，底层请求由 Anthropic 运维处理。两者是互补的两条路。判断的关键在你更看重治理一致性，还是原生功能的更新节奏；把这个问题带回内部，让安全团队和产品团队各说一句，答案就清楚了。

我们已经有 AWS 账号，是不是直接选 Bedrock 就行？

要看两件事：推理数据要不要留在 AWS 边界内，以及预算和成本分摊怎么归集。安全团队本来就按 IAM 和 CloudTrail 审计，Bedrock 接起来摩擦最小；产品侧要追 Anthropic 原生新功能的上线节奏，就得另外评估 Platform on AWS。还有一种情况值得回头算：现有账号里的预算、标签和成本分摊已经成型，接第二个模型来源时要不要拆账，取决于财务需不需要按团队分开看。

预购容量适合什么样的团队？

适合已经能给出稳定峰值和持续时间的团队，还在验证用量的项目先不急着签。判断标准其实很朴素：过去三个月里有几个月真正贴着上限跑，峰值持续多久。如果高峰只出现在促销或季度结算那几天，先申请配额提升、或者把能等的任务放进批处理，通常比签承诺量更灵活。另外，签了之后账单上会同时出现按量与按承诺两行，财务要能分开归集，利用率才算得出来。

发票和付款方式怎么确定？

页面上能看到的是计价币种和账单落在哪一层，其余条件要看合同相对方怎么答复。页面价格以美元显示，不做本地币种换算，也不自行加入汇率或地方税务计算；银行电汇、发票与弹性账期是企业采购里常见的谈法。发票主体与税务处理按所在地与方案谈，适合和付款方式、账期一起放进同一份清单，比签约后再补条款省事。

Bedrock 的配额不够用怎么办？

bedrock-mantle 的配额在 Service Quotas 里能看到，但提升申请要通过 AWS Support 的 limit increase 表单提交，选 Amazon Bedrock，并写明端点 bedrock-mantle、区域、模型、配额名称和目标值；现行 Messages API 文件没有给出固定的一到三个工作日审查承诺，别把它当成保证。当前文件列出的默认值是每分钟 200 万 input TPM，并可申请到 500 万 input TPM 与 50 万 output TPM，且不需要额外的 Anthropic 核准。长文档任务要留意一点：同一模型的标准版和 1M 上下文版可能是两组不同的配额，数字要分开核对。

中国大陆的团队可以直接走这些路径吗？

没有看到中国大陆可用的依据，也不能从新加坡或马来西亚的区域供应推断过去。已确认的区域栏位覆盖 global、us、eu、jp、apac 这些前缀，Vertex AI 那边另行公布区域，两者都不构成对大陆可用性的说明。有跨境部署需求时，把主体注册地、数据处理条款和付款路径放在一起问，比单问能不能用更有用。