Keystone saca el nombre del modelo del código: un gateway LLM open source añade 0,64 ms

La línea más cara de un microservicio con LLM es model="gpt-4o". Arrastra tras de sí la clave del proveedor, sus propios reintentos y una factura que nadie sabe desglosar. El equipo de Keystone ha lanzado The Model Switchboard (KTMS), un gateway open source en Go con licencia Apache 2.0 que elimina esa línea por completo. El servicio le dice al gateway lo difícil que es la tarea, y son las reglas las que deciden qué modelo responde. La sobrecarga en el banco de pruebas es de unos 0,64 ms en p50 y 1,1 ms en p99 con 200 RPS.

Cuarenta servicios y un solo nombre de modelo

La historia típica es esta: el primer servicio recibe una clave de OpenAI y, medio año después, hay cuarenta servicios, cada uno con su secreto, su envoltorio de reintentos y su propio recuento de tokens. A partir de ahí todo se rompe de forma previsible. Sale un modelo mejor o más barato: son cuarenta pull requests y cuarenta despliegues, y la mitad de los equipos actualizará dentro de un trimestre. Cae un proveedor: se caen los cuarenta servicios, porque el fallback o no está escrito o está escrito de forma distinta en cada uno. Llega la factura: la clave es común, las llamadas no tienen metadatos y no hay forma de saber quién ha gastado el dinero.

En Keystone, el servicio envía effort (LOW, MEDIUM o HIGH) y atributos: idioma, tipo de tarea, usuario. Para el gateway, los atributos son simples claves y valores que comparan las reglas. Los clientes en Python ni siquiera necesitan gRPC: el endpoint HTTP compatible con OpenAI entiende las mismas reglas. El effort se codifica en el nombre del modelo (auto:high), metadata se convierte en atributos y el campo user se usa para los límites.

Reglas, canarios y un juez de 250 ms

Las reglas se almacenan en Postgres y se sustituyen en bloque con una única llamada atómica. Gana la regla aplicable de mayor prioridad, y el campo use define la cadena de fallbacks, por convención del modelo barato al caro. La validación rechaza cualquier conjunto en el que, para algún effort, falte una regla sin atributos, de modo que ninguna petición puede escapar de todas las reglas. Las réplicas recogen los cambios en un plazo de 60 segundos. El comando ktms route explain muestra la ruta de antemano, sin llamar al modelo.

Las reglas admiten pesos, por ejemplo [90, 10]. Si hay user_id o canary_key, el reparto es «pegajoso»: un mismo usuario siempre cae en el mismo modelo, de modo que un modelo nuevo se despliega al 10% de la audiencia sin tocar los servicios. También existe un enrutamiento shadow experimental: una parte del tráfico se duplica de forma asíncrona hacia el candidato, y el juez compara las respuestas y escribe el resultado en las métricas.

Si el servicio no conoce la complejidad, se activa model: "auto". El gateway consulta a un modelo juez, que no devuelve texto sino una respuesta tipada con probabilidades. Se admiten Jev de TypeSafe y OpenAI Decisions. El plazo es estricto, 250 ms; si el juez falla o responde con lentitud, la petición sale con MEDIUM. La complejidad fijada explícitamente siempre tiene prioridad sobre el juez, y la elección es visible en las cabeceras X-KTMS-Route-Mode, X-KTMS-Judge-Score y X-KTMS-Judge-Model. La selección por parte del juez en la rama 1.x está marcada como experimental; solo auto:high y sus equivalentes son estables.

Fallos de proveedores y gasto bajo control

Los reintentos integrados de los SDK de los proveedores están desactivados: un intento del router equivale a una llamada al proveedor. El router repite una vez, sobre el mismo modelo, los errores 429, 5xx o cortes de conexión, y después recorre la cadena; en streaming, esto funciona hasta el primer chunk. Mecanismos de protección:

• Circuit breaker por par (proveedor, modelo): tras 5 fallos seguidos el circuito se abre y, a los 30 s, una petición de prueba comprueba el modelo.
• Retry-After, retry-after-ms y google.rpc.RetryInfo de Gemini: una espera de hasta 1 s se cumple en el sitio; una más larga pone el modelo en pausa para esa clave concreta (máximo 5 minutos por defecto).
• Si toda la cadena está en pausa, el cliente recibe UNAVAILABLE vendors_unavailable con un Retry-After honesto.

Los límites de gasto se fijan en dólares por clave y por usuario, por día UTC o por mes, además de un presupuesto mensual del equipo. Antes de cada llamada, el gateway reserva el peor caso (entrada × precio de entrada + máximo de tokens × precio de salida) con un único script Lua en Redis y, tras la respuesta, lo recalcula con el coste real. Los importes se almacenan en nanodólares. Si una llamada fuera a superar el límite, se rechaza, pero un modelo más barato más adelante en la cadena aún puede responder. Sin max_output_tokens, la reserva se calcula sobre 4096 tokens, por lo que conviene definir siempre este parámetro.

Otras funciones:

• Organizaciones y equipos con listas de modelos permitidos y presupuestos mensuales; org_id y team_id los asigna el gateway a partir de la clave.
• Batch a través de las API de los proveedores con un 50% de descuento, envío idempotente por client_batch_id; los prompts no se guardan en la base de datos.
• Límite de peticiones GCRA con burst configurable y presupuestos diarios de tokens con una tolerancia del 5%.
• Un evento por cada llamada hacia light-tokenmeter o cualquier servicio gRPC de contabilidad.

Limitaciones y qué hacer al respecto

Proveedores: OpenAI, Anthropic, Gemini, DeepSeek, Groq, Mistral, Azure OpenAI, Bedrock, cualquier servidor compatible con OpenAI y TypeSafe para las decisiones. Puede que algún proveedor exótico no esté soportado. En latencia, Keystone queda por detrás de agentgateway, Apache APISIX y Kong. En el banco de pruebas (Google Cloud c3-standard-4 con 4 vCPU y un upstream mock), el gateway sostuvo al menos 4000 RPS. Sin Redis, los límites no funcionan, y si Redis cae, los límites de peticiones y de tokens dejan pasar el tráfico. Para los límites de gasto se puede activar el modo estricto SPEND_LIMITS_FAIL_MODE=closed.

Conclusión práctica para equipos con decenas de servicios LLM: empiecen con tres reglas (LOW, MEDIUM y HIGH sin atributos) y cadenas que vayan del modelo barato al caro, y añadan después reglas por atributos. Definan desde el principio max_output_tokens y límites en dólares por clave para que la factura se pueda desglosar. El esquema se puede replicar en otro gateway; lo importante es sacar el nombre del modelo del código de los servicios y llevarlo a la configuración.