اختبار AMD لمسرعات الذكاء الاصطناعي: التشغيل القابل للقبول مرتين

ملخص

• لم تعد AMD تُقيَّم بقدرة وحدات معالجة الرسوميات Instinct على تسجيل أرقام قوية في الاختبارات العامة، بل بقدرة فرق الذكاء الاصطناعي العادية على جعل حمل عمل معين يُقبل مرتين: مرةً في التحقق، ومرة أخرى بعد أن يغير التحديث التالي لبرنامج التشغيل أو إطار العمل أو النموذج أو النواة أو صورة السحابة أو حدث الاسترداد البيئةَ.
• لقد أصبحت ROCm منصة إنتاج حقيقية، مع مصفوفات توافق عامة، ومسارات حاويات vLLM و PyTorch، وفحوصات سلامة، وإرشادات نقل HIP، وطلبات MLPerf، وطرق نشر Azure/OCI. ويكشف هذا النضج أيضًا عن العمل الخفي: تثبيت الإصدارات، وتغطية النوى، واختبارات التجميع، وضبط خاص بالنموذج، وإدارة الحصص، والتراجع، والمراجعة الخبيرة.
• لا تقتصر الحالة التجارية على ذاكرة أرخص أو رموز أكثر لكل دولار. يُظهر إيداع AMD للربع الأول من عام 2026 زخمًا في قطاع مراكز البيانات وطلبًا على Instinct MI350، لكن لا يزال على المشترين مقارنة التكلفة الإجمالية لكل تشغيل مقبول للمسرع مقابل CUDA، وخدمات النماذج السحابية المدارة، والبرمجيات كخدمة القائمة، وتسويات وحدة المعالجة المركزية/وحدة معالجة الرسوميات مفتوحة المصدر، والنقل الداخلي، وتقليل المهمة.
• نقاط المراقبة المفيدة هي: انحراف التوافق، وحدود سعة السحابة، والفجوات بين الاختبارات المعيارية والإنتاج، والنوى المفقودة، وتراجعات إطار العمل، وتأخير التصحيح، ومسؤولية تكامل المصنّع الأصلي، والرجوع إلى CUDA. فرصة AMD كبيرة لأن المسرعات الغنية بالذاكرة والمكدس المفتوح يمكن أن تقلل الاعتماد على مورد واحد؛ أما عبئها فهو أن موثوقية الإنتاج تُقرر في أكثر أجزاء المكدس افتقارًا إلى الجاذبية.

التشغيل المقبول، لا عنوان الشريحة، هو وحدة القيمة

السؤال الحقيقي لـ AMD ليس ما إذا كان مسرع Instinct يمكنه تشغيل نموذج مثير للإعجاب مرة واحدة. فهو يستطيع ذلك. لدى AMD أدلة عامة على الأجهزة والبرمجيات والاختبارات المعيارية كانت تبدو بعيدة قبل بضع سنوات فقط: مسرعات سلسلة MI300X و MI350، وإصدارات ROCm مع دعم إطار العمل الحالي، ومسارات vLLM والتدريب في حاويات، وطلبات MLPerf عامة، وأشكال Azure و Oracle Cloud، وطبقة برمجيات ذكاء اصطناعي مؤسسية متنامية. الشركة ليست واقفة خارج سوق البنية التحتية للذكاء الاصطناعي تطلب الانتباه.

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

إذا كانت المهمة تدريبًا، يشمل القبول دليل التقارب أو الجودة المستهدفة، واستقرار مسار البيانات، وسلوك نقاط التفتيش، والاتصال الجماعي، وسلوك إعادة التشغيل، ووقت المشغل.

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

أقوى حجة سوقية لـ AMD هي أن العديد من مشتري الذكاء الاصطناعي يريدون خيارات أوسع في المسرعات. يريدون هامشًا في الذاكرة، وضغطًا في الأسعار، وبدائل في التوريد، وتقليلًا للارتباط بمورد واحد، ومسارات برمجية لا تجعل كل حمل عمل جاد يعتمد على نفس المكدس المغلق.تصف صفحة ROCm من AMDمكدسًا برمجيًا مفتوحًا يشمل برامج تشغيل وأدوات تطوير وواجهات API لبرمجة وحدة معالجة الرسوميات من النوى منخفضة المستوى إلى تطبيقات المستخدم النهائي.تقدم صفحة سلسلة MI350عائلة مسرعات غنية بالذاكرة، حيث يوفر MI350X و MI355X ما يصل إلى 288 غيغابايت من ذاكرة HBM3E وسرعة نقل ذاكرة نظرية قصوى تبلغ 8 تيرابايت/ثانية، ويستهدف MI350P النشر عبر PCIe داخل البنى التحتية المؤسسية التقليدية.

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

حدود AMD هي المكدس الخاص بالمسرع والبرمجيات، وليس كل نتيجة سحابية

الكيان الدليلي لهذه المقالة هو AMD، الشركة التي تقف وراء مسرعات Instinct و ROCm وبرمجيات البنية التحتية للذكاء الاصطناعي ذات الصلة. هذه الحدود مهمة لأن منتجات AMD تصل إلى العملاء عبر واجهات متعددة. بعض الفرق تشتري خوادم OEM. بعضها تستأجر أجهزة Azure ND MI300X v5 VMs. وبعضها يستخدم أشكال bare-metal GPU من Oracle Cloud Infrastructure. وبعضها يقيم AMD Developer Cloud أو سحابات الشركاء. وبعضها يتلقى أجهزة AMD عبر منصة مدارة أو مزود خدمة نماذج. في كل حالة، يعتمد حمل العمل المقبول على مكونات AMD ومكونات غير AMD في نفس الوقت.

هذه الحدود تمنع خطأين. الأول هو نسب الفضل لـ AMD في كل عملية لمزود السحابة. إذا قامت صورة Azure VM بتثبيت برامج التشغيل بشكل نظيف، فإن تجميع Microsoft ودعمها جزء من النتيجة. إذا قامت مجموعة OCI بتوسيع اختبار معياري عبر 64 عقدة، فإن شبكة Oracle وتخزينها وعملياتها المعدنية وإدارتها للجدولة جزء من النتيجة. إذا كشف نظام OEM عن البرامج الثابتة الصحيحة وغلاف التبريد، فإن تكامل بائع الخادم جزء من النتيجة. توفر AMD السيليكون والبرمجيات الأساسية، لكن العميل يقبل النظام.

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

تُظهر إيداعات AMD العامة لماذا تسعى الشركة بقوة لهذا السطح. فينتائج الربع الأول من عام 2026، أعلنت AMD عن إيرادات بقيمة 10.3 مليار دولار وقالت إن إيرادات قطاع مراكز البيانات بلغت 5.8 مليار دولار، بزيادة 57% على أساس سنوي، مدفوعة بمعالجات EPYC والزيادة المستمرة في شحنات وحدات معالجة الرسوميات Instinct. وتصفاستمارة 10-Q للربع الأول 2026نمو مراكز البيانات بأنه مدفوع بشكل أساسي بالجيل الخامس من معالجات EPYC ووحدات معالجة الرسوميات من سلسلة Instinct MI350. هذا زخم تجاري، وليس مجرد ادعاء مخبري.

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

وبالتالي فإن الحدود القانونية والعلامة التجارية عملية. AMD هي الموضوع لأنها تتحكم في استراتيجية Instinct و ROCm. لكن حمل العمل المقبول هو سلسلة. إنها ليست شريحة AMD بمعزل عن غيرها، وليست ادعاءً لامعًا لمزود سحابة للذكاء الاصطناعي بمعزل عن غيره.

نضج ROCm مرئي في الأعمال الورقية

إحدى علامات نضج مكدس المسرع هي الوثائق المملة. لدى ROCm الآن ذلك بقدر مفيد.مصفوفة التوافقمن AMD، المحدثة في أواخر مايو 2026 في النسخة التي روجعت لهذه المقالة، ليست جذابة. إنها بالضبط نوع القطعة الأثرية التي تحتاجها فرق الإنتاج: توافق إصدار تلو الآخر عبر أنظمة التشغيل، ووحدات معالجة الرسوميات، ومكونات إطار العمل. تذهب صفحةمتطلبات نظام Linuxإلى أبعد من ذلك، بتفصيل مجموعات الأجهزة/أنظمة التشغيل المدعومة وغير المدعومة وتحذر من أن وحدات معالجة الرسوميات غير المدعومة قد تشغل بعض مسارات وقت تشغيل HIP بينما مكتبات ROCm المبنية مسبقًا ليست مدعومة رسميًا ويمكن أن تسبب أخطاء وقت التشغيل.

هذه الوثائق تغير كيف يجب الحكم على AMD. قبل خمس سنوات، ربما سأل مشترٍ ما إذا كانت ROCm موجودة بشكل مفيد لأعمال الذكاء الاصطناعي. في عام 2026، السؤال الأفضل هو ما إذا كانت التركيبة المحددة للفريق داخل الظرف المدعوم وما إذا كان يمكنها البقاء هناك بمرور الوقت. MI300X و MI325X و MI350X و MI355X ليست تسميات قابلة للتبادل. دعم Ubuntu و RHEL و Debian و Oracle Linux و Rocky Linux و SLES يمكن أن يختلف بالإصدار ووحدة معالجة الرسوميات. TensorFlow و PyTorch و JAX و Triton و RCCL و hipBLASLt ومكونات أخرى تتحرك بإيقاعها الخاص. يحتاج التشغيل المقبول إلى تحويل تلك المصفوفة إلى عقد نشر.

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

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

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

الحاويات تقلل الاحتكاك، لكنها لا تلغي القبول

أكثر إجابة عملية من AMD لقلق المشغلين العاديين هي سير العمل بالحاويات. تشيروثائق استدلال ROCm vLLMإلى صورة Docker لـ vLLM مفعلة بـ ROCm لاستدلال نماذج اللغة الكبيرة على وحدات معالجة الرسوميات MI355X و MI350X و MI325X و MI300X. تصف حاوية تدمج ROCm و PyTorch و vLLM مع تحسينات لوحدات معالجة الرسوميات AMD Instinct لمراكز البيانات. تسردوثائق تدريب PyTorchعائلات نماذج محسنة مسبقًا عبر Llama و OpenAI و DeepSeek و Qwen و Stable Diffusion و Flux و NCF و DLRM. تعطيوثائق Megatron-LMمسار حاوية محدد الإصدار مع مكونات ROCm و PyTorch و Transformer Engine و Flash Attention و hipBLASLt و Triton و RCCL.

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

الحاوية لا تزال ليست شهادة القبول. يمكن تحسين حاوية لنموذج موثق وتفشل مع نموذج العميل بسبب اختلاف الهيكلية أو طول التسلسل أو طريقة التكميم أو المحلل اللغوي أو المسار متعدد الوسائط أو استراتيجية KV-cache أو الامتداد المخصص. يمكن أن تعمل حاوية على عقدة واحدة وتكشف عن عنق زجاجة عندما تتبادل عدة عقد التدرجات أو تخدم نمط حركة مرور متقطع. يمكن أن تقدم حاوية إنتاجية جيدة بينما تفشل في هدف العمل لأن ذيول الكمون أو البدايات الباردة أو طول السياق أو تجزئة الذاكرة أو تأخيرات الجدولة غير مقبولة. كما يمكن أن تصبح قديمة مع تطور vLLM أو PyTorch الأساسي.

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

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

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

الاختبارات المعيارية مفيدة عندما تُعامل كدليل قبول، لا قدر

أدلة الاختبارات المعيارية العامة الآن قوية بما يكفي بحيث لا يمكن تجاهلها. قالت MLCommons إن جولةMLPerf Training v6.0ضمت 24 منظمة مقدمة، بما فيها AMD و Azure و Dell و HPE و NVIDIA و Oracle و Supermicro وغيرها. هذا الاتساع مهم. MLPerf ليست شريحة خاصة بشروط غير مسماة. إنها أدلة اختبار معياري محكومة بقواعد، وتقيس اختبارات التدريب الأنظمة الكاملة التي تنقل النماذج إلى مقياس جودة مستهدف.

مناقشة AMD الخاصة لـMLPerf Training v6.0أكثر تحديدًا. تقول AMD إن منصة MI355X أظهرت تحسنًا جيليًا بمقدار 3.5 أضعاف في ضبط Llama 2-70B الدقيق من أول تقديم بـ MI300X إلى تقديم MI355X، وأن MI355X جاء ضمن 5% من NVIDIA B200 في ضبط Llama 2-70B الدقيق وضمن 6% في تدريب Llama 3.1-8B المسبق في مقارنات MLPerf Training 6.0 المذكورة. وتقول AMD أيضًا إن الجولة تضمنت أول تقديم تدريب متعدد العقد لها و10 شركاء في النظام البيئي يقدمون على منصات AMD Instinct.

مناقشة Oracle العامة لتقديمها FLUX.1 في MLPerf Training v6.0 تضيف نوعًا آخر من الأدلة. أبلغت Oracle عن وقت تدريب محقق قدره 74.44 دقيقة على 512 وحدة معالجة رسوميات AMD Instinct MI300X عبر 64 عقدة OCI BM.GPU.MI300X.8، مع وصول جميع المحاولات العشر للجودة المستهدفة. هذا ليس نشرًا مؤسسيًا عاديًا، وليس بيانًا شاملًا عن كل عميل. لكنه ذو معنى لأنه يختبر أكثر من مجرد العمليات الحسابية لوحدة معالجة رسوميات واحدة. إنه يشمل التدريب الموزع، وشبكات الكتلة، ونوى ROCm، ووضع البيانات، وتنسيق العقد، والمحاولات المتكررة.

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

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

بعبارة أخرى، يجب أن تجعل MLPerf المشترين أكثر صرامة، لا أكثر استرخاءً. إنها تثبت أن AMD تنتمي إلى التقييمات الجادة. إنها لا تثبت أن المشتري يمكنه تخطي التقييم.

الوصول السحابي يحول مسألة الأجهزة إلى مسألة سعة ومسؤولية

التوفر السحابي هو أسرع طريق للعديد من الفرق لتقييم AMD، لكنه يغير شكل المخاطرة. أعلنت AMD في عام 2024 أنAzure ND MI300X v5 VMsكانت متاحة بشكل عام وأن Microsoft استخدمت أجهزة افتراضية مدعومة بـ MI300X و ROCm لأحمال عمل GPT. تنشر Microsoft بشكل منفصلدليل برنامج تشغيل Linux لـ Azure ND MI300X v5، يغطي تثبيت صورة السوق الموصى بها وسيناريوهات تثبيت/ترقية Ubuntu. تدرج وثائق OracleBM.GPU.MI300X.8بثماني وحدات معالجة رسوميات MI300X بسعة 192 غيغابايت و BM.GPU.MI355X.8 بثماني وحدات MI355X بسعة 288 غيغابايت. وقال إعلان AMD لـ OCI إن OCI Supercluster مع MI300X دعم ما يصل إلى 16,384 وحدة معالجة رسوميات في كتلة واحدة.

هذه إشارات توفر كبيرة. كما أنها تظهر لماذا لا يجب تقييم AMD كما لو كان العميل يشتري شريحة منفردة. يوفر مزود السحابة شكل النسخة، والصورة الأساسية، وعملية الحصص، والشبكة، والتخزين، وسير عمل الدعم، والتوفر الإقليمي، وجدول الصيانة، والاستجابة للحوادث. توفر AMD المسرع ومكدس ROCm الذي يجب أن يعمل داخل تلك البيئة. يوفر العميل حمل العمل، والبيانات، والوصول إلى النموذج، والنشر، والاختبارات، ومعايير القبول.

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

لذلك يجب أن يشمل حمل العمل المقبول دليل السعة. هل يمكن للفريق الحصول على الشكل في المنطقة التي تسمح بها متطلبات البيانات والامتثال بالتشغيل؟ هل يمكنه حجز سعة كافية للإنتاج أم فقط اختبارات دفعية؟ هل يمكنه إعادة التشغيل على منطقة أو مزود آخر إذا اختفت الحصة؟ هل يحتاج حمل العمل إلى bare metal أو عزل VM أو Kubernetes أو Slurm أو منصة خدمة نماذج مدارة؟ ما هو الرجوع إذا لم تكن سعة AMD متاحة أثناء حادث أو نافذة إطلاق؟

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

تكلفة النقل هي جزء السعر الذي لا يظهر في عرض التسعير

أكثر تحديات AMD مباشرة لبرمجيات المسرع القائم هو قابلية نقل HIP و ROCm. يصفدليل نقل HIPمن AMD HIP كواجهة برمجة تطبيقات وقت تشغيل بلغة C++ ولغة نواة لوحدات معالجة الرسوميات من AMD تسمح للمطورين بتحويل كود CUDA ليعمل على وحدات معالجة الرسوميات من AMD، ويوصي بأدوات مثل HIPIFY بالإضافة إلى النقل والاختبار التدريجي. هذا طريق مفيد للتطبيقات التي لديها كود GPU لا يمكنها الاعتماد ببساطة على دعم مستوى إطار العمل.

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

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

يمكن أن يحدث العكس أيضًا. قد يبالغ فريق في مشكلة النقل لأنه يتذكر فجوات ROCm القديمة أو آلام وحدة معالجة الرسوميات الاستهلاكية. إذا كان حمل العمل استدلالًا سائدًا لـ Llama أو Qwen عبر حاوية ROCm vLLM موثقة، أو وصفة تدريب مدعومة على أجهزة Instinct، فقد يكون العمل الإضافي متواضعًا. إذا استخدم التطبيق مسارات إطار عمل قياسية واستطاع الفريق تثبيت صورة معروفة بأنها جيدة، يمكن تقييم AMD بسرعة. إذا كان العنق الزجاجة الرئيسي هو سعة الذاكرة بدلاً من كود CUDA الغريب، فقد ينتج ملف تعريف ذاكرة Instinct ميزة تشغيلية حقيقية.

المقارنة الصحيحة ليست «AMD مقابل NVIDIA» بشكل مجرد. إنها التكلفة لكل تشغيل مقبول لمهمة مسماة. قارن مسار AMD بالبقاء على CUDA، أو استخدام مزود سحابة/نموذج مدار، أو تقليل حجم النموذج، أو استخدام نموذج مفتوح المصدر على السعة الحالية، أو شراء سير عمل SaaS قائم، أو بناء تنسيق داخلي، أو القيام بأقل من المهمة. اشمل الوقت الهندسي، وعقود الدعم، والالتزامات السحابية، والتشغيلات الفاشلة، وإعداد بيانات الاختبار، وقابلية الملاحظة، ومراجعة النموذج، والتراجع، وتغطية الحوادث، وتكلفة الخروج.

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

عمل الموثوقية يبدأ قبل النموذج

تحتاج أحمال عمل المسرع المقبولة إلى فحوصات ما قبل التشغيل. يقولإرشاد اختبار سلامة النظاممن AMD إن الفرق يجب أن تتحقق من أن أجهزة AMD مكونة بشكل صحيح وتعمل بأداء أمثل قبل تشغيل أحمال عمل الذكاء الاصطناعي، ويشير إلى ROCm Validation Suite واختبارات RCCL و BabelStream و TransferBench. هذا ليس عملًا ورقيًا. إنه كيف يتجنب الفريق الخلط بين مشكلة نموذج وعقدة معطلة، أو IOMMU مكون بشكل خاطئ، أو عرض نطاق ذاكرة ضعيف، أو اتصال بيني سيء، أو مشكلة اتصال جماعي.

في الإنتاج، تصبح هذه الطبقة أكثر أهمية لأن أنماط الفشل غامضة. إذا تباطأت مهمة تدريب، فهل السبب ROCm، أو وحدة معالجة رسوميات فاشلة، أو رابط متدهور، أو تباين تخزين، أو عنق زجاجة محمل بيانات، أو سلوك حراري، أو تأثيرات الجار المزعج في السحابة، أو تغيير نموذج، أو نواة إطار عمل جديدة؟ إذا ارتفع كمون الاستدلال، فهل السبب التجميع، أو ضغط KV-cache، أو شكل الطلب، أو التحليل اللغوي، أو تجزئة الذاكرة، أو وضع المجدول، أو سلوك الساعة، أو التسجيل، أو الشبكة، أو تراجع في مكدس الخدمة؟ بدون اختبارات السلامة والخط الأساسي، يتجادل الفريق بالآراء.

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

يجب أن يشمل اختبار القبول التشغيلي خمس طبقات على الأقل. أولاً، سلامة الأجهزة: RVS، وعرض نطاق الذاكرة، ورؤية وحدة معالجة الرسوميات، وسلامة الحرارة/الطاقة. ثانيًا، الاتصال: صحة وأداء تجميع RCCL لحجم العقدة أو الكتلة. ثالثًا، إطار العمل: PyTorch أو vLLM أو Megatron-LM أو المكدس المختار تحت إصدارات مثبتة. رابعًا، حمل العمل: النموذج الفعلي ونمط البيانات، ليس فقط عينة بائع. خامسًا، الاسترداد: إعادة التشغيل من نقطة تفتيش، والعودة إلى صورة معروفة بأنها جيدة، وتفريغ عقدة، وإعادة إنتاج طلب فاشل، وتوثيق من يتصرف عندما يظهر الخطأ.

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

مهمة الإنتاج هي القبول المتكرر. المنصة التي يمكنها جعل تشغيل واحد يعمل مثيرة للاهتمام. المنصة التي يمكنها جعل نفس فئة التشغيل مقبولة بعد التحديثات والفشل وتغييرات الموظفين قيّمة.

برمجيات الذكاء الاصطناعي المؤسسية تغير وعد المبيعات لكن ليس المقياس

تحاول AMD الصعود في المكدس. يتم وضعAMD Enterprise AI Suiteكرابط بين أطر عمل الذكاء الاصطناعي مفتوحة المصدر ونماذج الذكاء الاصطناعي التوليدي مع منصة Kubernetes جاهزة للمؤسسات. تهدف AMD Inference Microservices والمكدسات المرجعية إلى تقليل المسافة بين الأجهزة المعدنية وخدمة AI عاملة. هذا ضروري استراتيجيًا. مع انتقال البنية التحتية للذكاء الاصطناعي من مختبرات النماذج النخبوية إلى المؤسسات العادية، يريد المشترون أجزاءً خامًا أقل وأنظمة قابلة للنشر أكثر.

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

فرصة AMD هي تقديم سير العمل هذا بأسس مفتوحة المصدر وتقليل للارتباط. إذا جعلت Enterprise AI Suite و AIMs وحاويات ROCm وتكامل Kubernetes البنية التحتية لـ AMD أسهل للقبول، يمكن للشركة المنافسة على المقياس التشغيلي بدلاً من مقارنة المكونات الخام. قد لا يهتم فريق المنصة بأي نواة قدمت تسريعًا إذا كان يمكن نشر الخدمة ومراقبتها وترقيتها واستردادها باحتكاك أقل من المتوقع.

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

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

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

الحالة الاقتصادية يجب أن تحسب الرجوع

الرجوع ليس تشاؤمًا بالفشل. إنه جزء من السعر. على فريق يتبنى AMD للبنية التحتية للذكاء الاصطناعي أن يقرر ما يحدث عندما يفشل حمل العمل في القبول. هل يعود إلى CUDA؟ هل يشغل نموذجًا أصغر؟ هل ينتقل إلى API مدارة؟ هل يبقي مسار CPU للعمل الدفعي؟ هل يستخدم AMD للتقييم و NVIDIA للخدمة الحساسة للكمون؟ هل يقسم الحركة حسب عائلة النموذج؟ هل يؤخر الإنتاج حتى تهبط نواة مفقودة؟

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

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

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

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

تفوز AMD فقط عندما يتغلب مسارها على تلك البدائل بعد إدراج العمل الخفي. هذا معيار أشد من «أرخص من المسرع القائم». إنه أيضًا معيار أفضل لـ AMD، لأنه يحدد أين يمكن للشركة أن تتحسن: مصفوفات الدعم، والحاويات، وتغطية النماذج، وأدوات التصحيح، والتوفر السحابي، والمكدسات المرجعية المؤسسية، وقابلية استنساخ الشريك، والإثبات الخاص بحمل العمل.

ما يجب مراقبته تاليًا

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

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

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

رابعًا، قابلية استنساخ الشريك. مناقشة AMD لشركاء النظام البيئي في MLPerf مهمة لأنها تشير إلى ما وراء مختبر مرجعي واحد. كلما زادت قدرة Dell و HPE و Supermicro و Cisco و Oracle و Azure وغيرهم من الشركاء على استنساخ نتائج مقبولة تحت ظروف موثقة، كلما قل شعور تبني AMD كعمل متخصص. العكس صحيح أيضًا: إذا اعتمدت النتائج على تكوين واحد مضبوط بعناية، فسيسعر المشترون العاديون الاعتماد على خبير.

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

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

الاستنتاج ليس أن AMD غير جاهزة. بل أن AMD جاهزة بما يكفي لتُقيم بجدية وتشغيليًا. هذا معيار أعلى من اختبار معياري رئيسي وعلامة أفضل للشركة. لم تعد Instinct و ROCm بحاجة إلى أن يؤمن السوق بمصدر ثانٍ نظري. إنهما بحاجة إلى عملاء يثبتون، حمل عمل تلو الآخر، أن المصدر الثاني يمكن قبوله وصيانته ودفع ثمنه.

بالنسبة لـ AMD، مهمة الإنتاج هي الثقة المتكررة. لدى الشركة أجهزة مسرع، ومكدس برمجيات مرئي، وأدلة اختبارات معيارية عامة، وطرق سحابية. الدليل التالي أقل سينمائية: فريق يعيد تشغيل نفس حمل العمل بعد تحديث، ويرى نفس النتيجة المقبولة، ويعرف لماذا نجح، ويعرف ماذا يفعل إذا فشل، ويمكنه أن يظهر أن التكلفة الإجمالية لا تزال تتغلب على البديل.