Чи запускає vLLM GGUF? Так — лише на GPU

Минулого тижня читач запитав, чому його файл GGUF падає у vLLM на машині без GPU, тоді як той самий файл без проблем працює в Ollama. Коротка відповідь перед усім іншим: так, vLLM запускає GGUF — через офіційний плагін, лише на GPU. Плагін зветься vllm-gguf-plugin, синтаксис — repo:quant_type; щойно ви пробуєте на CPU, ви поза таблицею підтримуваного обладнання. Усе нижче — з документації vLLM та історії репозиторію vllm-project/vllm (92 000+ зірок з лютого 2023) — з документів, а не з мого тестового стенда.

Як сервірувати модель GGUF через vLLM?

Два кроки: встановіть плагін, тоді наведіть vLLM на модель. Підтримка GGUF більше не живе в ядрі vLLM — документація зауважує, що вона «мігрувала до vllm-gguf-plugin», тож голого pip install vllm недостатньо:

uv pip install vllm-gguf-plugin

# Прямо з Hugging Face, у форматі repo_id:quant_type:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M 
  --tokenizer Qwen/Qwen3-0.6B

# Або вже завантажений локальний файл:
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf 
  --tokenizer Qwen/Qwen3-0.6B

Прапорець --tokenizer — не прикраса. Офіційна документація радить токенізатор базової моделі, бо конвертація токенізатора з GGUF «тривала й нестабільна, особливо для моделей із великим словником». Пропустити її — значить обміняти прапорець з одного рядка на довгий і примхливий старт.

Дві GPU, одна модель: додайте --tensor-parallel-size 2, і той самий GGUF розділиться між обома картами — тензорний паралелізм працює з GGUF так само, як із будь-яким іншим форматом.

Чому vLLM відмовляє GGUF на CPU?

Ось частина, що дивує. Репутація GGUF — спершу CPU: це формат, на якому llama.cpp збудував собі ім’я на ноутбуках і Raspberry Pi. Усередині vLLM становище перевертається. Офіційна таблиця сумісності обладнання позначає GGUF так:

Обладнання	GGUF у vLLM
NVIDIA Volta / Turing / Ampere / Ada / Hopper	підтримується
GPU AMD	підтримується
GPU Intel	не підтримується
CPU x86	не підтримується
CPU Arm	не підтримується

Джерело: документація квантизації vLLM. Причина архітектурна: GGUF-шлях vLLM деквантизує блоки в GPU-ядра, створені під пакетне сервірування. За ними немає CPU-ядер — бо vLLM це сервінговий рушій, а не ноутбучна іграшка. Без GPU на машині жоден прапорець не врятує — беріть llama.cpp.

Що ламається: чесний список обмежень

Та сама сторінка документації несе попередження, варту дослівного цитування: «підтримка GGUF у vLLM є вкрай експериментальною та недооптимізованою». Конкретно:

• Покриття квантизації вужче, ніж у llama.cpp. K-кванти, які завантажують усі (Q4_K_M і компанія), працюють; екзотичні схеми — не завжди. Референсною реалізацією формату лишається llama.cpp.
• Підтримка архітектур наздоганяє із запізненням. Нові родини моделей спершу приземляються в llama.cpp; плагін приходить потім.
• Немає лінивого завантаження через mmap. llama.cpp мапить файл у пам’ять; vLLM вантажить його як звичайний чекпойнт.
• Насамперед це функція сліду пам’яті. Документація подає GGUF як спосіб тиснути споживання VRAM, а не ставку на пропускну здатність.

Нічого з цього не приховано. Усе — в першому абзаці офіційної сторінки GGUF — чесніше, ніж у більшості експериментальних функцій.

GGUF: vLLM чи llama.cpp — хто виграє?

Різні інструменти, що читають той самий файл:

	vLLM + GGUF	llama.cpp
Inference на CPU	ні	так, першого класу
Одночасні користувачі	continuous batching, створене для цього	обмежено
Покриття квантів	підмножина, експериментальне	еталон
Встановлення	vLLM + плагін	одна бінарка
Ідеально для	одна GPU, багато користувачів	один користувач, будь-яке обладнання

Якщо ви сервіруєте модель команді з однієї GPU, vLLM + GGUF дозволяє перевикористати ті самі файли Q4_K_M, якими ділиться весь local-LLM світ — з більшим вибором у нашому гіді з квантизації GGUF. За повним порівнянням рушіїв — llama.cpp vs Ollama та як запускати GGUF-моделі локально.

Правило в один рядок: той самий файл, протилежні інстинкти — llama.cpp вважає GGUF головним форматом, vLLM бачить у ньому один із варіантів.