我的 Mac 是 16GB 统一内存。跑 Qwen3.6-35B-A3B 这件事，之前靠 llama.cpp 的 mmap trick 勉强能行——模型文件 20GB 左右，系统只把活跃专家页进内存，平时看着内存占用不高，但上下文一长或者多开几个应用，该swap的还是swap，风扇该转的还是转。
前几天刷到 TurboQuant-MLX 的一个实验性构建，直接把 35B 模型从 70GB 压到了 9.4GB。用的不是常规的 Q4，而是1.58bit 三值量化——每个权重只存三种值：-c、0、+c。这个压缩率听起来像魔法，但我仔细看了模型卡和实测数据，觉得有必要拿出来聊聊。
先放结论：它能跑，而且能完整驻留在 16GB 内存里，不用 swap，不用外接 SSD 流式加载。但别指望它替代你现有的主力方案。
为什么 1.58bit 没变成乱码
按常识，把权重压到 1.58bit，模型输出应该直接崩溃成胡言乱语。但这个构建没崩，核心原因在于三点：
第一，它只压专家层。Qwen3.6-35B-A3B 是 MoE 架构，256 个路由专家，每 token 只激活 8 个。专家层参数量最大，但单个专家只处理一小部分 token，冗余度极高。注意力层、GDN 投影矩阵、lm_head 这些被每个 token 都走一遍的”关键路径”，保留在 3-bit。路由器选专家的 gate 甚至保持全精度——选错专家的代价是不可恢复的。
第二，MoE 的冗余抵消了量化噪声。8/256 的激活比例意味着，即使单个专家被压得比较狠，模型可以通过”换一批专家”来平均掉误差。模型卡里的原话是：top-8 of 256 的冗余度，是 32-expert 模型的 8 倍——后者在 sub-2-bit 下 demonstrably fails。
第三，三值比二值好。纯 1-bit（只有 -c 和 +c）的专家层我试过其他模型，输出基本是词沙拉。加入 0 之后，1.58bit 的重建质量落在了约 2-bit 的水平。用 base-3 编码把 20 个三值索引塞进一个 32-bit 整数，实际位宽约 1.6 bpw，这才把总大小拉到了 10GB 以内。
实测数据：能跑，但不够快
模型卡里的数据是在 16GB Mac mini 上测的：
- 解码速度：约 10.4 tok/s（平坦，512 token 和 1800 token 回答速度一致）
- 内存峰值：10.42 GB，不随上下文增长（30 层 GatedDeltaNet 用固定大小的循环状态，只有 10 层 full-attention 的 KV 会膨胀）
- 不需要 sudo 调 wired_limit，默认 Metal 内存上限就能跑
作为对比，我目前在 llama.cpp 上跑 Q4_K_M 的 35B，decode 大概 17 tok/s。TurboQuant 这个 1.58bit 构建慢了将近一半，但换来了完整驻留内存——没有 mmap 的磁盘抖动，没有专家换入换出的延迟尖峰。
质量方面，MMLU-Redux 思考模式下 80.1%，原版 93.3%。大约是原版的 86%。非思考模式 75.2%。日常聊天、写代码、总结文档，这个水平够用。但 GSM8K 数学 benchmark 只有 67%，说明算术精确度是明显短板。
最致命的坑：agent 工具循环直接不可用
模型卡里有一段话让我印象深刻，而且是被实测验证过的，不是推测：
“Tool-call syntax works… but tool-use judgment does not survive 1.58-bit.”
具体测试是：用 Opencode 跑”修复失败测试”任务，1.58bit 构建 4/4 次失败——要么重复执行同一个错误命令几百次，要么凭空捏造文件路径和 URL。而同一个 server + harness + prompt 下，3-bit 的 sibling 构建 33 秒就搞定了。
这不是采样参数没调对，而是信息地板的问题。三值专家层保留的语义精度，不足以支撑多步 observe → diagnose → edit 的规划循环。
所以模型卡的建议很明确：这个构建适合 chat、drafting、summarization、Q&A、一次性代码生成。不要接进 coding agent。
我的用法
我目前的计划是：llama.cpp Q4 继续当主力，处理需要工具调用和长上下文推理的任务。TurboQuant 的 1.58bit 构建装一个备用，专门用来跑不需要思考模式的快问快答——查资料、改文案、简单脚本。10 tok/s 不算快，但比等云端 API 的冷启动快，而且完全不占 swap。
安装倒是简单，两条命令：
pip install "turboquant-mlx-full>=0.12.3" mlx-lm
python -m turboquant_mlx.generate
--model manjunathshiva/Qwen3.6-35B-A3B-tq3a-tqTe-g64
--prompt "你的问题" --max-tokens 512 --no-think加上 --no-think 之后响应快很多，数学和严格格式任务也更稳。需要思考模式的时候，给够 4K+ 的 token 预算，不然容易在 <think> 里绕圈出不来。
这背后的趋势
1.58bit 不是 TurboQuant 一家的玩法。antirez 的 ds4 给 DeepSeek V4 Flash 做了非对称 2/8-bit 量化，MoE 专家层压到 2-bit，注意力层保持 8-bit。思路完全一致：该狠压的地方狠压，不该压的地方寸步不让。
这种”分层量化”比一刀切的 Q4 高级太多，而且会越来越主流。因为本地推理的瓶颈从来不是”能不能跑”，而是在有限的内存预算里，把精度分配到最需要它的地方。
对 16GB Mac 用户来说，1.58bit 三值量化意味着 35B 级别的模型终于可以从”勉强能跑”变成”常驻可用”。虽然速度和精度都有妥协，但这妥协是有明确边界的——你知道它擅长什么、不擅长什么，然后按需调用。
这比盲目追求”一个模型干所有事”务实多了。
