--- layout: post.njk source: https://yage.ai/share/hy3-one-bit-single-gpu-20260716.html speaker: yage.ai title: |- 腾讯混元 Hy3 的 1-bit 量化：单卡能装下，离好用还有多远 date: '2026-07-16' summary: 文章介绍了腾讯混元发布的 Hy3 模型及其量化版本（如 IQ1_M），重点分析了模型压缩（如 1-bit 量化）对显存占用、运行可靠性以及生成速度的影响。核心观点是，虽然量化能显著减少权重文件大小并适应有限的硬件，但它也带来了上下文长度缩短和复杂任务可靠性可能下降的风险，最终建议用户根据实际工作流进行 A/B 测试。 area: tech-engineering category: ai-ml tags: - model - quantization - memory - agentic-workflow people: [] companies_orgs: - 腾讯混元 products_models: - Hy3 media_books: [] draft: true status: evergreen --- 7 月 14 日，腾讯混元发布了 Hy3 的 IQ1_M 和 Q4_K_M 官方 GGUF 量化版本。传播最广的数字是：一个 295B 参数的模型压缩后约为 85.5 GiB，可以加载进单张 96GB 显卡。 这个数字没有问题，但它只回答了权重能否装下。模型运行时还需要 KV cache 和计算缓冲，量化也可能影响复杂任务的可靠性。再加上首字等待和生成速度，单卡能加载与日常好用之间，至少还有三笔账。 ## Hy3 做了怎样的能力取舍 Hy3 是腾讯混元发布的开源纯文本模型，拥有 295B 总参数、21B 激活参数，支持 256K 上下文，采用 Apache 2.0 许可。它使用 MoE 架构，每次只调用一部分专家权重。总参数决定模型的容量，21B 激活参数则控制每一步实际参与计算的规模。 这种设计带来了清楚的取舍。根据第三方评测机构 Artificial Analysis 的综合测试，Hy3 与 DeepSeek V4-Pro 处在相近区间，但低于 GLM-5.2。具体到任务，网页搜索、长文检索和工具编排是它的相对强项；仓库级 coding、终端操作和长程软件工程则弱一些。腾讯混元用较低的激活计算量，换来较宽的 agent 能力覆盖，没有同时追求最强的 coding 表现。 同一套综合评测下，Hy3 与 DeepSeek V4-Pro 接近，但低于 GLM-5.2 ## 1-bit 并不是整个文件每权重 1 bit 量化会用较低精度保存模型权重，从而减少显存占用。AngelSlim/Hy3-GGUF 中最受关注的 IQ1_M，通常被称为 1-bit 版本。 这里的 1-bit 是量化规格的名称。根据 Hugging Face 文件元数据，无 MTP 的 Hy3-IQ1_M.gguf 为 83.30 GiB，完整文件平均每个权重占 2.425 bit，也就是 2.425 BPW；带 MTP 的版本为 85.45 GiB、2.488 BPW。Q4_K_M 的无 MTP 版本则是 169.81 GiB。 实际位宽高于名字，是因为官方没有把所有张量压到同一精度。注意力、共享专家、嵌入和输出等关键路径保留了更多信息，缩放参数和文件元数据也会占空间。IQ1_M 压得最狠的是大量路由专家权重，整个文件仍是一套混合精度配方。 ## 96GB 单卡还要给 KV cache 留位置 权重加载后，模型还要保存自己读过的上下文。KV cache 就是这些注意力中间结果，输入越长，占用的显存越多。Hy3 使用 q8 KV cache 时，64K 上下文约需 10.63 GiB。 把它与权重相加，单卡预算就变得紧张。无 MTP 的 IQ1_M 占 83.30 GiB，加上 64K q8 KV cache 后达到 93.93 GiB，只剩 2.07 GiB。CUDA context、计算缓冲、计算图和显存碎片还没有算进去。官方确实提供了单张 H20 跑 64K 的配置，并把它标为 tight，但没有公开这套配置的峰值显存和速度日志。它证明方案可以尝试，不足以说明生产运行会很从容。 带 MTP 的权重是 85.45 GiB。加上同样的主模型 KV cache，算术结果已经达到 96.08 GiB，尚未加入 MTP 自己需要的 draft KV cache 和其他运行开销。官方的单卡方案因此推荐无 MTP、64K 上下文和 q8 KV cache。Hy3 支持 256K，是模型的架构上限，并不代表单张 96GB 卡也能使用这么长的上下文。 Hy3 IQ1_M 在 96 GiB 单卡中的权重与 64K KV cache 预算 ## 省下的显存，可能由可靠性来付账 目前，官方没有公开 BF16、FP8、Q4_K_M 和 IQ1_M 在同一套评测流程下的完整对照。公开说法是：4-bit 在 agent、代码、工具调用和长文理解上接近 BF16；1-bit 的长文理解接近原版，agent 和代码能力有小幅回落。 问题在于，小幅回落落到多步任务里，未必仍然小。一个 coding agent 要连续选择工具、填写 JSON 参数、修改代码、判断测试结果。任何一步出现偏差，后面的动作都可能跟着改变。普通问答看不出明显差异，并不能证明长程任务同样可靠。 这只是风险机制，不是已经测出的 Hy3 IQ1_M 失败率。Hy3 的参数规模较大，IQ1_M 又会按权重重要性分配不同精度，实际表现可能比朴素的 1-bit 直觉更好。答案仍要靠真实工作流的 A/B 测试，尤其要记录格式错误、无效工具调用、重试次数和完整任务成功率。 ## 速度够交互，长上下文仍然要等 现有性能数据主要来自社区转换版本，不能直接当成官方 IQ1_M 或 Q4_K_M 的统一实测。社区 GGUF 在 M3 Max 128GB 上大约能生成 23–25 tok/s；社区 MLX 版本在 M3 Ultra 上约为 27–29 tok/s。这些速度足以进行日常交互。MLX 实测与 GGUF 实测 使用了不同量化，数字只能用来判断大致体感。 生成速度也不是全部。模型先读 prompt 的阶段叫 prefill。M3 Max 上的社区测试约为 41 tok/s，冷读 8K prompt 粗略需要接近 200 秒。对于上下文很长的 coding agent，真正影响节奏的可能是首字等待，而不是后面每秒生成多少 token。 两张 H200 运行社区 IQ2_M 的测试为 72.2 tok/s，打开 MTP 后达到 81.5 tok/s。MTP 会一次预测多个后续 token，再由主模型验证。官方宣称它可以提速 50%–60%，但社区可审计结果高度依赖置信度门控；这组 H200 测试的提升约为 13%，Apple Silicon 上则基本没有收益。llama.cpp PR #25395记录了这些差异。 已有 96GB 显卡，可以从无 MTP、16K 或 32K 上下文的 IQ1_M 开始测试。已有 256GB M3 Ultra，也可以尝试社区 4-bit MLX。私有生产部署更适合先评测 Q4_K_M；使用率不高、数据也不敏感的场景，API 往往更省维护成本。 Hy3 展示了大模型压缩已经能做到什么，也把代价一并暴露出来：更低的激活计算量、更小的权重文件、较短的现实上下文，以及尚待验证的复杂任务可靠性。它适合已有硬件的人做实验，还不足以成为单独购买高配 Mac 或 H20 的理由。