بوابة LLM مقابل الموجه (Router) مقابل مزود الاستدلال (Inference Provider): الحدود المعمارية

تعد بوابة LLM، والموجه، ومزود الاستدلال ثلاث طبقات مختلفة في حزمة تقديم النماذج (model-serving stack)، والخلط بينها هو الخطأ الأكثر شيوعاً الذي تقع فيه الفرق عند تصميم منتجات الذكاء الاصطناعي. تقع البوابة في أقرب نقطة لتطبيقك وتتولى مهام المصادقة، والتطبيع (normalization)، والمراقبة؛ بينما يقرر الموجه أي نموذج أو مزود سيتعامل مع طلب معين؛ أما مزود الاستدلال فهو الكيان الذي يقوم فعلياً بتشغيل الأوزان وإرجاع الرموز (tokens).

يؤدي الخطأ في تحديد هذه الحدود إلى تكاملات هشة: حيث تقوم الفرق ببرمجة SDK خاص بمزود واحد بشكل ثابت، ثم تكتشف بعد أشهر أن إضافة نموذج احتياطي أو مقارنة التكلفة بين Claude Sonnet 5 و GPT-5.5 و DeepSeek V4 Flash يعني إعادة كتابة أجزاء كبيرة من معالجة الطلبات الخاصة بهم. تفصل هذه المقالة بين الطبقات الثلاث، وتوضح أين تقع المسؤوليات فعلياً، وتقدم إطار عمل لاتخاذ القرار عند تقييم الموردين في كل فئة.

أبرز النقاط

• يقوم مزود الاستدلال بتشغيل أوزان النموذج وتوفير API (مثل OpenAI أو Anthropic أو Google أو DeepSeek أو محرك مستضاف ذاتياً مثل vLLM)؛ بينما يختار الموجه بين المزودين أو النماذج لكل طلب؛ أما البوابة فهي الطبقة المواجهة للتطبيق التي توحد المصادقة، والتنسيق، والسجلات، وتجاوز الفشل (failover) عبر كليهما.
• يمكن لمنطق التوجيه (الاختيار بناءً على التكلفة، أو زمن الاستجابة، أو القدرة) أن يوجد كخدمة مستقلة أو كميزة داخل البوابة؛ وهو ليس نفس الشيء كالبوابة بحد ذاتها.
• الاستضافة الذاتية لمزود الاستدلال، واستخدام مزود يعتمد على API، واستخدام بوابة متعددة المزودين ليست أموراً متنافية؛ فغالباً ما تجمع أنظمة الإنتاج بين الثلاثة اعتماداً على النموذج وحجم العمل.
• قم بتقييم الموردين من خلال السؤال عن الطبقة التي يعملون فيها فعلياً، حيث أن منتجاً يتم تسويقه كـ "موجه" قد يقوم فقط بالتوجيه بين نقاط النهاية المتوافقة مع OpenAI التي لا يستضيفها هو نفسه، بينما قد تجمع "البوابة" بين التوجيه وميزات الحوكمة التي قد لا تحتاجها بعد.

ما الذي يفعله مزود الاستدلال فعلياً

مزود الاستدلال هو الطبقة التي تمتلك أوزان النموذج، ووحدات معالجة الرسومات (GPUs) (أو المسرعات المكافئة)، ومحرك التقديم منخفض المستوى. يشمل ذلك مزودي API التجاريين مثل Anthropic (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5)، و OpenAI (GPT-5.5)، و Google (Gemini 3.5 Flash)، و Zhipu (GLM-5.2)، و DeepSeek (DeepSeek V4 Pro, DeepSeek V4 Flash)، بالإضافة إلى عمليات النشر المستضافة ذاتياً للنماذج مفتوحة الأوزان مثل Qwen3.7 Plus أو MiniMax M3 أو Kimi K2.7 Code.

إذا كنت تستضيف ذاتياً، فإن طبقة مزود الاستدلال هي برنامج تقوم بتشغيله بنفسك. تصف وثائق تقديم vLLM محرك استدلال مبنياً حول التجميع المستمر (continuous batching) ومعالجة الانتباه الموفرة للذاكرة لتقديم أحمال عمل LLM على نطاق واسع، وهو نوع المكون الذي يقع مباشرة تحت نشر نموذج مستضاف ذاتياً. إن تشغيل vLLM (أو محرك مشابه) يجعلك مزود الاستدلال لهذا النموذج، المسؤول عن تخطيط سعة GPU، والتحجيم، ووقت التشغيل، مقابل الحصول على تحكم في التكلفة وموقع البيانات.

إذا كنت تستخدم API تجارياً، فإن البنية التحتية للمزود وحدود المعدل (rate limits) تصبح هي قيدك. لكل مزود نظام مصادقة خاص به، ومخطط طلب واستجابة، ورموز خطأ، وسلوك حدود معدل. هذه هي الطبقة التي يتم فيها تحديد جودة النموذج، ونافذة السياق، وزمن الاستجابة الخام فعلياً. لا يمكن لأي موجه أو بوابة تغيير قدرات مزود الاستدلال؛ بل يغيرون فقط كيفية وصولك إليه.

ما الذي يفعله الموجه (Router)

الموجه هو منطق اتخاذ قرار يختار وجهة أو نموذجاً أو مزوداً لطلب وارد. يمكن أن يحدث التوجيه على عدة محاور: التكلفة (إرسال الاستعلامات البسيطة إلى نموذج رخيص مثل DeepSeek V4 Flash أو Gemini 3.5 Flash، وحجز Claude Opus 4.8 للاستعلامات المعقدة)، وزمن الاستجابة (تفضيل المزود الذي يستجيب بشكل أسرع حالياً لنموذج معين)، أو التوفر (التجاوز إلى مزود ثانٍ إذا كان الأول متدهوراً).

يشرح التوضيح العام لـ OpenRouter حول توجيه النماذج هذا النمط على مستوى النموذج: يمكن توجيه الطلبات الخاصة بنموذج مفتوح الأوزان عبر مزودين متعددين يستضيفون نفس الأوزان، بحيث يمكن تنفيذ استدعاء نموذج منطقي واحد بواسطة أي من الخلفيات المتعددة. تصف وثائق اختيار المزود في OpenRouter أيضاً معلمات للتعبير عن تفضيلات الترتيب واستبعاد مزودين محددين من الاعتبار، وهي الآلية التي يعبر بها المتصل عن نية التوجيه بشكل صريح بدلاً من تركها بالكامل للمنصة.

النقطة المعمارية المهمة هي أن التوجيه عبارة عن سياسة، وليس فئة منتج بحد ذاته. يمكنك تنفيذ توجيه أساسي بنفسك في كود التطبيق (جملة if/else بسيطة بناءً على نوع المهمة أو حلقة إعادة محاولة عند الخطأ)، أو شراؤه كطبقة توجيه مخصصة، أو الحصول عليه مدمجاً داخل بوابة أوسع. قم بتقييم قدرة التوجيه من خلال السؤال عن الإشارات التي يستخدمها (السعر، زمن الاستجابة، معدل الخطأ، قدرة النموذج) وما إذا كانت هذه الإشارات قابلة للتكوين أم ثابتة.

ما الذي تفعله البوابة (Gateway)

البوابة هي الطبقة التي يتحدث معها كود تطبيقك فعلياً. وظيفتها هي تقديم واجهة متسقة بغض النظر عن مزود الاستدلال الذي يخدم الطلب في النهاية. تتضمن البوابة عادةً:

• مخطط طلب واستجابة موحد عبر المزودين، بحيث لا يتطلب التبديل من GPT-5.5 إلى Claude Sonnet 5 إعادة كتابة منطق التحليل الخاص بك.
• إدارة المصادقة والمفاتيح، بحيث لا تكون بيانات اعتماد المزود مبعثرة عبر كود التطبيق.
• تسجيل السجلات، وتتبع الاستخدام، ونسب التكلفة عبر كل نموذج ومزود قيد الاستخدام.
• سلوك تجاوز الفشل وإعادة المحاولة عندما يكون المزود بطيئاً، أو محدود المعدل، أو يعيد خطأ.
• اختيارياً، منطق التوجيه كميزة واحدة من بين عدة ميزات، بدلاً من كونه المنتج بأكمله.

تقوم صفحة أبحاث النماذج في TokenLab بفهرسة النماذج الحالية عبر المزودين، بما في ذلك النماذج الرائدة (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash)، والنماذج الموجهة للبرمجة (Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash)، ومرشحات التوجيه منخفضة التكلفة (DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3)، وهو نوع المرجع الذي يحتاجه مستخدم البوابة عند اتخاذ قرار بشأن ما يجب التوجيه إليه. راجع مقالة TokenLab حول لماذا تعد بوابة API للذكاء الاصطناعي الموحدة مهمة في عام 2026 للحصول على معالجة كاملة لمشكلة التوحيد بحد ذاتها.

حدود البنية التحتية، بشكل ملموس

من الأسهل رؤية الحدود من خلال تتبع طلب واحد عبر الطبقات الثلاث.

1. يرسل تطبيقك طلب إكمال محادثة إلى نقطة نهاية البوابة، محدداً نوع المهمة أو تفضيل النموذج.
2. تقوم البوابة بمصادقة الطلب، وتطبيعه ليناسب المخطط المتوقع لكل مزود مرشح، وتسليمه إلى منطق التوجيه.
3. يقوم الموجه بتقييم سياسته المكونة (سقف التكلفة، هدف زمن الاستجابة، أو ترتيب المزود الصريح) واختيار وجهة، على سبيل المثال Claude Sonnet 5 عبر API الخاص بـ Anthropic، أو مثيل DeepSeek V4 Pro مستضاف ذاتياً يتم تقديمه عبر vLLM.
4. يقوم مزود الاستدلال بتنفيذ النموذج وإرجاع الرموز.
5. تقوم البوابة بتطبيع الاستجابة مرة أخرى إلى شكل متسق وتسجيل النتيجة (زمن الاستجابة، التكلفة، المزود المستخدم، النجاح أو الفشل) لـ طبقة المراقبة الخاصة بك.

يمكن لكل طبقة أن تفشل بشكل مستقل. انقطاع المزود هو مشكلة في طبقة الاستدلال؛ قرار التوجيه السيئ (إرسال طلبات ذات سياق طويل إلى نموذج ذي نافذة سياق صغيرة) هو مشكلة في طبقة الموجه؛ مخطط الاستجابة غير المتسق الذي يكسر المحلل الخاص بك هو مشكلة في طبقة البوابة. فهم الطبقة التي أنتجت فشلاً معيناً هو ما يجعل تصحيح الأخطاء أمراً ممكناً. تغطي مقالة TokenLab حول بنية الموثوقية التحتية لواجهات برمجة تطبيقات الذكاء الاصطناعي عزل الفشل عبر هذه الطبقات بمزيد من التفصيل.

قائمة التحقق للقرار

استخدم قائمة التحقق هذه عند تقييم ما إذا كنت بحاجة إلى بوابة، أو موجه، أو تكامل مباشر مع مزود، أو مزيج من ذلك.

السؤال	إذا كانت الإجابة نعم	إذا كانت الإجابة لا
هل تستدعي أكثر من نموذج أو مزود اليوم، أو تتوقع القيام بذلك خلال 12 شهراً؟	أنت بحاجة إلى طبقة بوابة أو موجه، وليس استدعاءات SDK مباشرة لكل مزود.	قد يكون تكامل SDK مباشر مع مزود واحد كافياً على المدى القصير.
هل تحتاج إلى تجاوز فشل تلقائي عندما يكون المزود متدهوراً أو محدود المعدل؟	أنت بحاجة إلى منطق على مستوى الموجه مع فحوصات السلامة وترتيب احتياطي.	قد تكون عمليات إعادة المحاولة اليدوية في كود التطبيق مقبولة في البداية.
هل تحتاج إلى رؤية التكلفة والاستخدام لكل نموذج عبر المزودين في مكان واحد؟	أنت بحاجة إلى تسجيل السجلات ونسب التكلفة على مستوى البوابة.	قد تغطي لوحات التحكم الأصلية للمزود احتياجاتك في الوقت الحالي.
هل تستضيف ذاتياً أي نماذج مفتوحة الأوزان (GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code)؟	أنت تدير أيضاً طبقة مزود استدلال وتحتاج إلى بنية تحتية للتقديم مثل vLLM.	يمكنك الاعتماد كلياً على مزودي API التجاريين.
هل تحتاج إلى التوجيه حسب نوع المهمة (نموذج رخيص للتصنيف، نموذج رائد للاستدلال)؟	أنت بحاجة إلى سياسة موجه صريحة، وليس مجرد تجاوز فشل.	قد يكفي نموذج افتراضي واحد.

مثال على شكل الطلب

يوضح المثال أدناه الشكل العام لطلب بنمط البوابة الذي يعبر عن كل من تفضيل النموذج الأساسي وقائمة احتياطية، وهو نمط متسق مع كيفية وصف وثائق اختيار المزود في OpenRouter للتعبير عن تفضيلات التوجيه. تعامل مع أسماء الحقول كأمثلة توضيحية؛ تحقق من المعلمات الدقيقة مقابل مرجع API الحالي للبوابة التي اخترتها قبل الإطلاق.

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

في هذا الشكل، تمتلك البوابة تطبيع الطلب وعقد الاستجابة، ويمتلك الموجه تفسير routing_policy و fallback_models، ويمتلك المزود الذي يتم اختياره في النهاية توليد الإكمال فعلياً. تأكد من مخطط الطلب والاستجابة الدقيق مقابل الوثائق الحالية قبل الاعتماد على أي اسم حقل محدد في الإنتاج.

القيود

تصف الوثائق العامة من OpenRouter و vLLM آليات التوجيه والتقديم العامة، وليس ضمانات عالمية. يختلف زمن الاستجابة الدقيق، والتسعير، وسلوك تجاوز الفشل حسب المزود وتتغير بمرور الوقت، لذا تحقق من الأرقام الحالية مباشرة مقابل وثائق المزود بدلاً من هذه المقالة. تؤدي الاستضافة الذاتية مع vLLM إلى نقل المسؤولية التشغيلية (تخطيط السعة، التحجيم، التصحيح) إلى فريقك؛ فهي لا تلغي العمل في البنية التحتية، بل تعيد توزيعه. لا يمكن لأي سياسة توجيه تعويض اختيار نموذج غير متوافق بشكل أساسي، مثل إرسال مهمة تتطلب استدلالاً بسياق طويل إلى نموذج غير مناسب لذلك؛ إعداد الموجه ليس بديلاً عن تقييم قدرة النموذج مقابل حجم عملك، ولهذا السبب يعد الحفاظ على مرجع نموذج محدث مثل أبحاث النماذج في TokenLab أمراً مهماً.

الأسئلة الشائعة

هل البوابة هي نفس الموجه؟ لا. الموجه هو منطق اتخاذ قرار لاختيار نموذج أو مزود؛ البوابة هي الطبقة الأوسع المواجهة للتطبيق والتي تتضمن التوجيه كميزة واحدة ممكنة إلى جانب المصادقة، والتطبيع، وتسجيل السجلات.

هل يمكنني أن أكون مزود الاستدلال الخاص بي وما زلت أستخدم بوابة؟ نعم. يمكن للنماذج المستضافة ذاتياً التي يتم تقديمها عبر محرك مثل vLLM أن تقع خلف نفس البوابة مثل مزودي API التجاريين، طالما أن البوابة تدعم نقاط نهاية مخصصة أو متوافقة مع OpenAI.

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

إذا كنت تقيم الطبقة التي يجب اعتمادها أولاً، فراجع خيارات النماذج الحالية في صفحة أبحاث النماذج في TokenLab وابدأ بإعداد بوابة يسمح لك بإضافة التوجيه والمزودين تدريجياً بدلاً من الالتزام بتكامل واحد مقدماً.