LLM Gateways în producție (LiteLLM Proxy și Portkey) în LLMOps & Securitate AI: configurare, evaluare și bune practici

Un LLM gateway este un serviciu intermediar cu API compatibil OpenAI. Aplicațiile trimit toate cererile către gateway, iar acesta alege furnizorul și modelul, reîncearcă la erori, trece pe un model de rezervă, aplică limite și bugete și înregistrează costurile. Cheile furnizorilor stau într-un singur loc.

LiteLLM Proxy (open-source, BerriAI) se configurează dintr-un config.yaml: model_list definește grupuri de modele după model_name (mai multe implementări cu același nume sunt balansate), router_settings alege strategia de rutare (simple-shuffle implicit, least-busy, usage-based-routing, latency-based-routing), iar fallbacks numește grupul de rezervă. Cheile virtuale (/key/generate, cu bugete și limite) cer o bază PostgreSQL (DATABASE_URL).

Portkey AI Gateway este o alternativă open-source (licență MIT) cu rutare către mai mulți furnizori și guardrails integrate. Ambele gateway-uri trimit date și spre platforme de observabilitate, de exemplu Langfuse.

Concepte cheie și caracteristici

Concept / Parametru	Descriere practică
`model_list[].model_name`	Numele logic cerut de aplicație. Implementările cu același nume formează un grup între care se balansează traficul.
`litellm_params.model`	Modelul concret, cu prefixul furnizorului: `anthropic/claude-sonnet-5-5`, `openai/gpt-6-luna`.
`api_key: os.environ/NUME`	Citește cheia din variabila de mediu `NUME`.
`router_settings.routing_strategy`	`simple-shuffle` (implicit), `least-busy`, `usage-based-routing`, `latency-based-routing`.
`fallbacks`	Listă `[{"grup": ["grup-rezerva"]}]`; valorile sunt nume de grupuri din `model_list`. Există și `context_window_fallbacks` și `content_policy_fallbacks`.
`num_retries / timeout`	Reîncercări pe același grup și limita de timp per cerere.
`general_settings.master_key + DATABASE_URL`	Necesare pentru cheile virtuale cu `max_budget` și limite `tpm_limit` / `rpm_limit`.
`redis_host (router_settings)`	Starea de balansare comună când rulezi mai multe instanțe de proxy.

Exemple practice și scenarii reale

Exemplul 1: Configurație cu model de rezervă

Dacă grupul asistent eșuează după reîncercări, cererea trece la grupul asistent-rezerva.

model_list:
  - model_name: asistent
    litellm_params:
      model: anthropic/claude-sonnet-5-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: asistent-rezerva
    litellm_params:
      model: openai/gpt-6-luna
      api_key: os.environ/OPENAI_API_KEY

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2
  timeout: 60
  fallbacks: [{"asistent": ["asistent-rezerva"]}]

Exemplul 2: Apel din aplicație prin SDK-ul OpenAI

from openai import OpenAI

client = OpenAI(base_url="http://localhost:4000", api_key="cheie-virtuala")
r = client.chat.completions.create(
    model="asistent",
    messages=[{"role": "user", "content": "Salut"}],
)

Exemplul 3: Cheie virtuală cu buget

curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"models": ["asistent"], "max_budget": 50}'

Greșeli frecvente și capcane

Pui în fallbacks un nume de model al furnizorului (openai/gpt-6-luna). Valorile trebuie să fie nume de grupuri (model_name) din model_list.
Rulezi mai multe instanțe de proxy fără Redis comun. Limitele și starea de balansare nu mai sunt sincronizate între instanțe.
Setezi un timeout scurt pentru modele care gândesc mult. Cererile lungi dar valide ajung pe modelul de rezervă fără motiv.

`LLM Gateways în producție (LiteLLM Proxy și Portkey)` în LLMOps, Evaluare & Securitate AI