تتغير مشهد المنافسة في شرائح الذكاء الاصطناعي بشكل عميق. أطلقت OpenAI شريحة Jalapeño مخصصة لاستنتاج نماذج اللغة الكبيرة، بينما دمجت NVIDIA وحدات GPU مع وحدات LPU من Groq لتحقيق الحوسبة الهجينة، وقسمت Google التدريب والاستنتاج إلى شريحتين منفصلتين هما TPU 8t وTPU 8i. تعكس هذه المسارات الثلاثة الاحتياجات المختلفة لموارد الأجهزة بين التدريب والاستنتاج: يركز التدريب على الحساب المصفوفي والربط الواسع النطاق، بينما يتطلب الاستنتاج عرض نطاق أعلى لـ HBM، وذاكرة SRAM أكبر، ومسارات شبكة أقصر. مع توسع الفجوة بين وصفات الشرائح المخصصة لكل نوع من الأحمال، لم يعد FLOPS معيارًا وحيدًا، بل أصبح تكلفة الرمز (Token) معيارًا جديدًا للمنافسة في أجهزة الذكاء الاصطناعي.

كاتب المقال، المصدر: LeiFeng.com

تكلفة الرمز تصبح معيارًا جديدًا للمنافسة على الأجهزة للنماذج الكبيرة

الذكاء الجسدي يغزو المطبخ المليء بالدخان

قصة روبوت يعمل تحت ضغط مليون زائر

النائب السابق لرئيس Covariant AI، Zhoupu Shuzhong، قام مباشرةً بتلخيص دور LPU في سد الفجوة في منطقة Decode منخفضة التأخير الخاصة بـ Vera Rubin.

كما تم تصميم شريحة Groq تقريبًا حول هذا الأمر. تحتوي مجموعة خزائن LPX على 256 وحدة LPU، بمجموع 128 جيجابايت SRAM، وهي سعة لا يمكن مقارنتها مع HBM في خزائن GPU، لكن عرض النطاق الترددي المجمّع لـ SRAM يمكن أن يصل إلى 40 بيتا بايت/ثانية.

هذا التصميم يركز على "القرب". يمكن لـ HBM تخزين العديد من حالات النموذج، لكنه أبعد عن وحدات الحساب؛ بينما يُعد SRAM مكلفًا وصعوبة في زيادة سعته، لكن البيانات موجودة داخل الرقاقة، مما يوفر عرض نطاق عالي جدًا وتأخير وصول منخفض جدًا.

يُظهر التقليل من حسابات كل خطوة، وجلب البيانات بشكل متكرر، ووضع البيانات أقرب إلى وحدة الحساب المنطقية (ALU)، تأثيرًا مباشرًا جدًا على وقت انتظار الرمز التالي.

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

التكلفة أيضًا واضحة: هذا الهيكل ليس عالميًا مثل وحدات معالجة الرسومات، ولا يمكن لذاكرة SRAM المدمجة استيعاب حالة النموذج الكبير الكامل. لذا لم تجعل NVIDIA Groq 3 يعمل بشكل مستقل على النموذج بأكمله، بل طورت نظامًا هجينًا أكثر تعقيدًا.

يتم تنفيذ التمهيد على GPU، مع نقل معظم عمليات التحليل إلى LPU؛ ويمكن أن تعود عمليات الانتباه داخل التحليل إلى GPU. تحتفظ GPU وLPU بكل من ذاكرتي KV الخاصتين بهما، وتتبادلان بشكل رئيسي رموز المسودة، مع تراكب الحساب والاتصال عبر الدفعات الدقيقة. نظرًا لأن LPU هي منطقة مزامنة، بينما تشكل GPU وذاكرة KV الخارجية نظامًا غير مزامن، أضافت NVIDIA حتى FPGA كجسر غير مزامن بين الطرفين.

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

ومع ذلك، تُظهر بيانات NVIDIA الحدود الممكنة لهذا المسار: عندما تركز الأعمال فقط على الإجمالي للإThroughput وتقبل تأخيرًا أعلى، لا يزال Rubin GPU فعالًا؛ مع زيادة متطلبات سرعة Token لكل مستخدم، يبدأ LPX في إظهار ميزاته، وبعد استخدام عدد أكبر من LPU، ينخفض كفاءة الإجمالي للإThroughput.

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

أما جوجل، فوضعت هذا الشق على مستوى أعلى.

التدريب والاستدلال، باستخدام وصفتين شريحتين منفصلتين

Google في الجيل TPU 8 قام بتطوير TPU 8t و TPU 8i معًا،t موجه للتدريب،i موجه للاستنتاج. المنطق وراء هذا التصنيف مكتوب مباشرةً على تكوين ذاكرة الرقاقة.

يتم عرض Hot Chips مباشرة، يستخدم TPU 8t 6 مجموعات HBM، بينما يستخدم TPU 8i 8 مجموعات. وقدمت Google التفسير بأن الاستنتاج يتطلب المزيد من HBM لكل وحدة حساب، بالإضافة إلى نسبة أعلى من SRAM، لذا قام TPU 8i بتخصيص المزيد من الموارد لـ SRAM وسعة الذاكرة وعرض النطاق الترددي.

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

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

حتى جوجل طبقت هذا الفرق على البنية الشبكية. كان 3D Torus المستخدم عادةً في TPU أكثر ملاءمة للتدريب، مع التركيز على الإنتاجية الكلية داخل مجموعات كبيرة. يدعم TPU 8i BoardFly، مع مسارات شبكة أقصر: الحد الأقصى لمسارات BoardFly هو 7 hops، بينما يصل 16 hops في 3D Torus.

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

يجعل MoE هذه المشكلة أكثر وضوحًا. يمكن لـ MoE أن يُفعّل جزءًا فقط من الخبراء لكل رمز، مما يجعله فعالًا من حيث الحساب، لكن الموجه سيُرسل الرموز إلى خبراء مختلفين. بمجرد توزيع هذه الخبراء على شرائح مختلفة، سيزداد الاتصال All-to-All مع تقليل الحساب.

لذلك أضافت TPU 8i أيضًا محرك تسريع جماعي، حيث يتم تنفيذ بعض العمليات الجماعية على قطعة I/O القريبة من واجهة الشبكة. لا حاجة لنقل البيانات أولاً إلى قطعة الحوسبة، ثم إكمال العملية عبر HBM، مما يتيح تجنب جزء من نقل البيانات داخل الرقاقة.

يتم توجيه تخصيص الموارد لوحدة TPU 8t الإصدار التدريبي بوضوح نحو الجانب الآخر. تتطلب التدريبات كمية كبيرة من FLOPS، كما تحتاج إلى نطاق كبير للتوسيع لتوحيد المعلمات والانحدارات. يمكن توسيع Superpod الخاص بـ TPU 8t إلى 9600 شريحة، وتتمتع بحوالي 2 PB من ذاكرة HBM المشتركة و121 EFLOPS FP4 من قدرة حسابية مجمعة، كما أدخلت Google شبكة Virgo لها لربط التدريبات على نطاق أوسع ضمن نظام مخصص.

كما ذكرت جوجل في الموقع مشكلة عملية في تصميم الرقائق: السيليكون المظلم.

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

بما أن كلا المهمتين تتطلبان نسبًا مختلفة من الموارد، فمن الأفضل بشكل أوضح تنفيذ شريحتين منفصلتين.

من FLOPS إلى اقتصاد الرموز

وضع الخطوط الثلاثة معًا، الفروق واضحة حقًا.

تقوم OpenAI بعمل Jalapeño، وتخصص الرقائق حتى مستوى استنتاج LLM، مع الاحتفاظ بالجدولة المرنة لـ Prefill و Decode على نفس البنية الأساسية؛ بينما تستمر NVIDIA في التجزئة إلى أسفل، وتُوزّع مراحل الاستنتاج الواحدة بين GPU وGroq LPU؛ وتأخذ Google نهجًا أعلى، فتصنع التدريب والاستنتاج كرقاقتين منفصلتين من TPU.

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

كلما زاد الفرق بين "وصفات الرقائق" المطلوبة من نوعي الحمل، زادت خسارة الكفاءة عند استخدام رقاقة عامة واحدة لخدمة كليهما.

وهذا هو السبب في أن الأرقام الأساسية في هذه الدورة من المنافسة على الأجهزة تتغير. لا تزال FLOPS مهمة، لكنها بدأت تظهر بجانبها Tokens/s/user وTBT وTTFT وTokens/kW وعرض نطاق HBM وتأخير الشبكة.

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

OpenAI وNVIDIA وGoogle لا تزال تختار خط فاصل مختلفًا حاليًا، ومن المرجح أن يكون الخط الحقيقي الذي سيستمر في التغيير هو أين يجب رسم هذا الخط.

يمكن فصل التدريب والاستدلال، ويمكن فصل Prefill و Decode، ويمكن أيضًا فصل Attention داخل Decode عن الحسابات الأخرى. كلما تم التفصيل أكثر، زادت سهولة تحسين كفاءة كل وظيفة، لكن توزيع الموارد ونقل KV Cache والاتصال عبر الأجهزة يصبح أكثر تعقيدًا.

لذلك، قد لا تكون التحديات في المرحلة القادمة من المنافسة على رقائق الذكاء الاصطناعي مجرد تصنيع رقاقة أقوى.

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