English · Español

03 — Data Pipelines a Escala

🇪🇸 La diferencia entre un modelo mediocre y uno bueno, a coste igualado, está en los datos. El data pipeline (data pipeline) canónico (CommonCrawl → filtro → deduplicación → tokenización → shards) no es opcional; cada paso elimina un orden de magnitud de basura y gana un punto porcentual en MMLU. FineWeb-Edu lo demuestra empíricamente.

Un dataset de pretraining (pretraining) para un modelo de >1B parámetros no es "una carpeta con ficheros de texto". Es un pipeline que procesa 10-100 TB de crawl web crudo a través de 5-7 etapas, cada una eliminando una categoría de ruido.

El pipeline canónico

CommonCrawl WARC → extracción de texto → filtro de idioma →
filtro de calidad → dedup URL/contenido → eliminación de PII →
tokenización → sharding en blobs binarios

Por etapa, tasas de retención típicas (paper de FineWeb, Penedo 2024): - WARC → extracción de texto con trafilatura: ~80% se descarta (boilerplate/HTML). - → solo inglés (FastText): ~50% se descarta (95% del crawl es no-inglés). - → dedup URL: ~10% se descarta. - → dedup fuzzy de texto (MinHash): ~20% se descarta. - → clasificador de calidad: 20-90% se descarta (depende del umbral). - → scrub de PII: <1% se descarta.

Neto: un crawl crudo de 50 TB rinde ~1-5 TB de texto de entrenamiento usable, dependiendo del listón de calidad.

Fuente: CommonCrawl

CommonCrawl (commoncrawl.org) es el crawl web público canónico. Liberado ~mensualmente como archivos WARC. Cada dump es ~80-100 TB comprimidos.

• Formato: WARC (Web ARChive). Cada registro son cabeceras de respuesta HTTP + cuerpo.
• Licencia: los metadatos del crawl son abiertos; el contenido es la licencia que tenga la web origen. (Los laboratorios frontera y los datasets downstream como Pile-CC, RefinedWeb, FineWeb usan todos esto.)
• Cobertura: ~3 mil millones de páginas por dump, ~50 dumps/año accesibles.
• Limitaciones: respeta robots.txt (sites grandes pueden optar por excluirse — el NYT y Reddit lo han hecho); sesgado hacia inglés y web occidental; desactualizado para datos en vivo.

Los equipos frontera entrenan típicamente sobre la unión de 10-20 dumps de CommonCrawl (~500-1000 TB crudos) más fuentes no-crawl de alta calidad (Wikipedia, libros, arXiv, GitHub).

Filtros de calidad: el playbook moderno

Filtros heurísticos (estilo Gopher, Rae 2021): - Longitud en tokens 50-100k por doc. - Longitud media de palabra 3-10 chars. - Ratio símbolo-palabra < 0.1. - Ratio de viñetas < 0.9. - Detección de texto "Lorem ipsum" / placeholder.

Estos son rápidos (clase regex), descartan ~30% del texto post-filtro-de-idioma.

Filtros clasificadores (FineWeb-Edu, Penedo 2024): - Entrena un clasificador pequeño (p. ej. snowflake-arctic-embed) sobre pares (doc, score) donde score es de un LLM puntuando "valor educativo" 0-5. - Aplicar a escala; retener docs con score ≥3. - Resultado: descarta ~10× más datos que solo-heurísticas, pero la calidad sube muchísimo. Un modelo de 1.8B sobre 350B tokens de FineWeb-Edu vence a 1T tokens de CommonCrawl crudo en MMLU.

Filtros de dominio (estilo Llama-3): - Ponderación por fuente. Tuning tipo Wikipedia × 3, arXiv × 5, "web general" × 1. - Esta es la magia silenciosa — los pesos de filtro publicados son raros.

Dedup: MinHash + LSH

Documentos duplicados sesgan la curva de loss y memorizan verbatim. La dedup ocurre a dos escalas:

Exacta (nivel URL): trivial. SHA256 de la URL.

Fuzzy (nivel contenido): MinHash con locality-sensitive hashing. - Hash de 5-gramas de cada doc a un sketch de 128-int. - Bucketea los sketches en LSH de 8 bandas. - Documentos en el mismo bucket son candidatos a duplicados → comprobación de similitud Jaccard → descarta si > 0.8.

Por qué funciona: dos documentos que comparten el 80% de sus 5-gramas son casi-seguro duplicados (plantillas boilerplate, sites espejo). El sketch MinHash puede computarse en una pasada y compararse en \(O(1)\) por par dentro del bucket.

Herramientas: datasketch (Python, lento a escala TB), text-dedup (HuggingFace, más rápido), basado en Spark a escala frontera.

Throughput: dedup de 1 TB en una box de 64-cores CPU: ~6 horas. El cuello de botella clásico.

Tokenización: preocupaciones específicas del pretraining

La elección del tokenizer (tokenizer) es downstream de la arquitectura del modelo, pero el coste de pipeline de la tokenización importa:

• BPE de GPT-2 (50,257 de vocab): ~0.7 bytes/token en inglés. Pre-tokeniza a ~5 MB/s/core.
• Tokenizer de Llama-3 (128,256 de vocab): ~0.5 bytes/token en inglés. Vocab más grande → menos tokens sobre los que entrenar, más parámetros del modelo gastados en embedding.
• SentencePiece (Llama-½, 32,000 de vocab): ~0.6 bytes/token. Más viejo, default de vocab más pequeño.

Para X1: usa el tokenizer de GPT-2. Es gratuito, rápido, bien documentado, y los conteos de tokens publicados de Pile / FineWeb-Edu se citan en sus tokens.

Throughput de tokenización a escala: 5 TB de texto / 5 MB/s/core = \(10^6\) core-segundos = 11.6 core-días. En una box de 64-cores: ~4 horas. En un cluster (cluster) de 1024-cores: ~17 minutos. Este no es el cuello de botella; la dedup lo es.

Sharding para streaming

Una vez tokenizado, el corpus se guarda como shards binarios — típicamente 100 MB a 1 GB cada uno, en formatos como:

• Arrays uint16 con mmap. El más simple. Apila IDs de token como numpy.uint16 (funciona para vocabs ≤65,535). nanoGPT y Pythia usan esto.
• Shards .tar de WebDataset. Cada shard es un .tar de ficheros pequeños; el reader los streama. Usado por Mosaic Streaming.
• Formato MDS de mosaicml/streaming. Optimizado para reads distribuidos reanudables.
• Parquet. Lento para acceso aleatorio; usado para almacenamiento de texto crudo, no para reads en tiempo de entrenamiento.

Para el lab 00 de X1, usa el formato nanoGPT: train.bin y val.bin, cada uno un array plano uint16. Reads a 500+ MB/s en NVMe, trivialmente mapeable a memoria, sin tokenización en tiempo de entrenamiento.

Aritmética de throughput: ¿puede el dataloader alimentar un A100?

Un modelo de 50M parámetros a MFU 0.40 en un A100 80GB procesa:

• \(1.5 \times 10^{14}\) FLOP/s sostenidos / \(6 \cdot 5 \times 10^7\) FLOP/token = 500k tokens/s.

A 2 bytes/token (uint16): 1 MB/s de lectura de datos. SSDs NVMe hacen 3-7 GB/s. De sobra para 1× GPU.

A 8× H100 con TP=8 haciendo un modelo de 7B parámetros: - Tokens/seg ≈ \(8 \cdot 0.45 \cdot 989 \times 10^{12} / (6 \cdot 7 \times 10^9)\) = 84,000 tokens/s. - A 2 bytes/token: 0.17 MB/s por réplica. Total del cluster: todavía <1 MB/s.

El modelo está siempre compute-bound, no data-bound, una vez tokenizado. Toda la preocupación de "data pipeline a escala" es sobre llegar de web crudo a binario tokenizado, no sobre alimentar al modelo durante el entrenamiento.

Qué hace FineWeb-Edu realmente (case study)

FineWeb (Penedo 2024) procesa los 96 dumps de CommonCrawl de 2013-2024:

1. Extracción: trafilatura.
2. Idioma: FastText, solo inglés.
3. Calidad (heurística): filtros Gopher afinados por-dump.
4. Dedup: MinHash a nivel de dump (no cross-dump — el paper documenta esta elección como tradeoff memoria/calidad).
5. PII: basado en regex, baja precisión pero alto recall.

Resultado: 15T tokens de "FineWeb-base" (alta calidad, grande).

Para FineWeb-Edu, dan un paso adicional: 6. Clasificador: subset puntuado por LLM → entrena clasificador Snowflake-Arctic-embed → aplica a escala → retiene los top ~1.3T tokens.

El subset 1.3T de FineWeb-Edu iguala los 15T de FineWeb-base en MMLU con \(1/10\) de los tokens de entrenamiento. Esta es la scaling law de calidad de datos en números.

Coste de construir el dataset

Para el lab de X1 no construimos un dataset. Descargamos uno pre-construido. Pero el orden de magnitud:

Etapa	Cómputo	$-coste (spot CPU en la nube)
Descarga de CommonCrawl	50-100 TB egress	$500-2000 (o gratis desde S3 misma-región)
Extracción + filtro de idioma	~1000 core-horas	$30-100
Calidad + dedup	~10,000 core-horas	$300-1000
Tokenización	~100 core-horas	$3-10
Almacenamiento (1 año)	5-15 TB hot	$1500-5000
Total por dump de CC procesado	—	$2k-10k

Los laboratorios frontera procesan 20-50 dumps. Su coste de preparación de dataset es \(50k-\)500k antes de cualquier entrenamiento del modelo.

Atajo de X1: descarga directamente una muestra pre-tokenizada de FineWeb-Edu (~5-10B tokens, ~20 GB) desde HuggingFace. Tiempo de preparación total: 10 min. Coste de preparación total: < $1.

Calidad de datos > cantidad de datos, otra vez

El paper de Chinchilla asume que los datos son fungibles — un token es un token. Realidad: un token de FineWeb-Edu vale ~5-10 tokens de CommonCrawl crudo para precisión downstream.

Esto rompe la regla "20:1" de una manera específica: para cómputo fijo, entrena sobre los mejores datos que puedas conseguir, incluso si significa D < 20N. Un modelo de 50M parámetros sobre 3B tokens de alta calidad vence al mismo modelo sobre 5B tokens de calidad mixta.

Para X1: elige FineWeb-Edu sobre Pile-CC crudo. Mismo modelo, mismo cómputo, ~5% menos de val loss.

Qué falta intencionadamente

• Datos de código. El código (GitHub) es el 10-20% de los corpus frontera y tiene su propio pipeline (filtro de licencia, detección de lenguaje, scoring de calidad). The Stack v2 (Lozhkov 2024) es el dataset canónico. X1 ignora código — estamos entrenando un modelo solo-de-texto pequeño.
• Datos de matemáticas. OpenWebMath, ProofPile. Lo mismo — no está en el scope de X1.
• Libros / arXiv / Wikipedia. La mezcla frontera incluye ~10% de texto no-web. X1 se queda con FineWeb-Edu por simplicidad.
• Aprendizaje por currículo / intercambios de datos por etapa. Llama-3 usa un currículo de datos (menor calidad temprano, mayor calidad tarde). El presupuesto de 24 horas de X1 no justifica el staging.
• Pretraining continuado / intercambios de datos mid-training. Territorio de la Fase 19 + conocimiento de laboratorio frontera. Fuera del scope de X1.

---

Siguiente: theory/04-training-stability-at-scale.md.