把 27B 级模型压到 2-bit 还能不能可靠地调用工具？MarkTechPost 这篇实操指南给出的观察角度，比结论本身更值得关注。
发生了什么
MarkTechPost 发布了一篇面向开发者的编码指南，主题是如何在原生 llama.cpp 环境中运行 Underdog Saluki 27B——一个基于 Qwen 系 27B 的模型，并把它与 ISTA 提出的 GSQ-RCO 量化方法放在一起比较。文章覆盖三个层面：GGUF 文件头部信息的检查、实际内存占用，以及在 BFCL（Berkeley Function Calling Leaderboard）上的工具调用表现。换句话说，它不是一篇单纯的"跑起来"教程，而是试图回答"2-bit 量化之后，模型的功能性能力还剩多少"。
为什么重要
量化社区长期存在一个默认预期：4-bit 基本无损，3-bit 开始明显退化，2-bit 通常被视为"能说话但干不了活"。工具调用恰恰是对精度最敏感的任务之一——模型需要输出结构严格合法的 JSON、选对函数名、填对参数，任何格式漂移都会让下游 agent 直接失败。因此"2-bit 能否支撑 tool-calling"是一个有实际分量的边界问题。
另一方面，GSQ-RCO 这类方法的出现说明量化研究正从"统一位宽"转向"按层、按通道分配精度"。这类方案的价值不在于把模型压得更小，而在于把有限的比特预算花在对输出正确性影响最大的权重上。Saluki 这类社区微调模型与专用量化方法组合，也反映出开源生态里"基座—微调—量化"三段式流水线正变得越来越分工明确。
影响与看点
对开发者而言，最直接的意义是本地部署的成本曲线可能继续下移：如果 27B 级模型在 2-bit 下仍能维持可用的函数调用能力，那么消费级显存甚至统一内存设备上运行 agent 后端就有了新的选项。但需要注意几点：
- BFCL 分数只是单一维度，真实业务中的多轮工具编排、错误恢复、长上下文下的参数一致性，未必能被榜单反映。
- GGUF 头部与内存数据是可复现的硬信息，而"表现如何"高度依赖 llama.cpp 的具体版本与推理后端，跨版本结论不能直接搬运。
- 2-bit 量化的收益是显存，代价往往是鲁棒性；在生产环境里，它更适合做草稿模型、路由层或低风险子任务，而非直接替换主模型。
一个独立判断：2-bit 工具调用的真正门槛不在"能不能跑通一次"，而在"失败率是否可预测"。如果量化带来的错误是随机且不可检测的，工程上就难以兜底；如果错误集中在特定函数或参数类型上，反而可以通过约束解码和 schema 校验来弥补。这篇指南的价值，正在于它把讨论从"跑分"推向"可运维性"。
