■ space · стол переводчика

■ сначала ответ

Да — vLLM запускает GGUF, через vllm-gguf-plugin, только на GPU.

Синтаксис repo:quant_type + --tokenizer базовая модель; CPU x86/Arm и GPU Intel: не поддерживаются.

один GPU, много одновременных пользователей → vLLM; нет GPU или широчайшее покрытие квантов → llama.cpp.

Слова самих доков: «в высшей степени экспериментально и недооптимизировано» — фича про след в памяти, не про пропускную способность.

У СТОЛА

Скажите, на чём файл работает. Стол сверится с гостевым списком — официальной таблицей совместимости железа для квантов vLLM — и проштампует вердикт.

ПОДДЕРЖИВАЕТСЯ

GPU-кернелы стоят за GGUF-путём — плагин деквантизует блоки прямо в батчевый сервис. Пройдите к прилавку.

маршрут: uv pip install vllm-gguf-plugin → vllm serve repo:quant

источник гостевого списка: официальная таблица совместимости железа для квантов vLLM — отказ архитектурный: за GGUF-путём нет CPU-кернела, потому что vLLM — серверный движок, а не игрушка для ноутбука

ПРИЛАВОК

Два шага, и флаг, который никогда не украшение:

uv pip install vllm-gguf-plugin

# directly from Hugging Face, repo_id:quant_type format:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M \
  --tokenizer Qwen/Qwen3-0.6B

# or a local file you already downloaded:
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf \
  --tokenizer Qwen/Qwen3-0.6B

чистый старт. Доки советуют токенизатор базовой модели, потому что конверсия GGUF-токенизаторов «затяжна и нестабильна, особенно для моделей с большими словарями». Одна строка, без долгого старта.

Поддержка GGUF больше не входит в ядро vLLM — доки отмечают, что она «переехала в OOT vllm-gguf-plugin »; простого pip install vllm недостаточно.

Два GPU, одна модель: --tensor-parallel-size 2 расщепляет тот же GGUF по обеим картам.

Пришли от Ollama на CPU? Это движок, а не формат — llama.cpp гоняет GGUF даже на Raspberry Pi. За GGUF у vLLM нет CPU-кернела.

Один замок висит над железным: ОС. vLLM на Windows означает WSL2 — миновать его стоит налога форка.

ЧЕСТНЫЙ СПИСОК ОГРАНИЧЕНИЙ

Та же страница доков несёт предупреждение, достойное дословной цитаты: «Поддержка GGUF в vLLM в высшей степени экспериментальна и недооптимизирована.» Конкретно:

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

Ничто из этого не спрятано — всё в первом абзаце официальной GGUF-страницы, что больше, чем получают большинство экспериментальных фич.

ТОТ ЖЕ ФАЙЛ, ПРОТИВОПОЛОЖНЫЕ ИНСТИНКТЫ

	vLLM + GGUF	llama.cpp
CPU-инференс	нет	да, полноценный
Одновременные пользователи	continuous batching, создан для этого	ограничено
Покрытие квантов	подмножество, экспериментально	эталон
Установка	vLLM + плагин	один бинарник
Лучше всего для	один GPU, много пользователей	один пользователь, любое железо

Раздаёте команде с одного GPU? vLLM + GGUF переиспользует те же файлы Q4_K_M, что и весь остальной local-LLM-мир.

Один пользователь, любое железо? llama.cpp — один бинарник и весь формат.

Правило одной строки: тот же файл, противоположные инстинкты — llama.cpp считает GGUF форматом, vLLM — опцией.

■ честный штамп Документация, а не мой стенд. Проверено по: публичной летописи — vLLM + vllm-gguf-plugin · NVIDIA Volta → Hopper · GPU AMD. Записано 2026-09-23, обновлено 2026-10-12. Всё здесь — из документации vLLM и летописи репо vllm-project/vllm (92 000+ звёзд с февраля 2023): гостевой список — их таблица совместимости железа слово в слово, предупреждения — их слова в кавычках, и никакого tokens-per-second не выдумано, чтобы заткнуть дыры.

конец стола переводчика · ничего не fetched · всё локально