В этом материале
Расширение должно устранять измеренное ограничение. Сопоставляйте поток запросов, задержки и резерв с альтернативами настройки, прежде чем финансировать покупку следующего узла.
Растущий пул легко оценивать количеством карт, но этот показатель не объясняет полезную ёмкость сервиса. Следующий сервер может решить проблему очереди, добавить резерв или оказаться лишним для текущей гипотезы. Владельцу оборудования и финансовому партнёру полезно видеть, какое ограничение снимает каждый новый ресурс.
Опишите рабочую единицу ёмкости
Выберите понятный профиль: модель, формат весов, длины входа и ответа, ограничения качества и задержек. Затем измерьте, какой поток выдерживает одна конфигурация в этих условиях.
Не используйте пиковый показатель одного короткого теста как универсальную норму. Если планируется несколько классов запросов, сохраните их доли и отметьте, основаны они на наблюдениях или на предположениях.
Средства бенчмаркинга vLLM дают основу измерения. Решение, какой профиль считать полезным для продукта, остаётся отдельной задачей команды и партнёров.
Проверьте форму спроса во времени
Среднее за сутки скрывает пики и длинные перерывы. Разбейте наблюдения на согласованные интервалы и посмотрите, когда возникает очередь. Отделите разовый эксперимент от повторяющегося режима.
Для нового проекта без истории полезно построить несколько синтетических сценариев и ограничить бюджет их проверки. Не выдавайте такой прогноз за уже существующую клиентскую нагрузку.
Владельцу свободного сервера можно предложить проверяемую роль именно в нужных интервалах. Это иногда позволяет изучить гипотезу до покупки новой машины, если расписание и условия подходят.
Сравните расширение и настройку
Перед приобретением узла рассмотрите альтернативы: другой лимит параллелизма, разделение коротких и длинных задач, изменение профиля модели или более подходящее распределение существующих машин.
Для каждого варианта составьте короткую карточку: что меняется, какой результат ожидается, как проверяется успех и какие дополнительные расходы возникают. Так обсуждение финансирования становится предметным.
Если ограничение связано с сетью или медленным восстановлением, ещё одна карта не обязательно его устранит. Причина решения должна следовать из измерений, а не из удобства закупки знакомого компонента.
Добавьте резерв и площадку
Ёмкость всей системы нельзя считать простой суммой лучших результатов отдельных серверов. Нужно учитывать обслуживание, недоступные узлы и совместимость выбранных ролей. Конкретный резерв зависит от требований продукта.
Проверьте питание, охлаждение, размещение и возможности поддержки. Новый GPU может потребовать ресурса, который не был включён в его цену. Для партнёра важно видеть расходы до следующего шага, а не после доставки.
Установите порядок пересмотра плана. Если профиль работы изменился, прежнее обоснование закупки нужно обновить вместе с ограничениями сервиса.
Зафиксируйте решение о следующем шаге
Полезный итог содержит конфигурацию, бюджет проверки, срок наблюдения и условия расширения или остановки. Он не обязан обещать точный объём продаж, чтобы быть убедительным: достаточно прозрачной связи между ресурсом и проверяемой задачей.
Перед этим посмотрите проверку спроса, экономику инференса и модели расчётов.