Ultraman, podcast'te OpenAI'nin neden Codex'e Sora'dan daha fazla kaynak ayırdığını açıkladı. Sora'nın video üretimi, büyük miktarda sürekli hesaplama gücü gerektirir ve tek bir görev, GPU zamanını tekrar kullanılamaz hale getirir; ancak Codex, KV önbelleği, sürekli toplu işleme ve araç çağrısı gibi mekanizmalarla hesaplama gücünü birden fazla çakışan aşamaya dağıtır ve aynı GPU'nun daha fazla paralel iş akışını desteklemesini sağlar. GPU zamanı yeniden kullanım kapasitesi, AI ürünlerinin genişleme hızını belirlemeye başlıyor.

Makale yazarı, kaynak: Leifengwang

Sora, Codex'e neden kaybetti?

23 Ağustos'ta, Otomani, David Senra'nın podcast'inde OpenAI içi kaynak tercihlerinden bahsederken Sora'ya açıkça değindi.

Çok açık bir şekilde söyledi: Sora kendisi iyi bir ürün, devam edilirse iyi bir iş haline gelebilir, ancak çok fazla hesaplama gücü gerektiriyor; aynı dönemde Codex'in önceliği daha yüksek olduğu için hesaplama gücü ve ekip kaynakları Codex'e doğru kaymaya başladı.

Ancak ilginç olan, Codex'in aslında GPU'yu hiç de tasarruf etmemesi. Sora, uzun bir video üretmek için büyük bir uzay-zaman latent'ini çok sayıda Transformer hesaplamasından geçirir; Codex, "Bu hatayı düzelt" gibi bir komut aldığında, arka planda birçok kez çıkarım yapar, kodu okur, araçları çağırır, testleri çalıştırır ve yeni günlüklerle ve bağlamla birlikte tekrar çıkarım yapmaya devam eder.

Biri hesaplama gücünü tek bir video üretimi üzerine yoğunlaştırırken, diğeri bu gücü onlarca dakika hatta daha uzun sürebilen bir Agent iş akışına yayıyor. Bu nedenle, Sora ve Codex arasındaki gerçek farklar veri merkezi içine düşmeye başlıyor.

Aynı GPU setiyle neden video üretimi için hesaplama gücü daha az paylaşılırken, Coding Agent, KV önbelleği, sürekli toplu işleme, ön doldurma/çözümleme zamanlaması ve araç bekleme ile hesaplama gücünü daha fazla eşzamanlı görev içine geri sokabiliyor?

Aslında Sora, hesaplama gücü tüketiminin mutlak değerinde kaybetmedi, ancak iş yükü mimarisinde kaybetti: Sora'nın hesaplama gücü sürekli ve özel kullanıma sahipken, Codex'in hesaplama gücü parçalı ve yeniden kullanılabilir. Bu planlama mekanizması farkı, ikisinin genişleme hızını ayırdı.

Bu çizgi boyunca ilerledikçe, Sora'nın kaybettiği kaynakların arkasında belki de GPU zamanının nasıl kullanılacağına dair bir seçim olduğunu görebilirsiniz.

Sora'nın maliyeti, video model içine girdiği anda zaten artmaya başlamış olabilir. Öncelikle orijinal videoyu latent space'e sıkıştırır, ardından spacetime parçalarına böler ve Transformer bu parçalar üzerinde hesaplama yapar.

Metin token'ları genellikle dizgi yönünde büyür, video parçaları ise zaman, yükseklik ve genişlik üzerinde aynı anda yayılır; bu nedenle video, model içinde doğal olarak hacimli bir durumdur.

Görsel token sayısı, yaklaşık olarak N_video ≈ T × H × W olarak anlaşılabilir. Buradaki T、H ve W zaten sıkıştırılmış ve parçalara ayrılmış durumda, ancak üç boyutlu çarpma ilişkisi hâlâ mevcuttur.

Video süresinin uzaması, zaman yönünde patch’leri artırır; görüntü boyutunun artırılması ise uzaysal patch’leri genişletir. Yani video uzunluğu ve uzaysal boyut, maliyeti bağımsız olarak artırmaz; birlikte latent ızgarayı genişletirler.

Bu ızgara, Transformer'a girdikten sonra diffusion'un getirdiği ikinci bir hesaplama aşamasıyla karşılaşıyor. Sora, gürültülü bir latent ile başlar, her adımda mevcut duruma göre video temsili günceller ve yeni latent'i bir sonraki adıma iletir.

Bir video için hesaplama miktarı yaklaşık olarak C_video ≈ D × C_transformer(N_video) şeklinde anlaşılabilir, burada D örnekleme iterasyon sayısıdır. Video latent değeri ne kadar büyükse, her iterasyon o kadar ağırdır; örnekleme sayısı arttıkça, aynı video için ağ daha fazla kez çalıştırılır.

Burada video diffusion ile LLM arasındaki temel fark görülebilir. Dil modelleri, sonraki token'ları üretirken önceki Key ve Value'ları KV önbelleğinde saklayabilir ve model her adımda tüm geçmiş durumunu yeniden oluşturmak zorunda değildir.

Her bir güncelleme döngüsünün tamamlanmasından sonra ana latent değişmiştir, bir sonraki döngü yeni bir zaman-mekân durumuyla karşı karşıya kalır, bu nedenle video ana nesnesinin büyük bir kısmı hesaplama işlemine devam etmelidir.

Bu nedenle Sora'nın maliyeti, "geçmişleri yeniden kullanmak" yoluyla büyük ölçüde azaltılamaz. Daha çok, her adımda zaten değişmiş bir görüntü bloğunu işleyen bir görsel efekt sahnesinin çoklu işlem aşamalarına benzer. Video ne kadar uzun, boyut ne kadar yüksek ve örneklem ne kadar çok olursa, bu üretim yolu o kadar ağırlaşır.

Bir görevin yeterince ağır olması nedeniyle Sora'nın GPU kullanım oranı aslında oldukça iyi görünebilir. Büyük boyutlu matris hesaplamaları, Tensor Core'ların uzun süre meşgul kalmasını sağlar ve izleme grafiklerinde GPU neredeyse hiç boş kalmaz.

Yüksek kullanım oranı, çipin sürekli çalıştığını gösterir, ancak birim zamanda birçok görev tamamladığı anlamına gelmez. Bir video, bir GPU grubunu uzun süre kaplıyorsa, kullanım oranı ne kadar iyi olursa olsun, tek bir isteğin harcadığı GPU-saniyesi hâlâ yüksek kalır.

Video hizmeti, şekil farklılıkları nedeniyle hâlâ takılı kalıyor. Süre, çözünürlük ve en-boy oranı farklılığı, farklı tensor şekilleri oluşturuyor. Sunucu, toplu iş verimliliğini artırmak için boyutları birbirine yakın olan istekleri aynı kovaya yerleştiriyor. Biraz daha beklemek, daha kalın bir toplu iş oluşturabilir ancak kuyruk gecikmesini artırır; hemen çalıştırmak bekleme süresini kısaltır ancak toplu iş tam olarak doldurulmayabilir.

Bu nedenle, Sora'nın büyük bir kısmı hesaplama maliyeti, bir videonun kendi üretimi yolunda kilitlenmiştir. Örneklem döngüleri azaltılabilir, latent veriler daha da sıkıştırılabilir, model özütlebilir, çekirdekler daha da optimize edilebilir, ancak zamanlayıcı, bu ağır görevlerin nasıl sıralanacağı üzerinde değişiklik yapabilir; ancak "bir videonun kendisi büyük miktarda ardışık hesaplama gerektirir" gerçeğini değiştirmek zordur.

Bu, Codex'i anlamak için bir giriş noktasıdır. Codex aynı şekilde pahalıdır, ancak tüm maliyeti tek bir sürekli hesaplama bloğuna yüklemek yerine, görevi durdurulabilir, yeniden başlatılabilir ve yeniden birleştirilebilen birçok aşamaya böler.

Kullanıcı, Codex'e "Bu hatayı düzelt" diyerek bir görev verir; görev bir model çağrısıyla sona ermeyecektir. Agent önce depoyu okuyabilir, modelden bir sonraki adımı belirlemesini isteyebilir, ardından shell komutunu çalıştırabilir; hata alındığında günlükleri bağlama ekleyip modeli yeniden çağırabilir; ardından kodu değiştirebilir, testleri çalıştırabilir ve yeni sonuçlara göre çıkarımlarını devam ettirebilir.

Yani bir Codex görevi birçok turun birikimine daha yakındırPrefill + Decode + Tool. Anahtar nokta, her bir araç çağrısı tamamlandığında, bir sonraki turda modelin gördüğü bağlamın genellikle önceki turdan daha kalın olmasıdır.

Görev başladığında, model yalnızca kullanıcı talebi ve az miktarda kodla başlayabilir. Bir süre çalıştıktan sonra, daha fazla dosya, diff, terminal çıktısı, test günlükleri ve araç sonuçları prompt'a sürekli eklenir.

Kullanıcının son olarak gördüğü belki de birkaç yüzlük bir tamamlama açıklamasıdır, ancak GPU'nun arka planda işlediği içerik zaten çok büyük olabilir. Agent token tüketimi baskısı, bu sürekli büyüyen çalışma izinde saklıdır.

Her bir çıkarım adımında tüm geçmiş yeniden işlenirse, uzun görevler hızla tekrarlanan prefill ile yavaşlayacaktır, bu nedenle prompt önbellekleme Codex için kritik öneme sahiptir.

Bir Agent'in 100K tokenlik bir bağlamı olduğu varsayılabilir; araç yürütmesi sadece 3K tokenlik bir günlük ekler. Eğer önceki sabit ön ek önbelleğe uygunsa, bu turda yapılan yeni hesaplama çoğunlukla son kısmında yoğunlaşır; ancak eğer promptun başlangıcı önbellek hatasına neden olursa, sistem tekrar ağır bir prefill ile karşı karşıya kalabilir.

Burada önemli bir değişiklik oluştu: mantıksal token sayısı artık doğrudan gerçek GPU maliyetini temsil edemiyor. İki istek de 100K girdi token gösteriyor, ancak birinde içerik büyük ölçüde önbellekte, diğerinde yeniden hesaplama gerekiyor; bu nedenle GPU üzerindeki yükleri tamamen farklı. Agent yükü dolayısıyla bağlam artış hızına, önbellek vuruşuna ve bir görevin modelde kaç kez tekrar girdiğine bağlı.

Tek seferlik inference'ya girildikten sonra, prefill ve decode farklı donanım ihtiyaçlarına sahiptir. Prefill, çok sayıda giriş token'ını aynı anda işler, matris boyutları büyüktür ve daha kolay şekilde hesaplama yoğun yük oluşturur; decode ise her döngüde her sequence için yalnızca az sayıda token üretir, ancak model ağırlıklarına ve KV önbelleğine tekrar tekrar erişir, bu nedenle HBM bant genişliği ve paralellik ölçeğine daha çok bağımlıdır.

Bu, tek bir diziyi ayrı olarak çalıştırdığınızda çok fazla kaynak harcanacağı anlamına gelir. Model ağırlıkları hâlâ aynı büyüklükte kalır ve bir token üretmek için bile tam bir ileri hesaplama yapılmalıdır. Sunucu, bir kez ağırlık erişimiyle daha fazla isteği ilerletebilmek için birçok diziyi aynı toplu ileri hesaplamaya dahil etmelidir.

Ancak batch boyutu artırılmaya devam edebilir mi, KV önbelleği sınırlamalarıyla karşılaşıyor. Her dizinin bağlamı ne kadar uzunsa, HBM'de o kadar çok yer kaplar. Agent sayısı arttıkça, GPU'da aritmetik kapasite kalmış olabilir, ancak bellek zaten daha fazla aktif durumu tutamıyor.

PagedAttention türü tasarımlar, KV önbelleğini sayfalama yoluyla yöneterek video belleği parçalanmasını azaltır ve temel olarak aynı anda bir GPU tarafından tutulabilen aktif dizilerin sayısını artırır.

Araç çağrısı, Codex'in yükünü daha da parçalıyor. Agent testleri çalıştırırken, kodu derlerken veya I/O beklerken GPU'nun ona devam etmesine gerek yok, CPU, konteyner ve dosya sistemi devreye giriyor. Sonuç döndükten sonra, bu Agent bir sonraki inference döngüsüne giriyor.

60 dakika süren bir Agent, 60 dakika boyunca GPU'yu sürekli işgal ettiğini anlamına gelmez. Görev süresi, model hesaplaması ve dışsel yürütme olmak üzere iki parçaya ayrılır; bu da scheduler'a Sora'nın sağlayamadığı bir boşluk sunar: Bir Agent arac çalıştırırken, GPU hemen başka bir sequence'e hizmet verebilir.

Bu, yeni bir bellek sorunu da yaratacaktır. Araçların Agent'ı KV önbelleğini korumaya devam edecek mi? Korumak, daha hızlı yeniden başlatma sağlar ancak HBM'yi uzun süre işgal eder; uzaklaştırmak yer açar ancak görev geri döndüğünde yeniden yükleme maliyeti ortaya çıkar. Agent sayısı arttıkça, bu tür seçimler, işletim sisteminin çok sayıda uyku ve uyanma durumunda olan işlemi yönetmesine benzer.

Buraya kadar Codex ve Sora arasındaki fark, "kim daha ağırlıklı" değil, maliyetin ayrılıp ayrılmadığıdır. Sora'nın hesaplama gücü, sürekli bir üretme yolunda yoğunlaşırken, Codex'in hesaplama gücü birçok aşamada dağılmıştır. Ayrıştırıldığı için Codex, scheduler'ın bu aşamaların nasıl aynı GPU kümesini paylaşacağını belirlemesine olanak tanır.

Büyük modellerin çevrimiçi çalıştırılması sırasında ağırlıklar genellikle GPU’da uzun süre kalır ve tensor paralellik, düğüm iletişimleri ve önbellek durumları korunur. Bu nedenle Sora ve Codex arasındaki kaynak rekabeti çoğunlukla filo düzeyinde gerçekleşir: bazı GPU’lar uzun süre video servis havuzuna, diğerleri ise ULL havuzuna sabitlenir; üst düzey kapasite sistemi ise hangi tarafın ölçeklendirileceğini veya ölçeklendirileceğini belirler.

Gerçekçe karmaşık olan şey Codex havuzunun içinde oluyor. Sistemde aynı anda 200 Agent dizisi bulunuyorsa, bunların bir kısmı decode ediliyor, bir kısmı araç bekliyor, ayrıca onlarca araç ortamından yeni uzun bağlam işleme ihtiyacıyla geri dönmüş durumda. Zamanlayıcıya sadece FLOPs değil, aynı zamanda HBM kapasitesi, bellek bant genişliği, KV önbelleği kalıcılığı ve gecikme bütçesi de dahil olmak üzere birçok kısıtlama sunuluyor.

Sürekli toplu işleme, önce decode kullanım oranını çözün. Geleneksel statik toplu işleme, bir grup isteği birbirine bağlar; kısa diziler bittikten sonra kalan uzun istekler hâlâ topluyu işgal eder.

Sürekli toplu işleme, token yineleme düzeyinde dinamik olarak kullanıcı değiştirecek, bir dizi tamamlandığında çıkarılacak ve yeni istekler hemen yerine gelecektir. Toplu boyut ne kadar büyükse, bir model hesaplama döngüsünde ilerletilebilen dizi sayısı o kadar çok olacak ve model ağırlıklarına erişim ile bellek bant genişliği maliyeti daha kolay dağıtılacaktır.

Ancak burada çok yakında bellek duvarına ulaşılacaktır. Büyük miktarda uzun Agent'in KV önbelleği, HBM'yi sürekli işgal eder; bir GPU'nun Tensor Core'ları tamamen dolmadan bile bellek, daha fazla dizini içerecek durumda olmayabilir. Bu noktada daha fazla hesaplama gücü eklemek anlamsızdır; gerçek paralellik sınırlayıcısı, önbellek kapasitesi ve bellek yönetimidir.

Prefill ve decode arasında başka bir çatışma da mevcuttur. Onlarca dizinin stabil şekilde decode edildiği bir anda, 100K token'lık yeni bir bağlamla dönen bir Agent büyük bir prefill gerçekleştirmek zorunda kalır. Eğer bu prefill uzun bir yürütme penceresini tek başına kaparlarsa, yanındaki isteklerin TPOT'u açıkça kötüleşir.

Chunked prefill, uzun girdileri birkaç küçük parçaya böler ve prefill ile decode işlemlerini交错 yürütür; daha ileri bir yaklaşım, prefill ve decode işlemlerini farklı GPU havuzlarına ayırır.

Nedeni, iki aşamanın kendiliğinden farklı donanım sınırlamalarına yatkın olmasıdır: prefill daha çok hesaplama verimliliğine, decode ise HBM bant genişliğine, KV önbelleğine ve sabit token başına gecikmeye bağımlıdır. Bunları ayırdıktan sonra, her biri kendi ihtiyaçlarına göre kaynaklar yapılandırılabilir.

Bu, Agent serving'in çekirdeğinin yalnızca "model çekirdeğini daha hızlı yazmak" aşamasını geçtiğini gösteriyor. Kapasite artışı, görevlerin ne zaman ve nerede çalıştırılacağını yeniden düzenlemek, hangi durumların GPU belleğinde tutulması gerektiğini ve mevcut batch'te kimin yer alacağını belirlemekten kaynaklanıyor.

Bu nedenle, GPU kullanım oranı burada yeterli değil. Kapasite ekibi, görev başına GPU-saniyesi, TTFT (ilk kelime gecikmesi, kullanıcıların yavaşlık hissetmesini belirler), TPOT (tek kelime üretme süresi, modelin ne kadar hızlı “konuştuğunu” belirler), kuyruk gecikmesi, önek önbellek vuruş oranı, KV önbellek doluluk oranı ve SLO iyi verimliliği (etkin verimlilik, gerçek olarak satılabilir hesaplama gücünü temsil eder) aynı anda izlemelidir.

Bu göstergeler birlikte şu soruyu cevaplar: Kullanıcıların kabul edebileceği gecikme altında, bir saatte bir GPU kaç etkin görevi sürdürebilir?

Codex'in esnekliği burada ortaya çıkar. Sabit önek, tekrarlayan prefill'i azaltır, decode sürekli toplu işleme yapabilir, KV önbelleği sayfalama ve tahliye edilebilir, Agent araçları beklerken GPU'yu serbest bırakabilir. İş yükü çok parçalı olsa da, bu parçalar scheduler tarafından yeniden düzenlenebilir.

Bu soruyu doğal olarak kaynak katmanına doğru itiyor: Eğer aynı GPU grubu daha fazla uzun süreli Agent'e ara sıra hizmet verebilirse, bir saatlik GPU aslında bir saatten daha fazla iş süresi destekleyebilir.

Bir Codex Agent'in bir görevi alarak tamamlaması 60 dakika sürerse, bu sürenin yalnızca bir kısmı modelin prefill ve decode işlemlerine harcanır; geri kalan süre derleme, test etme, dosya okuma/yazma veya araçların bekletilmesi için kullanılır. Bu oran görevden göreve değişebilir, ancak yapı önemlidir: Agent'in duvar saati süresi ile GPU hesaplama süresi birbirine eşit değildir.

Sistemde aynı anda çok sayıda Agent varsa bile, hepsi aynı saniyede GPU gerektirmeyecektir. Kimi prefill yapıyor, kimi decode yapıyor, kimi test çalıştırıyor, kimi dosya sistemi için bekliyor. Scheduler bu aşamaları birbirine karıştırabildiğinde, sınırlı GPU sayısı, GPU sayısından çok daha fazla aktif iş akışını destekleyebilir.

Bu ilişkiyi şu şekilde kabaca anlayabilirsiniz: Agent-saatleri, GPU-saatleri, model çıkarım doluluk oranı ve zamanlama verimliliğine bağlıdır. Araç yürütme süresi ne kadar artarsa, batch boyutu o kadar kalınlaşır ve önbellek vuruş oranı o kadar yükselecek; bu da bir saatlik GPU'nun daha uzun bir Agent duvar-saati işini destekleme şansını artırır.

Bu, yeni GPU eklemenin anlamını doğrudan değiştirecektir. Codex'e bir dizi GPU eklemek, tek bir görevin yalnızca daha hızlı tamamlanmasını değil, sistemin aynı anda daha fazla Agent tutmasını da sağlayabilir. Bir mühendis, bu görevler arasında güçlü bağımlılıklar yoksa, arka planı değiştirmek, testleri tamamlamak ve başka bir depoyu işlemek gibi birden fazla görevi paralel olarak başlatabilir; bu durumda makinenin çalışma süresi paralel olarak artar.

Sora'nın kapasite eğrisi daha doğrudur. Bir videonun uzun wall-clock süresi doğrudan GPU üzerinde difüzyonu ilerletir; tek bir görev ve GPU kullanımı daha sıkı bir şekilde birbirine bağlanır. Ek GPU'lar doğrudan video verimliliğini artırabilir, ancak bir saatlik GPU ve video hesaplama süresi arasındaki ilişkiyi büyük ölçüde açmak zordur.

Codex'in bir yazılım görevi, GPU, CPU, konteyner, dosya sistemi ve araç ortamları arasında hareket eder. GPU, model çıkarımını yürütür, diğer sistemler ise çalıştırma görevini üstlenir; birden fazla Agent, scheduler aracılığıyla çıkarım kapasitesini paylaşır. Bu sayede GPU, yalnızca bir üretim cihazı değil, tüm Agent sisteminde kıt bir “düşünme kaynağı” haline gelir.

Bu, Codex'in aynı miktarda compute tüketmesine rağmen daha kolay yeni compute elde etmesinin nedenidir. OpenAI'nin yalnızca tek bir çıkarım maliyetine değil, yeni kapasitenin hızla daha fazla paralel iş yüküne dönüştürülebilir olup olmadığına da bakması gerekir.

Bir GPU grubu daha fazla uzun vadeli Agent'i destekleyebildiğinde ve bu Agent'ler sürekli yeni yazılım görevleri alabildiğinde, kaynaklar bu yöne doğru kolayca akar.

Altman'ın bu ifadesinin teknik anlamı böylece netleşti. Sora'nın büyük hesaplama gücü tek bir üretim yolunda kilitli, Codex'in hesaplama gücü ise birbirine geçişli birden fazla aşamaya bölünmüş. Her ikisi de aynı maliyetli, ancak kaynak getiri eğrileri farklı.

Sora ve Codex için kaynak aktarım yönergeleri; AI ürünlerinde, genişleme hızını doğrudan etkileyen yeni bir değişken ortaya çıkıyor: workload architecture.

Aynı pahalı GPU'lar kullanılarak, bir tür görev büyük hesaplama gücünü tek bir üretim yoluna kilitler, diğer tür görevler ise önbellekleme, toplu işleme, araç yürütme ve zamanlama yoluyla aynı inference kapasitesini daha fazla iş akışına çapraz olarak dağıtır; bu nedenle kaynak eğrileri doğal olarak ayrılır.

Bu nedenle gelecekte görünecek bazı temel düzeydeki sorular, ürün sorularına giderek daha çok yaklaşacaktır. KV önbelleği nereye yerleştirilsin, prefill nasıl bölünsün, decode batch ne kadar kalın olabilir, bekleme aracı olan Agent önbelleği zorla kaldırmalı mı? Bu seçimler, bir dizi GPU'nun aynı anda kaç görevi aynı anda tutabileceğini sonunda belirleyecektir.

Sora ve Codex arasındaki fark, sadece video ve kod arasındaki fark değil.

Aynı saatlik GPU'yu kimin daha çok iş yükü taşıyabileceğini gösteriyorlar.