项目 内容
评测模型 Qwen3.6-27B-W8A8、Qwen3.6-27B-BF16、Qwen3.6-35B-A3B
评测数据集 CEval、BoolQ、GSM8K
评测框架 AISBench
推理服务 vLLM OpenAI-Compatible API

摘要

本次工作面向 Qwen3.6 系列大语言模型开展统一精度评测，评测对象包括 Qwen3.6-27B-W8A8 量化模型、Qwen3.6-27B-BF16 全精度模型以及 Qwen3.6-35B-A3B 混合专家模型，评测数据集包括 CEval 金融法律六科、BoolQ 和 GSM8K。

针对大语言模型在 thinking 模式下可能因最大输出长度不足而产生的空预测、推理截断和最终答案缺失问题，本次工作设计了“固定输出预算评测与自适应补跑相结合”的两阶段评测方法。第一阶段统一设置最大生成长度为 2048 tokens，完成全量推理，并通过任务专用严格评分脚本重新计算准确率；第二阶段仅对固定阶段的空预测和未完成预测样本，将最大生成长度提高到 8192 tokens 并重新推理一次，再将补跑结果合并回原始预测文件。

为了保证评测公平性，已经形成合法最终答案但回答错误的样本不进行补跑；8192 补跑后仍未形成合法最终答案的样本直接计错，不再进行第三轮补跑。通过该方法，可以分别评估模型在固定输出预算下的推理效率，以及排除输出截断影响后的最终任务能力。

实验结果表明，在 CEval 自适应评测中，Qwen3.6-27B-BF16 准确率最高，为 90.99%；在 BoolQ 任务中，三个模型结果接近，Qwen3.6-27B-W8A8 和 Qwen3.6-35B-A3B 均达到 91.56%；在 GSM8K 固定 2048 预算下，Qwen3.6-35B-A3B 准确率最高，为 87.49%，但在 8192 补跑后仍有 80 条样本未形成最终答案。两个 27B Dense 模型在增加输出预算后恢复更加充分，最终准确率分别达到 95.91% 和 95.75%。

总体而言，Qwen3.6-27B-W8A8 与 Qwen3.6-27B-BF16 的准确率较为接近，本次实验未观察到 W8A8 量化造成的一致性明显精度下降。

一、项目背景与评测目标

随着大语言模型参数规模和推理能力不断提升，模型评测不应只依赖评测框架自动输出的 accuracy。特别是在 thinking 推理模式下，模型通常会生成较长的内部推理过程。如果最大输出长度设置较小，模型可能在完成推理之前达到 token 上限，从而出现最终答案为空、输出被截断或者只保留中间推理内容等情况。

此外，部分评测框架的默认后处理方法可能从不完整的推理文本中提取数字或选项，并将其作为最终答案。例如，在数学推理过程中，模型可能输出多个中间计算数字。如果模型尚未完成最终推理，但默认后处理从文本末尾或某个位置提取了数字，就可能形成错误评分或高估模型准确率。

本次工作主要比较以下三种模型：

  1. Qwen3.6-27B-W8A8：27B 参数 Dense 量化模型，模型权重和激活均采用 8-bit 表示。
  2. Qwen3.6-27B-BF16：27B 参数 Dense 全精度模型，采用 BF16 数据格式。
  3. Qwen3.6-35B-A3B：总参数规模约 35B、每个 token 激活约 3B 参数的 MoE 模型。

本次评测的主要目标如下：

  1. 建立统一、严格、可追溯的大语言模型评测流程。
  2. 避免 AISBench 默认后处理可能产生的评分偏差。
  3. 对比 W8A8 量化模型与 BF16 模型的精度差异。
  4. 对比 Dense 模型与 MoE 模型在不同任务上的表现。
  5. 分析最大输出长度对模型评测结果的影响。
  6. 区分模型能力不足与输出被截断造成的错误。
  7. 保留完整的配置文件、预测文件、运行日志和补跑记录，支持后续复现与审计。

二、实验环境与评测对象

2.1 实验环境

本次评测在 Linux 服务器环境中进行，模型由 vLLM 推理服务提前部署，并通过 OpenAI-Compatible API 对外提供服务。AISBench 不在评测进程中直接加载模型权重，而是通过 HTTP 请求调用已部署的模型服务。

项目 配置
操作系统 Linux
Python 版本 Python 3.10
Python 环境 Miniforge/Conda 环境 py310
评测框架 AISBench
推理服务 vLLM OpenAI-Compatible API
模型接口 /v1/chat/completions
模型查询接口 /v1/models
服务地址 http://10.70.1.100:8006
推理模式 thinking 模式
固定最大生成长度 2048 tokens
自适应补跑长度 8192 tokens
temperature 0.0
top_k 10
top_p 0.95
repetition_penalty 1.03

固定评测阶段统一设置：

max_tokens = 2048

其中，2048 表示单条请求允许生成的最大 token 数量，并不表示每条样本一定生成 2048 个 token。

自适应补跑阶段统一设置：

max_tokens = 8192

自适应阶段只对固定评测中没有形成合法最终答案的样本重新推理一次。

2.2 模型说明

2.2.1 Qwen3.6-27B-W8A8

Qwen3.6-27B-W8A8 为 27B 参数 Dense 量化模型，采用 W8A8 量化方式：

  • W8 表示模型权重采用 8-bit 表示；
  • A8 表示模型激活值采用 8-bit 表示。

量化的主要目标是降低模型权重存储空间、显存占用和推理计算开销，提高模型部署效率。

2.2.2 Qwen3.6-27B-BF16

Qwen3.6-27B-BF16 与 27B-W8A8 具有相同的 Dense 架构和参数规模，但模型权重采用 BF16 格式。

BF16 具有较大的数值动态范围，通常作为全精度模型或高精度推理基线，用于判断量化模型是否产生明显的精度下降。

2.2.3 Qwen3.6-35B-A3B

Qwen3.6-35B-A3B 采用 MoE 架构：

  • 模型总参数规模约为 35B；
  • 每个 token 只激活部分专家；
  • 每个 token 实际激活参数约为 3B。

35B-A3B 并不等同于普通 3B 模型。虽然每个 token 只激活约 3B 参数，但模型仍然拥有约 35B 的专家参数总容量，不同 token 可以根据路由结果使用不同专家。

2.3 数据集说明

2.3.1 CEval

CEval 是中文综合能力评测数据集。本次选取金融、经济和法律相关的六个科目：

  1. college_economics
  2. business_administration
  3. accountant
  4. tax_accountant
  5. law
  6. legal_professional

六个科目共包含 233 条测试样本，主要用于评估模型的中文专业知识、概念理解和选择题推理能力。

2.3.2 BoolQ

BoolQ 是自然语言二分类阅读理解任务。模型需要根据给定文本判断问题答案为 Yes 或 No，在当前数据配置中最终转换为 A 或 B 进行严格评分。

BoolQ 测试集共包含 3270 条样本，主要用于评估模型的文本理解、事实判断和短答案生成能力。

2.3.3 GSM8K

GSM8K 是数学应用题数据集，本次采用 4-shot Chain-of-Thought 提示方式，共包含 1319 条测试样本。

每条输入包含四组示例问答，模型需要完成逐步数学推理并输出最终数字答案。由于数学推理过程较长，GSM8K 对最大输出长度较为敏感。

三、统一评测协议与技术路线

3.1 总体技术路线

本次工作并非直接采用 AISBench 默认汇总结果，而是建立了一条统一、严格且可追溯的评测流程。

确认模型服务
        ↓
统一模型配置和数据集配置
        ↓
thinking 模式下固定 2048 全量评测
        ↓
运行任务专用严格评分脚本
        ↓
筛选空预测和未完成预测
        ↓
thinking 模式下使用 8192 补跑一次
        ↓
将补跑结果合并回原始预测文件
        ↓
再次运行严格评分脚本
        ↓
汇总三种模型结果并进行对比分析

该技术路线主要解决以下问题：

  1. 模型可能无法在 2048 token 内完成推理。
  2. 模型可能只输出 reasoning，没有输出最终 content。
  3. AISBench 默认后处理可能从未完成文本中提取中间数字。
  4. 如果对已经明确答错的样本进行补跑，会形成选择性重试。
  5. 多次重复补跑会导致不同模型获得不一致的推理机会。

3.2 固定 2048 评测协议

固定预算评测中，所有模型均采用相同的最大输出长度：

max_tokens = 2048

固定 2048 结果主要反映以下能力：

  1. 模型能否在有限输出预算内完成推理。
  2. 模型推理过程是否简洁。
  3. 模型能否及时进入最终答案阶段。
  4. 模型在固定推理成本下的任务准确率。
  5. 模型在实际受限部署条件下的表现。

固定 2048 阶段对所有样本只执行一次请求，不进行额外重试。

3.3 严格评分规则

本次分别编写 CEval、BoolQ 和 GSM8K 的任务专用严格评分脚本。

严格评分将模型输出划分为以下四类。

3.3.1 正确答案

模型输出中存在明确、完整且符合任务格式要求的最终答案，并且最终答案与标准答案一致。

3.3.2 明确答错

模型已经输出合法、完整的最终答案，但该答案与标准答案不一致。

明确答错的样本不允许补跑。因为模型已经完成了本次作答，如果重新生成，相当于给错误样本第二次答题机会，会破坏评测公平性。

3.3.3 空预测

模型返回的 content 存在以下情况之一：

  • None
  • 空字符串
  • 仅包含空格
  • 仅包含换行符
  • 未形成任何可评分内容

空预测样本允许进入 8192 补跑候选集合。

3.3.4 未完成预测

模型已经生成部分推理内容，但输出在句子、计算步骤或最终答案之前被截断，无法按照严格规则确定最终答案。

未完成预测通常伴随：

finish_reason = length

未完成预测样本允许进入 8192 补跑候选集合。

3.4 自适应 2048→8192 补跑协议

自适应评测不是对全部数据重新使用 8192 运行，而是在固定 2048 全量评测结束后，只对空预测和未完成预测重新推理一次。

补跑阶段统一设置：

max_tokens = 8192
enable_thinking = True
temperature = 0.0

具体规则如下：

  1. 空预测允许补跑一次。
  2. 未完成预测允许补跑一次。
  3. 已经形成合法答案但回答错误的样本不补跑。
  4. HTTP 请求失败单独统计。
  5. 8192 补跑后仍未完成的样本直接计错。
  6. 所有模型最多只进行一次 8192 补跑。
  7. 不进行第三轮补跑。
  8. 不从 reasoning 字段提取最终答案。
  9. 只对 content 字段执行最终答案解析。

该规则可以避免对不同模型采用不同的重试次数，从而保证模型间比较的公平性。

四、具体实施过程

4.1 模型服务确认

每次模型切换后，首先通过 /v1/models 接口确认当前端口部署的模型。

curl -s \
  http://10.70.1.100:8006/v1/models \
  | python -m json.tool

重点检查以下字段：

id
root
max_model_len

然后通过 /v1/chat/completions 发送一条简单测试请求，检查：

  • 当前模型名称是否正确；
  • thinking 模式是否生效；
  • 推理内容是否保存在 reasoning 字段；
  • 最终答案是否保存在 content 字段；
  • finish_reason 为 stop 还是 length；
  • 最大输出长度是否足够模型生成最终答案。

测试 35B-A3B 模型时发现，当最大输出长度设置为 256 时，模型返回：

content: null
finish_reason: length

推理内容全部位于 reasoning 字段，说明模型在达到 256 token 上限时尚未进入最终答案阶段。

将最大输出长度提高至 1024 后，模型能够正常返回：

content: '\n\nanswer:391'
finish_reason: stop

由此确认模型服务、thinking 模式和最终答案字段均正常。

4.2 AISBench 模型配置

AISBench 模型配置文件主要包含以下参数：

model="qwen3.6-27b-bf16"
host_ip="10.70.1.100"
host_port=8006
max_out_len=2048
request_rate=0.1
retry=10
batch_size=1

generation_kwargs=dict(
    temperature=0.0,
    top_k=10,
    top_p=0.95,
    repetition_penalty=1.03,
    chat_template_kwargs=dict(
        enable_thinking=True,
    ),
)

主要参数含义如下：

参数 作用
model 指定调用的模型名称
host_ip 模型服务 IP 地址
host_port 模型服务端口
max_out_len 最大输出 token 数量
request_rate 请求发送速率
retry API 请求失败后的重试次数
temperature 控制生成随机性
enable_thinking 是否启用 thinking 模式
repetition_penalty 控制重复生成

4.3 CEval 评测过程

CEval 采用六科统一配置运行，共 233 条数据。

固定 2048 阶段运行完成后，执行：

python score_ceval_strict.py <RUN_DIR>

严格评分脚本逐个读取六个科目的预测文件，并统计：

total
correct
strict accuracy
empty prediction count
unfinished prediction count
exact-format count
retry candidate count

CEval 最终答案只接受明确的 A、B、C、D 格式。空预测和未完成预测进入 8192 补跑阶段，补跑结果按照科目和样本 ID 覆盖到自适应结果目录中。

4.4 BoolQ 评测过程

BoolQ 共有 3270 条样本。为了降低单次任务持续时间，并方便中断恢复和问题定位，将数据划分为七个分段：

[0:500]
[500:1000]
[1000:1500]
[1500:2000]
[2000:2500]
[2500:3000]
[3000:3270]

其中，区间采用左闭右开形式。例如：

[1000:1500]

实际包含第 1000 至 1499 条样本，共 500 条。

每个分段运行前，通过 Python 脚本自动修改数据集配置文件中的：

test_range='[START:END]'

每个分段运行结束后保存以下内容：

  1. AISBench 运行目录；
  2. 推理日志；
  3. 严格评分结果；
  4. 总样本数；
  5. 正确样本数；
  6. 空预测 ID；
  7. 未完成预测 ID；
  8. 明确答错 ID。

七个分段与运行目录之间的映射统一写入：

run_directories.tsv

补跑脚本读取该映射文件，将七个分段合并为 3270 条全量记录，并根据全局 ID 筛选补跑候选。

4.5 GSM8K 评测过程

GSM8K 采用 4-shot CoT 配置，全量运行 1319 条样本。

固定阶段完成后执行：

python score_gsm8k_strict.py <RUN_DIR>

GSM8K 严格答案提取优先接受以下格式：

#### 18
The answer is 18
Final answer: 18
answer: 18
答案为18

严格评分脚本也允许从完整结束的最后一句中提取最终数字，但不会从以下位置提取答案：

  • 未完成的半句话；
  • 被截断的计算过程；
  • 中间推理步骤；
  • reasoning 字段；
  • 没有正常结束的输出。

补跑脚本首先将固定 2048 预测文件复制到 outputs/adaptive 目录，再逐条调用 vLLM 接口。

每完成一条样本，脚本都会立即保存：

预测结果文件
retry8192_details.json

这样即使长时间任务中途退出，已经完成的补跑结果也不会丢失。

4.6 后台运行与进度监控

长时间任务通过 nohup 方式在后台运行。

nohup env PYTHONUNBUFFERED=1 \
  python retry_gsm8k_35b_a3b_full_incomplete_8192.py \
  > retry_gsm8k_35b_a3b_8192.log 2>&1 &

查看任务进程：

ps -p "$PID" \
  -o pid,etime,%cpu,%mem,stat,cmd

查看父子进程：

pstree -ap "$PID"

实时查看日志：

tail -f "$LOG"

查看 AISBench 请求统计：

tr '\r' '\n' < "$OUT" \
  | grep -E 'Post:|Received:|Failed:' \
  | tail -5

其中：

  • Post 表示已经发送的请求数；
  • Received 表示成功收到响应的请求数；
  • Failed 表示请求失败数。

五、实验结果与分析

5.1 最终结果汇总

表 1：CEval 评测结果

模型 固定 2048 自适应 2048→8192 提升
Qwen3.6-27B-W8A8 185/233 = 79.40% 207/233 = 88.84% +9.44 个百分点
Qwen3.6-27B-BF16 184/233 = 78.97% 212/233 = 90.99% +12.02 个百分点
Qwen3.6-35B-A3B 188/233 = 80.69% 209/233 = 89.70% +9.01 个百分点

表 2：BoolQ 评测结果

模型 固定 2048 自适应 2048→8192 提升
Qwen3.6-27B-W8A8 2989/3270 = 91.41% 2994/3270 = 91.56% +0.15 个百分点
Qwen3.6-27B-BF16 2978/3270 = 91.07% 2981/3270 = 91.16% +0.09 个百分点
Qwen3.6-35B-A3B 2982/3270 = 91.19% 2994/3270 = 91.56% +0.37 个百分点

表 3：GSM8K 评测结果

模型 固定 2048 自适应 2048→8192 提升
Qwen3.6-27B-W8A8 1048/1319 = 79.45% 1265/1319 = 95.91% +16.46 个百分点
Qwen3.6-27B-BF16 1067/1319 = 80.89% 1263/1319 = 95.75% +14.86 个百分点
Qwen3.6-35B-A3B 1154/1319 = 87.49% 1205/1319 = 91.36% +3.87 个百分点

5.2 CEval 结果分析

CEval 共 233 条样本。

固定 2048 阶段：

  • Qwen3.6-35B-A3B 最高，为 80.69%；
  • Qwen3.6-27B-W8A8 为 79.40%；
  • Qwen3.6-27B-BF16 为 78.97%。

三个模型在固定阶段的差距较小。

自适应补跑后：

  • Qwen3.6-27B-BF16 最高，为 90.99%；
  • Qwen3.6-35B-A3B 为 89.70%；
  • Qwen3.6-27B-W8A8 为 88.84%。

各模型提升情况如下：

27B-W8A8：79.40% → 88.84%，提升 9.44 个百分点
27B-BF16：78.97% → 90.99%，提升 12.02 个百分点
35B-A3B：80.69% → 89.70%，提升 9.01 个百分点

CEval 只有 233 条样本，每一道题约占：

1 ÷ 233 × 100% ≈ 0.43 个百分点

因此一至两个百分点的差距可能只对应少量题目，不应对较小差距进行过度解释。

总体而言，固定预算下三个模型表现接近；增加输出预算后，27B-BF16 在 CEval 不完整样本中的恢复效果最好。

5.3 BoolQ 结果分析

BoolQ 共 3270 条样本。

固定 2048 阶段：

27B-W8A8：91.41%
27B-BF16：91.07%
35B-A3B：91.19%

自适应补跑后：

27B-W8A8：91.56%
27B-BF16：91.16%
35B-A3B：91.56%

模型间最终最大差距为：

91.56% - 91.16% = 0.40 个百分点

各模型通过补跑获得的提升较小：

27B-W8A8：提升 0.15 个百分点
27B-BF16：提升 0.09 个百分点
35B-A3B：提升 0.37 个百分点

BoolQ 只要求输出 Yes 或 No，模型一般不需要较长推理。因此，2048 个输出 token 已经基本充足，将最大输出长度提高到 8192 后提升有限。

该结果说明 BoolQ 适合评估模型的文本理解和事实判断能力，但单独使用 BoolQ 难以明显区分三个模型的复杂推理能力。

5.4 GSM8K 结果分析

GSM8K 共 1319 条样本，是三个数据集中对输出长度最敏感的任务。

5.4.1 Qwen3.6-27B-W8A8

固定 2048 阶段：

指标 数量
正确 1048
空预测 184
未完成 73
明确答错 14
补跑候选 257
固定准确率 79.45%

8192 补跑阶段：

指标 数量
形成合法答案 240
补跑答对 217
最终正确 1265
最终准确率 95.91%

补跑合法答案率为：

240 ÷ 257 = 93.39%

补跑候选新增正确率为：

217 ÷ 257 = 84.44%

该结果说明固定 2048 明显限制了 27B-W8A8 完成数学推理的能力。增加到 8192 后，大部分不完整样本都能够形成最终答案。

5.4.2 Qwen3.6-27B-BF16

固定 2048 阶段：

指标 数量
正确 1067
空预测 160
未完成 75
明确答错 17
补跑候选 235
固定准确率 80.89%

8192 补跑阶段：

指标 数量
形成合法答案 219
补跑答对 196
补跑合法但答错 23
补跑后仍无合法答案 16
最终正确 1263
最终准确率 95.75%

补跑合法答案率为：

219 ÷ 235 = 93.19%

27B-BF16 与 27B-W8A8 的补跑合法答案率非常接近，说明两个 27B Dense 模型均能较好地利用更长输出预算。

5.4.3 Qwen3.6-35B-A3B

固定 2048 阶段：

指标 数量
正确 1154
空预测 0
未完成 133
明确答错 32
补跑候选 133
固定准确率 87.49%

8192 补跑阶段：

指标 数量
形成合法答案 53
补跑答对 51
补跑合法但答错 2
补跑后仍未完成 80
最终正确 1205
最终准确率 91.36%

补跑合法答案率为：

53 ÷ 133 = 39.85%

在已经形成合法答案的 53 条样本中，有 51 条回答正确：

51 ÷ 53 = 96.23%

这说明 35B-A3B 的问题不主要表现为“形成答案后大量算错”，而是大量样本没有及时进入最终答案阶段。

因此，35B-A3B 的表现可以分为两个方面：

  1. 能够形成最终答案时，正确率较高。
  2. 在长 thinking 状态下，最终答案完成率明显偏低。

该现象可能与以下因素有关：

  • 模型自身推理风格；
  • chat template；
  • 提示词约束；
  • 停止条件；
  • vLLM 部署参数；
  • 模型训练方式；
  • 长推理过程中的终止行为。

因此，不能将该现象直接归因于 MoE 架构本身。

5.5 W8A8 与 BF16 结果对比

27B-W8A8 和 27B-BF16 采用相同的 Dense 架构和相同参数规模，主要区别在于模型数值精度。

表 4：W8A8 与 BF16 自适应结果对比

数据集 27B-W8A8 27B-BF16 差值
CEval 88.84% 90.99% BF16 高 2.15 个百分点
BoolQ 91.56% 91.16% W8A8 高 0.40 个百分点
GSM8K 95.91% 95.75% W8A8 高 0.16 个百分点

不能根据 BoolQ 和 GSM8K 中 W8A8 略高于 BF16，就得出“量化提高了模型能力”的结论。

更合理的解释包括：

  1. 模型间差距本身较小。
  2. 准确率是离散统计结果，少量题目即可改变排名。
  3. 模型生成过程可能存在一定随机性。
  4. 输出是否完成会影响严格评分结果。
  5. 量化误差不一定改变当前样本的最终决策。
  6. 不同部署实现可能影响模型的生成长度和终止行为。

因此，本次实验只能说明：

在当前数据集、生成参数、部署环境和严格评分规则下，Qwen3.6-27B-W8A8 与 Qwen3.6-27B-BF16 整体精度接近，未观察到 W8A8 量化导致的一致性明显精度下降。

由于本次尚未进行多随机种子重复实验和统计显著性检验，不能据此认定量化完全无损。

5.6 Dense 与 MoE 结果对比

固定 2048 阶段，35B-A3B 在 CEval 和 GSM8K 上均取得最高准确率，尤其在 GSM8K 上达到 87.49%，明显高于两个 27B Dense 模型。

该结果说明，35B-A3B 在有限输出预算下具有较强的初始推理表现，可能受益于较大的总参数容量和专家分工机制。

但是，在 GSM8K 自适应 8192 补跑中：

27B-W8A8 合法答案恢复率：93.39%
27B-BF16 合法答案恢复率：93.19%
35B-A3B 合法答案恢复率：39.85%

35B-A3B 的 133 条补跑候选中，仍有 80 条未形成最终答案。

因此，本次实验得到的结论为：

Qwen3.6-35B-A3B 在固定 2048 输出预算下表现较好，但在当前部署条件下，长 thinking 最终答案完成率较低；两个 27B Dense 模型固定阶段被截断的样本更多，但在增加输出预算后恢复更加充分。

该结论仅适用于本次模型版本、提示词、vLLM 配置和推理服务环境，不能直接推广为所有 MoE 模型均存在相同问题。

六、遇到的问题及解决方法

6.1 问题汇总

表 5：主要问题及解决方法

问题 原因分析 解决方法 解决结果
AISBench 默认结果与严格评分不一致 默认后处理可能从不完整推理文本中提取中间答案 编写任务专用严格评分脚本 得到统一、可解释的严格准确率
thinking 模式下出现空预测 token 用于 reasoning，达到长度上限前未进入 content 对空预测和未完成样本使用 8192 补跑 27B 模型在 GSM8K 上显著恢复
BoolQ 全量运行时间较长 3270 条一次运行不便于恢复和定位问题 将 BoolQ 拆分为七段顺序运行 支持分段重跑、审计和结果合并
历史运行目录较多 同时存在试跑、异常运行和正式运行目录 建立 run_directories.tsv 映射文件 保证样本无重复、无遗漏
多个 AISBench 进程难以判断 主进程会创建子进程和线程 使用 pstree -ap 检查父子关系 避免误杀正常子进程
下班前任务无法完成 thinking 模式推理时间较长 使用 nohup 和自动队列脚本 任务可在终端断开后继续运行
35B-A3B 补跑后仍有 80 条未完成 长 thinking 未进入最终答案阶段 按统一规则直接计错，不进行第三轮补跑 保证三个模型获得相同补跑机会
模型切换后接口参数不确定 不同模型的 thinking 行为和上下文长度不同 使用 curl 进行模型查询和小样本验证 确认模型名、字段结构和生成长度

6.2 AISBench 默认准确率与严格评分不一致

问题表现

35B-A3B 在 GSM8K 历史运行中的 AISBench 默认准确率为 94.92%，但使用严格评分脚本重新计算后，固定 2048 准确率为 87.49%。

原因分析

AISBench 默认 GSM8K 后处理可能从模型的长推理文本中提取数字。即使模型输出已经被截断，只要文本中存在数字，默认后处理仍可能将其作为最终答案。

这些数字可能只是中间计算结果，并不代表模型已经完成最终作答。

解决方法

编写 score_gsm8k_strict.py，仅接受明确答案格式或完整结束的最终句，不从以下内容中提取答案：

  • 未完成句子；
  • 中间计算过程；
  • 被截断的推理内容；
  • reasoning 字段。

解决结果

最终建立了统一、严格的评分口径，避免默认后处理高估模型能力。

6.3 thinking 模式下出现空预测

问题表现

HTTP 请求能够成功返回，Failed=0，但预测 JSON 中的 prediction 为空。

原因分析

thinking 模式下，模型会将大量 token 用于 reasoning 字段。当最大生成长度耗尽时，模型可能尚未进入最终答案阶段，因此：

content = null
finish_reason = length

该情况不是网络请求失败，而是最大输出长度不足。

解决方法

通过 API 测试检查以下字段：

reasoning
content
finish_reason
completion_tokens

然后对空预测和未完成预测使用 8192 token 补跑一次。

评分和补跑只读取 content 字段，不从 reasoning 字段提取答案。

解决结果

27B-W8A8 和 27B-BF16 在 GSM8K 上的大量空预测和未完成样本得到恢复，最终准确率分别由 79.45% 和 80.89% 提升至 95.91% 和 95.75%。

6.4 BoolQ 全量任务持续时间过长

问题表现

BoolQ 共有 3270 条样本，一次性全量运行持续时间较长。若任务中途失败，可能需要重新运行大量已完成样本。

原因分析

远程 vLLM 模型生成速度有限，thinking 模式下单条请求耗时较长，一次运行 3270 条不便于中断恢复。

解决方法

将 BoolQ 划分为七个分段：

[0:500]
[500:1000]
[1000:1500]
[1500:2000]
[2000:2500]
[2500:3000]
[3000:3270]

每个分段单独运行并保存日志、预测结果和严格评分文件。

解决结果

实现分段运行、局部重跑、分段审计和全量合并。单个分段失败时，无需重新运行全部 3270 条样本。

6.5 历史运行目录较多

问题表现

服务器中保存了多次试跑和正式运行，包括：

  • 8 条试跑；
  • 20 条试跑；
  • 50 条试跑；
  • 异常全量运行；
  • 正式分段运行；
  • 补跑结果。

仅按照目录时间判断，容易选错预测文件。

原因分析

AISBench 每次运行都会生成新的时间戳目录，而运行目录名称本身不一定包含样本范围信息。

此外，配置文件在运行完成后可能继续被修改，因此不能通过当前配置文件反推历史任务范围。

解决方法

结合以下信息进行审计：

  1. 日志文件名；
  2. Current exp folder 字段；
  3. 实际预测记录数；
  4. 运行时间；
  5. 分段启动顺序；
  6. 严格评分结果。

建立 run_directories.tsv 文件，为每个任务保存：

task_name
expected_count
run_directory
task_log
strict_log

解决结果

保证七个 BoolQ 分段共 3270 条样本无重复、无遗漏，并为后续补跑脚本提供稳定输入。

6.6 多个 AISBench 进程的判断

问题表现

执行 pgrep 或 ps 时发现多个 ais_bench 进程，容易误认为相同任务被重复启动。

原因分析

AISBench 主进程在推理和评估过程中会创建子进程和线程。多个相关 PID 不一定代表运行了多份相同任务。

解决方法

使用以下命令查看进程树：

pstree -ap <主PID>

区分：

  • 独立启动的重复主任务；
  • 正常 AISBench 子进程；
  • 程序线程。

解决结果

避免误杀正常评测子进程，同时能够识别并终止真正重复启动的任务。

6.7 后台任务持续运行

问题表现

BoolQ 和 GSM8K 全量评测可能持续十几个小时，无法保证在下班前完成。

原因分析

thinking 模式生成内容较长，远程模型服务吞吐有限，GSM8K 1319 条样本的单次运行耗时较长。

解决方法

使用 nohup 和自动队列脚本：

nohup env PYTHONUNBUFFERED=1 \
  bash run_task.sh \
  > task.log 2>&1 &

通过 PID 文件保存主进程信息，通过状态文件记录任务阶段。前一任务完成后，脚本自动启动下一数据集。

解决结果

BoolQ 完成后能够自动启动 GSM8K。即使关闭终端或下班离开，后台任务仍然可以继续运行。

6.8 35B-A3B 补跑后仍有 80 条未完成

问题表现

35B-A3B 在 GSM8K 固定 2048 阶段有 133 条未完成样本。将最大输出长度提高到 8192 后，仍有 80 条没有形成最终答案。

原因分析

模型在部分数学题上持续生成较长 thinking 内容，即使达到 8192 token，也未进入最终答案阶段。

可能影响因素包括：

  • 模型自身的推理风格；
  • chat template；
  • 最终答案提示约束；
  • vLLM 停止条件；
  • 模型训练方式；
  • 长上下文下的生成策略。

解决方法

按照预先确定的统一规则，8192 补跑只执行一次。补跑后仍未完成的样本直接计错，不进行第三轮补跑。

解决结果

保证三个模型获得相同的补跑机会，避免针对某个模型继续增加输出预算而破坏公平性。

七、文件结构与复现说明

7.1 项目目录树

benchmark/
├── ais_bench/
│   └── benchmark/
│       └── configs/
│           ├── models/
│           │   └── vllm_api/
│           │       ├── vllm_api_general_chat.py
│           │       ├── vllm_api_qwen36_27b_w8a8_thinking.py
│           │       └── vllm_api_qwen36_27b_bf16_thinking.py
│           └── datasets/
│               ├── ceval/
│               │   ├── ceval_finance_compliance_strict.py
│               │   └── ceval_finance_compliance_thinking.py
│               ├── SuperGLUE_BoolQ/
│               │   └── SuperGLUE_BoolQ_gen_0_shot_str_chunk.py
│               └── gsm8k/
│                   └── gsm8k_gen_4_shot_cot_chat_prompt.py
│
├── score_ceval_strict.py
├── score_boolq_strict.py
├── score_gsm8k_strict.py
│
├── retry_boolq_27b_w8a8_full_incomplete_8192.py
├── retry_boolq_27b_bf16_full_incomplete_8192.py
├── retry_boolq_35b_a3b_full_incomplete_8192.py
│
├── retry_gsm8k_27b_w8a8_full_incomplete_8192.py
├── retry_gsm8k_27b_bf16_full_incomplete_8192.py
├── retry_gsm8k_35b_a3b_full_incomplete_8192.py
│
├── run_27b_w8a8_boolq_then_gsm8k_quality.sh
├── run_27b_bf16_boolq_full_quality.sh
├── run_gsm8k_after_bf16_boolq.sh
│
├── quality_runs/
│   ├── 27b_w8a8_20260717_155146/
│   │   ├── boolq_0_500.log
│   │   ├── boolq_0_500_strict.txt
│   │   ├── boolq_500_1000.log
│   │   ├── boolq_500_1000_strict.txt
│   │   ├── ...
│   │   ├── gsm8k_full.log
│   │   ├── gsm8k_full_strict.txt
│   │   ├── run_directories.tsv
│   │   └── status.txt
│   │
│   ├── 27b_bf16_boolq_20260723_142012/
│   ├── 27b_bf16_gsm8k_20260723_153136/
│   └── 35b_a3b_boolq_history_20260714/
│       ├── run_directories.tsv
│       ├── boolq_0_500_strict.txt
│       ├── boolq_500_1000_strict.txt
│       ├── ...
│       └── boolq_fixed_2048_summary.txt
│
├── outputs/
│   ├── default/
│   │   ├── 20260718_071837/
│   │   ├── 20260723_142012/
│   │   ├── 20260724_063148/
│   │   └── 20260715_130722/
│   │
│   └── adaptive/
│       ├── 20260717_155146_boolq_27b_w8a8_2048to8192/
│       ├── 20260718_071837_gsm8k_27b_w8a8_2048to8192/
│       ├── 20260723_142012_boolq_27b_bf16_2048to8192/
│       ├── 20260724_063148_gsm8k_27b_bf16_2048to8192/
│       ├── 20260714_boolq_35b_a3b_2048to8192/
│       └── 20260715_130722_gsm8k_35b_a3b_2048to8192/
│
├── boolq_27b_bf16_adaptive_2048to8192_strict.txt
├── gsm8k_27b_bf16_adaptive_2048to8192_strict.txt
├── boolq_35b_a3b_adaptive_2048to8192_strict.txt
├── gsm8k_35b_a3b_adaptive_2048to8192_strict.txt
│
└── final_three_models_summary.txt

7.2 严格评分脚本

score_ceval_strict.py

用于提取 CEval 最终 A、B、C、D 选项，并统计：

  • 正确答案；
  • 空预测；
  • 未完成预测；
  • 明确答错；
  • 格式合规情况；
  • 补跑候选。

score_boolq_strict.py

用于从 BoolQ 输出中严格提取 A 或 B 答案，避免从解释文本和中间推理内容中错误提取选项。

score_gsm8k_strict.py

用于从 GSM8K 输出中提取明确的最终数字答案，不从未结束的中间推理中提取数字。

这三个脚本决定最终严格 accuracy，是整个评测结果可信性的核心。

7.3 补跑脚本

补跑脚本的主要执行流程为：

读取固定 2048 预测文件
        ↓
使用严格规则筛选候选
        ↓
复制原始预测到 adaptive 目录
        ↓
针对候选调用 8192 接口
        ↓
将新 content 覆盖对应 prediction
        ↓
保存每条补跑详情
        ↓
重新运行严格评分

补跑详情文件通常为：

retry8192_details.json

其中保存：

sample_id
gold
prediction
parsed_answer
correct
finish_reason
reasoning
completion_tokens
elapsed_seconds
error

7.4 outputs/default 目录

该目录保存固定 2048 阶段 AISBench 生成的原始运行结果，包括：

predictions
logs
results
summary

该目录必须保留，作为固定预算评测的原始证据。

7.5 outputs/adaptive 目录

该目录保存 8192 补跑并合并后的完整预测文件。

每个自适应目录中通常包含：

predictions/<model-name>/dataset.json
retry8192_details.json

该目录代表最终自适应评测结果。

7.6 quality_runs 目录

该目录用于保存任务级运行日志、状态文件、严格评分文本和运行目录映射。

其中：

status.txt

记录任务启动、结束、错误和完成状态。

run_directories.tsv

记录任务与 AISBench 输出目录的对应关系。

7.7 最终结果文件

final_three_models_summary.txt

该文件保存三种模型、三个数据集的固定 2048 和自适应 2048→8192 结果，是最终汇总文件。

八、结论与局限性

8.1 主要结论

  1. 在 CEval 自适应评测中，Qwen3.6-27B-BF16 表现最好，准确率为 90.99%。

  2. 在 BoolQ 任务中，三个模型的表现非常接近。Qwen3.6-27B-W8A8 和 Qwen3.6-35B-A3B 均达到 91.56%，Qwen3.6-27B-BF16 为 91.16%。

  3. 在 GSM8K 固定 2048 输出预算下，Qwen3.6-35B-A3B 表现最好，准确率为 87.49%，说明该模型在有限输出预算下更容易完成正确推理。

  4. 在 GSM8K 自适应 2048→8192 评测中，两个 27B Dense 模型提升明显。Qwen3.6-27B-W8A8 达到 95.91%，Qwen3.6-27B-BF16 达到 95.75%。

  5. Qwen3.6-35B-A3B 在 GSM8K 8192 补跑后仍有 80 条样本未形成最终答案，导致最终准确率为 91.36%。该现象表明模型当前部署中的长 thinking 最终答案完成率仍有优化空间。

  6. 在本次三个数据集、统一推理参数和严格评分规则下，27B-W8A8 与 27B-BF16 整体精度接近，未观察到 W8A8 量化导致的一致性明显精度下降。

  7. 固定 2048 结果和自适应 2048→8192 结果反映的是不同维度。固定结果更能反映有限输出预算下的推理效率，自适应结果更接近排除输出截断影响后的最终能力。正式汇报时应同时报告两种结果。

8.2 实验局限性

本次实验仍存在以下局限：

  1. 当前结果主要来自单次推理，尚未进行多随机种子重复实验。
  2. 没有对模型结果进行统计显著性检验。
  3. 不同模型由同一端口分时部署，未同时测量吞吐和延迟。
  4. 未系统分析不同 temperature 和提示词对最终答案完成率的影响。
  5. 35B-A3B 长 thinking 未完成问题尚未进一步区分是模型特性、模板问题还是部署参数问题。
  6. 本次主要评估准确率，尚未加入平均响应时延、首 token 时延、输出 token 数和吞吐率等性能指标。
  7. CEval 只选取了金融法律六科，不能代表完整 CEval 全部学科表现。

因此，本次结果应理解为当前模型版本、部署环境、提示词和评分规则下的实验结论，不应直接推广到其他模型版本或其他推理环境。

附录 A：关键运行命令

A.1 查询当前部署模型

curl -s \
  http://10.70.1.100:8006/v1/models \
  | python -m json.tool

A.2 运行 AISBench 评测

ais_bench \
  --models <MODEL_CONFIG> \
  --datasets <DATASET_CONFIG> \
  --summarizer example

A.3 后台运行评测任务

nohup env PYTHONUNBUFFERED=1 \
  ais_bench \
    --models <MODEL_CONFIG> \
    --datasets <DATASET_CONFIG> \
    --summarizer example \
  > task.log 2>&1 &

A.4 查看任务进程

ps -p "$PID" \
  -o pid,etime,%cpu,%mem,stat,cmd

A.5 查看父子进程

pstree -ap "$PID"

A.6 查看推理请求统计

tr '\r' '\n' < "$OUT" \
  | grep -E 'Post:|Received:|Failed:' \
  | tail -5

A.7 执行严格评分

python score_ceval_strict.py <RUN_DIR>

python score_boolq_strict.py <RUN_DIR>

python score_gsm8k_strict.py <RUN_DIR>

A.8 查看项目目录树

cd ~/benchmark

tree -L 3 \
  -I '__pycache__|*.pyc|.git' \
  > benchmark_tree.txt

附录 B：最终结果简表

数据集 最优固定 2048 结果 最优自适应结果
CEval 35B-A3B，80.69% 27B-BF16，90.99%
BoolQ 27B-W8A8，91.41% 27B-W8A8 与 35B-A3B 并列，91.56%
GSM8K 35B-A3B，87.49% 27B-W8A8，95.91%

最终可以概括为：

Qwen3.6-35B-A3B 在固定输出预算下具有较强的初始表现，两个 27B Dense 模型在长输出补跑中恢复更加充分；Qwen3.6-27B-W8A8 与 Qwen3.6-27B-BF16 整体精度接近，本次实验未观察到 W8A8 量化造成的一致性明显精度下降。

# 人工智能 # 算法 # 机器学习 # linux # 服务器
Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

cover

我用 Qwen3.8-Max 做了一个采购合同风险审查工具：从能分析，到能定位、复核和交付

avatar DeepSeek技术社区
cover

我用 Qwen3.8-MAX 搭了一个教研纪要 Agent，一次集体备课几秒出七段、分歧还不被和稀泥

avatar DeepSeek技术社区
cover

OpenCode Go 与 Command Code 的性价比分析 2026.08.31更新

avatar DeepSeek技术社区