1. 多模型评测的真实痛点为什么你的对比脚本总在换 Key 时崩掉做 LLM 模型性能分析这件事最容易被低估的不是评测指标设计而是接入层。你想对比 Qwen、Yi、ChatGLM、InternLM 在 C-Eval、GSM8K、HumanEval 上的表现理想状态是写一套脚本跑完所有模型输出一张延迟、吞吐、质量的对照表。但现实往往是每个模型一个 API 地址、一套鉴权方式、一种返回结构脚本里塞满了 if-else 分支改一个模型就要动一次代码。我见过太多团队在这一步卡住。评测任务本身MMLU、C-Eval、GSM8K、MATH、HumanEval/MBPP、BBH、CMMLU定义得很清楚但真正跑起来时光是维护多套 Key 和 Endpoint 就耗掉大半精力。更麻烦的是当你把同一道 GSM8K 数学题发给不同模型返回的 JSON 字段名都不一样——有的用choices[0].message.content有的用output.text解析逻辑越写越乱最后评测结果的可比性反而下降了。所以这篇要解决的核心问题是用一套统一的 Key 和 API 通道把多模型对比评测的接入成本压到最低。你只需要维护一个 Base URL、一个 API Key通过切换model参数就能在同一个脚本里跑遍所有目标模型。这样延迟对比、吞吐测试、输出质量评估才有一致的基础。适合谁看正在做模型选型的技术负责人、需要定期跑 benchmark 的算法工程师、想给自己项目挑一个性价比模型的独立开发者。你不需要很深的 ML 背景只要能写 Python 请求、会看 JSON 就行。下面我会先讲清楚统一接入的前置准备然后给出一份可以直接复制的多模型评测脚本配置接着验证请求是否跑通再列出几个我实际踩过的报错最后说明怎么把这套流程固化下来长期用。2. TaoToken 统一 Key 前置准备一个通道打通多模型评测接入在动手写评测脚本之前先把接入层的事情理清楚。TaoToken 在这里扮演的角色是统一 API 通道它对外暴露一个兼容 OpenAI 格式的接口你用一个 Key 就能调用多个模型。对于模型性能分析场景来说这意味着你的评测脚本只需要面向一种请求格式编程模型差异被收敛到model字段里。先明确几个关键地址后面配置会反复用到用途地址官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Base URLhttps://taotoken.net/api模型对话验证用https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentCoding Plan长期评测/Agenthttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注意 API Base URL 是https://taotoken.net/api不带任何查询参数。很多人在配置时习惯性把官网地址粘进去结果请求 404这是第一个坑。拿到 Key 的流程不复杂进控制台在 API Keys 页面创建一个新 Key复制出来存到环境变量里。不要硬编码在脚本里评测脚本经常要分享给同事或提交到仓库Key 泄露是高频事故。推荐做法export TAOTOKEN_API_KEYsk-你的key然后在 Python 里用os.environ.get(TAOTOKEN_API_KEY)读取。这样脚本本身可以随便传Key 留在本地环境。关于模型 ID 的获取最直接的方式是打开模型对话页面看模型列表里每个模型的标识符。不同模型的 ID 命名规则可能不一样比如有的是qwen-72b有的是yi-34b-chat具体以文档和控制台展示为准。评测脚本里我会用一个MODELS列表来管理方便增删。还有一个容易被忽略的点评测场景对超时和重试的要求比日常对话高。GSM8K 这种需要分步推理的任务单次响应可能十几秒甚至更久。所以脚本里要设置合理的timeout并且对失败请求做重试否则一个超时就会让整轮评测数据缺失。我一般设timeout60重试 2 次。前置准备做到这里就够了一个 Key、一个 Base URL、一份模型 ID 列表、环境变量存 Key。接下来进入脚本配置环节。3. 可复制的多模型评测脚本配置延迟、吞吐、质量三件套这一节是核心直接给可运行的配置和代码。评测脚本要同时采集三类指标延迟单次请求耗时、吞吐单位时间完成的请求数或 token 数、输出质量用规则或参考答案打分。为了让对比公平所有模型走同一套请求逻辑只换model字段。先看配置文件。我用一个 JSON 来管理评测参数这样改模型、改题目、改并发数都不用动代码{ base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, models: [ qwen-72b, yi-34b-chat, chatglm2-6b, internlm-20b ], tasks: [ { name: gsm8k_sample, prompt: 小明有 15 个苹果给了小红 3 个又买了 8 个现在有多少个请分步解答。, expected: 20 }, { name: humaneval_sample, prompt: 写一个 Python 函数输入列表返回其中所有偶数的平方和。, expected: def } ], timeout: 60, max_retries: 2, concurrency: 4 }注意base_url写的是https://taotoken.net/api不带 UTM 参数。api_key_env指向环境变量名脚本运行时读取。models列表里的 ID 请以你控制台实际展示为准这里只是示例。接下来是评测主脚本。它做四件事并发发请求、记录延迟、统计吞吐、对输出做简单质量判定。import os import json import time import asyncio import aiohttp CONFIG_PATH eval_config.json def load_config(): with open(CONFIG_PATH, r, encodingutf-8) as f: return json.load(f) async def call_model(session, cfg, model, task): url f{cfg[base_url]}/v1/chat/completions headers { Authorization: fBearer {os.environ[cfg[api_key_env]]}, Content-Type: application/json } payload { model: model, messages: [{role: user, content: task[prompt]}], temperature: 0 } start time.perf_counter() for attempt in range(cfg[max_retries] 1): try: async with session.post( url, headersheaders, jsonpayload, timeoutaiohttp.ClientTimeout(totalcfg[timeout]) ) as resp: data await resp.json() latency time.perf_counter() - start content data[choices][0][message][content] return { model: model, task: task[name], latency: round(latency, 3), content: content, ok: True } except Exception as e: if attempt cfg[max_retries]: return { model: model, task: task[name], latency: None, content: str(e), ok: False } await asyncio.sleep(1) async def run_eval(): cfg load_config() sem asyncio.Semaphore(cfg[concurrency]) results [] async def worker(model, task): async with sem: async with aiohttp.ClientSession() as session: r await call_model(session, cfg, model, task) results.append(r) start time.perf_counter() jobs [worker(m, t) for m in cfg[models] for t in cfg[tasks]] await asyncio.gather(*jobs) total_time time.perf_counter() - start ok_count sum(1 for r in results if r[ok]) throughput ok_count / total_time if total_time 0 else 0 print(f总请求: {len(results)}, 成功: {ok_count}, 耗时: {total_time:.2f}s, 吞吐: {throughput:.2f} req/s) for r in sorted(results, keylambda x: (x[model], x[task])): print(f{r[model]:20s} {r[task]:18s} latency{r[latency]} ok{r[ok]}) with open(eval_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: asyncio.run(run_eval())这段脚本的关键设计点temperature0保证输出可复现评测场景不需要随机性Semaphore控制并发避免把通道打满导致延迟数据失真延迟用perf_counter从发请求前开始计时包含网络往返失败请求记录错误信息而不是直接丢弃方便排查。质量判定这里只做了最简单的占位expected字段实际评测时你可以扩展成GSM8K 用答案数字匹配HumanEval 用代码执行测试用例C-Eval 用选项比对。核心是所有模型用同一套判定逻辑这样横向对比才有意义。跑完会生成eval_results.json里面每个模型每个任务的延迟和输出都在。你可以用 pandas 读进来做透视表按模型算平均延迟、按任务算成功率。这套配置的好处是加一个新模型只需要在models列表里加一行不用改任何请求代码。4. 验证请求与成功结果从单次调用到批量评测跑通配置写好后别急着跑全量评测。先用最小成本验证通道是否通否则批量跑起来全是 401 或超时浪费时间。第一步用 curl 做单次连通性测试curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: qwen-72b, messages: [{role: user, content: 11等于几只回答数字。}], temperature: 0 }如果返回的 JSON 里有choices[0].message.content且内容是2说明 Key、Base URL、模型 ID 三者都对。这一步能排掉大部分配置错误。第二步跑一个单模型的单任务确认脚本逻辑没问题python -c import asyncio, json from eval_script import load_config, call_model import aiohttp async def test(): cfg load_config() cfg[models] [qwen-72b] cfg[tasks] cfg[tasks][:1] async with aiohttp.ClientSession() as s: r await call_model(s, cfg, qwen-72b, cfg[tasks][0]) print(json.dumps(r, ensure_asciiFalse, indent2)) asyncio.run(test()) 预期输出类似{ model: qwen-72b, task: gsm8k_sample, latency: 3.421, content: 小明原来有15个苹果给小红3个后剩12个又买8个12820所以现在有20个。, ok: true }看到ok: true且content是合理回答说明整条链路通了。注意latency是 3.4 秒左右这是单次请求的端到端延迟包含网络和模型推理时间。第三步跑全量评测。把models和tasks恢复成完整列表执行主脚本python eval_script.py成功输出示例总请求: 8, 成功: 8, 耗时: 12.35s, 吞吐: 0.65 req/s chatglm2-6b gsm8k_sample latency2.103 okTrue chatglm2-6b humaneval_sample latency2.887 okTrue internlm-20b gsm8k_sample latency3.552 okTrue internlm-20b humaneval_sample latency4.021 okTrue qwen-72b gsm8k_sample latency3.421 okTrue qwen-72b humaneval_sample latency5.118 okTrue yi-34b-chat gsm8k_sample latency3.876 okTrue yi-34b-chat humaneval_sample latency4.663 okTrue从这组数据能直接读出几个结论ChatGLM2-6B 延迟最低参数量小Qwen-72B 在代码任务上延迟最高但输出质量通常更好Yi-34B 居中。吞吐 0.65 req/s 是在并发 4 的情况下测得的你可以调整concurrency观察吞吐变化——但要注意并发太高时延迟会上升这是排队效应评测时要固定并发数才能公平对比。eval_results.json里存了每个模型的完整输出你可以人工抽查几个确认质量判定逻辑是否合理。比如 GSM8K 的答案是否真的包含20HumanEval 的输出是否真的定义了函数。这一步是自动化评测的必要补充因为规则判定总有边界情况。到这里一套可复现的多模型评测流程就跑通了。接下来处理几个实际会遇到的报错。5. 常见报错排查401、local proxy failed、reading choices、OAuth评测脚本跑不通时报错信息往往指向接入层而不是模型本身。下面这几个是我实际遇到过的按出现频率排序。401 Unauthorized。最常见的原因是 Key 没读到或格式不对。检查两点环境变量是否真的导出成功echo $TAOTOKEN_API_KEY看有没有值以及请求头里是不是Bearer加空格再加 Key。很多人复制 Key 时带了换行符导致鉴权失败。另外确认 Key 没有过期或被删除去 API Keys 页面核对一下。local proxy failed / connection refused。这个报错通常和本地网络环境有关。如果你本机设置了系统级代理aiohttp 默认会读取环境变量里的HTTP_PROXY导致请求被转发到不可用的地址。解决办法是在脚本里显式禁用代理async with aiohttp.ClientSession(trust_envFalse) as session: ...trust_envFalse让 aiohttp 忽略环境变量里的代理设置直连 API 地址。这个坑在 CI 环境里尤其常见因为 CI 机器经常预置了代理变量。reading choices / KeyError: choices。这个报错说明返回的 JSON 结构和你预期的不一样。可能原因请求根本没成功返回的是错误对象比如{error: {...}}但你的代码直接去取choices了。修复方式是先判断响应状态码和结构data await resp.json() if choices not in data: return {ok: False, content: json.dumps(data, ensure_asciiFalse)} content data[choices][0][message][content]这样即使出错也能看到原始返回而不是一个模糊的 KeyError。另一个可能是模型 ID 写错了通道返回了模型不存在的提示。OAuth / authentication failed。如果你用的是某些 CLI 工具比如 Claude Code 或 Codex 类工具接入可能会遇到 OAuth 相关的报错。这类工具通常需要配置三件套Base URL、API Key、Model ID。以 Claude Code 为例配置文件里要写清楚{ base_url: https://taotoken.net/api, api_key: sk-你的key, model: claude-3-5-sonnet }三个字段缺一不可Base URL 不带 UTMModel ID 以文档为准。如果只填了 Key 没填 Base URL工具会去连默认地址自然失败。Codex 的auth.json同理需要把base_url指向https://taotoken.net/api。超时 / timeout。评测长推理任务时默认超时可能不够。把timeout调到 60 秒以上并且确认max_retries至少为 1。如果重试后仍然超时可能是并发太高导致排队降低concurrency再试。排查顺序建议先用 curl 验证单次请求再用单模型单任务验证脚本最后跑全量。这样能把问题定位到具体环节而不是在批量失败里猜。6. 把评测流程固化下来从一次性脚本到长期基准跑通一次评测不难难的是让它可重复、可对比、可积累。模型在更新你的评测集也应该跟着演进。这里说几个把流程固化下来的实用做法。第一评测集版本化。把eval_config.json里的tasks单独抽成一个文件比如benchmark_v1.json每次评测记录用的是哪个版本。这样当模型分数变化时你能区分是模型真的变好了还是题目换了。GSM8K、HumanEval 这类标准集可以直接用官方数据自建集则要标注来源和预期答案。第二结果落库而不是只存 JSON。单次评测的 JSON 适合排查但长期对比需要结构化存储。最简单的做法是用 SQLite每次评测插入一行(model, task, latency, ok, timestamp)然后用 SQL 做趋势查询。比如Qwen-72B 在过去一个月的 GSM8K 平均延迟变化这种问题用表格回答比翻 JSON 快得多。第三固定评测环境。延迟数据对网络环境极其敏感同一模型在不同时间、不同机器上跑出来的数字可能差一倍。所以对比时要么在同一台机器上连续跑完所有模型要么记录环境信息地区、并发数、时间段作为参考。吞吐数据同理并发数不同没有可比性。第四质量判定要能扩展。前面脚本里的expected字段只是占位。实际做 C-Eval 时你需要解析模型输出的选项字母做 HumanEval 时需要把生成的代码跑一遍测试用例。建议把判定逻辑写成独立函数按任务类型分发def judge(task_name, content, expected): if task_name.startswith(gsm8k): return expected in content if task_name.startswith(humaneval): return expected in content return None这样加新任务类型时只改判定函数不动主流程。第五长期跑用 Coding Plan。如果你需要定期比如每周跑一轮完整评测或者把评测接入 CI可以考虑用 Coding Plan 来管理长期调用额度。它的定位就是面向持续编码和 Agent 场景的比单次按量更适合这种周期性任务。地址在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后说一个实际经验评测脚本的价值不在于跑出多漂亮的数字而在于当你要换模型时能快速拿到可信的对比数据。我试过在项目中期临时换模型因为之前有这套流程半天就完成了新模型的延迟和质量评估而不是靠感觉拍板。把接入层统一到一套 Key 和 Base URL 上是让这件事变简单的关键一步。如果你还没开始建议先从两个模型、两个任务跑起把链路走通再逐步扩展评测集。跑通之后你会发现多模型对比真正花时间的不是写脚本而是设计合理的评测任务和判定标准——那才是模型性能分析的核心。