Su dispositivo de borde fue evaluado en un pase hacia adelante. Su agente ejecutará un bucle.

La conversación sobre hardware en IA de borde se ha vuelto mucho más honesta en el último año. Un artículo reciente en este sitio argumentó que la antigua jerarquía de diseño — “maximizar el rendimiento, luego gestionar la energía y la termalidad alrededor de él” — se ha invertido, y que para implementaciones industriales la energía ahora ocupa el primer plano, mientras que el rendimiento bruto queda último. Esto sigue un argumento que esta publicación ha estado defendiendo desde hace tiempo: que los dispositivos de borde son “limitados por la termalidad, no por MIPS/computación”, y que los teléfonos inteligentes ya están en esos límites. Ambas son correcciones reales y ya estaban retrasadas.

Pero aún lleva una suposición del mundo que está corrigiendo. Cada elemento de esa jerarquía se presupone contra una carga de trabajo asumida, y la carga de trabajo contra la que casi todos siguen presupuestando es un solo pase hacia adelante: un modelo recibe una entrada, produce una salida y el silicio tiene un momento para enfriarse.

Eso no es lo que hace un agente. Un agente decide, llama a una herramienta, lee lo que devuelve y vuelve a decidir. Cuántas veces recorre ese bucle no es una propiedad de su hardware, y tampoco es realmente una propiedad de su modelo. Es una propiedad del problema que alguien le entregó esa mañana. Tengo agentes ejecutándose en hardware de borde, y lo que más me costó aceptar no fue que fueran lentos. Fue que el costo de una ejecución se estaba estableciendo en algún lugar al que no tenía visibilidad en tiempo de diseño.

The Loop Is Unbounded Until Someone Types a Number

Esto no es una formulación retórica; es así como realmente están construidos los marcos. En OpenAI’s Agents SDK, el ejecutor “ejecuta un bucle”, y cuando el modelo produce llamadas a herramientas, el tiempo de ejecución “ejecuta esas llamadas a herramientas, agrega los resultados y vuelve a ejecutar el bucle”. Lo único que lo detiene es un límite de turnos — si se supera max_turns se lanza una excepción — y la documentación indica que se puede pasar max_turns=None para desactivar el límite por completo.

En un servidor, ese número es una decisión de facturación. Alguien nota la factura.

En un dispositivo, ese número es una decisión térmica, porque la longitud del bucle es el ciclo de trabajo. Y el ciclo de trabajo es la única variable con la que la refrigeración pasiva no puede discutir.

Sustained Load Does Something Different to a Phone Than a Benchmark Does

Un benchmark de marzo de 2026 puso cuatro plataformas bajo exactamente este tipo de carga: un modelo cuantizado de 1.5 mil millones de parámetros, un prompt fijo de 258 tokens, veinte ejecuciones consecutivas, midiendo rendimiento, energía y temperatura en cada una. Es un preprint, y evalúa un modelo en cuatro dispositivos, por lo que se deben tratar los números específicos como una caracterización de esas plataformas más que como una ley de la naturaleza. La forma del resultado es lo que importa.

Un iPhone 16 Pro alcanzó un pico de 40.35 tokens por segundo y no pudo sostenerlo. La degradación apareció dentro de dos inferencias. Se estabilizó en 22.56 tokens por segundo — una reducción del 44 % — y permaneció limitado durante el 65 % del benchmark. El escalado dinámico de voltaje y frecuencia, el mecanismo que reduce la velocidad del reloj cuando la temperatura de la unión sube, hizo precisamente lo que existe para hacer.

El Galaxy S24 Ultra falló de forma diferente, y peor. En lugar de degradarse, el gobernador térmico de Android impuso un piso rígido de frecuencia de GPU en la iteración seis, a 78.3 °C, y la inferencia se detuvo. Los autores hacen el punto que aquí importa mejor que yo podría: para implementaciones de agentes, esto es “más disruptivo que una degradación gradual”, porque el sistema no se vuelve más lento; se vuelve inutilizable.

Ahora mantenga el detalle que hace que esto sea condenatorio y no solo interesante. Cada una de esas veinte ejecuciones usó el mismo prompt. Esa es la carga de trabajo más amigable que el hardware de un agente verá jamás, y dos teléfonos insignia no pudieron sostenerla durante veinte repeticiones. Esto tampoco es un hallazgo nuevo — punto MELTing, presentado en MobiCom en 2024, concluyó que por motivos de energía y termalidad “la ejecución continua de LLMs sigue siendo esquiva”. Dos años y varios nodos de proceso después, la misma pared.

Two Curves Move Toward Each Other, and Your Product Breaks Where They Cross

El bucle de un agente es peor que un prompt repetido de una manera específica y mecánica.

La decodificación está limitada por el ancho de banda de memoria: el rendimiento está gobernado por la velocidad con la que el modelo puede leer su caché de clave‑valor, no por cuántas operaciones el chip puede realizar teóricamente. Esa caché crece con el contexto. Cada paso del bucle agrega un resultado de herramienta, una observación, un plan parcial — por lo que el paso diez genera tokens contra una caché materialmente mayor que la del paso uno.

Mientras tanto, el dispositivo se calienta y el gobernador reduce los relojes.

Así, el costo por paso aumenta exactamente en el momento en que la capacidad del dispositivo para pagarlo disminuye. Las dos curvas convergen, y dondequiera que se encuentren es donde su producto falla. Nunca es el paso uno. El paso uno es donde usted probó.

También hay un problema de escala debajo de esto. El trabajo generativo es simplemente un orden de gasto diferente al que el silicio de borde gastó durante una década: medido en 88 modelos, el costo de clasificación de texto ronda los 0.002 kWh por mil inferencias frente a 0.047 kWh para generación de texto — aproximadamente veinte veces más, antes de que cualquier bucle lo multiplique. esas mediciones se tomaron en una GPU de centro de datos, no en un teléfono, así que léalas como una razón entre tipos de trabajo más que como una cifra de potencia para su dispositivo. Para escala, el mismo estudio sitúa una carga completa de smartphone en 0.022 kWh.

Buy on Joules per Finished Task, Not on Tokens per Second

El resultado más útil de ese benchmark de 2026 es el que parece menos impresionante.

Un NPU Hailo-10H gestionó 6.9 tokens por segundo con menos de 2 vatios. Lento — genuinamente lento, y los autores lo afirman. Pero su coeficiente de variación del rendimiento fue del 0.04 %, dos órdenes de magnitud más estable que cualquier otro probado. La GPU de portátil en el mismo estudio entregó 131.7 tokens por segundo a 34.1 vatios.

Luego compare los dos en energía en lugar de velocidad: 270.5 milijulios por token en el pequeño NPU contra 297.3 en la GPU. A pesar de una diferencia de diecinueve veces en rendimiento, la pequeña pieza realizó ligeramente más cálculo por julio — y lo hizo con esencialmente ninguna variación.

Si selecciona hardware por tokens por segundo, compra el rápido. Si selecciona por la capacidad de completar un bucle acotado a un costo predecible, que es lo que realmente necesita un agente, el ranking cambia. La unidad que debería aparecer en la hoja de especificaciones es julios por tarea completada, con una cifra de variación al lado. Un benchmark que informa del rendimiento máximo le está hablando de la primera inferencia del día.

The Honest Objection, and What It Does Not Solve

La respuesta obvia es que este es un problema transitorio: el silicio mejora, los NPUs maduran, y cualquier cosa escrita sobre un teléfono de 2026 parecerá anticuada. O, más prácticamente, descargar los pasos costosos a un servidor.

Yo mismo apostaría por el hardware. Pero la descarga es el viaje de ida y vuelta que trasladó al borde para evitar, y un agente no lo paga una sola vez — lo paga por cada paso del bucle, y la longitud del bucle es lo que no puede predecir. Los diseños híbridos no eliminan la variación; la trasladan a la red.

La asimetría más profunda no se mueve con los nodos de proceso. El presupuesto de un dispositivo se fija en tiempo de diseño. La demanda de un agente se decide en tiempo de ejecución, por lo que el usuario solicite. Un silicio mejor eleva el techo. No le dice al agente dónde está el techo.

Así que dígale. Establezca el límite de turnos en la especificación del producto en lugar de descubrirlo en una revisión de código, y elija el número a partir del envoltorio térmico: decida cuántos pasos caben, luego diseñe el agente para producir su mejor respuesta disponible dentro de ese límite en vez de su respuesta ideal en uno arbitrario. Trátelo como una fecha límite, no como un objetivo.

Luego proporcione al agente el presupuesto como entrada. El margen restante, el estado de la batería, si la plataforma ya ha comenzado a limitar — eso pertenece al contexto, al igual que la hora actual. Un agente que sabe que está en el paso ocho de diez puede resumir y comprometerse. Un agente que no lo sabe seguirá explorando hasta que el sistema operativo decida por él.

Y pruebe la cola, no la mediana, lo que en un dispositivo físico significa probar en simulación. El caso de falla nunca es la ejecución limpia. Es la ejecución que tomó catorce pasos porque una herramienta devolvió algo ambiguo en el paso tres, y no puede enumerarlos a mano en un teléfono que necesita enfriarse entre intentos. Mis propios sistemas entrenan contra simulaciones mayormente por esta razón: el comportamiento interesante está en las ejecuciones largas, y las ejecuciones largas son exactamente lo que el hardware no le permitirá muestrear a mano.

Nada de esto requiere un chip más rápido. Requiere admitir que la carga de trabajo cambió de forma. Nadie envía un dispositivo cuya batería esté dimensionada para una fotografía. Seguimos enviando dispositivos cuyo presupuesto térmico está dimensionado para una inferencia.