Bonsai 2 27B：在小 9 倍的占用中实现近乎无损压缩

原文 ↗ Hacker News 讨论 ↗

新的 “Bonsai 2” 版本的 Qwen 3.8 27B 语言模型声称在几乎无损准确度的同时，将权重压缩到 5.9 GB 的三元格式，小到可以在 8–16 GB 消费级 GPU、Apple Silicon，甚至网页浏览器中运行。早期用户报告称，它在短任务和显存紧张的配置下吞吐量很亮眼，但在更长的、agentic 的编码任务上结果喜忧参半，常见循环问题，而且真实世界表现弱于基准测试所暗示的水平。讨论的重点大多集中在它与 Unsloth 和 ISTA 等现有量化方案的比较、上下文长度和 VRAM 的实际限制，以及如此激进的压缩是否真的能保留基础模型的能力。

硬件、VRAM 和性能

  • 主要吸引力：27B 的 Qwen 3.8 衍生模型仅约 5.9 GB，使 16 GB GPU 和中端硬件也可用。
  • 用户报告可在以下设备上运行：
    • NVIDIA：3070（8 GB，勉强）、3060（12 GB）、4090、5090、6000 Pro Blackwell、较老的 16 GB 显卡。
    • AMD：6700 XT、7900 XT/XTX；推理可用，但需要 Prism 的 fork、HIP 专用调优，有时还要走更慢的路径。
    • Apple Silicon：M1/M2/M4/M5 设备约为 7–40 tok/s，当前 fork 存在 Metal “tensor API” 问题。
    • WebGPU / 浏览器：可在桌面浏览器中运行；在某些手机上会失败或不稳定（例如 Pixel 9）。
  • 6 GB GPU 可以加载，但速度非常慢（约 0.7 tok/s）。
  • 有效权重大小约为 5.9 GB，但 KV cache 还需要额外 VRAM；8 GB 可能只在短上下文下可行。

设置、工具和兼容性

  • GGUF 需要 Prism 的 llama.cpp fork；上游 llama.cpp 目前还不支持三元格式。
  • 用户分享构建标志、服务器命令以及量化/缓存设置，以避免 OOM 并提升速度。
  • Bonsai 2 目前还没有可用的 drafter/speculative-decoding 模型；Spark/DGX 用户通过 n-gram speculation 获得的收益有限。

质量、“近乎无损”说法与基准测试

  • HF 页面上的基准测试表明其性能接近强力的 4-bit 量化版本，如果属实，部分人觉得“好得离谱”。
  • 多位用户报告：
    • 经常循环，尤其是在 WebGPU 和更长任务中。
    • 相比完整精度的 Qwen 3.8 27B，长程推理、agentic 编码以及记忆文本回忆明显更差。
    • 短篇自由生成输出不错，但作为编码 agent 令人失望。
  • 有些人认为基准测试经过挑选（很少有长上下文或多步任务），因此应对“近乎无损”持怀疑态度。

与其他量化和模型的比较

  • 与 Unsloth 量化（UD-Q4、2–3 bit 变体）、ISTA 的 3-bit Qwen 量化以及其他先进方案（如 AngelSlim）进行比较。
  • 线程中的共识：朴素的 ≤4 bpw 量化会迅速退化，但复杂的 QAT/PTQ（如 Bonsai）可以压到 2 bpw 以下；实现细节是专有或很复杂的。
  • 一些用户现在更偏好其他 3–4 bit GGUF（Unsloth、ISTA）的质量，而在 VRAM 成为瓶颈时才使用 Bonsai。

用例、局限与未来方向

  • 大家对以下方向兴趣强烈：
    • 基于 Qwen 3.8 的、适合手机的 8B 级 Bonsai。
    • 非常大的压缩模型（100B+ 或 Flash/Next 变体），也许能塞进高端消费级 VRAM。
  • 多个报告指出，在真实的“agentic”编码任务中，模型会卡住、循环，或无法决定方案，而云端前沿模型能可靠完成相同任务。

语言与指标讨论

  • 对“9x smaller”这类说法进行了长篇旁支争论：
    • 一些人认为它在数学上没有意义；另一些人则把它当作广为理解的习惯说法，表示“大小为 1/9”。
    • 关于“N× faster”以及 mWh/token 之类单位选择，也出现了类似争论。