开源编码模型剪掉44%专家，Terminal-Bench得分不降反升

同一次发布里出现两个开源模型。Victoria是Qwen3.8-Flash-Next的微调版，专攻编码和代理任务。Maple走加拿大优先路线，税务、福利、法规这类问题默认按加拿大语境回答。

Maple：默认答案从美国换成加拿大

大多数模型回答税务、福利这类问题时，默认提问者住在美国。Maple微调后，默认按加拿大用户处理。

在600个保留问题上，引用加拿大官方来源的比例从6.0%升到62.9%。完全正确的答案从6.6%升到21.8%。回复“没有答案”的比例从47.2%降到23.7%。把加拿大信息强加给明确说住在别处的用户的频率，从2.9%降到1.0%。

编码能力没有跟着缩水：Maple在HumanEval上拿到157/164。这批数字有个前提——评分由AI评审小组完成，人工评审还没做。评论区有人追问：“没有答案”少了近一半，其中多少来自工具调用、多少是直接编的？发布方没给这个拆分。

Victoria：剪掉44%专家，分数反而涨了

Victoria同样是Qwen3.8-Flash-Next的微调版，用REAP剪裁。每层专家数从512降到288，整体砍掉44%。与常见流程不同的是，它直接以4-bit（NVFP4）格式重新训练。训练时就适配最终要发布的格式，不是训完再量化。

Terminal-Bench 2.1上，Victoria平均得分70.0%。这是3次运行的平均，每个任务超时上限8小时。同模型此前的NVFP4版是62.5%。HumanEval是159/164。相比之前的构建，生成回复时少用35%的token。

单块B300上，配合草稿头能跑到280 tok/s，不用草稿头是135 tok/s。GGUF量化版也已放出，文件49.17 GiB。它在Terminal-Bench上拿到75.3%，作者提醒这是单次运行，噪声可能不小。HumanEval的93.2%是5次运行的平均。

想跑起来：体积和兼容性两个坎

GGUF文件带着草稿头。主流llama.cpp还不认识这个组件，加载时直接报错"expected 1256, got 1224"。作者给了解法：从自己的llama.cpp fork自行构建，分支叫qwen4exp-mtp（github.com/rmonsurate/llama.cpp）。预编译二进制在准备中。

Victoria的权重大小48.0 GiB，含草稿头。95.4 GiB的n-gram表单独存放，不计入这个数字。评论区一位RTX 3090加64GB内存的人说跑不动，想要更小的量化版。另一位想在双3090加32GB配置上试，但不确定怎么跑。有人直接说，这是Qwen 35B级别的体积。还有人的工具链不认NVFP4变体，希望出个FreeToken版。

数字背后：社区在质疑什么

有人自己试过REAP。在Deepseek V4上只剪掉25%的专家，分数就没到他愿意发布的程度。REAP在这里能切掉44%还守住分数，换到别的模型上不一定成立。还有人建议改试原理相近的REAM。

对基准分数的怀疑也被提了出来。一位评论者说，最近的模型发布里，平均分经常被无关紧要的基准垫高。Terminal-Bench这类实操任务反而掉5%到10%。Victoria的GGUF版在Terminal-Bench的75.3%只跑了一次，能否复现还缺更多运行数据。

发布方没给说法的还有三件事。更小的量化版本，Maple的人工评审排期，AI评审和人工评审的差距。