Buzz Mesh: عندما يشغّل المجتمع النموذج

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

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

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

ما هو Buzz فعلاً

Buzz مشروع مفتوح المصدر من Block، الشركة التي يقودها Jack Dorsey وتقف خلف Square. ومع ذلك، فاختزاله في «تطبيق Jack Dorsey الجديد» غير دقيق. يُطوّر كمشروع من Block، وشفرته العامة منشورة على GitHub بترخيص Apache 2.0.

يبدو كمزيج من Slack وGitHub ومنصة للوكلاء. يعمل البشر والوكلاء في القنوات نفسها، ويناقشون المهام، ويديرون الشفرة، ويشغّلون workflows. يحصل كل وكيل على هوية تشفيرية مستقلة وصلاحيات محدودة. وهكذا يمكن فصل الشخص الذي أجاز الإجراء عن الوكيل الذي نفّذه.

هذا ليس تجميلاً لإدارة المستخدمين. تستخدم أنظمة كثيرة حساب خدمة مشتركاً أو API key بصلاحيات واسعة. نعرف لاحقاً أن «الأتمتة» فعلت شيئاً، لكن ليس دائماً أي نسخة وبأي تكليف. يريد Buzz إظهار التفويض ونسبة الفعل كلٌ على حدة.

يمكن استضافة مساحة العمل ذاتياً. تعتمد المعمارية المنشورة مكونات مألوفة: Buzz Relay وPostgreSQL للأحداث والبحث وRedis لـPub/Sub والحضور وتخزين متوافق مع S3 للوسائط. إخفاء الواقع التشغيلي لا يجعل اللامركزية أكثر مصداقية.

Nostr هو الأساس

يعني Nostr عبارة Notes and Other Stuff Transmitted by Relays. يمتلك المستخدم زوج مفاتيح تشفيرية، ويوقّع الأحداث وينشرها إلى relays. تشترك التطبيقات في الأحداث المطلوبة عبر relay واحد أو أكثر.

يتضمن الحدث هوية المرسل العامة ووقتاً ونوعاً ومحتوى ومراجع وتوقيعاً. يبقى المفتاح الخاص لدى المستخدم، بينما يعمل المفتاح العام كهوية ووسيلة تحقق. يستخدم Nostr توقيعات Schnorr على secp256k1، وهي المنحنى البيضاوي المركزي أيضاً في Bitcoin.

سجل موقّع، لا blockchain

Nostr ليس blockchain. لا تعدين ولا إجماع عالمي ولا سلسلة واحدة تنتظرها كل relays. يقبل relay الأحداث ويخزنها وفق قواعده ثم يرسلها إلى التطبيقات، وقد تحتفظ relays أخرى بالأحداث نفسها أو بغيرها.

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

يثبت التوقيع أن مفتاحاً بعينه وقّع حدثاً، لكنه لا يضمن أن relay سيقدمه إلى الأبد. لذلك تحتاج الاستضافة الذاتية إلى backups وتصدير ومراقبة وإدارة مفاتيح سليمة. المفتاح الخاص المفقود ليس كلمة مرور يعيدها المدير، والمفتاح المسروق يمنح المهاجم هوية قادرة على توقيع أحداث صحيحة.

ما علاقة Bitcoin

يرتبط Nostr ثقافياً وتقنياً بمجتمع Bitcoin. يعرّف NIP-57 ميزة Lightning Zaps التي تتيح دفع satoshi لأشخاص أو أحداث وتمثيل إيصالات الدفع كأحداث.

لكن Bitcoin ليس إلزامياً. يعمل Nostr بلا blockchain أو عملة. كما أن Buzz Shared Compute ليس حالياً سوقاً مفتوحة تكسب فيها أجهزة مجهولة satoshi مقابل كل token. المشاركة طوعية داخل المجتمع. قد تدعم Lightning التعويض أو الحصص لاحقاً، لكنها لا تحل بعد تكلفة الكهرباء والاستهلاك والتشغيل.

كيف تعمل Shared Compute

يربط Buzz Mesh العضوية بإمكانية الوصول إلى مجموعة الحوسبة. يفعّل العضو المشاركة، ويختار نموذجاً يلائم جهازه، ويتيح inference للآخرين. يستطيع الوكيل اختيار «Buzz shared compute» كمزوّد دون API key لخدمة خارجية.

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

يحمي تشفير النقل الطريق، ولا يعمي الطرف النهائي. استخدام عتاد شخص آخر يتطلب الثقة بمشغّله. تقول رؤية Mesh بوضوح إن خصوصية المجتمع لا تتجاوز موثوقية أعضائه.

inference البعيد ليس inference موزعاً تلقائياً

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

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

يصف Buzz الاتجاهين. يعرض دليل التطوير مساراً حقيقياً من التطبيق إلى inference محلي أو بعيد. أما تقسيم النموذج على عدة أجهزة فهو جزء من رؤية Mesh: هدف معقول، لكنه ليس بعد منصة إنتاج تتوسع بلا حدود، وبعض الوظائف ما زالت خلف feature flag.

عنق الشبكة في مجموعة Mac Studio

يربط NetworkChuck أربعة أجهزة Mac Studio، في كل منها 512 GB من Unified Memory، لتوفير 2 TB تصل إليها وحدات GPU. لكن تجربته السابقة بخمسة أجهزة جعلت inference أبطأ بنسبة 91% وفق مقارنته.

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

يعرض NetworkChuck انخفاضاً من نحو 300 إلى 3 ميكروثوانٍ. ومع Llama 70B يرتفع الأداء من نحو 5 tokens في الثانية بأسلوب pipeline إلى 16 مع tensor وRDMA. لا تصبح المجموعة كلها أسرع مئة مرة؛ ينخفض تأخير الاتصال بهذا المقدار تقريباً، بينما يزيد throughput النموذج أكثر بقليل من ثلاثة أضعاف.

منذ macOS 26.2 تدعم أجهزة Apple silicon المزودة بـThunderbolt 5 تقنية RDMA over Thunderbolt. تنقل RDMA البيانات بين مناطق ذاكرة مسجلة بعبء أقل، وقد نسّقتها Apple مع MLX Distributed وJACCL.

لا يلغي التحديث الفيزياء. توصي Apple بطوبولوجيا fully meshed لأدنى تأخير: اتصال واحد لجهازين، ثلاثة كابلات لثلاثة أجهزة، وستة لأربعة. بدءاً من خمس عقد قد تفرض المنافذ طوبولوجيا ring وتمرير البيانات عبر عقد وسيطة. كما يقتصر التنفيذ الحالي على عشرة UC Queue Pairs وعمليات send/receive ثنائية الجانب.

يمكن للمجتمع تقديم عدة نماذج كاملة على أجهزة مختلفة عبر الإنترنت. أما تقسيم نموذج واحد بين زيورخ وبرلين ونيويورك فمشكلة أخرى: كل hop يؤخر tokens، وعقدة بطيئة قد توقف pipeline كله.

لا تُجمع RAM ببساطة

يجب أن توجد أوزان النموذج وKV cache وبيانات runtime واحتياطي السياقات الطويلة في مكان ما. عضوان يشغّل كل منهما نموذجاً في 64 GB يملكان عقدتي inference، لا جهازاً واحداً بذاكرة مشتركة 128 GB. وحده model sharding الحقيقي يغيّر الحد، مقابل اتصال أعقد ومخاطر أعطال أكبر.

يتزامن ذلك في 2026 مع سوق DRAM صعبة. تصف TrendForce الربع الثالث بأنه شديد الضيق، مع دعم طلب خوادم AI لأسعار قياسية. تجعل Shared Compute الأجهزة الموجودة أكثر فائدة، لكنها لا تجعل الأنظمة المحلية الجديدة ذات RAM الكبيرة رخيصة.

قد تكون مشاركة ثلاث workstations موجودة أصلاً منطقية. أما شراؤها فقط لتجنب فاتورة cloud فقد يكون استثماراً أسوأ. الكهرباء والتبريد والقطع والإنترنت والإدارة وخطر التوقف لا تختفي.

ما المميز فعلاً في Buzz Mesh

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

حجم نطاق الثقة معقول أيضاً: أشخاص يعملون معاً بالفعل، لا ملايين الغرباء. يناسب ذلك وكالة أو شركة صغيرة أو مشروع بحث أو فريق تطوير.

الاستقلال عن النموذج ميزة أخرى. تتيح نماذج open-weight التحكم بالأوزان والإعداد وruntime، لكن «امتلاك النموذج» اختصار. الأوزان المفتوحة ليست public domain، وقد تقيّد الرخصة الاستخدام أو التوزيع أو التشغيل التجاري. السيادة تعني توافر الأوزان وفهم الرخصة والتحكم في runtime وإمكان تصدير البيانات والعمل دون المزود الأصلي.

ما لم يقنع بعد

التعويض غير محلول. تكفي المشاركة الطوعية في فريق صغير، لكن عندما يوفر شخص العتاد والكهرباء لعشرة مستخدمين تصبح الحدود والأولويات والقياس والمحاسبة ضرورية. توفر Nostr وLightning مكونات، لا اقتصاداً كاملاً.

التشغيل سؤال آخر: من يحدّث النماذج ويتحقق من مصدرها ورخصتها؟ أي عقدة ترى prompts الحساسة؟ وماذا يحدث عند الضغط أو sleep أو سفر notebook أو اختفاء جهاز أثناء الإجابة؟ cloud مكلفة، لكنها تتحمل كثيراً من هذا العمل الممل.

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

وأخيراً، Buzz شاب. الشفرة والمعمارية ومسار الاختبار أكثر من شرائح عرض، لكن feature flags والإصدارات السريعة والوثائق المتحركة تكشف استمرار التطور. يصلح للتجربة ببيانات غير حرجة، لا للاعتماد عليه دون exit plan.

ما الذي يُنفذ فعلاً

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

ما زالت السوق المفتوحة والcredits المستقرة وhardware attestation والتحقق المستقل وتشغيل آلاف العقد المجهولة غائبة. لكن توجد واجهة مفهومة وحالة استخدام مباشرة: يحتاج وكيل إلى نموذج، ويملك عضو جهازاً، وينسق relay، وتحسب الآلات.

إذا عملت الدائرة الصغيرة بثبات، يمكن أن تلحق بها الحصص والcredits ومدفوعات Lightning والاتحاد الإقليمي والمهام القابلة للتحقق. يجب أولاً أن تعمل الدائرة الصغيرة.

أساس المقال وحدوده

لم أختبر Buzz Mesh بنفسي على عدة أجهزة. يعتمد التحليل على الشفرة العامة والمعمارية ورؤية Mesh ودليل التطوير ومواصفات Nostr ووثائق RDMA من Apple، بعد مراجعتها في 21 أغسطس 2026. لذلك فالتصريحات عن الاستقرار وthroughput والحمل الحقيقي ليست قياسات شخصية.

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

إلى اللقاء في المرة القادمة،
Joe