Une passerelle fonctionnelle en moins de cinq minutes
Un conteneur, un fournisseur, une requête. Aucun compte, aucune inscription, aucun appel vers l'extérieur. Si vous avez Docker, vous en aurez fini avant l'arrivée de votre café.
Démarrez la passerelle
Le mode embarqué ne nécessite rien d'externe : l'état est tenu en mémoire, donc rien ne survit à un redémarrage, et il n'y a encore ni Postgres ni Redis à monter. La console arrive sur le même port, servie par le même binaire Rust.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Ce n'est pas un pull qui fonctionne : les images ne sont pas encore publiques. Les partenaires de conception reçoivent les informations du registre en privé.
Le registre et la version sont des valeurs fictives — les partenaires de conception les reçoivent en privé. Console sur http://localhost:4000/ui/ : connectez-vous avec le compte administrateur initial et changez son mot de passe.
Ajoutez un fournisseur
Donnez-lui une cible en amont et un alias, puis redémarrez avec le fichier monté comme l'indique le commentaire. Les alias sont ce que référence votre code applicatif : vous pourrez les rediriger plus tard sans toucher à l'application.
# 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.yamlPointez votre SDK vers lui
Wäg expose la surface compatible OpenAI : seule l'URL de base change. Votre SDK, les formats de requête, le comportement du streaming et l'appel d'outils restent inchangés.
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"}],
)Regardez les en-têtes de réponse. C'est le premier signe visible que quelque chose a été décidé, et pas simplement relayé :
| En-tête | Ce qu'il vous indique |
|---|---|
x-waeg-routed-model | Quel déploiement a réellement servi la requête. |
x-waeg-route-reason | Pourquoi le routeur l'a choisi — pour le routage intelligent et l'affinité de session. |
x-waeg-cache | En cas de hit, lequel des quatre niveaux de cache a répondu. |
Voyez-la dans la console
Ouvrez la console : la requête y est déjà — trafic, latence, tokens, décision de routage et éventuels verdicts de politique. Le coût apparaît une fois le catalogue de prix fourni chargé sous Usage & cost → Pricing. Rien d'autre n'a été configuré : c'est ce que produit le passage par le chemin de la requête.
La suite depuis ici
Migrer depuis LiteLLM
Importez votre configuration existante en une commande, faites tourner les deux en parallèle et basculez quand les chiffres concordent.
Déployer pour de vrai
L'opérateur Wäg exploite la passerelle à partir d'une seule ressource personnalisée — mise à l'échelle, déploiements progressifs, contrôle de ses dépendances — et un chart Helm existe aussi. Fournissez Postgres, OpenFGA, Redis et un stockage objet.
Ajouter la gouvernance
Budgets hiérarchiques, chaîne de politique, contrôle des agents et de MCP, traces d'audit.
Wäg est en préversion privée : l'adresse d'image ci-dessus est donc une valeur fictive. Les partenaires de conception reçoivent en privé les images construites et signées ainsi que les informations du registre, avec un accompagnement à la prise en main.