بوابة LLM مفتوحة المصدر KTMS 1.0 تربط وحدات GPU الخاصة بالسحابة وتصمد أمام الأعطال

KTMS (Keystone. The Model Switchboard) بوابة LLM مفتوحة المصدر مكتوبة بلغة Go، وهي نقطة موحّدة تصل عبرها تطبيقات الشركة إلى نماذج مزوّدين مختلفين. أصدر المطورون الإصدار 1.0 وشرحوا كيف تعمل البوابة في بيئة الإنتاج. يمكن ربط وحدات GPU الخاصة وإرسال الطلبات إليها قبل السحابة المدفوعة. وقد حُدّد سلفًا سلوك البوابة عند تعطل كل واحدة من التبعيات الثلاث (Postgres وRedis وخدمة المحاسبة). وتتغير مفاتيح التشفير دون فقدان أي منها، والإصدارات موقّعة ويجري التحقق منها. ويتم التحديث دون إيقاف الخدمة.

وحدات GPU الخاصة أولًا، والسحابة احتياطيًا

لدى كثير من الفرق جهاز Mac Studio أو آلة Linux ببطاقة جيدة تبقى خاملة نصف الوقت. وفي المقابل تتضخم فاتورة السحابة بسبب طلبات كان بوسع نموذج محلي معالجتها. يحوّل KTMS هذه الأجهزة إلى مزوّد مستقل باسم local.

يصدر المسؤول عبر gRPC مفتاح العقدة (يظهر مرة واحدة فقط) ويسجّل النموذج. ثم يُشغَّل على الجهاز نفسه سكربت واحد. يثبّت السكربت Ollama والنموذج ووكيل العقدة، ويضبط الخدمات الخلفية، ويمنع الحاسوب من الدخول في السكون. ولا حاجة إلى صلاحيات المسؤول على macOS. وإذا تعطل شيء، يبيّن السكربت نفسه مع الخيار --doctor السبب: Ollama لا يستجيب، أو النموذج غير محمّل، أو Ollama يعمل على CPU عبر Rosetta، أو قيمة --tls غير صحيحة. وتُدعم الأنظمة Ollama وvLLM وTGI وllama.cpp.

تتصل البوابة بالعقدة بنفسها، ولذلك يجب جعل العقدة متاحة لها. يستطيع الوكيل إقامة نفق Cloudflare ووضع مرشّح أمام المحرك. ولا يمر عبر هذا المرشّح سوى POST /v1/chat/completions وGET /v1/models، ولذلك لا يمكن تنزيل نموذج أو حذفه من الخارج.

يجري اختيار العقدة على ثلاث خطوات:

• التصفية. تبقى العقد التي تملك النموذج المطلوب ومنفذًا (slot) شاغرًا ونافذة سياق كافية. وتُقدَّم العقد السليمة على المشتبه بها، والعقد «الدافئة» (النموذج محمّل في الذاكرة أصلًا) على «الباردة».
• الوزن. يُضرب الوزن الأساسي في غرامة الحمولة، وهي تزداد تربيعيًا مع انشغال المنافذ، وفي معامل تصحيح للسرعة. يُحسب هذا المعامل من سرعة التوليد (عدد التوكنات في الثانية، بوزن 0,7) والزمن حتى أول توكن (بوزن 0,3) قياسًا إلى الوسيط بين جميع العقد التي تملك هذا النموذج.
• الاختيار. تُطبَّق خوارزمية smooth weighted round-robin، كما في nginx.

خط الدفاع الرئيسي ضد البطء هو تقدير الطابور بقانون ليتل: يُضرب عمق الطابور في المدة المتوقعة للطلب. فإذا تجاوزت النتيجة قيمة queue_timeout_ms للنموذج (2000 مللي ثانية في المثال)، انتقل الطلب فورًا إلى النموذج التالي في السلسلة. وفي حالة العملاء التفاعليين يبلغ الحد 250 مللي ثانية. والمنفذ (slot) عبارة عن حجز (lease) في Redis يُمدَّد ما دام التوليد جاريًا.

سياسات التوزيع هي: nodes_first (الافتراضية)، وnodes_only (إذا لم تتوفر عقدة شاغرة فالنتيجة خطأ ولا يجري اللجوء إلى السحابة)، وcloud_first، وcloud_only. ويمكن اختيار السياسة عبر ترويسة (header) أو حقل في الطلب أو لاحقة في اسم النموذج، مثل auto:nodes-only:high.

ماذا تفعل البوابة عندما يتعطل Redis وPostgres

المبدأ: يجب ألا يتحول تعطل المحاسبة إلى تعطل في الخدمة.

• Redis. تُتجاوز حدود الطلبات والتوكنات دون احتسابها. أما الحدود بالدولار فيُختار لها وضع: open يسمح بالمرور، وclosed يرفض الطلب. ويُعدّ الكاش إخفاقًا (miss). وحالة العقد غير معروفة، فتُتجاوز ويتولى الرد السحابة. وبعد ثلاثة أخطاء شبكة متتالية تتوقف البوابة عن مراجعة Redis تمامًا لمدة ثانيتين، وهكذا يكلّف Redis المعلَّق الطلبَ مهلة انتظار واحدة فقط.
• Postgres. تظل المفاتيح التي جرى التحقق منها خلال آخر 5 دقائق تعمل، بينما تتلقى المفاتيح الأخرى الخطأ auth_unavailable. ويقتصر زمن التحقق على 3 ثوانٍ. وتُؤخذ الإعدادات من آخر لقطة ناجحة. أما الطلب الدفعي (batch) الذي يتعذر التحقق من idempotency الخاصة به فيُرفض، حتى لا يُدفع ثمنه مرتين.
• خدمة المحاسبة. تتراكم الأحداث في الذاكرة (حتى 10 000)، ولا تنتظرها الطلبات.

عند أعطال Postgres يردّ /readyz بالرمز 200 مع الحالة degraded ما دامت نافذة المفاتيح المعروفة سارية، وبالرمز 503 بعد انتهائها. وبذلك لا يعيد Kubernetes تشغيل الـ pods قبل أوانه. وتؤدي خمسة أعطال متتالية إلى فتح قاطع الدائرة (circuit breaker) الخاص بالمزوّد، وبعد 30 ثانية تُجرى محاولة تجريبية واحدة. ويُستحسن ضبط تنبيه على ktms_dependency_errors_total.

المفاتيح وتوقيع الإصدارات والتحديث دون توقف

تُخزَّن مفاتيح المزوّدين في Postgres مشفّرةً بخوارزمية AES-256-GCM. أما keyring الذي يضم مفاتيح التشفير فيُمرَّر عبر المتغير KTMS_ENCRYPTION_KEYS ولا يُحفظ في قاعدة البيانات. ويتألف التدوير من ثلاث خطوات. أولًا، تُضاف نسخة keyring الجديدة إلى جميع النسخ المتماثلة (replicas) وينتظر المشغّل انتهاء الطرح. ثم يُستدعى RotateEncryption، فتُعاد في معاملة واحدة تشفير مفاتيح المزوّدين وتوكنات العقد. وأخيرًا تُزال النسخة القديمة عندما لا تبقى نسخ احتياطية تحتاج إليها. ويكشف الجمع بين dump قاعدة البيانات وkeyring جميع المفاتيح بصيغتها الصريحة، ولذلك يجب حفظهما منفصلين.

منذ الإصدار 0.14.0 توقَّع الصور بأداة cosign في وضع keyless: يرتبط التوقيع بهوية workflow في GitHub Actions، ولا يوجد مفتاح دائم يمكن سرقته. وتُرفق بالصور وثيقة SBOM (قائمة المكونات) وSLSA-provenance (سجل يبيّن أين بُنيت الصورة وكيف). ويفحص govulncheck كل pull request، ولا يصدر أي إصدار دون اجتياز buf breaking واختبار التحديث. ويقرّ المطورون بصراحة بأن التوقيع يؤكد المصدر لا الأمان. فمن يحصل على صلاحيات workflow الإصدار يستطيع توقيع صورة خبيثة أيضًا.

ضمن سلسلة 1.x لا يُكسر الـ API العام. وتُطبَّق الترحيلات (migrations) عند الإقلاع تحت advisory-lock وتضيف إلى المخطط فقط، لذلك تعمل النسخ القديمة على القاعدة الجديدة إلى أن تقوم النسخ الجديدة. ولا يوجد تراجع عن الترحيل: يجب العودة عبر النسخة الاحتياطية المأخوذة قبل التحديث. وعند SIGTERM تُمنح الطلبات 30 ثانية، ويدخل وكيل العقدة أولًا في وضع drain.

بالنسبة إلى الفرق التي لديها وحدات GPU خاملة، هذه طريقة جاهزة لخفض فاتورة السحابة دون خطر البقاء بلا رد عند الحمل الزائد. وقبل التشغيل يُنصح بالتحقق من TLS (فالبوابة نفسها تعمل بـ gRPC نصّي plaintext)، وإزالة BOOTSTRAP_ADMIN_KEY، وإنشاء مفتاح مستقل لكل عميل، ومراقبة اتصالات Postgres (حتى 25 لكل نسخة متماثلة).