vLLM и GGUF FAQ: десять поисковых вопросов — с ответами

vLLM и GGUF FAQ: десять поисковых вопросов — с ответами

Десять реальных поисковых вопросов о vLLM и GGUF — поддержка CPU, синтаксис serve, покрытие квантов, ловушка токенизатора — с ответами из документации и наших проверенных постов.

HUMANавтор @mrsaynothing17d5 мин чтения

пятиминутный чек-лист

есть GGUF на раздачу? начните тут да есть GPU NVIDIA/AMD? нет GPU / GPU Intel llama.cpp — CPU первым классом сколько пользователей? на той единственной GPU один — только я несколько / команда llama.cpp один бинарник, самый широкий выбор квантов, CPU первым классом vLLM + vllm-gguf-plugin непрерывный batching, одна GPU, много параллельных пользователей GGUF грузится — выстраивается очередь в этом весь смысл vLLM
fig 1 — выбирайте по железу и числу людей, а не по формату файла. Оба движка читают один и тот же GGUF; разница — в том, что они оптимизируют.

Режимы отказа сведены в таблицу — пройдите её сверху вниз.

все syntax CPU quant
Симптом Причина Лечение
404 или "model not found" при serve GGUF подан плоским путём — vLLM хочет repo:quant_type Используйте форму repo:quant_type (следующий раздел)
Ошибка токенизатора при загрузке --tokenizer отсутствует или указывает на GGUF-репо Укажите на репо оригинальной базовой модели
Работает в Ollama/llama.cpp, отказывает в vLLM Тот же файл, другой движок — GGUF-путь vLLM только GPU CPU-боксы остаются на llama.cpp
Квант-схема отвергнута при загрузке Экзотический квант вне покрытия плагина Спускайтесь до Q4_K_M и товарищей — см. руководство по квантованию

Can vLLM run GGUF ?

Да — через официальный vllm-gguf-plugin, на GPU NVIDIA и AMD. Плагин собственный у vLLM, не коммьюнити-форк. Важны обе половины: плагин официальный, а таблица железа заканчивается на GPU. Полный проход по serve живёт в Can vLLM Run GGUF? Yes — on GPU Only.

Поддерживает ли vLLM GGUF на CPU?

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

Как раздавать GGUF-модель через vLLM?

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

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

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

проверка: раздайте модель, затем nvidia-smi — процесс vLLM должен держать VRAM, а не системную RAM.

Какие GGUF-кванты поддерживает vLLM?

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

Готов ли GGUF-саппорт vLLM к продакшену?

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

Грузит ли vLLM GGUF быстрее, чем llama.cpp?

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

vLLM или llama.cpp для GGUF — кто берёт?

Тот же файл, противоположные инстинкты: llama.cpp считает GGUF форматом, vLLM — опцией. Один GPU на несколько человек → vLLM плюс плагин. Один человек, любое железо, самый широкий выбор квантов → llama.cpp, один бинарник. Таблица лицом к лицу — CPU, параллельность, покрытие квантов, установка — в полном разборе.

Почему мой GGUF-файл отказывает в vLLM?

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

Гоняет ли Ollama GGUF?

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

Могут ли несколько пользователей делить один vLLM GGUF-сервер?

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

Ещё одна ловушка: грузится, а под нагрузкой падает по памяти

GGUF, отлично обслуживающий одного пользователя, всё равно может пробить потолок VRAM, когда batching умножает kv-cache на каждый параллельный запрос. Веса похудели; кэш растёт с каждым пользователем. Снижайте параллельность, урезайте контекст или спускайтесь на квант ниже — логика расчёта та же, что у любого деплоя vLLM.

Десять ответов выше тянутся к двум источникам: официальная документация vLLM и наши собственные serve-логи. Чего ещё никто не публиковал — стенда: Q4_K_M через плагин против того же файла в llama.cpp на одной карте, tok/s бок о бок. Когда этот стенд прогонится, он приземлится первым в хаб local-LLM.