Agenti AI locali, pod modulari e storage diretto GPU: come cambia l'architettura operativa

NVIDIA ha messo un numero sul problema: 3,21x. La CPU Vera, integrata in BlueField‑4 STX, ha superato una CPU x86 in un test di compressione a due stadi tipico dei servizi di storage. Segnale operativo: se lo storage non regge cifratura, compressione, verifica e ricostruzione sotto carico, il calcolo si strozza anche con GPU veloci.

1) La linea calda dello storage quando le GPU fanno I/O diretto

Il contesto è cambiato. Le finestre di contesto e i dataset superano la memoria di sistema. Le GPU non aspettano più la CPU: avviano richieste di I/O direttamente, in massa. Possono generare migliaia di operazioni concorrenti verso lo storage. In questo scenario, i servizi dati stanno sulla linea calda. Devono proteggere e ridurre i dati senza rallentare addestramento e inferenza. Se la coda cresce, il throughput cala. NVIDIA porta questa tesi al Future of Memory and Storage e nel suo blog tecnico: l’architettura di storage diventa moltiplicatore o freno del calcolo accelerato.

Il benchmark di compressione a due stadi punta a questo punto. Vera, parte di BlueField‑4 STX, raggiunge fino a 3,21x il throughput di una CPU x86 in un compito tipico dei servizi di storage. È un test che misura la capacità di sostenere pipeline di trasformazione e riduzione dati sotto richieste concorrenti avviate dalle GPU.

2) Agenti locali veloci su CPU e GPU: il caso LFM2.5‑2.6B

LFM2.5‑2.6B nasce con un obiettivo esplicito: “deploy local agents everywhere”. Gli autori parlano di agenti rapidi, caricabili su macchine con risorse limitate, anche su CPU. I numeri dichiarati sono concreti: su Apple M5 Max il modello genera 220 token al secondo; su una CPU AMD Ryzen tocca 113 token al secondo. In inferenza resta sotto i 2,5 GB di memoria.

La traccia dell’addestramento è altrettanto esplicita. Pre‑training su circa 34 trilioni di token. A metà, una fase di “mid‑training” estende la finestra di contesto a 128.000 token. Poi il post‑training trasforma il base model in un agente. La sequenza del post‑training segue quattro stadi: due round di Supervised Fine‑Tuning con forte peso a dati agentici (uso di strumenti, ricerca web, traiettorie da harness); “teacher specialization” con un teacher specialista per dominio, tra cui matematica, codice e tool use; “Multi‑domain On‑Policy Distillation” per distillare gli specialisti in uno studente unico; chiusura con “Agentic Rei”.

Gli autori definiscono le prestazioni “competitive con modelli quattro volte più grandi” su tre assi: uso di strumenti, seguire istruzioni e task multi‑step. Il messaggio resta operativo: agenti rapidi, eseguibili in locale, pensati per ambienti con risorse limitate.

3) Modelli e pesi: le promesse e i prezzi dichiarati da Qwen

Qwen presenta due modelli e promette di rilasciare i pesi: Qwen 3.8 Max da 2,4T e un 27B. Offre l’accesso via API a 2 dollari per milione di token in input e 6 dollari in output. La fonte inserisce l’annuncio in un contesto preciso: dopo un “Qwen Exodus” e un cambio di gestione con più API chiuse, c’erano dubbi su nuovi rilasci rilevanti in open weights; “Il dubbio è finito”, scrive AINews, che definisce Qwen 3.8 Max come un modello 2,4T che sarebbe stato il primo tra gli open, se non fosse per l’uscita di Kimi K3 già trattata dalla stessa testata.

Qwen elenca capacità chiave e risultati dichiarati. Primo, coding autonomo su orizzonti lunghi. La nota parla di oltre dieci giorni di esecuzione non presidiata, con la costruzione da zero di un “coding harness” auto‑evolutivo durante un run autonomo di più settimane. Secondo, ricerca AI autonoma. Il team riferisce di aver ricostruito da zero la pipeline di un paper (“Unified Data Selection for LLM Reasoning”) e di aver fatto girare in autonomia un ciclo di ricerca iterativo per 125 ore.

I due canali di accesso sono espliciti: open weights promessi e API a listino. I prezzi per input e output compaiono nella comunicazione. La fonte sottolinea anche la narrativa “Qwen is so back!” come apertura e collega l’annuncio ai dubbi precedenti.

4) Pod di inferenza trasportabili: l’offerta di Runware

Runware presenta Sonic Inference Pod come un’unità singola, trasportabile, progettata per l’inference di modelli di intelligenza artificiale e pensata per affiancare i campus degli hyperscaler, non per sostituirli. L’azienda afferma due promesse commerciali: qualità di inference più alta e costo più basso rispetto alle piattaforme serverless e ai cloud GPU. Il formato compatto mira a ridurre il time‑to‑capacity: si sposta dove serve, si installa in tempi brevi e si replica per aggiungere capacità, senza ampliare un sito fisso.

“Crediamo che il compute distribuito, posizionato più vicino agli utenti finali per inferenze più veloci, sia ciò che vincerà nel lungo periodo”, afferma il cofondatore e CEO Flaviu Radulescu. Il progetto sposta il calcolo verso l’edge per tagliare la latenza e seguire la crescita del traffico di inference. La modularità è il metodo di crescita: aggiungere capacità significa mettere in campo nuovi pod identici. Non serve riprogettare un data center esistente. Runware sostiene che questo schema semplifichi la pianificazione.

5) Incidenti agentici: proposta SAFE in consultazione pubblica

Linux Foundation pubblica una richiesta di commenti su SAFE (Shared AI Findings Exchange), una bozza di linee guida per trasformare incidenti e “near miss” legati ad agenti di AI in misure di difesa riutilizzabili da più attori. L’annuncio coincide con l’apertura di Black Hat a Las Vegas. Il lavoro si svolge nell’Open Secure AI Alliance, oggi con oltre 120 organizzazioni. Alla bozza contribuiscono membri dell’alleanza insieme a Linux Foundation. Tra i partecipanti compaiono NVIDIA, Cisco, CrowdStrike, Hugging Face e Red Hat.

SAFE propone quattro azioni:

• raccogliere e analizzare in modo confidenziale incidenti e quasi‑incidenti legati all’AI;
• informare i soggetti impattati;
• individuare fallimenti ricorrenti dei controlli;
• pubblicare raccomandazioni operative supportate da prove per ridurre il rischio sistemico.

La bozza esplicita il contesto: la sicurezza corre dietro a superfici d’attacco in rapida evoluzione. I difensori “devono muoversi ora alla velocità degl…”.

6) Un filo operativo tra calcolo, distribuzione e sicurezza

Dalle fonti emergono tre elementi, dichiarati dagli attori coinvolti. Primo: le GPU avviano richieste di I/O direttamente e in massa, e lo storage deve sostenere pipeline di cifratura, compressione, verifica e ricostruzione senza creare code che rallentano il throughput. Secondo: esecuzione locale e modelli compatti puntano a “local agents everywhere”, con numeri di velocità e memoria dichiarati per dispositivi di largo consumo. Terzo: la distribuzione dell’inferenza in pod trasportabili e la condivisione strutturata degli incidenti agentici vengono proposte come risposte pratiche, rispettivamente per ridurre latenza e per trasformare evidenze in raccomandazioni operative.

Queste mosse, benchmark e tesi sullo storage, percorsi di addestramento e prestazioni dichiarate per agenti locali, promesse di pesi e API, pod modulari, consultazione SAFE, si presentano come scelte esplicite, con numeri e obiettivi operativi indicati nelle comunicazioni citate. Le implicazioni sono oggetto di confronto pubblico nelle sedi tecniche richiamate dalle fonti.