Infraestructura de Versionado de Modelos: Gestión de Artefactos de ML a Escala

Actualizado el 11 de diciembre de 2025

Actualización de diciembre 2025: MLflow 3.0 extiende el registro para IA generativa y agentes de IA—conectando modelos con versiones de código, prompts, ejecuciones de evaluación y metadatos de despliegue. El versionado de modelos ahora rastrea no solo los pesos sino adaptadores fine-tuned, plantillas de prompts y configuraciones de recuperación. Los LLMs con cientos de GB de pesos requieren infraestructura especializada más allá de Git.

MLflow 3.0 extendió su registro de modelos para manejar aplicaciones de IA generativa y agentes de IA, conectando modelos con versiones exactas de código, configuraciones de prompts, ejecuciones de evaluación y metadatos de despliegue.¹ La evolución refleja un cambio fundamental en lo que significa "versionado de modelos"—de rastrear simples archivos pickle a gestionar sistemas complejos con múltiples adaptadores fine-tuned, plantillas de prompts y configuraciones de recuperación. Las organizaciones que ejecutan IA en producción necesitan infraestructura que versione no solo los pesos, sino todo el contexto requerido para reproducir y desplegar modelos de manera confiable.

A diferencia del versionado de software tradicional, el versionado de modelos de ML implica rastrear archivos binarios masivos, configuraciones de entrenamiento complejas, versiones de datasets y métricas de evaluación—todo mientras se mantienen los requisitos de reproducibilidad y cumplimiento.² El desafío se multiplica para los LLMs donde los modelos fine-tuned proliferan rápidamente y la ingeniería de prompts añade otra capa de artefactos que requieren control de versiones.

Por qué importa el versionado de modelos

Los sistemas de ML en producción fallan silenciosamente. Los modelos se degradan con el tiempo, las versiones fine-tuned rinden por debajo de lo esperado, y sin un versionado adecuado, los equipos no pueden identificar qué cambió o revertir a estados conocidos y funcionales.

El desafío del versionado

Artefactos binarios: Los pesos de los modelos van desde megabytes para ML clásico hasta cientos de gigabytes para modelos de lenguaje grandes. Git no puede manejar estos archivos eficientemente; la infraestructura especializada se vuelve esencial.

Explosión de configuración: Un solo modelo involucra código de entrenamiento, hiperparámetros, preprocesamiento de datos, ingeniería de características y configuración de despliegue. Cualquier cambio potencialmente afecta el comportamiento del modelo.

Dependencia del dataset: La calidad del modelo depende de los datos de entrenamiento. Sin versionado de datasets, reproducir un modelo se vuelve imposible incluso con código idéntico.

Acoplamiento de evaluación: Las métricas de rendimiento en conjuntos de prueba específicos determinan las decisiones de despliegue. Esas métricas deben vincularse permanentemente a las versiones del modelo.

Requisitos de negocio

Reproducibilidad: Los requisitos regulatorios en finanzas y salud exigen la capacidad de recrear versiones exactas del modelo desplegadas en cualquier momento.³

Auditabilidad: El cumplimiento requiere rastrear los modelos desplegados hasta los datos de entrenamiento, el código y los responsables que aprobaron el despliegue.

Capacidad de rollback: Los incidentes en producción requieren revertir a versiones anteriores del modelo en minutos, no horas.

Colaboración: Múltiples científicos de datos trabajando en el mismo modelo necesitan propiedad clara y resolución de conflictos para los artefactos del modelo.

Arquitectura del registro de modelos

Un registro de modelos sirve como el repositorio central que gestiona el ciclo de vida de los modelos de ML desde el desarrollo hasta producción:⁴

Componentes principales

Control de versiones: Cada versión del modelo recibe un identificador único, típicamente combinando el nombre del modelo con versión semántica (v1.2.3) o identificadores basados en hash.

Almacenamiento de metadatos: Los parámetros de entrenamiento, métricas de evaluación, linaje de datos e historial de despliegue persisten junto a los artefactos del modelo.

Almacenamiento de artefactos: Los pesos del modelo, archivos de configuración y activos asociados se almacenan en almacenamiento de objetos escalable (S3, GCS, Azure Blob).

Gestión del ciclo de vida: Los modelos transitan por etapas—desarrollo, staging, producción, archivado—con controles de gobernanza en cada transición.

Flujo de trabajo del registro

Trabajo de Entrenamiento → Registrar Modelo → Revisión Staging → Despliegue Producción
           ↓                      ↓                  ↓                      ↓
       Métricas              ID Versión        Aprobaciones          Enrutamiento Tráfico
       Registradas           Generado          Registradas             Monitoreado

Registro: Los pipelines de entrenamiento registran automáticamente modelos exitosos con metadatos asociados: - ID de ejecución de entrenamiento y contexto del experimento - Hiperparámetros y configuración - Métricas de evaluación en datos reservados - Referencias de versión de datos - Hash del commit de código

Staging: Los modelos candidatos se someten a validación antes de producción: - Pruebas automatizadas contra benchmarks - Revisión humana para aplicaciones sensibles - Pruebas A/B contra el modelo actual en producción - Perfilado de rendimiento para latencia de inferencia

Promoción: Los modelos aprobados se despliegan a producción: - El tráfico cambia gradualmente a la nueva versión - El monitoreo detecta degradación - Se activa rollback si las métricas declinan

Comparación de plataformas

MLflow

MLflow proporciona el registro de modelos de código abierto más completo:⁵

Características del Model Registry: - Almacén centralizado de modelos con versionado y alias - Rastreo de linaje (experimento → ejecución → modelo) - Transiciones de etapa (Staging, Production, Archived) - Anotaciones y etiquetado de metadatos - API REST para acceso programático

Mejoras de MLflow 3.0: - La entidad LoggedModel conecta modelos con código, prompts y evaluaciones - Trazado mejorado para aplicaciones de IA generativa - Soporte de agentes para sistemas de IA complejos - Databricks proporciona versión empresarial gestionada

Ejemplo de flujo de trabajo:

import mlflow

# Registrar modelo durante entrenamiento
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 0.001, "epochs": 10})
    mlflow.log_metrics({"accuracy": 0.95, "f1": 0.92})
    mlflow.pyfunc.log_model("model", python_model=trained_model)

# Registrar en el registro de modelos
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "fraud-detection-model")

# Promover a producción
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="fraud-detection-model",
    version=3,
    stage="Production"
)

Ideal para: Organizaciones que buscan capacidades completas de MLOps con flexibilidad de código abierto.

Weights & Biases

W&B enfatiza el seguimiento de experimentos con fuerte versionado de artefactos:⁶

Capacidades clave: - Seguimiento de experimentos con visualización rica - Versionado de artefactos con grafos de linaje - Registro de modelos con alias (@champion, @production) - Características de colaboración para flujos de trabajo en equipo - Integración con los principales frameworks de ML

Versionado de artefactos:

import wandb

run = wandb.init(project="nlp-models")

# Registrar modelo como artefacto
artifact = wandb.Artifact("bert-classifier", type="model")
artifact.add_file("model.pt")
run.log_artifact(artifact)

# Vincular al registro con alias
run.link_artifact(artifact, "model-registry/bert-classifier",
                  aliases=["latest", "production"])

Consideraciones: La arquitectura cloud-first requiere enviar datos a servidores externos, lo que puede entrar en conflicto con requisitos estrictos de privacidad de datos.

Ideal para: Equipos que priorizan el seguimiento de experimentos y la colaboración con mínima configuración inicial.

DVC (Data Version Control)

DVC extiende Git para archivos grandes y datasets:⁷

Arquitectura: - Comandos tipo Git (dvc add, dvc push, dvc pull) - Archivos de metadatos rastreados en Git, archivos grandes en almacenamiento remoto - Definiciones de pipeline para experimentos reproducibles - Múltiples backends de almacenamiento (S3, GCS, Azure, SSH)

Desarrollo reciente: DVC se unió a la familia lakeFS, con lakeFS sirviendo como estándar empresarial para versionado de datos a escala de petabytes.

Ejemplo de flujo de trabajo:

# Añadir archivo de modelo grande a DVC
dvc add models/bert-finetuned.pt

# Hacer commit de metadatos a Git
git add models/bert-finetuned.pt.dvc .gitignore
git commit -m "Add fine-tuned BERT model v1.0"

# Push a almacenamiento remoto
dvc push

# Reproducir desde cualquier commit
git checkout v1.0
dvc checkout

Ideal para: Equipos con flujos de trabajo Git existentes que buscan versionado ligero de datos y modelos.

Registros nativos de la nube

Vertex AI Model Registry (Google Cloud):⁸ - Integración nativa con GCP - Despliegue directo a endpoints - Rastreo automático de linaje - Integración con Vertex AI Pipelines

Amazon SageMaker Model Registry: - Integración con ecosistema AWS - Flujos de trabajo de aprobación - Compartición de modelos entre cuentas - Integración con SageMaker Pipelines

Azure ML Model Registry: - Integración con Azure - Compatibilidad con MLflow - Despliegue a endpoints gestionados

Ideal para: Organizaciones comprometidas con proveedores de nube específicos que buscan integración nativa.

Consideraciones específicas para LLMs

Los modelos de lenguaje grandes presentan desafíos únicos de versionado más allá del ML tradicional:⁹

Qué versionar

Modelos base: Rastrear qué modelo fundacional (Llama 3.1-8B, GPT-4, Claude) sirve como punto de partida.

Pesos fine-tuned: El fine-tuning completo produce archivos de pesos completamente nuevos; los adaptadores LoRA producen pequeños archivos delta que referencian modelos base.

Plantillas de prompts: Los prompts de sistema, ejemplos few-shot y formatos de instrucciones afectan significativamente el comportamiento del modelo.

Configuraciones de recuperación: Los sistemas RAG requieren versionado de modelos de embedding, estrategias de chunking y parámetros de recuperación.

Versionado semántico para LLMs

Adoptar versionado semántico para comunicar la importancia del cambio:¹⁰

Versión mayor (v2.0.0): - Modelo base diferente - Cambios de arquitectura - Cambios de API incompatibles

Versión menor (v1.3.0): - Fine-tuning con nuevos datos - Mejoras significativas de rendimiento - Nuevas capacidades añadidas

Versión de parche (v1.2.1): - Correcciones de errores - Optimizaciones menores - Actualizaciones de configuración

Gestión de adaptadores

LoRA y QLoRA crean archivos de adaptadores proliferantes que requieren organización sistemática:

base-model/
├── llama-3.1-8b/
│   └── v1.0.0/
│       ├── weights/
│       └── config.json
└── adapters/
    ├── customer-support-v1/
    │   ├── adapter_model.bin
    │   └── adapter_config.json
    ├── code-generation-v2/
    └── summarization-v1/

Estrategia de versionado de adaptadores: - Versionar adaptadores independientemente de los modelos base - Documentar versiones de modelo base compatibles - Rastrear datos de entrenamiento e hiperparámetros por adaptador - Habilitar cambio rápido entre adaptadores en serving

Estrategias de despliegue

Despliegues canary

Enrutar un pequeño porcentaje de tráfico a la nueva versión del modelo antes del despliegue completo:¹¹

# Configuración canary de Kubernetes
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: model-service
        subset: v1
      weight: 90
    - destination:
        host: model-service
        subset: v2
      weight: 10

Proceso: 1. Desplegar nueva versión junto a producción 2. Enrutar 5-10% del tráfico a la nueva versión 3. Monitorear métricas (latencia, tasa de error, métricas de negocio) 4. Incrementar gradualmente el tráfico si las métricas se mantienen 5. Completar despliegue o rollback basado en resultados

Herramientas: Istio, Argo Rollouts y Flagger automatizan la entrega progresiva con rollback automático ante degradación de métricas.

Pruebas A/B

Comparar versiones de modelos para medir impacto en el negocio:¹²

Diferencias clave con canary: - Canary detecta problemas (minutos a horas) - Pruebas A/B miden impacto (días a semanas) - Se requiere significancia estadística para conclusiones A/B

Implementación: - Hash de IDs de usuario para enrutamiento consistente - Rastrear métricas de conversión por variante - Ejecutar hasta alcanzar significancia estadística - Documentar resultados para referencia futura

Despliegue shadow

Enrutar tráfico de producción al nuevo modelo sin servir respuestas:

Beneficios: - Probar con patrones de tráfico reales - Comparar salidas sin impacto en usuarios - Identificar casos extremos antes del despliegue

Implementación: - El modelo de producción sirve respuestas - El modelo shadow procesa las mismas peticiones - Las salidas se comparan pero no se devuelven a usuarios - Las discrepancias activan investigación

Procedimientos de rollback

Cada despliegue necesita capacidad de rollback:

Rollback inmediato:

# Rollback de enrutamiento de tráfico
kubectl set image deployment/model-service model=model:v1.2.0

# Rollback de feature flag
feature_flags.disable("new_model_v2")

Rollback basado en registro: ```py

[Contenido truncado para traducción]