Operar un modelo de lenguaje grande en un entorno de producción ya no se limita a entrenar, probar y desplegar el modelo, ni a supervisar paneles de datos. El sistema moderno puede conectar prompts, bases de datos vectoriales y fuentes de conocimiento, y después generar textos abiertos que se evalúan según el tono, la seguridad y la confianza, además de la precisión. De ahí que Daniel Bryant plantee, en un artículo publicado en el blog de CNCF, una pregunta práctica: ¿quién debería poseer el pipeline de IA?
El autor considera que la respuesta no consiste en conceder a LLMOps un reino separado, sino en integrarla en una plataforma de ingeniería bien organizada, que ofrezca las capacidades necesarias mediante las mismas interfaces que utilizan los equipos de desarrollo para el resto de las cargas de trabajo.
¿Qué se entiende por LLMOps?
LLMOps se refiere al conjunto de prácticas, herramientas y flujos de trabajo necesarios para desarrollar, desplegar y gestionar grandes modelos de lenguaje durante todo su ciclo de vida en producción. Este ciclo incluye la gestión de datos, la ingeniería de prompts, el ajuste fino, el despliegue y el servicio de inferencia, la supervisión y la evaluación, además de la seguridad y la gobernanza.
Según el análisis, LLMOps no representa simplemente un cambio de nombre de MLOps. Los grandes modelos de lenguaje son más costosos de ajustar y servir, y evaluar sus resultados es más difícil que reducir el rendimiento a una cifra clara de precisión. No basta con que el modelo sea preciso; también debe ser seguro y digno de confianza, características más complejas de medir.
Además, la operación del modelo no termina con el despliegue inicial. Los modelos pueden desviarse de su comportamiento anterior, los costes pueden aumentar, los prompts pueden dejar de funcionar como de costumbre y las integraciones con sistemas de gestión de relaciones con clientes o bases de conocimiento internas requieren un seguimiento continuo.
Un ciclo de vida que se cruza con la ingeniería de plataformas
El ciclo de LLMOps abarca desde la preparación de datos y la ingeniería de prompts —tratando los prompts como elementos versionables en lugar de textos temporales— hasta el ajuste fino de modelos fundacionales abiertos mediante bibliotecas como Hugging Face Transformers. También incluye el versionado de modelos y prompts y el seguimiento de su procedencia, la provisión de inferencia mediante endpoints respaldados por unidades de procesamiento gráfico y la supervisión basada en comentarios humanos para detectar la deriva y los costes.
Cada parte de este ciclo necesita infraestructura, controles de acceso y un entorno de ejecución, ámbitos que ya forman parte del alcance de la ingeniería de plataformas. Sin embargo, el autor distingue entre la naturaleza de ambos campos: la ingeniería de plataformas se centra en la infraestructura, mientras que MLOps se centra en los modelos. Por ello, no considera que la pregunta útil sea «¿quién posee el pipeline?», sino «¿quién posee cada capa y existe realmente una entidad que las coordine?».
El riesgo de crear una pila paralela
El análisis divide el panorama de la entrega de software entre los equipos de DevOps, que pueden verse desbordados por las solicitudes de despliegue; los equipos de ingeniería de plataformas, que construyen flujos estandarizados de autoservicio; y los equipos de MLOps, que crearon pilas paralelas porque las herramientas de DevOps no estaban diseñadas para gestionar versiones de datos o supervisar la deriva. Con la incorporación de LLMOps, podría aparecer una tercera pila independiente para prompts, bases de datos vectoriales y pipelines de RAG, alejada de la entidad responsable de la gobernanza.
El autor relaciona esta posibilidad con el problema de las «operaciones de IA ocultas». Un equipo podría crear su propio pipeline de RAG, conectado a una base de datos vectorial que no haya sido revisada, sin que quede claro para la entidad responsable qué está funcionando realmente. Según el análisis, el mayor riesgo operativo no reside únicamente en un chatbot que produzca alucinaciones, sino en que estas capacidades se propaguen fuera de la plataforma y permanezcan fuera del alcance de la visibilidad y el control.
El autor no propone ralentizar a los equipos para evitarlo, sino hacer que la plataforma sea capaz de satisfacer las solicitudes rápidamente, incorporando la gobernanza en el propio flujo de uso. La ausencia de un flujo preparado puede empujar a los equipos a desarrollar sus capacidades fuera de la plataforma, mientras que ofrecer un flujo estándar ayuda a devolverlas a un entorno gestionable.
LLMOps dentro de las capas de la plataforma
Bryant se basa en la concepción de plataformas de la documentación técnica sobre plataformas publicada por el grupo TAG App Delivery de CNCF, que divide el entorno en tres capas: los productos en la parte superior, las plataformas en el centro como la capa de integración razonablemente menos gruesa y los proveedores de capacidades en la parte inferior.
Según esta concepción, funciones como las tareas de ajuste fino, las bases de datos vectoriales, los registros de prompts y los endpoints de inferencia pueden tratarse como otra capacidad de la plataforma. Al igual que las demás, necesitan interfaces de programación, versiones y una propiedad claramente definida. El autor señala herramientas del ecosistema de CNCF que pueden respaldar este modelo: Backstage presenta los flujos estándar en la capa de producto, mientras que Crossplane ensambla la infraestructura en la capa inferior, y marcos como Kratix, KusionStack y KubeVela operan en el centro para ofrecer un pipeline de LLM mediante una interfaz de autoservicio similar a la del resto de los servicios.
Controles prácticos para la gobernanza del pipeline
El análisis propone que los equipos de plataformas adopten un conjunto de controles prácticos:
- Interfaces de programación gobernadas en lugar de scripts informales: las tareas de ajuste fino, el despliegue de prompts y los endpoints de inferencia deberían solicitarse mediante la misma interfaz de autoservicio utilizada para el resto de las necesidades de los desarrolladores.
- Aplicación de políticas en el momento de la solicitud: los límites de costes, las reglas de residencia de datos y los controles de acceso a los modelos deben comprobarse antes de iniciar la tarea, no después de que aparezca la factura de los servicios en la nube.
- Aprobación humana proporcional al impacto: no todos los prompts necesitan aprobación previa, pero un modelo que maneje datos personales de clientes o tome decisiones autónomas puede requerirla.
- Registro de auditoría claro: el registro debería responder a preguntas como qué cambió y por qué, tanto si el cambio afectó al modelo, al prompt o a los datos, y quién lo aprobó o qué fue lo que aprobó.
El autor concluye que un pipeline de LLM es otro consumidor automatizado de las capacidades de la plataforma y necesita las mismas garantías que recibe un desarrollador humano o un agente autónomo. Los equipos que tienen éxito con este modelo no eligen un bando en la disputa entre DevOps, la plataforma y MLOps, sino que tratan todo el pipeline como un producto versionable, supervisable y consciente de los costes, con ciclos continuos de retroalimentación.
En este sentido, Bryant no considera que LLMOps elimine la cuestión de la propiedad ni que la reinvente, sino que somete a las plataformas existentes a una mayor presión debido al tamaño de los modelos, su elevado coste y la dificultad de evaluarlos. En su opinión, la solución consiste en construir una vez el flujo estándar y después ofrecerlo como una capacidad gobernada a desarrolladores, científicos de datos y agentes inteligentes mediante una interfaz de programación o una interfaz de usuario compartida. Señala que este debate continúa dentro de CNCF, especialmente en el grupo Platforms Working Group de TAG App Delivery, que está abierto a quienes deseen contribuir a él.