وحدة معالجة رسومية محلية أو OpenRouter أو كلاهما: توجيه كل دور استدلال بشكل مستقل

«أضِف احتياطيًا سحابيًا» تبدو وكأنها مجرد راية إعداد. أما بالنسبة إلى نظام استرجاع فهي أقرب إلى مشكلة في سلامة البيانات متنكّرة في هيئة راية إعداد.

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

تكامل السحابة في Fantom MCP Server هو في معظمه الآلية اللازمة لجعل ذلك آمنًا.

خمسة أدوار، تُوجَّه كلٌّ على حدة

لا يوجد مفتاح واحد باسم «استخدم السحابة»، لأن أدوار الاستدلال الخمسة لها متطلبات مختلفة فعلًا. كل دور يُوجَّه بسياسته الخاصة:

السياسات الأربع:

aggregate هي الافتراضية لأنها التي تستخدم عتادًا دفعت ثمنه بالفعل مع قدرتها في الوقت نفسه على امتصاص أي اندفاع مفاجئ.

البوابة التي تجعل هذا آمنًا

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

لذلك فالتوافق ليس تحذيرًا. إنه شرط مسبق صارم: المزوّد الذي لم يجتَز الاختبار يجب ألا يخدم نصًا واحدًا أبدًا.

الفحص غير خفيّ عن قصد: ضمِّن نصوص الاختبار نفسها عبر المسارين، وخذ تشابه جيب التمام زوجيًا لكل زوج متقابل، واشترط أن يتجاوز الحد الأدنى 0.99، واشترط أن يكون البُعد المُعاد مطابقًا تمامًا للعرض المُهيّأ.

الرقم المثير للاهتمام هو ذاك الذي أخفق. جيب التمام المقيس بين النموذج المحلي والنموذج السحابي هو 0.976 — قريب بما يكفي ليبدو سليمًا في فحص عابر، وأقل من الحد بمسافة مريحة، وبالضبط السبب في وجود سياسة cloud. هذان المُرمِّزان ليسا قابلين للتبادل، فإذا أردت استخدام السحابي فعلى الفهرس بأكمله أن يُبنى منه. هذا ليس التفافًا على المشكلة؛ هذه هي السياسة وهي تؤدي عملها.

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

الحد، مذكورًا لا مدفونًا

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

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

لماذا يُثبَّت التضمين ولا تُثبَّت إعادة الترتيب

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

إعادة الترتيب عديمة الحالة — فهي تسجّل درجات لقائمة مرشّحين ولا تكتب شيئًا — لذلك لا تحتاج إلى تثبيت.

ميزانية واحدة، مرفوعة فوق كل مزوّد

هذا هو الفخّ الذي يشكّل مسار السحابة بأكمله: OpenRouter يحدّ المعدل لكل مفتاح، لا لكل مُستدعٍ.

كل sidecar يحصل على المفتاح نفسه. ثلاثة مزوّدين كلٌّ منهم محدود بثمانية طلبات قيد التنفيذ يعني أربعة وعشرين طلبًا على ميزانية مشتركة واحدة. سقف لكل مزوّد لا يمكنه حماية الحد — على السقف أن يعيش فوقهم جميعًا.

ثمة تفاصيل قليلة هنا تستحق الإبراز.

وحدة التصريح هي التزامن، لا الطلبات في الدقيقة. فقيمة rate_limit المكتشفة هي رقم بالطلبات في الدقيقة، لذا تُحوَّل باستخدام زمن الذهاب والإياب الذي يقيسه المجمّع نفسه — قانون ليتل — ما يعني أنها تُعيد اشتقاق نفسها مع انحراف زمن الاستجابة بدل أن تُثبَّت على رقم من لحظة الإقلاع.

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

التراجع تكيّفي، وليس إعادة محاولة فورية أبدًا. فرمز 429 ينصّف الميزانية الفعلية ويبدأ فترة تهدئة مشوَّشة؛ ونافذة نظيفة مستمرة تُعيد تصعيدها تصريحًا واحدًا في كل مرة نحو السقف.

القيم الافتراضية متحفظة عن عمد. أربعة تصاريح حين يتعذّر اكتشاف أي شيء، لأن افتراض متسع لم تستطع قراءته هو الطريق إلى عاصفة 429 وجدول مكتوب نصفه. وسقف صارم عند 256، لأن خطأ طباعيًا في خانة تجاوز يجب ألا يُشبِع الحساب.

وحدات GPU المحلية معفاة تمامًا. فالعمل يُسحب لكل مزوّد، وبالتالي المزوّد السحابي المحجوب يتوقف ببساطة عن السحب بينما تواصل المحلية عملها. حدّ معدل السحابة يُبطئ السحابة؛ وهو لا يُعطّل عتادك.

التعامل مع المفتاح

مفتاح OpenRouter للكتابة فقط من منظور Fantom MCP Server. يصل ضمن طلب إداري، ويخرج مباشرة عبر إطار WebSocket إلى الـ sidecar الذي سيستخدمه، ولا يُكتب أبدًا في الإعدادات، ولا يُسجَّل، ولا تعيده أي نقطة نهاية، ولا يُحتفظ به بعد الاستدعاء.

ما يُحفَظ هو فقط ما يأمن حفظه: أي الأدوار لها نموذج مرتبط، وأي مصدر أعلى مثبَّت، وأوضاع التوجيه، وحقيقة أن دفعة قد حدثت. وإعادة الدفع دون مفتاح هي الحالة الطبيعية لتغيير وضع أو نموذج — إذ يدمج الـ sidecar الدفعة الجزئية مع الإدخال الذي يحتفظ به بالفعل.

ما الذي يعمل وأين، افتراضيًا

• مُعيد الترتيب — qwen/qwen3-reranker-8b
• مساعد الشيفرة — poolside/laguna-s-2.1
• صندوق RLM الرملي — deepseek/deepseek-v4-flash، مع وضع احتياطي محلي فقط

تُختار نماذج التضمين لكل نشر على حدة، لأن هذا الخيار هو الذي يحدّد ما هو فهرسك. جدول متجهات الشيفرة فضاء واحد بـ 2560 بُعدًا؛ وكل ما سبق موجود للحفاظ عليه كذلك.

الخلاصة

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

«أضِف احتياطيًا سحابيًا» هي فعلًا راية إعداد. وكل ما في هذه التدوينة هو ما يجب أن يكون صحيحًا تحتها قبل أن يصبح قلب تلك الراية آمنًا.

Fantom MCP Server متاح المصدر على github.com/Project-SandStar/FantomMcpServer. التدوينات السابقة: أسطول Sidecar ونظام RLM · ذكاء الشيفرة عبر اللغات.