> GGUF vs safetensors——说了算的是运行时，不是格式▋

DuckDuckGo 会把 gguf vs safetensors 自动补全成两个文件扩展名之间的铁笼大战。其实这是一道门禁。选 GGUF，一排运行时向你敞开——llama.cpp、Ollama、LM Studio、Jan。选 safetensors，敞开的是另一排——transformers、vLLM、ComfyUI。格式就是那张会打开的门的清单；其余一切都跟在后面。本文拒绝的谎言：这场对决由速度数字决定——而那些数字，没人能在同一台机器上对齐过。记录免费给你的——也是多数论证跳过的——是每个容器有多重，以及每个容器到底能在哪里被打开。

你到底在选择什么？

GGUF 是 llama.cpp 作者们造的单文件容器，量化按张量直接烘焙在里面——人人争论的量化阶梯只存在于这个格式里。一个文件装下权重、tokenizer 和聊天模板：文件就是发行版。Safetensors 是序列化容器——JSON 头加原始张量字节——装的是训练仓库出厂时的精度，通常是 BF16 或 FP16。它不量化；它只存放。

Safetensors 的名字就来自它唯一的职责：确保没有人在加载模型时被 pickle 腌掉。Python 的 pickle 在解包时会执行代码；safetensors 什么都不执行——这就是全部的安全卖点，也是 Hugging Face 生态把它定为标准的原因。

把同一个模型放进每种容器里称一称，哲学就显现在字节里。2026 年 10 月 14 日，同一个 Qwen3-0.6B 的出厂重量是：Q4_K_M GGUF，396,705,472 字节（397 MB）· BF16 GGUF，1,198,182,848 字节（1.20 GB）· BF16 safetensors，1,503,300,328 字节（1.50 GB）。量化容器只有全精度的四分之一，因为它保住的精度就是四分之一——而这些数字每一个都离你的终端只有一条 curl -I，不需要任何测试台。缺掉的精度是否折损质量，是字节回答不了的保真度问题；量化档位那篇讲清了每一级各让出什么。

格式不是偏好。它是一份清单——列出哪些运行时会打开你的文件。

字节说了什么？

记录式阅读的诚实规则：只写记录明确给出、注明出处的数字，不搞跑分 cosplay。这张表是一个模型、三种容器、出厂精确字节——先自己查证，再决定信不信。

容器	精度	出厂字节数	占全精度的比例
GGUF Q4_K_M	4 bit 量化	396,705,472 (397 MB)	26%
GGUF BF16	全精度，llama.cpp 打包	1,198,182,848 (1.20 GB)	80%
safetensors BF16	全精度，原始张量	1,503,300,328 (1.50 GB)	100%

验证：curl -sIL https://huggingface.co/unsloth/Qwen3-0.6B-GGUF/resolve/main/Qwen3-0.6B-Q4_K_M.gguf | grep -i content-length → 字节数，当天或任何一天 · 同一条命令对 BF16 和 safetensors 文件照用

诚实地读这张表。26% 是量化阶梯的全部承诺：原来十六个比特的地方现在放四个，磁盘和内存皆然。两行全精度之间的差距——1.20 对 1.50 GB——是打包开销，不是物理定律：llama.cpp 的 BF16 打包比原始转储把同样的张量装得更瘦。字节说不了的是速度和质量：一列没有对齐机器的 tokens-per-second 只是论坛噪音，本文拒绝印刷这种东西。llama.cpp 对 Ollama 那篇从引擎那一侧撞过同一堵墙：同一个文件，同一套数学，不同的壳。

记录告诉不了你的事

三堵墙，直说。一：质量——Q4 对 BF16 是保真度交换，没有任何字节数能度量它。二：速度——加载时间和每秒 token 数属于在点名机器上的对齐跑分，本文没有，所以一个也不印。三：规模——0.6B 模型的字节比例到 70B 依然成立，但 70B 上你会真实感到的绝对等待，是另一台硬件上的另一篇文章。

每种格式到底能在哪里跑？

这一部分才真正拍板。GGUF 在 llama.cpp、Ollama、LM Studio、Jan 里打开——单文件本地生态。vLLM 也能读 GGUF，走插件，限 GPU，带一串注意事项。Safetensors 在 transformers、vLLM 原生支持、ComfyUI 以及 Apple 的 MLX 工具链里打开。边缘的重叠很有意思：Ollama——这座架在 GGUF 引擎上的家电——照样附带一个 MLX runner，好让 Apple Silicon 用户加载由 safetensors 派生的权重。连家电都会留后手。

你已经在跑	你的格式自己选好了	为什么
Ollama、LM Studio 或 llama-server	GGUF	它们的引擎原生吃 GGUF；量化文件塞得进小磁盘
Python/transformers 流水线	safetensors	from_pretrained 是原生路径；没有要维护的转换步骤
GPU 服务器上的 vLLM	safetensors	原生，无插件，无 GGUF 注意事项——GGUF 注意事项本身
ComfyUI 或图像流水线	safetensors	扩散生态做的是 safetensors checkpoint 的买卖
小磁盘和小机器	GGUF Q4_K_M	同样的权重，397 MB 对 1.50 GB

GGUF 把量化设成默认；safetensors 把全精度设成默认。这个默认就替大多数人做完了决定。

到底该部署哪一个？

查任何表之前，先查机器上已经装了什么。如果这台机器听 ollama run 的号令，你就住在 GGUF 国——拿走 Q4_K_M 文件，别再逛论坛。如果你的日常是 Python，或者服务层是 vLLM，那 safetensors 从来就不是选择；它是生态的母语。两者互转可行，但几乎从不值得：每一次转换都是权重悄悄走样的新机会。

按本站惯例，强制的一句诚实话：我读过记录，没有跑过它。本页每个数字都来自出厂文件，在本文发布当天早上抓取——没有测试台，没有 tokens-per-second cosplay。记录能确立的是这场交换的形状——量化容器只要四分之一的字节，两个几乎不重叠的运行时，以及每一侧那个悄悄替多数人拍板的默认精度。整个集群——runner、格式、量化档位，全都在——已收录进本地 LLM 中心。

从来没人为了速度换格式。人们为了某个功能换运行时，格式只是跟着来的那张票。

所以，两个问题抛回墙那边：你每天用的那套环境真正能打开哪种格式——以及这三个容器在你的硬件上，一场公平的跑分该长什么样？在评论区报上机器和模型；规格最全的那位，定下一篇的规格表。