// سطح: helix-primary · سفارش 4

HelixLLM betaاجازه‌نامه: TBD

GoGinHTTP/3 QUICTLS 1.3llama.cppLLMsVerifiergRPCSSEKafkaPrometheusOpenTelemetry

منبع

HelixLLM — scored provider fallback chain Ranked by LLMsVerifier (5-min refresh) ↓ skip on 429 / 5xx Request OpenAI / Anthropic API HTTP/3 Gateway TLS 1.3 · QUIC Chutes OpenRouter Cerebras SambaNova Together llama.cpp (local) guaranteed fallback Response first success wins
// معماری

یک باینری، شش حالت — استنتاج سازگار با 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 نسخه ۱.۳ ارائه می‌شوند. استنتاج محلی از طریق llama.cpp با پشتیبانی از CUDA، Metal و ROCm انجام می‌شود، بنابراین همان بیلد روی سخت‌افزارهای انویدیا، اپل و ای‌ام‌دی به‌طور یکسان شتاب می‌گیرد. ویژگی برجسته آن زنجیره جایگزین چندارائه‌دهنده است که ناپایداری معروف استنتاج ابری رایگان را به منبعی مدیریت‌شده و خودترمیم‌شونده تبدیل می‌کند: HelixLLM به‌طور خودکار مدل‌های رایگان را از بیش از ۷ ارائه‌دهنده ابری (Chutes، OpenRouter، HuggingFace، Nvidia، Cerebras، SambaNova، Together) شناسایی می‌کند، هر ۵ دقیقه آن‌ها را از طریق LLMsVerifier امتیازدهی کرده و درخواست‌ها را از طریق زنجیره رتبه‌بندی‌شده با جایگزینی خودکار خطاهای ۴۲۹/۵xx هدایت می‌کند — همیشه با llama.cpp محلی به عنوان آخرین راهکار تضمین‌شده، به طوری که هیچ درخواستی صرفاً به دلیل عدم دسترسی به ارائه‌دهنده شکست نخورد.

فراتر از استنتاج خام، HelixLLM یک پلتفرم کامل کاربردی است: پایپ‌لاین دانش RAG (جذب، قطعه‌بندی، تعبیه، جستجوی vector) و سیستم عامل ReAct با قابلیت فراخوانی ابزار، جلسات مکالمه و یکپارچگی RAG در همان باینری گنجانده شده‌اند. سیستم حالت‌ها در سطح شبکه نیز سودمند است — در حالت full تمام لایه‌ها از طریق فراخوانی‌های مستقیم درون‌فرایندی Go با سربار شبکه صفر ارتباط برقرار می‌کنند، در حالی که همان باینری، زمانی که روی میزبان‌های مختلف توزیع می‌شود، از طریق gRPC، SSE و Kafka هماهنگ می‌شود. در پایان، مذاکره محتوا با Brotli/gzip، استریم SSE که با فرمت‌های OpenAI و Anthropic بایت‌به‌بایت مطابقت دارد، احراز هویت با کلید API و JWT همراه با محدودیت نرخ، معیارهای Prometheus، ردیابی OpenTelemetry و مجموعه بزرگی از زیرماژول‌های زیرساختی تولید Go تکمیل‌کننده این سیستم هستند.

محتوا

تیم‌ها به استنتاجی نیاز دارند که قابل حمل، سازگار با استانداردها و مقاوم باشد—بدون نیاز به بازنویسی کلاینت‌ها یا وابستگی به یک ارائه‌دهنده یا یک ماشین خاص. HelixLLM به گونه‌ای طراحی شد که همان باینری بتواند به صورت محلی برای توسعه اجرا شود و در عین حال به یک خوشهٔ تولیدی چند میزبانه مقیاس‌پذیر باشد، و با گویش‌های OpenAI و Anthropic که کلاینت‌ها از پیش استفاده می‌کنند، ارتباط برقرار کند.

این ابزار کل پشتهٔ استنتاج—درگاه، استنتاج محلی، بازگشت به ابر، RAG و عامل‌ها—را در یک باینری واحد فشرده می‌کند که با یک کلید حالت کنترل می‌شود، به طوری که معماری‌ای که مستقر می‌کنید یک تصمیم زمان اجرا است نه یک پروژه بازطراحی پلتفرم. و چیزی را که پیش‌تر یک نقطه ضعف بود به یک قابلیت تبدیل می‌کند: قابلیت اطمینان ارائه‌دهندگان ابری به یک دغدغهٔ درجه یک و پیوسته اندازه‌گیری‌شده بدل می‌شود که توسط زنجیره‌ای خودترمیم‌شونده و امتیازدهی‌شده مدیریت می‌شود؛ زنجیره‌ای که هر چند دقیقه یک بار ارائه‌دهندگان را دوباره رتبه‌بندی می‌کند و همواره به استنتاج محلی تضمین‌شده تنزل می‌یابد. قابلیتی که این امر آزاد می‌کند، یک نقطهٔ پایانی واحد است که واقعاً می‌توانید به آن تکیه کنید—سازگار با استانداردها، قابل حمل از لپ‌تاپ تا خوشه، و ناتوان از خاموشی به دلیل محدودیت نرخ یا شکست یک ارائه‌دهندهٔ بالادستی.

  • یک باینری واحد با سیستمی شش‌حالته که به صورت یکپارچه یا در نقش‌های توزیع‌شده اجرا می‌شود—فراخوانی‌های مستقیم Go درون‌فرایندی در حالت full، و gRPC/SSE/Kafka در حالت‌های توزیع‌شده—به طوری که توپولوژی استقرار بدون تغییر کد یا هزینه‌های شبکه‌ای ناخواسته تغییر می‌کند.
  • زنجیره‌ای خودکشف‌شونده و امتیازدهی‌شده از ارائه‌دهندگان چندگانه با بیش از ۷ ارائه‌دهندهٔ رایگان که به طور پیوسته توسط LLMsVerifier رتبه‌بندی می‌شوند، با شکست خودکار در برابر خطاهای ۴۲۹/۵xx و بازگشت تضمین‌شده به llama.cpp به عنوان آخرین راهکار—تبدیل ظرفیت لایهٔ رایگان به ظرفیتی قابل اعتماد.
  • سطوح سازگار با هر دو استاندارد OpenAI و Anthropic که از طریق HTTP/3 ارائه می‌شوند، با بازگشت خودکار به HTTP/2، به طوری که کلاینت‌های هر دو اکوسیستم بدون نیاز به تغییر متصل می‌شوند.
  • استنتاج محلی که از CUDA، Metal و ROCm در یک کدبیس واحد پشتیبانی می‌کند—همان بیلد روی سخت‌افزارهای انویدیا، اپل و ای‌ام‌دی با شتاب اجرا می‌شود.

  • مقیاس‌پذیری از یک میزبان به چند میزبان بدون بازنویسی. بیشتر سیستم‌ها مرز سخت‌گیرانه‌ای بین «توسعه محلی» و «تولید توزیع‌شده» قائل می‌شوند و عبور از این مرز به معنای بازطراحی معماری است. ما این مرز را با سیستمی حالت‌محور در یک باینری واحد حذف کردیم: همان لایه‌ها در حالت full از طریق فراخوانی‌های مستقیم درون‌فرایندی ارتباط برقرار می‌کنند و به طور شفاف در حالت‌های توزیع‌شده به gRPC/SSE/Kafka سوئیچ می‌کنند، به طوری که مقیاس‌پذیری تنها یک تغییر پیکربندی است نه یک انتقال.
  • ارائه‌دهندگان ابری رایگان غیرقابل اعتماد و محدود به نرخ. استنتاج لایهٔ رایگان تا زمانی که با خطای ۴۲۹ مواجه نشود یا در میانهٔ درخواست ناپدید نشود، سریع است. ما آن را قابل اعتماد ساختیم با کشف خودکار مدل‌های موجود، امتیازدهی آن‌ها با LLMsVerifier، ردیابی پیشگیرانهٔ هدرهای محدودیت نرخ برای دور زدن ارائه‌دهندگانی که در آستانهٔ محدودسازی هستند، و شکست خودکار به پایین زنجیرهٔ رتبه‌بندی‌شده تا llama.cpp محلی—به طوری که ناپایداری این مجموعه هرگز به کلاینت نمی‌رسد.
  • سازگاری کلاینت در دو اکوسیستم. بازنویسی کلاینت‌ها برای پذیرش یک بک‌اند استنتاجی جدید غیرممکن است. ما هر دو شکل API مربوط به OpenAI و Anthropic—تا جزئیات فرمت‌های استریم SSE متمایز آن‌ها—را پیاده‌سازی کردیم، به طوری که SDKهای هر دو اردوگاه به HelixLLM اشاره می‌کنند و به سادگی کار می‌کنند.

محتوا

  • Go + Gin — انتخاب شده زیرا یک باینری واحد با اولویت همزمانی، چیزی است که کل سیستم حالت‌ها را ممکن می‌سازد: یک بیلد که می‌تواند هم به‌عنوان سرور لپ‌تاپ و هم نقش کلاستر عمل کند. این باینری کل سیستم و لایه HTTP دروازه را در خود جای می‌دهد.
  • HTTP/3 (QUIC) + TLS ۱٫۳، با بازگشت به HTTP/2 — انتخاب شده برای انتقال مدرن، کم‌تأخیر و مقاوم در برابر قطع اتصال، که به‌عنوان سطح سرور با مذاکره خودکار ارائه می‌شود تا کلاینت‌هایی که نمی‌توانند از QUIC استفاده کنند، به‌صورت خودکار به HTTP/2 بازگردند.
  • llama.cpp (CUDA/Metal/ROCm) — انتخاب شده برای استنتاج محلی قابل‌حمل که روی بک‌اندهای انویدیا، اپل و ای‌ام‌دی از یک کدبیس واحد شتاب می‌گیرد؛ همچنین به‌عنوان تأمین‌کننده تضمینی آخرین راهکار عمل می‌کند تا زنجیره بازگشت هرگز به بن‌بست نرسد.
  • LLMsVerifier — انتخاب شده تا پرسش «کدام تأمین‌کننده در حال حاضر خوب است» را به عدد تبدیل کند؛ این ابزار زنجیره بازگشت ابری را هر پنج دقیقه امتیازدهی و رتبه‌بندی می‌کند تا مسیریابی بر اساس کیفیت زنده انجام شود، نه فرضیات قدیمی.
  • تأمین‌کنندگان ابری (Chutes، OpenRouter، HuggingFace، Nvidia، Cerebras، SambaNova، Together) — انتخاب شده برای بهره‌برداری از ظرفیت لایه رایگان در چندین منبع بالادستی؛ به‌صورت خودکار کشف و در یک زنجیره بازگشت واحد رتبه‌بندی می‌شوند تا هیچ تأمین‌کننده‌ای نقطه شکست نباشد.
  • gRPC + SSE + Kafka — انتخاب شده به‌عنوان پروتکل‌های انتقال بین‌حالته برای استقرارهای توزیع‌شده: gRPC برای تماس‌های سرویس‌به‌سرویس، SSE برای جریان‌سازی و Kafka برای جریان رویدادهای غیرهمزمان بین نقش‌ها.
  • پایگاه داده برداری / embeddings — انتخاب شده برای تقویت خط لوله دانش RAG از ابتدا تا انتها: دریافت، قطعه‌بندی، تعبیه و جستجو در اسناد برای پایه‌گذاری پاسخ‌های مدل.
  • Prometheus + OpenTelemetry — انتخاب شده برای معیارها و ردیابی توزیع‌شده که یک درخواست را در هر حالتی که مستقر شده باشد دنبال می‌کند.
  • زیرماژول‌های vasic-digital Go — انتخاب شده برای استفاده مجدد از زیرساخت‌های تولیدی سخت‌شده به‌جای بازسازی آن‌ها، تا پایه سیستم با پشته گسترده‌تر هماهنگ بماند.

  • وضعیت: بتا. سیستم استنتاج توزیع‌شده کاربردی و در حال توسعه فعال.
  • مجوز: نامشخص. مخزن در متادیتای خود هیچ مجوزی اعلام نکرده است (licenseInfo تهی) — این وضعیت تأیید نشده است و باید پیش از اعلام مجوز حل شود.
  • مخزن مرجع در حال حاضر به github.com/HelixDevelopment/llm ارجاع می‌دهد؛ مسیر HelixLLM به آن تغییر مسیر می‌دهد. آمار آستانه پوشش و تعداد زیرماژول‌ها در فایل README خوداظهاری شده است.

اولویت سطح: Helix-اصلی.