El plano de control no debería estar en el camino de los tokens
El plano de control decide qué conexión es elegible; el plano de ejecución realiza la llamada. Confundirlos aumenta el radio de fallo y oculta responsabilidades.
El problema de un catálogo multi-modelo
Una plataforma empresarial puede utilizar modelos distintos para razonamiento, trabajo rápido, visión, embeddings u otras modalidades. También necesita variar la selección por usuario, organización, capacidad y tarea interna.
El catálogo debe responder:
- qué capacidades están disponibles;
- qué modelos y proveedores las satisfacen;
- qué valores predeterminados se aplican;
- qué restricciones de residencia, seguridad o contrato existen;
- qué coste y versión de tarifa corresponden;
- qué modelo terminó utilizándose realmente.
Gestionar esas preguntas en variables locales de cada servicio produce deriva. Resolverlas mediante un gateway único parece centralizarlas, pero sitúa el servicio administrativo en el camino crítico de toda inferencia.
Dos planos
Plano de control
Mantiene catálogo, alias de capacidad, valores predeterminados, asignaciones, políticas, rate cards y referencias de credenciales. Resuelve una solicitud contextual en una configuración elegible.
Plano de ejecución
El runtime recibe la configuración resuelta y llama directamente al endpoint del modelo. Conserva su cliente de streaming, reintentos, tool calling y telemetría.
La guía de AWS para entornos agénticos multi-tenant utiliza una separación análoga entre control plane y application plane. La frontera no es exclusiva de ALLAN; su aplicación concreta sí lo es.
Por qué no utilizar siempre un gateway
Un gateway puede aportar ventajas reales: control de egress, observabilidad uniforme, transformación de protocolos o custodia central de credenciales. No es una decisión errónea por definición.
En ALLAN se retiró de esta ruta porque:
- convertía un servicio de administración en dependencia dura del streaming;
- añadía un salto de red a cada respuesta;
- duplicaba un cliente de inferencia que el runtime ya mantenía;
- ampliaba el número de componentes capaces de interrumpir una generación;
- mezclaba cambios de catálogo con la operación token a token.
El coste de la llamada directa es que la identidad de workload y la configuración sensible deben llegar de forma segura al consumidor. Un diseño público prudente no prescribe credenciales estáticas en payloads: debe preferir referencias a secretos, identidades de servicio, credenciales de corta duración, rotación, audiencias limitadas y control de egress.
Extracto. Sacar el plano de control del camino de los tokens no elimina su responsabilidad. La desplaza a un contrato de resolución que debe ser autenticado, auditable y revocable.
Resolver por capacidad
La interfaz pública no necesita exponer todos los identificadores técnicos. Puede presentar categorías estables —por ejemplo, razonamiento, baja latencia, visión o embeddings— y dejar que la plataforma resuelva una implementación compatible.
Una cascada típica aplica:
- override explícito permitido para la petición;
- preferencia del usuario;
- default de la organización;
- default de plataforma.
Cada nivel solo puede seleccionar modelos habilitados y elegibles. Si un modelo deja de cumplir la policy, la cascada continúa o falla de forma explicable.
El routing aprendido, como RouteLLM, estudia la selección dinámica entre modelos con diferente coste y rendimiento. Un catálogo empresarial añade condiciones que un benchmark de routing no suele capturar: modalidad, contexto, tools, residencia, proveedor permitido, seguridad, disponibilidad y límites del tenant.
La regla no es «usar siempre el modelo más barato», sino «usar el modelo elegible de menor coste que satisfaga la calidad requerida».
Alias para el usuario, procedencia para la auditoría
Un alias estable evita que las aplicaciones dependan de nombres comerciales y versiones efímeras. También permite cambiar una implementación sin reconfigurar cada agente.
La abstracción no debe borrar la procedencia. El ledger y la auditoría deben conservar:
- proveedor y modelo o deployment efectivo;
- versión de la tarifa;
- región o residencia cuando sea relevante;
- razón de routing;
- si hubo fallback;
- identidad de la política que autorizó la selección.
Ocultar complejidad en la interfaz es distinto de ocultar quién procesó los datos. La transparencia hacia el usuario y las obligaciones de información deben resolverse conforme al contexto jurídico y contractual.
Caché de resolución
Consultar el plano de control en cada paso de un loop aumenta latencia y carga. Una caché corta puede estabilizar la configuración durante el turno y reducir llamadas repetidas.
La clave de caché debe incluir todos los factores que cambian la resolución: rol, modelo solicitado, consumidor, tenant, usuario y policy relevante. La invalidación debe responder a deshabilitación, rotación de credenciales y cambios de seguridad; una TTL no sustituye la revocación urgente.
Fallback: disponibilidad con límites
El fallback debe estar ordenado, probado y visible. Una alternativa solo es válida si sigue cumpliendo:
- capacidad y modalidad;
- contexto y herramientas requeridas;
- residencia y clasificación de datos;
- allow-lists y policy del tenant;
- límites de coste;
- nivel de calidad aceptado.
Degradar silenciosamente puede mantener una respuesta y romper una obligación. En algunos casos, el comportamiento correcto es fallar de forma explícita y segura.
El evento de telemetría debe registrar que hubo degradación, la causa y el modelo efectivo. La persona no necesita conocer toda la topología, pero la plataforma debe poder explicar el cambio.
Metering por identidad estable
El consumo no debe depender de un nombre upstream mutable. El catálogo asigna una identidad estable y proyecta una rate card versionada al sistema de metering. El runtime emite uso con la resolución efectiva; el ledger aplica la tarifa que estaba vigente para ese evento.
Las convenciones GenAI de OpenTelemetry ofrecen un vocabulario emergente para atributos de proveedor, modelo y uso. No sustituyen el ledger ni la política de coste, pero ayudan a mantener telemetría interoperable.
Estado y límites
La separación principal control/ejecución y la resolución dinámica están presentes en ALLAN. El documento interno contenía ejemplos de proveedores, secretos, endpoints, fallbacks y consumidores que se han retirado de esta edición.
La arquitectura continúa evolucionando en categorías, entitlements, semántica de fallback y custodia de credenciales. Compatibilidad de API no significa que todos los proveedores tengan idéntico comportamiento operativo.
Referencias
Fuente editorial de ALLAN
docs/model-provider-management-design.md, anonimizado y reconciliado con la arquitectura vigente.
Fuentes externas
- AWS, Employing control planes in agentic environments, guía prescriptiva, consultada en 2026.
- AWS, Design fallbacks and graceful degradation, Agentic AI Lens, consultada en 2026.
- Ong, I. et al., RouteLLM: Learning to Route LLMs from Preference Data, ICLR 2025.
- Chen, L. et al., FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance, preprint, 2023.
- OpenTelemetry, Generative AI semantic conventions, especificación en evolución, consultada en 2026.
- NIST, Generative Artificial Intelligence Profile, 2024.