Оутаман в подкасте раскрыл, почему OpenAI направляет ресурсы на Codex, а не на Sora. Генерация видео Sora требует значительных непрерывных вычислительных ресурсов, и время GPU, затрачиваемое на одну задачу, сложно повторно использовать; в то время как Codex с помощью механизмов KV cache, непрерывной пакетной обработки и вызова инструментов распределяет вычислительные ресурсы по нескольким перекрывающимся этапам, позволяя одному и тому же GPU поддерживать больше параллельных рабочих процессов. Способность повторного использования времени GPU начинает определять скорость расширения AI-продуктов.

Автор статьи, источник: LeFeng.com

Почему Sora проиграла Codex?

23 августа Отоман в подкасте Дэвида Сенры самостоятельно упомянул Sora, говоря о распределении ресурсов внутри OpenAI.

Он сказал прямо: Sora — это хороший продукт, и при дальнейшем развитии он может стать прибыльным бизнесом, но он слишком требователен к вычислительным ресурсам; в то же время приоритетом был Codex, поэтому вычислительные мощности и командные ресурсы начали перераспределяться в сторону Codex.

Но интересно, что Codex также не экономит GPU. Для генерации видео Sora требуется множество итераций вычислений Transformer для огромного пространственно-временного латентного представления; когда Codex получает команду «исправь этот баг», его фоновые процессы могут многократно выполнять вывод, анализировать код, вызывать инструменты, запускать тесты, а затем возвращаться с новыми журналами и контекстом для дальнейшего вывода.

Один вкладывает всю вычислительную мощность в однократное создание видео, другой распределяет вычислительную мощность по рабочему потоку агента, который может длиться десятки минут или дольше. Таким образом, настоящее различие между Sora и Codex начинает проявляться внутри дата-центров.

Тот же набор GPU, почему вычисления для генерации видео сложнее распределить, тогда как Coding Agent может снова вписать вычислительные ресурсы в большее количество параллельных задач с помощью KV cache, непрерывного пакетирования, планирования prefill / decode и ожидания инструментов?

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

Глядя дальше по этой линии, можно увидеть, что ресурсы, потерянные Sora, возможно, являются результатом выбора, как следует использовать время GPU.

Стоимость Sora, возможно, начинает расти уже с момента поступления видео в модель. Сначала она сжимает исходное видео в латентное пространство, а затем разбивает его на spacetime-патчи, на которых Transformer выполняет вычисления.

Текстовые токены в основном растут вдоль последовательности, а видеопатчи одновременно распределяются по времени, высоте и ширине, поэтому видео в модели изначально представляет собой объемное состояние.

В общих чертах, количество визуальных токенов можно понимать как N_video ≈ T × H × W. Здесь T, H и W уже сжаты и разбиты на патчи, но трехмерная мультипликативная зависимость сохраняется.

Увеличение продолжительности видео добавляет патчи в временном направлении, а увеличение размера изображения расширяет пространственные патчи. То есть продолжительность видео и пространственный размер не увеличивают стоимость независимо друг от друга — они вместе растягивают латентную сетку.

После попадания этой сетки в Transformer она сталкивается со вторым уровнем вычислений, вызванным diffusion. Sora начинает с зашумленного латентного представления, на каждом шаге обновляет видео-представление на основе текущего состояния и передает новое латентное представление на следующий шаг.

Вычислительная нагрузка одного видео может быть приблизительно оценена как C_video ≈ D × C_transformer(N_video), где D — количество итераций выборки. Чем больше латентное пространство видео, тем тяжелее каждая итерация; при увеличении числа итераций одно и то же видео должно пройти через сеть несколько раз.

Здесь видно ключевое различие между видео diffusion и языковыми моделями. При генерации следующих токенов ключи и значения предыдущих токенов могут сохраняться в KV cache, и модели не нужно на каждом шаге заново воссоздавать всю историческую информацию.

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

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

Так как каждая задача достаточно тяжелая, использование GPU Sora может быть очень высоким. Вычисления с большими матрицами позволяют Tensor Core долго оставаться загруженными, и на графиках мониторинга GPU почти никогда не простаивает.

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

Видео serving по-прежнему будет зависеть от различий в форме. Разная продолжительность, разрешение и соотношение сторон формируют разные формы тензоров. Сервер для повышения эффективности пакетной обработки объединяет запросы с близкими размерами в одни и те же бакеты. Подождать немного дольше позволяет сформировать более плотный пакет, но увеличивает задержку в очереди; немедленное выполнение сокращает ожидание, но пакет может оказаться неполным.

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

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

Пользователь дал Codex задачу «исправить этот баг» — задача не завершится одним вызовом модели. Агент может сначала прочитать репозиторий, заставить модель определить следующий шаг, а затем выполнить shell-команду; получив ошибку, добавить журнал в контекст и повторно вызвать модель; затем изменить код, запустить тесты и продолжить рассуждения на основе новых результатов.

Таким образом, одна задача Codex ближе к сумме многих циклов Prefill + Decode + Tool, причем ключевым моментом является то, что после завершения каждого цикла вызова инструмента контекст, видимый моделью в следующем цикле, как правило, становится более объемным.

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

Пользователь, возможно, видит только несколько сотен слов завершенного описания, но промежуточная обработка в GPU могла уже создать чрезвычайно большой объем данных. Давление на потребление токенов агента скрыто в этой постоянно растущей траектории работы.

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

Предположим, что агент уже имеет контекст из 100K токенов, и после выполнения инструмента добавляется только 3K токенов логов. Если стабильный префикс в начале попадает в кэш, то вычисления в этом цикле сосредоточены в основном на этой последней части; как только изменение в начале промпта вызывает сбой кэша, система может снова столкнуться с тяжелым prefill.

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

После входа в однократный inference предзаполнение и декодирование имеют разные требования к оборудованию. Предзаполнение обрабатывает множество входных токенов за один раз, матрицы имеют большие размеры и легче формируют вычислительно интенсивную нагрузку; декодирование за каждый цикл генерирует лишь небольшое количество токенов для каждой последовательности, но требует многократного доступа к весам модели и KV-кэшу, поэтому оно больше зависит от пропускной способности HBM и масштаба параллелизма.

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

При этом увеличение размера пакета ограничено KV-кешем. Чем длиннее контекст каждой последовательности, тем больше HBM он занимает. После увеличения количества агентов на GPU может оставаться вычислительный резерв, но память уже не может вместить больше активных состояний.

Такие архитектуры, как PagedAttention, снижают фрагментацию видеопамяти за счет постраничного управления KV-кешем, что по сути увеличивает количество активных последовательностей, которые могут одновременно помещаться на одном GPU.

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

Таким образом, агент, работающий 60 минут, не означает непрерывное занятие GPU в течение 60 минут. Его время задачи разделено на вычисления модели и внешнее выполнение, что предоставляет планировщику пространство, которое Sora很难提供: когда агент запускает инструмент, GPU может немедленно обслуживать другую последовательность.

Конечно, это также создаст новые проблемы с видеопамятью. Агенту, ожидающему инструмента, следует ли сохранять KV cache? Сохранение позволяет быстрее восстановиться, но длительно занимает HBM; вытеснение освобождает пространство, но при возвращении задачи требует затрат на восстановление. Чем больше количество агентов, тем больше такие компромиссы напоминают управление операционной системой большим количеством процессов, которые переходят в спящий режим и пробуждаются.

На этом различие между Codex и Sora уже не в том, кто тяжелее, а в том, были ли затраты разделены. Вычислительные ресурсы Sora сосредоточены на одной непрерывной траектории генерации, а вычислительные ресурсы Codex распределены по нескольким этапам. Именно благодаря разделению Codex может перейти к следующему уровню оптимизации: позволить планировщику решить, как эти этапы будут совместно использовать одни и те же GPU.

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

Самые сложные процессы происходят внутри пула Codex. Предположим, в системе одновременно существует 200 последовательностей агентов: часть из них正在进行 декодирование, часть ожидает инструменты, а десятки только что вернулись из среды инструментов и должны обработать новые длинные контексты. Планировщик сталкивается не только с ограничениями по FLOPs, но и с ограничениями по емкости HBM, пропускной способности памяти, продолжительности хранения KV-кеша и латентностным бюджетом.

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

Continuous batching динамически заменяет пользователей на уровне итераций токенов: как только одна последовательность завершается, она удаляется, а новый запрос немедленно включается. Чем больше пакет, тем больше последовательностей может быть продвинуто за один цикл вычислений модели, что позволяет более эффективно распределить затраты на доступ к весам модели и пропускную способность памяти.

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

Существует еще один конфликт между prefill и decode. Предположим, что десятки последовательностей стабильно выполняют decode, и в этот момент агент возвращается с новым контекстом из 100K токенов, требуя выполнения крупного prefill. Если этот prefill занимает длительное окно выполнения, TPOT соседних запросов значительно ухудшится.

Чанкированный предзаполнение разбивает длинный ввод на несколько небольших фрагментов, позволяя чередовать предзаполнение и декодирование; более продвинутый подход заключается в разделении предзаполнения и декодирования на разные пулы GPU.

Причина в том, что два этапа по своей природе имеют разные аппаратные узкие места: prefill больше зависит от вычислительной пропускной способности, а decode — от пропускной способности HBM, KV-кэша и стабильной задержки по токенам. Разделив их, можно настроить ресурсы отдельно для каждого этапа в соответствии с его требованиями.

Это означает, что суть Agent serving выходит за рамки «сделать ядро модели быстрее». Многие улучшения в емкости достигаются за счет перераспределения задач: когда и где их выполнять, какие состояния стоит сохранять в памяти GPU и кого следует включать в текущий пакет.

Таким образом, здесь уже недостаточно только использования GPU. Команде по емкости необходимо одновременно отслеживать GPU-seconds per task, TTFT (задержка первого токена, определяющая, насколько плавно работает система для пользователя), TPOT (время генерации одного токена, определяющее, насколько быстро модель «говорит»), задержку в очереди, частоту попаданий в префиксный кэш, занятость KV-кэша и SLO goodput (эффективная пропускная способность, показывающая реальную вычислительную мощность, приносящую доход).

Эти показатели вместе отвечают на вопрос: сколько эффективных задач может выполнять GPU в час при задержке, приемлемой для пользователя.

Это и проявляется в планируемости Codex. Стабильный префикс снижает повторные prefill, decode позволяет выполнять непрерывную пакетную обработку, KV cache можно разбивать на страницы и вытеснять, а когда Agent ожидает инструменты, он может освободить GPU. Его рабочая нагрузка фрагментирована, но эти фрагменты можно переупорядочить планировщиком.

Это естественным образом переносит вопрос на уровень ресурсов: если один и тот же набор GPU может чередовать обслуживание большего количества долгосрочных агентов, то фактическое рабочее время, которое может поддерживаться одним часом GPU, может превышать один час.

Предположим, что Codex Agent работает от начала до завершения задачи в течение 60 минут, при этом только часть этого времени действительно тратится на prefill и decode модели, а остальное время расходуется на компиляцию, тестирование, чтение и запись файлов или ожидание инструментов. Конкретное соотношение может варьироваться в зависимости от задачи, но структура важна: общее время работы агента (wall-clock time) и время вычислений на GPU не совпадают один к одному.

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

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

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

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

Задача программного обеспечения Codex перемещается между GPU, CPU, контейнерами, файловой системой и средами инструментов. GPU отвечает за вывод модели, другие системы — за выполнение, а несколько агентов совместно используют возможности вывода через планировщик. Таким образом, GPU превращается из простого генерирующего устройства в ограниченный «ресурс мышления» всей системы агентов.

Вот почему Codex, несмотря на то, что он также может потреблять большое количество вычислительных ресурсов, легче получает новые вычислительные мощности. OpenAI нужно смотреть не только на стоимость одного запроса, но и на то, сможет ли новая емкость быстро преобразоваться в большее количество параллельных задач.

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

Технический смысл этих слов Алтмана также стал ясен. Большой объем вычислительных ресурсов Sora заблокирован в одиночном пути генерации, а вычислительные ресурсы Codex разделены на несколько перекрывающихся этапов. Оба варианта одинаково дороги, но кривая отдачи ресурсов различается.

Описание передачи ресурсов Sora и Codex: у AI-продуктов появляется еще одна переменная, напрямую влияющая на скорость расширения: workload architecture.

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

Таким образом, некоторые вопросы, которые сейчас кажутся низкоуровневыми, будут всё ближе подходить к вопросам продукта: как размещать KV cache, как разрезать prefill, насколько плотно можно упаковать decode batch, следует ли вытеснять кэш у агентов, ожидающих инструменты — эти решения в конечном итоге определят, сколько задач одновременно может поддерживать группа GPU.

Разница между Sora и Codex — это не только разница между видео и кодом.

Они соревнуются за один и тот же час GPU, и сколько работы он сможет выдержать.