🤖 AI

Fine-Tuning and Serving Gemma 4 31B on Google Cloud TPU: A Technical Comparison with GPU Baselines

تقدم هذه الورقة أول عرض توضيحي شامل لعمليات الضبط الدقيق والتشغيل لنموذج Gemma 4 31B على وحدات معالجة الموتر من Google Cloud (TPUs)، مع تفصيل التعديلات البرمجية اللازمة لنقل سير العمل المخصص لوحدات معالجة الرسومات (GPU-native) إلى حزمة JAX، وإثبات أن تهيئة الـ TPU تحقق سرعة تدريب تبلغ 1.61 ضعفاً بتكلفة أقل بمقدار 1.82 ضعفاً، مع إنتاجية استدلال مماثلة وزمن انتقال منخفض بشكل كبير مقارنة بالنماذج المرجعية لوحدات H100 GPU.

المؤلفون الأصليون: Jatin Kishnani, Mayank Goel, Amit Singh, Pulkit Agrawal, Sairanjan Mishra

نُشر 2026-05-26

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Jatin Kishnani, Mayank Goel, Amit Singh, Pulkit Agrawal, Sairanjan Mishra

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك تحاول تعليم روبوت ذكي للغاية ومكلف للغاية (نموذج ذكاء اصطناعي) مهارة جديدة: كتابة أكواد الكمبيوتر للدوائر الإلكترونية (Verilog). لديك خياران لـ "المدرسة" التي سيتم فيها هذا التدريب:

مدرسة الـ GPU: تديرها شركة NVIDIA، باستخدام رقائق H100 الشهيرة الخاصة بها. هذا هو المسار التقليدي والمعتاد الذي يسلكه الكثير من المعلمين ذوي الخبرة.
مدرسة الـ TPU: تديرها شركة Google، باستخدام رقائق TPU المخصصة والفريدة من نوعها. هذه المدرسة أحدث، وأكثر تخصصًا، وأسرع، وأرخص، لكنها تتطلب منك تعلم لغة جديدة تمامًا للدخول إليها.

هذا التقرير من h2loop.ai هو عبارة عن "دليل ميداني" كتبه مهندسون قرروا تجربة مدرسة Google TPU. لقد أخذوا نموذج ذكاء اصطناعي بـ 31 مليار معلمة (Gemma 4) وعلموه كيفية كتابة الكود، ثم قارنوا مدى جودة أدائه مقابل مدرسة NVIDIA التقليدية.

إليك تفاصيل رحلتهم، مشروحة ببساطة:

1. حاجز اللغة (مشكلة النقل)

العقبة الأكبر لم تكن الأجهزة نفسها؛ بل كانت البرمجيات.

مدرسة الـ GPU تتحدث لغة PyTorch، وهي لغة برمجة شائعة يعرفها معظم مطوري الذكاء الاصطناعي بالفعل.
مدرسة الـ TPU تتحدث لغة JAX، وهي لغة مختلفة تتطلب طريقة تفكير مختلفة.

اضطر المؤلفون إلى ترجمة "خطة الدرس" بأكملها من PyTorch إلى JAX. كان عليهم القيام بما يلي:

إعادة تنظيم كيفية تقسيم "دماغ" النموذج عبر رقائق متعددة (مثل تنظيم مكتبة حيث الكتب مبعثرة في 4 غرف بدلاً من غرفتين).
إعادة تسمية أجزاء معينة من النموذج لأن مدرسة TPU تطلق مسميات مختلفة (على سبيل المثال، تسمية "q_proj" بـ "q_einsum").
بناء "جسر" مخصص لحفظ عملهم، لأن مدرسة TPU تستخدم نظام أرشفة مختلفًا (Orbach) عن بقية العالم (Safetensors).

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

2. سباق التدريب (تعليم الروبوت)

بمجرد إعداد النموذج، بدأوا سباق التدريب.

السرعة: كانت مدرسة الـ TPU أسرع بمقدار 1.6 مرة. لقد أنهت الدورة التدريبية في 3.3 ساعة، بينما استغرقت مدرسة الـ GPU حوالي 5.4 ساعة.
التكلفة: نظرًا لأن مدرسة الـ TPU تتقاضى أجرًا أقل في الساعة وتنهي العمل بشكل أسرع، فإن الفاتورة الإجمالية كانت أرخص بمقدار 2.1 مرة.
- فاتورة الـ GPU: حوالي 119 دولارًا.
- فاتورة الـ TPU: حوالي 56 دولارًا.

لماذا كانت الـ TPU أسرع؟
فكر في رقائق الـ TPU كفريق من 4 عداءين يمررون العصا (البيانات) لبعضهم البعض بسرعة فائقة عبر طريق سريع داخلي (ICI). مدرسة الـ GPU كان لديها عداءان فقط. ورغم أن العداءين في مدرسة الـ GPU كانوا أسرع قليلاً كأفراد، إلا أن قدرة فريق الـ TPU على التنسيق وتحريك البيانات معًا جعلت الفريق بأكمله يفوز.

3. الامتحان (هل تعلم الروبوت؟)

بعد التدريب، اختبروا الروبوتات في امتحان برمجة Verilog.

النتيجة: الروبوت الذي تدرب على الـ GPU سجل درجة أعلى قليلاً (حوالي 5% أفضل) في الأسئلة الأكثر صعوبة.
الملاحظة: أشار المؤلفون إلى أن هذا الاختلاف يعود على الأرجح إلى أن المدرستين قامتا بتصحيح الامتحانات بطرق مختلفة قليلاً (إحداهما تجاهلت جزء "الطلب/البرومبت" من السؤال، والأخرى لم تتجاهله)، وليس لأن أحد الروبوتين كان أذكى بطبيعته. لم يكن الفرق كبيرًا من الناحية الإحصائية.

4. مقابلة العمل (تشغيل النموذج)

بعد التدريب، يحتاج النموذج إلى البدء في العمل، أي الإجابة على أسئلة المستخدمين في الوقت الفعلي. وهذا ما يسمى "الاستدلال" (Inference). اختبروا مدى سرعة النموذج في الإجابة على أسئلة ذات أطوال مختلفة.

الأسئلة القصيرة (المهام البسيطة):
- كانت مدرسة الـ GPU أسرع قليلاً في الإجابة على الأسئلة القصيرة جدًا.
- كانت أيضًا أرخص قليًا لكل إجابة لهذه المهام السريعة.
- التشبيه: إذا كنت تريد شراء قهوة واحدة فقط، فإن المتجر المحلي (GPU) أكثر كفاءة قليًا.
الأسئلة الطويلة (المهام المعقدة):
- عندما أصبحت الأسئلة طويلة (أكثر من 4,000 كلمة)، اكتسحت مدرسة الـ TPU الوضع تمامًا.
- السرعة: كانت الـ TPU أسرع بـ 23 مرة في بدء الإجابة على سؤال طويل (الوقت حتى أول توكن/Time-to-First-Token).
- السعة: استطاعت الـ TPU التعامل مع 4 أضعاف عدد الأشخاص الذين يطرحون أسئلة طويلة في نفس الوقت دون أن تتباطأ.
- التشبيه: إذا كنت بحاجة إلى كتابة رواية كاملة، فإن مدرسة الـ TPU تمتلك مكتبة ضخمة وفريقًا من الكتاب الذين يمكنهم العمل معًا بسلاسة. أما مدرسة الـ GPU فستتعرض للارتباك وتبدأ في إسقاط الكتب.

5. الحكم النهائي

خلص المؤلفون إلى أنه بالنسبة لاحتياجاتهم الخاصة (تدريب نموذج كبير وتقديمه للمستخدمين)، فإن Google TPU هي الفائزة.

التدريب: الـ TPU هي البطل الواضح (أسرع وأرخص بكثير).
الاستدلال: الـ TPU هي البطلة في أي شيء معقد أو طويل. بالنسبة للمهام البسيطة والقصيرة جدًا، لا تزال الـ GPU أفضل قليلاً.
التكلفة الإجمالية: عند جمع تكلفة التدريب ويوم واحد من تقديم الخدمة للمستخدمين، كان إعداد الـ TPU أرخص بمقدار 1.8 مرة بشكل عام.

الخلاية:
تطلب الانتقال إلى مدرسة الـ TPU الكثير من العمل الشاق في البداية (تعلم لغة جديدة، إصلاح الأثاث، بناء الجسور). ولكن بمجرد استقرارهم، كانت المدرسة تعمل بشكل أسرع، وتكلف أقل، وتتعامل مع المهام الكبيرة والمعقدة بشكل أفضل بكثير من مدرسة الـ GPU التقليدية. بالنسبة لشركة تقوم بأعمال ثقيلة في مجال الذكاء الاصطناعي، كان الجهد الإضافي للتحول يستحق العناء من أجل التوفير في التكلفة والأداء.

ملخص تقني: مقارنة بين TPU و GPU لنموذج Gemma 4 31B باستخدام تقنية LoRA SFT

بيان المشكلة

تواجه عمليات الضبط الدقيق (Fine-tuning) وخدمة النماذج اللغوية الكبيرة (LLMs) قيوداً متزايدة تتعلق بتكاليف الحوسبة وسرعة التكرار، بدلاً من توافر البيانات. وبينما توفر وحدات معالجة الموتر من جوجل (TPUs) أداءً نظرياً عالياً، يُنظر إلى منظومتها غالباً على أنها تتطلب جهداً هندسياً كبيراً مقارنة بمنظومة الـ GPU الناضجة القائمة على PyTorch. يعالج هذا التقرير الفجوة في الأدوات المفتوحة عبر توثيق عملية نقل وصفة تدريب قياسية (PyTorch, HuggingFace TRL, FSDP) من بيئة GPU إلى بيئة TPU القائمة على JAX (تشمل Tunix, Qwix, Orbax) لنموذج Gemma 4 31B. تستهدف الدراسة تحديداً الضبط الدقيق الخاضع للإشراف باستخدام LoRA (SFT) لتوليد أكواد Verilog، وما يتبع ذلك من خدمة الاستدلال (Inference serving)، مع تقديم مقارنة تجريبية بين أجهزة TPU و GPU تحت ظروف تشغيل (Hyperparameters) متطابقة.

المنهجية

قام المؤلفون بإجراء مقارنة جنباً إلى جنب للضبط الدقيق وخدمة نموذج Gemma 4 31B على تكوينين مختلفين من الأجهزة:

التدريب: TPU v5p-8 (4 رقائق) مقابل 2× NVIDIA H100 80GB GPUs.
الاستدلال: TPU v6e-8 (Trillium, 8 رقائق) مقابل 2× NVIDIA H100 80GB GPUs.
مجموعة البيانات: CodeV-R1 (10 آلاف زوج من اللغة الطبيعية إلى Verilog) للتدريب؛ وNVlabs/verilog-eval (156 مشكلة من المواصفات إلى RTL) للتقييم.

التعديلات الهندسية (من GPU إلى TPU)

تضمن جوهر المنهجية جهداً شاملاً للنقل بهدف تكييف مسارات التدريب والاستدلال من PyTorch إلى JAX:

تكوين الإطار والشبكة (Framework & Mesh Configuration): الانتقال من PyTorch FSDP إلى JAX مع تكوين شبكة أجهزة صريح (fsdp=1, tp=4 لـ v5p-8). لاحظ المؤلفون أن tp=8 فشلت لأن عدد رؤوس الانتباه (Attention heads) في Gemma 4 لا يقبل القسمة على 8.
حقن وتسمية LoRA: معالجة الاختلافات في تسمية الوحدات بين HuggingFace (PyTorch) و Tunix (JAX). ومن الجدير بالذكر أن Tunix يدمج إسقاطات K و V في تنسور واحد kv_einsum مما يتطلب معالجة مخصصة أثناء دمج نقاط التفتيش (Checkpoint merging).
التجزئة والتحسين (Sharding & Optimization): تنفيذ إصلاحات لتعليقات LoRA التجزئية حيث ورثت المعلمات المحقونة عبر Qwix رتب (Ranks) غير متطابقة من الأوزان الأساسية. تم تغيير المُحسن (Optimizer) إلى Optix AdamW، مما تطلب منطق تجزئة حالة مخصص.
مسار البيانات: استبدال DataLoader الخاص بـ HuggingFace بمكتبة Grain من جوجل، مع تنفيذ منطق مخصص لقناع الخسارة (Loss masking) (حذف مطالبات النظام وسلاسل الاستدلال) ومعالجة التسلسل.
نقاط التفتيش والتحويل: تطوير مسار مخصص لدمج محولات LoRA من Orbax (تنسيق JAX) مرة أخرى إلى Safetensors (تنسيق PyTorch/HF) لغرض الاستدلال، مع مراعاة عمليات تبديل أشكال التنسورات وتقسيمات kv_einsum المدمجة.
إعداد الاستدلال: نشر vLLM-TPU على v6e-8 باستخدام صورة Docker محددة (vllm/vllm-tpu:gemma4)، مع التعامل مع قيود مثل تجميع XLA عند بدء التشغيل، وتخصيص HBM، وتعطيل المدخلات متعددة الوسائط المجزأة بسبب أبعاد الانتباه غير المتجانسة في Gemma 4.

النتائج الرئيسية

أداء التدريب

السرعة: أكمل TPU v5p-8 التدريب بسرعة أكبر بـ 1.61 ضعفاً (3.34 ساعة) مقارنة بالخط المرجعي 2×H100 (5.39 ساعة).
الإنتاجية (Throughput): حقق TPU معدل 763 توكن/ثانية مقابل 486 توكن/ثانية على GPU.
التكلفة: بفضل الأسعار الساعية المنخفضة ( $16.80 مقابل$ 22.12) والتنفيذ الأسرع، كان تدريب TPU أرخص بـ 2.12 ضعفاً ( $56.11 مقابل$ 119.23).
تقارب الخسارة (Loss Convergence): اتبع كلا النموذجين مسارات تقارب متشابهة. ويُعزى الفرق المطلق في الخسارة (0.072 لـ TPU مقابل 2.258 لـ GPU) إلى اختلاف نطاقات حساب الخسارة (استخدم TPU خسارة المساعد فقط، بينما استخدم GPU خسارة التسلسل الكامل).

أداء الاستدلال

السياق القصير (≤2048 توكن): أظهر الـ GPU ميزة طفيفة في ذروة إنتاجية المخرجات (+6%) وفي زمن استجابة الذيل (P99 tail latency) بشكل أفضل قليلاً، وهو ما يُعزى إلى ارتفاع عرض نطاق HBM لكل شريحة وغياب عبء حشو (Padding) حاويات XLA.
السياق الطويل (≥4096 توكن): أظهر TPU v6e-8 هيمنة واضحة:
- الإنتاجية: أعلى بنسبة 66% في عدد توكنات المخرجات/ثانية عند 4096 توكن.
- زمن الوصول لأول توكن (TTFT): أسرع بـ 23.6 ضعفاً عند 4096 توكن (61 مللي ثانية مقابل 1,443 مللي ثانية) وأسرع بـ 7.1 ضعفاً عند 8192 توكن.
- القابلية للتوسع: حافظ TPU على ما يصل إلى 32 طلباً متزامناً (QPS) في السياق المتوسط، مقارنة بتشبع الـ GPU عند حوالي 8 طلبات، وذلك بفضل ذاكرة KV cache بتنسيق fp8 (التي ضاعفت السعة الفعلية) والحوسبة الإجمالية الأعلى.
التكلفة: بالنسبة لأعمال السياق الطويل، كان TPU أرخص بنسبة 41% لكل توكن مخرج.

جودة التقييم

في اختبار Verilog لتوليد الأكواد، حقق النموذج المدرب على GPU درجة pass@1 (0.697 مقابل 0.641) و pass@5 (0.814 مقابل 0.795) أعلى قليلاً. ويعزو المؤلفون هذا الفرق الطفيف إلى الاختلافات في أهداف التدريب (قناع الخسارة) والتباين في أخذ العينات العشوائية بدلاً من قدرات الأجهزة.

الأهمية والادعاءات

يزعم البحث أنه يقدم أول عرض شامل (End-to-end) لعمليات الضبط الدقيق وخدمة Gemma 4 31B على أجهزة TPU، مما يزيل فعلياً فجوة حرجة في منظومة الأدوات المفتوحة.

الجاهزية للإنتاج: يقدم العمل وصفة قابلة لإعادة الإنتاج وجاهزة للإنتاج لنشر Gemma 4 على بنية TPU التحتية، بما في ذلك إعدادات Docker المحددة، وإعدادات الشبكة (Mesh)، وسكريبتات تحويل نقاط التفتيش.
إجمالي تكلفة الملكية (TCO): خلصت الدراسة إلى أن تكوين TPU هو أرخص بـ 1.82 ضعفاً من خط مرجع GPU لعملية عمل نموذجية تشمل التدريب والخدمة. وتنتج هذه الميزة بشكل أساسي من توفير تكاليف التدريب، مع تضاعف توفير تكاليف الاستدلال بشكل كبير في تطبيقات السياق الطويل.
ملاءمة الأجهزة: يضع المؤلفون TPU كبنية تحتية مفضلة لأعمال السياق الطويل وخطوط الإنتاج الحساسة للتكلفة، مع الإقرار بمزايا الـ GPU في إنتاجية السياق القصير ونضج المنظومة (سهولة النمذجة الأولية).

يؤكد التقرير أنه على الرغم من أن الجهد الهندسي لنقل النموذج إلى JAX/Tunix ليس هيناً (يُقدر بنحو أسبوع من العمل لإعداد الشبكة، وإصلاحات التجزئة، وإعادة هيكلة المسار)، إلا أن هذه تكلفة تُدفع لمرة واحدة وتتوزع على العديد من عمليات التدريب، مما يجعل TPU بديلاً قابلاً للتطبيق ومتفوقاً للنماذج اللغوية الكبيرة واسعة النطاق.