أصبح تشغيل نموذج ذكاء اصطناعي ضخم على نطاق واسع أقل شبهاً بالإنجاز العلمي وأقرب إلى مسألة رياضية قاسية تتعلق بفواتير الكهرباء وإيجار مراكز البيانات. كل رمز (token) يولده Gemini يكلف Google شيئاً ملموساً: دورات السيليكون، ونطاق عرض الذاكرة، والواط المسحوب من الشبكة. ومع زيادة حجم الاستعلامات، تتراكم أجزاء السنت لتصبح مبالغ يمكن أن تلتهم هوامش الربح بالكامل. هذا الإلحاح الصامت هو ما يقف وراء Frozen v2، وهو مشروع داخلي لرقاقة خوادم بدأ يتشكل الآن داخل Google. فبدلاً من تحسين وحدات Tensor Processing Units متعددة الأغراض لجيل آخر، تحاول الشركة القيام بشيء أكثر راديكالية: صب هيكل نموذج Gemini مباشرة في السيليكون نفسه.

من المسرعات المرنة إلى السيليكون المخصص للنماذج

كانت وحدات TPU الخاصة بـ Google هي العمود الفقري لبنيتها التحتية لما يقرب من عقد من الزمان. فهي تقوم بتدريب النماذج، وتدعم خوارزميات ترتيب نتائج البحث، بل ويتم تأجيرها بالساعة لعملاء السحابة بما في ذلك Meta وغيرهم ممن يبحثون عن بديل لوحدات GPUs من Nvidia. هذه التعددية هي بالضبط ما يجعل الـ TPU عبارة عن TPU؛ فهي تتحدث لغة عامة من عمليات ضرب المصفوفات ونقل الذاكرة، والتي يمكن استخدامها من قبل أي شبكة عصبية تقريباً يمكنك وصفها برمجياً.

يتخلى Frozen v2 عن تلك المرونة عن عمد. حيث يتم تصميم الرقاقة كمسرع مخصص لمجال معين، بحيث تعكس دوائرها مادياً أجزاءً من بنية Gemini نفسها. فبينما تقوم الـ TPU بجلب التعليمات وتفسيرها كعمليات برمجية، سيقوم Frozen v2 بحفر المخطط الهيكلي للنموذج — أي ترتيب طبقاته ومسارات البيانات — مباشرة في تصميم الرقاقة. تتوقع Google أن يؤدي هذا الارتباط الوثيق بين النموذج والمعدن إلى جعل الرقاقة أكثر كفاءة بست إلى عشر مرات من وحدات TPU الحالية في تقديم استجابات الذكاء الاصطناعي. فعدد أقل من خطوات الحوسبة لكل استعلام يعني وقتاً أقل في انتظار ظهور الرمز، وطاقة أقل بكثير تُستهلك في توليده.

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

لماذا "ذاب" الإصدار الأول من Frozen

تعود جذور هذا النهج إلى مفهوم سابق يُنسب إلى Jeff Dean، كبير العلماء في Google DeepMind. اقترح مقترح "Frozen" الأصلي دفع التخصص إلى أبعد من ذلك، ليس فقط من خلال البرمجة الصلبة (hardcoding) للهيكلية، بل وأيضاً لأوزان النموذج الفعلية — وهي المليارات من المعلمات المضبوطة التي تشكل سلوك Gemini المتعلم — مباشرة في الرقاقة نفسها.

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

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

بنية بلا قيود

يحل Frozen v2 فخ التقادم من خلال البرمجة الصلبة للهيكلية مع ترك الأوزان حرة للتغيير. فكر في الأمر كصب مضمار سباق مخصص بدلاً من لحام السيارة بالطريق. يظل شكل الدائرة ثابتاً، ومحسناً لأنماط الحوسبة الخاصة بـ Gemini، ولكن المحتويات التي تتدفق عبر تلك الدوائر يمكن تحديثها عن طريق تحميل أوزان جديدة من الذاكرة.

هذا التمييز مهم من الناحية العملية. فعندما يقوم المهندسون بتدريب نقطة فحص (checkpoint) جديدة لـ Gemini، يمكنهم نشرها على أجهزة Frozen v2 دون الحاجة إلى تصنيع رقاقة جديدة. لا تزال درجة البرمجة الصلبة الدقيقة مسألة مفتوحة داخل Google؛ حيث يجب على الفرق تحديد العناصر الهيكلية التي تستحق "الخلود في السيليكون" بدقة، والعناصر التي يجب أن تظل قابلة للتهيئة. لكن المبدأ قد حُسم؛ فمن خلال تجميد الشكل وتبديل المعلمات بسلاسة، تحافظ Google على ميزة الكفاءة دون التضحية بالقدرة على التكرار والتطوير.

اقتصاديات الإبقاء عليه داخلياً

هناك سبب آخر لعدم رؤية Frozen v2 مدرجاً في قائمة أسعار Google Cloud. نظرًا لأن الرقاقة مصممة بشكل وثيق حول المكونات الداخلية لـ Gemini، فلن يكون لها جدوى تذكر للمطورين الخارجيين الذين يستخدمون PyTorch أو متغيرات Transformer مخصصة. ليس لدى Google خطط لبيعها كمنتج عام الأغراض، بل ستظل أداة داخلية، تهدف مباشرة إلى تلبية الطلب الهائل على قدرة الاستدلال (inference capacity) داخل مراكز بيانات Google نفسها.

يعكس هذا الخيار واقعاً اقتصادياً صارخاً. في سوق الذكاء الاصطناعي التوليدي الحالي، تتقارب قدرات النماذج بسرعة. غالباً ما تكمن الفجوة بين المنافسين في من يستطيع تحمل تكلفة تشغيل أكبر نموذج بأقل تكلفة لكل رمز (token). لم يعد الاستدلال (Inference) مجرد فكرة ثانوية تأتي بعد التدريب؛ فبالنسبة لمنتج واسع الاستخدام مثل Gemini، فإنه يمثل النفقات المهيمنة. إذا نجح Frozen v2 في خفض تلك النفقات بمقدار ستة أضعاف أو أكثر، فستكتسب Google مساحة من المناورة لا يمكن للمنافسين مضاهاتها بسهولة. يمكنها إما الاحتفاظ بالمدخرات كأرباح أو تمريرها في شكل أسعار أقل لمستهلكي واجهة برمجة التطبيقات (API) وتكاملات المنتجات، مما يضغط على OpenAI وAnthropic وغيرهما.

ما يشير إليه هذا بالنسبة للصناعة

تشير خطوة Google أيضاً إلى الاتجاه الذي تسلكه استراتيجية الأجهزة (hardware) الأوسع نطاقاً. لسنوات، كان النهج المعتاد هو بناء أكثر مسرع (accelerator) مرونة ممكنة وترك البرمجيات تتولى مهمة التخصص. تهيمن وحدات معالجة الرسومات (GPUs) من Nvidia لأنها تشغل كل شيء، بدءاً من الديناميكيات الجزيئية وصولاً إلى ألعاب الفيديو ونماذج اللغات الكبيرة. وقد صُممت وحدات TPU الخاصة بـ Google بنفس روح المنفعة الواسعة.

يكسر Frozen v2 هذا التقليد. إنه اعتراف بأنه عندما تدفع عائلة واحدة من النماذج حجماً كافياً من الاستعلامات، فإن السيليكون المخصص المصمم لهذا النموذج يمكن أن يسترد تكلفته عدة مرات. وقد اتبعت شركات الحوسبة السحابية الضخمة (hyperscalers) الأخرى منطقاً مشابهاً - مثل رقائق Trainium وInferentia من Amazon على سبيل المثال - ولكن نهج Google يذهب إلى أبعد من ذلك من خلال التصميم المشترك للأجهزة حول بنية نموذج محددة بدلاً من فئة عامة من الشبكات.

الخطر، بطبيعة الحال، هو الجمود. إذا تطورت بنية Gemini في اتجاه لا تستطيع الدوائر المبرمجة مسبقاً (hardcoded circuits) استيعابه، فقد تجد Google نفسها مع سيليكون باهظ الثمن لا يمكنه تشغيل أحدث أفكارها. وهذا هو بالضبط سبب أهمية التسوية القائمة على البنية فقط. فهي توفر مساراً وسطاً: تخصصاً كافياً لتحقيق مكاسب هائلة في الكفاءة، ومرونة كافية لتجنب وضع الشركة في مأزق.

الخلاصة الحقيقية

من الأفضل فهم Frozen v2 ليس كإعلان عن شريحة، بل كرهان استراتيجي على الشكل المستقبلي للمنافسة في مجال الذكاء الاصطناعي. تراهن Google على أن الفائزين لن يكتفوا ببناء أفضل النماذج فحسب، بل سيمتلكون البنية الكاملة (stack) - بدءاً من المخطط الأساسي للنموذج وصولاً إلى الإلكترونات التي تتحرك عبر الترانزستور. إذا نجح المشروع، فلن تظهر العوائد في نتائج اختبارات الأداء (benchmarks). بل ستظهر في عمود التكاليف في تقرير الأرباح الربع سنوي، حيث يمكن لتوفير بضعة سنتات لكل مليون رمز (token) أن يعيد رسم حدود ما هو ممكن تجارياً في مجال الذكاء الاصطناعي التوليدي.