Inspur تبني بنية تحتية للوكلاء الذكيين: 40,000 وكيل لكل رف مع تنسيق متعدد النماذج
البنية التحتية للذكاء الاصطناعي تتجاوز عصر خدمة طلب نموذج واحد في كل مرة. الوكيل الذكي على مستوى الإنتاج لا يقتصر على تلقي الاستفسارات وإرجاع الإجابات فحسب، بل قد يقوم بتقسيم المهمة إلى مراحل متعددة، واستدعاء أدوات خارجية، والحفاظ على السياق، والتنسيق مع الوكلاء الفرعيين، ومراجعة المخرجات الوسيطة، والبقاء نشطًا لفترات طويلة. عندما تقوم المؤسسات بنشر آلاف من هؤلاء الوكلاء في وقت واحد، تختلف متطلبات البنية التحتية بشكل جذري عن استدلال روبوتات المحادثة العادية. في معايير الحوسبة المفتوحة لعام 2026...
Inspur تبني بنية تحتية للوكلاء الذكيين: 40,000 وكيل لكل رف مع تنسيق متعدد النماذج
مقدمة
تتجاوز البنية التحتية للذكاء الاصطناعي الآن عصر معالجة طلب نموذج واحد في كل مرة.
الوكيل الذكي الإنتاجي لا يقتصر فقط على تلقي استفسار وإرجاع إجابة. قد يقوم بتقسيم المهمة إلى مراحل متعددة، واستدعاء أدوات خارجية، والحفاظ على السياق، والتنسيق مع الوكلاء الفرعيين، ومراجعة المخرجات الوسيطة، والبقاء نشطًا لفترات طويلة. عندما تقوم المؤسسات بنشر آلاف من هؤلاء الوكلاء في وقت واحد، تختلف متطلبات البنية التحتية تمامًا عن استدلال روبوتات الدردشة العادية.
في قمة تكنولوجيا الحوسبة المفتوحة 2026 التي عُقدت في بكين، اقترحت Inspur Information اتجاهين للبنية التحتية لهذا النوع الجديد من أعباء العمل:
- خادم رف مُبرد بالسائل أصلي لوحدة المعالجة المركزية، مصمم لدعم أكثر من 40,000 وكيل متزامن داخل رف واحد.
- الجمع بين عقدة MetaBrain SD200 الفائقة وواجهة برمجة تطبيقات دمج النماذج المتعددة EPAI، مما يسمح لنماذج كبيرة متعددة بتوليد الإجابات ومراجعتها ودمجها للمهام المعقدة.
يركز الاتجاه الأول على السعة: الحفاظ على اتصال عدد كبير من الوكلاء طويلي الأمد. بينما يركز الاتجاه الثاني على الجودة: السماح لنماذج متعددة ذات نقاط قوة مختلفة بالعمل معًا، بدلاً من إجبار نموذج واحد على التعامل مع كل جزء من المهمة الصعبة.
تحديات البنية التحتية المختلفة التي يفرضها عبء عمل الوكلاء
عادةً ما يتبع استدلال النماذج الكبيرة التقليدية نمطًا بسيطًا:
- يرسل المستخدم طلبًا.
- يقوم النموذج بإجراء الاستدلال.
- يعيد النظام استجابة.
- تنتهي الجلسة أو تنتظر الطلب التالي.
بينما مسار تنفيذ تطبيق الوكيل أطول بكثير.
قد تتضمن مهمة تجارية واحدة:
- التخطيط
- تقسيم المهمة
- الاسترجاع
- استدعاء الأدوات
- تنفيذ الكود
- التحقق من الصلاحيات
- عمليات البيئة المعزولة
- استدلال متعدد الجولات
- التنسيق مع الوكلاء الفرعيين
- التحقق من المخرجات
- تجميع النتائج
- إدارة الحالة طويلة الأمد
لذلك، لا يجب أن تدعم البنية التحتية استدلال النموذج فحسب، بل يجب أن تدعم أيضًا عددًا كبيرًا من عمليات البرمجيات المستمرة.
في البيئة المؤسسية، قد يرتفع عدد الوكلاء النشطين من العشرات إلى الآلاف أو حتى عشرات الآلاف. بعض الوكلاء قد يعملون باستمرار، بينما يتم إنشاء آخرين ديناميكيًا للمهام القصيرة ويتم تدميرهم بعد الانتهاء.
هذا يغير التوازن بين موارد وحدة المعالجة المركزية ووحدة معالجة الرسومات.
وحدة معالجة الرسومات تولد الرموز
لا تزال وحدة معالجة الرسومات لا غنى عنها في المراحل التالية:
- استدلال النموذج الكبير
- التعبئة المسبقة وفك التشفير
- توليد التضمينات
- المعالجة متعددة الوسائط
- إنتاج الرموز عالية الإنتاجية
- التنفيذ المتوازي للنماذج
وحدة المعالجة المركزية تدير بيئة الوكيل
تتعامل وحدة المعالجة المركزية مع الكثير من الأعمال المحيطة:
- جدولة عمليات الوكيل
- استدعاء الأدوات
- إدارة السياق والحالة
- التفاعل مع الأنظمة التجارية
- تنفيذ البيئة المعزولة
- عمليات الشبكة والتخزين
- المصادقة والصلاحيات
- تنسيق سير العمل
- تحضير النتائج
قد يكون النموذج مسؤولاً عن توليد الاستدلال أو النص، لكن وحدة المعالجة المركزية عادةً ما تدير بيئة تشغيل الوكيل.
لذلك، تتحول البنية التحتية للوكلاء من تصميم يركز على وحدة معالجة الرسومات إلى نظام يتعاون فيه وحدة المعالجة المركزية ووحدة معالجة الرسومات والشبكة والتخزين والتبريد وبرامج التنسيق.
لماذا تزداد أهمية كثافة وحدة المعالجة المركزية
في خوادم المؤسسات العادية، كانت كثافة وحدة المعالجة المركزية محدودة تاريخيًا بسبب استهلاك الطاقة والتبريد والمساحة والكابلات والمراوح واحتياجات الصيانة.
نشر الوكلاء يغير النموذج الاقتصادي.
إذا كانت آلاف الوكلاء تحتاج إلى موارد وحدة المعالجة المركزية للتنسيق واستدعاء الأدوات وبيئات التشغيل المعزولة، فإن أرفف وحدة المعالجة المركزية منخفضة الكثافة ستشغل مساحة غرفة خادم أكبر واتصالات شبكة أكبر وبنية تحتية مساعدة أكبر.
في الوقت نفسه، تتطور مراكز بيانات الذكاء الاصطناعي نحو طاقة رف أعلى.
وفقًا لتقارير المصادر، تتوقع Inspur Information أن تصل طاقة أرفف الذكاء الاصطناعي المحلية إلى ما يقرب من 300 كيلوواط، بينما تتجه بعض التصميمات العالمية نحو أنظمة أرفف بمقياس ميجاواط. التبريد الهوائي التقليدي عادةً ما يكون محدودًا بعشرات الكيلوواط لكل رف، وسيصبح أكثر صعوبة عند هذه الكثافات.
لذلك، لم يعد التبريد السائل مشكلة خاصة بوحدة معالجة الرسومات.
أرفف وحدة المعالجة المركزية التي تدعم أعباء عمل الوكلاء يجب أن تتطابق أيضًا مع بنية الطاقة والتبريد لمراكز بيانات الذكاء الاصطناعي من الجيل التالي.
رف واحد يمكنه دعم أكثر من 40,000 وكيل
أطلقت Inspur ما تزعم أنه أول خادم رف مُبرد بالسائل أصلي لوحدة المعالجة المركزية في الصناعة.
يعتمد هذا النظام على بنية التبريد السائل OCM 2.0، ويدعم معالجات x86 و Arm.
تشمل معلماته الرئيسية:
| الميزة | المعلمة المبلغ عنها من قبل الشركة المصنعة |
|---|---|
| الحد الأقصى لعدد وحدات المعالجة المركزية لكل رف | 384 |
| عدد الوكلاء المتزامنين المدعومين | أكثر من 40,000 وكيل |
| بنية المعالج | x86 و Arm |
| نطاق التبريد | وحدة المعالجة المركزية، الذاكرة، SSD، بطاقة الشبكة، الوحدة الضوئية ومكونات التدفئة الأخرى |
| كثافة الحوسبة | دمج 4 وحدات معالجة مركزية في مساحة 0.5U |
| طريقة الصيانة | صيانة دورة الحياة الكاملة للتبريد السائل |
| السيناريو المستهدف | مراكز بيانات الذكاء الاصطناعي عالية الكثافة وذات مقياس جيجاواط |
هذا النظام لا يعتبر التبريد السائل مجرد إضافة بعد اكتمال تصميم الخادم.
بدلاً من ذلك، تم تطوير تخطيط الحوسبة وهندسة التبريد بشكل متزامن.
التوسع من تبريد اللوحة الباردة لوحدة المعالجة المركزية إلى تبريد جميع المكونات
تقوم خوادم اللوحة الباردة التقليدية
بتبريد المعالج بشكل مباشر، لكن الذاكرة والشبكة والتخزين ومكونات الطاقة والأجهزة الأخرى لا تزال تعتمد على المراوح للتبريد.
مع زيادة الكثافة، يصبح هذا الأسلوب أقل فعالية.
تعمل بنية التبريد السائل الأصلي لـ Inspur على دمج مكونات التدفئة الرئيسية في نظام تبريد موحد:
- وحدة المعالجة المركزية
- الذاكرة
- بطاقة الشبكة
- الوحدة الضوئية
- SSD
- مكونات الاتصال
هذا يقلل من الاعتماد على تدفق الهواء الداخلي، مما يسمح بتخطيط مكونات أكثر إحكاما.
يوجد أدناه ثلاثة أيقونات زرقاء تحمل عبارات "هندسة التبريد السائل" و"توصيل التبريد السائل" و"صيانة التبريد السائل". ترتبط هذه الصورة ارتباطًا وثيقًا بالسياق، وتقدم بشكل مرئي عرض خوادم بنية التبريد السائل من Inspur، بما يتماشى مع تصميم بنية التبريد السائل المذكور في المستند.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/44c90e20-2048-4f43-8d1d-8516006843e0-d14e80b4-e2a0-4468-a7b6-77e5229ab1ca.png)
وحدة حوسبة مدمجة
يصف هذا التقرير وحدة حوسبة مدمجة تدمج مجموعات متعددة من المعالجات والمكونات الطرفية في هيكل رقيق وخفيف.
يهدف التصميم إلى استعادة المساحة التي كانت تشغلها المكونات التالية:
- المراوح الكبيرة
- مجاري الهواء
- أنابيب التبريد
- الكابلات الداخلية
- أدراج الخوادم التقليدية
يسمح توزيع المكونات بشكل مسطح بتغطية لوحة تبريد كبيرة واحدة لمساحة أوسع من النظام.
يعتمد الرف تصميمًا داخليًا يقلل أو يلغي استخدام الكابلات، ويدعم الصيانة دون توقف الخدمة. وتشير Inspur إلى أن هذا يحسن كفاءة نشر وصيانة الرف بالكامل.
لماذا OCM مهم؟
OCM هو اختصار لـ "وحدة الحوسبة المفتوحة".
تهدف البنية المعيارية إلى فصل وحدة المعالج عن التصميم العام للنظام. يتيح هذا التصميم دعمًا أسهل للمعالجات من أجيال أو بنى مختلفة دون الحاجة إلى إعادة تصميم الرف بالكامل لكل معالج.
بالنسبة للمؤسسات ومشغلي مراكز البيانات، يمكن أن يوفر هذا الحل المزايا التالية:
- خيارات أوسع للأجهزة
- تسهيل ترقية المنصة
- تقليل أعمال التصميم المتكررة
- توافق أفضل مع بنيتي x86 وArm
- إطالة عمر البنية التحتية للرف
تعتمد النتائج الفعلية على التوافق البيئي وقابلية التشغيل البيني وتوافر المكونات المساعدة.
الحجم لا يعني الذكاء
تشغيل عشرات الآلاف من الوكلاء الذكيين لحل مشكلات السعة لا يحسن تلقائيًا جودة الإجابات.
نماذج اللغات الكبيرة لها تخصصاتها.
قد تكون بعض النماذج أفضل في:
- الاستدلال المنطقي
- كتابة الأكواد
- تحليل النصوص الطويلة
- البحث التقني
- الكتابة الطبيعية
- الاستخراج المنظم
- المهام متعددة اللغات
حتى النماذج فائقة الحجم لديها نقاط ضعف.
عند معالجة المهام المعقدة، قد يفوت نموذج واحد أسئلة رئيسية يمكن لنموذج آخر اكتشافها. كما قد يقدم نموذج واحد إجابة بثقة دون الكشف عن عدم اليقين أو النظر في تفسيرات بديلة.
لذا يركز الاتجاه الثاني للبنية التحتية لـ Inspur على التعاون متعدد النماذج.
تعاون متعدد النماذج في معالجة المهمة نفسها
تقوم واجهة برمجة تطبيقات الدمج متعدد النماذج EPAI بتوزيع المهام المعقدة بشكل متوازٍ على عدة نماذج مرشحة.
يولد كل نموذج إجابة بشكل مستقل. يقوم نموذج تدقيق ودمج إضافي بمقارنة الإجابات المرشحة لتحديد:
- الاستنتاجات المشتركة
- الأحكام المتناقضة
- المعلومات المفقودة
- الرؤى الفريدة
النقاط غير المدعومة:
- المجالات التي تتطلب تنسيقًا
بعد ذلك، تولد المنصة إجابة شاملة.
هذا ليس مجرد تصويت بالأغلبية، ولا مجرد تجميع الردود مباشرة. سير العمل المتوقع هو كما يلي:
- توليد المرشحات
- مراجعة عبر النماذج
- تحليل الاختلافات والنقص
- الدمج في مخرجات نهائية
تقر Inspur أن النظام حقق 53.9% في تقييم DRACO، متفوقًا على كل نموذج فردي في مجموعة المرشحين المستخدمة في هذا الاختبار.
يجب اعتبار هذه النتيجة معيارًا لتقرير المنصة، وليس ادعاءً بأن الدمج يتفوق دائمًا على أفضل نموذج فردي. سيعتمد الأداء على النماذج المرشحة ونموذج التقييم ومنطق التوجيه ونوع المهمة وكلمات التحفيز وطريقة التقييم.
المهام البسيطة لا تزال تستخدم نموذجًا واحدًا
إذا تم تشغيل نماذج متعددة لكل طلب، فسيؤدي ذلك إلى زيادة غير ضرورية في التكلفة وزمن الاستجابة.
لذلك، يميز EPAI بين المهام القصيرة القابلة للتنبؤ والمهام المعقدة.
المهام المناسبة لنموذج واحد
قد يكون النموذج الخفيف كافيًا لـ:
- الأسئلة والأجوبة البسيطة
- تحويل التنسيقات
- الاستخراج الأساسي
- مهام التصنيف
- استدعاء الأدوات القصيرة
- تحويل المحتوى العادي
المهام الأكثر ملاءمة للدمج متعدد النماذج
قد تكون النماذج المتعددة مفيدة للمهام التالية:
- البحث العميق
- المقارنة التقنية
- تحليل البنية
- التخطيط المعقد
- الاستدلال على النصوص الطويلة
- المراجعة عالية الأهمية
- المهام ذات الأدلة الغامضة
- المخرجات التي تحتاج إلى تحقق مستقل
هذا المبدأ في التوجيه ضروري للأنظمة الإنتاجية.
عندما تفوق التحسينات المحتملة في الجودة التكاليف الإضافية للرموز ووقت وحدة معالجة الرسوميات وزمن استجابة الاستجابة، يكون التعاون متعدد النماذج أكثر قيمة.
سير عمل الدمج متعدد النماذج EPAI
تم تصميم واجهة برمجة تطبيقات EPAI لإخفاء تنسيق النماذج المتعددة خلف واجهة موحدة.
يرسل المطور طلبًا إلى المنصة. تدير EPAI ما يلي:
- اختيار النماذج المرشحة
- توزيع المهام بشكل متوازٍ
- جمع الاستجابات
- تنفيذ نموذج التقييم
- تحليل الاختلافات
- توليد الإجابة النهائية
يمكن دمج نفس الواجهة في تطبيقات الوكلاء وأطر التطوير دون حاجة كل فريق لبناء نظام توجيه وتقييم نماذج مخصص.
هذه البنية مناسبة للمؤسسات التي تستخدم مزيجًا من النماذج التالية:
- النماذج مفتوحة المصدر
- النماذج الملكية
- النماذج العامة
- النماذج الخاصة بمجال معين
- النماذج المنشورة محليًا
- نماذج واجهة برمجة التطبيقات السحابية
يتمثل التحدي التشغيلي الرئيسي في أن عدة نماذج كبيرة قد تحتاج إلى البقاء متاحة في وقت واحد. سيتطلب هذا متطلبات أعلى لذاكرة المسرعات وعرض النطاق الترددي للترابط والجدولة والاتصالات منخفضة الزمن.
MetaBrain SD200 يوفر محرك الرموز
عقدة MetaBrain SD200 الفائقة هي المنصة الأجهزية التي تدعم سير عمل الدمج متعدد النماذج.
يستخدم هذا النظام بنية اتصال متعددة المضيفين ومنخفضة الزمن مع دلالات الذاكرة. وفقًا لـ Inspur، يمكنه توحيد 64 مسرع GPU محليًا داخل نظام واحد.
يتضمن تصميمه:
- بنى مفتوحة للحوسبة OCM وOAM
- ترابط شبكي ثلاثي الأبعاد
- عنونة موحدة للمسرعات
- اتصال نظير إلى نظير عالي السرعة
- ذاكرة مشتركة كبيرة السعة
القدرات
- دعم نماذج متعددة بتريليونات المعلمات
- تحسين مشترك للبرامج والأجهزة
يُزعم أن هذه العقدة الفائقة يمكنها دعم نموذج واحد بحجم يصل إلى أربعة تريليونات معلمة، أو نماذج متعددة بتريليونات المعلمات تستخدمها تطبيقات الوكلاء في وقت واحد.
زمن توليد الرمز في اختبارات Inspur يصل إلى 4.77 مللي ثانية
تقر Inspur أن SD200 قلص زمن توليد الرمز الواحد لنموذج Kimi K2.6 ذي تريليون المعلمة إلى 4.77 مللي ثانية.
كما تذكر الشركة أن زمن توليد الرمز الأول انخفض بنسبة 35% مقارنة بالتطبيقات السابقة.
تشير هذه البيانات إلى نتائج في بيئات تحسين واختبار محددة، ولا ينبغي تفسيرها على أنها زمن استجابة مضمون لكل نموذج أو نشر أو طول تحفيز أو مستوى تزامن أو عبء عمل إنتاجي.
تُعزى هذه التحسينات إلى عدة تقنيات.
التنبؤ متعدد الرموز
عادةً ما تولد النماذج ذاتية الانحدار رمزًا واحدًا أولاً، ثم تتحقق من الحالة الجديدة، ثم تولد الرمز التالي.
يحاول التنبؤ متعدد الرموز توليد عدة رموز مرشحة في خطوة واحدة والتحقق منها معًا.
عندما تكون دقة التنبؤ عالية، يمكن تقليل عدد جولات فك التشفير التسلسلي.
قياس W4A8
يستخدم التحسين في بعض أحمال النماذج المختلطة من الخبراء حسابات بأوزان INT4 وتنشيطات INT8.
مقارنة بحسابات BF16، يمكن أن يقلل هذا من:
- ضغط عرض النطاق الترددي للذاكرة
- استخدام ذاكرة المسرع
- متطلبات الحوسبة
- تكلفة الاستدلال لكل رمز
قد يؤثر القياس على جودة النموذج، لذا تحتاج فرق الإنتاج إلى تقييم الدقة بناءً على أعباء عملها الخاصة، وليس فقط نتائج السرعة.
التجميع الفوري للنواة
يولد التجميع الفوري نوى مسرع مخصصة في وقت التشغيل بناءً على شكل المصفوفة والتخطيط ونوع البيانات.
مقارنة بالتطبيقات الثابتة العامة، يمكن للنوى المخصصة تقليل الفروع غير الضرورية وتحسين الوصول إلى الذاكرة.
فصل التعبئة-فك التشفير
لتعبئة التحفيز وفك تشفير الرمز خصائص أداء مختلفة.
فصل المرحلتين يمكن من تخصيص الموارد بشكل مختلف ونقل ذاكرة التخزين المؤقت KV بشكل غير متزامن، مما يقلل من التنافس بين الحوسبة والاتصال.
توافق النماذج
تقول Inspur إن SD200 أكمل تحسين الأداء لعدة نماذج مفتوحة المصدر رئيسية، بما في ذلك:
- Kimi K2.6
- DeepSeek V4
- GLM 5.2
- MiniMax M3
التوافق لا يعني بالضرورة أن كل نموذج سيحقق نفس زمن الاستجابة أو الإنتاجية.
هندسة النموذج، عدد المعاملات، تصميم MoE، طول السياق، التكميم، المعالجة المجمعة، وبرامج الخدمة، كلها تؤثر على الأداء.
الإصدار المؤسسي يخفض حاجز النشر
عقدة 64 مسرعًا فائقة مناسبة لمشاريع البنية التحتية الكبيرة للذكاء الاصطناعي، لكنها كبيرة جدًا ومكلفة جدًا بالنسبة للعديد من المؤسسات.
أطلقت Inspur أيضًا الإصدار المؤسسي MetaBrain SD200.
يقلص الإصدار المؤسسي مجال الحوسبة العمودية من 64 مسرعًا إلى 16، بهدف نشر نماذج تريليون المعاملات محليًا.
تشمل ميزاته المعلنة:
- مجال ربط موحد لـ 16 مسرعًا
- اتصال دلالي للذاكرة الأصلي
- عنونة موحدة
- ذاكرة مسرع موحدة بحجم تيرابايت
- تحسين زمن إنشاء أول رمز لاستدلال تريليون معامل بنسبة تتجاوز 40%
- دعم محلي لنماذج تريليون المعاملات الرائدة مفتوحة المصدر
- تكاليف نقل وتكييف أقل من نظام SD200 الكامل
يستهدف هذا الإصدار المؤسسي أعباء العمل التالية بشكل أساسي:
- فهم المستندات الطويلة
- الاستدلال المنطقي المعقد
- نشر النماذج الخاصة
- التعاون متعدد العوامل
- البحث الداخلي
- تطبيقات الأعمال الحساسة
يوفر نقطة دخول أصغر للمؤسسات التي تحتاج إلى تحكم محلي بالنموذج ولكنها لا تستطيع تبرير استخدام عقدة فائقة بـ 64 مسرعًا.
حزمة البنية التحتية تصبح أكثر تكاملًا
المنتجات التي تم إصدارها في OCTS 2026 تعرض بنية من ثلاث طبقات.
| الطبقة | المسؤولية الرئيسية |
|---|---|
| منصة البرمجيات | وصول النموذج، توجيه المهام، التنسيق، الصلاحيات، التقييم، ودمج النتائج |
| بنية وحدة المعالجة المركزية التحتية | عمليات العامل، استدعاء الأدوات، تنفيذ الصندوق الرمل، إدارة السياق، والتفاعل مع أنظمة الأعمال |
| عقدة وحدة معالجة الرسوميات الفائقة | استدلال النموذج الكبير، توليد الرموز عالي الإنتاجية، وتنفيذ نماذج متعددة |
لا يعمل النظام بشكل صحيح إلا عندما تعمل الطبقات الثلاث معًا.
لا يمكن لمجموعة سريعة من وحدات معالجة الرسوميات تعويض جدولة العوامل الضعيفة. لا يمكن لرف عالي الكثافة لوحدات المعالجة المركزية تحسين جودة الاستدلال إذا لم يتمكن من الوصول إلى نموذج قوي. لا يمكن لواجهة برمجة تطبيقات دمج معقدة توفير زمن وصول مفيد إذا لم يتم تحميل النماذج الأساسية أو الاتصال بها بكفاءة.
هذا هو التغيير الرئيسي في المنافسة على البنية التحتية للعوامل.
ركز السوق المبكر بشكل أساسي على مدى دعم خادم واحد لنموذج كبير واحد. يحول عصر العوامل الانتباه إلى أداء مستوى النظام:
- كم عدد عمليات العامل التي يمكن أن تبقى متصلة؟
- ما مدى سرعة استدعائها للنماذج والأدوات؟
- هل يمكن تشغيل نماذج متعددة في وقت واحد؟
- كيف تتم مشاركة الذاكرة أو عزلها؟
- كيف يتم تنفيذ الصلاحيات؟
- هل يمكن للمنصة توجيه المهام البسيطة والمعقدة بشكل مختلف؟
- هل يظل النظام مستقرًا تحت التزامن العالي والضغط؟
- ما مدى كفاءته في توليد الرموز المفيدة؟
ما الذي يجب على المؤسسات تقييمه قبل النشر
الأرقام المبهرة التي يقدمها البائعون مفيدة، لكنها غير كافية لاختيار منصة البنية التحتية للعوامل.
يجب أن يقيس تقييم بيئة الإنتاج عبء العمل الكامل.
1. تزامن العوامل
لا تقتصر الإحصاءات على المستخدمين النشطين فحسب، بل تشمل أيضًا:
- العوامل الفرعية لكل مهمة
- عمليات الأدوات
- الصناديق الرملية
- المهام الخلفية
- الجلسات المستمرة
- الزيادات القصوى
- عمليات استرداد الأعطال
2. متطلبات وحدة المعالجة المركزية والذاكرة لكل عامل
يختلف عامل استرجاع خفيف الوزن بشكل كبير في متطلبات الموارد عن عامل برمجة مزود ببيئة تطوير مستقلة.
يجب أن يعكس مقياس "عدد العوامل لكل رف" احتياجات الذاكرة الفعلية ووحدة المعالجة المركزية والتخزين والشبكة للتطبيق المستهدف.
3. زمن استجابة النموذج
يجب قياس ما يلي:
- زمن إنشاء الرمز الأول
- زمن الانتظار بين الرموز
- الوقت الإجمالي للمهمة من البداية إلى النهاية
- زمن الانتظار في قائمة الانتظار
- زمن استجابة استدعاء الأداة
- زمن الاستجابة في سيناريوهات التزامن
لا يضمن انخفاض زمن توليد الرمز في الاختبارات المعيارية انخفاض زمن الاستجابة لسير العمل الشامل.
4. اقتصاديات النماذج المتعددة
على الرغم من أن دمج النماذج المتعددة يمكن أن يحسن الجودة، إلا أنه قد يؤدي إلى مضاعفة تكاليف الاستدلال.
يجب على الفرق مقارنة:
- دقة النموذج الفردي
- دقة النموذج المدمج
- عدد الرموز المستهلكة
- استخدام وحدة معالجة الرسوميات
- وقت الاستجابة
- تكلفة نموذج المراجعة
- معدل الفشل
- تقليل المراجعة البشرية
5. توافق التبريد والمرافق
تتطلب أرفف التبريد السائل الأصلية بنية تحتية متوافقة للمرافق.
يجب التحقق من:
- وحدة توزيع سائل التبريد
- درجة حرارة الإمداد والعودة
- متطلبات الضغط والتدفق
- كشف التسرب
- إجراءات الصيانة
- خطة استعادة الحرارة المهدرة
- قدرة إمداد الطاقة للرف
- تحمل وزن أرضية مركز البيانات
6. قابلية نقل النموذج والمسرع
يمكن لمعايير الوحدة المفتوحة تحسين المرونة، لكن قابلية النقل الفعلية تعتمد على توافق البرامج.
يجب التحقق من:
- إطار النموذج
- محرك الاستدلال
- دعم التكميم
- توفر النواة
- نضج برنامج التشغيل
- أدوات المراقبة
- استبدال المسرع
- إجراءات الترقية
7. الموثوقية والحوكمة
تتطلب العوامل طويلة المدى إدارة صارمة فيما يتعلق بـ:
- المصادقة
- إعداد الصلاحيات
- إدارة المفاتيح
- الوصول إلى الشبكة
- بيئة الصندوق الرمل
- سجلات التدقيق
- تحديد المعدل
- الموافقة البشرية
- توجيه النموذج
- الاحتفاظ بالبيانات
لا ينبغي أن تأتي كثافة البنية التحتية على حساب العزل التشغيلي.
الأسئلة الشائعة
ما هو رف العوامل المبرد بالسائل الأصلي لوحدة المعالجة المركزية من Inspur؟
هو خادم رف كامل لوحدة المعالجة المركزية مصمم حول نظام تبريد، وليس إضافة تبريد سائل إلى تصميم تبريد هواء تقليدي. تدعي Inspur أنه يمكن أن يستوعب ما يصل إلى 384 وحدة معالجة مركزية ويدعم أكثر من 40,000 عامل متزامن.
هل يمكن لرف واحد تشغيل 40,000 عامل ذكاء اصطناعي حقًا؟
هذا الرقم هو أقصى قيمة قدمها تقرير البائع المرجعي لـ Inspur. السعة الفعلية تعتمد على موارد وحدة المعالجة المركزية والذاكرة والتخزين والشبكة وعزل الصندوق الرمل المطلوب لكل عامل.
لماذا يحتاج عامل الذكاء الاصطناعي إلى الكثير من وحدات المعالجة المركزية؟
قد تعمل نماذج اللغة على وحدات معالجة الرسوميات، لكن العوامل تحتاج أيضًا إلى وحدات معالجة مركزية لتنفيذ الجدولة، وتنفيذ الأدوات، وإدارة الحالة، والوصول إلى أنظمة الأعمال، والفحوصات الأمنية، وبيئات وقت التشغيل المعزولة. تزيد سير العمل الطويلة ومتعددة العوامل من هذا الطلب على وحدة المعالجة المركزية.
ما هو OCM 2.0؟
OCM هي بنية وحدة حوسبة مفتوحة لفصل وحدات الحوسبة عن تصميم الرف الأوسع. يدعم نظام OCM 2.0 المبرد بالسائل من Inspur مجموعة متنوعة من بنى وحدة المعالجة المركزية والتبريد السائل لجميع المكونات.
ما هو MetaBrain SD200؟
MetaBrain SD200 هي عقدة الذكاء الاصطناعي الفائقة من Inspur، مصممة لاستدلال النماذج الكبيرة وأعباء عمل النماذج المتعددة. تستخدم بنية توسع بـ 64 مسرعًا، وتدعم العنونة الموحدة والربط عالي السرعة.
ما هو EPAI API لدمج النماذج المتعددة؟
هي واجهة برمجة تطبيقات يمكنها إرسال مهمة إلى نماذج مرشحة متعددة، وجمع إجاباتها المستقلة، واستخدام نماذج المراجعة والدمج لتحديد الإجماع والاختلافات والإغفالات والرؤى الفريدة قبل إنشاء الاستجابة النهائية.
هل دمج النماذج المتعددة أفضل دائمًا من النموذج الفردي؟
لا. يمكن للنماذج المتعددة تحسين أداء المهام المعقدة، ولكنها تزيد من استهلاك الرموز والتكلفة الحاسوبية وزمن الاستجابة. المهام البسيطة مناسبة بشكل أفضل للتوجيه إلى نموذج فردي خفيف الوزن.
ما الفرق بين SD200 والإصدار المؤسسي SD200؟
يستخدم إصدار SD200 الكامل مجال توسع بـ 64 مسرعًا لاستضافة أعباء العمل فائقة الضخامة، بينما يقلص الإصدار المؤسسي SD200 المجال إلى 16 مسرعًا، ويستهدف المؤسسات التي تحتاج إلى نشر نماذج تريليون المعاملات محليًا بحاجز أقل من البنية التحتية.
أدوات ذات صلة
- منصة Inspur EPA للذكاء الاصطناعي على مستوى المؤسسات: تدعم إدارة النماذج، تطوير التطبيقات، الاسترجاع، النشر، وسير عمل النماذج المتعددة.
- حل التبريد السائل من Inspur: حلول بنية تحتية لنشر خوادم وحدة المعالجة المركزية/وحدة معالجة الرسوميات المبردة بالسائل.
- مشروع الحوسبة المفتوحة: مجتمع صناعي لتطوير تصاميم أجهزة مفتوحة للخوادم، الأرفف، مصادر الطاقة، التبريد، ومراكز البيانات.
- Kimi: منصة المساعد والنماذج من شركة Moonshot AI، تم الاستشهاد بنتائج تحسينها في Inspur SD200.
DeepSeek: موفر نماذج الذكاء الاصطناعي، حيث تم إدراج نماذجه مفتوحة المصدر في قائمة التوافق الخاصة بـ SD200.
روابط ذات صلة
- إعلان البنية التحتية للمنصة الذكية من Inspur: يشمل الإعلان الرسمي عن حوامل وحدات المعالجة المركزية المبردة بالسائل، وSD200، والعقدة الفائقة على مستوى المؤسسات.
- إعلان أداء MetaBrain SD200 بزمن استجابة 4.77 مللي ثانية: نظرة تقنية من Inspur حول تحسينات SD200 ونتائج توليد الرموز.
- واجهة برمجة تطبيقات دمج النماذج المتعددة من EPA: شرح رسمي لآليات التوليد الأولي، والمراجعة، والدمج، وتقييم DRACO.
- صفحة منتج Inspur EPA: معلومات المنتج حول منصة تطوير النماذج الكبيرة على مستوى المؤسسات.
- حلول مراكز البيانات المبردة بالسائل من Inspur: معلومات رسمية حول حلول نشر مراكز البيانات المبردة بالسائل.
- قمة تكنولوجيا الحوسبة المفتوحة 2026: صفحة فعاليات OCTS 2026 والإعلانات المتعلقة بالحوسبة مفتوحة المصدر.
- مؤسسة مشروع الحوسبة المفتوحة: معلومات رسمية حول معايير البنية التحتية المفتوحة والمشاريع المجتمعية.
ملخص
عالجت إعلانات Inspur في OCTS 2026 المشكلتين الرئيسيتين الناجمتين عن المنصات الذكية للمؤسسات.
تركز حوامل وحدات المعالجة المركزية المبردة بالسائل أصلاً على قابلية التوسع، مما يوفر بيئة كثيفة لجدولة المنصات الذكية، والأدوات، وصناديق الحماية، وإدارة السياق، وتشغيل العمليات الطويلة. بينما يركز سير عمل دمج النماذج المتعددة في SD200 وEPA على الذكاء، مما يتيح لنماذج كبيرة متعددة التعاون في معالجة المهام المعقدة، مع قيام نموذج المراجعة بدمج المخرجات.
الدرس الأوسع هو: لا يمكن اختزال البنية التحتية للمنصات الذكية في معجل واحد أسرع. تحتاج أنظمة الإنتاج إلى تنسيق
وحدات المعالجة المركزية، ووحدات معالجة الرسوميات، والذاكرة، والوصلات البينية، والتبريد، والتنسيق، والأذونات، والتقييم.
المعيار الأساسي للبنية التحتية للمنصات الذكية يتحول من أداء تشغيل النموذج الفردي، إلى قدرة النظام بأكمله على جدولة آلاف المنصات الذكية بكفاءة وإنتاج نتائج موثوقة باستمرار.