Skip to main content
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。