Hace años que la carga de datos a escala terabyte es el cuello de botella más frustrante en cualquier pipeline de entrenamiento. ¿Te suena esperar horas antes de poder iniciar una corrida, o ver caer workers porque el almacenamiento no da abasto? Hugging Face acaba de lanzar una mejora importante para datasets y huggingface_hub que cambia ese panorama: streaming más eficiente, seguro y preparado para entrenar con multi-TB sin descargar nada.
Qué lograron y por qué importa
En términos prácticos: ahora puedes llamar a load_dataset(..., streaming=True) igual que antes, pero el backend resuelve y transmite archivos mucho mejor. ¿Resultados concretos? Menos solicitudes de inicio (hasta 100× menos), resolución de archivos 10× más rápida, hasta 2× mayor velocidad de streaming y menos solicitudes en vuelo. En pruebas con 64xH100 y 256 workers, el streaming llegó a ser más rápido que leer desde SSD local.
Esto no es solo comodidad: reduce latencias, evita bloqueos por exceso de peticiones (adiós al 429), y elimina la espera de horas para preparar datos. Para equipos con clusters modestos o con costes de almacenamiento, significa empezar a entrenar antes y con menos fricción.
¿Qué cambiaron técnicamente?
Trabajaron en dos fases clave: startup (listado y resolución de archivos) y streaming (throughput durante el entrenamiento).
-
Startup: implementaron una cache persistente de lista de archivos compartida entre todos los DataLoader workers. El primer worker consulta el Hub; los demás leen el cache local. Resultado: ya no hay tormenta de solicitudes cuando cada worker intenta resolver el repo por su cuenta.
-
Optimización de resolución: el proceso de obtener la lista de ficheros se agrupa y minimiza las llamadas API, reduciendo latencia del paso inicial.
-
Streaming: añadieron prefetching para Parquet y buffering configurable. Mientras tu modelo procesa el chunk actual, la librería ya trae el siguiente. Además puedes ajustar parámetros como el tamaño mínimo de rangos y el número de bloques a prefetch para adaptar el pipeline a tu hardware y red.
Ejemplo técnico rápido (Parquet + pyarrow)
Para cambiar el tamaño mínimo de rango de 32MiB a 128MiB y habilitar prefetch:
import pyarrow
import pyarrow.dataset
fragment_scan_options = pyarrow.dataset.ParquetFragmentScanOptions(
cache_options=pyarrow.CacheOptions(
prefetch_limit=1,
range_size_limit=128 << 20,
),
)
ds = load_dataset(parquet_dataset_id, streaming=True, fragment_scan_options=fragment_scan_options)
También mejoraron HfFileSystem en huggingface_hub para leer archivos remoto con operaciones tipo open, read, seek y para reutilizar resultados de .ls() y .glob() entre workers.
from huggingface_hub import HfFileSystem
path = f"hf://datasets/{dataset_id}/{path_in_repo}"
with HfFileSystem().open(path) as f:
data = f.read() # o f.readline(), o .seek() para acceso aleatorio
Al pasar una instancia de HfFileSystem a un DataLoader, los listados cacheados se comparten y se eliminan llamadas redundantes.
Otras piezas importantes: Xet y Parquet CDC
Hugging Face usa Xet, un almacenamiento con deduplicado que acelera cargas y descargas porque no retransfiere datos duplicados. Para Parquet implementaron Content Defined Chunking (CDC), lo que mejora la deduplicación y hace que subir/streaming de grandes datasets sea más rápido que en almacenamientos remotos tradicionales.
Además hay integraciones con pyspark_huggingface para acelerar transferencias desde Spark y compatibilidad con pipelines custom (por ejemplo, WebDataset o sampling de frames en video con LeRobot).
¿Cómo aprovecharlo hoy?
- Actualiza las librerías:
pip install --upgrade datasets huggingface_hub
- Usa
streaming=Truecomo siempre:
from datasets import load_dataset
dataset = load_dataset("HuggingFaceM4/FineVisionMax", split="train", streaming=True)
print(next(iter(dataset)))
- Si necesitas exprimir rendimiento, ajusta
fragment_scan_options(o parámetros equivalentes) para aumentarrange_size_limityprefetch_limit, y experimenta con el número de workers y el tamaño de batch para balancear CPU, red y GPU.
Resultados prácticos y casos de uso
- Entrenar modelos VLM (como nanoVLM o SmolVLM) sin pasar por S3 ni descargar terabytes a tus discos.
- Flujos de trabajo de experimentación rápida: inspeccionar datasets y lanzar pruebas pequeñas sin esperas.
- Equipos con muchos workers concurrentes evitan bloqueos y caídas por exceso de solicitudes.
En la práctica, Hugging Face reporta que, con estas mejoras, el streaming puede igualar o superar la lectura desde SSD locales en sus clusters de entrenamiento: una transformación real para quienes estaban atados a preparar datos en disco antes de cada run.
Reflexión final
No siempre se trata de modelos más grandes; a veces la mayor ganancia viene de quitar fricción en la entrada de datos. Estas mejoras muestran que optimizar la I/O y la coordinación entre workers produce saltos de rendimiento que se sienten en tiempo real: menos esperas, menos errores y más tiempo para iterar en modelos y datos.
Si trabajas con datasets a escala, actualiza tus librerías, prueba el streaming y ajusta el buffering. ¿La sorpresa? Puede que ahora tu GPU pase más tiempo entrenando y menos esperando datos.
