Per risolvere questo problema, il team ha sviluppato un kernel CUDA personalizzato. Questo kernel impiega diverse strategie: utilizza tabelle di ricerca compatte a più livelli (per un totale di 1 kb) progettate per adattarsi all’interno di SRAM GPU su chip rapido; Utilizza un meccanismo a due fasi con dati ausiliari minimi per consentire ai thread paralleli di calcolare correttamente le loro posizioni di avvio nei dati compressi e delle posizioni di scrittura nel buffer di output; E elabora i pesi per un intero blocco di trasformatore per massimizzare la throughput. Il codice, integrato con la libreria di Transformers di abbracci, è open-source .
Tuttavia, questa decompressione al volo introduce un compromesso per le prestazioni. Rispetto all’esecuzione di un modello BF16 non compresso su hardware con memoria sufficiente, DFLOAT11 aggiunge latenza.
L’autore Tianyi Zhang ha fornito chiarimenti su Reddit, rilevando che per l’inferenza della dimensione 1 batch su un A100, DFLOAT11 è stato osservato circa il 40% più lento rispetto al BF16 nativo. Ma poiché la latenza di decompressione è relativamente costante, diventa meno impatto a dimensioni batch più grandi, con quasi parità (differenza 1.02x) osservata alla dimensione del batch 128.
Memoria del sistema CPU: uno scenario richiesto da VRAM insufficiente. Zhang ha riassunto:”Se i vincoli hardware (adatti a modelli più grandi, sequenze più lunghe o lotti più grandi) non sono la preoccupazione principale, non c’è molta motivazione per usare DF11″. Fattori come il potenziale impatto sul consumo di energia o sulla stabilità del sistema durante i carichi di lavoro di decompressione prolungati richiederebbero anche una valutazione nelle distribuzioni del mondo reale.
L’accessibilità hardware e i contesti più lunghi
Nonostante il compromesso di latenza negli scenari non vincolati, la proposta di valore DFLOAT11 è la riduzione delle capacità di hardware e Il documento mostra che consente Llama-3.3-70b su una singola GPU H200 da 141 GB e Qwen2.5-32b su un A6000 da 48 GB, entrambi impossibili con BF16 standard. Ciò potenzialmente rende i modelli all’avanguardia utilizzabili per le organizzazioni con budget GPU più piccoli.
Criticamente, il VRAM salvato per comprimere i pesi del modello può essere utilizzato per la cache KV, che spesso limita la lunghezza del contesto massima. Consentendo più spazio per questa cache, DFLOAT11 ha permesso ai modelli di elaborare 5.3x a 13.17x più lunghe sequenze rispetto a BF16 sulla stessa hardware prima di scavalcare la memoria. Per facilitare l’adozione, il team ha reso modelli dfLoat11 pre-compressi disponibili per abbracciare la faccia .
L’argomento per la precisione perdita Esempi di cadute di prestazioni Osservate in una valutazione specifica per i modelli quantizzati. Alcuni utenti finali preferirebbero evitare, poiché crea variabili incontrollate che devono essere testate empiricamente allo stress per ogni scenario di distribuzione”. Per applicazioni come l’elaborazione dei documenti sensibili in cui l’affidabilità è la chiave, può essere essenziale la garanzia di un output identico bit-per bit offerto da un approccio senza perdita di perdita. zipnn , ad esempio, utilizza la decompressione basata su CPU principalmente per accelerare il caricamento del modello e ridurre l’impronta di archiviazione. Precedenti tentativi senza perdita di accesso GPU, come neuzip usando il codifica ANS di Huff, in base a NVCOMP di NVIDIA, sono stati riportati in modo significativo. Ulta throughput di decompressione rispetto a Implementazione ANS di NVCOMP nei benchmark del documento. Affronta anche un angolo di efficienza diverso rispetto ai metodi come la NAMM di Sakana AI, che ottimizza la cache KV per contesti lunghi piuttosto che comprimere pesi statici. DFLOAT11 offre una soluzione specifica per adattarsi a grandi modelli in memoria GPU vincolata senza compromettere la fedeltà di output.
