Riepilogo Tecnico: Contratti tra Kernel di Training e Inferenza

Definizione del Problema

Le moderne pipeline di post-training per i Large Language Models (LLM) trattano la policy $\pi_\theta$ come un singolo oggetto matematico. Tuttavia, in precisione finita, $\pi_\theta$ è valutata da due programmi distinti: un kernel di training ($K_{train}$) ottimizzato per la differenziabilità (utilizzando accumulatori ad alta precisione, forme fisse e attention di riferimento) e un kernel di inferenza ($K_{inf}$) ottimizzato per il throughput (utilizzando operatori a bassa precisione, cache key-value paginate e tile di attention dinamiche).

Il documento identifica una critica "lacuna di specifica": questi due kernel calcolano funzioni misurabilmente diverse della stessa matrice di pesi $\theta$. Questa divergenza non è uniforme; si concentra su slice specifiche (ad es., input a lungo contesto, prompt critici per la sicurezza) che i benchmark aggregati tendono a sottorappresentare. La conflazione di $K_{train}$ e $K_{inf}$ porta a diversi modi di fallimento:

1. Bias off-policy nel RL: Le pipeline di reinforcement learning (ad es, PPO, GRPO) campionano rollout da $K_{inf}$ ma calcolano i gradienti usando $K_{train}$. Lo stimatore standard assume che il rapporto di importanza $w = \pi^{K_{train}}_\theta / \pi^{K_{inf}}_\theta$ sia 1, introducendo un bias che si manifesta come collasso della KL, reward hacking o improvido degrado delle prestazioni.
2. Drift di Deployment: I modelli sottoposti a fine-tuning in BF16 possono subire un drift significativo quando convertiti in FP8 o INT4 durante l'inferenza, particolarmente su prompt di sicurezza rari o output strutturati.
3. Non-riproducibilità: Fleet di serving eterogenei (diversi hardware/build di kernel) producono output divergenti per la stessa richiesta, rendendo i test A/B e gli audit di sicurezza non riproducibili.

Attualmente, non esiste una specifica leggibile dalle macchine che definisca quale livello di divergenza tra $K_{train}$ e $K_{inf}$ sia tollerabile, su quali slice di dati, e quali azioni intraprendere quando i limiti vengono superati.

Metodologia: Il Contratto del Kernel

Gli autori propongono un oggetto di specifica formale chiamato Contratto del Kernel, denotato come $C = (N, S, R, \Pi)$. Questo contratto viaggia con il checkpoint del modello e la build del kernel attraverso la pipeline CI/CD.

1. Struttura del Contratto

Il contratto consiste di quattro famiglie di clausole e una politica di escalation:

• Numeriche ($N$): Vincoli sui disaccordi numerici grezzi, come il drift dei logit ($\Delta_{logit}$), la divergenza KL, la distanza di Variazione Totale (TV) e il rapporto di importanza $w$ per il RL.
• Statistiche ($S$): Vincoli sugli esiti comportamentali, inclusi l'accordo top-$k$ dei token, il drift di calibrazione ($\Delta_{ECE}$), i delta di reward e la parsabilità degli output strutturati.
• Runtime ($R$): Vincoli operativi su latenza, throughput, uso della memoria (inclusa la cache KV) e tassi di errore.
• Osservabilità ($O$): Requisiti per campi di traccia, fingerprint del kernel e firme di replay per garantire che le violazioni siano attribuibili.
• Politica di Escalation ($\Pi$): Una mappatura dai livelli di severità della violazione ($L1$: informativo, $L2$: impatto sulla qualità, $L3$: criticità per la sicurezza) ad azioni di routing (log, guardia, fallback/rollback).

Le clausole sono definite con soglie ($\tau$), tassi di eccedenza ammessi ($\rho$) e specifiche slice di dati ($\Sigma$) a cui si applicano.

2. Limiti Teorici (La Catena)

Il documento deriva una catena di limiti di tipo Lipschitz che connette errori numerici di basso livello a errori di reward di alto livello:

1. Da Logit a Distribuzione: Un limite sul drift dei logit ($\|\varepsilon\|_\infty$) si propaga a un limite sulla distanza di Variazione Totale ($\Delta_{TV}$) e sulla divergenza KL, scalato per temperatura $T$.
2. Da Distribuzione a Reward: Per una funzione di reward $r$ limitata, la differenza di reward attesa è limitata da $2R \cdot \Delta_{TV}$.
3. Applicazione al RL: Sotto l'assunto di sovrapposizione del supporto e di advantage limitato, il documento dimostra che un limite per token del rapporto di importanza $w$ (o equivalentemente, la distanza TV tra le policy $K_{train}$ e $K_{inf}$) limita il bias dello stimatore standard del gradiente della policy. Questo reinterpreta il parametro di clipping $\epsilon$ di PPO non solo come una regione di fiducia per gli aggiornamenti della policy, ma come un budget per la coppia di kernel train-infer.

3. Pipeline di Enforcement

Il framework propone una pipeline di promozione a quattro stadi per far rispettare il contratto:

1. CI Offline: Valuta le clausole numeriche rigide contro dataset fissi.
2. Shadow: Specchia il traffico live verso il candidato kernel per rilevare regressioni dipendenti dal carico di lavoro.
3. Canary: Instrada una piccola frazione di traffico live verso il candidato con la politica di escalation attiva.
4. Promozione Completa: Avviene solo dopo una sostenuta conformità su una finestra di stabilità.

Un ciclo di routing online monitora continuamente la salute del contratto ($h_t$) e sposta il traffico verso kernel protetti o sicuri in base ai livelli di violazione in tempo reale.

Contributi Chiave

Il documento apporta tre contributi primari:

1. Concettuale: Identifica l'unità corretta di specifica nelle moderne pipeline di LLM non come il checkpoint o il motore da solo, ma come la coppia $(K_{train}, K_{inf})$ insieme alle specifiche slice di dati dove devono concordare.
2. Tecnico: Fornisce una catena di limiti che permette agli ingegneri di specificare vincoli al livello numerico misurabile (logit) ed ereditare garanzie al livello comportamentale (reward).
3. Applicativo: Dimostra che gli euristica standard di stabilità del RL (come il clipping di PPO) possono essere formalmente interpretate come clausole di contratto che limitano la divergenza dei kernel, e delinea un linguaggio DSL YAML minimale per implementare tali artefatti.

Risultati e Validazione

Il documento dichiara esplicitamente di non riportare una validazione empirica su scala di produzione e non sostiene che la divergenza del kernel sia l'unica causa dei modi di fallimento discussi. Invece, presenta un paper di framework e vocabolario.

I "risultati" sono derivazioni teoriche e un protocollo sperimentale proposto (Sezione 8) per la futura validazione:

• Teorico: Dimostrazioni che mostrano come i limiti del drift dei logit implichino i limiti del drift del reward e che il mismatch del kernel introduca un bias calcolabile nei gradienti della policy.
• Esperimenti Proposti: Gli autori delineano cinque esperimenti falsificabili (E1–E5) per testare il framework, inclusi la mappatura dei baseline di drift numerico, il test della sensibilità dell'hardware, la validazione del limite di bias del RL, l'esplorazione della distillazione consapevole del contratto e la simulazione di routing auto-rigenerante sotto iniezione di guasti.

Significato e Ambito

Il documento posiziona se stesso come uno strato di specifica fondamentale che colma diverse letteratura parallele: il post-training del RL, il serving ad alto throughput, la verifica formale e i contratti software.

• Modestia: Gli autori sono espliciti nel dichiarare che si tratta di un "paper di framework e vocabolario". Non pretendono di aver risolto empiricamente il problema della divergenza del kernel, ma di aver fornito l'"indice mancante" su $\pi_\theta$ e il vocabolario per discuterne.
• Direzioni Future: Il documento delinea quattro direzioni di ricerca: contratti dinamici (soglie dipendenti dal contesto), distillazione consapevole del contratto (addestrare modelli per soddisfare i contratti), verifica formale di subset di clausole e routing auto-rigenerante.
• Limitazioni: Il framework aggiunge overhead ingegneristico (computazione, storage, osservabilità) e comporta i rischi della legge di Goodhart (ottimizzazione di proxy clausole). Riconosce che gli strumenti di verifica formale attuali non possono ancora scalare alla piena produzione dei transformer, affidandosi invece a limiti ampi e test empirici.

In sintesi, il documento sostiene che trattare i kernel di training e di inferenza come entità distinte e legate da contratti è necessario per passare dalla "conoscenza empirica" sulla fragilità dell'implementazione a pratiche di ingegneria audite e riproducibili nella distribuzione di LLM.