Keystone تُخرج اسم النموذج من الشيفرة: بوابة LLM مفتوحة المصدر تضيف 0.64 مللي ثانية فقط

أغلى سطر في أي خدمة مصغّرة تعتمد على LLM هو model="gpt-4o". يجرّ هذا السطر وراءه مفتاح مزوّد خاصًّا، وإعادات محاولة خاصة، وفاتورة لا يجد أحد وقتًا لتفكيكها. أطلق فريق Keystone بوابة The Model Switchboard (KTMS) مفتوحة المصدر بلغة Go وبموجب رخصة Apache 2.0، وهي تزيل هذا السطر بالكامل. تخبر الخدمةُ البوابةَ بمدى صعوبة المهمة، وتحدد القواعد أي نموذج سيجيب. الكلفة الإضافية على بيئة الاختبار: نحو 0.64 مللي ثانية عند p50 و1.1 مللي ثانية عند p99 بمعدل 200 RPS.

أربعون خدمة واسم نموذج واحد

القصة المعتادة كالتالي: تحصل الخدمة الأولى على مفتاح OpenAI، وبعد ستة أشهر يصبح عدد هذه الخدمات أربعين، ولكل منها سرّها الخاص، وغلاف إعادة المحاولة الخاص بها، وحساب الرموز (tokens) الخاص بها. بعد ذلك تسوء الأمور بشكل متوقع. يصدر نموذج أفضل أو أرخص: هذا يعني أربعين pull request وأربعة وأربعين... أربعين عملية نشر، ونصف الفرق لن يحدّث إلا بعد ربع سنة. يتعطل المزوّد: فتسقط الخدمات الأربعون كلها، لأن المسار الاحتياطي إما لم يُكتب أو كُتب بطرق مختلفة. تصل الفاتورة: المفتاح مشترك، ولا توجد بيانات وصفية للاستدعاءات، ولا سبيل إلى معرفة من أنفق المال.

في Keystone تمرّر الخدمة effort (أي LOW أو MEDIUM أو HIGH) وسمات: اللغة ونوع المهمة والمستخدم. بالنسبة إلى البوابة، السمات مجرد مفاتيح وقيم تقارنها القواعد. عملاء Python لا يحتاجون حتى إلى gRPC: فواجهة HTTP المتوافقة مع OpenAI تفهم القواعد نفسها. يُرمَّز effort في اسم النموذج (auto:high)، وتتحول metadata إلى سمات، ويُستخدم الحقل user في الحدود.

القواعد والإصدارات الكناري ونموذج الحكم بمهلة 250 مللي ثانية

تُخزَّن القواعد في Postgres وتُستبدل كلها دفعة واحدة باستدعاء ذرّي واحد. تفوز القاعدة المطابقة ذات الأولوية الأعلى، ويحدد الحقل use سلسلة المسارات الاحتياطية، وفق الاصطلاح من النموذج الرخيص إلى الغالي. لا يقبل التحقق مجموعة قواعد يفتقر فيها أي effort إلى قاعدة بلا سمات، وبذلك لا يمكن لأي طلب أن يفلت من جميع القواعد. تلتقط النسخ المتماثلة (replicas) التغييرات خلال 60 ثانية. يعرض الأمر ktms route explain المسار مسبقًا دون استدعاء النموذج.

يمكن تحديد أوزان للقواعد، مثل [90, 10]. عند وجود user_id أو canary_key يكون التوزيع «لاصقًا»: يذهب المستخدم الواحد دائمًا إلى النموذج نفسه، ولذلك يُطرح النموذج الجديد على 10% من الجمهور دون أي تعديل في الخدمات. وهناك أيضًا توجيه ظلّي (shadow) تجريبي: تُنسخ نسبة من الحركة بشكل غير متزامن إلى النموذج المرشّح، ويقارن نموذج الحكم الإجابات ويكتب النتيجة في المقاييس.

إذا كانت الخدمة لا تعرف درجة التعقيد، يُفعَّل model: "auto". تسأل البوابة نموذج الحكم، الذي يعيد لا نصًّا بل إجابة مُنمَّطة مع احتمالات. المدعوم هو Jev من TypeSafe وOpenAI Decisions. المهلة صارمة: 250 مللي ثانية؛ وعند حدوث عطل أو بطء نموذج الحكم يُرسَل الطلب بمستوى MEDIUM. التعقيد المثبَّت له الأولوية دائمًا على نموذج الحكم، ويظهر الاختيار في الترويسات X-KTMS-Route-Mode وX-KTMS-Judge-Score وX-KTMS-Judge-Model. اختيار نموذج الحكم في الفرع 1.x موسوم بأنه تجريبي، والمستقر فقط هو auto:high وما يماثله.

أعطال المزوّدين والتحكم في الإنفاق

إعادات المحاولة المدمجة في SDK الخاصة بالمزوّدين معطَّلة: محاولة واحدة من الموجّه تساوي استدعاءً واحدًا للمزوّد. يعيد الموجّه المحاولة مرة واحدة على النموذج نفسه عند 429 أو 5xx أو انقطاع الاتصال، ثم ينتقل عبر السلسلة؛ وفي حالة البث (streaming) يعمل ذلك حتى أول chunk. آليات الحماية:

• Circuit breaker لكل زوج (مزوّد، نموذج): بعد 5 إخفاقات متتالية تُفتح الدائرة، وبعد 30 ثانية يختبر طلب تجريبي واحد النموذج.
• Retry-After وretry-after-ms وgoogle.rpc.RetryInfo في Gemini: الانتظار حتى ثانية واحدة يتم في مكانه، وما زاد عن ذلك يوقف النموذج مؤقتًا لمفتاح بعينه (الحد الأقصى 5 دقائق افتراضيًا).
• إذا كانت السلسلة كلها متوقفة مؤقتًا، يتلقى العميل UNAVAILABLE vendors_unavailable مع Retry-After صادق.

تُحدَّد حدود الإنفاق بالدولار لكل مفتاح ومستخدم عن يوم UTC أو شهر، إضافة إلى ميزانية شهرية للفريق. قبل كل استدعاء تحجز البوابة أسوأ حالة (المدخل × سعر المدخل + الحد الأقصى للرموز × سعر المخرج) بسكربت Lua واحد في Redis، وبعد الرد تعيد الحساب وفق التكلفة الفعلية. تُخزَّن المبالغ بالنانو-دولار. إذا كان الاستدعاء سيتجاوز الحد فإنه يُرفض، لكن نموذجًا أرخص لاحقًا في السلسلة قد يظل قادرًا على الرد. بدون max_output_tokens يُحتسب الحجز على 4096 رمزًا، ولذلك ينبغي تحديد هذا المعامل دائمًا.

الإمكانات الأخرى:

• مؤسسات وفرق مع قوائم نماذج مسموح بها وميزانيات شهرية؛ وتضع البوابة org_id وteam_id بحسب المفتاح.
• معالجة دفعية (Batch) عبر واجهات API الخاصة بالمزوّدين بخصم 50%، وإرسال متكافئ (idempotent) بحسب client_batch_id، ولا تُخزَّن الـ prompts في قاعدة البيانات.
• تحديد معدل الطلبات بخوارزمية GCRA مع burst قابل للضبط، وميزانيات رموز يومية بهامش 5%.
• حدث عن كل استدعاء يُرسَل إلى light-tokenmeter أو إلى أي خدمة محاسبة عبر gRPC.

القيود وما يمكن فعله حيال ذلك

المزوّدون: OpenAI وAnthropic وGemini وDeepSeek وGroq وMistral وAzure OpenAI وBedrock وأي خوادم متوافقة مع OpenAI، وTypeSafe للأحكام. قد لا تجد مزوّدًا غير مألوف. من حيث التأخير، تتأخر Keystone عن agentgateway وApache APISIX وKong. بيئة الاختبار: Google Cloud c3-standard-4 بأربع vCPU ومصدر upstream وهمي (mock)، وقد حملت البوابة ما لا يقل عن 4000 RPS. بدون Redis لا تعمل الحدود، وعند تعطله تسمح حدود الطلبات والرموز بمرور الحركة. بالنسبة إلى حدود الإنفاق المالي يمكن تفعيل الوضع الصارم SPEND_LIMITS_FAIL_MODE=closed.

الخلاصة العملية للفرق التي لديها عشرات من خدمات LLM: ابدؤوا بثلاث قواعد (LOW وMEDIUM وHIGH بلا سمات) وسلاسل من النموذج الرخيص إلى الغالي، ثم أضيفوا القواعد القائمة على السمات. حدّدوا فورًا max_output_tokens وحدود الدولار على المفاتيح، لتصبح الفاتورة قابلة للتفكيك. يمكن تكرار المخطط في بوابة أخرى أيضًا، والمهم هو نقل اسم النموذج من شيفرة الخدمات إلى الإعدادات.