Cada vez que aparece una sigla nueva terminada en «Ops», medio internet corre a ponerla en su currículum y la otra mitad a comprar la herramienta. DevOps, MLOps, LLMOps. Pero acá va la idea incómoda: no son tres cosas que compiten, son tres capas que se apilan. LLMOps no reemplaza a MLOps, y MLOps no reemplaza a DevOps. Cada una nace cuando la anterior se queda corta para un tipo de sistema nuevo. Si entiendes por qué nació cada una, dejas de elegir por moda y empiezas a elegir por necesidad.
La foto rápida
Cada capa hereda los problemas de la anterior y le suma los suyos. Esa es la clave de todo el artículo.
1. DevOps: entregar software sin dramas
DevOps es un conjunto de prácticas, herramientas y una filosofía cultural que automatiza e integra los procesos entre los equipos de desarrollo y de operaciones. Se centra en la colaboración entre equipos y la automatización de la tecnología (Atlassian).
El problema que resuelve es viejo: los desarrolladores escribían código y lo «tiraban por encima del muro» a operaciones, que tenía que hacerlo funcionar en producción. Resultado: culpas cruzadas, despliegues lentos y miedo a publicar. DevOps derriba ese muro con una idea central: un equipo es dueño de todo el ciclo de vida del software: lo diseña, lo despliega, lo monitorea y lo arregla (Atlassian).
El ciclo
La característica diferenciadora es lo continuo: integración continua, entrega/despliegue continuo (CI/CD), feedback continuo. En lugar de tests aislados o despliegues programados una vez al mes, todo ocurre de forma constante (Atlassian — DevOps Pipeline).
Ejemplo concreto
Tienes una API de Ruby. Un desarrollador hace push a main:
# .github/workflows/deploy.yml (simplificado)
on:
push:
branches: [main]
jobs:
ci-cd:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Tests
run: bundle exec rspec # CI: se prueba solo
- name: Deploy
run: ./deploy.sh # CD: si pasa, se despliega soloEse archivo es DevOps en la práctica: cada commit se prueba y se despliega automáticamente. El artefacto que gobiernas es el código. Si el código está bien, el sistema se comporta igual hoy que mañana. Esa previsibilidad es justo lo que se rompe en la siguiente capa.
2. MLOps: cuando tu software aprende (y se echa a perder solo)
MLOps es una cultura y práctica de ingeniería de ML cuyo fin es unificar el desarrollo (Dev) y las operaciones (Ops) de los sistemas de machine learning. Implica automatización y monitoreo en todos los pasos: integración, testing, release, despliegue y gestión de infraestructura (Google Cloud).
¿Por qué no basta con DevOps? Porque un sistema de ML tiene tres cosas que cambian, no una:
En software tradicional, si no tocas el código, el comportamiento no cambia. En ML, el mundo cambia aunque tú no toques nada: los datos de producción empiezan a diferir de los de entrenamiento (esto se llama drift) y el modelo se degrada solo. Un modelo de fraude entrenado en 2023 no reconoce los fraudes de 2026.
Por eso MLOps agrega un concepto que DevOps no tiene: entrenamiento continuo (CT, Continuous Training), además de CI/CD. Hay que versionar no solo el código, sino también los datos y el modelo, y reentrenar automáticamente cuando el rendimiento cae (Google Cloud, Wikipedia).
Niveles de madurez
Google Cloud define niveles de madurez de MLOps, resumidos:
| Nivel | Cómo se ve | Reentrenar significa |
|---|---|---|
| 0 — Manual | Notebooks a mano, entregas artesanales | Un humano rehace todo el proceso |
| 1 — Pipeline automatizado | Pipeline que reentrena con datos nuevos | El pipeline se dispara solo (CT) |
| 2 — CI/CD completo | CI/CD para el propio pipeline de ML | Se despliegan pipelines nuevos, no solo modelos |
Fuente: Google Cloud — MLOps levels. La mayoría de los equipos que dicen «hacemos MLOps» están en nivel 0 y no pasa nada: si tu modelo se reentrena una vez al trimestre a mano, no necesitas la maquinaria del nivel 2.
El ciclo de MLOps
El artefacto que gobiernas ya no es solo el código: es código + datos + modelo. Y la evaluación es numérica y objetiva (precisión, recall, F1). Recuerda ese punto, porque es lo primero que se rompe en LLMOps.
3. LLMOps: cuando el modelo ya no es tuyo
Aquí viene el giro. Con los modelos de lenguaje (LLMs) como GPT, Claude o Llama, la mayoría de las apps ya no entrenan un modelo desde cero. Parten de un modelo fundacional pre-entrenado por otro (OpenAI, Anthropic, Meta) y le agregan encima: prompts, RAG y a veces fine-tuning (Grid Dynamics).
LLMOps (Large Language Model Operations) es el conjunto de prácticas, flujos y herramientas para desarrollar, desplegar y mantener aplicaciones basadas en LLMs en producción: gestión de prompts, pipelines de RAG, fine-tuning, evaluación, despliegue, monitoreo y control de costos (Scaler).
Microsoft lo pone claro: para operacionalizar cargas de IA generativa, extiendes tu inversión en MLOps con GenAIOps (a veces llamado LLMOps). Hay patrones comunes con el ML tradicional y patrones únicos de la IA generativa. No es MLOps renombrado (Microsoft Azure Architecture Center).
Qué cambia de verdad respecto a MLOps
MLflow lo resume bien: LLMOps adapta los principios de MLOps para atender desafíos únicos de los LLMs, como la sensibilidad a los prompts, el costo por token y el riesgo de alucinación. No es solo una versión renombrada de lo que ya sabías (MLflow). Los cuatro cambios de fondo:
- El prompt es un artefacto de primera clase. En ML clásico, el modelo es el producto del entrenamiento. En apps de LLM, el comportamiento lo define tanto el prompt (instrucciones, ejemplos, contexto recuperado) como los pesos del modelo. Los prompts necesitan control de versiones, testing y rollback, igual que el código.
- RAG y bases de datos vectoriales. Recuperar contexto relevante (Retrieval-Augmented Generation) introduce embeddings y vector databases como pieza operativa nueva.
- Evaluar texto libre es mucho más difícil que medir precisión. En MLOps comparas contra un set de validación: la respuesta es correcta o no. En LLMOps, ¿cómo mides si una respuesta generada es «buena»? El texto abierto no tiene una única respuesta correcta.
- El costo es por inferencia, por token. Cada llamada cuesta dinero y cada token suma. El control de costos deja de ser «la factura del servidor» y pasa a ser una métrica de producto que vigilas en tiempo real.
Fuentes: dev.to (Apprecode), Atlan, DS Stream.
El ciclo de LLMOps
Fíjate qué desapareció: la caja de «entrenar modelo». En la mayoría de las apps de LLM no entrenas nada. Tu trabajo es orquestar prompts, recuperación y evaluación sobre un modelo que ya existe (DS Stream).
Ejemplo concreto: prompt versionado
# prompts/soporte_v3.py — el prompt es código: versionado y testeable
SYSTEM_PROMPT_V3 = """
Eres el asistente de soporte de Kimün Academy.
Responde SOLO con la información del contexto recuperado.
Si no está en el contexto, di "No tengo esa información".
Nunca inventes precios ni fechas.
"""
# test_prompts.py — sí, se testean los prompts
def test_no_inventa_cuando_no_sabe():
respuesta = llm(SYSTEM_PROMPT_V3, contexto="", pregunta="¿Cuánto cuesta el curso X?")
assert "no tengo esa información" in respuesta.lower()Ese test es puro LLMOps: estás versionando un prompt (v3) y validando su comportamiento, algo que no existe ni en DevOps ni en MLOps.
Tabla comparativa
| Dimensión | DevOps | MLOps | LLMOps |
|---|---|---|---|
| Qué opera | Software tradicional | Sistemas de ML propios | Apps sobre modelos fundacionales |
| Artefacto que versionas | Código | Código + datos + modelo | Código + prompts + datos/índices (+ modelo si haces fine-tuning) |
| ¿Entrenas modelo? | No | Sí, con tus datos | Normalmente no; usas uno pre-entrenado |
| Ciclo clave | CI/CD | CI/CD + CT (reentrenamiento) | CI/CD + evaluación + gestión de prompts/RAG |
| Cómo evalúas | Tests pasa/falla | Métricas (precisión, recall, F1) | Texto libre: LLM-as-judge, heurísticas, humanos |
| Qué se degrada solo | Poco (si no tocas el código) | El modelo por data drift | Calidad de respuestas, alucinaciones, cambios del modelo base |
| Costo dominante | Infraestructura | Cómputo de entrenamiento | Costo por token / por inferencia |
| Pieza nueva de infra | Pipeline CI/CD | Feature store, registro de modelos | Vector DB, gestión de prompts, guardrails |
Fuentes de la comparación: Google Cloud, Microsoft Azure, MLflow, Atlan.
¿Cuál necesitas? (la parte que nadie te dice)
Fiel al espíritu anti-sobreingeniería:
- ¿Construyes una app web, una API, un SaaS clásico? → Necesitas DevOps. Punto. Meter MLOps «por si acaso» es cargar complejidad que no usas.
- ¿Entrenas modelos con tus propios datos y necesitas reentrenarlos? → Ahí sí entra MLOps. Pero empieza en nivel 0 (manual) y sube solo cuando el dolor lo pida. Casi nadie necesita el nivel 2 desde el día uno.
- ¿Tu app llama a un LLM (GPT, Claude, Llama) con prompts y RAG? → Eso es LLMOps, y probablemente no necesites entrenar nada. Tu esfuerzo va en prompts, recuperación, evaluación y vigilar el costo por token.
⚠️ El error más caro
Conclusión
- DevOps nació para entregar software sin dramas: automatiza el ciclo código → producción.
- MLOps lo extiende porque el software que aprende también se echa a perder solo: hay que versionar datos y modelo, y reentrenar.
- LLMOps lo extiende otra vez porque, cuando el modelo ya no es tuyo, el trabajo se mueve a prompts, RAG, evaluación de texto y costo por token.
No es una carrera de reemplazos. Es una torre: cada piso se apoya en el de abajo. Elige el piso donde vive tu problema, no el que está de moda.
💡 Nota de transparencia