Сколько ускорителей нужно под инференс — как считается конфигурация
Из каких величин складывается расчёт, чем инференс отличается от обучения по требованиям к оборудованию, что учитывается при неравномерной нагрузке.
Число ускорителей под инференс считается не от размера модели, а от потока запросов и требований к времени ответа. Модель задаёт минимальную конфигурацию — сколько памяти нужно, чтобы она вообще запустилась. Поток запросов задаёт, сколько таких конфигураций должно работать параллельно, чтобы очередь не росла.
Разберём, из каких величин складывается расчёт, чем инференс отличается от обучения по требованиям к оборудованию, что учитывается при неравномерной нагрузке и какие данные нужны для подбора. Модельный ряд и конфигурации собраны на странице ускорителей MetaX.
Из чего складывается расчёт
- Объём памяти под модель. Считается по числу параметров и выбранной точности представления весов. К этому добавляется память под промежуточные состояния, объём которых растёт с длиной обрабатываемого контекста и с числом одновременных запросов.
- Минимальная конфигурация. Если модель не помещается в одну карту, она разносится на несколько. Это и есть неделимая единица обслуживания — добавлять ускорители дальше можно только такими группами.
- Производительность одной группы. Измеряется числом обработанных запросов в секунду при заданной длине входа и выхода. Цифра зависит от модели и режима, поэтому берётся из замера на целевой конфигурации.
- Целевой поток. Число запросов в пиковый час, а не среднее за сутки. Расчёт по среднему приводит к очередям в часы нагрузки.
- Требование к времени ответа. Задержка первого ответа и скорость выдачи определяют, какой размер пакета допустим. Крупный пакет повышает общую пропускную способность, но увеличивает задержку отдельного запроса.
- Запас. Закладывается на обслуживание, обновление моделей и на рост нагрузки — обычно не менее четверти расчётного числа.
Что отличает инференс от обучения по требованиям
| Параметр | Обучение | Инференс |
|---|---|---|
| Определяющая величина | время эпохи | поток запросов и задержка |
| Обмен между картами | на каждом шаге | только при разнесении модели |
| Память | веса, градиенты, состояния оптимизатора | веса и промежуточные состояния запросов |
| Режим нагрузки | постоянная загрузка | неравномерная, с пиками |
| Масштабирование | увеличением узлов под одну задачу | добавлением независимых групп |
Отсюда следует практический вывод: конфигурация, оптимальная под обучение, под инференс обычно избыточна по связи между картами и недостаточна по числу независимых групп.
Что учитывается при неравномерной нагрузке
- Пиковый и фоновый режим. Если дневной пик втрое выше ночного потока, часть карт ночью простаивает. Их можно занять пакетной обработкой — тогда расчёт ведётся по пику, а простой не пропадает.
- Несколько моделей на одном парке. Разные модели с разными требованиями к памяти размещаются по группам, а не смешиваются в одном пуле.
- Время переключения. Загрузка модели в память занимает время, поэтому частая смена моделей на одних и тех же картах снижает доступность.
- Резерв на отказ. Выход из строя одной карты выводит из работы всю группу, в которую она входит. Запас закладывается группами, а не отдельными картами.
- Очередь запросов. Механизм постановки в очередь сглаживает короткие всплески и позволяет не закладывать оборудование под редкие пики.
Требования к узлу и площадке
- Питание: потребление считается по максимальному режиму всех карт узла с учётом остальных компонентов, а не по средней загрузке.
- Охлаждение: плотная установка требует расчёта воздушного потока или жидкостного контура под фактическую плотность стойки.
- Процессор и память узла: подготовка запросов и передача данных на ускорители не должны становиться ограничением.
- Хранилище: веса моделей загружаются при запуске, и медленное хранилище затягивает ввод в работу после обслуживания.
- Сеть: при нескольких узлах балансировщик распределяет запросы между группами, и полоса до узлов рассчитывается по пиковому потоку.
- Программная часть: совместимость приложения с программным стеком ускорителей проверяется до закупки на пробной конфигурации.
Что прислать для расчёта
- Модели, которые планируется обслуживать, и их размер.
- Ожидаемый поток запросов в пиковый час и профиль нагрузки по суткам.
- Типичную длину входа и требуемую длину ответа.
- Требование к времени ответа — задержка первого ответа и общая длительность.
- Условия площадки: мощность на стойку, тип охлаждения, свободное место.
- Планы по росту нагрузки на ближайший год.
Частые вопросы
Можно ли посчитать число карт только по размеру модели? Нет. Размер модели задаёт минимальную конфигурацию, но сколько таких конфигураций нужно, определяет поток запросов и требование к задержке.
Что даёт увеличение размера пакета? Повышает общее число обработанных запросов в единицу времени, но увеличивает задержку отдельного запроса. Значение подбирается под требования сервиса.
Нужна ли быстрая связь между картами при инференсе? Нужна только внутри группы, на которую разнесена модель. Между независимыми группами обмена нет, и требования к связи снижаются.
Как закладывать резерв? Группами: отказ одной карты выводит из работы всю группу целиком. Резерв в четверть расчётного числа групп покрывает обслуживание и единичные отказы.
Что проверить до закупки? Совместимость приложения с программным стеком и фактическую производительность на целевой модели. Замер на пробной конфигурации точнее любых расчётных цифр.
Что мы делаем
Считаем конфигурацию под поток запросов и требования к задержке, а не под размер модели, подбираем число групп с резервом на обслуживание и отказы, проверяем совместимость программного стека, рассчитываем питание и охлаждение под фактическую плотность стойки. Поставляем ускорители MetaX и серверные платформы, комплектуем узлы и планируем расширение парка.
Пришлите список моделей, пиковый поток запросов и требования к времени ответа на sale@tkasiatorg.ru — рассчитаем число ускорителей под вашу нагрузку, предложим конфигурацию узла и дадим спецификацию с ценами и сроками поставки.

