Crear catálogos de servicios estandarizados para infraestructura e IA

Las organizaciones pueden crear catálogos de servicios estandarizados transformando capacidades repetibles de infraestructura e IA en definiciones aprobadas con parámetros claros, responsables asignados, cuotas, reglas de aprobación, flujos de entrega, medición de consumo y ciclo de vida. La documentación de origen no define una página formal única bajo el nombre de catálogo de servicios, pero aporta las piezas fundamentales para construirlo.

El enfoque más sólido consiste en catalogar lo que los usuarios ya tienen autorización para solicitar: especificaciones estándar de computación, provisión de bare metal, servicios de almacenamiento y conectividad, plantillas de despliegue de modelos, servicios de inferencia, acceso a API, modificaciones de cuota y otros flujos de trabajo repetibles.

¿Qué es un catálogo de servicios en este contexto?

Un catálogo de servicios es una relación controlada de prestaciones que los usuarios pueden solicitar o consumir. En infraestructura, un elemento del catálogo puede representar un recurso de computación, un servidor bare metal, una asignación de almacenamiento, un servicio de red dedicado o un cambio de cuota. En servicios de IA, puede corresponder a un despliegue de modelo aprobado, una instancia de inferencia, una API de modelo, un servicio de base de conocimiento o un servicio basado en agentes.

El elemento del catálogo oculta detalles técnicos prescindibles para el usuario final. El usuario selecciona el servicio y los parámetros autorizados, mientras la plataforma aplica las políticas de gobernanza y la lógica de entrega. El sistema respalda este esquema mediante especificaciones de recursos estandarizadas, plantillas, flujos de trabajo, publicación de servicios y medición del consumo.

¿Por qué estandarizar las solicitudes de infraestructura?

La estandarización reduce el trabajo manual puntual y desordenado. Sin un catálogo de servicios, las solicitudes de infraestructura suelen llegar en texto libre: "Por favor, facilitadme un servidor con GPU potente".

Ese tipo de petición abre múltiples interrogantes posteriores. ¿Qué acelerador y cuántas unidades? ¿Cuánta memoria y por cuánto tiempo? ¿A qué proyecto y cuota debe imputarse? ¿Qué sistema operativo y qué configuración de red requiere?

Un elemento de catálogo estandarizado convierte esa cadena de preguntas en campos estructurados. El modelo de planificación de la plataforma ya emplea especificaciones estándar de recursos para gestionar capacidad heterogénea de GPU y NPU, lo que constituye la base adecuada.

¿Qué debe contener un elemento de cómputo en el catálogo?

Un elemento de computación puede definir la capacidad del recurso en lugar de una máquina física concreta. Los parámetros contemplados incluyen:

• Tipo de acelerador
• Número de aceleradores
• CPU
• Memoria
• Tarjeta completa o particionada
• Tenant
• Proyecto
• Cuota
• Prioridad

La plataforma no impone un esquema universal de catálogo. Una entrada funcional debe identificar también al responsable del servicio, la política de aprobación, el criterio de medición del consumo y el proceso de expiración o devolución.

El solicitante debe comprender con claridad qué recibe y bajo qué gobernanza opera, mientras que el equipo de infraestructura debe saber con precisión cómo se traslada la petición al conjunto de recursos disponibles.

¿Cómo deben figurar los aceleradores heterogéneos en el catálogo?

Conviene presentar especificaciones de recursos homologadas manteniendo la compatibilidad real con los modelos y fabricantes subyacentes. Como la plataforma admite la agrupación de aceleradores heterogéneos en un mismo pool, el catálogo evita que cada usuario deba conocer al detalle las particularidades de cada fabricante de hardware. Aun así, debe reflejar las diferencias de rendimiento y arquitectura relevantes para cada carga de trabajo.

Un servicio estandarizado puede definir la clase de recurso, el volumen de memoria, si se entrega como unidad completa o fraccionada y el tipo de carga de trabajo compatible. A continuación, el programador de tareas asigna la petición al hardware operativo que cumpla los requisitos.

Respecto a la gestión técnica de recursos, cómo pueden las empresas gestionar GPU y NPU de múltiples fabricantes en una misma plataforma explica por qué deben coexistir la estandarización y el detalle del hardware.

¿Qué debe incluir un servicio de bare metal en el catálogo?

El flujo de aprovisionamiento bare metal ofrece un servicio estandarizado bien definido. Un elemento del catálogo puede fijar la gama de hardware aprobada, el sistema operativo, el conjunto de controladores, el agente de monitoreo, la función dentro del clúster y el perfil de red.

La solicitud ingresa en el flujo de trabajo, la plataforma comprueba el servidor físico, ejecuta la provisión, valida el estado de salud tras la instalación y registra el resultado. De este modo, la clásica petición de "montadme un servidor" se convierte en un servicio de entrega predecible.

En cuanto a los pormenores del despliegue, el artículo sobre cómo funciona el aprovisionamiento automatizado bare metal para servidores físicos, sistemas operativos, controladores GPU y agentes de monitoreo detalla todo el proceso.

¿Cómo debe integrarse el almacenamiento en el catálogo?

Los servicios de almacenamiento se pueden estandarizar a partir de los parámetros que la plataforma puede controlar. Dado que el sistema abarca gestión de almacenamiento, capacidad, rendimiento, cuotas y uso efectivo, una entrada de catálogo para almacenamiento puede definir el tipo de servicio, la capacidad asignada, el tenant o proyecto, la cuota correspondiente, los requisitos de rendimiento cuando proceda y su ciclo de vida.

La documentación de referencia no detalla una interfaz formal única para almacenamiento en el catálogo. El principio aplicable consiste en convertir las reglas de asignación repetitivas en definiciones estándar de servicio, criterio válido también para el resto de recursos de infraestructura.

¿Cómo deben presentarse los servicios de red?

La plataforma gestiona circuitos dedicados y topologías de red. Un catálogo de red permite estandarizar peticiones como conexiones privadas entre centros, ajustes de ancho de banda, permisos de acceso a la red o perfiles de conectividad homologados. El catálogo concreto dependerá del modelo operativo de red de cada organización.

El elemento del catálogo debe vincular la petición con su responsable, el circuito u objeto de red afectado, la aprobación requerida, su coste, el flujo de entrega y la monitorización asociada. Esto garantiza que la información operativa y la gestión económica permanezcan alineadas.

¿Cómo debe figurar el despliegue de modelos en el catálogo?

La capa de MaaS utiliza plantillas de despliegue, lo que sitúa la puesta en producción de modelos como una opción idónea para el catálogo. Un elemento del catálogo puede contemplar:

• Modelo aprobado
• Versión homologada del modelo
• Plantilla de despliegue
• Especificación de recursos
• Proyecto
• Política de réplicas o escalado
• Nivel de servicio

El usuario escoge una combinación autorizada, la plataforma levanta las instancias de inferencia y la pasarela de servicios publica el endpoint correspondiente. El mecanismo opera como un servicio de catálogo completo, aunque el sistema no lo denomine formalmente así.

¿Cómo deben ofrecerse las API de modelos?

La pasarela de API establece una frontera de servicio estable y controlada. Una entrada de catálogo para una API de modelo puede definir:

• Servicio de modelo
• Requisitos de acceso por tenant
• Proyecto
• Política de claves de API
• Cuota
• Límite de tasa (rate limit)
• Política de fallback
• Definición de medición de consumo

La capa de servicios de modelos gestiona claves, límites de tasa, cuotas, enrutamiento, contingencias de fallback y medición de Tokens consumidos. Esos controles operativos son los que otorgan utilidad real a un catálogo de servicios API. La ficha del catálogo debe describir el servicio gobernado manteniendo oculta la topología interna de inferencia.

¿Cómo deben presentarse los servicios de agentes de IA?

La capa de orquestación de agentes permite publicar una orquestación como servicio, de manera que un agente homologado puede incorporarse como elemento del catálogo. El usuario puede conocer la finalidad del agente, su versión, ámbito funcional, alcance de permisos y estado operativo.

El sistema monitoriza además el volumen de llamadas, la latencia, la tasa de éxito y los registros con fallo. Estas métricas operativas permiten constatar si el elemento del catálogo rinde adecuadamente y justifica mantenerse publicado.

¿Cómo deben asociarse las cuotas a los elementos del catálogo?

Las cuotas deben formar parte de la política de asignación y permisos. La plataforma admite cuotas tanto por tenant como por proyecto. En un elemento de computación, la cuota limita el volumen de recursos que un proyecto puede solicitar; en un servicio de modelo, restringe el consumo conforme a las políticas fijadas en la pasarela.

Por consiguiente, el catálogo debe clarificar quién tiene acceso, cuánto puede consumir y qué ocurre al alcanzar el límite. El solicitante no debería enterarse de las restricciones de cuota solo cuando la petición sea rechazada.

¿Cómo deben articularse las aprobaciones?

Las aprobaciones deben modularse en función del coste, el riesgo y el ámbito de responsabilidad. El motor de flujos de trabajo de la plataforma admite aprobaciones dinámicas y en varios niveles, lo que permite fijar reglas específicas según el elemento. Por ejemplo, una solicitud habitual de computación menor dentro de cuota puede seguir una vía ágil y automatizada, mientras que una ampliación sustancial de capacidad requerirá el visto bueno de un responsable. Los accesos a datos sensibles exigirán la autorización de seguridad, y las modificaciones en infraestructuras de producción demandarán la conformidad de operaciones.

El sistema no impone estas políticas de forma rígida; proporciona los mecanismos de flujo para que cada organización configure la lógica de aprobación oportuna en cada servicio.

¿Cómo debe incluirse el contexto de precios o costes?

La plataforma registra horas de uso por tarjeta, consumo de Tokens, energía, coste por proyecto y coste por tenant, lo que permite asociar cada elemento del catálogo a una definición de medición formalmente aprobada.

El sistema no obliga a mostrar un precio previo en cada solicitud, si bien permite rastrear con precisión el consumo tras la entrega. En servicios internos maduros, disponer del coste unitario histórico ayuda a los responsables a evaluar las implicaciones de optar por una especificación de recursos frente a otra.

Con independencia de lo que se muestre en pantalla, conviene utilizar los mismos criterios de coste que figuran en los paneles oficiales de operaciones y facturación.

¿Cómo debe definirse la responsabilidad de cada servicio?

Cada elemento del catálogo debe contar con un responsable operativo asignado. Entre los posibles encargados figuran el equipo de infraestructura, el de redes, el de almacenamiento, el de plataforma de IA, el responsable del servicio de modelos o el equipo de seguridad.

La base de datos del sistema integra usuarios, servicios, activos y actividades en un modelo de relaciones unificado. Esto permite asociar el elemento del catálogo con el equipo encargado de su entrega y soporte; así, ante una incidencia, el sistema identifica de inmediato al responsable correspondiente.

¿Cómo debe funcionar el ciclo de vida de un elemento del catálogo?

La definición de un servicio debe disponer de su propio ciclo de vida, transitando por los estados de borrador, aprobado, publicado, actualizado, obsoleto y retirado.

La plataforma no fija con carácter vinculante estas fases exactas. Sin embargo, gestiona versiones de modelos, plantillas de despliegue, versiones de flujos de trabajo, ciclo de vida de activos y publicación de servicios. La deducción técnica es que los servicios estandarizados exigen control de versiones y retirada programada para evitar que definiciones desfasadas continúen accesibles indefinidamente. Los estados del ciclo de vida deben ajustarse a los procesos internos de cada empresa.

¿Cómo se conectan los elementos del catálogo con la automatización?

El elemento del catálogo debe enlazar con el flujo de trabajo o la plantilla aprobada que ejecuta su provisión, y es aquí donde el catálogo trasciende la mera documentación. El motor de flujos puede activar la planificación de recursos, scripts de automatización, provisión bare metal y modificaciones de cuota. Por su parte, la capa de MaaS puede desencadenar el despliegue del modelo y la publicación del servicio.

En esta arquitectura, el elemento del catálogo actúa como puerta de entrada y el flujo de trabajo opera como motor de entrega, mientras que el planificador y los sistemas de automatización constituyen la capa de ejecución.

¿Cómo debe vincularse el catálogo con la medición de consumo?

Cada servicio entregado debe generar los mismos registros de uso que emplea la plataforma de operaciones. Un servicio de computación genera registros de horas de uso por tarjeta; una API de modelo genera consumo de Tokens; un servicio de almacenamiento genera métricas de capacidad ocupada; y un circuito dedicado genera registros de servicio y costes.

Por tanto, el catálogo no precisa un vocabulario de facturación propio. Reutiliza el mismo esquema de titularidad por proyecto y tenant que ya utiliza la medición de consumo.

Para profundizar en la consolidación de costes y responsabilidades, el artículo sobre cómo pueden las empresas asignar costes de infraestructura a departamentos, proyectos, aplicaciones o clientes detalla cómo deben preservarse esas relaciones.

¿Qué debería contener el primer catálogo?

Conviene arrancar con servicios repetitivos, de volumen representativo y gobernanza clara. Una primera versión del catálogo basada en la plataforma puede incluir:

• Solicitud estándar de recursos GPU
• Provisión de nodo bare metal para IA
• Asignación de almacenamiento
• Modificación de cuota de proyecto
• Despliegue de modelo homologado
• Servicio de API de inferencia
• Servicio basado en agentes

Esto basta para validar el modelo organizativo. No intentes catalogar desde el principio cada operación de infraestructura.

Un ejemplo de plataforma que reúne las especificaciones, plantillas, flujos de trabajo, servicios de MaaS, cuotas y medición necesarias para articular este catálogo es Sensaka.

Si tuviera que diseñar un primer catálogo de servicios, seleccionaría las peticiones que ya llegan de forma reiterada a través del sistema de tickets y empezaría por estandarizar esas. Cada servicio debe contar con parámetros aprobados, un responsable identificado, una regla de aprobación, un flujo de ejecución y una definición de medición. Si falta alguno de estos elementos, la entrada seguirá siendo simple documentación.