🤖 machine learning

CUCo: An Agentic Framework for Compute and Communication Co-design

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

المؤلفون الأصليون: Bodun Hu, Yoga Sri Varshan, Saurabh Agarwal, Aditya Akella

نُشر 2026-03-04

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Bodun Hu, Yoga Sri Varshan, Saurabh Agarwal, Aditya Akella

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

المشكلة: عنق الزجاجة لدى "القائد"
في الأيام الخوالي، كان على القائد (وحدة المعالجة المركزية - CPU) أن يقف في المنتصف، ويصرخ بالتعليمات لكل قسم.

يخبر قسم الوتريات (الحوسبة) بأن يعزفوا نوتة معينة.
ثم يتوقف، ويركض نحو قسم النحاسيات (الاتصال)، ليخبرهم بتمرير ورقة موسيقية إلى المبنى التالي، وينتظر حتى ينتهوا، ثم يخبر قسم الوتريات بعزف النوتة التالية.

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

مؤخرًا، تطورت التكنولوجيا: زُوِّد الموسيقيون بأجهزة لاسلكي (واجهات برمجة التطبيقات من جهة الجهاز مثل NVSHMEM/NCCL). الآن، يمكن للوتريات التحدث مباشرة مع النحاسيات دون الحاجة لركض القائد ذهابًا وإيابًا. ولكن هنا تكمن المشكلة: كتابة النص الذي يحدد كيفية تحدث الموسيقيين مع بعضهم البعض أثناء العزف أمر صعب للغاية. إنه يشبه مطالبة مؤلف موسيقي بكتابة نص يجب فيه على عازفي الكمان عزف "سولو" منفرد، وتمرير ملاحظة لصديق في مبنى آخر، والاستماع لإشارة لبدء المازورة التالية في آن واحد — كل ذلك دون ارتباك أو إفساد الأداء. القيام بذلك يدويًا هو كابوس من الأخطاء والتجارب والخطأ.

الحل: CUCo (المؤلف الموسيقي للذكاء الاصطناعي)
إليك CUCo. فكر في CUCo كمؤلف موسيقي ذكي للغاية ولا يكل، لا يكتفي فقط بكتابة الموسيقى، بل يتعلم كيف يكتب النص المثالي لهذه الأوركسترا المحددة، في هذا الملعب المحدد، ومع هذه الأجهزة اللاسلكية المحددة.

يعمل CUCo في مرحلتين متمايزتين، مثل طالب يتعلم القواعد أولاً ثم يتدرب ليصبح بارعًا (Virtuoso):

المرحلة الأولى: "المسار السريع" (الطالب الحريص على السلامة)

تخيل طالبًا قيل له: "اكتب نصًا يعمل، حتى لو لم يكن الأسرع".

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

المرحلة الثانية: "المسار البطيء" (البارع المتطور)

الآن، يأخذ الذكاء الاصطناعي ذلك النص "الآمن ولكن البطيء" ويبدأ تجربة تطورية.

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

التشبيه السحري: سباق التتابع

الطريقة القديمة: يركض العداء (GPU) لفة، ثم يتوقف عند الجدار، وينتظر المدرب (CPU) ليسلمه العصا، ثم يركض مرة أخرى.
طريقة CUCo: يتم تسليم العصا للعداء بحيث يمكنه الإمساك بها بينما لا يزال يركض. هو لا يتوقف، بل يمرر العصا للعداء التالي في المسار المجاور بينما هو في حالة انطلاق كامل.

لماذا هذا مهم؟

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

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

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

إليك ملخص تقني مفصل لورقة البحث بعنوان: "CUCo: إطار عمل وكيل لتعاون تصميم الحوسبة والاتصال (Compute and Communication Co-design)."

1. بيان المشكلة

في تدريب واستنتاج النماذج اللغوية الكبيرة (LLMs) واسعة النطاق، يتطلب تعظيم استغلال وحدات معالجة الرسومات (GPU) تداخلاً وثيقاً بين الحوسبة والاتصال. وبينما تسمح الأجهزة الحديثة (مثل NVLink وInfiniBand) وواجهات برمجة التطبيقات (مثل NCCL Device-Side وNVSHMEM) لوحدات معالجة الرسومات ببدء الاتصال مباشرة دون تدخل وحدة المعالجة المركزية (CPU)، فإن كتابة نوى (kernels) عالية الأداء تدمج هذين المجالين يدوياً تظل عملية مجهدة للعمالة، وعرضة للأخطاء، ويصعب التحكم فيها.

تشمل التحديات الرئيسية ما يلي:

فضاء تصميم معقد: القرارات المتعلقة بمكان وضع الاتصال، ونطاق المزامنة، وحجم التجزئة (chunking granularity)، واختيار الخلفية (Backend) (مثل GIN مقابل LSA) تتفاعل بشكل غير خطي. الإعدادات المثلى حساسة للغاية لتوبولوجيا أجهزة محددة وأعباء عمل معينة.
تباين الأجهزة (Hardware Heterogeneity): تعني الاختلافات في عرض نطاق الشبكة، وزمن الوصول، والتوبولوجيا (مثل Fat-Tree مقابل Torus) أن النواة المحسنة لإعداد واحد قد تفشل أو تؤدي أداءً ضعيفاً في إعداد آخر.
قصور الأدوات الحالية: تفترض المترجمات التقلية لتعلم الآلة أن الاتصال هو أثر جانبي من جانب المضيف (host-side side effect)، مما يمنعها من التحسين داخل النواة. وتفتقر مولدات النوى القائمة على النماذج اللغوية الكبيرة (LLM) حالياً إلى دعم دلالات الجمع متعددة وحدات معالجة الرسومات (multi-GPU collective semantics)، وغالباً ما تفشل في إنتاج كود موزع صحيح دون ضبط يدوي مكثف.

2. المنهجية: إطار عمل CUCo

إن CUCo هو سير عمل مدفوع بالوكلاء (agent-driven) ولا يتطلب تدريباً، مصمم لتوليد نوى CUDA مدمجة للحوسبة والاتصال تلقائياً. وهو يستخدم بنية وكلاء "بمسارين" لموازنة الصحة (correctness) والأداء.

أ. توصيف فضاء التصميم المهيكل

لضبط استدلال الوكلاء، يعرّف CUCo فضاء تهيئة تحسين (C) يتكون من خمسة أبعاد:

الخلفية (Backend - B): اختيار أداة الاتصال الأولية (مثل GIN للاتصال عبر RDMA بين العقد، أو LSA للوصول المباشر للذاكرة داخل العقدة).
المُصدر (Issuer - I): دقة مشاركة الخيوط (Thread، أو Warp، أو CTA).
الموضع (Placement - P): مدى عدوانية التداخل مقابل تعقيد الترتيب.
نطاق المزامنة (Sync Scope - S): مدى إحكام المزامنة مقابل إمكانية التداخل.
الدقة (Granularity - G): حجم قطع النقل مقابل تكلفة المزامنة الإضافية.

يجب على الوكلاء إصدار توجيه تحسين (Optimization Directive) صريح بناءً على هذه الأبعاد قبل توليد الكود، مما يضمن أن تكون القرارات قابلة للتتبع وصحيحة.

ب. وكيل المسار السريع (الأولوية للصحة)

هدف وكيل المسار السريع الوحيد هو إنتاج نواة صحيحة وظيفياً تبدأ من جانب الجهاز (device-initiated) انطلاقاً من نموذج أساسي مدفوع من جانب المضيف.

سير العمل:
1. التحليل: استخراج مخططات تبعية الاتصال من كود المستخدم.
2. التحويل: إعادة كتابة استدعاءات NCCL المدفوعة من المضيف إلى مكافئات مدفوعة من الجهاز (على سبيل المثال، استبدال ncclSend بـ gin.put). يستخدم حلقة "قاضٍ يعتمد على LLM" للتحقق من التجميع والصحة بشكل تكراري.
3. التعليق التوضيحي (Annotation): تحديد مناطق كود معينة كـ EVOLVE-BLOCK لتحديد مناطق الطفرة الآمنة للمرحلة التالية.
الاستراتيجية: يعطي الأولوية للمراحل المحافظة والمحددة بالحواجز (barrier-delimited) لضمان السلامة الموزعة (منع حالات الجمود أو الحالات غير المتسقة)، مما يخلق "بذرة" موثوقة للتحسين.

ج. وكيل المسار البطيء (الأولوية للأداء)

يقوم وكيل المسار البطيء بإجراء بحث تطوري مدفوع بـ LLM لتحسين النواة "البذرة" لتناسب أعباء عمل وأجهزة محددة.

مجتمعات متعددة الجزر (Multi-Island Population): يحافظ على $K$ من الجزر التطورية المستقلة لمنع التقارب المبكر. تقوم الجزر بترحيل المرشحين الأعلى أداءً دورياً لتبادل الاستراتيجيات.
مشغل الطفرة (Mutation Operator) القائم على LLM: بدلاً من تعديلات الكود العشوائية، يعمل الـ LLM كعامل تغيير مهيكل؛ حيث يقترح طفرات (فروقات، أو إعادة كتابة كاملة، أو تهجين) تقتصر حصرياً على مناطق EVOLVE-BLOCK الموضحة، مسترشداً بـ:
- الكود الأب والمقاييس.
- أرشيف الحلول المتنوعة وعالية الأداء (MAP-Elites).
- الاتجاهات الملخصة من الأجيال السابقة.
سياسة البحث ثنائية المرحلة:
- مرحلة الاستكشاف (Explore Phase): طفرات ذات درجة حرارة عالية لاكتشاف استراتيجيات هيكلية متنوعة (مثل أنابيب put/wait المجزأة، أو النوى المدمجة).
- مرحلة الاستغلال (Exploit Phase): فروقات محلية ذات درجة حرارة منخفضة لصقل أفضل المرشحين.
التقييم المتتالي (Cascade Evaluation): يقوم مرشح ثلاثي المستويات ( $\ell_1 \to \ell_2 \to \ell_3$ $ℓ_{1} \to ℓ_{2} \to ℓ_{3}$ ) بفحص المرشحين:
1. فحص التجميع (Compilation check).
2. التحقق من الصحة العددية (عبر mpirun).
3. اختبار الأداء (الكمون/الإنتاجية).
- يتم تغذية الفشل بالتعليقات الراجعة إلى الـ LLM لتوجيه الطفرات المستقبلية.

3. المساهمات الرئيسية

إطار عمل CUCo: أول نظام وكيل قادر على تصميم مشترك لنوى الحوسبة والاتصال لتعلم الآلة الموزع دون الحاجة لتدريب النماذج.
فضاء تصميم مهيكل: واجهة تصريحية تربط استدلال الوكيل بدلالات الجمع الصحيحة، مما يقلل من الهلوسة (hallucinations) لأنماط المزامنة غير الصالحة.
بنية المسارين: فصل مبتكر للمسؤوليات حيث يضمن "المسار السريع" الصحة بينما يقود "المسار البطيء" الأداء، مما يحل معضلة "الصحة مقابل التحسين" في الكود الموزع.
التطور الواعي بالأجهزة: يتكيف النظام ديناميكياً مع توبولوجيا الأجهزة المحددة (مثل NVLink مقابل RoCE) وخصائص أعباء العمل (مثل عدم توازن الرموز في MoE) من خلال حلقات التغذية الراجعة التجريبية.

4. النتائج التجريبية

تم تقييم CUCo على أربعة أعباء عمل تمثل تعدد وحدات معالجة الرسومات:

Flash Attention مع التوازي السياقي (Context Parallelism): (4 وحدات GPU، NVLink).
DeepSeek-V3 MoE Dispatch/Combine: (وحدتان GPU، RoCE بين العقد).
نقل KV-Cache: (وحدتا GPU، NVLink).
GEMM + AllGather: (4 وحدات GPU، روابط مختلطة).

مكاسب الأداء:

تقليل زمن الوصول (Latency Reduction): قلل CUCo باستمرار زمن الوصول النهائي بنسبة 5.3% إلى 26.2% مقارنة بالنماذج الأساسية المدفوعة من المضيف.
تسريع الأداء (Speedup): حقق تسريعاً يصل إلى 1.57× مقارنة بالنماذج غير المدمجة.
دراسة حالة (Flash Attention): ألغت النواة المدمجة فقاعات خط الأنابيب (pipeline bubbles) وحمل واجهة برمجة التطبيقات من جانب المضيف، مما قلل زمن الوصول من 1230.7 ملي ثانية إلى 1091.7 ملي ثانية (انخفاض بنسبة 11.3%). جاءت المكاسب الرئيسية من تقسيم الأنابيب لكل بلاطة (per-tile pipelining)، وهو ما كان مستحيلاً في النموذج الأساسي بسبب تشبع الـ SM.

الدراسات الاستئصالية (Ablation Studies):

ضرورة المسار السريع: أدى تخطي وكيل المسار السريع إلى انخفاض بنسبة 2.5% في ذروة الأداء وتطلب 5 أجيال لإنتاج نواة صحيحة (مقابل جيلين مع المسار السريع)، مما أهدر 25% من ميزانية البحث في أخطاء التجميع.
البحث ثنائي المرحلة: تفوقت استراتيجية "الاستكشاف ثم الاستغلال" على الاستغلال أحادي المرحلة، حيث حققت درجة نهائية أعلى بنسبة 4.3% ووصلت إلى الأداء الأمثل القريب بسرعة أكبر بـ 3 مرات.

5. الأهمية

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

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

يخطط المؤلفون لفتح المصدر بالكامل لـ CUCo لتسريع البحث في التصميم المشترك للحوسبة والاتصال.