Înapoi la catalog
LiteLLM: The Universal LLM Gateway (v1.82 - 2026 Edition)
O serie cuprinzătoare de podcasturi care acoperă LiteLLM, de la Python SDK și gestionarea unificată a excepțiilor până la Proxy Server, load balancing, virtual keys, observability și funcționalități enterprise precum RBAC și MCP Gateway.
Se redă acum
Click play to start
0:00
0:00
1
Piatra din Rosetta a LLM-urilor: Python SDK
Descoperă identitatea de bază a LiteLLM: o interfață Python unificată pentru peste 100 de LLM-uri. Învață cum să integrezi LiteLLM în baza ta de cod existentă pentru a apela Anthropic, Vertex sau Ollama fără a schimba logica de parsare compatibilă cu OpenAI.
2
Magia traducerii parametrilor
Nu-ți mai face griji despre ce furnizor suportă un anumit hiperparametru. Află cum SDK-ul LiteLLM traduce automat inputurile standard OpenAI, precum temperature, tools și max_tokens, pentru toate modelele upstream.
3
Gestionarea unificată a excepțiilor
Scrie blocurile try-except o singură dată. Descoperă cum LiteLLM prinde erorile personalizate de la AWS, Google și Azure, mapându-le perfect la excepțiile standard OpenAI, precum RateLimitError.
4
LLM Gateway: Configurarea Proxy Server-ului
Scoate LiteLLM din codul tău local și mută-l într-o platformă centralizată. Învață cum să lansezi LiteLLM Proxy Server prin Docker și să configurezi primele tale endpoint-uri folosind fișierul config.yaml.
5
Managementul centralizat al secretelor
Păstrează cheile API în afara fișierelor de configurare plaintext. Învață cum să conectezi LiteLLM la managere de secrete enterprise, precum AWS Secrets Manager sau Azure Key Vault, pentru a prelua dinamic credențialele.
6
Model Aliases: Upgrade-ul din umbră
Migrează utilizatorii către modele noi în mod silențios. Descoperă cum să folosești Model Aliases în LiteLLM pentru a mapa cererile pentru un model către un endpoint complet diferit, fără a modifica deloc codul client-side.
7
Load Balancing pentru throughput ridicat
Evită rate limits-urile și downtime-ul rutând traficul în mod inteligent. Explorează de ce simple-shuffle este strategia recomandată pentru load balancing în producție pe mai multe deployment-uri.
8
Întreruperi API și Fallbacks
Nu mai suferi niciodată de downtime AI. Învață cum să configurezi model fallbacks în LiteLLM, astfel încât, dacă furnizorul principal eșuează, traficul să fie redirecționat automat către un furnizor de rezervă.
9
Context Window Fallbacks
Nu mai plăti în plus pentru context windows masive la prompturi scurte. Învață cum să folosești pre-call checks și context window fallbacks pentru a ruta documentele supradimensionate către modele specializate.
10
Îmblânzirea cererilor blocate cu Timeouts
Nu lăsa API-urile lente să îți blocheze aplicația. Descoperă cum să configurezi global timeouts și stream timeouts în LiteLLM pentru a anula cererile blocate și a declanșa fallbacks rapide.
11
Virtual Keys pentru FinOps
Securizează-ți utilizarea API-ului cu precizie. Învață cum să generezi virtual keys folosind LiteLLM, setând limite stricte de RPM, TPM și buget pentru a-ți proteja organizația de costurile AI necontrolate.
12
Urmărirea cheltuielilor și Custom Tags
Atribuie cu precizie fiecare cent din cheltuielile LLM. Învață cum să transmiți metadata tags în cererile tale și să generezi rapoarte complete de cheltuieli folosind LiteLLM.
13
Caching pentru viteză și economii
Nu mai plăti pentru aceleași răspunsuri LLM la nesfârșit. Învață cum să configurezi exact caching cu Redis și semantic caching cu Qdrant pentru a reduce drastic latența și costurile API.
14
RBAC: Împuternicirea administratorilor de echipă
Distribuie managementul platformei în siguranță. Înțelege Role-Based Access Control din LiteLLM, delegând puterea către Org Admins și Team Admins fără a compromite securitatea globală.
15
Security Guardrails
Adaugă un strat invizibil de securitate cererilor tale LLM. Învață cum să configurezi pre-call și post-call guardrails în LiteLLM pentru a bloca prompt injections și a masca PII înainte de a ajunge la furnizorii externi.
16
Managementul dinamic al callback-urilor
Oferă microserviciilor puterea confidențialității. Învață cum să folosești header-ul x-litellm-disable-callbacks pentru a permite cererilor API sensibile să renunțe la logarea centralizată de observability.
17
Drop-in Observability
Obține vizibilitate instantanee asupra traficului tău LLM. Învață cum să direcționezi telemetria, traces și excepțiile către instrumente precum Langfuse și Sentry folosind callback-uri simple de succes și eșec.
18
Metrici Prometheus și sănătatea Pod-urilor
Ia pulsul proxy-ului tău. Descoperă cum să expui endpoint-ul /metrics către Prometheus, să urmărești cererile in-flight și să folosești custom tags pentru a segmenta datele în Grafana.
19
Text-to-Speech Universal
Standardizează-ți generarea vocală. Descoperă cum să apelezi modele Text-to-Speech de la Gemini, Vertex și AWS Polly folosind exact același format de endpoint audio compatibil cu OpenAI.
20
Puntea Assistants API
Gestionează starea conversației fără efort între furnizori. Învață cum LiteLLM încapsulează modelele non-native în interfața standard OpenAI Assistants API, permițându-ți să folosești Threads și Messages peste tot.
21
MCP Gateway
Îmbunătățește-ți modelele cu instrumente în mod centralizat. Descoperă cum să configurezi servere Model Context Protocol (MCP) prin HTTP, SSE sau STDIO în LiteLLM, oferind oricărui LLM acces la capabilități externe.
22
A2A: Urmărirea agenților autonomi
Adu agenții autonomi sub control. Învață cum să invoci agenți complecși LangGraph sau Bedrock prin proxy folosind protocolul A2A, permițând gruparea trace-urilor și urmărirea unificată a cheltuielilor.
23
Rotații de chei cu Zero-Downtime
Obține tranziții de securitate cu zero-downtime. Învață cum să configurezi rotații automate programate ale cheilor și grace periods pentru virtual keys de nivel enterprise în LiteLLM.
24
Admin UI și AI Hub
Fă-ți platforma AI accesibilă tuturor. Învață cum să gestionezi Admin UI, să ajustezi credențialele UI și să folosești AI Hub pentru a permite dezvoltatorilor să descopere în siguranță modelele și agenții permiși.
Episoade
1
Piatra din Rosetta a LLM-urilor: Python SDK
4m 03sDescoperă identitatea de bază a LiteLLM: o interfață Python unificată pentru peste 100 de LLM-uri. Învață cum să integrezi LiteLLM în baza ta de cod existentă pentru a apela Anthropic, Vertex sau Ollama fără a schimba logica de parsare compatibilă cu OpenAI.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 1 din 24. Schimbi cheia de API OpenAI cu una Anthropic și, dintr-o dată, toată aplicația ta crapă. Fiecare provider își structurează input-urile și output-urile diferit, forțându-te să scrii și să menții logică de parsing custom pentru fiecare model nou. Piatra Rosetta a LLM-urilor, SDK-ul de Python LiteLLM, rezolvă complet această problemă.
Există o concepție greșită destul de comună cum că LiteLLM concurează cu LangChain. Nu este așa. LiteLLM nu este un agent framework. Nu orchestrează tool-uri, nu gestionează memoria și nu face chain la task-uri. Este pur și simplu un drop-in replacement pentru clientul OpenAI.
SDK-ul de Python LiteLLM traduce peste o sută de API-uri de la diferiți provideri exact în formatul de chat completion de la OpenAI. Nu trebuie să înveți nuanțele specifice ale API-urilor Vertex AI, Anthropic sau Hugging Face. Scrii codul o singură dată folosind standardul OpenAI, iar LiteLLM se ocupă de translation layer în background.
Nucleul acestui SDK este o singură interfață unificată numită funcția de completion. Când folosești această funcție, îi dai un model string. Acest string îi spune lui LiteLLM ce provider să contacteze. De asemenea, pasezi parametri standard OpenAI, cum ar fi temperature, max tokens și lista de mesaje. LiteLLM ia acești parametri standard și îi mapează pe câmpurile corecte pentru providerul țintă.
Ia în considerare un scenariu în care vrei să apelezi Claude 3.5 Sonnet. Folosind SDK-ul standard Anthropic, ar trebui să îți structurezi blocurile de prompt conform cerințelor lor specifice de messages API. Cu LiteLLM, pur și simplu apelezi funcția de completion. Pasezi numele modelului pentru Claude. Pasezi array-ul standard de mesaje, folosind dicționare cu roluri de user și system. În cele din urmă, oferi cheia ta de API Anthropic, fie ca parametru, fie ca environment variable.
Aici este ideea principală. Response object-ul returnat de această funcție este structurat exact ca un obiect de chat completion de la OpenAI.
Când vrei să extragi textul generat de Claude, parcurgi exact aceeași cale pe care ai parcurge-o pentru un model GPT. Te uiți în array-ul choices. Iei primul element. Accesezi message object-ul. Citești proprietatea content. Logica aplicației tale habar nu are că Anthropic a generat textul. Network request-ul din spate a fost tradus, trimis către provider, iar răspunsul a fost mapat înapoi pe schema OpenAI înainte să ajungă vreodată la variabilele tale.
Această abstractizare se aplică întregii interacțiuni. Acoperă erori, statistici de token usage și chiar răspunsuri de tip streaming. Dacă Anthropic returnează o eroare de rate limit, LiteLLM o mapează la rate limit exception-ul standard de la OpenAI. Codul tău existent de error handling o prinde fără nicio modificare. Dacă ceri un răspuns de tip streaming, LiteLLM returnează chunk-uri care arată exact ca streaming chunk-urile de la OpenAI.
Poți itera prin diferite modele pur și simplu schimbând valoarea de tip string a parametrului model și înlocuind environment variable-ul pentru cheia de API. Restul codului tău Python rămâne complet static. Nu mai ești blocat într-un singur ecosistem doar pentru că ai scris codul de integrare pentru un anumit provider.
Adevărata valoare a interfeței unificate de completion constă în decuplarea logicii aplicației tale de variațiile nesfârșite ale API-urilor de la model provideri, transformând modificările complexe de infrastructură în simple schimbări de string-uri.
Mersi de ascultare, happy coding tuturor!
2
Magia traducerii parametrilor
3m 56sNu-ți mai face griji despre ce furnizor suportă un anumit hiperparametru. Află cum SDK-ul LiteLLM traduce automat inputurile standard OpenAI, precum temperature, tools și max_tokens, pentru toate modelele upstream.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 2 din 24. Se așteaptă Claude la max tokens, max tokens to sample, sau la cu totul altceva? De fiecare dată când schimbi providerii de modele, de obicei trebuie să rescrii întregul payload al request-ului API pentru a se potrivi convențiilor lor specifice de denumire. Parameter Translation Magic este feature-ul care face ca această problemă să dispară.
Când apelezi funcția de completion în LiteLLM, îți scrii request-ul folosind doar formatul standard de parametri OpenAI. Nu trebuie să cauți dictionary keys specifice pentru Anthropic, Vertex AI sau Cohere. Librăria îți interceptează input-urile formatate pentru OpenAI și le traduce automat în structura exactă cerută de providerul target.
Hai să ne uităm la un scenariu specific. Vrei să faci un query către un model Vertex AI Gemini. Ai nevoie să folosească function calling și vrei ca răspunsurile să fie foarte deterministe, așa că setezi temperature la zero virgulă doi. Dacă ai scrie o integrare directă, Vertex are propriul său mod unic, deeply nested, de a defini tools și de a seta configurațiile de generare ale modelului. Cu LiteLLM, ignori complet acest lucru. Îți construiești array-ul de tools folosind sintaxa JSON standard de la OpenAI. Pasezi acel array, împreună cu valoarea pentru temperature, direct în apelul de completion. LiteLLM preia acele arguments OpenAI, le descompune și construiește payload-ul corect pentru API-ul Vertex AI înainte de a trimite network request-ul.
Această mapare automată este incredibil de eficientă, dar introduce un edge case. Ce se întâmplă dacă pasezi un parametru OpenAI pe care modelul target pur și simplu nu îl suportă deloc? Poate specifici un presence penalty, dar providerului îi lipsește un concept corespunzător. By default, LiteLLM este strict. Va arunca o exception și va da fail la apelul de completion. Aceasta este o alegere de design deliberată. Te împiedică să pierzi silently configurări care ar putea fi critice pentru comportamentul aplicației tale.
Strict failing-ul este safe, dar poate fi frustrant dacă rutezi dinamic prompt-urile utilizatorilor prin zeci de modele diferite în producție. Dacă vrei ca apelul să aibă succes indiferent de nepotrivirile minore de parametri, adaugi un flag numit drop params setat pe true în apelul tău de completion. Când activezi asta, LiteLLM traduce în continuare tot ce poate mapa cu succes. Dar dacă întâlnește un parametru OpenAI pe care providerul target nu îl recunoaște, pur și simplu elimină acel parametru nesuportat din payload și trimite restul request-ului. Apelul are succes, iar parametrul nesuportat este ignorat în siguranță.
Dacă preferi să gestionezi capabilitățile gracefully în propriul tău cod, în loc să te bazezi pe silent drops, există un tool de introspecție built-in. Poți apela o helper function numită get supported openai params. Pasezi numele modelului ca argument, iar ea returnează o listă cu toți parametrii standard OpenAI care se mapează cu succes pe acel model specific. Asta îți permite să verifici ce suportă de fapt un model la runtime, înainte să execuți apelul de completion.
Iată ideea cheie. Adevărata valoare a traducerii parametrilor este că promovează specificația API-ului OpenAI dintr-o schema vendor-specific într-un limbaj de interfață universal pentru întregul tău application stack.
Mulțumesc pentru audiție, happy coding tuturor!
3
Gestionarea unificată a excepțiilor
3m 53sScrie blocurile try-except o singură dată. Descoperă cum LiteLLM prinde erorile personalizate de la AWS, Google și Azure, mapându-le perfect la excepțiile standard OpenAI, precum RateLimitError.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 3 din 24. Să scrii o logică custom de error handling pentru cincisprezece API-uri de AI diferite e o metodă excelentă să-ți irosești weekendul. Fiecare API are propriul mod unic de a-ți spune că trimiți prea multe request-uri sau că token-ul tău este invalid. Ca să nu mai scrii condiții la nesfârșit, LiteLLM folosește Unified Exception Handling.
În loc să înveți cum returnează erorile Anthropic, Cohere sau Google, trebuie să gestionezi un singur standard. LiteLLM mapează toate excepțiile provider-ului direct la tipurile standard de excepții OpenAI. Dacă un request eșuează, gateway-ul interceptează eroarea raw, o traduce pe baza status code-ului HTTP și a răspunsului de la provider, și aruncă eroarea OpenAI corespunzătoare.
Gândește-te la un scenariu în care folosești un inference endpoint de la Hugging Face. În orele de vârf, endpoint-ul este copleșit de trafic. Hugging Face va respinge request-ul. Dacă le-ai apela API-ul direct, ar trebui să parsezi eroarea lor specifică HTTP cinci zero trei service unavailable sau un mesaj custom de throttling. Cu unified exception mapping, nu ai nevoie de un exception handler specific pentru Hugging Face.
Îți structurezi codul folosind un bloc try standard în jurul apelului de generare. Imediat sub el, adaugi un bloc except gândit să prindă o eroare OpenAI Rate Limit Error. În interiorul acelui bloc, declanșezi funcția ta standard de exponential backoff. Aplicația ta se pune pe pauză, așteaptă și reîncearcă request-ul. Dacă mai târziu schimbi Hugging Face cu Vertex AI, logica ta de backoff rămâne exact la fel. Eroarea OpenAI Rate Limit Error prinde evenimentul de throttling de la Vertex la fel de sigur.
Această mapare acoperă tot setul standard de erori. Poți prinde o eroare OpenAI API Timeout Error atunci când un server remote nu mai răspunde. Poți prinde un Authentication Error atunci când un API key este rotit sau expiră. Poți gestiona un API Connection Error pentru picări de rețea, sau un Bad Request Error dacă payload-ul tău este malformat. Codul aplicației tale tratează întregul ecosistem de AI ca și cum ar comunica exclusiv cu un singur provider previzibil.
Iată ideea cheie. Uneori, o abstracție curată ascunde prea mult context. Un Bad Request Error generic de la OpenAI îți spune că apelul a eșuat, dar de multe ori trebuie să știi exact de ce. Azure, de exemplu, aplică filtre stricte de content policy. Dacă Azure respinge un prompt pentru că încalcă regulile de safety, maparea acestuia la o eroare generică OpenAI riscă să piardă acel safety flag specific pe care trebuie să-l loghezi sau să-l arăți user-ului.
Pentru a rezolva asta, LiteLLM atașează un atribut numit provider specific fields la obiectul excepției. Când prinzi o excepție OpenAI în codul tău, poți inspecta acest atribut. Acesta conține un dicționar cu datele de eroare originale, nemapate, direct de la provider. Ai fluxul unificat de try și except pentru rutare și retry-uri, dar păstrezi datele granulare pentru debugging și auditare.
Îți construiești sistemele reziliente, retry-urile și circuit breaker-ele în întregime în jurul claselor de excepții OpenAI. Standardizarea limitelor de eroare previne scurgerea modurilor de eșec specifice provider-ului în logica de bază a aplicației tale.
Mulțumesc pentru audiție, happy coding tuturor!
4
LLM Gateway: Configurarea Proxy Server-ului
4m 02sScoate LiteLLM din codul tău local și mută-l într-o platformă centralizată. Învață cum să lansezi LiteLLM Proxy Server prin Docker și să configurezi primele tale endpoint-uri folosind fișierul config.yaml.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 4 din 24. Ce-ar fi dacă întreaga ta companie ar putea partaja un endpoint LLM fără a expune vreodată cheile API brute ale providerului? Trecerea de la o integrare SDK locală la o arhitectură centralizată schimbă modul în care gestionezi accesul. Acesta este The LLM Gateway: Setting up the Proxy Server.
Mulți developeri presupun că introducerea unui proxy middleware custom necesită scrierea de cod client custom pentru a comunica cu el. Asta este fals. Proxy-ul LiteLLM vorbește formatul nativ al API-ului OpenAI. Orice librărie, aplicație sau script care știe cum să comunice cu OpenAI are nevoie doar să-și actualizeze base URL-ul pentru a pointa către noul tău proxy.
Pentru a porni serverul proxy, ai nevoie de un fișier de configurare. Acesta este un fișier YAML care îți definește logica de rutare. Nucleul acestui fișier este o secțiune numită model list. Această listă mapează numele modelelor pe care aplicațiile tale interne le vor cere, la modelele reale ale providerului de backend.
În interiorul model list-ului, fiecare intrare necesită două elemente principale. Primul este numele modelului. Acesta este aliasul pe care îl expui userilor tăi. Ai putea să-l numești internal-chat-model. Al doilea este un bloc numit LiteLLM parameters. Aici configurezi destinația propriu-zisă. Această distincție este importantă. Numele modelului este ceea ce cere clientul tău, dar blocul LiteLLM parameters definește ce procesează de fapt requestul.
Dacă rutezi către un deploy Azure OpenAI, blocul tău LiteLLM parameters va conține stringul specific modelului Azure, base URL-ul API-ului tău Azure și versiunea API-ului. De asemenea, îi spui lui LiteLLM care environment variable ține API key-ul. Nu hardcodezi cheia direct în fișierul YAML.
Cu fișierul de configurare gata, faci deploy la proxy folosind Docker. Folosești imaginea oficială LiteLLM din GitHub Container Registry. Când rulezi containerul Docker, execuți trei pași specifici. Mapezi portul local patru mii la portul patru mii al containerului. Montezi fișierul tău de configurare YAML în container, astfel încât proxy-ul să poată citi model list-ul. În cele din urmă, pasezi credențialele reale ale providerului în container ca environment variables.
Odată ce containerul rulează, proxy-ul este live și ascultă pe localhost portul patru mii. Îl testezi exact așa cum ai testa API-ul oficial OpenAI. Faci un request HTTP POST standard folosind un tool precum cURL. Țintești localhost portul patru mii, urmat de path-ul slash chat slash completions. În body-ul requestului, specifici aliasul pe care l-ai definit anterior ca model și oferi array-ul messages.
Proxy-ul primește acest payload standard. Citește aliasul cerut, îl caută în fișierul tău de configurare și extrage parametrii Azure. Apoi semnează requestul cu API key-ul tău Azure, îl forwardează către Microsoft și traduce răspunsul înapoi în formatul exact pe care îl așteaptă clientul tău.
Iată ideea cheie. Proxy-ul abstractizează complet providerul de backend de la nivelul de application layer. Dacă decizi să schimbi deploy-ul Azure cu un provider complet diferit luna viitoare, nu atingi nicio linie din codul aplicației tale. Actualizezi doar blocul LiteLLM parameters în fișierul tău de configurare YAML și repornești containerul.
Valoarea principală a serverului proxy este că aplicațiile tale client nu știu niciodată, și nu trebuie niciodată să știe, care cloud provider generează de fapt token-urile.
Mulțumesc pentru audiție, happy coding tuturor!
5
Managementul centralizat al secretelor
3m 52sPăstrează cheile API în afara fișierelor de configurare plaintext. Învață cum să conectezi LiteLLM la managere de secrete enterprise, precum AWS Secrets Manager sau Azure Key Vault, pentru a prelua dinamic credențialele.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 5 din 24. Dacă API key-ul principal al companiei tale stă într-un fișier YAML plaintext pe un server de producție, echipa ta de securitate va avea o zi proastă. Credențialele hardcoded sunt un incident care abia așteaptă să se întâmple. Soluția este Centralized Secret Management.
Când rulezi un gateway, acesta are nevoie de acces la API key-urile providerului tău upstream pentru a ruta traficul cu succes. Abordarea default este adesea să le pui într-un environment variable local sau direct în fișierul principal de configurare. Centralized Secret Management schimbă complet acest pattern. Îi permite gateway-ului să citească dinamic credențialele dintr-un vault enterprise extern, cum ar fi AWS Secrets Manager, Azure Key Vault, Google Secret Manager sau HashiCorp Vault.
Pentru a activa această conexiune, configurezi două câmpuri specifice în blocul de general settings al fișierului tău de configurare. Primul câmp este key management system. Aici, definești identificatorul providerului tău de vault. Dacă folosești AWS, vei seta asta la aws_kms. Al doilea câmp este key management settings. Aceasta este o structură nested în care oferi parametrii exacți de conexiune pe care îi cere vault-ul tău specific, cum ar fi regiunea AWS target sau alte detalii de autentificare necesare.
Odată ce conexiunea la vault este stabilită, trebuie să le spui configurațiilor tale individuale de model routing să își tragă cheile din acel vault. Faci asta folosind un string prefix specific în locul cheii reale.
Aici e partea esențială. În loc să tastezi un key string real, tastezi fraza os dot environ forward slash, urmată imediat de numele exact al secretului tău așa cum există în vault.
Să urmărim un scenariu concret. Vrei să rutezi traficul către un model Azure, iar API key-ul real este stocat în siguranță în AWS Secrets Manager sub numele azure api key production. În fișierul tău de configurare, setezi blocul de model routing. Dar pentru câmpul api key, setezi valoarea la os dot environ forward slash azure api key production.
Când gateway-ul procesează un request pentru acel model, vede prefixul. Știe să nu folosească acel string ca pe o cheie literală. În schimb, face un call securizat către AWS Secrets Manager, cere valoarea pentru acel nume exact de secret și preia cheia reală pentru a autentifica request-ul. Cheia în plaintext nu atinge niciodată discul tău. Fișierul tău de configurare rămâne complet curat și sigur pentru a-i da commit în version control.
Asta acoperă tragerea credențialelor upstream în gateway. Dar integrarea cu secret manager merge în ambele direcții. Poate, de asemenea, să scrie date. Când folosești gateway-ul pentru a genera noi virtual proxy keys pentru echipele tale interne de engineering, poți configura sistemul să salveze automat acele chei nou generate direct în secret manager-ul tău. Asta asigură că credențialele interne pe care le emiți sunt stocate și gestionate cu exact aceleași controale de securitate ca și credențialele de provider pe care le consumi.
Fișierele tale de configurare definesc structura infrastructurii tale de routing, dar nu ar trebui să conțină niciodată secretele acesteia. Cel mai sigur loc pentru a stoca un API key în configurația gateway-ului tău este nicăieri.
Mulțumesc pentru audiție, happy coding tuturor!
6
Model Aliases: Upgrade-ul din umbră
4m 03sMigrează utilizatorii către modele noi în mod silențios. Descoperă cum să folosești Model Aliases în LiteLLM pentru a mapa cererile pentru un model către un endpoint complet diferit, fără a modifica deloc codul client-side.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 6 din 24. Ce-ar fi dacă ai putea migra întreaga bază de utilizatori de la OpenAI la Anthropic fără să le ceri să modifice o singură linie din codul lor de integrare? Sau să muți discret un utilizator de pe free-tier pe o alternativă open-source fără să-i strici logica existentă a aplicației? Mecanismul care face posibilă această tranziție silențioasă se numește Model Aliases.
Este ușor să confunzi alias-urile cu routing-ul, așa că hai să le separăm. Routing-ul se ocupă de load balancing pe mai multe deployment-uri ale exact aceluiași model. Dacă ai trei instanțe Azure OpenAI separate care rulează aceeași versiune de GPT-4, routing-ul distribuie uniform traficul de intrare între ele pentru a preveni rate limits. Alias-urile fac ceva complet diferit. Un alias interceptează un nume de model cerut și îl mapează către un model complet diferit din spatele proxy-ului.
Aplici această mapare în momentul în care creezi o cheie virtuală pentru un client. Când trimiți request-ul către endpoint-ul de generare a cheilor din LiteLLM, incluzi un obiect aliases în payload-ul tău. Acest obiect este pur și simplu un dicționar care potrivește numele modelului pe care îl va cere clientul cu numele modelului pe care intenționezi de fapt să-l servești.
Hai să ne uităm la un scenariu concret. Ai un segment de utilizatori pe free-tier. Inițial, ei și-au construit tool-urile în jurul GPT-4, iar exact acel string este în prezent hardcoded în network request-urile lor. Să servești GPT-4 utilizatorilor care nu plătesc este scump, așa că decizi să le redirecționezi prompt-urile către un endpoint intern, extrem de optimizat, de Mistral 7B.
Pentru a realiza asta, generezi o nouă cheie virtuală special pentru acest grup de utilizatori. În payload-ul de generare, definești un alias care mapează string-ul GPT-4 direct la numele deployment-ului tău de Mistral 7B. Le dai această nouă cheie virtuală utilizatorilor. Ei nu își modifică deloc codul aplicației. Ei continuă să trimită request-uri standard de chat completion către proxy-ul tău, cerând explicit GPT-4.
Iată ideea principală. Proxy-ul LiteLLM primește request-ul și autentifică cheia virtuală. Citește configurația legată de acea cheie specifică și detectează regula ta de alias. Înainte să ruteze payload-ul către un provider extern, proxy-ul rescrie parametrul model în memorie. Elimină GPT-4 și îl înlocuiește cu Mistral 7B. Request-ul merge la deployment-ul tău intern de Mistral, generează textul și rutează răspunsul înapoi prin proxy către client.
Aplicația client primește formatul standard de răspuns pe care îl așteaptă. Parser-ele sale funcționează perfect, iar aplicația continuă să funcționeze normal. Dezvoltatorii care mențin acea aplicație client nu sunt deloc conștienți că modelul de limbaj din spate a fost schimbat.
Deoarece alias-urile sunt atașate direct de cheile virtuale individuale, și nu de configurația globală a serverului, menții controlul absolut asupra diferitelor segmente de utilizatori. O cheie poate face alias la trafic către un model mai ieftin pentru utilizatorii free, în timp ce o altă cheie permite traficului premium să treacă nemodificat. Poți folosi exact aceeași logică și pentru a gestiona model deprecations. Când un provider retrage un model mai vechi, pur și simplu faci alias de la numele vechi către noua versiune, scutindu-ți toți clienții de a fi nevoiți să facă push la update-uri de cod de urgență. Cel mai puternic aspect al unui model gateway nu este doar gestionarea traficului de rețea, ci decuplarea așteptărilor clientului de realitatea fizică a arhitecturii tale de backend.
Mulțumesc pentru audiție, happy coding tuturor!
7
Load Balancing pentru throughput ridicat
3m 40sEvită rate limits-urile și downtime-ul rutând traficul în mod inteligent. Explorează de ce simple-shuffle este strategia recomandată pentru load balancing în producție pe mai multe deployment-uri.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 7 din 24. În sfârșit ai obținut acces în producție la Azure OpenAI, ți-ai lansat aplicația și te-ai lovit imediat de o eroare masivă de rate limit la primul spike mare de trafic. Ai cota, dar face bottleneck într-o singură regiune. Load Balancing for High Throughput rezolvă asta. Pentru a gestiona volume mari de request-uri fără să atingi limitele, trebuie să-ți distribui traficul pe mai multe deployment-uri identice. În LiteLLM, faci asta prin configurarea unui router. Grupezi mai multe endpoint-uri de backend sub un singur nume logic de model. Să zicem că ai o aplicație susținută de cinci deployment-uri Azure, răspândite în cinci regiuni geografice diferite. Când aplicația ta cere un completion, routerul decide care din aceste cinci regiuni primește request-ul. Controlezi această logică de decizie setând o strategie de routing în setările routerului. Abordarea intuitivă este usage-based routing, unde sistemul trimite request-ul către deployment-ul care are în acel moment cel mai mic trafic. Dar ca să faci asta, trebuie să urmărești consumul exact de tokeni în timp real. Să urmărești state-ul în timp real înseamnă să faci un network call către un cache precum Redis pentru fiecare request în parte, chiar înainte ca prompt-ul să plece. Asta adaugă o taxă permanentă de latență aplicației tale. Pentru mediile de producție cu high throughput, vrei să eviți acel hop suplimentar. Abordarea recomandată este o strategie numită simple-shuffle. Simple-shuffle nu urmărește state-ul live. Selectează random un endpoint din pool-ul tău, pe baza unor weights predefinite. Când adaugi cele cinci deployment-uri Azure în fișierul de configurare, îi atribui o limită fiecăruia, de obicei Requests Per Minute, sau RPM. Poți folosi și Tokens Per Minute, sau TPM. Dacă regiunea ta principală are o limită RPM de zece mii, iar o regiune secundară are o limită RPM de cinci mii, simple-shuffle citește acele numere și le tratează ca weights. Va ruta automat de două ori mai mult trafic către regiunea principală. În spate, routerul ia lista de deployment-uri disponibile pentru acel model, ia în calcul acele weights de RPM și le amestecă într-o listă randomizată pentru acel request specific. Încearcă primul deployment din listă. Pentru că randomizarea respectă cu strictețe limitele de RPM pe care le-ai configurat, traficul tău se distribuie perfect în toate cele cinci regiuni în timp, evitând acele rate limits fără overhead-ul unei monitorizări în timp real. Ca să setezi asta, deschizi fișierul de configurare și setezi parametrul de routing strategy pe simple-shuffle. Apoi, în lista ta de modele, îți definești cele cinci endpoint-uri Azure. Le dai tuturor exact același nume de model. În final, atașezi parametrul RPM la fiecare definiție de endpoint, cu weight-ul dorit. Când aplicația ta apelează routerul folosind acel nume de model, routerul se ocupă automat de calcule și de randomizare. Ai beneficiile unei arhitecturi distribuite fără să ai nevoie de o dependență de Redis. Cel mai bun mod de a gestiona o scalare masivă este adesea să renunți la un tracking perfect în timp real pentru o randomizare stateless, predictibilă statistic. Mersi de ascultare, happy coding tuturor!
8
Întreruperi API și Fallbacks
4m 00sNu mai suferi niciodată de downtime AI. Învață cum să configurezi model fallbacks în LiteLLM, astfel încât, dacă furnizorul principal eșuează, traficul să fie redirecționat automat către un furnizor de rezervă.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 8 din 24. Când providerul tău principal de modele de limbaj suferă un outage, aplicația ta pică odată cu el sau face un pivot silențios către un fallback? Astăzi vorbim despre API Outages și Fallbacks, mecanismul exact care îți menține sistemul online atunci când endpoint-urile externe pică.
În primul rând, ajută să distingem asta de un concept înrudit. Fallback-urile nu sunt load balancing. Load balancing-ul îți distribuie proactiv traficul pe mai multe deployment-uri active pentru a preveni suprasolicitarea unui singur endpoint. Fallback-urile, pe de altă parte, sunt salvări strict reactive. Ele stau idle în timpul funcționării normale și se activează doar după ce a avut loc un fail definitiv.
Scopul principal este menținerea unui uptime ridicat, ideal atingând acel prag de 99,9%, chiar și atunci când providerii tăi upstream nu o fac. API-urile externe vor arunca inevitabil erori 500 internal server error sau excepții 429 de rate limit. Când se întâmplă asta, o configurație de fallback îi spune proxy-ului să intercepteze eroarea mid-flight și să ruteze request-ul către un provider alternativ, protejându-ți complet codul aplicației de această întrerupere.
Setezi asta în fișierul tău YAML de configurare a proxy-ului, folosind un array de fallbacks. Ia în considerare un scenariu concret. Deployment-ul tău principal este gpt-4. Vrei să te asiguri că, dacă gpt-4 devine offline, proxy-ul va încerca automat claude-3-opus în schimb.
În fișierul tău de configurare, îți definești setup-ul modelului gpt-4 ca de obicei. În interiorul acelei definiții specifice a modelului, adaugi o cheie fallbacks. Valoarea acestei chei este pur și simplu un array de string-uri, unde fiecare string este numele unui alt model definit în configurația ta. Adaugi claude-3-opus în acest array.
Când aplicația ta trimite un prompt către proxy cerând gpt-4, LiteLLM îl rutează către endpoint-ul principal. Dacă acel endpoint returnează o eroare, logica proxy-ului o prinde. Dacă ai configurate retries, s-ar putea să încerce endpoint-ul principal de încă câteva ori. Dar odată ce principalul dă fail definitiv, proxy-ul declanșează secvența de fallback.
Aici devine interesant. Proxy-ul ia exact prompt-ul și parametrii originali. Pentru că LiteLLM normalizează formatul API, traduce seamless request-ul formatat pentru OpenAI în formatul Anthropic cerut de Claude. Trimite imediat request-ul tradus către endpoint-ul de backup. Codul aplicației tale nu trebuie să gestioneze nicio logică de eroare, să rescrie prompt-ul sau să administreze API keys pentru al doilea provider. Proxy-ul gestionează întregul pivot intern.
Nu ești limitat la un singur backup. Array-ul de fallbacks acceptă o listă de modele. Dacă gpt-4-ul tău principal dă fail, și apoi primul tău fallback claude-3-opus dă și el fail, proxy-ul trece la următorul nume din array. Parcurge lista secvențial. Dacă ajunge la sfârșitul array-ului și absolut fiecare model de backup dă fail, abia atunci proxy-ul returnează o eroare înapoi către aplicația ta client.
Aici este insight-ul cheie. Prin adăugarea mai multor layere de modele de fallback în configurația ta, îți izolezi eficient codul aplicației de instabilitatea externă, transformând outage-urile severe ale providerilor în nimic mai mult decât niște latency spikes invizibile pentru end userii tăi.
Mulțumesc pentru audiție, happy coding tuturor!
9
Context Window Fallbacks
3m 17sNu mai plăti în plus pentru context windows masive la prompturi scurte. Învață cum să folosești pre-call checks și context window fallbacks pentru a ruta documentele supradimensionate către modele specializate.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 9 din 24. Să folosești un model scump cu un context de 128k pentru fiecare query al utilizatorului este o risipă masivă de bani. Dar dacă folosești ca default un model mai ieftin și mai mic, un utilizator care face upload la un PDF masiv îți va strica imediat aplicația. Mecanismul care rezolvă această situație se numește Context Window Fallbacks.
Ai putea presupune că fallback routing-ul are loc doar după ce un API al providerului returnează un cod de eroare. Asta e valabil pentru fallback-urile generale de reliability, dar limitele de context funcționează diferit. LiteLLM poate gestiona dimensiunile de prompt în mod proactiv folosind o setare numită enable pre-call checks. Când setezi acest boolean pe true în configurația de router, proxy-ul oprește request-ul și calculează numărul exact de tokeni al promptului înainte ca providerul să-l vadă vreodată.
Iată ideea principală. Configurezi un model principal, cum ar fi un model foarte cost-effective, iar în același bloc de configurare, definești o listă de context window fallbacks care pointează către un model mult mai mare. Când vine un nou request, se execută pre-call check-ul. Dacă numărul calculat de tokeni se încadrează în limita modelului principal, request-ul continuă normal. Dacă promptul este prea mare, LiteLLM renunță complet la ruta principală. Face forward instant la request către modelul de fallback mai mare.
Asta înseamnă că nu primești niciodată o eroare de context length de la upstream API. De asemenea, înseamnă că eviți penalizarea de latency de a aștepta ca un provider să respingă payload-ul inițial. Aplicația care face request-ul habar nu are că routing-ul s-a schimbat în spate.
LiteLLM se bazează pe model registry-ul său intern pentru a ști limitele exacte de context pentru diferiți provideri. Totuși, s-ar putea să vrei să impui limite mai stricte. Poate vrei să declanșezi fallback-ul mai devreme pentru a lăsa mai mult loc pentru tokenii de output generați, sau poate faci routing către un custom deployment cu o alocare de memorie non-standard. Gestionezi asta făcând override la parametrul max input tokens direct în configurația modelului tău. Specificarea acestei valori forțează proxy-ul să folosească limita ta custom atunci când evaluează pre-call check-ul.
Gândește-te la traficul standard al unei aplicații. Un utilizator pune o întrebare simplă de tip text. Proxy-ul numără cincizeci de tokeni, validează că se încadrează și face routing către GPT-3.5. Câteva minute mai târziu, același utilizator face upload la un PDF masiv care conține optzeci de mii de tokeni. Proxy-ul calculează noua dimensiune, vede că depășește limita pentru GPT-3.5 și face redirect automat strict către GPT-4-128k. Logica aplicației tale rămâne complet statică. Plătești pentru modelul premium doar atunci când payload-ul o cere cu adevărat.
Mutarea validării de tokeni din codul aplicației în proxy layer transformă strategia ta de fallback dintr-o plasă de siguranță pasivă într-un motor activ de optimizare a costurilor.
Mulțumesc pentru audiție, happy coding tuturor!
10
Îmblânzirea cererilor blocate cu Timeouts
4m 10sNu lăsa API-urile lente să îți blocheze aplicația. Descoperă cum să configurezi global timeouts și stream timeouts în LiteLLM pentru a anula cererile blocate și a declanșa fallbacks rapide.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 10 din 24. Nu există nimic mai rău pentru experiența utilizatorului decât un chatbot care afișează un loading spinner timp de patruzeci și cinci de secunde pur și simplu pentru că un API upstream a dat hang în tăcere. Ai nevoie de o metodă sigură prin care să tai instantaneu conexiunile moarte, astfel încât sistemul tău să își poată reveni. Rezolvăm asta ținând sub control request-urile care dau hang, cu ajutorul timeout-urilor.
Când rutezi traficul către modele de limbaj externe, delay-urile de rețea și outage-urile providerilor sunt inevitabile. Dacă un provider nu mai răspunde, comportamentul default al multor clienți HTTP este să țină conexiunea deschisă pentru mult timp. LiteLLM interceptează această problemă folosind două mecanisme distincte de timeout. Primul este parametrul standard de timeout. Această setare dictează timpul total maxim pe care LiteLLM îl va aștepta pentru ca un request întreg să se finalizeze, din momentul în care este trimis până la ultimul caracter generat.
Dacă setezi un timeout standard de treizeci de secunde, iar modelul are nevoie de treizeci și una de secunde ca să scrie un răspuns lung, LiteLLM va da abort request-ului. Asta funcționează bine pentru background tasks sau pentru generările scurte, non-streaming. Totuși, aplicarea unui timeout total la o aplicație de streaming creează o problemă structurală. Un răspuns detaliat ar putea dura în mod legitim șaizeci de secunde ca să vină prin stream înapoi la utilizator. Dacă setezi un timeout total scurt pentru a prinde request-urile blocate, vei omorî accidental generări perfect sănătoase, long-running.
Aici devine interesant. LiteLLM oferă un al doilea parametru numit stream timeout. Această setare măsoară în mod specific timpul până la primul token. Controlează exact cât timp va aștepta gateway-ul pentru a primi primul chunk de date de la provider. Odată ce acea primă bucată de date ajunge, ceasul pentru stream timeout se oprește, iar conexiunea rămâne deschisă pentru restul generării.
Ia în considerare un scenariu concret. Rutezi traficul către un endpoint principal Azure OpenAI. În fișierul tău de configurare, definești blocul modelului și adaugi parametrul stream timeout, setându-l la două secunde. Un utilizator trimite un prompt complex. LiteLLM dă forward acestui request către Azure. În mod normal, serverul upstream procesează prompt-ul și returnează primul chunk într-o fracțiune de secundă. Dar în acest caz, nodul Azure respectiv dă hang.
Gateway-ul începe să numere. Trece o secundă. Trec două secunde. Primul chunk nu ajunge. Pentru că ai definit un stream timeout de două secunde, LiteLLM refuză să aștepte declanșarea timeout-ului HTTP standard. Acesta dă abort forțat conexiunii fix la pragul de două secunde.
Să dai abort request-ului mort este doar jumătate din beneficiul arhitectural. Prin forțarea unui fail rapid, LiteLLM activează imediat logica ta de fallback. În momentul în care request-ul Azure ia timeout, gateway-ul rutează din nou exact același prompt al utilizatorului către următorul nod disponibil și sănătos din lista ta de deploy. Utilizatorul experimentează un delay abia perceptibil de două secunde înainte ca textul să înceapă să facă streaming, evitând complet o interfață înghețată.
Ai flexibilitatea de a aplica aceste reguli la diferite niveluri. Poți aplica un timeout global pentru toate request-urile rutate sau le poți ajusta fin per model. Un model greu, de raționament logic, ar putea necesita un stream timeout indulgent de cinci sau zece secunde, în timp ce un model rapid de clasificare ar trebui să facă failover după doar o secundă.
Timpul de răspuns al aplicației tale este guvernat nu doar de cât de repede are succes provider-ul tău principal, ci și de cât de agresiv forțezi o conexiune blocată să dea fail. Mulțumesc pentru audiție, happy coding tuturor!
11
Virtual Keys pentru FinOps
3m 56sSecurizează-ți utilizarea API-ului cu precizie. Învață cum să generezi virtual keys folosind LiteLLM, setând limite stricte de RPM, TPM și buget pentru a-ți proteja organizația de costurile AI necontrolate.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 11 din 24. Un script scăpat de sub control scris de un junior developer poate acumula cu ușurință o factură OpenAI de zece mii de dolari peste noapte. Platforma providerului din spate continuă să accepte request-uri la fel de repede cum le poate genera loop-ul. Virtual keys pentru FinOps sunt soluția prin care poți opri asta înainte să se întâmple.
Există o confuzie frecventă între master keys și virtual keys. Nu trebuie să dai niciodată master key-ul tău unui developer. Master key-ul este credențialul tău de administrare. Scopul lui principal este să îți autentifice platforma pentru a crea virtual keys. Virtual keys sunt credențialele restricționate pe care le dai efectiv developerilor sau aplicațiilor pentru a le folosi în codul lor.
Creezi un nou credențial făcând un HTTP POST request către endpoint-ul de key generate de pe proxy-ul tău LiteLLM. Autorizezi acest request folosind master key-ul tău ca bearer token. Body-ul acestui request este locul unde definești limitele financiare.
Ia în considerare un scenariu în care dai acces unui intern de vară. Vrei să te asiguri că are suficient acces pentru a construi un prototip, dar ai nevoie de o garanție absolută că nu îți va epuiza bugetul de infrastructură. Pasezi doi parametri specifici în payload-ul tău JSON pentru a impune asta.
În primul rând, definești plafonul financiar setând parametrul max budget. Dacă setezi această valoare la zece, aloci exact zece dolari americani acestui key specific. Asta este o limită hard pe toată durata de viață. Odată ce costul total al tuturor prompt-urilor și completion-urilor legate de acest key ajunge la zece dolari, key-ul este dezactivat automat și va respinge toate request-urile ulterioare.
În al doilea rând, controlezi viteza acelor request-uri setând parametrul RPM limit. RPM vine de la requests per minute. Dacă setezi RPM limit la unu, proxy-ul impune strict un request pe o fereastră de șaizeci de secunde. Dacă un infinite loop accidental în codul internului încearcă să trimită o sută de request-uri instantaneu, proxy-ul îl procesează pe primul și le respinge imediat pe celelalte nouăzeci și nouă cu o eroare standard de rate limit.
Când trimiți acest payload către endpoint-ul de generate, LiteLLM procesează regulile și returnează un response care conține noul virtual key generat. Acest key arată identic cu un credențial standard de la provider, de obicei începând cu un prefix sk. Îi dai acest string internului.
Aici e ideea principală. Developerul folosește acest virtual key exact așa cum ar folosi un key de OpenAI sau Anthropic, direcționând client library-ul standard către URL-ul proxy-ului tău LiteLLM în loc de internetul public. Când sosește un request, proxy-ul îl interceptează. Interoghează baza sa de date internă pentru a verifica dacă acel virtual key există. Apoi verifică dacă key-ul și-a depășit bugetul de zece dolari sau limita de viteză de un request pe minut.
Dacă request-ul trece ambele verificări, proxy-ul schimbă acel virtual key cu API key-ul tău corporate real și trimite payload-ul către provider. Când providerul răspunde, proxy-ul calculează costul exact al token-urilor de prompt și completion pe baza prețurilor publicate pentru acel model specific. Deduce acea fracțiune de cent din bugetul de zece dolari al acelui virtual key, înregistrează tranzacția și trimite response-ul înapoi către developer. Developerul nu este deloc conștient de schimbul de credențiale din spate sau de contabilitatea internă.
Prin impunerea limitelor la nivelul de proxy, virtual keys interceptează request-urile neautorizate sau scăpate de sub control înainte ca ele să ajungă la providerul de facturare, garantând matematic că un script compromis sau prost scris nu își poate depăși niciodată bugetul alocat.
Mulțumesc pentru audiție, happy coding tuturor!
12
Urmărirea cheltuielilor și Custom Tags
3m 54sAtribuie cu precizie fiecare cent din cheltuielile LLM. Învață cum să transmiți metadata tags în cererile tale și să generezi rapoarte complete de cheltuieli folosind LiteLLM.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 12 din 24. Directorul financiar tocmai a intrat și te-a întrebat exact ce feature nou de produs îți consumă bugetul lunar de AI. Deschizi dashboard-ul provider-ului, dar tot ce vezi este o singură factură agregată masivă pentru întreaga companie. Nu ai niciun răspuns. Spend Tracking și Custom Tags din LiteLLM rezolvă acest blind spot.
Când rutezi request-uri prin LiteLLM, proxy-ul calculează automat costul fiecărui completion pe baza modelului specific și a numărului de tokeni. O sumă totală în dolari este inutilă dacă nu o poți atribui unei surse specifice. Cea mai simplă modalitate de a grupa aceste cheltuieli este să folosești parametrul standard user în call-ul tău de chat completion. Pasezi un string unic care reprezintă clientul tău final. LiteLLM interceptează asta, calculează costul și îl loghează pe acel user ID specific.
Tracking-ul per user rezolvă o problemă, dar adesea un singur user declanșează mai multe procese de backend. Să zicem că ai un workload de clasificare de documente, iar departamentul de billing are nevoie de un raport care grupează cheltuielile după anumite background jobs. Un user ID nu te ajută aici. Aici intervin custom tags. LiteLLM îți permite să atașezi un array de string-uri la orice request, și va face tracking la cheltuieli pe acele string-uri exacte.
Iată ideea cheie. Librăriile standard, precum SDK-ul oficial OpenAI sau LangChain, nu știu nativ de metadata din LiteLLM. Dacă încerci să pasezi un parametru nerecunoscut numit metadata, SDK-ul îi va face strip sau va arunca o eroare înainte ca request-ul să ajungă vreodată la proxy. Pentru a face bypass la asta, folosești un parametru numit extra body. Acesta este un escape hatch standard, integrat în SDK-urile moderne, special pentru a injecta custom fields.
Hai să vedem cum faci asta cu un request LangChain. Îți configurezi obiectul standard de chat model. Când apelezi metoda invoke, pasezi prompt-ul ca de obicei. Pe lângă prompt, pasezi un parametru numit extra body. Îl setezi ca fiind un dicționar. În interiorul acelui dicționar, creezi o cheie numită metadata. În interiorul metadata, adaugi o cheie numită tags, care pointează către un array de string-uri. Ai putea pasa un string de genul job ID patru zero doi. LangChain împachetează acest extra body exact așa cum e și îl trimite over the wire. LiteLLM primește payload-ul, extrage tag-urile tale din blocul de metadata și atașează costul precis al acelui call LLM la job ID patru zero doi.
Asta acoperă input-urile. Dar cum rămâne cu output-urile? Odată ce traficul tău curge cu aceste tag-uri, trebuie să extragi datele. Faci asta interogând endpoint-ul de global spend report de pe proxy-ul tău LiteLLM. Faci un request HTTP GET standard către acest endpoint. Proxy-ul returnează un payload JSON care detaliază exact unde s-au dus banii. Îți grupează cheltuielile totale per API key, per user și, foarte important, per fiecare custom tag pe care l-ai furnizat. Poți da asta direct departamentului tău de billing. Ei pot vedea instantaneu că job-ul de clasificare de documente a costat exact patru dolari și douăzeci de cenți, indiferent de modelul underlying care a gestionat rutarea efectivă.
Să faci tagging la trafic la nivel de proxy înseamnă că granularitatea de billing nu mai este dictată de modul în care provider-ul tău de cloud își structurează facturile; este definită în întregime de contextul propriei tale aplicații.
Mersi pentru audiție, happy coding tuturor!
13
Caching pentru viteză și economii
3m 41sNu mai plăti pentru aceleași răspunsuri LLM la nesfârșit. Învață cum să configurezi exact caching cu Redis și semantic caching cu Qdrant pentru a reduce drastic latența și costurile API.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 13 din 24. De ce să plătești un API extern pentru a genera exact aceeași explicație de bază de o mie de ori? Arzi credite și îi forțezi pe utilizatori să aștepte computații care au fost deja efectuate. Rezolvarea acestei ineficiențe este nucleul Caching for Speed and Savings.
LiteLLM gestionează caching-ul în întregime la nivel de proxy. Când vine un request, proxy-ul verifică dacă a mai văzut exact acest prompt înainte. Dacă da, returnează imediat răspunsul stocat. Latența scade de la secunde la milisecunde, iar costul API-ului scade la zero. Pentru a seta asta, folosești fișierul tău config dot yaml. Activezi caching-ul în blocul tău de global settings setând cache la true și specifici tipul de cache. Redis este backend-ul standard pentru exact match caching. Furnizezi host-ul, port-ul și parola Redis, iar proxy-ul se ocupă de stocarea perechilor input-output.
Dar exact caching-ul este fragil. Caută un perfect string match. Dacă un utilizator cere, scrie o poezie despre LiteLLM, iar un alt utilizator cere, creează o poezie LiteLLM, un exact cache vede două request-uri complet diferite. Trimite al doilea request către modelul de limbaj complex, pierzând timp și bani pe un task redundant doar pentru că formularea s-a schimbat puțin.
Aici intervine semantic caching-ul. În loc să compare raw text strings, semantic caching-ul compară sensul de bază al prompt-urilor. LiteLLM suportă Qdrant, un vector database, pentru a gestiona asta. Când configurezi semantic caching-ul, trebuie să specifici un embedding model alături de modelul tău principal de generare. Când sosește un request, proxy-ul trimite mai întâi prompt-ul către embedding model. Acest model convertește textul într-un vector, care este o reprezentare matematică a sensului prompt-ului.
Proxy-ul face apoi un query în Qdrant pentru a vedea dacă un vector similar există deja în cache. Pentru că scrie o poezie și creează o poezie au aceeași intenție semantică, vectorii lor se mapează foarte aproape unul de celălalt în spațiu. Qdrant detectează această similaritate. Dacă match-ul este suficient de apropiat, proxy-ul trage cached response-ul de la primul utilizator și îl livrează celui de-al doilea. Sari complet peste pasul greu de generare a textului, plătind doar o fracțiune de cent pentru acel fast embedding lookup.
Configurarea acestui lucru necesită încă câteva linii în fișierul tău config dot yaml. Schimbi tipul de cache în qdrant semantic. Definești parametri specifici Qdrant, cum ar fi URL-ul de endpoint Qdrant și API key-ul tău. Cel mai important, definești un similarity threshold. Aceasta este o valoare zecimală între zero și unu. Un threshold ridicat, cum ar fi zero virgulă nouă nouă, cere o formulare aproape identică. Un threshold mai mic, cum ar fi zero virgulă opt, prinde variații mai largi, dar crește riscul de a returna un răspuns învechit sau ușor pe lângă subiect dacă două prompt-uri sună similar, dar au intenții diferite.
Iată ideea cheie. Semantic caching-ul nu este doar un mecanism de stocare, este un filtru activ pentru intenția utilizatorului. Ajustarea acelui similarity threshold este singurul lucru care stă între o reducere masivă a costurilor și returnarea de răspunsuri irelevante către utilizatorii tăi.
Mulțumesc pentru ascultare, happy coding tuturor!
14
RBAC: Împuternicirea administratorilor de echipă
3m 15sDistribuie managementul platformei în siguranță. Înțelege Role-Based Access Control din LiteLLM, delegând puterea către Org Admins și Team Admins fără a compromite securitatea globală.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 14 din 24. Ești platform engineer și îți petreci jumătate din zi răspunzând la mesaje în care ți se cer API keys noi sau măriri de buget. Fiecare onboarding al unui developer se transformă într-un IT ticket care îi blochează munca și îți irosește timpul. Soluția este delegarea controlului fără să pierzi vizibilitatea, folosind Role-Based Access Control.
LiteLLM suportă patru roluri specifice de user pentru a gestiona această delegare. Acestea sunt proxy admin, org admin, team admin și internal user. Proxy admin-ul se află chiar în vârf. Dacă faci deploy la LiteLLM, tu ești proxy admin-ul. Tu configurezi modelele, setezi baza de date și stabilești regulile globale. Dar nu ar trebui să gestionezi cererile zilnice de API keys. Aici intervine ierarhia.
Îți poți grupa compania în organizații, care reprezintă departamente mari, și echipe, care sunt grupuri de lucru specifice în cadrul acelor departamente. Org admin-ul poate gestiona echipe în cadrul organizației sale specifice. Dar adevărata putere operațională aparține team admin-ului.
Iată ideea cheie. Poți transfera toate task-urile administrative locale unui șef de departament, făcându-l team admin. Ca proxy admin, configurezi structura inițială o singură dată. Creezi o echipă, aplici un hard budget limit de cinci sute de dolari pe lună și îl desemnezi pe lead developer ca team admin. După aceea, ieși complet din buclă.
Team admin-ul are acum autonomia de a-și gestiona propriii ingineri. Se poate loga în UI sau poate folosi API-ul pentru a adăuga noi useri în echipa sa. Poate genera API keys noi pentru acei developeri și poate monitoriza cheltuielile agregate ale grupului său specific. Partea crucială e că orice API key creat de team admin sau de inginerii lui este legat automat de acel buget de cinci sute de dolari al echipei. Team admin-ul are control local deplin, dar nu poate cheltui niciun cent peste limita impusă de proxy admin.
Sub team admin se află internal user-ul. Acesta este rolul atribuit developerilor standard care scriu codul. Un internal user are acces restricționat. Își poate vizualiza propriul token spend și, dacă team admin-ul îi permite, își poate genera propriile API keys personale. Vizibilitatea lui asupra sistemului este strict limitată la el însuși. Nu poate vedea bugetul general al echipei, nu poate vizualiza API keys care aparțin colegilor lui și, cu siguranță, nu poate modifica setările echipei.
Pentru a seta asta programatic, proxy admin-ul face un singur API request către endpoint-ul de creare a echipei. Pasezi numele echipei, parametrul de max budget și un array de user IDs etichetate cu rolul de team admin. Sistemul returnează un team ID. De atunci încolo, șeful de departament folosește acel team ID pentru a-și direcționa propriile request-uri de management, ocolind complet echipa de platform engineering.
Role-Based Access Control în LiteLLM nu se rezumă doar la ascunderea butoanelor într-un UI, ci la restricționarea fizică a token spend-ului la nivel de grup, delegând în același timp key management-ul către persoanele care conduc efectiv proiectele.
Mersi pentru audiție, happy coding tuturor!
15
Security Guardrails
3m 56sAdaugă un strat invizibil de securitate cererilor tale LLM. Învață cum să configurezi pre-call și post-call guardrails în LiteLLM pentru a bloca prompt injections și a masca PII înainte de a ajunge la furnizorii externi.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 15 din 24. Să te bazezi pe un model de limbaj că se va comporta cum trebuie nu este o strategie de securitate. Dacă un utilizator dă paste din greșeală la date sensibile ale clienților într-un prompt, este deja prea târziu să ceri modelului să le ignore politicos. Ai nevoie de un bodyguard la ușă, iar asta este exact ceea ce oferă Security Guardrails.
Security Guardrails în LiteLLM acționează ca un layer de siguranță invizibil între clienții aplicației tale și providerii de modele de limbaj. Acestea interceptează traficul de API în două faze distincte. Prima fază se numește pre call. Aceasta se execută după ce LiteLLM primește request-ul de la aplicația ta, dar fix înainte să trimită acel payload către provider-ul extern. A doua fază se numește post call, care se declanșează după ce modelul își generează răspunsul, dar înainte ca LiteLLM să trimită acel răspuns înapoi către clientul inițial.
Definești această logică de rutare în întregime în fișierul tău config dot yaml. În blocul de setări de proxy, îți definești guardrail-urile specificând un endpoint sau o integrare suportată, iar apoi îi asignezi un mod, fie pre call, fie post call.
Hai să ne uităm la un scenariu concret folosind un guardrail de tip pre call. Să presupunem că un angajat îi cere unui model hostat în cloud să rezume un tichet de suport, dar acel tichet conține numere de securitate socială din SUA. Nu vrei sub nicio formă ca acele numere să părăsească rețeaua ta internă. Poți configura Microsoft Presidio ca guardrail-ul tău pre call. Când aplicația trimite prompt-ul, LiteLLM interceptează request-ul și dă textul mai departe către Presidio. Presidio scanează textul, localizează numărul de securitate socială și îl înlocuiește cu o mască generică. LiteLLM ia apoi acest prompt sanitizat și îl trimite prin internet către provider-ul de cloud. Modelul extern generează un rezumat bazat pe textul mascat, iar codul aplicației tale funcționează ca și cum nu s-ar fi întâmplat nimic neobișnuit.
Aici este ideea de bază. Nu trebuie să aplici aceste reguli la nivel global pe tot traficul tău. LiteLLM îți permite să atașezi guardrails la nivelul specific al modelului. Acest lucru este crucial atunci când operezi o arhitectură hibridă. Îți poți configura rutarea astfel încât orice prompt trimis către un model din cloud public să treacă prin guardrail-ul strict de mascare PII. Totuși, dacă rutezi exact același prompt către un model open source care rulează pe propriul tău hardware on premises, pur și simplu lași guardrail-ul în afara blocului de configurare al acelui model. Modelul local procesează datele raw, nemascate, deoarece informația nu traversează niciodată granița rețelei tale. Eviți overhead-ul inutil de procesare și păstrezi contextul exact.
Modul post call funcționează folosind exact același flow, doar că pe drumul de întoarcere. Când modelul extern răspunde, LiteLLM trece output-ul prin guardrail-urile tale post call. Acest lucru îți permite să evaluezi textul pentru limbaj toxic, URL-uri interne halucinate sau mențiuni neautorizate ale competitorilor, înainte ca userul să îl vadă vreodată. Dacă guardrail-ul post call dă flag conținutului, LiteLLM interceptează drumul de întoarcere. Blochează textul și returnează o eroare de siguranță către client, în loc să livreze output-ul dăunător.
Gestionând asta direct la nivel de proxy, arhitectura aplicației tale rămâne complet neschimbată. Developerii tăi trimit pur și simplu completion requests standard, iar proxy-ul aplică regulile tale de compliance. Cele mai de încredere layere de securitate sunt cele la care codul aplicației tale nu trebuie să se gândească niciodată. Mulțumesc pentru audiție, happy coding tuturor!
16
Managementul dinamic al callback-urilor
4m 03sOferă microserviciilor puterea confidențialității. Învață cum să folosești header-ul x-litellm-disable-callbacks pentru a permite cererilor API sensibile să renunțe la logarea centralizată de observability.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 16 din 24.
Vrei să faci log la tot traficul LLM pentru debugging, dar ce se întâmplă când un microservice trimite date de compliance extrem de sensibile, care nu pot fi salvate sub nicio formă? Ai putea presupune că trebuie să dai disable la observability la nivel global, făcând întregul sistem orb doar pentru a proteja câteva rute de API specifice. Dynamic Callback Management rezolvă această tensiune permițându-ți să controlezi logging-ul per request.
Într-un setup LiteLLM standard, callback-urile gestionează trimiterea de request și response payloads către platforme externe de observability. Configurezi platforme precum Langfuse sau Datadog la nivel de proxy și, by default, ele capturează tot ce trece prin ele. Concepția greșită comună este că acest logging e un sistem de tipul totul sau nimic. Oamenii cred adesea că, pentru a gestiona date sensibile, trebuie să facă deploy la un proxy complet separat, cu logging-ul oprit. Dynamic Callback Management elimină această muncă suplimentară.
Ia în considerare un microservice care gestionează dosare medicale. Aplicația trebuie să proceseze simptomele pacientului printr-un language model, dar trimiterea acelor date sensibile către un logging stack third-party încalcă regulile de compliance. Pentru a preveni acest leak, microservice-ul adaugă pur și simplu un HTTP header specific la request-ul său de ieșire. Acest header se numește x-litellm-disable-callbacks. Îi setezi valoarea ca o listă separată prin virgulă cu platformele specifice pe care vrei să le dai bypass.
Pentru serviciul de dosare medicale, microservice-ul trimite header-ul cu valoarea langfuse virgulă datadog. Când proxy-ul LiteLLM primește acest request, evaluează header-ul înainte de a apela language model-ul. Prompt-ul este trimis către provider, iar response-ul este rutat înapoi către client ca de obicei. Intervenția are loc în timpul fazei de telemetrie. Proxy-ul citește disable header-ul și blochează activ trimiterea payload-ului către endpoint-urile de observability specificate, pentru acea singură tranzacție. Între timp, toate celelalte aplicații care accesează același proxy concurent, continuă să facă log la traficul lor fără nicio întrerupere.
Aici devine interesant. Să oferi clienților puterea de a-și da disable la propriile audit logs introduce un potențial risc de securitate. În medii extrem de reglementate, developerii nu ar trebui să aibă mereu autoritatea de a-și ascunde traficul. Dacă infrastructura ta necesită un audit trail strict și inalterabil pentru absolut fiecare prompt, trebuie să îl impui centralizat.
Gestionezi asta folosind compliance locking. În fișierul de configurare al proxy-ului, în blocul de setări generale, setezi un parametru numit allow dynamic callback disabling pe false. Această singură setare stabilește o politică globală strictă care face override la orice instrucțiuni client-side.
Dacă un microservice încearcă să trimită header-ul disable callbacks în timp ce acest lock este activ, proxy-ul nu ignoră header-ul în tăcere. În schimb, respinge tranzacția complet și returnează o eroare HTTP 403 Forbidden. Acest mecanism garantează că traficul fie respectă politica globală obligatorie de logging, fie primește drop înainte de a ajunge la language model.
Adevărata utilitate a Dynamic Callback Management este că mută data privacy dintr-un deployment rigid de infrastructură într-un parametru agil, la nivel de request, oferind în același timp platform engineerilor ultimul cuvânt în ceea ce privește compliance-ul.
Mulțumesc pentru ascultare, happy coding tuturor!
17
Drop-in Observability
3m 42sObține vizibilitate instantanee asupra traficului tău LLM. Învață cum să direcționezi telemetria, traces și excepțiile către instrumente precum Langfuse și Sentry folosind callback-uri simple de succes și eșec.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 17 din 24. Când un utilizator se plânge că AI-ul i-a dat un răspuns bizar acum trei zile, cum extragi exact prompt-ul care l-a cauzat? Parsarea log-urilor aplicației pentru payload-uri JSON multi-line este un coșmar. Ai nevoie de date de trace structurate, dar construirea de integrări custom pentru fiecare tool de monitorizare consumă ore de inginerie. Această problemă exactă este rezolvată de Drop-in Observability.
În loc să scrii funcții wrapper custom pentru a-ți cronometra apelurile API, a număra token-urile și a prinde timeout-urile, LiteLLM interceptează traficul nativ. Expune două hook-uri principale în setările tale: success callback-ul și failure callback-ul. Aceste callback-uri acționează ca mecanisme automate de rutare pentru telemetria ta. Ele acceptă un array de string-uri care reprezintă providerii externi de observabilitate suportați. Pur și simplu numești tool-ul pe care vrei să-l folosești, iar LiteLLM traduce datele interne de request în formatul exact pe care îl așteaptă acel tool specific.
Să luăm ca exemplu success callback-ul. Acesta se declanșează în momentul în care un language model returnează un răspuns valid. Când se întâmplă asta, LiteLLM capturează automat un snapshot al tranzacției. Acesta include input prompt-ul exact trimis către model, output-ul generat, timpul necesar pentru generare și token usage-ul precis. Pentru a trimite aceste date către un tool extern, deschizi setările LiteLLM și setezi variabila success callback la o listă care conține string-ul "langfuse". Atâta timp cât cheile tale de autentificare Langfuse sunt prezente în environment variables, sistemul se ocupă de restul. Iată ideea principală. Procesul de logging are loc asincron, în background. Thread-ul principal al aplicației tale nu se blochează niciodată în timp ce așteaptă ca provider-ul de observabilitate să confirme trace-ul. Utilizatorii tăi experimentează zero latență adăugată.
Asta rezolvă happy path-ul. Pentru erori, folosești failure callback-ul. Acesta se declanșează atunci când un API call dă timeout, atinge un rate limit al provider-ului sau eșuează complet. Fără un tracing corect, o eroare de LLM apare adesea ca un status code opac. Prin setarea variabilei failure callback la o listă care conține string-ul "sentry", mapezi excepțiile LLM direct la workflow-ul tău existent de error tracking. Când un request eșuează, LiteLLM împachetează tipul de exception, numele modelului și input-ul încercat, apoi trimite acel context direct în Sentry.
Pentru a seta asta în codul tău, nu trebuie să modifici apelurile API efective. Modifici doar configurația globală. Atribui tool-urile alese array-urilor de callback o singură dată, în timpul startup-ului aplicației. Din acel moment înainte, fiecare completion call pe care îl faci este monitorizat. Logica ta de bază rămâne complet decuplată de infrastructura de logging. Dacă decizi să schimbi Langfuse cu un alt provider luna viitoare, modifici un singur string dintr-un array.
Adevărata putere a callback-urilor drop-in nu constă doar în evitarea codului boilerplate. Este standardizarea formei telemetriei tale pentru zeci de provideri LLM diferiți, astfel încât platforma ta de monitorizare să vadă exact un singur format consistent, indiferent de modelul subiacent care a răspuns la prompt.
Mulțumesc pentru ascultare, happy coding tuturor!
18
Metrici Prometheus și sănătatea Pod-urilor
3m 45sIa pulsul proxy-ului tău. Descoperă cum să expui endpoint-ul /metrics către Prometheus, să urmărești cererile in-flight și să folosești custom tags pentru a segmenta datele în Grafana.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 18 din 24. Dacă un request LLM durează zece secunde, providerul de AI este lent sau event loop-ul proxy-ului tău este complet blocat? Nu poți repara un bottleneck până nu știi exact unde se află. Prometheus Metrics și Pod Health din LiteLLM îți oferă exact această vizibilitate.
LiteLLM expune un endpoint standard de metrics la calea slash metrics. O greșeală comună când monitorizezi gateway-uri AI este să tratezi toate întârzierile de răspuns ca latency din partea providerului LLM. Asta este incorect. Există două perioade distincte de așteptare. În primul rând, există queue latency-ul pre-ASGI. Acesta este timpul pe care un request îl petrece așteptând în interiorul infrastructurii tale înainte ca proxy-ul măcar să înceapă să îl proceseze. În al doilea rând, există latency-ul LLM propriu-zis, care este timpul petrecut așteptând ca OpenAI, Anthropic sau un alt provider să returneze tokens. Endpoint-ul de metrics separă aceste numere, astfel încât să știi exact pe cine să dai vina pentru un răspuns lent.
Pentru a-ți monitoriza pod health-ul, te bazezi pe un gauge specific numit litellm in flight requests. Această metrică urmărește numărul exact de concurrent requests procesate activ de un pod în orice milisecundă. Aceasta este o măsurătoare în timp real a queue depth-ului. Când traficul are un spike, acest număr crește.
Ia în considerare un scenariu concret. Dashboard-ul tău de monitorizare arată un spike masiv în durata totală a request-urilor. Utilizatorii se plâng de răspunsuri lente. Dacă te uiți doar la timpul total, ai putea presupune că OpenAI are un outage. Dar când verifici endpoint-ul de metrics, latency-ul providerului este stabil la două secunde. Iată informația cheie. Te uiți la litellm in flight requests și vezi că a explodat de la douăzeci la două sute. Asta dovedește că întârzierea nu este de la OpenAI. Queue-ul pod-ului tău este complet supraîncărcat. Înarmat cu acest gauge exact, îți poți configura infrastructura să declanșeze un eveniment de auto-scale în momentul în care in-flight requests depășesc un anumit threshold, pornind noi proxy pods înainte ca event loop-ul să se blocheze.
De asemenea, trebuie să știi cine generează acest trafic. LiteLLM suportă custom Prometheus tags. Când un request ajunge la gateway, poți transmite custom metadata în request payload, cum ar fi un project ID, un departament sau un nume de aplicație. LiteLLM extrage aceste custom tags și le atașează ca labels la Prometheus metrics. În loc să vezi doar că gateway-ul a procesat zece mii de tokens, vezi că aplicația de marketing a procesat șapte mii de tokens, iar dashboard-ul de analytics a procesat trei mii. Asta oferă echipei DevOps posibilitatea de a grupa token usage-ul, queue depth-ul și latency-ul în funcție de anumiți tenants.
Cel mai important aspect pentru performanța gateway-ului este acesta. Nu face niciodată auto-scale la proxy-ul tău AI pe baza total response latency, deoarece vei irosi bani făcând scale up atunci când providerul extern este pur și simplu lent; fă scale pe baza gauge-ului tău de in-flight requests pentru a reacționa doar atunci când propriul tău infrastructure queue este de fapt plin.
Mulțumesc pentru audiție, happy coding tuturor!
19
Text-to-Speech Universal
4m 12sStandardizează-ți generarea vocală. Descoperă cum să apelezi modele Text-to-Speech de la Gemini, Vertex și AWS Polly folosind exact același format de endpoint audio compatibil cu OpenAI.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 19 din 24. Vrei să adaugi generare de voce în aplicația ta, dar să scrii cod de integrare custom pentru formatul audio al fiecărui provider necesită mentenanță constantă. De fiecare dată când treci de la un model de voce OpenAI la un model de voce Google, câmpurile JSON necesare, path-urile API și return type-urile audio se schimbă complet. Mecanismul care rezolvă această problemă este Universal Text-to-Speech folosind bridge-ul audio-speech LiteLLM.
În loc să întreții clienți API separați pentru OpenAI, Vertex AI și Gemini, îți standardizezi aplicația pe un singur format. LiteLLM expune un endpoint unificat care imită exact route-ul audio-speech standard de la OpenAI. Construiești un request care conține textul tău, numele modelului ales și o preferință de voce, trimițându-l către LiteLLM ca și cum ai vorbi direct cu OpenAI. Gateway-ul traduce apoi acest payload standardizat în formatul specific cerut de provider-ul target.
Aici este ideea cheie. Mulți provideri de AI nu oferă un API de text-to-speech dedicat și simplu, care să facă stream la fișiere audio out of the box. În funcție de provider, accesarea nativă a unui model de voce necesită adesea rutarea request-ului printr-un endpoint generic de text completion. Este posibil să trebuiască să transmiți flag-uri de configurare foarte specifice, să trimiți un system prompt complex și apoi să extragi string-uri audio encodate base64, nested adânc într-un response JSON. LiteLLM abstractizează tot acest layer de traducere. Gestionează negocierea API, despachetează structura proprietară a response-ului și izolează datele audio efective.
Ia în considerare un scenariu concret. Decizi să generezi audio vorbit folosind modelul preview Gemini Flash TTS de la Google. În codul aplicației tale, îndrepți clientul HTTP standard către URL-ul de proxy LiteLLM, la path-ul audio-speech. Setezi parametrul model să indice către modelul Gemini Flash TTS. Atribui plain text-ul tău parametrului input și specifici un identificator de voce valid.
Când execuți request-ul, LiteLLM interceptează payload-ul. Se autentifică în siguranță cu Google Cloud sau Vertex AI, în funcție de setup-ul tău. Reîmpachetează plain text-ul și selecția de voce în schema JSON specifică cerută de API-ul Google. Când modelul Google procesează textul și returnează rezultatul, LiteLLM interceptează response-ul proprietar. În loc să forțeze aplicația client să facă parse la un payload custom Google Cloud, LiteLLM extrage byte-ii audio raw. Face bridge perfect la transport layer, trimițând imediat ca stream un fișier MP3 standard înapoi către clientul tău. Aplicația ta de frontend sau backend primește un audio stream standard, fără să știe deloc că generarea din spate a fost făcută de Google în loc de OpenAI.
Această logică de bridge înseamnă că scrii integrarea de client text-to-speech exact o singură dată. Dacă un model audio nou, mai rapid, este lansat de Vertex mâine, trebuie doar să modifici string-ul modelului din request-ul tău. Codul aplicației care gestionează stream-ul MP3 rămâne complet neatins. Tratarea generării audio exact în același mod în care tratezi generarea de text îți permite să standardizezi logica aplicației. Prin forțarea tuturor request-urilor de text-to-speech printr-o singură interfață unificată, poți să rutezi, să faci load-balance și să setezi failover-uri pentru generarea ta audio pe provideri complet diferiți, fără să scrii măcar o linie de fallback code specific provider-ului. Mulțumesc pentru audiție, happy coding tuturor!
20
Puntea Assistants API
3m 59sGestionează starea conversației fără efort între furnizori. Învață cum LiteLLM încapsulează modelele non-native în interfața standard OpenAI Assistants API, permițându-ți să folosești Threads și Messages peste tot.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 20 din 24. OpenAI gestionează perfect starea conversației, păstrând codul tău de client complet stateless. Dar blocarea arhitecturii tale într-un singur provider doar pentru a păstra acel state management este un preț mare de plătit. Assistants API Bridge din LiteLLM rezolvă această problemă.
Bridge-ul este un feature al proxy-ului LiteLLM care expune exact endpoint-urile din OpenAI Assistants API. Accesezi path-uri standard, cum ar fi endpoint-urile v one assistants și v one threads, dar rutezi generarea propriu-zisă de text către orice model vrei tu.
Interfețele standard de chat completion sunt stateless. De fiecare dată când pui o întrebare, clientul tău trebuie să trimită întregul istoric al conversației înapoi la server. Asta consumă bandwidth și îți complică codul client-side. Assistants API rezolvă asta păstrând istoricul conversației pe server, în interiorul unui obiect Thread. Trebuie doar să adaugi mesaje noi la thread și să-i spui serverului să ruleze asistentul. Problema este că majoritatea celorlalți provideri, de la setup-uri locale la alternative cloud enterprise, nu oferă nativ această interfață stateful.
Bridge-ul LiteLLM face polyfill pentru această funcționalitate lipsă. Ca să funcționeze, configurezi proxy-ul LiteLLM să se conecteze la o bază de date. Această bază de date va acționa ca storage layer pentru state-ul conversației tale. Apoi, direcționezi clientul tău OpenAI existent către URL-ul proxy-ului LiteLLM, în loc de serverele OpenAI default.
Flow-ul logic începe cu crearea unui asistent. Trimiți un request către proxy, definind instrucțiunile asistentului și specificând un model target. Acesta ar putea fi un deployment Azure OpenAI sau un model Astra compatibil cu OpenAI. Proxy-ul salvează această configurație în baza sa de date.
Apoi, creezi un thread. Un thread este pur și simplu un container gol stocat de proxy. Când un user spune ceva, trimiți un request pentru a adăuga un mesaj la acel thread specific. Proxy-ul salvează mesajul. Până în acest moment, Large Language Model-ul underlying nu a fost contactat deloc.
Aici este ideea esențială. Bridge-ul comunică cu modelul tău target doar atunci când declanșezi un run. Când îi spui proxy-ului să ruleze asistentul pe un anumit thread, LiteLLM preia întregul istoric al mesajelor din baza sa de date. Formatează acel istoric într-un payload standard și stateless de chat completion. Apoi trimite acel payload flat către modelul underlying pe care l-ai configurat anterior.
Modelul evaluează conversația și returnează un răspuns către proxy. LiteLLM ia acel text, îl împachetează ca un nou mesaj de la asistent, îl salvează în baza de date a thread-urilor și actualizează statusul run-ului la completed. Clientul tău face poll la proxy, vede statusul completed și face fetch la cel mai recent mesaj exact așa cum ar face-o în mod normal.
Codul aplicației tale rămâne complet neschimbat. Încă are impresia că vorbește cu un sistem nativ stateful. Proxy-ul gestionează traducerea în mod transparent, preluând un request stateful de la client, executând un call stateless către model și menținând persistence layer-ul între ele.
Acest separation of concerns înseamnă că arhitectura ta de client se poate baza pe o interfață API modernă, state-managed, în timp ce infrastructura ta rămâne complet liberă să schimbe modelele underlying în funcție de cost, privacy sau cerințe de performanță.
Mulțumesc pentru audiție, happy coding tuturor!
21
MCP Gateway
4m 27sÎmbunătățește-ți modelele cu instrumente în mod centralizat. Descoperă cum să configurezi servere Model Context Protocol (MCP) prin HTTP, SSE sau STDIO în LiteLLM, oferind oricărui LLM acces la capabilități externe.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 21 din 24. Ai un model Llama open-source care rulează local, dar vrei să declanșeze acțiuni sau să citească fișiere folosind exact aceleași integrări GitHub pe care le folosește agentul tău Claude Code. Nu vrei să rescrii logica aplicației pentru a suporta un nou toolset pentru fiecare model nou. MCP Gateway rezolvă asta.
Mai întâi, să separăm MCP de A2A, sau rutarea Agent-to-Agent. O confuzie frecventă e să le tratăm ca fiind același lucru. A2A e atunci când rutezi un user prompt către un agent extern specializat pentru a genera un răspuns text. MCP e complet diferit. MCP vine de la Model Context Protocol și se referă la furnizarea unui set standardizat de tools către un model, lăsând acel model să decidă când și cum să le invoce pentru a finaliza un task.
Funcția MCP Gateway permite proxy-ului LiteLLM să acționeze ca o punte între orice model de limbaj și serverele tale MCP. În loc să scrii cod pentru a înregistra tools în fiecare aplicație client pe care o construiești, le definești central în proxy. Din acel moment, orice model care accesează proxy-ul poate utiliza acele tools.
LiteLLM se conectează la serverele MCP folosind două metode principale. Prima e STDIO, sau Standard Input and Output. Asta e folosită pentru tools locale. Configurezi proxy-ul să execute o comandă locală specifică, cum ar fi rularea unui script Node sau a unui fișier Python, direct pe mașina host. A doua metodă e HTTP cu Server-Sent Events, sau SSE. Asta e folosită pentru a te conecta la servere MCP remote, prin rețea.
Hai să ne uităm la un scenariu concret. Vrei să adaugi un server Zapier MCP remote, astfel încât modelele tale să poată interacționa cu aplicații web externe. Faci asta în întregime în fișierul YAML de configurare a proxy-ului. Sub blocul principal de configurare, adaugi o secțiune de servere MCP. Denumești integrarea, de exemplu, zapier-integration. Definești tipul de transport ca SSE. Apoi, furnizezi endpoint URL-ul serverului tău Zapier MCP. Pentru că asta e o conexiune remote, vei specifica și acele headers de autentificare necesare, cum ar fi un bearer token, direct în interiorul acestei definiții YAML.
Acum proxy-ul știe cum să comunice cu Zapier. Următorul pas e execuția. Când aplicația ta client trimite un chat completion request standard către LiteLLM, trebuie doar să includă un header specific care să indice ce tools MCP vrea să încarce.
Aici e ideea principală. Aplicația client nu trebuie să știe ce tools oferă de fapt Zapier. Proxy-ul interceptează request-ul clientului, contactează serverul Zapier MCP prin conexiunea SSE și preia dinamic lista curentă de tools disponibile. Proxy-ul injectează apoi acele tool definitions în payload și transmite întregul pachet către modelul de limbaj.
Dacă modelul de limbaj decide să invoce un tool Zapier, trimite un tool call înapoi către proxy. Proxy-ul îl prinde, execută acțiunea pe serverul Zapier MCP, obține rezultatul și îl trimite înapoi modelului. Aplicația ta client este complet protejată de această negociere dus-întors. Primește doar tool responses standard, compatibile cu OpenAI.
Adevărata putere a MCP Gateway constă în decuplarea implementării de tools de alegerea modelului, ceea ce înseamnă că o integrare construită pentru un singur ecosistem funcționează instantaneu pe zeci de modele diferite, fără a scrie adapter code personalizat.
Mulțumesc pentru audiție, spor la codat tuturor!
22
A2A: Urmărirea agenților autonomi
3m 25sAdu agenții autonomi sub control. Învață cum să invoci agenți complecși LangGraph sau Bedrock prin proxy folosind protocolul A2A, permițând gruparea trace-urilor și urmărirea unificată a cheltuielilor.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 22 din 24.
Când agentul tău autonom intră într-un reasoning loop de cincizeci de pași, cum urmărești factura până la request-ul inițial? Dacă agentul face zeci de call-uri izolate către diferite language models, log-urile tale de facturare devin o harababură ilizibilă de request-uri deconectate. Soluția pentru asta este LiteLLM Agent Gateway, cunoscut și sub numele de protocolul A2A.
Înainte să explorăm mecanismele, ar trebui să clarificăm o confuzie comună. Ascultătorii confundă adesea asta cu Model Context Protocol, sau MCP. MCP este folosit pentru a oferi tool-uri externe unui language model. A2A face exact opusul. Tratează un agent extern, autonom, ca și cum ar fi un language model standard, permițându-ți să îl invoci și să îl urmărești printr-un gateway centralizat.
Pentru a seta asta, îți definești agentul în fișierul de configurare LiteLLM exact așa cum ai defini un language model standard. Îi dai modelului un nume, setezi base URL-ul care indică spre API endpoint-ul agentului tău și specifici provider-ul ca un endpoint OpenAI custom. Acum, LiteLLM știe cum să ruteze request-urile primite de la clienți direct către agentul tău.
Când un client trimite un request pentru acest agent, LiteLLM acționează ca un pass-through pentru headerele de context. Preia metadatele legate de request, cum ar fi identificatorii de user, tag-urile de rutare ale echipei și limitele de buget, și le împachetează în headere HTTP specifice. Cel mai important dintre acestea este headerul X-LiteLLM-Trace-Id. LiteLLM trimite aceste headere împreună cu prompt-ul către agentul tău.
Aici este ideea cheie. Agentul tău primește acest request, își pornește bucla autonomă și începe să facă propriile call-uri interne pentru a procesa task-ul. Dacă agentul face aceste call-uri direct către un provider public, pierzi contextul de tracking. În schimb, agentul trebuie să își ruteze call-urile interne înapoi prin LiteLLM. Când face asta, trebuie să includă trace ID-ul pe care l-a primit în request-ul inițial.
Ia în considerare un scenariu concret. Invoci un agent LangGraph local. Un client trimite un prompt prin LiteLLM pentru a începe procesul. LiteLLM atribuie un trace ID unic și trimite payload-ul către endpoint-ul LangGraph. Aplicația ta LangGraph citește headerele HTTP primite și extrage X-LiteLLM-Trace-Id. Când LangGraph trebuie să evalueze un pas sau să rezume date, folosește clientul său intern pentru a trimite un completion call înapoi către LiteLLM. Partea crucială este că atașează exact același header de trace ID la request-ul său de ieșire.
Pentru că fiecare call intern poartă același trace identifier, LiteLLM le grupează automat. Când te uiți la platforma ta de observability sau la log-urile de buget, nu vezi cincizeci de request-uri random din surse necunoscute. Vezi un singur trace unificat. Știi exact care user a declanșat agentul, cât a costat întregul reasoning loop și care pași autonomi specifici au consumat cel mai mult buget.
Tratarea agenților ca model endpoints standard transformă workflow-urile complexe de agenți multi-step în unități de compute trackable și billable.
Mulțumesc pentru ascultare, happy coding tuturor!
23
Rotații de chei cu Zero-Downtime
3m 42sObține tranziții de securitate cu zero-downtime. Învață cum să configurezi rotații automate programate ale cheilor și grace periods pentru virtual keys de nivel enterprise în LiteLLM.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 23 din 24. Rotația cheilor API în producție înseamnă de obicei downtime programat, coordonare frenetică și speranța că niciun sistem de backend nu rămâne în urmă cu un credential invalid. Un hard cutover este o măsură strictă de securitate, dar este și o metodă extrem de sigură de a întrerupe request-urile in-flight. Soluția la această problemă este Zero-Downtime Key Rotations.
Într-un setup de proxy enterprise, păstrarea cheilor virtuale statice pentru totdeauna este un risc de securitate inacceptabil. LiteLLM gestionează asta permițându-ți să programezi rotații automate ale cheilor. În loc să generezi manual noi credențiale și să coordonezi un moment exact pentru a le schimba, lași proxy-ul să se ocupe de lifecycle. Dar simpla automatizare a creării unei noi chei nu rezolvă problema fundamentală de fiabilitate. Dacă gateway-ul respinge imediat vechea cheie în secunda în care este creată una nouă, orice serviciu care nu a sincronizat încă noul credential va da fail instantaneu.
Pentru a repara asta, LiteLLM folosește un grace period. Când creezi sau actualizezi o cheie virtuală, configurezi doi parametri specifici. În primul rând, setezi intervalul de auto rotate, care definește exact cât de des ar trebui să fie generată o cheie nouă. În al doilea rând, definești grace period-ul, care îi spune sistemului cât timp ar trebui să rămână validă cheia veche după ce are loc rotația.
Ia în considerare o arhitectură standard de microservicii în care politica ta de securitate cere rotația cheilor de acces LLM la fiecare treizeci de zile. Faci un request către endpoint-ul de generare a cheilor din LiteLLM. În acel request, setezi parametrul auto rotate la 30 de zile. În exact același request, setezi parametrul grace period la 24 de ore. Proxy-ul stochează această politică și pornește cronometrul.
La pragul de treizeci de zile, rotația se declanșează. LiteLLM generează automat o cheie virtuală complet nouă. Asta e partea care contează. Pentru următoarele 24 de ore, ai două chei complet valide care pointează către exact aceeași configurație, buget și logică de tracking.
În timpul acestei ferestre de overlap, secrets manager-ul tău face fetch la noua cheie și o injectează treptat în mediul tău de producție. Pe măsură ce containerele primesc restart sau configmap-urile se actualizează, serviciile trec independent la noul credential. Dacă un anumit background worker folosește încă vechea cheie la douăsprezece ore în interiorul grace period-ului, LiteLLM acceptă request-ul fără probleme. Gateway-ul rutează traficul către Large Language Model și loghează tranzacția în mod normal.
Odată ce grace period-ul exact de 24 de ore expiră, LiteLLM invalidează automat cheia originală. Orice sistem rămas care încă încearcă să folosească vechiul credential va primi o eroare de autentificare. Migrarea este completă.
Ai decuplat complet crearea noului secret de distrugerea celui vechi. Separarea acestor două evenimente transformă rotația cheilor dintr-o panică de infrastructură fragilă și extrem de coordonată, într-o rutină de background silențioasă și fiabilă.
Mulțumesc pentru audiție, spor la codat tuturor!
24
Admin UI și AI Hub
3m 44sFă-ți platforma AI accesibilă tuturor. Învață cum să gestionezi Admin UI, să ajustezi credențialele UI și să folosești AI Hub pentru a permite dezvoltatorilor să descopere în siguranță modelele și agenții permiși.
Salut, sunt Alex de la DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodul 24 din 24. Echipa ta de platformă a construit un gateway LLM extrem de securizat, perfect rutat. Dar când developerii interni chiar trebuie să construiască ceva, de unde știu ce modele și agenți au voie să folosească? Fără un mecanism de discovery, gateway-ul tău este o cutie neagră invizibilă. Această vizibilitate este oferită de Admin UI și de AI Hub.
Admin UI este un dashboard vizual construit direct în proxy-ul LiteLLM. Operarea unui gateway LLM exclusiv prin fișiere de configurare și query-uri în baza de date scalează greu atunci când mai multe echipe încep să ceară acces. Admin UI oferă operatorilor de platformă un loc centralizat pentru a gestiona proxy-ul. Prin această interfață, poți genera API keys noi, poți urmări consumul de tokeni pentru diferite echipe, poți monitoriza request logs live și poți configura reguli de rutare pentru modele.
Când lansezi pentru prima dată proxy-ul LiteLLM, acest dashboard este activat by default și securizat cu credențiale de login default. Pentru testare locală, asta e convenabil. Pentru producție, este o vulnerabilitate. Trebuie să schimbi imediat aceste credențiale default. Faci asta setând environment variables specifice pentru username-ul și parola de admin, înainte să pornești containerul.
Aici e partea importantă. S-ar putea să nu vrei deloc un dashboard grafic expus pe gateway-ul tău de producție. Multe echipe de platformă provizionează infrastructura strict prin scripturi automate și nu vor un control plane interactiv accesibil din rețea. Dacă asta se potrivește cu modelul tău de securitate, poți dezactiva complet dashboard-ul. Setând o environment variable numită disable admin ui pe true, elimini complet interfața. Proxy-ul va continua să ruteze traficul și să aplice regulile, dar web serverul nu va servi ecranele de administrare.
Asta îi acoperă pe operatorii de platformă, dar inginerii care consumă API-ul au nevoie de o perspectivă diferită. Aici intervine AI Hub. În timp ce Admin UI este pentru control, AI Hub este pentru discovery. Acționează ca un developer portal intern pentru organizația ta.
În loc să dea mesaje echipei de platformă ca să întrebe ce modele sunt aprobate în prezent sau unde se află documentația pentru un agent intern, developerii vizitează AI Hub. Se autentifică, de obicei prin providerul de single sign-on al organizației tale, și li se prezintă un catalog. Pot vedea exact ce modele sunt autorizați să apeleze, pot verifica rate limits aplicate acelor modele și pot descoperi agenți preconfigurați construiți de alte echipe.
Mai important, AI Hub le permite developerilor să facă self-serve. Își pot genera propriile API keys legate de bugetele specifice echipei lor, fără să aștepte ca un inginer de platformă să le facă provision manual. Asta schimbă fundamental modul în care organizația ta interacționează cu AI-ul generativ. Elimină decalajul dintre inginerii de infrastructură care securizează gateway-ul și inginerii de produs care construiesc aplicațiile.
Gateway-ul este util doar în măsura în care este accesibil, iar AI Hub transformă un proxy blocat într-o platformă self-serve, permițând echipelor tale de inginerie să se miște rapid fără să îți distrugă bugetul. Asta încheie seria noastră despre LiteLLM. Te încurajez să explorezi documentația oficială, să încerci aceste configurări hands-on și să vizitezi dev stories dot eu pentru a sugera subiecte pentru seriile viitoare. Mulțumesc că ai ascultat, happy coding tuturor!