En el N100, OpenVINO no fue más rápido. Y estuve a punto de medirlo mal
Si trabajas con modelos en equipos Intel, conoces la recomendación habitual: para inferencia en CPU, OpenVINO. Es el runtime de Intel, hecho para su hardware, y en una mini PC con un N100 parecería la elección obvia frente a ONNX Runtime.
Lo medí. En el N100, con los tres modelos que comparé, OpenVINO fue entre un 11 % y un 22 % más lento que ONNX Runtime.
Pero lo interesante no es ese resultado. Es que antes de llegar a él estuve a punto de medir otra cosa, y la medición equivocada habría pasado todas las comprobaciones.
Lo que pasó en el ensayo
Antes de tocar el N100 ensayé el protocolo en mi Mac, que tiene una CPU ARM. MobileNetV2 en FP32, OpenVINO con su configuración por defecto.
Salió rápido, y salió bien: las salidas coincidían con la referencia. La misma clase ganadora en las doce imágenes de prueba, y una similitud de coseno de 0.999 o más contra el resultado esperado.
Luego miré algo que casi nadie mira: la precisión con la que OpenVINO había decidido ejecutar el modelo.
Un modelo en FP32, y OpenVINO ejecutándolo en FP16. Sin pedirlo y sin avisar.
INFERENCE_PRECISION_HINT = float16
Es una decisión de diseño de OpenVINO, no un error: en ese procesador, FP16 corre más rápido. Pero no es la que yo le pedí, y no aparece en ninguna parte a menos que la busques. Con FP16, el p50 del modelo fue de 1.46 ms. Forzando f32, el mismo modelo en el mismo equipo tardó 2.39 ms.
Si me hubiera quedado con el primer número, habría medido un cambio de precisión y se lo habría atribuido al runtime.
Por qué la validación no lo atrapa
Esto es lo que me parece importante de todo el asunto. La comprobación habitual —¿da las mismas respuestas?— pasó. Y tenía que pasar: para clasificar imágenes, FP16 alcanza. La salida no cambia lo suficiente para que una prueba de exactitud lo note.
Así que da los mismos resultados y va más rápido no prueba que la comparación sea justa. Prueba que el cambio de precisión fue lo bastante pequeño para no notarse en ese modelo. En otro —uno más profundo, uno de regresión, uno que ya viene cuantizado— a lo mejor sí se nota. Y a lo mejor se nota en producción.
Cómo lo medí en el N100
Después del ensayo, el protocolo cambió. En todo caso FP32, la precisión se fija en f32 al compilar el modelo, y después de compilarlo se lee la precisión efectiva. Si no es f32, la medición no cuenta: se marca como inválida, aunque haya pasado todo lo demás.
compiled = core.compile_model(model, "CPU", {"INFERENCE_PRECISION_HINT": "f32"})
compiled.get_property("INFERENCE_PRECISION_HINT") # se comprueba, no se supone
Con eso, en un Intel N100 de 8 GB con Ubuntu 24.04, recién reiniciado, cien medidas tras veinte de calentamiento, batch 1 e hilos por defecto:
| Modelo | ONNX Runtime 1.30.0 | OpenVINO 2026.4.0 | OpenVINO frente a ORT |
|---|---|---|---|
| MobileNetV2 FP32 | 5.7 ms | 7.0 ms | 22 % más lento |
| ResNet18 FP32 | 22.8 ms | 26.9 ms | 18 % más lento |
| YOLO26n FP32 | 57.6 ms | 64.0 ms | 11 % más lento |
Son el p50 de la inferencia del modelo. La precisión efectiva de OpenVINO fue f32 en los tres casos, y en los tres las salidas coincidieron con la referencia. En la detección, el YOLO26n encontró los mismos objetos que la referencia, ni uno más ni uno menos.
No lo había predicho. Antes de medir escribí qué esperaba de cada caso, y en éste dejé la respuesta como incógnita. La medición la resolvió en una dirección que no esperaba.
Lo que este resultado no dice
Esto es una medición, no una sentencia sobre OpenVINO. Vale para lo que se midió, y nada más:
- Un equipo. Un N100. En un procesador con FP16 nativo, o con las instrucciones de matrices de los Xeon, la historia puede ser otra.
- Sólo la CPU. El N100 tiene una gráfica integrada, y OpenVINO sabe usarla. No la medí.
- Batch 1, latencia. OpenVINO tiene un modo pensado para procesar muchas entradas a la vez, con varios flujos en paralelo. Tampoco lo medí.
- Tres modelos, en f32. Con precisión reducida, o con la cuantización propia de OpenVINO, los números cambian.
Lo que sí dice es más modesto y, creo, más útil: en este equipo y con esta configuración, la ventaja que uno esperaría no apareció.
Lo que haría distinto al comparar runtimes
Si estás eligiendo runtime para un equipo de edge, cuatro cosas que habría hecho desde el principio:
Fija la precisión, y lee la que quedó. No la que pediste: la que el runtime eligió después de compilar. Son dos líneas de código, y son la diferencia entre comparar runtimes y comparar precisiones.
No uses la exactitud como prueba de que la comparación es justa. Que las salidas coincidan dice que el cambio no se notó en ese modelo. No dice que no haya cambio.
Escribe antes qué esperas. Aunque la respuesta sea no lo sé. Si no lo escribes, cualquier resultado parece confirmar lo que ya pensabas.
Mide en el equipo, no en tu máquina. Recién reiniciado, con calentamiento, y con p50 y p95, no con un promedio. La Mac me sirvió para encontrar el problema; la respuesta sólo la dio el N100.
La tabla completa —cinco modelos en una Raspberry Pi 5 y en el N100, con ONNX Runtime y OpenVINO— está en crtdrops.mx, junto a una revisión de modelos ONNX que corre en tu navegador sin subir el archivo a ninguna parte. Si abres uno de los modelos que medí, la herramienta lo reconoce y te enseña sus números.
Medir tu propio modelo así, en los dos equipos y con el mismo protocolo, es lo siguiente que voy a ofrecer.
crtdrops.mx — crtdrops.mx/#modelo
Israel Negrete Lepe es ingeniero en electrónica. Veinticinco años construyendo sistemas que llegan a producción: telemetría, rastreo vehicular, videovigilancia municipal, control de activos por RFID y plataformas transaccionales.