Infrastrutture software assenti ma necessarie per l’AI su Apple Silicon: il linguaggio Triton

L’avvento dei SoC Apple Silicon (M1, M2, ecc.) ha dato agli sviluppatori hardware potente e unificato per l’intelligenza artificiale, ma ha anche messo in luce un vuoto significativo nell’ecosistema software. In particolare, manca un’infrastruttura di programmazione GPU flessibile e a basso livello analoga a quelle disponibili su piattaforme NVIDIA. La comunità di ricerca lamenta che su Mac non esiste l’equivalente di CUDA o strumenti come Numba/Triton per scrivere kernel personalizzati direttamente in Python – d’altronde “Metal non è un framework popolare tra i ricercatori, né lo sono Swift/Xcode. Se [Apple] avesse qualcosa come il JIT CUDA di Numba, potremmo fare più ricerca su Mac […] e dire che avere un MacBook Pro non significa rinunciare a eseguire modelli di ricerca sul laptop” (github.com/ml-explore). In questo contesto, il linguaggio Triton di OpenAI emerge come l’esempio emblematico di infrastruttura assente ma necessaria: un DSL (domain-specific language) in grado di colmare il divario tra l’hardware Apple e le esigenze di ottimizzazione dell’AI. In quest’articolo tecnico analizziamo la natura di Triton, la sua importanza nel panorama del machine learning, e perché la sua mancanza nell’ecosistema Apple Silicon costituisce un problema da risolvere, esaminando documentazione, sfide tecniche, tentativi in corso e prospettive future.

L’ecosistema Apple Silicon per l’AI: potenziale hardware e limiti software

Apple Silicon introduce un’architettura eterogenea con CPU ad alte prestazioni/efficienza, GPU integrate e persino un Neural Engine dedicato, il tutto con memoria unificata (UMA) condivisa tra CPU e acceleratori. Questa progettazione offre vantaggi significativi per l’AI: un’ampia banda di memoria condivisa e latenza ridotta nell’accesso ai dati tra CPU e GPU, eliminando la necessità di copie esplicite host-device (Apple Metal vs NVIDIA Cuda). Apple ha costruito attorno a questo hardware un ecosistema software proprietario, con API come Metal per la programmazione GPU e framework di alto livello come Core ML e Accelerate/BNNS per utilizzare GPU e Neural Engine in modo trasparente. Inoltre, Apple ha rilasciato il nuovo framework open-source MLX (Machine Learning eXperience), una libreria NumPy-like altamente ottimizzata per Apple Silicon (Machine Learning Apple), con cui mira a rendere più agevole l’esecuzione locale di modelli di deep learning su Mac.

Tuttavia, nonostante queste solide fondamenta hardware e le librerie fornite, all’ecosistema Apple manca un elemento cruciale: la possibilità per ricercatori e sviluppatori di sfruttare al massimo la GPU Apple scrivendo kernel personalizzati e ottimizzati.

Su macOS non è disponibile CUDA (le GPU NVIDIA non sono supportate su Mac dal 2018 in poi), e Apple ha anche deprecato OpenCL/OpenGL in favore di Metal.

I framework di deep learning come PyTorch e TensorFlow hanno introdotto il supporto al backend Metal (MPS) per utilizzare la GPU Apple nei tipici operatori tensoriali; ad esempio, PyTorch dalla versione 1.12 consente il training su GPU dei Mac M1 tramite l’API MPS.

Questo è stato un passo importante, ma rimane confinato all’uso di operatori predefiniti. Se uno sviluppatore volesse implementare un nuovo operatore o una variante custom di un layer neurale su Mac, oggi non dispone di strumenti equivalenti a quelli disponibili su GPU NVIDIA.

In sintesi, l’ambiente Apple Silicon offre potenza hardware ma non fornisce (ancora) un mezzo aperto e flessibile per programmare tale hardware ai livelli più bassi. Questo contrasta con l’ecosistema NVIDIA, dove esiste una ricca infrastruttura software per l’AI: il linguaggio CUDA e una miriade di librerie, nonché DSL come Triton, che consentono di scrivere kernel GPU su misura ottenendo prestazioni estreme senza dover padroneggiare tutti i dettagli hardware.

Per contestualizzare la differenza, consideriamo le architetture GPU alla base.

Figura - Architettura semplificata di una GPU NVIDIA (CUDA): più SM (Streaming Multiprocessor) con ALU (quadrati verdi) e memorie locali (cache, shared memory) sono collegati tramite unità di Load/Store a una memoria globale del device separata dalla memoria di sistema.

Come mostrato sopra, nelle GPU NVIDIA ogni SM rappresenta l’unità di calcolo fondamentale, con i propri core e cache, e tutte le SM accedono a una memoria VRAM globale (distinta dalla RAM CPU) tramite un’interconnessione ad alta banda. I thread sono organizzati in blocchi all’interno di ogni SM e condividono tra loro una memoria condivisa (shared) veloce locale all’SM, mentre la memoria globale ha latenza maggiore. Questa architettura richiede una gestione esplicita dei trasferimenti di dati tra host (CPU) e device (GPU) e l’ottimizzazione della località dei dati per massimizzare l’uso delle memorie veloci di bordo.

Figura - Architettura semplificata di una GPU Apple (Metal): più core grafici equivalenti agli SM (ognuno con ALU, “Control” e memoria locale) sono connessi a un’unica Unified System Memory, cioè la memoria unificata condivisa con la CPU..

Nel caso di Apple, ogni core GPU (unità di calcolo analoga a un SM) ha anch’esso ALU vettoriali e cache, e thread organizzati in threadgroup (il corrispettivo dei blocchi CUDA). Anche qui esiste una memoria locale condivisa per threadgroup (denominata threadgroup memory, concettualmente simile alla shared memory NVIDIA). La differenza chiave è che non vi è una VRAM separata: la GPU e la CPU accedono alla stessa memoria fisica unificata. Ciò semplifica il modello di programmazione lato host (non servono espliciti cudaMemcpy), ma implica che la coerenza e contesa di memoria devono essere gestite con attenzione per evitare colli di bottiglia quando CPU e GPU accedono congiuntamente ai dati. Apple, controllando strettamente hardware e software, è riuscita a sfruttare efficacemente l’UMA in molti casi d’uso. Tuttavia, dal punto di vista di uno sviluppatore GPU, Metal risulta più “basso livello” rispetto a CUDA: lanciare un kernel richiede impostare manualmente pipeline, buffer, command encoder, ecc., mentre CUDA offre costrutti più automatizzati (es. la sintassi <<< >>> 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]. 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 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