الخلاصة

  • كشف اختبار NCCL شمل جميع وصلات SoftBank عن وصلة تعمل بجزء غير محدد من المعدل الطبيعي، مع بقاء LED أخضر وLink Status في حالة UP والقدرة الضوئية طبيعية. كانت هذه الإشارات صحيحة ضمن نطاقها، لكنها لم تكن دليلاً كافياً لقبول أداء عبء العمل.
  • يذكر عرض JANOG58 كلاً من switch وoptics وNIC والألياف واتساخ connector كسطوح محتملة للعزل، لكنه لا ينشر السبب الجذري أو النسبة الدقيقة أو قيم BER/FEC للحادثة أو إصلاحاً مقاساً. الأرقام ورسوم استبدال optics في الصفحات التفسيرية أمثلة وليست سجل الحادثة.
  • يتطلب قبول نظام rack-scale خط أساس قابلاً لإعادة الاختبار لكل وصلة، ودليلاً مادياً، وهوية واضحة للطوبولوجيا، وتغييراً محدوداً ثم إعادة الاختبار نفسه بعد الإصلاح. عدد وحدات GPU أو ظهور ASN وprefix لا يثبت السعة الداخلية القابلة للتقديم.

تتوزع سلطة القبول قبل أن تتوزع الأدلة. SoftBank تشغّل المنصة، ولذلك تتحكم في الطوبولوجيا، واختبارات القبول، وإدخال workloads، والمراقبة، وقرار إعادة الخدمة. NVIDIA ومورّدو switch وNIC وoptics يتحكمون في التصاميم المرجعية وfirmware وأدوات التشخيص وقوائم الأجزاء المؤهلة وعلاجات الدعم. فريق facility يتحكم في الكهرباء والتبريد السائل والدخول المادي إلى rack.

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

عرض Yasuhiro Uchida وChaocheng Chang الحالة في 16 يوليو 2026 ضمن اليوم الثاني من JANOG58. وتحمل الجلسة الرسمية اسم Rack-Scale GPUサーバーのNW設計と運用までの苦悩. يتتبع العرض النهائي، في 56 صفحة، تصميم أول بيئة rack-scale GPU لدى SoftBank وتشغيلها، بما في ذلك الشبكات والطاقة والتبريد والكابلات ووحدة الخدمة.

في صفحة فحص الأداء، أجرت SoftBank اختبار NCCL على جميع الوصلات. وجدت وصلة لا تقدم إلا «جزءاً» من الاتصال الطبيعي. لا يحدد العرض هذا الجزء، ولا يقول إنه الثلث. وفي الصفحة نفسها، بقي LED أخضر، وLink Status هو UP، والقدرة الضوئية ضمن المجال الطبيعي.

هذه ليست إشارات كاذبة. LED يبيّن أن دائرة الحالة رأت الشرط الذي صممت لقياسه. Link Status يبيّن أن الواجهة وصلت إلى الحالة الإدارية أو البروتوكولية المطلوبة. والقدرة الضوئية الطبيعية تعني أن الضوء المستقبَل لم يتجاوز حد الإنذار المختار. لا يضمن أي منها سلامة كل lane، أو هامش تصحيح الأخطاء، أو المعدل end-to-end الذي يحتاجه NCCL collective.

لذلك لا تسقط الحادثة قيمة state أو optical power. إنها تحدد فقط نهاية سلطتهما: يثبتان الوجود وبعض الشروط المحلية، لا السعة القابلة للبيع.

يوجد إلى جانب العرض النهائي preread من تسع صفحات، ويحمل رابطه الرسمي اسم الملف j56-lt4.pdf. يتناول ذلك المستند switches مبردة بالسائل، وواجهات cooling خاصة، ومسائل standardisation. وهو مفيد لفهم تبعية المنشأة، لكنه ليس تقريراً أقصر عن الوصلة المتدهورة، ولا يملأ القيم أو خطوات الإصلاح المفقودة.

حجم النظام يوضح كلفة الفجوة. يصف العرض rack من نوع GB200 NVL72 يضم 18 compute tray، وفي كل tray أربع وحدات B200 GPU، وتسع switch tray، وفي كل منها جهازا NVSwitch. ويبلغ المجموع 72 GPU و36 CPU، مع استهلاك يتجاوز 100 kW بحسب العرض. توثق NVIDIA الشكل المرجعي نفسه، مع passive cable backplane وpower shelves وbusbar وmanifolds للتبريد السائل.

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

تقسم SoftBank الشبكة إلى ثلاثة fabrics. يحمل Compute Fabric حركة scale-out بين GPU. يحمل Converged Fabric حركة front-end وstorage وNCCL bootstrap. ويحمل OOB Fabric إدارة switches وservers، ومراقبة facility، وإدارة NVSwitch. هذا الفصل يوضح المسؤوليات، لكنه لا يجعل الكابلات والطاقة والتبريد وعمليات الإدارة المشتركة مستقلة تلقائياً.

يعرض قسم OOB حداً مهماً. قد تصبح الاتصالات عبر management port إلى leaf switches نقطة فشل مفردة. ويمكن للوصول إلى loopbacks عبر underlay الخاص بـCompute Fabric أن يحسن reachability التشغيلية بتكلفة كابلات أقل. لكن العرض يقول صراحة إن ذلك لا يستبدل OOB. المسار الذي يساعد في إصلاح production fabric لا ينبغي أن يكون المسار الوحيد الذي يختفي عند تعطل ذلك fabric.

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

بعد اكتشاف العرض، يسرد deck سلسلة محتملة للتشخيص: switch وoptics وNIC والألياف وconnector متسخ. هذه قائمة بالحدود التي يجب فحصها، وليست تعييناً للسبب. يمكن أن يقع الخطأ عند transmitter أو receiver أو lane أو module أو connector أو cable، ثم يظهر كهبوط في throughput.

تشرح الصفحات التالية pre-FEC BER وpost-FEC BER وFEC histogram. وتعرض patterns طبيعية وغير طبيعية ورسماً تعليمياً يتضمن استبدال optics. لا تسجل تلك الصفحات قيم الوصلة الفعلية. ولا تقول إن الحادثة وصلت إلى bins المعروضة، أو إن تغيير module أعاد المعدل الطبيعي.

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

لا ينشر السجل benchmark قبل الإصلاح وبعده، ولا سبباً جذرياً، ولا مكوناً مسؤولاً، ولا أثراً على tenant. ولذلك لا يمكن تحويل الوصلة المتدهورة إلى ادعاء بانقطاع production، كما لا يمكن تحويل رسم الاستبدال إلى نتيجة إصلاح.

ينشر العرض اتجاهاً تشغيلياً أوضح. يصف Link UP = OK بأنه غير كاف، ويدعو إلى فهم مؤشرات مادية مثل BER وFEC، وجمع وتحليل logs الخاصة بالواجهات وoptics أسبوعياً وشهرياً، والانتقال من انتظار interface down إلى البحث عن إشارات التدهور.

هذا تصميم مراقبة، لا نجاح مثبت للصيانة التنبؤية. لا توجد thresholds منشورة، ولا سياسة retention، ولا معدل false positive، ولا فشل اكتشف مسبقاً، ولا تحسن مقاس في availability. الاستنتاج القابل للدفاع هو أن المشغّل حدد نقطة عمياء واختار مؤشرات أقرب إلى الآلية المادية.

تغيّر وحدة الخدمة توزيع الكلفة. يقارن deck بين تقديم الخدمة بوحدة rack أو tray أو GPU. ويقول إن SoftBank تقدم حالياً وحدات rack وtray بعد تقييم المقايضات. أما وحدة GPU فهي خيار جرى تحليله وليست العرض الحالي المعلن.

تقديم rack كامل يبسط الفصل لعميل واحد، لكنه ينقل إليه تبعيات مشتركة مثل Compute Fabric وCDU وNVSwitch وcompute trays وbusbar. تقديم tray يناسب عميلاً أصغر، لكنه يتطلب NVLink partition. وتقول SoftBank إن عملية إدارة NVSwitch مشتركة داخل rack وتمثل single point of failure؛ ويتطلب SLA أعلى redundancy على مستوى rack أو scalable unit.

تحدد هذه الخيارات من يتحمل المخاطر. تدفع SoftBank ثمن الكابلات الكثيفة وoptics وswitches وspares وlab ممثل والطاقة والتبريد والعمل المتخصص عبر حدود الموردين. ويدفع صاحب workload ثمن jobs المتأخرة وGPU الخاملة إذا عبرت الوصلة المتدهورة بوابة قبول اسمية. وقد لا يستطيع مشترٍ أصغر توفير rack تجريبي وقطع احتياطية، فيزداد اعتماده على حكم المورّد المتكامل.

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

في ديسمبر 2025، قالت SoftBank إن منصة تضم 1,224 من Blackwell GPU بدأت العمل في 22 ديسمبر، وإن التوسع إلى أكثر من 4,000 مخطط له. الرقم الأول بيان نشر من المشغّل، والثاني خطة. لا يقيس أي منهما عدد الوصلات التي اجتازت baseline قبول في لحظة معينة.

ولا يمكن استعارة دليل من نظام آخر. يعرّف TOP500 نظام CHIE-4 التابع لـSoftBank بأنه DGX B200 يستخدم InfiniBand NDR400. ترتيبه يخص ذلك النظام ولا يثبت أداء GB200 NVL72 المعروض في JANOG58.

البديل المضاد القابل للاختبار يبدأ من سجل القبول. لكل وصلة ضرورية، يحتفظ operator بتوزيع NCCL متوقع أو baseline workload قابل للنقل. وترتبط به حالة link، والقدرة الضوئية، وlane counters، وpre/post-FEC BER، وFEC histogram، وهوية module والألياف وطرفي switch/NIC وfirmware والطوبولوجيا والوقت.

عند حدوث انحراف، يغيّر الفريق عنصراً واحداً محدوداً في كل مرة، ويحفظ counters قبل التغيير وبعده. ثم يعيد اختبار جميع الوصلات بالشروط نفسها. ويُسجل trend وalert وticket وتغيير component وverified restoration كوقائع منفصلة.

لا يحتاج tenant بالضرورة إلى كل counter خاص بالمورّد. لكن service owner يجب أن يستطيع إثبات أن الوصلة حققت المعدل المعلن عند القبول، وأنها عادت إلى التوزيع نفسه بعد التدخل. إغلاق ticket بعد تغيير جزء لا يثبت عودة workload capacity.

تبقى الموارد الرقمية والتوجيه طبقة أخرى. قد تظل prefixes الخاصة بالإدارة والعملاء قابلة للوصول بينما يقدم collective path الداخلي أداء أقل. يثبت ASN وBGP هوية routing والوصول إلى edge. ولا يمنحان RIR أو standards body أو مؤتمر صلاحية إعلان fabric داخل rack صالحاً للخدمة.

تتيح JANOG نشر السجل وفحصه، وهذه سلطة نافعة ومحددة. لا تشغّل JANOG المنصة ولا توقع قبولها. الدرس من الحالة ليس أن BER يلغي state، بل أن state والدليل المادي وأداء workload يجب أن يغلقوا دورة واحدة قابلة للإعادة. حالة up لا تمنح تفويضاً ولا تثبت السعة.

المصادر