שערי LLM 2026: LiteLLM vs OpenRouter

Q: מה ההבדל בין LLM router ל-LLM gateway?

Router מקבל החלטה לאיזה מודל לשלוח בקשה (לפי חוקים, סמנטיקה או ML). Gateway הוא המעטפת המלאה: פרוקסי HTTP + router + auth + מגבלות תקציב + caching + guardrails + לוגים. בייצור אתם כמעט תמיד רוצים gateway, לא רק router בודד.

Q: האם ניתן להשתמש ב-LiteLLM בייצור?

כן. LiteLLM (רישיון MIT) מיועד לייצור ומופעל היום על ידי מאות ארגונים ב-scale של מיליוני בקשות ביום. הדרישות התפעוליות: Postgres למפתחות/הוצאה, Redis למצב ניתוב, HA setup, ו-version pinning. תקורת החביון היא כ-8ms ב-P95.

Q: האם OpenRouter תומך ב-semantic caching?

לא. OpenRouter מציע ניתוב, provider fallback ו-price/latency sorting, אבל אין לו semantic cache מובנה. אם אתם רוצים caching על גבי OpenRouter, תצטרכו לממש אותו באפליקציה או להוסיף שכבת Portkey/LiteLLM לפניו, קונפיגורציה שנקראת "gateway-of-gateways".

Q: האם Portkey הוא קוד פתוח?

הליבה של Portkey Gateway פתחה בקוד פתוח ב-2026 (Apache 2.0). קיים גם מוצר cloud מנוהל בתשלום עם dashboard, alerting מתקדם ו-guardrails ארגוניים. תוכלו לרוץ על הליבה בחינם ולעבור ל-cloud מאוחר יותר בלי שינויים באפליקציה.

Q: איזה שער LLM הכי חסכוני?

LiteLLM self-hosted הוא הזול ביותר בעלות תוכנה (חינם, MIT) אבל דורש תשתית שלכם. OpenRouter גובה עמלה של כ-5% על גבי מחיר הטוקנים בתמורה לניהול מלא. Portkey OSS חינמי; Portkey Cloud מבוסס מנוי. החיסכון הגדול ביותר מגיע מ-semantic caching (40%-60% פחות קריאות) ולא מהמחיר של השער עצמו.

עודכן: 2 באוגוסט 2026

שער LLM (LLM Gateway) הוא שכבת פרוקסי אחת שיושבת בין האפליקציה לבין ספקי המודלים ומספקת נקודת קצה אחידה, ניתוב חכם, fallback אוטומטי, semantic caching, בקרת תקציב ותצפית. הבחירה בין LiteLLM, OpenRouter, Portkey ו-RouteLLM ב-2026 נגזרת בעיקר משאלה אחת: האם אתם רוצים לתחזק את הפרוקסי בעצמכם. אני מתחזקת סביבות ייצור מרובות ספקים כבר שנתיים, וההבדל בין הכלים האלה בפועל הרבה יותר גדול ממה שנראה מהעמוד הראשי שלהם. במדריך הזה אני מפרקת את ארבעת הכלים לפי עומס אמיתי (חביון, אמינות, עלות ותפעול) עם קובצי תצורה עובדים ותבניות ייצור.

LiteLLM הוא הפרוקסי הפתוח (MIT) העיקרי בקטגוריה, מוסיף כ-8ms ב-P95 ומחייב Postgres+Redis לפריסה. זו הבחירה כברירת מחדל כשרוצים בעלות מלאה על הנתונים והתצורה.
OpenRouter הוא מצבור מנוהל של 300+ מודלים מאחורי מפתח אחד, ללא Setup, אבל מוסיף 100-150ms ומשאיר את הבקרה על ניתוב לפי איכות באחריות שלכם.
Portkey פתח את הליבה בקוד פתוח ב-2026 ומציע צנרת ארגונית עם guardrails, semantic caching ותצפית. פחות ממילישניה תקורה, מודל היברידי (מנוהל או self-hosted).
RouteLLM אינו שער כלל. הוא framework מחקר של Berkeley/LMSYS לאימון המסלב-ן (routing brain) עצמו, ומשולב בתוך שער אחר כמו LiteLLM.
שיעורי פגיעה של semantic cache בייצור נעים בין 40% ל-60% על תעבורה חוזרת. זו קפיצה של פי 3-5 בתפוקה, ולא רק חיסכון בעלות.
תבנית ה-fallback הנפוצה ב-2026: שרשרת של 3 מודלים עם exponential backoff (500ms→4s) + circuit breaker שמשעה ספק כושל ל-30 שניות.

מה זה שער LLM ובמה הוא שונה מנתב?

כשמישהו אומר "אני משתמש בשער LLM", הכוונה כמעט תמיד לפרוקסי HTTP שמנרמל את ה-API של עשרות ספקים (OpenAI, Anthropic, Google, Bedrock, Azure, Ollama, vLLM) מאחורי סכמת ה-Chat Completions של OpenAI. נתב (router) הוא רק המרכיב שמחליט לאיזה מודל להעביר בקשה נתונה, לפי חוקים, סמנטיקה או מודל חיזוי מאומן. שער הוא ה-מעטפת: פרוקסי + נתב + אימות + מגבלות תקציב + caching + guardrails + לוגים.

הבחנה מעשית נוספת: יש נתבים שרק ממליצים על מודל (למשל NVIDIA LLM Router) ומחזירים לאפליקציה שלכם החלטה, ואז האפליקציה עצמה מבצעת את הקריאה, אחראית ל-retries, לוגים ו-fallback. שער proxying אמיתי, לעומת זאת, לוקח על עצמו את כל השרשרת: מבצע את הקריאה, מפעיל retry עם exponential backoff, נופל למודל הבא בשרשרת אם ה-primary נכשל, ורושם את כל הבקשה והתגובה לצורך תצפית. ההבחנה הזו קריטית: אם אתם רואים חבילה שקוראת לעצמה "router" אבל לא מוצאים בדוקומנטציה שלה חוזה תשובה של HTTP, כנראה שהיא רק מייעצת ולא מבצעת.

בגלל הבלבול הזה, ב-2026 גם המונח "AI Gateway" הפך לנפוץ יותר מ-"LLM Router", כי הוא לוכד את מה שצוותי הייצור באמת רוצים: שכבה אחת עם auth, מדידה, caching, מגבלות קצב, מדיניות וחשבוניות סביב הבקשה, לא רק החלטת ניתוב. כשאני מקימה סביבה חדשה, השאלה הראשונה שאני שואלת את הצוות היא לא "איזה מודל", אלא "מי מחזיק בפרוקסי הזה כשהוא נופל בשעה 03:00". התשובה קובעת אם הולכים לפרוקסי מנוהל, ל-self-hosted עם on-call, או לגישה היברידית.

טבלת השוואה: ארבעת הכלים במבט על

לפני שנצלול לכל כלי בנפרד, זו הטבלה שאני שולחת לצוותים שמבקשים "החלטה ב-15 דקות". המספרים לקוחים מ-benchmarks של ספקי הכלים וממדידות שביצענו בייצור על תעבורה של כ-2M בקשות בחודש. שימו לב במיוחד לשורת ה-Latency: ההפרש של 150ms בין OpenRouter ל-Portkey הוא ההפרש בין אפליקציה שמרגישה מיידית לבין אפליקציה שמרגישה איטית.

מאפיין	LiteLLM	OpenRouter	Portkey	RouteLLM
סוג	פרוקסי קוד פתוח (MIT)	SaaS מנוהל	Hybrid: OSS + Cloud	Framework מחקר
Self-hosting	חובה	לא נתמך	אופציונלי	חובה
מספר מודלים	100+	300+	200+	לא רלוונטי
תקורת חביון (P95)	~8ms	100-150ms	<1ms	לא ישים
Semantic caching	Redis-based	לא	מובנה (מתקדם)	לא
Fallback אוטומטי	כן (config.yaml)	כן (provider ordering)	כן (conditional)	לא
Virtual keys ותקציבים	כן	כן	כן	לא
מחיר	חינם (תשתית שלכם)	Pay-per-token + 5%	OSS חינם / Cloud מנוי	חינם
שימוש טיפוסי	ייצור עם שליטה מלאה	חקירה ומעבר מהיר	ארגוני עם compliance	לוגיקת ניתוב חכמה

LiteLLM, הפרוקסי הפתוח שכולם מפרסים

LiteLLM הוא הבחירה שלי כברירת מחדל כשצוות רוצה בעלות מלאה על שער LLM בייצור. הוא פרוקסי ברישיון MIT שחושף נקודת קצה אחת תואמת-OpenAI מול 100+ ספקים, מרכז virtual keys, תקציבים לפי צוות, קצבים, fallback ולוגים, הכל בקובץ YAML אחד שאתם מגרסים ב-repo שלכם. התשלום על השליטה: אתם אחראים ל-Postgres למפתחות ולהוצאה, Redis למצב הניתוב, ניהול סודות, ו-version pinning כדי לצמצם סיכון שרשרת אספקה.

הנה קובץ config.yaml מינימלי-אך-ייצורי שאני מתחילה איתו בכל פרויקט חדש. הוא חושף שני מודלים ראשיים עם שרשרת fallback לחלופה זולה יותר, מפעיל semantic cache על Redis, ומגדיר budget alerting ל-Slack:

model_list:
  - model_name: chat-primary
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: os.environ/ANTHROPIC_API_KEY
      rpm: 500
  - model_name: chat-fallback
    litellm_params:
      model: openai/gpt-5-mini
      api_key: os.environ/OPENAI_API_KEY

router_settings:
  fallbacks:
    - chat-primary: [chat-fallback]
  num_retries: 3
  retry_after: 4        # exponential backoff base
  timeout: 30

litellm_settings:
  cache: true
  cache_params:
    type: redis
    host: os.environ/REDIS_HOST
    similarity_threshold: 0.95
  fail_closed_budget_enforcement: true
  max_parallel_requests: 100
  alerting: ["slack"]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

לאחר litellm --config config.yaml --port 4000, האפליקציה שלכם מדברת עם http://localhost:4000 כאילו הוא OpenAI. יצירת virtual key חדשה עם תקציב יומי של 50$ ל-team של המחקר, למשל, היא קריאה אחת ל-/key/generate:

curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "research",
    "max_budget": 50.0,
    "budget_duration": "1d",
    "models": ["chat-primary", "chat-fallback"],
    "rpm_limit": 60
  }'

מה שאני אוהבת ב-LiteLLM: fail_closed_budget_enforcement: true שבודק תקציב מול ה-DB לכל בקשה ומחזיר 503 אם לא מצליח לוודא הוצאה. עדיף להיכשל סגור מלגלות בסוף החודש חשבון של 40K$ שאיש לא צפה (הייתי שם, זה לא כיף). מה שפחות: LiteLLM מוסיף כ-8ms ב-P95, וזה נראה זעום עד שאתם רצים בסביבת streaming עם עשרות בקשות מקבילות. פרטים נוספים על ניתוב ו-fallback ב-Fallbacks Documentation הרשמית של LiteLLM.

OpenRouter, המצבור המנוהל

OpenRouter פותר בעיה אחרת לגמרי: אתם רוצים גישה למודל חדש ביום שהוא יוצא, בלי לפתוח חשבון אצל כל ספק, בלי לנהל מפתחות, בלי לפרוס דבר. מפתח אחד, 300+ מודלים, כולל מודלים ניסיוניים כמו Grok-3, Kimi-K2 ו-DeepSeek-V4 שלוקח שבועות להגיע ליתר הצבירנים. בקרות הניתוב שלו כוללות provider ordering, price-based routing, throughput sorting, latency sorting, ו-data policy filters, כדי לוודא שבקשות רגישות ל-privacy לא נשלחות לספק שמאמן על התעבורה שלכם.

קריאה ל-OpenRouter מ-Python נראית זהה לחלוטין לקריאת OpenAI. רק ה-base_url וה-header HTTP-Referer שונים:

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
    default_headers={
        "HTTP-Referer": "https://aiworkflowlab.dev",
        "X-Title": "AI Workflow Lab",
    },
)

response = client.chat.completions.create(
    model="anthropic/claude-sonnet-4-6",
    messages=[{"role": "user", "content": "Explain semantic caching."}],
    extra_body={
        "provider": {
            "order": ["Anthropic", "AWS Bedrock"],
            "allow_fallbacks": True,
            "data_collection": "deny",
        },
        "route": "fallback",
    },
)

ה-provider.order אומר ל-OpenRouter לנסות קודם את Anthropic הישיר, ואז לנפול ל-Bedrock. שרשרת fallback עם ספק אחד וסביבה אחרת של אותו מודל. זה שימושי כשיש outage אזורי. מצד שני, OpenRouter מוסיף 100-150ms תקורה גם כשהכל תקין, שבישימוני chat אינטראקטיביים ניתן להרגיש. הוא גם גובה עמלה של כ-5% על גבי מחיר הטוקנים של הספק, מה שנוסף לחשבון של תעבורה כבדה. הבחירה הנפוצה בצוותים שראיתי: OpenRouter לחקירה, LiteLLM לייצור. נסו מודלים חדשים דרך OpenRouter, ואז העבירו את המסלולים הקריטיים ל-LiteLLM self-hosted לצורך שליטה בעלות ובחביון.

Portkey, השער הארגוני עם guardrails

Portkey היה במקור מוצר cloud סגור, אבל ב-2026 הצוות פתח את ליבת ה-gateway בקוד פתוח, מהלך שהחזיר את ה-tool לשולחן ההחלטות של צוותים שלא היו מוכנים להעביר את כל התעבורה שלהם לצד שלישי. הבידול העיקרי: תקורה של פחות ממילישניה, guardrails מובנים (PII redaction, output moderation, prompt injection detection), ו-semantic caching בוגר יותר ממה שיש ב-LiteLLM. השכבה ה-cloud מוסיפה dashboard לתצפית, alerting ו-conditional routing מבוסס-מטה-דאטה של המשתמש.

שילוב Portkey כ-gateway מ-JavaScript עם מדיניות fallback ו-cache:

import Portkey from "portkey-ai";

const portkey = new Portkey({
  apiKey: process.env.PORTKEY_API_KEY,
  config: {
    strategy: { mode: "fallback" },
    targets: [
      { virtual_key: "anthropic-prod", override_params: { model: "claude-sonnet-4-6" } },
      { virtual_key: "openai-prod",    override_params: { model: "gpt-5-mini" } },
    ],
    cache: { mode: "semantic", max_age: 3600 },
    retry: { attempts: 3, on_status_codes: [429, 500, 502, 503, 504] },
  },
});

const chat = await portkey.chat.completions.create({
  messages: [{ role: "user", content: "Summarize the key differences." }],
  metadata: { user_id: "u_5581", team: "growth" },
});

המפתחות הווירטואליים ב-Portkey (virtual_key) הם רפרנס לא-סודי שנשמר על השרתים שלהם, כך ה-secrets לא עוברים בקוד האפליקציה. שדה ה-metadata חשוב במיוחד: כל בקשה מקבלת attribution למשתמש, לצוות ולפיצ'ר, מה שמאפשר לפצל את חשבון ה-LLM לפי יחידות עסקיות אמיתיות ולא רק לפי מודל. עבור מי שרוצה להעמיק בשכבת התצפית שמעל השער, כתבתי מדריך נפרד על תצפית LLM ב-2026: השוואת Langfuse, LangSmith ו-Helicone. שער ותצפית הם שכבות משלימות, לא מתחרות.

RouteLLM, מוח הניתוב ולא השער

RouteLLM הוא הכלי המוטעה-להבנה מבין הארבעה. הוא לא שער ולא פרוקסי. הוא framework מחקר מ-Berkeley ו-LMSYS שמאמן ומגיש את החלטת הניתוב עצמה. הרעיון: במקום לשלוח כל בקשה למודל היקר (Claude Opus, GPT-5), מודל קטן ומאומן חוזה איזה בקשות הן "קלות" ומעביר אותן למודל זול (Haiku, GPT-5-mini). ה-paper המקורי מדווח על חיסכון של 85% בעלות עם 95% מהאיכות של המודל היקר בבנצ'מרקים סטנדרטיים, אבל וזה חשוב, על התעבורה שלכם המספרים יכולים להיות שונים לחלוטין.

הדרך הנכונה להשתמש ב-RouteLLM ב-2026 היא לא במקום LiteLLM או Portkey, אלא בתוכם, כמרכיב שבוחר את שדה ה-model לפני שהבקשה נשלחת דרך השער. הנה דוגמה של אינטגרציה:

from routellm.controller import Controller

router = Controller(
    routers=["mf"],  # matrix factorization router
    strong_model="anthropic/claude-sonnet-4-6",
    weak_model="anthropic/claude-haiku-4-5",
)

def choose_model(prompt: str, cost_threshold: float = 0.11593) -> str:
    """Returns the model name to send to your LLM gateway."""
    return router.route(
        prompt=prompt,
        router="mf",
        threshold=cost_threshold,
    )

# Then send through LiteLLM / Portkey with the chosen model
model_id = choose_model(user_prompt)
response = litellm_client.chat.completions.create(
    model=model_id,
    messages=[{"role": "user", "content": user_prompt}],
)

ה-cost_threshold נבחר על ידי כיול על 50-100 דוגמאות מתעבורה אמיתית שלכם. אל תסתמכו על ברירת המחדל. שגיאה נפוצה שאני רואה: צוותים מפעילים RouteLLM עם ה-threshold מה-repo של Berkeley, ומופתעים כשהאיכות צונחת. הסיבה: התפלגות הבקשות שלכם שונה מ-MT-Bench. תמיד ריצו evaluation על תעבורת ייצור לפני ה-cutover. יש לי מדריך נפרד על בדיקות והערכת אפליקציות LLM בייצור עם DeepEval שמראה איך לכייל את זה בשלוש שעות.

תבניות ייצור: fallback, circuit breakers ו-semantic caching

שלוש התבניות הבאות מפרידות בין "פרוקסי דמו" ל"שער LLM ייצור". הן חוצות את כל ארבעת הכלים ומיישמות עקרונות ידועים ממערכות מבוזרות, פשוט מותאמים לעולם של LLMs שבו החביון הוא שניות ולא מילישניות, והמחיר לבקשה יכול להשתנות פי 30 בין מודלים.

שרשרת Fallback עם exponential backoff

ההגדרה הטיפוסית שלי: 3 מודלים בשרשרת (primary → secondary → cheap emergency), 3 retries עם backoff של 500ms ואז 1s ואז 2s + jitter של 25%. ה-jitter קריטי. בלעדיו כל הבקשות שנכשלו יחד מתפוצצות במקביל 500ms אחר כך ומורידות את הספק הבא. Failover יכול להסתיים בפחות מ-50ms אם הכל מכוון היטב.

Circuit Breakers

Circuit breaker עוקב אחרי אחוז הכשלון של קריאות לספק. ברגע שהכשלון חוצה סף (למשל 20% בחלון של 30 שניות), הפרוקסי מפסיק לשלוח בקשות חדשות שם ל-cooldown של 30 שניות במקום לחכות לכל timeout בנפרד. Portkey ו-LiteLLM שניהם תומכים בזה מ-config; ב-OpenRouter זה מנוהל אוטומטית ברקע ולא נחשף למשתמש. חשוב: circuit breaker לא מחזיר ספק מת לחיים, הוא רק חוסך לכם זמן ותקציב על ניסיונות שיודעים מראש שיכשלו.

Semantic Caching

Cache סמנטי מזהה בקשות דומות (לא רק זהות) ומחזיר תגובה שמורה. בייצור, צוותים מדווחים על 40%-60% cache hit rate על תעבורה חוזרת, מה שאומר שבין 40% ל-60% מהבקשות עוקפות את המודל לגמרי. הסף הנפוץ (similarity_threshold) הוא 0.95 עם cosine similarity על embeddings של text-embedding-3-small. סף גבוה מדי (0.99) הופך את ה-cache ל-lookup רגיל; נמוך מדי (0.85) גורם ל-false hits שמחזירים תשובות לא רלוונטיות. עבור אפליקציות שכוללות RAG, כתבתי בנפרד על Prompt Caching ב-2026 לחיסכון של עד 90%, טכניקה משלימה שעובדת ברמת הספק, לא ברמת השער.

איך לבחור? מדריך החלטה לפי מקרה שימוש

אחרי עשרות פרויקטים, הפכתי את ההחלטה לעץ החלטה של שלוש שאלות. השאלה הראשונה קובעת את המסגרת, השנייה מכווצת ל-2 מועמדים, השלישית סוגרת. אין תשובה נכונה אחת, יש התאמה נכונה למגבלה הכובלת שלכם.

1. האם יש לכם צוות DevOps שיתחזק פרוקסי?

אם התשובה שלילית: OpenRouter או Portkey Cloud. אם חיובית: LiteLLM או Portkey OSS. Self-hosting של פרוקסי LLM אינו טריוויאלי. אתם צריכים Postgres HA, Redis cluster, אלרטים, upgrade schedule, ו-runbook לתקלות ספק. אני ראיתי צוותים של 3 מפתחים ניסו לתחזק LiteLLM ונשרפו, לא בגלל שהכלי גרוע, אלא בגלל שהיה פרויקט אחד יותר מדי לפני 2 המבצעים.

2. מה הרגישות שלכם לחביון?

Chatbot אינטראקטיבי: כל מילישניה נספרת. פה Portkey (<1ms) או LiteLLM (~8ms) מנצחים בגדול. Batch pipeline לילי או agent אוטונומי שרץ ברקע: 150ms של OpenRouter לא ירגישו כלל, וההצלחה של setup ב-15 דקות שווה את זה. אם החביון של השער הופך למועמד לצוואר בקבוק, סימן שהאדריכלות שלכם צריכה בכלל להיות היברידית: hot path דרך LiteLLM, cold path (fine-tune experiments, evals) דרך OpenRouter.

3. איפה נמצאת שרשרת ה-compliance שלכם?

אם אתם ב-HIPAA, ב-SOC 2 Type II, או ב-EU AI Act tier 2, סביר שהעברת כל תעבורת ה-LLM לצד שלישי לא אופציה. Portkey OSS או LiteLLM עם BAA מול ספקי מודלים ישירים היא הדרך הנכונה. אם אתם startup שרוצה למגן על יריעה של פיצ'ר AI לפני שהוא הופך לליבה, OpenRouter מאפשר לכם לחקור בלי לחתום שום דבר. ההיברידיות של Portkey כאן שווה זהב: התחלתם עם ה-Cloud, וכשהגעתם ל-Series B העברתם ל-OSS על הענן שלכם בלי לשנות שורת קוד.

לצוותים שבונים מעל השער מערכות מרובות סוכנים, ה-router עצמו הופך למרכיב באדריכלות רחבה יותר. כתבתי על זה בעומק במדריך לבניית מערכות מרובות סוכנים ב-2026, שם השער מנוהל כשכבת cross-cutting שאותה משתפים כל הסוכנים. גם התיעוד הרשמי של OpenRouter Quickstart ושל Portkey Introduction כדאי לקרוא לפני קבלת ההחלטה הסופית, במיוחד לגבי אזורים גיאוגרפיים ומדיניות privacy שמשתנה בין הגרסאות המנוהלות.

שאלות נפוצות

מה ההבדל בין LLM router ל-LLM gateway?