Google تطلق TPU 8i Max و8tx: رقائق للوكلاء والبيانات السرية

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

ما العتاد الجديد؟

تضم عائلة TPU من الجيل الثامن الآن أربعة أنظمة. والإضافتان الجديدتان هما TPU 8i Max وTPU 8tx.

يجمع TPU 8i Max، في جوهره، وحدتين من TPU 8i. وتقول Google إنه يضاعف القدرة الحسابية، إلى جانب مضاعفة سعة SRAM وعرض نطاق HBM. ويستهدف نوافذ السياق الهائلة ومهام الوكلاء المعقدة. هنا، تكتسب الذاكرة وعرض نطاقها أهمية أكبر من أرقام التيرافلوبس الخام: ففي السياقات الطويلة، يُستهلك معظم الوقت في قراءة ذاكرة KV المؤقتة، لا في ضرب المصفوفات.

صُمّم TPU 8tx للحوسبة السرية. فهو يحمي البيانات على مستوى العتاد أثناء معالجتها، سواء في الاستدلال أو الضبط الدقيق. وبالنسبة إلى البنوك والقطاع الصحي والمنتجات القانونية، قد يزيل ذلك الاعتراض الرئيسي على النماذج السحابية: «لا يمكننا إرسال هذه البيانات إلى الخارج».

البرمجيات المحيطة بالرقائق

هنا يكمن الجانب الأكثر عملية في الإعلان.

ينقل Agent Compute Engine حالة جلسات الوكلاء الخاملة، ويحرّر المسرّعات. تخيّل خدمة دعم العملاء: يطرح الوكيل سؤالًا ثم ينتظر الرد يومًا كاملًا. في السابق، كان سياقه يشغل ذاكرة رقاقة مرتفعة التكلفة. أما الآن، فتُرحّل الحالة خارجها، وتخدم الرقاقة وكلاء آخرين.

يقلّص TPU Sync زمن نقل ذاكرة KV المؤقتة بأكثر من 90%، وفقًا لبيانات Google. وتبرز أهمية ذلك عند توزيع مرحلتي prefill وdecode على عُقد مختلفة: كلما انتقلت الذاكرة المؤقتة بسرعة أكبر، قصرت فترة الانتظار قبل ظهور أول رمز نصي.

حصل XLA Serving Engine على محرك مفتوح المصدر بلغة C++ لتشغيل النماذج وتقديم استجاباتها على وحدات TPU وGPU وCPU. وهذه إشارة مهمة للفرق التي تخشى الارتهان لمورّد واحد: إذ يمكن تشغيل طبقة تقديم النماذج نفسها على أنواع مختلفة من العتاد.

يسرّع GKE Dynamic Slicing بدء المهام بما يصل إلى 5 أضعاف، والتعافي من الأعطال بما يصل إلى 4.5 أضعاف. وفي عمليات التدريب والضبط الدقيق الطويلة، يعني ذلك توفيرًا مباشرًا في المال، بفضل تقليص فترة توقف العنقود بعد تعطل إحدى العُقد.

Gemini يصمّم الرقائق

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

القيود

جميع الأرقام، بما فيها نسبة 90% الخاصة بذاكرة KV المؤقتة وتسريع GKE بمقدار 5 أضعاف، مأخوذة من مواد Google ولم تخضع للتحقق المستقل. ولا يتضمن الإعلان أسعارًا أو مواعيد للإتاحة أو المناطق المشمولة. كما لا يتضمن مقارنة مع Nvidia، لذا ما زال من المبكر الحكم على أي تفوق في تكلفة الرمز النصي. وتستحق الحوسبة السرية على 8tx فحصًا منفصلًا: ما التهديدات التي تغطيها الحماية تحديدًا، وكيف تعمل آلية إثبات موثوقية البيئة، وما مستوى الأداء عند تفعيل الحماية؟

ما الخطوات العملية؟

إذا كنتم تطوّرون منتجات تعتمد على الوكلاء وتستخدم جلسات طويلة، فاحسبوا نسبة الوقت الذي تقضيه مسرّعاتكم خاملةً في انتظار الردود. هنا تحديدًا يمكن أن يحقق Agent Compute Engine أثرًا. وإذا كنتم تتعاملون مع بيانات خاضعة لمتطلبات تنظيمية، فادرسوا 8tx بوصفه نقطة يمكن طرحها في النقاش مع فرق الأمن. وإذا كنتم تخشون الارتهان لمورّد واحد، فاطّلعوا على XLA Serving Engine المفتوح المصدر: يمكن تجربته بصرف النظر عن اختيار الرقاقة. وينبغي لفرق المنتجات انتظار الأسعار ونتائج الاختبارات المعيارية قبل إعادة بناء بنيتها التحتية.