// tier: helix-primary · order 4

HelixLLM betalicense: TBD

GoGinHTTP/3 QUICTLS 1.3llama.cppLLMsVerifiergRPCSSEKafkaPrometheusOpenTelemetry

Source

• HelixDevelopment/HelixLLM

// architecture

ثنائي واحد، ستة أوضاع — استدلال متوافق مع OpenAI وAnthropic من حاسوبك المحمول إلى مجموعة متعددة المضيفين.

HelixLLM هو نظام LLM موزّع على مستوى المؤسسات مبنيّ على Go: ثنائي واحد بنظام أوضاع يتدرّج من التطوير أحادي المضيف إلى الإنتاج متعدد المضيفين. يقدّم واجهات برمجة تطبيقات متوافقة بالكامل مع OpenAI وAnthropic عبر HTTP/3، مع استدلال محلي باستخدام llama.cpp، وسلسلة احتياطية متعددة المزودين مُقيّمة، وخط أنابيب RAG، ونظام وكيل ReAct.

HelixLLM هو نظام LLM موزّع ثنائي مبنيّ على Go. يعرض واجهات برمجة تطبيقات متوافقة مع OpenAI وAnthropic عبر HTTP/3، ويشغّل استدلالاً محلياً باستخدام llama.cpp، ويكتشف تلقائياً ويقيّم مزودي الخدمات السحابية المجانية ضمن سلسلة احتياطية، ويضيف خط أنابيب معرفية RAG بالإضافة إلى وكيل ReAct القادر على استدعاء الأدوات — قابل للنشر في ستة أوضاع مختلفة.

HelixLLM هو نظام LLM موزّع على مستوى المؤسسات، مبنيّ باستخدام Go وGin، وحيلته الأساسية تكمن في أن قطعة برمجية واحدة تخدم جميع المستويات. يُترجم إلى ثنائي واحد يحدد نظام الأوضاع عند النشر ماهية هذا الثنائي: شغّله كـfull للحصول على مثيل شامل على حاسوب محمول، أو وزّع المسؤوليات عبر أوضاع gateway وbrain وknowledge وagents وcontrol موزّعة على عدة مضيفين — نفس الكود يعاد ترتيبه دون إعادة كتابته، من جهاز المطور إلى مجموعة الإنتاج.

يتقن النظام لغتين بطلاقتهما: واجهات برمجة تطبيقات متوافقة بالكامل مع OpenAI وAnthropic، بحيث تعمل عملاء SDK الحالية من كلا النظامين دون تعديل، وكلها تُقدّم عبر HTTP/3 (QUIC) مع احتياطي تلقائي لـHTTP/2 ودعم TLS 1.3. يعمل الاستدلال المحلي عبر llama.cpp مع دعم CUDA وMetal وROCm، بحيث يسرّع نفس البناء على أجهزة Nvidia وApple وAMD على حد سواء. أما الميزة البارزة فهي سلسلة الاحتياطية متعددة المزودين، التي تحول عدم موثوقية الاستدلال السحابي المجاني إلى مورد مُدار وقادر على الشفاء الذاتي: يكتشف HelixLLM تلقائياً النماذج المجانية من أكثر من 7 مزودي خدمات سحابية (Chutes، OpenRouter، HuggingFace، Nvidia، Cerebras، SambaNova، Together)، ويقيمها عبر LLMsVerifier كل 5 دقائق، ويوجّه الطلبات عبر السلسلة المرتبة مع احتياطي تلقائي للأخطاء 429/5xx — مع ضمان استخدام llama.cpp المحلي كملاذ أخير، بحيث لا يفشل الطلب أبداً لعدم توفر مزود.

بالإضافة إلى الاستدلال الخام، يُعد HelixLLM منصة تطبيقات كاملة: يتضمن خط أنابيب معرفية RAG (استيعاب، تجزئة، تضمين، بحث vector) ونظام وكيل ReAct مع استدعاء الأدوات، وجلسات المحادثة، وتكامل RAG ضمن نفس الثنائي. يؤتي نظام الأوضاع ثماره أيضاً على مستوى الاتصال — ففي وضع full تتواصل جميع الطبقات عبر استدعاءات Go المباشرة داخل العملية دون أي عبء شبكي، بينما ينسّق الثنائي المتطابق عند توزيعه على عدة مضيفين عبر gRPC وSSE وKafka. ويكتمل النظام بمفاوضات المحتوى Brotli/gzip، وبث SSE الذي يتطابق مع تنسيقات OpenAI وAnthropic بايتاً ببايت، ومصادقة API-key وJWT مع تحديد المعدل، ومقاييس Prometheus، وتتبع OpenTelemetry، ومجموعة كبيرة من وحدات Go للبنية التحتية الإنتاجية.

المحتوى

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

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

• ملف تنفيذي واحد بنظام مكون من ستة أوضاع يعمل إما بشكل متكامل أو كأدوار موزعة — مكالمات Go المباشرة داخل العملية في وضع full، وgRPC/SSE/Kafka عند الفصل — بحيث تتغير طوبولوجيا النشر دون تغيير في الكود أو فرض ضرائب شبكية غير مطلوبة.
• سلسلة عودة متعددة المزودين مكتشفة تلقائياً ومقيّمة عبر أكثر من 7 مزودين مجانيين، تُصنّف باستمرار بواسطة LLMsVerifier مع تجاوز تلقائي لأخطاء 429/5xx وضمان استخدام llama.cpp كملاذ أخير — تحويل قدرة الطبقة المجانية إلى قدرة موثوقة.
• واجهات متوافقة مع كل من OpenAI وAnthropic تُقدّم عبر HTTP/3 مع عودة تلقائية إلى HTTP/2، بحيث يتصل العملاء من أي من النظامين البيئيين دون تعديل.
• استدلال محلي يشمل CUDA وMetal وROCm من قاعدة كود واحدة — نفس الإصدار يعمل بتسريع على أجهزة Nvidia وApple وAMD.

• التوسع من مضيف واحد إلى عدة مضيفين دون إعادة كتابة. تفرض معظم الأنظمة حداً صارماً بين "التطوير المحلي" و"الإنتاج الموزع"، وعبر هذا الحد يتطلب إعادة هيكلة. لقد ألغينا هذا الحد بنظام أوضاع على ملف تنفيذي واحد: تتواصل نفس الطبقات عبر مكالمات مباشرة داخل العملية في وضع full وتتحول بسلاسة إلى gRPC/SSE/Kafka عبر الأوضاع الموزعة، بحيث يصبح التوسع مجرد تغيير في التكوين بدلاً من نقل.
• مزودو السحابة المجانيون غير الموثوقين والمحدودي المعدل. الاستدلال في الطبقة المجانية سريع حتى يفرض قيوداً على المعدل أو يختفي أثناء الطلب. جعلناه موثوقاً باكتشاف النماذج المتاحة تلقائياً، وتقييمها باستخدام LLMsVerifier، وتتبع رؤوس قيود المعدل بشكل استباقي لتوجيه الطلبات بعيداً عن المزودين على وشك التقييد، والعودة تلقائياً عبر السلسلة المصنفة إلى llama.cpp المحلي — بحيث لا تصل تقلبات المجموعة أبداً إلى المتصل.
• توافق العملاء عبر نظامين بيئيين. إعادة كتابة العملاء لاعتماد خلفية استدلال جديدة أمر غير مقبول. لقد قمنا بتنفيذ أشكال API لكل من OpenAI وAnthropic — وصولاً إلى تنسيقات بث SSE المختلفة الخاصة بكل منهما — بحيث تشير مجموعات تطوير البرمجيات من أي من المعسكرين إلى HelixLLM وتعمل ببساطة.

المحتوى

• Go + Gin — اختيرت لأن بيئة التشغيل ذات الملف الثنائي الواحد والموجهة نحو التوازي هي ما يجعل نظام الأوضاع بأكمله ممكنًا: بناء واحد يمكن أن يكون خادمًا محليًا أو دورًا ضمن مجموعة خوادم. تحمل النظام بأكمله بالإضافة إلى طبقة HTTP الخاصة بالبوابة.
• HTTP/3 (QUIC) + TLS 1.3، مع الرجوع التلقائي إلى HTTP/2 — اختيرت لنقل البيانات الحديث منخفض الكمون والمرن في الاتصالات، وتُعرض كواجهة الخادم مع التفاوض التلقائي بحيث تعود العملاء غير القادرين على استخدام QUIC بهدوء إلى HTTP/2.
• llama.cpp (CUDA/Metal/ROCm) — اختيرت للاستدلال المحلي المحمول الذي يتسارع عبر منصات Nvidia وApple وAMD من قاعدة برمجية واحدة؛ كما تعمل كخيار احتياطي مضمون يمنع سلسلة التراجع من الوصول إلى طريق مسدود.
• LLMsVerifier — اختيرت لتحويل "أي مزود جيد الآن" إلى رقم؛ حيث تقوم بتقييم وترتيب سلسلة التراجع السحابية كل خمس دقائق بحيث تتبع التوجيه الجودة الحية بدلاً من الافتراضات القديمة.
• موفرو الخدمات السحابية (Chutes، OpenRouter، HuggingFace، Nvidia، Cerebras، SambaNova، Together) — اختيروا لاستغلال السعة المجانية عبر عدة مصادر؛ حيث يتم اكتشافهم وترتيبهم تلقائيًا في سلسلة تراجع واحدة بحيث لا يشكل أي مزود نقطة فشل واحدة.
• gRPC + SSE + Kafka — اختيروا كوسائط نقل بين الأوضاع للنشر الموزع: gRPC للمكالمات بين الخدمات، وSSE للبث المباشر، وKafka لتدفق الأحداث المفككة بين الأدوار.
• مخزن المتجهات / embeddings — اختير لتشغيل خط المعرفة RAG من البداية إلى النهاية: استيعاب، تقطيع، تضمين، والبحث في المستندات التي تدعم إجابات النموذج.
• Prometheus + OpenTelemetry — اختيرا لقياس الأداء وتتبع الطلبات الموزعة عبر أي أوضاع يتم نشرها.
• وحدات Go الفرعية من vasic-digital — اختيرت لإعادة استخدام المكونات الأساسية للبنية التحتية الإنتاجية المجربة بدلاً من إعادة بنائها، مما يحافظ على اتساق أساس النظام مع المجموعة التقنية الأوسع.

• الحالة: تجريبية. نظام استدلال موزع وظيفي قيد التطوير النشط.
• الرخصة: لم تُحدد بعد. المستودع لا يعلن عن رخصة في بيانات التعريف (licenseInfo فارغ) — هذا الأمر غير مُتحقق منه ويجب حله قبل تحديد الرخصة.
• المستودع المرجعي حاليًا يشير إلى github.com/HelixDevelopment/llm؛ بينما يعيد مسار HelixLLM التوجيه إليه. أرقام عتبات التغطية وعدد الوحدات الفرعية في ملف README هي بيانات ذاتية التقرير.

درجة الأولوية: Helix-أساسية.