Migliori agenti AI per l’ottimizzazione GPU nel 2026: AKO, KernelAgent, AutoKernel, Apex e CUDA Agent a confronto

Un’accelerazione dichiarata di 232x per un kernel GPU può ridurre il carico di lavoro complessivo di meno del 5%. Per questo, il miglior agente AI per l’ottimizzazione GPU non è quello associato al benchmark più eclatante, ma quello che offre il percorso hardware corretto, un banco di prova inflessibile sulla correttezza e una soglia di ritorno economico end-to-end.

Risposta breve sull’ottimizzazione GPU: AKO è il migliore in assoluto, ma l’hardware cambia la classifica

AKO è il miglior harness per agenti AI quando si affronta una seria campagna di ottimizzazione su GPU NVIDIA. Offre la combinazione più solida di confronti con baseline sviluppate da esperti, infrastruttura ripetibile per le campagne e audit indipendente. Non è un nuovo modello: mette Claude Code nelle condizioni di proporre kernel, misurarli, conservare i percorsi promettenti e smascherare i candidati che sembrano corretti senza esserlo davvero.

Su hardware AMD, il verdetto cambia subito. Apex è la scelta dedicata a ROCm, mentre AutoKernel è l’alternativa più generalista per alcuni acceleratori AMD Instinct. KernelAgent si adatta meglio a un team PyTorch che cerca un ciclo per NVIDIA o Intel XPU guidato dai contatori hardware. CUDA Agent mostra il potenziale di ricerca più elevato del confronto, ma oggi non è un prodotto che un team possa adottare operativamente.

Prezzi e disponibilità riportati di seguito sono stati verificati il 16 agosto 2026. Si tratta di sistemi open source self-hosted: un prezzo iniziale di $0 indica quindi l’assenza di un canone software. Piano del modello, consumo API, lavoro degli ingegneri e calcolo GPU restano costi separati.

La tabella evita volutamente di ripetere i moltiplicatori dei benchmark. Le baseline esperte di AKO, il confronto di KernelAgent con torch.compile, la validazione di Apex su sette kernel, il risultato KernelBench di CUDA Agent e il 232x dichiarato nella competizione partono da denominatori diversi. Ordinarli dal più grande al più piccolo darebbe un’apparenza di precisione senza fornire indicazioni utili.

La regola decisionale è semplice: scegliere l’harness in grado di profilare, verificare e distribuire il codice sull’acceleratore effettivamente in uso, quindi confrontare le prove disponibili all’interno di quel percorso. Un ottimizzatore teoricamente superiore, ma incompatibile con l’hardware, ha un valore aziendale pari a zero.

Che cosa significa davvero un risultato di 232x per la spesa GPU

L’entusiasmo del momento parte da un risultato concreto. In un resoconto diretto arrivato su Hacker News il 15 agosto 2026, Sankalp riferisce di aver portato un benchmark NVIDIA B200 per la decomposizione QR da circa 419,000 microsecondi a 1,805 microsecondi: è il 232x dichiarato. La campagna è durata 14 giorni, ha prodotto più di 1,500 invii e si è chiusa al posto numero 12 su 183 partecipanti. L’autore ha registrato 103 invii che hanno migliorato il record uno dopo l’altro, passando da 108,803 a 1,805 microsecondi, con una riduzione del 98.34%. Il resoconto completo descrive configurazione e limiti dell’esperimento.

È una prova notevole dell’efficacia del workflow, non la dimostrazione che un modello in produzione diventi 232x più economico. Il punto di partenza era un’implementazione approssimativa per uno specifico benchmark. Il risultato finale è arrivato dopo interventi umani, competenza di dominio e ripetuti tentativi di uscire da ottimi locali. L’autore racconta quanto sia stato difficile scendere da circa 3,000 a 1,800 microsecondi e consiglia di esplorare da tre a cinque candidati in parallelo, invece di affidarsi a un solo percorso di ottimizzazione.

La variabile mancante è la quota del kernel critico, cioè la parte del tempo totale di esecuzione trascorsa nel kernel da ottimizzare. Secondo la legge di Amdahl, la porzione del sistema che non cambia impone un limite invalicabile al miglioramento complessivo.

Se il kernel assorbe il 25% del tempo di esecuzione e diventa 232x più veloce, lo speedup totale teorico è soltanto 1.3314x. La riduzione teorica del costo corrisponde al 24.8922%. Se lo stesso kernel occupa il 5% del tempo, lo speedup complessivo scende a 1.0524x e il risparmio teorico al 4.9784%.

Ecco perché un verificatore conta più di una demo brillante del modello. Un candidato può sfruttare input ripetuti, comportamento della cache, tolleranze troppo permissive o un insieme ristretto di shape e ottenere comunque un punteggio locale spettacolare. In produzione la domanda è più severa: rimane corretto con valori nuovi, su tutte le shape servite e dentro il framework reale, migliorando davvero latenza o costo end-to-end?

Anche il costo della campagna descritta è istruttivo. All’epoca, l’autore disponeva di ChatGPT Pro a $200 al mese, Claude Pro a $20 al mese e del credito mensile Starter di Modal pari a $30. Questi abbonamenti hanno reso accessibile la sperimentazione, ma l’unità operativa utile è rimasta una lunga sequenza di benchmark, analisi, modifiche e verifiche. L’agente ha abbassato il costo dell’esplorazione; non ha eliminato la necessità di definire correttamente lo spazio di ricerca.

1. AKO: la scelta migliore per campagne NVIDIA verificate

AKO è la scelta complessivamente migliore quando serve condurre una campagna sui kernel NVIDIA e il team può utilizzare Claude Code. Il suo vantaggio decisivo non è un modello miracoloso: AKO trasforma un agente di coding già esistente in un processo di ottimizzazione registrato, dotato di harness di benchmark, memoria della campagna, profiling e audit avversariale.

Esistono due punti di accesso utili. AKO4ALL è la skill pronta all’uso per ottimizzare un kernel tramite Triton, CUDA, C++, TileLang, CuTe DSL, Python o HIP. Registra la traiettoria e la cronologia Git, rendendo il risultato più ispezionabile di una chat destinata a scomparire. AKO4X è il sistema destinato alle campagne più ampie: può eseguire uno o più round, mantenere un archivio tra esecuzioni, lavorare in locale o su Modal, raccogliere profili NCU, far evolvere l’harness quando espressamente consentito ed effettuare un audit indipendente.

È proprio quest’ultima funzione a portare AKO al primo posto. Il materiale pubblicato mostra un candidato basato sulla cache che sembrava valido finché un controllo indipendente non ha modificato i valori di input riutilizzando gli stessi puntatori. A quel punto ha fallito tutti e 38 i controlli. È esattamente il tipo di reward hacking che sfugge a un benchmark permissivo e viene scoperto troppo tardi da un incidente in produzione.

Le prove sono documentate con una trasparenza insolita. La valutazione pubblicata di AKO ha utilizzato una NVIDIA B200 con CUDA 13.2, PyTorch 2.12, Triton 3.6 e Claude Opus 4.7 o 4.8. Su 10 famiglie di kernel e 471 carichi di lavoro, gli autori dichiarano di aver superato l’implementazione esperta in nove famiglie, con miglioramenti della media geometrica compresi tra 1.14x e 1.43x. Tra i casi più significativi figurano 30.71x per la sparse attention DSA, con 23 carichi su 23 superati, e 2.30x per il prefill GDN, con 100 su 100. AKO pubblica sia gli intervalli dei carichi sia l’ambiente di prova, e proprio questo rende preziosi anche i risultati meno vistosi.

Sono infatti i risultati più contenuti a offrire il segnale d’acquisto più credibile. GQA decode presenta un intervallo da 0.85x a 1.81x, MLA decode da 0.84x a 1.98x, MLA prefill da 0.82x a 2.37x e RMSNorm da 0.96x a 1.67x. GEMM è rimasto a 1.00x perché cuBLAS non è stato battuto. In altre parole, AKO perde su alcuni carichi e, in certi casi, non riesce a migliorare una libreria esperta ormai matura. È un quadro molto più credibile di una pagina in cui ogni indicatore punta verso l’alto.

Ideale per: team NVIDIA che eseguono campagne sui kernel ripetibili e sottoposte ad audit

Punto di forza: audit indipendente e memoria condivisa tra le campagne

Prezzo: $0 per il software AKO4X self-hosted con licenza MIT; Claude Code e l’uso della GPU sono separati, dati verificati il 16 agosto 2026

Prova gratuita: non applicabile

Secondo AKO, una tipica esecuzione di AKO4ALL dura circa 55 minuti e utilizza all’incirca 15,000 token di input, 253,000 token di output, 17.6 milioni di token letti dalla cache e 752,000 token scritti nella cache. Questo profilo rende l’economia del caching e i limiti del piano del modello parte integrante del budget. L’harness open source può costare $0, ma la campagna no.

1. 1

   Profilare un carico di produzione

   Misurare l’intera richiesta e individuare la quota di runtime del kernel prima di aprire una sessione con l’agente. Registrare shape rappresentative, dtype, dimensioni dei batch, comportamento del warm-up e costo end-to-end attuale. Se il kernel non è critico, fermarsi.

2. 2

   Scegliere AKO4ALL o AKO4X

   Usare AKO4ALL per un singolo kernel ben delimitato e AKO4X quando servono più round, un archivio, profiling NCU o audit indipendenti della campagna. Non partire dal sistema più grande soltanto perché offre più controlli.

3. 3

   Bloccare riferimento e input

   Considerare l’implementazione esistente come riferimento. Costruire i controlli di correttezza sulle shape effettivamente usate in produzione e aggiungere valori nuovi che impediscano scorciatoie basate su output memorizzati. Proteggere l’harness dalle modifiche dell’agente, salvo quando la sua evoluzione è parte esplicita dell’esperimento.

4. 4

   Eseguire una ricerca con un tetto di spesa

   Per il primo tentativo, fissare un limite di 32 ore su B200 e abbinarlo a un piano agente da $100. Ai prezzi attuali di Modal, il progetto pilota costa $299.99 prima del lavoro degli ingegneri. Conservare ogni candidato accettato insieme al suo ambiente esatto.

5. 5

   Condurre un audit indipendente

   Eseguire nuovamente il candidato vincente fuori dal contesto di lavoro dell’agente, con valori modificati, puntatori riutilizzati quando opportuno, shape di confine e prove ripetute. Un candidato che vince soltanto nel proprio ciclo di addestramento va scartato.

6. 6

   Esigere un ritorno end-to-end

   Integrare il kernel nel modello o servizio reale, quindi misurare latenza dell’intero carico e costo dell’acceleratore. Procedere al rilascio solo se il risparmio mensile osservato rispetta la finestra di ritorno definita prima della campagna.

2. KernelAgent: il miglior ciclo nativo PyTorch guidato dall’hardware

KernelAgent è la soluzione più adatta a un team PyTorch che vuole orientare l’ottimizzatore con i contatori hardware, anziché procedere per ripetuti tentativi sul codice. Il progetto open source riunisce generazione dei kernel, profiling, verifica, benchmarking e ottimizzazione in un ciclo multi-agente.

Il feedback del profiler è il suo elemento più distintivo. Il sistema raccoglie 28 metriche NVIDIA Nsight Compute, usa un modello roofline per stabilire se un candidato è limitato dalla memoria, dalla capacità di calcolo o da uno scarso utilizzo e indirizza di conseguenza l’ottimizzazione successiva. Un modello roofline serve, in sostanza, a capire se il kernel è frenato dalla potenza aritmetica, dal movimento dei dati o da una bassa occupazione. Questa diagnosi rende più mirata la modifica seguente.

Il ciclo verifica gli output, misura le prestazioni con eventi CUDA e può arrestarsi al numero di round configurato, alla convergenza o al raggiungimento di almeno il 95% dell’efficienza speed-of-light. Il repository indica il supporto completo per NVIDIA CUDA e Intel XPU, ma non per AMD ROCm. Funziona su Linux e macOS con Python da 3.8 a 3.12 e richiede Triton, PyTorch e un provider di modelli OpenAI, Anthropic o personalizzato. Il repository di KernelAgent riporta la matrice di supporto corrente.

Il benchmark pubblicato comprende 100 attività KernelBench Level 1. Gli autori dichiarano un miglioramento di 2.02x rispetto a un precedente gruppo di kernel generati, 1.56x rispetto a torch.compile predefinito, vittorie su torch.compile in 65 casi su 100 e il raggiungimento dell’89% del roofline di H100. A un sistema di generazione precedente viene attribuita una correttezza del 100% su 250 attività Level 1, Level 2 e Level 3; quel dato sulla correttezza non va trasferito senza cautela a ogni risultato ottimizzato di KernelAgent.

Un caso concreto rappresenta il valore effettivo meglio del dato aggregato. Un’implementazione matrice-vettore è passata da 9.52 millisecondi a 1.95 millisecondi, mentre torch.compile ha raggiunto 2.09 millisecondi. L’agente ha accelerato drasticamente l’implementazione grezza, ma il margine finale rispetto al compilatore già disponibile è stato molto più ridotto. Per questo la baseline economica deve essere il miglior sistema che verrebbe altrimenti distribuito, non il codice più lento che un agente può sostituire.

Ideale per: team PyTorch su NVIDIA CUDA o Intel XPU che vogliono iterazioni guidate dal profiler

Punto di forza: instradamento roofline basato su 28 metriche NCU

Prezzo: $0 per il software con licenza Apache 2.0; provider del modello e uso della GPU sono separati, dati verificati il 16 agosto 2026

Prova gratuita: non applicabile

KernelAgent dovrebbe essere la seconda scelta quando sono importanti un’architettura pulita e nativa PyTorch e la libertà di scegliere il provider. Diventa la prima quando il target rientra già nello stack supportato e il team vuole capire perché un kernel è lento. È meno indicato per una vasta campagna autonoma che richiede, già pronta, memoria tra esecuzioni e strumenti di audit avversariale.

3. AutoKernel: il miglior ciclo semplice per esperimenti notturni

AutoKernel è il punto di partenza più pratico per un team che vuole affidare a Claude, Codex o un altro agente di coding un semplice ciclo notturno di profiling, modifica e benchmark. Profila il modello, individua i colli di bottiglia, modifica Triton o CUDA C++, conserva o annulla ogni candidato e verifica infine il modello end-to-end.

Il progetto documenta un benchmark fisso con cinque fasi di controllo della correttezza e un report roofline. Un harness immutabile è essenziale: in caso contrario, un agente di coding con troppa libertà potrebbe migliorare il punteggio cambiando il test invece del kernel. Nel ciclo di AutoKernel, ogni candidato affronta la stessa prova e viene mantenuto solo in presenza di un miglioramento misurato.

Il ritmo previsto è facile da inserire in un budget. La documentazione stima circa 90 secondi per esperimento, circa 40 esperimenti all’ora e circa 320 nel corso di una notte. Sono valori utili alla pianificazione, non prestazioni garantite. Il repository descrive inoltre da 50 a più di 300 esperimenti per ciascun problema KernelBench su un insieme di oltre 250 problemi. AutoKernel documenta il ciclo e i requisiti attuali.

L’ampiezza del supporto hardware è un vantaggio reale. Tra i target NVIDIA testati figurano H100, A100 e RTX 4090. La versione 1.3 ha aggiunto il supporto AMD ROCm per MI300X, MI325X, MI350X e MI355X. Lo strumento richiede Python 3.10 o successivo e uv, e la documentazione elenca nove tipi di kernel.

Altrettanto importante è il limite delle prove disponibili: il README pubblico descrive harness, workflow e scala delle campagne, ma non presenta un benchmark aggregato indipendente e aggiornato per tutti i target supportati. Questo non rende debole AutoKernel. Significa che il motivo corretto per adottarlo è la facilità di distribuzione e la progettazione degli esperimenti, non una vittoria in classifica.

Ideale per: team che cercano un ciclo notturno leggibile e compatibile con diversi agenti

Punto di forza: semplici esperimenti con conservazione o ripristino, seguiti da una verifica end-to-end

Prezzo: $0 per il software con licenza MIT; agente di coding e uso della GPU sono separati, dati verificati il 16 agosto 2026

Prova gratuita: non applicabile

AutoKernel è un primo progetto pilota ragionevole per un team che si fida già del proprio agente di coding e ha bisogno soprattutto di disciplina sperimentale. Va preferito a KernelAgent quando il numero di tentativi notturni e la scelta dell’agente contano più di un progetto multi-agente guidato da NCU. Va preferito ad AKO quando serve un ciclo più leggero o quando sono necessari i target ROCm elencati. Non bisogna sceglierlo soltanto perché 320 esperimenti sembrano automaticamente migliori di 40: la qualità della ricerca dipende dall’harness, dalla varietà dei candidati e dalla baseline.

4. Apex: la migliore soluzione dedicata ad AMD ROCm

Apex è la scelta dedicata migliore per ottimizzare i carichi AMD ROCm supportati. Si tratta dell’ottimizzatore agentico di AMD-AGI, non di NVIDIA Apex, e i suoi presupposti operativi sono legati esplicitamente all’hardware AMD Instinct.

Il target predefinito è MI355X, con supporto dichiarato per MI300X, MI300A e MI250X. L’ambiente richiede Ubuntu 22.04 o successivo, Python 3.10 o successivo, Node.js 18 e ROCm 6.x o successivo per la valutazione. La configurazione attuale installa una wheel PyTorch per ROCm 7.2. Apex può orchestrare Claude Code, Codex o Cursor, ma non include l’accesso ai modelli. Il repository di Apex elenca target e vincoli di configurazione attuali.

Il workflow è pensato per la produzione. Apex misura il carico di lavoro, individua un collo di bottiglia, chiede all’agente un’ottimizzazione, la valuta con Magpie, integra i candidati superiori a 1.05x e conclude con un benchmark end-to-end. Può applicare hotpatch a percorsi Python o Triton in aiter, vLLM e SGLang, oltre che a HIP in aiter. Non può farlo su librerie C++ di sistema o estensioni monolitiche _C.so. Questo limite conta più dell’elenco degli agenti: se il collo di bottiglia si trova dietro una superficie di integrazione che Apex non può sostituire, la campagna non può raggiungerlo.

La validazione del produttore comprende sette kernel. Riporta 36.35x per all_reduce, 1.14x per fused_moe, 1.05x per rms_norm e 1.00x per gli altri quattro. Il 36.35x va considerato un risultato utile su un singolo kernel, non il ritorno atteso per l’intero portafoglio. I quattro kernel rimasti invariati dimostrano che la soglia di accettazione può correttamente decidere di non modificare il codice.

Ideale per: team AMD Instinct il cui collo di bottiglia è raggiungibile tramite un percorso hotpatch ROCm supportato

Punto di forza: ottimizzazione agentica e valutazione end-to-end progettate intorno a ROCm

Prezzo: $0 per il software con licenza MIT; accesso al modello e calcolo su GPU AMD sono separati, dati verificati il 16 agosto 2026

Prova gratuita: non applicabile

Apex diventa la raccomandazione principale non appena il target di produzione è un acceleratore AMD supportato e il codice critico si trova sulla sua superficie modificabile. AutoKernel versione 1.3 è l’alternativa quando si adattano meglio le sue meccaniche di campagna più ampie o il percorso dichiarato da MI300X a MI355X. In nessun caso basta la parola “AMD” per scegliere: occorre controllare l’acceleratore esatto, lo stack ROCm e il punto di integrazione.

5. CUDA Agent: il massimo potenziale nella ricerca, ma non una scelta commerciale

CUDA Agent è il sistema di ricerca più interessante del confronto e la soluzione meno adatta a un acquisto. Il progetto di ByteDance Seed e Tsinghua University addestra con reinforcement learning un sistema dedicato al lavoro CUDA e pubblica un dataset di 6,000 esempi, una skill per agenti di coding e una directory di lavoro per l’agente.

Gli autori lo descrivono come il primo sistema addestrato con reinforcement learning per lo sviluppo CUDA. La loro valutazione su KernelBench riporta un tasso di superamento complessivo del 98.8%, prestazioni superiori a torch.compile nel 96.8% dei problemi e uno speedup medio geometrico di 2.11x rispetto a torch.compile. Sul Level 3 dichiarano un tasso di superamento del 94%, prestazioni superiori a torch.compile nel 90% dei casi e uno speedup medio geometrico di 1.52x. La pagina del progetto CUDA Agent descrive la configurazione del benchmark.

La configurazione è impegnativa: fino a 128,000 token di contesto, 150 turni di addestramento e 200 turni di valutazione. Per essere accettato, un candidato doveva superare torch.compile di oltre il 5%, passare il controllo di correttezza su cinque input, non modificare gli script protetti e operare senza recuperare informazioni dal web. Questi vincoli rendono il risultato pubblicato più informativo di una demo priva di protezioni.

L’ostacolo all’acquisto è concreto. Né il sito del progetto né il repository pubblico indicano pesi del modello scaricabili o un endpoint gestito. Dataset e skill possono essere utili per costruire un sistema proprio, ma non equivalgono al prodotto addestrato descritto dal risultato principale. Finché il modello o il servizio effettivo non saranno disponibili, CUDA Agent resta un riferimento di ricerca, non un fornitore di ottimizzazione utilizzabile in produzione.

Ideale per: ricercatori che studiano addestramento degli agenti, traiettorie CUDA e valutazioni KernelBench

Punto di forza: configurazione di reinforcement learning pubblicata e solido risultato KernelBench dichiarato dagli autori

Prezzo: non in vendita; gli artefatti di ricerca pubblici sono disponibili, ma al 16 agosto 2026 non risulta un piano commerciale

Prova gratuita: non applicabile

CUDA Agent va tenuto nella lista di osservazione tecnica e la disciplina della sua valutazione dovrebbe diventare uno standard con cui giudicare altre affermazioni. Non va invece inserito in una comparazione d’acquisto come se il modello descritto fosse oggi disponibile per un team. È questa la differenza tra citare il limite superiore della ricerca e inventare un prodotto.

Quale strumento scegliere per ogni scenario

Scegliere AKO se si lavora su NVIDIA, si può usare Claude Code e si desidera la combinazione più solida di infrastruttura di campagna e audit tra quelle dichiarate. È particolarmente convincente in presenza di una famiglia di kernel importanti, più round di ottimizzazione e risparmi potenziali sufficienti a giustificare la conservazione delle traiettorie tra le esecuzioni.

Scegliere KernelAgent se il team lavora principalmente in PyTorch e vuole che la mossa successiva dell’ottimizzatore derivi dalle metriche NCU e dalla classificazione roofline. È la scelta più naturale per attività supportate su NVIDIA o Intel XPU quando gli ingegneri vogliono capire il collo di bottiglia hardware, non limitarsi ad accettare un candidato più veloce.

Scegliere AutoKernel se serve un primo passo operativo più contenuto: collegare un agente di coding già disponibile, profilare il modello ed eseguire durante la notte una sequenza fissa di esperimenti. È anche l’opzione intermedia più flessibile quando Codex è importante o quando un target AMD Instinct elencato rende poco adatti AKO o KernelAgent.

Scegliere Apex se il carico gira su hardware AMD Instinct supportato e il collo di bottiglia si trova in un percorso modificabile di aiter, vLLM, SGLang o HIP. Su AMD, questa compatibilità hardware pesa più delle prove pubblicate più ampie di AKO.

Scegliere CUDA Agent soltanto per ricerca, pianificazione della replica o progettazione della valutazione, almeno finché non saranno disponibili i pesi del modello addestrato o un endpoint gestito.

La sequenza esplicita è: prima l’hardware, poi la superficie di integrazione, quindi il verificatore e infine il benchmark. Il nome del modello viene dopo. Se due sistemi superano questi filtri, va preferito quello che rende visibili denominatore, intervalli dei fallimenti e risultato end-to-end. Un miglioramento più contenuto ma comparabile vale più di un numero spettacolare riferito alla baseline sbagliata.

Per scegliere il livello di orchestrazione più ampio intorno a un harness specializzato, il confronto tra piattaforme per agenti AI analizza i relativi compromessi. È bene mantenere quella decisione separata dal ciclo del kernel.

Il costo reale: partire con un progetto pilota da $299.99 e pretendere un ritorno

Il prezzo open source è la voce meno importante. Una campagna reale somma tempo dell’acceleratore, accesso all’agente, overhead di compilazione e profiling e revisione da parte di specialisti.

Il prezzo pubblicato da Modal per una NVIDIA B200 era di $0.001736 al secondo, ossia $6.2496 all’ora, al momento della verifica del 16 agosto 2026. Il piano Starter costa $0 al mese più il calcolo, include un credito di calcolo mensile di $30 e tre postazioni. Team costa $250 al mese più il calcolo, include un credito mensile di $100 e postazioni illimitate. Enterprise indica prezzi di calcolo personalizzati. Modal pubblica le tariffe correnti.

Di conseguenza, 32 ore su B200 costano $199.99. Aggiungendo un piano agente da $100, il budget della prima campagna arriva a $299.99 prima del lavoro degli ingegneri. Il tetto è intenzionalmente abbastanza basso da interrompere un’idea debole e abbastanza alto da superare una semplice demo.

Le attuali formule di accesso agli agenti offrono diversi riferimenti per il budget. ChatGPT Plus costa $20 al mese. ChatGPT Pro propone un’opzione da $100 con un utilizzo pari a 5x Plus e una da $200 con utilizzo 20x Plus; entrambe includono Codex. Claude offre un piano Free da $0, Claude Pro a $17 al mese con fatturazione annuale e pagamento anticipato di $200 oppure a $20 con fatturazione mensile, e Max a $100 per 5x o $200 per 20x. Claude Pro include Claude Code. I dati sono stati verificati il 16 agosto 2026 tramite le informazioni su Plus di OpenAI, le informazioni su Pro di OpenAI, la pagina dei prezzi di Anthropic e la guida ai piani di Anthropic. La fatturazione API può essere diversa, quindi il costo dei token del modello va tenuto separato dal calcolo GPU; la guida alle API AI più economiche approfondisce questo livello.

Ora bisogna confrontare il progetto pilota con una fattura di produzione. Una B200 in funzione per 720 ore al prezzo di listino attuale costa $4,499.71. Se il kernel obiettivo assorbe il 25% del carico e diventa 2x più veloce, l’intero workload risparmia il 12.5%, pari a $562.46 al mese. Il progetto pilota da $299.99 si ripaga in circa 16 giorni.

Se il kernel occupa soltanto il 5%, lo stesso miglioramento di 2x fa risparmiare il 2.5%, cioè $112.49 al mese. Il tempo di ritorno sale a circa 80 giorni. Il risultato di ottimizzazione è identico; quello economico no.

Il calcolo è volutamente prudente sotto un aspetto e incompleto sotto un altro. Usa il tempo dell’acceleratore al prezzo di listino come base del risparmio, ma non comprende ore degli ingegneri, variabilità dei token del modello, overhead di compilazione, sconti sulla capacità riservata o variazioni di utilizzo. Prima di approvare una campagna più lunga, ogni dato va sostituito con quello della fattura effettiva.

Come sono stati scelti questi ottimizzatori AI per GPU

Questo è un confronto basato su documentazione e prove aggiornate, non l’affermazione che tutti e cinque i sistemi siano stati installati e testati su hardware identico. Per questo il titolo parla di strumenti a confronto, non testati. Ogni sistema incluso doveva offrire un agente o un harness concreto per lavorare sui kernel GPU, una descrizione pubblica ufficiale e dettagli implementativi sufficienti a capire a chi serve e dove si ferma.

La classifica usa sei criteri:

• Possibilità di adozione: uno sviluppatore può ottenere ed eseguire oggi il sistema pertinente?
• Compatibilità hardware: supporta esplicitamente l’acceleratore e lo stack software obiettivo?
• Severità dei controlli di correttezza: l’harness contrasta risposte memorizzate, test modificati, shape troppo ristrette e tolleranze permissive?
• Denominatore del benchmark: la baseline è indicata e sono visibili fallimenti o casi invariati?
• Validazione end-to-end: dopo il miglioramento del kernel isolato, il workflow torna al modello o servizio effettivo?
• Chiarezza dei costi: è possibile delimitare il budget di GPU e agente per la prima campagna?

La classifica non calcola una media dei moltiplicatori dichiarati dai fornitori. Premia la qualità delle prove, l’adeguatezza operativa e la probabilità di trasformare un benchmark locale in un risparmio di produzione verificato. Per questo i risultati di AKO compresi tra 1.14x e 1.43x su un portafoglio ampio possono contare più di un numero isolato molto superiore, mentre il risultato KernelBench di CUDA Agent pari a 2.11x non compensa l’assenza di un modello distribuibile.

Nessun partner presente nel bacino commerciale attivo del sito è pertinente all’ottimizzazione dei kernel GPU. Inserire qui uno strumento per telefonia, CRM, formazione, contabilità o siti web renderebbe la pagina meno affidabile. La selezione non include quindi posizionamenti affiliati e classifica esclusivamente i sistemi rilevanti.

Gli strumenti e gli usi da evitare

Evitare KernelAgent per AMD ROCm. L’elenco di supporto attuale comprende NVIDIA CUDA e Intel XPU, non AMD ROCm. Un progetto guidato dal profiler non può compensare un runtime non supportato.

Evitare AMD-AGI Apex per attività NVIDIA. Apex trattato qui è progettato per ROCm e AMD Instinct. Inoltre, non è NVIDIA Apex, il diverso progetto per mixed precision e addestramento distribuito. Prima di assegnare tempo degli ingegneri, va identificato il prodotto corretto.

Evitare CUDA Agent come acquisto gestito per la produzione. Dataset, skill e artefatti di lavoro sono pubblici, ma non risultano disponibili i pesi addestrati né un endpoint. Va studiato, non inserito a budget come se fosse un servizio esistente.

Evitare AKO quando Claude Code non è una dipendenza approvata. L’harness attuale di AKO è prezioso proprio perché impone vincoli a un agente esistente, ma quella compatibilità resta una dipendenza di acquisto e sicurezza.

Evitare AutoKernel quando la decisione richiede un benchmark aggregato indipendente prima ancora del progetto pilota. Il materiale pubblico spiega bene il ciclo e i target supportati, ma non fornisce un risultato aggregato indipendente e aggiornato per tutti quei target. In tal caso occorre eseguire il progetto pilota delimitato o scegliere un sistema con prove più vicine al requisito.

Soprattutto, vanno evitate sessioni nude di Claude Code o Codex presentate come un ottimizzatore completo. Entrambi possono scrivere e rivedere kernel, e AutoKernel o Apex possono orchestrarli, ma il prodotto vero è ciò che li circonda: profiler, riferimento immutabile, test di correttezza, misurazione del benchmark, logica di conservazione o ripristino e controllo di distribuzione. Senza questo harness, l’agente è un autore di kernel entusiasta che corregge da solo il proprio esame.

Domande frequenti

Codex può ottimizzare kernel CUDA e Triton?

Sì. AutoKernel funziona esplicitamente con Codex per ottimizzare Triton o CUDA C++, mentre Apex può orchestrare Codex su attività AMD ROCm supportate. Codex da solo non è un sistema di ottimizzazione completo: servono un profiler, un harness di correttezza protetto, un benchmark e un ciclo di conservazione o ripristino.

KernelAgent è migliore di AutoKernel?

KernelAgent è migliore quando hanno priorità un ciclo nativo PyTorch, le metriche NCU e il tuning per NVIDIA o Intel XPU guidato dal roofline. AutoKernel è preferibile per un ciclo notturno più semplice, una scelta più ampia di agenti o i target NVIDIA e AMD Instinct che dichiara di supportare.

Apex ottimizza le GPU NVIDIA?

No. AMD-AGI Apex è un ottimizzatore ROCm per hardware AMD Instinct supportato. Non va confuso con NVIDIA Apex, che è un progetto diverso e non coincide con l’ottimizzatore agentico qui classificato.

Qual è il miglior agente AI per l’ottimizzazione delle GPU AMD?

Apex è la prima scelta dedicata per un carico AMD Instinct supportato che rientra nella sua superficie di integrazione modificabile. AutoKernel versione 1.3 è l’alternativa più ampia per MI300X, MI325X, MI350X e MI355X.

Come si confrontano correttamente i punteggi KernelBench?

Ogni punteggio deve essere accompagnato da hardware, livello dell’attività, baseline, definizione di superamento, input per la correttezza e metodo della media geometrica. Un risultato rispetto a torch.compile non è intercambiabile con uno rispetto a un’implementazione esperta o a una baseline approssimativa da competizione.

Un agente per kernel GPU conviene a un piccolo team?

Può convenire, se il profiling dimostra che un singolo kernel assorbe una quota sufficiente di una spesa ricorrente per acceleratori. Va usato il progetto pilota da $299.99 insieme alla soglia di ritorno del kernel critico, fermandosi quando il risparmio end-to-end misurato non può ripagare il lavoro entro la finestra stabilita.

L’azione da compiere lunedì

Non occorre installare tutti e cinque i sistemi. Lunedì mattina va profilato un carico di produzione rappresentativo e annotata la quota del tempo totale occupata dal kernel più critico. Poi si sceglie un solo percorso: AKO per una campagna NVIDIA sottoposta ad audit, KernelAgent per un ciclo PyTorch guidato dai contatori hardware, AutoKernel per una ricerca notturna più leggera oppure Apex per AMD ROCm supportato.

Il primo esperimento va limitato a 32 ore su B200 più un piano agente da $100, o all’equivalente sull’hardware effettivo. L’implementazione di riferimento e il benchmark vanno congelati. Occorre aggiungere controlli di correttezza con valori nuovi. Infine, il kernel vincente deve superare le prove fuori dal ciclo dell’agente e migliorare l’intero carico, non soltanto il proprio microbenchmark.

La regola per il rilascio sta in una frase: senza un ritorno end-to-end misurato, non si avvia una seconda campagna.