用业务评测选择 Bedrock 模型

先建立比较方法，再选模型

准备有版本的评测集，包含普通请求、长文档、含糊问题和禁止请求，并定义预期结果与评分规则。候选模型应使用一致的提示词、资料和输出上限；否则“更便宜”可能只是少读了上下文或少生成了答案。

记录精确模型 ID 或推理配置、区域、API 和日期。把允许处理地区、图像输入等硬约束与表达风格等偏好分开；先排除不符合硬约束的模型，再比较质量。

测量完整任务

指标	记录内容	决策用途
质量	正确性、引用支持、合理拒答	任务是否可用
延迟	首 token 和完整回答时间，包含检索	用户能否完成流程
成本	输入、输出、缓存类别及工具和检索费用	每个合格结果的费用
稳定性	限流、超时、未完成响应	容量与回退设计

大模型可能不适合简单任务，小模型也可能增加重试和人工修正。应比较合格结果的总成本，不能只比较 token 单价。

基线稳定后再引入路由

先形成可测量的默认配置。仅将通过评测的任务交给轻量模型，并为明确例外设计升级路径。回退模型必须满足同一数据边界和输出契约；若更换供应商会改变处理地区，就不能在故障时静默切换。

最终输出模型决策记录：样本版本、结果、排除理由、选用配置和变更触发条件。模型、提示词或检索改变后重跑相关样本，并保存可回退配置。

官方资料

• API compatibility
• Model endpoint availability

文档核验日期：2026 年 10 月 17 日。本文为参考指南，本次未执行真实云端 API 调用。