MLOps vs LLMOps: qué cambia cuando el modelo es un LLM

MLOps es la disciplina de ingeniería para desarrollar, desplegar, versionar y operar sistemas de aprendizaje automático de forma fiable; LLMOps extiende esa disciplina a las aplicaciones construidas en torno a grandes modelos de lenguaje, donde el comportamiento en producción depende no solo de un artefacto de modelo, sino también de prompts, contexto, recuperación, versiones de proveedor/modelo, llamadas a herramientas, controles de seguridad y pipelines de evaluación. LLMOps no reemplaza a MLOps. Cambia la unidad operativa de "un modelo más un pipeline de servicio" hacia "una aplicación LLM en evolución cuyo comportamiento emerge de varios componentes que cambian de forma independiente".

Qué significa realmente MLOps

MLOps aplica disciplina de ingeniería de software y operaciones a los sistemas de aprendizaje automático. El desafío de producción es más amplio que entrenar un modelo: la recolección de datos, la validación de datos, la experimentación, la reproducibilidad, la evaluación de modelos, el despliegue, la infraestructura y el monitoreo tienen que funcionar juntos.

La guía de arquitectura MLOps de Google enmarca la disciplina en torno a la integración continua, la entrega continua y el entrenamiento continuo. CI valida no solo el código sino también los datos, los esquemas y los modelos; CD despliega pipelines de ML y servicios de predicción; CT puede reentrenar y redesplegar modelos a medida que cambian los datos o las implementaciones.

La guía de AWS añade las mismas preocupaciones operativas desde otro ángulo: el linaje de modelos, la trazabilidad de modelo/versión, el monitoreo de drift y el monitoreo de calidad en producción son partes centrales para mantener los sistemas de ML fiables después del despliegue.

Qué cambia cuando el modelo es un LLM

Los grandes modelos de lenguaje cambian el problema de producción porque la aplicación a menudo no posee el ciclo de vida completo de entrenamiento del modelo. Un equipo puede llamar a una API de modelo alojado, ejecutar un modelo abierto localmente, cambiar entre proveedores o usar varios modelos para diferentes tareas.

Por lo tanto, el modelo es solo una dependencia versionada dentro de un sistema de comportamiento más amplio. Los prompts, los resultados de recuperación, el orden del contexto, las herramientas, la instantánea del modelo, la configuración de temperatura/razonamiento, los filtros de seguridad y la orquestación en tiempo de ejecución pueden cambiar la salida.

Esto crea una pregunta operativa más amplia: ¿qué combinación de modelo, contexto, datos, prompt, herramientas y tiempo de ejecución produjo este comportamiento? LLMOps existe para hacer que esa pregunta sea respondible y la respuesta lo suficientemente reproducible para el trabajo de ingeniería.

El ejemplo más simple

Supongamos que una aplicación responde preguntas sobre políticas internas.

En un enfoque de ML clásico, podrías versionar un clasificador entrenado, desplegarlo y monitorear la calidad de las predicciones. En una aplicación LLM, la respuesta podría depender de una instantánea de modelo alojado, un prompt de sistema, un modelo de embeddings, un índice vectorial, filtros de recuperación, un reranker y el contexto final seleccionado.

Cambiar cualquiera de esos componentes puede cambiar la respuesta final aunque el endpoint de la aplicación y la pregunta del usuario permanezcan idénticos.

Dónde se detiene el ejemplo simple

Algunos sistemas LLM todavía entrenan o ajustan sus propios modelos, por lo que las prácticas tradicionales de MLOps, como los pipelines de entrenamiento, el registro de modelos y el linaje de datos, siguen siendo directamente relevantes.

Otros sistemas usan solo API externas de modelos fundacionales y nunca ejecutan entrenamiento continuo. Su principal carga operativa es la evaluación de aplicaciones, la gestión de cambios de modelo/proveedor, el versionado de prompts/contexto, la calidad de recuperación y la observabilidad.

Por lo tanto, no existe un único “pipeline de LLMOps” universal. El ciclo de vida exacto depende de si entrenas, ajustas, autoalojas, recuperas conocimiento externo, ejecutas agentes o dependes de API de modelos gestionados.

MLOps vs LLMOps

LLMOps extiende MLOps en lugar de reemplazarlo

Los principios operativos fundamentales no desaparecen: el control de código fuente, CI/CD, la reproducibilidad, el linaje, los controles de despliegue, el monitoreo, la reversión y los criterios de aceptación medibles siguen siendo esenciales.

La extensión es que ahora más artefactos que definen el comportamiento se encuentran fuera de los pesos del modelo. Un modelo fundacional gestionado puede cambiar su comportamiento mediante actualizaciones de instantáneas, mientras que la salida de la aplicación puede cambiar mediante cambios en el prompt o la recuperación sin ningún reentrenamiento del modelo.

Por eso la jerarquía útil suele ser DevOps → MLOps → LLMOps/GenAIOps como preocupaciones operativas cada vez más especializadas, no tres prácticas mutuamente excluyentes.

¿Qué debe versionarse en LLMOps?

Las instantáneas de modelo se convierten en dependencias de lanzamiento

Con los LLM alojados, el equipo puede no controlar el entrenamiento del modelo, pero sí controla qué modelo o instantánea llama la aplicación.

La guía actual de la API de OpenAI advierte explícitamente que el comportamiento de los prompts puede cambiar entre instantáneas del modelo y recomienda fijar las aplicaciones en producción a instantáneas específicas cuando la consistencia importa, y luego ejecutar evaluaciones al actualizar.

La consecuencia operativa es directa: las actualizaciones de modelo deben tratarse como lanzamientos de la aplicación, no como mantenimiento invisible de infraestructura.

El ciclo de vida del proveedor se convierte en parte de las operaciones

Las aplicaciones LLM a menudo dependen de los límites de tasa del proveedor, los calendarios de descontinuación, la semántica de la API, los límites de contexto, las reglas de manejo de datos y los precios.

Un proveedor puede descontinuar un modelo mientras el código de tu aplicación permanece sin cambios. El calendario de descontinuación actual de OpenAI, por ejemplo, incluye fechas de retiro en 2026 para instantáneas de modelos más antiguos y superficies de plataforma.

Por lo tanto, LLMOps necesita seguimiento del ciclo de vida del proveedor, pruebas de migración y decisiones de respaldo además del monitoreo de la calidad del modelo.

Los prompts se comportan como código de producción

Los prompts son configuración de comportamiento ejecutable. Pequeños cambios pueden alterar la calidad de la salida, la selección de herramientas y la interpretación de políticas.

La guía actual de OpenAI recomienda almacenar los prompts de producción en el código de la aplicación, revisar los cambios de prompts mediante solicitudes de extracción, usar entradas tipadas y cubrir los cambios con pruebas y verificaciones de evaluación.

Eso hace que el versionado de prompts se parezca menos a editar texto de marketing y más a cambiar una función cuya salida es probabilística y dependiente del modelo.

La ingeniería de contexto se convierte en una preocupación operativa

El modelo de producción rara vez recibe solo un prompt estático. Puede recibir historial de conversación, documentos recuperados, salidas de herramientas, memoria, estado actual de la aplicación e instrucciones de política.

Por lo tanto, LLMOps debe observar el ensamblaje del contexto: qué evidencia se seleccionó, qué versión de estado estaba vigente, si ocurrió truncamiento y si las instrucciones importantes sobrevivieron a la compactación.

Una regresión del modelo y una regresión del contexto pueden verse idénticas en la respuesta final. Rastrear la ruta real del contexto es lo que permite al equipo separarlas.

RAG crea su propio ciclo de vida operativo

Un sistema RAG introduce una segunda canalización de producción junto a la inferencia del modelo: ingesta, extracción, fragmentación, metadatos, incrustaciones, índices, recuperación, reordenamiento y selección de contexto.

El corpus de conocimiento puede cambiar todos los días incluso cuando el modelo y el prompt no lo hacen. Por lo tanto, un índice obsoleto o un filtro de metadatos roto pueden degradar la calidad de las respuestas sin ninguna deriva del modelo.

LLMOps para RAG debe rastrear la versión del corpus/índice, el modelo de incrustación, la política de fragmentación, la configuración de recuperación, la frescura de las fuentes y las métricas de recuperación por separado de la calidad de generación.

Las evaluaciones reemplazan “me parece bien” con evidencia de lanzamiento

Las salidas generativas a menudo son abiertas, por lo que las pruebas de coincidencia exacta son insuficientes para muchas tareas. LLMOps agrega conjuntos de datos de evaluación y calificadores que pueden medir el éxito de la tarea, la corrección, la seguridad, la fundamentación, el estilo o criterios de aceptación específicos del dominio.

La pila de evaluación GenAI actual de MLflow admite conjuntos de datos de evaluación versionados, comparaciones de prompts/modelos, evaluadores personalizados y evaluación sobre trazas completas.

La práctica más sólida es el desarrollo guiado por evaluación: definir casos representativos y criterios de aceptación antes o junto con los cambios, y luego comparar las versiones contra la misma evidencia.

LLM como juez es útil pero no es la verdad absoluta

Los jueces LLM pueden escalar la evaluación de cualidades que son costosas de codificar como aserciones deterministas, como la relevancia, el tono o la fundamentación.

Sin embargo, el juez es otro modelo con su propio sesgo, versión y prompt. Por lo tanto, la configuración del juez debe versionarse y calibrarse contra casos de referencia humanos o deterministas cuando las consecuencias importan.

Una evaluación de producción puede combinar comprobaciones deterministas, métricas basadas en referencia, jueces modelo y revisión humana en lugar de pedirle a una sola métrica que represente todas las dimensiones de calidad.

El trazado se vuelve más importante que los registros de endpoint

Los registros de API tradicionales pueden decirte que una solicitud tardó dos segundos y devolvió HTTP 200. No pueden decirte qué fragmentos recuperados se seleccionaron, qué herramienta llamó el agente o qué span del modelo consumió la mayor cantidad de tokens.

El trazado GenAI actual de MLflow captura prompts, recuperaciones, llamadas a herramientas y spans de la aplicación, y su flujo de evaluación de producción puede puntuar información de trayectoria intermedia en lugar de solo el texto final.

Este es un cambio importante en LLMOps: la observabilidad sigue el grafo de comportamiento de la aplicación, no solo el endpoint de servicio.

Los agentes expanden LLMOps hacia operaciones en tiempo de ejecución

Una aplicación agéntica puede realizar varias llamadas a modelos, invocaciones de herramientas y transiciones de estado antes de producir un resultado.

Por lo tanto, operar agentes requiere recuentos de pasos, trazas de llamadas a herramientas, denegaciones de permisos, reintentos, detección de bucles, aprobaciones humanas y estado final verificado, además de las métricas ordinarias de latencia del modelo y tokens.

Una respuesta final correcta puede ocultar una mala trayectoria, por lo que la evaluación de agentes debe inspeccionar tanto el camino como el resultado.

Los tokens, las llamadas a modelos y el contexto se convierten en variables de costo

El costo de inferencia de ML clásico a menudo está dominado por la infraestructura de servicio o el cómputo por predicción. Las aplicaciones LLM pueden añadir precios de tokens del proveedor, llamadas repetidas de agentes, llamadas de embedding, reranking y sobrecarga de herramientas/tiempo de ejecución.

Por lo tanto, el costo debe atribuirse a la tarea o a la traza, no solo a un extremo. Un flujo de trabajo que realiza ocho llamadas ocultas al modelo puede ser funcionalmente correcto pero operativamente inaceptable.

La latencia se comporta de la misma manera: la latencia del modelo, la recuperación, el reranking y las herramientas externas se combinan en la latencia de extremo a extremo del usuario.

El almacenamiento en caché se vuelve semántico, no solo técnico

Los sistemas LLM pueden almacenar en caché prompts, embeddings, resultados de recuperación o respuestas completas, pero la clave de caché debe reflejar la semántica que puede cambiar el resultado.

Una caché de respuestas que ignora la versión del modelo, el inquilino, los permisos o la frescura de la fuente puede devolver una respuesta técnicamente válida pero semánticamente inválida.

Por lo tanto, LLMOps trata la invalidación de caché como parte del versionado de modelo/contexto/datos en lugar de solo una optimización de infraestructura.

La seguridad y los permisos se convierten en criterios de lanzamiento

Los sistemas generativos pueden producir texto ilimitado y los agentes pueden desencadenar acciones externas. Por lo tanto, las pruebas de seguridad se acercan más al CI/CD ordinario que en muchos sistemas clásicos de ML predictivo.

Las verificaciones de permisos, las pruebas de inyección de prompts, las pruebas de aislamiento de inquilinos y las aprobaciones de efectos secundarios deben ser pruebas de regresión reproducibles donde existan esos riesgos.

El modelo puede sugerir una operación, pero el tiempo de ejecución aún debe hacer cumplir la autorización. LLMOps posee la evidencia de que esos controles siguen funcionando después de cambios en el modelo, el prompt o las herramientas.

Cómo se ve CI en LLMOps

Cómo se ve CD en LLMOps

Un lanzamiento a producción puede no desplegar ningún artefacto de modelo nuevo. Puede simplemente enviar un nuevo prompt, configuración de recuperación, conjunto de herramientas o mapeo de proveedores.

Por lo tanto, el paquete de lanzamiento debe identificar la configuración completa que define el comportamiento en lugar de solo la imagen del contenedor de la aplicación.

Los indicadores de características, el despliegue por etapas, la evaluación en sombra, el tráfico canario y la reversión son útiles porque el comportamiento del LLM puede degradarse de maneras que las pruebas de contrato estáticas no detectan.

El entrenamiento continuo se vuelve opcional; la evaluación continua se vuelve central

El MLOps tradicional a menudo enfatiza el entrenamiento continuo cuando nuevos datos o la deriva justifican el reentrenamiento.

Muchas aplicaciones de LLM nunca entrenan el modelo fundacional. Su bucle continuo equivalente es la evaluación continua: recopilar fallos y casos de producción representativos, añadirlos a los conjuntos de datos de evaluación, probar cambios candidatos de prompt/modelo/recuperación y volver a desplegar solo cuando la evidencia mejore.

El ajuste fino puede reintroducir un ciclo de vida de entrenamiento, pero debería situarse dentro del mismo proceso más amplio de evaluación y lanzamiento.

¿Qué se debe monitorear en producción?

Las trazas de producción pueden convertirse en datos de evaluación

Uno de los patrones modernos de LLMOps más útiles es convertir trazas de producción muestreadas en registros de evaluación.

MLflow actualmente admite la recuperación de trazas de producción y la puntuación no solo de salidas sino también de spans intermedios como trayectorias de recuperación o llamadas a herramientas.

Esto cierra el bucle entre observabilidad y desarrollo: los fallos reales pueden convertirse en casos de regresión en el próximo lanzamiento en lugar de desaparecer dentro de los registros.

La reproducibilidad se vuelve condicional en lugar de exacta

La reproducibilidad clásica de ML a menudo busca recrear un modelo a partir de código versionado, datos, entorno y parámetros de entrenamiento.

Las aplicaciones de LLM alojadas no siempre pueden reproducir una salida idéntica token por token porque la generación es probabilística y los proveedores pueden controlar la infraestructura.

Por lo tanto, LLMOps busca una reproducibilidad conductual: registrar suficiente modelo/proveedor/versión, prompt, entradas de contexto, estado de recuperación y configuración de tiempo de ejecución para reproducir las condiciones y validar el comportamiento dentro de tolerancias esperadas.

El linaje se expande del linaje del modelo al linaje de la aplicación

La guía de MLOps de AWS trata el linaje del modelo como el historial de artefactos de código, datos, modelo e infraestructura necesarios para el diagnóstico y la reproducibilidad.

Para las aplicaciones de LLM, el linaje debería conectar además prompts, conjuntos de datos de evaluación, versiones de recuperación/índice, esquemas de herramientas, configuración de agente/tiempo de ejecución y snapshots de proveedor/modelo.

La pregunta objetivo se convierte en: ¿Qué configuración exacta de la aplicación produjo esta traza?

El enrutamiento multiproveedor y de modelos crea política operativa

Una vez que una aplicación puede usar varios proveedores o modelos locales, el enrutamiento se convierte en una política operativa en lugar de una simple cadena de modelo.

El enrutamiento puede depender de la capacidad, la latencia, el costo, la privacidad, la longitud del contexto, la disponibilidad, el soporte de herramientas o la localidad. Un respaldo puede preservar el tiempo de actividad mientras cambia la calidad de la respuesta o los supuestos de procesamiento de datos.

Por lo tanto, LLMOps debería registrar qué ruta se seleccionó realmente y evaluar las rutas de forma independiente en lugar de tratar cada punto final compatible como conductualmente intercambiable.

Evidencia de implementación original

Aaasaasa AI Client: proveedor, modelo y tiempo de ejecución son objetos operativos separados

Aaasaasa AI Client separa agente/cliente, proveedor, modelo, ubicación de tiempo de ejecución y permisos. Su AI Hub admite Ollama, LM Studio/puntos finales compatibles con OpenAI y otros protocolos de proveedores en lugar de tratar “el modelo” como una única configuración global.

La implementación incluye descubrimiento dinámico de modelos locales, transmisión, salida de pensamiento y controles explícitos de calentamiento/carga y descarga de Ollama. Esa es evidencia operativa de que el servicio local de LLM introduce preocupaciones sobre el ciclo de vida de los recursos más allá de un nombre de modelo de API.

El estado del proveedor se consulta a través de adaptadores de proveedor, y los tipos de conexión distinguen rutas locales, API en la nube, respaldadas por cuenta, agente remoto y cliente web. Estas son dimensiones operativas concretas que una plataforma consciente de LLM tiene que exponer.

El repositorio también preserva un límite importante: un tiempo de ejecución local no es automáticamente inferencia local. La ubicación del proveedor/modelo/tiempo de ejecución son preocupaciones versionadas o configurables que afectan la privacidad, la latencia, el costo y la disponibilidad.

Source of Truth Research Engine: el estado de la aplicación LLM se extiende más allá del modelo

Source of Truth Research Engine combina búsqueda léxica, incrustaciones opcionales, instantáneas de fuentes, identidad SHA-256, afirmaciones, procedencia y seguimiento de contradicciones en torno a la investigación asistida por modelos locales.

Esta es evidencia útil de LLMOps porque cambiar solo el modelo no define el sistema de investigación. La recuperación, la adquisición de fuentes, la clasificación de evidencia y la procedencia persistente son artefactos operativos independientes.

La implementación trata deliberadamente la similitud semántica como descubrimiento en lugar de evidencia, mostrando por qué la observabilidad de LLMOps debería distinguir el comportamiento de recuperación de la validez de las afirmaciones.

Modos de fallo comunes de LLMOps

Conceptos erróneos comunes

Una secuencia práctica de diseño de LLMOps

Lista de verificación de arquitectura LLMOps

Casos límite y limitaciones

Una aplicación simple que llama a un único modelo alojado fijo sin recuperación ni herramientas puede necesitar solo LLMOps ligero: código de prompt versionado, evaluaciones, fijación del modelo, trazabilidad básica y monitorización del proveedor.

Un modelo autoalojado con ajuste fino puede requerir casi todo el stack clásico de MLOps más la evaluación de aplicaciones específica de LLM, lo que hace que la frontera entre MLOps y LLMOps sea intencionadamente difusa.

Una plataforma de agentes puede tener operaciones mínimas de entrenamiento de modelos pero operaciones sustanciales en tiempo de ejecución porque los fallos ocurren en la selección de herramientas, el estado y la orquestación.

Un sistema con mucho RAG puede estar dominado operativamente por la ingesta de documentos y la calidad de la recuperación más que por el servicio del modelo.

La terminología seguirá evolucionando. La pregunta arquitectónica duradera no es qué etiqueta de “Ops” gana, sino qué artefactos producen comportamiento y, por tanto, deben ser versionados, evaluados, observados y gobernados.

¿Qué cambiaría esta respuesta?

Si los proveedores de modelos fundacionales estandarizaran un comportamiento del modelo perfectamente estable y un soporte de versiones a largo plazo, la gestión de proveedores/snapshots podría volverse menos significativa operativamente.

Si las aplicaciones asumieran cada vez más el ajuste fino o el entrenamiento, las preocupaciones clásicas de MLOps volverían a ser más centrales.

El principio operativo seguiría siendo: cada componente que pueda cambiar materialmente el comportamiento en producción pertenece al linaje, las pruebas, la observabilidad y el control de cambios.

Conocimiento canónico relacionado

LLMOps se sitúa por debajo de AI Governance y Enterprise AI Architecture: la gobernanza define qué cambios requieren evidencia y aprobación, mientras que LLMOps proporciona la maquinaria operativa para versionar, evaluar, desplegar y observar esos cambios.

Context Engineering y RAG son subdominios operativos dentro de muchas aplicaciones LLM porque el contexto y la recuperación pueden cambiar el comportamiento independientemente del modelo.

Agentic AI extiende LLMOps aún más hacia las operaciones de trayectoria, permisos y runtime de herramientas.

Preguntas frecuentes

Glosario

Conclusión

MLOps y LLMOps comparten el mismo objetivo de ingeniería: hacer que los sistemas de IA sean lo suficientemente reproducibles, comprobables y observables para operar de manera fiable en producción.

La diferencia es la forma del sistema. El MLOps clásico a menudo se centra en entrenar y servir artefactos de modelos; LLMOps debe operar una pila de comportamiento en la que las instantáneas de modelos, prompts, contexto, recuperación, herramientas, permisos y proveedores pueden cambiar de forma independiente.

La regla útil más breve es: versiona, evalúa y observa todo lo que pueda cambiar materialmente el comportamiento de la aplicación LLM, no solo el modelo.

Fuentes primarias y documentación actual

Las fuentes a continuación fundamentan la base de MLOps y los patrones operativos actuales para aplicaciones LLM y de agentes. Las secciones del proyecto son evidencia de implementación original y son intencionalmente más limitadas que las afirmaciones sobre una plataforma LLMOps completa.