Claves API, límites de tasa, cuotas, enrutamiento y fallback para servicios de IA

Las organizaciones pueden gestionar claves API, límites de tasa, cuotas, enrutamiento y fallback situando esos controles en un gateway unificado de servicios de modelos. El diseño de la fuente expone una interfaz única hacia las aplicaciones mientras admite múltiples canales internos de modelos, centralizando en ese límite la gestión de claves, la atribución a proyectos, el enrutamiento de tráfico, las cuotas por tenant, los límites de tasa, la degradación basada en el estado de salud, la medición de tokens y la auditoría de llamadas.

Esto mantiene los cambios operativos al margen del código de las aplicaciones. Cambiar un modelo de backend, ajustar los pesos del tráfico o retirar un canal con problemas se convierte en una operación de servicio gobernada, sin necesidad de modificar ninguna aplicación cliente.

¿Por qué usar un gateway unificado para servicios de modelos de IA?

Un gateway unificado establece un límite de servicio estable. El diseño del gateway de la fuente describe una interfaz única hacia el exterior y múltiples canales hacia el interior, con canales conmutables y pesos de enrutamiento centralizados, límites de tasa y fallback.

Sin esa capa, las aplicaciones suelen llamar directamente a instancias de inferencia individuales o a endpoints específicos de modelos, lo que genera un fuerte acoplamiento con el backend. Si el modelo interno cambia, es posible que haya que modificar la configuración de la aplicación, y si un canal deja de responder bien, cada aplicación se ve obligada a implementar su propia lógica de contingencia.

La fuente expone el valor de gestión de forma directa: gracias al gateway, cambiar de modelo pasa a ser una acción de operaciones en lugar de una tarea de desarrollo.

¿Qué representa una clave API en este modelo?

Una clave API identifica y controla el acceso al gateway de servicios de modelos. La página de operaciones de tokens de la fuente gestiona el listado de claves, el estado de cada clave y la vinculación con etiquetas de proyecto.

Eso convierte a la clave en un elemento de atribución además de una credencial. Las llamadas al servicio llegan a través de la clave, y el gateway puede asociar cada petición con el proyecto y el tenant adecuados. Esta asociación alimenta las cuotas, los límites de tasa, la medición de tokens, la imputación de costes y la auditoría de llamadas; por tanto, una clave sin metadatos de propiedad debilita toda la cadena operativa.

¿Por qué las claves API deben asociarse a etiquetas de proyecto?

El consumo necesita un responsable claro, y la fuente define esto como una regla operativa estricta. Si la clave no está vinculada a una etiqueta de proyecto, el uso no puede imputarse a un proyecto concreto, lo que genera problemas en los informes de tokens, el cálculo de costes por proyecto, los reportes de tenants, la conciliación de facturación y la gestión de cuotas.

La identidad del proyecto debe fijarse en el momento en que se emite la clave, en vez de intentar deducirla a final de mes según la aplicación que haya utilizado una clave compartida genérica.

En cuanto a la atribución de costes, cómo las empresas pueden rastrear los costes de infraestructura hacia departamentos, proyectos, aplicaciones o clientes explica por qué la propiedad debe registrarse desde el nivel de consumo en bruto.

¿Qué función cumple el límite de tasa?

El límite de tasa controla la rapidez con la que una clave, tenant o servicio puede enviar peticiones según la política configurada. El gateway de la fuente admite explícitamente la limitación de tasa por clave, lo que protege la capacidad del servicio ante ráfagas repentinas o clientes descontrolados.

Limitar la tasa también aporta previsibilidad al comportamiento. La fuente indica que las peticiones que superen el límite deben devolver un resultado esperado en lugar de fallar de manera imprevista.

Los valores exactos de tasa no se definen en la fuente. Deben determinarse según la capacidad del servicio, los acuerdos con los tenants, la latencia del modelo, la relevancia para el negocio y el patrón de ráfagas. Lo esencial es que el gateway aplique la regla con coherencia.

¿Cuál es la diferencia entre un límite de tasa y una cuota?

Un límite de tasa regula el ritmo de las peticiones. Una cuota controla cuánto puede consumir un tenant o proyecto durante un periodo definido o según una política de recursos. El gateway de la fuente gestiona las cuotas por tenant y los límites de tasa por clave como controles independientes.

Esa separación es fundamental. Un proyecto puede tener autorización para realizar un millón de peticiones al mes pero estar limitado a un número moderado de peticiones por segundo. O bien, disponer de una cuota mensual amplia pero con un límite estricto de ráfaga para proteger la capacidad de inferencia compartida.

La fuente no define un periodo universal de cuota ni una unidad fija para el límite de tasa, por lo que cada organización debe establecer esas políticas según sus necesidades.

¿Cómo deben funcionar las cuotas por tenant?

Las cuotas por tenant deben aplicarse de forma coherente en el límite del servicio. El gateway de servicios de modelos de la fuente incluye gestión de cuotas por tenant, lo que permite que un servicio multi-tenant comparta la misma infraestructura de inferencia manteniendo visibles los límites de consumo.

Cuando un tenant supera su cuota, el sistema debe responder de forma predecible. El gateway no debe permitir un uso ilimitado del servicio solo porque quede capacidad física de GPU disponible; este es el equivalente en la capa de servicios a las cuotas de computación.

Para entornos compartidos de GPU, cómo varios equipos o tenants pueden compartir de forma segura una infraestructura costosa de GPU explica cómo las fronteras entre tenants y proyectos se extienden más allá de la capa de servicios de modelos.

¿Qué estrategias de enrutamiento admite la fuente?

El gateway de la fuente admite enrutamiento ponderado, enrutamiento por capacidades del modelo y distribución diferenciada de tráfico para canales canary. El enrutamiento ponderado permite repartir el tráfico entre varios canales. El enrutamiento por capacidades hace que el servicio elija un canal que soporte el modelo o la función solicitada. El enrutamiento canary permite que un canal nuevo reciba un volumen limitado de tráfico antes de un despliegue más amplio.

La fuente no detalla un algoritmo de enrutamiento específico. El requisito operativo es que la política de enrutamiento esté centralizada y resulte visible.

¿Para qué sirve el enrutamiento ponderado?

El enrutamiento ponderado resulta útil cuando varios canales saludables pueden atender el mismo servicio y el operador desea regular la proporción de tráfico asignada a cada uno. Por ejemplo, el canal A puede recibir la mayor parte de las peticiones mientras el canal B procesa una fracción menor para validación. La fuente no impone porcentajes concretos; esa es una decisión propia de cada despliegue.

Este mismo mecanismo facilita despliegues progresivos o el equilibrado de capacidad. Desde la perspectiva operativa, la ventaja es que la aplicación sigue apuntando a un único endpoint estable mientras el gateway ajusta la distribución interna.

¿Cómo encaja el tráfico canary en el gateway?

El gateway de la fuente proporciona una distribución de tráfico independiente para canales canary, de modo que una nueva versión de modelo o un canal de inferencia pueda recibir una porción controlada del tráfico real. Antes de incrementar su cuota, el operador puede monitorizar la tasa de éxito, la latencia, el rendimiento de tokens, el estado de salud y el comportamiento ante errores.

Si el canal canary responde de forma anómala, su tráfico puede reducirse o retirarse sin necesidad de alterar la aplicación que realiza las llamadas.

Respecto al control de cambios general, qué es el despliegue canary en operaciones de infraestructura y cómo reduce el riesgo operativo explica cómo una exposición inicial reducida acota el radio de impacto.

¿Cómo debe funcionar el fallback?

El fallback debe ser una política explícita del gateway que defina qué ocurre cuando el canal preferente no puede atender la petición. El gateway de la fuente incluye degradación automática cuando falla el canal principal, registro de eventos de degradación y retorno automático al recuperarse el servicio.

Según el despliegue, el destino de fallback puede ser otro canal de modelos aprobado o una instancia alternativa del mismo servicio. La fuente no asume que todos los modelos sean intercambiables, por lo que el fallback solo debe configurarse cuando la alternativa cumpla con el comportamiento esperado para ese servicio.

¿En qué consiste la degradación elegante?

La degradación elegante implica que el servicio permanece disponible en un modo reducido o alternativo previamente aprobado cuando la ruta preferente falla. La fuente denomina a esto degradación y fallback.

El comportamiento posible depende de la arquitectura corporativa. La plataforma puede desviar el tráfico hacia otro canal aprobado, recortar ciertas funciones accesorias del servicio o devolver una respuesta predecible por falta de capacidad. La fuente no detalla cada modalidad de fallback, pero sí contempla políticas centralizadas, registro de incidencias y reconexión automática tras la recuperación.

¿Cómo debe influir el estado del canal en el enrutamiento?

El gateway debe basarse en el estado de salud para determinar si un canal sigue siendo apto para recibir tráfico. La fuente indica de manera expresa que los canales no saludables se retiran de forma automática, por lo que la capa de tráfico no debe seguir enviando peticiones a un servicio de inferencia con fallos confirmados.

Los datos de salud pueden proceder de la instancia de inferencia y de la capa de monitoreo del servicio. La página de instancias de modelos monitoriza el estado de la instancia, las réplicas, la asignación de nodos y tarjetas, el resultado de los health checks y si el estado es en ejecución, degradado o detenido; el gateway puede aprovechar esa información para proteger a las aplicaciones cliente.

En lo relativo a la conmutación automática de tráfico, cómo una pasarela de servicios puede desviar automáticamente el tráfico cuando un modelo o servicio de inferencia falla describe toda la secuencia de eventos.

¿Cómo debe gestionarse la recuperación?

El gateway de la fuente regresa de forma automática al canal principal una vez recuperado, por lo que la recuperación debe tratarse como una transición de estado en lugar de requerir cambios manuales en las aplicaciones. Un procedimiento adecuado de recuperación confirma que el canal vuelve a estar sano antes de reanudar el envío de tráfico.

La fuente no estipula el número exacto de comprobaciones de salud ni el tiempo de espera para la reconexión; esos parámetros deben ajustarse a cada servicio. El retorno en sí debe estar controlado y registrado, evitando que un canal inestable entre y salga continuamente de servicio sin que nadie lo perciba.

¿Cómo encaja la medición de tokens en el gateway?

El gateway representa la frontera del servicio donde el consumo puede medirse con regularidad. La página de operaciones de tokens de la fuente agrega el uso por tenant, modelo y proyecto. Asimismo, utiliza una preagregación horaria y puede alimentar informes mensuales.

La clave vincula la petición a un proyecto, la ruta identifica el modelo o canal, y el gateway registra la llamada. En conjunto, generan un registro de uso ordenado tanto para la operativa como para el control de costes.

Para conocer la cadena completa de MaaS, qué es MaaS y cómo interactúan los repositorios de modelos, las instancias de inferencia, las pasarelas API y la medición de tokens explica cómo se conectan todos estos componentes.

¿Qué debe registrar la auditoría de llamadas?

La fuente contempla la trazabilidad por llamada y la investigación de peticiones anómalas. Cada llamada al servicio debe conservar suficiente información identificativa para saber qué clave la originó, qué proyecto poseía la clave, qué modelo o canal atendió la petición, en qué momento ocurrió, si tuvo éxito y si se activó alguna inspección de seguridad.

La fuente no incluye un esquema completo de campos en su presentación. El requisito operativo radica en asegurar la trazabilidad completa desde quien realiza la llamada hasta el resultado del servicio.

¿Cómo deben rotarse o desactivarse las claves API?

La fuente gestiona el listado y el estado de las claves, pero no describe un procedimiento minucioso de rotación. Un diseño seguro basado en la fuente aborda el ciclo de vida de las claves como un proceso de acceso regulado, en el que la plataforma debe poder generar, habilitar y deshabilitar claves, asociarlas a un proyecto y auditar su utilización.

Cualquier intervalo de rotación adicional o método de gestión de secretos debe ajustarse al estándar de seguridad corporativo. La fuente no establece un periodo de rotación universal, por lo que no conviene inventarlo.

¿Qué debe mostrar el panel del gateway?

Una vista útil del gateway de servicios de modelos puede mostrar el endpoint externo del servicio, los canales internos disponibles, el estado de salud de cada canal, los pesos de enrutamiento, el canal canary, el estado de las claves, las políticas de límites de tasa, las cuotas por tenant, el estado actual de degradación, los eventos recientes de fallback, el consumo de tokens, la tasa de éxito de las llamadas y los registros de auditoría. El diseño de la versión 3.2 de la fuente abarca estas funciones distribuidas entre las páginas del gateway y las de operaciones de tokens.

Un ejemplo de plataforma que reúne esta cadena de gobernanza de servicios de modelos es Sensaka.

A la hora de definir las políticas del gateway, resulta indispensable fijar cuatro principios en todo servicio de modelos en producción: que cada clave tenga un propietario, que cada cliente tenga un límite predecible, que cada ruta tenga una regla de salud y que cada fallback cuente con un destino homologado. Cuando estas reglas están claras, cambiar un modelo o perder una instancia de inferencia deja de ser una emergencia en las aplicaciones y pasa a ser un evento operativo bajo control.