Entrenamiento e inferencia son fases distintas del ciclo de un modelo. El entrenamiento ajusta pesos a partir de datos y retroalimentación; la inferencia utiliza esos pesos para producir una salida ante una entrada. Confundirlas lleva a dimensionar mal hardware, almacenamiento y costes.
Una aplicación que solo consulta un modelo no necesita necesariamente la infraestructura de entrenamiento de ese modelo.
Qué ocurre al entrenar
El sistema procesa lotes de ejemplos, calcula una pérdida y actualiza parámetros mediante optimización. Guarda pesos, estados, checkpoints y métricas. El volumen de datos, tamaño del modelo y duración del proceso determinan la capacidad necesaria y el coste de repetirlo.
Qué ocurre al inferir
La inferencia carga pesos, tokeniza una entrada, construye el contexto y ejecuta el modelo. En una respuesta generativa, produce tokens de forma iterativa y conserva una caché de atención para la secuencia. La memoria requerida depende del modelo, la precisión, el contexto y la concurrencia.
Hardware y patrón de uso
El entrenamiento suele necesitar mucho cálculo paralelo, memoria y movimiento de datos. La inferencia puede ejecutarse en CPU para cargas pequeñas o en GPU cuando el modelo y la latencia lo justifican. Un servicio interactivo y un proceso por lotes tienen prioridades distintas.
Costes que no se ven en una demo
Además del cálculo, cuenta el almacenamiento de pesos y datasets, transferencia, logs, evaluación, disponibilidad y mantenimiento. Un modelo puede responder rápido en una prueba y saturarse cuando llegan varias solicitudes con contexto largo.
Evaluar antes de publicar
Define ejemplos, casos límite, latencia máxima, tasa de errores y comportamiento cuando falta información. La velocidad de inferencia no demuestra exactitud. Conserva una versión conocida para comparar después de cambiar pesos, runtime o hardware.
Decisión de infraestructura
Para inferencia ocasional puede bastar una API o una máquina con CPU. Una carga estable y sensible a datos puede justificar un modelo local, siempre que el equipo pueda operar seguridad, memoria y actualizaciones. El objetivo es servir la aplicación, no reproducir toda la plataforma de entrenamiento.
Datos, pesos y checkpoints
El entrenamiento necesita leer datos, producir estados intermedios y guardar checkpoints. Esos archivos pueden ser grandes y deben protegerse, versionarse y copiarse. La inferencia normalmente necesita pesos y configuración, pero no todos los estados que se usaron para entrenar.
Latencia frente a throughput
La inferencia interactiva intenta mostrar el primer token pronto. Un lote puede agrupar solicitudes para usar mejor el hardware, aunque una petición individual espere. Define el objetivo antes de elegir GPU, CPU, colas o número de réplicas.
Evaluación después del entrenamiento
Un modelo puede mejorar una métrica de validación y comportarse peor con los datos reales. Prueba entradas representativas, casos fuera de distribución y formatos que la aplicación necesita. Registra la versión de pesos y del runtime para poder explicar cambios.
Operar solo la fase que necesitas
Si la organización consume un modelo por API, su servidor gestiona autenticación, contexto, datos y errores, no el entrenamiento del modelo. Si ejecuta inferencia local, añade memoria, hardware, actualizaciones y observabilidad. Entrenar desde cero incorpora además datasets, experimentación y controles de reproducción.
Separar las fases evita comprar capacidad de entrenamiento para una aplicación que solo necesita inferencia estable.
Reproducibilidad y versiones
Guarda dataset, configuración, código, pesos y métricas que produjeron una versión. En inferencia registra qué versión respondió, con qué contexto y qué runtime. Sin esa relación, una mejora o regresión no puede investigarse.
Escalar la fase correcta
El entrenamiento puede ejecutarse de forma planificada en un lote; la inferencia necesita responder mientras llegan solicitudes. Separar ambos servicios evita que una tarea de entrenamiento consuma memoria o GPU necesaria para usuarios.
La infraestructura debe reflejar el ciclo real, no el tamaño del modelo utilizado en una fase distinta.
Datos que llegan a producción
La inferencia utiliza entradas reales, que pueden diferir del dataset de entrenamiento. Protege datos, limita contexto y registra errores sin conservar información innecesaria.
Una separación útil
El equipo puede consumir un modelo entrenado por terceros y concentrarse en servir la aplicación. Esa decisión reduce infraestructura, pero mantiene responsabilidad sobre datos, evaluación, permisos y disponibilidad.
Separar fases también simplifica permisos: el servicio de inferencia no necesita acceso de escritura al dataset de entrenamiento. Limita cada componente a los datos y acciones que necesita.
La versión publicada debe poder identificarse.
Versionar lo que llega a producción
Guarda dataset, configuración, código, pesos y métricas que produjeron una versión. En inferencia registra qué versión respondió, con qué contexto y qué runtime. Así se puede investigar una mejora o regresión.
El servicio de inferencia no necesita necesariamente acceso de escritura al dataset de entrenamiento. Separar permisos reduce el alcance de un error.
Un modelo puede inferir correctamente y aun así necesitar evaluación periódica cuando cambian los datos de entrada. La velocidad no sustituye a la revisión de calidad.
La fase de inferencia debe tener sus propias alertas de latencia, memoria y errores. No asumas que las métricas de entrenamiento describen una aplicación pública.
La versión que se sirve debe poder identificarse.
Define qué métricas activan una revisión y cuándo se sustituye una versión. El servicio publicado necesita su propio ciclo de mantenimiento.
La trazabilidad permite comparar resultados y corregir decisiones técnicas.