ONNX Runtime en el edge: inferencia portable y rápida
Actualizado: 2026-05-03
Desplegar un modelo de machine learning fuera del notebook donde se entrenó suele ser donde la fantasía se rompe: entrenas en PyTorch con una GPU en la nube y de repente tienes que servir inferencia en un servidor Linux, dentro de una app iOS, sobre un gateway industrial ARM y en una pestaña del navegador del cliente. Cada destino trae su propio runtime. ONNX Runtime[1] es la apuesta a la que más gente llega cuando ese dolor se vuelve crónico.
Puntos clave
- ONNX Runtime convierte el formato ONNX en herramienta utilizable: exportas una vez desde PyTorch o TensorFlow y ejecutas en casi cualquier sitio con el mismo artefacto.
- Los Execution Providers (EPs) separan el grafo del hardware; el mismo código corre en GPU de datacenter en desarrollo y en CPU de edge en producción.
- La cuantización dinámica es la puerta barata: una línea, sin calibración, 4× de reducción de tamaño en CNNs típicas.
- El estado real de los EPs de NPU en el primer trimestre de 2024 va por detrás de la narrativa comercial.
- Si el despliegue es exclusivamente GPU NVIDIA grande, TensorRT o vLLM probablemente ganen.
Qué resuelve ONNX de verdad
El problema no es técnico puro, es organizativo. Un equipo de ML que entrena en PyTorch y un equipo de mobile que integra en iOS hablan lenguajes distintos. Sin formato puente, cada nuevo target añade semanas de reingeniería: convertir el grafo, validar outputs, redescubrir operadores no soportados.
ONNX corta ese nudo proponiendo un formato intermedio abierto — un grafo computacional con operadores estándar versionados por opset. ONNX Runtime es la implementación de referencia: un artefacto .onnx que vale para servidor, móvil, browser y edge sin multiplicar el tooling.
Si el equipo vive exclusivamente en un ecosistema, la alternativa nativa suele rendir más. TensorRT saca más de una GPU NVIDIA; Core ML exprime mejor un A17 Pro. Pero en cuanto aparece el segundo target, el coste de mantener dos o tres runtimes nativos supera lo que se perdió eligiendo el denominador común.
Export: el paso que parece fácil
Todo el valor de ONNX Runtime depende de que el export funcione. En PyTorch el elemento crítico es declarar qué ejes son dinámicos:
import torch
dummy_input = torch.randn(1, 3, 224, 224)
torch.onnx.export(
model,
dummy_input,
"model.onnx",
input_names=["input"],
output_names=["output"],
dynamic_axes={
"input": {0: "batch_size"},
"output": {0: "batch_size"},
},
opset_version=17,
)Sin dynamic_axes, el modelo queda congelado a batch size 1 y rompe en producción. El opset_version=17 es un buen equilibrio: suficientemente moderno para modelos recientes y suficientemente antiguo para que todos los EPs lo entiendan.
El paso no-negociable después del export es la validación: alimentar el mismo tensor al modelo PyTorch y a la sesión ONNX Runtime y comparar con np.allclose a tolerancia conservadora. Fuentes típicas de discrepancia: operadores custom mal traducidos y diferencias float32/float16.
Execution Providers: donde vive el rendimiento
La arquitectura separa el grafo del hardware mediante Execution Providers. El EP por defecto es CPU (optimizado con MLAS), pero el argumento real del runtime es la lista que se añade encima:
- CUDA y TensorRT para NVIDIA.
- OpenVINO para Intel.
- DirectML para Windows con cualquier GPU.
- ROCm para AMD en Linux.
- Core ML para Apple Silicon.
- NNAPI para Android.
- QNN para Snapdragon.
- WebGPU y WebAssembly para el navegador.
La configuración es una lista priorizada: el runtime intenta el primero, cae al siguiente si el hardware no está disponible y termina en CPU como red de seguridad. El mismo código Python hace inferencia en GPU de datacenter en desarrollo y en CPU del edge en producción sin cambiar una línea. Este patrón complementa bien la automatización industrial descrita en redes 5G privadas en planta, donde los gateways ARM necesitan inferencia local sin dependencia de nube.
Cuantización y optimización de grafo
Al cargar el modelo, ONNX Runtime aplica pasadas automáticas —fusión de operadores, constant folding, eliminación de nodos muertos— sin intervención. El salto grande en tamaño y latencia viene de la cuantización:
- Dinámica: una línea, sin calibración, aceptable para la mayoría de CNNs. Reducción 4× en tamaño.
- Estática: con dataset de calibración representativo. Necesaria para el 2-4× completo en latencia.
En modelos grandes como Whisper o BERT, INT8 es muchas veces la diferencia entre correr en un móvil decente y no correr.
Browser, móvil y el caso real del edge
onnxruntime-web ejecuta modelos ONNX en el navegador usando WebGPU cuando está disponible y WebAssembly como fallback. Para image classification, detección o un Whisper-tiny transcribiendo en el cliente, desaparece la necesidad de un servicio de inferencia y su factura de GPU.
En móvil, ONNX Runtime Mobile produce .aar para Android y frameworks Swift/Objective-C para iOS. En edge embebido —Jetson, Raspberry Pi, gateways industriales ARM— el argumento es portabilidad: iterar en workstation con CUDA, validar en laptop con CPU y desplegar en Jetson Orin con el EP de TensorRT sin reescribir nada.
La capacidad de servir modelos cuantizados en dispositivos heterogéneos es donde ONNX Runtime resulta más valioso en proyectos que mezclan servidores, móviles y edge industrial.
Conclusión
ONNX Runtime no es el motor más rápido en ninguna plataforma concreta y casi ningún benchmark puntual lo convertirá en campeón. No lo pretende. Su propuesta es absorber la complejidad de la heterogeneidad: un artefacto, un API, muchos targets y suficiente margen de rendimiento en cada uno para que la portabilidad salga rentable. La advertencia honesta al primer trimestre de 2024 es el estado de las NPUs: la narrativa comercial va por delante de la realidad operativa. Para todo lo demás —CPU, GPU consumer, browser, mobile clásico— ya es la elección sensata.
