AISBench 与推理服务评测：依赖、思考预算和结果可比性

整理日期：2026-09-16。依据北京时间 2026-09-15 的可见提问摘录及本次核查的一手资料补写；未取得完整原始回答，非逐字转录。命令为操作示例，本次未在用户服务器执行。

从“只是调用 API，为什么需要 torch”开始

你问 AISBench 的依赖为何包含 torch、它与其他工具如何选择，以及 GLM-5.3-Flash 的 reasoning_effort=max 是否需要改代码。

需要区分评测端安装依赖与模型实际运行位置。API 模式可以把模型执行交给远端；评测框架仍可能因共享组件、数据处理或本地模型支持依赖 PyTorch。安装 torch 不证明评测端在加载完整模型，也不意味着必须在评测机安装 CUDA。具体依赖原因要沿当前安装版本的 import 路径确认。

项目定位与传参

AISBench 官方项目说明其基于 OpenCompass，并扩展服务化模型评测。公开仓库由 AISBench 组织维护；不能仅凭组织名推断所有维护者雇主。当前 README 的 VLLMCustomAPIChat 示例通过 generation_kwargs 附加生成参数。官方仓库

在该类型配置中，可以尝试：

# 配置示意：合并进当前模型配置，保留其他生成参数
models[0]["generation_kwargs"]["reasoning_effort"] = "max"

这是客户端传参方式，不是“服务器一定支持”的证明。模型官方卡片提供 low/high/max 三档，但服务端版本、模板和模型实现都需要接通。GLM 官方模型卡

三层验证，避免参数静默失效

评测配置：确认实际加载的是修改过的配置，且最终请求 JSON 中出现该字段。
API 服务：先单请求测试，检查是否拒绝、忽略或映射该字段，并记录服务端版本。
模型模板：确认该字段如何进入模型提示或预算控制。生成 token 增多只是线索，不能单独证明配置生效。

优先检查请求和模板；不要一开始就改评测框架源码。

如何选择工具

以当前目标选择，而非寻找一个绝对“更好”的工具：现有 AISBench 配置适合就沿用；比较其他工具时核对目标数据集、Chat API 参数透传、答案提取、重试、流式计时和逐题结果导出。只有 HTTP 连通性检查时，一个小请求就够；标准化准确率评测则还涉及题目构造和评分链路。

GLM 精度对照的最小记录

同一次对比应固定模型与权重 revision、量化配置、服务版本、数据集版本及子集、prompt/chat template、reasoning_effort、输出上限、采样参数和答案提取器。

同时记录超时、截断、解析失败和错误响应，避免把客户端失败全部解释为模型能力下降。评测预算改变时，应同时报告分数和生成成本；max 与 low 的得分不能当作相同条件的量化对照。

关联：GLM-5.3-Flash 精度异常复盘：从 GPQA 反馈到分层定位。

2026-09-16 增量：GLM reasoning_effort 是否等于固定 token 预算

今天的问题是 low/high/max 是否分别绑定 16K、64K 等固定预算。核查官方 GLM-5.3-Flash chat_template.jinja：模板将 low/high 保留，其余情况回落到 max，并向 system 内容加入 Reasoning Effort 指令。该模板代码未给出这些档位到固定 token 数的映射。官方模板（2026-09-16）

因此，不能把 high 写成“强制思考 16K”、max 写成“固定 64K”。effort 是模型行为条件；服务端生成上限和上下文容量是另外的约束。API 字段如何映射、是否支持单独 reasoning budget，仍由实际服务版本决定。

实践：同一题、同一模板 revision，分别保存三档的最终请求、模板渲染结果、输出 token、结束原因和任务得分。先检查是否因长度截断，再比较质量。模板对未知值的回落行为也不代表所有 API 都会接受未知值；服务端可能先校验拒绝。此前 AISBench 的 generation_kwargs 示例只解决传参，不能替代这一步验证。