Почему Sora проигрывает Codex? Ответ кроется в архитектуре рабочей нагрузки — это ключевой фактор, влияющий на скорость масштабирования AI‑продуктов. Об этом в подкасте Дэвида Сенры 23 августа упомянул Оттоман, говоря о распределении ресурсов в OpenAI. Хотя Sora — качественный продукт, он требует значительных вычислительных мощностей, поэтому приоритет был отдан Codex.
Разница между Sora и Codex проявляется в том, как используются вычислительные ресурсы. Sora потребляет мощности непрерывно и монопольно, а Codex — фрагментарно, с возможностью повторного использования. Это связано с особенностями их архитектуры.
Sora начинает потреблять много ресурсов уже на этапе ввода видео в модель. Процесс включает несколько этапов: сначала видео сжимается в latent space, затем разбивается на spacetime patches, и Transformer выполняет вычисления на этих патчах. Количество визуальных токенов в Sora можно оценить по формуле N_video ≈ T × H × W, где T, H и W — параметры, зависящие от длительности видео и его разрешения. Чем длиннее видео и выше его разрешение, тем больше ресурсов требуется.
После попадания сетки в Transformer требуется дополнительный расчёт из‑за диффузии: Sora начинает с зашумлённого latent, на каждом шаге обновляет представление видео и передаёт новый latent на следующий шаг. Вычислительные затраты на одну видеодорожку в Sora можно приблизительно оценить как Cvideo ≈ D × Ctransformer(N_video), где D — количество итераций выборки. При увеличении значения latent в видео диффузии возрастает нагрузка на каждую итерацию, а увеличение числа итераций выборки требует дополнительных проходов сети для одного видео.
Ключевое различие между видеодиффузией и LLM заключается в подходе к сохранению данных. В LLM предыдущие Key и Value сохраняются в KV cache, и модель не перестраивает всю историю на каждом шаге. В видеодиффузии после каждой итерации latent меняется, и следующая итерация работает с новым состоянием пространства‑времени, требуя повторных вычислений. Из‑за этого сложно снизить затраты на Sora за счёт повторного использования истории. Затраты на Sora сильно зависят от длины видео, его разрешения и числа выборок. Высокая утилизация GPU в Sora обусловлена большими матричными вычислениями, которые долго загружают Tensor Core, однако это не означает высокую отдачу в пересчёте на единицу времени: одна видеозаявка может долго занимать группу GPU, и затраты в GPU‑seconds остаются высокими.
Codex, в свою очередь, разбивает задачу на множество этапов, которые можно приостановить, восстановить и перекомбинировать. Например, задача «устранить баг» не завершается одним вызовом модели: Agent может считывать репозиторий, давать модели оценку следующего шага, выполнять shell, анализировать ошибки, добавлять логи в контекст, повторно вызывать модель, вносить правки в код, запускать тесты и продолжать рассуждения на основе новых данных. Одна задача Codex приближается к сумме множества итераций Prefill + Decode + Tool.
С каждой итерацией инструментального вызова контекст, который видит модель, становится объёмнее: в начале задачи модель имеет лишь требование пользователя и немного кода, а позже в prompt попадают файлы, diff, вывод терминала, логи тестов и результаты инструментов. Prompt caching критически важен для Codex, чтобы избежать перегрузки длинными задачами из‑за повторного prefill. Агент имеет 100K токенов контекста, после выполнения инструмента добавляется 3K токенов логов. Если стабильный префикс попадает в кэш (cache hit), основная нагрузка приходится на новую часть. При изменении префикса и cache miss система может столкнуться с тяжёлым prefill.
Логическое количество токенов больше не соответствует реальной нагрузке на GPU: два запроса с 100K входных токенов могут по‑разному нагружать GPU — в зависимости от того, какая часть уже кэширована. Нагрузка на агент зависит от скорости роста контекста, cache hit и количества повторных входов задачи в модель.
Prefill обрабатывает много токенов за раз, создавая compute‑heavy нагрузку. Decode генерирует мало токенов за раунд, требует частого доступа к весам модели и KV cache, зависит от HBM bandwidth и параллелизма. Для эффективности decode нужно объединять несколько sequence в batched forward — это позволяет одновременно обрабатывать больше запросов. Размер батча ограничен KV cache: чем длиннее контекст sequence, тем больше HBM он занимает.
При росте числа агентов GPU может иметь вычислительные резервы, но память уже не вместит больше активных состояний. PagedAttention снижает фрагментацию памяти, увеличивая число активных sequence на GPU за счёт управления KV cache по страницам. Вызов инструментов разделяет нагрузку Codex: когда агент выполняет тесты, компилирует код или ждёт I/O, GPU не задействован — работу берут на себя CPU, контейнеры и файловая система. Задача агента, выполняющаяся 60 минут, не означает непрерывного использования GPU в течение 60 минут — время разбивается на вычисления модели и внешнее выполнение. Это даёт планировщику возможность обслуживать другие sequence, пока агент выполняет инструменты.
Возникает проблема управления KV cache для агентов, ожидающих инструменты: сохранение кэша ускоряет восстановление, но занимает HBM; удаление освобождает память, но при возвращении задачи возникают затраты на восстановление. Codex отличается от Sora не «весом» вычислений, а тем, что его вычислительные ресурсы распределены по нескольким этапам, а не сосредоточены в одной непрерывной цепочке генерации. Это позволяет планировщику оптимизировать совместное использование GPU между этапами.
Эффективность 03Codex достигается за счёт реорганизации выполнения крупных моделей онлайн: веса долго остаются на GPU, требуется поддерживать tensor parallel, коммуникацию узлов и состояние кэша. Конкуренция за ресурсы между Sora и Codex происходит на уровне флота: часть GPU постоянно в видео serving pool, часть — в LLM pool; система верхнего уровня решает, где расширять, а где сокращать ресурсы. В Codex pool при наличии 200 Agent sequence часть из них декодируется, часть ждёт инструменты, несколько десятков только вернулись из инструментальной среды и обрабатывают новый длинный контекст. Scheduler учитывает не только FLOPs, но и ёмкость HBM, пропускную способность памяти, пребывание в KV cache и бюджет задержки.
Continuous batching решает проблему использования декодирования: вместо статического пакета, где короткие последовательности завершаются, а длинные продолжают занимать пакет, происходит динамическая замена на уровне итерации токенов — завершённая последовательность удаляется, новая сразу добавляется. Чем толще пакет, тем больше последовательностей может быть обработано за один цикл вычислений, и тем легче распределяется стоимость доступа к весам модели и пропускной способности памяти. Однако возникает ограничение по видеопамяти: большой объём KV cache длинных Agent постоянно занимает HBM — GPU может не достичь максимальной загрузки Tensor Core из‑за нехватки места для дополнительных последовательностей. Ограничивающим фактором для параллелизма становятся ёмкость кэша и управление видеопамятью.
Между Prefill и decode существует конфликт: если десятки последовательностей стабильно декодируются, а один Agent возвращается с новым контекстом в 100K токенов и требует крупного prefill, это может ухудшить TPOT соседних запросов. Чёнкнутый prefill (Chunked prefill) делит длинный ввод на мелкие части, позволяя чередовать prefill и decode; ещё один подход — разделить prefill и decode по разным GPU pool, поскольку эти этапы имеют разные аппаратные узкие места: prefill больше ориентирован на вычислительную пропускную способность, decode — на пропускную способность HBM, KV cache и стабильную задержку по токенам. Разделение позволяет настраивать ресурсы под конкретные потребности. Повышение ёмкости во многом зависит от перераспределения задач: когда и где они выполняются, какие состояния сохранять в видеопамяти, какие последовательности включать в текущий пакет.
Для оценки эффективности системы важны показатели: GPU‑seconds per task, TTFT (задержка первого токена), TPOT (время генерации одного токена), queueing latency, prefix cache hit, KV cache occupancy и SLO goodput (эффективная пропускная способность). Эти показатели показывают, сколько эффективных задач может выполнить GPU за час при допустимой задержке.
Codex отличается высокой планируемостью: stable prefix снижает повторное prefill, decode позволяет непрерывную пакетную обработку, KV cache поддерживает разбиение и вытеснение, агент при ожидании инструмента может освобождать GPU. Фрагментированная рабочая нагрузка может быть перераспределена планировщиком (scheduler). Время работы Codex Agent (60 минут) включает не только время работы модели (prefill и decode), но и время на компиляцию, тестирование, чтение/запись файлов, ожидание инструментов. Agent wall‑clock time и GPU compute time не соотносятся 1:1. При наличии множества агентов они не требуют GPU одновременно — одни выполняют prefill, другие decode, третьи тестируют или ожидают доступа к файловой системе. Планировщик может чередовать эти этапы, позволяя ограниченному количеству GPU поддерживать больше активных рабочих потоков.
Agent‑hours зависит от GPU‑hours, доли использования модели для вывода и эффективности планирования. Чем больше время выполнения инструментов, толще пакет, выше процент попаданий в кэш, тем больше времени работы агента может поддержать час работы GPU. Добавление GPU к Codex может не только ускорить отдельные задачи, но и позволить системе поддерживать больше агентов одновременно.
У Sora кривая ёмкости более прямая: значительная часть wall‑clock времени обработки видео приходится на продвижение diffusion на GPU, связь между задачей и использованием GPU тесная. Добавление GPU напрямую увеличивает пропускную способность видео, но разрыв между часом работы GPU и временем расчёта видео сложно увеличить. В случае Codex задача перемещается между GPU, CPU, контейнерами, файловой системой и средой инструментов. GPU отвечает за вывод модели, другие системы — за выполнение, агенты через планировщик совместно используют возможности вывода. Таким образом, GPU становится дефицитным «ресурсом мышления» в системе агентов, поэтому Codex легче получает дополнительные вычислительные ресурсы.
OpenAI нужно учитывать не только стоимость однократного вывода, но и возможность быстрого преобразования новых мощностей в больший объём параллельных задач. GPU могут поддерживать больше долгосрочных агентов, которые непрерывно получают новые задачи — это способствует дальнейшему распределению ресурсов. Sora задействует большой объём вычислений в рамках одной линии генерации, а Codex разбивает вычисления на несколько чередующихся этапов. Затраты одинаковы, но кривые возврата ресурсов различаются. Работа Sora и Codex показывает: у AI‑продуктов появился фактор, напрямую влияющий на скорость масштабирования — архитектура рабочей нагрузки (workload architecture). Задачи одного типа фиксируют большой объём вычислений в одной линии генерации, а задачи другого типа за счёт кэширования, пакетной обработки, выполнения инструментов и планирования распределяют один и тот же объём возможностей вывода между множеством рабочих потоков. Такие решения, как размещение KV cache, настройка prefill, размер decode batch, необходимость вытеснения кэша у ожидающих инструментов агентов, будут определять, сколько задач сможет одновременно поддерживать набор GPU. Разница между Sora и Codex — не только в типе контента (видео и код), но и в том, сколько задач удастся выполнить за один час на одном GPU. Ссылка
Подписаться в Макс
