Pile open per AI: modelli grandi, TPU nativi e privacy on‑premise

Google e Meta hanno aperto TorchTPU il 21 ottobre alla PyTorch Conference North America 2026, promettendo un backend PyTorch nativo per le TPU di Google che si usa come un semplice model.to("tpu")³. Nello stesso arco temporale, arrivano due modelli open con contesti lunghi: Nanbeige4.3‑33B da 524.288 token per coding agentico¹ e Carbon‑X da 14,8 miliardi per il DNA, eseguibile su una singola GPU da 80 GB⁴. Intanto, una CLI come logwhisper mostra come analizzare log in locale con Llama 3.2 via Ollama, senza chiavi API né invio dati fuori macchina². Presi insieme, questi tasselli delineano una pila praticabile: modelli riutilizzabili, esecuzione in sede su GPU o TPU, strumenti locali per diagnosi veloci.

Modelli open con contesti lunghi: cosa cambia per i carichi specialistici

Nanbeige LLM Lab pubblica Nanbeige4.3‑33B su Hugging Face con licenza Apache 2.0. È un modello denso da 33 miliardi di parametri, con finestra di contesto da 524.288 token, presentato come “teacher” per coding agentico e cowork in stile ufficio¹. Accanto al modello principale c’è la variante Nanbeige4.3‑33B‑Base per post‑training personalizzato. L’iniziativa nasce all’interno della piattaforma di recruiting BOSS Zhipin¹.

Le specifiche operative puntano a server multi‑GPU. I pesi sono in BF16 e richiedono circa 66 GB di memoria. Le ricette indicano SGLang e vLLM con parallelismo tensoriale a quattro vie¹. Il team pubblica una tabella comparativa contro tre modelli aperti di taglia simile: Qwen3.8‑27B, Muse‑Glimmer‑30B e Gemma4‑31B. Nelle 20 righe elencate, Nanbeige4.3‑33B guida 17 volte. Il picco dichiarato è 80,9 su Terminal‑Bench 2.1, contro 73,0 di Qwen3.8‑27B nella stessa riga¹.

Carbon‑X di Hugging Face parte da Qwen3‑14B, resta decoder‑only, unifica DNA e testo in un unico flusso di token e risponde in inglese in chat. Ha 14,8 miliardi di parametri, finestra di 40.960 token e licenza Apache 2.0⁴. Il progetto nasce in Hugging Face Bio con Zhongguancun Academy e con TIGEM insieme all’Università degli Studi di Napoli Federico II. La fonte afferma che la licenza e la possibilità di eseguirlo su GPU di proprietà consentono ai laboratori di mantenere in sede sequenze sensibili. L’inferenza gira su una singola GPU da 80 GB in bfloat16, con vLLM o Transformers. Sono disponibili file GGUF ufficiali: Q8_0 da 15,8 GB e Q4_K_M da 9,6 GB⁴.

I due rilasci coprono due fronti concreti: agenti di coding con contesti da 512K token e compiti di biologia computazionale in cui i dati non possono uscire dal perimetro. In comune, pesi aperti sotto Apache 2.0 e percorsi di esecuzione in sede, su hardware controllato^1,4.

Esecuzione e compatibilità: GPU multi‑nodo e TPU come opzione nativa

Per usare Nanbeige4.3‑33B servono pianificazione di memoria e parallelismo. I pesi BF16 si attestano intorno a 66 GB. Le ricette citano SGLang e vLLM con parallelismo tensoriale a quattro vie su server multi‑GPU¹. Sono indicazioni pratiche, mirate alla messa in produzione.

Sul fronte acceleratori, TorchTPU punta sull’ergonomia del porting. Google e Meta presentano un backend PyTorch nativo per TPU che sostituisce PyTorch/XLA, il bridge del 2020 basato su lazy tensor che “richiedeva modifiche intrusive al codice”³. L’obiettivo dichiarato è il cambio di device: da model.to("cuda") a model.to("tpu"). “Con TorchTPU, le TPU si uniscono a GPU e CPU come opzione nativa per PyTorch”, scrive Google Cloud in un annuncio cofirmato da Bill Jia, vicepresidente dell’ingegneria per Core ML/AI³. Jia, insieme a Zongwei Zhou di Meta, presenta il keynote “Workload Fungibility in the Agentic Era: Bringing Native PyTorch to Cloud TPUs”. Poco prima, Mark Collier della PyTorch Foundation osserva che l’inferenza ha superato il training come principale carico nei data center, creando “un’incredibile fame di token”³.

Il quadro operativo è chiaro: parallelismo su GPU per modelli a contesto lungo e backend nativo su TPU per ridurre l’attrito del porting. L’attenzione si sposta su operatori supportati, scheduler e gestione della memoria.

Strumenti per inferenza e diagnostica locali: ridurre la fuga di dati

logwhisper mostra un uso minimo e utile di modelli open in locale. È una CLI in Go che legge righe di log di produzione e restituisce una prima diagnosi in inglese semplice: cosa è successo, la causa probabile, il prossimo controllo². Usa Ollama per eseguire Llama 3.2 sulla macchina dell’utente. Non richiede chiavi API. Le righe di log restano sul computer di chi esegue il comando².

Il flusso è diretto. Si può puntare a un file: logwhisper examples/production.log. Oppure leggere da uno stream: cat app.log | logwhisper -model llama3.2:3b. La selezione del modello passa dall’opzione -model. Gli esempi mostrano i tag llama3.2:3b e llama3.2:1b in esecuzione locale tramite Ollama. Il repository include un file di prova, examples/production.log, per riprodurre l’esperienza con un comando minimo². L’output organizza gli eventi con etichette esplicite. L’autore mostra elementi numerati come “Slow query” e durate in millisecondi. L’idea nasce da un turno di reperibilità: un incidente, un muro di log, serve un primo passaggio che estragga il senso utile².

Gli stessi principi si applicano a carichi più grandi. Se i modelli stanno su GPU interne o su TPU esposte come device nativo PyTorch, l’attrito nella gestione dei dati diminuisce. In cambio, serve più disciplina operativa: aggiornare pesi, validare risposte, monitorare consumo e derive.

Implicazioni per privacy e controllo operativo

I tre casi tracciano una direzione concreta. Nanbeige4.3‑33B porta contesti lunghi su un modello denso e fornisce istruzioni su memoria e parallelismo¹. Carbon‑X dà un’opzione per sequenze sensibili con pesi aperti, una singola GPU di riferimento e quantizzazioni ufficiali per scenari locali⁴. TorchTPU affronta la compatibilità, spesso il collo di bottiglia nei porting, con l’obiettivo di un semplice model.to("tpu") al posto del bridge PyTorch/XLA più intrusivo³. A valle, strumenti come logwhisper coprono un bisogno quotidiano: diagnosi in locale senza traffico esterno².

Per chi lavora con AI, software e QA, il punto operativo è trattare modelli e backend come dipendenze di produzione. Servono procedure per la gestione dei pesi, test mirati sui casi d’uso e controlli sull’accesso ai dati. Non è teoria: i dettagli su memoria, parallelismo e formati di distribuzione nelle fonti sono già pensati per chi deve far girare i sistemi^1,4.

Aree critiche e passaggi pratici per i team

• Verificare i requisiti di memoria e topologie. Per Nanbeige4.3‑33B, pianificare circa 66 GB per i pesi BF16 e valutare parallelismo tensoriale a quattro vie con SGLang o vLLM su server multi‑GPU¹.
• Per domini sensibili, considerare Carbon‑X su una GPU da 80 GB in bfloat16 con vLLM o Transformers. Valutare le quantizzazioni GGUF ufficiali Q8_0 da 15,8 GB e Q4_K_M da 9,6 GB per scenari locali vincolati⁴.
• Testare la codebase con TorchTPU in un ambiente di staging. L’obiettivo è il porting come model.to("tpu"), verificando il supporto degli operatori rispetto a PyTorch/XLA citato come più intrusivo³.
• Integrare logwhisper nel runbook di incident response. Usare modelli Llama 3.2 via Ollama senza chiavi API, mantenendo i log sullo stesso host².

Alla PyTorch Conference, la “fame di token” è stata messa nero su bianco. Se backend nativi e modelli open con contesti lunghi restano coerenti con i dati pubblicati, una quota maggiore di inferenza può restare in sede, con strumenti concreti già disponibili per chi deve costruire e mantenere servizi in produzione^3,1,4,2.