Edge inference madura: cómo elegir modo de potencia y backend marca hasta un 74% de diferencia en modelos tiny

Por Zendoric · 28 de junio de 2026.

El Jetson Orin Nano Super 8GB cuesta unos 250 dólares. En él caben ocho modelos de lenguaje pequeños funcionando en tiempo real, con GPU NVIDIA Ampere, 1.024 núcleos CUDA y 8 GB de memoria LPDDR5 unificada a 204,8 GB/s. Yuvraj Singh acaba de publicar uno de los benchmarks de inferencia en edge más completos vistos hasta la fecha: 8 modelos LLM, 4 modos de potencia, dos backends de inferencia y miles de peticiones registradas con métricas de energía por token en lugar de solo velocidad. El resultado es una hoja de ruta práctica para quienes despliegan IA en el borde de la red.

**El modo de 25 W es el punto de inflexión real**

La conclusión más accionable del estudio es que el modo de 25 W (nvpmodel -m 1, GPU a 820 MHz, CPU a 1.420 MHz) domina en todas las dimensiones que importan en producción: ofrece entre un 35 % y un 47 % más de tokens por segundo que el modo de 15 W, y al mismo tiempo mejora la eficiencia energética (tok/J) entre un 1 % y un 7 % respecto al propio 15 W, y entre un 9 % y un 23 % respecto al modo MAXN. Esto ocurre porque MAXN eleva los relojes hasta 1.020 MHz en GPU y 1.728 MHz en CPU, consumiendo entre 6,36 y 10,64 W en el rail VDD_CPU_GPU_CV, pero la inferencia de modelos pequeños en modo de usuario único está limitada por el ancho de banda de memoria, no por la capacidad de cómputo. Subir el reloj más allá de 820 MHz aporta velocidad bruta pero a un coste energético que supera la ganancia en tokens generados.

Para sistemas siempre activos esto tiene consecuencias directas: el modo MAXN puede ser apropiado cuando la latencia de prefill importa más que la factura energética (reduce el tiempo al primer token entre un 31 % y un 38 % respecto a 15 W), pero para generación continua de texto la regla es clara: 25 W es el compromiso óptimo. El modo de 7 W resulta útil para investigación de eficiencia o despliegues con batería, pero implica reiniciar el dispositivo entre cargas de modelo debido a las restricciones de memoria.

**La elección del backend es tan importante como el hardware**

El segundo hallazgo de mayor calado es la brecha entre llama.cpp y Ollama. En modelos transformer sub-1B, llama.cpp supera a Ollama entre un 36 % y un 74 % en throughput con proporcional ventaja en eficiencia energética. La diferencia más extrema afecta al modelo LFM2.5-350M de Liquid AI: a 25 W, llama.cpp genera 115,4 tok/s frente a los 27,5 de Ollama, una diferencia de 4,2 veces. En términos de tok/J, LFM2.5-350M alcanza 17,16 tok/J bajo llama.cpp y apenas 6,39 bajo Ollama en ese mismo modo.

El motivo técnico no es un fallo de configuración: Ollama cargó todos los modelos con 100 % de offload a GPU (confirmado mediante ollama ps), por lo que ninguna capa cayó a CPU. La diferencia refleja ineficiencias en los kernels CUDA de Ollama para arquitecturas SSM (State Space Models), que son la base de los modelos LFM de Liquid AI. El autor usa Ollama v0.24.0, la única versión compatible con todos los modelos en JetPack R36.4.7 en el momento de la prueba; versiones más recientes de Ollama, que usan un fork de llama.cpp más actualizado, podrían cerrar parte de esa brecha. La nota metodológica es importante: los resultados de Ollama son específicos a ese estado del software y deben revisarse periódicamente.

Donde la diferencia desaparece prácticamente es en Qwen3-0.6B y Llama3.2-1B, donde ambos backends ofrecen resultados casi idénticos (entre un 1 % y un 6 % de diferencia). Para arquitecturas transformer convencionales bien soportadas, Ollama puede ser una elección razonable si el ecosistema de gestión de modelos justifica el coste de abstracción.

**Qué modelo elegir y por qué los 101 MB son suficientes para muchos casos**

El campeón de velocidad pura es SmolLM2-135M-Instruct: 165,2 tok/s y 29,62 tok/J a 25 W, en un archivo GGUF de 101 MB cuantizado a Q4_K_M. Su consumo pico en esa configuración ronda los 5,6 W, lo que, como señala Singh, lo hace operable desde un banco de energía USB-C. Esto no es un dato trivial: significa que hay casos de uso de asistencia local, procesamiento de formularios o interfaces de voz que pueden correr sin fuente de alimentación dedicada.

En la clase de ~1B parámetros, LFM2.5-1.2B de Liquid AI lidera en velocidad (54,1 tok/s a 25 W, un 15 % más rápido que Llama3.2-1B y un 33 % más que Gemma3-1B) en el footprint más pequeño de su categoría (698 MB). Sin embargo, Gemma3-1B presenta mayor eficiencia energética total (118,5 tok/J frente a 116,2 de LFM2.5-1.2B) gracias a un consumo más moderado durante el decode (6,82 W frente a 8,52 W). La elección entre ambos depende del presupuesto energético del sistema, no solo de la velocidad.

**Lo que este estudio dice sobre el estado del arte en edge AI**

Como contexto del sector, la proliferación de modelos sub-2B de calidad —SmolLM2, LFM2.5, Qwen3, Gemma3— está transformando el espacio de edge inference de forma silenciosa pero consistente. Hace dos años, correr un modelo capaz de seguir instrucciones en un dispositivo de bajo consumo requería compromisos severos en calidad. Hoy, un chip que cuesta 250 dólares puede generar más de 165 tokens por segundo con modelos que, en tareas específicas, ofrecen resultados utilizables.

Lo que hace valioso este benchmark no es solo qué modelo gana, sino cómo está construido: metodología reproducible, datos en bruto publicados en Hugging Face con todos los logs de tegrastats, código abierto en GitHub, y una separación rigurosa entre energía de prefill y energía de decode para calcular tok/J de forma honesta. El tok/J separado por fase es un avance metodológico significativo frente a los benchmarks que simplemente dividen tokens por vatios promedio, que inflaciona artificialmente la eficiencia en cargas con prefill pesado.

La implicación práctica para quienes diseñan pipelines de IA en el borde es concreta: antes de escalar a hardware más caro o añadir nodos, vale la pena auditar el modo de potencia del dispositivo y el backend de inferencia. En este estudio, ambas decisiones combinadas pueden multiplicar por cuatro la eficiencia obtenida del mismo chip. Eso es margen de optimización que no requiere nuevo hardware.