Riepilogo Tecnico: Lakestream

Enunciato del Problema

L'addestramento moderno dei Modelli Fondamentali di Grande Dimensione (LFM) ha alterato radicalmente i requisiti per le pipeline di dati. A differenza dei carichi di lavoro di deep learning tradizionali che si basano su dataset statici e pre-elaborati, l'addestramento degli LFM comporta una generazione dinamica di dati accoppiata al runtime. Questo cambiamento introduce tre sfide critiche che i sistemi esistenti non riescono a risolvere:

1. Volume di Dati Imprevedibile: Nell'addestramento multimodale (ad esempio, video, testo-immagine intercalato) e nel reinforcement learning, gli input grezzi subiscono una pesante pre-elaborazione runtime (decodifica, ridimensionamento, impaccamento di token). Ciò comporta fattori di espansione dei dati che variano da 62× a oltre 9.000×, rendendo infeasibile l'allocazione statica delle risorse e la pre-partizione.
2. Appartenenza Dinamica del Batch: Nei carichi di lavoro che utilizzano l'impaccamento di token online o la selezione di campioni dipendente dal modello, la composizione esatta di un batch di addestramento è determinata solo al termine della pre-elaborazione. Gli schemi di partizionamento statico non possono catturare questi confini, richiedendo un meccanismo per esporre atomicamente batch completi a tutti i rank di addestramento.
3. Allineamento dei Checkpoint: Le pipeline degli LFM spesso intercalano pre-addestramento, fine-tuning e reinforcement learning, rendendo necessaria la possibilità di tornare indietro a checkpoint specifici e riprodurre sequenze esatte di batch. I sistemi di consegna effimeri non possono garantire la persistenza e il versioning richiesti per un recupero deterministico.

Le soluzioni esistenti risultano insufficienti:

• Dataloaders Colocalizzati: Offrono allineamento semantico ma mancano di isolamento dei guasti. Un crash nella pre-elaborazione blocca l'intero lavoro, e le risorse CPU/memoria condivise creano limiti di throughput.
• Dataloaders Disaggregati (Centralizzati): Disaccoppiano la pre-elaborazione ma si affidano a una consegna RPC effimera. Mancano di cronologia persistente, atomicità a livello di batch e meccanismi per riprodurre batch specifici dopo i guasti.
• Code di Messaggi (es. Kafka): Operano su un'astrazione di record/offset piuttosto che su semantica di batch. O costringono a una consegna di shard fuori ordine (corrompendo l'aggregazione dei gradienti) o richiedono il download di batch completi per ogni rank (causando un'amplificazione di lettura massiva).

Metodologia

Lakestream è un piano dati per l'addestramento nativo dell'object store e senza broker, progettato per risolvere questi problemi adattando i principi dell'architettura lakehouse al ciclo di addestramento. La sua filosofia progettuale di base è che l'object store debba essere l'unico mezzo di coordinamento, eliminando broker, code o servizi centrali.

Astrazione Principale: Batch Globale Transazionale (TGB)

Il sistema introduce il Batch Globale Transazionale (TGB), un'entità persistente di prima classe che tratta ogni batch di addestramento come un'unità atomica con durabilità e ordinamento globalmente coerente.

• Materializzazione: I TGB vengono scritti come oggetti immutabili nell'object store.
• Visibilità Gestita dal Manifesto: La scrittura di oggetti dati non li rende visibili. Un TGB diventa visibile ai consumatori solo quando un manifesto confermato e versionato lo fa riferimento. Ciò garantisce che tutti i rank paralleli nei dati osservino un batch completo e coerente simultaneamente.
• Layout: I TGB sono organizzati in slice di dati corrispondenti alla mesh dei dispositivi (Parallelismo nei Dati e Parallelismo nel Contesto). Ogni rank legge solo la propria slice specifica tramite letture di intervallo mirate, eliminando l'amplificazione di lettura.

Piano di Controllo: Coordinamento Decentralizzato

Lakestream realizza il coordinamento senza un server centrale attraverso due meccanismi chiave:

1. Controllo di Concorrenza Ottimistico (OCC) tramite Manifesti: I produttori confermano i TGB tentando una scrittura condizionale (ad esempio, If-None-Match) di una nuova versione del manifesto. Se il nome della versione è già rivendicato, la scrittura fallisce e il produttore ricalibra il proprio stato locale sul manifesto confermato più recente prima di riprovare. Questo linearizza la sequenza globale dei batch senza comunicazione inter-produttore.
2. Commit Adattivo Decentralizzato (DAC): Per sostenere un throughput elevato mentre il manifesto cresce, Lakestream impiega l'algoritmo DAC. Invece di intervalli fissi, i produttori regolano dinamicamente il loro ritmo di commit basandosi su stime in tempo reale del tempo di I/O del manifesto e dei tassi di conflitto. DAC mantiene un "budget di sovraccarico" e un "budget di conflitto" espliciti, calcolando un intervallo di attesa ottimale tra i tentativi di commit per massimizzare la freschezza minimizzando al contempo i tentativi falliti sprecati.

Gestione del Ciclo di Vita

• Semantica Esattamente-Una-Volta: Lo stato del produttore (offset dello stream) è incorporato direttamente nella mappa di stato per-produttore del manifesto. Al riavvio, un produttore può recuperare la sua posizione esatta senza rieseguire l'elaborazione dei dati.
• Recupero Allineato ai Checkpoint: La ritenzione dei dati è legata direttamente ai progressi dei checkpoint distribuiti. Un watermark globale ($W_{global}$) è derivato dal watermark minimo di tutti i consumatori. Qualsiasi TGB o versione del manifesto al di sotto di questo watermark è idoneo alla cancellazione, garantendo che i costi di archiviazione rimangano limitati mentre si assicura che i dati richiesti per qualsiasi checkpoint attivo non vengano recuperati prematuramente.

Contributi Chiave

1. Architettura Senza Broker e Nativa dell'Object Store: Il sistema stabilisce l'object store come unico mezzo di coordinamento. Non esistono processi lato server nel percorso critico; una nuova esecuzione di addestramento richiede solo un nuovo prefisso di namespace.
2. Batch Globale Transazionale (TGB): Un'astrazione innovativa che unifica la visibilità dei dati con la semantica dello step di addestramento, fornendo visibilità atomica per tutti i rank, ordinamento globale e consegna esattamente-una-volta interamente attraverso primitive dell'object store.
3. Commit Adattivo Decentralizzato (DAC): Un algoritmo che mantiene un throughput di ingestione stabile mentre il manifesto cresce, adattando dinamicamente gli intervalli di commit senza comunicazione inter-produttore.
4. Ciclo di Vita Allineato ai Checkpoint: Un meccanismo che lega la ritenzione dei dati ai progressi dei checkpoint distribuiti, consentendo rollback sicuri e costi di archiviazione limitati senza un servizio di coordinamento persistente.

Risultati della Valutazione

Gli autori hanno valutato Lakestream su carichi di lavoro di pre-addestramento multimodale su larga scala e di Supervised Fine-Tuning (SFT) utilizzando fino a 64 GPU (NVIDIA H200).

• Throughput vs Pipeline Colocalizzate: Lakestream ha superato le pipeline colocalizzate ottimizzate dagli esperti da 2,68× a 7,73× in termini di throughput end-to-end. Questo guadagno è attribuito all'eliminazione della contesa strutturale delle risorse (condivisione della banda CPU/memoria) tra pre-elaborazione e addestramento.
• Throughput vs Kafka: Lakestream ha superato significativamente Apache Kafka nel throughput di ingestione del produttore, in particolare man mano che il numero di produttori aumentava. Kafka non è riuscito a sostenere semantica TGB rigorosa per carichi utili grandi (ad esempio, video) a causa dei limiti di dimensione dei messaggi e della backpressure del broker.
• Latenza: Lakestream ha raggiunto una latenza di lettura del consumatore inferiore rispetto a Kafka. Ad esempio, nei carichi di lavoro SFT video, Lakestream ha ridotto la latenza P95 da ~42,7s (Locale) e ~9,5s (Kafka) a 367ms.
• Scalabilità: L'algoritmo DAC ha mantenuto con successo alti tassi di successo del commit (96,3%) e throughput (431,9 MB/s) durante esecuzioni di 5 ore con 32 produttori, mentre le linee di base a intervallo fisso ed euristiche (AIMD, INCR) si sono degradate significativamente man mano che il manifesto cresceva.
• Amplificazione di Lettura: Lakestream ha raggiunto un'amplificazione di lettura vicina a 1× indipendentemente dalla dimensione del mondo, poiché ogni rank legge solo la propria slice di dati specifica. Al contrario, Kafka e le linee di base a lettura densa hanno mostrato un'amplificazione che scala linearmente con il numero di rank (ad esempio, 128×).
• Efficienza di Archiviazione: Il recupero guidato dai checkpoint ha ridotto la capacità di archiviazione massima del 72,0% (da 34,85 GiB a 9,76 GiB) rispetto alle esecuzioni senza cancellazione fisica, confermando che i watermark limitano efficacemente i costi di archiviazione.

Significato

Il documento afferma che Lakestream dimostra che l'archiviazione a oggetti, quando combinata con metadati versionati e coordinamento decentralizzato, è un substrato sufficiente per un piano dati consapevole dell'addestramento. Trattando il Batch Globale come un'entità transazionale persistente piuttosto che come un artefatto di consegna effimero, Lakestream affronta i requisiti semantici specifici dell'addestramento degli LFM—appartenenza dinamica del batch, allineamento dei checkpoint e isolamento dei guasti—che i sistemi di streaming basati su record esistenti non possono soddisfare. Il sistema dimostra che un'architettura senza broker può sostenere la consegna di dati ad alto throughput e bassa latenza per l'addestramento di modelli fondamentali su larga scala, senza il sovraccarico e i domini di guasto dei servizi centralizzati.