Тестируем выделенный L40S и vGPU на 16 ГБ по производительности (llama.cpp, ComfyUI)

Сегодня в интернете какой только нет информации об искусственном интеллекте или его применении в разных сферах. Можно сказать, что он уже плотно вошел в обычную жизнь — многие используют ИИ в повседневной работе (и не только), а компании всё чаще внедряют нейросети для автоматизации процессов и борьбы с рутиной. Тем более, что LLM стали заметно умнее и позволяют решать самые разные задачи: проводить быстрый анализ новых направлений, искать решения типовых проблем, генерировать изображения, видео и так далее.

В мае этого года мы расширили линейку VDS с GPU и запустили тарифы с виртуальными видеокартами (VGPU). Поскольку цена на тарифы с физической (GPU Passthrough) и виртуальной картами отличается, решили сравнить их между собой. Основная цель тестирования — понять, насколько vGPU уступают в реальных задачах, а где разница не так критична, чтобы помочь своим клиентам с выбором. 

В этой статье представляем результаты нашего тестирования, которые могут пригодиться для реализации ИИ-инструментов — как нашим клиентам, так и всем, кому интересна эта тема.

Что тестируем: два стенда — Passthrough и vGPU-16

Для тестов мы взяли две конфигурации серверов. Одна — с выделенной видеокартой (GPU Passthrough), другая — с виртуальным GPU на 16 Гб. 16 Гб мы выбрали как «золотую середину» для большинства ИИ-задач (сюда помещаются многие популярные модели). Также проводили тесты на vGPU 8 Гб. Сразу стало понятно, что работать с LLM уже некомфортно и проблематично поэтому дальше vGPU-8 упоминаем, но подробно на этой конфигурации не останавливаемся.

Тестовый стенд с Passthrough:

• CPU — 16 ядер AMD EPYC 9334;

• RAM — 32 Гб;

• GPU — NVIDIA L40S, 48 Гб.

Тестовые стенды с vGPU (также на базе  NVIDIA L40S):

• CPU — 8 ядер AMD EPYC 933

• 4;RAM — 12 Гб;

• GPU — NVIDIA L40S-16Q, 16 Гб.

Конфигурации vGPU развернуты на базе NVIDIA L40S с использованием технологии виртуализации NVIDIA. Это позволяет сравнивать их на равных: разница в производительности определяется только объемом выделенных ресурсов.

Ставим CUDA и драйверы 

Изначально на сервере с выделенной видеокартой (Passthrough GPU) была установлена только стандартная ОС Ubuntu 24.04 LTS. По умолчанию в ней нет драйверов для работы с GPU, включая проприетарные от Nvidia. Поэтому требовалось установить их вручную.

apt update
apt upgrade

apt install gcc-12 g++-12

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
dpkg -i cuda-keyring_1.1-1_all.deb
apt update

apt install cuda

echo 'export PATH="/sbin:/bin:/usr/sbin:/usr/bin:${PATH}:/usr/local/cuda/bin"' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}' >> ~/.bashrc
source ~/.bashrc

nvidia-smi
lsmod | grep nvi 
nvcc -V

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

Для сервера с vGPU мы отдельно ничего не устанавливали, так как версия драйверов на гостевой ОС должна соответствовать той, что поддерживает гипервизор, и менять её нельзя. Используются только предустановленные.

На момент тестов на серверах были следующие версии: 

• драйвер NVIDIA — 570.211.01, 

• драйвер для CUDA — 12.8.

Собираем llama.cpp под GPU

Для тестирования мы выбрали llama.cpp. Он содержит встроенные стандартные тесты и может запускаться непосредственно на сервере. Такой подход снижает накладные расходы по сравнению с Docker и позволяет точнее оценить разницу в производительности между конфигурациями серверов.

Сборка на сервере с Passthrough

Перед тестированием мы загрузили исходные файлы llama.cpp и произвели компиляцию на сервере следующим образом:

apt install git cmake
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp/
cmake -B build -DGGML_CUDA=ON
cmake --build build -j$(nproc)

Сборка на серверах с vGPU

Для серверов с vGPU компиляция отличалась — нужно было явно указать, какую версию CUDA и его компилятора следует использовать:

apt install git cmake cuda-toolkit-12-8
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp/
cmake -B build -DGGML_CUDA=ON -DCUDAToolkit_ROOT=/usr/local/cuda-12.8   -DCMAKE_CUDA_COMPILER=/usr/local/cuda-12.8/bin/nvcc
cmake --build build -j$(nproc)

Также llama.cpp умеет запускать веб-сервер с чатом — это позволило нам в процессе тестирования проверить, насколько осмысленно модель отвечает на вопросы в диалоге.

Готовим ComfyUI для генерации видео 

Дополнительно мы развернули ComfyUI — бесплатный open-source интерфейс на основе узлов (nodes) для генерации изображений, видео и анимаций с помощью нейросетей. Мы выбрали его за гибкость и хорошую поддержку видеогенерации.

Кратко опишем его установку.

Ставим необходимые пакеты для создания окружения:

apt install python3-pip python3-venv

Создаем окружение, переходим в него и устанавливаем cli:

python3 -m venv comfy-env
source comfy-env/bin/activate
pip install comfy-cli
cd ./comfy-env/

Устанавливаем с помощью cli в текущий каталог:

comfy --here install

Проверяем, что ComfyUI установлен:

comfy --here which

И запускаем ComfyUI (из того же виртуального окружения):

comfy launch

По инструкции выше мы установили только панель управления. Далее нам требовалось загрузить несколько компонентов для создания видео и разместить их в необходимых каталогах. Подробные инструкции по настройке есть в документации. Отметим, что мы использовали шаблон «Wan2.2 TI2V 5B Hybrid Version Workflow Example». При тестировании ComfyUI мы сосредоточились на скорости генерации роликов.

Важный момент: для vGPU-16 запуск ComfyUI отличался. Команда для запуска:

python main.py --disable-cuda-malloc --disable-dynamic-vram

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

[ERROR] !!! Exception during processing !!! CUDA error: operation not supported
…
[ERROR] !!! Exception during processing !!! VBAR allocation failed

Также для нормальной работы на сервере с vGPU-16 пришлось добавить swap размером 10 Гб в дополнение к 4 Гб zram (устанавливается вместе с шаблоном) – иначе при запуске генерации приложение принудительно останавливалось (OOM Killer).

Методика: модели, слои, токены, замеры памяти

В этом разделе расскажем подробнее о методике тестирования: о выбранных моделях, параметрах запуска, как проводились замеры видеопамяти, о некоторых настройках llama-bench и ComfyUI.

Модели для тестирования

llama.cpp использует модели только в формате GGUF (GPT-Generated Unified Format) — это современный бинарный формат файлов для хранения больших языковых моделей, оптимизированный для быстрого вывода на конфигурациях CPU + GPU. Модели загружались с сайта huggingface.co. 

Для тестирования использовались следующие модели:

• qwen2.5-1.5b-instruct-fp16

• qwen2.5-14b-instruct-q3_k_m (состоит из 2-х частей – 1 и 2)

• qwen2.5-14b-instruct-q4_0 (состоит из 3-х частей – 1, 2 и 3)

• Qwen3.6-35B-A3B-APEX-I-Mini

• Qwen3.6-35B-A3B-APEX-Compact  

• Qwen3.6-35B-A3B-APEX-Balanced

Из списка видно, что использовались модели серии Qwen — они популярны и работают довольно быстро. Также для проверки влияния архитектуры на ресурсы сервера мы взяли  модели версий 2.5 и 3.6.

Подготовка моделей (сборка из частей)

Некоторые модели состоят из нескольких файлов. Перед использованием мы собрали их в один файл с помощью утилиты llama-gguf-split (компилируется при сборке вместе с llama.cpp). 

Команда для сборки частей:

/path/to/bin/llama-gguf-split --merge /path/to/FIRST_PART /path/to/OUTPUT_FILE

Где:

/path/to/FIRST_PART — путь к первой части модели,

/path/to/OUTPUT_FILE — путь к получаемой целой модели.

Пример для модели qwen2.5-14b-instruct-q4_0:

~/llm_models# ../llama.cpp/build/bin/llama-gguf-split --merge ./qwen2.5-14b-instruct-q4_0-00001-of-00003.gguf ./qwen2.5-14b-instruct-q4_0.gguf
gguf_merge: ./qwen2.5-14b-instruct-q4_0-00001-of-00003.gguf -> ./qwen2.5-14b-instruct-q4_0.gguf
gguf_merge: reading metadata ./qwen2.5-14b-instruct-q4_0-00001-of-00003.gguf done
gguf_merge: reading metadata ./qwen2.5-14b-instruct-q4_0-00002-of-00003.gguf done
gguf_merge: reading metadata ./qwen2.5-14b-instruct-q4_0-00003-of-00003.gguf done
gguf_merge: writing tensors ./qwen2.5-14b-instruct-q4_0-00001-of-00003.gguf done
gguf_merge: writing tensors ./qwen2.5-14b-instruct-q4_0-00002-of-00003.gguf done
gguf_merge: writing tensors ./qwen2.5-14b-instruct-q4_0-00003-of-00003.gguf done
gguf_merge: ./qwen2.5-14b-instruct-q4_0.gguf merged from 3 split with 579 tensors.

Тестирование llama.cpp

Запуск каждого теста выполнялся из каталога ~/llama.cpp/build/bin c помощью бинарного файла llama-bench, который был создан на этапе подготовки к тестированию.

Команда для тестирования генерации токенов:

./llama-bench -m /path/to/model -p 0 -n 1024 -ngl 0,1,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95 

Поясним некоторые параметры:

-n – количество токенов для генерации;

-ngl – количество слоёв модели, загружаемых в gpu;

-p – количество загружаемых токенов. В тестах было установлено 0 – то есть никакой промт не загружался.

Как вы можете видеть, тесты на генерацию токенов производились без загрузки токенов – только чистая генерация. Тесты замеряли скорость генерации новых токенов после загрузки модели, с постепенным увеличением количества слоёв, загружаемых в память GPU. Таким образом, мы постепенно шаг за шагом «догружали» модели в GPU, проводя тесты. Тем самым разгружали RAM и CPU, задействуя всё больше ресурсов видеокарты и изменяя количество слоёв ngl от 0 (видеокарта почти не используется) до 99 (хотя покажем далее, что это было избыточным). И при каждом значении ngl модель генерировала 1024 токена, кроме запуска Qwen3.6-35B-A3B-APEX-Balanced для VGPU-16.

Для него использовалось только 128 токенов, так как на начальных этапах (когда GPU почти не задействован) работа проводится лишь с использованием ядер сервера – у VGPU-16 8 ядер, и скорость генерации получалась очень низкой. К тому же для моделей на сервере vGPU-16 не получилось полностью выгрузить модели этой серии полностью.

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

Ссылка на документацию llama-bench — можно посмотреть подробнее о параметрах и форматах вывода. 

С помощью генерации с llama-bench мы старались количественно оценить возможности работы сервера с разными моделями. Но они не отражают и не показывают, какие именно рассуждения и ответы реально генерирует модель. Поэтому также в дополнение к чисто «синтетическим тестам» запустили llama.cpp как веб-сервер с чатом — для взаимодействия с моделью через браузер. 

На этапе тестирования стало очевидно, что скорость генерации ответов ИИ практически полностью соответствуют результатам llama-bench. По этой причине мы запускали все модели в интерактивном режиме только для VDS с Passthrough — для демонстрации работы и оценки осмысленности ответов моделей. 

Всем моделям задавался следующий вопрос: «Расскажи, кто ты и что умеешь. Расскажи об этом в 200 словах». 

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

Как замеряли потребление памяти во время тестов

Значения использования памяти снимались через nvidia-smi параллельно с работой llama.cpp раз в 20 секунд. При формировании графиков из полученных значений брались только повторяющиеся значения — именно они показывают использование памяти в устойчивом режиме работы. Поэтому переходные изменения потребления памяти в них не не отражены.

Тестирование ComfyUI

Как мы уже упоминали ранее, тестирование ComfyUI проводилось с шаблоном «Wan2.2 TI2V 5B Hybrid Version Workflow Example», который позволяет генерировать короткие ролики по текстовому описанию.

Измеряли среднее время генерации видео для роликов 5, 10 и 15 секунд. Для каждой длительности видео было проведено порядка 4-5 генераций в разное время для уточнения результатов.

Дополнительно: в шаблоне есть опция референсных изображений, но при проведении тестов мы её не использовали.

Результаты тестирования

В этом разделе собрали все результаты тестирования: графики llama-bench (память и скорость генерации), живые ответы моделей в веб-чате, а также замеры генерации видео в ComfyUI. Сначала покажем результаты для Passthrough, затем — для VGPU-16, а после — сравним обе конфигурации между собой.

Passthrough: полный доступ к ресурсам — что даёт

На VPS с Passthrough объём видеопамяти позволил загрузить все модели целиком, поэтому сначала покажем использование ресурсов сервера в этих случаях.

На графике выше вы можете видеть, сколько памяти занято при различной степени загрузки моделей в GPU (напоминаем, что количество слоёв ngl варьируется от 0 до 99). То есть отдельной точкой на графике можно считать установленное значение памяти vRAM от степени загрузки модели в видеопамять при генерации 1024 токенов.

Здесь уже показана скорость генерации токенов моделями также в зависимости от степени загрузки модели в GPU. То есть кривые отражают, как быстро работает модель при различной степени загрузки в vRAM (ngl). 

Вот некоторые выводы, к которым мы пришли, анализируя данные:

1. Чем больше исходная модель, тем больше используется памяти GPU (что довольно очевидно, но стоит об этом упомянуть).

2. После некоторого значения загруженных слоев наступает насыщение («плато»), и дальнейший рост слоёв не влияет на скорость как генерации и использования памяти, так и загрузки контекста. 

3. Модели одной серии выходят на «плато» при одном и том же значении загруженных слоёв. Таким образом, можно считать, что модель в этот момент полностью использует предоставленные ресурсы. 

   Например:

   • для моделей Qwen3.6-35B-A3B-APEX-* —  ~45 слоёв, 

   • для моделей  qwen2.5-14b-instruct* —  ~50 слоёв, 

   • для qwen2.5-1.5b-instruct-fp16 — ~30 слоёв. 

   Максимальное использование памяти видеокарты:

4.Все кривые для одной модели похожи по поведению использования памяти. Отличаются только значения. Только у модели Qwen3.6-35B-A3B-APEX-* характерны небольшие задержки на 5-10 слоях, чего нету у других моделей. А переход  на «плато» ( 45-50 слоёв) —  менее крутой.

5. Графики использования памяти не начинаются с нуля. Значит, даже при указании на тестирование без загрузки слоев память GPU всё также используется на сервере, хоть и в минимальных пределах.

VGPU-16: золотой баланс или вынужденный компромисс?

Теперь приведем аналогичные полученные зависимости для vGPU-16. На графиках ниже — использование памяти vGPU-16 и скорость генерации токенов для разных моделей:

Кривые также отражают, сколько памяти занято при различной степени загрузки моделей в GPU для разных ngl – от 0 до 99.

На графиках видно, что модели Qwen3.6-35B-A3B-APEX-* не смогли полностью загрузиться в видеопамять и работали только в «смешанном» режиме CPU + GPU.

Ошибки выделения памяти возникали при загрузке:

• 45 слоёв для Mini,

• 40 слоёв для Compact,

• 25 слоёв Balanced. 

llama.cpp пытался получить больше памяти, чем доступно на сервере. Однако сами зависимости по своей форме и значениям практически не отличаются от Passthrough.

Сравнение конфигураций между собой

Чтобы убедиться в том, что модели ведут себя одинаково на разных конфигурациях, приведем для сравнения зависимости для qwen2.5-1.5b-instruct-fp16 — эта модель запускалась и работала на всех конфигурациях:

Графики проходят очень близко к друг другу, и полная загрузка модели проходит при тех же значениях загруженных слоёв (ngl) в видеопамять. Использование видеопамяти зависит только от самой модели и не зависит от конфигурации сервера. При детальном рассмотрении скорости генерации в начале кривых (до 20-30 слоёв)  наблюдается меньшая скорость – в этих режимах активно используются ядра процессора сервера, и чем слабее конфигурация, тем медленнее работает модель.

Также приведем сравнение скорости генерации для моделей qwen2.5-14b-instruct-q3_k_m и qwen2.5-14b-instruct-q4_0 при тестах на Passthrough и GPU-16:

Как и в предыдущем случае, при малом использовании GPU и активной работе на CPU сервер с большим количеством ядер (Passthrough — 16 ядер, VGPU-16 — 8 ядер) имеет более высокую скорость генерации токенов. При полной загрузке моделей в видеопамять разница исчезает.

Загрузка CPU и GPU (только для vGPU)

Также дополнительно для конфигурации с vGPU мы записали использование CPU  и GPU в процентах во время проведения тестов. Было интересно узнать, как используются ресурсы CPU и GPU в разных режимах. По полученным значениям построены графики, показывающие процент загруженности CPU и GPU в зависимости от количества загруженных слоёв модели. То есть каждая точка на кривой отражает процент загрузки ядер CPU и GPU в зависимости от степени загрузки модели в видеокарту (ngl). 

Результаты для моделей серий qwen2.5* — ниже:

Кривые использования CPU (в процентах от максимально доступных ресурсов) указаны с префиксом cpu_* для различных моделей, кривые  GPU — с префиксом gpu_*. 

Чем больше слоёв (ngl) загружено в GPU, тем выше загрузка его ядер — кривые gpu_* восходящие. И наоборот: загрузка CPU при этом падает — кривые cpu_* нисходящие. Значение на кривой, где модель полностью помещается в видеопамять, соответствует ранее описанному «плато».

На графиках отлично видно: при работе модели qwen2.5-1.5b-instruct-fp16 до 30 слоёв процессор сервера загружен полностью — даже несмотря на постепенный рост использования GPU. Та же тенденция у моделей qwen2.5-14b-instruct-q3_k_m и qwen2.5-14b-instruct-q4_0, лишь с одним отличием — «плато» для них возникает при 40-50 слоях.

Тесты llama-server: живые ответы моделей

Ниже — ответы моделей в веб-чате llama-server.

Реализация чата llama.cpp удобно отображает скорость генерации, и она, в целом, соответствует результатам  llama-bench.

Сводная таблица по полученным значениям:

При сопоставлении скорости генерации токенов с предыдущим тестом скорость ответа от моделей соответствует ранее полученным результатам. Также наблюдается интересный момент по самим ответам – количество генерируемых моделью серии Qwen 2.5 значительно меньше, чем Qwen 3.6. Это связано с тем, что модель при ответе пользователю проводит рассуждения (на картинках выше скрыто под «плашкой Reasoning») и только потом даёт окончательный ответ.

Тесты создания видео: генерация видео

Теперь переходим к результатам генерации видео.

Сводная таблица результатов генерация видео для Passthrough:

Сводная таблица результатов генерация видео для vGPU-16:

Выводы и интересные наблюдения:

1. Время генерации видео для Passthrough значительно меньше, чем для vGPU – для самого короткого видео разница двукратная при сравнении конфигураций.

2. Для Passthrough не требуется использовать дополнительные флаги при запуске приложения и/или добавлять swap (рассказывали об этом в разделе подготовки к тестированию) – видеопамяти хватает и подобных проблем не наблюдается как на vGPU.

3. Время генерации видео растет пропорционально времени – для создания ролика в 15 секунд нужно затратить приблизительно в 3 раза больше времени, чем для создания 5-секундного для vGPU.

4. Для Passthrough эта разница значительно больше — приблизительно  в 5 раз  при сравнении самого малого видеоролика с самым длительным. Разница между роликом средней продолжительности и 5-секундным также двукратная, как и у vGPU.

   

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

6. Если уменьшить количество проходов (во всех случаях использовалось значения 20), то можно добиться и большей скорости, но при этом будет страдать качество.

Итоги: какой GPU брать и когда

Мы рассмотрели и провели тестирование 2 различных конфигураций VDS с GPU: Passthrough и vGPU-16. 

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

Из результатов по vGPU видно, что vGPU-16 уверенно работает со всеми малыми моделями. Модели довольно крупные запускаются, но только в смешанном режиме CPU+GPU (со снижением скорости). Для некоторых практических задач с невысокими требованиями к ресурсам этого должно быть достаточно. VGPU-16 также позволяет запустить ComfyUI, но с некоторыми ограничениями: например, пришлось добавлять большой swap и менять режимы работы приложения, чтобы добиться корректной работы.

Итак, к чему мы пришли в  итоге.

Passthrough даёт полный доступ к видеокарте и показывает высокую производительность. Он подходит для генерации видео, работы с объемными моделями (35B+), а также для задач, где важна любая версия драйверов и CUDA. Высокая цена — плата за максимум возможностей.

vGPU — это компромисс между ценой и производительностью. Он умеет работать с малыми и средними моделями (до 14B), справляется с большинством LLM-задач: чат-боты, генерация текста, несложная аналитика. Но упирается в ограничения, например, требует дополнительных настроек, а крупные модели (35B+) работают медленно или вообще не запускаются. По сути, VGPU — это оптимальный баланс цены и скорости для некритичных и небольших задач.

Стоит ли переплачивать за Passthrough? Да — если проект приносит деньги или нужна стабильная высокая скорость. Нет — если вы на этапе прототипа или бюджет ограничен начните с VGPU-16 и масштабируйтесь позже.

Автор текста: Дмитрий, системный администратор FirstVDS

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.