把 27B 塞进 16GB 显卡：OrcaSAQ2 用 3-bit 压出 12.3GB，还盯着 agent 场景做测评

2026年10月1日

OrcaRouter 在 Hugging Face 上挂出了一个叫 OrcaSAQ2 27B 的模型，本质是把 Qwen3.8-27B 从 54 GB 的 BF16 checkpoint 压缩到 12.3 GB。这个数字落在 16 GB 显卡的可用范围内，单卡能直接 serving。压缩率是 77.2%，也就是说存储占用只有原来的 22.8%，约等于 4.4 倍缩小。

如果只是做量化，这类发布已经不算新鲜。OrcaSAQ2 有意思的地方在于两点：一是它用的不是普通的低 bit 均匀量化，而是自家一套「sensitivity-aware mixed-precision」系统，按照不同层对精度的敏感度去分配 bit，输出端的平均 decoder 精度是 3.21 bpw；二是它在模型卡的评测哲学上明显往 long-horizon agent 场景靠，强调的不只是 PPL 有没有涨，而是「模型跑完一串决策之后还能不能把活干完」。

从给出的数字看，压缩带来的失真被压得很紧。WikiText-2 上 BF16 的 PPL 是 5.6468，压缩后是 5.6482，delta 只有 +0.02%；token 级别的 Top-1 一致率 93.2%，mean KLD 0.031。这些数字都是基于这批权重对着 BF16 参考模型跑同一套评测路径出来的，至少口径是自洽的。当然模型卡自己也承认，量化不是数学意义上的无损，93.2% 的一致率意味着有一部分 token 决策和 BF16 不一样，PPL 的微小增量也不等于下游表现完全一致。

真正让这个模型值得多看一眼的，是它把 benchmark 放到了 agent 场景里。SWE-bench Verified 上它报了 70.0%，旁边列了 Claude Sonnet 4.6 的 79.6、Sonnet 4.5 的 77.2、Gemini 3 的 76.2，以及 Qwen3-Coder-480B-A35B 的 69.6。Terminal-Bench 2.1 上它报 58.4%，对应的 Claude Sonnet 4.6 / Claude Code 是 58.5%。模型卡在表格下面加了很重的免责声明，说 agent benchmark 严重依赖 scaffold、工具、推理预算、超时和执行环境，这些分数只是 public reference points，不是严格同口径的对比。这个提醒值得当真——在 12.3 GB 的模型上做出接近 70 的 SWE-bench，确实不是靠单卡小模型就能随便碰到的量级，但这些数字背后的 harness 差异有多大，目前没有公开的对照细节，别直接当成「单模型排名」来读。

架构上它继承的是 Qwen3.8-27B，64 层、hidden size 5120，混合注意力是 48 层 Gated DeltaNet 加上 16 层 full attention，最大上下文 262,144 token，支持 thinking mode、tool calling、MTP speculative decoding，通过 vLLM serving，Apache-2.0 协议，不含视觉 tower。也就是说它是个纯文本模型，别指望拿去跑多模态。

部署上的数字是它和普通 7B 量化模型拉开差距的地方。官方给的 serving 数据是在 15.7 GiB 的 GPU 内存上限下测的：vLLM、MTP 关，单流 65.3 tok/s、8 流 332 tok/s、16 流 333 tok/s；MTP 开，单流能到 90.1 tok/s，比关掉状态 +38%，但多流吞吐反而降到 220/219 tok/s。理由也写清楚了，MTP 用额外算力和 KV 容量换单流交互解码的流畅度，适合 coding assistant、交互式 agent、low-concurrency 这类场景；batch 打得高的负载，MTP 开不开需要自己实测。12.3 GB 的权重放进 16 GB 卡，留给 vLLM 开销、KV cache、MTP、batch、CUDA graph 的空间大约还有 3.7 GB，官方给的一个实用起点是约 32K 交互上下文，再按负载去调。

整个模型卡的调性很「agent 本位」。它反复强调一句话：短 benchmark 可以藏住小的退化，但 agent 藏不住。因为一个小错误会改变一次 tool call，tool call 改变环境状态，状态又影响后面每一次决策，长轨迹里误差会累积成行为上的大差异。这个观察本身是对的，也是它把 long-horizon 当作核心测试场景的原因。实际能不能兑现，还是得看你在自己的工具 schema、上下文分布和推理预算底下跑出来的结果，模型卡最后也承认「Maximum architectural context 不代表完整上下文要塞进每一张显卡都装得下」。

方法部分它并没有公开太多。OrcaSAQ2 用的是自家 sensitivity-aware 混合精度量化，但校准策略、精度分配和 packing 细节都没有披露。换句话说，你想复现这套压缩，手头材料不够；你想直接用，装上 OrcaSAQ2 的 vLLM 集成就能跑，quickstart 里给了 hf download 加 vllm serve 的命令，也给了 OpenAI-compatible 的调用样例。安装上它需要先 pip 装 vllm、huggingface_hub 和 git+https://github.com/Continuum-AI-Corp/OrcaSAQ2-kernel 这个内核包——注意这个仓库的代码是否完备、维护状态如何，目前没有公开资料能确认，动手前自己掂量一下。

对做单卡部署、跑 coding / terminal / browser agent、或者想在受内存约束的硬件上保留一个 27B 级别推理能力的人来说，OrcaSAQ2 把「27B 塞进 16GB 卡」这个组合变成了实际可跑的东西，这是它真正的价值。至于 93.2% 的一致率够不够、70 的 SWE-bench 在同 harness 下能重现多少，得等你自己在 vLLM 里起一个服务、喂一批真实任务才有个准数。