# vLLM или llama.cpp: CUDA-сервинг и GGUF-сценарии

vLLM или llama.cpp для локальной LLM: сравнение форматов, частичного GPU-размещения, серверного API и проверки одинаковой нагрузки.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/vllm-vs-llama-cpp/
Language: ru

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

## Начните с доступного артефакта

Если уже есть проверенный GGUF, сначала оцените его в родном рабочем маршруте llama.cpp. Если выбран checkpoint и формат, хорошо поддерживаемые vLLM на вашей карте, начните с него. Переконвертация ради названия движка добавляет отдельный источник различий и ошибок.

Возможности llama.cpp перечислены в [официальном репозитории](https://github.com/ggml-org/llama.cpp), серверные параметры — в [документации llama-server](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md). Для vLLM сверяйте архитектуру модели и аппаратный backend с соответствующей версией, а не с обобщённой таблицей из стороннего обзора.

## Сравните практические особенности

| Вопрос | llama.cpp | vLLM |
| --- | --- | --- |
| Основной проверяемый артефакт | GGUF и его метаданные | Поддерживаемый checkpoint и формат |
| Частичное размещение | Настройки переноса слоёв и backend | Собственные механизмы памяти и offload |
| Серверный интерфейс | llama-server с параметрами слотов и контекста | serve с настройками движка и кеша |
| Повторяемость | Версия сборки, backend, файл | Версия движка, checkpoint, параметры |

Это ориентиры для выбора эксперимента. Реальные возможности шире таблицы и меняются с выпусками. Особенно внимательно проверяйте поддержку новых архитектур: наличие похожего имени модели ещё не подтверждает корректный шаблон и все требуемые операции.

## Учитывайте CPU и GPU отдельно

Частичный перенос модели на GPU может позволить использовать доступную VRAM, оставляя часть работы в оперативной памяти. Но RAM не становится VRAM, а обмен и оставшиеся вычисления способны ограничивать задержку. По одному общему объёму памяти предсказать результат нельзя.

Практический тест llama.cpp сравнивает одинаковый GGUF при нескольких настройках переноса. Для vLLM проверяется поддерживаемый маршрут с сохранённой конфигурацией. Эти результаты помогают оценить пригодность конкретной машины. Связанные инструкции: [GPU layers](/ru/journal/llama-cpp-gpu-layers/) и [проверка бюджета vLLM](/ru/journal/vllm-gpu-memory-utilization/).

## Не сравнивайте разные выходы как одинаковую работу

Если один движок завершает ответ после короткой фразы, а другой продолжает рассуждение, число tokens/s и полное время относятся к разным результатам. Зафиксируйте шаблон, настройки генерации, предельный выход и фактические токены. Проверьте корректность прежде, чем сравнивать скорость.

Одинаковые условия нужны также для прогрева, повторяющихся префиксов и параллельности. [Официальное руководство vLLM по online serving](https://docs.vllm.ai/en/stable/serving/online_serving/) помогает выбрать интерфейс теста. Сначала проверьте одну сессию, затем поток, который действительно нужен предполагаемому приложению.

## Оцените стоимость сопровождения конфигурации

Владелец оборудования должен понимать, как повторить запуск после перезагрузки и какой файл используется. Для финансового партнёра имеют значение не только карта и память, но и подготовка среды, время восстановления и поддержка выбранной архитектуры. Эти вещи фиксируются в отчёте рядом с измерениями.

Можно выбрать маршрут для пилота на основании существующего артефакта и ресурсов машины. Результатом сравнения должен стать понятный сценарий эксплуатации, а не общий ярлык победителя для всех моделей и устройств.