企业官网建设流程全解析

7.89GB 文件不等于 8GB 显存能跑：Saluki 27B 部署前没人告诉你的内存真相

【免费下载链接】Underdog-Saluki-27B-1.0项目地址: https://ai.gitcode.com/hf_mirrors/ConwayResearch/Underdog-Saluki-27B-1.0

Underdog-Saluki-27B-1.0 发布后，"7.89 GB 跑 27B" 这个数字被反复传播：2-bit IQ2-mix 量化、工具调用 88/120 反超 54 GB 全尺寸原模型、官方自称"Runs on 16 GB laptop"。于是不少人的第一反应是——文件 7.89 GB，那我 8 GB 显存的显卡是不是也能塞下？

答案是否定的。7.89 GB 是权重文件的大小，不是运行时内存的账单。一个 GGUF 文件落地到推理进程里，要额外承担上下文 KV cache、计算缓冲区、可选视觉模块和并发请求的叠加开销。本文不吹不黑，只算账：先拆清楚 7.89 GB 这个数字到底由什么构成，再把"文件大小"与"显存/内存需求"之间的每一笔差额摊开，最后给出不同硬件配置下的真实可运行窗口。

7.89 GB 是怎么算出来的：GGUF 只含权重

先纠正一个更隐蔽的坑：仓库里那个 Underdog-Saluki-27B-1.0-IQ2-mix.gguf 的 LFS 指针文件里写得很清楚，实际字节数是7898369152。按厂商习惯的十进制换算（除以 1000³）是 7.898 GB，所以对外宣传 7.89 GB；但按操作系统和文件管理器的二进制换算（除以 1024³），它只有7.36 GiB。如果你用du或资源监视器看到的"7.4 GB"去对官方宣传数字，会产生第一层困惑——这不是模型有问题，而是两套计数体系。

其次，这个文件里装的是纯权重。Saluki 是基于 Qwen3.8-27B 的 2-bit 量化调优版，由 NOTICE 可知它构建在 ISTA-DASLab 的Qwen3.8-27B-GSQ-RCO-IQ2_XS.gguf之上，原模型是约 54 GB 的 BF16 全尺寸版本。GGUF 的职责就是压缩权重本身：把大部分参数压到平均 2 bit（IQ2-mix 是混合量化，不同张量用不同精度的 2-bit 变体），换来 1/7 的体积。而推理引擎要运行，除了权重还需要其他几样东西，它们不在文件里，却在进程的地址空间里占着实打实的字节。

上下文、并行工具调用和 mmproj 的额外内存账

KV cache：随上下文与并发数膨胀

llama.cpp 推理时，每个 token 的注意力键值（K/V）都要缓存在内存里，这就是 KV cache。它的理论大小是：

KV cache = 2 × 层数 × KV 头数 × 头维度 × 上下文长度 × 每个元素字节数

官方推荐的启动命令直接拉满 32K 上下文（README.md 的 Quickstart）：

llama-server -m Underdog-Saluki-27B-1.0-IQ2-mix.gguf --jinja -ngl 99 -fa on -c 32768

以 27B 级模型、GQA 架构的常见配置粗略估算，F16 精度的 KV cache 在 32K 上下文下会达到数个 GiB 的量级；如果把 KV cache 也量化（如 Q8_0），可以再省约一半。更要命的是它是按"上下文长度 × 并发请求数"线性扩张的：llama-server每多一个并发请求，就多一份独立的 KV cache。你看到的 7.89 GB 权重是固定项，KV cache 才是随负载浮动的大头。

thinking 模式：生成变长，峰值内存更高

Saluki 默认开启 thinking（与 Qwen3.8 一致，可逐请求切换）。README.md 的 Limitations 明确承认：thinking 开启时模型"often reasons at length before answering"。推理 token 越长，KV cache 峰值越高、总生成时间越长——这对内存账是双重打击。所以官方给工具调用场景的黄金组合是 thinking 关闭 + temperature 0：

# 通过 OpenAI 兼容 API 下发 { "chat_template_kwargs": { "enable_thinking": false } }

工具调用基准（120 题得 88 分、并行调用 42 分）正是在"thinking 关闭 + temperature 0"条件下测得的。而并行工具调用意味着单次回复要一次性输出多个 tool call，输出序列显著加长——这也是为什么"普通对话勉强能跑"的机器，一上并行 agent 场景就 OOM。

mmproj：视觉能力是外挂，不是默认

主文件是纯文本模型。要看图，得再挂一个视觉投影模块：

启动时用--mmproj挂载：

llama-server -m Underdog-Saluki-27B-1.0-IQ2-mix.gguf --mmproj mmproj-Underdog-Saluki-27B-1.0-Q8_0.gguf --jinja -ngl 99 -fa on -c 32768

也就是说，"带视觉的 7.89 GB"实际是7.89 GB + 0.63~0.93 GB，而且 mmproj 加载后同样常驻显存/内存。除此之外，还有一层容易被忽略的计算缓冲区（compute buffer）：FFN、attention 的前向计算临时张量虽小，但 2-bit 反量化到中间精度时也会瞬时占掉几百 MB 到 1 GB，-b和-ub参数可以限制它，代价是性能。

不同硬件配置下的真实可运行窗口

把账算全，结论就清晰了。8 GB 显存的独显（如 RTX 4070 Laptop / 4060 8GB）装不下完整运行态：仅权重就有 7.36 GiB，再加上 KV cache 和缓冲区，必然超限。这并不意外——官方主站对硬件门槛的表述从来不是"8 GB 显存"，而是"Runs on 16 GB laptop"，即 16 GB 统一内存/内存的整机。

分场景给出真实窗口：

场景一：16 GB 统一内存的 Mac / 核显本（官方宣称的目标机器）权重 7.36 GiB + 32K F16 KV cache（数个 GiB）+ 系统开销，整机 16 GB 可以跑，但属于"贴着天花板"：建议-fa on开启 Flash Attention、-c按需下调到 8K~16K，视觉模块选 Q8_0 版本。这也是它面向"本地 agent 跑在已有设备上"定位的底气——不需要买 54 GB 版才能用的企业级显存。

场景二：8 GB 显存独显（最容易被 7.89 GB 误导的配置）权重全量进显存就占掉 7.36 GiB，KV cache 没有容身之地。唯一可行路径是部分卸载：把-ngl降到 20~30，让一部分层驻留在系统 RAM（注意这时系统内存至少要 16 GB+），显存只做计算主力。换来的是每次跨层都要走 PCIe，延迟明显上升——能跑，但别期待"8 GB 显存跑满血 Saluki"。

场景三：纯 CPU / 大内存服务器（32 GB+ RAM，无独显）-ngl 0全 CPU 推理可行，llama.cpp 对 2-bit 权重的 CPU 支持完整；32 GB 内存可以同时开 32K 上下文和并发请求。此时瓶颈从内存变成速度，建议--mlock锁页防换出，配合-t调满核心。官方 SWE-bench 30/50、IFEval 93.5 的成绩正是在标准 llama.cpp 上跑出来的，说明它不挑运行时，但物理内存的账要先算清。

一句话总结这份内存真相：文件体积是"购买价格"，运行内存是"持有成本"。7.89 GB 的 GGUF 只代表你省下了 46 GB 的下载和存储开销；真要跑起来，16 GB 整机是官方认证的及格线，8 GB 显存独显需要"显存+内存"混合接力，而带视觉、开 thinking、拉 32K 上下文、上并行 agent 时——每一笔都要在预算表里提前画好。部署前先按"权重 + KV cache + mmproj + 缓冲区 + 并发系数"算一遍，比盯着 7.89 GB 这个营销数字靠谱得多。

【免费下载链接】Underdog-Saluki-27B-1.0项目地址: https://ai.gitcode.com/hf_mirrors/ConwayResearch/Underdog-Saluki-27B-1.0