llm 域评测云厂商作为产品出售的托管大模型(Bedrock、DashScope/Qwen、Vertex,
或任意 OpenAI 兼容网关)。与 agent-runtime(评运行时工程)不同,这里被测系统是
模型端点本身。MMLU 是第一个套件。
这不是主观 LLM 判分:我们原样跑公认的 MMLU,报客观选择题准确率(确定性)+
让托管 LLM 成为云产品的服务维度(延迟、token 成本)。
接入抽象
SUT 是一个 OpenAI 兼容端点,从Target 解析:
params.subjects 过滤学科;params.limit 限题数。
对端点调用的重试是可选项,默认关闭:不设 params.retry 时,每题都只尝试一次,
与本功能出现之前完全一致。设置 params.retry.max_attempts(总尝试次数,含首次)
即可开启重试,params.retry.backoff_base_s(默认 0.2)/
params.retry.backoff_max_s(默认 5.0)限定两次尝试之间的指数退避——第 n 次
失败后等待 backoff_base_s × 2ⁿ⁻¹ 秒,以 backoff_max_s 封顶。三者都在数据集
resolve 时校验:max_attempts 小于 1、或退避为负数,都会以一个点名该 key 的
ValueError 让运行失败,而不是被悄悄夹紧。只有 429、5xx、超时或连接错误才会
重试——其他 4xx 是请求自身的问题,重试只会拖延你本该看到的 bug,而不会修好它。
开启 params.retry 会改变本次运行的数据集 digest,并把数据集版本从
cais-mmlu/sample-v1 改标为 cais-mmlu/sample-v1/retry-<max_attempts>,正如
YCSB 的 disruption plan 会改变被测量的东西一样,因此重试过的运行永远不能与干净
运行比较:
params.retry 不是 target.retries。两个块写的是同样的三个 key 名,但
target.retries(其 max_attempts 默认为 3)约束的是控制面——创建运行时、
轮询其状态——从来不会重试被测量的 /chat/completions 调用。指望靠它让 LLM 调用
重试,换来的是没有重试、没有 digest 变化、也没有任何警告:只有 params.retry
能抵达被测量的路径。
测量什么
official-mmlu-evaluator 产出 mmlu.*:
全部
official=True(溯源标志——官方评估器产出,非审计声明)。无用量记录时省略
token/延迟维度。mmlu.avg_latency_ms 无论是否重试都只是成功那次尝试的耗时;开启
params.retry 后还会多出两项——mmlu.retry_count(首次之外的尝试次数)与
mmlu.retry_overhead_ms(失败尝试与退避耗费的时间)——两者都是 official=False
的 environmental,因为它们描述的是这套 harness 对这个端点在这次运行中的表现,
不是基准本身的属性。
本切片刻意边界
- 一小份真实 MMLU 样本(cais/mmlu,MIT)作 fixture,mock/参考路径无需网络;真实路径对配置端点跑这些题。全量(57 学科/~14k 题)拉取为后续增强——当前标为样本,非完整榜单。
- 0-shot;答案字母用词边界解析。
- 云 provision 的模型端点(相对自带)挂同一 seam。
