# Планирование GPU-пула: когда действительно нужен следующий сервер

Как готовить расширение пула LLM-инференса по наблюдениям: профиль нагрузки, рабочая ёмкость, резерв, ограничения площадки и критерии следующего вложения.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/inference-capacity-planning/
Language: ru

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

## Опишите рабочую единицу ёмкости

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

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

[Средства бенчмаркинга vLLM](https://docs.vllm.ai/en/stable/benchmarking/) дают основу измерения. Решение, какой профиль считать полезным для продукта, остаётся отдельной задачей команды и партнёров.

## Проверьте форму спроса во времени

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

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

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

## Сравните расширение и настройку

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

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

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

## Добавьте резерв и площадку

Ёмкость всей системы нельзя считать простой суммой лучших результатов отдельных серверов. Нужно учитывать обслуживание, недоступные узлы и совместимость выбранных ролей. Конкретный резерв зависит от требований продукта.

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

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

## Зафиксируйте решение о следующем шаге

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

Перед этим посмотрите [проверку спроса](/ru/journal/model-demand-validation/), [экономику инференса](/ru/journal/inference-economics/) и [модели расчётов](/ru/journal/revenue-share/).