Riepilogo Tecnico: Arbor – Ricerca ad Albero come Strato Cognitivo per Agenti Autonomi

Definizione del Problema

I recenti progressi nell'ottimizzazione del codice basata su Large Language Model (LLM) hanno dimostrato che gli agenti autonomi possono scoprire soluzioni di alta qualità per target computazionali isolati (ad esempio, singoli kernel o operatori specifici). Tuttavia, le prestazioni del software in produzione derivano dall'interazione complessa di più livelli (applicazione, framework, compilatore, kernel, hardware). L'ottimizzazione di uno strato spesso espone colli di bottiglia o regressioni in un altro, creando uno spazio di azione stato-dipendente e di grandi dimensioni dove gli interventi possono invalidare i progressi precedenti.

Gli approoli esistenti affrontano tre limitazioni primarie:

1. Ambito Isolato: Gli autotuner dei compilatori e i framework multi-agente operano tipicamente all'interno di un singolo livello o su un singolo target, fallendo nel gestire le dipendenze cross-layer.
2. Mancanza di Memoria Stateful: I sistemi attuali non mantengono una memoria di lavoro condivisa che evolva con ogni misurazione, trattando i fallimenti solo come segnali di arresto piuttosto che come dati diagnostici.
3. Incapacità di Gestire Fallimenti a Cascata: Quando un'ottimizzazione causa un crash del sistema o una regressione, i sistemi esistenti mancano del meccanismo per diagnosticare la causa radice, propagare i vincoli alla ricerca e rimodellare l'esplorazione successiva.

La sfida principale si sposta dalla generazione di candidati alla selezione dei candidati: navigare in un panorama dinamico dove ogni intervento rimodella la distribuzione dei colli di bottiglia, richiedendo un sistema in grado di rilevare spostamenti, diagnosticare fallimenti attraverso i vari livelli ed espandere autonomamente il fronte di ricerca.

Metodologia: Il Framework Arbor

Arbor formula l'ottimizzazione full-stack come una ricerca ad albero con punteggio euristico su uno spazio di azione in espansione dinamica. Introduce uno strato cognitivo che mantiene un albero di ricerca esplicito che funge da memoria di lavoro condivisa tra gli agenti.

1. Procedura di Ricerca e Gestione dello Stato

• Struttura dell'Albero: Lo stato di ottimizzazione è un albero $T = (V, E)$ con radice in un profilo di base (baseline). Ogni nodo rappresenta un'azione e il suo esito (mantenuto, revertito o crashato). Il percorso dalla radice al nodo definisce la sequenza cumulativa degli interventi.
• Espansione Dinamica: L'albero non è statico. Dopo un'azione riuscita, il sistema ri-profila per rivelare colli di bottiglia precedentemente invisibili, generando nuovi rami che non esistevano all'inizializzazione.
• Ciclo di Ricerca: L'Orchestratore esegue un ciclo depth-first:
  1. Profila lo stato corrente per identificare colli di bottiglia e quote temporali della GPU.
  2. Valuta i candidati tramite una funzione euristica.
  3. Invia l'azione con il punteggio più alto a uno Specialista di Dominio.
  4. Filtra i risultati attraverso la verifica dell'accuratezza e il benchmarking end-to-end.
  5. Aggiorna l'albero: le azioni mantenute diventano la nuova baseline; le azioni revertite registrano annotazioni diagnostiche; le azioni che causano crash attivano l'analisi della causa radice (RCA).
  6. Ricalcola il punteggio dei candidati rimanenti man mano che la distribuzione dei colli di bottiglia cambia.

2. Punteggio Euristico

I candidati sono valutati bilanciando il guadagno atteso rispetto al costo e al rischio, incorporando un bonus di esplorazione:
$$h(a) = \frac{g(a)}{c(a) \cdot (1 - r_{acc}) \cdot (1 - r_{crash}) \cdot m_{gap}} + C_s \frac{\ln N}{1 + n_{cat}}$$

• $g(a)$: Guadagno atteso, stimato dalla quota di tempo GPU del target kernel e dai priori di velocità specifici per categoria (derivati da una base di conoscenza persistente).
• $c(a)$: Costo stimato in termini di tempo di esecuzione (implementazione, riavvio, benchmarking).
• $r_{acc}, r_{crash}$: Tassi di fallimento empirici per accuratezza e crash, raffinati con il progredire della campagna.
• $m_{gap}$: Moltiplicatore di urgenza che scala con il gap rimanente rispetto al target di throughput.
• Termine UCB: Incoraggia l'esplorazione di categorie di azioni sotto-campionate.

3. Architettura Multi-Agente con Controlli e Contrappesi

Arbor struttura i suoi agenti per imitare organizzazioni ingegneristiche efficaci, scomponendo le capacità in Hard Skills (competenza di dominio) e Soft Skills (protocolli di coordinamento).

• L'Orchestratore (Il "Tech Lead"):

  • Guida il ciclo di ottimizzazione tramite profiling, scoring e delega.
  • Costruisce dinamicamente Specialisti di Dominio a runtime per compiti specifici (kernel, framework, comunicazione, compilatore, dispatch).
  • Compone i prompt utilizzando il contesto hardware, le voci della base di conoscenza e le cronologie dei fallimenti.
  • Non implementa il codice in sé, ma decide cosa provare e chi implementarlo.

• Il Critico (Il "Quality Assurance"):

  • Salvaguarda la stabilità e l'integrità delle misurazioni.
  • Esegue l'Analisi della Causa Radice (RCA) sui crash, distinguendo tra errori di implementazione e direzioni improduttive.
  • Applica Guardrail per rilevare anomalie nei benchmark.
  • Conduce l'Introspezione per valutare se un'idea revertita mantenga il proprio merito sotto diversi vincoli.
  • Monitora la salute del sistema a lungo termine, pubblicando vincoli per evitare di tornare in regioni improduttive.

• Specialisti di Dominio:

  • Costruiti dinamicamente per ogni task.
  • Operano in modo asincrono attraverso i vari livelli, eseguendo un raffinamento iterativo con validazione locale prima di restituire patch pronte per il merge.
  • Rispettano i vincoli pubblicati dal Critico.

• Base di Conoscenza Persistente:

  • Accumula strategie e modalità di fallimento attraverso le sessioni.
  • Permette il transfer di warm-start a nuovi modelli e hardware, informando i priori di scoring e riducendo la varianza tra le esecuzioni.

Contributi Chiave

1. Formulazione della Ricerca ad Albero Stateful: Il paper formula l'ottimizzazione cross-layer come una ricerca ad albero dove l'albero funge da memoria di lavoro condivisa. I fallimenti si propagano come vincoli sui nodi figli, e i successi innescano il ri-profiling per espandere il fronte di ricerca.
2. Architettura Multi-Agente con Controlli e Contrappesi: Introduce un sistema a due agenti dove un Orchestratore guida l'ottimizzazione aggressiva mentre un Critico salvaguarda la stabilità. Nessun agente può guidare unilateralmente il sistema, garantendo che i sacrifici di throughput a breve termine siano fatti solo quando necessari per la vitalità della sessione.
3. Scomposizione delle Competenze: Scompone le capacità degli agenti in hard skills (competenza di dominio) e soft skills (protocolli di coordinamento), supportate da una base di conoscenza persistente per il trasferimento tra le sessioni.
4. Costruzione Dinamica di Specialisti: Si allontana dagli agenti fissi, costruendo Specialisti di Dominio dinamicamente a runtime in base al target di ottimizzazione specifico, al contesto hardware e ai dati storici.

Risultati

Arbor è stato valutato sull'inferenza di modelli LLM su sei modelli di produzione su GPU AMD Instinct (MI355X e MI300X).

• Miglioramenti del Throughput:
  • Su MI355X, Arbor ha ottenuto un miglioramento del throughput compreso tra +40% e +193% rispetto alle baseline ottimizzate dal vendor dopo giorni di operatività totalmente autonoma.
  • Su MI300X (validazione cross-generazionale), i miglioramenti sono variati tra +62% e +99%.
• Riproducibilità: La varianza tra le esecuzioni era entro i 2 punti percentuali, dimostrando una riproducibilità indipendente dall'hardware.
• Ablation/Comparazione: Un singolo agente senza l'harness di Arbor (l'harness essendo il framework di ricerca ad albero multi-agente) si è stabilizzato a soli +33% di miglioramento del throughput e ha subito un crash irreparabile entro poche ore.
• Case Study (gpt-oss-120b): In un albero di ricerca specifico per un modello MoE da 120B, il sistema ha esplorato 30 azioni. 9 sono state mantenute, 16 sono state revertite con insight diagnostici e 3 hanno causato crash ma sono state recuperate tramite RCA. Il sistema ha raggiunto 6.515 tok/s/GPU (un miglioramento del 48% rispetto alla baseline di 4.405 tok/s/GPU), utilizzando insight dall'introspezione (ad esempio, identificando percorsi di codice morto) e dalla RCA (classificando i crash come problemi di dipendenza piuttosto che difetti algoritmici).

Significato e Claim

Il paper sostiene che Arbor rappresenti un cambiamento nell'ottimizzazione autonoma: dal passaggio dalla generazione di candidati isolati alla navigazione di spazi di azione ampi e stateful. Trattando i fallimenti come segnali diagnostici che rimodellano l'esplorazione e mantenendo una memoria di lavoro condivisa, Arbor consente campagne multi-giorno completamente autonome che sarebbero altrimenti impossibili a causa dell'instabilità del sistema.

Il framework dimostra che:

1. L'ottimizzazione cross-layer è fattibile senza intervento umano, a condizione che il sistema possa rilevare gli spostamenti dei colli di bottiglia e diagnosticare i fallimenti attraverso lo stack.
2. Le architetture con controlli e contrappesi sono critiche per l'autonomia sostenuta, impedendo all'esplorazione aggressiva di destabilizzare il sistema.
3. Il trasferimento della conoscenza tra le sessioni e le generazioni hardware è realizzabile attraverso la memoria persistente, abbassando la barriera per l'implementazione di nuovo hardware o modelli.

In definitiva, Arbor mira a ridurre il costo operativo e l'intensità di carbonio delle implementazioni LLM automatizzando l'impegno coordinato che tradizionalmente richiede team di ingegneria attraverso l'intero stack software e hardware.