Neural Network Training Labs
Laboratorio 23 · Central · 24 / 31

📦 Exportación e inferencia

Exportación e inferencia

Objetivo

Exportar ONNX, validar paridad y medir latencia por lotes.

Dataset real

Incluye predicción, exportación y benchmark reproducible.

Fundamento matemático

Paridad numérica y costo de inferencia.

Protocolo experimental

  1. Descargar y verificar la procedencia.
  2. Conservar o crear una partición reproducible.
  3. Ajustar transformaciones únicamente con train.
  4. Seleccionar modelo e hiperparámetros usando validation.
  5. Evaluar test una sola vez tras congelar la decisión.
  6. Comparar con la línea base: PyTorch eager.
  7. Guardar configuración, entorno, métricas, predicciones, gráficos y modelo.

Ejecución

python labs/23_model_export_and_inference/train.py --quick
python labs/23_model_export_and_inference/train.py --config improved

Preparar únicamente el dataset:

python -m neural_labs.cli dataset --lab 23_model_export_and_inference

Inferencia y exportación:

neural-labs predict --lab 23_model_export_and_inference --run latest --input sample.json
neural-labs export --lab 23_model_export_and_inference --run latest --format onnx --verify

Métricas

accuracy, latency_ms, throughput, model_size_mb.

Archivos

Ejercicios

Material formativo v3

Comandos profesionales

neural-labs quality --lab 23_model_export_and_inference --quick
neural-labs benchmark --lab 23_model_export_and_inference --quick --split-seed 42 --training-seeds 41 42 43
neural-labs leaderboard

Sellado del experimento

La partición se controla con split_seed; la inicialización y el entrenamiento con training_seed. El conjunto test se abre solamente después de seleccionar el checkpoint mediante validación y escribir experiment.lock.json.

🧠 Teoría

Teoría — Exportación e inferencia

Propósito

Exportar ONNX, validar paridad y medir latencia por lotes.

Idea central

Este laboratorio estudia exportación y perfil de inferencia usando cifar10, un dataset público real procedente de Torchvision / University of Toronto.

Un modelo entrenado en PyTorch vive dentro de un intérprete de Python y un grafo dinámico; llevarlo a producción exige desacoplarlo de ese entorno y empaquetarlo en un formato portátil que un motor de inferencia optimizado pueda ejecutar en servidores, móviles o dispositivos edge. ONNX (Open Neural Network Exchange) es ese formato intermedio: representa la red como un grafo estático de operadores estándar, independiente del framework de origen. Exportar consiste en trazar el modelo entrenado y volcarlo a ONNX; a partir de ahí un runtime como ONNX Runtime lo carga y lo ejecuta con optimizaciones de bajo nivel.

La pregunta central del laboratorio es de compromisos: al pasar de PyTorch eager al modelo exportado —y opcionalmente cuantizado— ganamos velocidad y reducimos tamaño, pero debemos verificar que no rompemos la corrección. Por eso el flujo es exportar, validar paridad numérica (que ONNX y PyTorch producen la misma salida) y luego perfilar latencia, throughput y tamaño sobre cifar10, comparando siempre contra la línea base de PyTorch eager.

Fundamento matemático

Paridad numérica y costo de inferencia.

La paridad numérica es la condición de que el modelo exportado calcule esencialmente la misma función que el original. No se exige igualdad bit a bit —el reordenamiento de operaciones y las diferencias de kernels producen redondeos distintos en aritmética de punto flotante— sino que la diferencia esté acotada por una tolerancia. Se comprueba pasando las mismas entradas x por ambos grafos y midiendo, por ejemplo, la desviación máxima absoluta: máxₓ ‖f_PyTorch(x) − f_ONNX(x)‖_∞ < ε, con ε del orden de 10⁻⁵ para float32. Esta prueba es imprescindible porque un export puede "compilar" correctamente y aun así alterar la semántica (por dimensiones dinámicas mal trazadas, operadores no soportados o un modo train/eval equivocado): sin verificar paridad, un modelo desplegado podría dar predicciones sutilmente distintas a las validadas.

El costo de inferencia se descompone en tres magnitudes que suelen estar en tensión. La latencia es el tiempo de una sola pasada hacia adelante (relevante cuando importa responder rápido a cada petición); se reporta con estadísticos robustos como la mediana y percentiles (p50, p95) porque su distribución tiene colas. El throughput es el número de muestras procesadas por segundo, que crece al agrupar entradas en lotes: un lote de tamaño B amortiza los costos fijos por invocación y aprovecha el paralelismo del hardware, de modo que throughput ≈ B / latencia_lote, aunque a costa de mayor latencia por muestra individual. El tamaño del modelo (en MB) condiciona la memoria y el ancho de banda, decisivos en edge.

La cuantización es la palanca principal para reducir ambos, tamaño y latencia. Consiste en representar pesos y activaciones con enteros de baja precisión (típicamente INT8) en lugar de float32, mediante una función afín de escala s y punto cero z: r ≈ s·(q − z), donde r es el valor real y q su representación entera. Al usar 8 bits en vez de 32, la memoria se reduce hasta ≈4× y las operaciones enteras son más rápidas y eficientes energéticamente en el hardware adecuado. El precio es una pérdida de precisión numérica que puede degradar la exactitud; por eso s y z se calibran cuidadosamente y la cuantización se trata como otro compromiso a medir, no a asumir. La lectura global: exportación e inferencia optimizada solo son válidas si la paridad se verifica primero y el impacto en exactitud, latencia y tamaño se cuantifica de forma reproducible.

Protocolo científico

Riesgos de interpretación

Incluye predicción, exportación y benchmark reproducible.

El dataset refleja su proceso de recolección y no representa automáticamente otros períodos, países o poblaciones. Una asociación predictiva no demuestra causalidad.

Pregunta crítica

¿Qué compromisos existen entre tamaño, latencia y precisión?

🔗 Referencias

Las referencias apuntan a las obras; no se reproduce su contenido, la redacción es original.

🔬 Experimentos

Plan de experimentos — Exportación e inferencia

Hipótesis principal

Exportar ONNX, validar paridad y medir latencia por lotes. La hipótesis debe aceptarse o rechazarse comparando el modelo con PyTorch eager y no solo observando que la pérdida disminuye.

Experimento mínimo

  1. Ejecutar baseline.yaml con tres semillas.
  2. Ejecutar improved.yaml con las mismas semillas.
  3. Mantener fija la partición de datos dentro de cada semilla.
  4. Elegir la variante con validation.
  5. Comparar la variante elegida contra la línea base en test.
  6. Revisar intervalos de confianza, errores y costo computacional.

Experimento específico

Comparar pytorch y onnx runtime.

Variables controladas

Tabla que debe completarse

Variante Semilla Métrica validation Métrica test Tiempo Parámetros Observación
baseline 41
baseline 42
baseline 43
improved 41
improved 42
improved 43

Criterio de conclusión

La conclusión debe declarar magnitud de la mejora, incertidumbre, costo adicional, errores relevantes y condiciones bajo las cuales el resultado podría no repetirse.

📝 Evaluación

Evaluación — Exportación e inferencia

Evidencias obligatorias

Preguntas

  1. Explique con sus palabras: Paridad numérica y costo de inferencia.
  2. ¿Qué información del dataset solo puede utilizarse durante entrenamiento?
  3. ¿Por qué la línea base PyTorch eager es una comparación razonable?
  4. ¿Qué compromisos existen entre tamaño, latencia y precisión?
  5. ¿Qué cambiaría antes de usar este modelo fuera del laboratorio?

Rúbrica

Criterio Insuficiente Adecuado Excelente Peso
Integridad de datos mezcla particiones separación correcta auditoría, hashes y justificación 20%
Implementación no ejecuta entrena y evalúa código claro, reusable y probado 20%
Diseño experimental resultado aislado comparación controlada multi-semilla e incertidumbre 20%
Análisis repite métricas interpreta errores identifica sesgos, límites y costo 25%
Comunicación incompleta reporte entendible model card y conclusiones verificables 15%

La aprobación exige al menos 70% y cero errores críticos de fuga de datos.