Google تفتح مصدر TorchTPU: PyTorch يحصل على TPU كجهاز أصيل

أتاحت Google للجميع TorchTPU، وهو مكدّس برمجي كامل لتشغيل PyTorch على TPU بوصفه جهازًا أصيلًا. وجاء الإعلان في مؤتمر PyTorch Conference 2026 في سان خوسيه. وإذا اختُصر الخبر في سطر شيفرة واحد، فهو: device_map="tpu". في Hugging Face Transformers يكفي هذا السطر لينتقل النموذج إلى المعالجات الTensorية من Google.

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

لماذا بقيت TPU زمنًا طويلًا حكرًا على قلة؟

تُعدّ TPU من Google منذ زمن عتادًا جادًّا. فالشركة تدرّب عليها نماذجها الخاصة، وأصبحت في السنوات الأخيرة تؤجّرها للعملاء الخارجيين بوتيرة متزايدة. وقد وقّعت مختبرات كبرى اتفاقيات لحجوزات ضخمة من قدرات TPU، أما الجيل السابع، Ironwood، فقدّمته Google بوصفه شريحة لعصر الاستدلال.

لم تكن الشريحة هي ما يعيق، بل الجسر بينها وبين عالم PyTorch. فاللغة المعتادة داخل Google كانت JAX، بينما كتبت بقية الصناعة بـ PyTorch. ولتشغيل PyTorch على TPU وُجد PyTorch/XLA، لكن المطوّر العادي رآه تخصصًا مستقلًا. كان لا بد من تكييف الشيفرة، وكان السلوك يختلف عن السيناريو المألوف مع GPU. وعاد كثير من الفرق إلى CUDA بعد المحاولة الأولى.

يُقدَّم TorchTPU على أنه الجواب عن هذه المشكلة. فبدل طبقة وسيطة يجب تعلّمها على حدة، تعرض Google TPU بوصفه جهازًا أصيلًا في PyTorch. وبالنسبة إلى مستخدم Transformers، يتقلص الفاصل بين «نموذج لـ GPU» و«نموذج لـ TPU» إلى قيمة معامل واحد.

ماذا فُتح بالضبط؟

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

أبرز حقائق الإصدار:

• يحمل المشروع اسم TorchTPU ويُوزَّع كمفتوح المصدر؛
• أُعلن عنه في PyTorch Conference 2026 في سان خوسيه؛
• الهدف هو جعل TPU جهازًا أصيلًا في PyTorch؛
• الواجهة لمستخدم Hugging Face Transformers: device_map="tpu"؛
• الخصم الرئيسي ليس شريحة بعينها، بل اعتياد المطورين على CUDA.

يبدو اختيار Hugging Face واجهةً للعرض قرارًا مدروسًا. فهنا يأخذ معظم المهندسين نموذجًا مفتوحًا للمرة الأولى، ويشغّلونه، ويقررون أين يتوسعون. وإذا بدا الطريق إلى TPU هناك بسيطًا كالطريق إلى GPU، فستصل Google إلى جمهور ضخم لم يكن ينظر أصلًا إلى عتادها.

كيف نختبر ذلك عمليًا؟

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

من المنطقي أن تتحرك الفرق التي تفكر في TPU بالترتيب التالي:

• أخذ نموذج قياسي من Transformers ومقارنة تكلفة ساعة التشغيل على TPU وGPU، لا السرعة وحدها؛
• فحص عدد نوى CUDA المخصصة والإضافات الخارجية في قاعدة الشيفرة، فهي المصدر الرئيسي للمتاعب عند الانتقال؛
• اختبار الاستدلال والتدريب كلًّا على حدة، لأن نضج المكدّس قد يختلف كثيرًا بين هذين السيناريوهين؛
• إبقاء مسار احتياطي على GPU إلى أن يجتاز TorchTPU الاختبار على حمل العمل الفعلي لديكم.

أما بالنسبة إلى السوق فالأهم شيء آخر. فما دام الانتقال إلى مسرّعات بديلة يتطلب إعادة كتابة الشيفرة، كانت Nvidia قادرة على الحفاظ على الأسعار وشروط التوريد. وكل خطوة تخفض كلفة الانتقال تمنح المشترين ورقة ضغط في المفاوضات، حتى لو بقي معظمهم على CUDA. الخندق لم يُردم، لكن Google أظهرت للتو أين يمكن عبوره.