Tu IA de reciclaje llega 1,5 metros tarde, y la física no espera

Vi cómo una botella de PET aplastada pasaba junto a un eyector neumático a cuatro metros por segundo, intacta, y supe que algo estaba fundamentalmente roto.

Estábamos en una Instalación de Recuperación de Materiales —una MRF, en la jerga del sector— en algún lugar ruidoso y caluroso, viendo una demostración de un sistema de clasificación con IA conectado a la nube. El discurso era pulido. El panel de control era precioso. La red neuronal podía identificar diecisiete tipos de materiales con una precisión impresionante en un banco de pruebas. Pero en la cinta en vivo, con basura real moviéndose a velocidad real, el sistema fallaba una y otra vez. No porque el modelo estuviera equivocado. Sino porque la respuesta llegaba demasiado tarde.

Ese momento cristalizó algo alrededor de lo cual llevaba meses dando vueltas. La industria del reciclaje no tiene un problema de precisión de la IA. Tiene un problema de física. Y ninguna cantidad de ajuste fino del modelo ni de optimización de API lo va a arreglar, porque la restricción no está en el algoritmo, está en la arquitectura.

Volví a nuestra oficina e hice las cuentas que ahora están en el centro de nuestra investigación sobre IA de borde con FPGA para la recuperación de materiales. El número que lo cambió todo: 1,5 metros. Esa es la distancia que recorre un trozo de material reciclable sobre una cinta transportadora estándar durante el tiempo que un sistema de IA en la nube tarda en pensar.

¿Qué ocurre en 500 milisegundos?

Medio segundo suena a nada. Parpadeas en unos 300 milisegundos. Pero en una cinta transportadora que va a 3 metros por segundo —una velocidad modesta para las líneas de clasificación modernas— 500 milisegundos significan que el objeto se ha movido un metro y medio. A 6 metros por segundo, cifra que las instalaciones de alto rendimiento como las que usan la tecnología SPEEDAIR de TOMRA alcanzan habitualmente, ese número se duplica hasta los 3 metros.

Un ciclo de ida y vuelta de inferencia de IA en la nube estándar —captura de la cámara, codificación, transmisión, encolado, agrupamiento en la GPU, inferencia y retorno— tarda aproximadamente 500 milisegundos. Eso no es el peor de los casos. Es un agregado realista de cada paso de la cadena.

A velocidades de cinta industriales, un retardo de inferencia en la nube de 500 ms genera un desplazamiento ciego de 1,5 a 3,0 metros, que supera con creces la precisión requerida para la eyección neumática.

El mecanismo de eyección de estas máquinas es una fila de diminutas válvulas neumáticas, espaciadas entre 12,5 y 31 milímetros, que disparan ráfagas precisas de aire comprimido. Necesitan acertar en el centro de masa de una botella, lata o fragmento de plástico específico sin perturbar el material contiguo. La tolerancia espacial se mide en milímetros. La nube entrega respuestas medidas en metros.

Recuerdo explicarle esto a un inversor que insistía en preguntar por qué no podíamos "simplemente usar una API más rápida". Cogí una servilleta y dibujé la cinta, la cámara, la nube, el eyector. Escribí la ecuación —desplazamiento igual a velocidad por tiempo— y vi cómo cambiaba su cara. Es la ecuación más simple de la física, y demuele por completo toda la tesis de la IA en la nube para clasificación.

¿Por qué no puedes simplemente "mirar hacia adelante"?

Esta es la primera objeción que todo el mundo plantea, y es razonable. Si la nube tarda 500 milisegundos en responder, basta con montar la cámara 1,5 metros aguas arriba y dejar que el sistema "mire hacia adelante", ¿no?

Intentamos razonarlo. Mi equipo pasó dos semanas modelándolo, y la respuesta es: funciona en una pizarra y se desmorona en el suelo de una fábrica.

El problema es que las cintas transportadoras no son instrumentos de precisión. Vibran. Los motores zumban a frecuencias que hacen que los plásticos ligeros se desvíen lateralmente. A velocidades superiores a 4 metros por segundo, las películas finas y el papel se comportan como diminutos perfiles aerodinámicos —los operarios lo llaman el efecto "alfombra voladora"— despegándose de la superficie de la cinta y ondeando de forma impredecible. Las pesadas botellas de vidrio ruedan hacia las bandejas de plástico, sacando a ambas de su trayectoria.

A lo largo de una distancia de recorrido de 1,5 metros, estas fuerzas estocásticas se acumulan. Un recipiente ligero que estaba perfectamente centrado bajo la cámara podría estar dos centímetros a la izquierda para cuando llega al eyector. Los algoritmos de seguimiento lineal pueden compensar una velocidad de cinta constante, pero no pueden predecir colisiones entre un frasco de vidrio y un vaso de yogur que aún no han ocurrido.

También está la cruda restricción física. En instalaciones de campo existente —que son la mayor parte de la industria del reciclaje— no puedes simplemente alargar una línea de transporte dos metros. Tendrías que rediseñar la disposición de la planta, mover pórticos, alterar los ángulos de alimentación. El CapEx es enorme, y lo estás gastando para acomodar un sistema de IA lento en lugar de arreglar la lentitud.

Y luego está la opción de la que nadie quiere hablar: ralentizar la cinta. Si no puedes clasificar con precisión a 4 metros por segundo, baja a 1 metro por segundo. Problema resuelto, salvo que acabas de recortar la capacidad de procesamiento de tu instalación en un 75 %. En una industria que funciona con márgenes ajustados por tonelada, eso no es un compromiso. Es una sentencia de muerte para el caso de negocio.

El enemigo que no puedes ver: el jitter

La latencia media ya es bastante mala. Pero el verdadero asesino es el jitter —la variación de esa latencia de una inferencia a la siguiente.

Un sistema en la nube podría promediar 500 milisegundos, pero las solicitudes individuales fluctúan. Una vuelve en 480 ms, la siguiente en 520 ms, y ocasionalmente una tarda 600 ms porque el búfer de un router se llenó en algún punto de Ohio. Esa variación de ±50 ms crea una ventana de incertidumbre de disparo de 100 milisegundos. A 3 metros por segundo, 100 ms son 300 milímetros de recorrido.

Para garantizar un impacto dentro de esa ventana, el sistema necesitaría disparar una ráfaga de aire comprimido que cubriera una zona de 30 centímetros. Eso desperdicia cantidades enormes de aire comprimido y eyecta todo lo que hay en esa zona: el material objetivo y el material bueno que está junto a él. La pureza se desploma.

Tuve una acalorada discusión con un colega sobre esto. Él insistía en que la nube de borde 5G resolvería el problema del jitter. Le mostré los números: incluso el borde 5G introduce de 20 a 50 milisegundos de latencia con su propio perfil de jitter. A 6 metros por segundo, 20 ms siguen siendo 120 milímetros de desplazamiento. Mejor que la nube, pero aún un orden de magnitud demasiado impreciso para válvulas espaciadas con un paso de 12,5 mm.

En la clasificación de alta velocidad, la latencia de cola —el retardo en el percentil 99— importa más que la latencia media. Si el 1 % de los paquetes llega tarde, el 1 % de tu material clasificado está mal.

Para una instalación que procesa 50 toneladas por hora, una caída de pureza del 1 % significa 500 kilogramos de contaminantes por hora colándose en lo que debería ser fardos limpios. Eso basta para degradar un fardo de Grado A a Grado B, o para provocar el rechazo directo por parte de un comprador. La economía se desmorona rápido.

Por qué elegimos el silicio programable

Una vez que entendí que el problema era arquitectónico —no algorítmico— el espacio de soluciones se estrechó drásticamente. Necesitábamos una latencia de inferencia por debajo de 2 milisegundos, y necesitábamos que ese número fuera determinista. No "normalmente por debajo de 2 ms". Siempre por debajo de 2 ms. Cada vez, sin excepción.

Ese requisito elimina las GPU, incluso las GPU de borde. Una GPU local puede alcanzar de 15 a 50 milisegundos, muchísimo mejor que la nube, pero es variable. Las GPU funcionan sobre sistemas operativos. Los sistemas operativos hacen cambios de contexto, gestionan interrupciones, registran sistemas de archivos y ocasionalmente deciden que es un momento estupendo para ejecutar una actualización en segundo plano. Incluso Linux de Tiempo Real (PREEMPT_RT) es fundamentalmente un sistema de tiempo compartido. No puede garantizar que la inferencia de IA no sea interrumpida por un controlador de red o un demonio SSH.

Así que recurrimos a las FPGA —Matrices de Puertas Programables en Campo. Y aquí es donde tengo que explicar algo que me llevó un tiempo interiorizar del todo, incluso con formación técnica.

Una FPGA no es un procesador. No ejecuta instrucciones. No escribes software para ella en el sentido tradicional. En cambio, configuras su tejido de silicio para que se convierta en el circuito que implementa tu algoritmo. La red neuronal no es un programa que se ejecuta sobre el hardware: es el hardware.

Esta distinción suena académica hasta que ves lo que significa para la latencia. Una CPU busca una instrucción, la decodifica, busca datos, ejecuta, almacena el resultado y repite esto miles de millones de veces. Una FPGA no tiene búsqueda de instrucciones. No hay contador de programa. Los datos fluyen a través de una tubería física de puertas lógicas como el agua por una cañería. En cuanto llega el primer píxel del sensor de la cámara, comienza el procesamiento. El sistema no espera a que se almacene un fotograma completo en el búfer.

El resultado: inferencia determinista por debajo de 2 milisegundos. A 3 metros por segundo, eso son 6 milímetros de desplazamiento del objeto. A 6 metros por segundo, 12 milímetros. Ambos muy dentro del margen de precisión de las boquillas eyectoras neumáticas.

Un sistema de visión basado en FPGA puede tener listo el resultado de inferencia para la parte superior de una imagen antes de que la cámara haya terminado de transmitir la parte inferior de la imagen.

¿Cómo encajas una red neuronal en un chip?

Hubo una noche —tarde, demasiado café, la oficina vacía— en la que estaba mirando fijamente las especificaciones de memoria de la FPGA que habíamos seleccionado y haciendo la aritmética sobre el número de pesos de nuestro modelo. Los números no cuadraban. Nuestra red neuronal era demasiado grande para la memoria interna del chip. Una FPGA tiene megabytes de almacenamiento interno rápido, no los gigabytes de VRAM que obtienes en una GPU.

Esta es la crítica histórica a las FPGA para la IA: son rápidas pero pequeñas. Y durante un tiempo, pensé que habíamos topado con un muro.

El avance decisivo fue la cuantización —específicamente, una cuantización agresiva combinada con una técnica de entrenamiento llamada Entrenamiento Consciente de la Cuantización, o QAT.

La idea central es esta. Las redes neuronales suelen entrenarse usando números de coma flotante de 32 bits (FP32) porque la matemática durante el entrenamiento necesita ser precisa. Pero una vez que un modelo está entrenado, esos pesos de 32 bits acarrean mucha más precisión de la que la tarea realmente requiere. Distinguir una botella de PET de una jarra de leche de HDPE es una distinción visual macroscópica —forma, opacidad, textura de la etiqueta. No necesitas 32 bits de precisión numérica para captar eso.

Comprimimos nuestros modelos a INT8 (enteros de 8 bits), lo que reduce la huella de memoria en 4 veces. Luego avanzamos aún más hasta INT4 (enteros de 4 bits) para las capas con muchos pesos, lo que la reduce en 8 veces. Nuestros benchmarks internos muestran que INT4 ofrece hasta un 77 % de mejora de rendimiento sobre INT8 en hardware FPGA compatible, manteniendo una precisión superior al 99 % del modelo FP32 original.

La clave es el QAT. A diferencia de la cuantización posterior al entrenamiento tosca, que simplemente trunca los pesos y espera lo mejor, el QAT simula el ruido de cuantización durante el entrenamiento. La red aprende a ser robusta ante una menor precisión. Es la diferencia entre pedirle a alguien que pinte con un pincel grueso después de haber dominado el trabajo de pincel fino, frente a enseñarle a pintar de forma hermosa con un pincel grueso desde el principio.

Con modelos cuantizados, toda la red neuronal cabe en la Block RAM interna de la FPGA. Sin acceso a memoria externa. Sin cuello de botella de DRAM. Los datos se mueven a terabytes por segundo dentro del chip. Usamos frameworks como FINN y hls4ml para mapear capas de red específicas a recursos específicos de la FPGA, ajustando el paralelismo de cada capa para que coincida con el rendimiento del sensor de la cámara, de modo que la tubería nunca se detenga.

¿Qué significa realmente "cero sistema operativo"?

Ejecutamos nuestra ruta crítica de inferencia sobre bare metal. Sin Linux. Sin Windows. Sin sistema operativo alguno en la parte del chip que piensa y actúa.

La gente siempre me pregunta si eso es extremo. Lo es. También es necesario.

Los chips FPGA que usamos —AMD Xilinx Zynq UltraScale+— son sistemas heterogéneos en una sola pieza de silicio. Contienen tanto tejido lógico programable como núcleos de procesador ARM físicos. Repartimos la carga de trabajo entre tres dominios:

El tejido FPGA gestiona la tubería de visión, la inferencia de la red neuronal y las señales de control de las válvulas. Lógica de hardware pura. Cero jitter. La Unidad de Procesamiento en Tiempo Real —un ARM Cortex-R5 que ejecuta C++ sobre bare metal— gestiona la configuración, las máquinas de estados y los enclavamientos de seguridad con una latencia de interrupción estrictamente acotada. Y una Unidad de Procesamiento de Aplicaciones separada que ejecuta Linux se ocupa de lo no crítico: registrar datos, servir la interfaz web, gestionar las actualizaciones remotas.

Las rutas de pensar y actuar están completamente aisladas de la ruta de reporte. Si la partición de Linux se cae —y Linux se cae— la FPGA continúa clasificando material a plena velocidad sin interrupción. He visto que esto ocurre durante las pruebas. El panel de control se apagó, el flujo de registros se detuvo, y la línea de clasificación no perdió ni un compás. Fue entonces cuando supe que la arquitectura era la correcta.

Para el desglose técnico completo de esta arquitectura —la tubería de flujo de datos, los esquemas de cuantización, el motor de sincronización sobre bare metal— consulta nuestro artículo de investigación detallado.

¿Por qué importa esto para la economía circular?

Déjame traducir los milisegundos a dinero.

Una MRF típica que procesa plástico PET con IA limitada por la nube tope la velocidad de su cinta en torno a 2 metros por segundo para acomodar la latencia y los errores de seguimiento. Rendimiento: aproximadamente 5 toneladas por hora por metro de ancho de cinta. Con inferencia de borde con FPGA a 2 ms de latencia, esa velocidad de cinta puede triplicarse hasta los 6 metros por segundo. Rendimiento: 15 toneladas por hora. La misma cinta. El mismo edificio. La misma huella.

Eso es un aumento del 300 % en capacidad de procesamiento. Para una instalación que opera dos turnos —16 horas— eso son 160 toneladas adicionales procesadas diariamente. Con el PET reciclado cotizando entre 400 y 800 dólares por tonelada, las implicaciones de ingresos se miden en millones anuales.

Pero el rendimiento es solo la mitad de la historia. La precisión importa igual de mucho. Una eyección precisa significa menos contaminantes colándose en los fardos limpios (mayor pureza, precio premium) y menos materiales objetivo omitidos accidentalmente y enviados al vertedero (mayor rendimiento, menos desperdicio). Incluso una mejora del 1-2 % en la tasa de recuperación reduce significativamente los ingresos perdidos y disminuye las tarifas de descarga en vertedero, que están subiendo a nivel mundial.

Luego está el coste operativo. Sin tarifas de salida de datos de la nube. Sin cargos de API por inferencia. Sin costes de ancho de banda por transmitir vídeo de alta definición a un centro de datos. Y las FPGA consumen de 10 a 20 vatios para la carga de trabajo de inferencia, frente a los 100 a 200 vatios de una configuración de GPU comparable —una ventaja de eficiencia de 10 veces que se acumula a lo largo de docenas de estaciones de clasificación funcionando 24/7.

El cambio de la nube a la FPGA de borde no es una preferencia técnica. Es la diferencia entre una instalación de reciclaje que funciona sobre el papel y una que funciona a velocidad.

El foso que importa

Me plantean una versión de esta pregunta con regularidad: "¿No te preocupa la mercantilización? ¿Qué pasa cuando NVIDIA saque una GPU de borde más rápida?"

Esto es lo que he llegado a creer. En una era en la que llamar a una API para clasificar una botella en un JPEG estático es un proyecto de fin de semana, el foso no es el modelo. Es la física. Es la capacidad de identificar y eyectar esa botella que se mueve a 6 metros por segundo, en medio de un flujo caótico de latas aplastadas y cartón mojado, con un 99 % de pureza, 24 horas al día, sin conexión a internet.

Eso requiere un codiseño de hardware y software —seleccionar el silicio de la FPGA, escribir el HDL, diseñar esquemas de cuantización personalizados, integrar los controladores de sensores y anclar la inferencia de visión a los pulsos del encoder para una precisión de eyección submilimétrica. No es algo que consigas envolviendo una API.

El panorama actual de la IA está lleno de empresas que operan en la capa de aplicación, desconectadas de la realidad física de las operaciones industriales. Nosotros operamos en la capa física. No entrenamos un modelo y lo entregamos. Diseñamos el circuito en el que el modelo se convierte.

La industria del reciclaje está en un punto de inflexión. Los estándares de pureza se están endureciendo. Los flujos de residuos posconsumo se están volviendo más complejos. La mano de obra escasea. Todos coinciden en que la IA es la respuesta. Pero la conversación se ha quedado atascada en qué modelo usar, cuando la verdadera pregunta es dónde y a qué velocidad se ejecuta ese modelo.

Un retardo de 500 milisegundos no es un inconveniente técnico que haya que optimizar hasta eliminarlo. Es una imposibilidad física para un proceso que opera a entre 3 y 6 metros por segundo. La ecuación es simple —desplazamiento igual a velocidad por tiempo— y le da igual el SLA de tu proveedor de nube.

El futuro de la economía circular depende de una inteligencia que sea rápida, determinista y esté ubicada en el punto exacto donde la ráfaga de aire se encuentra con la botella. No en un centro de datos. No en la nube. En el chip, en el borde, en el milisegundo que importa.