H3 Max: Создан с помощью fal Inference и Training

H3 Max генерирует 5-секундное видео менее чем за 3 секунды. В ходе наших оценок предпочтений пользователей при сравнении с двенадцатью ведущими видеомоделями он занимает первое место по качеству, пониманию подсказок (промптов) и эстетике. Независимые бенчмарки от Artificial Analysis и Design Arena также ставят его на первое место. Мы уже писали о самой модели. Эта статья посвящена платформе, которая проводит ее путь от обучения до продакшена и поддерживает производительность оптимизированной по мере роста нагрузки.

Платформа fal состоит из трех взаимодополняющих уровней: fal Compute, fal Serverless и fal Model APIs.

fal Compute предоставляет инфраструктуру для обучения: кластеры из 16 и более узлов, соединенных через RDMA-сети, такие как InfiniBand или RoCE, которые арендуются для долгосрочных задач обучения.

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

Model APIs находятся на верхнем уровне: более 1300 эндпоинтов за единым интерфейсом API. Когда вы обращаетесь к minimax/h3-max/image-to-video, вы используете Model API, а очереди, автоматическое масштабирование и обработка ошибок под капотом берутся на себя.

Многие из наших клиентов проходят этот стек последовательно: обучение на Compute, развертывание на Serverless, а затем дистрибуция в качестве Model API на маркетплейсе. H3 Max прошел именно этот жизненный цикл. В этой статье рассматривается каждый его уровень по отдельности, а также методы, которые позволяют H3 Max обеспечивать две разные вещи, которые легко перепутать. Первая — это низкая задержка инференса (inference latency): сколько времени занимает одна генерация на разогретой GPU, которая уже работает. Вторая — это низкая задержка от конца до конца (end-to-end latency) в масштабе: сколько пользователь на самом деле ждет свое видео с учетом очередей и холодных стартов, добавляющихся к инференсу. Первая проблема — это преимущественно проблема модели. Вторая — проблема инфраструктуры, и именно для ее решения существует Serverless.

Движение к генерации видео с низкой задержкой и высоким качеством

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

H3 Max — первая модель в индустрии, прорвавшая этот барьер в новую зону: высокое качество и низкая задержка одновременно. На графике выше показан первый показатель из введения — задержка инференса. На дашборде fal Serverless он отображается как Request Execution на вкладке App Analytics и измеряется как время, затраченное на выполнение обработчика эндпоинта, что представляет собой инференс плюс все остальное, что делает обработчик.

Второй показатель — это задержка от конца до конца в масштабе. Когда тысячи запросов поступают одновременно — больше, чем ваша простаивающая емкость может обработать, — общее время ожидания пользователя также включает время в очереди и холодные старты. Дашборд разделяет эти части на Request Startup и Request Execution и измеряет все целиком прямо на графике End-to-End Latency, замеряя время для каждого запроса от получения до ответа. Удержание этого показателя на низком уровне при высокой нагрузке является одной из целей продукта Serverless, и это отдельная инженерная задача по сравнению с ускорением одной генерации.

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

Уровень 1: Постобучение H3 Max на fal Compute

Мы начинаем с уровня обучения. H3 Max прошел постобучение силами команды исследователей fal на fal Compute с четкой целью: минимизировать время инференса при максимизации качества. На графике задержки от конца до конца этот уровень в первую очередь влияет на Request Execution.

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

Само обучение проходило на кластере взаимосвязанных узлов GB200 NVL72 на базе fal Compute. Финальный запуск занял от недели до десяти дней; значительно больше времени ушло на эксперименты, которые сформировали его. Оптимизация внедрялась только в том случае, если модель сохраняла свои позиции в наших оценках качества. Существует множество способов сделать видеомодель быстрее, которые отлично смотрятся на графике задержки, но незаметно портят результат. От них отказались.

fal Compute — это тот же продукт, который может арендовать любая команда: взаимосвязанные кластеры, как правило, от 16 узлов и более, с полным контролем над машинами. Если ваша задача обучения переросла возможности одного узла, это тот уровень, который создан именно для этого.

Уровень 2: Инференс в масштабе с fal Serverless

Итак, вы обучили (или провели постобучение) модель. Следующий шаг — ее развертывание для обслуживания инференса в масштабе с целью минимизации задержки от конца до конца. fal Serverless дает вам набор рычагов управления для обеих частей разделения из предыдущего раздела: Request Startup и Request Execution.

Снижение влияния холодного старта

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

Это разделение показывает, на что следует обратить внимание. Ранер проходит через пять ключевых состояний на пути к обслуживанию трафика, а время от PENDING до IDLE — это задержка вашего холодного старта.

• PENDING: ожидание планирования на доступном оборудовании. fal берет этот этап на себя и не берет за него плату.
• DOCKER_PULL: образ окружения подтягивается на узел и cached. Этот этап полностью пропускается, когда образ уже находится на узле, и за него также не взимается плата.
• SETUP: контейнер запускает функцию setup() вашего приложения, загружая веса модели на GPU и выполняя любые другие действия по инициализации. Тарификация начинается с этого момента.
• IDLE: готов обрабатывать запросы, но в данный момент не выполняет генерацию.
• RUNNING: в данный момент выполняет генерацию.

На боковой панели выше показан один воркер. Вкладка воркеров также агрегирует холодные старты по всем воркерам в выбранном диапазоне, включая p50, p95, p99 и среднюю длительность по каждому состоянию. Один медленный воркер может быть исключением, поэтому этот вид показывает, какое именно состояние вносит наибольший вклад в задержку холодного старта. В разделах ниже эти состояния рассматриваются по очереди.

Получение ресурсов тогда, когда они вам нужны

PENDING — это ожидание оборудования, поэтому его минимизация сводится к тому, сколько свободных машин типа machine_type, настроенного для вашего приложения, существует. Корпоративные клиенты fal Serverless обычно организуют ресурсы на двух уровнях:

• Бронь: фиксированное количество GPU на тип машины, удерживаемое 24/7 и изолированное от общего пула. Reserved capacity eliminates pending and setup time for a guaranteed pool of GPUs, что на практике означает всегда «разогретые» воркеры, отсутствие холодных стартов на зарезервированном уровне и предсказуемую экономику единиц ресурсов.
• Масштабирование поверх этой базы в общий пул. Пул для масштабирования общий для корпоративных клиентов, поэтому производительность в нем менее предсказуема: при высокой нагрузке всплеск может ожидать в состоянии PENDING дольше, чем зарезервированные ресурсы. Цены также отличаются. Тарифы на бронь фиксируются контрактом, в то время как неконтрактное использование оплачивается по текущим ставкам, которые могут меняться. Тем не менее, механизм масштабирования обеспечивает эластичность и гибкость, которые делают продукт Serverless еще более полезным в периоды пикового трафика, запуска моделей и экспериментов в дополнение к вашей базовой брони.

H3 Max делает кое-что еще более умное. Он распределяет нагрузку между несколькими типами машин, используя паттерн многоприложенческой маршрутизации. Публичная точка входа представляет собой небольшое CPU-приложение, которое берет на себя все запросы, не требующие GPU: валидацию, расширение промптов, проверку безопасности, биллинг. Генерации выполняются на отдельных GPU-приложениях на разных типах машин, причем каждое масштабируется независимо.

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

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

Минимизация времени скачивания образа

Прежде чем воркер сможет выполнить ваш метод setup(), ноде необходим образ вашего контейнера. Часто этот этап ничего не стоит: образы кэшируются на самих машинах, планировщик отдает предпочтение нодам, на которых уже есть ваш образ, и воркер, размещенный на одной из них, полностью пропускает скачивание, отображая на странице воркеров статус «Cached» вместо длительности. Когда скачивание все же происходит, оно является многослойным, поэтому по сети передаются только измененные вами слои. Именно поэтому в примере с боковой панелью выше на DOCKER_PULL ушло всего 1,56 секунды, а руководство по оптимизации образов контейнеров рассказывает, как поддерживать это состояние. Для такого приложения, как H3 Max, обслуживающего непрерывный трафик, скачивание либо пропускается, либо представляет собой погрешность округления на фоне setup.

Минимизация времени настройки

В примере на боковой панели настройка заняла 496 секунд из 524 секунд холодного старта, и такое соотношение является типичным. Загрузка десятков гигабайт весов в GPU — это самая дорогая часть запуска любой крупной модели. Это также та часть, для которой у платформы есть больше всего механизмов. FlashPack, открытый загрузчик тензоров от fal, передает веса с диска на GPU со скоростью до 25 Гбит/с без GDS, и H3 Max поставляет каждый компонент именно так: трансформер, оба VAE и текстовый энкодер. Кэширование скомпилированных кернелов означает, что первый воркер компилирует свои кернелы torch.compile, а каждый последующий воркер загружает результат вместо повторной компиляции. И в основе обоих процессов лежит трехуровневый кэш, включающий локальный NVMe, кэш масштаба дата-центра и объектное хранилище, благодаря чему холодные старты ускоряются сами по себе по мере того, как приложение получает трафик и кэши прогреваются.

Оптимизация конфигурации автоскейлера

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

• min_concurrency поддерживает минимальное количество воркеров.
• concurrency_buffer сохраняет запасные воркеры доступными сверх текущего спроса.
• keep_alive контролирует, как долго простаивающий воркер остается активным.
• scaling_delay задерживает масштабирование вверх, чтобы кратковременные всплески трафика не приводили к немедленному созданию новых воркеров.

Вы можете настроить все четыре параметра для работающего приложения без повторного развертывания. Это позволяет настраивать ресурсы по мере того, как вы видите, как люди используют ваш продукт, вместо того чтобы пытаться предсказать характер трафика перед запуском. Что такое холодный старт GPU в Serverless? описывает эти настройки более подробно.

Минимизация задержки инференса

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

В H3 Max этот подход развит дальше благодаря многонодовому инференсу: запуску одного приложения на нескольких нодах GPU, которые представлены как единый деплоймент за одной точкой входа. Каждая нода загружает свою часть модели, а главная (leader) нода обслуживает запросы. H3 Max работает именно так на чипах GB200, поскольку модель такого размера не помещается целиком на одной ноде.

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

Наблюдение за метриками в продакшене

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

App Analytics — это сводное представление: пропускная способность, показатели ошибок и процентили задержки, разделенные на запуск запроса и выполнение запроса, чтобы вы могли с одного взгляда понять, куда уходит время. Runner Analytics — это представление для отдельного ранера: боковая панель из предыдущего раздела плюс телеметрия графического процессора в реальном времени и фильтрация по этому ранеру. Для команд со стеком наблюдаемости собственные трассировки OpenTelemetry и сбор логов экспортируют те же данные.

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

Вот как эти представления выглядят на самом H3 Max:

Расширяя границы работы в реальном времени с fal Serverless WMA

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

WMA, World Model Accelerator, — это примитив fal Serverless для обслуживания интерактивных моделей по протоколу WebRTC, который используется для видеозвонков. Клиент подключается один раз через шлюз wma.fal.run, и с этого момента ранер удерживает активную сессию: медиапотоки идут прямо к клиенту, а управляющие сообщения передаются обратно по каналу данных.

Почему бы не использовать обычные запросы или WebSocket? Запрос возвращает готовый клип. Вы отправляете его, ждете, скачиваете. Это правильная форма для одного видео и совершенно не подходящая для непрерывного потока. WebSocket удерживает соединение, но работает поверх TCP, где один потерянный пакет задерживает каждый последующий кадр, и передает «сырые» данные, поэтому вашему приложению приходится самостоятельно декодировать кадры, регулировать скорость воспроизведения и синхронизировать звук. WebRTC передает в браузер медиадорожку. Вы привязываете ее к видеоэлементу, и браузер выполняет аппаратное декодирование, контроль темпа и синхронизацию аудио и видео нативно, пропуская потерянные кадры вместо того, чтобы останавливаться на них. После рукопожатия медиаданные могут передаваться напрямую между ранером и клиентом. Одна и та же сессия подходит для любой модели реального времени, а не только для видео. Голосовая модель транслирует аудиодорожку, изображение или 3D-модель — свои кадры в виде видеодорожки, а структурированное состояние (действия, позы, обновления сцены) передается по каналу данных.

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

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

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

Уровень 3: Распространение через Model API

Последним этапом жизненного цикла является распространение, и именно по нему большинство людей знают fal. Каждый Model API на fal, включая H3 Max, представляет собой приложение Serverless, работающее в режиме совместной аутентификации на тех же ранерах, с тем же кэшированием и аналитикой, которые вы видели выше. Благодаря этому данный шаг является наименьшим техническим этапом во всем стеке. После того как совместный режим включен в вашей учетной записи, установка app_auth = "shared" позволяет другим пользователям fal вызывать ваше приложение. Публикация также включает настройку биллинга и работу с командой fal над размещением в маркетплейсе с сохранением вашей текущей реализации инференса.

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

То, что дает публикация — это дистрибуция. Ваша модель становится одной из тех, что разработчики уже интегрируют, перед существующей клиентской базой fal, и вы получаете оплату, когда приложения других людей вызывают ее. Нет необходимости создавать стек обслуживания или запускать отдельную биллинговую систему. H3 Max работает там сегодня как и minimax/h3-max/text-to-video, и в день, когда ваша модель будет готова, она сможет функционировать там точно так же.

Единый жизненный цикл и его дальнейший путь

Если посмотреть на картину в целом, три слоя образуют единый путь, пройденный последовательно. H3 Max прошел пост-обучение на Compute, в связанном кластере GB200, пока не достиг первоклассного качества при скорости выше скорости реального времени. Он был развернут на Serverless, где многоузловой инференс, FlashPack, кэширование ядер и параметры масштабирования удерживают обе составляющие его задержки на низком уровне, и где те же панели управления, которые мы использовали для его настройки, доступны любому клиенту. И он распространяется как Model API, одна из более чем 1300 конечных точек, которую можно вызвать с помощью фрагмента TypeScript в начале этой страницы. Ничто на этом пути не зарезервировано исключительно для собственных моделей fal. Это полноценный продукт от начала и до конца.

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

H3 Max — первая модель, в которой генерация работает быстрее воспроизведения при качестве передового уровня. Это первое представление о том, к чему приводит такой рубеж: видео, которое вы дорабатываете в процессе, а не ждете его создания, а также непрерывно генерируемые приложения, интерактивное видео, реагирующее на аудиторию, и миры, которые рендерятся по мере их исследования. Такая инфраструктура уже существует: , интерфейс, на котором ведет трансляции , доступна уже сегодня, и мы ожидаем, что именно на этом уровне будет строиться следующий рубеж генеративных медиа. Непрерывный запуск такой модели сегодня обходится дорого. Но это не останется дорогим навсегда. Команды, которые создают продукты под этот момент, начинают прямо сейчас, и они идут тем же путем, который только что описала эта статья: обучение на Compute, развертывание на Serverless и распространение в виде Model APIs.

Именно на это делает ставку стек fal.

Начать работу

Все описанное выше доступно уже сегодня. Выберите ту точку входа, которая соответствует вашему текущему этапу:

• Если у вас есть модель для обслуживания, разверните ее на fal Serverless. Те же воркеры, то же кэширование, те же панели управления, что и у H3 Max.
• Если вы хотите сначала ознакомиться с панелями управления, изучите демонстрацию в режиме только чтения: демонстрационный учетный запись с временными шкалами воркеров и аналитикой, которые рассматривались в этой статье. Для ее открытия необходима учетная запись fal.
• Если вам нужна только модель, , или вызовите ее с помощью фрагмента кода в верхней части этой страницы.
• Если вы занимаетесь обучением или переходите на работу в реальном времени, свяжитесь с нами по поводу Compute или создавайте проекты на базе для интерактивных сессий.