27B 模型低比特部署与工具调用实测指南

把 54 GB 的 Qwen3.8-27B 压到 7.9 GB，还能保住工具调用，甚至在 120 道任务上超过完整模型，这是 Underdog Saluki 27B 制作者给出的主张。MarkTechPost 这份教程做的事，是拆开模型文件，再用同一套推理环境检查它的改动、资源占用和工具调用表现。

对想在本地运行 AI 编程助手的开发者，这套验证方法比宣传分数更有用。不过，提供的原文在评测代码处截断，没有最终成绩表。哪些结论已有文件证据，哪些仍待验证，需要分开看。

7.9 GB 的 Saluki，到底改了什么

Saluki 基于 ISTA-DASLab 对 Qwen3.8-27B 做出的 GSQ-RCO 量化。量化就是用更少的位数存权重，以体积和精度之间的取舍，降低部署门槛。

作者比较的是两个具体文件：Saluki 的 Underdog-Saluki-27B-1.0-IQ2-mix.gguf，大小为 7,898,369,152 字节，约 7.90 GB；ISTA 的 Qwen3.8-27B-GSQ-RCO-IQ2_XS.gguf，大小为 8,422,841,472 字节，约 8.42 GB。

GGUF 文件不只有权重，也记录张量名称、形状和存储类型。作者先解析文件头，发现两者都有 851 个张量，名称和形状相同。其中 146 个张量改变了存储类型，而且全部减少了位数。改动主要落在前馈网络的 down projection 和输出层，小型 DeltaNet 门控向量则从 BF16 降到 Q8_0。注意力和 DeltaNet 投影矩阵的类型没有变化。

但存储类型相同，不能证明内容相同。

剩下 705 个类型未变的张量中，作者对 352 个量化矩阵逐字节比较，只有 1 个完全一致；整体上又有 98.4% 的字节相同。这个结果符合「少量修改权重后，再使用相同量化网格编码」的解释，却不能单凭它还原制作过程。

更直接的证据来自未量化的 F32 归一化和门控向量：多数也发生了变化，变化幅度的中位数约为万分之几。

Saluki 的权重确实有改动，不能只把它理解为 ISTA 文件重新分配量化位数。

文件头仍将 ISTA DASLab 列为量化者，但这些检查没有交代后续修改采用了什么训练方法、数据或目标。模型改过，与改得更好，是两件需要分别验证的事。

文件能装下，运行时内存就够吗

这份教程另一个有用的部分，是把模型文件大小与运行内存拆开计算。

按作者读取的元数据，Qwen3.8-27B 共 64 个 block，其中 48 个采用 Gated DeltaNet 线性注意力，另外 16 个保留完整注意力，也就是每四层出现一次。线性注意力层维护固定大小的循环状态，不需要按完整注意力的方式保存全部历史 K、V。

因此，完整注意力部分的 KV cache 每个 token 需要 64 KiB；如果 64 层全部使用完整注意力，则会是 256 KiB。此外，每条序列还需要约 150 MiB 的固定循环状态。

上下文增长仍然会吃内存，只是这里增长得更慢。

作者用原版 llama.cpp 的 llama-server 启动模型，参数包括 -c CTX、-np 1、-ngl 99、-fa on、--jinja、--reasoning-format deepseek 和 -lv 5。其中 -np 1 限制为单槽运行，教程的启动目标是将全部层放到 GPU 上。

这些设置限定了结果的适用范围。单槽运行的占用，不能直接当作多个用户并发时的预算；7.9 GB 文件也不是显存需求的上限，还要加 KV cache、循环状态、计算缓冲区和运行时开销。原文从服务器日志读取这些缓冲区，在 NVIDIA 环境下还用 nvidia-smi 查看 GPU 已用内存。

支持的平台是 Linux NVIDIA GPU，例如 Colab T4，或 Apple Silicon Mac。提供的片段没有给出完整的显存实测表，也没有展示 CTX 的具体取值，因此还不能据此承诺某张显卡能跑多长上下文。

工具调用是否保住，得先把测法固定

作者把推理环境固定在 llama.cpp b11565，对应 2026-10-12 的发布版本和提交 f9a95aeb2。模型使用固定 revision，下载后核对大小和 SHA-256，避免仓库文件替换后，重复实验却得到另一套输入。

BFCL v4 的任务、答案和检查代码则固定在 gorilla 提交 6ea57973c7a6097fd7c5915698c54c17c5b1b6c8。文中称完整 notebook 固定了 14 个 BFCL 文件，包括 5 个任务文件、4 个答案文件和 5 个检查器源码文件。

速度测试也控制了输入长度、输出长度和缓存。下面这段代码分别测输入处理速度，也就是 prefill，以及逐 token 生成速度，也就是 decode：

def speed_probe(tag):
    """Prefill and decode rates from the server's own timings: two prompt lengths, 128 forced output tokens."""
    rng = random.Random(SEED)
    words = "def class return import yield lambda tensor gradient matrix kernel cache token buffer layer".split()
    rows = []
    for target in (256, 1024):
        text = " ".join(rng.choice(words) for _ in range(target))
        ids = api("/tokenize", {"content": text, "add_special": False})["tokens"][:target]
        r = api("/completion", {"prompt": ids, "n_predict": 128, "ignore_eos": True, "cache_prompt": False, **GREEDY})
        t = r["timings"]
        rows.append((t["prompt_n"], t["prompt_per_second"], t["predicted_n"], t["predicted_per_second"]))
        print(f"   {tag:7s} prompt {t['prompt_n']:5d} tok at {t['prompt_per_second']:7.1f} tok/s | "
              f"decode {t['predicted_n']} tok at {t['predicted_per_second']:5.2f} tok/s")
    SPEED[tag] = rows
    return rows

重点看 /completion 请求：n_predict: 128 固定输出长度，ignore_eos: True 避免提前结束，cache_prompt: False 关闭提示词缓存，速度读取服务器返回的 timings。否则，两次请求可能测到不同工作量。

工具调用测试计划使用同一批固定随机种子抽取的 120 道 BFCL 任务，覆盖简单调用、多工具选择、无关请求、并行调用及并行多工具调用，并使用 BFCL 自己的检查器，分别进行严格和宽松解析。

解析口径会影响判断。模型是否选对函数、参数是否正确，以及输出能否被直接解析，需要分别观察。宽松解析可能恢复出可用调用，但生产系统也要具备对应的处理能力。

提供的原文没有展示最终分数，无法确认 Saluki 保住了多少工具调用能力，更无法确认它超过了 54 GB 完整模型。

此外，教程实际并排运行的是 Saluki 和 ISTA 两个量化文件。即使补齐它们的对照成绩，也不能自动完成对完整模型的验证。

我的判断

我认可这份教程先查文件、再测运行、最后评能力的顺序。它把模型名称背后的差异变成了可检查的证据：哪些张量降了精度，哪些权重变了，缓存如何增长，测试是否使用同一批任务。这比只报一个准确率更方便开发者判断是否适合自己的机器。

局限也很明确。制作者的 120 任务成绩属于待核对的宣传主张；作者的文件比较有具体结果，性能和工具调用部分在给定片段里则主要是测试方法，没有足够的结果可供背书。

即使最终 BFCL 成绩不错，也只能支持相应任务范围内的判断。这里没有展示真实仓库修改、多轮工具反馈或工具执行失败后的恢复测试，不能据此认定它已经能胜任日常 AI 编程代理。

与更高位宽量化相比，Saluki 提供了更小的文件，但代价是否可以接受，需要在同硬件、同上下文、同采样配置下比较。原文没有给出这种完整对照，小体积目前是明确优势，准确率和速度优势仍需数据。

能拿来做什么

• 在本地部署前，按权重、KV cache、循环状态和计算缓冲区分别估算内存，并保留上下文长度与并发配置，避免只按 7.9 GB 文件大小选机器。
• 给 Node 工具调用服务做选型时，可以沿用固定模型 revision、推理版本、随机种子和测试集的方式，同时记录直接解析成功率与宽松解析后的成功率。
• 比较本地模型速度时，可以复用 256、1,024 token 输入和强制 128 token 输出的测试方法，关闭提示词缓存，分别报告 prefill 与 decode。
• 判断它能否进入日常 AI 编程流程前，先补齐本文缺失的评测成绩，再加入自己实际使用的函数与参数用例，检查函数选择、参数内容和拒绝无关调用的表现。