Da LiteLLM a Wäg in un pomeriggio, non un trimestre
LiteLLM porta rapidamente i team al multi-provider — ed è per questo che gira in tanti stack di produzione. Ciò che non offre è un livello di governance: budget gerarchici che fermano la spesa prima che il provider venga chiamato, policy applicate nel percorso della richiesta, chiamate a strumenti trattenute per un approvatore con nome, e una traccia di audit da consegnare a un team di compliance. Wäg prende il posto del proxy LiteLLM e aggiunge quel livello. Mantenete il vostro SDK, i vostri alias di modello e il codice applicativo. Cambiate un URL di base.
Cosa cambia
- L'URL di base a cui puntano i client
- Dove risiede la configurazione
- Il processo proxy che gestite
Cosa no
- Il vostro SDK — openai, langchain, llamaindex, l'SDK LiteLLM come client, qualsiasi cosa compatibile con OpenAI
- Gli alias dei modelli richiamati dal codice
- I formati di richiesta e risposta
- Comportamento dello streaming, chiamata di strumenti, visione
- I vostri account provider e le chiavi API
Quattro passi, nessuno dei quali è una riscrittura
1 · Importate la configurazione
Legge il vostro config.yaml di LiteLLM — da riga di comando, o incollato in Platform → System → Import nella console — e produce la configurazione Wäg: modelli e alias, riferimenti alle credenziali dei provider, strategia di routing, fallback, Redis, progetti come applicazioni con budget, chiavi virtuali, server MCP e agenti A2A.
$ waeg import litellm --from config.yaml -o waeg.yaml$ waeg config validate --config waeg.yamlDa controllare è il rapporto di importazione. Ogni chiave finisce in uno di quattro elenchi — mapped, skipped, needs_human e notes — e la riga di comando stampa i conteggi con alcuni esempi:
mapped
model_list (12 rows) → 6 aliases: gpt-4o, claude, fast, cheap, embed, vision
model_list[3].litellm_params.rpm: 600 → relative deployment weight
litellm_settings.fallbacks → alias fallbacks
litellm_settings.num_retries: 3 → routing.max_retries: 3
router_settings.routing_strategy → routing.strategy: weighted (see notes)
projects[0] (max_budget, budget_duration) → application app_ll_search + application budget
skipped
litellm_settings.success_callback → re-create under Observability
needs_human
general_settings.master_key: os.environ/LITELLM_MASTER_KEY → set WAEG_MASTER_KEY
litellm_settings.cache_params → re-create under Caching
notes
routing_strategy "latency-based-routing-v2" is not known → weightedOutput illustrativo. Lo mostriamo perché il rapporto è un artefatto reale: nulla fallisce in silenzio, tutto ciò che non ha un equivalente in Wäg viene elencato per la revisione anziché approssimato, e i segreti non vengono mai ristampati.
2 · Cambiate un URL di base
Wäg espone la superficie compatibile con OpenAI — /v1/chat/completions, /v1/responses (stateless), /v1/embeddings, /v1/images/*, /v1/audio/*, /v1/videos, /v1/rerank, /v1/ocr, /v1/moderations, /v1/files, /v1/batches, /v1/realtime, /v1/models — più /v1/messages di Anthropic, /v1beta di Gemini, e /v1/mcp e /v1/a2a per gli agenti. I client LiteLLM come Cline e Roo continuano a funzionare: GET /model/info risponde con o senza /v1, x-litellm-api-key è accettato sulle route pass-through e MCP, e x-litellm-session-id raggruppa le chiamate in conversazioni. Lo streaming è SSE reale.
client = OpenAI(
- base_url="http://litellm:4000/v1",
+ base_url="https://waeg.internal/v1",
api_key=os.environ["GATEWAY_KEY"],
)Da verificare: GET /v1/models restituisce i vostri alias, poi una richiesta in streaming e una con chiamata di strumenti per alias.
3 · Verificate in parallelo
Fateli girare entrambi. Inviate una percentuale del traffico a Wäg, o duplicate verso di esso il traffico di produzione, e confrontate. Poiché le repliche sono stateless e condividono i contatori tramite Redis e la configurazione tramite Postgres, potete scalare il canary in su e in giù senza perdere lo stato dei budget.
- Decisioni di routing — x-waeg-routed-model su ogni risposta, x-waeg-route-reason con il routing intelligente
- Comportamento della cache — x-waeg-cache, e se i tassi di successo corrispondono alle attese
- Conteggio dei token e attribuzione dei costi rispetto alla fattura del provider
- Latenza p50 / p95 / p99, tassi di errore e di fallback
- Segnali di compatibilità — i campi di richiesta e risposta su cui contano i vostri client che il gateway ha inoltrato o scartato, conteggiati sul vostro traffico
4 · Passate
Cambiate l'URL di base per un servizio, poi per gli altri. Lasciate girare il deployment LiteLLM finché non siete soddisfatti — tornare indietro è la stessa modifica di una riga al contrario.
Un ordine sensato: prima gli strumenti interni, poi i carichi batch e offline, poi un servizio di produzione, poi tutto il resto.
Rimettete l'URL di base. È tutta la procedura — Wäg non trattiene alcuno stato da cui dipendano le vostre applicazioni, e account provider, chiavi e alias dei modelli restano intatti. Tenete entrambi i deployment durante la transizione. In questa migrazione non c'è, per scelta, alcun passaggio di lock-in.
Campo di configurazione per campo di configurazione
| LiteLLM | Wäg | Note |
|---|---|---|
model_list[].model_name | alias del modello | Riportato identico — il vostro codice continua a funzionare |
litellm_params.model | deployment: provider + model_id | Più righe con lo stesso model_name diventano deployment pesati di un unico alias |
api_key: os.environ/X | api_key_env: X | Letta dall'ambiente a runtime; passate in seguito a un riferimento al vault, se preferite |
litellm_params.api_base | base_url del provider | Un altro host o un'altra regione diventa un altro provider |
router_settings.routing_strategy | routing.strategy | simple-shuffle e usage-based → weighted, least-busy e latency-based → latency, cost-based → cost; tutto il resto → weighted, con una nota. Wäg aggiunge intelligent |
litellm_settings.fallbacks | fallback dell'alias | Ordinati dal più capace con la strategia intelligent |
litellm_settings.num_retries | routing.max_retries | Più un circuit breaker per deployment |
general_settings.master_key | master_key | Un riferimento os.environ viene elencato per la revisione: impostate WAEG_MASTER_KEY. Più chiavi virtuali con budget ed elenchi di modelli consentiti |
projects[]: max_budget / budget_duration | applicazione + budget | Wäg è gerarchico: org → team → utente → applicazione → modello → chiave |
rpm su un deployment | peso del deployment | Un peso relativo, non un limite di frequenza. rpm_limit e tpm_limit di un progetto vanno nella policy di budget della sua applicazione; il TPM per deployment non ha corrispondenza |
cache_params | da ricreare dopo l'importazione | In Caching: livelli esatto, canonico, quasi-duplicato e semantico con controlli contro i falsi hit |
guardrails | da ricreare dopo l'importazione | Gli stessi fornitori esistono come voci del catalogo, in una catena ordinata: prima della chiamata, mid-stream e dopo la chiamata |
success_callback / failure_callback | da ricreare dopo l'importazione | In Observability: callback OTLP, Langfuse e HTTP, più le metriche Prometheus |
custom Python callbacks | — nessun equivalente | Wäg non è un processo Python. Usate invece un motore di policy via webhook HTTP |
keys[] con un project_id | chiavi virtuali | Legate all'applicazione del progetto, così il budget di un agente di coding segue la sua chiave |
mcp_servers | server MCP di piattaforma | L'autenticazione Bearer e con chiave API diventa credenziali statiche; OAuth utente e token exchange richiedono Enterprise. Gli strumenti importati vengono fissati |
agents[] | agenti A2A di piattaforma | Aggiornate la card di ogni agente dopo l'importazione; il gateway la recupera e la verifica |
import litellm (in-process) | un client del gateway | L'SDK continua a funzionare puntato su Wäg; il suo routing in-process e le callback no |
Compreso ciò che LiteLLM fa e Wäg no
Confrontate questi punti con la vostra installazione prima di iniziare. Se uno dei primi due è portante da voi, la migrazione è un progetto vero e non un pomeriggio — ed è meglio saperlo ora che a metà strada.
Nessun routing in-process
LiteLLM si può importare come libreria Python. Puntato su Wäg, l'SDK continua a funzionare come client, ma il suo routing in-process e le callback non vengono riportati — il routing avviene invece nel gateway.
Nessun callback Python personalizzato
LiteLLM consente di inserire Python arbitrario nel ciclo di vita della richiesta. Il punto di estensione di Wäg è un motore di policy via webhook HTTP — più semplice da gestire e mettere in sicurezza, meno flessibile nell'immediato. Una logica di callback consistente diventa un piccolo servizio.
Meno provider esotici, più fedeltà
La copertura di provider di LiteLLM è più ampia. Wäg ha circa una dozzina di tipi di provider nativi, più qualsiasi server compatibile con OpenAI, con adattatori nativi Anthropic e Gemini che preservano la fedeltà di strumenti, visione e output strutturato invece di appiattire tutto in un'unica forma. Controllate prima il vostro elenco.
Una diversa filosofia di routing
Wäg valuta le richieste strutturalmente — strumenti, visione, lunghezza del contesto, indizi di ragionamento — ne ricava soglie di capacità rigide e sceglie il modello più economico che le supera. Deterministico e spiegabile negli header. Nessun router ML nel percorso critico.
Una diversa filosofia di cache
Quattro livelli — esatto, canonico, quasi-duplicato, semantico — con protezioni contro i falsi positivi. «Capitale della Francia» e «capitale della Spagna» sono un mancato riscontro. Numeri, negazioni e cambi di entità invalidano un riscontro.
La governance è gerarchica, non piatta
È la vera ragione per migrare. I budget di LiteLLM sono per chiave. Quelli di Wäg si sovrappongono su org → team → utente → applicazione → modello → chiave con tetti di equità, così il modello rispecchia la struttura reale delle organizzazioni.
Cosa avete guadagnato
Budget che fermano prima la spesa
Limiti sovrapposti su org → team → utente → applicazione → modello → chiave. Ogni richiesta è verificata rispetto a ogni contatore applicabile; il primo superamento respinge la chiamata prima della spesa verso il provider. Con WAEG_CLUSTER=1 falliscono anche in modo chiuso se Redis non è raggiungibile.
Policy nel percorso della richiesta
Una catena ordinata di analizzatori prima della chiamata, durante lo streaming su finestra mobile e dopo la chiamata. Dati personali, prompt injection, moderazione o un vostro webhook. Bloccare, mascherare o oscurare, regola per regola.
Cicli degli agenti governati
I server MCP remoti ricevono credenziali per server — chiave statica, token utente inoltrato o credenziali client OAuth, e con Enterprise la connessione OAuth dell'utente o il token exchange — più elenchi di strumenti consentiti e fissaggio. Le chiamate a strumenti possono attendere un approvatore con nome, in Slack o Teams con Enterprise, e ogni passaggio è soggetto a budget e registrato.
Una traccia di audit
Ogni richiesta, decisione di routing, verdetto di policy e costo in log delle richieste, trace OTLP e metriche Prometheus — e, una volta attivato, un registro delle prove firmato e concatenato con hash che chiunque può verificare offline con waeg ledger verify. Enterprise aggiunge pacchetti di prove mappati sull'AI Act e su DORA, con le lacune segnalate, e la marcatura dei contenuti IA.
Un solo binario
Rust, distroless, senza root. Nessuna shell, interprete o gestore di pacchetti nell'immagine del gateway, release firmate con SBOM e nessun runtime Node nel gateway — l'assistente opzionale della console gira come servizio a sé.
Un operator per gestirlo
Un operator Kubernetes proprietario dichiara il gateway — topologia, storage, OpenFGA, scalabilità HPA o KEDA — e riconcilia provider, modelli, budget, chiavi e guardrail come risorse. Gli errori di configurazione emergono come condizioni con un motivo, non come un pod che fallisce un'ora dopo.
Vedi dove finisce il gateway e inizia la control plane · Vedi i benchmark
Domande ricorrenti
Devo modificare il codice applicativo?
No. Cambiate l'URL di base che il vostro client compatibile OpenAI già usa.
La mia configurazione LiteLLM viene riportata?
In gran parte, tramite waeg import litellm o Platform → System → Import nella console. Ricevete un rapporto su ciò che è stato mappato, ciò che è stato saltato e ciò che richiede una persona, e nulla fallisce in silenzio.
Posso far girare entrambi insieme?
Sì, ed è il percorso consigliato. Duplicate o ripartite il traffico e confrontate decisioni di routing, costi e latenza prima di passare.
Wäg è un fork di LiteLLM?
No. È un'implementazione indipendente in Rust, costruita attorno a un modello di richiesta di inferenza anziché sul dispatch tramite gli SDK dei provider. La compatibilità è voluta; l'origine è distinta.
Lo streaming è supportato?
Sì — veri Server-Sent Events, non un flusso bufferizzato e poi spezzettato.
Chiamata di strumenti e visione?
Sì, sui formati di richiesta OpenAI, Anthropic e Gemini. Gli adattatori nativi preservano i comportamenti specifici di ciascun provider anziché ridurli al minimo comune denominatore.
E le API native di Anthropic e Gemini?
Sono supportate come formati di richiesta di primo livello, non solo come traduzione del formato OpenAI.
Serve Redis?
Con più di una replica sì — mantiene budget e limiti di frequenza coerenti tra le repliche, accanto a Postgres e OpenFGA che servono comunque in produzione. La modalità embedded non richiede nulla di esterno, ma è a nodo singolo e tiene lo stato in memoria.
Funziona su Kubernetes?
Sì, in due modi. Un operator proprietario dichiara il gateway e il suo catalogo come risorse — repliche stateless, scalabilità HPA o KEDA, contatori di budget condivisi, probe di salute e readiness — e c'è un chart Helm se preferite gestirlo voi.
È davvero Apache-2.0?
Sì. Il percorso di produzione del gateway è Apache-2.0: routing, HA, cache, failover, budget, guardrail, MCP, job, osservabilità e registro delle prove. Enterprise aggiunge identità (SSO, SCIM, token dell'IdP), pacchetti di audit e di prove, pagamenti degli agenti, approvazioni Slack e Teams, guardrail pass-through e supporto.
Chiama verso l'esterno?
No. Nessuna telemetria e nessuna analisi, e la licenza è un token firmato offline senza server di licenze. Funziona completamente in air-gap: osservate le sue connessioni in uscita e vedrete solo i provider che avete configurato.
E se ci servisse aiuto per migrare?
I partner di progettazione ricevono supporto pratico alla migrazione, anche da LiteLLM: la facciamo insieme a voi invece di consegnarvi una guida.
Un endpoint. Tutti i modelli. Controllo completo.
Gestitelo nella vostra infrastruttura
Tutto ciò che serve per gestire una control plane in produzione è sotto Apache-2.0 e lo resterà — routing, alta disponibilità, cache, failover, budget, policy, MCP, job e osservabilità. Self-hosted, senza account, senza chiamate verso l'esterno.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Non è un pull funzionante: le immagini non sono ancora pubbliche. I partner di progettazione ricevono i dettagli del registry in forma privata.
Avvia in 5 minutiContribuite come design partner
Wäg non è ancora disponibile pubblicamente. Lavoriamo con un piccolo gruppo di team che gestiscono IA multi-provider in produzione e prendono sul serio governance e sovranità, per irrobustire la control plane su carichi reali.
- Tutte le funzioni Enterprise incluse, senza costi di licenza
- Migrazione assistita — la facciamo insieme a voi, anche da LiteLLM
- Una linea diretta con gli ingegneri e un'influenza reale su ciò che arriva dopo