Exportación e inferencia
Objetivo
Exportar ONNX, validar paridad y medir latencia por lotes.
Dataset real
- Dataset:
cifar10 - Fuente: Torchvision / University of Toronto
- Referencia: https://www.cs.toronto.edu/~kriz/cifar.html
- Licencia/condiciones: Consultar términos CIFAR-10
- Uso: los datos se descargan desde la fuente; no hay ejemplos sintéticos ni archivos inventados.
Incluye predicción, exportación y benchmark reproducible.
Fundamento matemático
Paridad numérica y costo de inferencia.
Protocolo experimental
- Descargar y verificar la procedencia.
- Conservar o crear una partición reproducible.
- Ajustar transformaciones únicamente con
train. - Seleccionar modelo e hiperparámetros usando
validation. - Evaluar
testuna sola vez tras congelar la decisión. - Comparar con la línea base: PyTorch eager.
- 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
notebook.ipynb: recorrido completo y ejecutable.notebook_student.ipynb: actividades evaluables sin soluciones.notebook_solution.ipynb: resolución docente y pruebas de referencia.train.py: interfaz de terminal que usa el mismo código del cuaderno.configs/baseline.yaml: configuración base.configs/improved.yaml: configuración ampliada.data/dataset.yaml: procedencia, licencia y política de partición.
Ejercicios
- Cambiar una decisión experimental y justificarla.
- Analizar errores por clase o segmento.
- Comparar costo, precisión y latencia.
- Documentar sesgos, limitaciones y usos no recomendados.
Material formativo v3
theory.md: fundamento, protocolo y riesgos de interpretación.experiments.md: hipótesis, variables controladas y tabla multi-semilla.assessment.md: preguntas y rúbrica de evaluación.lesson.yaml: resultados de aprendizaje, prerrequisitos y entregables.
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
- Ajustar transformaciones, vocabulario, normalización y selección de variables solo con
train. - Usar
validationpara arquitectura, hiperparámetros, checkpoint y umbrales. - Evaluar
testuna vez, después de congelar las decisiones. - Comparar contra PyTorch eager.
- Reportar variación entre semillas e intervalos de confianza; una métrica puntual no expresa toda la incertidumbre.
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.
- Huyen — Designing Machine Learning Systems (O'Reilly, 2022), capítulos de despliegue y optimización de modelos — compromisos de latencia, throughput y compresión en producción.
- Jacob et al. (2018), Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference, CVPR — esquema de cuantización INT8 con aritmética entera y su calibración.
- Documentación oficial de ONNX — especificación del formato de intercambio y conjunto de operadores: https://onnx.ai/
- Documentación oficial de PyTorch (
torch.onnx/torch.export) — exportación de modelos y validación de paridad: https://pytorch.org/docs/stable/onnx.html - Fuente del dataset: https://www.cs.toronto.edu/~kriz/cifar.html
- Consulte
docs/experiment-protocol.md,docs/reproducibility.mdydocs/ethics-and-licenses.md.
🔬 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
- Ejecutar
baseline.yamlcon tres semillas. - Ejecutar
improved.yamlcon las mismas semillas. - Mantener fija la partición de datos dentro de cada semilla.
- Elegir la variante con
validation. - Comparar la variante elegida contra la línea base en
test. - Revisar intervalos de confianza, errores y costo computacional.
Experimento específico
Comparar pytorch y onnx runtime.
Variables controladas
- Dataset y política de partición.
- Semillas declaradas.
- Presupuesto de épocas y criterio de parada.
- Métrica de selección:
accuracyo la especificada en la configuración. - Hardware y versiones registradas en
environment.json.
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
- Dataset preparado y auditoría sin solapamientos.
- Notebook ejecutado sin celdas omitidas.
- Línea base y modelo neuronal comparados.
- Resultados de al menos tres semillas o justificación del costo.
- Análisis de errores y limitaciones.
- Model card actualizada.
Preguntas
- Explique con sus palabras: Paridad numérica y costo de inferencia.
- ¿Qué información del dataset solo puede utilizarse durante entrenamiento?
- ¿Por qué la línea base PyTorch eager es una comparación razonable?
- ¿Qué compromisos existen entre tamaño, latencia y precisión?
- ¿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.