Мой блог
Как запустить Gemma на сервере: сравнение производительности Ollama и llama.cpp
Подробности изложены в материале первоисточника. Если изучить любую тематическую инструкцию по развертыванию языковых моделей, в которой упоминается инструмент Ollama, в комментариях обязательно найдутся сторонники llama.cpp, утверждающие, что это единственно верный путь. Я решил проверить данное утверждение на практике и запустил модель Gemma 4 обоими способами, чтобы выяснить, во сколько обходится пользовательское удобство.
За последние годы инструменты для инференса прошли большой эволюционный путь. Появившись в 2023 году как простая оболочка над llama.cpp, утилита Ollama со временем обзавелась собственным движком для мультимодальных архитектур, однако позже разработчики вновь вернулись к использованию исходного движка для работы с GGUF-форматом.



Выбор модели и подготовка сервера
Для тестирования я выбрал квантованную версию Gemma 4 26B A4B. Данная модель от Google построена на архитектуре Mixture of Experts (MoE), где для обработки конкретного запроса задействуется лишь часть доступных экспертов. Это позволяет достичь отличного баланса между точностью ответов и потреблением вычислительных ресурсов.


Конфигурация модели подразумевает 26 миллиардов параметров общих, но на каждый токен активируется около 4 миллиардов, что и отражено в аббревиатуре A4B. В четырехбитном кванте файл занимает от 14 до 18 гигабайт, поэтому в качестве рабочей площадки я задействовал облачный сервер с видеокартой NVIDIA RTX 4090 на 24 ГБ видеопамяти.

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

На этапе конфигурирования оборудования я перешел во вкладку GPU и отфильтровал доступные решения, остановившись на графическом процессоре RTX 4090. После добавления личного SSH-ключ и сохранения учетных данных суперпользователя оставалось лишь подтвердить создание инстанса.

Как только статус виртуальной машины сменился на готовность к работе, я подключился к ней по защищенному протоколу SSH и выполнил базовую диагностическую команду для проверки корректности распознавания графического адаптера.

Развертывание и настройка Ollama
Первым делом я протестировал запуск через Ollama. Главное достоинство этого инструмента заключается в сокрытии всей технической рутины от пользователя: здесь не требуется вручную компилировать исходный код или разрешать зависимости, а вся схема взаимодействия напоминает привычную работу с контейнерами Docker.


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

Загрузка весов и тестирование программного интерфейса
Интерфейс командной строки Ollama предлагает лаконичный набор привычных операторам команд вроде загрузки, запуска или удаления моделей. Для получения нужного файла я обратился к репозиторию на платформе Hugging Face.

Работоспособность локального HTTP-сервера я проверил через отправку простого запроса на получение каталога доступных файлов. В ответ система вернула корректную JSON-структуру с перечнем скачанных объектов.


Затем я отправил тестовый запрос к эндпоинту генерации чата. По умолчанию утилита отдает результат в режиме потоковой передачи чанками, однако для тестов я отключил потоковый вывод, указав соответствующий параметр в теле запроса, и получил итоговый структурированный ответ.

Развертывание и настройка llama.cpp
Второй сценарий подразумевает ручной запуск модели с использованием оригинального движка llama.cpp в строгом соответствии с официальной документацией проекта.

Сборка исходного кода
Сначала я установил необходимые инструменты для компиляции, включая систему контроля версий, утилиты сборки и компилятор. После клонирования репозитория потребовалось задействовать технологии параллельных вычислений NVIDIA CUDA для максимального ускорения работы на GPU.
Поскольку автоматический выбор образа установил лишь базовый драйвер, я проверил наличие фирменного компилятора CUDA. При его отсутствии потребовалось доустановить официальный инструментальный пакет разработчика.


Сам процесс сборки запускается через утилиту cmake с обязательным флагом активации CUDA-поддержки, иначе проект соберется исключительно в медленном варианте для центрального процессора.
Загрузка модели и запуск сервера
Инструменты llama.cpp позволяют скачивать модели напрямую из репозиториев Hugging Face с помощью специального флага. После завершения загрузки утилита открывает встроенную интерактивную оболочку, из которой можно выйти с помощью стандартных команд.
Для организации полноценного тестирования я запустил собственный HTTP-сервер llama.cpp, совместимый со стандартными спецификациями OpenAI. Чтобы обеспечить честные условия сравнения, я выделил под модель все доступные слои графического процессора и задал фиксированный размер контекста.
Успешность запуска я проверил аналогичным запросом к эндпоинту завершения чата, убедившись, что оба бэкенда функционируют идентично.
Бенчмарки и сравнительное тестирование
Для объективной оценки производительности я выделил ключевые метрики: время до генерации первого токена, мебтокеновую задержку, общую скорость генерации и полную длительность выполнения запроса. Вместо утомительных ручных проверок я применил специализированную утилиту для нагрузочного тестирования GuideLLM.
Тестирование Ollama
Для честного сопоставления контекста в Ollama я создал собственный конфигурационный файл с расширенными параметрами длины контекста, после чего сгенерировал кастомный алиас модели.
В базовом синхронном сценарии утилита выполнила тридцать последовательных запросов с тридцатью двумя тысячами входных токенов каждый. Медианное время обработки одного запроса составило около семи секунд, причем большую часть времени заняло ожидание первого токена.
Прирост параллельной нагрузки достигался путем изменения конфигурационных параметров системного сервиса и увеличения количества одновременных потоков до двух и четырех единиц.
Тестирование llama.cpp
Аналогичные тесты были проведены на сервере llama.cpp с идентичными параметрами контекста и квантования модели. Синхронный режим показал практически сопоставимые результаты при минимальном потреблении видеопамяти.
При увеличении степени параллелизма до двух и четырех одновременных потоков пропускная способность серверов возрастала, однако это неизбежно влекло за собой рост задержек для каждого отдельного запроса.
Итоги сравнения
Проведенные тесты показали, что Ollama действительно привносит определенные накладные расходы на управление инфраструктурой, но они не носят критического характера. При обработке одиночных запросов разница в производительности между двумя подходами практически стирается.
За простоту установки, удобный интерфейс управления и бесшовный запуск мы расплачиваемся несколькими процентами общей производительности. Если вам требуется максимальная гибкость или планируется запуск моделей на центральном процессоре, имеет смысл выбрать llama.cpp, однако для большинства практических задач удобство Ollama перевешивает незначительную разницу в скорости.
