A .gguf 是一次等待跑道的飞行：同一个文件能在 Ollama、llama.cpp、LM Studio、Jan 以及——带附加条件——vLLM 里运行。这就是飞行前检查，按顺序：选运行器、拉取模型、确认它真的落在 GPU 上、并在四种中止发生前就叫得出它们的名字。

■ the answer first

Fastest path: 最快路径： — Ollama pulls the GGUF straight from Hugging Face and serves it.

——Ollama 直接从 Hugging Face 拉取 GGUF 并提供服务。

Want the （哪些层上 GPU）？ (which layers hit the GPU)? llama-server -m file.gguf -ngl 99.

Quant default: 默认量化：——文件大小 + 约 1–2 GB 上下文开销应当装进你的显存。

THE PRE-FLIGHT

下载与模型开始服务之间的五项检查。边走边打勾——跑道在你身后亮起来。

■ 等待中——清单候场。

THE FILE, AND ITS NAME

GGUF（GGML Universal File）是量化模型的容器：权重、分词器、元数据——一个文件，没有配置大杂烩。

权重从 16 位压到 4 位：全精度要 ~18 GB 的 9B 模型，Q4 只要 ~5.5 GB——游戏显卡甚至 CPU 都能装。

bartowski/gemma-2-9b-it-GGUF:Q4_K_M

组织 · 基础模型 · 导出 · 量化标签——重要的是两件事：基础模型（gemma-2-9b-it）以及权重被压得多狠（Q4_K_M)

TWO WAYS TO FLY IT

Ollama——设好就忘的服务。 GGUF 是原生支持的，2024 年起还能直接从 Hugging Face 拉取。代价是控制力：你选不了 GPU 层数。

# 直接从 Hugging Face 拉一个 GGUF 量化版并聊天
ollama run hf.co/bartowski/gemma-2-9b-it-GGUF:Q4_K_M

# or wrap a file you already have — Modelfile, one line:# 或包装一个你已有的文件——Modelfile，一行：# FROM ./gemma-2-9b-it-Q4_K_M.gguf
ollama create gemma9b -f Modelfile
ollama run gemma9b

llama.cpp——GGUF 的老家。 支持最深也最新，llama-server 同时给你聊天界面和 OpenAI 兼容端点：

# 直接从 Hugging Face 下载（自动挑一个匹配的 GGUF）
llama-server -hf ggml-org/gemma-3-4b-it-GGUF --port 8080

# or run a file you already have, with full GPU offload# 或运行你已有的文件，GPU 全量卸载

The -ngl 是 llama.cpp 的超能力——部分卸载。用记录里的例子试：48 层的 9B 放在 6 GB 显卡上：

上 GPU 的层数（-ngl）

层在卡上，其余骑在 CPU 上走 PCIe——6 GB 显卡照样能跑，只是慢一些。 layers on the card, the rest riding CPU through PCIe — it runs fine on a 6 GB card, just slower.

单发提示：把 llama-server for llama-cli 换成同款旗标 -m flag. LM Studio is the same engine behind a GUI — drop in a 。LM Studio 是同一引擎套了 GUI——丢进去一个 ，点加载。

WHICH QUANT IN THE TANK

默认答案：Q4_K_M——与全精度差一两个百分点，体积约四分之一；7–14B 模型的“每 GB 质量”在这里登顶。

阶梯，从大到小：

Q8_0——几乎无损；如果你的显存能毫不在意地吃下每权重 8.5 比特，就用它。
Q6_K / Q5_K_M——小一档，对 30B+ 模型依然优秀。
Q4_K_M — the default.
IQ4_XS / Q3_K_M——把大模型塞进小卡；质量损失开始可感。
Q2_K and below——最后手段；模型会在句子中间开始胡言乱语。

装载法则：file size + ~1–2 GB of context overhead ≤ VRAM——9B 的 4.7 GB Q4_K_M 在 8 GB 卡上很从容。

开销是 KV 缓存：随上下文增长，与模型大小无关。按你最长的真实会话做预算。

And prefer a 更高量化的更小模型——Q8 的 4B 通常胜过 Q2 的 9B。

格式角落：safetensors is the unquantised archive——训练、微调、transformers、ComfyUI 用它。GGUF 是量化后可运行的那个。

GGUF 没法微调，safetensors 不转换（

You can't fine-tune a GGUF, and you can't run safetensors in Ollama or llama.cpp without converting (convert_hf_to_gguf.py 是那座桥）也没法在 Ollama 或 llama.cpp 里跑。训练 → safetensors；本地聊天 → GGUF。

THE FOUR ABORTS

为什么我的 GGUF 模型加载不了？这四种覆盖大多数情况：

01unknown model architecture

GGUF 用了一种你的运行时还不认识的新架构——MoE 和视觉模型天天出新。升级 Ollama 或重新编译 llama.cpp；没有别的修法。

02加载时内存不足

量化对你显存加上下文来说太大。降一档（Q4_K_M → Q3_K_M）、调低 -ngl, or shrink context with -c 4096.

03下载截断/损坏

加载时报 magic-number 或元数据错误。重新下载并核对 Hugging Face 页面上显示的 SHA256。

04ollama run ./model.gguf refuses

预期之内：run 接受模型名，不接受文件路径。用上面的 Modelfile 路线。

最后一个角度：本地 GGUF 端点与智能体编程工具是天作之合——把兼容 OpenAI 的客户端指过去；补全只花电费。

管道跑通之后，问题变成哪个模型配得上这个坑位；机舱篇会从头到尾读一遍 llama.cpp 对阵 Ollama 的记录。

一个模型，多个用户？vLLM 的 GGUF 模式能用——仅限 GPU，在它的原生格式旁边是二等乘客。

■ honest stamp 实测环境：ollama · llama.cpp 构建 · LM Studio · vLLM · GGUF Q4_K_M。 首发于 2026-09-07，记录更新于 2026-10-06。上文每条命令都按原样运行；体积（9B 的 5.5 GB Q4 / ~18 GB fp16）、6 GB 卡 48 层跑 20 层的例子、以及四种中止，都是原作实测记录。重录它们没有跑新的基准。

首飞到此为止 · 未取一分毫 · 一切皆本地