Amazon Bedrock 大模型选型实战：用 MMLU 与 Prompt 评测挑出最适合业务的那一个（TaoToken 统一 Key 接入）

1. 为什么模型选型不能只看榜单：从一次真实翻车说起

Amazon Bedrock 上能调的大模型越来越多，DeepSeek-R1、Amazon Nova Pro、Llama 3.3 70B Instruct 这些名字摆在一起，光看官方参数表根本分不出谁更适合你的业务。我见过太多团队直接拿公开榜单第一名去上线，结果在自己的客服问答场景里答非所问，最后返工重来。问题不在于榜单造假，而在于 MMLU 这类基准测的是通用学科知识，而你的业务 Prompt 里塞满了行业黑话、内部缩写、特定输出格式要求，这两件事根本不是一回事。

所以这篇要解决的核心问题是：在 Amazon Bedrock 上，怎么用 MMLU 基准加业务 Prompt 双轨评测，把选型从"拍脑袋"变成"有数据支撑的决策"。适合谁看？正在做 Bedrock 多模型对比的 AI 开发者、需要给业务方一份选型报告的架构师、以及想搭一套可复用评测流水线的工程同学。读完之后你能拿到三样东西：一套可复制的评测脚本骨架、一张评分表模板、一份 config.toml 配置示例，并且整个评测流程可以通过 TaoToken 统一 Key 接入，不用为每个模型单独维护一套鉴权逻辑。

我试过把评测脚本和业务代码混在一起写，后来发现模型一换、Key 一改，整个脚本就得重写。踩过的坑告诉我，评测这件事必须和接入层解耦，否则每次选型都是一次重构。下面按"先搭接入层、再跑双轨评测、最后出决策清单"的顺序展开。

2. TaoToken 前置：统一 Key 与 API 通道怎么准备

2.1 为什么评测流程需要统一接入层

做多模型评测最烦的不是写评测逻辑，而是每个模型厂商的鉴权方式、请求格式、返回结构都不一样。Bedrock 原生走的是 AWS SigV4 签名，你得配 access key、secret key、region，还要处理 boto3 的 client 初始化。如果评测里还要横向对比其他通道的模型，鉴权代码会迅速膨胀成一座屎山。

TaoToken 在这里的角色是一个统一的 Key 和 API 通道：你用一套 Key、一套 OpenAI 兼容的请求格式，就能把评测请求打到不同模型上。这样评测脚本里只关心"发什么 Prompt、收什么答案、怎么打分"，鉴权细节全部收敛到配置层。官网入口在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ，API 基址是 https://taotoken.net/api ，注意 API 地址不带 UTM 参数，配置时别画蛇添足。

2.2 拿到 Key 并确认可用模型

登录后进入控制台，在 API Keys 页面创建一个新 Key。建议按用途命名，比如bedrock-eval-2025，方便后面排查是哪个评测任务在消耗额度。创建完成后立刻复制保存，页面刷新后就看不到完整 Key 了。

接着去模型对话页面确认你要评测的模型是否在可用列表里。这一步很关键，因为 Bedrock 上不同 region 开放的模型不一样，有些模型需要单独申请权限。在模型对话里手动发一条测试消息，确认通道通畅，再进入脚本批量评测阶段。

如果你后续要做长期的编码类评测或者 Agent 任务评测，可以关注 Coding Plan 页面，它更适合高频、长周期的评测场景，按量计费的方式比单次调用更划算。

2.3 环境变量与依赖安装

评测脚本建议用 Python，依赖装这几个就够：

pip install openai pandas python-dotenv tabulate

然后在项目根目录建一个.env文件，把 Key 和基址写进去：

TAOTOKEN_API_KEY=sk-你的实际key TAOTOKEN_BASE_URL=https://taotoken.net/api

注意.env一定要加进.gitignore，我见过有人把 Key 提交到公开仓库，第二天额度就被刷光了。环境变量方式比硬编码在脚本里安全得多，也方便在 CI 里注入。

3. 可复制配置：config.toml 与评测脚本骨架

3.1 config.toml 配置示例

把评测参数全部外置到配置文件，是让评测可复现的关键。下面这份config.toml覆盖了模型列表、采样参数、数据集路径和评分阈值：

[api] base_url = "https://taotoken.net/api" api_key_env = "TAOTOKEN_API_KEY" timeout = 120 max_retries = 3 [[models]] name = "nova-pro" model_id = "amazon.nova-pro-v1:0" temperature = 0.1 max_tokens = 2048 [[models]] name = "deepseek-r1" model_id = "deepseek.r1-v1:0" temperature = 0.1 max_tokens = 4096 [[models]] name = "llama3-3-70b" model_id = "meta.llama3-3-70b-instruct-v1:0" temperature = 0.1 max_tokens = 2048 [evaluation] mmlu_dataset = "data/mmlu_sample.jsonl" business_prompt_file = "data/business_prompts.jsonl" output_dir = "results" sample_size = 20 pass_threshold = 0.75

这里有个细节：temperature统一设成 0.1，是为了让评测结果尽量可复现。如果你要测模型的创造性，可以单独开一组高 temperature 的对照实验，但选型主评测必须压低随机性，否则同一份数据跑两次结果对不上，没法做决策。

3.2 评测脚本骨架

脚本分成三块：加载配置、调用模型、打分汇总。核心调用逻辑用 OpenAI 兼容客户端，指向 TaoToken 的基址：

import os import json import time import tomllib import pandas as pd from openai import OpenAI from dotenv import load_dotenv load_dotenv() def load_config(path="config.toml"): with open(path, "rb") as f: return tomllib.load(f) def build_client(cfg): return OpenAI( api_key=os.environ[cfg["api"]["api_key_env"]], base_url=cfg["api"]["base_url"], timeout=cfg["api"]["timeout"], max_retries=cfg["api"]["max_retries"], ) def ask_model(client, model_cfg, prompt, system="直接返回答案，不要解释。"): resp = client.chat.completions.create( model=model_cfg["model_id"], messages=[ {"role": "system", "content": system}, {"role": "user", "content": prompt}, ], temperature=model_cfg["temperature"], max_tokens=model_cfg["max_tokens"], ) return resp.choices[0].message.content.strip() def run_mmlu(client, cfg, model_cfg): rows = [] with open(cfg["evaluation"]["mmlu_dataset"], encoding="utf-8") as f: samples = [json.loads(line) for line in f][: cfg["evaluation"]["sample_size"]] for item in samples: start = time.time() answer = ask_model(client, model_cfg, item["prompt"]) latency = time.time() - start rows.append({ "model": model_cfg["name"], "category": item.get("category", "unknown"), "pred": answer[:1].upper(), "ref": item["referenceResponse"], "correct": answer[:1].upper() == item["referenceResponse"], "latency_s": round(latency, 2), }) return rows def main(): cfg = load_config() client = build_client(cfg) all_rows = [] for model_cfg in cfg["models"]: print(f"评测模型: {model_cfg['name']}") all_rows.extend(run_mmlu(client, cfg, model_cfg)) df = pd.DataFrame(all_rows) os.makedirs(cfg["evaluation"]["output_dir"], exist_ok=True) df.to_csv(f"{cfg['evaluation']['output_dir']}/mmlu_result.csv", index=False) summary = df.groupby("model").agg( accuracy=("correct", "mean"), avg_latency=("latency_s", "mean"), ).reset_index() print(summary.to_string(index=False)) if __name__ == "__main__": main()

这段脚本的骨架价值在于：模型列表、采样参数、数据集路径全部来自config.toml，换模型只改配置不改代码。ask_model里把 system prompt 固定成"直接返回答案"，是因为 MMLU 是选择题，模型如果输出一堆解释，答案提取会变得很麻烦。

3.3 业务 Prompt 评测集怎么组织

MMLU 测的是通用知识，业务 Prompt 测的是"这个模型能不能干我的活"。业务评测集建议用 JSONL 格式，每行一条：

{"id": "biz-001", "prompt": "把下面这段用户投诉归类到：物流/质量/售后/其他。投诉内容：收到货发现包装破损，里面零件掉了。", "expected": "质量", "weight": 1.0} {"id": "biz-002", "prompt": "从这段合同文本里抽取甲方名称和签约日期，输出 JSON。文本：甲方为杭州某某科技有限公司，签约日期2025年3月12日。", "expected": "{\"party\":\"杭州某某科技有限公司\",\"date\":\"2025-03-12\"}", "weight": 1.5}

weight字段用来给不同业务场景加权，比如合同抽取比投诉分类更关键，权重就调高。最终业务得分是加权准确率，而不是简单平均。

4. 验证请求：跑通一次完整评测并看结果

4.1 先做单条冒烟测试

正式批量跑之前，先手动发一条请求确认通道通畅。用 curl 最快：

curl https://taotoken.net/api/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "amazon.nova-pro-v1:0", "messages": [{"role": "user", "content": "Which is bigger, 8.15 or 8.2?"}], "temperature": 0.1 }'

返回里能看到choices[0].message.content，说明 Key 和基址都对。如果返回 401，检查 Key 是否复制完整；返回 404，检查模型 ID 拼写。

4.2 批量运行与结果解读

冒烟通过后执行python eval.py，脚本会依次跑完配置里的三个模型。跑完后results/mmlu_result.csv里是逐条明细，终端打印的是汇总表。一份典型的汇总结果长这样：

这张表就是选型决策的核心依据。注意看两个准确率的差异：DeepSeek-R1 在业务 Prompt 上反超 Nova Pro，说明它在中文理解和复杂指令跟随上有优势；而 Llama 3.3 70B 虽然 MMLU 落后，但延迟只有 0.98 秒，适合对响应速度敏感的场景。

注意：单次评测结果有随机性，尤其是延迟指标波动较大。建议同一配置跑 3 次取平均，再下结论。

4.3 评分表模板

把上面的数据整理成给业务方看的评分表，建议加一列"业务权重"，让决策逻辑透明：

权重怎么定取决于业务。客服场景延迟权重要拉高，合同审阅场景准确率权重要拉高。这张表的价值不是给出唯一答案，而是让"为什么选它"变得可解释。

5. 本篇常见错排查

5.1 模型 ID 写错导致 404

Bedrock 的模型 ID 有严格格式，比如amazon.nova-pro-v1:0里的冒号和版本号不能省。如果你在配置里写成nova-pro这种简称，请求会直接 404。排查方法：去模型对话页面看实际调用时用的完整 ID，复制过来。

5.2 答案提取失败导致准确率虚低

MMLU 是四选一，模型如果输出"答案是 B，因为……"，你用answer[:1]提取会拿到"答"字，准确率直接归零。解决办法是在 system prompt 里强制"只返回选项字母"，或者在提取时用正则匹配[ABCD]。我建议两者都做，双保险。

5.3 并发过高触发限流

批量评测时如果开多线程并发，很容易撞上速率限制，返回 429。稳妥做法是串行跑，或者在脚本里加time.sleep(1)控制节奏。评测不是生产服务，慢一点没关系，结果准确更重要。如果确实要并发，把max_retries设成 3 以上，让客户端自动退避重试。

5.4 数据集格式不匹配

MMLU 原始数据集字段名是question、choices、answer，而 Bedrock Evaluations 用的格式是prompt、referenceResponse、category。如果你直接拿原始数据喂脚本，会报 KeyError。转换脚本很简单：

import json def convert(raw_path, out_path): with open(raw_path, encoding="utf-8") as f, open(out_path, "w", encoding="utf-8") as out: for line in f: item = json.loads(line) choices = "\n".join(f"{chr(65+i)}. {c}" for i, c in enumerate(item["choices"])) out.write(json.dumps({ "prompt": f"{item['question']}\n{choices}", "referenceResponse": chr(65 + item["answer"]), "category": item.get("subject", "unknown"), }, ensure_ascii=False) + "\n") convert("raw_mmlu.jsonl", "data/mmlu_sample.jsonl")

5.5 延迟数据被首次请求污染

第一次请求某个模型时，客户端要建连接、做握手，延迟会明显偏高。如果你把第一次的数据也算进平均，结果会失真。解决办法是在正式计时前先发一条预热请求，丢弃结果，再开始正式评测。

6. 选型决策清单与下一步动作

跑完双轨评测后，按这份清单逐项确认，就能输出一份可落地的选型结论：

第一，确认业务场景的核心指标。是准确率优先，还是延迟优先，还是成本优先？把权重写进评分表，别口头说"都要好"。

第二，确认模型在业务 Prompt 上的表现是否稳定。同一批 Prompt 跑三次，看准确率波动是否超过 5 个百分点。波动大的模型，上线后容易出意外。

第三，确认接入层是否统一。如果评测用一套 Key、上线又换一套，中间会埋坑。建议评测和上线共用同一套 TaoToken 通道，减少环境差异。

第四，确认降级方案。主选模型如果某天限流或涨价，备选模型能不能顶上？在配置里保留至少两个模型，用config.toml的模型列表管理。

具体动作上，你可以现在就去 API Keys 页面创建一个专用评测 Key，把本文的config.toml和脚本骨架复制到本地，换成你自己的业务 Prompt，跑一轮完整评测。跑完之后，把评分表发给业务方，用数据说话，比争论"哪个模型更聪明"高效得多。如果评测过程中遇到接入问题，接入文档里有完整的参数说明和错误码对照，对着排查基本能解决。