بوابة LLM 2026: مقارنة LiteLLM وPortkey وKong AI Gateway (Fallback وRetry والتكلفة)

آخر تحديث: 10 سبتمبر 2026

بوابة LLM (LLM Gateway) هي طبقة وكيل تجلس بين تطبيقك ومزوّدي النماذج (OpenAI وAnthropic وGoogle وغيرهم) لتوحيد واجهة الاستدعاء، وتوفير التبديل التلقائي (Fallback)، وإعادة المحاولة (Retry)، والتخزين المؤقت الدلالي، وتتبّع التكلفة، دون تعديل كود التطبيق. في مقارنة 2026 بين LiteLLM وPortkey وKong AI Gateway، يفوز LiteLLM لفرق Python التي تحتاج مرونة مفتوحة المصدر، ويفوز Portkey لفرق SaaS متعددة المستأجرين التي تحتاج قواعد Fallback شرطية قابلة للتكوين من لوحة تحكم، بينما يفوز Kong لأي منظمة تشغّل Kong بالفعل كبوابة API. أشاركك أدناه ما تعلّمته من تشغيلها في الإنتاج.

• LiteLLM مفتوح المصدر (40k+ نجمة GitHub) ويدعم 100+ مزوّد بواجهة OpenAI الموحّدة، مع Router مدمج للـ Fallback والـ Retry، وهو الخيار الافتراضي لفرق Python.
• Portkey يوفّر DSL قابل للتركيب لقواعد Fallback شرطية معقّدة، مع حراسات دلالية (Guardrails) وتخزين مؤقت دلالي. أصبح جزءاً من Palo Alto Networks (Prisma AIRS) في 2026.
• Kong AI Gateway يمدّد بوابة Kong التقليدية بمكوّنات LLM، وهو الخيار الأمثل عندما تكون Kong هي المعيار المؤسسي.
• Bifrost (Go) يضيف 11 ميكروثانية فقط عند 5000 RPS، أي رتبة أفضل من LiteLLM في الأحمال العالية.
• Fallback المُنتِج في 2026 يعني: كشف صحة المزوّد، استمرارية Streaming خلال التبديل، مفاتيح Idempotency، وقياس MTTR عبر OpenTelemetry GenAI.
• التخزين المؤقت الدلالي وحده قد يقلّل التكاليف حتى 86% في أحمال الأسئلة المتكرّرة (بحث AWS).

ما هي بوابة LLM ولماذا تحتاجها؟

بوابة LLM هي وكيل عكسي (Reverse Proxy) متخصّص يجلس بين تطبيقك ومزوّدي النماذج اللغوية الكبيرة. بدلاً من أن يستدعي تطبيقك api.openai.com مباشرةً، يستدعي البوابة، والبوابة تُقرّر: أي مزوّد؟ أي نموذج؟ هل نُعيد المحاولة عند 429؟ هل نُحوّل إلى مزوّد ثانوي عند 503؟ هل نُقدّم إجابة مُخزّنة من الذاكرة الدلالية؟ هذا الفصل بين "منطق التطبيق" و"منطق الشبكة/الموثوقية" هو ذاته الفصل الذي أنقذنا في عصر الميكروسيرفس مع خدمات مثل Envoy وIstio، والآن يتكرّر للـ LLMs.

بعد سنة من تشغيل ثلاثة مزوّدين في الإنتاج، تعلّمت أن غياب البوابة يعني أنك تُعيد كتابة نفس منطق Circuit Breaker ونفس عدّاد التكلفة في كل خدمة. البوابة تُوحّد ذلك في مكان واحد وتُعطيك أربع فوائد فورية: (1) واجهة موحّدة (عادةً بروتوكول OpenAI) بحيث يصبح تبديل المزوّد تغييراً في الإعدادات لا في الكود، (2) موثوقية عبر Fallback وRetry تلقائيَّين، (3) رؤية موحّدة للتكاليف والاستخدام لكل فريق أو مستأجر، (4) طبقة أمان مركزية للحراسات (Guardrails) وحقن التعليمات (Prompt Injection). راجع دليل الدفاع ضد حقن التعليمات لفهم كيف تُدمج الحراسات مع البوابة.

جدول المقارنة السريعة 2026

الجدول أدناه يُلخّص المحاور التي يسأل عنها فريقك فعلياً عند اختيار البوابة: الترخيص، عدد المزوّدين، شكل Fallback، النفقات الزائدة (Overhead)، والتوافق مع البنية الحالية.

الميزة	LiteLLM	Portkey	Kong AI Gateway	Bifrost (Maxim)
الترخيص	MIT (مفتوح)	MIT للنواة، مُدار للمؤسسات	Apache 2.0 (نواة Kong)	Apache 2.0
عدد المزوّدين المدعومين	100+	50+	~15 عبر مكوّنات	23+
لغة التشغيل	Python	Node.js / Rust	OpenResty (Lua) / Go	Go
Fallback شرطي	عبر Router (كود/YAML)	DSL شرطي (بيان)	مكوّن ai-proxy-advanced	Weighted / failover
Overhead تقريبي	10–20 ms	15–25 ms	5–15 ms	11 μs @ 5k RPS
تخزين مؤقت دلالي	نعم (Redis)	نعم (مُدمج)	عبر مكوّن	نعم
الحراسات (Guardrails)	محدود	مُدمج قوي	ai-prompt-guard	محدود
OpenTelemetry GenAI	نعم	نعم (Logs + Traces)	نعم (Kong Vitals)	نعم
أفضل استخدام	فرق Python الأولى	SaaS متعدد المستأجرين	منظمات Kong قائمة	أحمال Go عالية

LiteLLM: Router و Proxy و Fallback

LiteLLM هو الخيار الأكثر انتشاراً في 2026 بين فرق ML التي تُشغّل Python. يوفّر شقّين: مكتبة SDK تستدعي منها 100+ مزوّد بنفس واجهة OpenAI، وخادم Proxy يعمل كبوابة مركزية. الميزة الحاسمة هي فئة Router التي تدير قوائم النماذج والـ Fallback والـ Load Balancing باستدعاء واحد. النفقات الزائدة عادةً بين 10 و20 ميلي ثانية، وهي مقبولة لأغلب الأحمال ما لم تكن تستهدف زمن استجابة أقل من 100 ms.

أبسط إعداد Fallback يكفي مزوّداً أساسياً واثنين احتياطيَّين. راجع وثائق LiteLLM Router الرسمية للخيارات الكاملة. المثال أدناه يُظهر النمط الذي أستخدمه في الإنتاج:

from litellm import Router

model_list = [
    {
        "model_name": "chat-primary",
        "litellm_params": {
            "model": "openai/gpt-4.1",
            "api_key": os.environ["OPENAI_API_KEY"],
            "timeout": 8,
        },
    },
    {
        "model_name": "chat-fallback-anthropic",
        "litellm_params": {
            "model": "anthropic/claude-sonnet-4-5",
            "api_key": os.environ["ANTHROPIC_API_KEY"],
            "timeout": 8,
        },
    },
    {
        "model_name": "chat-fallback-gemini",
        "litellm_params": {
            "model": "gemini/gemini-2.5-pro",
            "api_key": os.environ["GEMINI_API_KEY"],
            "timeout": 8,
        },
    },
]

router = Router(
    model_list=model_list,
    fallbacks=[{"chat-primary": ["chat-fallback-anthropic", "chat-fallback-gemini"]}],
    num_retries=2,
    retry_after=1,          # exponential backoff base (seconds)
    allowed_fails=3,        # circuit breaker threshold
    cooldown_time=30,       # seconds before retrying a failed model
    routing_strategy="least-busy",
)

response = router.completion(
    model="chat-primary",
    messages=[{"role": "user", "content": "Summarize Q3 earnings"}],
)

ما يعجبني في LiteLLM: قواعد Fallback تُعرَّف قرب الكود، ما يجعل مراجعتها في Pull Request سهلاً. ما لا يعجبني: بعض التغييرات الجذرية بين إصدارات قصيرة الفارق، لذا نُثبّت رقم الإصدار (litellm==1.55.x) ونُرقّي بحذر. لا يوجد نظام حراسات قوي مُدمج، لذا نُضيف طبقة NeMo Guardrails بشكل منفصل عند الحاجة.

Portkey: DSL شرطي وحراسات دلالية

Portkey يأخذ نهجاً مختلفاً: كل منطق التوجيه والـ Fallback يُعرَّف في ملف تكوين JSON (يُسمّى Config) ويُشار إليه بمعرّف. تغييرات التوجيه تصبح تغييرات إعدادات لا نشر كود. هذا الفصل ذهبي لفرق SaaS متعددة المستأجرين التي تحتاج قواعد مختلفة لكل عميل، إذ يمكنك تحديث Config من لوحة التحكم دون Deploy جديد.

الفرق الجوهري عن LiteLLM هو Fallback الشرطي: يمكنك تحديد شروط دقيقة (رمز الخطأ، الحالة، حتى وسم مخصّص) قبل تفعيل التبديل. راجع وثائق Portkey للـ Fallbacks. مثال Config حقيقي:

{
  "strategy": {
    "mode": "fallback",
    "on_status_codes": [429, 500, 502, 503, 504]
  },
  "targets": [
    {
      "provider": "openai",
      "override_params": { "model": "gpt-4.1" },
      "retry": { "attempts": 2, "on_status_codes": [429, 503] }
    },
    {
      "provider": "anthropic",
      "override_params": { "model": "claude-sonnet-4-5" },
      "cache": { "mode": "semantic", "max_age": 3600 }
    },
    {
      "strategy": { "mode": "loadbalance" },
      "targets": [
        { "provider": "azure-openai", "weight": 0.7 },
        { "provider": "bedrock", "weight": 0.3 }
      ]
    }
  ]
}

لاحظ التخزين المؤقت الدلالي المُدمج (cache.mode: semantic) الذي يُطابق طلبك بالمعنى لا بالنص الحرفي. هذا وحده وفّر لنا 30% من فاتورة Anthropic في تطبيق دعم فني. تحذير مهم: Portkey أصبح جزءاً من Palo Alto Networks في 2026، مُدمجاً ضمن Prisma AIRS. إن كنت تُقيّم اليوم، راجع خارطة طريق Palo Alto لا مقارنات Portkey المستقلّة القديمة.

Kong AI Gateway: المكوّنات والحوكمة

Kong AI Gateway ليس منتَجاً جديداً بل مكوّنات (ai-proxy، ai-proxy-advanced، ai-prompt-guard، ai-rate-limiting-advanced) تُضاف إلى Kong Gateway الذي تعرفه منذ 2015. هذا يعني أن كل ما تعرفه عن Kong (Konnect, Vitals, RBAC, Consumer Groups) ينطبق فوراً على حركة LLM. Overhead منخفض (5–15 ms) لأن النواة مكتوبة بلغة OpenResty/Lua مع مسارات Go جديدة للـ AI.

القوّة الحقيقية لـ Kong تظهر في المنظمات التي تشغّل مئات الـ APIs خلف بوابة واحدة وتحتاج حوكمة موحّدة. مكوّن ai-prompt-guard يحجب أنماط حقن التعليمات، وai-rate-limiting-advanced يحسب الحدود بالـ tokens لا بالطلبات، وهو ما تحتاجه فعلاً في عالم LLM. تعريف مكوّن التبديل يكون في declarative config:

_format_version: "3.0"
services:
  - name: llm-chat
    url: http://placeholder
    routes:
      - name: chat-route
        paths: ["/v1/chat/completions"]
    plugins:
      - name: ai-proxy-advanced
        config:
          targets:
            - model:
                provider: openai
                name: gpt-4.1
              weight: 100
              route_type: llm/v1/chat
              auth: { header_name: Authorization, header_value: "Bearer $OPENAI_KEY" }
            - model:
                provider: anthropic
                name: claude-sonnet-4-5
              weight: 0
              route_type: llm/v1/chat
          balancer:
            algorithm: priority
            failover_criteria:
              - open_ai_error
              - timeout

راجع وثائق Kong ai-proxy-advanced الرسمية. عيب Kong الرئيس: إن لم تكن تُشغّله بالفعل، فإن تعلّم Kong فقط من أجل بوابة LLM مبالغة. اختَر LiteLLM أو Portkey بدلاً منه.

أي بوابة LLM هي الأفضل لفريقك؟

لا توجد إجابة واحدة؛ الاختيار يعتمد على البنية القائمة وحجم الفريق والميزانية. بعد نشر ثلاث بوّابات مختلفة عبر ثلاثة منتجات، أختار كالتالي:

• فرق Python ذات بنية ML أوّلاً وميزانية < 50k$/شهر: LiteLLM. مفتوح المصدر، 100+ مزوّد، Router مباشر، ولا حاجة لعلاقة مورّد جديدة.
• SaaS متعدد المستأجرين يحتاج قواعد لكل عميل + حراسات دلالية: Portkey. الـ DSL الشرطي وسهولة التحديث من لوحة التحكم يُوفّران أسابيع من العمل.
• مؤسسة تُشغّل Kong Enterprise للـ APIs التقليدية: Kong AI Gateway. توحيد التشغيل والمراقبة والحوكمة يُبرّر التكلفة.
• خدمة Go عند 5000 RPS أو أكثر: Bifrost. الـ Overhead بالميكروثانية يُهمّ عند هذا الحجم.
• MVP لأسبوعين تحتاج فيه نموذجاً يعمل الآن: OpenRouter. لا إعدادات، لا Proxy، صفر بنية تحتية، لكنه ليس بوابتك للإنتاج.

الفروقات في التسعير والملكية

LiteLLM النواة مجانية؛ Enterprise يبدأ ~1500$/شهر مع SSO وSCIM. Portkey تسعير هجين: مجاني حتى 10k طلبات/شهر ثم بالاستخدام؛ الآن ضمن Prisma AIRS. Kong AI Gateway مجاني مفتوح المصدر (OSS) والـ Enterprise يعتمد على عقد Kong. Bifrost مجاني بالكامل (Apache 2.0) مع خيار Maxim Cloud للمراقبة.

أنماط Fallback وRetry الإنتاجية

مقارنة الأدوات لا تكفي، ويجب أن تعرف الأنماط التي تُطبّقها فيها. في 2026، خمسة محاور تفصل بين Fallback جدّي وحلقة try/except ساذجة: زمن الكشف، استمرارية Streaming، Idempotency، قياس MTTR، وجودة النموذج الاحتياطي. أشرح كلاً منها بإيجاز.

1. كشف صحة المزوّد (Health Detection)

لا تنتظر timeout كامل لتعرف أن المزوّد ميت. استخدم Circuit Breaker يفتح الدائرة بعد N فشل متتالٍ خلال نافذة زمنية (مثلاً 3 فشل خلال 60 ثانية). LiteLLM يوفّر allowed_fails وcooldown_time؛ Portkey يستخدم Circuit Breaker مبنيًّا داخل استراتيجية Fallback.

2. استمرارية Streaming خلال التبديل

إذا انقطع Stream بعد إرسال 50 token للمستخدم، هل تُعيد الاستدعاء على المزوّد الثاني من الصفر؟ الجواب المُنتِج: نعم، مع علامة "استكمال" في الواجهة، والأفضل تخزين الرموز المُرسَلة في Redis لتفادي التكرار. هذا موضوع كثيراً ما يُنسى في المقارنات السطحية. صدقاً، اكتشفت أهميته بعد شكوى مستخدم رأى إجابته تُعاد من البداية ثلاث مرات في دقيقة واحدة.

3. مفاتيح Idempotency

عند إعادة المحاولة، أرسِل مفتاح Idempotency-Key نفسه. OpenAI وAnthropic يدعمانه، ويمنع خصم التكلفة مرّتين على الطلب نفسه إن نجحت المحاولة الأولى بعد timeout الشبكة.

4. جودة النموذج الاحتياطي

مزوّد احتياطي يُرجع إجابات سيّئة أسوأ من خطأ 503 صريح. شغّل تقييماً أسبوعياً (Held-out Eval) على مسار الـ Fallback بأمثلة إنتاج حقيقية. راجع تقييم وكلاء الذكاء الاصطناعي لتفاصيل الأطر.

قياس MTTR وربط OpenTelemetry GenAI

البوّابات الثلاث تُصدر Traces بمعيار OpenTelemetry GenAI Semantic Conventions. هذا يعني أن نفس Dashboard في Grafana أو Datadog يعمل عبر الثلاث. المقاييس الأربعة التي أراقبها يومياً:

1. gen_ai.client.token.usage: توزيع Prompt/Completion tokens لكل نموذج ومستأجر.
2. gen_ai.client.operation.duration: p50 وp95 وp99. p99 هو ما يؤلم مستخدميك.
3. معدل التبديل (Fallback Ratio): نسبة الطلبات التي انتهت على مزوّد غير الأساسي. ارتفاعها فوق 2% يعني مشكلة.
4. MTTR: الزمن بين أول خطأ 5xx وأول نجاح على البديل، وهدفنا أقل من 3 ثوانٍ.

لبناء لوحة تحكم كاملة راجع دليل مراقبة نماذج LLM في الإنتاج. الخلاصة: مقياس التكلفة يُخبرك بالفاتورة، لكن Fallback Ratio + MTTR هما ما يكشفان صحة المنصّة.

تحسين التكاليف عبر البوابة

هدف البوابة الأول تاريخياً كان الموثوقية، لكن في 2026 صار توفير التكلفة يُضاهيه أهميةً. ثلاث آليات تُوفّر أكبر أثر:

• التخزين المؤقت الدلالي (Semantic Cache): يُطابق طلبات متشابهة المعنى ويُرجع الإجابة المُخزّنة. بحث AWS يُظهر خفضاً حتى 86% في أحمال الأسئلة المتكرّرة (Support Chatbots). دمج مع Prompt Caching في Claude وOpenAI يُضاعف الأثر.
• التوجيه بالحجم (Model Cascading): أرسِل السؤال لنموذج صغير أولاً؛ إن كانت الثقة منخفضة، صعّد لنموذج أكبر. Not Diamond وMartian يفعلان هذا تلقائياً.
• حدود الميزانية لكل مستأجر (Per-Tenant Budgets): LiteLLM وPortkey يدعمان حدوداً يومية/شهرية بالدولار أو بالـ Tokens مع Alerts. يمنع عميلاً واحداً من استهلاك 80% من الفاتورة دون علمك.

مثال LiteLLM budget:

# litellm_config.yaml
general_settings:
  master_key: sk-...
  database_url: postgresql://...

router_settings:
  routing_strategy: cost-based-routing

model_list:
  - model_name: cheap-tier
    litellm_params: { model: openai/gpt-4o-mini }
  - model_name: strong-tier
    litellm_params: { model: openai/gpt-4.1 }

litellm_settings:
  max_budget: 500          # USD per month platform-wide
  budget_duration: 30d
  cache: true
  cache_params:
    type: redis
    supported_call_types: ["completion", "acompletion"]

إلى أين تتّجه البوابات في 2026 وما بعده؟

ثلاثة اتجاهات أراها تتشكّل: (1) اندماج البوابات مع بروتوكولات الوكلاء مثل MCP، فتصبح البوابة Router للوكلاء لا للنماذج فقط. (2) صعود Guardrails السحابية المحلّية (Palo Alto Prisma AIRS، Cloudflare AI Gateway) التي تدمج الحماية بمستوى الشبكة. (3) نضج مقاييس OpenTelemetry GenAI بحيث تصبح بوابتك مصدر الحقيقة الوحيد للتكلفة والجودة والأمان، دون حاجة لأدوات مراقبة منفصلة.

نصيحتي إن كنت تبدأ اليوم: ابدأ بـ LiteLLM في Docker Compose، واكتب Fallback بثلاثة مزوّدين، وفعّل Prometheus + Grafana مع OTel GenAI. عندما تصل إلى 100 مستأجر أو 100k$ شهرياً، أعِد التقييم بين البقاء على LiteLLM Enterprise أو الانتقال إلى Portkey/Kong حسب أولوياتك الجديدة.

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

ما هي بوابة LLM بالضبط؟

بوابة LLM هي وكيل شبكي يجلس بين تطبيقك ومزوّدي نماذج اللغة الكبيرة (OpenAI, Anthropic, Google) ويُوفّر واجهة موحّدة، Fallback تلقائي، Retry، Rate Limiting، تخزين مؤقت، وتتبّع تكلفة، دون تعديل كود التطبيق.

هل LiteLLM أفضل من Portkey؟

لا يوجد "أفضل" مطلق. LiteLLM أفضل لفرق Python الصغيرة والمتوسطة التي تريد حلاً مفتوح المصدر مع أوسع دعم للمزوّدين (100+). Portkey أفضل لفرق SaaS متعددة المستأجرين تحتاج قواعد Fallback شرطية معقّدة، حراسات دلالية مُدمجة، وتحديث Config من لوحة تحكم دون Deploy جديد.

كم يُضيف LiteLLM Proxy من زمن استجابة؟

عادةً 10–20 ميلي ثانية لكل استدعاء عندما يعمل بجوار المزوّد في نفس المنطقة. الأحمال العالية جداً (> 3000 RPS) قد تستفيد من Bifrost (Go) بنفقات ميكروثانية، لكن أغلب التطبيقات لن تلاحظ الفرق.

كيف تعمل استمرارية Streaming خلال Fallback؟

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

هل التخزين المؤقت الدلالي آمن للبيانات الحساسة؟

ليس افتراضياً. يجب تفعيل Namespace لكل مستخدم أو مستأجر بحيث لا تُشارَك إجابة مُخزّنة عبر حدود الخصوصية. Portkey وLiteLLM يدعمان مفتاح Namespace في إعدادات Cache، ولا تُفعّل التخزين الدلالي على بيانات PII بدون هذا الفصل.

هل Kong AI Gateway مجاني؟

النواة (Kong Gateway OSS) ومكوّنات AI الأساسية (ai-proxy) مجانية بترخيص Apache 2.0. المكوّنات المتقدّمة مثل ai-proxy-advanced وai-prompt-guard وai-rate-limiting-advanced تتطلّب اشتراك Kong Enterprise.