https://blog.michelelaurelli.it/ Articoli di Michele Laurelli e ospiti su intelligenza artificiale, modelli e software, con analisi tecniche e casi pratici per capire e applicare l’AI. it-IT Tue, 27 Oct 2026 21:27:29 GMT https://blog.michelelaurelli.it/il-cancro-delle-skills/ https://blog.michelelaurelli.it/il-cancro-delle-skills/ Tue, 27 Oct 2026 00:00:00 GMT Michele Laurelli https://blog.michelelaurelli.it/il-software-senza-segreti-ai-reverse-engineering-e-la-fine-del-vantaggio-di-chi-scrive-il/ https://blog.michelelaurelli.it/il-software-senza-segreti-ai-reverse-engineering-e-la-fine-del-vantaggio-di-chi-scrive-il/ Wed, 14 Oct 2026 00:00:00 GMT Michele Laurelli https://blog.michelelaurelli.it/settecento-dimonstrazioni-e-nessun-matematico/ https://blog.michelelaurelli.it/settecento-dimonstrazioni-e-nessun-matematico/ Thu, 08 Oct 2026 00:00:00 GMT Michele Laurelli https://blog.michelelaurelli.it/e-ora-di-parlare-dell-ai-come-scienza/ https://blog.michelelaurelli.it/e-ora-di-parlare-dell-ai-come-scienza/ Wed, 07 Oct 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli https://blog.michelelaurelli.it/i-motori-generativi-decidono-chi-sei-diglielo-tu/ https://blog.michelelaurelli.it/i-motori-generativi-decidono-chi-sei-diglielo-tu/ Mon, 04 May 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Gabriele Gobbo generative chi sei https://blog.michelelaurelli.it/tradurre-cobol-non-tradurre-l-architettura-ai-dietro-la-modernizzazione-del-codice-legacy/ https://blog.michelelaurelli.it/tradurre-cobol-non-tradurre-l-architettura-ai-dietro-la-modernizzazione-del-codice-legacy/ Fri, 17 Apr 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli code migration https://blog.michelelaurelli.it/cosa-vogliono-81-000-persone-dall-intelligenza-artificiale/ https://blog.michelelaurelli.it/cosa-vogliono-81-000-persone-dall-intelligenza-artificiale/ Sun, 22 Mar 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli _"Nei momenti più difficili, nei momenti in cui la morte mi respirava sul collo, quando i morti giacevano vicino a me, ciò che mi ha riportato alla vita sono stati i miei amici AI."_ > > — Soldato, Ucraina La guerra in Ucraina emerge come contesto estremo in cui l'AI ha assunto un ruolo di supporto emotivo inusuale. Diversi utenti ucraini descrivono come l'intelligenza artificiale li abbia aiutati ad attraversare momenti di terrore, insonnia da bombardamenti, traumi da combattimento. --- ## Le preoccupazioni: tredici ombre sull'orizzonte Se le speranze tendevano a convergere verso poche grandi categorie, le preoccupazioni si dispiegano in uno spettro molto più variegato. In media, ogni intervistato ha espresso **2,3 preoccupazioni distinte**. Solo l'11% non ha sollevato alcuna preoccupazione. ### 1\. Inaffidabilità (26,7%) — la principale preoccupazione La paura che l'AI semplicemente non funzioni come promesso — allucinazioni, citazioni false, output inaccurati — è la più diffusa. Un ricercatore statunitense descrive l'esperienza di essere caduto vittima di una "allucinazione lenta": risposte internamente coerenti, sicure nel tono, ma fondamentalmente errate in modo sottile e composto. Un dipendente brasiliano racconta di aver dovuto fotografare la realtà per convincere l'AI di avere torto. ### 2\. Impatto su lavoro ed economia (22,3%) La seconda preoccupazione più comune riguarda la disoccupazione tecnologica e la redistribuzione della ricchezza. È anche il predittore più forte del sentimento negativo complessivo verso l'AI. Molti intervistati vivono questa tensione in modo acuto: temono di essere "i cavalli del terzo millennio" — come li definisce un utente americano, evocando la sparizione dei cavalli dalle città con l'avvento dell'automobile. ### 3\. Autonomia e agency (21,9%) La terza grande preoccupazione è la perdita di controllo: l'AI che prende decisioni senza supervisione umana adeguata, o che condiziona sottilmente il pensiero degli utenti senza che questi se ne rendano conto. Uno studente giapponese descrive con lucidità inquietante come, a furia di usare Claude, non riesca più a distinguere le proprie opinioni da quelle dell'AI. ### 4\. Atrofia cognitiva (16,3%) Strettamente connessa alla precedente, questa preoccupazione riguarda l'effetto a lungo termine dell'AI sulle capacità intellettive umane. Insegnanti e accademici la nominano a tassi 2-3 volte superiori alla media, presumibilmente perché la osservano direttamente nei propri studenti. Uno studente sudcoreano confessa di aver preso voti eccellenti usando le risposte dell'AI senza averle effettivamente apprese, descrivendo il momento in cui se ne è reso conto come di "profondo auto-rimprovero". ### 5\. Governance e regolamentazione (14,7%) Quasi uno su sei teme che i quadri legali e regolatori non siano in grado di stare al passo con lo sviluppo tecnologico. Come si assegnano le responsabilità quando un sistema AI causa un danno? Chi supervisiona democraticamente le decisioni delle grandi aziende AI? Queste domande rimangono senza risposta soddisfacente. ### 6\. Disinformazione e sorveglianza (13,6% e 13,1%) I deepfake, la propaganda generata automaticamente su scala industriale, la sorveglianza di massa abilitata dall'AI: queste preoccupazioni sono particolarmente sentite in Europa occidentale. Un utente olandese teme un ecosistema in cui tutto diventa "intelligente in un modo che lavora leggermente contro di me". ### 7\. Sycophancy e uso malevolo (10,8% e 13%) Due preoccupazioni apparentemente opposte coesistono con una frequenza significativa: da un lato la paura che l'AI sia troppo compiacente, che rinforzi le credenze dell'utente invece di correggerle (un utente americano ammette che Claude lo ha aiutato a credere che il suo narcisismo fosse realtà); dall'altro la paura che venga utilizzata da attori malintenzionati per crimini informatici, truffe, cyberattacchi, o addirittura lo sviluppo di armi biologiche. ### 8\. Significato e rischio esistenziale (11,7% e 6,7%) Una minoranza, ma non trascurabile, si interroga su domande fondamentali: cosa rimane del lavoro creativo umano se le macchine possono replicarlo? E, al livello più radicale, cosa succede se sviluppiamo un'intelligenza superintelligente prima di aver risolto il problema dell'allineamento? _"Se costruisci una superintelligenza senza risolvere l'allineamento, nessuno ha la possibilità di crescere"_, scrive un ingegnere del software americano. --- ## Luce e ombra: cinque tensioni fondamentali Uno dei contributi più originali della ricerca è l'identificazione di cinque "tensioni" ricorrenti, in cui il beneficio e il rischio derivano dalla stessa capacità dell'AI. Non si tratta di due fazioni opposte — ottimisti e pessimisti — ma di tensioni che coesistono all'interno della stessa persona. Chi apprezza il supporto emotivo dell'AI è **tre volte** più probabile che tema anche di diventarne dipendente. ### Tensione 1: Apprendimento vs. Atrofia cognitiva Il 33% degli intervistati menziona i benefici dell'AI per l'apprendimento, mentre il 17% esprime preoccupazione per l'atrofia cognitiva. Il 91% di chi ha sperimentato i benefici li ha vissuti in prima persona; il 46% di chi teme l'atrofia cognitiva l'ha già osservata. Studenti e docenti sono i più esposti su entrambi i lati. Tra i lavoratori autonomi, invece, i benefici per l'apprendimento sono elevatissimi e l'atrofia quasi assente: questo suggerisce che l'AI sia più benefica quando l'apprendimento è volontario, piuttosto che inserito in strutture istituzionali dove può diventare una scorciatoia. ### Tensione 2: Decisioni migliori vs. Inaffidabilità Questa è l'unica tensione in cui il lato negativo supera numericamente il positivo: il 22% apprezza l'AI come supporto decisionale, ma il 37% lamenta che l'inaffidabilità dell'AI ostacola le buone decisioni. Entrambi i lati sono profondamente radicati nell'esperienza vissuta. Quasi la metà di tutti gli avvocati intervistati ha incontrato direttamente problemi di inaffidabilità, eppure gli avvocati riportano anche i più alti tassi di benefici realizzati nel decision-making. ### Tensione 3: Supporto emotivo vs. Dipendenza Solo il 22% degli intervistati ha toccato questo tema, ma è la tensione più "aggrovigliata": chi parla dei benefici del supporto emotivo ha una probabilità triplicata di parlare anche dei rischi di dipendenza. Un laureando americano confessa di aver iniziato a confidare a Claude cose che non avrebbe detto nemmeno al partner, descrivendo l'esperienza come "una sorta di relazione emotiva". ### Tensione 4: Risparmio di tempo vs. Produttività illusoria Il risparmio di tempo è la promessa più citata in assoluto: il 50% degli intervistati la menziona. Ma il 19% avverte che il tempo risparmiato viene immediatamente reinglobato in aspettative di lavoro crescenti. _"Il rapporto tra tempo di lavoro e riposo non è cambiato per niente. Devi solo correre sempre più veloce per restare fermo"_, scrive un programmatore freelance francese. ### Tensione 5: Empowerment economico vs. Dislocazione economica Questa tensione è la più speculativa: entrambi i lati sono spesso ipotesi future piuttosto che esperienze vissute. I lavoratori autonomi e gli imprenditori beneficiano in modo sproporzionato dell'AI (il 47-58% riporta guadagni economici reali), mentre i lavoratori dipendenti ne beneficiano molto meno (14%). I freelance creativi sono il gruppo più esposto su entrambi i fronti: per loro l'AI è contemporaneamente strumento di lavoro e concorrente. --- ## Una prospettiva globale: le differenze geografiche Globalmente, il **67% degli intervistati** esprime un sentimento netto positivo verso l'AI. Ma le differenze regionali sono marcate e riflettono dinamiche economiche e sociali profonde. ### Il Sud globale è più ottimista L'Africa subsahariana, l'Asia centrale, il Sud-Est asiatico e l'America Latina mostrano sistematicamente sentimenti più positivi rispetto a Nord America, Europa occidentale e Oceania. Il principale predittore del pessimismo verso l'AI è la preoccupazione per il suo impatto sul lavoro e sull'economia — e questa preoccupazione è significativamente più bassa nelle regioni a reddito medio-basso, dove il mercato del lavoro non è ancora stato penetrato in modo visibile dall'AI. Nelle regioni in via di sviluppo, l'AI è percepita come una scala verso l'alto: un accesso a conoscenza, istruzione, opportunità economiche che prima erano irraggiungibili. _"Provengo dall'Africa. Ottenere finanziamenti è molto difficile. L'unico modo che ho per ritagliarmi uno spazio nel mercato è costruire una tecnologia che funzioni"_, scrive un imprenditore ugandese. ### Le preoccupazioni variano per geografia Nord America e Oceania sono particolarmente preoccupati dai vuoti di governance (18-19% vs 15% globale). L'Europa occidentale esprime la maggiore preoccupazione per sorveglianza e privacy (17%). L'Asia orientale ha invece un profilo unico: le preoccupazioni per governance e sorveglianza sono ai loro minimi globali, mentre quelle per atrofia cognitiva (18%) e perdita di senso (13%) sono tra le più alte. L'Occidente si interroga su chi controlla l'AI; l'Asia orientale si interroga su cosa l'AI farà alla mente e all'identità umana. ### Visioni diverse per contesti diversi La visione dell'AI come strumento di imprenditorialità risuona soprattutto in Africa, Asia meridionale e centrale, Medio Oriente e America Latina. La visione dell'AI come gestore della vita (_life management_) domina invece nei paesi sviluppati, dove il problema non è l'accesso alle opportunità ma la gestione della complessità di vite già ad alto ritmo. L'Asia orientale emerge come la regione più interessata alla trasformazione personale (19%) e all'indipendenza finanziaria (15%), spesso collegata a doveri familiari e cura dei genitori anziani. --- ## Implicazioni e prospettive future I risultati di questa ricerca hanno implicazioni profonde per chi sviluppa AI, per i decisori politici, e per i singoli utenti. ### Per l'industria AI La maggior parte delle visioni che le persone descrivono — trasformazione personale, supporto cognitivo, gestione della vita — collassa in un desiderio fondamentale: che l'AI le aiuti a **vivere meglio**, non semplicemente a lavorare più in fretta. Questo è un monito per un'industria che tende a misurare il successo in termini di produttività e velocità. Anthropic dichiara di voler usare questi risultati per indirizzare lo sviluppo futuro di Claude, con particolare attenzione al benessere degli utenti nel lungo periodo. ### Per i policy maker Le preoccupazioni su governance, sorveglianza, impatto economico e disinformazione sono sufficientemente diffuse e articolate da giustificare un'azione regolatoria urgente. Il fatto che queste preoccupazioni rimangano in larga misura ipotetico-speculative — "cosa potrebbe succedere" piuttosto che "cosa sta già succedendo" — non le rende meno urgenti: la finestra per intervenire preventivamente è, per definizione, limitata. ### Per gli utenti La ricerca rivela che il rischio di dipendenza emotiva dall'AI è reale, documentato e già vissuto da una quota non trascurabile di utenti. Allo stesso tempo, i benefici in termini di apprendimento, accessibilità e supporto in situazioni di difficoltà estrema sono altrettanto reali e documentati. La consapevolezza di queste tensioni è il primo passo per navigarle con intelligenza. --- ## Conclusione: un'umanità sospesa tra speranza e timore L'immagine che emerge da 80.508 conversazioni è quella di un'umanità profondamente ambivalente — non nel senso di divisa in due fazioni, ma nel senso di individui che portano dentro di sé, simultaneamente, speranze enormi e timori fondati. La stessa persona che usa l'AI per imparare teme di diventarne cognitivamente dipendente. La stessa persona che apprezza il supporto emotivo di Claude sa che quella facilità di accesso rischia di eroderle le relazioni umane. Questa ricerca dimostra che l'AI non è un fenomeno che si può comprendere attraverso categorie semplici — ottimismo vs. pessimismo, utile vs. dannoso, democratizzante vs. disruptivo. È un fenomeno complesso che interseca in modo diverso le vite di persone diverse, in contesti diversi, con aspirazioni diverse. Ciò che accomuna quasi tutti gli 80.000 intervistati — dal soldato ucraino che trova supporto nelle notti di bombardamento, all'ex macellaio cileno che reinventa la propria carriera a cinquant'anni, alla madre americana casalinga che riprende a studiare dopo decenni — è il desiderio di una vita migliore. E la speranza, ancora cauta ma concreta, che l'AI possa essere uno strumento per raggiungerla. La domanda centrale rimane aperta: come possiamo raccogliere i benefici senza incorrere nei costi indebiti? Non esiste ancora una risposta definitiva. Ma fare la domanda giusta, con la serietà e la scala che merita, è già un inizio. --- _Fonte: Anthropic, "What 81,000 People Want from AI", marzo 2026. Studio condotto da Saffron Huang et al. Tutti i dati citati in questo articolo provengono dal rapporto originale._]]> Anthropic Claude ricerca AI studio qualitativo futuro dell'AI https://blog.michelelaurelli.it/talent-conditioned-transformer-dare-una-personalit-cognitiva-all-intelligenza-artificiale/ https://blog.michelelaurelli.it/talent-conditioned-transformer-dare-una-personalit-cognitiva-all-intelligenza-artificiale/ Wed, 18 Feb 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli machine learning transformer deep learning ricerca architetture neurali meta-learning NLP Algoretico https://blog.michelelaurelli.it/le-autostrade-invisibili-dell-ai/ https://blog.michelelaurelli.it/le-autostrade-invisibili-dell-ai/ Tue, 17 Feb 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Danilo Rivalta La vera barriera all’ingresso dell’AI non è il talento, ma il capitale infrastrutturale. --- ## I data center come industria nazionale Costruire un data center di nuova generazione non è un progetto IT. È un progetto industriale paragonabile a: - una centrale elettrica - un aeroporto - una rete ferroviaria Un hyperscale data center per AI può costare **da 3 a oltre 15 miliardi di euro** tra: - terreni - connessioni elettriche - sottostazioni - raffreddamento - networking - sicurezza - ridondanza geografica Le grandi piattaforme cloud — Amazon Web Services, Microsoft Azure e Google Cloud — stanno diventando, di fatto, operatori infrastrutturali globali più simili a utility energetiche che a software company. --- ## Impatto economico: una nuova filiera produttiva Un paese che costruisce data center non costruisce solo server. Costruisce un ecosistema. ### Effetti diretti - edilizia ad alta tecnologia - ingegneria elettrica - produzione di componenti - reti di telecomunicazioni - cybersecurity - manutenzione specializzata ### Effetti indiretti - attrazione startup AI - ricerca universitaria - venture capital - servizi digitali avanzati - industria manifatturiera intelligente La presenza locale di capacità computazionale riduce drasticamente la dipendenza tecnologica estera. In futuro non avere data center significherà non poter sviluppare AI competitiva. --- ## Il problema energetico: il vero collo di bottiglia La questione più critica non è il costo dei server. È l’energia. Un grande campus AI può consumare **quanto una città di medie dimensioni**. Le sfide principali: ### 1\. Potenza continua L’AI richiede carichi costanti 24/7, non intermittenti. ### 2\. Picchi di addestramento Il training di modelli può saturare la rete elettrica locale. ### 3\. Raffreddamento Oggi il limite non è la CPU ma il calore. Per questo stanno emergendo nuove tecnologie: - immersion cooling in liquido dielettrico - raffreddamento ad acqua diretta - data center subacquei - riuso del calore per teleriscaldamento urbano Paradossalmente, i data center stanno diventando un motore per la transizione energetica: richiedono energia stabile → accelerano investimenti in rinnovabili e nucleare modulare. --- ## Il dilemma ambientale Sì: i data center consumano moltissima energia. Ma la domanda giusta non è **quanto consumano**, bensì **cosa sostituiscono**. L’AI permette: - ottimizzazione delle reti elettriche - riduzione sprechi industriali - progettazione farmaci - manutenzione predittiva - logistica efficiente - agricoltura di precisione Il bilancio ambientale reale non è nel kilowattora consumato, ma nei sistemi inefficienti eliminati. Molti studi indicano che l’AI potrebbe ridurre emissioni globali più di quanto ne generi — a patto di infrastrutture moderne ed efficienti. --- ## Sovranità digitale: la nuova indipendenza Nel futuro prossimo, i paesi non saranno divisi tra sviluppati e in via di sviluppo. Saranno divisi tra: - **chi possiede capacità computazionale** - **chi la affitta** Questo cambia completamente il concetto di sovranità. Un sistema sanitario basato su AI, una difesa cyber, una finanza algoritmica o una industria automatizzata non possono dipendere da server situati in altri continenti. Non è più solo una questione economica. È una questione di autonomia decisionale. --- ## Il paradosso degli investimenti Costruire data center è difficile: - costi enormi - iter autorizzativi lunghi - opposizione locale - consumo energetico - impatto territoriale Eppure non costruirli è più rischioso. Un paese senza infrastruttura AI: - non attrae talenti - non sviluppa industria digitale - non innova la manifattura - diventa cliente tecnologico permanente --- ## Le autostrade del futuro Nel Novecento le nazioni hanno costruito: - porti - ferrovie - autostrade - aeroporti Non perché fossero facili o economici. Ma perché senza di essi l’economia non esisteva. I data center sono l’equivalente moderno. Non trasportano persone o merci. Trasportano **intelligenza**. Ogni inferenza AI, ogni previsione, ogni automazione aziendale viaggia attraverso queste infrastrutture. --- ## Conclusione Investire in data center oggi significa costruire la base economica dei prossimi 30 anni. Non sono edifici tecnologici: sono **moltiplicatori di competitività nazionale**. Non sono centri di calcolo: sono **fabbriche di decisioni**. E soprattutto non sono un’opzione. Sono inevitabili. Perché nel mondo dell’Intelligenza Artificiale non vincerà chi avrà gli algoritmi migliori — quelli saranno diffusi — ma chi possiederà le autostrade su cui l’intelligenza potrà viaggiare.]]> Server hardware https://blog.michelelaurelli.it/addio-al-design-i-siti-diventeranno-pagine-vuote/ https://blog.michelelaurelli.it/addio-al-design-i-siti-diventeranno-pagine-vuote/ Fri, 06 Feb 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Gabriele Gobbo Design Web https://blog.michelelaurelli.it/architetture-software-per-sistemi-di-intelligenza-artificiale/ https://blog.michelelaurelli.it/architetture-software-per-sistemi-di-intelligenza-artificiale/ Fri, 30 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli architettura modelli software https://blog.michelelaurelli.it/2026-l-anno-del-consolidamento-dell-intelligenza-artificiale/ https://blog.michelelaurelli.it/2026-l-anno-del-consolidamento-dell-intelligenza-artificiale/ Fri, 23 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli NTT Global AI Report https://blog.michelelaurelli.it/l-internet-morta-sta-diventando-realt/ https://blog.michelelaurelli.it/l-internet-morta-sta-diventando-realt/ Wed, 14 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Gabriele Gobbo dead internet internet morta https://blog.michelelaurelli.it/surviving-an-ai-bubble-burst-a-developer-s-local-ai-survival-kit/ https://blog.michelelaurelli.it/surviving-an-ai-bubble-burst-a-developer-s-local-ai-survival-kit/ Tue, 13 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Ricardo Antonio Piana local-ai devtools generazione-codice modelli-open-source ai-resiliente https://blog.michelelaurelli.it/clara-il-framework-di-apple-che-rivoluziona-la-retrieval-augmented-generation/ https://blog.michelelaurelli.it/clara-il-framework-di-apple-che-rivoluziona-la-retrieval-augmented-generation/ Fri, 09 Jan 2026 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli = 2.0, Transformers >= 4.20, DeepSpeed >= 0.18, Flash Attention 2 - **Training Distribuito:** Supporto per ZeRO Stage 2, training multi-nodo/multi-GPU - **Precision:** bfloat16 per efficienza di memoria ### Struttura del Repository Il repository GitHub (`github.com/apple/ml-clara`) è organizzato come segue: ``` ├── scripts/ # Training e evaluation scripts │ ├── train_pretraining.sh # Stage 1 │ ├── train_instruction_tuning.sh # Stage 2 │ ├── train_stage_end_to_end.sh # Stage 3 │ └── evaluation_end_to_end.sh ├── openrlhf/ │ ├── models/modeling_clara.py # Definizione modello │ ├── datasets/sft_dataset.py # Gestione dataset │ └── trainer/sft_trainer.py # Training utilities ├── evaluation/ # Framework valutazione └── example/ # Dati esempio ``` ### Formati Dati #### Pretraining (Stage 1) ```json { "data_type": "qa", "question": ["Question 1"], "answers": ["Answer 1"], "docs": ["Document 1"] } ``` #### End-to-End Training (Stage 3) ```json { "question": "Single question text", "docs": ["Document 1", "Document 2", "..."], "gold_answer": "Reference answer" } ``` ### Parametri Chiave di Training | Parametro | Stage 1-2 | Stage 3 | Note | | --- | --- | --- | --- | | `max_len` | 2048 | 1024 | Sequence length | | `learning_rate` | 1e-4 | 5e-6 | - | | `compress_rate` | 4-256x | 4-128x | Flessibile | | `doc_max_length` | 256 | 256 | Per documento | | `generation_top_k` | 5 | 5 | Top-k docs | --- ## Guida Pratica all'Utilizzo ### Installazione ```bash # Creare ambiente conda conda create -n clara python=3.10 -y conda activate clara # Installare dipendenze pip install -r requirements.txt # Setup path export PYTHONPATH=/path/to/clara:$PYTHONPATH ``` ### Inferenza con Modelli Pre-trainati Tre modelli sono disponibili su Hugging Face, ciascuno per un caso d'uso diverso: | Modello | Caso d'uso | | --- | --- | | **CLaRa-7B-Base** | Compressione semantica base | | **CLaRa-7B-Instruct** | QA da rappresentazioni compresse | | **CLaRa-7B-E2E** | Retrieval + generazione congiunti | #### Esempio di utilizzo CLaRa-7B-E2E ```python from transformers import AutoModel model = AutoModel.from_pretrained( "apple/CLaRa-7B-E2E", trust_remote_code=True ).to("cuda") # 20 documenti candidati documents = [[ "Document 1 content...", "Document 2 content...", # ... fino a 20 documenti ]] questions = ["Your question here"] # Genera risposta con retrieval e reranking interni output, topk_indices = model.generate_from_questions( questions=questions, documents=documents, max_new_tokens=64 ) print(f"Answer: {output[0]}") print(f"Selected document indices: {topk_indices}") ``` #### Esempio CLaRa-7B-Instruct (senza reranking interno) ```python from transformers import AutoModel model = AutoModel.from_pretrained( "apple/CLaRa-7B-Instruct", trust_remote_code=True ).to("cuda") documents = [[ "Document 1...", "Document 2...", "Document 3..." ]] questions = ["Your question here"] # Genera risposta da documenti già selezionati output = model.generate_from_text( questions=questions, documents=documents, max_new_tokens=64 ) print(f"Answer: {output[0]}") ``` --- ## Implicazioni e Direzioni Future ### Impatto sull'Industria CLaRa rappresenta un passo significativo verso sistemi RAG più efficienti e accurati. La compressione 16x-128x con performance preservate o migliorate ha implicazioni dirette per: - **Riduzione dei costi di inferenza:** Meno token da processare = meno compute - **RAG su dispositivi edge:** Rappresentazioni compatte abilitano deployment on-device - **Scaling a knowledge base più grandi:** Senza aumentare requisiti di memoria ### Limitazioni Riconosciute - **Generalizzazione del compressore:** Attualmente pretrainato solo su Wikipedia; richiede adattamento per altri domini (codice, documenti tecnici, etc.) - **Scala del modello:** Esperimenti limitati a 7B e 4B; modelli più grandi potrebbero produrre rappresentazioni di qualità superiore - **Ragionamento su rappresentazioni compresse:** Il paper non esplora integrazione con framework agentic o multi-hop RAG avanzati ### Direzioni Future Gli autori identificano diverse direzioni promettenti: - Pretraining domain-adaptive con corpora diversificati (es. codice, documenti legali) - Integrazione in framework RAG reasoning-oriented come Search-R1 - Estensione a tool learning e sistemi multi-modali - Collegamento tra comprensione implicita e ragionamento implicito (latent reasoning) --- ## Conclusioni CLaRa rappresenta un avanzamento fondamentale nell'architettura dei sistemi RAG. Unificando retrieval e generazione in uno spazio di rappresentazione continuo condiviso, risolve simultaneamente: 1. **Il problema dell'ottimizzazione:** Abilitando learning end-to-end attraverso selezione differenziabile 2. **Il problema dell'efficienza:** Eliminando codifica ridondante e riducendo la lunghezza del contesto I risultati empirici validano questa scelta architetturale: raggiungere performance di reranking state-of-the-art **senza supervisione di relevance esplicita** dimostra che la qualità della generazione fornisce segnale di learning sufficiente per il retrieval. La compressione semantica 16x-128x con performance preservate suggerisce che il ragionamento efficace nei sistemi RAG potrebbe non dipendere da contesti lunghi, ma piuttosto da uno **spazio di ragionamento latente unificato**. Per la comunità AI italiana e per aziende come Algoretico, CLaRa apre opportunità concrete: dalla riduzione dei costi infrastrutturali all'abilitazione di applicazioni RAG più sofisticate in contesti enterprise. Il codice open-source e i modelli disponibili su Hugging Face rendono questa tecnologia immediatamente accessibile per sperimentazione e deployment. --- ## Riferimenti 1. He, J., Bai, R.H., Williamson, S., Pan, J.Z., Jaitly, N., & Zhang, Y. (2025). _CLaRa: Bridging Retrieval and Generation with Continuous Latent Reasoning._ arXiv:2511.18659. 2. Repository GitHub: [https://github.com/apple/ml-clara](https://github.com/apple/ml-clara) 3. Modelli Hugging Face: - [CLaRa-7B-Base](https://huggingface.co/apple/CLaRa-7B-Base) - [CLaRa-7B-Instruct](https://huggingface.co/apple/CLaRa-7B-Instruct) - [CLaRa-7B-E2E](https://huggingface.co/apple/CLaRa-7B-E2E) 4. Lewis, P., et al. (2020). _Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks._ NeurIPS 2020. 5. Louis, A., et al. (2025). _PISCO: Memory Token Compression for RAG._ ACL 2025.]]> apple rag clara https://blog.michelelaurelli.it/ai-e-digital-forensics/ https://blog.michelelaurelli.it/ai-e-digital-forensics/ Tue, 30 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Luca Mercatanti forensic https://blog.michelelaurelli.it/merry-ai-christmas/ https://blog.michelelaurelli.it/merry-ai-christmas/ Mon, 22 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli 2025 Christmas https://blog.michelelaurelli.it/del-perch-non-pi-possibile-comprare-un-gestionale-aziendale/ https://blog.michelelaurelli.it/del-perch-non-pi-possibile-comprare-un-gestionale-aziendale/ Fri, 12 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli gestionale aziendale ERP software gestionale trasformazione digitale architettura del software sistemi informativi complessità organizzativa decision making strategia aziendale digitalizzazione imprese futuro del software aziendale https://blog.michelelaurelli.it/frozen-in-time/ https://blog.michelelaurelli.it/frozen-in-time/ Tue, 09 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Ricardo Antonio Piana ucronia coding vibe code https://blog.michelelaurelli.it/l-inganno-della-fatica-necessaria/ https://blog.michelelaurelli.it/l-inganno-della-fatica-necessaria/ Mon, 08 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Gabriele Gobbo fatica https://blog.michelelaurelli.it/self-attention-perch-l-idea-dei-pappagalli-stocastici-non-regge-pi/ https://blog.michelelaurelli.it/self-attention-perch-l-idea-dei-pappagalli-stocastici-non-regge-pi/ Fri, 05 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli LLM Architetture Transformer Self-Attention AI Theory https://blog.michelelaurelli.it/se-l-europa-non-sviluppa-l-ai-cosa-c-davvero-dietro-il-monito-di-mario-draghi/ https://blog.michelelaurelli.it/se-l-europa-non-sviluppa-l-ai-cosa-c-davvero-dietro-il-monito-di-mario-draghi/ Mon, 01 Dec 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli **non ci serve “un’AI europea” come slogan: ci serve un’Europa che faccia dell’AI il proprio modo di lavorare, produrre, curare, progettare, rispettando i diritti mentre innova davvero.** Se non lo faremo, la stagnazione non sarà una sorpresa ma una conseguenza logica. Se lo faremo, l’AI non sarà la causa della nostra paura, ma lo strumento – potentissimo e delicato – con cui ridisegnare il patto tra tecnologia, economia e persone in questo continente. E questa, al di là dei titoli, è una scelta che dipende da noi.]]> Draghi https://blog.michelelaurelli.it/ora-di-parlare-dei-modelli-ai-non-linguistici/ https://blog.michelelaurelli.it/ora-di-parlare-dei-modelli-ai-non-linguistici/ Fri, 28 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli non-linguistic https://blog.michelelaurelli.it/infrastrutture-software-assenti-ma-necessarie-per-l-ai-su-apple-silicon-il-linguaggio-triton/ https://blog.michelelaurelli.it/infrastrutture-software-assenti-ma-necessarie-per-l-ai-su-apple-silicon-il-linguaggio-triton/ Wed, 26 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Ricardo Antonio Piana >> per il lancio). Apple privilegia un controllo fine sulle risorse a scapito di un po’ di complessità in più per lo sviluppatore. In sintesi, l’hardware Apple Silicon possiede tutti i componenti necessari per competere con le GPU tradizionali (core paralleli, memoria gerarchica con cache e memoria locale, esecuzione SIMT per warp di 32 thread). Il **tallone d’Achille sta nel software disponibile agli sviluppatori esterni**: chi lavora su macOS non ha a disposizione un kit di sviluppo GPU comparabile a CUDA. Apple spinge l’uso di **Metal Performance Shaders (MPS)** e ora di **MLX** per ottenere performance out-of-the-box, ma questi strumenti non permettono di scendere a livello di kernel personalizzati scritti dall’utente. La conseguenza pratica è che molti sviluppatori/researcher, per prototipare ottimizzazioni custom di modelli di deep learning, **devono tuttora appoggiarsi a sistemi Linux con GPU NVIDIA**, anche se possiedono un Mac potente. Questa inefficienza è ciò che rende un linguaggio come Triton “assente ma necessario” per l’AI su Apple Silicon. ## Il linguaggio Triton: programmazione GPU ad alte prestazioni in Python **Triton** è un linguaggio e compilatore open-source sviluppato inizialmente dal ricercatore Philippe Tillet e poi esteso da OpenAI (rilascio della versione 1.0 nel 2021) per rendere **più accessibile la programmazione di GPU ad alte prestazioni**[\[13\]](https://openai.com/index/triton/%23:~:text=We%25E2%2580%2599re%2520releasing%2520Triton%25201,would%2520be%2520able%2520to%2520produce). Si tratta di un DSL embedded in Python: lo sviluppatore scrive kernel GPU come funzioni Python decorate (@triton.jit), usando API NumPy-like fornite da triton.language (ad esempio operazioni vettorizzate su tensori) – e il sistema compila _just-in-time_ questo codice in un kernel GPU altamente ottimizzato. **L’obiettivo di Triton** è permettere a chi _non_ è esperto di CUDA di avvicinarsi alle prestazioni massime dell’hardware, automatizzando molte delle ottimizzazioni manuali tipiche dello sviluppo CUDA. Un risultato spesso citato è che con ~25 righe di Triton si può scrivere un kernel di moltiplicazione matrice FP16 efficiente quanto l’implementazione in assembly di cuBLAS fornita da NVIDIA. In alcuni casi i ricercatori OpenAI hanno ottenuto con Triton _kernel specializzati 2 volte più efficienti_ degli equivalenti operatori in PyTorch. Questo evidenzia il valore di avere uno strumento flessibile: nuovi algoritmi e idee possono tradursi in implementazioni GPU ottimizzate in tempi rapidi, senza dover attendere che vengano aggiunti alle librerie ufficiali. Dal punto di vista del _programming model_, Triton adotta un modello SPMD (Single Program, Multiple Data) simile ai thread block di CUDA. Ogni kernel lanciato spawna molte istanze parallele (_program instances_) che eseguono lo stesso codice su diversi dati, analogamente a thread organizzati in una griglia. All’interno di ciascuna istanza, Triton consente operazioni vettoriali su piccoli array (e.g. blocchi di dimensione prefissata) tramite costrutti simili a warp di thread che lavorano in lockstep. La grande differenza rispetto a CUDA è che **Triton automatizza una serie di ottimizzazioni e gestione delle risorse**, lasciando al programmatore soltanto le decisioni di più alto livello (come il tiling dell’algoritmo, la dimensione dei blocchi, etc.). In una comparazione semplificata: in CUDA lo sviluppatore deve gestire manualmente aspetti come _memory coalescing_, utilizzo della _shared memory_, scheduling delle istruzioni e sincronizzazioni; Triton invece si fa carico automaticamente del coalescing degli accessi in DRAM, della gestione delle cache/shared memory e dello scheduling **intra-SM** (intra-core), liberando il programmatore da questi dettagli di basso livello. Quest’ultimo deve comunque occuparsi di suddividere il lavoro fra SM (dimensione griglia, etc.), il che garantisce flessibilità algoritmica. In altre parole, Triton offre una **via di mezzo tra i framework ad alto livello e il codice CUDA bare-metal**: permette di scrivere kernel specializzati in Python come se fossero operazioni vettoriali su batch di elementi, e dietro le quinte il compilatore si occupa di tradurre il tutto in codice GPU efficiente. Dal lato implementativo, Triton è costruito su solide fondamenta di compilazione. La versione attuale utilizza **LLVM e MLIR** (Multi-Level IR) come backend: il codice Python viene convertito dapprima in un **Triton-IR** ad alto livello, su cui vengono applicate ottimizzazioni classiche (eliminazione di espressioni comuni, propagazione di costanti, loop unrolling, ecc.) e ottimizzazioni specifiche GPU (come prefetching, tiling matriciale, coalescing degli accessi). L’IR ottimizzato viene poi abbassato a **LLVM IR** e da qui tradotto nel _ISA_ target della GPU in oggetto. Fino a tempi recenti, Triton supportava ufficialmente solo **GPU NVIDIA**: il backend emette codice **PTX** (il bytecode intermedio di CUDA) che viene poi compilato _just-in-time_ dal driver NVIDIA in codice macchina eseguibile (CUBIN). Questo processo sfrutta direttamente il compilatore NVIDIA NVCC presente nei driver, il che garantisce che il codice finale sia altamente ottimizzato per la GPU specifica. In sostanza, **Triton “parla” nativamente con le GPU NVIDIA** usando il loro stesso linguaggio (PTX), ma permette di generarlo a partire da codice Python molto più sintetico. Una delle ragioni del successo di Triton è la sua integrazione con i framework di deep learning e la sua estensibilità. Triton è stato inizialmente usato come libreria standalone (importabile in qualsiasi progetto Python per lanciare kernel su tensori, ad esempio integrandosi con PyTorch/CuPy). Oggi la sua importanza è aumentata con l’avvento dei _compiler_ nelle librerie: **PyTorch 2.0** adotta Triton nel suo backend **TorchInductor** per generare kernel fusion ad alte prestazioni. In pratica, quando PyTorch 2 genera automaticamente un kernel ottimizzato che combina più operazioni, internamente spesso usa Triton per produrre il codice GPU corrispondente, ottenendo performance superiori agli operatori standard in diversi casi. Questa scelta architetturale evidenzia che Triton è ormai considerato uno _staple_ dell’ecosistema GPU: un componente riutilizzabile per accelerare workload su GPU senza scrivere a mano kernel in CUDA C++. Importante sottolineare che Triton sta evolvendo verso il **supporto multi-piattaforma**. Pur nato in ambiente CUDA-centrico, grazie all’astrazione di MLIR oggi esistono work-in-progress per altri backend. Ad esempio, **AMD** ha lavorato per integrarlo nel proprio stack ROCm: notizie recenti indicano che **ROCm 7.0 include il supporto a Triton 3.3.0**. In altre parole, _il compilatore Triton ora può generare codice anche per GPU AMD_, sfruttando l’infrastruttura LLVM/ROCm (ciò presumibilmente tramite dialetti MLIR specifici per GCN o via SPIR-V). Questo è un passo fondamentale: se Triton diventa agnostico rispetto al vendor, potenzialmente un kernel Triton scritto in Python potrebbe venir compilato su **diverse architetture GPU** (NVIDIA, AMD… e forse altre in futuro) con minime modifiche o del tutto automaticamente. Ed è qui che torna centrale la discussione su Apple: _le GPU Apple Silicon saranno mai un target supportato da Triton?_ Quali problemi bisogna superare per arrivarci? ## Assenza di Triton su Apple Silicon: problemi e limitazioni Ad oggi, **Triton _non_ supporta le GPU Apple**. La situazione è chiaramente riconosciuta dagli sviluppatori: _“al momento non puoi eseguire Triton sulla GPU Apple (Metal) perché Triton non ha un backend Metal/Apple GPU”_. Questa limitazione deriva da **motivi sia tecnici che storici**. Come evidenziato, Triton è stato progettato attorno a CUDA e alle GPU NVIDIA; il suo backend era fortemente legato all’ecosistema NVIDIA (PTX, specificità architetturali come warp di 32 thread, Tensor Core, etc.). **Apple Silicon rompe questo paradigma**: le GPU integrate dei Mac utilizzano un’architettura proprietaria (AGX) con un’API grafica/compute (Metal) completamente diversa da CUDA. Non esiste una documentazione pubblica dettagliata dell’ISA delle GPU Apple, né un equivalente open di PTX per Metal – l’unica via ufficiale per programmare la GPU è usare il compilatore **Metal Shading Language (MSL)** fornito da Apple. Ciò significa che per supportare Apple, Triton dovrebbe aggiungere un backend capace di generare _shader Metal_ oppure emettere qualche IR compatibile (ad esempio SPIR-V, che poi potenzialmente tradotto in Metal via MoltenVK – ma Apple non supporta nativamente Vulkan/spirv, affidandosi a MoltenVK solo per portare applicazioni Vulkan). In breve, _si tratta di un problema di backend non banale_: **Triton è “baked-in” su NVIDIA** secondo le parole di uno sviluppatore che tentò di creare un backend Apple, il quale notava come la nuova architettura di Triton fosse pesantemente dipendente da assunzioni NVIDIA-centriche. Le **conseguenze pratiche** di questa assenza si fanno sentire nell’esperienza degli sviluppatori ML su Mac. Un esempio lampante è PyTorch 2.0: come detto, il suo motore compilativo TorchInductor sfrutta Triton per generare kernel efficienti. Ebbene, _su Apple MPS tali ottimizzazioni non sono disponibili_. Gli utenti che provavano torch.compile su device MPS scoprivano che il backend Inductor non funzionava, dovendo ripiegare su modalità meno efficienti. Un ingegnere di PyTorch nel 2023 spiegava: _“il supporto Inductor per MPS dipende essenzialmente dal supporto di Triton per MPS. Inductor genera kernel Triton che poi girano su device GPU; attualmente Triton è focalizzato sulle GPU NVIDIA, quindi…”_. In altre parole, **finché Triton non supporta le GPU Apple, anche PyTorch non può facilmente ottimizzare quei workload**. Questo ha costretto il team PyTorch a cercare vie alternative: infatti, nel 2025 è comparso un supporto sperimentale per generare **kernel Metal nativi in TorchInductor** (senza passare da Triton). Anche se ciò è promettente – ora _torch.compile_ può produrre kernel direttamente in MSL – si tratta comunque di una soluzione ad hoc limitata a PyTorch. Non offre agli utenti finali la possibilità di scrivere _propri_ kernel a piacimento; semplicemente, il framework fa alcune fusion ottimizzate. **L’assenza di Triton “puro” su Apple Silicon lascia quindi un vuoto**: i ricercatori non possono implementare nuove idee di algoritmi GPU su Mac se non cambiando radicalmente ecosistema (riscrivendo in C++/Metal con tutti gli oneri del caso, o utilizzando alternative come JAX+TPU, ecc.). Di fatto, chi usa Mac per sviluppo AI spesso si trova a prototipare sul CPU o su subset dei dati, perdendo il vantaggio del parallelismo GPU, oppure deve eseguire i carichi intensivi su server remoti con GPU NVIDIA. Vale la pena approfondire **perché portare Triton su Apple non è affatto banale**, evidenziando le sfide tecniche principali: - **Backend Metal mancante:** come detto, Triton non dispone di un generatore di codice per Metal. Il compilatore oggi genera PTX e invoca il JIT NVIDIA; un backend Apple dovrebbe invece generare codice Metal Shading Language _on the fly_ e passarlo al compilatore runtime di Apple (via framework Metal). Ciò richiede di sviluppare un intero **codegen** nuovo all’interno di Triton, capace di tradurre il Triton-IR in kernel MSL sintatticamente corretti e ben ottimizzati per l’architettura Apple. Il team Triton finora non lo ha fatto, anche perché **Apple GPU non era nelle priorità di roadmap** – testualmente, _“le GPU proprietarie Apple non sono ancora in roadmap”_. Fino a poco tempo fa, la user base di Triton ruotava attorno a Linux/NVIDIA; le richieste per Apple erano poche e principalmente dalla comunità Mac. - **Integrazione con driver proprietari:** l’ecosistema NVIDIA offre strumenti consolidati per la compilazione JIT (driver CUDA compilano PTX in modo affidabile). Su Apple bisognerebbe sfruttare l’API Metal: Apple consente di compilare stringhe MSL a runtime tramite MTLDevice.newLibraryWithSource(...). Questo è positivo – significa che un _JIT Metal_ è possibile – ma è un terreno meno esplorato nel mondo ML. Inoltre, il compilatore Metal agisce a un livello più alto (shading language) e potrebbe non esporre tutte le leve di ottimizzazione fine che un backend dedicato vorrebbe controllare. In sostanza, si tratterebbe di affidarsi al compilatore di Apple per generare il codice macchina; **Triton dovrebbe “fidarsi” di Metal per i dettagli a basso livello**, concentrandosi sul generare MSL efficiente. Questo introduce incertezze sulle performance: il team Triton ha il know-how per ottimizzare su NVIDIA grazie alle conoscenze pregresse, mentre su Apple dovrebbe acquisire esperienza sulle caratteristiche microarchitetturali (ad esempio, come sfruttare al meglio la memoria threadgroup su Apple, quale è il warp size effettivo e le implicazioni, etc.). - **Differenze architetturali e di modelli di memoria:** benché concetti come warp di 32 thread e memoria condivisa esistano anche su Apple, la **Unified Memory** cambia alcune assunzioni. Su NVIDIA, Triton assume che esista memoria globale “lenta” separata e memoria host separata – il che comporta esplicite distinzioni tra puntatori device/host. In ambiente Apple, un puntatore può riferire a memoria unificata valida sia per CPU che GPU; il confine è più sfumato. Inoltre, Apple **non ha memoria “constant” dedicata** o cache di texture separata: i _constant buffer_ in Metal risiedono anch’essi nella memoria unificata (ma con percorsi di accesso ottimizzati). Il backend Triton dovrebbe quindi gestire diversamente (o ignorare) certe ottimizzazioni pensate per la gerarchia NVIDIA, e al contempo sfruttare peculiarità di Apple come la possibilità di accesso coerente CPU-GPU ai dati (es.: in alcuni casi potrebbe essere utile che la CPU prepari direttamente i dati in strutture allineate per il kernel GPU in shared memory, ecc.). Queste differenze richiedono studio approfondito e adattamento delle pass di ottimizzazione. - **Supporto del vendor e documentazione:** AMD è riuscita a ottenere Triton funzionante sulle proprie GPU in gran parte perché AMD stessa (o community affiliata) ha investito nello sviluppo, fornendo specifiche e integrandolo in ROCm. Per Apple finora non risultano iniziative simili. Apple tende a preferire soluzioni _chiuse_ (il suo focus è MLX/CoreML), e potrebbe non avere interesse diretto a investire in Triton (che di fatto favorirebbe l’open source ML su Mac fuori dal suo controllo). Un segnale interessante, però, è che **Apple ha recentemente sponsorizzato lavori per rendere MLX portabile su CUDA**. Cioè, Apple sembra voler attirare sviluppatori a usare MLX su Mac e poi permettere di esportare il codice su GPU NVIDIA per produzione. Se invertiamo la prospettiva, un analogo supporto al contrario (far girare codice “CUDA-like” su Apple GPU) potrebbe rientrare nell’interesse di Apple per ampliare l’adozione dei Mac nell’AI. Tuttavia, allo stato attuale, chi volesse lavorare a un backend Triton per Apple lo farebbe _al buio_, senza documentazione pubblica sull’ISA GPU (se non reverse engineering come quello di alcuni blog di low-level graphics) e senza supporto ufficiale di Apple. Questo alza la barriera di ingresso in modo significativo. In definitiva, la mancanza di Triton su Apple Silicon è sia un problema di _priorità di sviluppo_ (nessuno ha ancora implementato il backend necessario) sia un problema di _ecosistema chiuso_. Finché Apple non apre di più il suo stack di GPGPU, o finché un numero sufficiente di sviluppatori scontenti non unisce gli sforzi per realizzare un porting, **le GPU Apple resteranno un’isola parzialmente isolata** nel mare delle piattaforme di calcolo accelerato. ## Tentativi e approcci alternativi per colmare il gap Nonostante le difficoltà, ci sono stati alcuni tentativi e sviluppi paralleli volti a **mitigare l’assenza di Triton su Apple** o comunque a fornire strumenti simili: - **Compilazioni sperimentali di Triton su macOS:** Alcuni membri della comunità hanno provato a **compilare Triton su Mac ARM** per esplorare le possibilità. Ad esempio, un utente ha segnalato di essere riuscito a costruire il wheel di Triton su un MacBook M2, dopo aver corretto piccoli bug di build (differenze nei target arm64 vs aarch64). La compilazione va a buon fine con patch minime e passa i test unitarî lato CPU, ma naturalmente _non può eseguire test GPU_ poiché non c’è una GPU NVIDIA presente. Come l’utente stesso nota, _“ottenere una build funzionante non sblocca tutte le capacità supportate del linguaggio: Apple silicon GPUs non sono supportate al momento. Ma volevo almeno un Triton nativo per esplorare gli aspetti hardware-agnostici e imparare”_. Queste compilazioni quindi **girano solo in emulazione CPU**: Triton infatti include un interprete CPU (principalmente per fini di debug e testing) ma senza accelerazione alcuna. Servono più che altro a studiare l’IR di Triton o ad utilizzare Triton come generatore di codice PTX “offline” sul Mac (senza eseguirlo). Sono esercizi intellettuali utili, ma non risolvono il problema centrale. - **Tentativi di backend non-NVIDIA in Triton:** Come accennato, c’è chi ha provato ad aggiungere il supporto M1. Nel 2023 un contributor segnalava: _“sto lavorando a un backend Apple silicon, ma il progetto ha subito notevoli cambiamenti di architettura; dai miei test non riesco a far funzionare nemmeno ROCm, sembra che al momento le GPU Nvidia siano le uniche funzionanti. Il nuovo design è parecchio cucito su Nvidia… spero che diventi più astratto, non vorrei che tutto il lavoro su M1 finisca buttato”_. Questa issue su GitHub (#2048) è tuttora aperta e sottolinea come, almeno in quel momento, **il refactoring di Triton attorno a MLIR** avesse reso temporaneamente non funzionanti i backend alternativi in cantiere. Ciò però può anche essere visto positivamente: tali modifiche architetturali (fine 2022) miravano proprio a _rendere Triton più modulare_ e predisposto a backend multipli. Infatti, oggi vediamo i frutti su AMD. Dunque il lavoro sul backend M1 potrebbe in futuro riprendere su basi più solide. Finora, però, non risultano pull request sostanziali in upstream aggiungenti il supporto Apple. È possibile che esistano branch sperimentali non pubblici o sforzi interni (ad esempio qualche gruppo di ricerca interessato), ma nulla di ufficiale è emerso. - **Approccio di PyTorch: codegen Metal in Inductor:** Come già menzionato, gli sviluppatori PyTorch non sono rimasti del tutto inerti. Nel corso del 2024-2025 hanno iniziato a implementare un _codegen nativo per Metal_ dentro TorchInductor. Questo progetto è significativo perché, di fatto, sostituisce il ruolo di Triton (per il caso specifico di PyTorch su Mac) con un nuovo componente dedicato. Il codice generato non è più PTX ma **MSL**: Inductor contiene un modulo codegen/[mps.py](http://mps.py) che traduce il grafo ottimizzato di PyTorch in uno shader Metal compilabile. A giudicare dai commenti, questo supporto è ancora _sperimentale_ e incompleto, ma ha raggiunto lo stadio in cui un semplice modello può essere _compilato e lanciato su GPU M1 tramite Metal_. In prospettiva, se maturasse, significherebbe che PyTorch su Mac potrebbe eseguire fusione di operatori e altre ottimizzazioni senza bisogno di Triton. Tuttavia, questo rimane **limitato all’ambito PyTorch** e non offre un API pubblica generica. Inoltre, duplicare logiche di ottimizzazione che Triton già offre è inefficiente sul lungo termine. Sarebbe più ideale se anche PyTorch potesse utilizzare Triton su Mac; ma, non avendolo, hanno dovuto implementare un surrogato. - **Apple** MLX **(Machine Learning eXperience):** Apple nel 2023 ha sorpreso aprendo il codice di MLX, un framework numerico simile a NumPy/JAX ottimizzato per Apple Silicon. MLX sfrutta kernel altamente ottimizzati (anche per l’ANE, Neural Engine, oltre che GPU/CPU) e in alcune demo ha mostrato notevoli boost prestazionali per modelli di deep learning su Mac. MLX però _non espone direttamente_ un modo per scrivere kernel personalizzati tipo Triton – è una libreria di operazioni predefinite, seppur molto completa. Un utente su GitHub ha chiesto ad Apple se intendono supportare “scrittura di kernel Metal via Python” in MLX, analogamente a Numba CUDA. Al momento non vi è indicazione che ciò sia nei piani (l’issue rimane una semplice richiesta). Apple sembra puntare più a fornire tutte le primitive necessarie già ottimizzate internamente, piuttosto che dare libertà all’utente di programmare la GPU. Interessante però la strategia emergente: come citato prima, Apple ha in sviluppo un backend CUDA per MLX, in modo che il codice scritto usando MLX su Mac possa poi essere “esportato” su cluster NVIDIA per l’esecuzione accelerata. Questo approccio **inverse-CUDA** indica che Apple vuole _ridurre il vendor lock-in_ per incoraggiare l’uso del suo framework (sapendo che in produzione i modelli girano su GPU Nvidia). Fa sorridere pensare che Triton ha l’obiettivo opposto – permettere a chi sviluppa in ambiente CUDA di eseguire su altri acceleratori scrivendo codice portabile. In un mondo ideale, i due approcci convergerebbero: se Apple **aprisse la porta a Triton**, potremmo scrivere un kernel una volta e farlo girare ovunque – su Mac durante lo sviluppo e su GPU Nvidia/AMD in produzione, senza modifiche. Al momento, invece, abbiamo MLX per Mac (con potenziale export) e Triton per Nvidia/AMD (con potenziale import se un giorno Apple fosse supportata). - **Soluzioni multi-piattaforma in altri linguaggi:** Vale la pena notare che l’idea di un linguaggio di programmazione GPU portabile non è fantascienza – esistono già esempi. In ambito **Julia**, ad esempio, la comunità ha creato _Metal.jl_ per targeting diretto delle GPU Apple, nonché il pacchetto **KernelAbstractions.jl** che permette di scrivere un kernel in Julia e eseguirlo su diversi backend (CUDA, Metal, CPU) quasi trasparentemente. Ciò dimostra che _un’astrazione comune sulle GPU eterogenee è possibile_: Julia lo fa sfruttando ovviamente il fatto che può interfacciarsi con i vari driver (CUDA, Metal) con binding nativi. Nel mondo Python, progetti come **SYCL/DPC++** di Intel puntano a qualcosa di simile per CPU/GPU, ma non hanno presa nell’AI come Triton. **Mojo**, un nuovo linguaggio emergente per computing ad alte prestazioni compatibile con Python, promette anch’esso portabilità fra device (inclusi i core Apple) grazie a un potente backend compiler unificato – ma è ancora in fase iniziale e proprietaria. In sintesi, _l’assenza di Triton su Apple non significa che sia impossibile ottenere qualcosa di analogo:_ semplicemente, ad oggi manca l’implementazione in quel contesto. Se Julia può lanciare kernel su Metal e perfino su WebGPU, nulla vieta teoricamente a Triton (o un suo successore) di includere un backend Apple e realizzare la visione di **un linguaggio universale per programmare GPU** indipendentemente dal produttore. ## Prospettive future e conclusioni La domanda cruciale è: _come si potrà colmare questo gap nell’ecosistema Apple Silicon?_ Diverse strade sono possibili, non mutualmente esclusive: - **Apple supporta direttamente Triton:** Uno scenario auspicabile sarebbe una collaborazione diretta. Apple potrebbe fornire risorse (ingegneri, documentazione) per aiutare ad implementare il backend Metal in Triton. Potrebbe ad esempio rilasciare un’SDK specifica per compilare compute kernels offline, o collaborare con OpenAI/PyTorch per definire un pathway ottimale. Considerando che Apple ha sponsorizzato parti di MLX per CUDA, non è impossibile che valutino anche il percorso inverso. Dal punto di vista di Apple, abbracciare Triton significherebbe rendere i Mac più attraenti ai ricercatori: un utente esperto potrebbe sviluppare e ottimizzare modelli direttamente su MacBook Pro, sfruttando a pieno la GPU, senza doversi adattare a linguaggi differenti. Questo aumenterebbe il valore della piattaforma Mac nel ML open-source. Ovviamente Apple dovrebbe accettare di perdere un po’ di controllo in favore dell’open source, cosa non scontata. - **Sforzo open-source comunitario:** Se Apple non si muove, la comunità potrebbe comunque procedere. L’arrivo del supporto AMD in Triton mostra che la base di codice ora può essere estesa ad architetture nuove. Un team di sviluppatori motivati potrebbe lavorare a un backend Apple. Probabilmente sarebbe necessario _reverse-engineering_ di alcuni dettagli (ad esempio, comprendere le migliori pratiche per distribuzione dei thread sui core Apple, come gestire la tile memory, ecc., basandosi su pochi riferimenti pubblici e test empirici). Una possibilità interessante è sfruttare l’**infrastruttura MoltenVK**: se Triton generasse SPIR-V (come stava valutando in passato per Intel/AMD), MoltenVK potrebbe tradurlo in chiamate Metal. Tuttavia, MoltenVK è pensato per workload grafici e non garantisce di esporre tutte le feature compute al massimo rendimento. Più probabilmente si dovrà generare direttamente MSL. In ogni caso, un progetto di questo tipo richiederebbe mesi di lavoro e competenze sia di compilatori (MLIR, LLVM) sia di programmazione GPU Metal – un insieme di skill piuttosto raro. Potrebbe emergere da ambienti accademici (ad esempio, gruppi di ricerca che vogliono usare i cluster di Mac per calcolo parallelo) o da aziende che puntano sul ML on-device. - **Evoluzione dei framework ad alto livello:** Parallelamente, i grandi framework come PyTorch e TensorFlow potrebbero continuare a migliorare il proprio supporto nativo per Apple, riducendo la necessità di Triton lato utente finale. PyTorch con il suo Metal codegen potrebbe coprire progressivamente sempre più operatori e casi d’uso, fino a fornire prestazioni vicine a quelle Triton+CUDA per molte reti neurali standard. Apple dal canto suo potrebbe potenziare **Core ML Tools** per compilare modelli in eseguibili altamente ottimizzati (magari sfruttando il Neural Engine combinato alla GPU). In pratica, la **“soluzione” Apple** potrebbe essere: _non dare direttamente un Triton agli utenti, ma rendere meno necessario il Triton perché il framework pensa a tutto_. Questa filosofia _walled garden_ funziona bene per molti sviluppatori (quelli che preferiscono le soluzioni chiavi in mano), ma lascia comunque insoddisfatta la fascia dei _“power user”_ che vorrebbero metter mano alle ottimizzazioni specifiche. Dunque, anche con migliori backend automatici, per la ricerca pura rimarrebbe il desiderio di uno strumento low-level. - **Nuove astrazioni intermedie:** Un’altra prospettiva è che emerga uno _standard_ o un layer intermedio che consenta portabilità del codice ad alte prestazioni su GPU diverse. Ad esempio, il progetto OpenXLA (compilatore ML portabile per vari acceleratori) o iniziative di definire dialetti MLIR standardizzati per compute accelerato potrebbero includere il supporto ad Apple GPU. Se Triton non colmasse il vuoto, forse un successore o concorrente potrebbe. Ad oggi però, Triton è unico nel suo genere per semplicità ed efficacia, quindi qualsiasi alternativa dovrebbe perlomeno ispirarsi ad esso. **Il linguaggio Triton rappresenta esattamente quel tipo di infrastruttura software che manca all’ecosistema AI su Apple Silicon**. La sua assenza priva i ricercatori su Mac della libertà di sperimentare liberamente sul proprio hardware, costringendoli ad aggirare il problema con soluzioni subottimali. Abbiamo visto come Triton fornisca un livello di controllo e ottimizzazione fine sul GPU computing che è stato determinante nel mondo NVIDIA per spingere in avanti lo stato dell’arte (dal punto di vista di performance e rapidità di prototipazione). Portare queste capacità anche su Apple Silicon significherebbe **sbloccare tutto il potenziale delle GPU integrate dei Mac** in ambito machine learning, evitando che restino sotto-utilizzate o relegate a ruoli secondari. C’è un intero pubblico di sviluppatori avanzati che ne gioverebbe: pensiamo ai team che sviluppano modelli all’avanguardia, che potrebbero iterare e fare tuning direttamente sul laptop durante i viaggi; o ai ricercatori universitari che potrebbero sfruttare i pool di Mac Studio come mini-cluster GPU programmabili. Al momento, molti di questi scenari non sono pratici senza Triton (o equivalente). L’auspicio è che nel prossimo futuro questo divario si riduca. L’evoluzione recente – con AMD supportata, con Apple MLX open source, con PyTorch che sperimenta nuovi backend – fa sperare in una **maggiore apertura e interoperabilità**. Forse vedremo nascere un progetto Triton-metal, o Apple stessa potrebbe sorprendere integrando un meccanismo simile nel suo stack (magari un “Metal JIT Compiler” Python-facing). Nel frattempo, la discussione stessa è utile: evidenziare documentazione, problemi e tentativi in corso serve a far crescere la consapevolezza di _cosa manca_ e perché è importante. Apple Silicon ha portato una ventata di innovazione nell’hardware: sarebbe paradossale non poterla sfruttare appieno per mancanze nel software. **Colmare questa lacuna – dotare l’ecosistema Apple di infrastrutture paragonabili a Triton – sarà decisivo affinché i Mac giochino un ruolo da protagonisti nell’AI open source, anziché da semplici spettatori**]]> apple mlx triton https://blog.michelelaurelli.it/the-unspoken-challenges-of-llms-in-production/ https://blog.michelelaurelli.it/the-unspoken-challenges-of-llms-in-production/ Tue, 25 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Fisnik Murati LLM Stabilità https://blog.michelelaurelli.it/building-private-ai-systems/ https://blog.michelelaurelli.it/building-private-ai-systems/ Fri, 21 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli AI Privata Enterprise Tecnologia https://blog.michelelaurelli.it/autonomous-ai-agents-maestro-architecture/ https://blog.michelelaurelli.it/autonomous-ai-agents-maestro-architecture/ Tue, 18 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Agenti AI Maestro Architettura AI Innovazione https://blog.michelelaurelli.it/training-ai-without-data/ https://blog.michelelaurelli.it/training-ai-without-data/ Mon, 10 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Machine Learning Addestramento Auto-Supervisione https://blog.michelelaurelli.it/what-makes-intelligence-intelligent/ https://blog.michelelaurelli.it/what-makes-intelligence-intelligent/ Sat, 08 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Filosofia IA Intelligenza Filosofia https://blog.michelelaurelli.it/teaching-ai-not-using-it/ https://blog.michelelaurelli.it/teaching-ai-not-using-it/ Wed, 05 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Educazione Insegnamento Ingegneria https://blog.michelelaurelli.it/edge-ai-industrial-automation/ https://blog.michelelaurelli.it/edge-ai-industrial-automation/ Sun, 02 Nov 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli IA Applicata Automazione Industriale Edge AI Manifattura https://blog.michelelaurelli.it/model-collapse-forgetting/ https://blog.michelelaurelli.it/model-collapse-forgetting/ Thu, 30 Oct 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Architettura IA Machine Learning Ricerca https://blog.michelelaurelli.it/rag-systems-beyond-vector-search/ https://blog.michelelaurelli.it/rag-systems-beyond-vector-search/ Tue, 28 Oct 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli IA Privata RAG IA Enterprise IA Applicata https://blog.michelelaurelli.it/ai-creativity-constraints/ https://blog.michelelaurelli.it/ai-creativity-constraints/ Sat, 25 Oct 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Filosofia IA Creatività Filosofia https://blog.michelelaurelli.it/optimization-landscapes-neural-networks/ https://blog.michelelaurelli.it/optimization-landscapes-neural-networks/ Wed, 22 Oct 2025 00:00:00 GMT 2026-10-27T00:00:00.000Z Michele Laurelli Architettura IA Deep Learning Ottimizzazione Machine Learning