🟡 Intermediate

LiteLLM — AI Gateway pre multi-model produkčné pipeline-y

LiteLLM je open-source AI gateway napísaný v Pythone, ktorý unifikuje API rozhrania viac ako 100 LLM providerov (OpenAI, Anthropic, Google Vertex, Azure, Cohere, lokálne Ollama, Llama 4…) do jedného OpenAI-compatible interface. V produkčnom AI-ops stacku v roku 2026 hrá podobnú rolu ako API Gateway v klasickom mikroservisnom prostredí.

Hlavná hodnota nie je iba unifikácia rozhrania — to sú aj rate limiting, retry, fallback medzi providermi, cost tracking, prompt caching a observability.


1. Problém, ktorý LiteLLM rieši

V malej firme s AI features typicky vznikne tento bordel:

  • Aplikácia A volá OpenAI priamo cez openai-python.
  • Aplikácia B volá Anthropic cez anthropic-sdk.
  • Aplikácia C volá Gemini cez google-genai-sdk.
  • Nikto nevie, koľko tokenov za mesiac míňame, ktorý use-case je najdrahší, kedy nás OpenAI rate-limitne, či používame cache.
  • Keď chceme prepnúť z OpenAI na Anthropic kvôli cene → refaktoring 3 aplikácií.
  • Keď chceme A/B testovať dva modely → custom kód v každej aplikácii.

LiteLLM rieši toto všetko jedným HTTP endpointom.


2. Architektúra

Dva mody:

  • Python SDK — knižnica litellm ako drop-in replacement za openai-python:

    from litellm import completion
    resp = completion(
        model="claude-opus-4-7",
        messages=[{"role": "user", "content": "Hello"}]
    )
    

    Vidíš to ako openai.chat.completions.create(), ale model parameter môže byť claude-opus-4-7, gemini-3-pro, gpt-5-turbo, ollama/llama4-70b, atď.

  • LiteLLM Proxy (production setup) — samostatný server, ktorý exposuje OpenAI-compatible HTTP API:

    litellm --config config.yaml --port 4000
    

    Aplikácie sa pripoja k http://litellm:4000/v1/chat/completions s Authorization: Bearer <virtual_key> a LiteLLM internepre-route-uje na správneho providera.


3. Config príklad (produkčný setup)

model_list:
  - model_name: claude-opus
    litellm_params:
      model: anthropic/claude-opus-4-7
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: gpt-5
    litellm_params:
      model: openai/gpt-5-turbo
      api_key: os.environ/OPENAI_API_KEY

  - model_name: cheap-fallback
    litellm_params:
      model: ollama/llama4-70b
      api_base: http://ollama:11434

router_settings:
  routing_strategy: latency-based-routing
  fallbacks:
    - claude-opus: [gpt-5, cheap-fallback]
  num_retries: 2
  timeout: 30
  cooldown_time: 60

general_settings:
  master_key: sk-1234
  database_url: postgres://litellm:secret@db/litellm
  alerting: [slack]
  slack_webhook_url: https://hooks.slack.com/...

Čo si práve získal:

  • Auto-fallback keď Anthropic vráti 503 alebo rate-limit → skús OpenAI → ak aj to padne → použi lokálny Llama 4.
  • Latency-based routing — LiteLLM si pamätá P50/P99 každého providera a routuje na najrýchlejšieho.
  • Cooldown — keď provider vráti 5xx, LiteLLM ho na 60 s "vypne" z routing pool-u.
  • Virtual API keys s rate-limitmi per-key — tím A dostane 100k tokenov/deň, tím B 1M/deň.

4. Cost tracking & observability

  • Per-request cost — LiteLLM má built-in pricing tabuľku pre každý provider, vie ti povedať: "Tento request stál 0.0042 USD."
  • /spend endpoint — agreguje útrate per virtual key / per model / per user.
  • Postgres backend — všetky requesty/responses sa logujú (voliteľne).
  • OpenTelemetry export — trace a metriky idú do Tempo/Jaeger/Datadog.
  • Slack alerting"Spend exceeded 500 USD this week", "Anthropic returned 503 for 5 min".

5. Prompt caching

LiteLLM podporuje multi-provider caching layer (Redis backend), ktorý je transparentný pre aplikáciu:

litellm_settings:
  cache: true
  cache_params:
    type: redis
    host: redis
    ttl: 3600
    similarity_threshold: 0.95   # semantic cache

Pre exact-match caching (identický prompt) je úspora ~100%. Pre semantic cache (embeddings podobnosť) ušetríš ~30-50% pri RAG workloadoch s opakujúcimi sa otázkami.

Anthropic prompt caching (native feature) sa konfiguruje v rovnakej vrstve s ttl 5 minut a šetrí 90% nákladov pri dlhých system promptoch.


6. Použitie s ostatnými nástrojmi

  • DSPy — backend cez dspy.LM("openai/gpt-5", api_base="http://litellm:4000"). Centralizovaný cost-tracking pre DSPy compilation runs.
  • LangChain / LlamaIndex — kompatibilné cez OpenAI provider interface.
  • Promptfoo — testovacie suity proti LiteLLM virtual keyom.
  • Ollama — lokálne modely transparentne miešané s cloud providermi (cost optimization: trivialne dotazy → Ollama, hard → Claude).

7. Kedy LiteLLM nestojí za zavedenie

  • 1 aplikácia, 1 model, 1 use-case — overkill. SDK direktívne stačí.
  • Striktný compliance/dátová suverenita (proxy musí byť na premise) — LiteLLM beží on-prem, ale treba dodatočnú audit kontrolu.
  • < 1000 requests/deň cez celý systém — réžia LiteLLM proxy (Postgres + Redis + Python proces) môže prevýšiť úžitok.

8. Bežné gotcha

  • Anthropic streaming chunks sa líšia od OpenAI — LiteLLM ich normalizuje, ale niektoré aplikácie spoliehajú na delta.tool_calls[].index field, ktorý LiteLLM v starších verziách neexposoval. Verifikuj pri produkčnom switchi.
  • Tool/function calling — argumenty má každý provider trochu inak naformátované. LiteLLM unifikuje, ale Edge cases s nested JSON treba testovať.
  • Rate-limit headers — Anthropic vracia anthropic-ratelimit-tokens-remaining, OpenAI x-ratelimit-remaining-tokens. LiteLLM neunifikuje tieto custom headers; aplikácia ktorá ich číta priamo musí byť upravená.
  • Embedding modely — nezabudni do model_list pridať aj text-embedding-3-small a podobne, default embeddings() endpoint vyžaduje routing.

9. Alternatívy

  • OpenRouter — managed (cloud) verzia s podobnou funkcionalitou. Bez self-host overhead, ale s providerovým markupom.
  • Helicone — observability-first proxy, menej routing features.
  • Portkey — komerčný AI gateway s GUI a teamovým billingom.
  • Vercel AI SDK Gateway — Vercel-managed gateway, ale viazaný na Vercel ekosystém.

Súvisiace témy

  • AI-in-DevOps — širší kontext AI v DevOps toolchaine.
  • Agentic-DevOps-2026 — kde sa LiteLLM stáva de facto štandardom.
  • API-Gateway — klasický mikroservisný analóg.
  • Rate limiting patterns — caddy-ratelimit modul ako edge-layer komplement.
  • Monitoring — observability pre LLM workloady.