ऑटोमन ने पॉडकास्ट में बताया कि OpenAI ने Codex के बजाय Sora पर संसाधन क्यों केंद्रित किए। Sora के वीडियो जनरेशन के लिए बड़ी मात्रा में निरंतर कंप्यूटिंग पावर की आवश्यकता होती है, जिससे एकल कार्य के लिए GPU समय का पुनः उपयोग कठिन हो जाता है; जबकि Codex KV cache, continuous batching, और टूल कॉल के माध्यम से कंप्यूटिंग को कई अंतर्लिन्न चरणों में विभाजित करता है, जिससे एक ही GPU अधिक समानांतर वर्कफ्लो को समर्थन दे सकता है। GPU समय की पुनः उपयोगयोग्यता अब AI उत्पादों के विस्तार की गति निर्धारित करने लगी है।

लेखक, स्रोत: लेफेंगवेन

Sora क्यों हार गया Codex से?

23 अगस्त को, ऑटीमैन ने डेविड सेन्रा के पॉडकास्ट में OpenAI के आंतरिक संसाधनों के बारे में बात करते हुए Sora का उल्लेख किया।

उसने सीधे कहा: Sora खुद एक अच्छा उत्पाद है, और इसे आगे बढ़ाने से एक अच्छा व्यवसाय बन सकता है, लेकिन यह बहुत अधिक कंप्यूट की आवश्यकता रखता है, इसी समय, Codex की प्राथमिकता अधिक थी, इसलिए कंप्यूटिंग शक्ति और टीम का ध्यान Codex की ओर बढ़ने लगा।

लेकिन दिलचस्प बात यह है कि Codex वास्तव में GPU को भी बचाता नहीं है। Sora एक वीडियो जनरेट करता है, जिसमें विशाल स्पेशियो-टेम्पोरल latent को कई चक्रों में Transformer की गणना से गुजरना पड़ता है; Codex को "इस बग को ठीक कर दो" का निर्देश मिलता है, तो बैकग्राउंड में कई चक्रों में निष्पादन, कोड पढ़ना, उपकरणों का उपयोग, परीक्षण चलाना, और फिर नए लॉग और संदर्भ के साथ वापस आकर निष्पादन जारी रखना पड़ सकता है।

एक एकल वीडियो जनरेशन में कैलकुलेशन पावर को केंद्रित करता है, जबकि दूसरा कैलकुलेशन पावर को एक ऐसे एजेंट वर्कफ्लो में फैला देता है जो कुछ मिनटों या उससे अधिक समय तक चल सकता है। इसलिए, Sora और Codex के बीच असली अंतर डेटासेंटर के अंदर शुरू होता है।

एक ही GPU सेट के लिए, वीडियो जनरेशन की कंप्यूटिंग क्यों अधिक कठिन है जबकि कोडिंग एजेंट KV कैश, कंटिन्यूअस बैचिंग, प्रीफिल / डिकोड स्केड्यूलिंग और टूल वेटिंग के माध्यम से कैलकुलेशन को अधिक समानांतर कार्यों में वापस भर सकता है?

वास्तव में, Sora की हानि गणना उपभोग के निरपेक्ष मान में नहीं, बल्कि कार्य लोड आर्किटेक्चर में है: Sora की गणना निरंतर और अनन्य है, जबकि Codex की गणना टुकड़ों में और पुनः उपयोगयोग्य है। यही समय सारणीकरण तंत्र का अंतर दोनों की विस्तार दर को अलग करता है।

इस लाइन के नीचे देखने पर, लगता है कि Sora जिस हिस्से के संसाधनों को खो रहा है, उसके पीछे GPU समय का उपयोग कैसे किया जाए, इस पर एक चयन हो सकता है।

सोरा की लागत शायद वीडियो के मॉडल में प्रवेश के समय ही बढ़ने लग जाती है। यह पहले मूल वीडियो को latent space में संपीड़ित करता है, फिर spacetime patches में काट देता है, ताकि Transformer इन patches पर गणना कर सके।

टेक्स्ट टोकन मुख्य रूप से अनुक्रम दिशा में बढ़ते हैं, जबकि वीडियो पैच समय, ऊंचाई और चौड़ाई पर एक साथ फैले होते हैं, इसलिए वीडियो मॉडल के भीतर प्राकृतिक रूप से एक आयतन वाली स्थिति होती है।

On a rough level, 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.

वीडियो की अवधि बढ़ाने से समय दिशा में पैच बढ़ते हैं, और चित्र आकार बढ़ाने से स्थानिक पैच बढ़ते हैं। अर्थात, वीडियो की लंबाई और स्थानिक आकार अलग-अलग रूप से लागत बढ़ाते नहीं हैं, वे मिलकर latent ग्रिड को फैलाते हैं।

इस ग्रिड को Transformer में भेजने के बाद, इसे डिफ्यूजन द्वारा लाई गई दूसरी स्तर की गणना का सामना करना पड़ता है। Sora शोर वाले latent से शुरू होता है, प्रत्येक चक्र में वर्तमान स्थिति के आधार पर वीडियो प्रतिनिधित्व को अपडेट करता है, और फिर नया latent अगले चक्र में भेजता है।

单条视频的计算量可以粗略理解成 C_video ≈ D × C_transformer(N_video)，其中 D 是采样迭代次数。视频 latent 越大，每一轮越重；采样轮数增加，同一条视频又要多跑几轮网络。

यहाँ वीडियो डिफ्यूजन और LLM के मुख्य अंतर दिखाई देते हैं। भाषा मॉडल अगले टोकन को जनरेट करते समय, पिछले Key और Value को KV cache में सहेजा जा सकता है, और मॉडल को हर कदम पर पूरे इतिहास की स्थिति को पुनः बनाने की आवश्यकता नहीं होती है।

प्रत्येक अपडेट चक्र के बाद, वीडियो डिफ़्यूज़न में मुख्य latent परिवर्तित हो जाता है, और अगला चक्र एक नए स्पेस-टाइम स्टेट का सामना करता है, इसलिए वीडियो विषय के लिए बड़ी मात्रा में गणना जारी रखनी पड़ती है।

इसलिए Sora की लागत को "ऐतिहासिक पुनर्उपयोग" से बहुत अधिक कम नहीं किया जा सकता। यह एक विजुअल इफेक्ट शॉट की तरह है जो कई चरणों में प्रोसेस किया जाता है, जहां प्रत्येक चरण पहले से बदल चुकी पूरी छवि को प्रोसेस करता है। वीडियो जितना लंबा, उच्च रिज़ॉल्यूशन और अधिक सैंपल्स होगा, उतनी ही इस जनरेशन पथ की लागत बढ़ेगी।

चूंकि एकल कार्य पर्याप्त भारी है, इसलिए Sora का GPU उपयोग अच्छा दिख सकता है। बड़े आकार के मैट्रिक्स की गणना से टेंसर कोर लंबे समय तक व्यस्त रहते हैं, और मॉनिटरिंग ग्राफ में GPU लगभग कभी अनुपयोगी नहीं दिखता।

उच्च उपलब्धता केवल यह दर्शाती है कि चिप सतत कार्यरत है, लेकिन इसका अर्थ यह नहीं है कि इकाई समय में कई कार्य पूरे हुए हैं। यदि एक वीडियो लगातार कई GPU पर कब्जा बनाए रखता है, तो utilization कितना भी अच्छा क्यों न हो, प्रत्येक अनुरोध द्वारा खपत GPU-seconds अभी भी उच्च होगा।

वीडियो सर्विंग अभी भी शेप अंतर के कारण अटकी हुई है। अलग-अलग अवधि, रिज़ॉल्यूशन और अनुपात अलग-अलग टेंसर शेप बनाते हैं। सर्वर की बैच दक्षता बढ़ाने के लिए, समान बकेट में आकार के करीबी अनुरोध शामिल किए जाते हैं। कुछ समय और प्रतीक्षा करने से अधिक मोटी बैच बन सकती है, लेकिन पंक्ति में देरी बढ़ जाती है; तुरंत निष्पादित करने से प्रतीक्षा समय कम होता है, लेकिन बैच पूरी तरह से भरी नहीं हो सकती।

इसलिए, सोरा की अधिकांश कैलकुलेशन लागत एक वीडियो के अपने जनरेशन पथ में बंद हो चुकी है। सैंपलिंग राउंड कम किए जा सकते हैं, latent को आगे संपीड़ित किया जा सकता है, मॉडल को डिस्टिल किया जा सकता है, kernel को आगे ऑप्टिमाइज़ किया जा सकता है, लेकिन scheduler केवल “इन भारी कार्यों को कैसे व्यवस्थित किया जाए” पर ही प्रभाव डाल सकता है, “एक वीडियो के लिए स्वयं को बहुत सारी निरंतर कैलकुलेशन की आवश्यकता होती है” इस तथ्य को बदलना मुश्किल है।

यह कोडेक को समझने का एक अन्य तरीका है। कोडेक भी महंगा है, लेकिन यह सभी लागत को एक निरंतर गणना ब्लॉक पर नहीं डालता, बल्कि कार्य को कई ऐसे चरणों में विभाजित करता है जिन्हें रोका, पुनः शुरू किया और पुनः संयोजित किया जा सकता है।

उपयोगकर्ता ने Codex को "इस बग को ठीक करो" का निर्देश दिया, और कार्य एक बार के मॉडल कॉल से समाप्त नहीं होगा। एजेंट पहले रिपॉजिटरी पढ़ सकता है, मॉडल को अगला कदम निर्धारित करने के लिए भेज सकता है, फिर shell निष्पादित कर सकता है; त्रुटि प्राप्त करने के बाद, लॉग को संदर्भ में जोड़ सकता है, मॉडल को पुनः कॉल कर सकता है; इसके बाद कोड में संशोधन कर सकता है, परीक्षण चला सकता है, और नए परिणामों के आधार पर अतिरिक्त तर्क कर सकता है।

इसलिए एक Codex कार्य बहुत सारी राउंड के योग के बराबर होता है Prefill + Decode + Tool। महत्वपूर्ण बात यह है कि प्रत्येक टूल कॉल के पूरा होने के बाद, अगली राउंड में मॉडल द्वारा देखा गया संदर्भ अक्सर पिछली राउंड की तुलना में अधिक विस्तृत होता है।

शुरुआत में, मॉडल के पास केवल उपयोगकर्ता का अनुरोध और कुछ कोड होता है। कुछ समय बाद, अधिक फाइलें, diff, टर्मिनल आउटपुट, टेस्ट लॉग और टूल परिणाम प्रॉम्प्ट में आते रहते हैं।

उपयोगकर्ता अंततः जो कुछ हजार शब्दों का समापन विवरण देखता है, उसके पीछे GPU द्वारा संसाधित किया गया सामग्री बहुत विशाल हो सकती है। Agent token consumption का दबाव, इस लगातार बढ़ती कार्य अनुसरणी में छिपा हुआ है।

यदि प्रत्येक निष्कर्षण चक्र में पूरा इतिहास पुनः प्रसंस्कृत किया जाता है, तो लंबे कार्य शीघ्र ही पुनः प्रीफिल के कारण रुक जाएंगे, इसलिए प्रॉम्प्ट कैशिंग कोडेक के लिए महत्वपूर्ण है।

मान लीजिए एक एजेंट के पास 100K टोकन का कॉन्टेक्स्ट है, और टूल निष्पादन के बाद केवल 3K टोकन का लॉग जोड़ा जाता है; यदि पिछला स्थिर प्रीफिक्स कैश में मिल जाता है, तो इस चक्र में नवीनतम गणना मुख्य रूप से इस पिछले हिस्से पर केंद्रित होगी; यदि प्रॉम्प्ट के शुरुआती हिस्से में परिवर्तन के कारण कैश मिस हो जाता है, तो सिस्टम को फिर से एक भारी प्रीफिल का सामना करना पड़ सकता है।

यहाँ एक महत्वपूर्ण परिवर्तन आया है: लॉजिकल टोकन संख्या अब सीधे GPU लागत का प्रतिनिधित्व नहीं कर सकती। दोनों अनुरोधों में 100K इनपुट टोकन दिखाई देते हैं, जिनमें से एक का अधिकांश सामग्री पहले से कैश में है, जबकि दूसरे को पुनः गणना करने की आवश्यकता है, और उनका GPU पर दबाव अलग-अलग है। इसलिए, एजेंट का लोड संदर्भ की वृद्धि दर, कैश हिट, और एक कार्य कितनी बार मॉडल में पुनः प्रवेश करता है, पर निर्भर करता है।

एकल इन्फरेंस के प्रवेश के बाद, प्रीफिल और डिकोड के लिए अलग-अलग हार्डवेयर आवश्यकताएँ होती हैं। प्रीफिल एक साथ कई इनपुट टोकन को संसाधित करता है, जिसमें मैट्रिक्स का आकार बड़ा होता है और यह कम्प्यूट-भारी वर्कलोड बनाने के लिए अधिक संभावना रखता है; डिकोड प्रत्येक सीक्वेंस के प्रत्येक चरण में केवल कुछ ही टोकन उत्पन्न करता है, लेकिन मॉडल वजन और KV कैश को बार-बार एक्सेस करता है, इसलिए यह HBM बैंडविड्थ और समानांतरता पर अधिक निर्भर होता है।

इसका अर्थ है कि अगर एक अलग sequence को अलग से चलाया जाए, तो यह बहुत अधिक बर्बादी होगी। मॉडल वेट्स अभी भी उतने ही बड़े रहते हैं, और एक token जनरेट करने के लिए भी पूर्ण फॉरवर्ड कैलकुलेशन में भाग लेना पड़ता है। सर्वर को केवल कई sequence को एक ही batched forward में डालकर ही एक ही वेट्स एक्सेस के साथ कई अनुरोधों को आगे बढ़ाना संभव होता है।

और batch को आगे बढ़ाया जा सकता है, लेकिन KV cache के प्रतिबंधों से प्रभावित होता है। प्रत्येक sequence का संदर्भ जितना लंबा होगा, उतना ही अधिक HBM का उपयोग होगा। Agent की संख्या बढ़ने के बाद, GPU के पास गणितीय अतिरिक्त क्षमता हो सकती है, लेकिन विस्मृति में अधिक सक्रिय स्थितियाँ समायोजित नहीं हो पाएंगी।

PagedAttention जैसे डिज़ाइन KV कैश को पेजिंग आधारित प्रबंधन के माध्यम से कम वीडियो मेमोरी फ्रैगमेंटेशन के लिए डिज़ाइन किए गए हैं, जो मूल रूप से एक GPU द्वारा एक साथ समर्थित सक्रिय अनुक्रम की संख्या बढ़ाते हैं।

टूल कॉल ने कोडेक के लोड को आगे विभाजित कर दिया। जब एजेंट परीक्षण चलाता है, कोड को कंपाइल करता है या I/O का इंतजार करता है, तो GPU को इसके लिए आगे काम नहीं करना पड़ता, CPU, कंटेनर और फाइल सिस्टम इसे संभाल लेते हैं। जब परिणाम वापस आते हैं, तो यह एजेंट अगले इन्फरेंस चक्र में प्रवेश करता है।

एक 60 मिनट का Agent चलाना इस बात का अर्थ नहीं है कि GPU को 60 मिनट तक लगातार व्यस्त रखा जाए। इसका कार्य समय को मॉडल की गणना और बाहरी निष्पादन में विभाजित किया गया है, जिससे scheduler को एक ऐसा स्थान मिलता है जो Sora बहुत कठिनाई से प्रदान कर सकता है: जब कोई Agent टूल चलाता है, तो GPU तुरंत किसी अन्य sequence की सेवा कर सकता है।

इससे नए VRAM समस्याएँ भी पैदा होती हैं। टूल के एजेंट को KV कैश को बरकरार रखना चाहिए या नहीं? बरकरार रखने से त्वरित पुनर्स्थापना संभव होती है, लेकिन यह HBM को लंबे समय तक कब्जे में रखता है; निकालने से स्थान मुक्त होता है, लेकिन कार्य वापस आने पर पुनर्स्थापना लागत का सामना करना पड़ता है। जितने अधिक एजेंट होंगे, इस प्रकार के समझौते ऑपरेटिंग सिस्टम द्वारा बहुत सारे सोए हुए और जागने वाले प्रक्रियाओं के प्रबंधन की तरह होते हैं।

यहाँ तक, कोडेक और सोरा के बीच का अंतर अब “कौन अधिक भारी है” नहीं, बल्कि लागत को क्या तरीके से विभाजित किया गया है, इस पर है। सोरा की कैलकुलेशन शक्ति एक लगातार जनरेशन पथ में केंद्रित है, जबकि कोडेक की कैलकुलेशन शक्ति कई चरणों में बिखरी हुई है। इसीलिए, जब यह विभाजित होता है, तो कोडेक अगले स्तर के अनुकूलन में प्रवेश कर सकता है: जहाँ scheduler यह निर्धारित करता है कि ये चरण कैसे एक ही GPU समूह को साझा करें।

बड़े मॉडल के ऑनलाइन रन के दौरान, वेट्स को लंबे समय तक GPU पर रखा जाता है, और टेंसर पैरेलल, नोड कम्युनिकेशन और कैश स्टेट को भी बनाए रखना पड़ता है। इसलिए Sora और Codex के बीच संसाधनों के लिए प्रतिस्पर्धा अधिकतर fleet level पर होती है: कुछ GPU लंबे समय तक वीडियो सर्विंग पूल में रहते हैं, जबकि दूसरे लंबे समय तक LLM पूल में रहते हैं, और ऊपरी क्षमता प्रणाली यह निर्णय लेती है कि किस ओर विस्तार किया जाए और किस ओर संकुचित किया जाए।

वास्तविक जटिलता Codex पूल के अंदर हो रही है। मान लीजिए कि सिस्टम में 200 एजेंट अनुक्रम एक साथ मौजूद हैं, जिनमें से कुछ डिकोड कर रहे हैं, कुछ टूल का इंतजार कर रहे हैं, और कई दर्जन टूल वातावरण से वापस आए हुए हैं और नए लंबे कॉन्टेक्स्ट को प्रोसेस करने की आवश्यकता है। स्केड्यूलर के सामने केवल FLOPs ही नहीं, बल्कि HBM क्षमता, मेमोरी बैंडविड्थ, KV कैश निवास और लेटेंसी बजट जैसी सीमाएँ भी हैं।

कंटिन्यूअस बैचिंग पहले डिकोड के उपयोग दर की समस्या को हल करती है। पारंपरिक स्थिर बैच एक सेट के अनुरोधों को एक साथ बांध देता है, जिससे छोटी अनुक्रम समाप्त होने के बाद भी शेष लंबे अनुरोध बैच पर कब्जा बनाए रखते हैं।

कंटिन्यूअस बैचिंग टोकन इटरेशन स्तर पर डायनामिक रूप से यूजर्स को बदलती है, एक सीक्वेंस पूरा होने पर इसे हटा दिया जाता है, और नए अनुरोध तुरंत भर दिए जाते हैं। बैच जितना मोटा होगा, एक चक्र में मॉडल कैलकुलेशन द्वारा आगे बढ़ाए जा सकने वाले सीक्वेंस उतने ही अधिक होंगे, जिससे मॉडल वेट्स के एक्सेस और मेमोरी बैंडविड्थ की लागत को आसानी से वितरित किया जा सकता है।

लेकिन यहां जल्द ही वीडियो मेमोरी दीवार का सामना करना पड़ेगा। बड़ी संख्या में लंबे Agent के KV कैश सतत HBM का उपयोग करेंगे, और एक GPU अभी तक Tensor Core को पूरी तरह से इस्तेमाल नहीं कर पाई होगी, लेकिन वीडियो मेमोरी पहले ही अधिक sequence को समायोजित करने के लिए भर चुकी होगी। इस स्थिति में केवल कैलकुलेशन पावर बढ़ाने का कोई मतलब नहीं है; सच्ची सीमा कैश क्षमता और वीडियो मेमोरी प्रबंधन है।

Prefill और decode के बीच एक और संघर्ष मौजूद है। मान लीजिए कि कई sequence स्थिर रूप से decode कर रहे हैं, और एक Agent 100K token के नए संदर्भ के साथ लौटता है और बड़े prefill को निष्पादित करने की आवश्यकता होती है। यदि यह prefill एक लंबा निष्पादन विंडो कब्जा कर लेता है, तो पास के अनुरोधों का TPOT स्पष्ट रूप से खराब हो जाता है।

चंक्ड प्रीफिल लंबे इनपुट को कई छोटे ब्लॉक में विभाजित करता है, ताकि प्रीफिल और डिकोड को एक साथ एक्जीक्यूट किया जा सके; और इससे आगे, प्रीफिल और डिकोड को अलग-अलग GPU पूल पर विभाजित किया जा सकता है।

कारण यह है कि दोनों चरणों की अपनी अलग-अलग हार्डवेयर बॉटलनेक्स होती हैं: प्रीफिल कम्प्यूटेशनल थ्रूपुट पर अधिक निर्भर है, जबकि डिकोड HBM बैंडविड्थ, KV कैश और स्थिर टोकन-वाइज लेटेंसी पर अधिक निर्भर है। उन्हें अलग करने के बाद, आप अपनी-अपनी आवश्यकताओं के अनुसार संसाधनों को कॉन्फ़िगर कर सकते हैं।

यह बताता है कि एजेंट सर्विंग का कोर अब केवल "मॉडल कर्नेल को तेज़ लिखना" से आगे निकल चुका है। अधिकांश क्षमता वृद्धि यह फैसला करके प्राप्त होती है कि कार्य कब और कहाँ चलाए जाएं, कौन सी स्थितियाँ ग्राफ़िक्स मेमोरी में रखने योग्य हैं, और वर्तमान बैच में किसे शामिल किया जाए।

इसलिए, GPU उपयोग यहाँ अब पर्याप्त नहीं है। क्षमता टीम को GPU-seconds per task, TTFT (पहले शब्द की देरी, जो उपयोगकर्ता को लगता है कि सिस्टम फंस रहा है या नहीं), TPOT (प्रत्येक शब्द का उत्पादन समय, जो यह तय करता है कि मॉडल कितनी तेज़ी से "बोलता" है), queueing latency, prefix cache hit, KV cache occupancy और SLO goodput (प्रभावी थ्रूपुट, जो वास्तविक रूप से कमाई जा सकने वाली कैलकुलेशन क्षमता को दर्शाता है) को एक साथ देखना होगा।

ये सूचक एक साथ एक प्रश्न का उत्तर देते हैं: उपयोगकर्ता द्वारा स्वीकार्य देरी के अंतर्गत, एक घंटे में GPU कितने प्रभावी कार्यों को बनाए रख सकता है।

कोडेक की स्केड्यूलेबिलिटी यहीं दिखती है। स्टेबल प्रीफिक्स दोहराव वाले प्रीफिल को कम कर सकता है, डिकोड कंटिन्यूअस बैचिंग के लिए उपयुक्त है, KV कैश को पेजिंग और विस्थापित किया जा सकता है, और एजेंट टूल का इंतजार करते समय GPU को छोड़ सकता है। इसका वर्कलोड बहुत टुकड़ा-टुकड़ा है, लेकिन इन टुकड़ों को स्केड्यूलर द्वारा पुनः व्यवस्थित किया जा सकता है।

यह प्रश्न को स्वाभाविक रूप से संसाधन स्तर तक ले जाता है: यदि एक ही सेट के GPU अधिक लंबे समय तक के Agent को बारी-बारी से सेवा प्रदान कर सकते हैं, तो एक घंटे के GPU द्वारा समर्थित कार्य का समय एक घंटे से अधिक हो सकता है।

मान लीजिए कि एक Codex Agent को कार्य प्राप्त होने से लेकर पूरा करने तक कुल 60 मिनट लगते हैं, जिसमें केवल एक भाग समय ही मॉडल prefill और decode के लिए वास्तविक रूप से उपयोग होता है, शेष समय संकलन, परीक्षण, फ़ाइल पढ़ने-लिखने या उपकरणों का प्रतीक्षा करने के लिए खर्च होता है। यह अनुपात कार्य के अनुसार भिन्न हो सकता है, लेकिन संरचना महत्वपूर्ण है: Agent का wall-clock समय और GPU कंप्यूट समय एक-एक के अनुपात में नहीं होते।

यदि सिस्टम में एक साथ कई एजेंट होते हैं, तो वे एक ही सेकंड में एक साथ GPU की आवश्यकता नहीं करते। कोई prefill कर रहा होता है, कोई decode कर रहा होता है, कोई परीक्षण चला रहा होता है, और कोई फाइल सिस्टम का इंतजार कर रहा होता है। जब तक scheduler इन चरणों को एक दूसरे के साथ बारी-बारी से व्यवस्थित कर सकता है, सीमित GPU से GPU की संख्या से कहीं अधिक सक्रिय वर्कफ्लो संचालित किए जा सकते हैं।

इस संबंध को इस प्रकार समझा जा सकता है: Agent-hours, GPU-hours, मॉडल इन्फरेंस ड्यूटी साइकिल और शेड्यूलिंग दक्षता पर निर्भर करता है। जितना अधिक टूल निष्पादन समय, बैच गहरा और कैश हिट दर अधिक होगी, उतनी ही अधिक संभावना होगी कि एक घंटे के GPU समय में अधिक Agent wall-clock कार्य समायोजित हो सके।

यह नए GPU के अर्थ को सीधे बदल देगा। Codex पर GPU का एक समूह जोड़ने से केवल एकल कार्य तेज़ होने के अलावा, सिस्टम एक साथ अधिक Agent को बनाए रखने में सक्षम हो सकता है। एक इंजीनियर कई कार्यों को समानांतर रूप से शुरू कर सकता है—एक बैकएंड में परिवर्तन करने के लिए, एक परीक्षण जोड़ने के लिए, एक दूसरे रिपॉजिटरी को संभालने के लिए—जब तक इन कार्यों के बीच कोई मजबूत निर्भरता नहीं है, मशीन का कार्य समय समानांतर रूप से बढ़ सकता है।

सोरा की क्षमता वक्र अधिक सीधा है। एक वीडियो का बड़ा वॉल-क्लॉक समय स्वयं GPU पर डिफ़्यूज़न को आगे बढ़ाता है, और एकल कार्य और GPU उपयोग अधिक घनिष्ठ रूप से जुड़े होते हैं। नए GPU जोड़कर वीडियो थ्रूपुट को सीधे बढ़ाया जा सकता है, लेकिन एक घंटे के GPU समय और वीडियो कैलकुलेशन समय के बीच का संबंध बहुत अधिक नहीं खींचा जा सकता।

कोडेक का एक सॉफ्टवेयर कार्य GPU, CPU, कंटेनर, फाइल सिस्टम और टूल एनवायरनमेंट के बीच घूमता रहता है। GPU मॉडल इन्फरेंस के लिए जिम्मेदार है, अन्य सिस्टम कार्यान्वयन के लिए जिम्मेदार हैं, और कई Agent स्केड्यूलर के माध्यम से इन्फरेंस क्षमता को बाँटते हैं। इस प्रकार, GPU केवल एक जनरेटिंग डिवाइस नहीं रहा, बल्कि पूरे Agent सिस्टम में एक सीमित “विचार संसाधन” बन गया।

इसीलिए कोडेक्स जितना कंप्यूट निगल सकता है, उतना ही नया कंप्यूट प्राप्त करने में आसान है। ओपनएआई को न केवल एकल निष्पादन लागत, बल्कि नए क्षमता को तुरंत अधिक समानांतर कार्यों में परिवर्तित किया जा सकता है या नहीं, यह भी देखना होगा।

जब एक बैच GPU अधिक दीर्घकालिक एजेंट्स को समर्थन कर सकती है, और इन एजेंट्स को नए सॉफ्टवेयर कार्य लगातार प्राप्त होते रहते हैं, तो संसाधन आसानी से इस दिशा में बहते रहते हैं।

अल्टमैन के उस वाक्य का तकनीकी अर्थ इस प्रकार स्पष्ट हो जाता है। सोरा की बड़ी प्रसंस्करण क्षमता एकल जनरेशन पथ में बंद है, जबकि कोडेक की प्रसंस्करण क्षमता कई अंतर्लिन्न चरणों में विभाजित है। दोनों समान रूप से महंगे हैं, लेकिन संसाधन लाभ वक्र अलग है।

सोरा और कोडेक के संसाधन स्थानांतरण के निर्देश, AI उत्पादों में एक ऐसा नया चर शुरू हो रहा है जो प्रसार की गति को सीधे प्रभावित करेगा: workload architecture।

एक ही महंगे GPU का उपयोग करते हुए, एक प्रकार का कार्य बड़ी गणना क्षमता को एकल उत्पादन पथ में बंद कर देता है, जबकि दूसरा प्रकार का कार्य कैशिंग, बैचिंग, उपकरण निष्पादन और नियोजन के माध्यम से एक ही सेट की निष्पादन क्षमता को अधिक कार्यप्रवाहों के बीच विभाजित कर सकता है, इसलिए उनकी संसाधन वक्र स्वाभाविक रूप से अलग हो जाती हैं।

इसलिए भविष्य में कुछ ऐसे नींव के सवाल जो अब बहुत नीचे हैं, वे उत्पाद समस्याओं के बहुत करीब आ जाएंगे। KV cache कहाँ रखें, prefill कैसे काटें, decode batch कितना घना हो सकता है, और इंतजार कर रहे Agent को कैश को बाहर निकालना चाहिए या नहीं—ये चुनाव अंततः एक सेट GPU के साथ कितने कार्यों को एक साथ बनाए रखा जा सकता है, यह तय करेंगे।

Sora और Codex के बीच का अंतर केवल वीडियो और कोड का अंतर नहीं है।

वे एक ही घंटे के GPU के लिए प्रतिस्पर्धा कर रहे हैं, जो कितने कार्यों को संभाल सकता है।