LiteLLM: az OpenAI-kompatibilis gateway, amit a legtöbb platformcsapat futtat

A LiteLLM az a nyílt forráskódú LLM gateway, amelyet a legtöbb platformcsapat akkor is futtat, ha nem így tervezte. Két termék egy csomagban: egy Python SDK, amely a nagy szolgáltatókat az OpenAI kérés- és válaszformájára egységesíti, és egy proxy, amely virtuális kulcsokat, büdzséket, routingot és költségkövetést tesz eléjük. A dokumentáció és a közzétett számok alapján ez a kategória legteljesebb szerelvénye, és elég nehéz ahhoz, hogy tudatos döntést érdemeljen.

Egy ugrással a modellszolgáltatók előtt ül, nem az alkalmazásadatok előtt. A visszakeresés, a promptkezelés és az agent-orchestrálás máshol él; egy OpenAI kliens, egy LangGraph munkafolyamat és egy LiteLLM proxy gond nélkül együtt létezik. Amit a gateway birtokol, az maga a kérés: ki adhatja meg, melyik deployment szolgálja ki, mennyibe kerül és ki viseli a számlát.

Mi a LiteLLM

A név két futtatható dolgot takar, amelyek egy konfigurációs fájlt és egy modelláratáblát osztanak. Az SDK egy könyvtár, amit importálunk. A proxy egy szerver, amely OpenAI huzalformátumot beszél, így minden kliens, ami már működik az OpenAI ellen, átirányítható az alap URL és a kulcs megváltoztatásával.

• MIT-licencelt, Enterprise szinttel, amely identitási és governance funkciókat ad hozzá, nem kapacitást.
• Több mint 140 providerintegráció és körülbelül 1900 modell, nyilvános ár- és kontextusablak-fájlban tartva, amely a csomaggal együtt érkezik.
• OpenAI-kompatibilis végpontok: chat completions, az Anthropic messages út, a responses API, embeddingek, batchek és realtime.
• Virtuális kulcsok kulcs-, csapat- és felhasználószintű büdzsével, ratelimittel és modell-engedélyezési listával, mind Postgres mögött.
• Egy router több kiválasztási stratégiával, deploymentenkénti leállással, súlyozott failoverrel, modellhatárokon átívelő fallbackkel és session-affinitással.
• MCP gateway és A2A agent gateway ugyanazon a végponton és ugyanazzal a kulcspolitikával, hogy az agentek szabályozott eszközhozzáférést kapjanak külön réteg nélkül.
• Callbackek Langfuse, MLflow, Helicone, LangSmith és OpenTelemetry felé, plusz Prometheus metrikák és admin felület.

Hogyan működik

Minden proxyon ámenő kérés ugyanazt a sorrendet követi: a kulcs hitelesítése, a büdzsé és a ratelimit ellenőrzése, a tokenek számolása, a deployment kiválasztása, a szolgáltató meghívása, a válasz fordítása, a költség rögzítése. Minden lépés külön is meghiúsulhat, és a router hibakezelése az a hely, ahol a legtöbb üzemeltetési tudás keletkezik.

A modellnevek az absztrakció, amelyen ez az egész áll. A konfigurációs fájl közös alias alatt listáz deploymenteket, több deployment viselheti ugyanazt az aliast, és az aliasra érkező kérést az a deployment szolgálja ki, amelyet a routingstratégia választ. Ha az aliast mozgatjuk, minden hívó szolgáltatót vált kódmódosítás nélkül. Ugyanebben a táblában élnek a fallbackek: egy kiesett deploymentet vagy a testvérei közül választanak újra, vagy egy megnevezett fallback modellre eszkalálják.

Mért többletlatencia

A benchmarkoldal 8 ms p95-öt ad 1000 kérés/másodpercnél, négy példányon egyenként 4 vCPU és 8 GB mellett, a realtime végponthoz pedig 59 ms mediánt, 67 ms p95-öt és 99 ms p99-et 1207 RPS mellett. Ugyanez az oldal közvetlen Portkey-összehasonlítást is közöl közel 1170 RPS mellett, azonos hardveren, ahol a LiteLLM p95 150 ms és p99 240 ms, a Portkey 230 ms és 500 ms értéket jelez.

A hasznosabb rész a maga a dokumentáció által közölt fenntartás. A terhelésgenerátor 0,5 és 1 másodperc között szünetel a kérések között, így bármely pillanatban körülbelül 130 kérés van folyamatban; a gondolkodási idő nélküli zárt ciklusú kliens 1000-et tart, és ugyanakkora átbocsátás mellett mintegy nyolcszoros késleltetést jelez. A közzétett késleltetési szám a folyamatban lévő kérések mélysége nélkül nem jelent semmit, és ez több közzététel, mint amit a legtöbb gyártói benchmark magával hoz.

Első lépések

A legkisebb hasznos telepítés egy konfigurációs fájl két deploymentdel egy aliast, egy master kulccsal és egy Postgres kapcsolattal. A gyorsítótár, a guardrailok, a callbackek és az admin felület később jönnek.

# config.yaml: két deployment egy alias alatt, plusz egy kezelt fallback
model_list:
  - model_name: chat-fast
    litellm_params:
      model: openai/gpt-5.6-luna
      api_key: os.environ/OPENAI_API_KEY
      rpm: 900
  - model_name: chat-fast
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
      rpm: 60
  - model_name: chat-cheap
    litellm_params:
      model: openai/gpt-5.6-luna
      api_key: os.environ/OPENAI_API_KEY

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2
  fallbacks:
    - chat-fast: [chat-cheap]

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

# docker run -p 4000:4000 -v $(pwd)/config.yaml:/app/config.yaml \
#   -e DATABASE_URL -e LITELLM_MASTER_KEY \
#   docker.litellm.ai/berriai/litellm:latest --config /app/config.yaml

A kliensoldali változtatás két sor: az OpenAI SDK-t a proxyra kell irányítani, és virtuális kulcsot kell átadni a szolgáltatói kulcs helyett. Minden válasz tartalmazza az x-litellm-overhead-duration-ms fejlécet a gateway saját költségével, és erre érdemes riasztani, ha a késleltetés nő úgy, hogy a szolgáltató nem változott.

Kulcsok, büdzsék és költség

A kulcsmodell az, ami miatt a LiteLLM megéri. Egy virtuális kulcs modell-engedélyezési listát, visszaállítási idővel bíró maximális büdzsét, TPM- és RPM-limiteket, párhuzamos kérési plafont és egy tulajdontost hordoz. A kulcsok örökölnek a tulajdonostól, ami kényelmes, de egyben a design legélesebb éle: az admin által felhasználóazonosító nélkül kiállított kulcs semmit nem örököl, és az admin tulajdonú kulcs eléri a adminisztrációs útvonalakat, mert az ügyviteli hozzáférés a tulajdonos szerepét követi, nem a kulcs saját jogosultságait.

# egy kulcs egy csapatnak: plafonnal, ratelimittel és hozzárendeléssel
curl 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "models": ["chat-fast"],
    "max_budget": 40,
    "budget_duration": "30d",
    "rpm_limit": 600,
    "tpm_limit": 400000,
    "metadata": {"team": "platform", "env": "prod"}
  }'

# mennyit költött ez a kulcs, és melyik limittel szemben
curl 'http://localhost:4000/key/info?key=sk-...' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

A költséget ugyanabból a nyilvános áratáblából számítják, amelyet az SDK szállít, minden completion-, embedding- és képkérésnél kiírnak, és kulcsonként, felhasználónként és csapatonként lekérdezhető. Ezek tehát becslések egy olyan táblából, amely a szolgáltató számlázását megelőzheti: elég közel a belső elszámoláshoz, nem elég pontos egy számla egyeztetéséhez. Ha egy szám szerződéses súllyal számít, a szolgáltató számlájából jöjjön.

Árazás és licenchatárok

A gateway MIT-licenc alatt örökre ingyen futtatható saját szerveren, felhasználó- és tokenalapú díj nélkül. Az árazási oldal az open source szintbe sorol több mint 140 providerintegrációt, virtuális kulcsokat, felhasználókat és csapatokat, költségkövetést, büdzséket és ratelimitet, LLM fallbackeket, kérés- és válasznaplózást, Prometheus metrikákat és guardrailokat. A beszerzés közvetlenül vagy az AWS Marketplace-en és viszonteladókon keresztül zajlik.

A licenc kontrollt vásárol, nem átbocsátást. Az SSO öt felhasználóig benne van, fölötte licencköteles; a SCIM, az audit naplók, a secret manager visszaírás, az IP engedélylisták, a több régiós vezérlőréteg, a virtuális kulcsrotáció és a beépített moderációs callbackek mind mögötte vannak, és a dokumentáció egyenként nevesíti őket, hogy senki ne a bevezetés után fedezze fel a határt. Az Enterprise árazása az éves kéréskapacitáshoz és a telepítés formájához igazodik, sosem tokenenként, és nincs listaár, így minden valódi költségösszehasonlítás az értékesítéssel kezdődik.

Hol csikizik

A gyengeségei üzemeltetési jellegűek, nem funkcionálisak. A proxyhoz Postgres kell, és egynél több példány esetén Redis is: ez állapottartó rendszer séma-migrációkkal és kapcsolatszámtani művelettel, és a dokumentációnak külön méretezési oldalai pont azért vannak, mert ott buknak el a telepítések. A Python SDK nagy függőségi fát húz egy szolgáltatásba, amely valójában kéréseket formáz. A 2026. márciusi supply-chain incidens, amelyben megszemélyesített LiteLLM kiadások jutottak el a PyPI-re, pedig emlékeztet arra, hogy ez egy rendkívül sok telepítéssel rendelkező csomag, amely produkciós kulcsokat kezel.

Ezek a többletlatencia számok a LiteLLM saját benchmarkjából származnak, ahol minden gateway ugyanarra a determinisztikus mock upstreamre mutatott, azonos hardveren, ami fairré teszi az összevetést és előre megjósolhatóvá a győztest. Ami nem LLM gateway, annak érdemes megnézni a Kubernetes natív változatát: az Envoy AI Gateway az OpenAI routing felületét adja meg anélkül, hogy Python futásidőt tennél a kérési útvonalba, és ez a strukturális különbség többet számít a fenti számoknál.

Vélemény

A LiteLLM a helyes alapérték annak a platformcsapatnak, amely sok csapatnak ad hozzáférést több szolgáltatóhoz, és három kérdést kell megválaszolnia üzem közben: ezt ki költötte, melyik deployment szolgálta ki, és mi történik, ha az adott szolgáltató romlik. Mindhármat jobban megválaszolja, mint az alternatívák, és mindezt anélkül, hogy átvenné a szolgáltatói kulcsok kezelését.

1. Vedd fel, ha egynél több csapat hív modelleket egynél több szolgáltatón át. A büdzsék, a költségelszámolás és a szolgáltatókon átívelő fallback indokolja az állapottartó telepítést.
2. Vedd fel, ha a beszerzés összevonása a cél. A modellváltás konfigurációs szerkesztés lesz, nem biztonsági felülvizsgálati kör.
3. Ha egyetlen szolgáltatás van, először csak az SDK-t ved. A hibákat és válaszokat egységesíti az üzemeltetési költség töredékéért, és később nyitva hagyja a proxy ajtaját.
4. Hagyd ki, ha egy csapat és egy szolgáltató a teljes történet. Egy szolgáltatói SDK és egy költség-táblázat kevesebb gépszet ugyanerre az eredményre.
5. Hagyd ki, ha a forró útvonalon az utolsó ezredmásodperc számít. A gateway Python folyamat a kérési útvonalon, a Rust átírás még béta jelölésű.

Források

1. LiteLLM dokumentáció: első lépések
2. LiteLLM dokumentáció: virtuális kulcsok
3. LiteLLM dokumentáció: router és terheléselosztás
4. LiteLLM dokumentáció: benchmarkok
5. LiteLLM dokumentáció: támogatott végpontok
6. LiteLLM dokumentáció: Enterprise
7. LiteLLM árazás