Ultraman mengungkapkan dalam podcast mengapa OpenAI lebih memprioritaskan sumber daya untuk Codex daripada Sora. Generasi video Sora memerlukan daya komputasi berkelanjutan yang besar, dengan setiap tugas memakan waktu GPU yang sulit digunakan ulang; sementara Codex melalui mekanisme seperti KV cache, continuous batching, dan pemanggilan alat, mendistribusikan daya komputasi ke beberapa tahap yang dapat saling bersilangan, memungkinkan satu GPU yang sama untuk mendukung lebih banyak alur kerja paralel. Kemampuan penggunaan ulang waktu GPU mulai menentukan kecepatan ekspansi produk AI.

Penulis artikel, sumber: Leifengwang

Mengapa Sora kalah dari Codex?

Pada 23 Agustus, Otomaton secara aktif menyebut Sora saat membahas pengalokasian sumber daya di dalam OpenAI di podcast David Senra.

Dia mengatakannya secara langsung: Sora adalah produk yang baik, dan jika dilanjutkan, bisa menjadi bisnis yang cukup baik, tetapi terlalu memakan compute. Pada periode yang sama, prioritas Codex lebih tinggi, sehingga sumber daya komputasi dan tim mulai dialihkan ke Codex.

Tapi yang menarik, Codex sebenarnya juga tidak hemat GPU. Untuk menghasilkan satu video, Sora memerlukan perhitungan Transformer berulang kali pada latent spasial-waktu yang besar; sementara Codex yang menerima perintah “perbaiki bug ini” dapat menjalankan banyak putaran inferensi secara berurutan, membaca kode, memanggil alat, menjalankan pengujian, lalu kembali dengan log dan konteks baru untuk melanjutkan inferensi.

Satu menekankan daya komputasi ke dalam satu kali generasi video, sementara yang lain mendistribusikan daya komputasi ke dalam alur kerja Agent yang bisa berlangsung selama puluhan menit atau lebih. Oleh karena itu, perbedaan sejati antara Sora dan Codex mulai muncul di dalam ruang server.

Dengan GPU yang sama, mengapa komputasi untuk generasi video lebih sulit untuk dibagi, sementara Coding Agent dapat memasukkan kembali daya komputasi ke dalam lebih banyak tugas paralel melalui KV cache, continuous batching, penjadwalan prefill/decode, dan menunggu alat?

Faktanya, Sora bukan kalah karena konsumsi daya komputasi absolutnya, tetapi karena arsitektur beban kerjanya: daya komputasi Sora bersifat kontinu dan eksklusif, sedangkan daya komputasi Codex bersifat terfragmentasi dan dapat digunakan ulang. Perbedaan mekanisme penjadwalan inilah yang memperbesar kecepatan ekspansi keduanya.

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

Biaya Sora mungkin sudah mulai meningkat sejak video masuk ke dalam model. Ia terlebih dahulu akan mengompres video asli ke dalam latent space, lalu memotongnya menjadi spacetime patches, sehingga Transformer dapat menghitung pada patch-patch tersebut.

Token teks terutama tumbuh sepanjang arah sekuens, sedangkan patch video tersebar secara serentak di waktu, tinggi, dan lebar, sehingga video secara alami merupakan keadaan tiga dimensi di dalam model.

Secara kasar, jumlah token visual dapat dipahami sebagai N_video ≈ T × H × W. Di sini, T, H dan W telah dikompresi dan dipatch, tetapi hubungan perkalian tiga dimensi tetap ada.

Memperpanjang durasi video akan menambah patch pada arah waktu, sementara meningkatkan ukuran gambar akan memperluas patch spasial. Dengan kata lain, durasi video dan ukuran spasial tidak meningkatkan biaya secara independen; keduanya bersama-sama memperbesar grid laten.

Setelah blok grid memasuki Transformer, ia masih harus menghadapi perhitungan kedua yang dibawa oleh diffusion. Sora memulai dari latent yang berisik, setiap putaran memperbarui representasi video berdasarkan status saat ini, lalu mengirim latent baru ke putaran berikutnya.

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 iterations means running the network multiple additional times for the same video.

Di sini dapat dilihat perbedaan kunci antara video diffusion dan LLM. Saat model bahasa menghasilkan token berikutnya, Key dan Value sebelumnya dapat disimpan dalam KV cache, sehingga model tidak perlu membangun ulang seluruh status historis pada setiap langkah.

Setiap kali pembaruan video diffusion selesai, latent utama telah berubah, sehingga putaran berikutnya menghadapi keadaan ruang-waktu baru, sehingga sejumlah besar perhitungan untuk subjek video masih perlu dilanjutkan.

Jadi, biaya Sora sulit untuk secara signifikan mengurangi beban melalui "pemanfaatan ulang historis". Ia lebih mirip sebuah adegan efek visual yang menjalani beberapa siklus pemrosesan, di mana setiap siklus harus menangani seluruh gambar yang telah berubah. Semakin panjang video, semakin tinggi resolusinya, dan semakin banyak sampel yang diambil, semakin berat jalur generasi ini.

Karena tugas tunggal cukup berat, pemanfaatan GPU Sora justru mungkin terlihat sangat baik. Perhitungan matriks berukuran besar memungkinkan Tensor Core tetap sibuk dalam waktu lama, sehingga grafik pemantauan menunjukkan GPU hampir tidak pernah menganggur.

Utilisasi tinggi hanya menunjukkan bahwa chip terus bekerja, bukan berarti banyak tugas dikirimkan per satuan waktu. Jika satu video terus memakai satu set GPU dalam waktu lama, maka meskipun utilisasi terlihat bagus, GPU-seconds yang dikonsumsi per permintaan tetap tinggi.

Video serving masih akan terhambat oleh perbedaan bentuk. Durasi, resolusi, dan rasio aspek yang berbeda akan membentuk tensor shape yang berbeda. Untuk meningkatkan efisiensi batch, server perlu memasukkan permintaan dengan ukuran yang serupa ke dalam bucket yang sama. Menunggu sedikit lebih lama dapat mengumpulkan batch yang lebih padat, tetapi akan meningkatkan latensi antrian; menjalankan segera dapat mempersingkat waktu tunggu, tetapi batch mungkin tidak terisi penuh.

Oleh karena itu, sebagian besar biaya komputasi Sora telah terkunci dalam jalur generasi video itu sendiri. Jumlah sampling dapat dikurangi, latent dapat dikompresi lebih lanjut, model dapat didistilasi, kernel juga dapat dioptimalkan lebih lanjut, tetapi yang dapat diubah oleh scheduler terutama adalah “bagaimana mengatur urutan tugas-tugas berat ini”, sulit untuk mengubah fakta bahwa “satu video memang memerlukan banyak perhitungan berurutan”.

Ini juga merupakan pintu masuk untuk memahami Codex. Codex juga mahal, tetapi ia tidak membebani seluruh biaya pada satu blok komputasi berkelanjutan, melainkan membagi tugas menjadi banyak tahap yang dapat dihentikan, dilanjutkan, dan digabungkan kembali.

Pengguna memberi Codex perintah "perbaiki bug ini", tugas ini tidak akan berakhir dengan satu panggilan model. Agent mungkin terlebih dahulu membaca repositori, meminta model menentukan langkah selanjutnya, lalu menjalankan shell; setelah mendapatkan error, log ditambahkan ke konteks, lalu model dipanggil ulang; kemudian mengubah kode, menjalankan pengujian, dan terus bernalar berdasarkan hasil baru.

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

Pada awal tugas, model mungkin hanya memiliki permintaan pengguna dan sedikit kode. Setelah berjalan selama beberapa waktu, lebih banyak file, diff, output terminal, log pengujian, dan hasil alat terus masuk ke prompt.

Yang mungkin baru dilihat pengguna hanyalah penjelasan singkat berjumlah ratusan kata, namun konten yang telah diproses oleh GPU mungkin sudah sangat besar. Tekanan pada konsumsi token Agent tersimpan di dalam jejak pekerjaan yang terus bertambah ini.

Jika setiap iterasi inference memproses seluruh riwayat secara ulang, tugas panjang akan cepat terhambat oleh prefill berulang, sehingga prompt caching sangat penting bagi Codex.

Misalkan sebuah Agent telah memiliki konteks 100K token, dan setelah eksekusi alat hanya menambahkan 3K token log, jika prefix stabil sebelumnya dapat mencocokkan cache, maka perhitungan tambahan kali ini terutama terfokus pada bagian belakang ini; sekali perubahan pada bagian awal prompt menyebabkan cache miss, sistem mungkin harus menghadapi kembali prefill yang sangat berat.

Ada perubahan penting di sini: jumlah token logis tidak lagi dapat secara langsung mewakili biaya GPU sebenarnya. Kedua permintaan menunjukkan 100K token input, tetapi satu di antaranya sebagian besar kontennya sudah di-cache, sementara yang lain memerlukan perhitungan ulang, sehingga beban mereka terhadap GPU sangat berbeda. Beban Agent oleh karena itu bergantung pada kecepatan pertumbuhan konteks, cache hit, dan seberapa sering suatu tugas masuk kembali ke dalam model.

Setelah memasuki inference satu kali, prefill dan decode memiliki kebutuhan perangkat keras yang berbeda. Prefill memproses banyak token masukan sekaligus, dengan ukuran matriks yang besar, sehingga lebih mudah membentuk beban kerja yang berat secara komputasi; decode menghasilkan sedikit token per siklus untuk setiap sequence, tetapi harus mengakses berulang-ulang bobot model dan KV cache, sehingga lebih bergantung pada bandwidth HBM dan skala konkurensi.

Ini berarti bahwa decoding jika dijalankan secara terpisah untuk satu sequence akan sangat tidak efisien. Bobot model tetap sebesar itu, dan untuk menghasilkan satu token, diperlukan satu perhitungan forward penuh. Server hanya dapat mempercepat lebih banyak permintaan secara bersamaan dengan memasukkan banyak sequence ke dalam satu batched forward.

Namun, batch tidak dapat terus diperbesar karena dibatasi oleh KV cache. Semakin panjang konteks setiap sequence, semakin banyak HBM yang digunakan. Setelah jumlah agent meningkat, GPU mungkin masih memiliki sisa daya komputasi, tetapi memori video sudah tidak mampu menampung lebih banyak status aktif.

Desain semacam PagedAttention mengelola cache KV secara halaman, mengurangi fraktur memori GPU, pada dasarnya meningkatkan jumlah urutan aktif yang dapat ditampung secara bersamaan oleh satu GPU.

Pemanggilan alat lebih lanjut membagi beban Codex. Saat Agent menjalankan pengujian, mengompilasi kode, atau menunggu I/O, GPU tidak perlu terus bekerja untuknya; CPU, kontainer, dan sistem file akan mengambil alih. Setelah hasil kembali, Agent ini akan memasuki siklus inferensi berikutnya.

Jadi, sebuah Agent yang berjalan selama 60 menit tidak berarti secara terus-menerus memakai GPU selama 60 menit. Waktu tugasnya dibagi menjadi dua bagian: perhitungan model dan eksekusi eksternal, yang memberi scheduler ruang yang sulit disediakan oleh Sora: ketika sebuah Agent menjalankan alat, GPU dapat segera melayani urutan lainnya.

Tentu, ini juga akan menciptakan masalah memori baru. Apakah agen yang menunggu alat harus tetap mempertahankan KV cache? Mempertahankannya memungkinkan pemulihan yang lebih cepat, tetapi akan secara permanen memakan HBM; mengusirnya dapat melepaskan ruang, tetapi ketika tugas kembali, biaya pemulihan harus ditanggung. Semakin banyak jumlah agen, semakin mirip pertimbangan ini dengan cara sistem operasi mengelola sejumlah besar proses yang tidur dan bangun.

Di sini, perbedaan antara Codex dan Sora bukan lagi tentang "siapa yang lebih berat", tetapi apakah biayanya telah dipisahkan. Daya komputasi Sora terkonsentrasi pada satu jalur generasi kontinu, sementara daya komputasi Codex tersebar di beberapa tahap. Karena dipisahkan, Codex dapat memasuki optimasi tingkat berikutnya: membiarkan scheduler menentukan bagaimana tahap-tahap ini berbagi sekelompok GPU yang sama.

Saat model besar berjalan secara daring, bobot biasanya harus tetap berada di GPU dalam jangka panjang, serta mempertahankan status tensor parallel, komunikasi node, dan cache. Oleh karena itu, persaingan sumber daya antara Sora dan Codex lebih sering terjadi di tingkat fleet: sebagian GPU tetap berada di pool video serving, sementara sebagian lainnya tetap berada di pool LLM, dan sistem kapasitas lapisan atas menentukan mana yang perlu diperluas dan mana yang perlu dikurangi.

Hal yang benar-benar kompleks terjadi di dalam Codex pool. Misalkan sistem secara bersamaan memiliki 200 baris Agent sequence, sebagian sedang decode, sebagian menunggu alat, dan puluhan baru saja kembali dari lingkungan alat, perlu memproses konteks panjang baru. Scheduler menghadapi batasan tidak hanya mencakup FLOPs, tetapi juga kapasitas HBM, bandwidth memori, residensi KV cache, dan anggaran latensi.

Continuous batching terlebih dahulu menyelesaikan masalah pemanfaatan decode. Batch statis tradisional akan mengikat sekelompok permintaan bersama-sama, sehingga setelah permintaan dengan sequence pendek selesai, permintaan panjang yang tersisa masih memakan bagian batch.

Continuous batching akan secara dinamis mengganti entri pada tingkat iterasi token, dengan setiap sequence yang selesai dikeluarkan, dan permintaan baru segera menggantikannya. Semakin besar batch, semakin banyak sequence yang dapat diproses dalam satu siklus perhitungan model, sehingga biaya akses bobot model dan bandwidth memori menjadi lebih mudah dibagi.

Namun di sini akan segera menghadapi dinding memori video. Cache KV dari banyak Agent panjang akan terus memakan HBM, sehingga mungkin GPU belum memaksimalkan Tensor Core, tetapi memori video sudah penuh dengan sequence tambahan. Pada titik ini, menambahkan daya komputasi tidak lagi bermakna; yang benar-benar membatasi konkurensi adalah kapasitas cache dan manajemen memori video.

Ada konflik lain antara prefill dan decode. Misalnya, puluhan sequence sedang decode secara stabil, lalu sebuah Agent kembali dengan konteks baru sebesar 100K token yang memerlukan prefill besar. Jika prefill ini memakan jendela eksekusi yang panjang, TPOT dari permintaan di sampingnya akan menurun secara signifikan.

Chunked prefill akan membagi input panjang menjadi beberapa bagian kecil, memungkinkan eksekusi prefill dan decode secara bergantian; pendekatan lebih lanjut adalah memisahkan prefill dan decode ke dalam pool GPU yang berbeda.

Alasannya adalah dua tahap ini secara inheren cenderung pada bottleneck perangkat keras yang berbeda: prefill lebih bergantung pada throughput komputasi, sedangkan decode lebih bergantung pada bandwidth HBM, cache KV, dan latensi per token yang stabil. Dengan memisahkannya, sumber daya dapat dikonfigurasi secara terpisah sesuai kebutuhan masing-masing.

Ini menunjukkan bahwa inti dari Agent serving telah melampaui sekadar "membuat kernel model lebih cepat". Banyak peningkatan kapasitas berasal dari penataan ulang kapan dan di mana tugas dijalankan, status mana yang layak tetap berada di memori GPU, serta siapa yang seharusnya dimasukkan ke dalam batch saat ini.

Oleh karena itu, pemanfaatan GPU di sini sudah tidak cukup. Tim kapasitas perlu memantau sekaligus GPU-seconds per task, TTFT (latensi kata pertama, yang menentukan seberapa lancar pengguna merasakan), TPOT (waktu generasi per kata, yang menentukan seberapa cepat model "berbicara"), queueing latency, prefix cache hit, KV cache occupancy, dan SLO goodput (throughput efektif, yang mewakili daya komputasi yang benar-benar dapat menghasilkan pendapatan).

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

Kemampuan penjadwalan Codex terlihat di sini. Prefix stabil dapat mengurangi prefill berulang, decode dapat melakukan batch berkelanjutan, cache KV dapat dipaging dan dievakuasi, dan Agent dapat melepaskan GPU saat menunggu alat. Beban kerjanya sangat terpecah, tetapi fragmen-fragmen ini dapat diatur ulang oleh scheduler.

Ini juga secara alami mendorong pertanyaan ke lapisan sumber daya: jika sekelompok GPU yang sama dapat melayani lebih banyak Agent jangka panjang secara bergantian, maka waktu kerja yang sebenarnya dapat didukung oleh satu jam GPU mungkin lebih dari satu jam.

Misalkan sebuah Codex Agent membutuhkan waktu 60 menit dari awal hingga menyelesaikan tugas, di mana hanya sebagian waktu yang benar-benar digunakan untuk prefill dan decode model, sedangkan waktu sisanya digunakan untuk kompilasi, pengujian, membaca dan menulis file, atau menunggu alat. Proporsi spesifiknya akan bervariasi tergantung tugas, tetapi strukturnya penting: waktu wall-clock Agent dan waktu komputasi GPU tidak berbanding satu-satu.

Jika sistem memiliki banyak agen secara bersamaan, mereka tidak akan membutuhkan GPU pada detik yang sama. Ada yang sedang prefill, ada yang sedang decode, ada yang menjalankan pengujian, dan ada yang menunggu sistem file. Selama scheduler dapat mengatur ulang tahapan-tahapan ini secara bergantian, GPU terbatas dapat mendukung jumlah alur kerja aktif yang jauh lebih besar daripada jumlah GPU.

Hubungan ini dapat dipahami secara kasar sebagai: Agent-hours bergantung pada GPU-hours, rasio penggunaan model inferensi, dan efisiensi penjadwalan. Semakin lama waktu eksekusi alat, semakin tebal batch, dan semakin tinggi cache hit, maka satu jam GPU semakin berpeluang mendukung durasi Agent wall-clock yang lebih panjang.

Ini akan secara langsung mengubah makna penambahan GPU baru. Menambahkan sejumlah GPU ke Codex tidak hanya membuat tugas tunggal lebih cepat, tetapi juga memungkinkan sistem untuk menjalankan lebih banyak Agent secara bersamaan. Seorang insinyur dapat memulai beberapa tugas secara paralel: satu memperbarui backend, satu memperbaiki pengujian, satu menangani repositori lain—selama tugas-tugas ini tidak memiliki ketergantungan kuat, waktu kerja mesin dapat meningkat secara paralel.

Kurva kapasitas Sora lebih langsung. Waktu wall-clock yang panjang untuk satu video secara langsung mendorong diffusion di GPU, sehingga tugas tunggal dan penggunaan GPU lebih terintegrasi. GPU tambahan dapat langsung meningkatkan throughput video, tetapi jarak antara satu jam GPU dan waktu komputasi video sulit diperbesar secara signifikan.

Sebuah tugas perangkat lunak dari Codex berpindah di antara GPU, CPU, kontainer, sistem file, dan lingkungan alat. GPU bertanggung jawab atas inferensi model, sementara sistem lainnya menangani eksekusi, dan beberapa Agent berbagi kapasitas inferensi secara bergantian melalui scheduler. Akibatnya, GPU berubah dari perangkat generasi biasa menjadi sumber daya "pemikiran" yang langka dalam seluruh sistem Agent.

Inilah mengapa Codex, meskipun sama-sama dapat menyerap banyak compute, lebih mudah mendapatkan compute baru. OpenAI perlu melihat bukan hanya biaya inferensi sekali jalan, tetapi juga apakah kapasitas tambahan dapat segera diubah menjadi lebih banyak pekerjaan paralel.

Ketika sejumlah GPU dapat mendukung lebih banyak Agent jangka panjang, dan Agent-agent ini secara terus-menerus menerima tugas perangkat lunak baru, sumber daya akan dengan mudah terus mengalir ke arah ini.

Makna teknis dari pernyataan Altman itu pun menjadi jelas. Sebagian besar daya komputasi Sora terkunci dalam satu jalur generasi tunggal, sementara daya komputasi Codex dibagi menjadi beberapa tahap yang dapat saling bersilangan. Keduanya sama-sama mahal, tetapi kurva pengembalian sumber dayanya berbeda.

Penjelasan pemindahan sumber daya Sora dan Codex, produk AI mulai memiliki satu variabel tambahan yang secara langsung memengaruhi kecepatan ekspansi: workload architecture.

Menggunakan GPU mahal yang sama, satu jenis tugas mengunci sejumlah besar daya komputasi ke dalam satu jalur generasi, sementara jenis tugas lainnya dapat menggunakan caching, batching, eksekusi alat, dan penjadwalan untuk menggabungkan kapasitas inferensi yang sama ke lebih banyak alur kerja, sehingga kurva sumber dayanya secara alami akan terpisah.

Jadi, beberapa masalah yang tampaknya sangat mendasar di masa depan akan semakin mendekati masalah produk. Bagaimana menempatkan KV cache, bagaimana membagi prefill, seberapa tebal decode batch bisa diisi, apakah agent yang menunggu alat harus mengusir cache—pilihan-pilihan ini pada akhirnya akan menentukan berapa banyak tugas yang dapat dipertahankan secara bersamaan oleh sejumlah GPU.

Perbedaan antara Sora dan Codex bukan hanya perbedaan antara video dan kode.

Mereka bersaing untuk GPU yang sama dalam satu jam, seberapa banyak pekerjaan yang bisa ditanggung.