بناء خادم استدلال بذاكرة فيديو 576 جيجابايت: سجل التشغيل

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

بناء: رف 7U · معالجين AMD EPYC 7643 (96 نواة/192 خيطًا) · ذاكرة وصول عشوائي DDR4 ECC سعة 512 جيجابايت · 6 بطاقات رسومات NVIDIA RTX PRO 6000 Blackwell Max-Q، سعة 576 جيجابايت GDDR7 · قرص تخزين NVMe بسعة 2 تيرابايت + 4 تيرابايت
تم بناؤه وتشغيله: أغسطس 2026، ورشة كنتينو، براغ · الحالة: تم التوصيل

نعتقد أن هذه المقالة أكثر فائدة. يمكن لأي شخص نسخ قائمة الأجزاء.

ما هو عليه

ست بطاقات رسومات RTX PRO 6000 Blackwell Max-Q، سعة كل منها 96 جيجابايت، على منصة EPYC Rome ثنائية المقبس مع ذاكرة ECC سعة 512 جيجابايت. 576 جيجابايت من ذاكرة الوصول العشوائي للفيديو (VRAM) في جهاز واحد ، وهو ما يكفي لاستيعاب نموذج يحتوي على 753 مليار مُعامل بدقة 4 بت مع مساحة متبقية لمليون رمز سياقي.

يُعدّ إصدار Max-Q مهمًا. فباستهلاك 300 واط لكل بطاقة بدلًا من 600 واط، يمكن وضع ست بطاقات منها ضمن نطاق حراري وكهربائي مناسب لورشة عمل، ولاحقًا لغرفة خوادم. وقد بلغ استهلاك الطاقة عند الحمل الكامل حوالي 2.9 كيلوواط ، أي ما يعادل 80% تقريبًا من استهلاك دائرة كهربائية واحدة بجهد 230 فولت/16 أمبير.

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

العيب الأول: وحدتا معالجة رسومية تعملان بهدوء بنصف السرعة

تم تشغيل النظام، وتم التعرف على جميع البطاقات الست، nvidia-smi بدا مثالياً.

اثنان منهم كانا يعملان بسرعة PCIe Gen4 x8 بدلاً من x16.

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

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

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

العيب الثاني: نمط تصحيح الأخطاء الذي لم يكن موجودًا في الذاكرة

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

لم نستبدلهم، والسبب هو الجزء المثير للاهتمام.

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

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

وهكذا بقيت الوحدات.

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

ملاحظة عملية واحدة كلفتنا بعض الوقت: هذه المنصة تستخدم معالجة الأخطاء في البرامج الثابتة أولاًلذا، تُقرأ عدادات تصحيح الأخطاء (ECC) في نظام لينكس صفرًا بغض النظر عما يحدث. يجب قراءة حالة الذاكرة من سجل أحداث وحدة التحكم في إدارة اللوحة الأساسية (BMC). إذا كنت تراقب edac ولا شيء آخر، فأنت لا تراقب شيئاً.

ما تفعله الآلة فعلياً

جميع الأرقام تم قياسها على هذا النظام المحدد، وليس من ورقة بيانات.

الحساب والاتساق

مقاسات	نتيجة
FP16 dense matmul، لكل بطاقة	291–302 تيرا فلوب (3.5% موزعة على ستة)
عرض نطاق ذاكرة الوصول العشوائي للفيديو (VRAM) لكل بطاقة	~1,471 جيجابايت/ثانية (متجانسة حتى 0.2%)
الاستدلال المتوازي للبيانات سداسي الاتجاهات	3,859 توك/ثانية كفاءة التوسع بنسبة 90.8%
يتم توزيع كل نسخة على ست وحدات معالجة رسومية.	0.45%

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

الاستدلال على النماذج الكبيرة

GLM-5.2 — 753 مليار مُعامل (40 مليار مُعامل نشط)، 4 بت، 341 جيجابايت مُخزنة عبر ست بطاقات:

الطلبات المتزامنة	1	4	16	32	48
جيل توك/	38.0	78.5	117-120	148.1	172.2

كما يقوم بتحميل سياق النموذج الأصلي المكون من 1,048,576 رمزًا على هذا الجهاز - 494 جيجابايت من ذاكرة الوصول العشوائي للفيديو، مما يترك 6.6 جيجابايت متاحة على أقل بطاقة رسومات. هذا يعمل، لكن هامش الربح ضئيل، وقد ذكرنا ذلك.

ضبط الدفعة الصغيرة المعبأة مسبقًا (-b/-ub 4096) رفعت معالجة البيانات الفورية من 403 إلى 606 توكو/ثانية، بزيادة قدرها 50% لتغيير سطر واحد. تمت إضافة فك التشفير التخميني زيادة بنسبة 53% في التدفق الأحادي لكن تكلفتها 6% على عمليات المعالجة الدفعية طويلة الأمد، لذلك يتم تمكينها لكل عبء عمل بدلاً من تمكينها بشكل عام.

حرق في

810,033 عملية حسابية على المصفوفات عبر ست وحدات معالجة رسومية عند تحميل كامل بنسبة 100%. لا توجد أخطاء حسابية. درجة حرارة قصوى 88 درجة مئوية، استهلاك طاقة مستمر 300 واط لكل بطاقة، بدون تباطؤ حراري — clocks_event_reasons اقرأ غير نشط طوال الوقت.

حيث تكون هذه الآلة ضيقة، وقد قلنا ذلك

هامش الحرارة حوالي درجتين مئويتين. بلغت درجة الحرارة القصوى 88 درجة مئوية مقابل نقطة توقف تبلغ حوالي 90 درجة مئوية، في بيئة تتراوح درجة حرارتها بين 28 و33 درجة مئوية في ورشة عمل غير مُتحكم بها في شهر أغسطس. في غرفة تقل درجة حرارتها عن 25 درجة مئوية، يكون هناك هامش حرارة مريح. أما في غرفة دافئة، فلا يوجد هامش حرارة مريح. وصلت أحمال العمل الحقيقية المستمرة إلى نفس درجات الحرارة التي تصل إليها درجات حرارة التشغيل الأولي للوقود الاصطناعي، لذا فإن هذه المشكلة لا تقتصر على الوقود الاصطناعي فقط.

العامل الحاسم هو الحد الأقصى لاستهلاك طاقة وحدة معالجة الرسومات (GPU) - ٢٦٠ واط بدلاً من ٣٠٠ واط. لم نقم بقياس تأثير ذلك على الإنتاجية في هذا الجهاز ، لذا لم نوصِ به كما لو كنا قد فعلنا ذلك. قارن أداءه مع متطلبات العمل الخاصة بك.

مجموعة البرامج محددة وهشة. لن يعمل GLM-5.2 مع vLLM أو SGLang على هذا الجيل من وحدات معالجة الرسومات - ثلاثة قيود منفصلة من المصدر. llama.cpp هو المسار الصحيح. بشكل منفصل، يتضمن تثبيت vLLM تصحيحًا محليًا يُصلح عطلًا عند التزامن مع النماذج الكمية، و هذا التصحيح لا يصمد pip install -U vllm. ثبّت نسخك.

يعني المقبس المزدوج NUMA. يتم تقسيم عرض النطاق الترددي بين المضيف والجهاز حسب المقبس: وحدات معالجة الرسومات من 0 إلى 2 على مقبس، ومن 3 إلى 5 على مقبس آخر، مع خسارة تقارب 20% لمخازن المضيف المؤقتة المخصصة على العقدة الخاطئة. ليس هذا عيبًا - إنها طبيعة النظام - ولكن عليك تثبيته مع numactl حيث يكون عرض النطاق الترددي بين المضيف والجهاز مهماً.

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

لماذا ننشر الأخطاء

تقرير التشغيل الذي يُشير إلى اجتياز جميع الاختبارات بنجاح لا يُخبرك شيئًا عن مُعدّيه. فكل جهاز بهذا التعقيد يُعاني من خلل ما عند تشغيله لأول مرة. والسؤال هو: هل سيُكتشف هذا الخلل في مختبرنا أم في خزانتك؟

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

هذا هو الغرض من عملية التشغيل.