نشرت Google Cloud معيارًا يقارن بين أحمال العمل الخاصة بالتصنيف والتوليد على TPU v6e في 15:36 UTC في 4 سبتمبر. وخلاصته الأبرز: "بالنسبة لمهام التوليد ذات الكثافة العالية في مرحلة decode، يصل نموذج Gemma 3 27B إلى حد أداء صارم بعد 64 مستخدمًا متزامنًا، ليتسطح عند مضاعف إنتاجية مُطبَّع يبلغ 4.12x عند 128 مستخدمًا. وعلى النقيض، يتوسع نموذج 12B إلى مضاعف يبلغ 8.19x."
التحفظ الوارد لاحقًا
"عند مستويات التزامن القصوى (مثل 128 مستخدمًا)، قد تلاحظ طفرات شاذة رياضيًا في متوسط الإنتاجية. … في ظل قيود الموارد الشديدة، يمكن أن يؤدي سوء ضبط --max-num-seqs أو --max-model-len إلى انقطاعات صامتة في الطلبات، أو مهلات اتصال لدى العميل، أو حالات OOM في عقدة عامل GKE. عندما تنتهي هذه الطلبات الفاشلة فورًا، فإنها تقصر مدة الجلسة زيفًا وتقوم بتضخيم مقاييس الإنتاجية بشكل اصطناعي. تمثل نقاط بيانات 128 مستخدمًا في هذه المعايير الحد الأقصى المطلق لاستقرار العنقود ويجب اعتبارها سقفًا لا مقياسًا إنتاجيًا مستدامًا."
ما تقوله الصفوف الموثوقة
يقرأ جدول التوليد عبر 16 و32 و64 و128 مستخدمًا 1.00x / 1.98x / 2.96x / 8.19x بالنسبة إلى Gemma 3 12B، و1.05x / 1.97x / 4.00x / 4.12x بالنسبة إلى 27B. وعند 64 مستخدمًا متزامنًا — وهو آخر صف لا يتبرأ منه المنشور — يكون النموذج الأكبر هو الأسرع، وهو عكس ما يقوله العنوان. إن سردية "حد الأداء" بأكملها هي مقارنة بين رقمين من الصف الذي تم التنصل منه.
لا شيء هنا قياس مطلق
كل خلية هي مضاعف لـ Gemma 3 12B عند 16 مستخدمًا، في جدول يحمل عنوان عمود "Throughput (req/s)". لا يوجد أي رقم مطلق للطلبات في الثانية، ولا أي رقم للتكلفة — في منشور تبدأ جملته الأولى بالحديث عن اقتصاديات الوحدة. والإعداد هو مجموعة عقد TPU v6e أحادية المضيف في طوبولوجيا شرائح 2x2 على GKE Autopilot، مع الخدمة عبر vLLM بواسطة tpu-inference، عند max-model-len=128000، max-num-batched-tokens=8192، max-num-seqs=512.
ما يخطئه التأطير المتداول
سيُقتبس هذا على أنه "TPU v6e يحقق 8x". لكنه مضاعف مُطبَّع، على عقدة واحدة، وعلى مكدس خدمة واحد، وعند مستوى تزامن يصفه الناشر بأنه غير مستقر وربما شابته أخطاء بسبب الطلبات المهملة. المنشور صريح على نحو غير معتاد — فإخلاء المسؤولية موجود هناك بلا مواربة — وهذه الصراحة تقع في الفقرة التي لا يصل إليها أحد. وجدول التصنيف، الذي تأتي قممه عند 6.04x-6.37x من صف 128 مستخدمًا نفسه، يحمل المشكلة ذاتها.