Định dạng tệp mô hình

Một bản phát hành mô hình không phải một tệp — đó là một checkpoint được đóng gói lại theo từng engine. Trang này vẽ bản đồ các định dạng bạn thực sự gặp ở cục bộ: GGUF cho thế giới llama.cpp, safetensors cho chồng PyTorch/HF, lượng hóa GPU bản-địa-của-engine, và ONNX cho runtime biên. Chọn engine trước; định dạng tự theo.

GGUF: một tệp, chứa tất cả

Một tệp .gguf đóng gói trọng số mô hình, từ vựng tokenizer, chat template và metadata theo-từng-tensor vào một tệp nhị phân duy nhất. Tải một lần, không cấu hình, và mọi app biết nói GGUF chạy cùng một tệp: llama.cpp và llama-server, Ollama, LM Studio, Jan, KoboldCpp. Định dạng hỗ trợ memory-map, nên trọng số stream từ đĩa từng trang — khởi động nhanh và page cache của HĐH làm việc cache miễn phí.

Giải phẫu tên tệp, từng trường một, cho Qwen3-8B-Q4_K_M.gguf:

Soi bất kỳ GGUF nào không cần nạp:

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 ... %}

Khối metadata đó là lý do một GGUF "chạy ngay" qua năm app khác nhau: engine đọc kiến trúc, dựng đồ thị, nạp tokenizer, và frontend chat áp dụng template nhúng sẵn. Không săn config, không lệch từ vựng, không phải tải tokenizer riêng.

Safetensors: bản địa Hugging Face

Safetensors là một hộp chứa cố tình nhàm chán: một header JSON chứa tên tensor, hình dạng và dtype, theo sau là byte thô. Nó lưu chỉ tensor — không mã chạy được, khác các checkpoint .bin vị pickle tải mù là nguy hiểm — và hỗ trợ mmap zero-copy, đó là lý do khởi động PyTorch nhanh. Transformers, vLLM, SGLang, TRL và cả hệ sinh thái tinh chỉnh nói nó một cách bản địa.

Vì nó chỉ lưu tensor, một mô hình chạy được là cả thư mục repo:

model-00001-of-00004.safetensors   ← các mảnh trọng số (~5 GB mỗi mảnh)
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors
model.safetensors.index.json        ← bản đồ mảnh: tên tensor → tệp mảnh
config.json                         ← kiến trúc + siêu tham số
generation_config.json              ← cài đặt lấy mẫu mặc định
tokenizer.json                      ← chính tokenizer
tokenizer_config.json               ← chat template nằm ở đây

Việc chia mảnh tồn tại vì checkpoint 70B FP16 nặng ~140 GB — một tệp duy nhất sẽ quá tải. Nếu bạn phục vụ bằng vLLM bạn tải tất cả các mảnh; không có lối tắt "chỉ tệp 4-bit" trong một bản phát hành safetensors. Phục vụ lượng hóa là một repo riêng (biến thể AWQ hoặc GPTQ của cùng mô hình).

Lượng hóa GPU bản-địa-engine: AWQ, GPTQ, EXL2

Các định dạng này tồn tại cho server suy luận GPU, nơi thông lượng quan trọng hơn sự tiện lợi tệp:

• AWQ — lượng hóa nhận-thức-kích-hoạt. Các prompt hiệu chuẩn tìm ~1% kênh trọng số mà kích hoạt phụ thuộc nhiều nhất; những kênh đó được bảo vệ bằng phép co giãn, phần còn lại xuống 4-bit. Chất lượng gần gốc ở 4-bit với kernel nhanh; lựa chọn 4-bit mặc định trong vLLM.
• GPTQ — lượng hóa GPU kinh điển, hậu duệ của optimal brain quantization: lượng hóa từng tầng một, bù lỗi của mỗi tầng against các trọng số chưa lượng hóa. 4-bit, kernel chỉ-GPU, vẫn có mặt khắp nơi trong cấu hình phục vụ.
• EXL2 — định dạng của exllamav2 với số bit biến thiên mỗi trọng số. Một repo có thể ngồi ở, chẳng hạn, 4.65 bpw bằng cách trộn tensor 2–8 bit để tổng đáp đúng dưới trần VRAM của bạn. Công cụ cho lúc Q4 không vừa nhưng Q3 thì đau.

Cả ba đều cần dữ liệu hiệu chuẩn và một lần chạy chuyển đổi, và không cái nào chạy trên CPU.

ONNX, MLX, FP16/BF16 thô

ONNX là định dạng đồ-thị-tính-toán di động: xuất một mô hình transformers một lần, chạy bất cứ đâu onnxruntime chạy — máy Windows không CUDA, điện thoại, demo WebGPU trên trình duyệt. onnxruntime cũng lượng hóa đồ thị sang INT8 cho CPU. Bạn trả bằng ma sát cài đặt và thường là tốc độ đỉnh; bạn nhận khả năng di động đến máy không có chồng PyTorch. Biên và nhúng là sân nhà của nó, không phải chat desktop.

MLX là khung mảng của Apple cho Apple Silicon; tổ mlx-community đóng gói lại phần lớn các bản phát hành lớn sang định dạng MLX, gồm cả 4-bit và 8-bit. Trên Mac dòng M chạy mlx-lm, đó là định dạng của bạn — xem Apple Silicon.

FP16/BF16 thô quan trọng khi bạn muốn tham chiếu không tổn thất, nền tinh chỉnh, hay nguồn chuyển đổi. BF16 giữ khoảng mũ 8-bit của FP32 và đánh đổi bit mantissa lấy nó — ổn định hơn nhiều cho huấn luyện so với FP16, cùng 2 byte mỗi trọng số. Mô hình 7–8B ở FP16/BF16 nặng ~16 GB riêng trọng số, trước bất kỳ ngữ cảnh nào.

Định dạng nào cho engine nào

Trộn định dạng là lỗi kinh điển của người mới: trỏ vLLM vào .gguf, hoặc llama.cpp vào các mảnh safetensors. Không cái nào chạy — engine hoặc báo lỗi hoặc cần một bước chuyển đổi trước.

Các lối chuyển đổi

Lối chuẩn từ một repo Hugging Face đến tệp cục bộ là hai bước — chuyển checkpoint sang GGUF 16-bit, rồi lượng hóa xuống:

git clone https://github.com/ggerganov/llama.cpp
pip install -r llama.cpp/requirements.txt

# 1. chuyển checkpoint HF (safetensors) sang GGUF
python llama.cpp/convert_hf_to_gguf.py ./Qwen3-8B --outtype bf16 --outfile qwen3-8b-bf16.gguf

# 2. lượng hóa về cỡ đích
llama-quantize qwen3-8b-bf16.gguf qwen3-8b-Q4_K_M.gguf Q4_K_M

Trên thực tế bạn hiếm khi tự chuyển: các bên lượng hóa như bartowski và mradermacher công bố mọi cỡ của mọi bản phát hành đáng chú ý trong vài giờ. Tự chuyển khi bạn có bản tinh chỉnh riêng tư, muốn I-quant hiệu chuẩn imatrix, hoặc cần mức bit ngoài chuẩn — chi tiết ở lượng hóa.

Mô hình embedding — một nửa truy xuất của RAG — phát hành trong cùng các định dạng: GGUF cho endpoint embedding của llama.cpp, safetensors cho sentence-transformers. Cùng quy tắc như mọi thứ phía trên: ghép định dạng với engine bạn thực sự sẽ chạy.

Liên quan: Lượng hóa · Các họ mô hình · Engine · RAG