vLLM и GGUF FAQ: десять поисковых вопросов — с ответами
Десять реальных поисковых вопросов о vLLM и GGUF — поддержка CPU, синтаксис serve, покрытие квантов, ловушка токенизатора — с ответами из документации и наших проверенных постов.
пятиминутный чек-лист
Режимы отказа сведены в таблицу — пройдите её сверху вниз.
| Симптом | Причина | Лечение |
|---|---|---|
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.