¿Qué es MaaS? Repositorios, inferencia, API Gateways y medición de tokens

MaaS, o Model as a Service, transforma un modelo de IA en un servicio operable al que las aplicaciones pueden invocar mediante una interfaz controlada. La cadena operativa resulta directa: el repositorio de modelos gestiona el activo del modelo, las instancias de inferencia ejecutan el modelo, el API gateway expone y controla el acceso, y la medición de tokens registra cómo se consume el servicio.

El cambio consiste en pasar de "tenemos un archivo de modelo" a "operamos un servicio de producción". En cuanto un modelo entra en producción, necesitas control de versiones, reglas de despliegue, salud del servicio, enrutamiento, cuotas, claves de acceso, registros de uso, reversión (rollback) e imputación de costes. MaaS es la capa que articula todas esas actividades.

¿Qué es MaaS?

Model as a Service proporciona modelos de IA como servicios gestionados y accesibles mediante llamadas, de modo que cada usuario o equipo de aplicación no tenga que desplegar y operar el modelo por su cuenta.

Una plataforma MaaS suele ubicarse entre la infraestructura de cómputo subyacente y las aplicaciones que consumen las capacidades de IA. Por debajo se encuentran los recursos de GPU o NPU, sistemas operativos, contenedores, programadores, almacenamiento y redes. En su interior se sitúan los activos de modelos, plantillas de despliegue, instancias de inferencia, enrutamiento de servicios, controles de uso y medición. Por encima interactúan aplicaciones, agentes, sistemas de negocio, desarrolladores y usuarios finales.

Una capa MaaS útil debe responder a varias preguntas simultáneas. ¿Qué versión del modelo está aprobada para producción, dónde se ejecuta y cuánto cómputo tiene asignado? ¿A qué endpoint deben llamar las aplicaciones y quién tiene autorización para hacerlo? ¿Cuánto tráfico recibe y cuántos tokens de entrada y salida se procesan? ¿Cuál es la tasa de éxito y cuánto cuesta el servicio?

Si esas preguntas se dispersan en sistemas independientes, operar el modelo resulta mucho más difícil que limitarse a desplegarlo.

¿Qué función cumple un repositorio de modelos?

Un repositorio de modelos gestiona el modelo como un activo controlado. Como mínimo, debe registrar el nombre del modelo, versión, origen, estado, responsable y la información requerida para desplegarlo. Un repositorio más robusto puede almacenar además resultados de evaluación y emplearlos como criterio para la puesta en producción, lo que separa el hecho de que "un modelo exista" de que "un modelo esté aprobado para servicio".

El modelo operativo de origen trata además los modelos y las bases de conocimiento como objetos diferenciados. Esto resulta ventajoso porque un mismo modelo puede abastecer a varias bases de conocimiento, y una base de conocimiento puede evaluarse frente a diversos modelos. Mantenerlos separados evita acoplar la capa de recuperación directamente en el propio activo del modelo.

El repositorio debe conservar asimismo el historial de versiones. Si se despliega la versión de modelo 2.3 y más adelante causa incidencias de calidad o latencia, el equipo de operaciones necesita saber qué versión anterior puede restaurarse. Aquí es donde la gestión del repositorio se conecta directamente con el despliegue y la reversión.

¿Qué es una instancia de inferencia?

Una instancia de inferencia es un despliegue en ejecución de un modelo que recibe peticiones y genera respuestas. La instancia consume recursos de cómputo y, según el modelo y el diseño del servicio, puede ejecutarse en un acelerador, en varios aceleradores, en un acelerador particionado o sobre recursos de CPU.

El activo del modelo y la instancia en ejecución son entidades distintas. Una misma versión de modelo puede contar con varias instancias de inferencia, y esas instancias pueden dar servicio a diferentes entornos, inquilinos, regiones, niveles de rendimiento o segmentos de tráfico.

Cada instancia debe reflejar su estado operativo: si está activa o detenida, su especificación de recursos asignada, versión del modelo, recuento de réplicas, estado del endpoint, salud operativa, carga actual, tasa de éxito, latencia y rendimiento de tokens.

Esa distinción es imprescindible para una operativa segura. Si una instancia se degrada, puedes desviar el tráfico de ella sin retirar el modelo del repositorio. Si despliegas una versión nueva, puedes crear instancias adicionales antes de dirigirles tráfico de producción.

¿Cómo encajan las plantillas de despliegue en MaaS?

Las plantillas de despliegue aportan repetibilidad a la entrega de modelos. En lugar de configurar cada servicio de inferencia de forma manual, la plataforma puede definir una plantilla reutilizable que especifique el cómputo necesario, el entorno de ejecución, la imagen de contenedor, la versión del modelo, el número de réplicas, la exposición de red, la política de escalado y otros ajustes operativos.

Las plantillas reducen la desviación de configuración y establecen un punto claro de revisión. Una organización puede autorizar una plantilla de producción para una familia concreta de modelos y restringir las modificaciones a campos previamente controlados.

Esto resulta muy útil cuando distintos modelos exigen perfiles de recursos variados. Un modelo pequeño de embeddings puede ejecutarse de forma eficiente en un acelerador compartido, mientras que un modelo de lenguaje extenso puede requerir varios aceleradores de gran capacidad de memoria. Una plantilla permite al usuario solicitar el servicio sin tener que seleccionar dispositivos individuales a mano, aunque el programador subyacente deba encontrar hardware compatible.

En cuanto a la programación de estos recursos, la guía sobre reserva y programación de recursos de GPU en Kubernetes explica cómo las clases de recursos, las cuotas, la topología y el estado de salud influyen en la asignación.

¿Cómo funcionan el canary release y el rollback en servicios de modelos?

El canary release envía una proporción limitada de tráfico a un nuevo modelo o despliegue antes del lanzamiento completo, minimizando así el impacto de una versión defectuosa. Por ejemplo, una nueva versión de modelo puede arrancar con una cuota pequeña de tráfico mientras la plataforma vigila la tasa de éxito, la latencia, el rendimiento de tokens y las respuestas de las aplicaciones. Si la nueva versión se comporta con normalidad, la cuota de tráfico puede incrementarse. Si presenta anomalías, el tráfico regresa a la versión anterior.

Por tanto, una reversión involucra a más elementos que el repositorio de modelos. Implica también al gateway del servicio y a las instancias de inferencia activas. El repositorio conoce las versiones autorizadas, la capa de despliegue arranca las instancias requeridas, el gateway gestiona qué versión recibe peticiones, la capa de monitorización evalúa el impacto y el flujo de trabajo registra la modificación. Ese circuito cerrado es lo que convierte la entrega de modelos en una verdadera capacidad operativa.

¿Por qué necesita MaaS un API gateway?

El API gateway proporciona a las aplicaciones un único punto de entrada gestionado hacia los servicios de modelos. Sin un gateway, cada aplicación tendría que conocer la dirección y el comportamiento de cada instancia individual de modelo. Eso genera un acoplamiento estrecho: si una instancia de modelo se traslada, escala o sustituye, la configuración de las aplicaciones se vería afectada.

Una pasarela oculta esa topología interna. Expone un endpoint de servicio estable y enruta las solicitudes hacia el modelo o la instancia adecuada detrás de él. También aplica controles operativos, como validación de claves de API, identificación de inquilinos, límites de tasa, cuotas, reglas de enrutamiento, selección de modelo, políticas de fallback, degradación elegante, registro de peticiones y auditoría de invocaciones.

Con un gateway, cambiar de modelo se convierte en una acción operativa en lugar de un cambio en el desarrollo de aplicaciones. Si el Modelo A deja de estar disponible, el gateway puede redirigir una clase autorizada de peticiones hacia el Modelo B sin requerir el redespliegue de cada aplicación cliente.

¿Cómo funciona el enrutamiento multimodelo?

El enrutamiento multimodelo aprovecha los atributos de la petición y las políticas definidas para seleccionar qué modelo o instancia debe atender una llamada. Una ruta sencilla puede basarse en el endpoint. Una ruta avanzada puede tener en cuenta el inquilino, el modelo solicitado, la política del proyecto, la clase de tráfico, la salud del modelo, el coste o las reglas de fallback.

Sea cual sea la ruta, debe resultar explicable. La plataforma debe ser capaz de justificar por qué una petición se dirigió a un modelo específico, algo fundamental para la resolución de problemas y la facturación. Si dos versiones de modelo presentan características de coste o calidad distintas, cambios silenciosos de enrutamiento pueden generar informes de uso desconcertantes; por eso las políticas de enrutamiento pertenecen a la misma cadena operativa que la medición y la auditoría.

¿Qué implica la degradación elegante para MaaS?

La degradación elegante consiste en mantener un nivel de servicio aceptable cuando el modelo preferido o la capacidad deseada no están disponibles. El comportamiento exacto depende de la aplicación. Una solicitud puede dirigirse a un modelo aprobado más pequeño, un nivel de servicio inferior puede aceptar mayor latencia, una función no crítica puede desactivarse temporalmente o una cola puede absorber el tráfico de forma transitoria.

El gateway respalda esas políticas, pero la regla de negocio debe fijarla el responsable del servicio. Los modelos no son perfectamente intercambiables: un modelo alternativo puede diferir en calidad de respuesta, límites de contexto, comportamiento de seguridad o coste. Por tanto, la plataforma debe tratar el fallback como una política explícita y no como una decisión de enrutamiento improvisada.

¿Qué es la medición de tokens?

La medición de tokens registra el volumen de entrada y salida procesado por el modelo a través del servicio. El modelo operativo de origen adopta el token como la unidad de medida para la entrada y la salida de los modelos.

Un registro de uso útil debe identificar mucho más que el simple recuento de tokens. Conecta el consumo con la marca temporal, el proyecto, el inquilino, la clave de API o identidad del llamante, el modelo, la versión del modelo, el servicio de inferencia, los tokens de entrada, los tokens de salida, el resultado de la petición, la latencia y la regla de coste o facturación.

Eso transforma los datos brutos de uso en información operativa práctica. Puedes determinar qué proyecto consumió más tokens, qué modelo generó el mayor coste de servicio y si un repunte de consumo se debió a más peticiones o a prompts más extensos. Esos mismos registros nutren los informes de cuotas y costes.

¿Cómo se conecta la medición de tokens con la facturación?

La medición de tokens permite respaldar la facturación externa o el reparto interno de costes cuando la definición de medición coincide con la definición comercial o contable. Esa concordancia resulta determinante: si el gateway cuenta los tokens de una forma mientras el sistema de facturación aplica otra regla, los usuarios cuestionarán los importes.

Conviene definir si la facturación contabiliza tokens de entrada, de salida o ambos, y cómo se tratan las llamadas fallidas. Define cómo se gestionan los resultados en caché si el servicio los soporta, cómo se computan los reintentos y qué zona horaria y periodo de liquidación corresponden. Aplica después esa misma definición en paneles de uso, facturas, informes de proyectos y análisis de costes.

Para comprender el modelo integral de costes, la guía sobre cómo las empresas pueden medir el coste de infraestructura de IA por hora de GPU, token, proyecto, inquilino o modelo profundiza en la combinación del consumo de servicios con el de la infraestructura física.

¿Cómo se vinculan las instancias de inferencia con la medición de tokens?

Vincular las instancias de inferencia con el uso de tokens permite a la plataforma comparar el resultado del servicio con los recursos de cómputo que lo produjeron.

Supongamos que dos instancias atienden el mismo modelo. La Instancia A emplea cuatro aceleradores y genera 20 millones de tokens a lo largo de una hora. La Instancia B emplea cuatro aceleradores semejantes y genera 12 millones de tokens en esa misma hora. Eso no prueba por sí solo que la Instancia B sea ineficiente, ya que la variedad de peticiones y la longitud de las respuestas pueden variar, pero aporta al equipo de operaciones un punto de partida evidente.

Si añades latencia, tasa de éxito, tamaño de petición, energía, uso de aceleradores y versión de modelo, la plataforma puede indagar por qué dos despliegues análogos ofrecen resultados dispares. Esa es la ventaja de integrar la medición del servicio con la telemetría de la infraestructura.

¿Cómo debe abordar MaaS el escalado?

MaaS debe escalar la capacidad de inferencia en función de la demanda cuantificable del servicio y de la disponibilidad de recursos. Las señales pueden incluir concurrencia de peticiones, profundidad de cola, latencia, rendimiento de tokens, uso de aceleradores u otras métricas propias de la carga. El Horizontal Pod Autoscaler de Kubernetes permite ajustar réplicas de cargas de trabajo a partir de métricas de recursos o personalizadas cuando la arquitectura de la aplicación lo admite.

El servicio de modelos añade otra restricción, ya que una nueva réplica puede tardar tiempo en cargar los pesos del modelo antes de quedar lista para responder. La política de escalado debe prever ese tiempo de inicialización. Si la demanda crece más rápido de lo que las instancias tardan en arrancar, el servicio puede necesitar capacidad reservada. Si la demanda cae, la plataforma debe evitar mantener asignados aceleradores caros sin necesidad. Por ello, el escalado se mueve siempre en el equilibrio entre los SLO del servicio y el control de costes.

¿Qué debe mostrar un panel de operaciones de MaaS?

Un panel útil de MaaS debe presentar de forma conjunta oferta, demanda, calidad y costes del servicio. En oferta, muestra modelos, versiones aprobadas, instancias de inferencia, aceleradores asignados y capacidad disponible. En demanda, refleja llamadas, tokens de entrada, tokens de salida, concurrencia y tráfico por inquilino o proyecto. En calidad, incluye tasa de éxito, latencia, tiempo hasta el primer token en los casos oportunos y estado de cumplimiento de los SLO. En costes, aporta horas de acelerador, energía donde esté monitorizada y coste unitario por token.

Cada indicador principal debe permitir profundizar en los detalles. Si la tasa de éxito de tokens desciende, el operador debe ser capaz de localizar el modelo y la instancia correspondientes. Si el coste se incrementa, debe poder desglosar el proyecto, inquilino, modelo y cómputo que motivaron ese aumento.

Un ejemplo de plataforma desarrollada en torno a esta cadena integrada de servicios es Sensaka.

Al evaluar una arquitectura MaaS, plantearía una pregunta fundamental: ¿puede la plataforma trazar una llamada a la API de producción desde el cliente y el gateway hasta la versión del modelo, la instancia de inferencia, el cómputo subyacente, el registro de tokens y la traza de auditoría? Si la respuesta es afirmativa, MaaS opera como una verdadera capa funcional. Si es negativa, probablemente se trate de una acumulación de piezas sueltas para servir modelos.