Black Forest Labs FLUX 3 Action sfida Nvidia con pesi aperti per robot

Black Forest Labs ha rilasciato FLUX 3 Action il 23 settembre, portando un modello open-weight da 7 miliardi di parametri direttamente nella corsa al controllo robotico per scopi generali. L’azienda afferma che il suo modello guida un importante benchmark di simulazione pur usando meno parametri della policy concorrente Cosmos 3 Nano di Nvidia.

Questo confronto conferisce rilievo al rilascio. Black Forest Labs FLUX 3 Action non è semplicemente un generatore di immagini adattato a un’altra demo. Prevede insieme video e azioni del robot, quindi trasforma osservazioni visive e istruzioni in linguaggio naturale in una sequenza di comandi fisici.

I risultati iniziali sembrano promettenti, ma restano più circoscritti di una svolta generale nella robotica. Il punteggio più alto proviene da attività simulate su tavolo, mentre un piccolo test su hardware esterno ha utilizzato soltanto 30 tentativi. I pesi aperti comportano inoltre condizioni di licenza, requisiti computazionali rilevanti e responsabilità di sicurezza esplicite per chiunque li impieghi.

Black Forest Labs FLUX 3 Action cambia la competizione nella robotica

Il cambiamento rilevante è che un importante sviluppatore di IA visiva ha rilasciato sia pesi robotici utilizzabili sia il codice necessario per adattarli.

FLUX 3 Action è un world action model, o WAM, che prevede futuri stati visivi e comandi robotici all’interno di un’unica architettura. Accetta frame della telecamera, lo stato corrente del robot e un’istruzione testuale. Produce quindi il successivo blocco di azioni insieme a frame video previsti.

Black Forest Labs ha rilasciato tre componenti principali. Il repository di base contiene il modello preaddestrato sulle azioni e gli encoder condivisi. Checkpoint DROID e SO-101 separati forniscono policy adattate a due configurazioni robotiche consolidate.

DROID è un ampio dataset per la manipolazione robotica costruito con dimostrazioni del mondo reale in numerosi ambienti. La policy DROID rilasciata è destinata a una configurazione di robot Franka con tre visuali della telecamera. La versione SO-101 è rivolta a un braccio robotico più piccolo ed economico, comunemente usato con il framework LeRobot di Hugging Face.

Il modello ha 7 miliardi di parametri. Secondo la documentazione del modello pubblicata, una chiamata di inferenza DROID restituisce 32 azioni che coprono circa due secondi di movimento.

Questo orizzonte d’azione è importante perché i controller robotici devono osservare, pianificare e agire ripetutamente. Una finestra di previsione utile più lunga può ridurre la frequenza con cui deve essere eseguito il modello completo. Tuttavia, blocchi d’azione più lunghi possono anche amplificare gli errori quando l’ambiente cambia dopo l’avvio di un piano.

Il rilascio include strumenti per fine-tuning completo, adattamento efficiente nei parametri, inferenza, conversione dei checkpoint e valutazione. Gli sviluppatori possono iniziare dal modello di base, adattarlo a un altro robot o eseguire una delle policy già predisposte.

Si tratta di qualcosa di più ampio della pubblicazione di una model card e di un video dimostrativo. Il repository di inferenza pubblico include preparazione dei dati, addestramento distribuito, gestione dei checkpoint, strumenti di esportazione ed esempi specifici per robot.

L’azienda ha sviluppato il rilascio con Nvidia e Hugging Face. Questa collaborazione rende più complessa la cornice competitiva. Nvidia ha contribuito a rendere possibile il modello e fornisce gran parte dello stack hardware, ma la sua policy Cosmos è anche il più importante rivale aperto nel benchmark.

FLUX 3 Action nasce dal più ampio programma FLUX 3. Black Forest Labs si è inizialmente costruita una reputazione attorno alla generazione di immagini. La sua architettura più recente estende quella base visiva alla previsione di video, audio e azioni.

Il collegamento non è superficiale. Un modello video deve stimare come gli oggetti si muovono, collidono, si deformano e reagiscono nel tempo. Una policy robotica necessita di informazioni correlate, ma deve anche selezionare comandi che producano il risultato desiderato.

Black Forest Labs scommette che questi due problemi appartengano a un unico modello condiviso. Questa scommessa dispone ora di pesi scaricabili, checkpoint funzionanti e risultati di benchmark che altri team possono verificare.

Un modello più piccolo ora guida RoboLab-120

La più forte affermazione iniziale di FLUX 3 Action è un tasso di successo del 42,92% su RoboLab-120, rispetto al 36,8% della più grande Cosmos3-Nano-Policy di Nvidia.

RoboLab-120 è un benchmark di simulazione che contiene 120 attività di manipolazione su tavolo. Ogni policy affronta sfide visive, procedurali e relazionali su vari livelli di difficoltà.

Gli esempi includono l’identificazione dell’oggetto corretto, la comprensione delle relazioni spaziali e il completamento di istruzioni in più fasi. Il benchmark viene eseguito in Nvidia Isaac Sim su una configurazione di robot Franka in stile DROID.

Il paper di RoboLab descrive un sistema per generare scene e attività realistiche senza vincolare il test a una sola architettura di modello. RoboLab-120 utilizza dieci prove per attività, creando un set di valutazione più ampio di una breve sequenza dimostrativa.

Black Forest Labs riferisce che il suo modello ottimizzato per DROID ha raggiunto il 42,92% di successo complessivo. OASIS WAM avrebbe ottenuto il 39,0%, mentre Cosmos3-Nano-Policy di Nvidia ha registrato il 36,8% con l’impostazione linguistica predefinita.

π0.5 di Physical Intelligence ha raggiunto il 28,0% nello stesso confronto. DreamZero ha ottenuto il 25,7%, mentre la più piccola Cosmos3-Edge-Policy di Nvidia ha raggiunto il 22,9%.

Questi dati rendono FLUX 3 Action l’attuale leader nel confronto pubblicato. Non significano che completi in modo affidabile la maggior parte delle attività. Un tasso di successo del 42,92% rappresenta comunque fallimenti in oltre metà dei tentativi valutati.

Anche il confronto sui parametri è degno di nota. FLUX 3 Action usa 7 miliardi di parametri, mentre Cosmos 3 Nano ne usa 16 miliardi. Questo offre a Black Forest Labs un modello più piccolo con un vantaggio di 6,12 punti percentuali nella classifica riportata.

Il numero di parametri non è una misura diretta di costo, latenza o intelligenza. Architettura, precisione, trasferimenti di memoria, passaggi di campionamento e overhead degli encoder incidono tutti sulle prestazioni effettive nel deployment.

Black Forest Labs offre inoltre diverse varianti di inferenza. La policy di base usa quattro passaggi di denoising con guidance. Un altro checkpoint rimuove la guidance esterna, mentre una versione distillata per passaggio produce risultati in un solo passaggio.

L’azienda riferisce un’inferenza più rapida rispetto a Cosmos 3 Nano nelle configurazioni hardware testate. Il vantaggio preciso varia in base al checkpoint, alla precisione numerica e alla GPU.

Queste ottimizzazioni affrontano un vincolo reale della robotica. Un modello che pianifica azioni impressionanti ma risponde troppo lentamente non può recuperare da movimenti, interferenze o errori percettivi.

Tuttavia, il benchmark principale richiede contesto. RoboLab valuta la manipolazione simulata, non il lavoro imprevedibile in presenza di persone. La simulazione può standardizzare i confronti, ma non può rappresentare ogni errore del sensore, guasto meccanico, collisione o cambiamento ambientale.

Il benchmark è inoltre emerso dallo stack di ricerca robotica di Nvidia. Ciò non invalida i risultati, ma rende la riproduzione indipendente particolarmente preziosa.

Una issue pubblica relativa a Cosmos aveva in precedenza segnalato difficoltà nel riprodurre alcuni risultati RoboLab pubblicati. Il report Cosmos di riferimento presenta punteggi a diversi livelli di specificità delle istruzioni, illustrando come gli esiti del benchmark dipendano dalla configurazione del test.

Per acquirenti e sviluppatori, l’interpretazione corretta è circoscritta ma significativa. FLUX 3 Action ha stabilito una posizione credibile nel benchmark usando un modello più piccolo. Team indipendenti devono ora determinare se questo vantaggio si mantiene con hardware, istruzioni e ambienti fisici differenti.

Perché la previsione congiunta di video e azioni è importante

Black Forest Labs tratta il controllo robotico come un problema di previsione visiva, con le azioni incorporate nella stessa scena in evoluzione.

I tradizionali modelli vision-language-action collegano direttamente input visivi e istruzioni linguistiche ai comandi del robot. Un world action model aggiunge una previsione esplicita di come dovrebbe cambiare il mondo osservato.

FLUX 3 Action esegue il denoising congiunto di token video e azione. Il denoising significa che il sistema parte da output candidati rumorosi e li raffina iterativamente fino a ottenere una previsione coerente.

Il modello utilizza un diffusion transformer con due flussi di output sincronizzati. Un flusso rappresenta i frame visivi futuri. L’altro rappresenta le azioni del robot associate a quei momenti.

Entrambi i flussi condividono lo stesso livello di rumore per ciascun campione di addestramento. Questo design incoraggia il modello a collegare un movimento comandato alla sua prevista conseguenza visiva.

Un autoencoder video congelato converte i frame in una rappresentazione compatta. Un encoder Qwen3-VL-4B congelato elabora l’istruzione testuale. Il modello d’azione addestrabile combina questi segnali con lo stato del robot.

Per la policy DROID, tre visuali della telecamera vengono disposte in un’unica tela visiva. Il sistema riceve anche le posizioni delle giunture e lo stato della pinza. Restituisce 32 comandi, ciascuno contenente sette obiettivi per le giunture e un valore per la pinza.

Questo differisce dalla generazione di un video e dalla richiesta a un controller separato di imitarlo. Le sequenze video e azione emergono dallo stesso passaggio del modello e restano allineate temporalmente.

Il meccanismo offre a Black Forest Labs un percorso plausibile dai media generativi all’IA fisica. L’addestramento video espone un modello a movimento, contatto, permanenza degli oggetti e rapporti di causa-effetto. I dati robotici gli insegnano poi come macchine specifiche possano influenzare quelle scene.

La precedente collaborazione FLUX-mimic dell’azienda aveva offerto un’anticipazione. Quel sistema collegava la base visiva di FLUX 3 alle competenze robotiche di mimic, incluso il lavoro sulla manipolazione industriale.

FLUX 3 Action estende l’idea a pesi pubblici e strumenti di adattamento riutilizzabili. Negli esperimenti dell’azienda copre anche qualcosa di più dei bracci industriali.

Black Forest Labs riferisce di aver addestrato versioni per due videogiochi e un drone indoor. La policy per videogiochi utilizzava un unico insieme di pesi in ambienti di guida separati, con una didascalia testuale che identificava il gioco attivo.

Per l’esperimento con il drone, il modello ha ricevuto una visuale da telecamera di bordo da 256 per 256 e ha generato quattro valori di controllo. Il suo set di addestramento conteneva 800 voli scriptati creati in Isaac Sim.

L’azienda afferma che il drone ha navigato stanze riorganizzate e seguito istruzioni parafrasate che non coincidevano esattamente con le frasi di addestramento. Questi risultati sono dimostrazioni dello sviluppatore, non una valutazione indipendente standardizzata.

Ciononostante, illustrano l’affermazione architetturale. Un modello condiviso può rappresentare comandi per un braccio robotico, un drone o un veicolo virtuale quando ogni incarnazione riceve input e teste di output adeguati.

Questo non rende il modello universalmente intercambiabile. Ogni macchina ha telecamere, dimensioni delle azioni, unità, tempi e limiti di sicurezza diversi. L’adattamento richiede comunque dati che rappresentino il corpo e l’attività di destinazione.

Il vantaggio principale è una base visiva riutilizzabile. Gli sviluppatori potrebbero non dover addestrare da zero la comprensione delle scene per ogni nuova macchina. Possono concentrare maggiormente lo sforzo di addestramento sulle osservazioni e sui controlli del robot.

Questo approccio ricorda la strategia dei foundation model che ha trasformato il software linguistico e d’immagine. La robotica presenta un test più difficile perché output errati possono danneggiare l’hardware o ferire le persone.

Il video previsto dal modello offre un altro possibile vantaggio. Gli ingegneri possono ispezionare ciò che il modello si aspetta accada, non soltanto il comando numerico che invia. Questa previsione visiva può supportare il debugging, anche se non costituisce una garanzia formale di sicurezza.

I pesi aperti non significano robotica senza restrizioni

FLUX 3 Action è ispezionabile e adattabile, ma la sua licenza, le esigenze hardware e le misure di protezione per il deployment limitano ciò che “aperto” significa nella pratica.

Black Forest Labs definisce il rilascio open weights anziché completamente open source. I parametri del modello sono disponibili e il relativo codice di inferenza e addestramento è pubblico. I pesi utilizzano la FLUX Kommunity License, mentre alcune parti del repository software adottano una licenza open-source convenzionale.

La licenza del modello consente l'uso non commerciale e alcuni utilizzi commerciali da parte di utenti idonei. Organizzazioni più grandi o deployment al di fuori di tali condizioni potrebbero dover stipulare un accordo separato.

Questa distinzione conta per i team di robotica che valutano il rischio di dipendenza nel lungo periodo. Un laboratorio di ricerca può sperimentare con i pesi, mentre un produttore commerciale deve verificare se l'uso previsto rientra nei requisiti.

I requisiti di risorse del modello rappresentano un altro limite. Il checkpoint DROID utilizza circa 32 GB di memoria GPU in bfloat16 su una Nvidia H200, secondo le indicazioni hardware pubblicate.

La quantizzazione FP8 e l'offloading del text encoder consentono di eseguire il sistema su una scheda da 24 GB. La quantizzazione riduce la precisione numerica per risparmiare memoria e migliorare la velocità, mentre l'offloading sposta una parte del modello lontano dalla GPU principale.

Questo requisito è accessibile rispetto ad alcuni modelli di frontiera, ma non corrisponde a un'inferenza edge leggera. Un robot in produzione potrebbe comunque necessitare di un server GPU vicino, di un costoso computer di bordo o di un percorso di comunicazione progettato con cura.

La latenza è solo una delle preoccupazioni operative. La policy produce posizioni target dei giunti, ma non impone limiti di velocità dei giunti, forza, collisione o spazio di lavoro.

La model card invita esplicitamente chi esegue il deployment ad aggiungere tali controlli a livello applicativo. Raccomanda la validazione in simulatore, limiti di sicurezza attivi sul robot, supervisione umana e un arresto hardware facilmente accessibile.

Questi avvertimenti evidenziano la differenza tra una policy appresa e un sistema completo di controllo robotico. Un deployment in fabbrica richiede anche monitoraggio dello stato, comportamenti di emergenza, rilevamento dei guasti, controllo degli accessi, procedure di manutenzione e confini di responsabilità.

I chunk di azioni introducono un'ulteriore questione di controllo. FLUX 3 Action può restituire 32 comandi in un'unica previsione. Un controller deve decidere quanti eseguirne prima di osservare l'ambiente e pianificare di nuovo.

L'esecuzione dell'intera sequenza può migliorare l'efficienza quando il mondo si comporta come previsto. Ripianificare prima può aiutare quando gli oggetti si muovono, una presa scivola o una persona entra nello spazio di lavoro.

L'esempio SO-101 riflette questo compromesso. Il suo ciclo di controllo esegue 32 azioni da una sequenza prevista più lunga, scarta le restanti e pianifica nuovamente.

Gli sviluppatori devono inoltre preservare l'ordine delle telecamere, la normalizzazione, le unità dei giunti, la temporizzazione e le convenzioni di stato associate a ciascun checkpoint. Mescolare questi dettagli può produrre output dall'aspetto plausibile ma errati.

Ecco perché i pesi scaricabili non eliminano l'ingegneria robotica. Spostano parte del lavoro dall'apprendimento di una policy verso integrazione, verifica e applicazione della sicurezza.

Per gli acquirenti aziendali, la domanda più utile non è se il modello sia aperto. È se il sistema completo resti verificabile, manutenibile e sicuro nelle effettive condizioni operative dell'organizzazione.

Il confronto con Nvidia è reale ma incompleto

FLUX 3 Action esercita pressione sulla strategia dei modelli di Nvidia, ma il rilascio dipende anche in larga misura dai benchmark, dagli strumenti di simulazione e dalla piattaforma di calcolo di Nvidia.

Il confronto competitivo più chiaro è tra FLUX 3 Action e Cosmos3-Nano-Policy. Entrambi prevedono stati visivi e azioni futuri, entrambi offrono pesi accessibili ed entrambi puntano alla manipolazione robotica generale.

Black Forest Labs riporta prestazioni RoboLab migliori con meno parametri. Afferma inoltre una velocità di inferenza superiore su diverse GPU testate.

Questa combinazione è importante perché gli sviluppatori di robot affrontano spesso un vincolo a tre tra capacità, tempo di risposta e memoria. Un modello più piccolo che migliori il successo nei compiti potrebbe ridurre le esigenze infrastrutturali senza accettare comportamenti più deboli.

Tuttavia, la sola dimensione del modello non dimostra l'efficienza del deployment. FLUX 3 Action include un autoencoder visivo congelato e un text encoder. Il profilo completo di memoria e latenza dipende da come vengono eseguiti questi componenti.

Anche la scelta del checkpoint modifica il confronto. L'inferenza in quattro passaggi può preservare la qualità richiedendo però più calcolo. Un checkpoint a passaggio singolo è più veloce, ma potrebbe sacrificare parte del successo.

Nvidia resta centrale per il rilascio. RoboLab gira in Isaac Sim, i test di inferenza riportati usano GPU Nvidia e il modello è stato sviluppato con il supporto di Nvidia.

Black Forest Labs è inoltre membro della più ampia collaborazione di Nvidia sui modelli aperti. Il rapporto assomiglia più alla competizione all'interno di una piattaforma condivisa che a un semplice sfidante che attacca un operatore consolidato.

Hugging Face svolge un altro ruolo importante. Il suo framework LeRobot raccoglie dataset robotici, policy e integrazioni hardware affinché i ricercatori possano riprodurre i flussi di lavoro in modo più coerente.

Il checkpoint SO-101 di FLUX 3 Action arriva con informazioni salvate su preprocessing e normalizzazione. Ciò riduce una comune fonte di errore nello spostamento di una policy tra un repository e un braccio fisico.

Il panorama competitivo più ampio include i modelli π di Physical Intelligence, Nvidia GR00T, DreamZero, OpenVLA, OASIS e altri sistemi vision-language-action. Ciascuno compie scelte diverse in materia di dati di addestramento, architettura del modello, apertura e hardware supportato.

Alcuni si concentrano sulla previsione diretta delle azioni. Altri aggiungono componenti di world modeling o pianificazione. Diversi pubblicano i pesi ma mantengono restrizioni sull'uso commerciale o sui dati di addestramento.

La posizione distintiva di FLUX 3 Action combina preaddestramento su video generativi, previsione congiunta di frame futuri, azioni robotiche e strumenti pubblici di adattamento. Il suo primato nei benchmark rafforza questa proposta, ma non risolve il dibattito architetturale.

Una policy di azione diretta può essere più piccola e semplice perché non prevede video. Un world action model impiega calcolo per rappresentare possibili scene future, il che può migliorare il ragionamento fisico ma anche aumentare la latenza.

Le prove decisive arriveranno da confronti controllati con gli stessi dati, hardware, vincoli di sicurezza e compiti nel mondo reale. Le classifiche pubbliche raramente catturano l'intero sistema.

Il rilascio modifica comunque le aspettative. I team di robotica possono ora chiedersi perché un modello più grande o chiuso ottenga risultati peggiori di un'alternativa disponibile da 7 miliardi di parametri su un benchmark pertinente.

I concorrenti devono rispondere con risultati più forti, deployment più rapido, supporto per embodiment più ampio, licenze più chiare o prove provenienti da installazioni reali. Questa pressione è più rilevante della sola posizione in classifica.

Cosa dovrebbero osservare sviluppatori e acquirenti

I prossimi tre segnali sono la riproduzione indipendente, test più ampi su robot reali e un adattamento duraturo su nuove macchine.

Il primo segnale è la riproduzione del risultato RoboLab-120. Team indipendenti dovrebbero eseguire il checkpoint rilasciato con versioni fissate, prompt documentati e impostazioni di valutazione identiche.

Un punteggio riprodotto vicino al 42,92 percento rafforzerebbe l'affermazione secondo cui FLUX 3 Action possiede un autentico vantaggio nei benchmark. Grandi deviazioni indicherebbero sensibilità alla configurazione, alle versioni del software o a dettagli non pubblicati.

La riproduzione dovrebbe includere più di un checkpoint. Le varianti base, guidance-distilled, step-distilled, bfloat16 e FP8 offrono compromessi diversi tra velocità, uso della memoria e successo nei compiti.

I report più utili pubblicheranno dettagli hardware completi e distribuzioni degli insuccessi. Un tasso di successo complessivo può nascondere debolezze nelle procedure complesse, nelle relazioni spaziali o nelle istruzioni vaghe.

Il secondo segnale è una valutazione più ampia su robot reali. Un test di terze parti citato nella copertura ha coinvolto dieci compiti DROID, tre tentativi ciascuno e un braccio Franka.

Secondo quanto riportato, FLUX 3 Action ha completato 28 tentativi su 30. Cosmos 3 Nano ne ha completati 27, DreamZero 20 e π0.5 13.

Questi risultati offrono incoraggianti prove esterne, ma 30 prove restano troppo poche per trarre conclusioni sul deployment. Un ulteriore fallimento modificherebbe materialmente la percentuale.

I test futuri dovrebbero includere centinaia di prove, oggetti sconosciuti, variazioni dell'illuminazione, disturbi alle telecamere, superfici di lavoro spostate e interruzioni umane. Dovrebbero inoltre documentare interventi e movimenti non sicuri, non solo il completamento finale dei compiti.

Il successo in simulazione diventa più persuasivo quando una policy conserva il proprio vantaggio in siti fisici e su hardware mantenuto da team diversi. Se il vantaggio scompare, il modello potrebbe beneficiare dell'allineamento con il benchmark.

Il terzo segnale è l'adattamento a embodiment realmente nuovi. Black Forest Labs fornisce un modello base, supporto al fine-tuning completo e un flusso di lavoro SO-101 efficiente in termini di parametri.

Gli sviluppatori dovrebbero osservare quanti dati e quanta capacità di calcolo specifici per il compito richieda un nuovo robot. Un modello fondazionale utile dovrebbe ridurre il carico di adattamento, non semplicemente trasferirlo altrove.

Le prove più forti arriverebbero da team esterni che adattano il modello a bracci diversi, manipolatori mobili, droni o strumenti industriali. Tali progetti dovrebbero confrontare tempi di addestramento, volume dei dati, affidabilità e latenza di controllo con policy consolidate.

Le licenze modelleranno questa adozione. I ricercatori possono esplorare il modello già ora, ma gli utenti commerciali devono stabilire se i termini FLUX Kommunity siano adatti alla loro organizzazione e al loro deployment.

Anche l'economia dell'hardware sarà rilevante. Un percorso di inferenza da 24 GB amplia l'accesso, ma un funzionamento affidabile in produzione include capacità di riserva, monitoraggio, hardware di controllo e sistemi di sicurezza.

Gli sviluppatori impegnati in queste valutazioni necessitano di registri disciplinati di prompt, checkpoint, layout delle telecamere, dataset e fallimenti. Una base di conoscenza ingegneristica ricercabile può aiutare i team a preservare questo contesto tra gli esperimenti.

FLUX 3 Action di Black Forest Labs ha attirato attenzione collegando un chiaro meccanismo tecnico a pesi pubblici e risultati misurabili. Non ha dimostrato un'intelligenza robotica general-purpose e il suo attuale punteggio di benchmark lascia ampio spazio agli insuccessi.

L'opportunità immediata è la sperimentazione pratica. I team possono ispezionare il codice, eseguire osservazioni registrate senza un robot e valutare il checkpoint in simulazione prima di avvicinarsi all'hardware fisico.

La domanda più difficile arriva dopo. Gli sviluppatori possono riprodurre il vantaggio, trasferirlo a macchine sconosciute e mantenere un comportamento sicuro quando l'ambiente smette di corrispondere al benchmark?

Quei risultati determineranno se FLUX 3 Action diventerà una base robotica ampiamente utilizzata o resterà un punto di riferimento impressionante. Per ora, il suo contributo più importante consiste nel fornire al settore un modello concreto e ispezionabile da testare.