Streaming S01
Lo stack di rete per lo streaming di dati verso la GPU
Cosa fa davvero ogni livello tra un oggetto su S3 e un tensore in VRAM — e perché "basta fare streaming diretto alla GPU su TCP" è l'unica cosa che non si può fare. Una mappa del perché la ricerca è arrivata allo stato dell'arte che ha.
1 · Ciò che le persone immaginano vs. ciò che esiste
Il modello mentale dietro "fai streaming del dataset direttamente alla GPU" è un unico filo dal bucket alla VRAM. Quel filo non esiste sulla rete internet aperta. Un byte che lascia un oggetto S3 deve attraversare quattro salti indipendenti, e ognuno è governato da una tecnologia diversa con i suoi limiti. L'illusione del "diretto" riguarda in realtà quali di questi salti riesci a saltare.
Ogni sistema di streaming esistente — HF datasets, MosaicML, WebDataset, DALI, lo stato
dell'arte della ricerca — è un insieme preciso di risposte a: quali salti attraverso in software sulla
CPU, e quali affido a hardware dedicato che permette alla CPU di farsi da parte? "Diretto alla GPU"
in letteratura significa sempre una cosa precisa: saltare il bounce buffer dello
Host (CPU+RAM) così che i byte arrivino in VRAM senza che la CPU li copi.
Quel salto è reale — ma solo sulle tecnologie delle righe verdi qui sotto, nessuna delle quali è la rete
internet pubblica.
2 · Il livello di trasporto: perché non "semplicemente TCP"?
Quando prima ho detto che "non possiamo usare TCP", intendevo questo — non che TCP non riesca a spostare i byte (li sposta quasi tutti, oggi), ma che TCP strutturalmente non può consegnare un byte nella memoria della GPU senza la CPU. TCP è un protocollo di kernel, guidato dalla CPU: ogni segmento è riassemblato, verificato con checksum e copiato dalla CPU host nella RAM host. La GPU non è mai parte di una connessione TCP. Quindi un percorso basato su TCP paga sempre il bounce buffer host e una tassa per byte sulla CPU. Lo stato dell'arte è una famiglia di protocolli progettati apposta per togliere la CPU dal percorso dei dati.
| Trasporto / protocollo | Cos'è | Perché può — o non può — fare streaming nella GPU | Verdetto |
|---|---|---|---|
| TCP/IP HTTP · API S3 |
Il trasporto affidabile predefinito. Tutto sulla rete internet pubblica, incluso ogni GET S3, viaggia su di esso. |
Guidato dal kernel: la CPU riassembla, fa il checksum e copia ogni segmento nella RAM host. La GPU non può terminare un flusso TCP, quindi una copia su PCIe è poi obbligatoria. È il bounce buffer, per progettazione. | No — CPU nel ciclo |
| QUIC / HTTP/3 | Trasporto moderno basato su UDP (meno head-of-line blocking, handshake più rapidi). Ciò che usa oggi un client HTTP per oggetti veloce. | Latenza migliore, stesso problema di fondo: gira in spazio utente/kernel sulla CPU. Congestion control, recupero delle perdite e crittografia sono tutto lavoro della CPU; il payload atterra comunque prima nella RAM host. | No — terminato sull'host |
| NFS / mount POSIX "S3 come filesystem" |
Montare un bucket (s3fs, Mountpoint, goofys) così che il codice di training veda dei file. Comodo, ed è ciò che la maggior parte delle pipeline ingenue sceglie. | Ogni lettura diventa una range request HTTP sotto uno shim di filesystem, poi passa dalla page cache sulla CPU. Throughput misurato a ~300 MB/s vs 10+ GB/s di NVMe locale — ~30× più lento — e non tocca mai la GPU direttamente. | No — lento e CPU-bound |
| RDMA InfiniBand · RoCEv2 · iWARP |
Remote Direct Memory Access. La NIC scrive i dati direttamente in una regione di memoria pre-registrata sull'host remoto, bypassando del tutto la sua CPU e il kernel. | È la primitiva abilitante. Combinata con GPUDirect, il motore DMA della NIC può puntare direttamente alla VRAM della GPU — la CPU non tocca mai il payload. Ma RDMA richiede un fabric lossless a bassa latenza: vive dentro un datacenter, non attraverso la WAN. | Sì — le fondamenta |
| GPUDirect RDMA GPU ↔ NIC |
Tecnologia NVIDIA che permette a una NIC di terze parti di leggere/scrivere la memoria della GPU su PCIe senza sostare nella RAM host. Si abbina all'RDMA sopra. | Elimina l'ultima copia: dati remoti → NIC → VRAM GPU, CPU fuori dal percorso. È esattamente il "diretto alla GPU" che si immagina — ma richiede che mittente, fabric e NIC parlino tutti RDMA. | Sì — solo datacenter |
| GPUDirect Storage (GDS) cuFile |
Un percorso DMA dallo storage (NVMe locale, o NVMe-oF su fabric) alla memoria della GPU, saltando il bounce buffer della CPU. Esposto tramite l'API cuFile. |
Reale e in produzione — ma solo per storage a blocchi/file su fabric RDMA (NVMe, NVMe-oF, Lustre, WekaFS, GPFS). Non parla S3/HTTP. Se i prerequisiti non ci sono, cuFile ricade silenziosamente su un bounce buffer CPU ("modalità compatibilità"). |
Parziale — non object storage |
| cuObject / GPUDirect-per-S3 tech preview |
Il pezzo più nuovo di NVIDIA: semantica di object storage (stile S3) con un data plane RDMA diretto nella memoria GPU. Il control plane è HTTP; il data plane è RDMA. | La cosa più vicina a "S3 diretto alla GPU" che esista — ma il data plane richiede comunque RDMA (InfiniBand/RoCEv2) tra un server di storage compatibile e la macchina GPU. All'inizio del 2026 era una technical preview, non general availability, e confinata ai fabric di datacenter. | Parziale — emergente, solo LAN |
| NCCL / NVLink GPU ↔ GPU |
Il livello di comunicazione collettiva per il training multi-GPU (all-reduce, broadcast). NVLink/NVSwitch è il fabric GPU-GPU dentro il nodo. | Non è un trasporto di ingest: sposta gradienti e attivazioni tra GPU che già contengono i dati, non i dati dallo storage. Rilevante perché, una volta che un rank ha un batch, condividerlo GPU-a-GPU costa poco; portare dentro la prima copia è la parte difficile di cui parla questa pagina. | N/A — intra-training, non ingest |
3 · Quindi cosa è davvero raggiungibile sulla WAN?
Questo è il nocciolo pragmatico per noi. Il vero ingest GPU-diretto è una capacità del fabric di datacenter, e i laboratori di world-model che addestrano in cloud (AWS, GCP, CoreWeave, Lambda) per lo più sono dentro fabric simili — ma l'object store da cui attingono di solito non è sullo stesso fabric RDMA delle loro GPU. Quindi l'architettura realistica è un relè, non un unico filo:
L'esperienza "senza attriti" che possiamo onestamente promettere è: il ricercatore non lancia mai un passo di download e il suo disco locale non si riempie mai — non "i byte si teletrasportano dal nostro bucket nella VRAM". Il salto WAN è nascosto da concorrenza e prefetch (il risultato ben noto: un loader ingenuo lascia la GPU inattiva al 95% su S3, ma il prefetch async/threaded ne recupera la gran parte, raggiungendo ~67% del throughput da disco locale). La parte GPU-diretta avviene sull'ultimo salto, da una cache in-region gestita dall'SDK, dove può esistere un vero fabric RDMA/GDS.
| Livello | Collo di bottiglia che rimuove | Tecnica usata dallo stato dell'arte |
|---|---|---|
| Latenza WAN | GPU in attesa dei round-trip | Code di prefetch profonde, centinaia di range request concorrenti, threading senza GIL (Meta SPDL) |
| Costo egress e ri-letture | Pagare al GB a ogni epoca | Co-locare lo storage in-region; store a egress zero (Cloudflare R2); cache NVMe in-region scaldata una volta |
| Shuffle ad accesso casuale | HTTP odia le letture casuali | Shard + shuffle degli shard, poi un buffer in memoria limitato; shuffle globale fatto offline (il limite onesto) |
| Bounce buffer in RAM host | CPU che copia ogni byte | GDS / cuFile dalla cache locale; fabric RDMA dove disponibile |
| Decodifica (spec. video) | CPU che decodifica i frame | Decodifica hardware sulla GPU — NVDEC per il video, nvJPEG per le immagini (DALI) |
4 · La modalità che cambia i conti: il video
Per testo e immagini i byte sono piccoli e gli attori affermati sono maturi. Il video è diverso, ed è la nostra verticale. Un dataset di world-model è enorme, e il passo costoso non è la rete ma la decodifica: trasformare H.264/H.265 compresso in tensori di frame. Qui "verso la GPU" smette di essere marketing e diventa vero silicio — il decodificatore hardware NVDEC sulla GPU trasforma il bitstream video in frame senza la CPU, proprio accanto a dove il training ne ha bisogno.
5 · Cosa significa per il livello di streaming "ec"
Non costruiremo un nuovo trasporto — RDMA, GPUDirect e GDS esistono già e NVIDIA li possiede. Il nostro livello senza attriti li compone e nasconde il relè. In concreto, il prodotto difendibile è l'orchestrazione implicata dalla tabella qui sopra, impacchettata così che un laboratorio scriva tre righe invece di costruire tutto questo:
- Relè WAN → cache → GPU, gestito per l'utente: prefetch, cache NVMe in-region, e GDS/NVDEC sull'ultimo salto — il ricercatore vede solo un iteratore di dataset.
- Zero preparazione. Punta al video grezzo in un bucket; noi facciamo shard, indice e decodifica in modo trasparente. Ogni attore affermato impone prima un passo offline di "conversione nel nostro formato" — quell'attrito è il varco.
- Decodifica video-nativa sulla GPU via NVDEC, con la nostra etichettatura di clip esistente
(pipeline
Data_Validation) eseguita in-stream — il pezzo che un loader generico strutturalmente non può fare. - Generalizzare verso l'esterno. Lo stesso relè serve immagini e array; il video è il varco, non il soffitto. Un laboratorio di world-model che ci adotta per il video di gameplay ci tiene per il resto.