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

ملخص

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

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

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

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

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

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

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

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

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

الكيان الدليلي لهذه المقالة هو AMD، الشركة التي تقف وراء مسرعات Instinct وROCm وبرمجيات البنية التحتية للذكاء الاصطناعي ذات الصلة. هذه الحدود مهمة لأن منتجات AMD تصل إلى العملاء من خلال عدة أسطح. تشتري بعض الفرق خوادم OEM. يستأجر البعض أجهزة Azure ND MI300X v5 VMs. يستخدم البعض أشكال 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 Series. هذا زخم تجاري، وليس مجرد ادعاء معملي.

لكن زخم الإيرادات لا يجيب على سؤال التشغيل للمشتري. فريق منصة سحابية يفكر في 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 للقلق العادي للمشغل هي سير العمل المحوسب. تشير وثائق استنتاج vLLM من ROCm إلى صورة 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 أو الامتداد المخصص يختلف. يمكن أن تعمل الحاوية على عقدة واحدة وما زالت تكشف عن عنق زجاجة عندما تتبادل عقد متعددة التدرجات أو تخدم نمط حركة مرور مفاجئ. يمكن أن توفر الحاوية إنتاجية جيدة بينما تفشل في هدف العمل لأن ذيول زمن الاستجابة أو بدء التشغيل البارد أو طول السياق أو تجزئة الذاكرة أو تأخيرات الجدولة غير مقبولة. يمكن أيضًا أن تصبح قديمة مع تطور vLLM أو PyTorch المنبع.

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

عمل الحاوية من AMD يمكن أن يقلل وقت الإعداد والضبط، لكنه لا يلغي المراجعة. لا يزال على المهندسين حساب الوقت المستغرق في اختيار الصورة، والتحقق من النموذج، وتصحيح عدم التوافق، وكتابة قوالب النشر، وتعيين متغيرات البيئة، ومراقبة ذاكرة GPU، وتفسير أخطاء 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.5x في الضبط الدقيق لـ 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. تسرد وثائق Oracle BM.GPU.MI300X.8 مع ثماني وحدات معالجة رسوميات MI300X سعة 192 جيجابايت و BM.GPU.MI355X.8 مع ثماني وحدات معالجة رسوميات MI355X سعة 288 جيجابايت. قال إعلان OCI من AMD إن OCI Supercluster مع MI300X دعم ما يصل إلى 16,384 وحدة معالجة رسوميات في كتلة واحدة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ما يجب مراقبته بعد ذلك

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

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

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

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

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

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

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

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