AREX Feed Article
1.5TB 压到约 200GiB：腾讯混元发布 Hy4-preview 超低位量化版
腾讯混元官方 X 账号 @TencentHunyuan（显示名 Tencent Hy，商业认证）于 2026 年 8 月 29 日 05:31 UTC（北京时间 13:31）发推宣布推出 Hy4-preview 的 GGUF 量化版：把 1.5TB 的权重压缩到约 200GiB，采用名为 MIX-STQ1_0 的混合量化方案，逐层位宽由校准数据决定，低至 1.31-bit 的 STQ1_0，高至 2.06-bit 的 IQ2_XXS（）。1.5TB 对约 200GiB，模型体积砍到约七分之一。
官方给出的四项基准对比 BF16 只掉了 0.2 到 1.6 分：MCP Atlas 83.7→83.2、SWE-Bench multi 82.9→81.3、MRCR 81.3→81.1、IFBench 73.5→72.5。权重托管在 HuggingFace 仓库 ，模型卡列出实际文件为 213.66 GiB（2.38 bpw）。压缩率和精度数字目前均为厂商自述，尚无独立验证结果。
校准数据决定每一层拿几个 bit
「诀窍不只是压得低，而是压在哪里。」官方推文这样解释 MIX-STQ1_0 的设计：校准数据为每一层挑选位宽，「同样的预算，更低的误差」。
模型卡给出了具体分配：路由专家的 gate/up 投影在 29 层用 1.3125 bpw（STQ1_0），另 48 层用 2.0625 bpw（IQ2_XXS），整体 2.38 bpw。STQ1_0 格式来自 llama.cpp 的 PR #22836：权重为三值 {-d, 0, +d}，每 4 个 lane 强制 1 个为零（3:4 稀疏）；每 4 个权重存成 4-bit 码加 1-bit 选表位，索引一个 32 项码本，每 256 个权重共用一个 fp16 scale，折算下来正好 1.3125 bpw。
改动在编码器。模型卡称，上游量化器直接取最大值 amax 作 scale、把零放在绝对值最小的位置，对训练后量化不够用；他们保持格式逐字节一致，只改两个决策：用加权最小二乘求 scale，按 imatrix 感知的增量代价选择置零位置。
在 1200 行真实专家权重上实测，最小二乘 scale 单独带来 -89.7% 的加权 SSD 下降，imatrix 项再补 -4.1%。推文配图把 MIX-STQ1_0 与均匀低位方案 UD-IQ1_M 并排对比：同样预算下，路由专家权重平均 1.78 bpw（102.8 GiB），比 UD-IQ1_M 的 1.88 bpw（108.3 GiB）还小 5.5 GiB。
模型卡还写了位宽花在哪：路由专家族占全部参数的 97.7%；直接写回残差流的 ffn_down_exps 刻意用高两档的 IQ3_XXS（最后 3 层 IQ4_XS）；attention out 等张量只落在 Q5_K，因为 llama.cpp 只在 n_expert==8 时自动提档，HY4 的 256 个专家匹配不上。
六项基准：掉得最多的是 HLE-agent 的 2.4 分
推文正文列了四项：MCP Atlas 83.7→83.2，SWE-Bench multi 82.9→81.3，MRCR 81.3→81.1，IFBench 73.5→72.5。推文配图的图表还多列了两项：SWE-Bench Pro 65.7→65.0，HLE-agent 55.5→53.1。六项里跌幅最大的是 HLE-agent 的 2.4 分，最小的是 MRCR 的 0.2 分。
仓库里另有一个常规 4-bit 构建 Q4_K_M（435.20 GiB，4.86 bpw），模型卡称其为「安全默认」，STQ1_0 的体积约为它的一半。
官方 GGUF 不能直接跑：要先给 llama.cpp 打补丁
两套 GGUF 都不能用官方 llama.cpp 直接运行。模型卡写明：hyv4 架构尚未上游，需要先 checkout 到指定提交 0cea36222，再打两个补丁，0001 是 hyv4 架构补丁（两个构建都需要），0002 是 STQ1_0 量化与 CUDA 补丁。chat 必须加 --jinja 参数，HY4 的模板不匹配 llama.cpp 任何内置家族。
显存门槛不低：全量驻留需要约 214 GiB（STQ1_0）或约 435 GiB（Q4_K_M），不够就降低 -ngl 参数。模型卡给出 8×H20 上的实测吞吐：prefill 204.56 t/s，decode 19.52 t/s。此外 STQ1_0 的编码器强制依赖 imatrix，重新量化必须提供；GGUF 要放本地盘，llama.cpp 的 mmap 在 NFS 上随机页错误只有约 12 MB/s。
770B 的 MoE 为什么经得起 1.31-bit
Hy4-preview 是腾讯 Hy 团队的新一代 MoE 旗舰：770B 总参数、每 token 激活 49B；78 层中首层用稠密 FFN，其余 77 层各含 256 个路由专家和 1 个共享专家，每 token 激活 top-8。注意力用带 IndexCache 的 Gated DSA，残差路径用 iHC，上下文 1M，Apache 2.0 协议（）。权重此前已以 BF16 和 FP8 两种精度开源在 HuggingFace、ModelScope、GitCode、CNB 四个平台。
推文说的 1.5TB 是 BF16 权重文件的体积，770B 是参数量。独立 AI 研究员 Benjamin Marie（博客 The Kaitchup 作者）在转发中给了一个解释：极低位量化对超大规模 MoE 很有效，「说明大量权重近乎无用或冗余」（）。加上 97.7% 的参数集中在路由专家这一族，逐层分配位宽正好作用于模型最胖的部分。
有人在等 imatrix，有人在问仓库是谁的
要复现的人反应最快。Alexey Fateev（@superalesha，在 4×RTX 3090 上评测本地 LLM 的独立基准测试者）转发说：「2.38 bpw 而 MRCR 只掉 0.2 分，听起来是大胜。我想自己验证这个数字，但 214 GiB 放不进 96 GB，这模型我这边跑不了。他们的编码器改动不是，它适用于任何模型。@TencentHunyuan 把 imatrix.gguf 和分层选择规则发出来，我就在能装进 4 张 3090 的 MoE 上跑同一套配方」（）。
也有人把问题指向基准没覆盖的地方。Flextor（@Flextor97，自称当天就实测新发布模型的评测者）在回复里问：1.5TB 到约 200GiB 是 7 倍削减，真正的考验是长上下文，「1M 窗口在 1.31-bit 下还撑得住吗？超过 200k token 召回会不会掉？」（）。
仓库的归属是这条发布里没交代清楚的部分。权重所在的 HuggingFace 账号名叫 AngelSlim，腾讯官方模型卡的 Quantization 一节则写着「我们提供 AngelSlim」，称它是更易用、更全面的模型压缩工具包。GGUF 仓库的模型卡通篇以第一人称介绍构建，但没有署名作者，也没有说明自己与腾讯官方的关系。模型被压到了 1.31-bit，作者是谁反而没有交代。