LLM inference на отечественном GPU: тестируем llama.cpp и vLLM на серверах с Angara

У одного из наших заказчиков появился кластер с серверами на отечественных GPU-акселераторах Angara. Не в рамках пилота «поставим и посмотрим», а как реальная корпоративная инсталляция с планами гонять на нём LLM inference для внутренних инструментов. Нас попросили оценить, насколько это вообще реально и что придётся допиливать.

Мы потратили несколько дней, прогнали стандартные бенчмарки и ряд рабочих сценариев. Результаты - честные, без PR-глянца. Сразу оговоримся: точные цифры token/s мы не публикуем по договорённости с заказчиком, но порядки и соотношения - реальные.

Стенд и конфигурация

Кластер - три сервера с отечественными акселераторами Angara на каждом узле. Для сравнения использовали референсный сервер с NVIDIA A100 80GB из собственной инфраструктуры. Всё это под управлением РЕД ОС, которая в данном окружении является базовой ОС.

Инструменты тестирования:

• llama.cpp - собрали из исходников с поддержкой соответствующего backend-а. Здесь были первые сюрпризы (о них ниже).
• vLLM - версия 0.8.x, с кастомными патчами под нестандартный backend.
• Модели - Llama 3.1 8B и 70B в квантизации Q4_K_M и Q8_0, плюс Mistral 7B для кросс-проверки.

llama.cpp: работает, но с нюансами

Первый вопрос был простой - поднимется ли llama.cpp вообще. Поднялся, но не сразу.

Первое - backend. llama.cpp поддерживает несколько backend-ов помимо CUDA: OpenCL, Metal, SYCL, Vulkan. Для Angara оказался рабочим путь через OpenCL-совместимый слой. Пришлось собирать с нужными флагами и чинить несколько ошибок линковки, характерных именно для этой конфигурации. Ничего экзотического, но документация по этому пути у llama.cpp спартанская - готовьтесь к самостоятельному исследованию.

Второе - производительность. На модели 8B Q4_K_M в режиме одного пользователя получили token/s примерно в два-три раза ниже, чем на A100. Это грубо, зависит от задачи и размера контекста, но как ориентир - вот такая картина. 70B Q4_K_M - примерно аналогичное соотношение, может чуть хуже на long-context задачах.

Третье - стабильность. За несколько дней тестирования было два крэша с невнятными ошибками из глубины OpenCL-стека. Воспроизвести детерминированно не удалось. Скорее всего драйверная история - будем следить за обновлениями.

vLLM: сложнее, но батчинг работает

vLLM интереснее для production-сценариев, где нужно обслуживать несколько запросов одновременно. Continuous batching - ключевое преимущество vLLM перед llama.cpp в серверном режиме.

Завести vLLM в штатном виде не вышло - он заточен под CUDA. Есть experimental ветка с поддержкой ROCm (AMD), и отдельные попытки сообщества сделать более абстрактный backend. Нам пришлось применять патчи, которые нашли в нескольких issue на GitHub, плюс пара исправлений своими руками.

В итоге vLLM поднялся. Batching работает. При нагрузке в 8-16 параллельных запросов на 8B модели соотношение throughput к A100 улучшилось по сравнению с одиночными запросами - это ожидаемо, GPU начинает утилизироваться лучше. Но пиковый throughput всё равно ощутимо ниже референсного A100.

Отдельная история - memory management. vLLM активно использует специфику CUDA-аллокатора, и на нестандартном backend-е периодически вылетает OOM там, где по расчёту не должен. Диагностировать сложно - стандартные GPU-инструменты мониторинга к этому акселератору не подключаются напрямую. Мы написали простой wrapper, который логирует занятость памяти через vendor API, - иначе работаешь вслепую.

MT-2000: посмотрели отдельно

На одном из узлов стоял МТ-2000 - другой отечественный акселератор, другая архитектура. Там история с запуском llama.cpp аналогичная, но через Vulkan backend. Производительность на наших тестах оказалась схожей с Angara в пределах погрешности измерений - разбираться детальнее не было задачи.

Что это значит на практике

Если коротко: инференс на отечественных GPU в 2026 году - это реально, но не «поставил и забыл».

Сырая производительность ниже A100 в 2-3x на типичных задачах. Для внутренних инструментов, где latency не критична в пределах нескольких секунд, это терпимо. Для чего-то интерактивного с требованием sub-second - надо считать.

Экосистема - главная проблема. CUDA доминирует в ML-инструментарии, и каждый компонент, который заточен под неё, придётся либо патчить, либо искать альтернативный путь. Это трудозатраты, которые нужно закладывать.

Стабильность - вопрос открытый. Несколько дней тестирования дают ограниченную уверенность. Для production нужно либо длительный burn-in, либо готовность к инцидентам и быстрому реагированию.

Мы уже думали над тем, как правильно мониторить такой inference-стек, - про наблюдаемость LLM-агентов писали отдельно, и часть тех подходов применима и здесь, хотя на GPU-уровне приходится дописывать custom collectors.