Torna al catalogo
LiteLLM: The Universal LLM Gateway (v1.82 - 2026 Edition)
Una serie di podcast completa dedicata a LiteLLM, dal Python SDK e la gestione unificata delle eccezioni fino al Proxy Server, load balancing, virtual keys, observability e funzionalità enterprise come RBAC e MCP Gateway.
In Riproduzione
Click play to start
0:00
0:00
1
La Stele di Rosetta degli LLM: Il Python SDK
Scopri l'identità principale di LiteLLM: un'interfaccia Python unificata per oltre 100 LLM. Impara a integrare LiteLLM nella tua codebase esistente per chiamare Anthropic, Vertex o Ollama senza modificare la tua logica di parsing compatibile con OpenAI.
2
La magia della traduzione dei parametri
Smetti di preoccuparti di quale provider supporti quale iperparametro. Scopri come l'SDK di LiteLLM traduce automaticamente gli input standard di OpenAI come temperature, tools e max_tokens per tutti i modelli upstream.
3
Gestione Unificata delle Eccezioni
Scrivi i tuoi blocchi try-except una sola volta. Scopri come LiteLLM cattura gli errori personalizzati di AWS, Google e Azure, mappandoli perfettamente sulle eccezioni standard di OpenAI come RateLimitError.
4
L'LLM Gateway: Configurare il Proxy Server
Porta LiteLLM fuori dal tuo codice locale e in una piattaforma centralizzata. Impara ad avviare il Proxy Server di LiteLLM tramite Docker e a configurare i tuoi primi endpoint utilizzando il file config.yaml.
5
Gestione Centralizzata dei Secret
Tieni le tue API keys fuori dalle configurazioni in chiaro. Scopri come connettere LiteLLM a secret manager enterprise come AWS Secrets Manager o Azure Key Vault per recuperare dinamicamente le credenziali.
6
Model Aliases: L'aggiornamento ombra
Migra gli utenti verso nuovi modelli in modo silenzioso. Scopri come utilizzare i Model Aliases in LiteLLM per mappare le richieste di un modello verso un endpoint completamente diverso senza alterare alcun codice lato client.
7
Load Balancing per un High Throughput
Evita rate limit e downtime instradando il traffico in modo intelligente. Esplora perché simple-shuffle è la strategia consigliata per il load balancing in produzione su più deployment.
8
Disservizi API e Fallback
Non subire mai più un downtime dell'IA. Scopri come configurare i model fallbacks in LiteLLM in modo che, se il tuo provider principale fallisce, il traffico venga reindirizzato automaticamente verso un provider di backup.
9
Context Window Fallbacks
Smetti di pagare troppo per context windows enormi su prompt brevi. Scopri come utilizzare i controlli pre-call e i context window fallbacks per instradare documenti sovradimensionati verso modelli specializzati.
10
Domare le richieste in sospeso con i Timeout
Non lasciare che API lente blocchino la tua applicazione. Scopri come configurare i global timeouts e gli stream timeouts in LiteLLM per interrompere le richieste in stallo e attivare fallback rapidi.
11
Virtual Keys per la FinOps
Metti al sicuro l'utilizzo delle tue API con precisione. Scopri come generare virtual keys utilizzando LiteLLM, impostando limiti rigorosi di RPM, TPM e budget per proteggere la tua organizzazione da costi IA fuori controllo.
12
Spend Tracking e Custom Tags
Attribuisci ogni centesimo di spesa LLM in modo accurato. Scopri come passare i metadata tags nelle tue richieste e generare report di spesa completi utilizzando LiteLLM.
13
Caching per Velocità e Risparmio
Smetti di pagare ripetutamente per le stesse risposte dell'LLM. Scopri come configurare l'exact caching con Redis e il semantic caching con Qdrant per abbattere la latenza e i costi delle API.
14
RBAC: Responsabilizzare i Team Admins
Distribuisci la gestione della piattaforma in modo sicuro. Comprendi il Role-Based Access Control (RBAC) di LiteLLM, delegando il potere agli Org Admins e ai Team Admins senza compromettere la sicurezza globale.
15
Security Guardrails
Aggiungi un livello di sicurezza invisibile alle tue richieste LLM. Scopri come configurare i pre-call e post-call guardrails in LiteLLM per bloccare le prompt injections e mascherare le PII prima che raggiungano i provider esterni.
16
Gestione Dinamica delle Callback
Dai ai microservizi il potere della privacy. Scopri come utilizzare l'header x-litellm-disable-callbacks per consentire alle richieste API sensibili di escludersi dal logging centralizzato di observability.
17
Drop-in Observability
Ottieni visibilità istantanea sul tuo traffico LLM. Scopri come convogliare telemetry, traces ed eccezioni verso strumenti come Langfuse e Sentry utilizzando semplici callback di successo e fallimento.
18
Metriche Prometheus e Pod Health
Tasta il polso al tuo proxy. Scopri come esporre l'endpoint /metrics a Prometheus, tracciare le in-flight requests e utilizzare custom tags per analizzare i dati in Grafana.
19
Text-to-Speech Universale
Standardizza la generazione vocale. Scopri come chiamare i modelli Text-to-Speech di Gemini, Vertex e AWS Polly utilizzando l'esatto stesso formato di endpoint audio compatibile con OpenAI.
20
Il Bridge per l'Assistants API
Gestisci lo stato delle conversazioni senza sforzo tra i vari provider. Scopri come LiteLLM avvolge i modelli non nativi nell'interfaccia standard dell'Assistants API di OpenAI, permettendoti di utilizzare Threads e Messages ovunque.
21
L'MCP Gateway
Potenzia i tuoi modelli con i tools in modo centralizzato. Scopri come configurare i server Model Context Protocol (MCP) HTTP, SSE o STDIO in LiteLLM, dando a qualsiasi LLM accesso a funzionalità esterne.
22
A2A: Tracciare gli Autonomous Agents
Metti sotto controllo gli autonomous agents. Scopri come invocare agenti complessi di LangGraph o Bedrock attraverso il proxy utilizzando il protocollo A2A, abilitando il trace grouping e lo spend tracking unificato.
23
Key Rotations con Zero-Downtime
Ottieni transizioni di sicurezza con zero-downtime. Scopri come configurare key rotations automatiche programmate e grace periods per le virtual keys di livello enterprise in LiteLLM.
24
L'Admin UI e l'AI Hub
Rendi la tua piattaforma IA accessibile a tutti. Scopri come gestire l'Admin UI, modificare le credenziali della UI e utilizzare l'AI Hub per consentire agli sviluppatori di scoprire in modo sicuro i modelli e gli agenti consentiti.
Episodi
1
La Stele di Rosetta degli LLM: Il Python SDK
4m 14sScopri l'identità principale di LiteLLM: un'interfaccia Python unificata per oltre 100 LLM. Impara a integrare LiteLLM nella tua codebase esistente per chiamare Anthropic, Vertex o Ollama senza modificare la tua logica di parsing compatibile con OpenAI.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: il gateway LLM universale, episodio 1 di 24. Sostituisci la tua API key di OpenAI con una di Anthropic e improvvisamente l'intera applicazione va in crash. Ogni provider struttura i propri input e output in modo diverso, costringendoti a scrivere e mantenere una logica di parsing personalizzata per ogni nuovo modello. La Stele di Rosetta degli LLM, il Python SDK di LiteLLM, risolve completamente questo problema.
C'è un equivoco comune secondo cui LiteLLM sia in competizione con LangChain. Non è così. LiteLLM non è un agent framework. Non orchestra tool, non gestisce la memoria e non fa chaining di task. È semplicemente un drop-in replacement per il client OpenAI.
Il Python SDK di LiteLLM traduce oltre cento diverse API di provider nell'esatto formato di chat completion di OpenAI. Non devi imparare le sfumature specifiche delle API di Vertex AI, Anthropic o Hugging Face. Scrivi il tuo codice una sola volta usando lo standard OpenAI, e LiteLLM gestisce il layer di traduzione in background.
Il cuore di questo SDK è un'unica interfaccia unificata chiamata funzione di completion. Quando usi questa funzione, fornisci una stringa per il modello. Questa stringa indica a LiteLLM quale provider contattare. Passi anche i parametri standard di OpenAI come temperature, max tokens e la lista messages. LiteLLM prende questi parametri standard e li mappa sui campi corretti per il provider di destinazione.
Considera uno scenario in cui vuoi chiamare Claude 3.5 Sonnet. Usando l'SDK standard di Anthropic, dovresti strutturare i tuoi blocchi di prompt in base ai requisiti specifici della loro Messages API. Con LiteLLM, ti basta chiamare la funzione di completion. Passi il nome del modello per Claude. Passi il tuo array messages standard, usando dizionari con i ruoli user e system. Infine, fornisci la tua API key di Anthropic, come parametro o come variabile d'ambiente.
Ecco il punto chiave. Il response object restituito da questa funzione è strutturato esattamente come un oggetto chat completion di OpenAI.
Quando vuoi estrarre il testo generato da Claude, percorri esattamente lo stesso percorso che seguiresti per un modello GPT. Esamini l'array choices. Prendi il primo elemento. Accedi all'oggetto message. Leggi la proprietà content. La logica della tua applicazione non ha idea che sia stato Anthropic a generare il testo. La richiesta di rete sottostante è stata tradotta, inviata al provider, e la response è stata mappata di nuovo sullo schema di OpenAI prima ancora di raggiungere le tue variabili.
Questa astrazione si applica all'intera interazione. Copre gli errori, le statistiche sull'utilizzo dei token e persino le response in streaming. Se Anthropic restituisce un errore di rate limit, LiteLLM lo mappa sull'eccezione di rate limit standard di OpenAI. Il tuo codice di error handling esistente lo intercetta senza modifiche. Se richiedi una response in streaming, LiteLLM produce dei chunk che sono esattamente identici agli streaming chunk di OpenAI.
Puoi iterare tra diversi modelli semplicemente cambiando il valore della stringa del parametro model e sostituendo la variabile d'ambiente per l'API key. Il resto del tuo codice Python rimane completamente statico. Non sei più vincolato a un singolo ecosistema solo perché hai scritto il tuo codice di integrazione per uno specifico provider.
Il vero valore dell'interfaccia di completion unificata sta nel disaccoppiare la logica della tua applicazione dalle infinite varianti nelle API dei provider di modelli, trasformando complesse modifiche all'infrastruttura in semplici swap di stringhe.
Grazie per aver ascoltato, buon coding a tutti!
2
La magia della traduzione dei parametri
3m 45sSmetti di preoccuparti di quale provider supporti quale iperparametro. Scopri come l'SDK di LiteLLM traduce automaticamente gli input standard di OpenAI come temperature, tools e max_tokens per tutti i modelli upstream.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 2 di 24. Claude si aspetta max tokens, max tokens to sample, o qualcos'altro? Ogni volta che cambi provider di modelli, di solito devi riscrivere l'intero payload della tua API request per adattarlo alle loro specifiche naming convention. Parameter Translation Magic è la feature che fa sparire questo problema.
Quando chiami la funzione di completion in LiteLLM, scrivi la tua request usando sempre e solo il formato standard dei parametri di OpenAI. Non devi cercare le chiavi specifiche del dizionario per Anthropic, Vertex AI o Cohere. La libreria intercetta i tuoi input formattati per OpenAI e li traduce automaticamente nell'esatta struttura richiesta dal provider di destinazione.
Vediamo uno scenario specifico. Vuoi interrogare un modello Gemini su Vertex AI. Hai bisogno che usi il function calling, e vuoi che le risposte siano altamente deterministiche, quindi imposti la temperature a zero virgola due. Se stessi scrivendo un'integrazione diretta, Vertex ha un suo modo unico e profondamente annidato di definire i tool e impostare le configurazioni di generazione del modello. Con LiteLLM, ignori tutto questo completamente. Costruisci il tuo array di tool usando la sintassi JSON standard di OpenAI. Passi questo array, insieme al valore della temperature, direttamente nella chiamata di completion. LiteLLM prende quegli argomenti di OpenAI, li scompone e costruisce il payload corretto per l'API di Vertex AI prima di inviare la network request.
Questo mapping automatico è incredibilmente efficiente, ma introduce un edge case. Cosa succede se passi un parametro di OpenAI che il modello di destinazione semplicemente non supporta affatto? Magari specifichi una presence penalty, ma il provider non ha un concetto corrispondente. Di default, LiteLLM è strict. Solleverà un'eccezione e farà fallire la chiamata di completion. Questa è una scelta di design deliberata. Ti impedisce di perdere silenziosamente configurazioni che potrebbero essere critiche per il comportamento della tua applicazione.
Il failing in modalità strict è sicuro, ma può essere frustrante se stai facendo routing dinamico dei prompt degli utenti su decine di modelli diversi in produzione. Se vuoi che la chiamata vada a buon fine indipendentemente da piccole discrepanze nei parametri, aggiungi un flag chiamato drop params impostato a true all'interno della tua chiamata di completion. Quando lo abiliti, LiteLLM traduce comunque tutto ciò che riesce a mappare con successo. Ma se incontra un parametro di OpenAI che il provider di destinazione non riconosce, rimuove semplicemente quel parametro non supportato dal payload e invia il resto della request. La chiamata va a buon fine e il parametro non supportato viene ignorato in modo sicuro.
Se preferisci gestire le capabilities in modo elegante nel tuo codice anziché affidarti a dei drop silenziosi, c'è un tool di introspezione integrato. Puoi chiamare una helper function chiamata get supported openai params. Passi il nome del modello come argomento, e lei restituisce una lista di tutti i parametri standard di OpenAI che mappano con successo su quello specifico modello. Questo ti permette di verificare cosa supporta effettivamente un modello a runtime prima di eseguire la chiamata di completion.
Ecco il punto chiave. Il vero valore della parameter translation è che promuove le specifiche dell'API di OpenAI da uno schema vendor-specific a un linguaggio di interfaccia universale per l'intero stack della tua applicazione.
Grazie per l'ascolto, e happy coding a tutti!
3
Gestione Unificata delle Eccezioni
3m 36sScrivi i tuoi blocchi try-except una sola volta. Scopri come LiteLLM cattura gli errori personalizzati di AWS, Google e Azure, mappandoli perfettamente sulle eccezioni standard di OpenAI come RateLimitError.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 3 di 24. Scrivere una logica di error handling custom per quindici diverse API di AI è un ottimo modo per sprecare il tuo weekend. Ogni API ha il suo modo unico di dirti che stai inviando troppe request o che il tuo token non è valido. Per evitarti di scrivere infiniti condizionali, LiteLLM usa la Unified Exception Handling.
Invece di imparare come Anthropic, Cohere o Google restituiscono i loro errori, devi gestire un solo standard. LiteLLM mappa tutte le exception dei provider sottostanti direttamente ai tipi di exception standard di OpenAI. Se una request fallisce, il gateway intercetta il raw error, lo traduce in base all'HTTP status code e alla response del provider, e solleva il corrispondente errore OpenAI.
Considera uno scenario in cui usi un inference endpoint di Hugging Face. Durante le ore di punta, l'endpoint viene sovraccaricato di traffico. Hugging Face rifiuterà la request. Se chiamassi direttamente la loro API, dovresti parsare il loro specifico errore HTTP 503 Service Unavailable o un messaggio di throttling custom. Con l'unified exception mapping, non hai bisogno di un exception handler specifico per Hugging Face.
Strutturi il tuo codice usando un blocco try standard attorno alla tua generation call. Subito sotto, aggiungi un blocco except progettato per catturare un Rate Limit Error di OpenAI. All'interno di quel blocco, fai scattare la tua funzione di exponential backoff standard. La tua applicazione va in pausa, aspetta e fa un retry della request. Se in seguito sostituisci Hugging Face con Vertex AI, la tua backoff logic rimane esattamente la stessa. Il Rate Limit Error di OpenAI cattura l'evento di throttling di Vertex con la stessa affidabilità.
Questo mapping copre l'intero set standard di failures. Puoi catturare un API Timeout Error di OpenAI quando un server remoto va in hang. Puoi catturare un Authentication Error quando un'API key ruota o scade. Puoi gestire un API Connection Error per le cadute di rete o un Bad Request Error se il tuo payload è malformato. Il tuo application code tratta l'intero ecosistema AI come se comunicasse esclusivamente con un singolo provider prevedibile.
Ecco il punto chiave. A volte, un'astrazione pulita nasconde troppo contesto. Un Bad Request Error generico di OpenAI ti dice che la call è fallita, ma spesso hai bisogno di sapere esattamente perché. Azure, ad esempio, applica filtri rigorosi di content policy. Se Azure rifiuta un prompt perché viola le safety guidelines, mappare quell'errore a un errore generico di OpenAI rischia di farti perdere lo specifico safety flag che devi loggare o mostrare all'utente.
Per risolvere questo problema, LiteLLM attacca un attributo chiamato provider specific fields all'oggetto exception. Quando catturi un'exception OpenAI nel tuo codice, puoi ispezionare questo attributo. Contiene un dizionario contenente gli error data originali e non mappati, direttamente dal provider. Ottieni il flusso unificato di try ed except per il routing e i retry, ma mantieni i dati granulari per il debugging e l'auditing.
Costruisci i tuoi sistemi resilienti, i tuoi retry e i tuoi circuit breaker interamente attorno alle exception classes di OpenAI. Standardizzare i tuoi error boundaries impedisce ai failure modes provider-specific di intaccare la tua core application logic.
Grazie per l'ascolto, happy coding a tutti!
4
L'LLM Gateway: Configurare il Proxy Server
4m 06sPorta LiteLLM fuori dal tuo codice locale e in una piattaforma centralizzata. Impara ad avviare il Proxy Server di LiteLLM tramite Docker e a configurare i tuoi primi endpoint utilizzando il file config.yaml.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 4 di 24. Cosa succederebbe se tutta la tua azienda potesse condividere un unico endpoint LLM senza mai esporre le chiavi API raw del provider? Passare da un'integrazione SDK locale a un'architettura centralizzata cambia il modo in cui gestisci l'accesso. Questo è The LLM Gateway: Setting up the Proxy Server.
Molti sviluppatori presumono che introdurre un proxy middleware custom richieda la scrittura di codice client custom per comunicare con esso. Questo è falso. Il proxy LiteLLM parla il formato API nativo di OpenAI. Qualsiasi libreria, applicazione o script che sa come parlare con OpenAI ha solo bisogno di aggiornare il suo base URL per puntare al tuo nuovo proxy.
Per avviare il proxy server, hai bisogno di un file di configurazione. Questo è un file YAML che definisce la tua logica di routing. Il cuore di questo file è una sezione chiamata model list. Questa lista mappa i nomi dei modelli che le tue applicazioni interne richiederanno agli effettivi modelli del backend provider.
All'interno della model list, ogni voce richiede due elementi principali. Il primo è il model name. Questo è l'alias che esponi ai tuoi utenti. Potresti chiamarlo internal-chat-model. Il secondo è un blocco chiamato LiteLLM parameters. È qui che configuri la destinazione effettiva. Questa distinzione è importante. Il model name è ciò che il tuo client richiede, ma il blocco LiteLLM parameters definisce cosa elabora effettivamente la richiesta.
Se stai facendo routing verso un deployment Azure OpenAI, il tuo blocco LiteLLM parameters conterrà la model string specifica di Azure, il tuo base URL dell'API di Azure e la versione dell'API. Dici anche a LiteLLM quale environment variable contiene la chiave API. Non hardcodi la chiave nel file YAML stesso.
Con il file di configurazione pronto, fai il deploy del proxy usando Docker. Usi l'immagine ufficiale di LiteLLM dal GitHub Container Registry. Quando fai girare il container Docker, esegui tre passaggi specifici. Mappi la tua porta locale quattromila alla porta quattromila del container. Monti il tuo file di configurazione YAML nel container in modo che il proxy possa leggere la tua model list. Infine, passi le credenziali effettive del tuo provider nel container come environment variables.
Una volta che il container è in esecuzione, il proxy è live e in ascolto su localhost alla porta quattromila. Lo testi esattamente come testeresti l'API ufficiale di OpenAI. Fai una richiesta HTTP POST standard usando un tool come cURL. Punti a localhost porta quattromila, seguito dal path slash chat slash completions. Nel request body, specifichi l'alias che hai definito prima come model, e fornisci il tuo messages array.
Il proxy riceve questo payload standard. Legge l'alias richiesto, lo cerca nel tuo file di configurazione ed estrae gli Azure parameters. Quindi firma la richiesta con la tua chiave API di Azure, la inoltra a Microsoft e traduce la risposta tornando all'esatto formato che il tuo client si aspetta.
Ecco l'intuizione chiave. Il proxy astrae completamente il backend provider dall'application layer. Se il mese prossimo decidi di scambiare il tuo deployment Azure con un provider completamente diverso, non tocchi una singola riga del tuo application code. Aggiorni solo i LiteLLM parameters nel tuo file di configurazione YAML e riavvii il container.
Il valore primario del proxy server è che le tue client applications non sanno mai, e non hanno mai bisogno di sapere, quale cloud provider sta effettivamente generando i token.
Grazie per l'ascolto, happy coding a tutti!
5
Gestione Centralizzata dei Secret
3m 43sTieni le tue API keys fuori dalle configurazioni in chiaro. Scopri come connettere LiteLLM a secret manager enterprise come AWS Secrets Manager o Azure Key Vault per recuperare dinamicamente le credenziali.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: il gateway LLM universale, episodio 5 di 24. Se la master API key della tua azienda si trova in un file YAML in plaintext su un server di produzione, il tuo team di sicurezza avrà una brutta giornata. Le credenziali hardcoded sono un disastro annunciato. La soluzione è il Secret Management centralizzato.
Quando fai girare un gateway, ha bisogno di accedere alle API key del tuo provider upstream per fare routing del traffico correttamente. L'approccio di default spesso è buttarle in una environment variable locale o direttamente nel file di configurazione principale. Il Secret Management centralizzato cambia completamente questo pattern. Permette al gateway di leggere dinamicamente le credenziali da un enterprise vault esterno, come AWS Secrets Manager, Azure Key Vault, Google Secret Manager o HashiCorp Vault.
Per abilitare questa connessione, devi configurare due campi specifici all'interno del blocco dei general settings del tuo file di configurazione. Il primo campo è il key management system. Qui, definisci l'identifier del tuo vault provider. Se usi AWS, lo imposti su aws_kms. Il secondo campo è il key management settings. È una struttura nested in cui fornisci gli esatti parametri di connessione richiesti dal tuo vault specifico, come la region AWS di destinazione o altri dettagli di autenticazione necessari.
Una volta stabilita la connessione al vault, devi dire alle configurazioni di routing dei singoli modelli di prendere le loro chiavi da quel vault. Lo fai usando uno specifico string prefix al posto della chiave vera e propria.
Ecco il punto chiave. Invece di digitare una vera e propria key string, digiti la frase os punto environ slash, seguita immediatamente dal nome esatto del tuo secret così come si trova nel vault.
Facciamo un esempio concreto. Vuoi fare routing del traffico verso un modello Azure, e la vera API key è salvata in modo sicuro in AWS Secrets Manager con il nome azure api key production. Nel tuo file di configurazione, imposti il blocco di routing del modello. Ma per il campo api key, imposti il valore su os punto environ slash azure api key production.
Quando il gateway processa una richiesta per quel modello, vede il prefisso. Sa di non dover usare quella string come literal key. Invece, fa una chiamata sicura ad AWS Secrets Manager, richiede il valore per quell'esatto nome del secret, e recupera la vera chiave per autenticare la richiesta. La chiave in plaintext non tocca mai il tuo disco. Il tuo file di configurazione rimane completamente pulito e sicuro per il commit nel version control.
Questo copre il recupero delle credenziali upstream nel gateway. Ma l'integrazione del secret manager va in entrambe le direzioni. Può anche scrivere dati. Quando usi il gateway per generare nuove virtual proxy keys per i tuoi team di engineering interni, puoi configurare il sistema per salvare automaticamente quelle chiavi appena generate direttamente nel tuo secret manager. Questo assicura che le credenziali interne che emetti siano salvate e gestite con gli stessi identici controlli di sicurezza delle credenziali del provider che consumi.
I tuoi file di configurazione definiscono la struttura della tua infrastruttura di routing, ma non dovrebbero mai contenere i suoi secrets. Il posto più sicuro in cui salvare un'API key nella configurazione del tuo gateway è da nessuna parte.
Grazie per aver ascoltato, happy coding a tutti!
6
Model Aliases: L'aggiornamento ombra
3m 18sMigra gli utenti verso nuovi modelli in modo silenzioso. Scopri come utilizzare i Model Aliases in LiteLLM per mappare le richieste di un modello verso un endpoint completamente diverso senza alterare alcun codice lato client.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: il gateway LLM universale, episodio 6 di 24. E se potessi migrare la tua intera user base da OpenAI ad Anthropic senza chiedere loro di aggiornare una sola riga del loro codice di integrazione? O passare silenziosamente un utente del free-tier a un'alternativa open-source senza rompere la logica della sua applicazione esistente? Il meccanismo che rende possibile questa transizione silenziosa si chiama Model Aliases.
È facile confondere gli alias con il routing, quindi separiamo le due cose. Il routing gestisce il load balancing tra più deploy dello stesso identico modello. Se hai tre istanze separate di Azure OpenAI che fanno girare la stessa versione di GPT quattro, il routing distribuisce il traffico in entrata in modo uniforme tra di loro per prevenire i rate limit. Gli alias fanno qualcosa di completamente diverso. Un alias intercetta il nome del modello richiesto e lo mappa su un modello completamente diverso dietro al proxy.
Applichi questo mapping nel momento in cui crei una virtual key per un client. Quando invii la tua richiesta all'endpoint di generazione delle chiavi di LiteLLM, includi un oggetto aliases nel tuo payload. Questo oggetto è semplicemente un dizionario che associa il nome del modello che il client chiederà con il nome del modello che intendi effettivamente servire.
Vediamo uno scenario concreto. Hai un segmento di utenti del free-tier. Originariamente hanno costruito i loro tool attorno a GPT quattro, e quella string esatta è attualmente hardcoded nelle loro richieste di rete. Servire GPT quattro agli utenti non paganti è costoso, quindi decidi di reindirizzare i loro prompt verso un endpoint interno Mistral sette B altamente ottimizzato.
Per farlo, generi una nuova virtual key specifica per questo gruppo di utenti. Nel payload di generazione, definisci un alias che mappa la string GPT quattro direttamente al nome del tuo deploy Mistral sette B. Dai questa nuova virtual key agli utenti. Loro non modificano il codice della loro applicazione. Continuano a inviare richieste di chat completion standard al tuo proxy, chiedendo esplicitamente GPT quattro.
Ecco il punto chiave. Il proxy LiteLLM riceve la richiesta in entrata e autentica la virtual key. Legge la configurazione legata a quella specifica chiave e individua la tua regola di alias. Prima di fare il routing del payload verso un provider esterno, il proxy riscrive il parametro model in memoria. Rimuove GPT quattro e lo sostituisce con Mistral sette B. La richiesta va al tuo deploy interno di Mistral, genera il testo e fa il routing della risposta verso il client attraverso il proxy.
L'applicazione client riceve il formato di risposta standard che si aspetta. I suoi parser funzionano perfettamente e l'applicazione continua a funzionare normalmente. Gli sviluppatori che mantengono quell'applicazione client sono completamente ignari del fatto che il language model sottostante sia stato sostituito.
Dato che gli alias sono collegati direttamente alle singole virtual key anziché alla configurazione globale del server, mantieni il controllo assoluto sui diversi segmenti di utenti. Una chiave può fare da alias per il traffico verso un modello più economico per gli utenti free, mentre un'altra chiave permette al traffico premium di passare non modificato. Puoi anche usare questa stessa identica logica per gestire le deprecation dei modelli. Quando un provider ritira un vecchio modello, crei semplicemente un alias dal vecchio nome alla nuova versione, evitando a tutti i tuoi client di dover pushare aggiornamenti di codice in emergenza. L'aspetto più potente di un model gateway non è solo gestire il traffico di rete, ma disaccoppiare le aspettative del client dalla realtà fisica della tua architettura di backend.
Grazie per l'ascolto, happy coding a tutti!
7
Load Balancing per un High Throughput
3m 33sEvita rate limit e downtime instradando il traffico in modo intelligente. Esplora perché simple-shuffle è la strategia consigliata per il load balancing in produzione su più deployment.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 7 di 24. Finalmente hai ottenuto l'accesso in production ad Azure OpenAI, hai lanciato la tua app e hai subito beccato un enorme errore di rate limit al tuo primo grande picco di traffico. Hai la quota, ma c'è un collo di bottiglia in una singola region. Il Load Balancing per un high throughput risolve questo problema. Per gestire grandi volumi di richieste senza raggiungere i limiti, devi distribuire il tuo traffico su più deploy identici. In LiteLLM, lo fai configurando un router. Raggruppi più endpoint di backend sotto un singolo nome di modello logico. Mettiamo che tu abbia un'applicazione supportata da cinque deploy Azure sparsi in cinque diverse regioni geografiche. Quando la tua app richiede una completion, il router decide quale di queste cinque regioni riceve la richiesta. Controlli questa logica decisionale impostando una routing strategy nelle impostazioni del tuo router. L'approccio intuitivo è l'usage-based routing, dove il sistema invia la richiesta al deploy che al momento ha il traffico più basso. Ma per farlo devi tracciare l'utilizzo esatto dei token in real-time. Tracciare lo stato in real-time significa fare una chiamata di rete a una cache come Redis per ogni singola richiesta, prima ancora che il prompt venga inviato. Questo aggiunge un costo di latenza permanente alla tua applicazione. Per gli ambienti di produzione ad high throughput, vuoi evitare questo hop aggiuntivo. L'approccio consigliato è una strategia chiamata simple-shuffle. Simple-shuffle non traccia lo stato in real-time. Seleziona casualmente un endpoint dal tuo pool in base a pesi predefiniti. Quando aggiungi i tuoi cinque deploy Azure al tuo file di configurazione, assegni un limite a ciascuno, di solito Requests Per Minute, o RPM. Puoi anche usare Tokens Per Minute, o TPM. Se la tua regione primaria ha un limite RPM di diecimila, e una regione secondaria ha un limite RPM di cinquemila, simple-shuffle legge quei numeri e li tratta come pesi. Instraderà automaticamente il doppio del traffico verso la regione primaria. Dietro le quinte, il router prende la lista dei deploy disponibili per quel modello, calcola i loro pesi RPM, e li mescola in una lista randomizzata per quella specifica richiesta. Prova il primo deploy sulla lista. Dato che la randomizzazione rispetta rigorosamente i limiti RPM che hai configurato, il tuo traffico si distribuisce perfettamente su tutte e cinque le regioni nel tempo, schivando i rate limit senza l'overhead del monitoraggio in real-time. Per configurarlo, apri il tuo file di configurazione e imposti il parametro routing strategy su simple-shuffle. Poi, nella tua lista dei modelli, definisci i tuoi cinque endpoint Azure. Dai a tutti esattamente lo stesso nome di modello. Infine, associ il parametro RPM a ogni definizione di endpoint con il tuo peso desiderato. Quando la tua applicazione chiama il router usando quel nome di modello, il router gestisce la matematica e la randomizzazione automaticamente. Ottieni i vantaggi di un'architettura distribuita senza aver bisogno di una dipendenza Redis. Il modo migliore per gestire una massive scale è spesso quello di rinunciare al perfetto tracciamento in real-time in favore di una randomizzazione stateless e statisticamente prevedibile. Grazie per l'ascolto, happy coding a tutti!
8
Disservizi API e Fallback
3m 47sNon subire mai più un downtime dell'IA. Scopri come configurare i model fallbacks in LiteLLM in modo che, se il tuo provider principale fallisce, il traffico venga reindirizzato automaticamente verso un provider di backup.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 8 di 24. Quando il tuo provider principale di language model subisce un outage, la tua applicazione va down con lui, o fa un pivot silenzioso su un backup? Oggi parliamo di API Outage e Fallback, l'esatto meccanismo che mantiene il tuo sistema online quando gli endpoint esterni falliscono.
Innanzitutto, è utile distinguere questo concetto da uno correlato. I fallback non sono load balancing. Il load balancing distribuisce proattivamente il tuo traffico su più deploy attivi per evitare di sovraccaricare un singolo endpoint. I fallback, d'altra parte, sono salvataggi strettamente reattivi. Rimangono in idle durante il normale funzionamento e si attivano solo dopo che si è verificato un fallimento definitivo.
L'obiettivo principale è mantenere un uptime elevato, idealmente raggiungendo la soglia del novantanove virgola nove percento, anche quando i tuoi provider upstream non ci riescono. Le API esterne inevitabilmente lanceranno errori 500 di internal server error o eccezioni 429 di rate limit. Quando succede, una configurazione di fallback dice al proxy di intercettare l'errore mid-flight e di instradare la request a un provider alternativo, proteggendo completamente il codice della tua applicazione dal disservizio.
Puoi configurarlo nel tuo file YAML di configurazione del proxy usando un array fallbacks. Considera uno scenario concreto. Il tuo deploy primario è gpt-4. Vuoi assicurarti che, se gpt-4 va offline, il proxy provi automaticamente claude-3-opus al suo posto.
Nel tuo file di configurazione, definisci il setup del tuo modello gpt-4 come al solito. All'interno di quella specifica definizione del modello, aggiungi una chiave fallbacks. Il valore di questa chiave è semplicemente un array di stringhe, dove ogni stringa è il nome di un altro modello definito nella tua configurazione. Aggiungi claude-3-opus a questo array.
Quando la tua applicazione invia un prompt al proxy richiedendo gpt-4, LiteLLM lo instrada all'endpoint primario. Se quell'endpoint restituisce un errore, la logica del proxy lo intercetta. Se hai configurato dei retry, potrebbe provare l'endpoint primario ancora un paio di volte. Ma una volta che il primario fallisce definitivamente, il proxy attiva la sequenza di fallback.
È qui che la cosa si fa interessante. Il proxy prende esattamente il prompt e i parametri originali. Dato che LiteLLM normalizza il formato dell'API, traduce in modo trasparente la request in formato OpenAI nel formato Anthropic richiesto da Claude. Invia immediatamente la request tradotta all'endpoint di backup. Il codice della tua applicazione non deve gestire alcuna logica di errore, riscrivere il prompt, o gestire le API key per il secondo provider. Il proxy gestisce l'intero pivot internamente.
Non sei limitato a un singolo backup. L'array fallbacks accetta una lista di modelli. Se il tuo gpt-4 primario fallisce, e poi fallisce anche il tuo primo fallback claude-3-opus, il proxy passa al nome successivo nell'array. Scorre la lista in modo sequenziale. Se raggiunge la fine dell'array e ogni singolo modello di backup fallisce, solo allora il proxy restituisce un errore alla tua applicazione client.
Ecco il punto chiave. Stratificando diversi modelli di fallback nella tua configurazione, isoli efficacemente il codice della tua applicazione dall'instabilità esterna, trasformando gli hard outage del provider in nient'altro che invisibili picchi di latenza per i tuoi utenti finali.
Grazie per l'ascolto, happy coding a tutti!
9
Context Window Fallbacks
3m 20sSmetti di pagare troppo per context windows enormi su prompt brevi. Scopri come utilizzare i controlli pre-call e i context window fallbacks per instradare documenti sovradimensionati verso modelli specializzati.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 9 di 24. Usare un costoso modello con context da 128k per ogni singola query dell'utente è un enorme spreco di soldi. Ma se invece usi di default un modello più piccolo ed economico, un utente che carica un PDF enorme manderà immediatamente in crash la tua applicazione. Il meccanismo che risolve questo problema si chiama Context Window Fallbacks.
Potresti pensare che il fallback routing avvenga solo dopo che l'API del provider restituisce un codice di errore. Questo è vero per i fallback di affidabilità generali, ma i context limit funzionano in modo diverso. LiteLLM può gestire le dimensioni del prompt in modo proattivo usando un'impostazione chiamata enable pre-call checks. Quando imposti questo boolean a true nella configurazione del tuo router, il proxy ferma la request e calcola l'esatto token count del prompt prima ancora che il provider la veda.
Ecco il punto chiave. Configuri un modello primario, ad esempio un modello molto economico, e in quello stesso blocco di configurazione definisci una lista di context window fallbacks che punta a un modello molto più grande. Quando arriva una nuova request, viene eseguito il pre-call check. Se il token count calcolato rientra nel limite del modello primario, la request procede normalmente. Se il prompt è troppo grande, LiteLLM scarta completamente la route primaria. E inoltra all'istante la request al modello di fallback più grande.
Questo significa che non ricevi mai un errore di context length dall'API upstream. Significa anche che eviti la penalità di latenza dovuta all'attesa che un provider rifiuti il payload iniziale. L'applicazione che fa la request non ha idea che il routing sia cambiato dietro le quinte.
LiteLLM si affida al suo model registry interno per conoscere gli esatti context limit dei diversi provider. Tuttavia, potresti voler imporre limiti più stringenti. Magari vuoi triggerare il fallback in anticipo per lasciare più spazio ai token di output generati, o magari stai facendo routing verso un custom deployment con un'allocazione di memoria non standard. Gestisci tutto questo facendo l'override del parametro max input tokens direttamente nella configurazione del tuo modello. Specificare questo valore forza il proxy a usare il tuo limite custom durante la valutazione del pre-call check.
Pensa al traffico standard di un'applicazione. Un utente fa una semplice domanda di testo. Il proxy conta cinquanta token, valida che rientrino nel limite, e fa il routing verso GPT-3.5. Pochi minuti dopo, quello stesso utente carica un PDF enorme che contiene ottantamila token. Il proxy calcola la nuova dimensione, vede che supera il limite di GPT-3.5 e fa un redirect automatico direttamente a GPT-4-128k. La logica della tua applicazione rimane completamente statica. Paghi per il modello premium solo quando il payload lo richiede davvero.
Spostare la validazione dei token fuori dal codice della tua applicazione e dentro il proxy layer trasforma la tua fallback strategy da una rete di sicurezza passiva a un motore attivo di ottimizzazione dei costi.
Grazie per aver ascoltato, happy coding a tutti!
10
Domare le richieste in sospeso con i Timeout
4m 12sNon lasciare che API lente blocchino la tua applicazione. Scopri come configurare i global timeouts e gli stream timeouts in LiteLLM per interrompere le richieste in stallo e attivare fallback rapidi.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 10 di 24. Non c'è niente di peggio per la user experience di un chatbot che mostra un loading spinner per quarantacinque secondi semplicemente perché un'API upstream si è bloccata silenziosamente. Hai bisogno di un modo affidabile per interrompere immediatamente le connessioni morte, così il tuo sistema può riprendersi. Risolviamo questo problema domando le request bloccate con i timeout.
Quando instradi il traffico verso language model esterni, i ritardi di rete e i disservizi dei provider sono inevitabili. Se un provider smette di rispondere, il comportamento di default di molti client HTTP è quello di mantenere la connessione aperta a lungo. LiteLLM intercetta questo problema usando due distinti meccanismi di timeout. Il primo è il parametro di timeout standard. Questo setting determina il tempo massimo totale che LiteLLM aspetterà per il completamento di un'intera request, dal momento in cui viene inviata fino all'ultimo carattere generato.
Se imposti un timeout standard di trenta secondi, e il modello impiega trentuno secondi per scrivere una risposta lunga, LiteLLM interromperà la request. Questo funziona bene per i task in background o per generazioni brevi e non in streaming. Tuttavia, applicare un timeout totale a un'applicazione in streaming crea un problema strutturale. Una risposta completa potrebbe legittimamente impiegare sessanta secondi per fare lo streaming verso l'utente. Se imposti un timeout totale breve per intercettare le request bloccate, finirai per killare accidentalmente generazioni lunghe e perfettamente sane.
È qui che la situazione si fa interessante. LiteLLM fornisce un secondo parametro chiamato stream timeout. Questo setting misura specificamente il tempo fino al primo token. Controlla esattamente per quanto tempo il gateway aspetterà di ricevere il chunk di dati iniziale dal provider. Una volta che questo primo pezzo di dati arriva, il timer dello stream timeout si ferma, e la connessione rimane aperta per il resto della generazione.
Considera uno scenario concreto. Stai instradando il traffico verso un endpoint primario di Azure OpenAI. All'interno del tuo file di configurazione, definisci il blocco del tuo modello e aggiungi il parametro stream timeout, impostandolo a due secondi. Un utente invia un prompt complesso. LiteLLM inoltra questa request ad Azure. Normalmente, il server upstream elabora il prompt e restituisce il primo chunk in una frazione di secondo. Ma in questo caso, lo specifico nodo Azure si blocca.
Il gateway inizia a contare. Passa un secondo. Passano due secondi. Il primo chunk non arriva. Dato che hai definito uno stream timeout di due secondi, LiteLLM si rifiuta di aspettare che scatti il timeout HTTP standard. Interrompe forzatamente la connessione esattamente allo scoccare dei due secondi.
Interrompere la request morta è solo metà del vantaggio architetturale. Forzando un fallimento rapido, LiteLLM attiva immediatamente la tua logica di fallback. Nel momento in cui la request verso Azure va in timeout, il gateway reindirizza l'esatto stesso prompt dell'utente al successivo nodo disponibile e sano nella tua lista di deploy. L'utente sperimenta un ritardo di due secondi appena percettibile prima che il testo inizi lo streaming, evitando completamente un'interfaccia bloccata.
Hai la flessibilità di applicare queste regole a diversi livelli. Puoi applicare un timeout globale a tutte le request instradate, oppure puoi fare un fine-tuning per ogni singolo modello. Un modello pesante di ragionamento logico potrebbe richiedere uno stream timeout permissivo di cinque o dieci secondi, mentre un modello di classificazione veloce dovrebbe fare failover dopo un solo secondo.
La reattività della tua applicazione è governata non solo da quanto velocemente il tuo provider primario ha successo, ma da quanto aggressivamente forzi il fallimento di una connessione bloccata. Grazie per l'ascolto, happy coding a tutti!
11
Virtual Keys per la FinOps
4m 08sMetti al sicuro l'utilizzo delle tue API con precisione. Scopri come generare virtual keys utilizzando LiteLLM, impostando limiti rigorosi di RPM, TPM e budget per proteggere la tua organizzazione da costi IA fuori controllo.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 11 di 24. Uno script impazzito scritto da uno sviluppatore junior può facilmente generare una fattura OpenAI di diecimila dollari in una sola notte. La piattaforma del provider sottostante continua ad accettare request alla stessa velocità con cui il loop le lancia. Le virtual key per la FinOps sono il modo per fermare tutto questo prima che accada.
C'è spesso confusione tra master key e virtual key. Non devi mai dare la tua master key a uno sviluppatore. La master key è la tua credenziale amministrativa. Il suo scopo principale è autenticare la tua piattaforma per creare virtual key. Le virtual key sono le credenziali con restrizioni che dai effettivamente agli sviluppatori o alle applicazioni da usare nel loro codice.
Crei una nuova credenziale facendo una request HTTP POST all'endpoint di key generate sul tuo proxy LiteLLM. Autorizzi questa request usando la tua master key come bearer token. Il body di questa request è dove definisci i guardrail finanziari.
Immagina uno scenario in cui stai fornendo l'accesso a uno stagista estivo. Vuoi assicurarti che abbia abbastanza accesso per creare un prototipo, ma ti serve la garanzia assoluta che non possa bruciare il tuo budget infrastrutturale. Per imporlo, passi due parametri specifici nel tuo payload JSON.
Per prima cosa, definisci il limite finanziario impostando il parametro max budget. Se imposti questo valore a dieci, allochi esattamente dieci dollari americani a questa specifica key. Questo è un hard limit a vita. Una volta che il costo totale di tutti i prompt e le completion legati a questa key raggiunge i dieci dollari, la key viene disabilitata automaticamente e rifiuterà tutte le request successive.
Secondo, controlli la velocità di quelle request impostando il parametro RPM limit. RPM sta per requests per minute. Se imposti l'RPM limit a uno, il proxy impone rigorosamente una request in una finestra di sessanta secondi. Se un loop infinito accidentale nel codice dello stagista prova a lanciare cento request all'istante, il proxy processa la prima e rifiuta immediatamente le restanti novantanove con un classico errore di rate limit.
Quando invii questo payload all'endpoint di generate, LiteLLM processa le regole e restituisce una response contenente la virtual key appena generata. Questa key sembra identica a una credenziale standard del provider, e in genere inizia con un prefisso sk. Dai questa string allo stagista.
Ecco il punto cruciale. Lo sviluppatore usa questa virtual key esattamente come farebbe con una key di OpenAI o Anthropic, puntando la sua client library standard all'URL del tuo proxy LiteLLM invece che all'internet pubblico. Quando arriva una request, il proxy la intercetta. Interroga il suo database interno per verificare che la virtual key esista. Poi controlla se la key ha superato il suo budget di dieci dollari o il suo limite di velocità di una request al minuto.
Se la request supera entrambi i controlli, il proxy scambia la virtual key con la tua vera API key aziendale e inoltra il payload al provider. Quando il provider risponde, il proxy calcola il costo esatto dei token di prompt e completion in base ai prezzi pubblicati per quello specifico modello. Sottrae quella frazione di centesimo dal budget di dieci dollari della virtual key, registra la transazione e invia la response allo sviluppatore. Lo sviluppatore è completamente all'oscuro dello scambio di credenziali sottostante o della contabilità interna.
Imponendo dei limiti al layer del proxy, le virtual key intercettano le request non autorizzate o fuori controllo prima che raggiungano il billing provider, garantendo matematicamente che uno script compromesso o scritto male non possa mai superare il suo budget assegnato.
Grazie per l'ascolto, happy coding a tutti!
12
Spend Tracking e Custom Tags
3m 38sAttribuisci ogni centesimo di spesa LLM in modo accurato. Scopri come passare i metadata tags nelle tue richieste e generare report di spesa completi utilizzando LiteLLM.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: il gateway LLM universale, episodio 12 di 24. Il tuo CFO è appena entrato e ti ha chiesto esattamente quale nuova feature del prodotto sta bruciando il budget mensile per l'AI. Apri la dashboard del tuo provider, ma tutto quello che vedi è un'unica, enorme fattura aggregata per l'intera azienda. Non hai una risposta. Lo spend tracking e i custom tag in LiteLLM risolvono questo punto cieco.
Quando fai routing delle richieste tramite LiteLLM, il proxy calcola automaticamente il costo di ogni completion in base al modello specifico e al token count. Un importo totale in dollari è inutile se non puoi attribuirlo a una fonte specifica. Il modo più semplice per raggruppare questa spesa è usare il parametro user standard nella tua chiamata di chat completion. Passi una string univoca che rappresenta il tuo cliente finale. LiteLLM la intercetta, calcola il costo e lo registra su quello specifico user ID.
Il tracking per user risolve un problema, ma spesso un singolo user attiva più processi di backend. Mettiamo che tu abbia un workload di classificazione dei documenti, e che il reparto fatturazione abbia bisogno di un report che raggruppi la spesa per specifici background job. Un user ID non ti aiuta in questo caso. È qui che entrano in gioco i custom tag. LiteLLM ti permette di allegare un array di string a qualsiasi richiesta, e traccerà la spesa su quelle esatte string.
Ecco il punto chiave. Le librerie standard, come l'SDK ufficiale di OpenAI o LangChain, non riconoscono nativamente i metadata di LiteLLM. Se provi a passare un parametro non riconosciuto chiamato metadata, l'SDK lo rimuoverà o lancerà un errore prima ancora che la richiesta raggiunga il proxy. Per aggirare il problema, usi un parametro chiamato extra body. Questa è un'escape hatch standard integrata negli SDK moderni, pensata appositamente per iniettare campi custom.
Vediamo come farlo con una richiesta LangChain. Configuri il tuo oggetto chat model standard. Quando chiami il metodo invoke, passi il tuo prompt come al solito. Insieme al prompt, passi un parametro chiamato extra body. Lo imposti come dictionary. All'interno di quel dictionary, crei una chiave chiamata metadata. All'interno di metadata, aggiungi una chiave chiamata tags, che punta a un array di string. Potresti passare una string come job ID quattro zero due. LangChain impacchetta questo extra body esattamente così com'è e lo invia sulla rete. LiteLLM riceve il payload, estrae i tuoi tag dal blocco metadata e associa il costo preciso di quella chiamata LLM al job ID quattro zero due.
Questo copre gli input. E per gli output? Una volta che il tuo traffico scorre con questi tag, devi estrarre i dati. Lo fai interrogando l'endpoint global spend report sul tuo proxy LiteLLM. Fai una richiesta HTTP GET standard a questo endpoint. Il proxy restituisce un payload JSON che dettaglia esattamente dove sono finiti i soldi. Raggruppa la tua spesa totale per API key, per user e, cosa fondamentale, per ogni custom tag che hai fornito. Puoi consegnarlo direttamente al tuo reparto fatturazione. Potranno vedere all'istante che il job di classificazione dei documenti è costato esattamente quattro dollari e venti centesimi, indipendentemente da quale modello sottostante abbia gestito il routing effettivo.
Taggare il tuo traffico a livello di proxy significa che la granularità della tua fatturazione non è più dettata da come il tuo cloud provider struttura le sue fatture; è interamente definita dal contesto della tua applicazione.
Grazie per l'ascolto, happy coding a tutti!
13
Caching per Velocità e Risparmio
3m 37sSmetti di pagare ripetutamente per le stesse risposte dell'LLM. Scopri come configurare l'exact caching con Redis e il semantic caching con Qdrant per abbattere la latenza e i costi delle API.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 13 di 24. Perché pagare un'API esterna per generare la stessa identica spiegazione di base mille volte? Bruci crediti e costringi gli utenti ad aspettare calcoli che sono già stati eseguiti. Risolvere questa inefficienza è il fulcro del Caching for Speed and Savings.
LiteLLM gestisce il caching interamente a livello di proxy. Quando arriva una request, il proxy verifica se ha già visto esattamente questo prompt in precedenza. Se lo ha già visto, restituisce immediatamente la response memorizzata. La latenza crolla da secondi a millisecondi e il costo dell'API si azzera. Per configurarlo, usi il tuo file config punto yaml. Abiliti il caching nel blocco delle impostazioni globali impostando cache a true, e specifichi il tuo cache type. Redis è il backend standard per l'exact match caching. Fornisci host, port e password di Redis, e il proxy si occupa di memorizzare le coppie input-output.
Ma l'exact caching è fragile. Cerca uno string match perfetto. Se un utente chiede, scrivi una poesia su LiteLLM, e un altro utente chiede, crea una poesia su LiteLLM, una exact cache vede due request completamente diverse. Inoltra la seconda request al language model pesante, sprecando tempo e denaro in un task ridondante solo perché la formulazione è leggermente diversa.
È qui che entra in gioco il semantic caching. Invece di confrontare stringhe di testo grezze, il semantic caching confronta il significato sottostante dei prompt. LiteLLM supporta Qdrant, un vector database, per gestire questo aspetto. Quando configuri il semantic caching, devi specificare un embedding model insieme al tuo modello di generazione principale. Quando arriva una request, il proxy passa prima il prompt all'embedding model. Questo modello converte il testo in un vector, che è una rappresentazione matematica del significato del prompt.
Il proxy quindi interroga Qdrant per verificare se un vector simile esiste già nella cache. Poiché scrivi una poesia e crea una poesia condividono lo stesso intento semantico, i loro vector sono mappati molto vicini nello spazio. Qdrant rileva questa somiglianza. Se il match è abbastanza vicino, il proxy recupera la response in cache dal primo utente e la consegna al secondo utente. Salti completamente il pesante step di text generation, pagando solo una frazione di centesimo per il rapido embedding lookup.
Configurare questo richiede solo poche righe in più nel tuo config punto yaml. Cambi il cache type in qdrant semantic. Definisci i parametri specifici di Qdrant, come l'endpoint URL di Qdrant e la tua API key. La cosa più importante è che definisci una similarity threshold. Questo è un valore decimale compreso tra zero e uno. Una threshold alta, come zero virgola nove nove, richiede una formulazione quasi identica. Una threshold più bassa, come zero virgola otto, cattura variazioni più ampie, ma aumenta il rischio di restituire una risposta obsoleta o leggermente off-topic se due prompt sembrano simili ma hanno intenti diversi.
Ecco il punto chiave. Il semantic caching non è solo un meccanismo di storage, è un filtro attivo per l'intento dell'utente. Fare tuning della tua similarity threshold è l'unica cosa che si frappone tra una massiccia riduzione dei costi e il restituire risposte irrilevanti ai tuoi utenti.
Grazie per l'ascolto, e happy coding a tutti!
14
RBAC: Responsabilizzare i Team Admins
3m 19sDistribuisci la gestione della piattaforma in modo sicuro. Comprendi il Role-Based Access Control (RBAC) di LiteLLM, delegando il potere agli Org Admins e ai Team Admins senza compromettere la sicurezza globale.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 14 di 24. Sei un platform engineer e passi metà della giornata a rispondere a messaggi che chiedono nuove API key o aumenti di budget. Ogni onboarding di un developer si trasforma in un ticket IT che blocca il suo lavoro e ti fa perdere tempo. La soluzione è delegare il controllo senza perdere la supervisione, usando il Role-Based Access Control.
LiteLLM supporta quattro ruoli utente specifici per gestire questa delega. Sono il proxy admin, l'org admin, il team admin e l'internal user. Il proxy admin si trova al vertice. Se fai il deploy di LiteLLM, sei tu il proxy admin. Configuri i modelli, imposti il database e stabilisci le regole globali. Ma non dovresti gestire le richieste quotidiane di API key. È qui che entra in gioco la gerarchia.
Puoi raggruppare la tua azienda in organization, che rappresentano grandi dipartimenti, e in team, che sono gruppi di lavoro specifici all'interno di quei dipartimenti. L'org admin può gestire i team all'interno della propria organization. Ma il vero potere operativo è nelle mani del team admin.
Ecco il punto chiave. Puoi delegare tutte le attività amministrative locali a un responsabile di dipartimento, nominandolo team admin. Come proxy admin, imposti la struttura iniziale una volta sola. Crei un team, applichi un limite di budget rigido di cinquecento dollari al mese e assegni al lead developer il ruolo di team admin. Dopodiché, ti tiri fuori completamente.
Il team admin ora ha l'autonomia per gestire i propri engineer. Può fare login nella UI o usare l'API per aggiungere nuovi utenti al proprio team. Può generare nuove API key per quegli sviluppatori e monitorare la spesa aggregata del proprio gruppo. Cosa fondamentale, qualsiasi API key creata dal team admin o dai suoi engineer è automaticamente vincolata a quel budget del team di cinquecento dollari. Il team admin ha il pieno controllo locale, ma non può spendere un solo centesimo oltre il limite imposto dal proxy admin.
Sotto il team admin c'è l'internal user. Questo è il ruolo assegnato agli sviluppatori standard che scrivono il codice. Un internal user ha accesso limitato. Può visualizzare la propria spesa in token e, se il team admin lo consente, generare le proprie API key personali. La sua visione del sistema è strettamente limitata a se stesso. Non può vedere il budget complessivo del team, non può visualizzare le API key dei colleghi, e certamente non può modificare i setting del team.
Per configurare tutto questo a livello programmatico, il proxy admin fa una singola API request all'endpoint di creazione del team. Passi il nome del team, il parametro max budget e un array di user ID taggati con il ruolo di team admin. Il sistema restituisce un team ID. Da quel momento in poi, il responsabile del dipartimento usa quel team ID per instradare le proprie richieste di gestione, bypassando completamente il team di platform engineering.
Il Role-Based Access Control in LiteLLM non serve solo a nascondere bottoni in una UI, ma a limitare fisicamente la spesa in token a livello di gruppo, spingendo la gestione delle API key verso le persone che guidano effettivamente i progetti.
Grazie per l'ascolto, happy coding a tutti!
15
Security Guardrails
3m 42sAggiungi un livello di sicurezza invisibile alle tue richieste LLM. Scopri come configurare i pre-call e post-call guardrails in LiteLLM per bloccare le prompt injections e mascherare le PII prima che raggiungano i provider esterni.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: il Gateway LLM universale, episodio 15 di 24. Affidarsi al fatto che un language model si comporti bene non è una strategia di sicurezza. Se un utente incolla accidentalmente dati sensibili dei clienti in un prompt, chiedere al modello di ignorarli gentilmente è già troppo tardi. Ti serve un buttafuori all'ingresso, ed è esattamente ciò che offrono i Security Guardrails.
I Security Guardrails in LiteLLM agiscono come un layer di sicurezza invisibile tra i client della tua applicazione e i provider dei language model. Intercettano il traffico API in due fasi distinte. La prima fase si chiama pre call. Viene eseguita dopo che LiteLLM riceve la request in entrata dalla tua applicazione, ma poco prima di inoltrare il payload al provider esterno. La seconda fase si chiama post call, che si attiva dopo che il modello ha generato la sua response, ma prima che LiteLLM invii quella response indietro al client originale.
Definisci questa logica di routing interamente all'interno del tuo file config dot yaml. Sotto il blocco delle impostazioni del proxy, definisci i tuoi guardrail specificando un endpoint o un'integrazione supportata, e assegnandogli poi una modalità tra pre call o post call.
Vediamo uno scenario concreto usando un guardrail in pre call. Supponiamo che un dipendente chieda a un modello ospitato in cloud di riassumere un ticket di supporto, ma quel ticket contiene dei Social Security Number americani. Non vuoi assolutamente che quei numeri escano dalla tua rete interna. Puoi configurare Microsoft Presidio come tuo guardrail di pre call. Quando l'applicazione invia il prompt, LiteLLM intercetta la request e passa il testo a Presidio. Presidio scansiona il testo, individua il Social Security Number e lo sostituisce con una maschera generica. LiteLLM prende quindi questo prompt sanitizzato e lo invia su internet al cloud provider. Il modello esterno genera un riassunto basato sul testo mascherato, e il codice della tua applicazione opera come se non fosse successo nulla di strano.
Ecco il punto chiave. Non devi applicare queste regole globalmente a tutto il tuo traffico. LiteLLM ti permette di attaccare i guardrail a livello di specifico modello. Questo è fondamentale quando operi con un'architettura ibrida. Puoi configurare il tuo routing in modo che qualsiasi prompt inviato a un modello in cloud pubblico passi attraverso il rigoroso guardrail di mascheramento delle PII. Tuttavia, se fai routing di quello stesso identico prompt verso un modello open source che gira sul tuo hardware on premises, semplicemente lasci fuori il guardrail dal blocco di configurazione di quel modello. Il modello locale processa i dati raw non mascherati, perché le informazioni non attraversano mai il perimetro della tua rete. Eviti un inutile overhead di processamento e preservi il contesto esatto.
La modalità post call opera usando lo stesso identico flusso, solo nel viaggio di ritorno. Quando il modello esterno risponde, LiteLLM passa l'output attraverso i tuoi guardrail di post call. Questo ti permette di valutare il testo per linguaggio tossico, URL interni allucinati o menzioni non autorizzate di competitor, prima ancora che l'utente lo veda. Se il guardrail di post call flagga il contenuto, LiteLLM intercetta il viaggio di ritorno. Blocca il testo e restituisce un errore di sicurezza al client invece di consegnare l'output dannoso.
Gestendo tutto questo direttamente a livello di proxy, l'architettura della tua applicazione rimane completamente invariata. I tuoi sviluppatori inviano semplicemente delle request di completion standard, e il proxy applica le tue regole di compliance. I layer di sicurezza più affidabili sono quelli a cui il codice della tua applicazione non deve mai pensare. Grazie per l'ascolto, happy coding a tutti!
16
Gestione Dinamica delle Callback
4m 11sDai ai microservizi il potere della privacy. Scopri come utilizzare l'header x-litellm-disable-callbacks per consentire alle richieste API sensibili di escludersi dal logging centralizzato di observability.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 16 di 24.
Vuoi loggare tutto il traffico LLM per il debug, ma cosa succede quando un microservizio invia dati sensibili per la compliance che non possono assolutamente essere salvati? Potresti pensare di dover disabilitare l'observability a livello globale, rendendo l'intero sistema cieco solo per proteggere alcune API route specifiche. Il Dynamic Callback Management risolve questo problema permettendoti di controllare il logging per singola request.
In un setup LiteLLM standard, i callback gestiscono l'invio dei payload di request e response a piattaforme di observability esterne. Configuri piattaforme come Langfuse o Datadog a livello di proxy e, di default, catturano tutto ciò che ci passa attraverso. L'errore comune è pensare che questo logging sia un sistema tutto o niente. Spesso si pensa che per gestire dati sensibili sia necessario fare il deploy di un proxy completamente separato con il logging disattivato. Il Dynamic Callback Management elimina questo lavoro extra.
Considera un microservizio che gestisce cartelle cliniche. L'applicazione deve processare i sintomi dei pazienti tramite un language model, ma inviare questi dati sensibili a uno stack di logging di terze parti viola la compliance. Per prevenire questo leak, il microservizio aggiunge semplicemente un header HTTP specifico alla sua request in uscita. Questo header si chiama x-litellm-disable-callbacks. Imposti il suo valore con una lista separata da virgole delle piattaforme specifiche che vuoi bypassare.
Per il servizio delle cartelle cliniche, il microservizio passa l'header con il valore langfuse virgola datadog. Quando il proxy LiteLLM riceve questa request, valuta l'header prima di chiamare il language model. Il prompt viene inviato al provider e la response viene instradata al client come al solito. L'intervento avviene durante la fase di telemetry. Il proxy legge l'header disable e blocca attivamente l'inoltro del payload agli endpoint di observability specificati per quella singola transazione. Nel frattempo, tutte le altre applicazioni che puntano allo stesso proxy in concomitanza continuano a loggare il loro traffico senza alcuna interruzione.
Ed è qui che la cosa si fa interessante. Dare ai client il potere di disabilitare i propri audit log introduce un potenziale rischio di sicurezza. In ambienti altamente regolamentati, i developer non dovrebbero sempre avere l'autorità di nascondere il proprio traffico. Se la tua infrastruttura richiede un audit trail rigoroso e inalterabile per ogni singolo prompt, devi forzarlo centralmente.
Gestisci questa cosa usando il compliance locking. All'interno del file di configurazione del proxy, nel blocco dei setting generali, imposti un parametro chiamato allow dynamic callback disabling su false. Questo singolo setting stabilisce una policy globale rigorosa che fa l'override di qualsiasi istruzione client-side.
Se un microservizio tenta di passare l'header disable callbacks mentre questo lock è attivo, il proxy non ignora silenziosamente l'header. Invece, rifiuta completamente la transazione e restituisce un errore HTTP 403 Forbidden. Questo meccanismo garantisce che il traffico o rispetta la policy di logging globale obbligatoria, oppure viene droppato prima di raggiungere il language model.
La vera utilità del Dynamic Callback Management è che sposta la data privacy da un deploy infrastrutturale rigido a un parametro agile a livello di request, pur dando ai platform engineer l'ultima parola sulla compliance.
Grazie per l'ascolto, e happy coding a tutti!
17
Drop-in Observability
3m 46sOttieni visibilità istantanea sul tuo traffico LLM. Scopri come convogliare telemetry, traces ed eccezioni verso strumenti come Langfuse e Sentry utilizzando semplici callback di successo e fallimento.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 17 di 24. Quando un utente si lamenta che l'IA gli ha dato una risposta bizzarra tre giorni fa, come fai a recuperare il prompt esatto che l'ha causata? Fare il parsing dei log dell'applicazione per cercare payload JSON multilinea è un incubo. Hai bisogno di dati di trace strutturati, ma creare integrazioni custom per ogni tool di monitoraggio prosciuga ore di sviluppo. Questo esatto problema viene gestito dalla Drop-in Observability.
Invece di scrivere funzioni wrapper custom per cronometrare le tue chiamate API, contare i token e catturare i timeout, LiteLLM intercetta il traffico nativamente. Espone due hook principali all'interno delle tue impostazioni: la success callback e la failure callback. Queste callback fungono da meccanismi di routing automatico per la tua telemetria. Accettano un array di string che rappresentano i provider di observability esterni supportati. Ti basta nominare il tool che vuoi usare, e LiteLLM traduce i dati interni della sua request nel formato esatto che quello specifico tool si aspetta.
Prendi la success callback. Questa scatta nel momento in cui un modello linguistico restituisce una response valida. Quando succede, LiteLLM cattura automaticamente uno snapshot della transazione. Questo include l'esatto prompt di input inviato al modello, l'output generato, il tempo impiegato per generarlo e l'utilizzo preciso dei token. Per inviare questi dati a un tool esterno, apri le tue impostazioni di LiteLLM e imposti la variabile della success callback su una lista contenente la string "langfuse". Finché le tue chiavi di autenticazione di Langfuse sono presenti nelle tue variabili d'ambiente, il sistema gestisce il resto. Ecco il punto chiave. Il processo di logging avviene in modo asincrono in background. Il thread principale della tua applicazione non si blocca mai in attesa che il provider di observability confermi la trace. I tuoi utenti non subiscono alcuna latenza aggiuntiva.
Questo gestisce l'happy path. Per gli errori, usi la failure callback. Questa scatta quando una chiamata API va in timeout, raggiunge un rate limit del provider o fallisce completamente. Senza un tracing adeguato, un errore dell'LLM spesso emerge come uno status code opaco. Impostando la tua variabile della failure callback su una lista contenente la string "sentry", mappi le eccezioni dell'LLM direttamente al tuo workflow di error tracking esistente. Quando una request fallisce, LiteLLM impacchetta il tipo di eccezione, il nome del modello e l'input tentato, e poi invia quel contesto direttamente a Sentry.
Per configurare tutto questo nel tuo codice, non hai bisogno di modificare le tue effettive chiamate API. Tocchi solo la configurazione globale. Assegni i tool che hai scelto agli array delle callback una sola volta durante lo startup dell'applicazione. Da quel momento in poi, ogni chiamata di completion che fai viene monitorata. La tua core logic rimane completamente disaccoppiata dalla tua infrastruttura di logging. Se il mese prossimo decidi di sostituire Langfuse con un altro provider, cambi una sola string in un array.
Il vero potere delle drop-in callback non è solo evitare il codice boilerplate. È standardizzare la forma della tua telemetria attraverso dozzine di provider LLM diversi, in modo che la tua piattaforma di monitoraggio veda esattamente un unico formato coerente, indipendentemente da quale modello sottostante abbia risposto al prompt.
Grazie per l'ascolto, happy coding a tutti!
18
Metriche Prometheus e Pod Health
3m 26sTasta il polso al tuo proxy. Scopri come esporre l'endpoint /metrics a Prometheus, tracciare le in-flight requests e utilizzare custom tags per analizzare i dati in Grafana.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 18 di 24. Se una request LLM impiega dieci secondi, è il provider AI a essere lento, o è l'event loop del tuo proxy a essere completamente intasato? Non puoi risolvere un collo di bottiglia finché non sai esattamente dove si trova. Prometheus Metrics e Pod Health in LiteLLM ti offrono proprio questa visibilità.
LiteLLM espone un metrics endpoint standard al percorso slash metrics. Un errore comune nel monitoraggio dei gateway AI è considerare tutti i ritardi di risposta come latenza del provider LLM. Questo è inesatto. Ci sono due periodi di attesa distinti. Primo, c'è la latenza della coda pre-ASGI. Questo è il tempo che una request passa in attesa all'interno della tua infrastruttura prima ancora che il proxy inizi a elaborarla. Secondo, c'è la latenza LLM effettiva, ovvero il tempo passato in attesa che OpenAI, Anthropic o un altro provider restituisca i token. Il metrics endpoint separa questi numeri, così sai esattamente a chi dare la colpa per una risposta lenta.
Per monitorare la salute dei tuoi pod, ti affidi a un gauge specifico chiamato litellm in flight requests. Questa metrica tiene traccia del numero esatto di request concorrenti attivamente elaborate da un pod in un qualsiasi millisecondo. È una misura in tempo reale della queue depth. Quando ci sono picchi di traffico, questo numero sale.
Considera uno scenario concreto. La tua dashboard di monitoraggio mostra un picco enorme nella durata totale delle request. Gli utenti si lamentano delle risposte lente. Se guardi solo il tempo totale, potresti pensare che OpenAI abbia un outage. Ma quando controlli il metrics endpoint, la latenza del provider è stabile a due secondi. Ecco il punto chiave. Guardi litellm in flight requests e vedi che è schizzato da venti a duecento. Questo dimostra che il ritardo non dipende da OpenAI. La coda del tuo pod è completamente sovraccarica. Armato di questo preciso gauge, puoi configurare la tua infrastruttura per attivare un evento di auto-scale nel momento in cui le in-flight requests superano una soglia specifica, avviando nuovi pod proxy prima che l'event loop si intasi.
Devi anche sapere chi sta generando questo traffico. LiteLLM supporta tag Prometheus custom. Quando una request arriva al gateway, puoi passare metadati custom nel payload della request, come un project ID, un dipartimento o il nome di un'applicazione. LiteLLM estrae questi tag custom e li allega come label alle metriche di Prometheus. Invece di vedere semplicemente che il gateway ha elaborato diecimila token, vedi che l'applicazione di marketing ha elaborato settemila token e l'analytics dashboard ne ha elaborati tremila. Questo dà a DevOps la possibilità di raggruppare l'utilizzo dei token, la queue depth e la latenza per tenant specifici.
Il takeaway più critico per le performance del gateway è questo. Non fare mai l'auto-scale del tuo proxy AI basandoti sulla latenza di risposta totale, perché sprecherai soldi facendo scale up quando il provider esterno è semplicemente lento; fai scale basandoti sul tuo gauge delle in-flight requests per reagire solo quando la coda della tua infrastruttura è effettivamente piena.
Grazie per l'ascolto, happy coding a tutti!
19
Text-to-Speech Universale
3m 48sStandardizza la generazione vocale. Scopri come chiamare i modelli Text-to-Speech di Gemini, Vertex e AWS Polly utilizzando l'esatto stesso formato di endpoint audio compatibile con OpenAI.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 19 di 24. Vuoi aggiungere la generazione vocale alla tua app, ma scrivere codice di integrazione custom per il formato audio di ogni singolo provider richiede una manutenzione costante. Ogni volta che passi da un modello vocale di OpenAI a uno di Google, i campi JSON richiesti, i path dell'API e i return type dell'audio cambiano completamente. Il meccanismo che risolve questo problema è l'Universal Text-to-Speech, utilizzando il bridge audio-speech di LiteLLM.
Invece di mantenere client API separati per OpenAI, Vertex AI e Gemini, standardizzi la tua applicazione su un unico formato. LiteLLM espone un endpoint unificato che replica esattamente la route audio-speech standard di OpenAI. Costruisci una request contenente il tuo testo, il nome del modello scelto e una preferenza per la voce, inviandola a LiteLLM come se stessi parlando direttamente con OpenAI. Il gateway poi traduce questo payload standardizzato nel formato specifico richiesto dal tuo provider di destinazione.
Ecco il punto chiave. Molti provider di AI non offrono un'API text-to-speech semplice e dedicata che faccia lo streaming di file audio out of the box. A seconda del provider, l'accesso nativo a un modello vocale spesso richiede il routing della request attraverso un endpoint generico di text completion. Potresti dover passare dei flag di configurazione molto specifici, inviare un system prompt complesso, e poi estrarre delle stringhe audio codificate in base64, annidate in profondità all'interno di una response JSON. LiteLLM astrae questo intero layer di traduzione. Gestisce la negoziazione dell'API, spacchetta la struttura proprietaria della response e isola i dati audio effettivi.
Considera uno scenario concreto. Decidi di generare dell'audio parlato usando il modello in preview Gemini Flash TTS di Google. Nel codice della tua applicazione, punti il tuo client HTTP standard all'URL del proxy LiteLLM al path audio-speech. Imposti il parametro model in modo che punti al modello Gemini Flash TTS. Assegni il tuo plain text al parametro input, e specifichi un identificatore vocale valido.
Quando esegui la request, LiteLLM intercetta il payload. Si autentica in modo sicuro con Google Cloud o Vertex AI, a seconda del tuo setup. Rimpacchetta il tuo plain text e la selezione della voce nello schema JSON specifico richiesto dall'API di Google. Quando il modello di Google elabora il testo e restituisce il risultato, LiteLLM intercetta la response proprietaria. Invece di costringere la tua applicazione client a parsare un payload custom di Google Cloud, LiteLLM estrae i byte audio raw. Fa da bridge in modo trasparente sul transport layer, facendo immediatamente lo streaming di un file MP3 standard verso il tuo client. La tua applicazione frontend o backend riceve uno stream audio standard, completamente ignara del fatto che la generazione sottostante sia stata eseguita da Google anziché da OpenAI.
Questa logica di bridge significa che scrivi l'integrazione del tuo client text-to-speech esattamente una volta sola. Se domani Vertex dovesse rilasciare un nuovo modello audio più veloce, ti basterà cambiare la stringa del model nella tua request. Il codice dell'applicazione che gestisce lo stream MP3 rimane completamente intatto. Trattare la generazione audio esattamente nello stesso modo in cui tratti la generazione di testo ti permette di standardizzare la logica della tua applicazione. Forzando tutte le request text-to-speech attraverso un'unica interfaccia unificata, puoi fare routing, load-balancing e impostare failover per la tua generazione audio su provider completamente diversi, senza scrivere una singola riga di codice di fallback specifico per il provider. Grazie per l'ascolto, e happy coding a tutti!
20
Il Bridge per l'Assistants API
4m 10sGestisci lo stato delle conversazioni senza sforzo tra i vari provider. Scopri come LiteLLM avvolge i modelli non nativi nell'interfaccia standard dell'Assistants API di OpenAI, permettendoti di utilizzare Threads e Messages ovunque.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 20 di 24. OpenAI gestisce lo stato della conversazione in modo impeccabile, mantenendo il tuo codice client completamente stateless. Tuttavia, vincolare la tua architettura a un singolo provider solo per mantenere questa gestione dello stato è un prezzo alto da pagare. L'Assistants API Bridge di LiteLLM risolve questo problema.
Il bridge è una feature del proxy LiteLLM che espone gli endpoint esatti della Assistants API di OpenAI. Chiami path standard come gli endpoint v one assistants e v one threads, ma fai il routing dell'effettiva generazione del testo verso qualsiasi modello tu voglia.
Le interfacce standard di chat completion sono stateless. Ogni volta che fai una domanda, il tuo client deve rimandare l'intera cronologia della conversazione al server. Questo consuma banda e complica il tuo codice lato client. La Assistants API risolve questo problema mantenendo la cronologia della conversazione sul server all'interno di un oggetto Thread. Ti basta fare l'append dei nuovi messaggi al thread e dire al server di avviare il run dell'assistant. Il problema è che la maggior parte degli altri provider, dai setup locali alle alternative cloud enterprise, non offre nativamente questa interfaccia stateful.
Il bridge di LiteLLM fa da polyfill per questa funzionalità mancante. Per farlo funzionare, configuri il proxy LiteLLM per connettersi a un database. Questo database farà da storage layer per lo stato della tua conversazione. Dopodiché, punti il tuo client OpenAI esistente all'URL del proxy LiteLLM invece che ai server di default di OpenAI.
Il flusso logico inizia con la creazione di un assistant. Invii una request al proxy definendo le istruzioni dell'assistant e specificando un target model. Questo potrebbe essere un deploy di Azure OpenAI o un modello Astra compatibile con OpenAI. Il proxy salva questa configurazione nel suo database.
Successivamente, crei un thread. Un thread è semplicemente un contenitore vuoto salvato dal proxy. Quando un utente dice qualcosa, invii una request per aggiungere un messaggio a quello specifico thread. Il proxy salva il messaggio. Fino a questo punto, il large language model sottostante non è stato minimamente contattato.
Ecco il punto chiave. Il bridge comunica con il tuo target model solo quando fai il trigger di un run. Quando dici al proxy di fare il run dell'assistant su un thread specifico, LiteLLM recupera l'intera cronologia dei messaggi dal suo database. Formatta quella cronologia in un payload standard e stateless di chat completion. Poi invia quel payload piatto al modello sottostante che hai configurato prima.
Il modello valuta la conversazione e restituisce una response al proxy. LiteLLM prende quel testo, lo impacchetta come un nuovo messaggio dell'assistant, lo salva nel database del thread e aggiorna lo status del run a completed. Il tuo client fa polling sul proxy, vede lo status completed e recupera l'ultimo messaggio esattamente come farebbe di solito.
Il codice della tua applicazione rimane completamente invariato. Continua a pensare di comunicare con un sistema stateful nativo. Il proxy gestisce la traduzione in modo trasparente, prendendo una request stateful dal client, eseguendo una chiamata stateless al modello e mantenendo il persistence layer nel mezzo.
Questa separation of concerns significa che la tua architettura client può fare affidamento su una moderna interfaccia API state-managed, mentre la tua infrastruttura rimane completamente libera di fare lo swap dei modelli sottostanti in base a requisiti di costo, privacy o performance.
Grazie per l'ascolto, happy coding a tutti!
21
L'MCP Gateway
4m 04sPotenzia i tuoi modelli con i tools in modo centralizzato. Scopri come configurare i server Model Context Protocol (MCP) HTTP, SSE o STDIO in LiteLLM, dando a qualsiasi LLM accesso a funzionalità esterne.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: Il Gateway Universale per LLM, episodio 21 di 24. Hai un modello Llama open-source che gira in locale, ma vuoi che triggeri azioni o legga file usando esattamente le stesse integrazioni GitHub che usa il tuo agent Claude Code. Non vuoi riscrivere la logica della tua applicazione per supportare un nuovo toolset per ogni nuovo modello. L'MCP Gateway risolve questo problema.
Innanzitutto, separiamo MCP da A2A, o Agent-to-Agent routing. Un errore comune è considerarli la stessa cosa. A2A è quando fai il routing di un prompt utente verso un agent esterno specializzato per generare una risposta testuale. MCP è completamente diverso. MCP sta per Model Context Protocol, e consiste nel fornire un set standardizzato di tool a un modello, lasciando che sia il modello a decidere quando e come invocarli per completare un task.
La feature MCP Gateway permette al proxy LiteLLM di fare da ponte tra qualsiasi modello linguistico e i tuoi server MCP. Invece di scrivere codice per registrare i tool in ogni singola applicazione client che crei, li definisci centralmente nel proxy. Da quel momento in poi, qualsiasi modello che chiama il proxy può utilizzare quei tool.
LiteLLM si connette ai server MCP usando due metodi principali. Il primo è STDIO, o Standard Input and Output. Questo si usa per i tool locali. Configuri il proxy per eseguire uno specifico comando locale, come lanciare uno script Node o un file Python, direttamente sulla macchina host. Il secondo metodo è HTTP con Server-Sent Events, o SSE. Questo si usa per connettersi a server MCP remoti tramite rete.
Vediamo uno scenario concreto. Vuoi aggiungere un server MCP Zapier remoto in modo che i tuoi modelli possano interagire con web app esterne. Lo fai interamente all'interno del file YAML di configurazione del proxy. Sotto il blocco di configurazione principale, aggiungi una sezione per i server MCP. Dai un nome all'integrazione, ad esempio, zapier-integration. Definisci il tipo di trasporto come SSE. Poi, fornisci l'URL dell'endpoint del tuo server MCP Zapier. Dato che si tratta di una connessione remota, specificherai anche gli header di autenticazione richiesti, come un bearer token, direttamente all'interno di questa definizione YAML.
Ora il proxy sa come comunicare con Zapier. Il passo successivo è l'esecuzione. Quando la tua applicazione client invia una richiesta di chat completion standard a LiteLLM, deve semplicemente includere un header specifico che indica quali tool MCP vuole caricare.
Ecco il punto chiave. L'applicazione client non ha bisogno di sapere quali tool offre effettivamente Zapier. Il proxy intercetta la richiesta del client, contatta il server MCP Zapier tramite la connessione SSE e recupera dinamicamente la lista aggiornata dei tool disponibili. Il proxy quindi inietta le definizioni di questi tool nel payload e inoltra l'intero pacchetto al modello linguistico.
Se il modello linguistico decide di invocare un tool di Zapier, rimanda una tool call al proxy. Il proxy la intercetta, esegue l'azione sul server MCP Zapier, ottiene il risultato e lo restituisce al modello. La tua applicazione client è completamente isolata da questa negoziazione back-and-forth. Riceve semplicemente delle tool response standard compatibili con OpenAI.
Il vero potere dell'MCP Gateway è il disaccoppiamento dell'implementazione dei tool dalla scelta del modello, il che significa che un'integrazione creata per un ecosistema funziona all'istante su decine di modelli diversi senza dover scrivere codice adapter custom.
Grazie per l'ascolto, happy coding a tutti!
22
A2A: Tracciare gli Autonomous Agents
3m 24sMetti sotto controllo gli autonomous agents. Scopri come invocare agenti complessi di LangGraph o Bedrock attraverso il proxy utilizzando il protocollo A2A, abilitando il trace grouping e lo spend tracking unificato.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 22 di 24.
Quando il tuo agente autonomo entra in un reasoning loop di cinquanta step, come fai a tracciare il costo fino alla request originale? Se l'agente fa decine di call isolate a diversi LLM, i tuoi billing log diventano un disastro illeggibile di request scollegate. La soluzione è il LiteLLM Agent Gateway, noto anche come protocollo A2A.
Prima di esplorare come funziona, dovremmo chiarire un equivoco comune. Spesso chi ascolta lo confonde con il Model Context Protocol, o MCP. L'MCP si usa per fornire tool esterni a un LLM. L'A2A fa esattamente l'opposto. Tratta un agente autonomo esterno come se fosse un LLM standard, permettendoti di invocarlo e tracciarlo tramite un gateway centralizzato.
Per configurarlo, definisci il tuo agente nel file di configurazione di LiteLLM esattamente come definiresti un LLM standard. Dai un nome al modello, imposti la base URL che punta all'API endpoint del tuo agente e specifichi il provider come un endpoint OpenAI custom. Ora, LiteLLM sa come fare il routing delle request in arrivo dai client direttamente al tuo agente.
Quando un client invia una request chiedendo di questo agente, LiteLLM fa da pass through per gli header di contesto. Prende i metadati legati alla request, come gli identificatori utente, i tag di routing del team e i limiti di budget, e li impacchetta in specifici header HTTP. Il più importante di questi è l'header X-LiteLLM-Trace-Id. LiteLLM inoltra questi header insieme al prompt al tuo agente.
Ecco il punto chiave. Il tuo agente riceve questa request, avvia il suo loop autonomo e inizia a fare le sue call interne per processare il task. Se l'agente fa queste call direttamente a un provider pubblico, perdi il contesto di tracciamento. Invece, l'agente deve fare il routing delle sue call interne di nuovo attraverso LiteLLM. Quando lo fa, deve includere il trace ID che ha ricevuto nella request originale.
Considera uno scenario concreto. Stai invocando un agente LangGraph locale. Un client invia un prompt tramite LiteLLM per avviare il processo. LiteLLM assegna un trace ID univoco e inoltra il payload all'endpoint di LangGraph. La tua applicazione LangGraph legge gli header HTTP in entrata ed estrae l'X-LiteLLM-Trace-Id. Quando LangGraph deve valutare uno step o riassumere dei dati, usa il suo client interno per inviare una completion call di nuovo a LiteLLM. Cosa fondamentale, allega esattamente lo stesso header con il trace ID alla sua request in uscita.
Dato che ogni call interna porta con sé lo stesso trace ID, LiteLLM le raggruppa automaticamente. Quando guardi la tua piattaforma di observability o i tuoi budget log, non vedi cinquanta request casuali da fonti sconosciute. Vedi un'unica trace unificata. Sai esattamente quale utente ha attivato l'agente, quanto è costato l'intero reasoning loop e quali step autonomi specifici hanno consumato più budget.
Trattare gli agenti come degli standard model endpoint trasforma dei workflow complessi e multi-step in unità di calcolo tracciabili e fatturabili.
Grazie per l'ascolto, happy coding a tutti!
23
Key Rotations con Zero-Downtime
3m 21sOttieni transizioni di sicurezza con zero-downtime. Scopri come configurare key rotations automatiche programmate e grace periods per le virtual keys di livello enterprise in LiteLLM.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 23 di 24. La rotazione delle API key in produzione di solito significa downtime programmato, coordinamento frenetico e la speranza che nessun sistema di backend rimanga indietro con una credenziale morta. Un hard cutover è una misura di sicurezza rigorosa, ma è anche un modo infallibile per rompere le request in volo. La soluzione a questa tensione è la Zero-Downtime Key Rotation.
In un setup proxy enterprise, mantenere virtual key statiche per sempre è un rischio per la sicurezza inaccettabile. LiteLLM gestisce la cosa permettendoti di programmare la rotazione automatica delle key. Invece di generare manualmente nuove credenziali e coordinare il momento esatto per scambiarle, lasci che sia il proxy a gestire il lifecycle. Ma automatizzare semplicemente la creazione di una nuova key non risolve il problema di affidabilità di fondo. Se il gateway rifiuta immediatamente la vecchia key nel secondo in cui ne viene creata una nuova, qualsiasi servizio che non ha ancora sincronizzato la nuova credenziale fallirà all'istante.
Per risolvere questo problema, LiteLLM usa un grace period. Quando crei o aggiorni una virtual key, configuri due parametri specifici. Primo, imposti l'intervallo di auto rotate, che definisce esattamente ogni quanto deve nascere una nuova key. Secondo, definisci il grace period, che dice al sistema per quanto tempo la vecchia key deve rimanere valida dopo che è avvenuta la rotazione.
Considera una classica architettura a microservizi in cui la tua security policy richiede di ruotare le key di accesso all'LLM ogni trenta giorni. Fai una request all'endpoint di generazione delle key di LiteLLM. In quella request, imposti il parametro auto rotate a 30 giorni. Nella stessa identica request, imposti il parametro grace period a 24 ore. Il proxy salva questa policy e fa partire il timer.
Allo scoccare dei trenta giorni, scatta la rotazione. LiteLLM genera automaticamente una virtual key nuova di zecca. Questa è la parte che conta. Per le successive 24 ore, hai due key completamente valide che puntano all'esatta stessa configurazione, budget e logica di tracking.
Durante questa finestra di overlap, il tuo secrets manager recupera la nuova key e la inietta lentamente nel tuo ambiente di produzione. Mentre i container ciclano o le config map si aggiornano, i servizi passano in modo indipendente alla nuova credenziale. Se uno specifico background worker sta ancora usando la vecchia key a dodici ore dall'inizio del grace period, LiteLLM accetta la request senza battere ciglio. Il gateway instrada il traffico verso il Large Language Model e logga la transazione normalmente.
Una volta trascorso l'esatto grace period di 24 ore, LiteLLM invalida automaticamente la key originale. Qualsiasi sistema rimanente che tenta ancora di usare la vecchia credenziale riceverà un errore di autenticazione. La migrazione è completa.
Hai disaccoppiato completamente la creazione del nuovo secret dalla distruzione di quello vecchio. Separare questi due eventi trasforma la key rotation da un panico infrastrutturale fragile e altamente coordinato, a una tranquilla e affidabile routine in background.
Grazie per l'ascolto, happy coding a tutti!
24
L'Admin UI e l'AI Hub
4m 19sRendi la tua piattaforma IA accessibile a tutti. Scopri come gestire l'Admin UI, modificare le credenziali della UI e utilizzare l'AI Hub per consentire agli sviluppatori di scoprire in modo sicuro i modelli e gli agenti consentiti.
Ciao, sono Alex di DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 24 di 24. Il tuo platform team ha creato un gateway LLM altamente sicuro e con un routing perfetto. Ma quando gli sviluppatori interni devono effettivamente creare qualcosa, come fanno a sapere quali modelli e agenti possono utilizzare? Senza un meccanismo di discovery, il tuo gateway è una scatola nera invisibile. Questa visibilità è fornita dall'Admin UI e dall'AI Hub.
L'Admin UI è una dashboard visiva integrata direttamente nel proxy LiteLLM. Gestire un gateway LLM esclusivamente tramite file di configurazione e query sul database scala male quando più team iniziano a richiedere l'accesso. L'Admin UI offre ai platform operator un punto centralizzato per gestire il proxy. Tramite questa interfaccia, puoi generare nuove chiavi API, tracciare il consumo di token tra i diversi team, monitorare i log delle richieste live e configurare le regole di routing dei modelli.
Quando avvii per la prima volta il proxy LiteLLM, questa dashboard è abilitata di default e protetta con credenziali di login di default. Per il testing in locale, questo è comodo. In produzione, rappresenta una vulnerabilità. Devi modificare immediatamente queste credenziali di default. Puoi farlo impostando specifiche variabili d'ambiente per l'username e la password di amministrazione prima di avviare il container.
Ecco il punto chiave. Potresti non voler esporre affatto una dashboard grafica sul tuo gateway in produzione. Molti platform team fanno il provisioning dell'infrastruttura esclusivamente tramite script automatizzati e non desiderano un control plane interattivo accessibile via rete. Se questo si adatta al tuo modello di sicurezza, puoi disattivare completamente la dashboard. Impostando una variabile d'ambiente chiamata disable admin ui su true, rimuovi completamente l'interfaccia. Il proxy continuerà a fare routing del traffico e ad applicare le regole, ma il web server non servirà le schermate amministrative.
Questo copre i platform operator, ma gli ingegneri che consumano l'API hanno bisogno di una prospettiva diversa. È qui che entra in gioco l'AI Hub. Mentre l'Admin UI è destinata al controllo, l'AI Hub è dedicato alla discovery. Funge da developer portal interno per la tua organizzazione.
Invece di scrivere al platform team per chiedere quali modelli sono attualmente approvati o dove si trova la documentazione per un agente interno, gli sviluppatori visitano l'AI Hub. Si autenticano, in genere tramite il provider di single sign-on della tua organizzazione, e viene loro presentato un catalogo. Possono vedere esattamente quali modelli sono autorizzati a chiamare, esaminare i rate limit applicati a quei modelli e scoprire agenti preconfigurati creati da altri team.
Ancora più importante, l'AI Hub permette agli sviluppatori di fare self-serve. Possono generare le proprie chiavi API legate ai budget specifici del loro team, senza dover aspettare che un platform engineer ne faccia il provisioning manualmente. Questo cambia radicalmente il modo in cui la tua organizzazione interagisce con l'IA generativa. Colma il divario tra gli infrastructure engineer che mettono in sicurezza il gateway e i product engineer che sviluppano le applicazioni.
Il gateway è utile solo se è accessibile, e l'AI Hub trasforma un proxy blindato in una piattaforma self-serve, permettendo ai tuoi engineering team di muoversi velocemente senza sforare il budget. Questo conclude la nostra serie su LiteLLM. Ti incoraggio a esplorare la documentazione ufficiale, a provare queste configurazioni hands-on e a visitare dev stories dot eu per suggerire argomenti per le prossime serie. Grazie per l'ascolto e happy coding a tutti!