Привет, Хабр. Меня зовут Дмитрий Крюков, я инженер по разработке ПО искусственного интеллекта в YADRO. Мы продолжаем рассказывать о возможностях GPU-серверов YADRO G4208P и YADRO VEGMAN R220 G2 в работе с локальными (on-premise) LLM-моделями. Сегодня делимся результатами тестирования популярных LLM из семейства DeepSeek R1 и Qwen3 размерами от 14B до 685B параметров. Тесты проводились в условиях, максимально близких к решению реальных кейсов: чат-бот, саммаризация и автоматизация аналитических задач. 

Для тестирования мы использовали GPU-серверы из нашей актуальной линейки. Уже готовим к выходу VEGMAN R22 G3, на котором мы также планируем провести тесты и поделиться результатами.

Какие модели мы выбрали для тестов

На рынке доступны сотни моделей, которые можно использовать в типовых бизнес-сценариях. Мы выбрали локальные варианты из разных «весовых категорий»: от компактной Deepseek-R1-Distill-14B до Deepseek-R1-0528, требующей 8xH100 NVL.

Для запуска модели с полным контекстом потребуется:

★★★★★ —  более 8xH100 (здесь и далее речь о модели NVIDIA H100 PCIe 80GB)

★★★★ — 8xH100

★★★ — 4xH100

★★ — 2xH100

★ — 1xH100 

Про результаты оценки производительности GPU-сервера на задачах широкого спектра читайте в прошлой статье цикла.

Фреймворк для тестирования и конфигурация серверов

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

Мы будем использовать vLLM benchmark, большой плюс которого —  простота и прозрачность реализации. Если вы используете vLLM в своем продукте, то ваш код, скорее всего, похож на этот бенчмарк.

Конфигурации серверов:

Все зависит от задачи

На что на самом деле способен сервер под реальной нагрузкой? Сколько токенов в секунду он выдает и сколько одновременных пользовательских запросов способен обработать? Ответить на эти вопросы можно в контексте конкретной задачи, то есть с учетом характер нагрузки. Поэтому в этом разделе мы:

• Рассмотрим несколько характерных задач, которые выполняют современные LLM. 

• Обсудим, чем они отличаются друг от друга.

• Подберем набор данных, который поможет нам сымитировать нужную задачу в наших тестах. 

Задача №1: чат-бот

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

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

Еще один сервис, похожий на классический чат-бот, но все же от него отличающийся, — умный ассистент. Он обеспечивает интерактивное общение с LLM-моделью, которая умеет запоминать детали, понимать контекст нескольких сообщений подряд, выполнять команды и интегрироваться с другими сервисами. Умный ассистент, к примеру, может стать помощником сотрудника: запишет встречу в календарь, найдет нужный файл или подскажет, как создать заявку на отпуск.

Пара примеров: 

• чат-бот поддержки vLLM;

• Character.AI — role-playing чат-бот бывших разработчиков Google LaMDA.

Характер нагрузки для чат-бота или умного ассистента часто сложно предсказать. Чем дольше пользователь ведет диалог с моделью, тем больше контекст запроса, который должна обрабатывать модель. Сколько пользователей прервет диалог после первого ответа модели, а сколько продолжат задавать уточняющие вопросы или даже вступят с моделью в дискуссию? Самый надежный способ имитации нагрузки — это использование данных реальной LLM serving-системы. 

В своих тестах мы использовали датасет BurstGPT, собранный исследователями на базе реальной рабочей нагрузки LLM serving-системы.

Задача №2: автоматизация сложных аналитических задач

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

LLM-модели помогают:

• решать научные и математические задачи;

• анализировать статьи и проводить библиометрический анализ;

• планировать поставки;

• оптимизировать маршруты.

Например, DeepSeek R1 применили для планирования трехдневного путешествия по Европе с бюджетом до 2000 евро. Результаты автор описывает как «многообещающие»: система успешно создала план, хотя и выявила ограничения R1 в обработке поисковых задач и задач с памятью.

Чаще всего объем входных данных модели в таких сценариях будет значительно меньше объема выходных данных. Длина ответа непредсказуема, модель может как мгновенно ответить на вопрос, так и начать долгое рассуждение. Для имитации такого рода задач мы выбрали популярный датасет от AI-MO (Project-Numina).

Задача №3: cаммаризация

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

Также они способны выявлять ошибки в крупных базах данных: DeepSeek-R1-Distill-70B улучшает качество медицинских записей в больнице Ланьчжоу (статья на китайском). 

Для этого типа задач характерен огромный объем входных данных при небольшом объеме выходных. М�� решили воспользоваться встроенной в vLLM возможностью генерации и использования синтетических датасетов.

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

Мы использовали два основных сценария: офлайн и серверный. Расскажем о них подробнее.

Офлайн-сценарий

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

Запросы объединяются в крупные группы (батчи) для максимальной загрузки вычислительных ресурсов. Время обработки конкретного запроса в этом сценарии не критично, основная метрика производительности — общая пропускная способность (throughput), которую мы будем измерять в выходных токенах в секунду (output tokens/s). 

Примеры таких задач:

• Анализ медицинских записей пациентов: поиск ошибок в медкартах и рекомендации по диагностике.

• Обработка научных статей: извлечение ключевых тезисов, построение графиков цитирования и прочий библиометрический анализ.

• Редактирование и аннотирование автоматически транскрибированных записей: выявление ошибок транскрибации, разметка тем разговора и другая постобработка.

Серверный сценарий

Интерактивная обработка запросов в реальном времени с жесткими требованиями к задержке ответа. Запросы обрабатываются в основном мелкими батчами, чтобы минимизировать время отклика. Приоритет — минимальная задержка при максимально возможном числе одновременных пользовательских запросов. 

Для тестирования задержки (latency) мы будем поэтапно увеличивать параметр max_concurrency, который имитирует число пользователей, одновременно ожидающих ответ от системы. 

Примеры задач:

• Чат-бот поддержки: ответы на вопросы в клиентской сфере, техподдержка продуктов.

• RAG-системы: поиск ответов в корпоративных базах данных.

• Code assistance: автодополнение кода в IDE.

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

• Time-To-First-Token (TTFT) — время от отправки запроса до получения первого токена ответа.

• End-To-End Latency (E2E Latency) — время от отправки запроса до получения финального токена ответа.

• Time-Per-Output-Token (TPOT) — среднее время генерации каждого следующего токена после первого.

Сколько GPU нужно для модели

Большие современные модели, такие как Deepseek-R1-0528, требуют значительно больше памяти, чем есть на одном GPU. Модели поменьше, такие как DeepSeek-R1-Distill-32B, могут уместиться на одну серверную GPU, но часто для их исполнения используют несколько ускорителей, чтобы использовать больший контекст модели. Тут нам приходит на помощь параллелизм моделей. Так как все вычисления происходят в рамках одного сервера, мы будем использовать тензорный параллелизм (tensor parallelism, TP).

Для моделей, чье исполнение требует кратно меньше GPU, чем доступно на сервере, целесообразно развернуть несколько экземпляров.

Число экземпляров модели, доступных для запуска на серверах YADRO:

Особенности запуска DeepSeek-R1-0528

Общий размер весов модели DeepSeek-R1-0528(685B) составляет более 640 GB, поэтому ее невозможно разместить на системе 8xH100 (640 GB VRAM). Сервер G4208P имеет 8xH100 NVL (750 GB VRAM), но даже этого недостаточно, чтобы разместить модель с контекстным окном в 128K. В своих экспериментах мы снизили контекст до 32K.

Результаты тестов

Офлайн-сценарий

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

Уменьшение контекстного окна увеличивает пропускную способность?

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

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

Комментарии к таблице:

• Числовые значения в таблице указаны в токенах в секунду.

• 32/64/128k — максимальный размер контекста. 

• TP — тензорный параллелизм (1/2/4/8 — количество GPU).

Изменение производительности при уменьшении максимального контекстного окна:

Выводы раздела

По результатам запусков в офлайн-режиме отметим, что линейка серверов YADRO позволяет запускать широкий спектр моделей:

• На сервере G4208P (8х Н100NVL) возможно успешно исполнять такие модели, как DeepSeek R1 685B(fp8) и Qwen c 235B(bf16). Для моделей меньшего размера есть возможность запустить несколько экземпляров, что кратно увеличивает пропускную способность всей системы.

• Платформа G4208P (8x 4090) позволяет запускать модели размером до 70B(bf16), а платформа VEGMAN R2 модели до 32B(bf16).

Производительность сервера важно оценивать в привязке не только к модели и аппаратному обеспечению, но и к решаемой задаче. Так разница в количестве выходных токенов на одной и той же системе для задач Math&Logic и саммаризации (RANDOM 128K) может достигать 350 раз.

Серверный сценарий

Рассмотрим сценарий на примере чат-бота и решения логических задач.  На графиках ниже для каждой платформы и задачи представлена зависимость средней скорости обработки запроса (e2e latency) от числа одновременных запросов к LLM serving-системе. 

Отметим, что увеличение количества одновременных запросов приводит к росту среднего времени обработки запроса. Для больших моделей этот рост происходит быстрее из-за большего количества ресурсов, нужных для исполнения модели. Поэтому в правой части графиков отсутствуют значения для больших моделей (например, DeepSeek-R1-685B и Qwen3-235B), так как замеры с 1024 и 2048 одновременными запросами для них не проводились.

G4208P 8xH100NVL:

G4208P 8xRTX 4090:

Vegman R220 G2 2xH100:

Показатели TTFT и TPOT

Существуют и другие метрики оценки задержки (latency) в серверном сценарии. Например, разработчики MLCommons строго ограничивают максимально допустимые TTFT и TPOT для своих нагрузок:

• Для модели 70B: TTFT — 2 с, TPOT — 200 мс. 

• Для модели 405B: TTFT — 6 с, TPOT — 175 мс. 

Ниже мы добавили таблицы зависимости показателей TTFT и TPOT от количества пользователей, одновременно ожидающих ответа системы (concurrent requests).

G4208P 8xH100NVL

Прочерк в таблицах ниже означает, что замеры не производились.

BurstGPT

TTFT&TPOT для задачи chatbot, сервер G4208P 8xH100NVL:

AI-MO

TTFT&TPOT для задачи math&logic, сервер G4208P 8xH100NVL:

G4208P 8xRTX 4090

BurstGPT

TTFT&TPOT для задачи chatbot, сервер G4208P 8xRTX 4090:

AI-MO

TTFT&TPOT для задачи math&logic, сервер G4208P 8xRTX 4090:

VEGMAN R220 G2 2xH100

BurstGPT

TTFT&TPOT для задачи chatbot, сервер VEGMAN R220 G2 2xH100:

AI-MO

TTFT&TPOT для задачи math&logic, сервер VEGMAN R220 G2 2xH100:

Выводы раздела

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

В таблицах ниже указано количество поддерживаемых одновременных запросов от пользователей со средним временем обработки <30 c и <15 c на задачах chatbot и math&logic, для разных моделей и конфигураций.

Заключение

Линейка серверов YADRO позволяет решать широкий спектр задач при помощи LLM из разных «весовых категорий». Статья поможет сориентироваться в выборе модели, но важно помнить, что итоговые значения производительности будут зависеть от вашей задачи. Ниже — несколько общих рекомендаций.

Если вам требуется работать с большими моделями, такими как DeepSeek 685B, то разместить их получится на конфигурации G4208P G3 c 8х H100 NVL:

• В серверном сценарии DeepSeek 685B показал среднее время обработки запроса около 22 секунд для задачи чат-бота с 30 одновременными запросами пользователей. Первый токен ответа пришел всего через одну секунду.

• При решении логических задач DeepSeek 685B показал среднее время обработки запроса около 11 секунд с 30 одновременными запросами, а время ожидания первого токена ответа составило менее 0,2 секунды.

Запускать модели размера ~70B(bf16) можно и на системе G4208P G3 8xRTX 4090, время обработки запроса при решении логических задач в этом случае составит ~14 секунд при 30 одновременных запросов пользователей.

Для моделей размером 32B(bf16) и меньше можно использовать как VEGMAN R220, так и различные конфигурации G4208P в зависимости от нужной производительности или ожидаемого количества одновременных запросов пользователей.