Cómo hacemos que los modelos YOLO sean más rápidos en tu chip favorito en Ultralytics

En Ultralytics, creamos modelos de visión por ordenador; básicamente, ¡enseñamos a los ordenadores a ver! Piensa en estos modelos como enormes recetas matemáticas. Están formados por operaciones (las llamamos capas) y una enorme cantidad de números que llamamos pesos.

Nuestros modelos Ultralytics YOLO procesan las imágenes tal como son en realidad: ¡matrices de números! Cada píxel no es más que valores de color, la cantidad de rojo, verde y azul (por tanto, RGB) de cada punto que compone la imagen. Llamamos «tensores» a estas matrices de números porque suena mucho mejor que «matrices multidimensionales», que suena mucho mejor que «números apilados sobre números apilados sobre números».

Cuando introduces una imagen en nuestro modelo, emprende un viaje épico por la red. Imagina tu tensor surfeando por capa tras capa, transformándose, convolucionándose y siendo manipulado matemáticamente de la forma más bella posible. Piensa en ello como una fiesta en la que los números se mezclan y socializan, extrayendo la esencia de lo que hace que un gato sea un gato o un coche sea un coche. Llamamos extracción de características a este proceso.

¿Qué sale por el otro extremo? ¡Más números! Números con significado. En las tareas de detección, te indican exactamente dónde están las cosas en tu imagen y qué son probablemente. «¡Eh, hay un 95 % de probabilidades de que eso sea un perro en las coordenadas (x, y)!». Llamamos inferencia a este proceso mágico.

Ahora bien, antes de que nuestros modelos puedan hacer su magia, tienen que ir al colegio; necesitan entrenarse. La parte del entrenamiento es donde la cosa se pone intensa.

Durante el entrenamiento, cada vez que presentamos una imagen a la red, no nos limitamos a obtener una respuesta. Hacemos dos cosas especialmente exigentes. Primero, calculamos cuánto se ha equivocado la red (lo llamamos pérdida, básicamente la distancia al centro de la diana). Segundo, y esto es lo importante, actualizamos todos y cada uno de los números (o pesos) de la red en función de esa pérdida. Piensa en ello como ajustar miles de pequeños mandos a la vez, calculando cada ajuste para que la red sea más precisa cada vez.

En esencia, entrenamos la red mediante correcciones: cada error le enseña lo que NO debe hacer y ajustamos todos esos pesos para que, cuando vuelva a ver una imagen similar, se acerque más a la respuesta correcta. En definitiva, la red aprende recibiendo pequeños empujones en la dirección correcta, error a error, hasta que empieza a acertar de lleno con las predicciones.

¿De cuántos números estamos hablando? Bueno, nuestro pequeño y adorable YOLO11n tiene unos cuantos millones de parámetros. Pero ¿YOLO11x? ¡Ese gigante tiene más de 50 millones de parámetros! Más parámetros significan más detalles que puedes codificar, como la diferencia entre dibujar con ceras y disponer de una paleta completa de artista.

Durante la inferencia, este número de parámetros se vuelve crucial. Ejecutar una red de 3 millones de parámetros es como dar una vuelta corriendo a la manzana. Ejecutar una red de 50 millones de parámetros se parece más a correr un maratón mientras haces malabares con antorchas encendidas.

Entonces, ¿qué ES exactamente el cálculo? ¿Cómo se realizan realmente todas estas operaciones con números? ¿Cómo lo hacemos más rápido? ¿Y qué significa siquiera «optimizar el cálculo»?

Cómo hacen realmente las operaciones matemáticas los chips#

El cálculo se realiza con chips. Estos pequeños cuadrados de silicio son, básicamente, los castillos de arena más organizados del universo. Cada operación que hace tu ordenador, cada suma, cada comparación, cada «si esto, entonces aquello», está grabada físicamente en el silicio. Hay circuitos físicos reales en zonas concretas del chip dedicados a sumar números y otros destinados a operaciones lógicas. Es como tener una pequeña ciudad cuyos distintos barrios se especializan en diferentes tipos de matemáticas.

Probablemente esto suene extraño, incluso aunque seas informático. Se debe a que llevamos los últimos 40 años construyendo capa sobre capa de abstracción, como una lasaña tecnológica que ha crecido tanto que ya ni siquiera podemos ver el plato del fondo. Hemos simplificado tanto las cosas que la mayoría de los programadores actuales no tienen ni idea de cómo se produce realmente el cálculo en el silicio. ¡No es culpa suya, sino que está diseñado así!

Vamos a retirar estas capas. Mira este código Python de lo más sencillo:

x = 1
if x == 1:
    y = x + 1

Estamos creando una variable x, asignándole el valor 1 y, si x es igual a 1 (alerta de spoiler: lo es), creamos y con el valor de x más 1. Tres líneas. Fácil.

Pero aquí es donde se pone interesante. Entre esas tres líneas inocentes y los electrones moviéndose realmente por el silicio, hay AL MENOS cuatro enormes capas de traducción (en realidad hay más, pero nuestra responsable de Contenido Digital dice que mi recuento de palabras ya le está provocando ansiedad). Déjame guiarte por este viaje alucinante:

Capa 1: Python → Bytecode Primero, Python lee tu código y lo compila en algo llamado bytecode, un lenguaje intermedio que resulta más fácil de digerir para los ordenadores, pero que haría que te sangraran los ojos si intentaras leerlo.

Capa 2: Bytecode → Código máquina El intérprete de Python (como CPython) toma ese bytecode y lo traduce a código máquina, las instrucciones reales que entiende tu procesador. Aquí es donde tu elegante «if x == 1» se convierte en algo como «CARGAR registro, COMPARAR registro, SALTAR si el indicador de cero está activado».

Capa 3: Código máquina → Microcódigo ¡Giro de guion! Los procesadores modernos ni siquiera ejecutan directamente el código máquina. Lo descomponen aún más en microcódigo, operaciones todavía más pequeñas que pueden gestionar los componentes internos del chip. Tu única instrucción «ADD» podría convertirse en varias microoperaciones.

Capa 4: Microcódigo → Electrónica física Por fin llegamos al silicio. Esas microoperaciones activan señales eléctricas reales que fluyen por los transistores. Miles de millones de pequeños interruptores se encienden y se apagan, los electrones danzan por rutas cuidadosamente diseñadas y, de algún modo, mágicamente, 1 + 1 se convierte en 2.

Cada capa existe para ocultar la increíble complejidad de la capa inferior. Es como esas muñecas rusas, salvo que cada muñeca habla un idioma completamente distinto y la más pequeña está literalmente hecha de rayos atrapados en arena.

¿La ironía? Esas tres líneas de Python probablemente activan MILLONES de interruptores de transistores. Pero gracias a estas abstracciones, no necesitas pensar en nada de eso. Simplemente escribes «y = x + 1» y confías en que, en algún lugar profundo del silicio, ocurre la magia.

La arquitectura#

Todas y cada una de las operaciones están implementadas físicamente en el silicio, y el LUGAR donde ocurren en el chip depende por completo de la topología del chip. Es como planificar una ciudad, pero para electrones. El sumador vive aquí, el multiplicador allí, y todos necesitan comunicarse de forma eficiente.

Hay cientos de chips diferentes en el mercado, cada uno diseñado para fines distintos. ¿Qué cambia entre ellos? La topología: cómo se sitúan e implementan las operaciones en el plano físico. A esto lo llamamos arquitectura, y vaya si tenemos unas cuantas:

• x86 (Intel y AMD): el abuelo de la informática de escritorio, complejo pero potente
• ARM: mueve tu teléfono y, cada vez más, tu portátil; diseñado para la eficiencia
• RISC-V: el rebelde de código abierto, cada vez más presente en todas partes
• PowerPC: la bestia de IBM, todavía presente en consolas y servidores
• MIPS: el favorito del mundo académico, sencillo y elegante
• SPARC: la aportación de Sun Microsystems (ahora Oracle) a la informática de alto rendimiento
• Arquitecturas de GPU (núcleos CUDA de NVIDIA, RDNA de AMD): monstruos del procesamiento paralelo

Cada arquitectura no solo organiza sus transistores de forma diferente, sino que también habla un idioma distinto. Las abstracciones que usamos para enviar instrucciones a estas máquinas son completamente diferentes. Es como tener que escribir indicaciones para alguien, pero dependiendo de su coche quizá tengas que escribirlas en francés, mandarín o mediante danza interpretativa.

El latido del silicio#

El combustible de nuestros chips son los electrones, la electricidad que fluye hacia el chip y proporciona la energía para el cálculo. Pero la energía por sí sola no basta. Para que un chip funcione realmente y mueva datos por su intrincada topología, todo depende de un componente fundamental: el reloj. Es lo que hace que los electrones fluyan por rutas concretas en momentos concretos. Sin él, solo tendrías silicio alimentado sin hacer nada.

Imagina que intentas coordinar una actuación multitudinaria en la que miles de millones de componentes deben moverse perfectamente sincronizados. Sin ritmo, sería un caos. Eso es exactamente lo que hace el reloj por tu procesador. Es un cristal que vibra a un ritmo increíblemente constante y envía pulsos eléctricos miles de millones de veces por segundo.

Cuando oyes «procesador de 3,5 GHz», ese GHz (gigahercio) es la velocidad del reloj: 3.500 millones de pulsos por segundo. Cada pulso se denomina ciclo de reloj y es la unidad de tiempo fundamental en informática.

NO ocurre NADA entre ciclos de reloj. Todo el ordenador se queda congelado, esperando el siguiente pulso. Es como el juego de «un, dos, tres, escondite inglés» más extremo del universo. En cada «luz verde» (pulso de reloj):

• Los datos se mueven entre componentes
• Se ejecutan los cálculos
• Se toman decisiones lógicas
• Se lee o se escribe en la memoria

Algunas operaciones requieren un ciclo (una suma sencilla), mientras que otras necesitan muchos ciclos (una división o la obtención de datos de la RAM). Todo está coreografiado con precisión: miles de millones de componentes realizan sus operaciones específicas, sincronizados con este ritmo implacable.

Puedes hacer overclocking a tu procesador haciendo que el cristal vibre más rápido; todo ocurre más deprisa, pero también genera más calor y se vuelve menos estable. Si lo fuerzas demasiado, el ordenador se bloquea porque los electrones literalmente no pueden seguir el ritmo.

Antiguamente, estas operaciones se implementaban con máquinas del tamaño de una habitación. Pero los componentes que realizan todo este cálculo son extraordinariamente sencillos: no son más que interruptores. Interruptores de encendido y apagado.

Conecta suficientes interruptores siguiendo el patrón adecuado y tendrás un sistema de cálculo. Toda la revolución digital se reduce a una sofisticada disposición de interruptores.

Esta sencillez significa que, si tienes interruptores, cualesquiera que sean, puedes construir un ordenador. Se han construido ordenadores funcionales con tuberías de agua y válvulas, fichas de dominó, bloques de LEGO, canicas e incluso redstone en Minecraft.

Los principios no han cambiado desde la década de 1940. Simplemente hemos aprendido a fabricar interruptores extremadamente pequeños. Tu teléfono tiene más potencia de cálculo que todos los ordenadores que enviaron a seres humanos a la Luna, y cabe en tu bolsillo porque descubrimos cómo fabricar interruptores a escala atómica.

Cuando ejecutamos redes neuronales con millones de parámetros, activamos estos diminutos interruptores miles de millones de veces por segundo, perfectamente sincronizados con el latido de ese cristal. Cada actualización de pesos, cada multiplicación de matrices y cada función de activación avanzan al ritmo del reloj.

¡No es de extrañar que entrenar modelos haga que tu ordenador suene como si intentara despegar!

Hacer que las redes neuronales hagan BRRRRR#

Vale, tenemos estos chips con miles de millones de interruptores bailando al ritmo de un cristal y queremos ejecutar en ellos redes neuronales con millones de parámetros. Debería ser fácil, ¿no? ¡Solo hay que lanzarles los números al chip y dejar que se ponga en marcha!

Ejecutar redes neuronales rápidamente es como intentar cocinar un menú de cinco platos en una cocina cuyo frigorífico está a tres manzanas, en la que solo tienes una sartén y cada ingrediente pesa 225 kilos. Las matemáticas no son el mayor problema; lo es todo lo demás.

El desajuste de arquitecturas#

La mayoría de los chips se diseñaron para ejecutar Microsoft Word, no redes neuronales. Tu CPU se construyó pensando que pasaría la vida ejecutando sentencias if, bucles y calculando de vez en cuando tus impuestos (el único cálculo que incluso los superordenadores encuentran emocionalmente agotador). Está optimizada para operaciones secuenciales: haz esto, después aquello y luego lo otro.

Pero las redes neuronales son completamente diferentes. Quieren hacerlo TODO A LA VEZ. Durante el entrenamiento, actualizas millones de pesos en función de lo erróneas que fueron tus predicciones. Durante la inferencia (es decir, al utilizar realmente el modelo entrenado), haces pasar datos por millones de cálculos simultáneamente. Imagina que tienes que multiplicar un millón de números por otro millón de números. Tu CPU, con toda su buena voluntad, quiere hacerlo de uno en uno, como un contable muy rápido pero extremadamente metódico.

Por eso las GPU se convirtieron en la columna vertebral del cálculo de IA. Las GPU se diseñaron para los videojuegos, donde necesitas calcular simultáneamente el color de millones de píxeles. Resulta que calcular colores de píxeles y realizar operaciones matemáticas de redes neuronales son sorprendentemente parecidos: ambos implican realizar la misma operación en enormes cantidades de datos en paralelo.

Pero ni siquiera las GPU son perfectas para las redes neuronales. Por eso las empresas están construyendo ahora chips de IA especializados (TPU, NPU y cualquier otra sigla que termine en PU). Estos chips se diseñan desde cero con un único objetivo: hacer que las redes neuronales sean rápidas. Son como contratar a un chef que solo sabe cocinar un plato, pero lo cocina a velocidad sobrehumana. Mientras tu CPU tiene dificultades con las operaciones matriciales secuenciales y tu GPU las gestiona bastante bien en paralelo, estos chips especializados se comen las matrices para desayunar, comer y cenar.

El muro de la memoria (o por qué mover bits es más difícil que hacer matemáticas)#

En el cálculo moderno de redes neuronales, dedicamos más tiempo y energía a MOVER datos que a CALCULAR realmente con ellos.

Piensa en el chip de tu ordenador como un brillante matemático que trabaja a la velocidad del rayo, pero cuyos libros de consulta están guardados en distintos edificios al otro lado de la ciudad. Puede resolver cualquier ecuación al instante, pero primero necesita conseguir los números, y ese trayecto tarda una eternidad.

Tu chip puede multiplicar dos números en un ciclo de reloj (recuerda, uno de esos miles de millones de pulsos por segundo). ¡Velocidad de vértigo! Pero ¿obtener esos números de la memoria y llevarlos al chip? Puede tardar CIENTOS de ciclos. Es como si tu matemático pudiera resolver un problema en un segundo, pero necesitara cinco minutos para ir andando a la biblioteca y volver.

La razón es la distancia (y el espacio). La electricidad se mueve rápido, pero no infinitamente rápido. Cuanto más lejos tenga que viajar el dato por el chip, más tardará. Los diseñadores de ordenadores resolvieron este problema creando una jerarquía de memoria, como si hubiera varios lugares de almacenamiento a diferentes distancias:

• Registros (integrados directamente en las unidades de cálculo): el escritorio de tu matemático. ¡Acceso instantáneo! Pero es diminuto: aquí solo puedes guardar unos 32 números. Es como tener notas adhesivas justo delante.
• Caché L1 (a micrómetros de distancia): la estantería de la oficina. Tarda 3-4 ciclos en recuperar algo. Aquí caben unos cuantos miles de números.
• Caché L2 (a milímetros de distancia): el archivador del pasillo. Tarda 10-15 ciclos y puede contener unos cuantos millones de números.
• Caché L3 (al otro lado del chip): el trastero de abajo. Tarda 30-50 ciclos y almacena decenas de millones de números.
• RAM (en un chip completamente distinto): el almacén al otro lado de la ciudad. Tarda entre 100 y 300 ciclos. Aquí viven tus miles de millones de números.
• SSD/disco duro (conectado mediante cables): otra ciudad entera. Tarda millones de ciclos. Almacenamiento masivo, velocidad glacial.

Las estructuras exactas varían: el chip de tu teléfono podría prescindir de la caché L3, mientras que una CPU de servidor podría tener enormes cantidades de ella. Sin embargo, el principio sigue siendo el mismo: la memoria más cercana es más rápida, pero más pequeña.

Ahora viene lo doloroso para las redes neuronales. Imagina que tu modelo Ultralytics YOLO tiene 50 millones de parámetros (ChatGPT tiene miles de millones, por cierto). Son 50 millones de números que deben viajar desde la memoria hasta las unidades de cálculo y volver. Aunque cada número ocupe solo 4 bytes, son 200 megabytes de datos que tienen que desplazarse por tu sistema.

El chip podría procesar cada número en un solo ciclo, pero si tarda 100 ciclos en obtenerlo de la RAM, pasas el 99 % del tiempo esperando la entrega. Es como tener un coche de Fórmula 1 atrapado en un atasco. Toda esa potencia de cálculo, parada y esperando a que lleguen los datos.

Esta es la idea clave: este es EL cuello de botella de la informática moderna. Se denomina cuello de botella de von Neumann. Hacer que los chips sean más rápidos calculando es relativamente fácil. Hacer que la memoria sea más rápida está alcanzando límites físicos. Por eso casi TODA la optimización del rendimiento en IA se realiza en el nivel de la memoria. Cuando los ingenieros aceleran las redes neuronales, rara vez hacen que las matemáticas sean más rápidas; buscan formas ingeniosas de mover menos datos, almacenarlos mejor en la caché o acceder a ellos de forma más inteligente.

Los chips de IA modernos no se centran únicamente en la velocidad de cálculo; se obsesionan con el ancho de banda de memoria y las estrategias de movimiento de datos. Precargan datos, reutilizan valores que ya están en la caché y organizan los cálculos para minimizar los viajes a la memoria. Los ganadores de la carrera del hardware de IA no son quienes tienen las calculadoras más rápidas, sino quienes han descubierto cómo mantenerlas abastecidas de datos. Todo consiste en optimizar los patrones de acceso a la memoria.

Cada vez que mueves un bit de datos, consumes energía. No mucha, hablamos de picojulios, pero cuando mueves terabytes por segundo, se acumula RÁPIDO. De hecho, mover datos 1 mm por un chip consume más energía que realizar el cálculo en sí.

Por eso tu portátil suena como un reactor cuando entrenas redes neuronales. No son las matemáticas las que generan calor, sino el movimiento de datos. Cada actualización de parámetros, cada cálculo de gradientes y cada pasada hacia delante están calentando literalmente tu habitación.

Los aceleradores de IA modernos son, básicamente, ejercicios de termodinámica. ¿Cuánto cálculo podemos concentrar antes de que se funda el chip? ¿A qué velocidad podemos disipar el calor? Es como hacer overclocking, pero el reloj está siempre al 11 y nosotros solo intentamos no provocar un incendio.

¿La solución? Diseño consciente de la arquitectura#

Las redes neuronales más rápidas no son necesariamente las más inteligentes; son las diseñadas teniendo en cuenta los chips. Estas redes:

• Mantienen los datos lo más cerca posible
• Reutilizan los cálculos de forma obsesiva
• Se alinean perfectamente con las capacidades del hardware
• Minimizan el movimiento de memoria a cualquier precio

Es como la diferencia entre una receta que dice «usa ingredientes de tu supermercado local» y otra que requiere importar especias del Tíbet, queso de Francia y agua de la Antártida. Puede que ambas sepan bien, pero una es sin duda más práctica.

Y por eso hacer que las redes neuronales sean rápidas es un arte. No basta con tener buenas matemáticas; necesitas comprender el hardware, respetar la jerarquía de memoria y bailar perfectamente con la arquitectura.

Bienvenido al mundo en el que la informática se encuentra con la física, la ingeniería y la pura hechicería. Donde mover un número cuesta más que calcular con él. Donde el paralelismo es rápido, pero la sincronización es la muerte. Donde tu mayor enemigo no es la complejidad, sino la distancia.

Cómo hacemos que YOLO sea más rápido#

Cuando entrenas un modelo YOLO, obtienes una red neuronal que funciona de maravilla en tu entorno de entrenamiento. Pero aquí está el detalle: tu GPU para videojuegos, tu iPhone y ese diminuto chip de una cámara de seguridad hablan idiomas completamente distintos. Tienen fortalezas diferentes, debilidades diferentes y formas muy distintas de procesar los datos.

Piénsalo así: una GPU tiene miles de núcleos que pueden trabajar simultáneamente: está diseñada para el procesamiento paralelo. Mientras tanto, un chip móvil puede tener circuitos especiales diseñados específicamente para operaciones de IA, pero solo puede gestionar determinados tipos de matemáticas. ¿Y ese dispositivo periférico de la cámara de tu timbre? Intenta ejecutar IA con un presupuesto energético menor que el de una bombilla LED.

En Ultralytics, admitimos más de una docena de formatos de exportación porque cada uno está optimizado para un hardware diferente. No se trata de tener demasiadas opciones, sino de tener la opción adecuada para TUS necesidades concretas.

Fusionar operaciones: hacer más con menos#

En el modelo YOLO original, muchas operaciones se realizan en secuencia. Por ejemplo, podríamos hacer una convolución, normalizar después los resultados y aplicar luego una función de activación. Son tres pasos independientes, cada uno de los cuales requiere sus propias lecturas y escrituras en memoria.

Pero aquí está la parte ingeniosa: podemos combinar estas operaciones en un único paso. Cuando exportamos YOLO para su implementación, fusionamos estas operaciones. En lugar de:

1. Calcular la convolución → Guardar en la memoria
2. Cargar de la memoria → Normalizar → Guardar en la memoria
3. Cargar de la memoria → Aplicar la activación → Guardar en la memoria

Hacemos:

1. Calcular la convolución + normalización + activación → Guardar en la memoria

En un modelo YOLO típico que procesa una imagen de 640×640, este sencillo truco elimina gigabytes de transferencias de memoria innecesarias. En un teléfono móvil, esa es la diferencia entre una detección fluida en tiempo real y un retraso frustrante.

Usar números más pequeños: la magia de la cuantización#

YOLO no necesita números extremadamente precisos para detectar objetos con exactitud. Durante el entrenamiento, usamos 32 bits para representar cada peso; es como usar una calculadora científica para medir los ingredientes de un sándwich. ¿Y para el despliegue real? 8 bits funcionan perfectamente.

Esto se llama cuantización y es una de nuestras técnicas de optimización más potentes. Al usar números más pequeños:

• El modelo se reduce un 75 % (de 200 MB a 50 MB para Ultralytics YOLO11x)
• Se ejecuta entre 2 y 4 veces más rápido en la mayoría de los dispositivos
• Consume mucha menos energía (la batería de tu teléfono te lo agradece)

No todas las capas de YOLO son igual de sensibles a esta reducción. ¿Las primeras capas, que detectan bordes y formas básicas? Son robustas: podemos usar números de 8 bits sin ningún problema. Las capas finales de detección, que determinan «¿esto es un gato o un perro?», necesitan algo más de precisión. Por eso ajustamos la precisión capa por capa, usando solo los bits necesarios para mantener la exactitud y maximizar la velocidad.

Hemos comprobado que, con una cuantización cuidadosa, Ultralytics YOLO mantiene el 99,5 % de su exactitud original y se ejecuta 3 veces más rápido en teléfonos. Esa es la diferencia entre un modelo de investigación y algo que realmente puedes usar en el mundo real.

Elegir el mejor algoritmo#

Hay docenas de formas diferentes de realizar la misma operación matemática. Una convolución sencilla (la operación central de YOLO) puede calcularse mediante algoritmos completamente distintos, y la mejor opción depende de tu hardware específico y del tamaño de entrada.

Cuando exportamos YOLO, nuestro framework de optimización prueba distintos algoritmos y elige el más rápido para tu caso concreto. Es como tener varias rutas hasta el mismo destino y elegir una según las condiciones actuales del tráfico. En una GPU, podríamos usar un algoritmo que procese muchos píxeles simultáneamente. En una CPU, podríamos usar uno optimizado para el procesamiento secuencial. Las matemáticas son las mismas, pero la estrategia de ejecución es completamente distinta.

Memoria: el cuello de botella oculto#

¿Recuerdas que hablábamos de que la memoria es el verdadero cuello de botella de la informática moderna? Esto es especialmente cierto en el caso de YOLO. El modelo puede tener 50 millones de parámetros y, durante la inferencia, generar gigabytes de resultados intermedios. Mover todos estos datos suele ser más lento que realizar el cálculo propiamente dicho.

Usamos varios trucos para minimizar el movimiento de datos:

Planificación inteligente: Organizamos las operaciones para que los datos se utilicen inmediatamente mientras todavía están en la memoria caché rápida. En la red piramidal de características de YOLO, esto reduce el tráfico de memoria un 40 %.

Procesamiento por bloques: En lugar de procesar una imagen completa de una vez, la dividimos en bloques más pequeños que caben en la caché. Así, el procesador puede trabajar con memoria local y rápida, en lugar de recuperar datos constantemente de la memoria principal, que es más lenta.

Reutilización de búferes: En lugar de crear memoria nueva constantemente para los resultados intermedios, reutilizamos los mismos búferes de memoria. Es increíblemente eficiente: todo el backbone de YOLO puede ejecutarse con solo un conjunto de búferes reutilizables.

Poda: menos es más#

Aquí tienes un dato sorprendente: los modelos YOLO suelen estar sobredimensionados. Podemos eliminar el 30 % de los canales de muchas capas sin apenas afectar a la exactitud. No se trata solo de hacer el modelo más pequeño: también lo hacemos más rápido, porque literalmente hay menos cálculos que realizar.

El proceso es elegante: analizamos qué partes de la red contribuyen menos a los resultados finales de detección, las eliminamos y después ajustamos el modelo para compensarlo. Un modelo YOLO11m podado puede ser un 30 % más rápido y mantener el 99 % de su exactitud original. En dispositivos alimentados por batería, esta mejora de eficiencia puede traducirse en horas adicionales de funcionamiento.

Aceleración por hardware: aprovechar los puntos fuertes de cada chip#

Cada procesador destaca en tareas diferentes, y las diferencias de rendimiento son asombrosas. El mismo modelo YOLO11n tarda:

• 45 milisegundos por fotograma en una CPU Intel moderna
• 4 milisegundos en una GPU NVIDIA RTX
• 22 milisegundos en el procesador de un teléfono de gama alta
• 15 milisegundos en un TPU periférico Google Coral

No son solo diferencias de velocidad derivadas de las frecuencias de reloj: reflejan diferencias arquitectónicas fundamentales. Las GPU tienen miles de núcleos que funcionan en paralelo, perfectos para las convoluciones de YOLO. Las NPU móviles tienen circuitos especializados diseñados específicamente para redes neuronales. Las CPU sirven para todo: son flexibles, pero no están especializadas.

La clave de la optimización es adaptar las operaciones de YOLO a lo que cada chip hace mejor. A una GPU le encanta realizar la misma operación sobre muchos datos simultáneamente. Una NPU móvil quizá solo admita determinadas operaciones, pero las ejecuta con una eficiencia extraordinaria. Un TPU periférico solo funciona con enteros de 8 bits, pero alcanza una velocidad extraordinaria dentro de esa limitación.

La magia de la compilación#

Cuando exportas un modelo YOLO, ocurre algo extraordinario entre bastidores. No nos limitamos a convertir el formato del archivo: compilamos el modelo específicamente para tu hardware de destino. Es como la diferencia entre Google Translate y un hablante nativo. El proceso de compilación:

1. Analiza tu modelo para comprender su estructura y sus requisitos
2. Tiene en cuenta las capacidades de tu hardware: en qué destaca y con qué tiene dificultades
3. Genera código optimizado que habla el lenguaje nativo de tu hardware

El compilador puede reorganizar las operaciones para aprovechar mejor la caché de tu procesador, seleccionar instrucciones especializadas compatibles con tu chip o incluso usar aprendizaje automático para encontrar la mejor estrategia de optimización. Sí, usamos IA para optimizar la IA: ¡el futuro ya está aquí!

Este paso de compilación puede multiplicar por 10 el rendimiento. El mismo modelo YOLO puede avanzar a duras penas con código genérico, pero volar con instrucciones correctamente optimizadas.

Despliegue periférico en el mundo real#

Hablemos de lo que ocurre cuando YOLO se encuentra con el mundo real, concretamente con el exigente mundo de los dispositivos periféricos. Imagina una cámara de seguridad que necesita ejecutar YOLO las 24 horas del día, los 7 días de la semana para detectar objetos. Se enfrenta a limitaciones muy estrictas:

• Memoria: quizá solo entre 512 MB y 2 GB de RAM en total
• Energía: a menudo solo entre 2 y 5 vatios (menos que un cargador de teléfono)
• Refrigeración: sin ventiladores, solo disipación pasiva del calor
• Fiabilidad: debe funcionar continuamente sin bloquearse

Esto es lo que consigue la optimización en la práctica. Una cámara de seguridad que ejecuta YOLO11s:

• Modelo original: 15 vatios, funciona a 85 °C y alcanza 20 FPS
• Optimizado con cuantización y poda: 3 vatios, unos cómodos 45 °C y alcanza 25 FPS

Hemos reducido el consumo de energía un 80 % y, al mismo tiempo, hemos mejorado el rendimiento. Esa es la diferencia entre un dispositivo que se sobrecalienta y agota las baterías y otro que funciona de forma fiable durante años.

La clave está en elegir las compensaciones adecuadas. En los dispositivos periféricos, solemos:

• Usar cuantización INT8 (menos precisión y mucho menos consumo)
• Procesar menos fotogramas cuando la actividad es baja
• Distribuir el trabajo entre distintos procesadores para controlar el calor
• Mantener los modelos lo bastante pequeños para que quepan por completo en la memoria rápida

El proceso de optimización#

En Ultralytics, seguimos un enfoque sistemático para la optimización. Primero, analizamos el rendimiento del modelo para entender dónde se emplea realmente el tiempo. A menudo, los cuellos de botella no están donde esperarías. Quizá el 80 % del tiempo se emplee en solo unas pocas capas o las transferencias de memoria dominen el tiempo de cálculo.

A continuación, aplicamos las optimizaciones de forma iterativa:

1. Empieza por los cuellos de botella más importantes
2. Aplica una optimización cada vez
3. Mide tanto la mejora de velocidad como el impacto en la exactitud
4. Conserva las optimizaciones que ofrezcan una buena relación entre ventajas e inconvenientes
5. Repite el proceso hasta alcanzar tus objetivos

Por ejemplo, al desplegar YOLO11m en un teléfono:

• Punto de partida: 200 ms por fotograma, modelo de 200 MB
• Después de la cuantización: 80 ms por fotograma, modelo de 50 MB
• Después de la poda: 60 ms por fotograma, modelo de 35 MB
• Después de fusionar operaciones: 45 ms por fotograma, modelo de 35 MB

Cada paso mejora el rendimiento y mantiene más del 99 % de la exactitud original. ¿El resultado? Detección de objetos en tiempo real en un dispositivo que cabe en tu bolsillo.

El futuro: computación heterogénea#

Los dispositivos modernos son cada vez más eficientes al utilizar varios procesadores conjuntamente. Tu teléfono no tiene un solo procesador: tiene varios, cada uno especializado en tareas diferentes:

• El sensor de la cámara tiene un ISP (procesador de señales de imagen) para el preprocesamiento
• La NPU (unidad de procesamiento neuronal) ejecuta la inferencia de YOLO
• La CPU gestiona la lógica compleja y la coordinación
• La GPU renderiza los resultados en pantalla

El futuro de la optimización de YOLO consiste en dividir el modelo de forma inteligente entre estos procesadores. Quizá la NPU se encargue de las convoluciones principales, la CPU de la lógica de detección final y la GPU de visualizar los resultados. Cada procesador hace aquello en lo que destaca, creando una canalización más eficiente de lo que podría conseguir cualquier procesador por sí solo.

Estamos desarrollando algoritmos inteligentes de partición que determinan automáticamente la mejor forma de dividir YOLO entre los procesadores disponibles, teniendo en cuenta no solo sus capacidades, sino también el coste de mover datos entre ellos.

En resumen#

Optimizar modelos YOLO no consiste solo en convertir formatos de archivo; consiste en transformar la IA más avanzada en algo que realmente funcione en el mundo real. Mediante técnicas como la cuantización (usar números más pequeños), la poda (eliminar partes innecesarias), la fusión de operaciones (combinar pasos) y la gestión inteligente de la memoria, conseguimos mejoras de rendimiento de entre 10 y 100 veces manteniendo la exactitud.

¿Lo extraordinario? No existe una optimización «mejor» universal. Un servidor en la nube con energía ilimitada necesita optimizaciones distintas a las de un dron alimentado por batería. Un teléfono con un chip de IA dedicado necesita un tratamiento distinto al de una Raspberry Pi. Por eso Ultralytics ofrece tantas opciones de exportación: cada una está optimizada para escenarios diferentes.

Todas las optimizaciones que hemos tratado tienen un objetivo: hacer que la visión artificial sea accesible en cualquier lugar. Tanto si estás creando un timbre inteligente como una aplicación para drones o un servicio masivo en la nube, te proporcionamos las herramientas necesarias para que YOLO funcione dentro de tus limitaciones.

Cuando exportas un modelo YOLO con Ultralytics, no solo estás guardando un archivo. Estás aprovechando años de investigación para hacer prácticas las redes neuronales. Estás transformando un modelo de IA de última generación en algo que puede ejecutarse en hardware real, con limitaciones reales, para resolver problemas reales.

Eso es lo que hacemos en Ultralytics. Cerramos la brecha entre la investigación en IA y el despliegue práctico. Hacemos que la visión artificial funcione en cualquier lugar, porque el futuro de la IA no consiste solo en tener los mejores modelos, sino en hacer que esos modelos sean útiles en el mundo real.