Lumabri مدل‌های عظیم MoE را روی شبکه‌ای از پردازنده‌های معمولی اجرا می‌کند

تصور کنید بتوانید مدل‌های زبانی غول‌پیکری را که برای اجرا به هزاران دلار سخت‌افزار نیاز دارند، روی لپ‌تاپ قدیمی خود و با کمک چند دوست اجرا کنید. Lumabri این تخیل را به واقعیت تبدیل کرده است تا سد سخت‌افزاری در برابر مدل‌های بازمتن را کاملاً تخریب کند.

طبق مستندات منتشر شده در ۹ اوت ۲۰۲۶، این پروژه اجازه می‌دهد کاربران با تجمیع فضای دیسک و توان پردازشی چندین گره (Peer)، مدل‌های عظیم ترکیب خبره‌ها (Mixture of Experts یا MoE) — شبیه به تیمی از متخصصان که در هر لحظه فقط یکی یا دو نفر برای پاسخ به سؤال فعال می‌شوند — را بدون نیاز به حتی یک واحد پردازش گرافیکی (GPU) اجرا کنند. نکته کلیدی این است که خروجی مدل، چه روی یک سرور پیشرفته و چه روی یک لپ‌تاپ خانگی، بیت‌به‌بیت یکسان است.

بسیاری از تلاش‌های توزیع‌شده پیشین مانند Petals یا hivemind برای بخش‌های سنگین ترنسفورمر به GPUهای رده‌بالا متکی بودند. این موضوع باعث می‌شد ورود به این شبکه برای اکثر کاربران غیرممکن باشد، زیرا تنها تعداد کمی از افراد سخت‌افزار لازم را در اختیار داشتند. Lumabri این منطق را وارونه کرد و سیستم را ابتدا برای پردازنده مرکزی (CPU) و SSD بهینه کرد. این رویکرد یادآور تلاش‌های مشابهی است که در پروژه Reame برای کاهش هزینه‌های استنتاج از طریق اولویت دادن به CPU و دیسک دنبال شده بود. در این معماری، GPU دیگر یک پیش‌نیاز نیست، بلکه صرفاً یک شتاب‌دهنده برای افزایش سرعت است. اصل بنیادین این است که هر ماشینی می‌تواند به شبکه بپیوندد؛ حتی یک شبکه که هیچ GPU در آن وجود ندارد، یک شبکه کاملاً فعال و کاربردی است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی دموکراتیزه کردن مدل‌های بازمتن اشاره کردیم، حذف وابستگی به سخت‌افزارهای انحصاری، اولین قدم برای استقلال مدل‌های هوش مصنوعی است.

معماری شبکه Swarm

این سیستم از یک ساختار دو مرحله‌ای استفاده می‌کند که هدف آن حذف نیاز به دانلودهای حجیم محلی است. هسته این سیستم بر پایه موتور colibri است که به زبان C خالص و بدون هیچ وابستگی خارجی (Dependency) نوشته شده است. در فاز اول، تمرکز بر روی بایت‌های مدل است. یک «ردیاب» (Tracker) به عنوان فهرست عمل می‌کند و «نگهداران» (Maintainers) محدوده‌های بایتی خاصی از دایرکتوری مدل را سرو می‌کنند.

وقتی کاربر با مدل چت می‌کند، بایت‌های مورد نیاز در اولین استفاده از شبکه گرفته شده و در یک آینه محلی ذخیره می‌شوند. به همین دلیل، اولین پاسخ به دلیل انتقال داده‌ها از شبکه کندتر است، اما پاسخ‌های بعدی با سرعت کامل از دیسک محلی خوانده می‌شوند. حتی اگر سرور اصلی آفلاین شود، کپی محلی در مسیر ~/.lumabri همچنان فعال می‌ماند.

برای اینکه مدل‌های شبکه‌ای شبیه به فایل‌های محلی به نظر برسند، Lumabri از یک لایه واسط یا شیم (liblumabri.so) با استفاده از LD_PRELOAD استفاده می‌کند تا فراخوانی‌های libc (مانند open ،fopen ،opendir و pread) را بازنویسی کند. این یعنی موتور مدل تصور می‌کند فایل‌ها روی هارد دیسک هستند، در حالی که در واقعیت از گره‌های مختلف شبکه فراخوانی می‌شوند. فایل‌ها به صورت فایل‌های محلی پراکنده (Sparse Files) با اندازه واقعی ذخیره می‌شوند تا دستوراتی مثل fstat و readdir و همچنین کش صفحات هسته (Kernel Page Cache) به صورت بومی کار کنند. هرگونه تلاش برای نوشتن روی فایل‌های مدل خطای EROFS (سیستم فایل فقط خواندنی) برمی‌گرداند و اگر بلوکی وجود داشته باشد که هیچ گرهی نتواند آن را سرو کند، سیستم به جای ارسال صفرهای خام، خطای صریح EIO را گزارش می‌کند.

فاز دوم: اجرای توزیع‌شده خبره‌ها

در حالی که فاز اول داده‌ها را مدیریت می‌کند، فاز دوم محاسبات ریاضی را توزیع می‌کند. در مدل‌های MoE، برای هر توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک که مدل تکه‌تکه می‌خورد — تنها بخش کوچکی از مدل (خبره‌ها) فعال می‌شوند. Lumabri وزن‌های متراکم (Dense Weights)، روتور و KV Cache را روی دستگاه کاربر نگه می‌دارد، اما ردیف فعال‌سازی (Activation Row) — که حدود ۴ کیلوبایت است — را به گره‌ای می‌فرستد که خبره مورد نظر را در اختیار دارد. در این فرآیند، وزن‌های خبره هرگز به دستگاه کاربر (Chatter) نمی‌رسند.

این مکانیزم اجازه می‌دهد مدلی را اجرا کنید که بسیار بزرگ‌تر از رم دستگاه شماست. این رویکرد روی مدل‌های OLMoE، GLM، Inkling، Kimi K3 و DeepSeek V4 به اثبات رسیده است. به دلیل استفاده از مسیر کد یکسان در هر دو حالت محلی و توزیع‌شده (برای مثال، فایل expert_node.c شامل olmoe.c است)، توکن‌های تولید شده کاملاً یکسان و بیت‌به‌بیت هستند.

جزئیات پیاده‌سازی در موتورهای مختلف

به نقل از توسعه‌دهندگان، پشتیبانی از موتورهای مختلف نیازمند قلاب‌های (Hooks) خاصی است، زیرا هر لایه‌ای مسیریابی نمی‌کند. Lumabri این تفاوت‌ها را از طریق هدرهای اختصاصی در مسیر expert_engines/ و پچ‌های تولید شده توسط make_patches.py مدیریت می‌کند. باینری موتور هرگز تغییر نمی‌کند؛ بلکه سیستم یک کپی از آن را پچ می‌کند.

• GLM: نیازمند رویکرد دسته‌بندی (Batching) خاصی است. GLM خبره‌ها را روی تمام ردیف‌های مسیریابی شده به صورت یکجا محاسبه می‌کند؛ Lumabri این مورد را از طریق lumi_moe_apply_batch بازسازی می‌کند تا ترتیب ردیف‌ها و انباشت داده‌ها با موتور اصلی مطابقت داشته باشد. همچنین یک ردیف MTP در ایندکس n_layers وجود دارد که مسیریابی می‌کند.
• DeepSeek V4: پیچیده‌ترین پیاده‌سازی است. در اینجا وزن روتور یک مقیاس ساده نیست، بلکه قبل از تصویر پایین (Down Projection) ادغام شده و به bf16 گرد می‌شود. این یعنی وزن باید همراه با فعال‌سازی به گره مقصد ارسال شود. ذخیره خبره در V4 مستقیماً از دایرکتوری مدل باز می‌شود، به این معنی که گره‌ها هیچ وزن متراکمی ندارند. این مدل یک پیکربندی سخت‌گیرانه و یک طرح تنسور FP8/FP4 را اعتبارسنجی می‌کند. فایل deepseek.c توسط ابزار tools/amalgamate_deepseek.py تولید می‌شود و برای اعتبارسنجی به یک مدل واقعی نیاز دارد، زیرا نمونه‌های مصنوعی برای پیکربندی سخت‌گیرانه آن بیش از حد پیچیده هستند.
• Kimi K3: مسیریابی را در یک فضای نهان (Latent Space) در c->latent انجام می‌دهد، بنابراین پهنای داده‌های ارسالی در شبکه به جای پهنای پنهان (Hidden Width)، برابر با پهنای نهان است.
• Inkling و OLMoE: از طریق تست‌های سنتتیک و اسکریپت phase2_test.sh ثابت شده که تطابق بایت‌ها در اجرای P2P کاملاً حفظ می‌شود.

عملکرد و مدیریت تأخیر

تأخیر شبکه بزرگ‌ترین گلوگاه در استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند — توزیع‌شده است. Lumabri برای مقابله با این مشکل استراتژی‌های زیر را به کار گرفته است:

• مسیریابی بر اساس نزدیکی: سیستم در هنگام شروع با ارسال دو PING، فاصله تا گره‌ها را اندازه‌گیری می‌کند و درخواست‌ها را به نزدیک‌ترین کپی می‌فرستد. گرهی که تأخیر آن در محدوده ۲۵٪ + ۲ میلی‌ثانیه نسبت به بهترین تأخیر باشد، «به اندازه کافی نزدیک» تلقی شده و در توزیع بار مشارکت می‌کند. در تست‌ها، اجرای خبره‌ای با تأخیر ۲ میلی‌ثانیه در برابر ۳۰ میلی‌ثانیه، سرعت را از ۱.۴ به ۱۰.۵ توکن در ثانیه رساند.
• پیش‌خوانی (Readahead): این قابلیت توسط LUMABRI_PREFETCH (پیش‌فرض ۲ بلوک) کنترل می‌شود. در حالی که موتور در حال پردازش بلوک N است، شبکه بلوک‌های N+1 تا N+K را ارسال می‌کند. این کار سرعت بارگذاری آینه‌های سرد در شبکه‌های با تأخیر ۴۰ میلی‌ثانیه‌ای تا ۴۵٪ افزایش می‌دهد.
• جایگزینی خودکار (Failover): اگر گرهی در حین تولید پاسخ از دسترس خارج شود، سیستم به‌طور خودکار درخواست را به کپی دیگری می‌فرستد. تست‌ها نشان دادند که حذف یک اهداکننده در میانه تولید، منجر به یک خط جایگزینی می‌شود اما توکن‌ها همچنان بیت‌به‌بیت یکسان می‌مانند.
• هم‌زمانی: اسکریپت concurrency_test.sh نشان می‌دهد که روی یک سیستم ۶ هسته‌ای که سرور، گره‌ها و ۴ کلاینت را اجرا می‌کند، فاصله بین سریع‌ترین و کندترین پاسخ ثابت می‌ماند (مثلاً ۱۰.۴ ثانیه تا ۱۰.۷ ثانیه). این نشان‌دهنده اشغال CPU است و نه ایجاد صف‌های انتظار (Lock Convoys).

امنیت در محیط‌های غیرقابل اعتماد

اجرای کد و داده روی دستگاه غریبه‌ها ریسک‌های امنیتی دارد. Lumabri یک مدل اعتماد لایه‌بندی شده را معرفی کرده است:

شبکه‌های باز (Open Swarms): در اینجا هر کسی می‌تواند بپیوندد اما هیچ‌کس مورد اعتماد نیست. سیستم از هش‌های SHA-256 برای هر مگابایت داده استفاده می‌کند تا سلامت داده‌ها را تأیید کند. هر نگهدار این هش‌ها را محاسبه کرده (در .lumabri_hashes/ ذخیره می‌کند) و هنگام ثبت‌نام ارسال می‌کند. ردیاب اولین اعلان را به عنوان حقیقت پذیرفته و هر ثبت‌نام بعدی که هش‌هایش متفاوت باشد را حذف می‌کند. کاربران هر بلوک دریافتی را تأیید می‌کنند. برای تأیید محاسبات، با تنظیم LUMABRI_VERIFY=N سیستم N درصد از فراخوانی‌های خبره را روی یک کپی دیگر تکرار می‌کند؛ هرگونه اختلاف، نشانه تقلب است و اجرا متوقف می‌شود.

شبکه‌های امضا شده (Signed Swarms): برای جلوگیری از دستکاری مدل توسط ردیاب، اپراتور می‌تواند بردار هش‌ها را با کلید Ed25519 امضا کند (lumabri key --out swarm). منبع اصلی هر بردار هش را به مدل، مسیر و اندازه متصل کرده و امضا می‌کند. کاربران این امضاها را با یک کلید عمومی که از راهی خارج از شبکه دریافت کرده‌اند، تأیید می‌کنند. این تضمین می‌کند که ردیاب شاید بتواند حقیقت را پنهان کند، اما نمی‌تواند آن را بازنویسی کند. پیاده‌سازی‌های Ed25519 و SHA-512 به زبان C و مطابق با RFC 8032 و OpenSSL هستند.

شبکه‌های خصوصی (Private Swarms): برای گروه‌های دعوت‌نامه-محور، از توکن‌های دسترسی (LUMABRI_TOKEN) استفاده می‌شود. این توکن به ردیاب ارسال شده و هر گره نگهدار یا خبره، اتصالات بدون احراز هویت را رد می‌کند. این کار هم از بایت‌ها و هم از محاسبات محافظت می‌کند.

نقش‌ها و استقرار

کاربران می‌توانند در سه نقش متمایز (که از طریق TUI یا فلگ --role مدیریت می‌شوند) وارد شبکه شوند:

• چت‌کننده (Chatter): مصرف‌کننده مدل. در اولین ورود، آدرس ردیاب و کلید عمومی را وارد می‌کند و در دفعات بعد تنها با فشردن Enter وارد می‌شود.
• اهداکننده دیسک (Disk Donor): بودجه‌ای از فضای گیگابایتی خود را اختصاص می‌دهد (--donate GB). ردیاب ابتدا فایل‌هایی را که کمترین کپی را دارند اختصاص می‌دهد (Rarest-first) تا شبکه در نقاط حساس تقویت شود. اهداکنندگان ابتدا سهم خود را از شبکه می‌گیرند و سپس آن را سرو می‌کنند.
• اهداکننده محاسبات (Compute Donor): خبره‌ها را برای دیگران اجرا می‌کند. این نقش نیازمند داشتن وزن‌های مدل روی دیسک محلی است (--model-dir DIR). این گره‌ها می‌توانند از یک کش RAM از نوع LRU (--cache N) استفاده کنند تا خبره‌ها را از SSD استریم کنند؛ این یعنی یک ماشین ۱۶ گیگابایتی می‌تواند بخشی از یک مدل ۵۰۰ گیگابایتی را نگه دارد.

مکانیسم‌های فنی و راه‌اندازی

برای شروع سریع، Lumabri ابزارهای تولید مدل‌های تصادفی (Fixture) را از طریق make fixture با استفاده از پایتون و numpy فراهم کرده است. این کار اجازه می‌دهد اولین شبکه در ۵ دقیقه ایجاد شود و خط لوله از lumabri serve تا lumabri chat پیش از استقرار مدل‌های واقعی و چند گیگابایتی تست شود.

دستورات شروع سریع:

• سرور: ./lumabri serve --model /path/to/model
• چت‌کننده: ./lumabri chat --tracker <server-ip>:7300 --engines-dir /path/to/colibri/c
• اهداکننده دیسک: ./lumabri serve --model ./slice --join TRACKER:7300 --model-name NAME --donate 5

مدیریت شبکه:

• کف NAT: نگهداران یک اتصال کنترلی خروجی به ردیاب نگه می‌دارند. اگر اتصال مستقیم شکست بخورد، بایت‌ها از طریق این اتصال رله می‌شوند تا کاربران پشت NATهای خانگی بدون تنظیمات روتر بتوانند داده‌ها را سرو کنند.
• منطق ردیاب: ردیاب در مسیر اصلی انتقال داده نیست؛ فقط در هنگام بوت و هر ۱۰ ثانیه یک‌بار برای ضربان قلب (Heartbeat) مورد مشورت قرار می‌گیرد، نه برای هر توکن.
• تخصیص خبره: اهداکنندگان محاسبات می‌توانند با --hold N تعداد خبره‌هایی که می‌توانند حمل کنند را مشخص کنند و ردیاب مجموعه‌ای را تخصیص می‌دهد که هیچ‌کس دیگر پوشش نمی‌دهد.

پیاده‌سازی دقیق و تست

برای تضمین صحت مطلق، Lumabri از یک مجموعه تست سخت‌گیرانه استفاده می‌کند. اسکریپت selftest.sh تطابق بایت‌ها را در حالت‌های سرد، گرم و آفلاین تأیید می‌کند. برای فاز دوم، تست‌های جداگانه‌ای برای هر موتور (مانند phase2_glm_test.sh و phase2_deepseek_test.sh) وجود دارد تا اطمینان حاصل شود که اجرای خبره از راه دور با اجرای محلی بیت‌به‌بیت یکسان است. برای کسانی که به دنبال ارزیابی دقیق‌تر مدل‌های محلی هستند، ابزار Homebench راهکاری جامع برای سنجش سرعت و کیفیت این مدل‌ها در یک دستور فراهم کرده است.

مدیریت مدل

یک ردیاب می‌تواند چندین مدل را به طور همزمان فهرست کند. یک سرور می‌تواند چندین نمونه از lumabri serve را روی پورت‌های مختلف اجرا کند (مثلاً ۷۳۰۰ برای GLM، ۷۳۱۰ برای OLMoE و ۷۳۲۰ برای DeepSeek). یک کاربر می‌تواند در حین چت با دستور /model <name> بین این مدل‌ها جابجا شود، که باعث ری‌استارت شدن موتور با معماری مدل جدید می‌شود.

مقیاس‌پذیری منابع

• حافظه: گره خبره برای هر اتصال یک رشته (Thread) اجرا می‌کند، اما در صورت نبود داده در کش، یک قفل لودر (Loader Lock) فعال می‌شود. کاربران می‌توانند --cache را طوری تنظیم کنند که مجموعه کاری در رم جای بگیرد تا این خطاها به حداقل برسد.
• دیسک: نگهداران از pread موقعیتی روی توصیف‌گرهای فایل مشترک استفاده می‌کنند که باعث می‌شود هیچ قفلی در مسیر خواندن نباشد و کش صفحات بتواند چندین کلاینت را به طور بهینه سرو کند.
• محاسبات: concurrency_test.sh ثابت می‌کند که با پیوستن چت‌کننده‌های بیشتر، زمان مطلق به دلیل اشغال CPU رشد می‌کند، اما فاصله بین سریع‌ترین و کندترین پاسخ ثابت می‌ماند که نشان‌دهنده نبود صف‌های انتظار است.

این تغییر به سمت شبکه‌های دترمینستیک و مبتنی بر CPU، این فرض را که هوش مصنوعی در مقیاس بزرگ نیازمند خوشه‌های متمرکز GPU است، تغییر می‌دهد. با تبدیل «کف سخت‌افزاری» به یک CPU ساده، Lumabri توانایی میزبانی و اجرای بزرگ‌ترین مدل‌های بازمتن جهان را دموکراتیزه می‌کند.

گام بعدی شما

• اگر سخت‌افزار محدودی دارید، از مدل‌های MoE کوچک‌تر برای تست اولیه Lumabri استفاده کنید.
• برای کاهش تأخیر، سعی کنید در شبکه‌هایی عضو شوید که گره‌های آن‌ها در نزدیکی جغرافیایی شما هستند.
• اگر فضای SSD خالی دارید، به عنوان Disk Donor عضو شوید تا پایداری مدل‌های بازمتن در شبکه افزایش یابد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک اینکه چگونه تراشه‌های جدید در حال تغییر بازی استنتاج هستند، به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.