一台机器离 770B 模型近了多少？
把一个约 1.5TB 的模型文件塞进本地设备，像把整间档案室搬回书房：模型虽然开放了权重，你能拿到训练完成的参数，却未必有地方放，更别说顺利运行。Hy4-preview 的新进展，就是有人把这间“档案室”压到了约 214GiB。它仍不轻巧，却让部署从纯粹的服务器级项目，向大内存、多显卡设备靠近了一步。
但先把信源说清：目前能确认的是第三方 Hugging Face 命名空间 AngelSlim 发布了两份 GGUF；“腾讯压缩至约200GB并保留约98%性能”只来自一则没有正文的 Reddit 标题，材料中没有官方说明、评测方法或具体指标。
省下来的是什么？
我们此前介绍过，Hy4-preview 共有 770B，也就是 7700 亿个参数。它采用 MoE（混合专家）结构：处理每个 token——模型阅读文字时切分出的基本单位——只激活其中 49B 参数。这样能减少当次计算量，但部署时仍要存放完整专家权重，硬盘和内存压力并不会随激活量一起缩到 49B。
这次的关键是量化：用更少的二进制位记录权重，代价是丢掉一部分数值精度。可以把它理解为压缩照片。像素还在，但每个像素可用的颜色变少，文件随之缩小。
AngelSlim 页面列出两个 GGUF 文件。GGUF 是 llama.cpp 生态常见的本地模型格式，可以把权重和运行所需的元数据装在同一文件里。较稳妥的 Q4_K_M 版本为 435.20GiB，平均每个权重占 4.86 bit；更激进的 STQ1_0 版本为 213.66GiB，平均为 2.38 bit，大约只有前者一半。
这也解释了为什么不能简单称它为“1-bit 模型”。1-bit 量化通常用两个状态表示权重，但实际文件往往混用不同精度。这里的 STQ1_0 只在部分专家层使用约 1.31 bit，其他部分还采用约 2.06 bit及更高精度格式，最终平均位宽是 2.38 bit。
真正改变的是部署边界
压到约 214GiB，不等于普通电脑已经能跑。文件体积也不等于运行时内存占用；模型工作时还需要额外空间。它更现实的受众，是拥有大内存或多卡设备、此前又被约 1.5TB 权重挡在门外的用户。
工具链也还没有完全铺平。仓库说明称，这两个文件都不能直接运行在原版 llama.cpp 上，因为 Hy4-preview 的 hyv4 架构尚未进入上游代码，用户必须应用仓库提供的补丁后自行构建。页面虽列出 llama.cpp、Ollama 等入口，实际可用条件比“一条命令本地运行”更苛刻。
局限与未知
- “约98% performance”没有说明是哪项能力、用什么测试衡量，不能理解为所有能力都保留了98%。
- 现有材料不能证明 AngelSlim 的版本得到 Tencent 官方背书；“官方1-bit”与第三方命名空间、2.38 bit平均位宽也明显不一致。
- 材料没有给出不同硬件上的速度、运行时内存和完整质量评测。现在可以确认的是容量大幅下降，不能确认实际体验只损失很少。