GGUF 說明：讓 AI 在任何地方運行的開放格式

GGUF（GGML 通用格式）是一種用於儲存量化大型語言模型權重的單文件格式，專為在消費級硬體上高效本地推論而設計。它是 llama.cpp、Ollama 和 LM Studio 使用的標準文件格式——如果您在本地運行 AI 模型，您幾乎肯定在使用 GGUF 文件。

根據 Hugging Face 的數據，截至 2026 年初，平台上託管的 GGUF 模型文件超過 50,000 個，反映了該格式在本地推論生態系統中的主導地位。GGUF 的 4 位元量化（Q4_K_M）與全精度 FP16 相比，將模型壓縮了約 75%——一個 14GB 的模型變成大約 4GB——在大多數基準測試上品質僅下降 4-5%。根據 llama.cpp 的基準測試，Apple Silicon 上的量化 GGUF 模型對於 7B 參數模型可達到每秒 40-60 個 token，使得在消費級筆記型電腦上進行即時推論成為現實。

本指南解釋了 GGUF 是什麼、為何重要，以及命名慣例的含義，讓您在下載或部署模型時能夠做出明智的決策。

GGUF 是什麼

GGUF（GGML 通用格式）是一種用於儲存大型語言模型權重的文件格式。它由 Georgi Gerganov（名稱中的「GG」）創建，他是 llama.cpp 的開發者，llama.cpp 是大多數本地推論工具的基礎 C++ 函式庫。

在 GGUF 存在之前，有 GGML——來自同一開發者的早期格式。GGUF 在 2023 年 8 月取代了 GGML，採用更好結構化的設計，支援元資料、可擴展性和更清晰的版本控制。

GGUF 的關鍵特性：

單一文件。 整個模型——權重、配置、分詞器——都在一個文件中。不需要單獨的 config.json 或 tokenizer.json 文件。這是相對於 PyTorch/Hugging Face safetensors 格式的重大實際改進，後者將模型分散在多個文件中。

自描述性。 GGUF 文件包含有關模型架構、訓練參數和量化配置的元資料。讀取 GGUF 文件的工具無需外部文件即可知道其包含的內容。

記憶體映射。 GGUF 支援記憶體映射（mmap），讓作業系統只載入給定推論過程所需的文件部分。這使得運行比可用 RAM 更大的模型成為可能——速度較慢，但不會崩潰。

量化優先設計。 GGUF 是圍繞量化模型建構的——模型的權重精度從 16 位元或 32 位元浮點數降低到較低精度整數的模型。這就是為什麼 GGUF 模型能在消費級硬體上運行。

量化：核心概念

一個 7B 參數模型在全精度 16 位元（FP16）下佔用約 14GB 記憶體。大多數消費級 GPU 有 8-12GB 的 VRAM。這個數學行不通。

量化通過降低精度來壓縮模型權重。不是將每個權重儲存為 16 位元浮點數，而是將其儲存為 4 位元整數。這將記憶體使用量減少了大約 4 倍，使 7B 模型可以輕鬆適應 8GB VRAM。

對大多數任務而言，品質取捨出奇地小。Q4 量化模型在大多數基準測試上的表現與原始 F16 模型相當——降低精度帶來的資訊損失部分由訓練過程補償，而對於推論（非訓練），影響是有限的。

閱讀 GGUF 文件名稱

GGUF 文件遵循編碼關鍵資訊的命名慣例。理解它可以讓您為自己的硬體和品質要求選擇正確的文件。

典型的文件名：Meta-Llama-3.2-7B-Instruct-Q4_K_M.gguf

分解說明：

• Meta-Llama-3.2 — 模型系列和組織
• 7B — 參數數量（70 億）
• Instruct — 模型變體（指令調整版，非原始基礎模型）
• Q4_K_M — 量化類型（這是重要部分）

量化類型

量化類型告訴您模型被壓縮的程度：

_K 變體使用 k-quants，一種更複雜的量化方法，對模型的不同部分應用不同的精度。在 k-quant 家族中，_M 是「中等」，_S 是「小」。

大多數使用案例的實用建議： Q4_K_M 是最常用的 GGUF 量化。它提供了大小縮減（與 F16 相比約 70%）和最小品質損失（約 4-5%）的良好平衡。對於客戶部署，這通常是正確的起點。

何時使用更高精度： 如果您有 VRAM/RAM 來容納 Q5_K_M 或 Q6_K，這些對於精度敏感的任務（程式碼生成、數學、複雜推理）提供了明顯更好的品質。如果硬體允許，大小的增加是值得的。

何時使用更低精度： 如果您在 RAM 有限的機器上部署（8GB 總系統記憶體或小型 GPU），Q3_K_M 可能是運行 7B 模型的必要條件。預計在複雜任務上品質會有一些下降。

GGUF vs 其他格式

如果您從 Hugging Face 下載模型進行訓練，您得到的是 safetensors。當您想用 Ollama 或 LM Studio 在本地運行時，您需要 GGUF。當 Ertas 等工具匯出微調模型時，轉換自動發生，或者您可以使用 llama.cpp 的轉換指令碼手動轉換。

微調模型如何使用 GGUF

當您使用 LoRA 微調模型時，您會產生一個 LoRA 適配器——一組修改基礎模型行為的額外小型權重。要將其部署用於推論，您通常將適配器合併回基礎模型權重，並將結果匯出為 GGUF。

匯出過程：

1. 從基礎模型權重開始（safetensors 格式）
2. 應用 LoRA 適配器以產生合併的全精度模型
3. 量化到您的目標精度（推薦 Q4_K_M）
4. 輸出為準備好供 Ollama/LM Studio 使用的單一 GGUF 文件

Ertas 自動處理這個匯出管道——您獲得一個準備好載入 Ollama 的 GGUF 文件，無需手動運行轉換指令碼。生成的文件是您客戶特定的模型，完全自包含。

實用的硬體需求

不同 GGUF 模型大小需要多少記憶體？

對於大多數代理部署，在具有 8-16GB RAM（或 6-8GB VRAM 的 GPU）的機器上運行的 7B 模型涵蓋了大多數使用案例。Mac Mini M4（16GB 統一記憶體）以超過 40 tokens/秒的速度運行 7B 模型——對於生產 API 使用而言舒適地快速。

為何 GGUF 對 AI 建構者很重要

GGUF 及使用它的工具（llama.cpp、Ollama、LM Studio）的存在，使消費級硬體 AI 推論成為可行。在此生態系統出現之前，在本地運行 7B 模型需要資料中心 GPU 或非常笨拙的 Python 環境。

對於 AI 代理，GGUF 是實現整個本地推論價值主張的格式：

• 模型在客戶硬體上運行，沒有雲端 API 依賴
• 微調模型是可攜式的單文件資產，可在任何地方部署
• 購買硬體後推論成本降至接近零

理解 GGUF 命名慣例讓您能夠自信地為客戶部署選擇模型，並清晰地溝通取捨。7B 模型的 Q4_K_M 與同一模型的 F16 是不同的東西——了解差異意味著為硬體限制選擇正確的工具。

---

常見問題

GGUF 格式是什麼？

GGUF（GGML 通用格式）是一種用於儲存大型語言模型權重的文件格式，由 llama.cpp 背後的開發者 Georgi Gerganov 創建。它將模型權重、配置和分詞器資料打包成一個針對本地推論優化的自描述文件。GGUF 是 Ollama、LM Studio 和 llama.cpp 用於在消費級硬體上運行 AI 模型的標準格式。

GGUF 和 GGML 有什麼區別？

GGUF 是 GGML 的繼承者，在 2023 年 8 月取代了它。兩者都由同一開發者創建，但 GGUF 增加了結構化元資料、更好的可擴展性和更清晰的版本控制。現代版本的 llama.cpp 不再支援 GGML。如果您遇到 GGML 模型文件，需要將其轉換為 GGUF 才能與目前的工具一起使用。

我應該使用哪種量化級別？

對於大多數使用案例，Q4_K_M 是推薦的起點。與全精度 FP16 相比，它將模型大小縮小了約 75%，品質損失僅 4-5%。如果您有額外的 VRAM 或 RAM，Q5_K_M 或 Q6_K 對於精度敏感的任務（如程式碼生成和數學）提供了明顯更好的品質。如果您被限制在 8GB 系統記憶體中，Q3_K_M 對於 7B 模型可能是必要的，但預計在複雜任務上會有一些品質下降。

我可以將任何模型轉換為 GGUF 嗎？

大多數流行的開放權重語言模型都可以使用 llama.cpp 附帶的轉換指令碼轉換為 GGUF。來自 Hugging Face 的 safetensors 或 PyTorch 格式的模型是典型的起點。然而，模型架構必須被 llama.cpp 支援——大多數主要架構（Llama、Mistral、Phi、Qwen、Gemma）都受支援，但非常新或不尋常的架構可能無法立即可用。Ertas Studio 等工具在匯出微調模型時自動處理轉換。

延伸閱讀

• 本地運行 AI 模型 — 硬體設置指南和 Ollama 深入介紹
• LM Studio vs Ollama 用於客戶部署 — 在哪種情境下使用哪種本地推論工具
• 模型蒸餾和 LoRA 指南 — 從完整訓練到高效微調
• GGUF vs SafeTensors：何時使用各個格式，以及 safetensors 在 GPU 上的服務位置
• GGUF vs ONNX：GGUF 用於本地 LLM，ONNX 用於行動 NPU、原生 Windows 和瀏覽器