Qwen3.8-27B 的评测表里，有一行两列同时被加粗

看 model card 的评测表，大多数人只看自己关心的那一行，扫一眼哪个格子是黑的就翻页了。加粗几乎是这类表格里最省事的信号——不用读数字，眼睛自动会往粗体上跳。

但加粗的含义是要写在某处的。Hugging Face 上 Qwen/Qwen3.8-27B 的 model card 里，## Benchmark Results 一节有两张表，加粗规则只在其中一张的脚注里被解释了一次；而在没有被解释的那张表里，有一行出现了两个加粗的相同数字。下面这篇只做一件事：把这处差异原样摆出来，给出能让你自己回原文核对的位置，然后停住。

以下全部内容基于我们 2026-08-16 采集的快照 1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0，所有数字均为 model card 自述，评测方法与环境以官方说明为准，我们没有复现过任何一项评测。

先看这一行

这一行在 README.md:199，属于 ### VL Performance 表（表格整体位于 README.md:191–README.md:210）里的 Agentic Multimodal Intelligence 分组。评测集名叫 ClawEval-MM，能力标签是 Multimodal tool use。它是一个多指标行，每格里同时给 Pass@3 与 Average 两个数：

列名（照抄 README.md:192）	Pass@3	Average
Qwen3.8-27B	57.4	56.9
Qwen3.6-27B	42.6	50.4
Qwen3.7-Plus	57.4	60.1
Muse Glimmer-30B	—	—
Opus4.6 Max	52.5	54.7

（拆成两栏只是为了看清楚；原表里 Muse Glimmer-30B 那一格是一个 --，并没有分指标写。）

表里的加粗表示原表该处带 <strong> 标签，不是我们加的强调。Pass@3 这一栏，57.4 在 Qwen3.8-27B 与 Qwen3.7-Plus 两列同时带 <strong>；两个数值本身完全相同。Average 栏的加粗只有一处，落在 Qwen3.7-Plus 的 60.1。

-- 是原表原样的写法，脚注给出的定义是 “Empty cells (—) indicate that results are not yet available or not applicable.”（README.md:220）。引用时照抄这句定义就好，别自己解释成 0 分或者「不支持」。

ClawEval-MM 这一行的指标口径 model card 里是写了的，在表二脚注第 5 条（README.md:217）：Scores are reported as “Pass@3 / average score.” Pass@3 is the percentage of tasks passed in at least one of three trials; the average score is the mean benchmark score across the three trials.

加粗规则写在哪一张表的脚注里

两张表各有一组脚注，都是 8 条 <li>：表一（### Text Performance）的脚注在 README.md:176–README.md:185，表二（### VL Performance）的脚注在 README.md:212–README.md:221。

「加粗代表什么」这句只在表一的脚注里出现了一次，是第 7 条，原文一行：

The best result in each row is shown in bold.

位置是 README.md:183。

表二那 8 条脚注（README.md:213–README.md:220）里，没有任何一条说明加粗的含义——它们分别讲的是 CI 标签的呈现方式与标注修正、MathVision 的 prompt 口径、WebArena-Verified 的 grader、RecreationBench 的自建属性、ClawEval-MM 的指标定义、Vision2Web 的平均方式与判分模型、SWE-MM 的 split，以及 -- 的含义。

同时，表二实际是用了加粗的。按我们对快照的统计，表一有 13 处 <strong>，表二有 18 处（多指标单元格里一格可以含多处加粗）。也就是说：说明写在表一，用法两张表都在用，但表二没有对应的说明。

这两件事放在一起，就出现了本文标题那一行：如果按表一脚注「每行最高值加粗」的口径去读表二，ClawEval-MM 的 Pass@3 这一栏里出现了两个「最高」。表一那条脚注是否适用于表二，README 里没有说明。

到这里就停。为什么不写、是不是同一套模板套下来的、哪一处「才是对的」——这些我们没有依据，不推断，也不拿它去评价这份 model card 或者做这份表的人。

你可以自己数一遍

这类观察最怕的就是「我记得好像是」。所以给出我们用的口径，你可以在自己拉到的快照里跑一遍。先看两张表的结构：

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>'))"

我们这边的输出是：表一 16 个 <tr>、表二 16 个 <tr>；脚注各 8 条；-- 表一 10 处、表二 13 处；<strong> 表一 13 处、表二 18 处。

<tr> 的读法要小心：表一的 16 行 = 1 个表头行 + 3 个分组行（Coding / Agent / General）+ 12 个评测行；表二的 16 行 = 1 个表头行 + 2 个分组行（Agentic Multimodal Intelligence / General Multimodal Intelligence）+ 13 个评测行。两张表合起来 25 个评测行、25 个互不重名的评测集。直接把 16 当成「16 个评测」就错了。

还有一点值得提前知道：这两张表在 model card 里是原生 HTML <table>，不是 Markdown 表格（README.md:70、README.md:191）。所以想按行按格解析，得用 HTML 解析器，靠竖线切分是切不动的。我们核这一行用的就是逐 <tr> 切行、逐 <td> 切格，把每格的纯文本、<strong> 标记和 metric-label（Pass@1 / Score / Pass@3 / Average / Without CI / With CI）分别取出来再比对。

顺带一提，表一的标题写的是 “Text Performance”，但它的 HTML 类名和表二一样是 vl-table（README.md:70、README.md:191），样式定义块也只写在表一之前（README.md:59–README.md:68）。这只是个类名，同样不推断原因。

表二里其它几个多指标行

既然翻到了这里，把表二另外几个含多指标的行的加粗落位也一并记下来，省得下次又要重数。这些同样只是位置记录，不是能力结论：

• MathVision（README.md:203）：Without CI 的加粗在 Qwen3.7-Plus 的 90.3，With CI 的加粗在 Qwen3.8-27B 的 94.6——With CI 这一指标在该行只有这一格有值。
• 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。这一行还有另一处差异：同一行其余四列都写成 “Without CI xx”（部分另有 “With CI xx”），只有 Muse Glimmer-30B 那格是裸的 78.8，既没有 “Without CI” 也没有 “With CI” 的标注；而脚注（README.md:213）写的是 “otherwise, only the available setting is shown”。

必须说清楚的是：CI 这个缩写在整份 README 里从未被展开解释。我们对全文检索 code interpreter、Code Interpreter、confidence interval（大小写不敏感），返回 0 处命中。所以引用时只能原样写 “Without CI” / “With CI”，谁也别去猜它是什么。

表一里也有一个多指标行 Agents' Last Exam（README.md:133–README.md:138），Pass@1 的 20.4 与 Score 的 42.9 都在 Qwen3.8-27B 列带加粗。

这一行给读表的人留下的规矩

ClawEval-MM 这一行之所以值得单独写一篇，不是因为它「说明谁更强」——恰恰相反，它是个提醒：加粗是排版信号，不是结论。你至少要做到下面几条，引用才站得住：

第一，引用必须带指标名。同一行里 Pass@3 和 Average 的加粗落点就不一样，只写「ClawEval-MM 得了 57.4」，读者无从判断你说的是哪个指标、哪一列。表里出现过同一个数字落在完全不同位置的情况，例如 90.3 在表一是 LiveCodeBench v6 的 Qwen3.8-27B 值，也是 GPQA Diamond 的 Qwen3.7-Plus 值，还是表二 MathVision Without CI 的 Qwen3.7-Plus 值。省掉限定就是歧义。

第二，加粗只能转述成事实，不能转述成能力。可以写「model card 自述该单元格在该行带加粗」，不能写成「因此在多模态工具调用上更强」。这张表里没有总分、没有平均分、没有加权分、没有排名，也没有任何总分口径，自己算一个出来同样不行。

第三，列名照抄，不解释。Qwen3.6-27B、Qwen3.7-Plus、Muse Glimmer-30B、Opus4.6 Max 这四列是 model card 自己选的对比列。除了 SWE-bench Pro 那条脚注（README.md:177）说明了 Opus4.6 Max 用的是官方公布分之外，README 没有交代这些对比列各自是怎么跑的、是哪个版本。我们也不去查证。

第四，别把脚注覆盖率当成方法透明度。脚注只覆盖了一部分评测集：表一有 6 个评测集完全没有脚注，表二有 5 个。有脚注的那些也未必写全——整节里没有评测执行日期、没有硬件与推理框架版本、没有随机种子、没有置信区间或方差，除 SWE-MM 写了 “public dev split”（README.md:219）外也没有逐项说明版本与 split。

第五，自建评测要标出来。表二的 RecreationBench 在脚注里被自述为 in-house（README.md:216），表一的 QwenSWEBench（README.md:180）、CoWorkBench（README.md:181）同样如此。引用时把「model card 自述为自建评测集」这句带上。

最后一条老生常谈：不许由分数推资源。27B 这个名字、64 层、262,144 的上下文，还有表里任何一格分数，都推不出显存占用、量化后体积、吞吐或时延。这类推算我们一个字都不写。

回到标题那一行。两列同一个数字同时加粗，说明的其实是一件很朴素的事：一张表里的排版约定，只在写下约定的那张表里成立；跨表沿用之前，最好先回原文看一眼脚注在不在。

延伸阅读

• 从头读起：Qwen3.8-27B 是什么：一个模型仓里有哪些文件、各自负责什么
• 本专题共 35 篇，完整分组目录见专题页
• Qwen3.8-27B 的 Benchmark 加粗口径：VL 表没说明却粗了 18 处
• Qwen3.8-27B 评测表里的 CI 是什么：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 自述，我们没有复现。 模型仓库内容随上游更新而变动，请以官方最新说明为准。