Потребность в GPU для инференса LLM: расчет мощности

Зачем вообще считать GPU, а не брать «с запасом на глаз»

Покупка GPU «на глаз» обычно заканчивается одним из двух сценариев: либо вы переплачиваете за простаивающее железо, либо берете «впритык» и быстро упираетесь в очереди. Для инференса LLM это особенно заметно: пользователи ждут ответ сразу, и даже небольшая задержка ощущается как «сервис тормозит».

Когда мощности не хватает, деградация почти всегда идет по одному пути. Сначала растет время ответа, потом появляются обрывы по таймаутам, затем вводятся лимиты на длину ответа или число запросов. В итоге команда тратит время не на продукт, а на тушение пожаров, а бизнес слышит одно и то же: «вчера работало, сегодня медленно».

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

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

Обычно заранее смотрят:

• пиковую одновременность (сколько запросов реально генерируются одновременно);
• среднюю длину и p95 длины промпта и ответа (в токенах);
• допустимую задержку (например, «первый токен за 1-2 секунды»);
• долю «тяжелых» запросов (длинный контекст, длинные ответы).

Пример: внутренний помощник для отдела закупок. В обычное время активны 5-10 человек, но в конце месяца одновременно пишут 30, и каждый приносит длинные фрагменты текста. Если GPU подобраны «впритык», в конце месяца возникнет очередь, и люди вернутся к ручной работе.

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

Термины, без которых расчеты будут путаться

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

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

• входные токены (prompt, включая системные инструкции и историю диалога);
• выходные токены (то, что модель генерирует).

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

Два показателя, которые часто путают:

• Пропускная способность (tokens/sec) - сколько токенов в секунду система может обработать или сгенерировать. Это про «сколько всего».
• Задержка (latency) - сколько времени проходит от запроса до первых слов и до полного ответа. Это про «как быстро» для одного пользователя.

Дальше - одновременность. «Одновременные пользователи» не равны «одновременным генерациям». Пользователь может читать ответ, думать, печатать, а GPU в это время простаивает. Для планирования важнее, сколько запросов реально генерируются параллельно (и сколько из них длинные).

Длина контекста LLM - это сколько токенов модель держит «в голове»: текущий запрос плюс история, документы, инструкции. Чем длиннее контекст, тем выше потребление VRAM и тем сильнее может падать скорость. Типичная ловушка: все меряют скорость на коротких запросах, а в реальности добавляют историю чата и несколько страниц текста.

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

Какие исходные данные собрать перед расчетом

Если взять «пользователей в месяц» вместо того, сколько людей одновременно отправляют запросы, расчет почти всегда получается неверным.

Запросы измеряйте в токенах, а не в символах. И важно знать не только среднее, но и хвосты: p90/p95. Именно длинные запросы и ответы создают очереди.

Минимальный набор (лучше по логам или пилоту):

• пиковые запросы в секунду и пиковая одновременность (сколько диалогов реально генерируют ответ одновременно);
• средняя и p90/p95 длина входа и выхода в токенах;
• требования по задержкам: время до первого токена (TTFT) и время до полного ответа;
• какой контекст разрешен в продукте и какой реально используется;
• профиль нагрузки: ровный поток или короткие пики (после планерки, урока, рассылки).

Пример: внутренний помощник для службы поддержки. В обычный час работает 30 операторов, но одновременно пишут 6-8 человек, а в пике после обновления регламентов - 15. Если взять 30 как «одновременность», вы купите лишнее. Если взять 6 как «всегда», получите очереди и жалобы.

Пошаговая модель расчета по токенам и одновременности

Удобнее считать не «количество пользователей», а пиковую скорость генерации в токенах и реальную одновременность. Тогда модель прозрачна и ее легко проверить на пилоте.

Шаги расчета

1) Оцените пик по реальным генерациям.

Сколько запросов одновременно генерируют ответ. Это почти всегда меньше, чем число онлайн-пользователей.

2) Зафиксируйте цель по скорости на один запрос.

Определите, сколько output tokens/sec нужно на один запрос, чтобы задержка была приемлемой, и умножьте на одновременность.

Пример: 15 одновременных запросов x 40 ток/с = 600 output ток/с в пике.

Отдельно учитывайте входные токены: инпут «съедает» время на префилл и сильно влияет на задержку при длинном контексте. Практичная оценка выглядит так:

• нагрузка на генерацию (output ток/с),
• плюс вклад префилла (input токены на запрос x запросов в секунду),
• плюс накладные расходы на системный промпт, форматирование, безопасность и маршрутизацию.

Часто на накладные расходы уходит еще 10-25%.

3) Переведите токены/с в GPU через измерения.

Возьмите вашу модель, длину контекста и настройки (квантизация, batch, параллелизм). Прогоните тест и зафиксируйте, сколько токенов/с дает одна GPU при нужной задержке.

Формула простая:

GPU_нужно = (требуемые токены/с) / (измеренные токены/с на 1 GPU)

4) Проверьте «хвост» задержек, а не только среднее.

Смотрите хотя бы p95. Если p95 «проваливается» в пике, добавьте запас и повторите тест.

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

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

Главная причина - KV cache («кэш ключей и значений»). На каждом шаге генерации модель хранит внутренние данные по токенам контекста, чтобы продолжать отвечать связно. Этот кэш лежит в VRAM и растет почти линейно с длиной контекста и числом одновременных сессий. Поэтому большой лимит контекста бьет сразу по двум направлениям: VRAM заканчивается раньше, а tokens/sec падает из-за роста объема вычислений.

Вывод для планирования: нельзя брать максимальный контекст «как в документации» и считать, что он бесплатный. Рабочий лимит лучше выбирать под реальное поведение пользователей.

Хороший подход:

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

Если 90% чатов укладываются в 2-4 тыс. токенов, а редкие случаи уходят в 16-32 тыс., нет смысла держать максимум для всех.

Когда пользователи часто присылают длинные документы, обычно помогает комбинация мер: ограничение контекста по умолчанию, сокращение истории (последние сообщения плюс краткое резюме), RAG (подтягивать нужные фрагменты вместо всего документа), а также разделение потоков для «быстрых чатов» и «тяжелых разборов».

Для планирования мощности полезно считать несколько сценариев, а не один средний. Например, заведите два профиля: «чат 4k контекста» и «документы 16k», задайте долю запросов и целевую параллельность для каждого.

Как заложить запас под пики и не переплатить

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

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

Запас часто выбирают так:

• +20-30%: нагрузка ровная, пики редкие, короткая очередь приемлема;
• +40-60%: пики почти каждый день, важен стабильный UX;
• +80-100%: «волнами» (кампании, сезонность), возможны резкие всплески;
• дополнительно +30-50%: если ожидаете рост пользователей в ближайшие 6-12 месяцев.

Очередь запросов помогает не покупать лишнее, но у нее есть предел. Признаки, что очередь уже вредит UX:

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

Отдельно заложите резерв на деградации: обновления, перезапуски сервисов, фоновые задачи (логирование, безопасность), а также более длинные диалоги, чем вы ожидали. Если простой дорогой, часто работает стратегия N+1: один дополнительный GPU или узел в резерве, чтобы при отказе или обслуживании оставаться в целевых задержках.

Факторы, которые заметно меняют расчет

Даже аккуратная модель по токенам/сек и одновременности «плывет», если не учесть практику.

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

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

Размер модели и тип задач тоже меняют профиль: для чата важна стабильная низкая задержка, для суммаризации важны общие токены/сек, для RAG добавляется нагрузка на CPU, RAM и диски.

Параллелизм: когда нужен второй GPU

Если модель не помещается в память одного ускорителя, нужен параллелизм и более одного GPU.

• Один GPU: модель помещается и хватает производительности в пике.
• Два и больше GPU: модель не помещается или нужно тянуть высокий пик по одновременности.
• Разные GPU для разных потоков: отдельные очереди для «быстрых» и «тяжелых» запросов.

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

Частые ошибки при выборе GPU для инференса

Самая частая ошибка - считать мощность «по пользователям», а не по тому, сколько текста вы реально генерируете. Два продукта могут иметь одинаковые 200 активных пользователей, но в одном ответы по 2-3 предложения, а в другом - по странице. Потребность в GPU будет отличаться в разы.

Вторая ловушка - путать среднюю и пиковую нагрузку. Если ориентироваться на среднее, в часы пик вы получите очередь и жалобы. Если покупать строго под пик - переплатите. Лучше заранее решить, что вы делаете в пики: допускаете ли небольшую очередь, ограничиваете ли длину ответов, вводите ли приоритеты для важных запросов.

Третья ошибка - смотреть только на «токены в секунду» и забывать про контекст и KV cache. GPU может быть быстрым на коротких запросах, но упереться в память или резко замедлиться на длинных диалогах.

И еще одна частая проблема - не проверять платформу целиком. Тормозить могут:

• CPU при подготовке запросов и постобработке;
• сеть между узлами;
• диски при подгрузке моделей и логировании;
• настройки сервера и драйверов.

Наконец, многие пропускают пилот. Даже 1-2 недели теста с реальными промптами и ограничениями дают честные метрики: p95 задержки, фактические tokens/sec на ваших сценариях и потребление памяти. Без этого легко купить «впритык» или переплатить за запас, который не используется.

Короткий чеклист перед закупкой или заказом сервиса

Перед выбором GPU или расчётом бюджета на сервис проверьте, что вы считаете реальную нагрузку, а не «среднюю температуру».

Нагрузка и пики

• Есть прогноз пикового одновременного использования (не только среднее, но и p95/p99).
• Понятен профиль запросов: сколько коротких вопросов и сколько длинных диалогов в пике.
• Учтены «событийные» пики (отчетный день, рассылка, запуск кампании, начало учебного семестра).

Токены, контекст и ожидания пользователей

• Известны средние и p95 длины входа (prompt) и выхода (ответ) в токенах.
• Задан лимит контекста и политика для длинных диалогов: обрезка истории, суммаризация, отдельный «длинный режим».
• Определены целевые задержки: TTFT и время до полного ответа.
• Понятно, допускается ли очередь: например, «до 5 секунд ожидания в пике приемлемо».
• Заложен запас на рост нагрузки и сервисные операции: обновления модели, A/B тесты, мониторинг, резерв на отказ узла.

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

Если инференс планируется на своей площадке, заранее проверьте ограничения вне GPU: сеть, CPU, диски, требования к отказоустойчивости и круглосуточной поддержке.

Пример расчета на простом сценарии

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

Исходные числа:

• 400 сотрудников в компании;
• одновременно пишут 8% в пиковый момент = 32 человека;
• средний запрос: 120 токенов, средний ответ: 220 токенов;
• целевая задержка: ответ «набирается» примерно за 6 секунд.

Считаем требуемую скорость генерации в пике:

32 * 220 / 6 = около 1170 токенов/сек.

Если конфигурация в реальном профиле запросов дает 1200 токенов/сек, вы близко к цели. Если дает 800 токенов/сек, среднее время генерации станет 32 * 220 / 800 = 8,8 секунды. В пике люди начнут ждать и переспрашивать, разгоняя очередь.

Что будет, если контекст увеличить в 2 раза

Допустим, из-за длинных документов средний prompt вырастает с 120 до 240 токенов. В формуле выше это напрямую не видно, но на практике вы потеряете часть производительности и быстрее упретесь в память: длинный контекст снижает скорость и ограничивает batch.

Если из-за удвоения контекста реальная скорость упала на 25%, ваши 1200 токенов/сек превратятся в 900 токенов/сек, а задержка в пике вырастет примерно до 7,8 секунды.

Запас на «плохой день»

«Плохой день» - это больше одновременных (например, 12% вместо 8%) и ответы длиннее (например, 300 токенов вместо 220). Тогда потребность станет:

48 * 300 / 6 = 2400 токенов/сек.

Обычно разумно закладывать запас 1,3-1,7x к расчетному пику, а для критичных сервисов продумать второй узел на случай всплесков.

Следующие шаги: пилот, проверка и выбор платформы

После расчета на бумаге проверьте его на реальной нагрузке. Соберите 1-2 недели логов из текущего продукта (или проведите пилот), чтобы увидеть фактические tokens/sec, задержки и долю длинных диалогов. Часто именно редкие, но тяжелые запросы ломают красивую «среднюю» цифру.

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

Проверяйте сервер целиком, а не только GPU. Узким местом могут стать CPU, RAM, сеть, диск, а также охлаждение и питание (чтобы GPU держал стабильную частоту под длительной нагрузкой).

Для внедрения заранее подготовьте наблюдаемость: метрики по tokens/sec, алерты по росту задержки, контроль заполнения VRAM, расписание обновлений модели и драйверов.

Если нужна поставка и внедрение под ключ на своей площадке, иногда удобнее подключать системного интегратора, который собирает и балансирует весь узел (GPU, CPU, RAM, сеть, охлаждение) под ваш профиль нагрузки. Например, GSE.kz как производитель и системный интегратор в Казахстане может закрыть и серверную часть (линейка S200), и поддержку 24/7, что упрощает эксплуатацию, когда инференс становится критичным сервисом.