Ultraman dalam podcast mengungkap mengapa OpenAI lebih mengutamakan sumber daya kepada Codex daripada Sora. Penghasilan video Sora memerlukan daya komputasi berterusan yang besar, dan masa GPU yang digunakan untuk satu tugas sukar digunakan semula; manakala Codex melalui mekanisme seperti KV cache, continuous batching, dan pemanggilan alat, menyebarkan daya komputasi ke pelbagai peringkat yang boleh bersilang, membolehkan GPU yang sama menyokong lebih banyak aliran kerja selari. Kemampuan untuk menggunakan semula masa GPU kini menentukan kelajuan ekspansi produk AI.

Penulis artikel, sumber: LeiFeng.com

Mengapa Sora kalah kepada Codex?

Pada 23 Ogos, Otomo secara aktif menyebut Sora semasa membincangkan pengorbanan sumber di dalam OpenAI dalam podcast David Senra.

Dia berkata dengan jelas: Sora adalah produk yang baik, dan jika diteruskan, ia boleh menjadi perniagaan yang baik, tetapi ia terlalu memakan komputasi. Pada masa yang sama, keutamaan Codex lebih tinggi, jadi sumber komputasi dan tenaga kerja beralih ke Codex.

Tetapi yang menariknya, Codex sebenarnya juga tidak menghemat GPU sama sekali. Untuk menghasilkan satu video, Sora memerlukan laten spasial-temporal yang besar melalui berbilang perhitungan Transformer; sementara Codex, apabila menerima arahan “baiki ralat ini”, mungkin akan menjalankan berbilang putaran inferens, membaca kod, memanggil alat, menjalankan ujian, kemudian kembali dengan log dan konteks baru untuk terus melakukan inferens.

Satu menekankan penggunaan daya pengiraan dalam penghasilan video sekali jalan, manakala yang lain menyebarkan daya pengiraan ke dalam alur kerja Agen yang mungkin berterusan selama puluhan minit atau lebih. Oleh itu, perbezaan sebenar antara Sora dan Codex bermula di dalam pusat data.

Dengan peralatan GPU yang sama, mengapa komputasi untuk penghasilan video lebih sukar untuk dibahagikan, manakala Coding Agent mampu memasukkan semula kekuatan pengiraan ke dalam lebih banyak tugas serentak melalui KV cache, continuous batching, penjadualan prefill / decode, dan menunggu alat?

Sebenarnya, Sora bukan kalah kerana nilai penggunaan kuasa komputasi yang mutlak, tetapi kalah kerana arkaitektur beban kerja: kuasa komputasi Sora adalah berterusan dan eksklusif, manakala kuasa komputasi Codex adalah serpihan dan boleh digunakan semula. Perbezaan mekanisme penjadualan inilah yang mencipta perbezaan laju pengembangan antara keduanya.

Melihat lebih jauh sepanjang garis ini, bagian sumber daya yang hilang oleh Sora mungkin merupakan pilihan tentang bagaimana masa GPU seharusnya digunakan.

Kos Sora mungkin sudah bermula meningkat sejak video memasuki model. Ia akan mula-mula mengkompres video asal ke dalam latent space, kemudian memotongnya menjadi spacetime patches, membolehkan Transformer mengira pada patch-patch ini.

Token teks terutama tumbuh mengikut arah urutan, manakala patch video diisikan serentak pada masa, tinggi, dan lebar, oleh itu video secara semula jadi merupakan keadaan berisipadu di dalam model.

From a high-level perspective, the number of visual tokens can be understood as N_video ≈ T × H × W. Here, T, H and W have been compressed and patched, but the three-dimensional multiplicative relationship still holds.

Memperpanjang masa video akan menambah patch dalam arah masa, sementara peningkatan saiz gambar akan memperluas patch ruang. Dengan kata lain, panjang video dan saiz ruang tidak meningkatkan kos secara berasingan; keduanya bersama-sama memperbesar grid laten.

Selepas blok grid ini memasuki Transformer, ia masih perlu menghadapi pengiraan kedua yang dibawa oleh diffusion. Sora bermula dengan latent yang berisik, dan dalam setiap putaran, ia mengemas kini perwakilan video berdasarkan keadaan semasa, kemudian menghantar latent baru ke putaran seterusnya.

Computational cost for a single video can be roughly understood as C_video ≈ D × C_transformer(N_video), where D is the number of sampling iterations. The larger the video latent, the heavier each iteration; increasing the number of sampling rounds means running the network multiple additional times for the same video.

Di sini dapat dilihat perbezaan utama antara video diffusion dan LLM. Semasa model bahasa menghasilkan token seterusnya, Key dan Value sebelumnya boleh disimpan dalam KV cache, jadi model tidak perlu membina semula keseluruhan status sejarah pada setiap langkah.

Setiap kali pengemaskinian video diffusion selesai, latent utama telah berubah, dan pengemaskinian seterusnya akan menghadapi keadaan ruang-masa yang baharu, oleh itu pengiraan besar-besaran terhadap subjek video masih perlu diteruskan.

Oleh itu, kos Sora sukar untuk dikurangkan secara besar-besaran melalui “pengulangan sejarah”. Ia lebih seperti satu adegan kesan visual yang menjalani berbilang proses, di mana setiap pusingan perlu memproses keseluruhan gambar yang telah berubah. Semakin panjang video, semakin tinggi resolusi, dan semakin banyak sampel, semakin berat laluan penghasilan ini.

Just because each task is sufficiently heavy, Sora's GPU utilization may actually look very good. Large matrix computations can keep Tensor Cores busy for extended periods, with GPU activity nearly constant on monitoring charts.

Ketersediaan tinggi hanya menunjukkan bahawa cip sentiasa beroperasi, dan tidak bermakna banyak tugas telah dihantar dalam tempoh masa tertentu. Jika satu video mengekalkan satu set GPU untuk masa yang lama, maka walaupun penggunaan kelihatan cantik, GPU-seconds yang digunakan untuk setiap permintaan masih tinggi.

Video serving masih akan terhambat oleh perbezaan bentuk. Panjang, resolusi, dan nisbah aspek yang berbeza akan membentuk bentuk tensor yang berbeza. Untuk meningkatkan kecekapan batch, pelayan perlu memasukkan permintaan dengan dimensi yang serupa ke dalam bucket yang sama. Menunggu sedikit lebih lama boleh mengumpulkan batch yang lebih tebal, tetapi akan meningkatkan latensi antrian; melaksanakan segera boleh memperpendek masa tunggu, tetapi batch mungkin tidak terisi penuh.

Oleh itu, sebahagian besar kos pengiraan Sora telah terkunci dalam laluan penghasilan video itu sendiri. Bilangan sampel boleh dikurangkan, latent boleh ditekan lagi, model boleh didistilasi, kernel juga boleh diperbaiki, tetapi yang boleh diubah oleh scheduler ialah “bagaimana tugas-tugas berat ini dijadualkan”, dan sukar untuk mengubah fakta bahawa “satu video memerlukan pengiraan berterusan yang banyak”.

Ini juga merupakan pintu masuk untuk memahami Codex. Codex juga mahal, tetapi ia tidak membebankan semua kos ke dalam satu blok pengiraan berterusan, sebaliknya ia membahagikan tugas kepada banyak peringkat yang boleh dihentikan, dipulihkan, dan digabungkan semula.

Pengguna memberi Codex arahan "baiki bug ini", tugas ini tidak akan berakhir dengan satu panggilan model. Agen mungkin terlebih dahulu membaca repositori, meminta model menilai langkah seterusnya, kemudian menjalankan shell; selepas mendapat ralat, log dimasukkan ke dalam konteks dan model dipanggil semula; seterusnya, kod dimodifikasi, ujian dijalankan, dan seterusnya berdasarkan keputusan baharu untuk terus membuat penalaran.

So a single Codex task is closer to the accumulation of many roundsPrefill + Decode + Tool, where the key point is that after each tool call, the context seen by the model in the next round is often thicker than the previous one.

Pada permulaan tugas, model mungkin hanya mempunyai permintaan pengguna dan sedikit kod. Selepas berjalan selama beberapa masa, lebih banyak fail, diff, output terminal, log ujian, dan hasil alat akan terus masuk ke dalam prompt.

Pengguna mungkin hanya melihat penjelasan ringkas yang terdiri dari beberapa ratus perkataan, tetapi kandungan yang telah diproses oleh GPU mungkin sudah sangat besar. Tekanan terhadap penggunaan token Agent tersembunyi di dalam jejak kerja yang terus bertambah ini.

Jika setiap inferens ulangan memproses sejarah penuh, tugas panjang akan cepat terhambat oleh prefill berulang, oleh itu pengecualian prompt sangat penting untuk Codex.

Andaikan sebuah Agent telah memiliki konteks 100K token, dan pelaksanaan alat hanya menambahkan 3K token log. Jika prefix stabil sebelumnya dapat memicu cache, pengiraan tambahan kali ini akan berfokus pada bahagian belakang ini; sekiranya perubahan pada bahagian awal prompt menyebabkan cache miss, sistem mungkin perlu menghadapi semula prefill yang berat.

Terdapat perubahan penting di sini: bilangan token logik tidak lagi boleh secara langsung mewakili kos GPU sebenar. Kedua-dua permintaan menunjukkan 100K token input, tetapi satu daripadanya sebahagian besar kandungannya telah disimpan dalam cache, manakala yang lain perlu dikira semula, dan tekanan kepada GPU mereka sangat berbeza. Beban Agent oleh itu bergantung kepada kelajuan pertumbuhan konteks, cache hit, dan berapa kali tugas yang sama masuk semula ke dalam model.

Setelah memasuki inference sekali, prefill dan decode memerlukan keperluan peranti keras yang berbeza. Prefill memproses banyak token input sekaligus, dengan dimensi matriks yang besar, lebih mudah membentuk beban kerja yang berat secara komputasi; decode menghasilkan hanya sedikit token setiap langkah setiap urutan, tetapi perlu mengakses berulang-ulang bobot model dan KV cache, oleh itu lebih bergantung kepada lebar pita HBM dan skala konkuren.

Ini bermakna bahawa decode jika dijalankan secara berasingan untuk satu urutan akan sangat tidak efisien. Bobot model masih besar, dan untuk menghasilkan satu token, ia perlu menjalankan satu pengiraan maju penuh. Pelayan hanya boleh meningkatkan kecekapan dengan memasukkan banyak urutan ke dalam satu batched forward, supaya satu akses bobot boleh memproses lebih banyak permintaan secara serentak.

Namun, batch bolehkah diperbesar lagi, dan akan terbatas oleh KV cache. Semakin panjang konteks setiap urutan, semakin banyak HBM yang digunakan. Selepas bilangan Agen bertambah, GPU mungkin masih mempunyai kelebihan pengiraan, tetapi memori video sudah tidak mampu menampung lebih banyak keadaan aktif.

Reka bentuk seperti PagedAttention mengurus cache KV secara halaman untuk mengurangkan kepingan memori GPU, pada dasarnya meningkatkan bilangan urutan aktif yang boleh diterima oleh GPU secara serentak.

Pemanggilan alat semula membahagikan beban Codex lebih lanjut. Semasa Agent menjalani ujian, mengkompil kod, atau menunggu I/O, GPU tidak perlu terus bekerja untuknya; CPU, kontena, dan sistem fail akan mengambil alih. Semasa keputusan kembali, Agent ini akan memasuki pusingan inferens seterusnya.

Satu agen yang berjalan selama 60 minit tidak bermaksud mengambil alih GPU secara berterusan selama 60 minit. Masa tugasnya dibahagikan kepada pengiraan model dan pelaksanaan luaran, yang memberikan ruang kepada penjadual yang sukar disediakan oleh Sora: apabila seorang agen menjalankan alat, GPU boleh segera melayani urutan lain.

Tentu, ini juga akan menciptakan masalah memori paparan baru. Adakah agen yang menunggu alat harus terus menyimpan KV cache? Menyimpannya membolehkan pemulihan yang lebih pantas, tetapi akan mengambil ruang HBM secara jangka panjang; mengusirnya boleh melepaskan ruang, tetapi apabila tugas kembali, ia perlu menanggung kos pemulihan. Semakin banyak agen, pengambilan keputusan ini semakin menyerupai sistem pengendali yang menguruskan banyak proses yang tidur dan bangun.

Di sini, perbezaan antara Codex dan Sora bukan lagi tentang “siapa yang lebih berat”, tetapi sama ada kosnya telah dipisahkan. Kuasa pengiraan Sora terpusat dalam satu laluan penghasilan berterusan, manakala kuasa pengiraan Codex tersebar di pelbagai peringkat. Justeru kerana dipisahkan, Codex boleh memasuki pengoptimuman peringkat seterusnya: membenarkan scheduler menentukan bagaimana peringkat-peringkat ini berkongsi GPU yang sama.

Semasa model besar dijalankan secara dalam talian, bobot biasanya perlu kekal di GPU untuk jangka masa panjang, serta mengekalkan paralelisme tensor, komunikasi nod, dan keadaan cache. Oleh itu, persaingan sumber antara Sora dan Codex lebih sering berlaku pada tahap armada: sebahagian GPU kekal dalam pool perkhidmatan video, manakala sebahagian lagi kekal dalam pool LLM, dengan sistem kapasiti lapisan atas menentukan di mana peningkatan atau pengurangan kapasiti perlu dilakukan.

Perkara yang benar-benar kompleks berlaku di dalam Codex pool. Andaikan sistem tersebut mempunyai 200 urutan Agent secara serentak, di mana sebahagian sedang decode, sebahagian menunggu alat, dan puluhan lain baru kembali dari persekitaran alat dan perlu memproses konteks panjang yang baru. Scheduler menghadapi sekatan yang tidak hanya termasuk FLOPs, tetapi juga kapasiti HBM, lebar pita memori, kediaman KV cache, dan anggaran latensi.

Continuous batching terlebih dahulu menyelesaikan masalah penggunaan decode. Batch statik tradisional akan mengikat sekumpulan permintaan bersama-sama, dan selepas urutan pendek selesai, permintaan panjang yang tinggal masih mengambil bahagian batch.

Pengumpulan berterusan akan secara dinamik menukar pengguna pada tahap iterasi token, satu urutan akan dikeluarkan setelah selesai, dan permintaan baru akan segera menggantikannya. Semakin tebal batch, semakin banyak urutan yang boleh diproses dalam satu putaran pengiraan model, dan kos akses bobot model serta lebar pita memori menjadi lebih mudah diratakan.

Tetapi di sini akan segera mencapai dinding memori video. Cache KV yang besar untuk banyak Agent panjang akan terus mengambil alih HBM, dan mungkin sebelum Tensor Core pada satu GPU digunakan sepenuhnya, memori video sudah penuh dengan sekuens tambahan. Pada titik ini, menambahkan lebih banyak kekuatan pengiraan tidak bermakna; yang benar-benar membatasi kesejajaran ialah kapasiti cache dan pengurusan memori video.

Terdapat konflik lain antara prefill dan decode. Bayangkan bahawa puluhan sequence sedang decode dengan stabil, kemudian seorang Agent kembali dengan konteks baru sebanyak 100K token yang memerlukan prefill besar. Jika prefill ini mengambil jendela eksekusi yang panjang, TPOT permintaan di sebelahnya akan menurun secara ketara.

Chunked prefill akan memecah input panjang menjadi beberapa bahagian kecil, membolehkan prefill dan decode dijalankan secara berselang-seli; pendekatan yang lebih lanjut adalah memisahkan prefill dan decode ke dalam pool GPU yang berbeza.

Sebabnya ialah, dua peringkat ini secara asalnya cenderung kepada beban peranti yang berbeza: prefill lebih bergantung pada throughput pengiraan, manakala decode lebih bergantung pada lebar pita HBM, cache KV, dan latensi token demi token yang stabil. Apabila dipisahkan, sumber boleh dikonfigurasi mengikut keperluan masing-masing.

Ini menunjukkan bahawa inti Agent serving telah melampaui sekadar "menyusun semula kernel model agar lebih pantas". Banyak peningkatan kapasiti datang daripada menyusun semula kapan tugas dilaksanakan, di mana tugas dilaksanakan, status mana yang patut dikekalkan dalam memori GPU, dan siapa yang patut dimasukkan ke dalam batch semasa.

Oleh itu, penggunaan GPU di sini sudah tidak mencukupi. Pasukan kapasiti perlu memantau secara serentak GPU-seconds per task, TTFT (latensi kata pertama, yang menentukan sama ada pengguna merasa lag atau tidak), TPOT (masa penghasilan setiap kata, yang menentukan seberapa pantas model “berbicara”), queueing latency, prefix cache hit, KV cache occupancy, dan SLO goodput (throughput berkesan, yang mewakili kuasa pengiraan yang benar-benar boleh menghasilkan pendapatan).

Indikator-indikator ini bersama-sama menjawab satu soalan: Berapa banyak tugas berkesan yang boleh dipertahankan oleh GPU dalam satu jam di bawah latensi yang boleh diterima pengguna.

Keterjadualan Codex terlihat di sini. Prefix stabil boleh mengurangkan prefill berulang, decode boleh melakukan batch berterusan, cache KV boleh dipaginasi dan dikeluarkan, dan Agent boleh melepaskan GPU semasa menunggu alat. Beban kerjanya sangat kecil-kecil, tetapi serpihan-serpihan ini boleh disusun semula oleh scheduler.

Ini juga secara semula jadi mendorong soalan ke lapisan sumber: jika GPU yang sama boleh melayani lebih banyak Agen jangka panjang secara bersilang, maka masa kerja yang sebenarnya boleh disokong oleh GPU satu jam mungkin melebihi satu jam.

Andaikan sebuah Codex Agent memerlukan 60 minit dari menerima tugas hingga selesai, di mana hanya sebahagian masa sahaja digunakan untuk prefill dan decode model, manakala masa selebihnya digunakan untuk kompilasi, ujian, membaca dan menulis fail, atau menunggu alat. Nisbah spesifik ini akan berbeza mengikut tugas, tetapi strukturnya penting: masa wall-clock Agent dan masa komputasi GPU tidak sama satu kepada satu.

Jika terdapat banyak agen secara serentak dalam sistem, mereka tidak akan memerlukan GPU pada saat yang sama dalam satu saat. Ada yang sedang prefill, ada yang sedang decode, ada yang menjalankan ujian, dan ada yang menunggu sistem fail. Selama penjadual boleh menginterleavkan fasa-fasa ini, GPU yang terhad boleh menyokong aliran kerja aktif yang jauh melebihi bilangan GPU.

Anda boleh memahami hubungan ini secara kasar: Agent-hours bergantung kepada GPU-hours, nisbah beban inferensi model, dan kecekapan penjadualan. Semakin lama masa pelaksanaan alat, semakin tebal batch, dan semakin tinggi kejayaan cache, semakin banyak masa kerja Agent wall-clock yang boleh disokong oleh satu jam GPU.

Ini akan secara langsung mengubah maksud penambahan GPU. Menambahkan sejumlah GPU ke Codex tidak hanya membuat tugas individu lebih cepat, tetapi juga memungkinkan sistem untuk mengeksekusi lebih banyak Agent secara serentak. Seorang jurutera boleh memulakan beberapa tugas secara serentak — satu mengubah backend, satu memperbaiki ujian, satu menangani repositori lain — selagi tugas-tugas ini tidak bergantung kuat antara satu sama lain, masa kerja mesin boleh meningkat secara serentak.

Lengkung kapasiti Sora lebih langsung. Masa wall-clock yang panjang untuk satu video secara langsung mendorong diffusion di GPU, menggabungkan tugas tunggal dan penggunaan GPU dengan lebih rapat. GPU tambahan boleh secara langsung meningkatkan throughput video, tetapi jarak antara masa GPU satu jam dan masa pengiraan video sukar untuk diperbesarkan secara besar-besaran.

Tugasan perisian Codex bergerak di antara GPU, CPU, kontena, sistem fail, dan persekitaran alat. GPU bertanggungjawab atas inferens model, sementara sistem lain menjalankan tugas, dan beberapa Agent berbagi kapasiti inferens secara bersilang melalui scheduler. Dengan demikian, GPU berubah dari peranti penghasilan semata-mata menjadi sumber “pemikiran” yang langka dalam keseluruhan sistem Agent.

Inilah sebabnya Codex, walaupun mampu mengonsumsi banyak compute, lebih mudah mendapatkan compute baru. OpenAI perlu melihat bukan hanya kos inferens tunggal, tetapi juga sama ada kapasiti tambahan boleh ditukar dengan cepat kepada beban kerja selari yang lebih banyak.

Apabila sekumpulan GPU mampu menyokong lebih banyak Agent jangka panjang, dan Agent tersebut mampu menerima tugas perisian baru secara berterusan, sumber akan dengan mudah terus mengalir ke arah ini.

Makna teknikal perkataan Altman juga menjadi jelas. Kekuatan komputasi besar Sora terkunci dalam satu laluan penghasilan tunggal, manakala kekuatan komputasi Codex dibahagikan kepada beberapa peringkat yang boleh saling tindih. Kedua-duanya sama mahal, tetapi lengkung pulangan sumber berbeza.

Penerangan pemindahan sumber daya Sora dan Codex, produk AI kini memperkenalkan satu pemboleh ubah tambahan yang secara langsung mempengaruhi kelajuan pengembangan: workload architecture.

Menggunakan GPU yang mahal yang sama, satu jenis tugas mengunci sejumlah besar kekuatan pengiraan ke dalam satu laluan penghasilan, manakala jenis tugas lain boleh menggunakan cache, batching, pelaksanaan alat, dan penjadualan untuk menggabungkan kapasiti inferens yang sama kepada lebih banyak aliran kerja, maka lengkung sumber mereka akan secara semula jadi berbeza.

Oleh itu, beberapa isu yang kelihatan sangat asas akan semakin mendekati isu produk. Bagaimana KV cache diletakkan, bagaimana prefill dipotong, seberapa tebal decode batch boleh dimuatkan, dan sama ada agent yang menunggu alat perlu mengusir cache—pilihan-pilihan ini akhirnya akan menentukan berapa banyak tugas yang boleh dikekalkan secara serentak oleh sekumpulan GPU.

Perbezaan antara Sora dan Codex bukan sekadar perbezaan antara video dan kod.

Mereka bersaing untuk GPU yang sama dalam satu jam, dan seberapa banyak kerja yang boleh ditanggung.