腾讯混元把295B塞进单卡：Hy3发布1bit/4bit量化版，本地能跑了

7月14日，腾讯混元团队在官方渠道扔出了一枚不算大但相当解渴的更新：Hy3 的 1bit 和 4bit 量化版本正式上线，权重打包成 GGUF 格式，对接 llama.cpp 生态。翻译成开发者听得懂的话——那个 295B 参数、原本得靠多卡服务器才能伺候的旗舰模型，现在一张 96GB 的推理卡、甚至一台内存够大的本地机器，就能把它跑起来。

这事儿从 7 月 6 日 Hy3 正式版发布之后就一直被社区催。原因很直接：BF16 权重接近 600 GB 的模型，对绝大多数个人开发者和中小团队来说，看得见摸不着。

先说数字：从 598GB 到 85.5GiB

这次量化一共放出了三个版本，分工非常清楚：

• IQ1_M（1bit 极限量化版）：85.5 GiB，比 BF16 缩了 6.7 倍。一张 96GB 的推理卡就能塞下。定位是「硬件最受限但还想在本地跑旗舰」的场景。
• Q4_K_M（4bit 量化版）：169.9 GiB，两张推理卡承载。目标是「用有限资源逼近满血效果」。
• GPTQ Int4 版本：直接对接 vLLM 部署，天然吃到 vLLM 生态在高并发、低延迟上的红利，更贴服务端需求。

把 6.7 倍的压缩率放在 295B 这个尺度上看，含义是不一样的。同样是 4bit 量化，压一个 70B 模型和压一个 295B 模型，工程价值差着一个数量级——前者只是让消费级显卡更舒服，后者是把「旗舰级智能」从数据中心搬下来。这才是这次更新真正在意的事。

1bit 没变笨，这是意外

通常你听到「1bit 量化」，第一反应是「能跑，但估计废了」。这也是社区对极限量化长期的心理预期——参数压得越狠，能力塌得越明显，最后跑出来的东西勉强算个演示。

混元这次的说法是，他们自己也有点意外。Hy3 1bit 版本在主流任务上「站得住」：长文理解几乎和原始模型持平，Agent 与代码方向只有小幅回落。

为什么能站住？这跟 Hy3 本身的架构脱不开关系。Hy3 是 MoE，总参 295B、激活 21B，MTP 层 3.8B。MoE 模型的参数分布本来就稀疏，专家网络之间的信息冗余度比 Dense 模型高，量化时能被「吸收」的误差空间更大。换句话说，同样压到 1bit，MoE 的容错性天然比 Dense 好。这不是新观点，但 Hy3 这次是把这套逻辑真正跑通了、拿数据说话了。

4bit 版本更不用多说。判断量化好不好，最直接的指标是输出分布跟原始模型的贴合度——Q4_K_M 在绝大多数位置上给出的首选答案和 Top-K 概率分布都和 BF16 保持一致。落到具体任务，Agent、多语言代码、工具调用、长文理解，成绩都贴近满血。GPTQ Int4 在评测集上的掉点也非常有限。

对开发者来说，选型逻辑其实很简单：

• 一张卡预算，只想在本地把旗舰跑起来验证想法 → 1bit
• 两张卡预算，希望接近满血效果 → 4bit
• 有服务端部署需求，追求并发和延迟 → GPTQ Int4 + vLLM

部署这件事，llama.cpp 生态终于配得上旗舰模型了

把权重打包成 GGUF，走的是 llama.cpp 这条路。这条路线过去一直被贴着「消费级」「玩票」的标签——大家用它跑 7B、13B、70B，玩得挺开心，但真到旗舰级别，主流部署方案还是 vLLM、SGLang 这些。

混元这次把 Hy3 直接送进 GGUF 生态，等于把 llama.cpp 的可玩性上限往上抬了一个身位。这背后其实是一个正在发生的转变：本地推理不再等于「小模型玩具」，它开始能承载严肃的生产力任务。一台内存够大的工作站、一张 96GB 的推理卡，就足以跑起一个能对标闭源旗舰的模型——两年前，这个场景还只存在于 PPT 里。

当然，1bit 版本对硬件的要求还是有的。85.5 GiB 意味着你要么有单张 H100 80GB 之外的高显存卡（比如 A100 80GB 加内存卸载、H200，或者国产卡里显存宽裕的方案），要么走 CPU + 大内存路线，牺牲速度换可行性。这不是「每个人的 MacBook 都能跑」，但对企业内部实验、私有部署、离线场景，门槛已经低到可以谈落地了。

Hy3 本身：混元这半年做了什么

如果只看量化这件事，可能会忽略更重要的背景——Hy3 本身是腾讯混元这半年打法的一个总结。

时间线捋一下：

• 2026年1月底：混元重建预训练和强化学习基础设施
• 4月23日：Hy3 preview 发布，混元重建后第一个版本
• 7月6日：Hy3 正式版发布，接入 WorkBuddy、CodeBuddy、元宝、ima、Marvis 等业务
• 7月14日：1bit / 4bit / GPTQ Int4 量化版本发布

从底层重建到产品反哺，不到半年跑通了一整个链路。这个节奏放在国内大模型厂商里，算是相当克制且高效的——没有月更、没有版本号乱飞，就是一步一步往前推。

Hy3 的架构定位也很清楚：MoE，总参 295B、激活 21B，支持 256K 上下文，快慢思考融合。21B 激活参数意味着单 Token 推理成本显著低于 Dense 架构的同等性能模型，这对腾讯 C 端海量调用场景是刚需。

从公开的评测和业务数据看，Hy3 preview 上线后日均 token 消耗增长了 20 倍，WorkBuddy 上自主选择 Hy3 preview 的用户数增长了 6 倍。这些数字比跑分更能说明问题——真正被业务用起来的模型，才有资格谈「实用性」。

Hy3 在 CodeBuddy 和 WorkBuddy 上首字延迟（TTFT）降低了 54%，端到端响应时间缩短 47%，成功率超过 99.99%。它已经验证能稳定支撑长达 495 步的复杂智能体工作流，覆盖文档处理、数据分析、知识检索、MCP 工具链编排。姚顺雨在 preview 发布时提到「模型与推理设计融合」，现在回头看，这套思路是贯穿到底的——从模型架构到推理框架到量化方案，都在为「同样成本下拿到更高智能密度」服务。

开源协议这一条，值得单独说

Hy3 用的是 Apache 2.0。这是商业友好度最高的开源协议之一，允许自由商用、修改、分发，唯一的义务是保留原始版权声明。

对比一下国内其他家：不少模型开源协议里加了商用限制条款，或者对超过一定用户量的场景要求额外授权。混元这次直接给了 Apache 2.0，态度很清楚——就是希望开发者拿去用、拿去改、拿去做产品。

这也解释了为什么这次量化版本发布这么被期待。你把商业协议放开，把模型能力做到旗舰水准，但如果部署门槛还是「多卡集群」，那开源的意义就打折了。量化版本补上的是最后一公里——协议、能力、可部署性，三个条件同时成立，模型才算真正「开源」了。

生态与调用

本地部署之外，Hy3 的 API 渠道也已经铺开：腾讯云 TokenHub 有官方 API，海外覆盖 OpenRouter、Hermes、Kilo、Cline、OpenCode、Cherry Studio 等平台。开源权重同步上了 Hugging Face、ModelScope、GitCode、CNB。

对国内开发者来说，如果不想折腾本地部署，也不想为了对比几个模型分别注册一堆平台账号，OpenAI Hub 目前已经支持 Hy3 及主流开源、闭源模型的统一调用，一个 Key、兼容 OpenAI 格式，国内直连——适合做多模型对比测试、或者已经在用 GPT/Claude 的项目里平滑接入 Hy3。

一点判断

单卡跑 295B，听上去像个宣传口号，但拆开看确实是把好几件事同时做对了：MoE 架构本身对量化友好、极限量化算法这两年迭代到位、GGUF 生态成熟、Apache 2.0 协议放开。任何一环缺位，这件事都做不成。

更值得注意的是节奏。国内大模型这两年，动辄「刷榜第一」「对标 GPT-4」，但真正让开发者「今天就能拿去用」的动作反而不多。混元这次的量化版本，没有炫技，也没有对标谁，就是把社区呼吁最强烈的一个需求解决掉——「让旗舰模型跑得起来」。

从工程审美上讲，这比又发一个跑分领先的新模型更让人尊重。

下一步值得看的是：Hy3 在真实生产环境里的稳定性、1bit 版本在更多长尾任务上的极端表现，以及混元后续会不会把这套量化路径开源化、工具化——如果能，那对整个开源社区来说，等于多了一条「把旗舰模型送到本地」的标准范式。

参考来源

• 腾讯混元发布 1bit 与 4bit 量化版 Hy3 模型，旗舰 AI 模型可单卡本地运行 - IT之家 — 本次量化版发布的一手消息与技术细节
• Hy3/README_CN.md · Tencent-Hunyuan/Hy3 - GitHub — Hy3 官方开源仓库，包含模型架构、部署指南、推荐参数
• Hy3 模型 - Hugging Face — 腾讯混元在 Hugging Face 上的模型权重下载页