Un gateway funzionante in meno di cinque minuti
Un container, un provider, una richiesta. Nessun account, nessuna registrazione, nessuna chiamata verso l'esterno. Se avete Docker, potete finire questa pagina prima che arrivi il caffè.
Avviare il gateway
La modalità embedded non richiede nulla di esterno: lo stato è tenuto in memoria, quindi nulla sopravvive a un riavvio, e non c'è ancora alcun Postgres o Redis da predisporre. La console si avvia sulla stessa porta, servita dallo stesso binario Rust.
$ 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.
Registry e versione sono segnaposto — i partner di progettazione li ricevono in forma privata. Console su http://localhost:4000/ui/: accedete con l'account admin predefinito e cambiatene la password.
Aggiungere un provider
Indicategli un upstream e un alias, poi riavviate con il file montato come mostra il commento. Gli alias sono ciò a cui fa riferimento il codice applicativo, così potrete rimapparli in seguito senza toccare l'applicazione.
# waeg.yaml
providers:
openai:
provider: openai
api_key_env: OPENAI_API_KEY # or api_key_ref: a vault reference
models:
- name: chat # what your code sends as "model"
deployments:
- provider: openai
model_id: gpt-4o
# Restart with it mounted:
# docker run -p 4000:4000 -e OPENAI_API_KEY \
# -v "$PWD/waeg.yaml:/etc/waeg/waeg.yaml" \
# <registry>/waeg-gateway:<version> serve --config /etc/waeg/waeg.yamlPuntare l'SDK su di esso
Wäg espone la superficie compatibile OpenAI, quindi l'unica cosa che cambia è la base URL. SDK, forma delle richieste, comportamento dello streaming e tool calling restano invariati.
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:4000/v1", # the only change
api_key="<your-waeg-virtual-key>", # created in the console
)
resp = client.chat.completions.create(
model="chat",
messages=[{"role": "user", "content": "Hello"}],
)Osservate gli header della risposta. È il primo segnale visibile che qualcosa ha deciso qualcosa, anziché limitarsi a inoltrarlo:
| Header | Cosa vi dice |
|---|---|
x-waeg-routed-model | Quale deployment ha effettivamente servito la richiesta. |
x-waeg-route-reason | Perché il router l'ha scelto — per il routing intelligente e l'affinità di sessione. |
x-waeg-cache | In caso di hit, quale dei quattro livelli di cache ha risposto. |
Vederlo nella console
Aprite la console e la richiesta è già lì: traffico, latenza, token, decisione di routing ed eventuali verdetti di policy. Il costo compare una volta caricato il listino prezzi incluso in Usage & cost → Pricing. Non è stato configurato altro: è ciò che produce il passaggio nel percorso della richiesta.
Dove andare da qui
Migrare da LiteLLM
Importate la configurazione esistente con un solo comando, eseguite entrambi in parallelo e passate quando i numeri coincidono.
Metterlo davvero in produzione
L'operator Wäg gestisce il gateway a partire da una sola custom resource — scalabilità, rollout, controlli sulle sue dipendenze — e c'è anche un chart Helm. Portate Postgres, OpenFGA, Redis e un object store.
Aggiungere la governance
Budget gerarchici, catena di policy, controllo di agenti e MCP, record di audit.
Wäg è in anteprima privata, quindi l'indirizzo dell'immagine qui sopra è un segnaposto. I partner di progettazione ricevono in forma privata le immagini compilate e firmate e i dettagli del registry, con un onboarding affiancato.