Stanford explica cómo hacer un LLM desde cero

Si hoy usas un modelo de lenguaje para escribir, resumir o programar, probablemente ya te pasó esto: funciona bien hasta que necesitas entender por qué respondió eso, cuánto cuesta entrenarlo, o qué cambia cuando ajustas la arquitectura. Ahí es donde la mayoría se queda corta. Usar un LLM es fácil; construirlo, entrenarlo y depurarlo desde cero es otra historia.

El curso CS336: Language Modeling from Scratch de Stanford entra justo en ese hueco. No promete atajos mágicos ni una receta de “copiar y pegar”. Lo que propone es más útil: darte las piezas técnicas para entender cómo se arma un modelo de lenguaje moderno, desde el tokenizador hasta el entrenamiento distribuido, pasando por optimización, evaluación y alineamiento. Si trabajas en IA en Latinoamérica, o estás aprendiendo para moverte a ese campo, este curso te sirve como mapa serio para dejar de mirar los LLM como caja negra.

Qué enseña CS336 y por qué importa

CS336 no está pensado como una introducción ligera a IA generativa. Está más cerca de un laboratorio conceptual donde se desarma el stack completo de un language model. La idea central es simple: si entiendes cada componente, también entiendes dónde se van el dinero, el tiempo y la calidad. Eso cambia cómo evalúas una arquitectura, cómo interpretas una métrica y cómo decides si conviene entrenar, afinar o simplemente usar un modelo existente.

La página oficial del curso lo presenta como un recorrido por el entrenamiento de modelos de lenguaje desde cero, con énfasis en la práctica y en los fundamentos. Puedes revisarlo directamente en la web de Stanford: https://cs336.stanford.edu/ . También conviene mirar la documentación de PyTorch para las partes de implementación, porque gran parte del aprendizaje real ocurre cuando conviertes una idea en código ejecutable: https://pytorch.org/docs/stable/index.html .

Lo valioso del curso no es solo el temario. Es el enfoque. En vez de tratar los LLM como una lista de APIs, te obliga a pensar en capas: datos, tokenización, arquitectura, función de pérdida, optimización, escalado y evaluación. Si alguna vez te preguntaste por qué dos modelos con parámetros parecidos rinden distinto, o por qué un entrenamiento se rompe con un cambio pequeño en batch size, aquí empiezas a encontrar respuestas concretas.

Un curso pensado para entender, no solo usar

Hay una diferencia grande entre consumir contenido de IA y construir criterio técnico. CS336 apunta a lo segundo. No necesitas memorizar papers para seguirlo, pero sí te conviene llegar con bases de Python, álgebra lineal y algo de deep learning. Si ya trabajas con modelos en producción, el curso te ayuda a conectar decisiones de ingeniería con resultados medibles: tokens por segundo, estabilidad del loss, costo por entrenamiento, latencia y comportamiento en inferencia.

Para una audiencia latinoamericana esto es especialmente útil porque el acceso a cómputo suele ser más limitado. Cuando no tienes un clúster enorme, cada decisión importa más: un tokenizador mal elegido te puede inflar el vocabulario, un batch size mal calibrado te puede desperdiciar GPU, y una evaluación floja te puede hacer celebrar un modelo que en realidad no sirve. Entender el sistema completo te ayuda a gastar mejor.

Qué tipo de preguntas te ayuda a responder

El curso te da herramientas para responder preguntas que aparecen todo el tiempo en equipos de producto, investigación o infraestructura. Por ejemplo:

• ¿Cuántos datos necesitas realmente para que el modelo aprenda algo útil?
• ¿Por qué el tokenizador cambia tanto el rendimiento en español?
• ¿Cuándo conviene escalar parámetros y cuándo conviene escalar datos?
• ¿Qué parte del entrenamiento está causando inestabilidad?
• ¿Cómo comparas un modelo pequeño bien entrenado contra uno grande mal afinado?

Ese tipo de preguntas no se resuelve con intuición sola. Se resuelve entendiendo el pipeline completo.

Del texto al token: la primera decisión técnica

Antes de hablar de transformers, hay que hablar de texto. Un LLM no ve palabras como tú las lees. Ve secuencias de tokens. Esa conversión parece menor, pero define parte del rendimiento, el costo y hasta el comportamiento del modelo en idiomas distintos al inglés.

En un contexto como el español latinoamericano, la tokenización importa mucho. No es lo mismo entrenar con un corpus dominado por inglés que con texto en español, donde aparecen tildes, contracciones, nombres propios locales y variaciones regionales. Si el tokenizador fragmenta demasiado una palabra frecuente, el modelo paga más por aprenderla. Si la fragmenta mal, pierde eficiencia.

CS336 pone atención en esa capa porque ahí empieza la cadena completa. No basta con “meter texto”. Tienes que decidir cómo representar ese texto para que el modelo lo procese bien y de manera eficiente.

Tokenización, vocabulario y costo

Un vocabulario más grande no siempre es mejor. Puede reducir la longitud de las secuencias, pero también aumenta la complejidad del embedding y puede empeorar la cobertura si el corpus no está bien balanceado. Un vocabulario más pequeño hace lo contrario: secuencias más largas, pero una representación más compacta. En práctica, el equilibrio depende del idioma, del dominio y del presupuesto de cómputo.

Una forma útil de pensar esto es con números simples. Si un texto de 1.000 palabras termina en 1.400 tokens, entrenar sobre ese corpus cuesta más que si termina en 1.050 tokens. Esa diferencia se multiplica por millones o miles de millones de tokens. Por eso la tokenización no es un detalle de preprocesamiento, sino una decisión económica.

Qué revisar cuando limpias datos

Antes de entrenar, el curso te empuja a pensar en calidad de datos. No solo en cantidad. Un pipeline serio suele revisar al menos esto:

1. Duplicados exactos y casi duplicados.
2. Texto corrupto o mal extraído.
3. Mezcla de idiomas no deseada.
4. Contenido tóxico o de baja calidad.
5. Sesgos de dominio demasiado fuertes.

Si entrenas con datos sucios, el modelo aprende ruido. Y el ruido no solo baja la calidad: también puede hacer más lento el aprendizaje y empeorar la estabilidad del entrenamiento. En modelos grandes, una mala mezcla de datos puede costar semanas de cómputo.

Arquitectura: el transformer sigue siendo el centro

Cuando la gente habla de LLM, casi siempre piensa en transformers. Con razón. Aunque hay variantes y mejoras, el transformer sigue siendo la arquitectura base para la mayoría de modelos de lenguaje modernos. CS336 te lleva a entender por qué funciona, qué problemas resuelve y qué límites todavía tiene.

La clave está en el self-attention. En lugar de procesar la secuencia palabra por palabra como en modelos más antiguos, el transformer puede relacionar posiciones distintas del texto en paralelo. Eso acelera el entrenamiento y mejora la capacidad de capturar dependencias largas. Pero no es magia: también aumenta el costo de memoria y hace que el escalado sea un tema serio.

Si quieres ver cómo se implementan estas ideas en código real, la documentación de PyTorch sobre módulos y autograd es una buena referencia práctica: https://pytorch.org/docs/stable/nn.html . No necesitas memorizar toda la API, pero sí entender cómo se conectan capas, tensores y gradientes.

Attention, embeddings y posición

La arquitectura se sostiene sobre tres piezas que conviene entender por separado:

• Embeddings: convierten tokens en vectores densos.
• Positional encoding: le da al modelo información sobre el orden.
• Attention: decide qué partes de la secuencia pesan más para cada token.

La combinación de esas piezas permite que el modelo aprenda patrones de sintaxis, contexto y coocurrencia. Pero si una de ellas está mal configurada, el rendimiento cae. Por ejemplo, una mala estrategia de posiciones puede afectar secuencias largas, y un embedding mal entrenado puede dejar fuera matices importantes del vocabulario.

Tabla comparativa de piezas del modelo

Lo útil de esta tabla es que te obliga a pensar en fallas concretas. No es “el modelo funciona o no funciona”. Es: ¿en qué parte del pipeline se rompió la calidad?

Entrenamiento: donde se gana o se pierde todo

Entrenar un LLM no es solo correr epochs. Es un problema de optimización a gran escala, con memoria limitada, gradientes inestables y muchísima sensibilidad a hiperparámetros. CS336 hace bien en poner foco en esta parte, porque ahí es donde se separa la teoría bonita de un modelo que realmente aprende.

La función de pérdida más común en language modeling sigue siendo cross-entropy sobre el siguiente token. Parece simple, pero su comportamiento depende de la distribución de datos, del tamaño del batch, del schedule de learning rate y de cómo manejas el clipping de gradientes. Si uno de esos elementos está mal, puedes ver loss bajando y aun así tener un modelo mediocre.

En entrenamiento serio, también importa el cómputo distribuido. No todos tienen acceso a decenas de GPUs, pero entender cómo se reparte el trabajo te ayuda a leer papers, estimar costos y depurar cuellos de botella. Si quieres profundizar en fundamentos de entrenamiento distribuido, la documentación de PyTorch Distributed es una referencia oficial útil: https://pytorch.org/docs/stable/distributed.html .

Hiperparámetros que sí mueven la aguja

Hay parámetros que parecen secundarios y en realidad cambian mucho el resultado. Estos son algunos de los más relevantes:

• Learning rate: demasiado alto puede destruir el entrenamiento; demasiado bajo lo vuelve lento.
• Batch size: afecta estabilidad, uso de memoria y throughput.
• Weight decay: ayuda a regularizar, pero mal calibrado degrada el ajuste.
• Warmup steps: suavizan el arranque del entrenamiento.
• Gradient clipping: reduce explosiones de gradiente.

No necesitas adivinar. En la práctica, se hacen barridos controlados y se observan curvas. El objetivo no es que el loss baje rápido, sino que baje de manera estable y que la validación acompañe.

Cómo leer una curva de entrenamiento

Una curva de loss bien interpretada te dice mucho. Si el loss de entrenamiento cae pero el de validación se estanca, probablemente estás sobreajustando. Si ambos se quedan planos desde el inicio, puede haber un problema de datos, arquitectura o learning rate. Si el loss oscila demasiado, sospecha de batch size, schedule o clipping.

En equipos pequeños, una práctica útil es registrar al menos estos datos por corrida:

1. Número total de tokens vistos.
2. Learning rate máximo y schedule.
3. Batch size efectivo.
4. Pérdida de entrenamiento y validación.
5. Throughput en tokens por segundo.
6. Uso de memoria por GPU.

Con esos seis puntos ya puedes comparar experimentos de forma seria, sin depender de impresiones.

Evaluación y alineamiento: medir algo más que perplexity

Un error común es creer que un buen LLM es solo el que baja más la perplexity. Esa métrica sirve, pero no alcanza. Puedes tener un modelo con buena pérdida en validación y aun así obtener respuestas malas, inconsistentes o poco útiles para usuarios reales. CS336 empuja a mirar evaluación con más cuidado.

La evaluación moderna mezcla varias capas: métricas automáticas, benchmarks, pruebas humanas y análisis de fallos. No hay una sola cifra que resuma todo. Si tu caso de uso es soporte al cliente en español, por ejemplo, te importa tanto la exactitud como el tono, la seguridad y la capacidad de seguir instrucciones.

También entra aquí el alineamiento. Después del pretraining, muchos modelos pasan por instruction tuning o técnicas relacionadas con preferencias humanas. Eso no reemplaza el entrenamiento base, pero sí adapta el comportamiento a usos concretos. Entender esa diferencia evita que confundas “modelo grande” con “modelo útil”.

Perplexity no lo cuenta todo

Perplexity mide qué tan bien predice el siguiente token, pero no siempre correlaciona con utilidad final. Un modelo puede tener buena perplexity y aun así fallar al seguir instrucciones, inventar datos o responder de forma inconsistente en tareas de razonamiento.

Por eso conviene evaluar con tareas concretas. Si tu producto es para educación, prueba preguntas reales de estudiantes. Si es para atención al cliente, usa conversaciones reales anonimizadas. Si es para programación, mide precisión en snippets y consistencia en lenguajes específicos.

Qué cambia cuando alineas un modelo

Alinear un modelo no significa “hacerlo más inteligente” en abstracto. Significa ajustar su comportamiento para que sea más útil bajo ciertas reglas. Eso puede incluir seguir instrucciones, reducir respuestas tóxicas, o priorizar formatos específicos.

En términos prácticos, alineamiento puede cambiar:

• La longitud promedio de respuesta.
• La tasa de rechazo ante prompts sensibles.
• La consistencia en formatos estructurados.
• La preferencia por respuestas seguras frente a respuestas arriesgadas.

Eso tiene impacto directo en producto. Un modelo alineado puede sentirse mejor para el usuario final aunque su métrica base no cambie mucho.

Cómo te sirve este curso si trabajas en Latinoamérica

En nuestra región, el reto no es solo aprender IA. Es aprender a hacerlo con restricciones reales: menos acceso a GPUs, presupuestos más ajustados, datasets más pequeños y necesidades de producto muy concretas. Ahí CS336 puede servir como filtro contra la improvisación.

Si entiendes el proceso completo, puedes tomar decisiones más inteligentes. Tal vez no te conviene entrenar un modelo desde cero para un caso de uso pequeño. Tal vez te conviene afinar uno existente con datos propios. O tal vez te conviene invertir primero en evaluación y calidad de datos antes que en más parámetros. Ese tipo de decisiones ahorra tiempo y dinero.

También te ayuda a conversar mejor con perfiles técnicos y no técnicos. Si trabajas en una startup en México, Colombia, Chile, Perú o Ecuador, poder explicar por qué un tokenizador afecta el costo o por qué el batch size impacta la estabilidad te da una ventaja clara. No estás repitiendo buzzwords; estás hablando con criterio.

Ruta práctica para aprovechar el curso

Si quieres sacarle jugo sin perderte, puedes seguir esta ruta:

1. Lee la estructura general del curso en la web oficial.
2. Repasa fundamentos de PyTorch y autograd.
3. Implementa un tokenizer simple y mide cuántos tokens produce en español.
4. Entrena un modelo pequeño con un corpus reducido.
5. Observa loss, validación y throughput.
6. Compara resultados con distintos learning rates y batch sizes.
7. Recién después sube complejidad.

Ese orden importa. Si empiezas por escalar, te pierdes el aprendizaje técnico. Si empiezas por lo pequeño, entiendes por qué lo grande se vuelve caro.

Tabla resumen

Si te interesa construir criterio técnico real sobre LLM, este curso vale la pena aunque no lo sigas completo. Te obliga a mirar lo que normalmente se esconde detrás de una API: datos, tokens, gradientes, memoria y evaluación. Y eso, para cualquiera que quiera trabajar en IA con seriedad, ya es una ventaja.