Riepilogo Tecnico: Concordia: JIT-Compiled Persistent-Kernel Checkpointing per l'Inferenza di LLM Fault-Tolerant

1. Problematica

Gli agenti LLM (Large Language Model) a lunga esecuzione mantengono uno stato sostanziale sulle GPU, inclusi KV cache, scheduler delle richieste, stati di comunicazione e adapter online. A differenza dell'inferenza stateless tradizionale, questi carichi di lavoro accumulano minuti o ore di computazione. Un guasto in un rank GPU, in un comunicatore o in un kernel applicativo può distruggere questo stato, rendendo la sessione irrecuperabile senza riavviare l'intero stack di servizio, ricaricare i pesi del modello e riprodurre le chiamate agli strumenti (tool calls) — un processo che è spesso semanticamente impossibile una volta avvenute interazioni esterne.

I meccanismi di recupero esistenti affrontano un compromesso fondamentale:

• Logging specifico per l'applicazione: Richiede la modifica di ogni kernel di attenzione, allocatore e libreria per registrare esplicitamente gli aggiornamenti KV. Questo è fragile negli stack moderni che coinvolgono librerie fuse (fused), kernel vendor e compilatori di grafi dinamici.
• Checkpointing mediato dall'host: Si affida alla CPU per lanciare kernel di checkpoint o scansionare la memoria GPU. Ciò introduce un'elevata latenza dovuta ai trasferimenti PCIe e ai confronti di pagina lato CPU, e pone l'host sul percorso critico durante il recupero, impedendo alla GPU di eseguire mentre l'host orchestra il ripristino.

Il paper sostiene che la fault tolerance per questi carichi di lavoro richieda un contesto di esecuzione residente sulla GPU capace di osservare i kernel binari, eseguire il rilevamento delle pagine sporche (dirty-page detection) alla larghezza di banda HBM ed eseguire la logica di recupero senza l'intervento dell'host.

2. Metodologia: Il Runtime Concordia

Concordia è un sistema di runtime progettato per interporre un intervento sul caricamento dei moduli GPU e fornire un substrato persistente e residente sul dispositivo per la fault tolerance. La sua architettura si compone di quattro meccani principali:

2.1 Persistent Kernel Executor

La base di Concordia è un kernel persistente che viene eseguito per l'intera durata di una sessione LLM.

• Operatività: Monitora continuamente un ring buffer lock-free in memoria mappata dall'host.
• Task: Esegue compiti di calcolo, checkpoint, comunicazione e recupero senza richiedere nuovi lancia_menti di kernel CUDA da parte dell'host.
• Impronta di risorse: Riserva un numero minimo di Streaming Multiprocessors (SM) (ad es., 1 block su RTX PRO 6000, ~0,53% di impronta SM), lasciando il resto della GPU disponibile per i kernel applicativi.
• Percorso di controllo: Agisce come un ciclo di controllo fidato. Se i kernel applicativi o i comunicatori falliscono, il worker persistente rimane vivo per orchestrare il recupero finché il dispositivo non viene dichiarato perso.

2.2 Strumentazione PTX/SASS e Compilazione JIT

Concordia strumenta i binari GPU per esporre punti di checkpoint sicuri e generare handler specializzati.

• Strumentazione: Intercetta le chiamate cuModuleLoad. Per i moduli PTX, riscrive il codice per inserire hook di pausa cooperativa e checkpoint in ingresso, uscita e nei siti di barriera. Per i kernel solo binari (SASS), applica una patch conservativa per reindirizzare l'esecuzione attraverso stub di trampolino (trampoline stubs).
• Handler JIT-compilati: Per ogni regione di memoria registrata (ad es., blocchi PagedAttention KV, adapter LoRA, buffer opachi), Concordia compila JIT un handler di delta-checkpoint specializzato.
  • Regioni KV: Gli handler scansionano le tabelle dei blocchi fisici e i bitmap di dirty-page forniti dal runtime di serving.
  • Regioni Adapter/Op: Gli handler eseguono una scansione densa delle pagine o un confronto shadow contro copie residenti sulla GPU.
• Hot-Swapping: Questi handler sono compilati tramite NVRTC e inseriti nella tabella degli operatori del kernel persistente, permettendo aggiornamenti dinamici senza interruzione del servizio.

2.3 Delta Checkpointing lato GPU

Invece di snapshot completi, Concordia esegue il delta checkpointing direttamente sulla GPU.

• Processo: Ai confini dei kernel o delle collettività NCCL, il kernel persistente esegue l'handler JIT-compilato per identificare le pagine sporche alla larghezza di banda HBM (~1,8 TB/s).
• Logging: Solo le pagine sporche e i metadati vengono aggiunti a un log di tipo Append-Only File (AOF) memorizzato in memoria CXL visibile alla CPU o in DRAM dell'host.
• Sfruttamento della struttura: Il sistema sfrutta la struttura dello stato degli LLM: i pesi base sono statici (immutabili), mentre i KV cache e gli adapter cambiano in modo sparso. Ciò consente al sistema di evitare la registrazione di ogni aggiornamento e di rilevare invece i cambiamenti in modo efficiente.

2.4 Recupero e Fault Tolerance

• Modello Fail-Stop: Concordia assume che i kernel applicativi o i comunicatori possano fallire, ma il worker persistente è considerato fidato. Se il battito cardiaco (heartbeat) del worker si interrompe, la GPU è considerata persa.
• Flusso di recupero: In caso di guasto, una GPU sostitutiva (o lo stesso dispositivo dopo un reset) carica l'ultimo snapshot base committato e riproduce il log AOF da CXL/DRAM.
• Integrazione NCCL: Un wrapper NCCL potenziato intercetta le operazioni collettive per identificare confini sicuri. In caso di guasto, passa a un ring di fallback pre-calcolato o attiva un dispositivo sostitutivo, ricostruendo il DAG del comunicatore senza una riinizializzazione completa di NCCL.
• Cross-Architettura (Opzionale): Per il recupero tra diverse architetture GPU, Concordia può normalizzare il codice strumentato in una rappresentazione intermedia portabile (CTX) e abbassarlo (lower) verso l'ISA target, sebbene questa sia un'estensione opzionale.

3. Contributi Chiave

1. Substrato a Kernel Persistente: Il paper identifica la necessità di un esecutore residente sul dispositivo per abilitare una fault tolerance trasparente, evitando la latenza e le dipendenze sul percorso critico del checkpointing mediato dall'host.
2. Contratto di Recupero Unificato: Concordia combina la strumentazione PTX/SASS, un esecutore persistente lock-free, handler delta JIT-compilati lato GPU e il logging append-only in CXL/DRAM in un unico sistema.
3. Delta Checkpointing Consapevole della Struttura: Il sistema sfrutta la struttura dell'inferenza LLM (pesi statici, aggiornamenti KV sparsi) per eseguire il rilevamento delle pagine sporche interamente sulla GPU alla larghezza di banda HBM, eliminando la necessità di logging KV specifico per l'applicazione.
4. Valutazione delle Prestazioni: Il sistema è valutato su GPU Blackwell e target eterogenei, dimostrando velocità significative nel checkpointing e tempi di recupero nell'ordine dei sub-secondi.

4. Risultati Sperimentali

La valutazione è stata condotta su GPU NVIDIA RTX PRO 6000 (Blackwell) e RTX 5090, utilizzando PyTorch 2.10.0 e NCCL 2.27.5.

• Velocità di Checkpointing: Il delta checkpointing lato GPU è da 85× a 219× più veloce della scansione trasparente delle pagine lato CPU.
  • Per una regione di 256 MB con una pagina sporca, il diff lato CPU ha richiesto ~111 ms (dominato dalla scansione CPU), mentre il lato GPU ha richiesto ~0,56 ms (dominato dalla larghezza di banda HBM).
  • Il miglioramento di velocità scala con la dimensione della regione perché il diff della CPU scala con la dimensione totale della regione, mentre il diff della GPU scala con la dimensione dei dati sporchi.
• Latenza di Trigger: L'invio di un task di checkpoint tramite il ring buffer persistente richiede <0,1 µs, rispetto ai 7,6 µs di un cudaLaunchKernel sincrono. Ciò elimina l'overhead di lancio dell'host ad ogni confine di checkpoint.
• Overhead di Risorse: Il kernel persistente occupa solo lo 0,53% degli SM (1 block su 188), significativamente inferiore agli approcci esistenti di persistent thread come CLC (5–10%) o Green Contexts (3–8%).
• Throughput di Inferenza: Nell'inferenza di Qwen3-0.6B, l'overhead di checkpoint era di 18,9 ms per confine (meno del 4% del tempo di generazione), con il sistema che manteneva 108,2 token/sec.
• Recupero da Guasto: Un prototipo di recupero da guasto su due GPU ha ripristinato il servizio in ~1,5 secondi (10 ms di rilevamento + 300 ms di isolamento + 800 ms di ripristino dello stato + 400 ms di reintegrazione). Ciò contrasta con i 47+ secondi richiesti per un normale riavvio di NCCL e il ricaricamento del modello.
• Fine-Tuning LoRA: Il sistema ha gestito efficacemente l'adattamento online, rilevando solo le pagine dell'adapter mutabili (1,75% del totale delle pagine) e ottenendo un'accelerazione di 299× rispetto al delta checkpointing lato CPU per l'intero modello.

5. Significato e Claim

Il paper sostiene che Concordia fornisca un substrato necessario per l'inferenza LLM a lunga esecuzione fault-tolerant spostando il ciclo di controllo del recupero dall'host al dispositivo.

• Claim Modesti sulle Prestazioni Statiche: Gli autori dichiarano esplicitamente che per benchmark di decode statici e a singolo modello, i CUDA Graph accuratamente ingegnerizzati potrebbero ancora superare l'esecuzione eager. Concordia non è presentata come un sostituto di CUDA Graphs, ma come uno strato complementare che opera sotto i confini del framework per gestire carichi di lavoro dinamici e fault tolerance.
• Trasparenza: Il sistema mira a binari GPU non modificati o parzialmente modificati, coprendo kernel generati dal framework e librerie vendor dove il logging a livello applicativo è impraticabile.
• Modello di Recupero: La significatività risiede nel rendere possibile un modello di riproduzione AOF stile Redis per gli LLM, separando la durabilità dalla scarsa capacità HBM e permettendo il recupero senza ricostruire i comunicatori o ricaricare i pesi.
• Limitazioni: Il sistema assume che il worker persistente non fallisca indipendentemente (non gestisce i guasti bizantini) e richiede il checkpointing cooperativo nei punti di barriera per la migrazione cross-architettura. Nota inoltre che le regioni mutabili opache richiedono comunque copie shadow residenti sulla GPU, consumando HBM.

In sintamente, Concordia dimostra che mantenendo un contesto di esecuzione persistente e strumentato sulla GPU, è possibile ottenere una fault tolerance trasparente e ad alte prestazioni per l'inferenza LLM, riducendo i tempi di recupero da minuti a secondi ed eliminando la CPU dell'host dal percorso critico.