Ενορχήστρωση Πρακτόρων AI 13 λεπτά ανάγνωσηςAdvanced

LLM Gateway Σύγκριση 2026: LiteLLM vs Portkey vs OpenRouter vs Kong

Παραγωγικά LLM apps χρειάζονται gateway μπροστά από τους providers. Σύγκριση LiteLLM, Portkey, OpenRouter και Kong AI Gateway σε latency, failover, caching και κόστος.

Cara Donovan

Ενημερώθηκε: 17 Αυγούστου 2026

Ένα LLM gateway είναι το ενιαίο σημείο εισόδου που κάθεται μεταξύ της εφαρμογής σου και των παρόχων μοντέλων (OpenAI, Anthropic, Google, Bedrock, Azure, open-source), αναλαμβάνοντας routing, failover, rate limiting, semantic caching, virtual keys και observability σε ένα σημείο. Το 2026 δεν είναι πια «nice to have»: μετά από αρκετά multi-hour incidents σε major providers, το να είσαι hard-wired σε έναν πάροχο ισοδυναμεί με ξεκάθαρο single point of failure. Σε αυτόν τον οδηγό συγκρίνω τα τέσσερα gateways που βλέπω πραγματικά σε production (LiteLLM, Portkey, OpenRouter και Kong AI Gateway) με νούμερα latency, cost models και συγκεκριμένα YAML/Python examples από τη δική μου prod εγκατάσταση.

  • LiteLLM: MIT open-source proxy, self-hosted, 100+ providers, ~8ms P95 overhead σε Python (μετάβαση σε Rust ανακοινώθηκε Ιούνιο 2026 για sub-1ms).
  • Portkey: control plane για production με <1ms overhead στο edge, guardrails, RBAC και HIPAA/SOC2 story, self-hosted core plus managed cloud.
  • OpenRouter: hosted aggregator με 300+ μοντέλα πίσω από ένα API key· zero setup αλλά 100–150ms extra latency και καθόλου έλεγχος infrastructure.
  • Kong AI Gateway: επέκταση του Kong Gateway με AI plugins (semantic routing, PII sanitizer, LLM-as-Judge)· λογικό μόνο αν τρέχεις ήδη Kong.
  • Token-aware rate limiting (tokens/min, cost/min ανά tenant), όχι μόνο RPM, είναι πια baseline requirement.
  • Fallback chains με health-aware routing σε 429/5xx/timeout είναι το κύριο differentiator έναντι direct SDK integration.

Τι είναι ένα LLM gateway και γιατί το χρειάζεσαι

Ένα LLM gateway είναι ένας proxy που βάζει μία OpenAI-compatible διεύθυνση μπροστά από πολλούς providers και αναλαμβάνει έξι load-bearing concerns: provider abstraction, routing, retries/fallback, caching, observability και rate limiting. Χωρίς gateway, κάθε νέος πάροχος σημαίνει καινούριο SDK, καινούρια auth logic, καινούριο retry policy και καινούριο logging pipeline μέσα στον application code σου.

Στην πράξη, το πρώτο πράγμα που κερδίζεις είναι resilience. Όταν ο πρωτεύων πάροχος επιστρέφει 429, 503 ή timeout, η ίδια αίτηση φεύγει αυτόματα σε backup πάροχο χωρίς αλλαγή κώδικα. Το δεύτερο είναι cost governance: virtual keys ανά team με hard budgets αποτρέπουν το «γιατί ξοδέψαμε $12.000 σε ένα σαββατοκύριακο» που έχω δει τρεις φορές (και όχι σε ίδια εταιρεία). Το τρίτο είναι portability: ένα YAML rename μεταφέρει traffic από GPT-4o σε Claude Sonnet 4.5 χωρίς να αγγίξεις το application code.

Αν διαβάζεις αυτόν τον οδηγό επειδή σκέφτεσαι πρώτη φορά gateway, ίσως σε ενδιαφέρει και ο οδηγός LLM observability 2026. Οι δύο ενότητες (gateway και observability) είναι συμπληρωματικές και συνήθως αναπτύσσονται μαζί.

Πίνακας σύγκρισης LiteLLM vs Portkey vs OpenRouter vs Kong

Ξεκινάω με μια πυκνή σύνοψη των διαστάσεων που πραγματικά συγκρίνουν οι ops teams. Τα latency νούμερα είναι P95 overhead πέραν του upstream provider (μετρήσεις από third-party benchmarks και δικές μου prod egress metrics).

ΧαρακτηριστικόLiteLLMPortkeyOpenRouterKong AI Gateway
Άδεια χρήσηςMIT (open-source)OSS core + CloudProprietary SaaSApache 2.0 core + Enterprise
DeploymentSelf-hosted (Docker, Helm, Terraform)Self-host ή SaaSΜόνο SaaSSelf-host, hybrid, Konnect SaaS
P95 latency overhead~8ms (Python), sub-1ms σε Rust build<1ms (edge)100–150ms~2–5ms (Go-based)
Providers100+250+300+ μοντέλαOpenAI, Anthropic, Cohere, Bedrock, Azure, Mistral, self-hosted
Virtual keys & budgetsΔωρεάν (OSS)Δωρεάν core, RBAC στο paidAPI keys per appΣτο Enterprise tier
Semantic cachingRedis-based (OSS)Ναι, με similarity thresholdPrompt caching (basic)AI Semantic Cache plugin (Enterprise)
Guardrails / PIIIntegrations (Presidio, LlamaGuard)50+ built-in guardrailsΌχιAI Prompt Guard, PII Sanitizer (Enterprise)
ΚόστοςΔωρεάν + $500–2.000/μήνα self-hostFree tier · pay-per-requestProvider markup ~5%Konnect ~$25/μήνα CP + ~$200/1M req

LiteLLM: το self-hosted workhorse

Το LiteLLM είναι ο πιο διαδεδομένος open-source proxy για LLM traffic. MIT-licensed, ~53k GitHub stars, εβδομαδιαία releases. Τρέχει ως Python service (ή Docker container) και εκθέτει ένα OpenAI-compatible endpoint (/v1/chat/completions, /v1/embeddings, /v1/audio/transcriptions) που normalize-άρει 100+ providers πίσω από την ίδια wire spec.

Το configuration ζει σε ένα config.yaml που version-άρεις στο repo. Παράδειγμα με fallback από GPT-4o σε Claude Sonnet 4.5 και per-team budget:

# litellm-config.yaml
model_list:
  - model_name: primary-llm
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
      rpm: 500
  - model_name: primary-llm  # ίδιο public name, fallback στο ίδιο route
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
      rpm: 400

router_settings:
  routing_strategy: latency-based-routing
  num_retries: 2
  timeout: 30
  fallbacks:
    - primary-llm: ["anthropic/claude-sonnet-4-5"]
  cache_responses: true

litellm_settings:
  cache: true
  cache_params:
    type: redis
    host: os.environ/REDIS_HOST
    similarity_threshold: 0.95  # semantic cache

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL
  max_budget: 5000  # USD/μήνα σε επίπεδο instance

Από τη μεριά του client, μιλάς με τον proxy όπως θα μιλούσες με OpenAI:

from openai import OpenAI

client = OpenAI(
    api_key="sk-team-support-abc123",  # virtual key με budget=$200/μήνα
    base_url="https://llm-gateway.internal/v1",
)

resp = client.chat.completions.create(
    model="primary-llm",
    messages=[{"role": "user", "content": "Summarize this ticket"}],
    metadata={"tenant_id": "acme", "feature": "ticket-triage"},
)

Το μεγάλο win του LiteLLM είναι ότι όλα τα enterprise-y features (virtual keys, spend tracking, per-team budgets, MCP gateway με OAuth) είναι στο δωρεάν OSS core. Το paid Enterprise tier προσθέτει SSO/SAML, RBAC, SCIM, audit logs και enterprise guardrails. Οι δικοί μου αριθμοί από ένα cluster 3 pods σε EKS: ~8ms P95 gateway overhead πάνω από το upstream, ~1ms σε cache hits, ~$700/μήνα infra cost για ~15M requests/μήνα. Honestly, για το budget είναι δύσκολο να το χτυπήσεις.

Portkey: control plane για production AI

Ενώ το OpenRouter επικεντρώνεται σε model access και το LiteLLM σε self-hosted routing, το Portkey επικεντρώνεται σε ό,τι συμβαίνει μετά το deployment: observability, reliability, governance. Κάθε request περνάει από logging, tracing, cost attribution, guardrail evaluation και εμφανίζεται σε real-time dashboard με latency distributions, cost breakdowns ανά feature/user/model και cache hit rates.

Το configuration γίνεται μέσω Configs: JSON objects που ορίζουν στρατηγικές routing και μπορείς να τα εφαρμόσεις είτε ως header είτε ως virtual key alias. Παράδειγμα weighted load-balance με fallback:

{
  "strategy": { "mode": "loadbalance" },
  "targets": [
    {
      "provider": "openai",
      "override_params": { "model": "gpt-4o" },
      "weight": 0.7,
      "on_status_codes": [200]
    },
    {
      "provider": "anthropic",
      "override_params": { "model": "claude-sonnet-4-5" },
      "weight": 0.3
    }
  ],
  "cache": { "mode": "semantic", "max_age": 3600 },
  "retry": { "attempts": 3, "on_status_codes": [429, 500, 502, 503, 504] },
  "before_request_hooks": [
    { "type": "guardrail", "id": "pii-redact" },
    { "type": "guardrail", "id": "prompt-injection-scan" }
  ]
}

Το Portkey διαφημίζει <1ms overhead στο edge, και τα δικά μου νούμερα το επιβεβαιώνουν σε US-East. Το compliance story είναι από τα καλύτερα στην αγορά: HIPAA-ready, SOC 2 Type II, EU-hosted control plane, BYOK για encryption. Αν φτιάχνεις healthcare, fintech ή enterprise SaaS που περνάει από security review, το γεγονός ότι έχεις 50+ built-in guardrails plus audit logs είναι από μόνο του δικαιολογία για το platform fee.

Το μειονέκτημα: το paid pricing είναι pay-per-request και σε high-volume workloads (>50M/μήνα) το self-hosted LiteLLM μπορεί να είναι 3–5× φθηνότερο σε total cost, αρκεί να έχεις το DevOps capacity να το τρέξεις.

OpenRouter: multi-model με μηδέν setup

Το OpenRouter είναι η απλούστερη απάντηση στο «θέλω ένα API key για κάθε μοντέλο». Sign up, βάλε credits, κάλεσε 300+ μοντέλα (Claude, GPT-4o, Gemini 2.5, Llama 4, DeepSeek V3, Mistral Large, Grok 4) μέσα από ένα single OpenAI-compatible endpoint. Καμία infrastructure, κανένας provider account, κανένα YAML.

from openai import OpenAI

client = OpenAI(
    api_key=OPENROUTER_KEY,
    base_url="https://openrouter.ai/api/v1",
)

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

Η ταχύτητα υιοθέτησης είναι απαράμιλλη: από zero σε παραγωγικό traffic σε πέντε λεπτά. Το trade-off είναι ότι κάθεται σαν επιπλέον hop μεταξύ σου και του παρόχου, με μετρημένο P95 overhead 100–150ms, που για streaming ή low-latency chatbots είναι αισθητό. Δεν έχεις έλεγχο του infra, δεν κάνεις self-host, τα logs σου ζουν στα δικά τους dashboards και το SLA είναι όσο καλό είναι και το OpenRouter την ημέρα του incident.

Πρακτικά, το χρησιμοποιώ ως secondary gateway για weekend prototyping ή για μοντέλα που δεν έχουμε ενταγμένα στο κύριο LiteLLM (π.χ. πειραματικά open models). Δεν το τρέχω ως primary edge σε production apps.

Kong AI Gateway: όταν έχεις ήδη Kong

Το Kong AI Gateway δεν είναι stand-alone LLM proxy. Είναι το Kong Gateway συν AI-specific plugins. Αυτό μετράει επειδή το Kong έχει ώριμο story για routing, auth, rate limiting, Kubernetes, Konnect και enterprise operations. Για οργανισμούς που είναι ήδη στο Kong, το AI traffic γίνεται απλά «άλλο ένα class API traffic» με prompt-aware plugins από πάνω: AI Proxy για provider translation, AI Proxy Advanced για load balancing και semantic routing, AI Prompt Guard, AI PII Sanitizer, AI Semantic Cache, AI LLM-as-Judge.

Παράδειγμα declarative config για Kong με AI Proxy Advanced:

_format_version: "3.0"
services:
  - name: llm-service
    url: http://placeholder
    routes:
      - name: chat-route
        paths: ["/v1/chat/completions"]
    plugins:
      - name: ai-proxy-advanced
        config:
          balancer:
            algorithm: semantic
            slots: 10000
          targets:
            - model:
                provider: openai
                name: gpt-4o
              weight: 60
            - model:
                provider: anthropic
                name: claude-sonnet-4-5
              weight: 40
          embeddings:
            auth:
              header_name: Authorization
              header_value: Bearer ${OPENAI_KEY}
            model:
              provider: openai
              name: text-embedding-3-large
      - name: ai-semantic-cache
        config:
          embeddings:
            model:
              provider: openai
              name: text-embedding-3-large
          vectordb:
            strategy: redis
            distance_metric: cosine
            threshold: 0.15

Τα free (Apache 2.0) plugins καλύπτουν μόνο routing σε ένα upstream. Για semantic routing, semantic cache, PII sanitizer και LLM-as-Judge χρειάζεσαι Enterprise license. Το Kong Konnect SaaS control plane ξεκινά ~$25/μήνα ανά control plane, με published usage pricing γύρω στα $200/μήνα ανά 1M επιπλέον requests στο Plus tier.

Ειλικρινά, το Kong AI Gateway αξίζει μόνο αν το Kong είναι ήδη το API gateway σου. Αλλιώς προσθέτεις έναν βαρύ platform stack για να λύσεις πρόβλημα που το LiteLLM ή το Portkey λύνει καθαρότερα. Αν όμως ήδη τρέχεις Kong, το marginal cost του να προσθέσεις AI routing στο ίδιο data plane είναι πολύ χαμηλό.

Fallback routing και health-aware πολιτικές

Το πρώτο που πρέπει να ρυθμίσεις σε οποιοδήποτε gateway είναι ordered fallback chains. Στην πράξη σημαίνει: μια αίτηση που παίρνει 429, 503, timeout ή model_unavailable από τον πρώτο πάροχο, ξαναπροσπαθείται στον δεύτερο χωρίς να το μάθει ποτέ ο caller. Το κρίσιμο σημείο είναι να μην κάνεις blind retry. Αν ο πρώτος πάροχος είναι σε νεκρή ζώνη, το να τον δοκιμάζεις κάθε 200ms απλά μεγαλώνει την ουρά.

Οι σοβαρές πολιτικές είναι health-aware: το gateway κρατάει rolling window error rate ανά πάροχο και βγάζει τον unhealthy provider από το rotation για N δευτερόλεπτα (circuit breaker). Το LiteLLM το κάνει με cooldown_time στο router config· το Portkey μέσω on_status_codes και conditional routing· το Kong μέσω upstream health checks. Οι δημόσιες οδηγίες του Cloudflare AI Gateway για fallback και error handling είναι επίσης καλή αναφορά, ακόμη κι αν δεν το χρησιμοποιείς.

# LiteLLM: circuit breaker + latency-based routing
router_settings:
  routing_strategy: latency-based-routing
  cooldown_time: 60          # seconds εκτός rotation μετά από failures
  allowed_fails: 3           # πόσα errors πριν σβήσουμε τον provider
  num_retries: 2
  retry_after: 5             # honor Retry-After header
  fallbacks:
    - gpt-4o: ["claude-sonnet-4-5", "gemini-2.5-pro"]
    - claude-sonnet-4-5: ["gpt-4o", "gemini-2.5-pro"]

Στη δική μας prod εμπειρία, ένα σωστά ρυθμισμένο fallback chain μας κράτησε ζωντανούς κατά τη διάρκεια του 4-hour Anthropic outage του Απριλίου 2026. Το error rate των end users παρέμεινε <0.5% γιατί το LiteLLM έκανε failover σε GPT-4o αυτόματα, και ειλικρινά δεν το κατάλαβε ούτε το support team.

Token-aware rate limiting σε multi-tenant

Το ζουμί: τα «RPM per API key» limits που έφτιαξες για REST APIs το 2019 δεν κάνουν για LLM traffic. Ένα request μπορεί να καταναλώσει 200 tokens ή 200.000. Πρέπει να μετράς tokens per minute (TPM), cost per minute και concurrency ανά tenant/team/model, όχι απλά RPM. Αλλιώς ένας μόνο power user μπορεί να κάψει το quota όλου του app σε μία αίτηση.

Το LiteLLM υποστηρίζει tpm/rpm/max_budget ανά virtual key, ανά team και ανά model. Παράδειγμα για ένα support team με σκληρό budget:

curl -X POST https://llm-gateway.internal/key/generate   -H "Authorization: Bearer $LITELLM_MASTER_KEY"   -H "Content-Type: application/json"   -d '{
    "team_id": "support",
    "models": ["primary-llm"],
    "max_budget": 500,
    "budget_duration": "30d",
    "tpm_limit": 200000,
    "rpm_limit": 300,
    "metadata": {"cost_center": "cs-support"}
  }'

Το Portkey προσθέτει cost-based limits με real-time enforcement, π.χ. «μπλόκαρε αυτόν τον tenant αν ξεπεράσει $10/λεπτό». Το Kong AI Rate Limiting Advanced plugin (Enterprise) υποστηρίζει token counting με sliding window και token bucket strategies. Το OpenRouter σε ασφαλίζει σε επίπεδο account credits, καθόλου granularity per tenant.

Παίρνεις καλή εικόνα για το πώς κοστολογούνται τα requests αν έχεις ήδη διαβάσει τον οδηγό Prompt Caching στο Claude API, όπου εξηγώ πώς το caching αλλάζει δραματικά τα token economics.

Semantic caching και μείωση κόστους

Το exact-match caching (hash του prompt → response) πιάνει <5% hit rate σε πραγματικά workloads. Το semantic caching (embeddings του prompt και similarity search σε vector store) πιάνει 25–40% σε FAQ-heavy chatbots και support agents. Στη δική μας υλοποίηση, σε ένα ticket triage agent, το semantic cache μείωσε το LLM cost κατά $4.200/μήνα με similarity threshold 0.95.

Το LiteLLM το υλοποιεί μέσω Redis + qdrant/faiss integration· το Portkey μέσω managed semantic cache με configurable max_age και similarity· το Kong μέσω του AI Semantic Cache plugin (Enterprise) που δουλεύει με Redis vector search. Το OpenRouter έχει basic prompt caching αλλά όχι semantic.

Ποιο LLM gateway να διαλέξεις

Το δικό μου decision tree για teams που ρωτούν:

  • Solo founder / weekend prototype: OpenRouter. Ξεκινάς σε πέντε λεπτά, καίς $20 σε credits, βλέπεις αν η ιδέα δουλεύει. Όταν το monthly spend περάσει τα $1.000, ξανασκέψου.
  • Python-heavy startup, Series A/B, DevOps team: LiteLLM self-hosted από day 1. Δωρεάν core, virtual keys, budgets, semantic cache όλα included. ~$700/μήνα infra για ~15M requests.
  • Healthcare / fintech / enterprise SaaS με compliance requirements: Portkey. Τα 50+ built-in guardrails, HIPAA-ready, SOC 2, audit logs κερδίζουν το security review μόνα τους.
  • Ήδη τρέχεις Kong ως API gateway: Kong AI Gateway. Το marginal ops cost είναι σχεδόν μηδέν, το Ops team ξέρει ήδη το tooling.
  • Έχεις πολλαπλά AI features με διαφορετικά cost profiles: hybrid, LiteLLM ως primary edge για internal cost governance + OpenRouter ως secondary fallback για long-tail models.

Αν εξετάζεις πώς να συνδυάσεις gateway με evaluation και monitoring pipeline, ρίξε μια ματιά στον οδηγό LLM evaluation frameworks 2026. Το gateway παράγει τα production logs που τροφοδοτούν το evaluation harness.

Συχνές ερωτήσεις

Τι είναι ένα LLM gateway και γιατί το χρειάζομαι;

Ένα LLM gateway είναι ένας proxy που κάθεται μεταξύ εφαρμογής και providers και χειρίζεται multi-provider routing, failover, semantic caching, rate limiting και observability από ένα σημείο. Το χρειάζεσαι όταν θέλεις resilience σε provider outages, κεντρικό cost governance με virtual keys/budgets και ελευθερία να αλλάζεις μοντέλα χωρίς να αγγίζεις τον application code.

Ποιο είναι το καλύτερο open-source LLM gateway το 2026;

Το LiteLLM είναι το πιο ώριμο και πιο διαδεδομένο MIT-licensed option, με 100+ providers, virtual keys/budgets στο δωρεάν core και ~53k GitHub stars. Το Portkey OSS core και το Kong Gateway (Apache 2.0) είναι επίσης open source αλλά με πιο βασικά AI-specific features δωρεάν· τα advanced routing/guardrails είναι στα Enterprise tiers τους.

Πώς κάνω failover μεταξύ OpenAI και Anthropic όταν πέσει ο ένας;

Στο LiteLLM ορίζεις ordered fallback chain στο router config (fallbacks: {gpt-4o: [claude-sonnet-4-5]}) με allowed_fails, cooldown_time και retry_after. Το gateway ανιχνεύει 429/5xx/timeout errors, μετρά rolling error rate και βγάζει αυτόματα τον unhealthy provider από το rotation μέχρι να επανέλθει.

Είναι το Portkey open source;

Το Portkey έχει open-source AI Gateway core (self-hostable) plus managed Cloud tier. Οι δωρεάν λειτουργίες καλύπτουν routing, caching και virtual keys· τα enterprise features όπως RBAC, SSO/SAML, HIPAA-ready deployment, audit logs και οι 50+ built-in guardrails είναι στο paid πλάνο.

Πόσο latency προσθέτει ένα LLM gateway;

Εξαρτάται από την υλοποίηση: Portkey ~<1ms στο edge, Kong ~2–5ms (Go-based), LiteLLM ~8ms P95 σε Python (με Rust rewrite σε alpha από Ιούνιο 2026 να στοχεύει sub-1ms), OpenRouter 100–150ms επειδή είναι hosted extra hop. Για streaming ή low-latency chatbots, self-hosted gateways όπως LiteLLM/Portkey/Kong είναι σχεδόν πάντα η σωστή επιλογή.

Cara Donovan
Σχετικά με τον Συγγραφέα Cara Donovan

AI operations lead at a B2B SaaS. Builds the unglamorous infrastructure that keeps prod LLM apps from melting.

Σχετικά Άρθρα