Ultra Ethernet Consortium: إعادة بناء الإيثرنت للذكاء الاصطناعي على نطاق واسع

الملخص التنفيذي

• Ultra Ethernet Consortium هو مشروع تابع لمؤسسة Joint Development Foundation أُطلق في 19 يوليو 2023 من قِبل AMD وArista Networks وBroadcom وCisco وEviden/Atos وHewlett Packard Enterprise وIntel وMeta وMicrosoft. وهو اتحاد مواصفات صناعي، وليس شركة تجارية أو مشغل شبكات تقليدي.
• نطاق UEC أوسع من مجرد رابط إيثرنت أسرع أو بديل لـ RoCE. تغطي مواصفاته الإصدار 1.0.3 المكونة من 573 صفحة طبقات البرمجيات والنقل والشبكة والرابط والطبقة المادية، مع أعمال الإدارة والتخزين والاختبار والامتثال حول المجموعة الأساسية.
• يجمع Ultra Ethernet Transport بين عدة أنماط للتسليم، وتعدد المسارات على مستوى الرزم، وإعادة الإرسال الانتقائي، والتحكم في الازدحام القائم على المرسل والمستقبل، وECN، وقص الرزم الاختياري، وإعادة محاولة الرابط الاختيارية، والتحكم في التدفق القائم على الرصيد الاختياري، وأمان النقل من طرف إلى طرف الاختياري.
• تُظهر منتجات وعروض توضيحية من AMD وBroadcom وNokia وKeysight أن التنفيذ قد بدأ، لكن الامتثال العلني لا يزال يعتمد بشكل أساسي على الإقرار الذاتي للمنفذين، ولم يتم نشر سجل اعتماد مستقل شامل أو إحصاء واسع النطاق للنشر الفعلي.
• تكمن الفرصة الاستراتيجية لـ UEC في قاعدة الإيثرنت المثبتة وسلسلة التوريد متعددة البائعين. وتتمثل مخاطره الرئيسية في تعقيد نقاط النهاية، وتجزئة الميزات الاختيارية، والتزامات براءات الاختراع بنظام RAND، وعدم نضج الإدارة والاختبار، والفجوة بين نشر المواصفات والتحقق من التشغيل البيني في بيئة الإنتاج.

لماذا حوّل الذكاء الاصطناعي الشبكة إلى جزء من الحاسوب

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

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

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

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

يشرح هذا التمييز لماذا يهم UEC البنية التحتية الرقمية. فالمشروع لا يمتلك مسرعات أو مصانع أو مراكز بيانات أو مناطق سحابية. إنه يحدد العقود التي يمكن للشركات الأعضاء والمنفذين الآخرين وضعها داخل بطاقات NIC ورقاقات المحولات (switch ASICs) والأنظمة والمشغلات والمكتبات ومعدات الاختبار. ولن يتحقق تأثيره إلا عندما تتبادل هذه المنتجات المستقلة حركة المرور بشكل صحيح في ظل الفشل والازدحام والترقية وظروف البائعين المختلطين.

ما هو UEC — وما ليس هو

Ultra Ethernet Consortium هو الاسم العام لمشروع رسمي تُسمى سلسلته القانونية Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. يضع هيكل السلسلة المشروع داخل مؤسسة Joint Development Foundation وعائلة Linux Foundation الأوسع. وهو يمنح المشاركين إطاراً قانونياً قائماً مسبقاً للعضوية والحوكمة والملكية الفكرية والتمويل والعلاقات الخارجية دون الحاجة إلى إنشاء شركة مستقلة جديدة.

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

كما أن UEC ليس مطابقاً لـ Ultra Ethernet Transport. فـ UET هو بنية النقل في مركز المواصفات. وعمل الاتحاد أوسع من ذلك، فهو يشمل الربط البرمجي مع libfabric ودلالات الرزم والرسائل وافتراضات الشبكة وخيارات طبقة الرابط ومتطلبات الطبقة المادية والإدارة ومواءمة التخزين والأداء والتصحيح والامتثال والاختبار. واختزال المشروع إلى "بروتوكول RDMA جديد" يُخفي التصميم عبر الطبقات الذي يجعله طموحاً وصعباً.

كما أن UEC ليس مجموعة عمل IEEE 802.3. حيث تطور IEEE 802.3 معايير الإيثرنت الأساسية للتحكم في النفاذ للوسط (MAC) والطبقة المادية من خلال عمليتها الرسمية الخاصة. ويعتمد UEC على ذلك النظام البيئي ويحتفظ باتصال، لكنه لا يحل محله. وينطبق نفس الحد على آليات IETF تحت UET، بما في ذلك IPv4 وIPv6 وإشعار الازدحام الصريح (ECN)؛ وعلى نظام OpenFabrics البيئي الذي يحتفظ بـ libfabric؛ وعلى المنظمات التي تعمل على التخزين والأجهزة المفتوحة والوصلات البينية للمسرعات.

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

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

الائتلاف المؤسس من تسع شركات

أُعلن عن الاتحاد في 19 يوليو 2023 من قِبل تسع منظمات تتموضع في طبقات مختلفة من سلسلة توريد الذكاء الاصطناعي والحوسبة عالية الأداء: AMD وArista Networks وBroadcom وCisco وEviden المرتبطة آنذاك بـ Atos وHewlett Packard Enterprise وIntel وMeta وMicrosoft. كان ذلك الاتساع أصلاً استراتيجياً منذ البداية. فنظام نقل يتم تطويره فقط من قِبل بائعي المحولات قد يُهمل قيود التطبيقات ونقاط النهاية. وتصميم تقوده فقط شركات المسرعات قد يُحسن بإحكام حول نظام أجهزة واحد. ومشروع قائم على السحابة فقط قد يفتقر إلى الخبرة في السيليكون والبصريات والأنظمة اللازمة لتحويل البنية إلى منتجات.

جلبت AMD المعالجات والمسرعات وشبكات نقاط النهاية. وجلبت Arista وCisco خبرة في تبديل الإيثرنت واسع النطاق والتشغيل. وساهمت Broadcom بسيليكون التبديل وبطاقات NIC و SerDes عالية السرعة. وجلبت HPE وEviden أنظمة HPC وسجلاً في الوصلات البينية المتخصصة. وساهمت Intel بالمعالجات وخبرة الإيثرنت والبرمجيات. ومثّلت Meta وMicrosoft مشغلين فائقي الضخامة لديهم حوافز مباشرة لزيادة استخدام مجموعات الذكاء الاصطناعي الكبيرة وتقليل الاعتماد على مورد متكامل واحد.

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

توفر تقنية Slingshot من HPE مثالاً مفيداً على السلالة التقنية. فـ Slingshot هو نسيج HPC متوافق مع الإيثرنت يتميز بالتوجيه التكيفي وميزات إدارة الازدحام. وقد ذكرت تعليقات مرتبطة بـ HPE أنه تم تقديم مواصفة إيثرنت لـ HPC إلى UEC، وقدرت أن حصة كبيرة من UET مستمدة من أفكار النقل في Slingshot. لم يتم التحقق من النسبة المئوية الدقيقة بشكل مستقل، ولا ينبغي اعتبارها محاسبة للاتحاد. لكن النقطة الأوسع مدعومة جيداً: لم يبدأ UEC من صفحة بيضاء، بل اعتمد على خبرة إنتاجية في HPC وشبكات السحابة وRDMA والإيثرنت.

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

سلسلة قانونية صُممت ليتعاون فيها المتنافسون

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

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

كان الرئيس الأصلي Brad Booth من Meta. وتُدرج مواصفات 1.0.3 الحالية J Metz من AMD كرئيس، وBarry Davis من HPE كنائب للرئيس، وHugh Holbrook من Arista كرئيس للجنة الاستشارية الفنية، وPuneet Agarwal من Marvell كنائب رئيس TAC. كما تم إدراج Paul Congdon كمحرر للمواصفات. وتحدد الوثيقة أيضاً قادة ومؤلفين عبر أعمال الطبقة المادية والرابط والنقل والبرمجيات. ويُسمي جدول أعمال قمة 2026 قادة تشغيليين إضافيين. ولا تحل أدوار القمة هذه بالضرورة محل الألقاب الرسمية في المواصفات؛ ولا توفر المادة العامة مخططاً تنظيمياً كاملاً وحالياً.

تظهر ثلاث فئات للعضوية في الميثاق: Steering وGeneral وContributor. يشارك أعضاء Steering في الحوكمة ويعينون عادة ممثلين في لجنة التوجيه. ويمكن للأعضاء General العمل عبر المجموعات التقنية لكنهم لا يجلسون في لجنة التوجيه. ويشارك أعضاء Contributor في مجموعات مختارة ويفتقرون إلى حقوق التصويت بالأغلبية العظمى. وتُسوق صفحة العضوية العامة الحالية مستويي General وContributor، بأسعار مشروع سنوية تبلغ 20,000 دولار أمريكي و5,000 دولار أمريكي على التوالي، بالإضافة إلى عضوية Linux Foundation. وهي لا تشرح بوضوح مسار القبول أو السعر الحالي لوضع Steering.

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

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

من انطلاقة بأربع مجموعات إلى مواصفة من 573 صفحة

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

بحلول ديسمبر 2023، أبلغ UEC عن حوالي 40 شركة وأكثر من 300 فرد. وكان قد أنشأ لجنة استشارية فنية وتوسع إلى ثماني مجموعات عمل. وكان غرض TAC هو التماسك الهندسي: فلا يمكن لتصميم النقل أن يفترض سلوك محول أو طريقة إشارة أو واجهة برمجة تطبيقات لم توافق مجموعة أخرى على دعمها. وفي مارس 2024، أبلغ الاتحاد عن 55 شركة وأكثر من 750 مشاركاً نشطاً، ونشر وصفاً أكثر وضوحاً لمعماريته المقصودة.

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

نما الامتداد المؤسسي جنباً إلى جنب مع العمل التقني. أبلغ UEC عن 1,193 مشاركاً نشطاً في يوليو 2024 وعن 97 منظمة عضو في أغسطس. هذه أرقام اتحاد مؤرخة تستند إلى تعريفات ليست علنية بالكامل، ولا ينبغي إضافتها آلياً إلى إعلانات لاحقة. في 2025، قال UEC إن 27 شركة جديدة انضمت، لكن حالات المغادرة والاندماج وتداخل فترات الإبلاغ تمنع هذا التصريح من تحديد إجمالي حالي دقيق. ويذكر الموقع نفسه أنه لا يتم عرض جميع الأعضاء.

أصدر الاتحاد مواصفة Ultra Ethernet 1.0 في 11 يونيو 2025. كانت تلك هي اللحظة التي تحول فيها UEC من خارطة طريق إلى خط أساس تنفيذي علني. وتبع ذلك الإصدار 1.0.1 في سبتمبر وصحح خوارزمية مصدر التحكم في الازدحام برصيد المستقبل وقضايا تحريرية. ووصل الإصدار 1.0.2 في يناير 2026 وصحح خوارزميات إدارة الازدحام، مع أن الوثائق الرسمية تختلف حول ما إذا كان تاريخ إصداره 21 أو 28 يناير. ينبغي أن يظل هذا التناقض مرئياً بدلاً من حله بصمت.

الإصدار 1.0.3، الذي نُشر في 16 يوليو 2026، هو المرجع الحالي عند نقطة توقف البحث. يمتد على 573 صفحة ويضيف دعماً لإشارات 200 جيجابت/ثانية لكل مسار وقدرة تفاوض بوليانية. كما تُحدد ملاحظات الإصدار تصحيحات مطلوبة تتعلق بتسليم الرزم وأرصدة الازدحام وإعادة محاولة طبقة الرابط ومجموعات التحكم المرتبة في الطبقة المادية، إلى جانب توضيحات لأمن النقل والعمليات الذرية والرزم المقصوصة. الفرق بين التصحيحات المطلوبة والتوضيحات التحريرية مهم: فبعض التغييرات تؤثر على السلوك المطابق وبالتالي على صيانة التنفيذ.

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

بنية واحدة عبر خمس طبقات وظيفية

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

في الأعلى، تتفاعل أطر الذكاء الاصطناعي وMPI وSHMEM ومكتبات العمليات الجماعية عبر واجهات OpenFabrics، وخاصة libfabric. وتترجم طبقة UET Semantic Services Sublayer عمليات التطبيق إلى معاملات نقل. وتقرر طبقة Packet Delivery Sublayer كيفية تجزئة الرسائل وترتيبها وتأكيد استلامها واستعادتها. ويتحكم إدارة الازدحام في كمية البيانات التي تدخل النسيج وكيفية توزيع حركة المرور بين المسارات. ويحمي أمن النقل الاختياري حركة المرور من نقطة نهاية إلى أخرى. ويوفر IPv4 أو IPv6 القياسي توجيه طبقة الشبكة. ويؤمن الإيثرنت الرابط، مع قص الرزم الاختياري، وإعادة محاولة طبقة الرابط، والتحكم في التدفق القائم على الرصيد، والتفاوض على الميزات.

وتُعرف الطبقة المادية الإحصائيات ومتطلبات الإشارة عند 100 أو 200 جيجابت/ثانية لكل مسار.

يحافظ هذا الهيكل على أجزاء مهمة من الشبكة الحالية. فلا يعرف UEC بديلاً لتوجيه IP. وهو يتوقع توجيهاً تقليدياً متعدد المسارات متساوي التكلفة (ECMP) ومحولات قادرة على ECN. ويبقى جزء كبير من الذكاء في نقاط نهاية النسيج، التي تتلاعب بالاعتلاج، وتتابع حالة النقل، وتضع البيانات، وتستجيب لإشارات الازدحام. ويمكن للمحولات المحسنة إضافة وظائف، لكن التصميم لا يتطلب من كل عملية نشر استبدال نسيجها بالكامل قبل أن تمر حركة UET.

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

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

العقد البرمجي: libfabric بدلاً من واجهة برمجة تطبيقات مملوكة

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

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

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

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

يعتمد المشروع على نظام OpenFabrics البيئي لأنه لا يمتلك libfabric. وتوضح هذه العلاقة سمة أوسع لـ UEC: فالبنية مجمعة من مكونات تُدار في أماكن مختلفة. ويمكن لـ UEC تعريف كيفية تخطيط نقله إلى libfabric، لكن يجب عليه التنسيق مع القائمين على واجهة برمجة التطبيقات ومستخدميها. وتوجد تبعيات مماثلة مع IEEE Ethernet وشبكات IETF ومنظمات التخزين وأنظمة تشغيل البائعين.

نقاط نهاية النسيج وملامح أعباء العمل

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

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

يعرف UEC ثلاثة ملامح تنفيذية: AI Base وAI Full وHPC. وهي ليست أنواع شبكات منفصلة، بل حزم تحدد الوظائف التي يجب على التنفيذ دعمها. والغرض من AI Base هو تغطية اتصالات الذكاء الاصطناعي الشائعة بتكلفة تنفيذ وحالة أقل. ويضيف AI Full وظائف مثل الإرسالات القابلة للتأجيل، والمطابقة التامة، وعمليات الجلب أو المقارنة الذرية. ويتضمن ملف HPC معظم قدرات AI Full، ويستبعد الإرسال القابل للتأجيل، ويركز بشكل أكبر على الترتيب والرسائل القصيرة ودلالات HPC.

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

المصطلحات هي بالفعل علامة تحذير. فالمواصفة الرسمية 1.0.3 تستخدم AI Base وAI Full وHPC. بينما يستخدم ملف readme منفصل للامتثال من 2025 AI Base وAI Extended وHPC. والتفسير الأفضل دعماً هو أن "AI Full" هو الحالي وأن مواد الامتثال قديمة أو غير متسقة. وإلى أن يتم تصحيح حزمة الاختبار العامة، ينبغي على البائعين والمشترين تحديد كل من إصدار المواصفة ولغة الملف الشخصي الدقيقة وراء أي ادعاء.

من نية التطبيق إلى تسليم الرزم

داخل UET، تحمل طبقة Semantic Services Sublayer نية التطبيق. وهي تعرف هوية الرسالة، وعنونة الذواكر الوسيطة، والعمليات الموسومة وغير الموسومة، والوصول إلى الذاكرة عن بُعد، والعمليات الذرية، وسلوك الإكمال، ومعرفات المهمة، وتفويض الذواكر الوسيطة، والاستجابات، والأخطاء. ثم تحدد طبقة Packet Delivery Sublayer كيف تصبح تلك النية رزماً وكيف تصل تلك الرزم إلى نقطة نهاية أخرى.

بالنسبة للأنماط الموثوقة، تنشئ نقاط النهاية سياقات تسليم الرزم (Packet Delivery Contexts). ويحتوي PDC على حالة مثل أرقام تسلسل الرزم والتأكيدات واكتشاف التكرار ونمط الترتيب ومعلومات الازدحام وحالة اتجاه العودة وفئة الحركة. ويرتبط PDC واحد بنمط تسليم واحد وفئة حركة واحدة، ويمكن أن توجد عدة PDCs بين نفس زوجي FEPs.

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

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

أما التسليم المرتب الموثوق (Reliable Ordered Delivery أو ROD) فيوفر تسليماً لمرة واحدة ومرتباً حسب التسلسل. وهو يستخدم مساراً واحداً وقيمة اعتلاج واحدة، ويتجاهل الرزم خارج الترتيب، ويعتمد على استعادة Go-Back-N التي تبدأ من أول تسلسل مفقود. يبدو هذا أقل تطوراً من RUD، لكنه يحافظ على الدلالات المطلوبة للعمليات التي يكون فيها الترتيب الصارم مهماً. ويعامل UEC الترتيب كمتطلب تطبيقي بدلاً من افتراض أن كل عملية نقل يجب أن تدفع ثمنه.

أما التسليم غير المرتب الموثوق للعمليات المتسامحة مع التكرار (Reliable Unordered Delivery for Idempotent Operations أو RUDI) فيقدم مقايضة مختلفة. فهو يوفر تسليماً لمرة واحدة على الأقل ويسمح بالتكرارات، مما يقلل من حالة التسلسل والتأكيد العادية عند الهدف. ويمكن أن يكون مفيداً عندما لا يؤدي تكرار العملية إلى تغيير النتيجة النهائية، مثل بعض حركات الذاكرة عن بُعد المحددة المتبوعة بحاجز منفصل. وهو خطير إذا طُبق بشكل خاطئ؛ فطبقة الرزم لا تستنتج ما إذا كانت العملية متسامحة مع التكرار، بل على البرمجيات أن تتخذ هذا القرار. واستخدام RUDI لعملية غير متسامحة مع التكرار يمكن أن ينتج حالة تطبيق غير صالحة.

يوفر التسليم غير الموثوق غير المرتب (Unreliable Unordered Delivery أو UUD) رزم بيانات بأفضل جهد دون ضمانات الموثوقية أو الترتيب العادية. وهو ينتمي إلى نفس الإطار الدلالي لكنه لا يحمل متطلبات التحكم في الازدحام نفسها مثل RUD وROD. ويجب على التطبيقات تجنب الإضرار بحركة المرور الخاضعة للتحكم في الازدحام عندما يتشارك UUD في الطوابير أو فئات الحركة.

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

توزيع الرزم: استخدام النسيج بدلاً من مسار واحد محظوظ

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

يعالج UET هذا بتغيير الاعتلاج على مستوى دقة الرزمة. حيث يمكن للمرسل استخدام عشرات أو مئات قيم الاعتلاج، مما يسمح لآليات ECMP الموجودة في المحولات بتوزيع الرزم على عدة مسارات. وتُزود طبقة Packet Delivery Sublayer معلومات التسلسل؛ وتختار طبقة Congestion Management Sublayer الاعتلاج أو المسار؛ وتقوم المحولات بتجزئتها العادية؛ وتُعلم التغذية الراجعة المرسل بقيم الاعتلاج التي تبدو مزدحمة.

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

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

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

ثلاث آليات ازدحام لثلاثة اختناقات مختلفة

لا يعرف UEC خوارزمية ازدحام واحدة شاملة. بل يميز بين الازدحام في قلب الشبكة، والازدحام المتجه نحو المستقبل (incast)، والتخزين المؤقت المحدود لنقطة النهاية.

التحكم في الازدحام بإشارة الشبكة (Network-signal Congestion Control أو NSCC) هو قائم على المصدر. حيث يحتفظ المرسل بنافذة ازدحام، ويقدر البايتات قيد الطيران، ويعدل النافذة باستخدام التأكيدات والتأكيدات السلبية والمهل الزمنية وزمن الانتظار وإشارات الشبكة مثل ECN. وينسق سلوك النافذة مع تعدد المسارات على مستوى الرزم. ويرى UEC أن النافذة توقف بشكل طبيعي قبول البيانات عندما تفشل الرزم في مغادرة الشبكة، بينما يمكن لمتحكم قائم على المعدل فقط أن يسيء تفسير التغذية الراجعة المفقودة.

هذه هي الحجة الهندسية للاتحاد، وليست دليلاً مستقلاً على أن كل تنفيذ لـ NSCC يتفوق على DCQCN أو متحكمات ازدحام RoCE الأخرى. فالنتائج تعتمد على تفاصيل الخوارزمية، ووسم المحول، والهيكل، وأنماط حركة المرور، واختيارات المعاملات. لذا، فإن "استخدام NSCC" ليس ادعاء أداء كافياً بذاته.

يستهدف التحكم في الازدحام برصيد المستقبل (Receiver-credit Congestion Control أو RCCC) الازدحام المتجه نحو المستقبل. فعندما ترسل عدة مصادر في آن واحد إلى وجهة واحدة، يمكن أن يصبح الرابط الأخير هو عنق الزجاجة حتى لو كان قلب الشبكة غير مزدحم. ويتتبع المستقبل الطلب ويوزع الأرصدة بين المرسلين، منسقاً وصول التجميع ومغيراً نافذة كل مصدر الفعالة وفقاً للمنافسة. ويمكن أن يعمل RCCC إلى جانب NSCC لأن ازدحام المستقبل وازدحام القلب مشكلتان مختلفتان.

يستخدم التحكم في تدفق النقل (Transport Flow Control أو TFC) أيضاً الأرصدة لكنه يخدم خدمات نقطة إلى نقطة ذات مخزن مؤقت محدود. والغرض منه هو المنع المباشر لفيضان مخزن المستقبل المؤقت عندما يكون التسامح مع الفقد منخفضاً. ويمكن استخدامه مع أو بدون تعدد المسارات. إن معاملة كل آلية رصيد على أنها نفس الشيء من شأنها أن تحجب مجالات الفشل المتميزة التي يُقصد بكل منها السيطرة عليها.

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

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

قص الرزم واستعادة الفقد بدقة

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

هذا أكثر إفادة من وسمة ECN. فـ ECN تقول إنه تمت مواجهة ازدحام؛ أما القص فيحدد رزمة لم تنجُ حمولتها. وبالدمج مع RUD وإعادة الإرسال الانتقائي، يمكن أن يسرع هذا التعافي دون انتظار مهلة زمنية أو إعادة إرسال تسلسل كبير بعد فقدان واحد.

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

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

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

استعادة الرابط والأرصدة والتفاوض على الميزات

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

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

يعمل التحكم في التدفق القائم على الرصيد (Credit-Based Flow Control أو CBFC) على مستوى كل قناة افتراضية على مستوى الرابط. وهو يخبر المرسل بكمية سعة الاستقبال المتبقية ويمكن أن يوفر تحكماً أدق من الإيقاف المؤقت العريض بالأولوية. ويقدمه UEC كطريقة لدعم سلوك شبه غير فاقد متحكم به دون اشتراط أن يكون كل نشر لـ UET غير فاقد عالمياً. وCBFC اختياري، وصُمم UET للعمل عبر شبكات ذات أفضل جهد.

لا ينبغي اعتبار CBFC اسماً آخر لـ Priority Flow Control. فالآليتان تختلفان في الإشارة والدقة، حتى وإن سعت كلتاهما إلى منع فيضان المخزن المؤقت. ولا يزال CBFC يتطلب تكويناً متسقاً وتسليماً صحيحاً لإطارات التحكم الخاصة به. كما يمكن للأرصدة المحلية أن تتفاعل مع نوافذ طرف إلى طرف وأرصدة المستقبل، مما يخلق عدة حلقات تحكم متداخلة.

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

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

الإشارات المادية عند 100 و200 جيجابت لكل مسار

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

يتناول عمل PHY في UEC أيضاً إحصائيات تصحيح الأخطاء الأمامي (FEC)، ونسب كلمات الشيفرة المصححة وغير القابلة للتصحيح، ومجموعات التحكم المرتبة، وتقارير جودة الرابط، والتفاعل بين الأخطاء المادية وLLR. هذه التفاصيل مهمة لأن قرارات التعافي للنقل تعتمد على ما يمكن للطبقات الدنيا ملاحظته والإبلاغ عنه.

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

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

أمن النقل الاختياري من طرف إلى طرف

توفر طبقة أمن النقل الفرعية (Transport Security Sublayer أو TSS) حماية اختيارية من نقطة نهاية إلى أخرى. ولا يتطلب نموذج تهديدها أن تكون المحولات موثوقة. ويمكنها أن توفر السرية والسلامة والحماية من الإعادة ومهمة العزل ومجالات الأمان والمفاتيح الجماعية وتدوير المفاتيح والتكامل مع جذور ثقة الأجهزة.

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

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

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

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

ما الذي يعنيه حاليًا "متوافق مع UEC"

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

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

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

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

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

وثيقة مفتوحة مع التزامات براءات اختراع بنظام RAND

مواصفة Ultra Ethernet 1.0.3 قابلة للتنزيل علناً وموزعة بموجب رخصة Creative Commons Attribution-NoDerivatives 4.0. وهذا يسمح بإعادة التوزيع مع الإسناد لكنه لا يسمح بتوزيع نسخ معدلة بموجب الرخصة. والأهم من ذلك، أن الوصول إلى حق المؤلف والوصول إلى براءة الاختراع منفصلان.

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

يحتفظ UEC بسجل علني لإقرارات المطالبات الضرورية (Necessary Claims). وعند نقطة التوقف، كانت الإقرارات المرتبطة بـ Broadcom وMicrosoft وHuawei وQualcomm وAMD وHPE وGoogle وMarvell وغيرهم مرئية، بما في ذلك إيداعات مرتبطة بأعمال 1.1 المستقبلية. ويحسن السجل الشفافية بإظهار أن المنفذين قد يحتاجون إلى تقصي الملكية الفكرية قبل بناء أو شحن منتج.

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

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

لذا، فالوصف الصادق هو "منشور علناً ومتعدد البائعين، مع التزامات براءات اختراع بنظام RAND"، وليس خالياً من الإتاوات عالمياً. وتحتاج فرق المشتريات إلى الملف التقني ومسار الترخيص معاً.

الموجة الأولى من المنتجات والاختبارات

أصبح دليل التنفيذ مرئياً حوالي الإصدار 1.0، لكن الأمثلة تشغل مراحل مختلفة من النضج.

جعلت AMD بطاقة Pollara 400 AI NIC متاحة تجارياً في أبريل 2025 ووصفتها بأنها مصممة حول قدرات UEC قيد التطوير. Pollara هي منصة نقاط نهاية قابلة للبرمجة وإشارة مهمة على أن النقل قد انتقل إلى أجهزة مشحونة. لكن الصياغة مهمة: التصميم لميزات UEC المتطورة ليس مثل الاعتماد المستقل مقابل كل متطلب 1.0.3 نهائي.

أعلنت Broadcom عن Tomahawk 6 في يونيو 2025 كرقاقة تبديل بسعة 102.4 تيرابت/ثانية مع ميزات ذات صلة بأنسجة بمقياس UEC. وفي أكتوبر، أعلنت عن بطاقة Thor Ultra 800G NIC وذكرت أن التصميم وفر امتثالاً كاملاً لميزات UEC. هذا ادعاء بائع كبير، لكن الدليل العلني لا يحوله إلى شهادة اتحاد مستقلة. وينبغي تحديد عينات المنتج ونضج البرمجيات ودعم الملف الدقيق بشكل منفصل.

أعلنت Nokia وKeysight عن عرض توضيحي لحركة UET من طرف إلى طرف في أكتوبر 2025 عبر عائلتي المحولات 7220 و7250 من Nokia لمراكز البيانات بسرعة 800 جيجابت إيثرنت. ووفرت Keysight توليد حركة المرور والتحقق. ويظهر الاختبار أن حركة UET يمكنها عبور أنظمة تحويل تجارية وأن دعم معدات الاختبار يتطور. لكنه لا يثبت ملف نقاط نهاية كامل متعدد البائعين، أو مقياس إنتاج، أو اعتماد مستقل لكل ميزة اختيارية.

وصف أعضاء آخرون محولات أو أنظمة أو برمجيات أو خطط اختبار قادرة على UEC، وركزت قمة 2026 بشدة على التحول إلى منتج. ويدعم الدليل انتقالاً إلى التنفيذ، لكنه لا يدعم بعد تعداداً دقيقاً لبطاقات NIC العاملة بـ UET أو المحولات المعتمدة أو مناطق السحابة المنشورة أو الأنسجة الكاملة.

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

RoCE وInfiniBand وSlingshot وUALink

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

RoCEv2 هو السلف المباشر وتقنية رئيسية مثبتة. وهو يضع حركة RDMA على إيثرنت قابل للتوجيه وله دعم تطبيقي ومنتجي واسع. وينتقد UEC نشرات RoCE الشائعة لتثبيت المسار للتدفق الكامل، واستعادة Go-Back-N، وإعادة ترتيب المستقبل، وصعوبة ضبط DCQCN، والاعتماد على Priority Flow Control في العديد من التصاميم، والسلوك الضعيف تحت الازدحام المتجه نحو المستقبل أو الدفعات الجماعية. هذه مواقف تقنية لـ UEC، وليست دليلاً على أن كل شبكة RoCE أداؤها ضعيف.

المقارنة ديناميكية أيضاً. فيمكن للبائعين إضافة توجيه تكيفي، وتوزيع الرزم، وخوارزميات ازدحام أفضل، أو وظائف شبيهة بـ UEC إلى بطاقات NIC قابلة للبرمجة مع الاحتفاظ بتوافق RoCE. فمثلاً، تقدم رسائل AMD حول Pollara خياري RoCEv2 وUEC RDMA على أجهزة قابلة للبرمجة. لذا، قد ينافس UEC RoCE كنقل كامل بينما يؤثر أيضاً على كيفية تطور منتجات RoCE المستقبلية.

InfiniBand هو البديل الرئيسي للنسيج المتخصص. وهو يوفر نظاماً متكاملاً لـ RDMA والازدحام وموثوقية الرابط والإدارة مع خبرة طويلة في HPC. ويتضمن عمل 2.0 لرابطة تجارة InfiniBand دعماً مادياً لـ XDR بسرعة 200 جيجابت/ثانية لكل مسار وقياساً عن بُعد محدثاً. وأقوى تمييز لـ UEC ليس ادعاء أن InfiniBand يفتقر إلى الأداء، بل هو إمكانية تحقيق سلوك الذكاء الاصطناعي وHPC عبر سلسلة توريد الإيثرنت الأوسع وتوجيه IP القياسي وخيار أكبر بين البائعين.

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

وعادة ما يكون UALink مكملاً وليس بديلاً مباشراً. فمواصفته 200G العلنية الحالية تستهدف الاتصال منخفض زمن الانتظار من مسرع إلى مسرع داخل الحجيرة وتصف أنظمة تصل إلى 1,024 مسرعاً. أما UEC 1.0 فهو بشكل أساسي نسيج توسع خارجي يربط العقد عبر المحولات. ويمكن لمركز بيانات استخدام رابط توسع داخلي داخل حجيرة حسابية وUEC بين الحجيرات أو العقد. وقد تؤدي أعمال UEC المستقبلية على نقل التوسع الداخلي المحسن والعمليات الجماعية داخل الشبكة إلى تقريب الحدود وخلق إما تقارب أو منافسة.

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

المشكلة التشغيلية أكبر من البروتوكول

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

وتجعل حركة المرور المختلطة المشكلة أصعب. فقد يحمل نسيج مركز بيانات UET وRoCE وTCP والتخزين والإدارة وخدمات UET المرتبة وغير المرتبة. ولا يُحل تخصيص الطوابير والإنصاف بين هذه الفئات لمجرد أن كل بروتوكول منفذ بشكل صحيح. ويمكن لخوارزمية ازدحام أن تتصرف جيداً في عزلة وبشكل سيء عندما تتنافس مع متحكم آخر يستخدم تغذية راجعة وافتراضات مختلفة.

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

تخلق الميزات الاختيارية تمييزاً منتجياً وتجزئة في آن واحد. فقد يحسن أحد البائعين نقطة نهاية AI Base أساسية لـ ECMP وECN التقليديين. وقد يدعم آخر AI Full وTSS والقص وLLR وCBFC. ويمكن لكليهما المشاركة في نظام UEC البيئي، ومع ذلك لا يمكن للمشغلين افتراض نفس الدلالات أو الأداء أو الأمان. وتحتاج مصفوفات الامتثال إلى أن تصبح مصفوفات قدرة تشغيلية.

ستكون صيانة الإصدارات مستمرة. فقد أثرت التصحيحات من 1.0.1 إلى 1.0.3 على الازدحام والأرصدة وإعادة المحاولة وسلوك الرزم. ويمكن أن تحتوي مجموعة كبيرة على عدة إصدارات من البرامج الثابتة لبطاقات NIC وإصدارات محولات وأدوات اختبار. وترقية طبقة واحدة دون تنسيق الأخرى يمكن أن تعرض بالضبط التسابق عبر الطبقات الذي يحاول الاتحاد تجنبه.

لذا، فتحالفات UEC الخارجية مركزية وليست شكلية. فمشروع Open Compute يمكنه وصل النقل بالأنظمة المفتوحة والأجهزة. وتحالف OpenFabrics ومجتمع libfabric يصلان التطبيقات. وتوفر IEEE 802.3 عمل الإيثرنت الرسمي. وتجلب SNIA وNVM Express متطلبات التخزين والإدارة. وتزود تقنيات IETF بـ IP وECN وآليات ذات صلة. ولهذه المنظمات عمليات قرار وجداول زمنية مختلفة؛ ويقلل الاتصال من الازدواجية لكنه لا يمكن أن يضمن التبني المتزامن.

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

الأهمية الحالية: من نصر المواصفة إلى مصداقية التنفيذ

بحلول يوليو 2026، كان UEC قد حقق عدة أمور كانت غير مؤكدة عند الإطلاق. فقد شكل ائتلافاً واسعاً، وأنتج بنية متكاملة من خمس طبقات، وأصدر مواصفة 1.0 كاملة، وصانها عبر إصدارات تصحيحية، وأضاف دعماً لـ 200G لكل مسار، وأفصح عن إقرارات براءات اختراع، واجتذب إعلانات منتجات واختبارات. المشروع نشط وقد تحرك جدول أعماله بشكل حاسم نحو التنفيذ.

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

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

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

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

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