Cómo medir un demo de IA embebida: latencia, memoria y energía

El video del demo muestra una tarjeta que reconoce un gesto, un LED verde y un texto que dice “tiempo real, ultra bajo consumo”. Un ingeniero de una armadora en el Bajío hace tres preguntas: qué tan exacto es en el dispositivo, cuántos milisegundos tarda cada inferencia y cuántos microjoules consume. Nadie tiene los números, o cada número salió de un montaje distinto. Si quieres medir un demo de IA embebida de forma que un ingeniero le crea, los cuatro resultados (exactitud, latencia, memoria y energía) tienen que salir del mismo modelo, la misma compilación y el mismo hardware, con las condiciones por escrito. Esta guía da los pasos y toma prestadas las reglas de medición del benchmark MLPerf Tiny, que se escribieron justo para que estos números se puedan comparar.

Puntos clave

• Fija la tarea, el conjunto de datos y la exactitud mínima antes de medir velocidad o energía; un modelo más rápido que no llega a la meta de exactitud no es un resultado.
• Mide la exactitud en el dispositivo, pasando por su propia extracción de features, no en el notebook de entrenamiento.
• Mide la latencia en corridas repetidas y reporta la mediana, junto con la frecuencia de reloj. MLPerf Tiny corre al menos 10 segundos y 10 inferencias por corrida, cinco veces.
• Mide la energía solo en la alimentación del núcleo, con un flanco de GPIO como disparador, y repórtala en microjoules por inferencia.
• Di si la extracción de features está incluida. MLPerf Tiny la excluye y advierte que eso puede distorsionar las comparaciones; un demo de producto normalmente no debería excluirla.

El problema: cuatro números de cuatro montajes distintos

Las afirmaciones sobre IA embebida suelen armarse por piezas: la exactitud del entrenamiento, la latencia de un benchmark del fabricante con un modelo parecido, la memoria del tamaño del archivo del modelo y el consumo de la corriente activa de la hoja de datos (datasheet). Cada pieza puede ser cierta, y aun así la combinación describe un sistema que no existe.

Banbury y sus colegas escribieron el benchmark MLPerf Tiny, junto con más de 50 organizaciones, porque el campo no tenía una forma común de medir estos sistemas. Sus reglas son una buena plantilla para cualquier demo, aunque nunca se vaya a someter a un benchmark.

Paso 1: Define la tarea, los datos y la meta de exactitud

Escribe la tarea, el conjunto de datos de prueba y la exactitud mínima aceptable antes de medir cualquier otra cosa. MLPerf Tiny lo hace para cada una de sus cuatro tareas. Para la detección de palabras clave, por ejemplo, usa el conjunto Speech Commands con diez palabras más “desconocida” y “silencio”, una CNN de referencia separable en profundidad con unos 38,600 parámetros (52.5 KB como modelo de TensorFlow Lite) y una meta de calidad de 90 % de exactitud top-1. Un envío que no llega a la meta no cuenta en su división cerrada.

Para tu demo, la meta viene de la aplicación: la tasa de falsas alarmas que tolera un usuario o la tasa de detección que necesita un equipo de mantenimiento. Después, todos los números de velocidad y energía se reportan solo para un modelo que la cumple.

Paso 2: Mide la exactitud en el dispositivo

Manda el conjunto de prueba a la tarjeta (por serial o USB), corre el pipeline completo en el dispositivo, incluida la extracción de features a partir de la entrada cruda, y regresa las salidas. Compáralas con las etiquetas en la computadora.

Así atrapas las dos fallas silenciosas más comunes: features calculadas distinto en el dispositivo que en el entrenamiento, y exactitud perdida al cuantizar a int8. La referencia de detección de anomalías de MLPerf Tiny muestra que los efectos de la cuantización son reales incluso en un benchmark bien hecho: el artículo reporta un AUC de 0.88 para el autoencoder en punto flotante y de 0.86 para el cuantizado.

Paso 3: Mide la latencia con un temporizador de hardware

Hay dos métodos que funcionan bien. En los núcleos Cortex-M que implementan el contador de ciclos de la unidad Data Watchpoint and Trace (DWT CYCCNT, definido en la arquitectura Armv7-M y ausente en núcleos Armv6-M como el Cortex-M0 y el M0+), lee el contador antes y después de la inferencia. En cualquier núcleo, cambia el estado de un pin GPIO alrededor de la llamada a la inferencia y mide el pulso con un analizador lógico o un osciloscopio.

Convierte ciclos a tiempo con el reloj real del núcleo. Como ejemplo ilustrativo, 4.8 millones de ciclos a 80 MHz son 60 ms, unas 16.7 inferencias por segundo; a 160 MHz son 30 ms. Un número de latencia sin frecuencia de reloj no se puede comparar con nada.

Repite la medición. MLPerf Tiny corre la inferencia al menos 10 segundos y al menos 10 iteraciones por corrida, hace cinco corridas y reporta la mediana del rendimiento. Las cachés, los estados de espera de la flash y las interrupciones hacen que una sola medición no sea confiable.

Decide y deja claro si la latencia incluye la extracción de features. MLPerf Tiny excluye el preprocesamiento de su ventana de medición, y sus autores señalan que eso puede distorsionar los resultados cuando la extracción de features en la práctica es parte del modelo. En un demo de producto, el número que vive el usuario la incluye, así que mide y reporta ambos.

Paso 4: Mide la memoria desde la compilación y el runtime

Flash: lee el tamaño del código más los pesos del modelo en el archivo map del linker, no solo el archivo del modelo; el runtime y los kernels también ocupan espacio. RAM: suma los buffers de muestras, los de features y la arena de tensores del runtime. El artículo de TensorFlow Lite Micro describe su planeación de memoria basada en una arena, diseñada para sistemas sin asignación dinámica; usa el reporte del propio runtime, o llena la arena con un patrón conocido y revisa cuánto se sobrescribió, para encontrar el pico real en lugar del tamaño asignado.

Paso 5: Mide la energía por inferencia en la alimentación del núcleo

La energía requiere un monitor de potencia que mida la corriente lo bastante rápido para capturar la ráfaga de la inferencia, y una forma de marcar el inicio y el fin de la ventana. El montaje de energía de MLPerf Tiny es un buen modelo: un monitor de energía aparte alimenta y mide solo la potencia que llega al núcleo del dispositivo, un administrador de E/S con traductores de nivel aísla al dispositivo de la computadora para que sus conexiones no sumen ni fuguen corriente, y el dispositivo marca la ventana de tiempo con un flanco de GPIO. El resultado se reporta en microjoules por inferencia.

Un cálculo ilustrativo: un núcleo que consume 12 mA a 3.0 V durante una inferencia de 60 ms usa 3.0 × 0.012 × 0.060 = 2.16 mJ, o 2,160 µJ por inferencia. Integra la corriente medida en la ventana en lugar de multiplicar una sola lectura por el tiempo; la corriente durante la inferencia no es plana.

Después mide también el ciclo de trabajo real: la potencia promedio en muchos ciclos, con reposo, despertar y adquisición del sensor. La energía por inferencia te habla del modelo; la potencia promedio te habla de la duración de la batería.

Paso 6: Reporta el resultado con sus condiciones

Reporta juntas la exactitud, la latencia, la memoria y la energía, con el hardware, el reloj del núcleo, el compilador y su nivel de optimización, el runtime y su versión, la versión del modelo, si el preprocesamiento está incluido y cómo se midió la energía. MLPerf Tiny separa una división cerrada (mismo modelo y datos que la referencia, cuantización permitida) de una abierta (se permiten cambios al modelo, documentados); di qué tipo de comparación soportan tus números.

Mediciones de IA embebida, comparadas

Métrica	Cómo medirla	Error común	Repórtala con
Exactitud	Conjunto de prueba pasado por el pipeline del dispositivo	Usar la exactitud del notebook o del modelo flotante	Conjunto de datos, meta de calidad, cuantizado vs flotante
Latencia	Contador DWT o pulso de GPIO, corridas repetidas, mediana	Una sola corrida; sin frecuencia de reloj; preprocesamiento omitido sin avisar	Reloj del núcleo, opciones del compilador, con y sin features
Flash	Archivo map: código + runtime + pesos	Contar solo el archivo del modelo	Runtime y versión
RAM	Buffers + memoria de features + pico medido de la arena	Tamaño asignado de la arena en vez del pico; olvidar los buffers	Tamaño de ventana, traslape
Energía por inferencia	Monitor en la alimentación del núcleo, ventana marcada por GPIO, integrada	Corriente activa de la hoja de datos × latencia; potencia de la computadora que se cuela	Voltaje de alimentación, qué se incluye
Potencia promedio	Monitor durante muchos ciclos completos	Medir con la inferencia corriendo sin parar	Ciclo de trabajo, modo de reposo

Cómo ponerlo en práctica

Si tienes una hora

Agrega un cambio de estado de GPIO alrededor de tu llamada a la inferencia y mídelo en un osciloscopio a la frecuencia de reloj con la que vas a entregar. Repite 10 veces y anota la mediana y la dispersión.

Si tienes un sprint

Pasa tu conjunto de prueba por el dispositivo, calcula la exactitud en el dispositivo, lee la flash y la RAM de la compilación y del runtime, y mide la energía por inferencia con un monitor de potencia en la alimentación del núcleo. Pon los cuatro números y sus condiciones en una sola tabla.

Si quieres que dure toda la vida del producto

Automatiza la medición como una prueba con hardware en el lazo que corra en cada versión del modelo o del firmware, y haz que la compilación falle cuando la exactitud baje de la meta o cuando la latencia, la memoria o la energía se pasen de su presupuesto.

La pregunta que debes hacerte: “¿Mis números de exactitud, latencia, memoria y energía salen todos de la misma compilación en la misma tarjeta, y alguien más podría reproducirlos con lo que dejé por escrito?”

Preguntas frecuentes

¿Cómo se mide la latencia de inferencia en un microcontrolador?

Lee un contador de ciclos de hardware (como el DWT CYCCNT de los núcleos Cortex-M Armv7-M) antes y después de la inferencia, o cambia el estado de un pin GPIO alrededor de la llamada y mide el pulso con un analizador lógico. Repite muchas veces, reporta la mediana e indica la frecuencia de reloj del núcleo.

¿Cómo se mide la energía de una inferencia de IA embebida?

Alimenta el núcleo del dispositivo desde un monitor de potencia que muestree la corriente lo bastante rápido para capturar la ráfaga, marca la ventana de inferencia con un flanco de GPIO e integra la potencia en la ventana. Reporta microjoules por inferencia y mide aparte la potencia promedio de todo el ciclo de trabajo.

¿La latencia debe incluir la extracción de features?

En un producto, normalmente sí, porque el usuario vive el pipeline completo. MLPerf Tiny excluye el preprocesamiento para poder comparar modelos, y sus autores advierten que eso puede distorsionar los resultados, así que reporta ambos números y aclara cuál es cuál.

¿Por qué la exactitud en el dispositivo es distinta de la del entrenamiento?

Las causas habituales son features calculadas de otra forma en el dispositivo, exactitud perdida en la cuantización a int8 y diferencias entre los datos de entrenamiento y los datos reales del sensor. Pasar el conjunto de prueba por el pipeline del dispositivo aísla las dos primeras.

¿Qué es MLPerf Tiny?

MLPerf Tiny es un conjunto de benchmarks de la industria para sistemas de aprendizaje automático diminutos, desarrollado por más de 50 organizaciones. Define cuatro tareas (detección de palabras clave, visual wake words, clasificación de imágenes y detección de anomalías), modelos de referencia y metas de calidad, y mide exactitud, latencia y energía con reglas comunes.

Lecturas relacionadas: del sensor a la inferencia embebida, inferencia en un Cortex-M y cómo medir el consumo de un microcontrolador.

Fuentes

1. Banbury, C., Reddi, V. J., Torelli, P., Holleman, J., et al. (2021). “MLPerf Tiny Benchmark.” Proceedings of the Neural Information Processing Systems Track on Datasets and Benchmarks. arXiv:2106.07597. https://arxiv.org/abs/2106.07597
2. Banbury, C. R., Reddi, V. J., Lam, M., Fu, W., et al. (2020). “Benchmarking TinyML Systems: Challenges and Direction.” arXiv:2003.04821. https://arxiv.org/abs/2003.04821
3. David, R., Duke, J., Jain, A., Reddi, V. J., et al. (2021). “TensorFlow Lite Micro: Embedded Machine Learning on TinyML Systems.” Proceedings of Machine Learning and Systems (MLSys). arXiv:2010.08678. https://arxiv.org/abs/2010.08678
4. Arm Ltd. Armv7-M Architecture Reference Manual (DDI 0403), unidad Data Watchpoint and Trace, contador de ciclos. https://developer.arm.com/documentation/ddi0403/latest/
5. Zhang, Y., Suda, N., Lai, L., y Chandra, V. (2017). “Hello Edge: Keyword Spotting on Microcontrollers.” arXiv:1711.07128. https://arxiv.org/abs/1711.07128