奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

Qwen3.8-27B 的 Benchmark 加粗口径：VL 表没说明却粗了 18 处

2026-08-16

翻 model card 的 Benchmark 表，大多数人是直奔数字去的：找到自己关心的那一行，看看哪个格子是粗体，心里就有了结论。粗体这个东西看起来天经地义，不需要解释——但它其实是需要解释的，而且解释这件事在 Qwen3.8-27B 的 model card 里只做了一半。

我们采集的是 Hugging Face Qwen/Qwen3.8-27B 仓库，快照 1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0，核对日 2026-08-16。下面所有行号都是我们在这份快照的 README.md 里实读出来的。

先把两张表在文件里的位置钉死

README.md 的 ## Benchmark Results 这一节从第 56 行开始，到 ## Quickstart（README.md:225）之前结束，中间是两张表：

位置行号
## Benchmark ResultsREADME.md:56
### Text PerformanceREADME.md:58
内联 <style> 块README.md:59–README.md:68
表一 <table>README.md:70–README.md:174
表一脚注 <ol>README.md:176–README.md:185
### VL PerformanceREADME.md:189
表二 <table>README.md:191–README.md:210
表二脚注 <ol>README.md:212–README.md:221

有两点值得先说清楚。第一，这两张表在 model card 里是原生 HTML <table>，不是 Markdown 表格（README.md:70、README.md:191）。这意味着你没法靠管道符切列，得当成 HTML 解析。第二，那个内联 <style> 块只出现在表一之前，而两张表用的都是 class="vl-table"——包括标题写着 “Text Performance” 的那一张。这只是个类名，我们不推断原因。

两张表的结构完全对称：各 16 个 <tr>。表一是 1 个表头行 + 3 个分组行（Coding / Agent / General）+ 12 个评测行；表二是 1 个表头行 + 2 个分组行（Agentic Multimodal Intelligence / General Multimodal Intelligence）+ 13 个评测行。合计 25 个评测行、25 个不同的评测集名，无重名。列名也完全一样，五列：Qwen3.8-27B、Qwen3.6-27B、Qwen3.7-Plus、Muse Glimmer-30B、Opus4.6 Max（README.md:72、README.md:192）。这四个对比列是 model card 自己选的对比对象，不是我们做的对比。

差异本身：一句读表说明，只写在一张表下面

表一的脚注是 8 条 <li>，位于 README.md:177–README.md:184。其中第 7 条（README.md:183）原文是：

The best result in each row is shown in bold.

表二的脚注也是 8 条 <li>，位于 README.md:213–README.md:220。这 8 条分别讲的是：CI 两种设置的呈现方式与标注修正、MathVision 的 prompt 口径、WebArena-Verified 的 grader 与 scaffold、RecreationBench 的自建属性与覆盖平台、ClawEval-MM 的 Pass@3 与 average 定义、Vision2Web 的取平均方式与判分模型、SWE-MM 的 split 与改动来源，以及最后一条对 -- 的释义。没有任何一条说明加粗代表什么。

而表二实际是用了加粗的。我们在快照目录里数了一遍：

python -c "
import io
lines=io.open('README.md',encoding='utf-8').read().split('\n')
text=' '.join(lines[70:174]); vl=' '.join(lines[191:210])
foot_t='\n'.join(lines[174:187]); foot_v='\n'.join(lines[210:222])
print('text <tr>:',text.count('<tr>'),'vl <tr>:',vl.count('<tr>'))
print('text <li>:',foot_t.count('<li>'),'vl <li>:',foot_v.count('<li>'))
print('text --:',text.count('>--<'),'vl --:',vl.count('>--<'))
print('text strong:',text.count('<strong>'),'vl strong:',vl.count('<strong>'))"

输出：

text <tr>: 16 vl <tr>: 16
text <li>: 8 vl <li>: 8
text --: 10 vl --: 13
text strong: 13 vl strong: 18

表一 13 处 <strong>，表二 18 处。所以事实是这样两句并列的：「每行最高值加粗」这句说明写在 README.md:183，属于表一脚注；表二的 8 条脚注（README.md:213–README.md:220）里没有对应说明，而表二用了 18 处 <strong>。表一那条脚注是否适用于表二，README 没有说。我们只陈述这个差异，不推断原因，也不拿它评价什么。

顺带说一句为什么加粗数会比评测行数多：多指标的单元格里一个格可以含多处加粗，比如同时给 Pass@3 和 Average 两个标签的格子。所以 13 和 18 这两个数不能直接除以行数当成「有几行有最高值」。

这个差异会在哪几处具体绊到人

如果你默认把表一的口径搬到表二，会碰上下面几种情况。我们用程序把 21 个单指标行做了「加粗是否唯一且等于该行最高值」的判定，输出全为 OK；剩下的多指标行逐格核对，问题都出在这些行上。

第一处，表二 ClawEval-MM（README.md:199）的 Pass@3 有两个加粗。 这一行的 Pass@3，Qwen3.8-27B 是 57.4，Qwen3.7-Plus 也是 57.4，两列同时带 <strong>。若照表一脚注「每行最高值加粗」的口径去读，这一行就出现了两个「最高」。同一行的 Average 指标，加粗落在 Qwen3.7-Plus 的 60.1，Qwen3.8-27B 的 Average 是 56.9，没有加粗。这一行的脚注（README.md:217）只解释了 Pass@3 与 average 各自怎么算——Pass@3 是三次试验中至少通过一次的任务比例，average 是三次试验的平均分——没有解释并列加粗。

第二处，多指标行的加粗不归属某一列，而归属某一个指标。 表二有三行带 “Without CI” / “With CI” 两种设置：

  • MathVision（README.md:203）：Without CI 的加粗在 Qwen3.7-Plus 的 90.3；With CI 的加粗在 Qwen3.8-27B 的 94.6，而这个指标全表只有这一格有值。
  • BabyVision（README.md:204）：Without CI 加粗 65.7、With CI 加粗 85.6，两个都在 Qwen3.8-27B。
  • CharXiv (RQ)（README.md:205）：Without CI 的加粗在 Qwen3.7-Plus 的 85.8；With CI 的加粗在 Qwen3.8-27B 的 90.2。

也就是说，「这一行加粗在哪一列」这个问题在这三行里没有单一答案，必须指明是哪个指标。表一的 Agents' Last Exam（README.md:133–README.md:138）是同类结构，Pass@1 的 20.4 与 Score 的 42.9 两处加粗都在 Qwen3.8-27B。

第三处，CharXiv (RQ) 那一行的 Muse Glimmer-30B 单元格没有 CI 标签。 同行其余四列都写成 “Without CI xx”（部分还带 “With CI xx”），只有这一列是裸的 78.8（README.md:205）。表二脚注第 1 条（README.md:213）写的是 “otherwise, only the available setting is shown”。差异到此为止，README 没有进一步说明。

还得补一句：CI 这个缩写在整份 README.md 里从头到尾没有被展开解释过。我们用 Python 全文检索过 code interpreter、Code Interpreter、confidence interval（大小写不敏感），返回 0 处命中。所以引用这三行的时候，只能原样写 “Without CI” / “With CI”，不许自己给它安一个全称。同样，表一 Terminal Bench 2.1 (Terminus) 里那个 Terminus 是什么，README 也没写。

顺手把 -- 的读法一起校准

既然在数 <strong>，就把 -- 一起数了：表一 10 处、表二 13 处。这些 -- 不是均匀分布的。按列拆开看（跳过 colspan 分组行逐格解析）：

列表一 12 行中有数值 / 为 --表二 13 行中有数值 / 为 --
Qwen3.8-27B12 / 013 / 0
Qwen3.6-27B12 / 013 / 0
Qwen3.7-Plus12 / 013 / 0
Muse Glimmer-30B5 / 73 / 10
Opus4.6 Max9 / 310 / 3

-- 的官方释义在两张表的最后一条脚注里都有，原文一致：「Empty cells (—) indicate that results are not yet available or not applicable.」（README.md:184、README.md:220）。所以它既不是 0 分，也不是「不支持」，更不是「不行」。引用带 -- 的行时，把这句定义一起带上，比自己造一个解释安全得多。

这里同样只陈述覆盖率的差异，不推断原因，也不据此评价任何一列对应的模型。

那到底该怎么写引用句

把上面几条合起来，一个能站住脚的引用句至少要包含四件事：哪个评测集、哪一列、哪个指标、以及这是谁说的。

反面例子最能说明问题：「Qwen3.8-27B 得了 90.3 分」这句话在这两张表里根本无法定位——90.3 是表一 LiveCodeBench v6 的 Qwen3.8-27B 值（README.md:166–README.md:171），同时也是表一 GPQA Diamond 的 Qwen3.7-Plus 值（README.md:150–README.md:155），还是表二 MathVision Without CI 的 Qwen3.7-Plus 值（README.md:203）。少写一个限定词，读者就对不上号。

还有三条限定是引用时躲不开的：

  • 改动过的评测集要连改动一起说。 SWE-bench Pro 的脚注（README.md:177）写了 “Problematic tasks were corrected, and all baseline models were re-evaluated on the refined benchmark”；MathVision 与 CharXiv (RQ) 的脚注（README.md:213）写了对少量错误标注做过人工核对后的修正。
  • 同一行里混用了不同来源的分数要说明。 还是 SWE-bench Pro 那条脚注：Opus4.6 Max 用的是 “officially reported score”，其余模型是在 Claude Code harness 下按 temp=1.0、top_p=0.95、256K context window 评的。MathVision 那条（README.md:214）也一样：Qwen3.8-27B 用固定 prompt，其余模型取两种 prompt 变体中的较高分。
  • 自建评测集要标出来。 QwenSWEBench（README.md:180）、CoWorkBench（README.md:181）、RecreationBench（README.md:216）在脚注里被 model card 自述为 in-house（自建）评测。

最后，25 个评测行里，表一有 6 个评测集完全没有脚注（Terminal Bench 2.1 (Terminus)、JobBench、Agents’ Last Exam、IFBench、GPQA Diamond、LiveCodeBench v6），表二有 5 个完全没有脚注（OSWorld-Verified、AndroidWorld、OmniDocBench 1.5、RealWorldQA、ERQA）。这两张表和两组脚注里都没有写评测执行日期、硬件与推理框架版本、随机种子、置信区间或方差；对比列各自的版本、快照与调用方式，除 SWE-bench Pro 那条脚注外也没有交代。所以「有脚注」不等于「方法已完全公开」，「没脚注」也不等于什么别的——就是没写。

回到开头那件事：加粗是排版，脚注才是它的定义。定义只写在表一下面，表二用了 18 处却没有对应说明。知道这一点，比记住任何一个数字都更影响你怎么读这张表。所有数字都是 model card 自述的评测结果，评测方法与环境以官方说明为准，我们没有复现过。

延伸阅读

本文依据 Hugging Face 仓库 Qwen/Qwen3.8-27B 的 model card 与随仓配置文件 （config.json、generation_config.json、preprocessor_config.json、chat_template.jinja 等）整理， 核对日 2026-08-16，对应仓库快照 1d4bf0f。 本文内容为 model card 与配置文件口径，我们没有下载权重、没有部署、也没有推理过这个模型， 因此不涉及生成质量、推理速度与显存占用的任何描述；文中所有评测数字均为 model card 自述，我们没有复现。 模型仓库内容随上游更新而变动，请以官方最新说明为准。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员