دراسة حالة: محطة عمل الذكاء الاصطناعي بأربع بطاقات RTX 4090

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

تم تشغيل المشروع وتسليمه في أبريل 2026. تم إجراء معايير التشغيل في 2026-04-10.

لماذا أربع بطاقات رسومات RTX 4090؟

كانت متطلبات عبء العمل واضحة منذ البداية: تشغيل نظام LLM مُكمّم بحجم 70 مليار بت بزمن استجابة مقبول للطلب الواحد، وتلبية الطلبات المتزامنة ضمن فريق بحث صغير، والاحتفاظ بكل شيء محليًا لأسباب تتعلق بالتحكم في البيانات. وكان السؤال هو: كم عدد وحدات معالجة الرسومات (GPUs) وما نوعها؟

يستهلك نموذج 70B في INT4 (AWQ أو GGUF Q4_K_M) ما يقارب 38-40 جيجابايت من ذاكرة الوصول العشوائي للفيديو (VRAM) عمليًا. هذا يُلغي تمامًا حلول وحدة معالجة الرسومات الواحدة - حتى بطاقة RTX 4090 بسعة 24 جيجابايت لا تستطيع استضافة النموذج بمفردها. أنت بحاجة إلى وحدتي معالجة رسومات على الأقل، ويفضل أربع، لكي يتوفر لدى خدمة Tensor المتوازية في vLLM مساحة كافية لذاكرة التخزين المؤقت KV.

توفر أربع بطاقات RTX 4090 سعة إجمالية قدرها 96 جيجابايت من ذاكرة الوصول العشوائي للفيديو (VRAM). وهذا يكفي لتحميل نموذج Llama 3.3 70B AWQ INT4 مع gpu_memory_utilization=0.80 مع الحفاظ على مساحة تخزين مؤقتة كافية للقيم والمفاتيح لمعالجة الطلبات المجمعة. كما يوفر ذلك قدرة حسابية هائلة - 4 × 128 شريحة متعددة الوحدات تعمل في وقت واحد - وهو أمر بالغ الأهمية لسرعة المعالجة الفورية.

كان البديل المُقترح هو أربع بطاقات رسومات RTX Pro 6000 Blackwell، والتي توفر 384 جيجابايت من ذاكرة الوصول العشوائي للفيديو (VRAM) بإجمالي 96 جيجابايت لكل منها. هذا مستوى مختلف تمامًا: ذاكرة VRAM أكبر من حاجة أي نموذج بحجم 70 مليار، مما يجعلها مناسبة لتشغيل نماذج كبيرة متعددة في وقت واحد أو استضافة نماذج بحجم 200 مليار أو أكثر بتقسيم معقول. بالنسبة لهذا الحمل - نموذج رئيسي واحد، دفعة صغيرة متزامنة، ضمن ميزانية محطة عمل واحدة - ستبقى هذه السعة الإضافية غير مُستغلة، ويكون فرق التكلفة كبيرًا. لذلك، كانت أربع بطاقات رسومات RTX 4090 هي الحل الأمثل لحالة الاستخدام المذكورة.

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

أحد القيود المعمارية التي يجب ذكرها مسبقًا: بطاقات RTX 4090 لا تدعم تقنية NVLink. يتم التواصل بين وحدات معالجة الرسومات (GPU) عبر PCIe من نظير إلى نظير. هذا الأمر مهم للاستدلال المتوازي باستخدام الموترات (المذكور في قسم الاختبارات المعيارية) ويستحق فهمه قبل الطلب. انظر N03 للحصول على شرح كامل لأهمية تقنية NVLink ومتى لا تكون مهمة.

مواصفات الأجهزة

بعض الملاحظات حول الخيارات:

وحدة المعالجة المركزية. معالج EPYC 7542 هو شريحة من جيل Rome تضم 32 نواة وذاكرة تخزين مؤقتة من المستوى الثالث (L3) بسعة 128 ميجابايت موزعة على 8 وحدات CCD. بالنسبة لمحطة عمل استدلالية، يُعد هذا العدد من النوى كبيرًا جدًا، فلن تتمكن من استغلال 64 خيطًا بالكامل في الاستدلال. تكمن ميزته في عدد مسارات PCIe المتاحة: يوفر معالج Rome EPYC 128 مسار PCIe 4.0 من وحدة المعالجة المركزية، مما يسمح بتركيب أربع وحدات معالجة رسومية x16 كاملة على هذه المنصة دون مشاركة المسارات أو تقسيمها. بطاقة RTX 4090 هي جهاز PCIe 4.0 x16؛ أنت بحاجة إلى أربعة منافذ x16 كاملة، وهذا ما يوفره لك معالج EPYC. انظر W02 للحصول على تفاصيل طوبولوجيا المسار.

الرامات " الذاكرة العشوائية في الهواتف والحواسيب. جاء النظام مزودًا بذاكرة DDR4 ECC LRDIMM سعة 512 جيجابايت، متجاوزًا بذلك السعة المحددة أصلاً وهي 256 جيجابايت. تُعدّ ذاكرة النظام الإضافية مفيدة للغاية هنا: إذ يتم تحميل النماذج من NVMe عبر ذاكرة النظام قبل نقلها إلى ذاكرة الفيديو، وبالنسبة للنماذج الأكبر حجمًا أو عند التبديل بين النماذج، فإن سعة 512 جيجابايت تعني إمكانية تخزين مجموعات أوزان نماذج متعددة في ذاكرة النظام في وقت واحد وتجنب عمليات قراءة NVMe المتكررة.

NVMe. تُخزَّن بيانات النموذج (2 تيرابايت) على قرص PCIe 4.0 NVMe عالي السرعة. تُعدّ سرعة القراءة المتسلسلة عاملاً مهماً عند التحميل: إذ يستغرق تحميل ملف نموذج بحجم 38 جيجابايت بسرعة قراءة متسلسلة تبلغ 4,589 ميجابايت/ثانية حوالي 8-10 ثوانٍ. وتؤكد أوقات التحميل المقاسة ذلك: فقد حمّل ملف llama.cpp ملف GGUF بحجم 70 بايت Q4_K_M في 10.8 ثانية؛ بينما استغرق برنامج vLLM (الذي يُنشئ أيضًا رسوم CUDA البيانية عند التحميل) 95 ثانية.

مزود طاقة مزدوج. يستخدم الهيكل وحدتي تزويد طاقة ATX. هذا نظام توزيع طاقة مُجزأ: تُغذي كل وحدة تزويد طاقة جزءًا من النظام - عادةً وحدتي معالجة رسومية ومكونات اللوحة المرتبطة بهما. في حال تعطل إحدى وحدتي تزويد الطاقة، ستفقد وحدات المعالجة الرسومية المتصلة بها. هذا ليس نظام N+1 احتياطيًا؛ بل هو ترتيب لسعة الطاقة، وليس ترتيبًا للتحويل التلقائي في حالة الأعطال. بالنسبة لأنظمة الإنتاج التي يكون فيها وقت التشغيل شرطًا تعاقديًا، يُعد هذا التمييز مهمًا. انظر W04 للاطلاع على مناقشة كاملة حول حجم وحدة تزويد الطاقة.

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

كومة البرمجيات

بيئة بايثون موجودة في /home/logic/llm-env/نماذج على NVMe في /mnt/nvme/models/.

نتائج التشغيل

خط الأساس لحسابات وحدة معالجة الرسومات

الاختبار الأول دائمًا هو الحساب الخام: ضرب المصفوفات عند FP16 (مسار Tensor Core) وFP32. هذا يؤكد أن البطاقات تعمل بشكل صحيح ويوفر خط أساس للحساب للمقارنة مع المواصفات الاسمية.

للمقارنة: تبلغ ذروة الأداء النظري لوحدة معالجة Tensor Core في بطاقة RTX 4090 حوالي 330 تيرافلوب عند استخدام FP16، وحوالي 82.6 تيرافلوب عند استخدام FP32. وتُعدّ نتائج الاختبار المعياري، التي تُشير إلى حوالي 52% من ذروة أداء FP16، متوقعة، حيث أن القياس عبارة عن عملية ضرب مصفوفات ذات إنتاجية مستدامة لا تصل إلى ذروة الأداء النظري لنواة GEMM المُعدّلة يدويًا. وتؤكد هذه النتائج أن جميع مصفوفات Tensor Core الأربعة تعمل بكفاءة وثبات.

أداء وحدة معالجة الرسومات 1 أقل بنسبة 6% تقريبًا في دقة FP16 مقارنةً بالوحدات الأخرى. هذا تباين طبيعي في جودة السيليكون ضمن نفس الفئة. لا يوجد عطل في المكونات.

عرض النطاق الترددي لذاكرة وحدة معالجة الرسومات

يتوافق عرض نطاق ذاكرة الوصول العشوائي للفيديو (VRAM) البالغ 920 جيجابايت/ثانية مع مواصفات بطاقة RTX 4090 (1,008 جيجابايت/ثانية كحد أقصى؛ والفرق ناتج عن الحمل الزائد في الاختبار المعياري). يُعدّ هذا الرقم لعرض النطاق هو العامل الحاسم في سرعة فك التشفير: إذ يتطلب كل رمز مُولّد تحميل مجموعة كاملة من ذاكرة التخزين المؤقت للمفتاح والقيمة (KV) وموترات الوزن من ذاكرة الوصول العشوائي للفيديو، لذا يُحدّد عرض النطاق الحد الأقصى لسرعة التوليد.

يُعدّ معدل نقل البيانات بين وحدات معالجة الرسومات (19-22 جيجابايت/ثانية عبر PCIe من نظير إلى نظير) القيد المعماري ذي الصلة بخدمة المعالجة المتوازية للموتر. مع NVLink، تصل سرعة هذا المسار إلى 900 جيجابايت/ثانية. أما مع PCIe فقط، فستحصل على ما يقارب 2% من هذه السرعة. لا يُعدّ هذا الأمر كارثيًا للاستدلال - إذ إن معظم الاتصالات المتوازية للموتر على نموذج 70 بايت AWQ INT4 عبر 4 وحدات معالجة رسومات تتناسب مع قدرة PCIe - ولكنه يُقلّل من سرعة فك التشفير لطلب واحد مقارنةً بنظام متصل عبر NVLink. راجع قسم المعايير أدناه، و N03 للمناقشة الأوسع.

إحدى الملاحظات الشاذة: تم قياس عرض النطاق الترددي من الجهاز إلى المضيف عند 1.4 جيجابايت/ثانية، وهو أقل بكثير من المتوقع البالغ 26 جيجابايت/ثانية تقريبًا لـ PCIe Gen4 x16. هذا سلوك معروف في CUDA مع الذاكرة غير المثبتة. إذا كان تطبيقك ينقل البيانات من وحدة معالجة الرسومات إلى المضيف بشكل متكرر (مثل أخذ عينات من سجلات الإخراج في مسار مخصص)، فاستخدم torch.pin_memory() أو تخصيص مخازن مؤقتة مثبتة مسبقًا. لا تُفعّل مسارات خدمة vLLM و llama.cpp القياسية هذا المسار في الحلقة الساخنة.

أكدت جميع روابط PCIe أنها تعمل بتردد Gen4 x16 (16 جيجابت/ثانية) تحت الحمل. في وضع الخمول، يستخدم برنامج التشغيل وضع توفير الطاقة ASPM، وتنخفض سرعة الروابط إلى Gen1 (2.5 جيجابت/ثانية) - وهذا أمر طبيعي وليس عطلاً في الأسلاك أو وصلة الرفع.

تخزين NVMe

تُعدّ هذه أرقامًا ممتازة لتقنية NVMe بالنسبة لمحرك أقراص PCIe 4.0 مُصمّم للاستخدام المنزلي أو شبه المنزلي. بالنسبة لخدمة النماذج، فإنّ الرقم المهم هو سرعة القراءة المتسلسلة: 4,589 ميجابايت/ثانية تعني أن نموذجًا بسعة 38 جيجابايت يُحمّل إلى ذاكرة الوصول العشوائي (RAM) في غضون 8-9 ثوانٍ تقريبًا قبل أي نقل إلى ذاكرة الفيديو (VRAM). أما سرعة 568 ألف عملية إدخال/إخراج عشوائية في الثانية (IOPS) فهي أكثر أهمية إذا كنت تُشغّل مسار استرجاع (RAG، تخزين متجهي) حيث يكون عبء العمل عبارة عن العديد من عمليات القراءة العشوائية الصغيرة - وهذا المحرك يتعامل مع ذلك بكفاءة دون أن يُصبح عائقًا.

استدلال vLLM — Llama 3.3 70B AWQ INT4

هذا هو المعيار الأساسي. النموذج: casperhansen/llama-3.3-70b-instruct-awqالإصدار: vLLM 0.19.0 مع tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.

تتطلب سرعة فك التشفير لطلب واحد البالغة 8.0 توكو/ثانية سياقًا. قام الإصدار vLLM 0.19.0 بتشغيل نموذج AWQ مع awq النواة، وليس awq_marlin. awq_marlin يُعدّ kernel المسار الأسرع لتقنية AWQ على معالجات Ada Lovelace (RTX 4090) و Blackwell الرسومية - وتشير ملاحظات الاختبار المعياري إلى أنه لم يتم اختياره خلال عملية التشغيل هذه، ومن المتوقع أن يكون التحسن بمقدار 2-3 أضعاف في سرعة فك التشفير لطلب واحد. awq_marlin، يجب أن يصل نفس النموذج على نفس الأجهزة إلى ما يقرب من 16-24 توكو/ثانية في التدفق الفردي.

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

يمثل زمن الاستجابة البالغ 2,043 مللي ثانية لطلب مكون من 16 رمزًا الحد الأدنى لزمن الاستجابة (TTFT) في ظل vLLM على هذا التكوين. بالنسبة لحالات الاستخدام التفاعلية (المحادثة، المساعدة في كتابة التعليمات البرمجية)، يُعد هذا الزمن بطيئًا نسبيًا. والسبب الرئيسي هو الحمل الزائد الناتج عن عملية التوزيع/التجميع المتوازية باستخدام الموترات عبر أربع وحدات معالجة رسومية (GPUs) عبر PCIe - حيث تتطلب كل خطوة تعبئة مسبقة عملية AllReduce عبر جميع البطاقات الأربع عبر بنية PCIe. مع NVLink، سيبلغ زمن الاستجابة (TTFT) حوالي 50-100 مللي ثانية؛ ومع PCIe P2P بسرعة 20 جيجابايت/ثانية، يزداد هذا الزمن. هذه هي التكلفة المباشرة لبنية عدم استخدام NVLink على الطلبات الفردية الحساسة لزمن الاستجابة (انظر N03).

llama.cpp — اللاما 3.3 70B Q4_K_M GGUF

طراز: Llama-3.3-70B-Instruct-Q4_K_M.ggufالخلفية: llama-cpp-python 0.3.20 مع CUDA/cuBLAS، تم تفريغ جميع الطبقات إلى وحدة معالجة الرسومات.

يُقدّم برنامج llama.cpp سرعة فك تشفير تبلغ حوالي 20 توك/ثانية عند فك تشفير تدفق واحد، وهي سرعة أفضل من سرعة AWQ الحالية في vLLM، ويعود ذلك إلى توافق مسار النواة الخاص بـ llama.cpp، والمبني على مكتبة cuBLAS، مع تقنية التكميم Q4_K_M. لا يدعم llama.cpp تجميع الطلبات المتعددة في وقت واحد كما يفعل vLLM، لذا فإن سرعة 20 توك/ثانية هي حد أقصى لكل جلسة، وليست سعة إجمالية. بالنسبة لسير العمل التفاعلي أحادي المستخدم، تُعدّ سرعة 20 توك/ثانية في llama.cpp سرعة قراءة مريحة للإخراج باللغة الإنجليزية.

تُعدّ سرعة معالجة المطالبات البالغة 1,568 رمزًا في الثانية عالية. يقيس هذا مدى سرعة استيعاب النموذج للمطالبات (مرحلة التعبئة المسبقة). تُعدّ سرعة التعبئة المسبقة مهمة عند تشغيل نموذج على مطالبات نظام طويلة أو سياق مستند طويل. عند 1,568 رمزًا في الثانية، تتم معالجة سياق مستند يحتوي على 4,000 رمز في أقل من 3 ثوانٍ قبل بدء عملية الإنشاء.

للاطلاع على الجوانب الاقتصادية والمقارنة مع بدائل الحوسبة السحابية، انظر T01 (توك/ثانية لكل يورو) و T02 (تكلفة المليون رمز مميز محليًا مقابل السحابة).

ما الغرض من المحركين؟

اختبار الإجهاد - الحمل المستمر

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

حرق وحدة معالجة الرسومات (ضرب المصفوفة FP16 بنسبة 100%، 60 ثانية)

لم تُسجّل أي أخطاء حسابية في جميع وحدات معالجة الرسومات الأربع. ارتفعت درجات الحرارة من حوالي 28 درجة مئوية إلى مستوى ثابت بحلول الثانية 40. سجّلت وحدة معالجة الرسومات الثانية أعلى درجة حرارة عند 72 درجة مئوية، وهي أعلى درجة حرارة في مسار تدفق الهواء داخل الهيكل عند هذا الموضع. يبلغ حدّ التخفيض الحراري لبطاقة RTX 4090 83 درجة مئوية، وأعلى درجة حرارة مُسجّلة (72 درجة مئوية) تترك هامشًا قدره 11 درجة مئوية. لم يُسجّل النظام أي تخفيض حراري في أي وقت.

تم ضبط حدود الطاقة على قيم مختلفة بين البطاقات الأربع (480 واط، 450 واط، 500 واط، 480 واط). هذا تباين بسيط ينبغي توحيده. nvidia-smi -pl 480 -i 0,1,2,3 (أو أي حد مناسب) لتحديد حدود ثابتة قبل الاستخدام الإنتاجي.

اختبار الحرق المشترك لوحدة معالجة الرسومات ووحدة المعالجة المركزية (جميع وحدات معالجة الرسومات الأربعة + 64 خيط معالجة مركزية في وقت واحد، 60 ثانية)

أدى إضافة 64 خيط معالجة مركزية عند تحميل كامل إلى انخفاض إجمالي قدرة معالجة الرسومات بنسبة 0.6% فقط. يستهلك معالج EPYC 7542 حوالي 200 واط من الطاقة الحرارية عند التحميل الكامل؛ وكان النظام المدمج يعمل باستهلاك إجمالي للطاقة يتراوح بين 2.1 و2.2 كيلوواط تقريبًا. بقيت جميع درجات الحرارة ضمن الحدود المسموح بها: بلغت درجة حرارة وحدة معالجة الرسومات الثانية ذروتها عند 73 درجة مئوية تحت التحميل المدمج، أي أقل بـ 10 درجات مئوية من عتبة خفض التردد.

بلغ متوسط ​​الحمل 55+ خلال مرحلة اختبار المعالج (وهو المعدل المتوقع لـ 64 خيط معالجة). كان النظام مستقرًا تمامًا طوال الوقت؛ لم تحدث أي ارتفاعات حادة في درجة الحرارة، أو أخطاء حسابية، أو أعطال في نظام التشغيل.

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

ما الذي نجح بشكل جيد

منصة EPYC. تم حل مشكلة ميزانية مسارات PCIe بشكل نهائي. تعمل جميع بطاقات RTX 4090 الأربع بكامل طاقتها من الجيل الرابع x16 تحت الضغط (تم التأكد من ذلك في 04d فحص حالة PCIe). لا يوجد تشعب، ولا توجد فتحات متدهورة. بعض أجهزة AMD Ryzen المزودة بأربع وحدات معالجة رسومية تشغل فتحتين أو أكثر بسرعة x8؛ هذا ليس هو الحال في EPYC Rome.

الرامات " الذاكرة العشوائية في الهواتف والحواسيب. يُعدّ حجم 512 جيجابايت مناسبًا. أثناء تحميل نموذج llama.cpp، يتم تخصيص مساحة في الذاكرة لملف GGUF الذي يبلغ حجمه 38 جيجابايت؛ لذا فإن توفر 512 جيجابايت يعني إمكانية تشغيل عمليات متعددة بالتزامن مع خادم LLM دون التنافس على الذاكرة.

سرعة NVMe التسلسلية. تساهم سرعة القراءة المتسلسلة البالغة 4,589 ميجابايت/ثانية في تقليل أوقات التحميل. وفي سير عمل تكرار النماذج - التحميل والاختبار والتبديل بين النماذج - يتراكم هذا التأثير على مدار يوم كامل.

حراري. أسوأ درجة حرارة مستدامة تبلغ 73 درجة مئوية (وحدة معالجة الرسومات 2، اختبار مشترك) مع هامش أمان قدره 10 درجات مئوية. في حمل عمل استدلالي نموذجي، لن تعمل وحدات معالجة الرسومات بكامل طاقتها بشكل مستمر - فعملية فك التشفير محدودة بعرض نطاق ذاكرة الوصول العشوائي للفيديو، وليست محدودة بقدرة الحساب - لذا ستكون درجات حرارة التشغيل الفعلية أقل من ذروة اختبار الضغط.

llama.cpp 1,568 tok/s prompt eval. فاجأنا هذا الرقم إيجاباً. مسار التعبئة المسبقة لـ cuBLAS على أربعة معالجات 4090 سريع. تستفيد التطبيقات ذات السياق الطويل من ذلك.

ما فاجأنا

خطأ في نواة vLLM AWQ. تم إجراء الاختبار المعياري مع awq النواة بدلاً من awq_marlinقامت مجموعة أدوات التشغيل بتشغيل هذا تلقائيًا بناءً على تكوين النموذج في ذلك الوقت. awq_marlinمن المتوقع أن يرتفع معدل نقل البيانات للطلب الواحد من 8 توك/ثانية إلى 16-24 توك/ثانية. هذا خلل في إعدادات البرنامج، وليس قيدًا متعلقًا بالأجهزة - لذا يُرجى التحقق من سلسلة طريقة التكميم vLLM عند إعداد خادم الإنتاج.

عرض النطاق الترددي D2H. فاجأنا معدل نقل البيانات من الجهاز إلى المضيف، البالغ 1.4 جيجابايت/ثانية، خلال التحليل الأولي. هذا سلوكٌ خاص بذاكرة CUDA غير المثبتة، وليس خطأً في PCIe. لا يُشكّل هذا الأمر مشكلةً بالنسبة لحزم الخدمة القياسية (vLLM، llama.cpp). أما بالنسبة لرمز الاستدلال المخصص الذي ينقل الموترات إلى وحدة المعالجة المركزية للمعالجة اللاحقة، فيُفضّل استخدام تخصيصات الذاكرة المثبتة.

تم تصحيح أخطاء وحدة معالجة الرسومات 3 PCIe AER. أثناء اختبار vLLM، سجلت وحدة معالجة الرسومات 3 (الناقل c1:00.0) أخطاء PCIe مصححة (RxErr + BadTLP). تم تصحيح هذه الأخطاء تلقائيًا بواسطة الجهاز ولم تؤثر على الحساب. السبب المحتمل: تثبيت كابل PCIe أو إعادة التفاوض على الاتصال بسرعة الجيل الرابع. يُنصح بالمراقبة تحت ضغط إنتاج مستمر؛ في حال ازدياد عدد الأخطاء، أعد تثبيت كابل PCIe الخاص بوحدة معالجة الرسومات 3. لم تُسجل أي أخطاء أثناء اختبارات الضغط نفسها.

انقطاع قصير في وصلة بطاقة الشبكة. انقطع اتصال الشبكة لفترة وجيزة ثم عاد للعمل أثناء اختبار أداء وحدة معالجة الرسومات (13:38 بالتوقيت العالمي المنسق). يُرجح أن يكون ذلك بسبب ارتفاع مفاجئ في الطاقة نتيجة تشغيل وحدة معالجة الرسومات في الوقت نفسه. قيد التشغيل في بيئة الإنتاج مع nvidia-persistenced أثناء التشغيل (الذي يحافظ على تهيئة سياقات وحدة معالجة الرسومات)، تكون تغيرات الطاقة عند بدء التحميل أصغر. قم بالتمكين nvidia-persistenced كخدمة systemd قبل الإنتاج.

ما الذي سنفعله بشكل مختلف في الإصدار الثاني؟

تفعيل awq_marlin من البداية. تحقق من مسار نواة التكميم vLLM أثناء عملية التشغيل، وليس بعدها. أضف فحصًا لهوية النواة إلى نص التشغيل.

قم بتطبيع حدود طاقة وحدة معالجة الرسومات قبل إجراء الاختبارات المعيارية. تم شحن البطاقات الأربع بحدود طاقة مختلفة (480 واط، 450 واط، 500 واط، 480 واط). تحديد حد طاقة ثابت (nvidia-smi -pl) قبل تشغيل الاختبار المعياري الأول يعطي أرقامًا أنظف وأكثر قابلية للمقارنة، ويتجنب استهلاك الطاقة غير المتسق أثناء الاحتراق المشترك.

أضف مجموعة أدوات مراقبة عند التسليم. يستغرق إعداد برنامج Prometheus مع مُصدِّر DCGM، بالإضافة إلى Grafana، بضع ساعات، ويتيح رؤية درجة حرارة وحدة معالجة الرسومات، واستخدام ذاكرة الوصول العشوائي للفيديو، ومعدلات أخطاء PCIe في الوقت الفعلي. يُنصح بتضمين هذه الميزة ضمن عملية التشغيل القياسية بدلاً من تركها كمهمة بعد التسليم. انظر L05 للاطلاع على دليل إعداد المكدس.

دبوس nvidia-persistenced في ملف وحدة systemd أثناء إعداد نظام التشغيل. هو سطر واحد، لكن يتم تجاهله باستمرار. بدونه، يستغرق تحميل وحدة معالجة الرسومات (GPU) لأول مرة بعد فترة هدوء بضع ثوانٍ إضافية، مما ينتج عنه ارتفاع مفاجئ في الطاقة تسبب في تذبذب إشارة بطاقة الشبكة (NIC).

توسع LVM. يحتوي قرص نظام التشغيل (512 جيجابايت SATA) على 100 جيجابايت فقط مخصصة لقسم LVM. أما المساحة المتبقية البالغة 374 جيجابايت فهي غير مخصصة. لا يوجد سبب لتركها. lvextend و resize2fs يستغرق الأمر 30 ثانية، مما يمنحك تلك المساحة اللازمة لتكاليف نظام التشغيل والسجلات وطبقات Docker.

ضع في اعتبارك استخدام وحدة تخزين NVMe ثانية لتخزين النماذج. تحتوي وحدة التخزين NVMe الوحيدة بسعة 2 تيرابايت حاليًا على جميع النماذج، وستمتلئ مع نمو مكتبة النماذج. يمكن إضافة وحدة تخزين NVMe ثانية بسعة 4 تيرابايت في وضع RAID 0 أو ببساطة كوحدة تخزين منفصلة. /mnt/nvme2 سيضيف التثبيت مرونة ويحافظ على أداء القراءة المتسلسلة عاليًا عبر مكتبة إجمالية أكبر.

مقارنة: بدائل لهذا التصميم

كان من الممكن التعامل مع عبء عمل العميل باستخدام أجهزة مختلفة. إليك مقارنة موضوعية:

يُعدّ نظام 4x RTX 4090 بسعة 96 جيجابايت الحد الأدنى المطلوب لتشغيل Llama 3.3 70B AWQ INT4 ضمن بيئة vLLM بكفاءة معالجة دفعية عالية. وهو ليس الحد الأقصى؛ إذ يُضيف نظام 8x وحدات معالجة رسومية سعةً متناسبة. بالنسبة لعميل بحثي يرغب في محطة عمل واحدة مخصصة - وليس مجموعة خوادم - غالبًا ما يكون نظام 4x هو الخيار الأمثل للبدء.

لا يدعم كل من التكوينين 4× و8× تقنية NVLink بين وحدات معالجة الرسومات، مما يعني أن الاستدلال المتوازي للموتر يعمل عبر PCIe. وينعكس ذلك عمليًا على زمن استجابة TTFT للطلبات الفردية، وليس على الإنتاجية الإجمالية المجمعة. بالنسبة لأحمال العمل بحجم فريق (عشرات الطلبات في الساعة، وليس الآلاف)، لا يُعد هذا عاملًا مُقيِّدًا. للاطلاع على متطلبات زمن استجابة TTFT أقل من 100 مللي ثانية، انظر N03 والسبب وراء استهداف التشكيلة لأنظمة وحدات معالجة الرسومات المتعددة المتصلة بـ PCIe بدلاً من أنظمة NVSwitch fabric.

التخطيط الشامل للطاقة والكهرباء

تحت حمل مستمر على وحدة معالجة الرسومات، بلغ إجمالي استهلاك الطاقة للنظام حوالي 1,900-2,200 واط عند قياسه على خطوط وحدة معالجة الرسومات (1,914 واط عند تشغيل وحدة معالجة الرسومات فقط؛ وحوالي 2,100 واط عند دمجها مع وحدة المعالجة المركزية ومحركات الأقراص واللوحة الأم). يجب مراعاة فقدان كفاءة وحدة التزويد بالطاقة (بافتراض 90%)، والتخطيط لدائرة كهربائية بحد أدنى 16 أمبير/230 فولت، مع تفضيل 20 أمبير كاحتياطي.

يقسم تصميم وحدة التزويد بالطاقة المزدوجة الطاقة على منفذين. يجب أن يكون كلا المنفذين على دوائر كهربائية قادرة على تحمل الحمل بشكل مستقل: إذا كانت وحدة التزويد بالطاقة A تغذي وحدتي معالجة رسومية بقدرة 500 واط لكل منهما بالإضافة إلى 200 واط للوحة/المعالج، فإن ذلك يعني 1,200 واط على دائرتها. لذا، يجب اختيار الحجم المناسب.

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

يرى P01 للمقارنة بين التيار أحادي الطور والتيار ثلاثي الأطوار و P04 لتحديد حجم القاطع.

نطاق الأسعار

تُصنّف هذه المواصفات - منصة EPYC 7542، وذاكرة وصول عشوائي ECC بسعة 512 جيجابايت، وأربع بطاقات رسومات RTX 4090، ووحدة تخزين NVMe بسعة 2 تيرابايت، وهيكل رف مع مزود طاقة مزدوج - ضمن 18,000 - 24,000 يورو بدون ضريبة القيمة المضافة يتراوح السعر حسب أسعار المكونات الحالية، ويعتمد على اختيار الهيكل، وتوقيت توريد ذاكرة الوصول العشوائي، وتوفر وحدة معالجة الرسومات. مدة التسليم من 10 إلى 28 يومًا حسب توفر المكونات، ويتم تأكيدها عند الطلب.

لا يشمل هذا السعر التركيب، أو وحدة توزيع الطاقة في الرف، أو الشبكة (محول 10 جيجابت إيثرنت، أو الكابلات)، أو أي ترخيص برمجي. يأتي النظام مزودًا بنظام Ubuntu 24.04 LTS مثبتًا مسبقًا، وبيئة Python الافتراضية مُهيأة مسبقًا؛ لذا يُرجى إحضار أوزان النماذج الخاصة بك.

ما يناسب هذا التصميم

• البحث والاستدلال في برنامج الماجستير في القانون ضمن فريق صغير. تشغيل نموذج 70B لفريق يتراوح عدد مستخدميه بين 5 و15 مستخدمًا. يُعالج معدل نقل البيانات الإجمالي البالغ 179 توكو/ثانية ضمن vLLM الجلسات المتزامنة بكفاءة عالية.
• تقييم النموذج وتكراره. سرعة تحميل NVMe العالية تعني سرعة التبديل بين الطرازات المرشحة. كما أن ميزانية مسارات PCIe في منصة EPYC تضمن عمل جميع وحدات معالجة الرسومات الأربعة بكامل عرض النطاق الترددي دائمًا.
• عمليات نشر البيانات ذات السيادة. تتم جميع عمليات الاستدلال محلياً. لا تغادر أي بيانات النظام المبنى. هذا هو السبب الرئيسي غير الاقتصادي لتشغيل النظام محلياً في سياقات البحث.
• نقطة دخول مناسبة للميزانية المحدودة (70B). تُعدّ بطاقة RTX 4090 أعلى بطاقة رسومات استهلاكية من حيث سعة ذاكرة الوصول العشوائي للفيديو (VRAM). بسعة 24 جيجابايت لكل بطاقة، وباستخدام أربع بطاقات، يصل إجمالي السعة إلى 96 جيجابايت، مما يُمكّنك من الوصول إلى فئة 70B دون الحاجة إلى دفع أسعار بطاقات الرسومات الاحترافية.

ما لا يناسبه هذا التصميم

• زمن استجابة الطلب الواحد أقل من 100 مللي ثانية. تُحدِّد بنية PCIe P2P المتوازية الموترية الحد الأدنى لزمن الاستجابة الكلي للنماذج الكبيرة. إذا كنت بحاجة إلى زمن استجابة تفاعلي سريع على نماذج بحجم 70 مليار أو أكثر، فإن هذه البنية ليست الخيار الأمثل. أنت بحاجة إلى وحدات معالجة رسومية متصلة بـ NVLink، مما يعني فئة مختلفة تمامًا من الأجهزة (انظر N03).
• تشغيل نماذج كبيرة متعددة في وقت واحد. بإجمالي ذاكرة وصول عشوائي للفيديو تبلغ 96 جيجابايت مع gpu_memory_utilization=0.80لديك حوالي 77 جيجابايت قابلة للاستخدام. لن يتسع الجهاز لنموذج 70B INT4 ثانٍ. إذا كنت بحاجة إلى تشغيل نموذجين في وقت واحد، فقم بالترقية إلى منصة ذات ذاكرة وصول عشوائي للفيديو (VRAM) أكبر لكل وحدة معالجة رسومية (GPU) أو إلى عدد أكبر من وحدات معالجة الرسوميات.
• إنتاج واسع النطاق يخدم. بالنسبة لمئات المستخدمين المتزامنين أو وقت التشغيل المضمون بموجب اتفاقية مستوى الخدمة، فإن هذه البنية (بدون وحدات إضافية لبطاقة الشبكة على هيكل بأربع وحدات معالجة رسومية، وعقدة واحدة، ووحدات معالجة رسومية استهلاكية مع تعطيل تصحيح الأخطاء ECC) ليست الأساس المناسب. أما خادم K-AI ذو الثماني وحدات معالجة رسومية مع معالج L40 أو RTX Pro 6000 Blackwell، ونظام مراقبة مناسب، وبطاقتي شبكة فهو الخيار الأمثل.
• تدريب النماذج الكبيرة. مع ذاكرة وصول عشوائي للفيديو (VRAM) إجمالية تبلغ 96 جيجابايت، يمكنك ضبط نماذج 70B بدقة (LoRA، QLoRA)، ولكن لا يمكنك تدريبها بكامل معلماتها. تكون ميزانية ذاكرة الوصول العشوائي للفيديو (VRAM) للتدريب أكثر تقييدًا منها للاستدلال. إذا كان التدريب جزءًا من خطة عبء العمل، فضع هذا في اعتبارك.

---

هذا جزء من سلسلة دراسات الحالة (C) في ويكي كينتينو. تم قياس بيانات البناء في 10 أبريل 2026. نُشرت المقالة في 15 مايو 2026. نرحب بالتصحيحات والقياسات اللاحقة على info@kentino.com.