据 MarkTechPost 十月九日报道，Conway Research 旗下的 OnDevice 助手项目发布了 Saluki 27B，一个基于 Qwen3.8-27B 的 2-bit GGUF 量化版本，文件体积仅 7.89GB，采用 Apache 2.0 协议开源。最反直觉的是，这个极度压缩的版本在工具调用基准上的表现居然超过了原始 Qwen3.8-27B。
原因在于 Saluki 不是简单的权重量化，而是在 2-bit 压缩的同时做了针对工具调用场景的后训练微调。它用了 NSA 稀疏注意力和 PRISM 蒸馏技术，把模型容量集中保留在函数调用的结构化输出能力上，牺牲了部分通用对话质量，但换来了在端侧设备上的可用延迟。
部署门槛很低：一张 8GB 显存的消费级显卡就能跑，或者用 16GB 统一内存的 Mac 通过 llama.cpp 加载。适合做本地路由模型——当用户请求是简单工具调用时走 Saluki，复杂推理才调云端大模型。
从本地部署的实际体验来看，2-bit 量化的模型在生成速度上确实有明显优势——因为权重体积小，从内存加载到计算单元的时间更短。在一台普通笔记本上跑，每秒生成的 token 数跟 4-bit 版本差不多，但内存占用小了将近一半。这对于内存紧张的轻薄本来说很关键。
不过要注意，官方公布的工具调用反超原版的数据，是在特定基准测试集上的结果。实际业务场景中的工具调用往往涉及更复杂的上下文和更多的工具选项，建议你在自己的任务集上跑一遍对比。如果只是简单的两三个工具调用，Saluki 可能确实够用；如果涉及长链路的多步工具编排，还是建议用更大的模型。
2-bit 量化为什么还能保住工具调用能力？
2-bit 量化的传统认知是精度损失太大，模型基本不可用。但 Saluki 的案例说明：当你明确知道模型只需要做好工具调用这一件事时，可以针对性地压缩其他能力，把有限的位宽预算留给函数输出的结构化字段。这跟通用模型的全场景压缩思路完全不同。
本地部署要多少显存和内存？
实际部署时建议跟原版 Qwen3.8-27B 的 4-bit 量化版本做同任务对比测试。虽然官方说工具调用反超原版，但在长上下文和复杂推理场景下，原版肯定还是更强。把 Saluki 用在它擅长的地方才是正解。
去论坛讨论
前往 silicon-agi.com 论坛 参与讨论