El problema: un modelo pequeño y poca autonomía
Un sensor recoge una lectura, un modelo pequeño de IA la interpreta y el dispositivo espera la siguiente medida. Si el cálculo dura pocos milisegundos, ¿por qué la batería puede agotarse rápidamente? Una posible respuesta es que el sistema pasa casi todo el tiempo esperando mientras consume energía. Dormir parece la solución natural. Sin embargo, con pausas cortas, esa elección puede gastar más energía de la que ahorra.
La pregunta central es cuánto debe durar una pausa para que el ahorro durante el sueño compense el coste de entrar y salir de ese estado. Construiremos el balance de un dispositivo hipotético, distinguiendo potencia, energía, duración de pausa y retraso de respuesta. Obtendremos un umbral calculable y una guía de qué medir en una placa. Todos los parámetros son sintéticos: no son medidas de un microcontrolador comercial, un producto EL-AI ni una batería real.
Potencia y energía: grifo y depósito, con un límite
La potencia indica la rapidez con la que consumimos energía: se mide en vatios, equivalentes a julios por segundo. La energía es la cantidad consumida en un intervalo, medida en julios. Un grifo más abierto recuerda una potencia mayor; el agua entregada recuerda la energía. La analogía solo distingue ritmo y cantidad: una batería tiene fenómenos eléctricos y químicos que un depósito ideal no describe. Para nuestro balance basta E = P × t si la potencia es constante.
Procesar a 100 milivatios durante 20 milisegundos consume 2 milijulios: 0,100 W × 0,020 s = 0,002 J. «100 mW» no expresa por sí solo el coste de una decisión porque falta el tiempo; «2 mJ por decisión» tampoco da la potencia media sin conocer la frecuencia. Por eso, comparar modelos exige declarar frecuencia de ejecución, trabajo realizado y frontera del sistema medido.
El mismo trabajo, dos formas de esperar
Definamos un ciclo T desde el inicio de una decisión hasta el inicio de la siguiente. La fase activa dura tA = 20 ms a PA = 100 mW. El tiempo restante es G = T − tA. Comparamos estrategias que realizan exactamente el mismo trabajo: en la primera, el procesador sigue inactivo pero preparado, a PI = 30 mW; en la segunda, cambia de estado, duerme a PS = 0,1 mW y vuelve a estar preparado antes del siguiente ciclo. «Inactivo» y «dormido» son estados distintos, no sinónimos.
Las transiciones de entrada y salida duran en total tX = 4 ms y consumen EX = 0,3 mJ. EX es la energía total durante esos cuatro milisegundos, no un sobrecoste añadido a otro consumo ya contado en ese intervalo. Así evitamos contar dos veces. Suponemos que el sueño conserva lo necesario para reanudar y no cambia el trabajo activo; si hay que recargar el modelo o reconstruir buffers, hay que incluir ese coste. G debe ser al menos tX para que el estado quepa temporalmente.
El balance, término a término
La primera pregunta cuantitativa es cuánta energía consume el ciclo completo. Ambas estrategias incluyen PA × tA, el trabajo útil. La estrategia siempre preparada añade PI × G. La de sueño añade EX y solo PS × (G − tX), porque las transiciones ya ocupan parte de la pausa. Todos los tiempos deben usar unidades coherentes: el código trabaja en segundos, vatios y julios, convirtiendo los resultados solo para mostrarlos.
Con una decisión por segundo, T = 1 s y G = 0,98 s. Seguir preparado cuesta 2 + 29,4 = 31,4 mJ por ciclo. Dormir cuesta 2 + 0,3 + 0,0976 = 2,3976 mJ. El término del sueño usa 0,976 s, no 0,98 s. En este ejemplo esperar cuesta mucho más que calcular cuando el procesador sigue preparado. Optimizar solo la red neuronal dejaría intacta la mayor parte del consumo de esa estrategia.
La sorpresa de las pausas cortas
Repitamos exactamente el mismo trabajo cada 25 ms. La pausa queda en solo 5 ms. El sueño cabe, porque cuatro milisegundos bastan para las transiciones, pero queda apenas un milisegundo dormido. Seguir preparado cuesta 2,15 mJ por ciclo; dormir cuesta 2,3001 mJ. La potencia dormido sigue siendo muy baja, pero la energía total aumenta. Pagamos la entrada y el regreso para un intervalo demasiado corto: es el coste oculto que una cifra de potencia no muestra.
| T (ms) | G (ms) | E inactivo (mJ) | E sueño (mJ) |
|---|---|---|---|
| 25 | 5 | 2.15 | 2.3001 |
| 30 | 10 | 2.3 | 2.3006 |
| 100 | 80 | 4.4 | 2.3076 |
| 1000 | 980 | 31.4 | 2.3976 |
Derivar el umbral: ¿cuánto debe durar la pausa?
Ahora podemos responder sin probar todas las duraciones. Restamos las energías: el trabajo activo se cancela porque es idéntico. Dormir conviene cuando su coste de transición es menor que el ahorro durante la espera. Reordenando, con PI mayor que PS, obtenemos G*. El pequeño término PS × tX corrige que EX ya cubre todo el intervalo de transición. No debe eliminarse cambiando silenciosamente la definición de EX.
En el ejemplo la pausa debe superar unos 10,02 ms y contener las transiciones. Como el cálculo activo dura 20 ms, el periodo completo debe superar unos 30,02 ms. El umbral de pausa y el de periodo son diferentes. A 30 ms seguimos apenas en el lado desfavorable: la diferencia es solo 0,0006 mJ por ciclo. No tendría sentido tratar esos decimales sintéticos como precisión garantizada de una medida real; cerca del equilibrio, error y variabilidad pueden invertir la elección.
Para leer el gráfico, sigamos primero la línea inactiva: crece deprisa porque cada milisegundo añade consumo a 30 mW. La de sueño empieza más arriba por el coste fijo de transición y crece lentamente a solo 0,1 mW. A la izquierda del cruce conviene seguir preparado; a la derecha, dormir según estas hipótesis. El gráfico no muestra la energía total de la decisión: sumar 2 mJ a ambas curvas las desplazaría hacia arriba sin cambiar el cruce.
Ahorrar energía no basta: hay que despertar a tiempo
El criterio energético no garantiza responder a tiempo. tX suma entrada y salida; la latencia de despertar es la parte necesaria para volver a operar después de un evento. Ante una medida periódica conocida podemos adelantar el despertar. Ante un evento imprevisible no: la latencia de salida forma parte del tiempo de respuesta. Un modo puede ahorrar energía y resultar incompatible con el plazo para entregar un resultado.
Zephyr documenta una política de residencia que compara el tiempo hasta el siguiente evento programado con residencia mínima más latencia de salida. Conecta el razonamiento con el software embedded, pero los parámetros pertenecen a la plataforma: nuestro G* no configura automáticamente una placa. Hay que comprobar fuentes de despertar activas, periféricos que pierden estado y restricciones de la aplicación. Una ecuación energética no sustituye esa información.
El sensor puede cambiar la conclusión sobre la batería
El balance anterior solo abarca el subsistema de procesamiento elegido. Supongamos un sensor separado, excluido de esas potencias, encendido a 5 mW. En un ciclo de un segundo añade 5 mJ a ambas estrategias. Con sueño pasamos de 2,3976 a 7,3976 mJ por decisión. La elección entre estrategias no cambia porque el término común se cancela; sí cambian mucho la energía total y el margen de mejora adicional del procesador.
No podemos apagar el sensor y seguir afirmando que prestamos el mismo servicio sin comprobarlo. Podría necesitar estabilización, recalibración o muestras continuas que se perderían dormido. Si el modelo reconoce eventos breves, muestrear menos cambia lo que puede observar. Es un compromiso entre información disponible y energía, no un ahorro gratuito. Radio, regulador y pérdidas de alimentación también entran en el balance si buscamos la autonomía del dispositivo completo.
Tres cifras distintas: energía, media y pico
La potencia media es la energía del ciclo dividida entre T. En el caso de un segundo, 2,3976 mJ equivalen a 2,3976 mW medios para el subsistema sin sensor. A 25 ms, 2,3001 mJ se convierten en 92,004 mW: la energía por decisión es parecida, pero hay cuarenta decisiones por segundo. Milijulios similares no implican autonomía similar. Siempre hay que preguntar cuántas veces se repite el trabajo.
La potencia pico es otra información. Energía y duración de transición solo determinan su potencia media, aquí 75 mW. No describen la forma temporal ni excluyen un pico mucho mayor. Sin una traza de corriente y tensión con resolución suficiente no podemos deducir el dimensionamiento de la alimentación. Del mismo modo, una latencia media de despertar no garantiza un percentil alto ni cumplir todos los plazos.
Del cálculo a la medida: qué falta realmente
Para convertir el modelo en una evaluación hardware hay que identificar placa y revisión, microcontrolador o SoC, firmware, runtime de IA, compilador, reloj y modo de potencia. Deben declararse entrada, batch y trabajo activo incluido: adquisición, preparación, inferencia y comunicación no son intercambiables. El protocolo debería integrar V(t) × I(t) sobre ciclos completos, incluir transiciones y separar arranque en frío de régimen estable. Hay que registrar temperatura y alimentación porque los parámetros pueden cambiar.
Son comprobaciones propuestas, no experimentos realizados. El material descargable solo ejecuta la aritmética del modelo, verifica el equilibrio y genera gráficos. No usa aleatoriedad ni necesita semilla; conserva entradas, versiones y resultados. El código muestra el paso decisivo: restar el tiempo de transición de la pausa y evitar contar dos veces la misma energía. El JSON permite comparar cada fila de la tabla con la salida calculada.
La respuesta: el sueño tiene que compensar
Dormir conviene cuando el tiempo disponible permite recuperar el coste de transición y conservar el servicio requerido. En el ejemplo, el equilibrio llega con una pausa de unos 10,02 ms: una pausa de 5 ms empeora el consumo y una de 980 ms lo reduce mucho. La lección es medir el ciclo entero y preguntar si el ahorro llega a tiempo, en vez de elegir siempre un modo más profundo. Solo después tiene sentido hablar de autonomía, incluyendo sensores, comunicación y pérdidas.
Fuentes y reproducibilidad
La fuente primaria de software es la documentación Zephyr sobre estados y políticas de gestión de energía, consultada en la dirección latest el 27 de septiembre de 2026. El balance y los parámetros son una construcción didáctica independiente, no un benchmark de Zephyr. No afirmamos una implementación en placa ni productos embedded ya disponibles de EL-AI. El estudio explora un tema editorial solicitado sin convertirlo en una afirmación comercial.
Zephyr Project — System Power Management: Power States and Policies.
P_idle, P_sleep = 0.030, 0.0001 # W
E_transition, t_transition = 0.0003, 0.004 # J, s
P_active, t_active, T = 0.100, 0.020, 1.0
G = T - t_active
assert G >= t_transition
E_idle = P_active*t_active + P_idle*G
E_sleep = P_active*t_active + E_transition + P_sleep*(G-t_transition)
G_break_even = (E_transition-P_sleep*t_transition)/(P_idle-P_sleep)
print(f"{1000*E_idle:.4f} mJ; {1000*E_sleep:.4f} mJ")
print(f"{1000*G_break_even:.6f} ms")
Código, datos e instrucciones · JSON. Cálculos didácticos ejecutados con Python 3.14.0; figuras con Matplotlib 3.11.2. Análisis asistido por IA, sin afirmar revisión por pares ni humana. Portada original ImageGen ilustrativa: no documenta personas, sedes ni instalaciones de EL-AI. Fuentes consultadas el 27 de septiembre de 2026.