أصبح تجميع عدة أجهزة Mac Studio لتشغيل نماذج الذكاء الاصطناعي محليًا فكرة عملية بالفعل، لكن السبب ليس أن أربعة أجهزة Mac تتحول حرفيًا إلى حاسوب واحد. التحول الحقيقي حدث عندما أضافت Apple دعم RDMA over Thunderbolt 5 إلى macOS، ثم دمجته مع منظومة MLX وJACCL لتقليل كلفة الاتصال بين العقد أثناء Distributed Inference.
حتى 29 أغسطس 2026، لم تعد هذه ميزة تجريبية مخفية كما كانت في بداياتها. توثق Apple رسميًا RDMA عبر Thunderbolt منذ macOS 26.2، وقد عرضت في WWDC26 كيفية بناء عنقود من أربعة أجهزة Mac وتشغيل الاستدلال الموزع عليها. كما أعلنت Apple في 25 أغسطس 2026 جيل Mac Studio الجديد بمعالجي M5 Max وM5 Ultra، وبدأت تسوّق التجميع عبر Thunderbolt 5 رسميًا كميزة للذكاء الاصطناعي الموزع.
لكن توجد تفاصيل مهمة غالبًا ما تضيع خلف عبارة "AI Supercomputer": الذاكرة لا تصبح RAM واحدة متماسكة على مستوى نظام التشغيل، وRDMA ليس بديلًا سحريًا عن GPU Interconnects المستخدمة في مراكز البيانات، وإضافة أجهزة أكثر لا تعني بالضرورة زيادة السرعة بالنسبة نفسها.
ما الذي تغير فعليًا مع RDMA عبر Thunderbolt 5؟
عند تشغيل نموذج كبير على عدة حواسيب، لا تكفي قدرة كل GPU منفردة. تحتاج العقد إلى تبادل Tensors ونتائج وسيطة باستمرار، ولذلك قد يصبح الاتصال بينها هو عنق الزجاجة بدل الحساب نفسه.
في الاتصالات التقليدية القائمة على TCP/IP تمر البيانات عبر طبقات برمجية متعددة قبل وصولها إلى التطبيق المستهدف. إذا أردت مراجعة الصورة الأساسية لكيفية تعاون هذه الطبقات، يشرح دليل البروتوكولات الشبكية وTCP/IP دور كل مستوى في عملية الاتصال.
أما RDMA، أو Remote Direct Memory Access، فيوفر مسارًا منخفض العبء لنقل البيانات بين ذاكرة جهاز وآخر مع تجنب قدر كبير من تدخل المعالج ومكدس الشبكة التقليدي.
وتوضح وثيقة Apple التقنية TN3205 أن RDMA over Thunderbolt متاح ابتداءً من macOS 26.2 على أجهزة Mac المزودة بـApple silicon وThunderbolt 5، وأن الهدف منه هو الاتصال عالي الأداء ومنخفض زمن الاستجابة بين أجهزة Mac المتصلة مباشرة.
كما تسجل ملاحظات إصدار macOS 26.2 الرسمية الميزة صراحة ضمن الاستخدامات الموجهة إلى Distributed AI Inference باستخدام MLX.
Thunderbolt 5 وحده لا يصنع Cluster سريعًا
وجود كابل سريع بين جهازين لا يكفي. يمكن التفكير في المنظومة الحالية على أربع طبقات مترابطة:
- Thunderbolt 5: الرابط الفيزيائي عالي السرعة بين أجهزة Mac.
- RDMA: آلية نقل منخفضة العبء والـLatency فوق اتصال Thunderbolt.
- JACCL: طبقة Collective Communication التي تنظم عمليات الاتصال بين العقد.
- MLX: إطار التعلم الآلي الذي يقسم العمل ويستخدم هذه الاتصالات في التدريب والاستدلال الموزع.
وهذه النقطة مهمة لأن RDMA بمفرده ينقل البيانات فقط. النموذج يحتاج إلى عمليات أعلى مستوى مثل all-gather وتجميع النتائج والمزامنة بين جميع العقد.
ما هو JACCL ولماذا أصبح جزءًا أساسيًا من الصورة؟
JACCL هي مكتبة Collective Communication مفتوحة المصدر طورتها Apple لتوفير اتصال منخفض زمن الاستجابة بين أجهزة Mac باستخدام RDMA عبر Thunderbolt.
بدل أن يدير مطور نموذج AI الاتصالات الخام بين كل جهاز وآخر، توفر JACCL primitives للاتصال والمزامنة وتجميع البيانات، بينما يستطيع MLX استخدامها كـDistributed Backend.
وتوضح وثائق MLX Distributed الرسمية أن MLX يدعم عدة Backends، منها Ring عبر TCP وJACCL عبر RDMA، وأن JACCL مهم تحديدًا للأحمال كثيرة التواصل مثل Tensor Parallelism.
وفي جلسة Apple الخاصة بالاستدلال والتدريب الموزع في WWDC26 عرض مهندسو Apple السلسلة كاملة: Thunderbolt 5 ثم RDMA ثم JACCL ثم MLX، قبل تشغيل نموذج موزع على أربعة أجهزة Mac Studio.
هل تجمع أجهزة Mac ذاكرتها فعلًا؟
يمكن لعدة أجهزة Mac أن توفر للنموذج سعة ذاكرة مجمعة تسمح بتوزيع أوزانه وعملياته بين العقد، لكن من الأدق ألا نتخيل ذلك كأن macOS حصل فجأة على شريحة RAM واحدة بحجم 2 تيرابايت.
لكل جهاز Apple silicon ذاكرته الموحدة الخاصة به. يقوم Framework الموزع بتقسيم النموذج والـTensors بين الأجهزة، ثم تستخدم العقد RDMA لتبادل البيانات المطلوبة بسرعة.
لذلك عندما يقال إن Cluster من أربع عقد بسعة 512GB لكل عقدة يوفر نحو 2TB للنموذج الموزع، فالمقصود السعة الإجمالية المتاحة عبر عملية Sharding، وليس ذاكرة موحدة ذات زمن وصول محلي متطابق من جميع المعالجات.
وهذا التفريق مهم لأن الوصول إلى ذاكرة العقدة الأخرى يظل أبطأ من الوصول إلى الذاكرة المحلية داخل شريحة Apple silicon، حتى مع RDMA.
لماذا كان الـLatency مشكلة كبيرة للذكاء الاصطناعي الموزع؟
إذا كان هدفك فقط تقسيم نموذج ضخم لأنه لا يتسع داخل ذاكرة جهاز واحد، يمكن توزيع مجموعات من الطبقات بين عقد مختلفة. لكن تسريع الحساب نفسه يتطلب غالبًا تبادل بيانات أكثر بكثير بين الأجهزة.
وهنا يظهر الفرق بين أشهر أشكال Model Parallelism.
| الأسلوب | طريقة العمل | حساسيته للاتصال | الفائدة الرئيسية |
|---|---|---|---|
| Pipeline Parallelism | تقسيم مجموعات من طبقات النموذج بين العقد | أقل نسبيًا | تشغيل نموذج أكبر من ذاكرة عقدة واحدة |
| Tensor Parallelism | تقسيم عمليات الطبقة نفسها بين عدة عقد | مرتفعة جدًا | تشغيل عدة معالجات بالتوازي داخل الطبقة |
Tensor Parallelism يحتاج إلى عمليات اتصال جماعية متكررة أثناء الحساب، ولذلك قد تقضي العقد جزءًا كبيرًا من وقتها في انتظار البيانات إذا كان زمن الاستجابة مرتفعًا.
RDMA وJACCL لا يلغيان هذه الاتصالات؛ بل يجعلانها أقل كلفة، ولهذا أصبحت الطرق كثيرة التواصل أكثر قابلية للاستخدام على Cluster من أجهزة Mac.
ماذا أثبتت Apple عن الأداء؟
الرقم الأكثر فائدة حاليًا هو الرقم الذي توثقه Apple نفسها، وليس مقارنة عشوائية بين Mac Studio وبطاقات مراكز بيانات مختلفة جذريًا.
في WWDC26 استخدمت Apple أربعة أجهزة M3 Ultra وأظهرت تشغيل Distributed Inference عبر MLX، مع وصول سرعة توليد نموذج Qwen بحجم 27B إلى ما يقارب ثلاثة أضعاف أداء جهاز واحد في الاختبار المعروض.
وفي إعلان Mac Studio الجديد بتاريخ 25 أغسطس 2026، ذكرت Apple أن Cluster من أربعة أجهزة Mac Studio يمكن أن يحقق أداء Distributed AI Inference أسرع بما يصل إلى 3 مرات مقارنة بجهاز واحد في اختبارات الشركة.
يمكن مراجعة تفاصيل الجيل الجديد واختبارات Apple في إعلان Mac Studio الرسمي.
لكن عبارة "حتى 3x" مهمة. أربعة أجهزة لا تضمن 4x، وقد تكون الزيادة أقل بحسب النموذج، وطريقة Quantization، وحجم الـPrompt، وعدد الرموز، واستراتيجية Sharding، ونسبة الوقت الذي يقضيه الحمل في الحساب مقارنة بالاتصال.
الوضع الحالي لـMac Studio في أغسطس 2026
المقالة الأصلية حول هذه التقنية ظهرت في فترة كانت تجارب Mac Studio Cluster تعتمد أساسًا على أجيال مثل M3 Ultra وM4 Max. الوضع تغير منذ ذلك الحين.
في 25 أغسطس 2026 أعلنت Apple Mac Studio مع M5 Max وM5 Ultra. ووفق المواصفات الرسمية، يصل M5 Ultra إلى:
- 36 نواة CPU كحد أقصى.
- 80 نواة GPU كحد أقصى.
- 512GB من Unified Memory كحد أقصى.
- عرض نطاق للذاكرة يصل إلى 1.2TB/s.
- Thunderbolt 5.
لكن هناك فرق بين الإعلان والتوفر الفعلي. حتى 29 أغسطس 2026، الجيل الجديد ما زال في مرحلة الطلب المسبق، وتقول Apple إن وصوله للعملاء يبدأ في 22 سبتمبر 2026، بينما تكوين M5 Ultra بذاكرة 512GB مقرر أن يتوفر في أواخر أكتوبر.
لذلك فإن معظم تجارب RDMA الواقعية المنشورة حتى الآن أُجريت على أجهزة الجيل السابق، خصوصًا M3 Ultra، بينما يمثل M5 Ultra الاتجاه الذي ستنتقل إليه إعدادات Mac Studio عالية السعة بعد توفره.
ما الأجهزة التي تدعم RDMA over Thunderbolt؟
الميزة ليست حصرية لاسم Mac Studio بحد ذاته. متطلبات Apple الأساسية هي:
- Mac بمعالج Apple silicon.
- دعم Thunderbolt 5.
- macOS 26.2 أو إصدار أحدث يدعم الميزة.
وهذا يعني أن بعض أجهزة Mac mini وMacBook Pro المزودة بـThunderbolt 5 يمكنها تقنيًا المشاركة أيضًا، وليس فقط Mac Studio.
أما إذا كنت جديدًا على مفاهيم العقد والاتصالات المحلية والـBandwidth والـLatency، فمن المفيد أولًا بناء الأساس عبر دليل تعلم أساسيات الشبكات من الصفر قبل الانتقال إلى Distributed Computing.
كيف تكون توصيلات أربعة أجهزة Mac؟
عند استخدام JACCL في MLX، يحتاج الإعداد الفيزيائي إلى Fully Connected Mesh: كل جهاز يجب أن يمتلك اتصال Thunderbolt مباشرًا مع كل جهاز آخر.
في Cluster من أربع عقد توجد ستة روابط ثنائية مطلوبة حتى يكون كل زوج من الأجهزة متصلًا مباشرة.
قد تتحدث وثائق JACCL أيضًا عن Mesh وRing على مستوى خوارزمية الاتصال الجماعي، لكن هذا لا يعني بالضرورة إمكانية إزالة الروابط المباشرة من إعداد MLX. الوثائق الحالية لـMLX تشترط Mesh كاملًا عند استخدام JACCL Backend، وبعد ذلك تستطيع المكتبة اختيار طريقة الاتصال المناسبة للـCollective Operation.
إعداد Mac Cluster باستخدام MLX وJACCL
هذه هي الطريقة الأقرب إلى المسار الرسمي الذي توثقه Apple وMLX حاليًا.
1. تحديث جميع العقد
استخدم macOS 26.2 أو أحدث على جميع أجهزة Cluster، ومن الأفضل إبقاء العقد على الإصدار نفسه لتجنب اختلافات الـDrivers والواجهات.
2. توصيل أجهزة Mac بكابلات Thunderbolt 5
أنشئ Full Mesh بحيث يتصل كل Mac مباشرة بكل Mac آخر عبر Thunderbolt 5.
3. إبقاء شبكة عادية للإدارة
لا يلغي RDMA الحاجة إلى Ethernet أو Wi-Fi. تحتاج MLX إلى الوصول إلى الأجهزة عبر SSH لتشغيل العمليات وتنسيق الـCluster.
الفكرة هي أن شبكة الإدارة تستطيع استخدام Ethernet، بينما تمر عمليات نقل البيانات الحساسة للـLatency بين عمليات MLX عبر RDMA وThunderbolt.
4. تفعيل RDMA من macOS Recovery
أعد تشغيل الجهاز إلى Recovery، ثم افتح Terminal ونفذ:
rdma_ctl enable
بعد إعادة التشغيل يمكن التأكد من ظهور واجهات RDMA بالأمر:
ibv_devices
وتوضح Apple هذه الخطوات مباشرة في وثيقة TN3205 الرسمية.
5. تثبيت MLX وMLX-LM
يجب تجهيز بيئة Python متوافقة على العقد وتثبيت الحزم المطلوبة لتشغيل النموذج. MLX-LM هي الحزمة التابعة لمنظومة MLX والمخصصة لتشغيل وتدريب وضبط نماذج اللغة على Apple silicon.
توثق MLX-LM دعم Distributed Inference وFine-Tuning باستخدام MLX Distributed.
6. التحقق من بنية الاتصالات
توفر MLX أداة mlx.distributed_config لاكتشاف روابط Thunderbolt والتحقق من أن الـMesh صحيح وإنشاء Hostfile.
أحد الأنماط التي توثقها MLX هو:
mlx.distributed_config --verbose --backend jaccl --hosts mac1,mac2,mac3,mac4 --over thunderbolt --output cluster.json
يمكن استخدام خيارات الإعداد التلقائي عندما تكون صلاحيات SSH وsudo مناسبة، أو تنفيذ الإعدادات المطلوبة يدويًا على كل عقدة.
7. تشغيل النموذج موزعًا
بعد إنشاء Hostfile، يستطيع mlx.launch بدء عملية على كل عقدة واستخدام JACCL كـBackend.
الشكل العام هو:
mlx.launch --backend jaccl --hostfile cluster.json -- python -m mlx_lm chat --model MODEL
اسم النموذج وطريقة Quantization يجب اختيارهما حسب حجم الذاكرة المتاح وهدف الاستخدام، ولا توجد سرعة ثابتة تنطبق على كل LLM.
هل ما زلنا بحاجة إلى Exo؟
لا. وهذه إحدى أكبر النقاط التي تغيرت مقارنة بالمراحل الأولى من انتشار Mac Clustering.
Exo ليس شرطًا لتشغيل RDMA أو لإنشاء Cluster باستخدام MLX. لدى Apple الآن مسار رسمي موثق يعتمد على MLX وJACCL وmlx.launch.
ومع ذلك يبقى Exo مشروعًا مفتوح المصدر مفيدًا لمن يريد Runtime أعلى مستوى لتجميع أجهزة مختلفة وتقديم النماذج كتطبيق محلي دون بناء طبقة orchestration بنفسه.
إذن العلاقة الصحيحة هي:
- RDMA over Thunderbolt: تقنية يقدمها macOS.
- JACCL: مكتبة الاتصالات الموزعة.
- MLX: Framework يستطيع تشغيل Distributed AI فوق JACCL.
- Exo: مشروع مستقل يمكنه الاستفادة من هذه القدرات لتقديم تجربة Cluster جاهزة بصورة أكبر.
هل RDMA يعني اتصال GPU-to-GPU مباشرًا تمامًا؟
من الشائع اختصار RDMA بعبارة "GPU يتصل مباشرة بذاكرة GPU أخرى"، لكنها ليست أفضل طريقة لفهم تنفيذ Apple الحالي.
الصياغة الأدق هي أن RDMA يسمح بنقل البيانات بين ذاكرة الأجهزة مع تجنب جزء كبير من تدخل CPU ومكدس الشبكة التقليدي، ما يقلل الـOverhead والـLatency.
بل إن وثائق MLX نفسها تشير إلى أن الاتصال منخفض المستوى يتطلب تعاون CPU وGPU في أجزاء من التنفيذ، وتوفر إعدادًا خاصًا لتحسين المزامنة بينهما.
لذلك من الأفضل فهم RDMA كـمسار ذاكرة منخفض العبء وليس ككابل يجعل GPUs منفصلة تتصرف كأنها GPU واحدة.
هل يستطيع Cluster تشغيل نموذج بتريليون Parameter؟
من حيث سعة الذاكرة، تستطيع إعدادات متعددة العقد تشغيل نماذج Open-Weight أكبر بكثير مما يستطيع جهاز واحد استيعابه، وقد أظهرت تجارب فعلية تشغيل نماذج من فئة Kimi K2 ذات الحجم الإجمالي الذي يصل إلى نحو تريليون Parameter باستخدام Mac Studio Clusters.
لكن عدد Parameters وحده لا يحدد كمية الذاكرة المطلوبة.
الاستهلاك يعتمد على:
- دقة الأوزان مثل FP16 أو BF16 أو 8-bit أو 4-bit.
- ما إذا كان النموذج Dense أو Mixture-of-Experts.
- عدد Parameters النشطة في كل Token.
- حجم KV Cache.
- طول Context.
- عدد الطلبات المتزامنة.
- Overhead الخاص بالـRuntime.
لذلك لا يصح استنتاج أن "1T Parameters = مساحة ثابتة" أو أن أي Cluster بسعة 2TB سيشغل كل نموذج بتريليون Parameter بالطريقة نفسها.
هل أربعة أجهزة Mac Studio أسرع دائمًا من جهاز واحد؟
لا. Clustering يقدم فائدتين مختلفتين يجب عدم الخلط بينهما:
- Capacity Scaling: تمكين نموذج لا يتسع في جهاز واحد من العمل عبر عدة عقد.
- Performance Scaling: زيادة عدد Tokens في الثانية أو سرعة تنفيذ العملية.
الفائدة الأولى أسهل في تحقيقها. أما الثانية فتعتمد على نسبة الحساب إلى الاتصال.
إذا كان النموذج صغيرًا ويتسع بسهولة داخل جهاز واحد، فإن إضافة شبكة وعمليات Synchronization قد تقدم مكسبًا محدودًا أو حتى تجعل بعض مراحل العمل أبطأ.
ويصبح Cluster أكثر منطقية عندما يكون لديك نموذج ضخم، أو Batch كبير، أو عملية موزعة تستطيع الاستفادة من جميع وحدات الحساب دون أن يصبح الاتصال هو المسيطر على زمن التنفيذ.
لماذا لا تقارن Mac Studio مباشرة بعشرات H100؟
من المغري حساب مجموع الذاكرة فقط والقول إن أربعة أجهزة Mac Studio ذات سعة كبيرة تعادل عددًا معينًا من بطاقات NVIDIA H100 أو H200، لكن هذه مقارنة مضللة.
سعة الذاكرة ليست سوى عامل واحد. منصات مراكز البيانات تختلف في:
- قدرة Tensor Compute.
- عرض نطاق الذاكرة.
- Interconnect مثل NVLink وNVSwitch وInfiniBand.
- التوسع إلى عشرات أو مئات العقد.
- بيئة CUDA والمكتبات المحسنة.
- دعم التدريب واسع النطاق.
- التبريد والطاقة والاعتمادية والإدارة.
نقطة قوة Mac Studio Cluster مختلفة: تقديم كميات كبيرة من الذاكرة الموحدة في أجهزة مكتبية هادئة نسبيًا لتشغيل نماذج كبيرة محليًا، خصوصًا للاستدلال والبحث والتجارب التي لا تحتاج إلى بنية مركز بيانات.
أين توجد حدود RDMA over Thunderbolt؟
رغم أهمية الميزة، لا ينبغي التعامل معها كنسخة مكتبية مطابقة لشبكات RDMA في مراكز البيانات.
توثق Apple عددًا من حدود RDMA Verbs في تنفيذها الحالي، منها أن الواجهة تدعم عمليات Send وReceive فقط، بالإضافة إلى حدود لعدد Queue Pairs وأحجام الرسائل والطلبات المعلقة.
كما أن Full Mesh يصبح أكثر تعقيدًا كلما زاد عدد الأجهزة. أربع عقد تحتاج إلى ست وصلات مباشرة، ومع زيادة عدد العقد يرتفع عدد الروابط المطلوبة بسرعة.
لهذا يعد Mac Studio Cluster مناسبًا أكثر للتجميع المكتبي الصغير نسبيًا من بناء Fabric يضم مئات العقد.
ماذا عن الخصوصية والتشغيل المحلي؟
تشغيل النموذج على أجهزتك يعني أن عملية Inference نفسها لا تحتاج إلى إرسال الـPrompt إلى API سحابية، وهي ميزة مهمة للمختبرات والشركات التي تريد إبقاء بعض البيانات داخل بنيتها المحلية.
لكن عبارة "خصوصية كاملة" تحتاج إلى حذر. قد يستمر النظام في الاتصال بالإنترنت لتنزيل النماذج أو الحزم، وقد تستخدم التطبيقات المحيطة خدمات خارجية أو Telemetry، وقد يرسل AI Agent بيانات إلى أدوات أخرى حتى إذا كان الـLLM نفسه محليًا.
الخصوصية الفعلية تعتمد على تصميم المنظومة كاملة، وليس فقط مكان وجود النموذج.
تأمين API المحلي
يمكن استخدام MLX-LM لتوفير HTTP API شبيه بواجهة OpenAI، ما يسمح لتطبيقات أخرى بالتحدث إلى النموذج المحلي.
لكن وثائق MLX-LM Server تنبه إلى أن الخادم ليس موصى به كما هو للاستخدام Production لأنه يقدم ضوابط أمنية أساسية فقط.
إذا كان Cluster سيستخدم داخل شركة أو مختبر، فمن الأفضل عدم تعريض Model Server مباشرة للإنترنت، وتقييد الوصول إليه داخل شبكة موثوقة، واستخدام Authentication وReverse Proxy وسياسات Firewall مناسبة إذا احتاج عدة مستخدمين للوصول إليه.
هل يستحق Mac Studio Cluster الاستثمار؟
لا توجد إجابة واحدة لأن السؤال الصحيح ليس: "هل Mac Studio أرخص من GPU في مركز بيانات؟" بل: ما المشكلة التي تريد حلها؟
قد يكون Cluster منطقيًا عندما:
- تحتاج إلى تشغيل Open-Weight LLM كبير محليًا.
- لا يتسع النموذج في ذاكرة جهاز واحد.
- تريد بيئة مكتبية هادئة نسبيًا بدل خادم GPU تقليدي.
- لديك بيانات تريد إبقاء عملية Inference الخاصة بها داخل المؤسسة.
- تستخدم MLX بالفعل في البحث أو التطوير على Apple silicon.
- تستفيد من الجهاز نفسه أيضًا في Workloads احترافية أخرى.
وقد لا يكون منطقيًا عندما:
- تحتاج فقط إلى نموذج صغير يعمل بسهولة على جهاز واحد.
- استخدامك متقطع وتكلفة API السحابية منخفضة.
- تحتاج إلى تدريب ضخم متعدد GPUs.
- تعتمد مشاريعك أساسًا على CUDA ومكتبات NVIDIA.
- تحتاج إلى Scale أكبر بكثير من بضعة أجهزة مكتبية.
ما الذي تغير منذ ظهور التجارب الأولى؟
الفرق الأكبر هو انتقال الفكرة من مجموعة تجارب يقودها المجتمع إلى Capability موثقة رسميًا داخل منظومة Apple.
في أواخر 2025 كان التركيز على إثبات أن RDMA عبر Thunderbolt يستطيع إزالة جزء كبير من عنق زجاجة الاتصال الذي أضر بمحاولات Mac Clustering السابقة.
أما في 2026 فأصبح لدى Apple:
- دعم RDMA رسمي منذ macOS 26.2.
- Technote مخصصة للمطورين.
- JACCL كطبقة Collective Communication.
- دعم Distributed داخل MLX.
- أدوات مثل
mlx.distributed_configوmlx.launch. - شرح كامل للـCluster في WWDC26.
- تسويق رسمي لـMac Studio باعتباره قادرًا على Clustered Compute.
- رقم معلن يصل إلى 3x لأداء Distributed AI Inference بأربع عقد في اختبارات Apple.
لهذا لم يعد السؤال هو ما إذا كان من الممكن ربط عدة أجهزة Mac وتشغيل LLM بينها؛ ذلك أصبح مثبتًا وموثقًا. السؤال الأهم الآن هو ما إذا كانت طبيعة النموذج والميزانية وحجم الاستخدام تجعل هذا التصميم أفضل من جهاز واحد أو خدمة سحابية أو منصة GPU مخصصة.
الخلاصة
ما جعل Mac Studio Cluster مثيرًا للاهتمام ليس مجرد جمع مئات أنوية GPU أو تيرابايتات من الذاكرة. العامل الحاسم هو بناء مسار اتصال موزع مناسب للذكاء الاصطناعي: Thunderbolt 5 للنقل، RDMA لتقليل عبء الاتصال، JACCL للعمليات الجماعية، وMLX لتوزيع النموذج والحساب.
هذه المنظومة تسمح بتقسيم نماذج كبيرة على عدة أجهزة Apple silicon، وتوفر في Workloads مناسبة تسارعًا حقيقيًا؛ وApple نفسها تتحدث حاليًا عن أداء يصل إلى ثلاثة أضعاف باستخدام أربع عقد.
لكنها ليست بديلًا مباشرًا عن Supercomputer أو GPU Cluster داخل مركز بيانات. كل Mac ما زال عقدة مستقلة بذاكرته ومعالجه، والأداء يتأثر بالاتصال وطريقة توزيع النموذج، والتوسع الفيزيائي عبر Full Mesh له حدوده.
ومع وصول Mac Studio بمعالجي M5 Max وM5 Ultra وسعة تصل إلى 512GB لكل جهاز، أصبح Local AI على Mac ينتقل من تشغيل نموذج صغير على كمبيوتر شخصي إلى إمكانية بناء Workstation Cluster حقيقي لتشغيل نماذج Open-Weight ضخمة داخل المكتب، دون الحاجة إلى إرسال كل عملية Inference إلى السحابة.