Saluki 27B：把工具调用保住，还把 27B 塞进 8GB，这事值得细看

2026年10月14日

把 27B 压进 8GB，还保住函数调用

最近 HF 上架了一个挺有讨论度的模型，ConwayResearch 出的 Underdog Saluki 27B 1.0。光看名字可能没反应，但卖点很直白：一个基于 Qwen3.8-27B 的 GGUF，体积压到 7.89GB，比原版 54GB 小了近 7 倍，而且主打「保住工具调用能力」。翻译成人话就是：一张普通消费级显卡、甚至纯 CPU 都能跑得动的模型，还带函数调用，不用为了体积把 Agent 最关键的那条链路砍掉。

这事的重点在于「能压到什么程度、代价是什么」。Saluki 把 27B 参数压到 IQ2 混合量化，跑在 stock llama.cpp 上，官方在 Underdog Bench（从 Berkeley Function Calling Leaderboard 冻结的 120 个任务）上测出 88 分，对比全尺寸 Qwen3.8-27B 自己跑的 84 分。并行工具调用 100 个 BFCL 任务里 Saluki 42、全尺寸 35。也就是说在工具调用这件事上，压缩后的反而略高于原版，平均 retention 号称 96%（跨 9 个 benchmark）。

这里说两句冷水。第一，这些分是 Underdog 官方自己的 harness 跑的，他们自己也写明了：全尺寸那些公开分数来自另一套 harness，不能直接等值比较，120 个任务本身也是 modest test，几个任务的差距属于 run-to-run 波动。第二，除了工具调用，别的维度确实在缩水：SWE-bench Verified 从 33 掉到 30，AIME 2025 从 96.7 掉到 79.2，AIME 2026 从 94.6 掉到 80.0，MBPP+ 从 83.9 掉到 78.0。官方也坦率承认，竞争数学大概只剩全尺寸的 82-85%，最弱的是字母级指令谜题（回文、元音规则、字母顺序这类）。所以别把它当成「无损小钢炮」，准确的定位是：在本地能跑的前提下，工具调用这条链路的保留度最高，推理和数学是要让位的。

真正打动我的地方是它把「跑起来」这件事做得足够顺手。模型自带 Qwen3.8 的 chat template，--jinja 打开就能处理工具调用和 thinking，thinking 默认开、可按请求关，跟原版一致。服务端直接吐 OpenAI chat API 在 8080 端口，意味着现有的 OpenAI 客户端、很多 Agent 框架能无痛切换。上手命令就两行：huggingface-cli download 拉权重，llama-server 起来，加 --ngl 99 -fa on -c 32768。要图像的话，主文件本身是纯文本，得另外下载 vision 插件（F16 928MB 或 Q8_0 629MB），再用 --mmproj 传进去，走 OpenAI chat API 发图即可。

这种「按需加 vision」的设计我觉得挺实在。很多人本地跑模型，图其实不常用，硬塞一个大视觉塔反而白占显存。它把文本主模型和视觉插件拆开，用不上就不背这个负担，这是实用主义者会做的取舍，不是秀肌肉的做法。

几个使用细节可以记住：想又快又直接地做工具调用，官方建议 thinking 关掉、temperature 0，配合 "chat_template_kwargs": {"enable_thinking": false}；日常推理那就默认 thinking 开、temperature 0.6、top_p 0.95。另外限制里写明了，并行调用的回复里大概有五分之一会有小的格式瑕疵，thinking 开着时它会经常长篇推理再回答。这些都不是「瑕不掩瑜」的空话，是真跑 Agent 时会踩到的实坑。

最后说下生态位置。它在模型树里是基于 Qwen3.8-27B 和 ISTA-DASLab 的 GSQ-RCO GGUF 再做的，Apache 2.0 协议，底子是 Qwen 团队的，压缩工作是 Underdog 做的。截至页面数据，这个模型最近一个月下载量 269829，一个月近 27 万的下载，说明「本地能跑 + 工具调用保住」这个需求点是真实存在的，不是厂商自嗨。

我的看法是这样的：如果手上有一张 8-12GB 显存的卡，想本地跑一个能接函数调用、跟现有 OpenAI 客户端无缝对接的模型，Saluki 27B 是这周值得下下来试试的一个选择。但如果主要要的是强推理、竞赛数学，就别被「27B 压进 8GB」这个标题带着走，那种负载还是老老实实上全尺寸或者云端。工具调用保住，不等于样样都保住，这就是压缩模型的定价逻辑——得知道自己愿意为哪一项能力付体积的代价。

相关链接