شريحة Jalapeño من OpenAI تتفوق على Blackwell من NVIDIA في الكفاءة

iconTechFlow
مشاركة
AI summary iconملخص
يُظهر رقاقة Jalapeño من OpenAI كفاءة طاقية أفضل من رقاقة Blackwell من NVIDIA، وفقًا لتحليل على السلسلة. تم بناؤها خلال 16 شهرًا، وتتفوق على رقاقات NVIDIA وAMD وGoogle في المعايير الرئيسية. مصممة للاستنتاج العام للذكاء الاصطناعي، توفر Jalapeño إنتاجًا عاليًا للرموز لكل واط دون استخدام التخمين. وعلى الرغم من أنها تفتقر إلى دعم CUDA، إلا أن أدائها قد يغيّر سوق رقاقات الذكاء الاصطناعي. تشير البيانات على السلسلة إلى تزايد الاهتمام بحلول الأجهزة البديلة للذكاء الاصطناعي.

المؤلف: SemiAnalysis

مُترجم: Deep潮 TechFlow

مقدمة شينتشاو: تم الكشف عن بيانات الاختبار الفعلية للشريحة الاستنتاجية الأولى التي طورتها OpenAI، Jalapeño، والتي تتفوق مباشرةً في كفاءة الطاقة على أحدث شريحة رائدة من NVIDIA، Blackwell، وتقرب من الجيل القادم، Rubin. بالنسبة للشركات التي تعاني من قيود الطاقة في مراكز البيانات، قد تعيد هذه الشريحة تشكيل خريطة سوق الحوسبة. لكن لا يزال هناك سؤال مفتوح حول ما إذا كانت الشريحة من الجيل الأول قادرة حقًا على إحداث تأثير حقيقي على نظام CUDA التابع لـ NVIDIA.

مقارنة تكلفة الملكية الإجمالية، وthroughput لكل ميغاواط، والتفاصيل الحارة لـ ASIC المطور داخليًا مقابل Rubin وJalapeño

على مدار العامين الماضيين، كانت OpenAI تعمل بصمت على تطوير شريحة "Jalapeño"، والتي تم الإعلان عنها مؤخرًا في مؤتمر Hot Chips. كانت الشائعات حول نجاح الإنتاج قد انتشرت لفترة، لكننا الآن حصلنا على التفاصيل. دعتنا OpenAI لفحص الشريحة، والدخول إلى المختبر للتحقق من مدى دقتها، وإجراء اختبارات معيارية باستخدام مجموعة InferenceX الخاصة بنا.

في يونيو من هذا العام، أعلنت OpenAI عن مشروع شريحة بالتعاون مع Broadcom، مصممة من الصفر خصيصًا لاستنتاجات نماذج اللغة الكبيرة. بدأ العمل على التصميم في منتصف عام 2024، واستغرق من تجنيد الفريق الأولي إلى تصنيع الشريحة حوالي 16 شهرًا فقط، وهو دورة تطوير ASIC أسرع بكثير.

عادةً، لا تكون الرقائق من الجيل الأول تنافسية، لكن OpenAI سارت عكس الاتجاه، حيث تفوقت على جميع رقائق NVIDIA وAMD وGoogle التي استطعنا اختبارها على عدة نماذج مفتوحة المصدر رائدة، واحتلت موقعًا قياديًا في الصناعة. يعتمد OpenAI على تصميم متكامل متطرف بين البرنامج والعتاد. ومن المفاجئ أن OpenAI لم تركز بشكل مفرط على جزء محدد من استنتاج النموذج، بل ركزت على تطوير رقاقة عامة توفر أداءً عاليًا في جميع السيناريوهات.

ستستعرض هذه المقالة بالتفصيل بنية Jalapeño على InferenceX، والتفاصيل البرمجية، ونتائج الأداء.

شريحة استدلال عامة

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

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

بالنظر فقط إلى المواصفات، فهو منافس قوي فورًا:

واستخدام HBM4 يجعله كافيًا للمقارنة مع وحدات معالجة الرسوميات الرائدة من NVIDIA وAMD:

كانت العديد من وسائل الإعلام تتابع كلمات عابرة من OpenAI، وتزعم أن هذه الشريحة ستُحسّن نماذجها بطرق لا تستطيع فيها الشريحة الأخرى تحقيقها. هذا خطأ. Jalapeño هي شريحة استدلال عامة يمكنها تشغيل مجموعة متنوعة من النماذج وأحمال العمل، بما في ذلك اختبار InferenceX الخاص بنا — والذي قمنا بتشغيله في المختبر مع مهندسي OpenAI. كمزحة، عرضت OpenAI حتى علىّ تشغيل لعبة Doom، التي تم نقلها إلى شرائحهم باستخدام تعليمات Codex فقط.

هذه هي نتائج الأداء/الواط الأكثر أهمية لدينا، والتي تقيس معدل تدفق الرموز تحت استهلاك طاقة إجمالي قدره ميغاواط واحد. يتفوق Jalapeño بوضوح على جميع الرقائق الأخرى. ولم يتم استخدام التنبؤ المتعدد للرموز (MTP) في هذه الحالة، بينما كانت جميع الرقائق الأخرى في الرسم البياني مُهيأة بأفضل إعدادات SKU الخاصة بها مع تفعيل MTP بالكامل.

في جميع السيناريوهات تقريبًا، يتفوق Jalapeño من حيث الأداء/الواط على Blackwell، دون أي تحسين مخصص لنقطة معينة على المنحنى. فهو ليس فقط متميزًا في سيناريوهات التأخير المنخفض، بل أيضًا في سيناريوهات الإنتاجية العالية. إن المقارنة الأكثر عدالة هي النظر إلى نتائج التنبؤ برمز واحد، حيث يتفوق Jalapeño على جميع منافسيه بمسافات كبيرة. في سيناريوهات التزامن المنخفض، يظهر Jalapeño تفاعلًا مذهلًا، حيث يحقق أكثر من 700 رمز لكل مستخدم في الثانية على نموذج DeepSeek R1 عند تزامن قدره 1.

بشكل لا يُصدق، تم تحقيق كل هذا باستخدام التنبؤ برمز واحد (STP)، دون تشفير استباقي ولا فصل بين التمهيد والفك. بالإضافة إلى DeepSeek R1، رأينا أيضًا نماذج أخرى مثل Kimi-K2.5 وGPT-OSS التي تصل إلى حوالي 1,400 رمز لكل مستخدم في الثانية. بالنسبة لجميع النماذج، تأكدنا من أن نتائج Jalapeño على GSM8k متساوية مع شرائح NVIDIA.

هنا بعض الملاحظات المهمة. أولاً، جميع البيانات مقدمة من OpenAI. لقد قمنا بفحص InferenceX في المختبر، لكننا لم نجرِ اختبارات كاملة لمجموعة معايير InferenceX، ولم نرِ نتائج AgentX. AgentX هو مجموعة الاختبارات المفضلة لدينا لمقارنة أداء الشرائح، نظرًا لخصائصه في سياقات طويلة جدًا ومتعددة المراحل، والتي تعكس سلوك التخزين المؤقت تحت أحمال إنتاج حقيقية. قد تظهر الإطارات التي تؤدي جيدًا على 8k1k أداءً أسوأ على AgentX، لأن أحمال الإنتاج الحقيقية تختبر مكونات مثل الموجهات، وآليات التخزين المؤقت للبادئات، وإدارة التخزين المؤقت، وبنية التخفيض. لا تغطي اختبارات 8k1k الأحادية هذه الجوانب. لمزيد من التفاصيل، يرجى قراءة مقالتنا عن AgentX.

AgentX - InferenceXv3: هل لا تزال حماية CUDA فعالة في استنتاج الوكلاء؟

ثانيًا، نعتقد أن المقارنة مع Blackwell غير كاملة وغير عادلة بعض الشيء. المنافس الحقيقي لـ Jalapeño هو شرائح مثل Rubin التي تستخدم أيضًا HBM4. لقد بدأت أنظمة Vera Rubin بالفعل في شحن المنتجات للعملاء، بينما لا يزال Jalapeño الخاص بـ OpenAI في مرحلة العينات الهندسية، ولا يزال بحاجة إلى وقت طويل قبل الوصول إلى الإنتاج الضخم.

لذلك، يجب أن تُقارن الأداء فعليًا مع روبين، وليس بلاكويل. من ناحية ما، كنا نتوقع بالفعل أن تتفوق شرائح مخصصة مثل جالابينيو على بلاكويل. إن كفاءة Vera Rubin NVL72 من حيث الأداء/الواط هي 5.4 مرات أعلى من GB200 NVL72، وهو ما كتبناه في مقالتنا التي حلّلنا فيها بيانات الأداء التي أصدرتها نيفيديا وكوروييف في الشهر الماضي. سنقوم لاحقًا بمقارنة Jalapeño مع بيانات أداء Vera Rubin لشهر يوليو.

فيرا روبين NVL72 مقابل GB200 NVL72؟ تحليل TCO والهندسة

ثالثًا، النموذج الذي تم اختباره ليس من أحدث النماذج المفتوحة المصدر. فقد نشرت NVIDIA وAMD نتائج نماذج أكبر باستخدام AgentX، مثل DeepSeek V4 Pro وKimi K3. كلما كان النموذج أكبر وأحدث إصدارًا، زادت تعقيدات تشغيله على الرقائق الجديدة. ومع ذلك، فإن النموذج الذي نجح OpenAI في تشغيله على Jalapeño ليس صغيرًا.

Performance Analysis

الهدف من تصميم OpenAI هو الأداء لكل واط. السبب بسيط: OpenAI محدودة حاليًا بطاقة مراكز البيانات، وليس بميزانيتها أو مساحة مراكز البيانات، لذا فإن عدد التوكنات لكل ميغاواط أمر بالغ الأهمية. في Computex 2026، قال هوانغ رينشون إن الأداء لكل واط، والموثوقية، والطول العمر هما الخصائص الأساسية للـ GPU المستقبلية. وقد قال كلماته الحرفية: "إذا كان لديك جيجاواط واحد من الطاقة، فإن إنتاجية كل واط هي الدخل." كما أشار إلى أنه لا معنى لاختيار بنية خاطئة فقط لأن الرقاقة أرخص.

كما شددت نفيديا على هذا الأمر في عرض فيرا خلال حدث Hot Chips 2026، مع عرض نفس مخطط الإيرادات: "تُقيَّد مراكز البيانات اليوم بالطاقة الكهربائية." الطاقة الكهربائية حاسمة وتدفع الإيرادات.

لا يمكن للمشغلين الحصول بسهولة على مزيد من الميغاواط. الفرق في جدول زمني بين زيادة وحدات GPU وزيادة قدرة الشبكة الكهربائية هائل. تخضع حدود الطاقة لمراكز البيانات لقيود عديدة، مثل توصيل المرافق، والبنية التحتية، وقدرات التبريد، وتصميم أنظمة UPS/مولدات الطوارئ. تتجاوز تأخيرات الشبكة الكهربائية مرارًا وتكرارًا تقدم الأجهزة والبناء، مما يخلق طلبًا على قدرات الطاقة خلف العداد. أي بناء محطات توربينات غازية ومولدات ميدانية مباشرة داخل مراكز البيانات. تقع هذه القدرات خلف عداد المرافق ولا تعتمد على الشبكة العامة. هذا يسمح للمشغلين بتزويد المرافق بالطاقة دون الحاجة إلى الانتظار حتى تكتمل توصيلات الشبكة وترقيات المرافق. وهذا بالضبط السبب الذي يجعل Colossus 2 التابع لـ xAI يعتمد بشدة على الطاقة خلف العداد، بينما تبقى اتصالاتها الفعلية بالشبكة الكهربائية متأخرة بكثير. لمزيد من المعلومات، راجع نموذج الطاقة الخاص بنا.

كما كتبنا في منشور X، يمكن تبسيط tok/s/MW إلى عدد التوكنات لكل جول. لأن الواط هو جول في الثانية. وبالتالي، فإن tok/s/MW يمثل كفاءة النظام وقدرته على تحويل الطاقة إلى توكنات.

في هذا السياق، يتفوق Jalapeño حتى مقارنةً بـ Rubin. إن إنتاجية Jalapeño من OpenAI من حيث عدد التوكنات لكل ميغاواط STP تتجاوز نتائج MTP الخاصة بـ Vera Rubin. وقد نُشرت هذه النتيجة من قبل NVIDIA و CoreWeave في يوليو. كما أنها تتفوق بكثير على نتيجة GB200 المتوقعة لعام 2025. وكما ذكرنا في مقال Vera Rubin، فإن مقارنة VR مع نتيجة GB200 لعام 2025 تتم لأن كلاهما في مرحلة تشغيل أولية مشابهة. كما أن المقارنة مع GB200 لعام 2025 تحافظ على ثبات نضج البرنامج. ووفقًا لهذا المنطق، نقارن بين ثلاثة أنواع من النتائج: أحدث نتائج Vera Rubin لشهر يوليو 2026، ونتائج GB200 لعام 2025، ونتائج Jalapeño الحالية. هذه المقارنة منطقية جدًا لأنها تستخدم أفضل البيانات العامة المتاحة عن Rubin. علاوة على ذلك، فإن OpenAI أطلقت شريحتها بعد Rubin. لا تزال كل من OpenAI و Rubin في مراحل غير ناضجة، لذا سيستمر تحسن الأداء.

من حيث الأداء/إجمالي تكلفة الملكية، فإن فيرا روبين وجالابينيو متساويان تقريبًا، حيث ينتج كل دولار نفس عدد رموز الإخراج تقريبًا. ومع ذلك، كما ذُكر سابقًا، لم تُستخدم التخمين في تحليل جالابينيو، بينما استُخدم التخمين في نتائج فيرا روبين. يمكن للتخمين أن يقلل تكلفة كل رمز بنسبة 3-5 مرات. عندما يتم تطبيق التخمين على جالابينيو، ستكون كفاءته التكلفة في تقديم الرموز أعلى بكثير. بالطبع، يعود جزء من ميزة إجمالي تكلفة الملكية إلى تجنب هوامش الربح العالية لشركة نيفيديا والتحول إلى هوامش ربح أقل (لكنها لا تزال عالية) لشركة بروكوم. لكن هذا ليس السبب الوحيد. على سبيل المثال، لم تنجح مشاريع ASIC للذكاء الاصطناعي الخاصة بـ Meta و Microsoft رغم استثماراتها الأطول. وهذا يشير إلى أن التكلفة ليست سوى جزء من المعادلة. لرؤية التحليل الكامل لإجمالي تكلفة الملكية لجالابينيو، راجع نموذج SemiAnalysis AI Cloud TCO.

من الناحية المعمارية، اختارت OpenAI عدم فصل التحميل المسبق (prefill) والفك (decode) إلى مجموعات شرائح مختلفة. تشارك النموذج التجريبي والنموذج الرئيسي نفس الشرائح وهيكل الاتصالات. إن هذا المفهوم التصميمي يضحّي ببعض الكفاءة النظرية من أجل تسهيل التشغيل العملي. يكمن الدافع وراء ذلك في أن تكوين عبء العمل يتغير مع مرور الوقت. على سبيل المثال، تغيرت نسبة المدخلات وكتابة التخزين المؤقت وقراءة التخزين المؤقت ورموز الإخراج بشكل ملحوظ. حدث هذا التغيير بعد مرورنا بثلاثة عصور نماذج: المعرفة، والاستدلال، والوكلاء، كما ناقشنا في مقالتنا الأخيرة. وبالتالي، فإن تحديد عدد ثابت مسبقًا من الشرائح غير المتجانسة للتحميل المسبق والفك سيؤدي مع مرور الوقت إلى انخفاض الكفاءة. وقد اختارت OpenAI في هذا التصميم استخدام مجموعات متجانسة، وتعمل على ضمان أداء جيد للشرائح في جميع المهام.

وقد حقق ذلك بالفعل. على Kimi K2.5 (الذي يعتمد على نموذج Cursor Composer 2.5)، وصل Jalapeño إلى ما يقارب 700 tok/s/user. هذه السرعة تزيد عن تسع مرات سرعة الرقاقة الثانية الأفضل، والتي تبلغ 100 tok/s/user.

على GPT-OSS، كانت هناك تفوق آخر. إن إنتاجية Jalapeño من حيث التفاعل لكل ميغاواط تقارب ضعف أعلى نقطة إنتاجية لـ GB200، وهي أكثر من 50 مرة أعلى من نقطة التزامن 1 لـ GB200. تستخدم نقاط Jalapeño ذات التزامن الأعلى EP8.

هذه النتائج مذهلة! لكن يجب أن نكون دقيقين: فهي مجرد 8k1k، وهي أسهل بكثير في الضبط، ولم تُختبر بعد ببيانات AgentX. كما ذكرنا في مقال AgentX، فإن أحمال العمل متعددة الجلسات وذات السياق الطويل تضع ضغطًا أكبر على جوانب متعددة من طبقة الاستنتاج، مثل الموجهات وذاكرة التخزين المؤقت للبادئات. لتحقيق أداء ممتاز في أحمال عمل الوكلاء، هناك حاجة إلى مزيد من التحسينات. اقرأ مقال AgentX لمزيد من التفاصيل.

AgentX - InferenceXv3: هل يمكن لحصن CUDA الصمود في استنتاج الوكلاء؟

المواصفات والهندسة التفصيلية

جميع هذه النتائج جاءت من خطوة A0 من Jalapeño، بعد إطلاق المشروع بفترة 9 أشهر فقط. لكن خطوة B0 موجودة حاليًا في مصنع الرقائق! تحسينات خطوة B0 زادت الأداء لكل واط بنسبة حوالي 25% مقارنة برقائق A0 السابقة. على وجه التحديد، تحقق خطوة B0 13.4 PFLOPs من MXFP4 على شريحة بحجم ماسك ضوئي واحد. تم تصنيع هذه الشريحة باستخدام تقنية N3P من TSMC. على النقيض من ذلك، تحقق شريحة حسابية واحدة من Rubin 17.5 PFLOPs من NVFP4 الكثيف على نفس الحجم ونفس العقد.

بالنظر إلى أن TDP الخاص بـ Jalapeño لا يتجاوز 700 واط، في حين أن Rubin تستخدم بين 900-1150 واط لكل شريحة حسابية، فإن هذا الأداء أكثر إعجابًا. نظرًا لأن Jalapeño مصمم للاستنتاج وليس للتدريب، فلا حاجة لـ OpenAI لرفع TDP لتحقيق أقصى FLOPs. هذا مفهوم. لكن على أي حال، تُظهر النتائج المذكورة أعلاه أن Jalapeño يقدم قيمًا نظرية قصوى لـ FLOPs ملحوظة.

عند المقارنة المباشرة مع مسرّعات أخرى، يمتلك Jalapeño أعلى عرض نطاق HBM لكل واط وأعلى عدد FLOPs لكل واط، وهو مستوى يعادل تكوين Rubin Max-Q بقدرة 1800 واط.

سيستخدم Jalapeño HBM4، ليصبح أحد أولى الرقائق التي تتبنى هذه التقنية بعد Nvidia وAMD، وحتى متفوقًا على مشاريع TPU وTrainium الحالية. أحد المبادئ الأساسية في تصميم Jalapeño هو الاستفادة القصوى من عرض نطاق HBM، لذا فإن التنازل عن استخدام HBM من أعلى مستوى يتعارض مع هذا الهدف. وهذا يحقق عرض نطاق ذاكرة قدره 15.4 تيرابايت/ثانية لكل حزمة، وهو ما يفوق جميع مسرّعات HBM3E المتوفرة حاليًا. يشير عرض النطاق البالغ 15.4 تيرابايت/ثانية إلى أن HBM4 الخاص بـ Jalapeño يمكن أن يصل إلى سرعة دبوس 10 جيجابت/ثانية، وهي أعلى قليلاً من سرعة 9.6 جيجابت/ثانية التي تستخدمها Nvidia في Rubin. من المرجح أن توفر سامسونغ HBM.

أكملت OpenAI تدفق Jalapeño في نوفمبر 2025، وبالتحديد تدفق تصميم CoWoS، وليس فقط الرقاقة العلوية. بعد تسعة أشهر من تدفق Jalapeño في نوفمبر 2025، وبعد التصحيح فقط على شريحة سيليكون حقيقية لمدة ثلاثة أشهر، حققت OpenAI نتائج ممتازة باستخدام Jalapeño. وهذا أكثر إثارة للإعجاب بالنظر إلى أن الفريق بدأ من الصفر في طبقة البرمجيات.

في الوقت نفسه، تم إكمال تدفق CoWoS لـ Rubin في أكتوبر 2025، قبل شهر، لكن النتائج المبكرة الوحيدة التي شاهدناها حتى الآن تأتي من عينات الهندسة الخاصة بـ CoreWeave. لم تسمح Nvidia لنا باختبار النتائج ونشر المعايير، كما فعلت OpenAI، مما يشير إلى أن برمجيات رقاقة ما تزال غير ناضجة. نظرًا لقدرة OpenAI على تشغيل نماذج جديدة بسرعة كبيرة على رقائقها الخاصة، فقد يكون خندق CUDA قد تلاشى.

ما زالت بعيدة عن التحسين الكامل، ويمكننا ملاحظة أن Jalapeño قدمت بيانات أفضل بشكل عام. لا نعتقد أن أجهزة Nvidia أسوأ، بل أن تقدم تحسينات البرمجيات في Jalapeño كان أسرع من Nvidia. وهذا يُظهر قوة التصميم المتكامل للعتاد والبرمجيات، وهو المجال الرئيسي الذي تمكّن فيه فرق ASIC في المختبرات الرائدة من تجاوز شركات الرقائق التجارية الأكثر نضجًا. وبشكل غير بديهي، قد يكون البدء من الصفر قد منح OpenAI ميزة أيضًا، لأنه يمكنه اتخاذ قرارات هندسية جديدة دون قيود التوافق العكسي أو الإصدارات القديمة من البرمجيات.

على الرغم من أن OpenAI لديها نموذج تجريبي Jalapeño، فإن الإنتاج الضخم مخطط له حاليًا للزيادة التدريجية في عام 2027، مع تخصيص معظم الإنتاج لآخر العام القادم. لمزيد من التفاصيل حول عدد الوحدات والسعر المتوسط، راجع نموذج SemiAnalysis Accelerator.

يمكن القول إن OpenAI Jalapeno هو مُعالج ASIC ضخم حقًا.

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

هيكل Jalapeño

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

كما يحتوي على نواة مقياسية بحجم 64 بت ونواة متجهية FP32/INT32. كما استثمرت OpenAI في تصميمات زائدة على مستوى الصواني، ودمجت استرداد العائد على مستوى النوى والقنوات. وادّعَوا أن المساعدة المدعومة بالذكاء الاصطناعي في تصميم الرقاقة قلّصت مساحة SIMD بنسبة 8% ومساحة محرك المصفوفة بنسبة 10%. وعلى الرغم من أنهم لم يحددوا شروط العملية/الجهد/الحرارة (PVT) الدقيقة، فقد أشاروا إلى أن وحدة المساعدة المدعومة بالذكاء الاصطناعي حسّنت التوقيت والاستهلاك الطاقي مقارنة بالوحدة الأولية.

يُركّز تصميم معمارية Jalapeño على القضاء على نقل الذاكرة الخاص بـ KVCache والأوزان، بالإضافة إلى التأخير والتكلفة الثابتة، بحيث يكون أقرب إلى القدرة الحسابية/العرض النطاقي القصوى الأصلية مقارنةً بغيره من مسرّعات، حتى في حالات الدفعات الصغيرة أو الأشكال الصغيرة.

تم تقسيم النوى وHBM إلى شرائح متعددة، حيث يمتلك كل شريحة نواة رؤية محلية منخفضة التأخير على شريحتها الخاصة من HBM. يتم مزامنة الشرائح عبر شبكة جمعية مخصصة ذات عرض نطاق عالي. وقد مكّنت هذه البنية الذاكرة المبسطة Jalapeño من تحقيق ميزة كبيرة مقارنة بالـ GPU، حيث يجب على وصولات الذاكرة في GPU عبور نظام ذاكرة معقد، مما ينتج عنه تأخيرات أكبر يجب توزيعها أو إخفاؤها على أشكال كبيرة.

هذا الخيار قابل للتنفيذ لأنه من خلال توزيع الأوزان و KV بدقة، يمكن تقييد المزامنة بين النوى على اتصالات عالية السعة محدودة ومعروفة، مثل اتصالات التوازي التنسوري التي يمكن تداخلها مع الحساب.

بالإضافة إلى ذلك، هناك NoC عام إضافي يستخدم للاتصالات العامة و الوصول إلى الشبكة الموسعة. بشكل عام، توفر OpenAI استهلاكًا كبيرًا للطاقة وتحقيق تحسن كبير في الأداء مقارنةً بـ Nvidia و Google من خلال نظام NOC ووحدة الذاكرة المبسطة.

على المستوى الأساسي، وصفت OpenAI نواة غير متسلسلة (OoO) مزودة بذاكرة تخزين مؤقت من المستوى L1. وهذا يختلف تمامًا عن النمط الذي نراه في مسرّعات أخرى، والتي تستخدم مخازن مؤقتة تُدار بالبرمجيات، عادةً مع دعم DMA غير متزامن. الحجة هنا هي أن هذا يسمح لـ Jalapeño بتجنب التكاليف الثابتة، مثل تأخير الحواجز، والتي تتطلب في مسرّعات أخرى (مثل GPU) زيادة كمية العمل لكل نواة لإخفائها أو توزيعها، مما يجعل من الصعب الوصول إلى عرض النطاق الترددي أو القوة الحسابية القصوى الخام.

الثمن هو أن Jalapeño يعتمد على التحميل المسبق الجيد لضمان وصول طلبات الذاكرة في الوقت المناسب، وهو ما يصعب التنبؤ به والاستدلال عليه. ومع ذلك، وبفضل Codex للحصول على مسارات تفصيلية في إطار جيد، يمكن العثور على النواة المثلى مع أفضل تحميل مسبق للشكل المعطى، وقد يتطلب ذلك تدخلًا بشريًا شبه معدوم. نعتقد أن هذا هو بالضبط السبب في قدرة OpenAI على تشغيل DeepSeek R1 وKimi K2.5 وGPT-OSS بسرعة كبيرة.

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

باستخدام Jalapeño، تركز OpenAI على القضاء على التأخير الثابت في النظام لتحقيق أداء قريب قدر الإمكان من roofline في جميع مناطق منحنى باريتو. نظريًا، قد يوفر هذا ميزة نسبية مقارنة بالـ GPU في عدة نقاط عمل:

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

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

هذا يأتي مع تحذير: حتى لو كان هناك حد أقصى نظري للأداء، فقد يكون من الصعب على النواة الفعلية تحقيق هذا الأداء. لذلك، يبدو أن منهجيتها هي:

تصميم أقصى أداء ممكن لجميع أشكال الأحمال

دع Codex يتحمل العبء ويجد النواة التي تحقق هذا الحد الأقصى

فريق OpenAI يُطلق حمولة InferenceX على Jalapeño بسرعة دوران عالية جدًا.

لذلك نحن متفائلون بشأن هذه الطريقة.

إذا نجح Jalapeño، فسيتم إطلاق إشارة قوية.

الانغماس الصناعي في نماذج البرمجة ومحرّكات الترجمة العامة المثالية سيُكسر من قبل نماذج الذكاء الاصطناعي المتقدمة.

تكتب OpenAI نواة Jalapeño كما تكتب تجميعًا.

كل نواة تحتوي على كود مُحسّن يدويًا، ويبلغ جزء منه حوالي 3000 سطر.

دعم أيضًا للتحقق من الصحة وSanitizer مخصص.

كانت أعمال النواة المبكرة تعتمد على تدخل الإنسان، وليست آلية بالكامل.

ثم انتقل إلى الإصدار الداخلي الأكبر حجمًا من Codex.

تخطط OpenAI لبيع هذا الإصدار للعملاء المؤسسيين.

يُسمى محرك الخدمة الداخلي "Teacup".

من المثير للاهتمام أن OpenAI لم تكن تمتلك سابقًا تنفيذًا داخليًا لـ MLA kernel.

حتى قاموا بإجراء اختبار معياري لـ DeepSeek باستخدام InferenceX.

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

هذا يُظهر قدرة تطوير خط أنابيب البرنامج.

OpenAI تستخدم Gluon لبرمجة Jalapeño.

Gluon هي لغة برمجة نواة OpenAI.

يُبنى Gluon على Triton، مع الحفاظ على نموذج البرمجة SPMD (Single Program Multiple Data) الخاص بـ Triton.

لكنه كشف عن التجريد البرمجي الأساسي.

على سبيل المثال، بالنسبة لـ NVIDIA GPU، فهي توفر واجهة برمجة تطبيقات تُخريطة إلى تعليمات PTX.

تشمل تعليمات MMA، وتعليمات TMA، وآلية mbarrier، إلخ.

التجريد الأكثر تميزًا الذي يقدمه Gluon هو التخطيط.

بشكل عام، يحدد التخطيط التعيين بين موارد الأجهزة وعناصر التنسور.

على سبيل المثال، المسجل الخامس في وارب 9 يتوافق مع عنصر المصفوفة في الصف السادس والعمود السابع.

يُستند تجريد تخطيط Gluon إلى التخطيطات الخطية.

هذا جبر تخطيط اخترعه OpenAI.

Linear Layouts تُصيغ رياضيًا ما هو التخطيط.

وتوفر أدوات لترتيب الواجهة.

يدعم هذا العديد من الميزات، مثل التحويلات المثبتة بشكل صحيح للتهيئة.

أيضًا تبديل الذاكرة الأمثل.

في نموذج البرمجة الخاص بـ Jalapeño، يتم تعيين كل برنامج Gluon إلى خيط دائم.

نعتقد أن هذا يشير إلى أن Jalapeño مناسب لنمط البرمجة الثابتة.

يُنفَّذ كل برنامج على عدة شرائح، حيث يُخصص المبرمج العمل، وليس مُجدول العتاد.

ذكرت OpenAI TensorInfo.

إنه تجريد لتصميم مُشفَّر صراحةً.

قد تكون هذه مجموعة من التصاميم المصممة لـ Jalapeño.

سيتم تشغيله بواسطة Linear Layouts.

أخيرًا، يوفر كل نواة وحدة تحميل مسبق للبيانات وفك الارتباط غير التسلسلي.

على سبيل المثال، يمكن للمستخدم برمجة الانتظار حتى يتم استرداد البيانات مسبقًا.

تم قفل هذا البيانات بواسطة المُسلّم.

السخرية المُرّة أن نماذج OpenAI مثل GPT 5.6 Sol تعمل حاليًا على وحدات معالجة رسومات NVIDIA.

They are used to design chips that pose a real threat to CUDA's moat.

GPU الخاصة بـ NVIDIA تُعزز حاليًا المرشح المحتمل للخلافة في الوقت الحقيقي.

بالمقارنة عبر الزمن، يمكننا أيضًا رؤية سرعة تطوير Jalapeño.

في أقل من أسبوعين، زادت سعة معالجة بعض سيناريوهات التفاعل بأكثر من مرتين.

كل tarball حصلنا عليه من فريق Jalapeño يحتوي على عالم رائع.

لم يتم تحسين أداء النواة فحسب، بل قام فريق Jalapeño بتمكين TP32 خلال 8 أيام.

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

هذا التطور السريع يُعد حقًا مُذهلًا.

للاختبار المسبق للأداء قبل التشغيل على أجهزة فعلية، تمتلك OpenAI محاكيًا يُسمى "chilisim".

دقتها ضمن 5% من الأجهزة الفعلية، باستخدام خطوط تrace بعرض ثابت.

القدرة على التتبع محدودة على A0، لكنها تحسنت بشكل كبير على B0.

قد يكون ذلك مدعومًا ببيانات التشغيل الفعلية لشرائح A0.

قام المهندس بعرض تشغيل النموذج الداخلي باستخدام Codex CLI.

يُعرف باسم "Raiku" أو "5.3 Codex Spark"، ووقت تنفيذ الأوامر (TPOT) هو 1.2 مللي ثانية.

كما عرض الفريق عرضًا توضيحيًا مكتوبًا بواسطة Codex يعمل مباشرة على الرقاقة.

تشمل Doom بـ 36 FPS ومحاكاة ديناميكا السوائل FP32.

كما يوجد تصور بسحب الفأرة "Liquid Light".

من حيث النماذج، يُعرف الحل الداخلي لـ OpenAI megakernel باسم "gigakernel".

يتم بناؤه حول ميغاكيرنيل واحد، ويدور على الجهاز لتقليل تكاليف CPU ووقت التشغيل.

يواصل الفريق تطوير استراتيجية الحساب أثناء الاختبارات.

الاهتمام الداخلي الخاص هو كيفية تنسيق استخدام 1,000,000 rollout.

هل يجب استخدام Disagg؟ هذا هو السؤال

كما ذكرنا سابقًا، لم تستخدم OpenAI فصل prefill-decode على هذه الرقائق.

لقد أثار هذا دهشتنا، لأن أداء وحدات معالجة الرسومات NVIDIA وAMD استفاد بشكل كبير من PDD.

حتى على نفس الأجهزة المتماثلة.

دعونا نستكشف لماذا قام فريق Jalapeño بذلك.

عندما يكون الحمل الثابت، يبدو فصل التمهيد-التفكيك جذابًا.

Prefill و decode يحملان ضغطًا مختلفًا على الأجهزة.

توزيع كل مرحلة على حوض مُحسَّن بشكل منفصل لتحسين الكفاءة تحت نسبة الإدخال والإخراج المختارة.

لكن حركة المرور الإنتاجية لن تحافظ على هذا النسبة.

تتغير طول تسلسل المدخلات والمخرجات، والتوازي، ونسبة إصابة الذاكرة المؤقتة، ونسبة قبول التخمين، وهدف التأخير طوال اليوم.

بمجرد تقسيم الجهاز إلى مجموعتي prefill و decode، فإن زيادة طلبات prefill ستؤدي إلى بقاء شرائح decode في حالة سكون، مع تراكم الطلبات في الطابور.

لكن الطلب المفرط على الترميز يعكس ذلك.

يجب على المشغلين التنبؤ المستمر بالتقسيم الصحيح وترك سعة احتياطية للجانبين.

وإعادة موازنة نظام يتغير فيه النسبة المثالية باستمرار.

في النظام الموحّد، قد لا تُستغل بعض الموارد بشكل كافٍ في مراحل معينة.

لكن لا يزال يمكن استخدام كل جهاز لخدمة الطلب التالي.

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

يبدو أن الاستخدام المحلي أفضل، لكن الاستخدام العالمي قد يكون سيئًا.

الفصل سيُدمّر الموضعية.

يُنشئ عامل التعبئة المسبقة ذاكرة KV كبيرة مطلوبة فورًا من قبل عامل الترميز.

يجب على النظام نقل هذا الحالة عبر الشبكة لاستمرار الإنشاء.

هذا يزيد من استهلاك النطاق الترددي، والمزامنة، والانتظار، ومجال خلل آخر.

التكاليف تزداد أيضًا مع طول تسلسل الإدخال لأن ذاكرة KV تنمو.

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

السماح بتحريك بعض KV يمكن أن يحسن استخدام الأجهزة، مع تكلفة استهلاك الطاقة وتأخير الطلب الواحد.

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

التجزئة الثابتة تُهدر الأجهزة عند تغير مجموعات الحركة.

إضافةً إلى ذلك، يتغير توازن الانتباه ووظيفة FFN مع تغيير طول السياق.

أي نسبة ثابتة للعتاد تكون فعالة فقط بالقرب من نقطة التصميم.

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

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

من الياباني إلى الهندي (حار خفيف إلى حار جدًا): كاتسو وفيندالو وشانا—كيف تُركّب هذه الأطباق الكاريّة في نظام رف؟

يتكون نظام Jalapeño على مستوى وحدة الرف من رف مضيف CPU ورف ASIC. يحتوي رف المضيف على 16 وحدة مضيف CPU تُسمى "Katsu". كل وحدة Katsu مرتبطة بأحد وحدات ASIC الـ16 الموجودة على الجانب الأيمن، والتي تُسمى "Vindaloo". كل مضيف مزود بمعالجين AMD EPYC من فئة Turin، و1.5 تيرابايت من ذاكرة DRAM، و2 وحدة E1.S و2 وحدة M.2 SSD. كما تأتي كل وحدة مزودة بشبكة أمامية بسعة 400 جيجابت (2×200 جيجابت). تتصل كل وحدة Katsu بكل وحدة Vindaloo عبر 8 كابلات PCIe DAC خارجية. تُركب هذه الكابلات أفقيًا في المقدمة الأمامية للرف. تم تصميم النظام على مستوى النظام بالتعاون مع Celestica.

يتكون رف ASIC من 16 صندوقًا Vindaloo و8 صناديق مفاتيح توسيع (6 محلية + 2 عالمية)، ويُسمى "Chana". يحتوي كل صندوق Vindaloo على 8 ASIC Jalapeño، ليصل المجموع الكلي إلى 128 ASIC Jalapeño لكل رف. يتم توصيل ASICs عبر لوحة خلفية من الكابلات النحاسية بكل صندوق مفاتيح Chana، على غرار Nvidia Oberon. تُقسَّم هندسة التوسيع إلى مجالات محلية وعالمية. يغطي المجال المحلي 128 ASIC داخل الرف. ويربط المجال العالمي ما يصل إلى 16 أرففًا أو 2,048 ASIC. سنشرح عرض النطاق الترددي والهندسة بالتفصيل أدناه.

تستهلك رفوف الخوادم الجانبية حوالي 50 كيلوواط (31 كيلوواط في الإنتاج)، بينما تستهلك رفوف ASIC 130 كيلوواط. يبلغ إجمالي نظام الرف المزدوج حوالي 160 كيلوواط. من حيث استهلاك الطاقة، هذا يعادل تقريبًا رفًا مزدوج العرض من GB300.

يمكن لـ OpenAI ربط ما يصل إلى 2,048 وحدة Jalapeño XPU ضمن شبكة موسعة واحدة. تتكون شبكة التوسيع من مجالين. يربط المجال المحلي جميع وحدات XPU الـ 128 داخل الرف عبر لوحة خلفية. يستخدم المجال العالمي مزيجًا من كابلات نحاسية ووصلات ضوئية لربط 2,048 وحدة XPU عبر 16 رفًا. يحتوي كل رف على 8 أرصفة تبديل Chana. تُستخدم 6 أرصفة تبديل Chana الوسطى للمجال المحلي، وكل منها يحتوي على ASIC تبديل Tomahawk 6 بسعة 102.4T. تُستخدم أرصفتا التبديل العلوية والسفلية للمجال العالمي. نعتقد أنه قد يكون هناك 2 وحدة تبديل Tomahawk 6 بسعة 102.4T لكل أرصفة، أي ما يصل إلى 204.8T لكل أرصفة تبديل.

في المنطقة المحلية، يوفر كل XPU عرض نطاق أحادي الاتجاه قدره 4.8 تيرابت/ثانية لـ 128 شريحة Jalapeño. وهي متصلة بطريقة كاملة إلى كاملة بـ 6 وحدات ASIC Tomahawk 6 بعرض نطاق قدره 102.4 تيرابت/ثانية. وهذا يعادل 48 زوجًا متمايزًا (DP) من موصلات ذكر وأنثى لكل XPU. بإجمالي 6,144 زوجًا من الكابلات النحاسية السلبية لكل رف لتوسيع محلي.

في المجال العالمي، يتم ربط 2,048 وحدة XPU عبر 16 رفًا باستخدام مزيج من لوحات خلفية نحاسية، ومفاتيح كهربائية 204.8T TH6، ووحدات ضوئية بسعة 1.6T، ومفاتيح تحويل ضوئي. تبلغ عرض النطاق الترددي الأحادي للرابط العالمي لكل وحدة XPU 1.6 تيرابت/ثانية. أي أن كل وحدة XPU تحتوي على 16 زوجًا متمايزًا (DP) من موصلات ذكر وأنثى، تُستخدم للاتصال بين وحدة XPU والمحول العالمي عبر اللوحة الخلفية. يحتوي كل صندوق محول عالمي على وحدتي ASIC، ويتم توزيع عرض النطاق الترددي الصادر بين اللوحة الخلفية والأجهزة الضوئية الأمامية.

بين المجال المحلي والمجال العالمي، عدد موصلات اللوحة الخلفية لكل رف هو 64 زوج DP لكل XPU. بإجمالي 8,192 زوج DP من كابلات النحاس السلبية لكل رف.

يستخدم المجال العالمي بنية Rail نقية، مكونة من 8 ريلات داخل المجال العالمي. نحن نعتقد أن OpenAI تستخدم مفاتيح تبديل الضوئية (OCS) مثبتة على كل رف لمسار روابط الضوء في المجال العالمي. سيتم نقل عرض النطاق الترددي العالمي البالغ 1.6 تيرابت/ثانية لكل XPU عبر لوحة خلفية نحاسية إلى صينية التبديل العالمية، ثم تخرج من المفتاح عبر وحدات ضوئية بسعة 1.6 تيرابت على الواجهة الأمامية. تدخل أولاً إلى مفتاح ضوئي سلبي، ثم تغادر الرف. وهذا يسمح بتوسيع حجم المجال إلى 2,048 XPU، موزعة على 16 رفًا، كل رف يحتوي على 128 XPU.

بما أن الشبكة الموسعة تمثل فقط حوالي 10% من تكلفة النظام الإجمالية، فإن هذا المرونة توفر خيارات قيّمة للنماذج المستقبلية التي تتراوح بين 10 تريليون و20 تريليون معلمة أو نوافذ سياقية تتراوح بين 2 مليون و4 مليون رمز. من حيث النشر، تتعاون OpenAI مع neocloud. كما أنها جمعت بيانات موثوقية مع شركاء مراكز البيانات قبل شهر واحد، في الوقت الذي كانت تُحسّن فيه وقت النشر من الرصيف إلى الرف.

الخطوة التالية

بعد ذلك، نناقش مستقبل Jalapeño، حيث سيُطلق أول رمز إنتاجي له قريبًا. الهدف التالي هو 100 ميغاواط، والمعوقات الرئيسية تتعلق بالعتاد: كم يمكنهم إنتاجه، وكم يمكنهم توزيع وتشغيل مراكز البيانات بكفاءة، وكيفية التعامل مع المراقبة والمرونة إلخ. لقد تم التحقق من البرنامج، ولديهم نماذج داخلية، وأي ميزة أولية في البرمجيات يمكن التغلب عليها بسهولة. خلف جدار الدفع، سنناقش تأثير ذلك على شركات الرقائق مثل NVIDIA وAMD وCerebras، التي وقّعت عقودًا مع OpenAI على مدار السنوات القادمة.

نحن نغطي أيضًا إنتاجية وكمية وجداول زمنية للرقائق من الجيل التالي في نموذج Accelerator.

الجزء التالي محتوى مدفوع، ولم يتم ترجمته أكثر بسبب مشاكل الصلاحيات، لكن النص السابق يحتوي على معلومات كافية تُظهر تحدي OpenAI لشرائح NVIDIA. هذه المعلومات ستقدم مرجعًا جديدًا وموثوقًا لللاعبين المهتمين بقطاع الشرائح وسعر سهم NVIDIA.

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