El camino entre un modelo de IA entrenado y un endpoint productivo "debería ser suave, pero rara vez lo es", abre el equipo de NVIDIA en su post técnico. La empresa bautiza con un nombre específico el conjunto de fricciones que conoce cualquier equipo de MLOps: pipeline friction, y ofrece una receta con 16 buenas prácticas distribuidas en cuatro frentes principales.
¿Qué es la fricción de pipeline?
Es cualquier obstáculo que ralentice o interrumpa el viaje de un modelo desde entrenamiento hasta inferencia productiva. A diferencia de los bugs con mensajes de error claros, la fricción se manifiesta como ineficiencia silenciosa: un modelo que consume el doble de memoria GPU esperada, un servidor de inferencia que descarta peticiones bajo carga, o un despliegue que funciona en una arquitectura de GPU pero falla en otra.
NVIDIA agrupa las fuentes más comunes en cuatro categorías: problemas de exportación del modelo, operaciones no soportadas, tamaños de entrada dinámicos y desajustes de versiones entre librerías, drivers y hardware.
¿Cómo resolver los problemas de exportación?
Casi todo equipo entrena en PyTorch o TensorFlow y exporta a ONNX como representación intermedia antes de optimizar con TensorRT. Es ahí donde aparecen los problemas: control de flujo dinámico no soportado, operaciones sin equivalente ONNX y desajustes de forma entre lo que produce el framework y lo que espera el exportador.
Las tres prácticas que recomienda NVIDIA:
- Validar exportaciones temprano y seguido: incorporar la validación al CI/CD para que cada checkpoint pruebe su exportabilidad.
- Versionar los operator sets de ONNX deliberadamente: pinear la versión y documentar el motivo. Los operator sets más nuevos soportan más operaciones pero pueden romper compatibilidad con runtimes viejos.
- Simplificar el grafo antes de exportar: eliminar componentes de entrenamiento (dropout, cabezas de pérdida auxiliar, hooks de debug) y usar pases de optimización para fusionar batch normalization. TensorRT incluye optimización de grafos automática.
¿Qué hacer con operaciones no soportadas?
Incluso con buenas prácticas de exportación, aparecen operaciones que el runtime objetivo no soporta nativamente, sobre todo en arquitecturas de frontera con mecanismos de atención exóticos, activaciones custom o normalizaciones especializadas. TensorRT puede caer en un camino de ejecución lento o fallar el build.
NVIDIA recomienda los plugins de TensorRT: implementaciones en C++ o CUDA que se integran al pipeline de optimización y aprovechan la misma selección de kernels y memoria que las operaciones nativas. Esto es preferible al graph partitioning, que introduce copias de memoria entre runtimes y bloquea optimizaciones cross-layer. Antes de escribir un plugin nuevo conviene revisar el repositorio oficial: NVIDIA mantiene plugins listos para uso y la comunidad aporta extensiones con regularidad.
¿Cómo manejar tamaños de entrada dinámicos?
Si el engine TensorRT se construye para una shape fija, cualquier desviación obliga a padding (desperdicia cómputo), resize (puede alterar el comportamiento) o reconstruir el engine (caro y lento).
La solución son los optimization profiles: cada profile define dimensiones mínima, óptima y máxima por tensor de entrada, creando un engine único capaz de manejar un rango de tamaños sin recompilar. Para imágenes entre 224×224 y 1024×1024 se define un profile con esos límites y un tamaño óptimo igual a la resolución más frecuente.
NVIDIA también sugiere definir profiles separados para patrones de carga distintos (inferencia single-image en horario bajo, lotes grandes en peak) y benchmarkear con trtexec en los tres puntos del rango para detectar cliffs de rendimiento donde el engine cambia de kernel.
¿Cómo prevenir desajustes de versiones?
Los version mismatches son las fricciones más insidiosas porque a menudo no generan error: el modelo corre con accuracy degradada o el runtime cae a un camino lento sin warning. Estas fallas silenciosas pueden persistir meses.
La matriz típica incluye framework de entrenamiento, exportador ONNX, TensorRT, CUDA Toolkit, cuDNN, driver de GPU y sistema operativo. NVIDIA recomienda:
- Pinear y documentar todo el stack en un version manifest junto al modelo.
- Usar contenedores NGC de NVIDIA, que ya empaquetan versiones compatibles de TensorRT, CUDA, cuDNN y frameworks populares.
- Probar upgrades en aislamiento: un componente a la vez con la batería de tests completa antes de avanzar.
Profiling y debugging
Aun sin fricción visible puede haber problemas de performance bajo la superficie. NVIDIA distingue tres herramientas:
- trtexec para medir latencia y throughput base del modelo aislado.
- NVIDIA Nsight Deep Learning Designer para análisis layer-level dentro del grafo.
- NVIDIA Nsight Systems para profiling de sistema completo, visualizando actividad CPU y GPU en una sola línea de tiempo.
Integración con Dynamo-Triton
Optimizar el modelo es la mitad del trabajo. En producción hay que manejar peticiones concurrentes, versiones de modelo, balanceo entre GPUs y alta disponibilidad. NVIDIA Dynamo-Triton (antes Triton Inference Server) es la plataforma open source de serving que soporta nativamente engines TensorRT junto a otros frameworks.
La recomendación final es configurar el dynamic batching de Dynamo-Triton de forma que el max batch size coincida con la dimensión máxima de los optimization profiles de TensorRT, garantizando que cualquier batch dinámico caiga dentro del rango optimizado.
¿Qué se lleva un equipo LatAm?
Para equipos chilenos sin un Site Reliability Engineer dedicado a ML, las dos prácticas con mejor ratio costo-beneficio son los contenedores NGC y el profiling con trtexec antes de cualquier conversación sobre hardware más caro. Una hora de trtexec sobre un workload real suele revelar que el bottleneck no estaba donde el equipo lo asumía, evitando inversiones costosas en GPUs adicionales que no resolverán el problema real.
