عميل/خادم LLM خاص: 1000 سطر من AllSpeak يتجاوز تعقيدات الشبكة

في 27 سبتمبر 2026، كشف تقرير فني عن تصميم نظام عميل/خادم خاص بالنماذج اللغوية الكبيرة (LLM) يتجاوز تحديات التكوين التقليدي للشبكات. اعتمد الحل، الذي نُشر على Dev.to، على بروتوكول MQTT وأُنجز في حوالي 1000 سطر من الكود المكتوب بلغة AllSpeak، ما يوفر وصولاً آمناً إلى نموذج LLM محلي يعمل على بطاقة رسوميات Nvidia GPU من الأجهزة المحمولة. هذه المنهجية تتجنب الحاجة إلى حلول معقدة كـ Docker، أو الوكلاء العكسيين، أو إعادة توجيه المنافذ، أو شبكات VPN، أو طبقات TLS والمصادقة، والتي غالباً ما تتطلب جهداً كبيراً في إعداد ملفات YAML بدلاً من التركيز على الوظيفة الأساسية. النظام الجديد لا يتطلب فتح أي منافذ على الشبكة المنزلية، محققاً أقل "سطح هجوم" ممكن، بتكلفة تشغيلية للخادم المستأجر أقل من سعر وجبة جاهزة شهرياً.
التحليل التقني
يعتمد هذا النظام على مبدأ "الاتصال الخارجي" من كلا الطرفين، حيث لا يقبل أي من الجهاز العميل (الهاتف/الكمبيوتر المحمول) أو الخادم المحلي (الكمبيوتر الشخصي) أي اتصالات واردة من الإنترنت. يخدم نقطة الالتقاء هذه وسيط رسائل MQTT، وهو بنية تحتية موجودة منذ عقود. يتصل العملاء بالوسيط (broker) ويشتركون في المواضيع (topics)، ويتلقون ما يُنشر فيها. وفي هذه الحالة، تعمل البطاقة الرسومية Nvidia GPU محلياً على الكمبيوتر الشخصي، وتشغل Ollama نموذج LLM بحجم 4B، القادر على إنتاج إجابات في جزء من الثانية من خلال 6 غيغابايت من ذاكرة GPU.
تتمحور البنية حول ثلاثة مكونات رئيسية:
- صفحة الويب الثابتة (العميل): تعمل على الهاتف/الكمبيوتر المحمول، تنشر الأسئلة إلى الوسيط عبر `wss://443`.
- الخدمة المحلية (الخادم): على الكمبيوتر الشخصي، تشترك في موضوع الأسئلة، تستدعي Ollama (عبر `http://11434`)، ثم تنشر الإجابات مجزأة عبر `tls://8883`.
- وسيط MQTT: خادم Linux مستأجر يشغل Mosquitto وNginx، يعمل كنقطة تبادل للرسائل دون معرفة مباشرة بالشبكة المنزلية.
تظهر الأرقام الهندسية كفاءة الحل:
- واجهة المستخدم (الصفحة): 420 سطراً (252 سطراً من الكود).
- الخدمة على الكمبيوتر الشخصي: 94 سطراً (46 سطراً من الكود).
- مكون Python الإضافي: 536 سطراً (بما في ذلك التعليقات).
- إجمالي محتويات خادم الويب: 10 ملفات بحجم 71 كيلوبايت (51 كيلوبايت منها للأيقونات).
- تهيئة الوسيط: 15 سطراً، بالإضافة إلى موقع Nginx بـ 6 أسطر.
صادفت عملية التطوير تحديات تقنية، بما في ذلك:
- وسيط MQTT يتجاهل الرسائل الاختبارية الصامتة لمدة 20 دقيقة بسبب عدم مطابقة صيغة AllSpeak الخاصة بالتحزيم (`!last!`, `!part!`).
- خدمة SSHD على الكمبيوتر الشخصي ترفض المفتاح لمدة ساعة دون توضيح للعميل، بسبب إعداد `StrictModes` الذي يتجاهل المفاتيح في مجلدات بوضع `777`.
- بعض الشروط في وقت تشغيل AllSpeak لم تكن تعمل كما هو متوقع، مثل `is object` لعدم تطبيقها على القواميس، و`clear` التي تترك قيمة منطقية `false` بدلاً من سلسلة نصية فارغة.
تم اكتشاف هذه المشكلات وتصحيحها من خلال عملية اختبار صارمة شملت بيئة اختبار رأسية للصفحة، واختبارات وحدة للمكون الإضافي، وتشغيلاً كاملاً للنظام مع وسيط حقيقي ونموذج وهمي.
السياق وتأثير السوق
يقدم هذا الحل نموذجاً مبسطاً للوصول إلى الموارد الحسابية المحلية مقارنةً بالبدائل الحالية. على سبيل المثال، يوفر Tailscale أيضاً عدم فتح منافذ، وهو مجاني، ولكنه يتطلب تثبيت عميل على كل جهاز، وهو ما يتناقض مع رغبة المستخدم في مشاركة مجرد رابط URL. في المقابل، Cloudflare Tunnel مجاني ولا يتطلب عميلاً، لكنه يعرض خدمة HTTP، مما يضع عبء بناء طبقة المصادقة على عاتق المستخدم بدلاً من الاعتماد على حسابات الوسيط وقوائم التحكم بالوصول (ACLs). أما إعادة توجيه المنافذ مع وكيل عكسي، فتعرض الجهاز الذي يحتوي على GPU مباشرة للإنترنت، وهو السيناريو الذي تجنبه هذا التصميم.
في هذا النظام، يُسند الجزء الأكبر من الأمن إلى طبقات تحكم صغيرة ومركزة. بيانات اعتماد MQTT الخاصة بالصفحة تكون عامة، ويمكن قراءتها من حركة المرور. ومع ذلك، تم التخفيف من هذا الخطر بقرارين:
- تحديد حساب الوسيط الخاص بالصفحة بواسطة ACL إلى مساحة اسم موضوع واحدة فقط (أربع أسطر من التهيئة)، مما يعني أن تسرب هذه البيانات لا يمنح وصولاً كاملاً إلى الوسيط.
- اعتماد رمز وصول منفصل، يُفحص على الكمبيوتر الشخصي لكل استعلام، ويُكتب في الصفحة مرة واحدة لكل جهاز ويُحفظ في مساحة تخزين المتصفح الخاصة.
دوران رمز الوصول هذا يلغي وصول جهاز معين، بينما دوران كلمة مرور وسيط الصفحة يلغي أي نسخة مسربة من الصفحة. لا يُعد هذا بديلاً عن التفكير الشامل في الأمن، ولكنه يقلل بشكل كبير من "سطح التفكير" الأمني المطلوب مقارنة بخدمة استدلال مكشوفة. ومع ذلك، تظل هناك قيود واضحة: النظام يدعم استعلاماً واحداً في كل مرة، ويستخدم رمز وصول مشتركاً بدلاً من تسجيلات دخول فردية، ويُعد أداة شخصية لا منتجاً تجارياً، حيث يعتمد على نموذج 4B على GPU بسعة 6 غيغابايت.
رؤية Glitch4Techs
يشكل هذا الحل الهندسي تطوراً ملحوظاً في تبسيط الوصول إلى موارد الذكاء الاصطناعي المحلية. لقد نجح المشروع في تحقيق هدف "أقل سطح ممكن"، بتكلفة منخفضة للغاية وحجم كود قابل للمراجعة. إنه انتصار للتصميم المتأني الذي يقلل من التعقيد التشغيلي المرتبط بنشر LLMs الخاصة. ومع ذلك، فإن النقطة الشائكة تكمن في طبيعة بيانات اعتماد MQTT العامة للصفحة. على الرغم من وجود قائمة ACL تحد من نطاق الوصول إلى مساحة اسم موضوع واحدة (أربع أسطر من التهيئة)، فإن اعتماد هذا النظام على رمز وصول ثانوي يتم التحقق منه على الكمبيوتر الشخصي يمثل طبقة أمنية حرجة. في حالة تجاوز هذا الرمز أو تعرضه للاختراق، فإن البيانات العامة لـ MQTT يمكن أن تصبح نقطة ضعف تستغلها الأطراف الخبيثة للتلاعب بحركة المرور عبر الوسيط، حتى لو لم يؤدِ ذلك إلى وصول مباشر إلى GPU. هذا الضعف المحتمل، المقترن بالاعتماد على رمز مشترك واحد بدلاً من مصادقة المستخدم الفردية، يحد من قابلية التوسع والمراجعة الأمنية لأي استخدام يتجاوز الأداة الشخصية البحتة.
كن أول من يعرف بمستقبل التقنية
أهم الأخبار والتحليلات التقنية مباشرة في بريدك.



