Сервер для LLM-инференса: как рассчитать конфигурацию под пользователей, контекст и задержку

Сервер для LLM-инференса рассчитывают не только по размеру модели. Сначала определяют реальную длину входных запросов и ответов, пиковую частоту обращений, число одновременно обрабатываемых запросов и допустимую задержку. Затем отдельно считают память под веса модели и KV-кэш, оценивают поток токенов и только после этого выбирают GPU, CPU, RAM, NVMe и сеть. Небольшому внутреннему чат-боту может хватить одного ускорителя, а та же модель с длинным контекстом и десятками активных диалогов потребует нескольких GPU или серверных реплик.

Модель + контекст + активные запросы + целевая задержка + резерв = конфигурация сервера.

Сама модель может полностью помещаться в видеопамять, но сервис всё равно начнёт отклонять запросы при росте нагрузки. Причина в том, что память расходуется не только на веса. Значительную часть занимают KV-кэш, временные буферы, служебные структуры и данные программной среды.

Число пользователей само по себе тоже мало что говорит. Сто сотрудников, которые обращаются к чат-боту несколько раз в день, создают иную нагрузку, чем двадцать клиентов, одновременно отправляющих объёмные документы и ожидающих развёрнутые ответы.

Почему размера модели недостаточно

При выборе сервера нужно проверить четыре независимых ограничения.

Вместимость

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

Задержка и пропускная способность

Пользователь сначала ждёт обработки контекста и первого фрагмента ответа, затем — дальнейшей генерации. Тест с контекстом в 500 токенов нельзя переносить на нагрузку в 8 000 или 16 000 токенов.

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

Масштабирование

Возможны три схемы:

1. Одна модель разделена между несколькими GPU.
2. Запущено несколько независимых копий модели.
3. Модель или реплики распределены между серверами.

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

Какие данные нужны для расчёта

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

Контекст измеряют токенизатором конкретной модели. Пересчёт по символам или словам неточен: разбиение зависит от языка и словаря.

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

Как рассчитать память под веса модели

NVIDIA H200 — пример серверного GPU с большим объёмом высокоскоростной памяти. Источник: NVIDIA.

Источник изображения: NVIDIA

Предварительный объём весов определяют по формуле:

Память весов ≈ число параметров × число бит на параметр ÷ 8

Для быстрой оценки:

• 7 млрд параметров в 16-битном формате — около 14 ГБ;
• 14 млрд — около 28 ГБ;
• 32 млрд — около 64 ГБ;
• 70 млрд — около 140 ГБ;
• 70 млрд в 8-битном формате — около 70 ГБ;
• 70 млрд в 4-битном формате — около 35 ГБ.

Это теоретический размер самих весов. Рекомендации Hugging Face по оптимизации инференса рассматривают квантование и другие способы уменьшить расход памяти, но итоговый объём сервиса определяется не одной формулой.

К весам нужно добавить:

• шкалы и метаданные квантования;
• временные тензоры и рабочие области библиотек;
• память под графы выполнения;
• KV-кэш;
• структуры планировщика;
• фрагментацию;
• резерв для стабильной работы в пиковых нагрузках.

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

Что меняет квантование

Перевод весов с 16 до 4 бит теоретически сокращает их объём примерно в четыре раза, однако общий расход памяти уменьшается не настолько сильно. KV-кэш может храниться в 16- или 8-битном формате, а буферы и часть операций — использовать более высокую точность.

Есть и другие ограничения:

• разные модели по-разному теряют в качестве;
• формат должен поддерживаться выбранной средой и GPU;
• 4-битная модель не обязательно работает быстрее 8-битной;
• преобразование форматов иногда уменьшает выигрыш в производительности;
• у моделей со смесью экспертов в памяти обычно хранятся все веса экспертов, хотя для одного токена активна только часть.

Квантование прежде всего решает задачу вместимости. Его влияние на качество и скорость проверяют на рабочих запросах.

KV-кэш: как контекст и параллельные запросы расходуют память

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

Кэш растёт вместе с последовательностью и существует отдельно для каждого активного запроса. В него входят токены входного контекста и уже созданная часть ответа.

Для распространённых трансформерных архитектур используют приближённую формулу:

KV-кэш = 2 × число слоёв × число KV-голов × размер головы × байт на элемент × токены × активные последовательности

Множитель 2 учитывает ключи и значения. Число KV-голов нужно брать из конфигурации модели, а не заменять общим числом голов внимания. Возможности постраничного размещения, повторного использования блоков и ограничения кэша описаны в документации TensorRT-LLM.

Пример для условной модели на 70 млрд параметров

Возьмём архитектуру:

• 80 слоёв;
• 8 KV-голов;
• размер головы 128;
• 2 байта на элемент.

На один токен одной последовательности потребуется:

2 × 80 × 8 × 128 × 2 = 327 680 байт, или примерно 0,3125 МиБ.

Отсюда:

• 8 192 токена занимают около 2,5 ГиБ на одну последовательность;
• 16 384 токена — около 5 ГиБ;
• 16 последовательностей по 8 192 токена — около 40 ГиБ;
• 32 последовательности по 16 384 токена — около 160 ГиБ.

Веса модели в 4-битном формате теоретически занимают около 35 ГБ. Но при шестнадцати длинных одновременных запросах сумма весов и KV-кэша уже приближается к 75 ГБ без буферов и резерва. На ускорителе с 80 ГБ такая конфигурация окажется у границы вместимости, хотя сама модель в состоянии покоя занимает меньше половины памяти.

Обычно расход KV-кэша уменьшают несколькими способами:

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

Для RAG особенно важно контролировать число и размер найденных фрагментов. Передача всех результатов поиска подряд увеличивает и KV-кэш, и время обработки входа. Дополнительное ранжирование часто выгоднее простого увеличения контекста.

Как перевести число пользователей в активные запросы

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

Активные запросы ≈ пиковая частота поступления × среднее время обработки

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

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

Тысяча сотрудников может давать два-три активных диалога, а несколько крупных клиентов API — постоянно держать десятки последовательностей.

Какие показатели задержки измерять

В LLM-сервисе нет одной универсальной задержки. Для интерактивного приложения важны три показателя.

Время до первого токена

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

Задержка между токенами

Она показывает плавность дальнейшей генерации. На неё влияют размер модели, пропускная способность памяти GPU, пакетирование, конкуренция запросов и обмен между ускорителями.

Полное время ответа

Оно зависит и от скорости генерации, и от длины результата. Поэтому конфигурации сравнивают при одинаковом распределении входа и ответа. Метрики LLM-инференса разделяют время до первого токена, интервалы генерации, полную задержку и пропускную способность.

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

Полезнее считать запросы, которые завершились с соблюдением заданных ограничений. Например, учитывать только ответы с первым токеном быстрее двух секунд и допустимыми интервалами генерации. Такой подход применяется в GenAI-Perf.

Какие компоненты сервера определяют результат

Dell PowerEdge XE9680.

Источник изображения: infohub.delltechnologies.com

GPU и видеопамять

При выборе ускорителя оценивают:

1. Объём и пропускную способность видеопамяти.
2. Производительность в формате модели.
3. Способ связи между несколькими GPU.
4. Энергопотребление и требования к охлаждению.

Объём определяет, поместятся ли веса, KV-кэш и буферы. Пропускная способность памяти особенно важна при последовательной генерации. Несколько GPU не образуют автоматически общий пул: модель должна быть разделена программной средой, а данные — передаваться между ускорителями. Обычный PCIe и высокоскоростной интерконнект могут дать разную задержку при одинаковом суммарном объёме памяти.

Центральные процессоры

CPU обслуживают токенизацию, API, маршрутизацию, сетевые операции и часть RAG-конвейера. При обработке документов они также выполняют распаковку, преобразование форматов и разбиение текста.

Помимо числа и производительности ядер важны:

• линии PCIe;
• расположение GPU относительно процессорных сокетов;
• пропускная способность памяти;
• NUMA-топология;
• число доступных накопителей и сетевых адаптеров.

Для плотных конфигураций рассматривают серверы на AMD EPYC и серверы на Intel Xeon. Выбор делают по топологии платформы, совместимости с ускорителями и программным стеком, а не только по названию процессора.

Оперативная память и NVMe

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

NVMe влияет прежде всего на холодный запуск, смену моделей, RAG-индексы и пакетную обработку. Если генерация, база векторов и индексация работают на одном сервере, их ввод-вывод желательно разделить по накопителям или пулам.

Сеть

Для текстового API клиентский канал редко является главным ограничением. Сеть становится критичнее, когда база векторов находится на другом узле, модель распределена между серверами или несколько узлов обмениваются большими объёмами данных. Важны не только гигабиты в секунду, но и задержка и стабильность.

Питание, корпус и охлаждение

Нужно проверить:

• форм-фактор и мощность поддерживаемых GPU;
• райзеры, кабели и расстояние между картами;
• суммарное потребление;
• допустимую мощность питания стойки;
• сохранение частот при длительной нагрузке;
• работу при отказе блока питания.

Для нескольких полноразмерных ускорителей удобнее специализированные платформы. В линейках Dell PowerEdge 16-го поколения и Dell PowerEdge 17-го поколения есть системы разного класса, но совместимость проверяют по конкретному корпусу, типу GPU и тепловому пакету.

Почему программная среда не менее важна, чем оборудование

Одинаковые GPU могут показывать разную производительность из-за планировщика и управления памятью. Современные среды инференса используют:

• непрерывное пакетирование;
• постраничное выделение KV-кэша;
• кэширование общего начала запросов;
• обработку длинного контекста частями;
• квантование;
• разделение модели между GPU;
• несколько реплик;
• спекулятивную генерацию;
• отдельные очереди для интерактивных и фоновых задач.

Такие функции представлены в документации vLLM, но каждая оптимизация имеет ограничения. Кэширование общего начала полезно только при повторяющемся префиксе. Крупные пакеты повышают общий поток, но могут ухудшать ожидание первого токена. Разделение модели добавляет обмен между GPU, а спекулятивная генерация требует дополнительной памяти. Настройки выбирают по измерениям на рабочей нагрузке. (vLLM)

Расчёт конфигурации по шагам

Сначала фиксируют точную модель, формат весов и архитектуру внимания. Затем:

1. Рассчитывают теоретический объём весов и измеряют фактическое потребление после загрузки.
2. Определяют медиану, 95-й процентиль и предел для входа и ответа.
3. Считают KV-кэш для типичного пика и тяжёлого разрешённого запроса.
4. Оценивают входной и выходной поток токенов.
5. Выбирают разделение модели или независимые реплики.
6. Проверяют результат нагрузочным тестом после прогрева.

Входной и выходной поток считают отдельно:

Входные токены/с = запросы/с × средняя длина входа

Выходные токены/с = запросы/с × средняя длина ответа

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

Пример расчёта 70B-модели

Исходные данные:

• 70 млрд параметров;
• 4-битные веса;
• средний вход — 4 000 токенов;
• 95-й процентиль — 8 000;
• средний ответ — 300;
• один запрос в секунду;
• около 20 активных последовательностей;
• 16-битный KV-кэш из примера выше.

Веса занимают теоретически около 35 ГБ. KV-кэш для одной последовательности на 8 000 токенов — примерно 2,44 ГиБ, а для двадцати — около 48,8 ГиБ. Сумма уже превышает 83 ГБ без квантовочных метаданных, буферов и резерва.

Один GPU на 80 ГБ такую нагрузку на 95-м процентиле не гарантирует. Возможны несколько решений:

• ускоритель с большей памятью;
• два связанных GPU;
• меньший предел контекста;
• меньше активных последовательностей на реплику;
• отдельный пул для длинных запросов;
• несколько реплик с распределением пользователей.

Поток составит около 4 000 входных и 300 выходных токенов в секунду. Эти числа задают профиль теста, но не предсказывают задержку конкретного GPU: её измеряют на выбранной модели и программной среде.

Конфигурация для разных задач

Внутренний чат-бот

Для небольшого корпоративного помощника иногда достаточно одного GPU на 24–48 ГБ, если модель компактна, история ограничена, а одновременных диалогов мало. Если простой недопустим, нужна вторая реплика, даже когда производительности одной хватает.

RAG-система

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

API для продукта

Масштабируют не «количество GPU вообще», а реплики с измеренной полезной производительностью. Для клиентов задают пределы входа, ответа и параллельности. Обновление без простоя требует дополнительной прогретой реплики.

Пакетная обработка

Здесь допустима большая задержка отдельной задачи, поэтому пакетирование можно делать агрессивнее. CPU и NVMe должны подавать данные достаточно быстро, чтобы GPU не простаивал. Фоновую очередь лучше отделять от интерактивной.

Многопользовательская платформа

Несколько моделей и адаптеров конкурируют за видеопамять. Нужны отдельные пулы, квоты по токенам и параллельности, маршрутизация по длине контекста и резерв на отказ узла. Часто выгоднее использовать несколько независимых реплик, а не объединять все GPU под одну модель.

Несколько GPU или несколько серверов

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

Несколько реплик предпочтительнее, если модель помещается на одном GPU, но нужно обслуживать больше пользователей. Такая схема проще масштабируется - добавлением ещё одной реплики, позволяет обновляться без полной остановки и сохраняет работу при отказе одного ускорителя.

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

Ошибки при расчёте

Чаще всего конфигурацию недооценивают, потому что:

• считают только файл весов;
• используют среднюю нагрузку вместо пиков;
• умножают максимальный контекст на всех зарегистрированных пользователей;
• забывают о KV-кэше и длине ответа;
• сравнивают тесты с разными входами;
• занимают весами почти всю видеопамять;
• считают 4-битную модель автоматически в четыре раза быстрее;
• смешивают индексацию RAG и интерактивный API;
• игнорируют PCIe-топологию, питание и охлаждение;
• тестируют систему одним коротким запросом;
• не предусматривают резервную реплику.

Сервер для LLM-инференса выбирают в следующем порядке: описывают профиль нагрузки, считают веса и KV-кэш, определяют поток токенов, выбирают схему GPU и только затем комплектуют CPU, RAM, NVMe, сеть и корпус. Расчёт памяти отвечает на вопрос, поместится ли нагрузка. Ответ на вопрос о задержке и количестве пользователей даёт нагрузочный тест конкретной модели в выбранной программной среде.