Fachadas a la entrada. Un solo modelo por dentro.

Seis elementos de primer nivel, no inferidos

En un gateway con forma de HTTP, estos elementos se deducen de una ruta, de una cabecera o del comportamiento del SDK de un proveedor. Aquí son campos de un objeto de dominio, y por eso las políticas, el enrutamiento, la caché y la contabilidad pueden razonar sobre ellos de forma uniforme.

Esa única decisión es la razón por la que chat, embeddings, visión, audio, trabajos de vídeo asíncronos y sesiones en tiempo real comparten una sola ruta de políticas, enrutamiento y contabilidad en lugar de seis.

Hable el dialecto, conserve la fidelidad

Los clientes envían peticiones con forma de OpenAI, Anthropic o Gemini, o directamente la forma nativa de petición de inferencia. Los adaptadores nativos preservan el comportamiento específico de cada proveedor — tool calling, visión, salida estructurada — en lugar de aplanarlo todo en una única forma de mínimo común denominador y perder capacidad en los extremos.

Nueve etapas, en un orden fijo

Todas las peticiones recorren las mismas etapas. La identidad, el acceso a modelos y el presupuesto se resuelven antes de invocar nada; la política de entrada se ejecuta antes de la caché, así que incluso una respuesta en caché se filtra; el enrutamiento elige el despliegue; la política de salida y de herramientas se aplica a la respuesta; el coste, los veredictos y las evidencias se registran a la salida.

1. 01
   Autenticar

   Clave virtual, token de agente o un token del IdP corporativo en /v1 (Enterprise). Resuelve la org, el equipo, el usuario, la aplicación y la ejecución del agente.

   ✗ 401
2. 02
   Acceso a modelos

   Los permisos de modelo, acotados por la lista de permitidos de la clave, deciden qué alias puede llamar esta identidad.

   ✗ 403
3. 03
   Presupuesto

   Los límites de tasa y los presupuestos se reservan sobre clave, org, equipo, usuario, aplicación y modelo. Todos deben pasar.

   ✗ 429 — sin gasto de proveedor
4. 04
   Políticas (antes de la llamada)

   Cadena ordenada de guardrails sobre la entrada: PII, inyección, moderación o su propio webhook. La caché ve el prompt ya enmascarado.

   ✗ BLOQUEO · ◑ ENMASCARADO · ◐ REDACCIÓN
5. 05
   Caché

   Exacta → canónica → casi duplicada → semántica, con cada nivel protegido frente a falsos aciertos. Un acierto se salta el proveedor y las etapas de salida.

   ✓ ACIERTO — se devuelve, sin llamada al proveedor
6. 06
   Enrutar

   Filtro de capacidades, residencia, afinidad de sesión y, después, la estrategia de enrutamiento elige el despliegue. Un failover nunca sale de las jurisdicciones permitidas.

7. 07
   Invocar

   Dialecto del proveedor, streaming SSE real, failover dentro del mismo alias y luego fallbacks ordenados; cada intento escribe una entrada de egress en el libro. La política en streaming se aplica sobre una ventana deslizante.

8. 08
   Política (tras la llamada)

   Los guardrails de salida se aplican a la respuesta completa. Las llamadas a herramientas que devuelve el modelo las juzga la política de herramientas: permitidas, eliminadas con una nota o rechazadas.

   ✗ 403 · eliminada
9. 09
   Contabilizar

   Los presupuestos se liquidan, el libro registra el resultado, y los tokens, el coste, los veredictos y la decisión de enrutamiento quedan como registros de peticiones, trazas OTEL y métricas de Prometheus.

Un proxy reenvía una petición. Esto decide qué se le permite ser a la petición — que es justamente la diferencia entre un gateway y un control plane.

Cuatro ciclos de vida, una sola ruta de políticas

Como el ciclo de vida es un campo de la petición y no un detalle de implementación de un endpoint, la misma gobernanza se aplica a los cuatro.

Esta es la parte que un gateway con forma de HTTP no puede añadir a posteriori sin una reescritura. El ciclo de vida tiene que estar en el modelo de dominio antes de que las políticas puedan aplicarse a él de forma uniforme.

Cuatro planos, separados a propósito

Nativo de Kubernetes, no compatible con Kubernetes

Cualquier cosa metida en un contenedor es compatible con Kubernetes. Nativo significa que la plataforma modela aquello que usted ejecuta: Wäg incluye su propio operator y sus recursos personalizados, de modo que el gateway es un objeto que el clúster entiende y no un despliegue que alguien cableó a mano. Un WaegInstance es dueño de los Deployments del gateway, la red, el autoescalado y la monitorización, y notifica un error de configuración como una condición con su motivo; los proveedores, modelos, organizaciones, presupuestos, guardrails y claves también pueden ser recursos personalizados. Como los presupuestos y los límites de tasa se comparten a través de Redis en lugar de mantenerse por réplica, escalar nunca permite gastar dos veces un presupuesto — y el operator marca como no lista una instancia con varias réplicas de API y sin Redis. Requiere Kubernetes 1.28 o posterior, u OpenShift 4; hay un chart de Helm si prefiere plantillas a un operator.

Rust en el plano de datos

Construido sobre tokio, hyper y axum, con rutas de streaming sin copia, y distribuido como un único binario distroless que no se ejecuta como root. Sin intérprete, sin gestor de paquetes y sin runtime de Node en el gateway — la consola de administración la sirve el mismo binario. No hay un router de ML en la ruta caliente, así que el enrutamiento añade análisis determinista en lugar de inferencia de un modelo.

Lo que Wäg no es

Lo decimos con claridad para que lo evalúe en el eje correcto y para que nadie solicite un briefing esperando otro producto.

• No es un servidor de inferencia. No ejecuta modelos. Enruta hacia los que ya utiliza, incluidos endpoints self-hosted de vLLM u Ollama, y Wäg Edge gobierna los modelos que se ejecutan en los ordenadores de los miembros y en apps móviles.
• No es un proveedor de modelos. Sin pesos, sin GPU, sin pipeline de fine-tuning.
• No es una base de datos vectorial. Hace de proxy para las llamadas de embeddings y cachea semánticamente; no almacena su corpus.
• No es un backend de observabilidad. Emite OTEL y Prometheus hacia lo que usted ya tenga en marcha.
• No sustituye a un API gateway. Kong y Envoy gobiernan HTTP. Wäg gobierna tokens, modelos y acciones de agentes. Son capas complementarias, y la mayoría de los entornos ejecutan ambas.

Ver el control plane · Ver los benchmarks