Отман у подкасті розкрив, чому OpenAI зосереджує ресурси на Codex, а не на Sora. Генерація відео Sora вимагає великої кількості неперервних обчислювальних ресурсів, і час GPU на одну задачу важко повторно використовувати; тоді як Codex за допомогою механізмів KV cache, continuous batching та виклику інструментів розподіляє обчислювальні ресурси між кількома перекриваючими етапами, дозволяючи одному GPU підтримувати більше паралельних робочих процесів. Здатність до повторного використання часу GPU починає визначати швидкість розширення AI-продуктів.

Автор статті, джерело: Leiphone

Чому 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, можливо, починає зростати ще з моменту, коли відео потрапляє до моделі. Спочатку вона стискає оригінальне відео до latent space, а потім розрізає його на spacetime patches, щоб Transformer міг обчислити на цих patch-ах.

Токени тексту переважно зростають у напрямку послідовності, а відео-патчі одночасно розташовуються у часі, висоті та ширині, тому відео в межах моделі природним чином є об’ємним станом.

Загалом, кількість візуальних токенів можна розуміти як N_video ≈ T × H × W. Тут T, H та W вже були стиснуті та розділені на патчі, але тривимірна множення залишається.

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

Після того як ця сітка потрапляє до Transformer, їй доводиться зіткнутися з другим рівнем обчислень, що виникають через diffusion. Sora починає з латентного представлення з шумом, на кожному кроці оновлює відеопредставлення на основі поточного стану, а потім передає нове латентне представлення на наступний крок.

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

Тут видно ключову різницю між відеодифузією та LLM. Під час генерації наступних токенів мовна модель може зберігати попередні Key і Value у KV cache, і модель не повинна на кожному кроці заново створювати всю історію стану.

Після завершення кожного циклу оновлення відеодифузії латентний стан суб’єкта змінюється, і на наступному циклі система працює з новим просторово-часовим станом, тому велика кількість обчислень для суб’єкта відео продовжується.

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

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

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

Відео serving все ще буде зупинятися через різницю у формі. Різні тривалість, роздільна здатність та співвідношення сторін формують різні tensor shape. Сервер для підвищення ефективності пакетної обробки має об’єднувати запити з подібними розмірами в однакові бакети. Очікування трохи довше дозволяє зібрати більш щільний пакет, але збільшує затримку черги; негайне виконання скорочує час очікування, але пакет може виявитися неповним.

Тому велика частина обчислювальних витрат Sora вже закріплена в самому шляху генерації відео. Кількість зразків можна зменшити, latent можна додатково стиснути, модель можна дистилювати, kernel також можна оптимізувати, але scheduler може змінювати лише те, «як розподілити ці важкі завдання», але не може змінити факт того, що «одне відео саме по собі вимагає великої кількості послідовних обчислень».

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

Користувач надає Codex завдання «виправити цей баг» — завдання не завершується одним викликом моделі. Агент може спочатку прочитати репозиторій, надати моделі визначити наступний крок, а потім виконати shell; отримавши помилку, додати лог до контексту та повторно викликати модель; після цього змінити код, запустити тести та продовжити міркування на основі нових результатів.

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

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

Користувач, можливо, бачить лише кілька сотень слів остаточного пояснення, але проміжна обробка в GPU могла вже стати дуже об’ємною. Тиск на споживання токенів агента прихований у цьому постійно зростаючому сліді роботи.

Якщо кожен інференс повторно обробляє всю історію, довгі завдання швидко зупинятимуться через повторне заповнення, тому кешування запитів критично важливе для Codex.

Припустимо, що агент вже має 100K токенів контексту, а виконання інструменту додає лише 3K токенів журналу; якщо стабільний префікс на початку попадає в кеш, то обчислення циклу зосереджуються переважно на цій останній частині; якщо зміна початкової частини запиту призводить до cache miss, система може знову стикнутися зі значним prefill.

Тут відбулася важлива зміна: кількість логічних токенів більше не може прямо відображати реальну вартість GPU. Обидва запити показують 100K вхідних токенів, але в одному з них більша частина вже кешована, а в іншому потрібно перераховувати — їхнє навантаження на GPU абсолютно різне. Навантаження агента залежить від швидкості зростання контексту, частоти попадань у кеш та кількості повторних входів завдання в модель.

Після входу в одноразове висновок, prefill і decode мають різні вимоги до апаратного забезпечення. Prefill обробляє багато вхідних токенів за раз, матриці мають великий розмір і легше утворюють навантаження, що вимагає багато обчислень; decode генерує лише кілька токенів за цикл для кожної послідовності, але постійно звертається до ваг моделі та KV cache, тому більше залежить від пропускної здатності HBM та масштабу паралелізму.

Це означає, що декодування окремої послідовності буде дуже неефективним. Ваги моделі залишаються такими ж великими, і для генерації одного токена потрібно виконати повний прямий прохід. Сервер повинен об’єднувати багато послідовностей в один пакет, щоб один доступ до вагів одночасно обробляв більше запитів.

Але збільшення пакету обмежується KV-кешем. Чим довший контекст кожної послідовності, тим більше HBM він займає. Після збільшення кількості агентів GPU може мати вільну обчислювальну потужність, але пам’ять GPU вже не зможе вмістити більше активних станів.

Дизайн, подібний до PagedAttention, зменшує фрагментацію пам’яті KV за допомогою сторінкового управління, суттєво збільшуючи кількість активних послідовностей, які GPU може одночасно містити.

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

Тоже саме, агент, що працює 60 хвилин, не означає неперервного використання GPU протягом 60 хвилин. Його час завдання розділений на обчислення моделі та зовнішнє виконання, що надає планувальнику простір, який Sora важко забезпечити: коли агент виконує інструмент, GPU може одразу служити іншій послідовності.

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

Тут різниця між Codex і Sora вже не в тому, хто важчий, а в тому, чи були витрати розбиті. Обчислювальні ресурси Sora зосереджені в одній неперервній траєкторії генерації, тоді як обчислювальні ресурси Codex розподілені між кількома етапами. Саме через розбиття Codex може перейти до наступного рівня оптимізації: дозволити scheduler вирішити, як ці етапи будуть ділити одну й ту ж групу GPU.

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

Справжні складні речі відбуваються всередині Codex pool. Припустимо, у системі одночасно існують 200 послідовностей Agent, частина з яких зараз декодує, частина очікує інструментів, а десятки з них тільки що повернулися з оточення інструментів і мають обробити нові довгі контексти. Планувальник стикається з обмеженнями, які включають не лише FLOPs, але й об’єм HBM, пропускну здатність пам’яті, тривалість KV cache та бюджет затримок.

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

Continuous batching динамічно замінює користувачів на рівні ітерації токенів: після завершення однієї послідовності вона видаляється, а новий запит негайно додається. Чим більший батч, тим більше послідовностей може бути просунуто за один цикл обчислення моделі, що дозволяє краще розподілити витрати на доступ до ваг моделі та пропускну здатність пам’яті.

Але тут швидко зустрінеться обмеження пам’яті GPU. Велика кількість довгих KV-кешів агентів постійно займатиме HBM, і навіть якщо Tensor Core ще не завантажені повністю, пам’ять вже не зможе вмістити більше послідовностей. У цей момент подальше збільшення обчислювальних потужностей не має сенсу — справжнім обмеженням паралелізму є ємність кешу та управління пам’яттю.

Між prefill та decode існує ще одна конфліктна ситуація. Припустимо, десятки sequence стабільно декодуються, і раптово агент повертається з новим контекстом у 100K токенів, що вимагає виконання великої операції prefill. Якщо цей prefill займе довгий вікно виконання, TPOT сусідніх запитів значно погіршиться.

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

Причина полягає в тому, що обидва етапи мають різні обмеження апаратного забезпечення: prefill більше залежить від обчислювальної пропускної здатності, а decode — від пропускної здатності HBM, KV cache та стабільної затримки по токенам. Розділивши їх, можна окремо налаштувати ресурси під кожен із них.

Це означає, що ядро Agent serving вийшло за межі просто «зробити модель kernel швидшою». Багато збільшення ємності походить із перерозподілу того, коли і де виконувати завдання, які стани варто зберігати у пам’яті GPU, і хто повинен бути включений у поточний батч.

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

Ці показники разом відповідають на питання: скільки ефективних завдань може підтримувати GPU за годину при затримці, прийнятній для користувача.

Саме тут проявляється можливість планування Codex. Стабільний префікс зменшує повторне заповнення, decode може виконувати безперервне пакетне опрацювання, KV cache може бути сторінковим та витісненим, а агент під час очікування інструментів може віддавати GPU. Його навантаження дуже дрібне, але ці фрагменти можуть бути переплановані планувальником.

Це природним чином переносить питання на рівень ресурсів: якщо той самий набір GPU може чергувати обслуговування більшої кількості довгострокових агентів, то одна година GPU фактично може підтримувати більше ніж одну годину роботи.

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

Якщо в системі одночасно існує велика кількість агентів, вони не потребуватимуть GPU в одну і ту ж секунду. Хтось зараз виконує prefill, хтось — decode, хтось запускає тести, а хтось чекає на файлову систему. Досить того, щоб планувальник міг чергувати ці етапи — обмеженої кількості GPU вистачить, щоб підтримувати значно більше активних робочих потоків, ніж кількість GPU.

Цю залежність можна умовно розуміти так: Agent-hours залежать від GPU-hours, коефіцієнта завантаження моделі та ефективності планування. Чим довше виконується інструмент, тим товщі батчі, тим вищий показник спрацьовування кешу — і тим більше можливостей має одна година GPU підтримувати довший Agent wall-clock час роботи.

Це безпосередньо змінить значення додавання нових 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.

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

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

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

Вони борються за той самий годинний GPU — скільки роботи він зможе витримати.