KTMS 1.0, el gateway LLM open source, conecta GPU propias a la nube y resiste fallos de dependencias

KTMS (Keystone. The Model Switchboard) es un gateway LLM abierto escrito en Go: un punto único por el que las aplicaciones de una empresa acceden a modelos de distintos proveedores. Sus autores han lanzado la versión 1.0 y explican cómo se comporta el gateway en producción. Permite conectar GPU propias y enviarles las peticiones antes que a la nube de pago. Para cada una de las tres dependencias (Postgres, Redis y el servicio de contabilización) está definido de antemano qué hacer si falla. Las claves de cifrado se cambian sin pérdidas, y las versiones están firmadas y se verifican. La actualización se hace sin detener el servicio.

Primero las GPU propias, la nube como reserva

Muchos equipos tienen un Mac Studio o una máquina Linux con una buena tarjeta que pasa la mitad del tiempo parada. Mientras tanto, la factura de la nube crece por peticiones que un modelo local también podría atender. KTMS convierte esas máquinas en un proveedor aparte llamado local.

El administrador emite por gRPC la clave del nodo (se muestra una sola vez) y registra el modelo. En la propia máquina se ejecuta un único script. Instala Ollama, el modelo y el agente del nodo, configura los servicios en segundo plano e impide que el equipo se suspenda. En macOS no hacen falta permisos de administrador. Si algo falla, el mismo script con la opción --doctor indica la causa: Ollama no responde, el modelo no está cargado, Ollama se ejecuta en CPU a través de Rosetta o se ha indicado un --tls incorrecto. Se admiten Ollama, vLLM, TGI y llama.cpp.

El gateway se conecta por sí mismo al nodo, de modo que este debe ser accesible. El agente puede levantar un túnel de Cloudflare y un filtro delante del motor. Por el filtro solo pasan POST /v1/chat/completions y GET /v1/models, por lo que no es posible descargar ni borrar un modelo desde fuera.

La elección del nodo se hace en tres pasos:

• Filtro. Se conservan los nodos que tienen el modelo necesario, un slot libre y una ventana de contexto suficiente. Los nodos sanos van antes que los sospechosos, y los «calientes» (con el modelo ya en memoria) antes que los «fríos».
• Peso. El peso base se multiplica por una penalización de carga, que crece de forma cuadrática con la ocupación de los slots, y por un factor de corrección por velocidad. Este factor se calcula a partir de la velocidad de generación (tokens por segundo, peso 0,7) y del tiempo hasta el primer token (peso 0,3), respecto a la mediana de todos los nodos con ese modelo.
• Selección. Se aplica smooth weighted round-robin, como en nginx.

La principal defensa contra la lentitud es la estimación de la cola según la ley de Little: la profundidad de la cola se multiplica por la duración esperada de la petición. Si el resultado supera el queue_timeout_ms del modelo (2000 ms en el ejemplo), la petición pasa de inmediato al siguiente modelo de la cadena. Para los clientes interactivos el límite es de 250 ms. El slot es un lease en Redis que se renueva mientras dura la generación.

Las políticas de ubicación son nodes_first (por defecto), nodes_only (si no hay un nodo libre, se devuelve un error y no se recurre a la nube), cloud_first y cloud_only. Se pueden elegir mediante una cabecera, un campo de la petición o un sufijo del modelo, por ejemplo auto:nodes-only:high.

Qué hace el gateway cuando caen Redis y Postgres

El principio: un fallo de la contabilización no debe convertirse en un fallo del servicio.

• Redis. Los límites de peticiones y de tokens se omiten sin contabilizar. Para los límites en dólares se elige un modo: open deja pasar y closed rechaza. La caché se trata como un fallo de acierto (miss). Se desconoce el estado de los nodos, así que se saltan y responde la nube. Tras tres errores de red seguidos, el gateway deja de consultar Redis durante 2 segundos, de modo que un Redis bloqueado le cuesta a la petición un solo timeout.
• Postgres. Las claves verificadas en los últimos 5 minutos siguen funcionando; las demás reciben auth_unavailable. La verificación está limitada a 3 segundos. La configuración se toma de la última instantánea correcta. Un batch cuya idempotencia no se puede comprobar se rechaza, para que no se pague dos veces por él.
• Servicio de contabilización. Los eventos se acumulan en memoria (hasta 10 000) y las peticiones no esperan por ellos.

Cuando falla Postgres, /readyz responde 200 con el estado degraded mientras siga vigente la ventana de claves conocidas, y 503 después. Kubernetes no reiniciará los pods antes de tiempo. Cinco fallos seguidos abren el circuit breaker del proveedor, y a los 30 segundos se deja pasar un intento de prueba. Conviene configurar la alerta sobre ktms_dependency_errors_total.

Claves, firma de versiones y actualización sin tiempo de inactividad

Las claves de los proveedores se guardan en Postgres cifradas con AES-256-GCM. El keyring con las claves de cifrado se pasa mediante la variable KTMS_ENCRYPTION_KEYS y no se almacena en la base de datos. La rotación consta de tres pasos. Primero, añadir la nueva versión del keyring a todas las réplicas y esperar a que termine el despliegue. Después, llamar a RotateEncryption: en una sola transacción se vuelven a cifrar las claves de los proveedores y los tokens de los nodos. Por último, retirar la versión antigua cuando no quede ningún backup que la necesite. Un volcado junto con el keyring da acceso a todas las claves en texto claro, por lo que deben guardarse por separado.

Desde la versión 0.14.0, las imágenes se firman con cosign en modo keyless: la firma está vinculada a la identidad del workflow en GitHub Actions y no hay nada que robar. A las imágenes se adjuntan un SBOM (lista de componentes) y SLSA-provenance (registro de dónde y cómo se compiló). Cada pull request se revisa con govulncheck, y una versión no sale sin buf breaking ni una prueba de actualización. Los autores advierten con franqueza: la firma confirma el origen, no la seguridad. Quien obtenga permisos sobre el workflow de release podrá firmar también una imagen maliciosa.

Dentro de la serie 1.x, la API pública no se rompe. Las migraciones se aplican al arrancar bajo un advisory-lock y solo añaden esquema, por lo que las réplicas antiguas funcionan sobre la base nueva mientras arrancan las nuevas. No hay rollback: para volver atrás hay que restaurar el backup hecho antes de actualizar. Ante SIGTERM, las peticiones disponen de 30 segundos, y el agente del nodo entra primero en drain.

Para los equipos con GPU ociosas, es una forma lista para usar de reducir la factura de la nube sin el riesgo de quedarse sin respuesta ante una sobrecarga. Antes de poner el gateway en marcha conviene comprobar TLS (el propio gateway habla gRPC en texto plano), eliminar BOOTSTRAP_ADMIN_KEY, crear una clave independiente por cliente y vigilar las conexiones a Postgres (hasta 25 por réplica).