«1,07x скорости воспроизведения»: Visko и Google Cloud вывели живую видеомодель Orbis на Cloud TPU за 30 дней

Что именно сделали Visko и Google Cloud

Visko — AI-стартап, который строит то, что сам называет Live Models: видеомодели мира, генерирующие картинку непрерывно и реагирующие на изменения на ходу. Флагманская модель Orbis стримит живое видео, начиная с одного текстового или графического промпта: пока поток играет, зритель может вводить новые управляющие промпты и менять сцену в реальном времени — без перезапуска и без разрыва непрерывности. Пример из публикации: сессия открывается котом, дремлющим у потрескивающего камина, и стоит зрителю попросить добавить миску еды, как миска появляется на месте, а кот потягивается, встаёт и мяукает.

Публичная демонстрация Orbis открылась 1 сентября 2026 года; возможности, на которые её ориентируют, — интерактивные развлечения, live commerce, AI-компаньоны, иммерсивное обучение и симуляция для робототехники. Чтобы такие интерактивные сессии масштабировались надёжно, в августе 2026 года Visko вместе с инженерами Cloud TPU начала переносить живой конвейер Orbis на тензорные процессоры Google, и за 30 дней полный мультимодальный конвейер заработал на TPU в реальном времени.

«Visko приносит в экосистему Cloud TPU новый класс рабочих нагрузок — реального времени и управляемых на ходу», — приводит публикация слова Dave Elliott, руководителя направления Developer Advocacy for AI в Google Cloud. Он отмечает, что совместная инженерия живого мультимодального конвейера на одном срезе TPU с использованием JAX, torchax и собственных ядер Pallas показала, как быстро небольшая команда стартапа проходит путь от прототипа на PyTorch до рендера на скорости 1,07x от воспроизведения на AI Hypercomputer от Google Cloud.

Публикация подписана двумя авторами — Will Yin, CEO Visko, и Ivan Nardini, Developer Relations Engineer в Google Cloud, — то есть описывает работу с обеих сторон партнёрства, а не только со стороны вендора.

Почему живое видео — задача с жёстким дедлайном

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

Каждый фрагмент нужно денойзить, декодировать из латентов, апскейлить до 1664x936 при 18 кадрах в секунду и снабдить сгенерированным звуком — и всё это быстрее реального времени воспроизведения, пока идёт сессия.

Две структурные сложности делают живые видеомодели куда требовательнее обычного батч-инференса. Первая — batch size 1: каждый живой поток это интерактивная сессия одного зрителя, и замаскировать задержку, сгруппировав десятки одновременных запросов в большой батч, нельзя. Вторая — строгая последовательная зависимость: каждый фрагмент напрямую зависит от предыдущего, а видеомодель держит скользящую память недавних видео-латентов, чтобы фрагмент N+1 плавно продолжал действие фрагмента N, поэтому отрендерить фрагменты заранее или распараллелить их по будущим моментам не получится.

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

Как конвейер уложился в один срез TPU

Чтобы инфраструктура оставалась компактной и недорогой по мере роста, команда выстроила живой конвейер как цепочку из трёх генеративных моделей на одном срезе Cloud TPU в точности BF16: базовая диффузионная видеомодель, апскейлер сверхвысокого разрешения и генератор звука делят одни и те же чипы и на каждом фрагменте работают по очереди.

Стек собран на трёх открытых компонентах: JAX — высокопроизводительная библиотека массивов для ускорителей, которую компилятор XLA превращает в оптимизированный машинный код; torchax — слой совместимости, запускающий модели PyTorch на Cloud TPU через JAX, чтобы команде не пришлось сразу переписывать всё с нуля; Pallas — язык программирования собственных ядер для TPU в JAX.

По итогам профилирования и оптимизации каждой стадии суммарная задержка на фрагмент уложилась в цель с запасом около 7% на разброс во время живого стриминга, а сквозная генерация пошла на скорости 1,07x от воспроизведения. Почти две трети вычислительного бюджета приходится на денойзинг видео, поэтому именно эта стадия стала главной целью оптимизаций ядер и распараллеливания.

Три оптимизации, которые дали реальное время

Ulysses context parallelism. Видеофрагмент разворачивается внутри видео-трансформера в огромную последовательность пространственно-временных токенов, и чтобы распределить эту работу по чипам TPU при batch size 1, команда применила Ulysses: между чипами разбивается не набор весов, а последовательность токенов. Непосредственно перед слоем внимания быстрый all-to-all обмен по межчиповому интерконнекту ICI пересобирает тензоры так, что каждый чип держит всю видеопоследовательность, но отвечает только за четверть голов внимания; после вычисления второй all-to-all возвращает разбиение по последовательности для feed-forward слоёв. При batch size 1 этот путь оказался быстрее и tensor parallelism, и ring attention.

Собственное ядро splash attention на Pallas. Чтобы ускорить само внимание, команда встроила кастомное ядро splash attention из MaxDiffusion — открытой референсной библиотеки Google Cloud для диффузионных моделей на Cloud TPU. Splash attention приносит на архитектуру TPU тайлинг в стиле FlashAttention: полная квадратичная матрица внимания не материализуется в HBM, а считается компактными плитками в сверхбыстрой памяти на кристалле VMEM, и то же ядро можно забрать в собственный конвейер файлом custom_splash_attention.py.

Аудиомодель — в нативный JAX. Все три модели Orbis сначала перенесли на Cloud TPU через torchax; для видео и апскейлинга связка torchax с ядрами внимания Pallas сразу уложилась в цель по задержке, и обе модели в финальном конвейере остались на torchax, а переписывать пришлось только звук: перевод аудиостадии с torchax на нативный JAX дал ускорение в 5,8 раза и вывел весь конвейер под дедлайн воспроизведения.

Почему BF16, а не FP8, и что ещё стоит знать

Нативный BF16 для непрерывного потока. Квантование FP8 снижает давление на пропускную способность памяти, но небольшие ошибки квантования накапливаются от фрагмента к фрагменту, поэтому в непрерывном потоке визуальное качество в рамках бюджета задержки сохранил именно BF16. Ещё одна деталь эксплуатации — кэш компиляции XLA: первый запуск тратит несколько минут на компиляцию графов, а кэширование собранных артефактов сокращает перезапуск воркера до менее чем минуты.

Ограничение публикации: это технический разбор от самих участников работы, а не независимый замер. Числа — 1,07x сквозной генерации, 5,8-кратное ускорение аудиостадии, 1664x936 при 18 кадрах в секунду и запас 7% — приводятся со слов команд Visko и Google Cloud; в тексте нет ни стоимости такой сессии, ни числа одновременных потоков на один срез, ни сетевой задержки на стороне зрителя.

Из практических рекомендаций авторы советуют ускорять внимание в диффузионных моделях готовым ядром из MaxDiffusion и писать собственные ядра на Pallas, переносить существующие модели PyTorch на TPU через torchax и точечно переписывать критические по задержке стадии на нативный JAX, снимать профиль через Cloud TPU Profiler, поднимать TPU на короткие прогоны и бенчмарки через TPU Flex-start VMs, а начинающим командам — идти за кредитами и техническим наставничеством в Google for Startups Cloud Program. Со стороны Google Cloud проектом руководили инженеры Yixin Shi, James Huang и Elisa Tsai.