مصفوفة قياس الأداء PyTorch 2.13: ما الذي يجب اختباره قبل ترقيات FlexAttention وCuTeDSL وtorchcomms وFSDP2

PyTorch 2.13 هو نوع الإصدار الذي يمكن أن يجعل الفريق يشعر بالتخلف قبل أن يقوم بمهمة واحدة. يحظى FlexAttention بمزيد من الاهتمام، وتهتم Apple Silicon MPS أكثر بالتطوير المحلي، ويشير CuTeDSL إلى عمل kernel ذي المستوى الأدنى، وتغيير torchcomms وFSDP2 محادثات التدريب الموزعة، ويستمر عمل الذاكرة حول طبقات مثل nn.LinearCrossEntropyLoss.

تلك القائمة مفيدة. إنها ليست خطة ترقية.

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

وينطبق نفس الانضباط على الفرق التي تفكر بالفعل في تقديم التغييرات، كما هو الحال في LLM تقديم خطط الترحيل. عزل التغيير، وقياسه، وجعل التراجع مملاً. عادة الأدلة من [مقاعد اختبار الذكاء الاصطناعي للمستند] (/en/blog/mistral-ocr-4-evidence-preserving-document-ai-test-bench-2026) تنتمي أيضًا إلى هنا: كل نتيجة مرجعية تحتاج إلى مصدر، ومعرف تشغيل، وبيئة، وأمر، وقرار.

السؤال ليس ما إذا كان الإصدار 2.13 أسرع

نادرًا ما تفشل ترقية إطار العمل لأن الميزة الرئيسية مزيفة. لقد فشل لأن الفريق يختبر مسارًا ويشحن إلى مسار آخر.

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

إليكم النسخة الواضحة: المعيار الذي لا يمكن أن يؤدي إلى التراجع هو مجرد مخطط.

يجب اختبار PyTorch 2.13 كتغيير للنظام الأساسي. وهذا يعني نفس عبء العمل، وليس عبء عمل أجمل، عبر الواجهات الخلفية التي يستخدمها الفريق بالفعل. لا تفشل أجهزة الكمبيوتر المحمولة Apple Silicon وخوادم CUDA وعمال ROCm ووظائف CPU CI والمجموعات الموزعة بنفس الطريقة. تقبل مصفوفة الاختبار المفيدة ذلك مقدمًا.

مصفوفة اختبار PyTorch 2.13 عبر الأنظمة الأساسية

{
  "matrix": "optijara-cross-platform-pytorch-2-13",
  "versions": ["current_baseline", "pytorch_2_13"],
  "backends": ["mps", "cuda", "rocm", "cpu", "distributed"],
  "gates": ["correctness", "latency", "throughput", "peak_memory", "determinism", "compile_export", "rollback"],
  "decisions": ["adopt", "isolate", "defer", "rollback"]
}

ابدأ بالتحكم

تشغيل التحكم هو المكان الذي تنقطع فيه العديد من البرامج المعيارية بهدوء.

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

ثم حافظ على الأجزاء المملة متطابقة. نفس النصوص. نفس المدخلات. نفس سياسة الاحماء. نفس نافذة القياس لا تقارن تشغيل PyTorch 2.13 الذي تم ضبطه بعناية مع خط أساس قديم لم يلمسه أحد منذ أشهر.

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

FlexAttention على MPS وCUDAيستحق FlexAttention اختبارات مبنية على أنماط الاهتمام الحقيقية للفريق. لا يكون الاهتمام المكثف كافيًا إذا كان الدافع وراء الترحيل هو سلوك متناثر أو طويل السياق. قم بتضمين الأقنعة السببية، وأنماط النوافذ المنزلقة، وأنماط الكتل المتناثرة، وأطوال التسلسل الطويلة، والدقة المختلطة، والتمريرات الخلفية. تحدد مستندات FlexAttention الرسمية سطح واجهة برمجة التطبيقات (API). يساعد دليل ملفات تعريف Hugging Face الفرق على قراءة آثار الانتباه بدلاً من الثقة في رقم إنتاجية إجمالي واحد.

في Apple Silicon، يجب أن يتجاوز اختبار MPS نجاح الاستيراد. قم بتشغيل نفس النمط المتفرق والقناع وشكل الدُفعة وطول التسلسل المخطط للعمل الفعلي. قارن مع خط الأساس MPS السابق، ومرجع CUDA أو وحدة المعالجة المركزية (CPU)، حيثما أمكن، للتأكد من صحته. انتبه للمشغلين غير المدعومين، والتراجع الصامت، وطفرات الذاكرة، والانجراف المختلط الدقة.

في CUDA، قم بإضافة عمليات التحقق العكسية الحتمية. كرر أشواط المصنفة. قارن التدرجات مع التفاوتات المتفق عليها. احتفظ بمسار SDPA القديم أو مسار الاهتمام المخصص بجانب FlexAttention حتى يأخذ المسار الجديد مكانه. إذا كان السلوك الحتمي جزءًا من متطلبات الإطلاق، فإن البوابة ليست ذات سرعة متوسطة. البوابة قابلة للتكرار تحت نفس إعدادات البذرة والدقة والواجهة الخلفية.

بوابات النواة والذاكرة والمترجم

يجب أن يجلس برنامج CuTeDSL في مسار النموذج الأولي ما لم يكن الفريق يمتلك بالفعل صيانة مخصصة للنواة. الاختبار ليس السرعة فقط. إنها ملكية. من يقوم بتصحيح الكود؟ ما هي الأجهزة المطلوبة؟ كيف سيقارنه الفريق بسلوك PyTorch القياسي؟ ما مدى سرعة تعطيله عند تغيير وضع التشغيل أو الشكل أو الدقة؟

ينتمي nn.LinearCrossEntropyLoss إلى مسار الذاكرة والصحة. قارن ذاكرة الذروة ووقت الخطوة وسلوك اللوجيستيات وسلوك الدقة المختلط وإشارات التقارب والتوافق مع مكدس التدريب. يكون فوز الذاكرة ذا قيمة فقط إذا كان مسار الخسارة لا يزال يدرب النموذج المقصود ولا ينشئ عمل تكامل جديد.

بالنسبة إلى torch.compile والتصدير، استخدم البوابات بدلاً من التفاؤل. حساب فواصل الرسم البياني. سجل ترجمة النفقات العامة. اختبر الأشكال الديناميكية الحقيقية، وليس فقط عرضًا توضيحيًا نظيفًا ذو شكل ثابت. تحقق من التصدير عندما يترك النموذج لغة Python لوقت تشغيل آخر. يعد منشور التطبيع والاندماج في 10 يوليو سياقًا معماريًا مفيدًا لأن الاندماج يمكن أن يغير حركة مرور الذاكرة وبنية النواة. لا يزال لا يلغي الحاجة إلى إثبات خاص بعبء العمل. للحصول على عدسة أوسع لقابلية النقل، قارن ذلك مع اختبار قابلية نقل الحوسبة بالذكاء الاصطناعي، حيث يجب إثبات اختيار الواجهة الخلفية في ظل قيود عملية.

الاختبارات الموزعة والاحتياطية

يحتاج تداخل torchcomms وFSDP2 إلى اختبارات النظام الموزع، وليس اختبارات مربعات الاختيار. بالنسبة إلى torchcomms، قم بقياس السلوك الجماعي وزمن الوصول وعرض النطاق الترددي ومعالجة الفشل وتوافر الواجهة الخلفية والتوافق مع أدوات الإطلاق الحالية. تأكد من أن المراقبة لا تزال تشرح ما يحدث عندما تتباطأ المهمة.

بالنسبة لتداخل FSDP2، قم بقياس وقت الخطوة، وانتظار الاتصال، وذاكرة الذروة، وحفظ نقطة التفتيش وتحميلها، ومعالجة حالة المحسن، والقياس عبر أعداد العقد التي يتم التحكم فيها. لا توافق على التداخل من خطوة واحدة سريعة. المسار الأفضل هو الذي يقوم بالتدريب، ونقاط التفتيش، والتعافي، ويترك ما يكفي من الأدلة للمشغلين لتصحيح الفشل التالي.تحافظ فحوصات ROCm ووحدة المعالجة المركزية على سلامة المسارات الاحتياطية. قد لا يقوم الفريق بتدريب أكبر نموذج له على وحدة المعالجة المركزية، ولكن وظائف وحدة المعالجة المركزية غالبًا ما تحمي اختبارات CI والتطوير المحلي واختبارات الدخان. قد تجلس ROCm في أسطول مختلط. يجب ألا يوافق نجاح CUDA فقط على أسطول يعتمد أيضًا على أجهزة الكمبيوتر المحمولة Apple Silicon، أو عمال ROCm، أو وحدة المعالجة المركزية الاحتياطية.

أخطاء ومحاذير شائعة

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

الفخاخ الأخرى أقل بريقًا. تحسب الفرق عملية الإحماء على أنها سرعة الحالة الثابتة. يبلغون عن متوسط ​​الإنتاجية لكنهم يفتقدون ذاكرة الذروة. إنهم يختبرون أطوال تسلسلية أقصر من استخدامات الإنتاج. إنهم يكررون مطالبات مذكرة الإصدار كما لو كانت تلك المطالبات ضمانات. إنهم يتخطون التراجع لأن المعيار بدا نظيفًا.

يجب كتابة التحذيرات قبل بدء التشغيل. تكلفة التنفيذ يمكن أن تفوق مكاسب معيارية صغيرة. يمكن للأجهزة وبرنامج التشغيل والدقة وشكل عبء العمل تغيير الإجابة. قد تحتاج البيانات المعيارية إلى عناصر تحكم في الخصوصية إذا كانت المطالبات أو التصنيفات أو العينات حساسة. يمكن لسلوك ذاكرة التخزين المؤقت أن يجعل عمليات التشغيل المتكررة تبدو أفضل من عملية التشغيل لأول مرة. تحدد جودة التقييم ما إذا كان انحراف الدقة مرئيًا أم لا. يمكن لواجهات برمجة التطبيقات النموذجية ومسارات kernel المخصصة إضافة أعمال صيانة لا يظهرها رقم السرعة.

قم بتأجيل اعتماد PyTorch 2.13 عندما لا يتم اختبار الأنماط المتفرقة الحرجة، أو تفشل عمليات التحقق العكسي الحتمية، أو تكون مسارات التصدير غير مدعومة، أو يكون الاسترداد الموزع هشًا، أو يتم تجاوز ميزانيات الذاكرة، أو يعتمد التراجع على البطولات اليدوية. العزلة ليست الفشل. غالبا ما يكون الجواب الكبار.

قائمة مراجعة التنفيذ وخطة القياس

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

يجب أن تسجل خطة القياس زمن الوصول p50 وp95، والإنتاجية، وذاكرة الذروة، ووقت التجميع، وفواصل الرسم البياني، والانحراف الرقمي، والتكرار الحتمي، وسلوك نقطة التفتيش، ومدة التراجع. قم بتخزين معرفات التشغيل وتفاصيل الأجهزة وإصدارات البرامج والأوامر ومعرفات شريحة مجموعة البيانات وعناوين URL المصدر وبوابات النجاح أو الفشل وملاحظات الاستنساخ.تعيين الحدود قبل إجراء الاختبارات. يجب ألا يشترك دفتر الأبحاث، والتدريب الليلي، وخدمة الاستدلال التي تواجه العملاء، ومهمة الضبط الدقيق الموزعة في عتبة واحدة. قرر ما الذي يبرر الاعتماد قبل وجود المخططات. وإلا فإن المعيار يصبح تفاوضا بعد وقوعه.

إذا كان الفريق بحاجة إلى مساعدة في تحويل ملاحظات الإصدار إلى اختبارات بنية أساسية قابلة للتكرار للذكاء الاصطناعي، فيمكن لـ Optijara المساعدة في تصميم المصفوفة، وأتمتة التقاط الأدلة، وتحويل ترقيات الإطار إلى خطط اعتماد مُقاسة. يجب أن يكسب PyTorch 2.13 عبء عمل التبني حسب عبء العمل، والواجهة الخلفية بعد الواجهة الخلفية.