Antes de tocar código: qué necesitas realmente para entrenar un LLM
Entrenar un modelo de lenguaje desde cero no es descargar un script y pulsar enter. Es un proyecto de ingeniería con tres frentes que debes resolver antes de la primera línea: datos, cómputo y evaluación. Según la documentación oficial de frameworks como PyTorch y Hugging Face, la mayoría de los fracasos en proyectos de entrenamiento no vienen del código, sino de una planificación deficiente del corpus y de una infraestructura mal dimensionada.
Este artículo describe una configuración paso a paso asumiendo que quieres construir un modelo pequeño o mediano (entre 100M y 1.500M de parámetros) para un dominio específico, no un competidor de los grandes modelos generalistas. Si tu objetivo es un modelo de 70B parámetros con datos multilingües masivos, el presupuesto se mide en millones de dólares y este tutorial se queda corto: reconócelo desde el principio.
Paso 1: definición del alcance y del presupuesto de cómputo
Antes de escribir el tokenizador, decide el tamaño del modelo en función de las GPU disponibles. La regla práctica que se usa en la industria relaciona tokens de entrenamiento con parámetros: un modelo bien entrenado suele consumir entre 20 y 100 veces más tokens que parámetros. Para un modelo de 125M parámetros, un corpus de 2.500M a 10.000M de tokens es razonable.
Estimación de VRAM y tiempo
La memoria necesaria durante el entrenamiento no depende solo del tamaño del modelo. Los estados del optimizador AdamW multiplican por cuatro el peso del modelo en precisión mixta. Un modelo de 125M parámetros puede consumir entre 2 y 3 GB solo en estados del optimizador, más activaciones y gradientes. En una GPU de 24 GB puedes entrenar modelos de hasta 300-400M parámetros con batch pequeño y gradient checkpointing.
Un error común que he visto en equipos noveles: asumir que una RTX 4090 de consumo permite entrenar un modelo de 1B parámetros sin técnicas de ahorro de memoria. La realidad es que el entrenamiento se detiene por OOM (out of memory) a los pocos pasos, y el tiempo de depuración supera al de entrenamiento.
Paso 2: construcción y limpieza del corpus
El dataset es el activo más valioso y el más descuidado. Para un modelo de dominio (legal, médico, técnico, atención al cliente), necesitas entre 1.000 y 10.000 millones de tokens de texto de calidad. Si partes de cero, la pipeline de limpieza debe incluir:
- Deduplicación a nivel de documento y de párrafo con MinHash o SimHash. Sin esto, el modelo memoriza y sobreajusta a frases repetidas.
- Filtrado de idioma con un clasificador ligero (fastText funciona bien) para descartar contenido que no sea español si ese es tu dominio.
- Eliminación de boilerplate (menús de navegación, avisos de cookies, footers) que envenenan la señal de entrenamiento.
- Control de calidad heurístico: ratio de caracteres alfabéticos, longitud media de frase, presencia de repeticiones n-grama.
Según estudios del sector sobre datasets públicos como C4 y The Pile, entre el 40% y el 60% del texto bruto se descarta tras la limpieza. Planifica el almacenamiento en consecuencia: un corpus de 10.000M tokens en texto plano ocupa aproximadamente 40 GB.
Paso 3: tokenizador específico del dominio
No reutilices el tokenizador de GPT-2 o Llama si tu dominio tiene vocabulario propio. Un tokenizador BPE entrenado sobre tu corpus reduce el número de tokens por documento y acelera el entrenamiento. La configuración con la librería tokenizers de Hugging Face es directa:
from tokenizers import Tokenizer, models, trainers, pre_tokenizers tokenizer = Tokenizer(models.BPE(unk_token=»[UNK]»)) tokenizer.pre_tokenizer = pre_tokenizers.ByteLevel(add_prefix_space=False) trainer = trainers.BpeTrainer(vocab_size=32000, special_tokens=[«[PAD]»,»[UNK]»,»[BOS]»,»[EOS]»]) tokenizer.train_from_iterator(corpus_iter, trainer=trainer) tokenizer.save(«tokenizer_dominio.json»)Un vocabulario entre 32.000 y 50.000 tokens cubre bien español general. Para dominios técnicos con muchos acrónimos, considera 48.000. Verifica la tasa de compresión: si tu tokenizador genera más de 1,4 tokens por palabra en promedio, probablemente necesitas más vocabulario o un corpus de entrenamiento más representativo.
Paso 4: arquitectura del modelo y configuración inicial
Para un modelo desde cero, una arquitectura decoder-only tipo GPT es el estándar. La configuración debe ser coherente: dimensión oculta (d_model), número de capas, cabezas de atención y dimensión de feed-forward. Una regla que funciona: feed-forward = 4 × d_model, y número de cabezas tal que la dimensión por cabeza sea 64 o 128.
Ejemplo de configuración para un modelo de 125M
{ «vocab_size»: 32000, «hidden_size»: 768, «num_hidden_layers»: 12, «num_attention_heads»: 12, «intermediate_size»: 3072, «max_position_embeddings»: 1024, «hidden_act»: «gelu», «dropout»: 0.1 }Con esta configuración, el modelo tiene aproximadamente 125M de parámetros. Si tu GPU es de 16 GB, reduce el batch por dispositivo a 8 y usa acumulación de gradientes de 4 para un batch efectivo de 32. El learning rate inicial típico es 3e-4 con scheduler coseno y warmup de 2.000 pasos.
Paso 5: loop de entrenamiento con PyTorch y Accelerate
La configuración mínima viable usa transformers con Trainer o un loop manual con accelerate. Para control total, el loop manual es preferible. Los puntos críticos:
- Precisión mixta (fp16 o bf16) con torch.cuda.amp. En GPUs Ampere o superiores, bf16 es más estable.
- Gradient checkpointing activado si el modelo no cabe en memoria.
- Guardado de checkpoints cada 500 pasos, no cada época. En modelos grandes, una época puede ser inviable.
- Evaluación de perplejidad en un conjunto de validación del 5% del corpus.
Un detalle que solo se aprende con la práctica: el loss puede parecer estable pero la perplejidad de validación divergir si el corpus de validación tiene una distribución distinta. Asegúrate de que la validación se extrae aleatoriamente del mismo corpus limpio, no de una fuente diferente.
Paso 6: evaluación y señales de alarma
La perplejidad no basta. Necesitas evaluar el modelo en tareas concretas: generación de texto, clasificación o respuesta a preguntas. Para un modelo pequeño, usa benchmarks ligeros como un subconjunto de la tarea de razonamiento o pruebas manuales de generación con prompts de tu dominio.
Señales de que algo va mal:
- Loss que baja pero generación incoherente: probablemente sobreajuste por duplicados en el corpus.
- Perplejidad de validación que sube tras un mínimo: learning rate demasiado alto o corpus demasiado pequeño para el tamaño del modelo.
- Repeticiones en la generación: falta de diversidad en el corpus o tokenizador mal entrenado.
Paso 7: ajuste fino y despliegue
Un modelo base entrenado desde cero no responde instrucciones. Para uso práctico, necesitas una fase de instrucción o ajuste fino supervisado con pares pregunta-respuesta de tu dominio. Esta fase es más ligera: entre 10.000 y 100.000 ejemplos de calidad suelen ser suficientes para un modelo pequeño.
El despliegue con vLLM o llama.cpp permite servir el modelo con cuantización a 8 o 4 bits, reduciendo requisitos de VRAM. Un modelo de 125M cuantizado a 4 bits ocupa menos de 100 MB y puede correr en CPU, aunque la latencia será mayor.
Limitaciones que debes asumir
Entrenar desde cero no garantiza calidad. Un modelo de 125M entrenado con 5.000M de tokens en español tendrá un conocimiento factual limitado y alucinará con frecuencia. No compite con modelos preentrenados de mayor tamaño. Si tu objetivo es un asistente conversacional general, el ajuste fino de un modelo existente es más eficiente en coste y tiempo. El entrenamiento desde cero tiene sentido cuando necesitas control total sobre el vocabulario, la licencia o la arquitectura, o cuando investigas dinámicas de entrenamiento.
Según la documentación oficial de PyTorch y las guías de Hugging Face, el coste de un entrenamiento de 125M parámetros con 5.000M de tokens en una sola GPU de 24 GB puede oscilar entre varios días y una semana, dependiendo del throughput. No hay atajos: la pipeline de datos consume tanto tiempo como el entrenamiento.
Si decides avanzar, empieza con un corpus de 500M tokens y un modelo de 50M parámetros. Valida la pipeline completa antes de escalar. La experiencia demuestra que el 80% de los errores aparecen en las primeras 24 horas de entrenamiento y son más fáciles de corregir con un modelo pequeño.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.