Конец эпохи TGI: на что перейти — vLLM или llama.cpp? Сравнение и гайд по миграции

Свистать всех наверх: TGI больше не флагман

Год назад вы развернули свой первый LLM-сервис на TGI. Все было просто: Docker, пара флагов, и готово. Hugging Face обещал масштаб, скорость и стабильность. Но в феврале 2026-го случилось неизбежное — команда объявила, что Text Generation Inference переходит в режим поддержки. Новых фич не будет, только критические багфиксы.

Переводя с корпоративного на русский: проект признали legacy. Технический долг стал слишком велик, архитектура не тянет новые модели вроде Llama 3.3 70B с MoE-слоями, а конкуренты обогнали по всем фронтам.

Два пути: серверная пушка или локальный швейцарский нож

Основных претендентов на трон два: vLLM и llama.cpp. Они представляют разные философии, и выбор между ними — это не просто замена одной строки в Docker Compose.

vLLM: когда нужна пропускная способность, а не красота

vLLM (версия 0.6.2 на март 2026) — это инженерный подход к инференсу. Его создатели в Беркли смотрели на проблему под углом облачных провайдеров: как обслужить тысячу пользователей на одной A100, не разорившись на аренде.

Секрет в PagedAttention — алгоритме управления памятью, который работает с ключевыми кэшами как с виртуальной памятью в ОС. Результат? В 3-5 раз выше пропускная способность по сравнению со старым TGI при тех же ресурсах. Особенно для длинных диалогов.

llama.cpp: ваш пони, который умеет все

llama.cpp (на момент марта 2026 — версия 3xx, с полной поддержкой Vulkan и Apple Silicon второго поколения) — это проект для тех, кто верит в силу CPU и квантования. Его главная магия — формат GGUF. Модель в 70 миллиардов параметров весит не 140 ГБ, а 40 ГБ и шустро работает на процессоре с AVX-512.

Если vLLM — это про throughput (сколько запросов в секунду), то llama.cpp — про latency (сколько миллисекунд до первого токена) на скромном железе. Он идеален для edge-устройств, корпоративных серверов с кучей CPU и нулевыми GPU, или когда нужно запустить 10 разных моделей параллельно, не покупая десять H100.

Практика: режем продакшн, не просыпая токенов

Теория — это хорошо, но вас волнует, как перенести работающий сервис с минимальным даунтаймом. Вот план, который мы отработали на трех проектах.

1 Диагностика: что у вас сейчас работает?

Запустите бенчмарк вашего текущего TGI. Запомните три цифры: время обработки стандартного промпта (например, из вашего лога), потребление памяти GPU и 99-й перцентиль задержки. Без этого вы не поймете, стала ли миграция успешной.

# Пример: собираем метрики с TGI перед выключением
curl -X POST http://old-tgi:8080/generate \\
  -H \"Content-Type: application/json\" \\
  -d '{\"inputs\": \"Explain quantum computing in simple terms\", \"parameters\": {\"max_new_tokens\": 200}}' \\
  -o /tmp/tgi_benchmark.json
# Замеряем время выполнения через time или из логов nginx

2 Выбор движка: два вопроса, которые решат все

Задайте себе честно:

• У вас больше GPU или CPU? Если в датацентре пылятся серверы с Xeon Gold, но GPU только пара старых T4 — ваш путь llama.cpp. Если есть кластер A100/H100 — vLLM.
• Ваш сервис — это чат для сотрудников или публичное API с тысячей RPS? Для чата с 50 пользователями llama.cpp на CPU даст меньшую задержку. Для API — только vLLM.

3 Миграция на vLLM: пошаговый разбор

Допустим, вы выбрали vLLM. Вот как переехать.

Сначала скачайте модель в актуальном формате. В 2026 году многие используют не сырые веса с Hugging Face, а предварительно сконвертированные в AWQ (для vLLM) через специализированные сервисы. Это экономит время.

# Установка последней версии vLLM (март 2026)
pip install vllm==0.6.2
# Запуск сервера с поддержкой Tensor Parallelism для больших моделей
python -m vllm.entrypoints.openai.api_server \\
  --model meta-llama/Llama-3.3-70B-Instruct-AWQ \\
  --tensor-parallel-size 4 \\
  --gpu-memory-utilization 0.9 \\
  --max-model-len 16384  # Критично для новых длинных контекстов

Самый болезненный момент — API. TGI использовал свой формат запросов, vLLM по умолчанию предлагает OpenAI-совместимый эндпоинт. Вам придется поправить клиентский код. Но есть и хорошая новость: сообщество уже создало адаптеры, которые эмулируют TGI API поверх vLLM. Ищите vllm-tgi-adapter на GitHub.

4 Миграция на llama.cpp: когда GPU нет и не будет

Здесь другая история. Во-первых, вам нужна модель в формате GGUF. К счастью, в 2026 году почти все популярные модели сразу выкладываются в GGUF на Hugging Face. Если нет — конвертируйте сами с помощью llama.cpp/convert.py.

Запуск сервера еще проще. Соберите llama.cpp с поддержкой всех бэкендов (CUDA, Metal, Vulkan).

# Сборка с поддержкой GPU (пример для Linux с CUDA)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make LLAMA_CUDA=1 LLAMA_CUBLAS=1 -j
# Запуск сервера
./server -m models/llama-3.3-70b-instruct.Q5_K_M.gguf \\
  -c 16384 \\
  -ngl 99  # Загрузить все слои на GPU (если он есть)
  --host 0.0.0.0 --port 8081

llama.cpp тоже предоставляет OpenAI-совместимый API, так что смена клиента будет похожа. А если вы встраиваете движок прямо в приложение, как в нашей статье "Llama.cpp без обёрток", то миграция сведется к замене библиотеки.

Подводные камни, о которых молчат в мануалах

Что дальше? SGLang, TensorRT-LLM и другие претенденты

vLLM и llama.cpp — не единственные игроки. В 2026 году набирает обороты SGLang — движок, заточенный под сложные промпты с условиями и планированием. Он переигрывает vLLM в задачах типа "сгенерий JSON по схеме, а потом составь по нему отчет". Если у вас сложные пайплайны генерации, посмотрите наш разбор SGLang против vLLM.

Есть еще TensorRT-LLM от Nvidia — максимальная производительность на их же железе, но ценой часов компиляции модели под конкретную GPU. Идеально для статичных продакшн-нагрузок.

Мой совет? Начинайте с vLLM или llama.cpp, как с самых стабильных и документированных. Разберитесь с ними. А через полгода, когда появится время, поэкспериментируйте с SGLang для специфичных задач. Экосистема инференса меняется быстрее, чем вы успеваете прочитать этот абзац. Главное — не застрять в ушедшей эпохе.

Подписаться на канал