Может ли vLLM гонять GGUF? Десять вопросов — сначала ответы

vLLM гоняет GGUF через официальный vllm-gguf-plugin, только на GPU NVIDIA и AMD. Синтаксис serve — repo:quant_type с обязательным --tokenizer, указывающим на исходную модель. На CPU ответом остаётся llama.cpp.

Один GPU на несколько человек → vLLM + vllm-gguf-plugin. Один человек, любое железо, самый широкий выбор квантов → llama.cpp, один бинарник. Нет GPU или GPU Intel → llama.cpp, CPU первым классом. Оба движка читают один и тот же GGUF; разница — в том, что они оптимизируют, выбирайте по железу и числу людей, а не по формату файла.

Да — через официальный vllm-gguf-plugin, на GPU NVIDIA и AMD. Плагин — собственный у vLLM, не коммьюнити-форк. Важны обе половины: плагин официальный, а таблица железа заканчивается на GPU.

Нет. За GGUF-путём vLLM не стоит CPU-ядро — CPU x86/Arm и GPU Intel остаются вне таблицы поддерживаемого железа. В этом ловушка классического репорта: тот же GGUF, что отдаёт 404 в vLLM на ноуте, спокойно работает в Ollama, потому что родная территория GGUF — движки, ставящие CPU во главу. Файл никогда не был проблемой.

Одна строка — репо, тип кванта и токенизатор:

vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M --tokenizer Qwen/Qwen3-0.6B

Синтаксис — repo:quant_type. Ловушка — флаг --tokenizer: он называет репо оригинальной модели, никогда GGUF-репо — файлы GGUF несут только веса, а vLLM хочет настоящий токенизатор из исходной модели.

K-кванты, которые реально качают люди — Q4_K_M и товарищи — работают; экзотические схемы могут не завестись. llama.cpp остаётся эталонной реализацией формата, поэтому новые квант-схемы и архитектуры моделей приземляются туда первыми, а до плагина доходят позже.

Документация отвечает сама: "Поддержка GGUF в vLLM высоко экспериментальна и недооптимизирована." Эта фраза живёт в первом абзаце официальной страницы GGUF — больше честности, чем получает большинство экспериментальных фич. Считайте плагин способом переиспользовать уже скачанные файлы и держите выход на llama.cpp открытым.

Нет — и скорость никогда не была целью. llama.cpp мапит файл в память, поэтому GGUF стартует лениво; vLLM грузит его как любой другой чекпойнт. GGUF внутри vLLM — фича про память: в доках она подана как способ ужать потребление VRAM, а не про пропускную способность. Выигрыш в пропускной способности даёт batching — совершенно в другом месте.

Три настоящих причины: неверный синтаксис serve (плоский путь вместо repo:quant_type), отсутствующий или неверный --tokenizer, либо железо вне таблицы поддержки. Четвёртая попадается реже: квант-схема, которую плагин не покрывает. Идите по таблице ниже сверху вниз — первые три строки покрывают большинство репортов.

Да — нативно; GGUF — родной формат Ollama, а не надстройка. Стяните GGUF с Hugging Face, покажите его Ollama — готово. Если GPU скучает, пока всё работает, это другая проблема со своим чек-листом.

Это единственная работа, ради которой существует vLLM: непрерывный batching ставит в очередь параллельные запросы к одной загруженной модели. GGUF-плагин наследует эту машинерию — честная оговорка та самая строчка доков про «недооптимизированность», так что если вы тariруете общий сервер — прогоните свой квант на своей карте, прежде чем обещать кому-то цифру. И ещё одна ловушка: GGUF, отлично обслуживающий одного пользователя, всё равно может пробить потолок VRAM, когда batching умножает KV-кэш на каждый параллельный запрос — веса похудели; кэш растёт с каждым пользователем. Снижайте параллельность, урезайте контекст или спускайтесь на квант ниже.