Как запускать открытые модели в продакшене, не поддерживая собственную инфраструктуру инференса09.11.2026 18:30

При поддержке Microsoft

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

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

Для технических команд это означает ответы на четыре вопроса.

1. Какая модель развертывания лучше всего подходит для рабочей нагрузки?

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

Так возникает промежуточный вариант для команд, которым нужны выделенные мощности GPU и больший контроль над конфигурацией модели и инфраструктуры, но которые не хотят самостоятельно создавать и эксплуатировать весь стек обслуживания. Managed Compute в Microsoft Foundry — один из способов решить эту задачу.

2. Как проектировать с учетом мощностей, задержки и пропускной способности?

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

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

3. Какую часть стека обслуживания вы хотите контролировать?

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

Ваша команда контролирует	Microsoft управляет значительной частью среды обслуживания
Выбор модели и ускорителя	Среда выполнения и контейнеров
Выделенные мощности	Настройка и оптимизация инфраструктуры
Рабочую точку между задержкой и пропускной способностью	Обновления ПО и среды выполнения
Масштабирование мощностей	Устранение уязвимостей и патчи безопасности

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

Поскольку managed compute является частью Foundry, разработчики также могут продолжать использовать привычные API инференса, аутентификацию, сетевые настройки, SDK и средства наблюдаемости для всех типов развертывания.

4. Какие характеристики ускорителя нужны рабочей нагрузке?

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

Хороший пример — GPU AMD Instinct™ MI300X: как вариант с большим объемом памяти в managed compute в Foundry, каждый GPU располагает 192 ГБ высокоскоростной памяти HBM3 с пропускной способностью до 5,3 ТБ/с, а на платформе из восьми GPU — 1,5 ТБ. Такой объем позволяет запускать более крупные модели на меньшем числе GPU, обеспечивая больший запас для батчинга и инференса с длинным контекстом, где веса модели и кэш «ключ-значение» (KV) конкурируют за память.

Но аппаратное обеспечение — лишь часть уравнения. Экосистема AMD ROCm обеспечивает открытый программный уровень и уровень оптимизации для AMD Instinct с широкой поддержкой открытых моделей и AI-фреймворков с открытым исходным кодом. Масштаб того, что способно дать одно лишь ПО, видно по тестам AMD Performance Labs: на системе 8× AMD Instinct MI355X полностековая программная оптимизация в ROCm 10 обеспечила в среднем в 3,3 раза более высокую пропускную способность инференса для GLM-5, Kimi-K2.5 и DeepSeek-R1–0528 по сравнению с базовым уровнем ROCm 7.0. В managed compute за непрерывную оптимизацию отвечает платформа, а не клиент.

GLM 5.3 Flash показывает, как эти характеристики превращаются в решения о развертывании. Модель с 320 млрд параметров, из которых 18 млрд активны на токен, доступна в трех конфигурациях, оптимизированных для AMD Instinct MI300X, каждая с контекстным окном 512K. Конфигурация на четырех GPU ориентирована на компактные сценарии чата, программирования и агентов, а две конфигурации на восьми GPU используют тензорный (TP), параллелизм данных (DP) и экспертный параллелизм (EP), отдавая приоритет либо параллелизму и времени до первого токена, либо запасу памяти для нагрузок с длинным контекстом.

Тот же принцип проявляется и в промышленном масштабе. AT&T использовала managed compute в Foundry для нескольких открытых моделей и архитектур GPU — около 530 GPU, включая примерно 430 GPU AMD Instinct MI300X. Одна только Phi-4 обрабатывала более 700 млрд токенов в месяц для подготовки данных и генерации синтетических данных.

Важен и выбор конфигурации. В тестах GLM 5.3 Flash на диалоговой нагрузке конфигурация на восьми GPU TP4 + DP2 + EP обеспечила примерно в 1,8 раза более высокую выходную пропускную способность, чем конфигурация на четырех GPU, при этом сократив среднее время до первого токена более чем вдвое. На других нагрузках прирост был меньше — это еще раз подтверждает, что командам нужно тестировать каждую конфигурацию на собственных нагрузках, а не принимать решения на основе флагманского GPU.

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

• Сколько GPU требуется для модели?

• Какие задержку и пропускную способность можно обеспечить в заданной рабочей точке?

• Сколько одновременных пользователей или запросов можно обслуживать при сохранении целевой производительности?

• Насколько эффективно используются выделенные мощности?

• Как потребление GPU-часов превращается в фактическую стоимость токена или единицы работы?

Продакшен начинается там, где заканчивается выбор модели

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

Для нагрузок, которым нужна выделенная инфраструктура, ключевое решение — какой контроль над моделью, ускорителем, мощностями и производительностью необходим командам без владения каждым уровнем стека обслуживания. Managed compute в Foundry предлагает один из способов найти этот баланс, а GPU AMD Instinct MI300X обеспечивают объем памяти, достаточный для запуска крупных открытых моделей на меньшем числе GPU.

Спонсорские статьи — это материалы, подготовленные компанией, которая оплачивает публикацию или имеет деловые отношения с VentureBeat; они всегда четко помечены. Для получения дополнительной информации пишите на sales@venturebeat.com.

Полный текст статьи читайте на VentureBeat.ru