أوتومان كشف في البودكاست عن سبب توجيه OpenAI مواردها نحو Codex بدلاً من Sora. يتطلب إنشاء الفيديو بواسطة Sora كمية كبيرة من قوة الحوسبة المستمرة، حيث يصعب إعادة استخدام وقت GPU المخصص لمهمة واحدة؛ بينما يوزع Codex قوة الحوسبة عبر مراحل متعددة يمكن تداخلها من خلال آليات مثل KV cache وcontinuous batching واستدعاء الأدوات، مما يسمح لوحدة GPU واحدة بدعم عدد أكبر من سير العمل المتوازية. بدأت قدرة إعادة استخدام وقت GPU على تحديد سرعة توسع المنتجات الذكية الاصطناعية.

مؤلف المقال، المصدر: LeFeng.com

لماذا خسرت Sora أمام Codex؟

في 23 أغسطس، ذكر أوتيمان تلقائيًا Sora أثناء حديثه عن توزيع الموارد داخل OpenAI في بودكاست ديفيد سينرا.

قال بوضوح: Sora منتج جيد، ويمكن أن يصبح عملًا مربحًا إذا استمر، لكنه يستهلك كمًا هائلاً من قوة الحوسبة، وفي نفس الوقت، كانت أولوية Codex أعلى، لذا بدأ توزيع قوة الحوسبة والموارد البشرية نحو Codex.

لكن المثير للاهتمام أن Codex لا يوفر GPU على الإطلاق. لتكوين فيديو واحد بواسطة Sora، يجب أن تخضع latent الزمني-المكاني الضخمة لعدة دورات من حسابات Transformer؛ أما Codex فعندما يتلقى أمرًا مثل "أصلح هذا العيب"، فقد يُشغل دورة متتالية من الاستدلالات، وقراءة الكود، واستدعاء الأدوات، وتشغيل الاختبارات، ثم يعود بسجلات وسياق جديد للاستدلال مرة أخرى.

يُركز أحدهما على تخصيص قوة الحوسبة لعملية إنشاء فيديو واحدة، بينما يوزع الآخر قوة الحوسبة على سير عمل Agent قد يستمر لعشرات الدقائق أو أكثر. وهكذا، تبدأ الفجوة الحقيقية بين Sora و Codex في الظهور داخل مراكز البيانات.

نفس مجموعة GPU، لماذا يصعب توزيع حسابات توليد الفيديو، بينما يمكن لـ Coding Agent إعادة تعبئة قدرات الحوسبة في مهام متزامنة أكثر من خلال ذاكرة KV، التجميع المستمر، جدولة التمهيد/التفكيك، وانتظار الأدوات؟

في الواقع، لم يخسر Sora بسبب القيمة المطلقة لاستهلاك القوة الحسابية، بل بسبب بنية عبء العمل: قوة الحوسبة الخاصة بـ Sora مستمرة وحصرية، بينما قوة الحوسبة الخاصة بـ Codex مجزأة وقابلة لإعادة الاستخدام. إن هذا الفرق في آلية الجدولة هو ما أدى إلى فرق في سرعة التوسع بينهما.

بالنظر أسفل هذا الخط، قد تكتشف أن الجزء الذي خسره Sora من الموارد يعكس في الخلفية اختيارًا حول كيفية استخدام وقت وحدات معالجة الرسومات.

ربما يبدأ ارتفاع تكلفة Sora منذ لحظة دخول الفيديو إلى النموذج. فسيقوم أولاً بضغط الفيديو الأصلي إلى فضاء latent، ثم تقسيمه إلى قطع spacetime، ليقوم Transformer بحساب هذه القطع.

يتم توسيع نص التوكن بشكل رئيسي في اتجاه التسلسل، بينما تُوزّع كتل الفيديو في الوقت والارتفاع والعرض معًا، لذا فإن الفيديو هو حالة ذات حجم طبيعي داخل النموذج.

من النظرة العامة، يمكن فهم عدد رموز الفيديو على أنه N_video ≈ T × H × W، حيث T وH وW قد تم ضغطها وتقسيمها إلى أجزاء، لكن العلاقة الثلاثية الضربية لا تزال قائمة.

تمديد مدة الفيديو يزيد من الـ patch في اتجاه الزمن، وزيادة حجم الصورة تُوسّع الـ patch المكاني. بمعنى آخر، لا تزداد تكلفة طول الفيديو وأبعاد المساحة بشكل مستقل؛ بل تعمل معًا على توسيع شبكة latent.

بعد دخول هذه الشبكة إلى Transformer، يجب أن تواجه الطبقة الثانية من الحسابات التي تجلبها الانتشار. يبدأ Sora من حالة كامنة مشوشة، وفي كل دورة يُحدّث تمثيل الفيديو بناءً على الحالة الحالية، ثم يُرسل الكامنة الجديدة إلى الدورة التالية.

يمكن فهم كمية الحساب لفيديو واحد تقريبًا على أنها C_video ≈ D × C_transformer(N_video)، حيث D هي عدد مرات التكرار في العينة. كلما زاد حجم latent الفيديو، زادت ثقلية كل جولة؛ وكلما زاد عدد جولات العينة، يجب أن يمر الفيديو نفسه بعدد أكبر من الجولات عبر الشبكة.

يمكن هنا رؤية الفرق الأساسي بين تشتت الفيديو ونموذج اللغة. عند توليد الرموز التالية، يمكن حفظ المفاتيح والقيم السابقة في ذاكرة KV، ولا يحتاج النموذج إلى إعادة بناء حالة التاريخ الكامل في كل خطوة.

عند اكتمال كل دورة تحديث لـ video diffusion، يتغير الكامن الرئيسي، وبالتالي تواجه الدورة التالية حالة زمنية-مكانية جديدة، لذا لا يزال يتعين تنفيذ كم كبير من الحسابات لعنصر الفيديو.

لذلك، من الصعب تقليل تكلفة Sora بشكل كبير من خلال "إعادة استخدام السجلات". إنها أكثر شبهاً بلقطة مؤثرات بصرية تخضع لمعالجة متعددة الدورات، حيث تتطلب كل دورة معالجة صورة كاملة تغيرت بالفعل. كلما زاد طول الفيديو، وازدادت الدقة، وازداد عدد العينات، أصبحت مسار الإنتاج أكثر ثقلاً.

وبسبب ثقل المهمة الفردية، قد تكون استخدام وحدة معالجة الرسومات لـ Sora جيدًا جدًا. يمكن للحسابات المصفوفية الكبيرة الحجم أن تحافظ على انشغال وحدات التنسور لفترات طويلة، بحيث تظهر الرسوم البيانية للمراقبة وحدة معالجة الرسومات مشغولة تقريبًا طوال الوقت.

ارتفاع معدل الاستخدام لا يعني سوى أن الشريحة تعمل باستمرار، ولا يدل على تسليم عدد كبير من المهام في وحدة الزمن. إذا احتلت فيديو واحد مجموعة من وحدات معالجة الرسومات لفترة طويلة، فحتى لو كان معدل الاستخدام ممتازًا، فإن عدد ثوانٍ وحدة معالجة الرسومات المستهلكة لكل طلب لا تزال مرتفعة.

سيستمر توقف خدمة الفيديو بسبب اختلافات الشكل. تختلف المدة والدقة ونسبة العرض إلى الارتفاع، مما يؤدي إلى أشكال tensor مختلفة. لزيادة كفاءة الدُفعات، يحتاج الخادم إلى وضع الطلبات ذات الأحجام المتشابهة في نفس الدلو. الانتظار لفترة أطول يمكن أن يُنتج دُفعات أكثر كثافة، لكنه يزيد من تأخير الطابور؛ بينما التنفيذ الفوري يقلل من وقت الانتظار، لكن الدُفعات قد لا تمتلئ بالكامل.

لذلك، تم تأمين معظم تكلفة قوة الحوسبة لـ Sora داخل مسار الإنتاج الخاص بكل فيديو. يمكن تقليل عدد دورات العينة، ويمكن ضغط latent بشكل أكبر، ويمكن تقطير النموذج، ويمكن تحسين kernel أيضًا، لكن ما يمكن تعديله في scheduler هو بشكل أساسي "كيفية ترتيب هذه المهام الثقيلة"، ولا يمكن تغيير حقيقة أن "كل فيديو يتطلب كمية كبيرة من الحسابات المتسلسلة".

هذا أيضًا نقطة الدخول لفهم Codex. Codex مكلف أيضًا، لكنه لا يُحمّل جميع التكاليف على كتلة حسابية مستمرة، بل يقسم المهمة إلى العديد من المراحل التي يمكن إيقافها واستئنافها وإعادة دمجها.

يُعطي المستخدم Codex تعليمات "إصلاح هذا الخطأ"، ولا تنتهي المهمة بدعوة نموذج واحدة. قد يقوم الوكيل أولاً بقراءة المستودع، وطلب من النموذج تحديد الخطوة التالية، ثم تنفيذ shell؛ وبعد الحصول على الخطأ، يضيف السجلات إلى السياق ويُعيد استدعاء النموذج؛ ثم يُعدّل الكود ويشغّل الاختبارات، ثم يستمر في الاستدلال بناءً على النتائج الجديدة.

لذلك فإن مهمة Codex أقرب إلى تراكم العديد من الجولات Prefill + Decode + Tool، والنقاط الأساسية هي أنه مع إكمال كل جولة من استدعاء الأداة، فإن السياق الذي يراه النموذج في الجولة التالية غالبًا ما يكون أكثر كثافة من الجولة السابقة.

في بداية المهمة، قد يحتوي النموذج فقط على طلب المستخدم وكمية صغيرة من التعليمات البرمجية. بعد التشغيل لفترة من الوقت، تدخل ملفات وفرق ونتائج طرفية وسجلات اختبار ونتائج أدوات إضافية باستمرار إلى المُحفز.

ربما يرى المستخدم فقط شرحًا مكونًا من بضع مئات من الكلمات، لكن المحتوى الذي تم معالجته داخل GPU قد يكون ضخمًا بالفعل. ضغط استهلاك رموز الوكيل يكمن في هذه المسار العمل المتزايد باستمرار.

إذا تم إعادة معالجة جميع السجلات في كل جولة استنتاج، فستُعطل المهام الطويلة بسرعة بسبب إعادة التهيئة المتكررة، لذا فإن تخزين المُحفزات أمر بالغ الأهمية لـ Codex.

افترض أن عاملًا ما يمتلك بالفعل 100K رمز في السياق، وأن تنفيذ الأداة يضيف فقط 3K رمز في السجلات. إذا تمكّن البادئة الثابتة السابقة من إصابة الذاكرة المؤقتة، فسيكون التركيز الأساسي للحسابات الإضافية هذه الدورة على هذا الجزء الأخير؛ وعندما يتسبب تغيير في مقدمة المطالبة في حدوث فشل في الذاكرة المؤقتة، قد يواجه النظام مرة أخرى عملية تمهيد ثقيلة جدًا.

حدث تغيير مهم هنا: لم يعد عدد الرموز المنطقية يمثل مباشرة تكلفة GPU. كلا الطلبين يظهران 100K رمز إدخال، لكن أحدهما يحتوي على جزء كبير من المحتوى مخزن مؤقتًا، بينما الآخر يتطلب إعادة حساب، مما يجعل ضغطهما على GPU مختلفًا تمامًا. وبالتالي، يعتمد عبء الوكيل على سرعة نمو السياق، ونسبة_hits في التخزين المؤقت، وعدد مرات تكرار المهمة في النموذج.

بعد الدخول إلى inference واحد، فإن prefill و decode لهما متطلبات أجهزة مختلفة. يعالج prefill عددًا كبيرًا من رموز الإدخال دفعة واحدة، وحجم المصفوفة كبير، مما يجعله أكثر عرضة لتكوين حمل ثقيل على الحوسبة؛ بينما يولد decode عددًا قليلاً فقط من الرموز لكل تسلسل في كل دورة، ولكنه يحتاج إلى الوصول المتكرر إلى أوزان النموذج وKV cache، وبالتالي يعتمد أكثر على عرض نطاق HBM وحجم التوازي.

هذا يعني أن فك التشفير إذا تم تشغيله على تسلسل واحد منفصل سيكون مهدراً للغاية. لا تزال أوزان النموذج كبيرة، ويجب إجراء حساب تقدمي كامل لإنشاء رمز واحد. فقط عن طريق وضع العديد من التسلسلات في نفس عملية التقدم المجمعة، يمكن للخادم جعل الوصول إلى الأوزان يدفع عدة طلبات في وقت واحد.

لكن هل يمكن زيادة حجم الدُفعات أكثر؟ إنها تخضع لقيود ذاكرة KV. كلما طال سياق كل تسلسل، زاد استهلاك ذاكرة HBM. بعد زيادة عدد الوكلاء، قد تظل وحدة معالجة الرسومات تحتوي على فائض حسابي، لكن ذاكرة العرض قد لا تتحمل المزيد من الحالات النشطة.

تهدف التصاميم من نوع PagedAttention إلى تقليل تجزئة ذاكرة GPU من خلال إدارة ذاكرة KV بطريقة مبنية على الصفحات، وهي في جوهرها تزيد من عدد التسلسلات النشطة التي يمكن لوحدة معالجة الرسومات استيعابها في وقت واحد.

استدعاء الأدوات يقسم عبء عمل Codex بشكل إضافي. عندما يُجري العامل اختبارات أو يُرَكِّب الكود أو ينتظر I/O، لا يحتاج GPU إلى الاستمرار في العمل من أجله، بل تأخذ CPU والحاويات ونظام الملفات زمام الأمور. بمجرد عودة النتائج، يدخل العامل في دورة استنتاج التالية.

لذلك، فإن عامل يعمل لمدة 60 دقيقة لا يعني استهلاكًا مستمرًا لـ 60 دقيقة من وحدة معالجة الرسومات. يتم تقسيم وقت المهمة إلى جزأين: حساب النموذج والتنفيذ الخارجي، مما يمنح الجدولة مساحة لا يمكن لـ Sora توفيرها بسهولة: عندما يُشغّل عامل أداة، يمكن لوحدة معالجة الرسومات فورًا خدمة تسلسل آخر.

بالطبع، سيؤدي هذا أيضًا إلى إنشاء مشاكل جديدة في ذاكرة العرض. يجب على عامل الأداة أن يقرر ما إذا كان يجب الاحتفاظ بذاكرة KV أم لا؟ الاحتفاظ بها يسمح باستعادة أسرع، لكنه يستهلك HBM على المدى الطويل؛ بينما إزالتها تحرر المساحة، لكن عند عودة المهمة، يجب تحمل تكلفة الاستعادة. كلما زاد عدد العوامل، أصبحت هذه التنازلات أكثر شبهاً بنظام التشغيل الذي يدير عددًا كبيرًا من العمليات التي تدخل في حالة السكون والاستيقاظ.

هنا، لا يكمن الفرق بين Codex و Sora في "من الأثقل"، بل في ما إذا كانت التكلفة قد تم فصلها. تتركز قوة الحوسبة في Sora في مسار توليد مستمر، بينما تتشتت قوة الحوسبة في Codex عبر مراحل متعددة. وبسبب هذا الفصل، يمكن لـ Codex الدخول إلى مستوى تحسين أعمق: السماح لـ scheduler بتحديد كيفية مشاركة هذه المراحل لنفس مجموعة وحدات معالجة الرسوميات.

عند تشغيل النماذج الكبيرة عبر الإنترنت، عادةً ما تبقى الأوزان مثبتة على وحدات معالجة الرسومات لفترات طويلة، كما يجب الحفاظ على توازي التنسورات واتصال العقد والذاكرة المؤقتة. لذلك، يحدث التنافس على الموارد بين Sora و Codex بشكل أساسي على مستوى الأسطول: فجزء من وحدات معالجة الرسومات يبقى لفترة طويلة في مجموعة خدمة الفيديو، بينما يبقى جزء آخر لفترة طويلة في مجموعة نماذج اللغة الكبيرة، ثم تقرر أنظمة السعة العليا أي جانب يتم توسيعه وأي جانب يتم تقليصه.

الأمور المعقدة حقًا تحدث داخل بركة Codex. افترض أن النظام يحتوي في نفس الوقت على 200 تسلسلًا للوكيل، بعضها يجري فك التشفير، وبعضها ينتظر الأدوات، وهناك عشرات التسلسلات التي عادت للتو من بيئة الأدوات وتحتاج إلى معالجة سياقات طويلة جديدة. يواجه الجدولة قيودًا لا تشمل فقط FLOPs، بل تشمل أيضًا سعة HBM وعرض النطاق الترددي للذاكرة ووجود ذاكرة KV والموازنة الزمنية.

يجب حل مشكلة استخدام decode في التجميع المستمر. يربط التجميع الثابت التقليدي مجموعة من الطلبات معًا، بحيث تظل الطلبات الطويلة الباقية تحتل التجميع حتى بعد انتهاء الطلبات القصيرة.

سيتم تبديل المستخدمين ديناميكيًا على مستوى تكرار الرموز في التجميع المستمر، حيث يتم إزالة التسلسل بمجرد اكتماله، ويتم إدخال الطلبات الجديدة فورًا. كلما زاد حجم التجميع، زاد عدد التسلسلات التي يمكن للنموذج推进ها في كل دورة حسابية، مما يجعل تكلفة الوصول إلى أوزان النموذج وعرض النطاق الترددي للذاكرة أسهل في التوزيع.

لكن هنا سيُواجه قريبًا جدار ذاكرة العرض. ستستهلك كاش KV الطويل للعديد من الوكلاء ذاكرة HBM باستمرار، وقد لا تكون وحدة معالجة الرسومات قد استخدمت كامل قدرة Tensor Core، لكن ذاكرة العرض تكون قد امتلأت ولا يمكنها استيعاب مزيد من التسلسلات. في هذه المرحلة، لا معنى لزيادة القوة الحسابية، فالقيود الحقيقية على التوازي هي سعة التخزين المؤقت وإدارة ذاكرة العرض.

هناك تعارض آخر بين التمهيد (Prefill) والفك (decode). افترض أن عشرات التسلسلات تُفك بشكل مستقر، وفي هذه الأثناء يعود عامل (Agent) مع سياق جديد يحتوي على 100K رمز، ويحتاج إلى تنفيذ تمهيد كبير. إذا شغل هذا التمهيد نافذة تنفيذ طويلة جدًا، فسيتدهور أداء TPOT للطلبات المجاورة بشكل ملحوظ.

سيقوم تمهيد الشريحة بتقسيم المدخلات الطويلة إلى شرائح صغيرة، مما يسمح بتنفيذ التمهيد والفك بالتناوب؛ والخطوة المتقدمة أكثر هي فصل التمهيد والفك على مجموعات GPU مختلفة.

السبب هو أن مرحلتين هاتين تميلان إلى حدود أجهزة مختلفة: يعتمد prefill على إنتاجية الحساب، بينما يعتمد decode على عرض نطاق HBM وذاكرة KV وتأخير ثابت لكل رمز. بعد فصلهما، يمكن تخصيص الموارد وفقًا لاحتياجات كل منهما على حدة.

هذا يوضح أن جوهر خدمة الوكيل يتجاوز مجرد جعل نواة النموذج أسرع. يأتي الكثير من تحسين السعة من إعادة ترتيب توقيت تشغيل المهام ومكان تشغيلها، وما هي الحالات التي تستحق البقاء في ذاكرة GPU، ومن يجب تضمينه في الدفعة الحالية.

لذلك، لم يعد استخدام GPU كافيًا هنا. يجب على فريق السعة مراقبة GPU-seconds per task وTTFT (تأخير أول كلمة، والذي يحدد ما إذا كان المستخدم سيشعر بالتأخير) وTPOT (وقت توليد كلمة واحدة، والذي يحدد مدى سرعة "حديث" النموذج) وتأخير الطابور ونسبة إصابة ذاكرة البادئة وشغل ذاكرة KV وSLO goodput (الإجمالي الفعال، الذي يمثل قوة الحوسبة التي يمكن بيعها فعليًا).

هذه المؤشرات معًا تجيب على سؤال: كم عدد المهام الفعالة التي يمكن لوحدة معالجة الرسوميات لمدة ساعة واحدة الحفاظ عليها ضمن التأخير الذي يمكن للمستخدم قبوله.

يتجلى قابلية جدولة Codex هنا. يمكن للبادئة الثابتة تقليل إعادة تمهيد متكررة، ويمكن للـ decode التجميع المستمر، ويمكن لـ KV cache التقسيم والإزالة، ويمكن للوكيل التخلي عن GPU أثناء انتظار الأدوات. إن حمل عملها مجزأ، لكن هذه الشظايا يمكن إعادة ترتيبها بواسطة الجدولة.

هذا يدفع المشكلة بشكل طبيعي إلى طبقة الموارد: إذا كان يمكن لنفس مجموعة وحدات معالجة الرسومات خدمة عوامل طويلة الأمد بشكل متناوب، فإن وقت العمل الذي يمكن لوحدة معالجة رسومات لمدة ساعة دعمه قد يتجاوز ساعة واحدة.

افترض أن وكيل Codex يستغرق 60 دقيقة من البدء إلى الإنجاز، حيث لا يُستخدم سوى جزء من هذا الوقت في تنفيذ prefill وdecode للنموذج، بينما يُستخدم الباقي في التجميع، والاختبار، وقراءة/كتابة الملفات، أو الانتظار للأدوات. ستختلف النسبة الدقيقة حسب المهمة، لكن الهيكل مهم: وقت الجدار لوكيل Agent لا يساوي وقت حساب GPU بنسبة 1:1.

إذا كان هناك عدد كبير من الوكلاء في النظام، فلن يحتاجوا جميعًا إلى وحدة معالجة الرسوميات في نفس الثانية. هناك من يجري مقدمة، ومن يجري تحليلًا، ومن يجري اختبارات، ومن ينتظر نظام الملفات. طالما أن الجدولة تستطيع تناوب هذه المراحل، فإن وحدات معالجة الرسوميات المحدودة يمكنها دعم عدد من سير العمل النشطة يفوق بكثير عدد وحدات معالجة الرسوميات.

يمكن فهم هذه العلاقة تقريبًا على النحو التالي: تعتمد ساعات الوكلاء على ساعات GPU ونسبة استخدام نموذج الاستدلال وكفاءة الجدولة. كلما زاد وقت تنفيذ الأداة، وازداد سمك الدُفعات، وارتفعت نسبة إصابة التخزين المؤقت، زادت فرصة وحدة GPU في دعم فترة عمل أطول للوكيل بالوقت الفعلي.

هذا سيغير مباشرة معنى إضافة وحدات معالجة الرسوميات الجديدة. إضافة مجموعة من وحدات معالجة الرسوميات إلى Codex لا تجلب فقط تسريعًا أسرع للمهام الفردية، بل قد تسمح أيضًا للنظام بالحفاظ على عدد أكبر من الوكلاء في وقت واحد. يمكن لمهندس واحد تشغيل مهام متعددة بالتوازي: واحدة لتعديل الخلفية، وأخرى لإكمال الاختبارات، وأخرى للتعامل مع مستودع آخر، طالما أن هذه المهام لا تعتمد بشكل قوي على بعضها البعض، يمكن لوقت عمل الجهاز أن ينمو بالتوازي.

منحنى سعة Sora أكثر مباشرة. فإن فترة وقت الجدار الطويلة لفيديو واحد تُقدّم نفسها مباشرة على وحدة معالجة الرسومات، مما يربط المهمة الواحدة واستخدام وحدة معالجة الرسومات بشكل أوثق. يمكن إضافة وحدات معالجة رسومات جديدة لزيادة إنتاجية الفيديو مباشرة، لكن من الصعب جعل الفرق بين ساعة وحدة معالجة الرسومات ووقت حساب الفيديو كبيرًا جدًا.

مهمة برمجية من Codex تنتقل بين GPU وCPU والحاويات ونظام الملفات وبيئة الأدوات. يُستخدم GPU لاستنتاج النموذج، بينما تُستخدم الأنظمة الأخرى للتنفيذ، وتشترك عدة وكلاء في قدرة الاستنتاج عبر مُجدول. وهكذا، يتحول GPU من كونه جهاز إنتاج بسيط إلى مورد "تفكير" نادر داخل نظام الوكلاء بأكمله.

هذا هو السبب في أن Codex، على الرغم من قدرته على استهلاك كميات كبيرة من الحوسبة، فإنه يحصل بسهولة أكبر على حوسبة إضافية. يجب على OpenAI أن تنظر ليس فقط إلى تكلفة الاستدلال الواحدة، بل أيضًا إلى ما إذا كان يمكن تحويل القدرة الجديدة بسرعة إلى كمية أكبر من الأعمال المتوازية.

عندما يمكن لدفعة من وحدات معالجة الرسوميات دعم عدد أكبر من الوكلاء الطويلي الأجل، وفي الوقت نفسه تستطيع هذه الوكلاء استقبال مهام برمجية جديدة باستمرار، فإن الموارد تتدفق بسهولة في هذا الاتجاه.

لهذا السبب، أصبح المعنى التقني للعبارة التي قالها ألتمان واضحًا. يتم تقييد كمية كبيرة من قوة الحوسبة الخاصة بـ Sora في مسار إنتاج واحد، بينما يتم تقسيم قوة الحوسبة الخاصة بـ Codex إلى مراحل متعددة يمكن تداخلها. كلا الجانبين مكلفان بنفس القدر، لكن منحنى العائد على الموارد مختلف.

شرح نقل الموارد لـ Sora و Codex، حيث تبدأ منتجات الذكاء الاصطناعي في امتلاك متغير إضافي يؤثر مباشرة على سرعة التوسع: workload architecture.

باستخدام وحدات معالجة الرسوميات (GPU) باهظة الثمن، فإن نوعًا واحدًا من المهام يُقفل كمية كبيرة من قوة الحوسبة في مسار إنتاجي واحد، بينما يمكن لنوع آخر من المهام استخدام التخزين المؤقت، والدمج، وتنفيذ الأدوات، والجدولة لتقسيم نفس قدرة الاستنتاج بين مسارات عمل أكثر، وبالتالي ستختلف منحنيات الموارد الخاصة بهما بشكل طبيعي.

لذلك، ستتزايد المسائل التي تبدو أساسية في المستقبل لتصبح أكثر اقترابًا من قضايا المنتج: أين يتم وضع KV cache، كيف يتم تقسيم prefill، كم يمكن أن يكون حجم decode batch، وهل يجب طرد ذاكرة التخزين المؤقت من العامل الذي ينتظر الأداة؟ هذه الخيارات ستُحسم في النهاية عدد المهام التي يمكن لحزمة من وحدات معالجة الرسومات الحفاظ عليها في وقت واحد.

الفرق بين Sora و Codex لا يقتصر فقط على الفرق بين الفيديو والكود.

إنها تتنافس على نفس ساعة GPU، فكم من العمل يمكنها دعمه؟