La tua AI per il riciclo è in ritardo di 1,5 metri — e la fisica non aspetta

Ho visto una bottiglia di PET schiacciata sfrecciare oltre un espulsore pneumatico a quattro metri al secondo, intatta, e ho capito che qualcosa non funzionava a un livello fondamentale.

Eravamo in un Impianto di Recupero Materiali — un MRF, in gergo del settore — da qualche parte, rumoroso e caldo, a guardare una demo di un sistema di selezione basato su AI connesso al cloud. La presentazione era brillante. La dashboard era bellissima. La rete neurale riusciva a identificare diciassette tipi di materiale con un'accuratezza notevole su un banco di prova. Ma sul nastro dal vivo, con rifiuti reali che si muovevano a velocità reale, il sistema continuava a sbagliare. Non perché il modello fosse errato. Perché la risposta arrivava troppo tardi.

Quel momento ha cristallizzato qualcosa attorno a cui giravo da mesi. Il settore del riciclo non ha un problema di accuratezza dell'AI. Ha un problema di fisica. E nessun perfezionamento del modello o ottimizzazione delle API lo risolverà, perché il vincolo non è nell'algoritmo — è nell'architettura.

Sono tornato in ufficio e ho fatto i calcoli che ora sono al centro della nostra ricerca sull'AI edge FPGA per il recupero dei materiali. Il numero che ha cambiato tutto: 1.5 metri. Ecco quanta strada percorre un pezzo di materiale riciclabile su un nastro trasportatore standard nel tempo che serve a un sistema di AI nel cloud per pensare.

Cosa succede in 500 millisecondi?

Mezzo secondo sembra nulla. Sbatti le palpebre in circa 300 millisecondi. Ma su un nastro trasportatore che viaggia a 3 metri al secondo — una velocità modesta per le moderne linee di selezione — 500 millisecondi significano che l'oggetto si è spostato di un metro e mezzo. A 6 metri al secondo, velocità che gli impianti ad alta produttività come quelli che usano la tecnologia SPEEDAIR di TOMRA raggiungono regolarmente, quel numero raddoppia a 3 metri.

Un ciclo completo di inferenza AI standard nel cloud — acquisizione dalla telecamera, codifica, trasmissione, accodamento, batching su GPU, inferenza e ritorno — richiede all'incirca 500 millisecondi. Non è uno scenario peggiore. È un aggregato realistico di ogni passaggio della catena.

Alle velocità dei nastri industriali, un ritardo di inferenza nel cloud di 500 ms crea uno spostamento cieco da 1.5 a 3.0 metri — di gran lunga superiore alla precisione richiesta per l'espulsione pneumatica.

Il meccanismo di espulsione di queste macchine è una fila di minuscole valvole pneumatiche, distanziate tra 12.5 e 31 millimetri, che sparano precisi getti di aria compressa. Devono colpire il baricentro di una specifica bottiglia, lattina o frammento di plastica senza disturbare il materiale accanto. La tolleranza spaziale si misura in millimetri. Il cloud fornisce risposte misurate in metri.

Ricordo di averlo spiegato a un investitore che continuava a chiedere perché non potessimo "semplicemente usare un'API più veloce". Ho preso un tovagliolo e ho disegnato il nastro, la telecamera, il cloud, l'espulsore. Ho scritto l'equazione — spostamento uguale velocità per tempo — e ho visto cambiare la sua espressione. È l'equazione più semplice della fisica, e demolisce l'intera tesi dell'AI-nel-cloud-per-la-selezione.

Perché non puoi semplicemente "guardare avanti"?

Questa è la prima obiezione che tutti sollevano, ed è ragionevole. Se il cloud impiega 500 millisecondi per rispondere, basta montare la telecamera 1.5 metri più a monte e lasciare che il sistema "guardi avanti", giusto?

Abbiamo provato a ragionarci. Il mio team ha passato due settimane a modellarlo, e la risposta è: funziona su una lavagna e crolla sul pavimento di una fabbrica.

Il problema è che i nastri trasportatori non sono strumenti di precisione. Vibrano. I motori ronzano a frequenze che fanno derivare lateralmente le plastiche leggere. A velocità superiori a 4 metri al secondo, le pellicole sottili e la carta si comportano come minuscole ali portanti — gli operatori lo chiamano l'effetto "tappeto volante" — sollevandosi dalla superficie del nastro e svolazzando in modo imprevedibile. Le pesanti bottiglie di vetro rotolano nei vassoi di plastica, facendo deviare entrambi dalla traiettoria.

Su una distanza di percorrenza di 1.5 metri, queste forze stocastiche si sommano. Un contenitore leggero che era perfettamente centrato sotto la telecamera potrebbe trovarsi due centimetri più a sinistra quando raggiunge l'espulsore. Gli algoritmi di tracciamento lineare possono compensare una velocità costante del nastro, ma non possono prevedere collisioni tra un barattolo di vetro e un vasetto di yogurt che non sono ancora avvenute.

C'è anche il puro vincolo fisico. Nelle installazioni brownfield — che sono la maggior parte del settore del riciclo — non puoi semplicemente allungare una linea di trasporto di due metri. Dovresti riprogettare il layout dell'impianto, spostare i cavalletti, modificare gli angoli di alimentazione. Il CapEx è enorme, e lo stai spendendo per accomodare un sistema di AI lento invece di risolverne la lentezza.

E poi c'è l'opzione di cui nessuno vuole parlare: rallentare il nastro. Se non riesci a selezionare con precisione a 4 metri al secondo, scendi a 1 metro al secondo. Problema risolto — solo che hai appena tagliato del 75% la capacità di lavorazione del tuo impianto. In un settore che vive di margini risicati per tonnellata, non è un compromesso. È una condanna a morte per il business case.

Il nemico che non puoi vedere: il jitter

La latenza media è già abbastanza grave. Ma il vero killer è il jitter — la variazione di quella latenza da un'inferenza alla successiva.

Un sistema cloud potrebbe avere una media di 500 millisecondi, ma le singole richieste oscillano. Una torna in 480 ms, la successiva in 520 ms, e occasionalmente una impiega 600 ms perché il buffer di un router si è riempito da qualche parte in Ohio. Quella variazione di ±50 ms crea una finestra di incertezza di sparo di 100 millisecondi. A 3 metri al secondo, 100 ms sono 300 millimetri di percorrenza.

Per garantire un colpo a segno entro quella finestra, il sistema dovrebbe sparare un getto di aria compressa che copra una zona di 30 centimetri. Questo spreca enormi quantità di aria compressa ed espelle tutto ciò che si trova in quella zona — il materiale bersaglio e il materiale buono che gli sta accanto. La purezza crolla.

Ho avuto un'accesa discussione con un collega su questo. Insisteva che l'edge cloud 5G avrebbe risolto il problema del jitter. Gli ho mostrato i numeri: persino l'edge 5G introduce dai 20 ai 50 millisecondi di latenza con un proprio profilo di jitter. A 6 metri al secondo, 20 ms sono comunque 120 millimetri di spostamento. Meglio del cloud, ma comunque di un ordine di grandezza troppo impreciso per valvole distanziate con un passo di 12.5 mm.

Nella selezione ad alta velocità, la latenza di coda — il ritardo del 99° percentile — conta più della latenza media. Se l'1% dei pacchetti arriva in ritardo, l'1% del materiale selezionato è sbagliato.

Per un impianto che lavora 50 tonnellate all'ora, un calo di purezza dell'1% significa 500 chilogrammi di contaminanti all'ora che si intrufolano in quelle che dovrebbero essere balle pulite. È abbastanza per declassare una balla dal Grado A al Grado B, o per far scattare il rifiuto totale da parte di un acquirente. L'economia si sfalda in fretta.

Perché abbiamo scelto il silicio programmabile

Una volta capito che il problema era architetturale — non algoritmico — lo spazio delle soluzioni si è ristretto drasticamente. Avevamo bisogno di una latenza di inferenza inferiore a 2 millisecondi, e avevamo bisogno che quel numero fosse deterministico. Non "di solito sotto i 2 ms." Sempre sotto i 2 ms. Ogni singola volta.

Quel requisito elimina le GPU, persino le GPU edge. Una GPU locale può raggiungere dai 15 ai 50 millisecondi, molto meglio del cloud, ma è variabile. Le GPU girano su sistemi operativi. I sistemi operativi effettuano context switch, gestiscono interrupt, registrano i journal dei file system e occasionalmente decidono che è un ottimo momento per eseguire un aggiornamento in background. Persino Real-Time Linux (PREEMPT_RT) è fondamentalmente un sistema time-sharing. Non può garantire che l'inferenza AI non venga interrotta da un driver di rete o da un demone SSH.

Così ci siamo rivolti agli FPGA — Field-Programmable Gate Array. Ed è qui che devo spiegare qualcosa che ho impiegato un po' a interiorizzare del tutto, persino con un background tecnico.

Un FPGA non è un processore. Non esegue istruzioni. Non ci scrivi software nel senso tradizionale. Piuttosto, configuri il suo tessuto di silicio affinché diventi il circuito che implementa il tuo algoritmo. La rete neurale non è un programma in esecuzione su hardware — è l'hardware.

Questa distinzione sembra accademica finché non si vede cosa significa per la latenza. Una CPU preleva un'istruzione, la decodifica, preleva i dati, esegue, memorizza il risultato e ripete questo processo miliardi di volte. Un FPGA non ha alcun prelievo di istruzioni. Nessun program counter. I dati scorrono attraverso una pipeline fisica di porte logiche come acqua in un tubo. Non appena il primo pixel arriva dal sensore della telecamera, l'elaborazione inizia. Il sistema non aspetta che un fotogramma completo venga bufferizzato.

Il risultato: inferenza deterministica sotto i 2 millisecondi. A 3 metri al secondo, sono 6 millimetri di spostamento dell'oggetto. A 6 metri al secondo, 12 millimetri. Entrambi ampiamente entro l'inviluppo di precisione degli ugelli degli espulsori pneumatici.

Un sistema di visione basato su FPGA può avere pronto il risultato dell'inferenza per la parte superiore di un'immagine prima che la telecamera abbia finito di trasmettere la parte inferiore dell'immagine.

Come si fa a far stare una rete neurale su un chip?

C'è stata una notte — tardi, troppo caffè, l'ufficio vuoto — in cui fissavo le specifiche di memoria dell'FPGA che avevamo scelto e facevo i conti sul numero di pesi del nostro modello. I numeri non tornavano. La nostra rete neurale era troppo grande per la memoria on-chip del chip. Un FPGA ha megabyte di veloce archiviazione interna, non i gigabyte di VRAM che si ottengono su una GPU.

Questa è la critica storica agli FPGA per l'AI: sono veloci ma piccoli. E per un po' ho pensato che avessimo sbattuto contro un muro.

La svolta è stata la quantizzazione — nello specifico, la quantizzazione aggressiva combinata con una tecnica di addestramento chiamata Quantization-Aware Training, o QAT.

Ecco l'idea di fondo. Le reti neurali vengono tipicamente addestrate usando numeri in virgola mobile a 32 bit (FP32) perché la matematica durante l'addestramento deve essere precisa. Ma una volta che un modello è addestrato, quei pesi a 32 bit portano molta più precisione di quanta il compito ne richieda effettivamente. Distinguere una bottiglia di PET da un flacone di latte in HDPE è una distinzione visiva macroscopica — forma, opacità, texture dell'etichetta. Non servono 32 bit di precisione numerica per coglierla.

Comprimiamo i nostri modelli a INT8 (interi a 8 bit), il che riduce l'ingombro di memoria di 4 volte. Poi spingiamo oltre, fino a INT4 (interi a 4 bit) per gli strati ad alto numero di pesi, riducendolo di 8 volte. I nostri benchmark interni mostrano che INT4 offre un aumento delle prestazioni fino al 77% rispetto a INT8 su hardware FPGA compatibile, mantenendo un'accuratezza superiore al 99% del modello FP32 originale.

La chiave è il QAT. A differenza della rozza quantizzazione post-addestramento che si limita a troncare i pesi e a sperare per il meglio, il QAT simula il rumore di quantizzazione durante l'addestramento. La rete impara a essere robusta alla minor precisione. È la differenza tra chiedere a qualcuno di dipingere con un pennello grosso dopo che ha padroneggiato la pennellata fine, e insegnargli a dipingere magnificamente con un pennello grosso fin dall'inizio.

Con i modelli quantizzati, l'intera rete neurale sta nella Block RAM on-chip dell'FPGA. Nessun accesso a memoria esterna. Nessun collo di bottiglia della DRAM. I dati si muovono a terabyte al secondo all'interno del chip. Usiamo framework come FINN e hls4ml per mappare specifici strati della rete su specifiche risorse dell'FPGA, regolando il parallelismo di ogni strato in modo da corrispondere al throughput del sensore della telecamera, così che la pipeline non si blocchi mai.

Cosa significa davvero "zero sistema operativo"?

Eseguiamo il nostro percorso di inferenza critico su bare metal. Nessun Linux. Nessun Windows. Nessun sistema operativo di alcun tipo sulla parte del chip che pensa e agisce.

La gente mi chiede sempre se è estremo. Lo è. È anche necessario.

I chip FPGA che usiamo — AMD Xilinx Zynq UltraScale+ — sono sistemi eterogenei su un singolo pezzo di silicio. Contengono sia fabric logico programmabile sia core hard di processore ARM. Suddividiamo il carico di lavoro su tre domini:

Il fabric FPGA gestisce la pipeline di visione, l'inferenza della rete neurale e i segnali di controllo delle valvole. Pura logica hardware. Zero jitter. La Real-Time Processing Unit — un ARM Cortex-R5 che esegue C++ bare-metal — gestisce la configurazione, le macchine a stati e gli interblocchi di sicurezza con una latenza di interrupt rigorosamente limitata. E una separata Application Processing Unit che esegue Linux si occupa delle cose non critiche: registrare i dati, servire l'interfaccia web, gestire gli aggiornamenti remoti.

I percorsi del pensare e dell'agire sono completamente isolati dal percorso della rendicontazione. Se la partizione Linux va in crash — e Linux va in crash — l'FPGA continua a selezionare il materiale a piena velocità senza interruzioni. L'ho visto succedere durante i test. La dashboard si è oscurata, il flusso dei log si è fermato, e la linea di selezione non ha perso un colpo. È stato allora che ho capito che l'architettura era giusta.

Per l'analisi tecnica completa di questa architettura — la pipeline di dataflow, gli schemi di quantizzazione, il motore di sincronizzazione bare-metal — consulta il nostro dettagliato documento di ricerca.

Perché è importante per l'economia circolare?

Lasciate che traduca i millisecondi in denaro.

Un tipico MRF che lavora plastica PET con un'AI limitata dal cloud limita la velocità del nastro a circa 2 metri al secondo per accomodare la latenza e gli errori di tracciamento. Produttività: all'incirca 5 tonnellate all'ora per metro di larghezza del nastro. Con l'inferenza edge su FPGA a 2 ms di latenza, quella velocità del nastro può triplicare fino a 6 metri al secondo. Produttività: 15 tonnellate all'ora. Stesso nastro. Stesso edificio. Stesso ingombro.

Si tratta di un aumento del 300% della capacità di lavorazione. Per un impianto che opera su due turni — 16 ore — significa 160 tonnellate aggiuntive lavorate ogni giorno. Con il PET riciclato scambiato tra $400 e $800 a tonnellata, le implicazioni sui ricavi si misurano in milioni all'anno.

Ma la produttività è solo metà della storia. La precisione conta altrettanto. Un'espulsione precisa significa meno contaminanti che si intrufolano nelle balle pulite (maggiore purezza, prezzi premium) e meno materiali bersaglio accidentalmente mancati e mandati in discarica (maggiore resa, meno sprechi). Anche un miglioramento dell'1-2% nel tasso di recupero riduce significativamente i ricavi persi e abbassa le tariffe di conferimento in discarica, che stanno aumentando a livello globale.

Poi c'è il costo operativo. Nessun costo di egress dal cloud. Nessun addebito per API a inferenza. Nessun costo di banda per lo streaming di video ad alta definizione verso un data center. E gli FPGA consumano dai 10 ai 20 watt per il carico di lavoro di inferenza, contro i 100-200 watt di una configurazione GPU comparabile — un vantaggio di efficienza di 10 volte che si accumula su decine di stazioni di selezione che lavorano 24/7.

Il passaggio dal cloud all'FPGA edge non è una preferenza tecnica. È la differenza tra un impianto di riciclo che funziona sulla carta e uno che funziona a velocità reale.

Il fossato che conta

Mi arriva regolarmente una versione di questa domanda: "Non siete preoccupati per la commoditizzazione? Cosa succede quando NVIDIA lancerà una GPU edge più veloce?"

Ecco cosa sono arrivato a credere. In un'epoca in cui chiamare un'API per classificare una bottiglia in un JPEG statico è un progetto da weekend, il fossato non è il modello. È la fisica. È la capacità di identificare ed espellere quella bottiglia che si muove a 6 metri al secondo, in mezzo a un flusso caotico di lattine schiacciate e cartone bagnato, con il 99% di purezza, 24 ore al giorno, senza una connessione a internet.

Questo richiede una co-progettazione hardware-software — selezionare il silicio dell'FPGA, scrivere l'HDL, progettare schemi di quantizzazione su misura, integrare i driver dei sensori e agganciare l'inferenza di visione agli impulsi dell'encoder per una precisione di espulsione sub-millimetrica. Non è qualcosa che si ottiene avvolgendo un'API.

Il panorama attuale dell'AI è pieno di aziende che operano al livello applicativo, scollegate dalla realtà fisica delle operazioni industriali. Noi operiamo al livello fisico. Non addestriamo un modello e lo consegniamo. Progettiamo il circuito che il modello diventa.

Il settore del riciclo è a un punto di svolta. Gli standard di purezza si stanno inasprendo. I flussi di rifiuti post-consumo stanno diventando più complessi. La manodopera è scarsa. Tutti concordano che l'AI sia la risposta. Ma la conversazione si è bloccata su quale modello usare, quando la vera domanda è dove e quanto velocemente quel modello viene eseguito.

Un ritardo di 500 millisecondi non è un inconveniente tecnico da ottimizzare via. È un'impossibilità fisica per un processo che opera a 3-6 metri al secondo. L'equazione è semplice — spostamento uguale velocità per tempo — e non si cura dello SLA del tuo provider cloud.

Il futuro dell'economia circolare dipende da un'intelligenza che sia veloce, deterministica e collocata nel punto esatto in cui il getto d'aria incontra la bottiglia. Non in un data center. Non nel cloud. Sul chip, sull'edge, nel millisecondo che conta.