模型檔案格式
一個模型發布不是一個檔案——它是一個依各引擎重新包裝的檢查點。這一頁整理你在本機實際會遇到的格式：llama.cpp 世界的 GGUF、PyTorch／HF 生態的 safetensors、引擎原生的 GPU 量化，以及邊緣執行環境的 ONNX。先選引擎；格式隨之而定。
GGUF：一個檔案，萬物盡在其中
一個 .gguf 檔把模型權重、分詞器詞彙表、對話模板與每張量元資料打包成單一二進位檔。一次下載、零設定，而且所有會講 GGUF 的應用程式跑的都是同一個檔案：llama.cpp 與 llama-server、Ollama、LM Studio、Jan、KoboldCpp。這個格式支援記憶體映射，所以權重從磁碟逐頁串流——啟動快，而且 OS 分頁快取免費幫你做快取。
以 Qwen3-8B-Q4_K_M.gguf 為例，逐欄位解剖檔名：
| 欄位 | 值 | 意義 |
|---|---|---|
Qwen3 |
家族＋世代 | 引擎據以建構的架構；也是品質世代 |
8B |
規模級 | 約 80 億參數——VRAM 預算以此為基準 |
Q4_K_M |
量化標籤 | 每權重約 4.8 位元，K-quant「中」混合——見 量化 |
.gguf |
容器 | 權重＋分詞器＋對話模板＋元資料，一個檔案 |
不用載入就能檢查任何 GGUF：
python gguf-py/gguf/scripts/gguf_dump.py model.gguf
general.architecture : qwen3
general.name : Qwen3 8B
qwen3.context_length : 32768
tokenizer.ggml.model : gpt2 (BPE)
tokenizer.chat_template : {%- ... a Jinja template ... %}
那段元資料就是 GGUF 能在五個不同應用程式間「直接能用」的原因：引擎讀架構、建計算圖、載入分詞器，而聊天前端套用內嵌的模板。不用找設定、不會詞彙表不匹配、不用另外下載分詞器。
Safetensors：Hugging Face 的原生格式
Safetensors 是一個刻意無聊的容器：一段記錄張量名稱、形狀與 dtype 的 JSON 標頭，後面接原始位元組。它只存張量——沒有可執行程式碼，不像帶 pickle 味的 .bin 檢查點那樣盲目載入不安全——而且支援零複製 mmap，這就是 PyTorch 啟動快的原因。Transformers、vLLM、SGLang、TRL 與整個微調生態系都原生講這個格式。
因為它只存張量，一個能用的模型是整個存放庫目錄：
model-00001-of-00004.safetensors ← 權重分片（每片約 5 GB）
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors
model.safetensors.index.json ← 分片地圖：張量名稱 → 分片檔
config.json ← 架構＋超參數
generation_config.json ← 預設取樣設定
tokenizer.json ← 分詞器本體
tokenizer_config.json ← 對話模板在這裡
分片存在是因為 70B FP16 檢查點約 140 GB——單一檔案會難以管理。如果你用 vLLM 服務，就要下載全部分片；safetensors 發布裡沒有「只要 4-bit 檔案」的捷徑。量化服務是另外的存放庫（同一模型的 AWQ 或 GPTQ 變體）。
引擎原生 GPU 量化：AWQ、GPTQ、EXL2
這些格式是為 GPU 推論伺服器而生，那裡吞吐量比檔案便利性重要：
- AWQ——激活感知量化。校準提示詞找出激活最依賴的約 1% 權重通道；那些通道獲得保護性縮放，其餘全部 4-bit。4-bit 下近乎原始品質且核心快速；vLLM 的預設 4-bit 選擇。
- GPTQ——經典 GPU 量化，源自最佳腦量化：逐層量化，每層的誤差對尚未量化的權重做補償。4-bit、僅 GPU 核心，至今仍遍布服務設定。
- EXL2——exllamav2 的格式，每權重可變位元。一個存放庫可以藉由混合 2–8 bit 張量停在例如 4.65 bpw，讓總量剛好落在你的 VRAM 上限之下。Q4 塞不下、Q3 又會痛時的工具。
三者都需要校準資料與一次性的轉換流程，而且都不能在 CPU 上跑。
ONNX、MLX、原始 FP16/BF16
ONNX 是可攜的計算圖格式：把 transformers 模型匯出一次，onnxruntime 跑得動的地方都能跑——沒有 CUDA 的 Windows 機器、手機、瀏覽器 WebGPU 展示。onnxruntime 還能把計算圖量化成 INT8 給 CPU 用。你付出的是設定摩擦與常常較低的峰值速度；換到的是沒有 PyTorch 堆疊的機器上的可攜性。邊緣與嵌入式才是它的主場，不是桌面對話。
MLX 是 Apple 為 Apple Silicon 打造的陣列框架；mlx-community 組織把大多數主要發布重包成 MLX 格式，含 4-bit 與 8-bit。在跑 mlx-lm 的 M 系列 Mac 上，那就是你的格式——見 Apple Silicon。
原始 FP16/BF16 檢查點在你需要無損參考、微調基底或轉換來源時很重要。BF16 保留 FP32 的 8 位元指數範圍，用尾數位元去換——訓練穩定性遠勝 FP16，每權重同樣 2 位元組。7–8B 模型在 FP16/BF16 下光權重就約 16 GB，還沒算任何上下文。
哪種引擎吃哪種格式
| 引擎／堆疊 | 吃的格式 | 備註 |
|---|---|---|
| llama.cpp、Ollama、LM Studio、Jan | GGUF | 單一檔案；CPU＋GPU；所有量化家族 |
| vLLM、TGI、SGLang | safetensors、AWQ、GPTQ | 伺服器吞吐量；GPU |
| exllamav2 / TabbyAPI | EXL2、GPTQ | 可變 bpw；GPU |
| transformers / PyTorch | safetensors | 訓練、微調、研究 |
| onnxruntime | ONNX | 邊緣、行動、瀏覽器 |
| mlx-lm | MLX | Apple Silicon |
混用格式是經典的新手錯誤：叫 vLLM 吃 .gguf，或叫 llama.cpp 吃 safetensors 分片。兩者都不行——引擎要嘛直接報錯，要嘛得先經過轉換。
轉換路徑
從 Hugging Face 存放庫到本機檔案的標準路徑是兩步——先把檢查點轉成 16-bit GGUF，再往下量化：
git clone https://github.com/ggerganov/llama.cpp
pip install -r llama.cpp/requirements.txt
# 1. 把 HF 檢查點（safetensors）轉成 GGUF
python llama.cpp/convert_hf_to_gguf.py ./Qwen3-8B --outtype bf16 --outfile qwen3-8b-bf16.gguf
# 2. 量化到目標大小
llama-quantize qwen3-8b-bf16.gguf qwen3-8b-Q4_K_M.gguf Q4_K_M
實務上你很少自己轉：bartowski 與 mradermacher 這類量化者，會在幾小時內把每個重要發布的每種大小都發布出來。自己轉的時機：私有微調、想要 imatrix 校準的 I-quant、或需要非標準位元數——細節見 量化。
嵌入模型——RAG 的檢索那一半——以同樣的格式出貨：llama.cpp 嵌入端點用 GGUF，sentence-transformers 用 safetensors。規則與上面一切相同：讓格式配合你實際要跑的引擎。