AREX Feed Article
独立复测 Hy4-preview 超低位量化版："不要加依赖"20 次里违反 9 次
腾讯混元发布 Hy4-preview 超低位量化版的当天，独立测试者 Bounty（@bountyAIhunter）就在租来的 8xH20 节点上给出了一份第三方复测。他把同一个带 14 项需求规格的构建任务，分别对 BF16 API、Q4_K_M 和 STQ1_0 各跑 20 次，测得的规格满足数依次是 13.1/14、12.7/14 和 11.6/14。损失几乎全部集中在否定性指令上："不要加依赖"（Do not add dependencies）在 STQ1_0 上 20 次里违反 9 次，而正向指令和 CLI 参数从未出错（）。
同一天 05:31 UTC，腾讯混元官方账号 @TencentHunyuan 宣布推出 Hy4-preview 的 GGUF 量化版：1.5TB 权重重压缩至约 200GiB（实际文件 213.66 GiB），方案名为 MIX-STQ1_0，每层位宽由校准数据决定，最低 1.31-bit、最高 2.06-bit；同时提供常规 4-bit 构建 Q4_K_M（435.20 GiB），权重托管在 HuggingFace 的 仓库（）。官方自称精度"几乎不动"：MCP Atlas 83.7→83.2、SWE-Bench multi 82.9→81.3、MRCR 81.3→81.1、IFBench 73.5→72.5。此前报道指出，这些数字当时尚无独立验证结果。
14 项需求各跑 20 次：规格满足从 13.1 掉到 11.6
Bounty 先点明官方数字的边界："每一项都是单次采样（single-shot）得分"，而他想要"单次采样给不出的那个数字"。于是他挑了一个任务，写了一份 14 项需求的构建规格，在租来的 8xH20 节点上对每份文件各跑 20 次，统计 14 项里有多少项存活、平均要重复提醒几次、有多少次擅自加了依赖。
| 构建 | 规格满足 | 平均提醒次数 | 20 次中擅自加依赖 |
|---|---|---|---|
| BF16 API | 13.1/14 | 0.4 | 1/20 |
| Q4_K_M（435.20 GiB） | 12.7/14 | 0.8 | 2/20 |
| STQ1_0（213.66 GiB） | 11.6/14 | 1.9 | 9/20 |
他的原话是："体积减半的代价是 14 项需求里少了 1.1 项。IFBench 说只掉 1 分，所以官方的大标题数字依然成立。"但损失并不是均匀摊开的。STQ1_0 也不是简单的"2-bit"：路由专家的 gate/up 投影在 29 层降到 1.3125 bpw，其余层保持 IQ2_XXS 的 2.0625 bpw。
"不要加依赖"：20 次里违反 9 次
关键在损失的分布：STQ1_0 保留正向指令、丢失否定指令。"不要加依赖"在 20 次运行中违反 9 次，"它从来没有搞错过一次 CLI 参数"。平均提醒次数也从 BF16 API 的 0.4 次涨到 1.9 次。对照之下，BF16 API 也有 1/20 次擅自加依赖，Q4_K_M 是 2/20，说明这类"禁止"指令对模型本就不算稳固，STQ1_0 把违反率从 2/20 抬到了 9/20。
推文发出后十几分钟内，两条回复随即概括了这组发现。TeqVolt（@TeqVolt）写道："单次采样分数衡量的是模型做了什么，从来不是它克制了什么"（）。NEXORA（@NEXORAResearch）说："基准分几乎没动，真实世界的服从度动了。这才是值得盯着的数字"（）。
补丁版 llama.cpp 与 --jinja：没有开箱即用
Bounty 还补了两个"今天所有讨论帖里都缺"的部署事实：两个 GGUF 文件都需要补丁版 llama.cpp，hyv4 架构不在任何 stock 构建里；chat 必须加 --jinja，否则聊天模板"静默地什么都不做"。仓库卡片印证了这两点：需要应用 hy4-preview-patch/ 目录下的补丁，--jinja 是必需的，因为 HY4 的聊天模板不匹配 llama.cpp 任何内置模板家族。
速度方面，Bounty 在 8xH20 上测得 vendor decode 为 19.52 tok/s；仓库卡片给出同一数字（19.52 ± 0.01 t/s），预填充 204.56 ± 1.42 t/s，全量驻留显存约 214 GiB（STQ1_0）或 435 GiB（Q4_K_M）。他的结论是："任何量化档位下，这都不是一台笔记本能跑的模型。"
435GB 还是 213GB：取决于模型要不要守规矩
Bounty 给的选购建议直接来自测试结果："如果模型必须遵守它被明令禁止打破的规则，选 435GB；如果它只需要执行你让它做的事，213GB 就够了。"翻译成使用场景：凡是靠"不要加依赖""不要改配置"这类否定约束兜底的 agent 流水线，STQ1_0 的 9/20 违反率意味着约 45% 的运行会破戒，Q4_K_M 则是 2/20。
测试留下两个没有答案的问题。为什么否定指令比正向指令先丢，Bounty 的推文只给了现象和数据，没有机制解释。这份结论目前也来自一个测试者、一个任务、每组 20 次运行。官方数字与复测数字的差距，恰好是单次采样分数给不出的那一部分。