Docker, PyTorch, Shakespeare y TinyStories para construir un modelo miniatura desde cero
Lic. Carlos Enrique Loria Beeche
Esta es la segunda parte de la serie Entrena tu propio LLM.
En la primera entrega abrimos la caja negra: explicamos qué son los tokens, los embeddings, los parámetros, la atención, los Transformers, el entrenamiento y la generación autorregresiva.
Puede leerla aquí:
Entrena tu propio LLM: del dragón a un modelo de lenguaje
Ahora sí nos arremangaremos.
En esta segunda parte prepararemos el entorno, revisaremos el hardware disponible, ejecutaremos código, entrenaremos un pequeño GPT con Shakespeare y después avanzaremos hacia TinyStories.
No construiremos un competidor de los grandes modelos comerciales. Construiremos algo mucho más útil para aprender: un modelo pequeño, visible, modificable y suficientemente sencillo como para observar qué ocurre en cada etapa.
Qué vamos a construir
El laboratorio tendrá dos fases.
Primera fase: Shakespeare
Entrenaremos un modelo pequeño que trabaja con caracteres.
Este experimento nos permitirá observar:
- cómo se construye un vocabulario;
- cómo se codifica el texto;
- cómo se forman los lotes;
- cómo se calcula la pérdida;
- cómo se actualizan los parámetros;
- cómo se guarda un checkpoint;
- cómo se genera texto nuevo.
Segunda fase: TinyStories
Después utilizaremos un corpus mucho mayor y tokenización por subpalabras.
Con TinyStories podremos observar cómo un modelo pequeño comienza a producir:
- oraciones completas;
- personajes;
- acciones;
- estructuras narrativas;
- pequeños desenlaces.
Qué necesitaremos
Para completar el laboratorio necesitaremos:
- una computadora con Windows o Linux;
- al menos 8 GB de memoria RAM;
- varios gigabytes de espacio libre;
- conexión a Internet;
- Docker;
- Git;
- paciencia para observar el entrenamiento.
Una GPU NVIDIA puede acelerar considerablemente el proceso, pero no es obligatoria para comenzar.
El modelo de Shakespeare puede ejecutarse únicamente con CPU. Será más lento, pero suficiente para estudiar todo el recorrido.
TinyStories se beneficia mucho más de una GPU, aunque también podremos realizar pruebas cortas con CPU.
Por qué utilizaremos Docker
Podríamos instalar Python, PyTorch y las demás dependencias directamente en el sistema operativo.
Sin embargo, para este laboratorio utilizaremos Docker.
Docker nos permite crear un entorno controlado que contiene:
- una versión concreta de Python;
- PyTorch;
- NumPy;
- tiktoken;
- las demás librerías necesarias;
- una carpeta de trabajo reproducible.
Podemos imaginarlo como una pequeña caja que contiene nuestro laboratorio.
Dentro de ella tendremos el mismo entorno aunque cambiemos de computadora.
Esto reduce conflictos entre versiones y facilita repetir el experimento.
CPU y GPU
CPU
La CPU es el procesador general de la computadora.
Es adecuada para:
- ejecutar el código;
- preparar datos;
- probar modelos pequeños;
- realizar entrenamientos cortos;
- comprender el proceso.
Su desventaja es que el entrenamiento de redes neuronales puede ser lento, porque requiere grandes cantidades de operaciones matriciales.
GPU
Una GPU está diseñada para ejecutar muchas operaciones similares en paralelo.
Esto resulta especialmente útil para:
- multiplicación de matrices;
- atención;
- cálculo de gradientes;
- procesamiento de lotes;
- entrenamiento de redes neuronales.
Una GPU NVIDIA compatible con CUDA puede reducir considerablemente el tiempo de entrenamiento.
Sin embargo, no basta con que la computadora tenga una GPU instalada. También necesitamos:
- un controlador apropiado;
- una versión compatible de CUDA;
- una distribución de PyTorch con soporte para CUDA;
- acceso a la GPU desde Docker.
RAM y VRAM
El entrenamiento necesita memoria para almacenar mucho más que los parámetros del modelo.
Durante cada paso también se conservan:
- activaciones intermedias;
- gradientes;
- estados del optimizador;
- secuencias de entrada;
- resultados temporales.
La memoria principal de la computadora se denomina RAM.
La memoria propia de una GPU dedicada se denomina VRAM.
Si una GPU dispone de poca VRAM, podemos reducir:
- el tamaño del modelo;
- el tamaño del lote;
- la longitud del contexto;
- la cantidad de ejemplos procesados simultáneamente.
En un NVIDIA Jetson, la CPU y la GPU comparten la misma memoria física. Esto exige mayor cuidado al seleccionar el tamaño del lote.
La duración dependerá del equipo
La primera parte conceptual podía leerse en una sola sesión.
El laboratorio real no tiene una duración fija.
La duración dependerá de:
- el procesador;
- la GPU;
- la memoria disponible;
- la velocidad del almacenamiento;
- el tamaño del lote;
- la cantidad de pasos;
- el modelo seleccionado;
- la configuración de PyTorch.
La meta no es terminar lo más rápido posible.
La meta es observar cómo aprende el modelo.
Instalar Docker en Windows
En Windows utilizaremos Docker Desktop.
Docker Desktop ejecuta contenedores Linux mediante WSL2, el Subsistema de Windows para Linux.
Después de instalarlo debemos comprobar que:
- Docker Desktop está iniciado;
- WSL2 está habilitado;
- el motor de Docker está funcionando;
- la consola reconoce el comando
docker.
Desde PowerShell:
docker version
docker compose versionTambién podemos comprobar WSL:
wsl --status
wsl --list --verboseLa distribución utilizada por Docker debe trabajar con la versión 2.
Instalar Docker en Linux
En Linux utilizaremos Docker Engine y el complemento Docker Compose.
Después de la instalación verificamos:
docker version
docker compose versionTambién conviene comprobar que el usuario puede ejecutar Docker:
docker psSi aparece un error de permisos, puede ser necesario agregar el usuario al grupo docker y volver a iniciar la sesión.
NVIDIA y Docker
En una computadora Linux con GPU NVIDIA, podemos comprobar primero el controlador:
nvidia-smiLuego verificamos si Docker reconoce el runtime de NVIDIA:
docker info | grep -Ei "runtimes|nvidia|default runtime"En Windows con Docker Desktop, la aceleración NVIDIA se proporciona mediante WSL2.
En Jetson debemos utilizar imágenes compatibles con JetPack y L4T. No debemos asumir que una imagen genérica de Python utilizará automáticamente la GPU integrada.
Descargar el código del laboratorio
Utilizaremos los ejemplos publicados por Gary Explains.
Desde PowerShell o una terminal de Linux:
git clone https://github.com/garyexplains/examples.git
cd examplesDentro de la carpeta encontraremos, entre otros, estos dos proyectos:
tinynanogpt_chartok
tinystoriesgptEl primero utiliza tokenización por caracteres y Shakespeare.
El segundo utiliza TinyStories y tokenización por subpalabras.
Qué contiene el repositorio
Encontraremos archivos como:
train.py
generate.py
model.py
data/Sus funciones generales serán:
model.py: define la arquitectura;train.py: entrena el modelo;generate.py: utiliza un checkpoint para producir texto;data/: contiene o recibe el dataset.
No necesitamos comprender inmediatamente cada línea.
Primero ejecutaremos el proyecto. Después relacionaremos el código con los conceptos de la primera parte.
Crear el entorno Docker
En la carpeta examples creamos un archivo llamado Dockerfile.
FROM python:3.12-slim
WORKDIR /workspace
RUN python -m pip install --no-cache-dir --upgrade pip && \
python -m pip install --no-cache-dir \
torch \
numpy \
tqdm \
tiktoken \
huggingface_hub
CMD ["bash"]Qué significa cada línea
FROM python:3.12-slim utiliza una imagen ligera que ya contiene Python 3.12.
WORKDIR /workspace define la carpeta principal dentro del contenedor.
El bloque RUN instala las dependencias.
CMD ["bash"] indica que queremos abrir una consola Bash al iniciar.
Crear compose.yaml
En la misma carpeta creamos:
services:
llm-lab:
build: .
working_dir: /workspace
volumes:
- .:/workspace
stdin_open: true
tty: trueLa línea:
volumes:
- .:/workspacecomparte la carpeta actual con la carpeta /workspace del contenedor.
Esto significa que:
- el código permanece en la computadora;
- el contenedor puede utilizarlo;
- los checkpoints quedan guardados fuera del contenedor;
- no perdemos los resultados cuando el contenedor termina.
Construir la imagen
docker compose buildEntrar al contenedor
docker compose run --rm llm-labDentro veremos una consola semejante a:
root@contenedor:/workspace#Verificar PyTorch
Primero comprobamos que PyTorch esté instalado:
python -c "import torch; print(torch.__version__)"Luego consultamos el dispositivo disponible:
python -c "import torch; print('CUDA disponible:', torch.cuda.is_available()); print('Dispositivo:', torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'CPU')"Una salida basada en CPU será semejante a:
CUDA disponible: False
Dispositivo: CPUUna salida con GPU NVIDIA será semejante a:
CUDA disponible: True
Dispositivo: NVIDIA Quadro P3200Esta comprobación es decisiva.
Que nvidia-smi funcione en el sistema anfitrión no garantiza que PyTorch dentro del contenedor pueda utilizar la GPU.
Precaución con la imagen genérica
El Dockerfile anterior constituye un entorno sencillo y reproducible para CPU.
La instalación genérica:
pip install torchno siempre instalará la variante CUDA adecuada para cada equipo.
Para utilizar una GPU NVIDIA convencional puede ser necesario:
- utilizar una imagen oficial de PyTorch con CUDA;
- instalar la distribución CUDA recomendada por PyTorch;
- asignar la GPU al contenedor.
Para Jetson necesitaremos una imagen compatible con L4T.
Por eso conviene separar dos fases:
- comprobar que el laboratorio funciona con CPU;
- preparar la aceleración adecuada para cada plataforma.
Primera práctica: Shakespeare
Entramos en la carpeta:
cd tinynanogpt_chartokPodemos revisar sus archivos:
lsEl dataset se encuentra en:
data/shakespeare.txtEl archivo contiene algo más de un millón de caracteres de obras de Shakespeare.
Por qué comenzar con caracteres
En este primer modelo, cada carácter será un token.
Por ejemplo:
To bese divide así:
["T", "o", " ", "b", "e"]Esto reduce considerablemente el vocabulario.
En vez de utilizar decenas de miles de tokens, trabajaremos con aproximadamente 65 caracteres distintos.
El modelo deberá aprender por sí mismo:
- cómo se forman las palabras;
- dónde aparecen los espacios;
- cómo se utiliza la puntuación;
- cómo se estructuran los diálogos;
- qué secuencias de caracteres son frecuentes.
No es la estrategia más eficiente para un modelo grande, pero es excelente para estudiar el proceso.
Ejecutar el entrenamiento
python train.pyEl programa mostrará información semejante a:
Using device: cpu
Dataset: 1,115,394 chars, vocab size: 65
Model: 6L/6H/384D, 10.8M paramsLa abreviatura 6L/6H/384D indica:
- 6 capas;
- 6 cabezas de atención;
- embeddings de 384 dimensiones.
El modelo posee aproximadamente 10,8 millones de parámetros.
Qué veremos durante el entrenamiento
El programa mostrará periódicamente:
- el paso actual;
- la pérdida de entrenamiento;
- la pérdida de validación;
- muestras de texto;
- checkpoints guardados.
Al principio, el texto será casi completamente aleatorio.
xqJ:
Wz!aRTDespués de algunos pasos comenzarán a aparecer espacios, palabras incompletas, signos de puntuación, nombres y estructuras parecidas a diálogos.
No significa que el modelo comprenda Shakespeare. Significa que sus parámetros están aprendiendo regularidades estadísticas presentes en el corpus.
Una prueba corta
Podemos ejecutar solamente 100 pasos para comprobar el funcionamiento:
python -c "from train import train; train('./data/shakespeare.txt', max_steps=100)"O 500 pasos para una demostración más visible:
python -c "from train import train; train('./data/shakespeare.txt', max_steps=500)"Esta prueba servirá también para comparar diferentes equipos.
Guardar el aprendizaje
Durante el entrenamiento se generan archivos de checkpoint.
Al finalizar veremos algo semejante a:
checkpoint_final.ptEste archivo contiene:
- los parámetros aprendidos;
- la configuración del modelo;
- el vocabulario;
- la información necesaria para generar texto.
El código define la arquitectura.
El checkpoint contiene lo que esa arquitectura aprendió.
Generar texto con el modelo
Una vez creado el checkpoint podemos ejecutar:
python generate.py checkpoint_final.pt \
--prompt "To be or not to be" \
--max_new_tokens 300El parámetro --prompt proporciona el texto inicial.
--max_new_tokens 300 indica cuántos tokens nuevos queremos generar.
Qué debemos esperar
Después de un entrenamiento corto, el texto puede ser incoherente.
Sin embargo, ya podríamos observar:
- palabras parecidas al inglés;
- mayúsculas;
- saltos de línea;
- nombres inventados;
- puntuación teatral;
- fragmentos con ritmo similar al corpus.
El objetivo no es obtener una obra literaria.
El objetivo es comprobar que un conjunto de parámetros inicialmente aleatorios puede aprender patrones mediante la predicción repetida del siguiente carácter.
Mirar dentro del mini-GPT
Ahora relacionaremos el código con las piezas conceptuales explicadas en la primera parte.
Del texto a identificadores numéricos
El programa construye el vocabulario a partir de los caracteres presentes en Shakespeare.
chars = sorted(list(set(text)))
vocab_size = len(chars)Luego crea dos conversiones:
- encode: texto a números;
- decode: números a texto.
stoi = {caracter: indice for indice, caracter in enumerate(chars)}
itos = {indice: caracter for indice, caracter in enumerate(chars)}Cómo se preparan los ejemplos
El texto se convierte en una secuencia larga de números y luego se extraen fragmentos.
Supongamos:
dragónLa entrada podría ser:
[d, r, a, g, ó]y los objetivos:
[r, a, g, ó, n]Para cada posición, el objetivo es el token que aparece inmediatamente después.
La longitud de contexto
Nuestro mini-GPT utiliza una ventana de contexto de 256 caracteres.
Una ventana mayor permitiría utilizar más texto anterior, pero incrementaría:
- el consumo de memoria;
- la cantidad de operaciones;
- el tiempo de entrenamiento.
Embeddings de tokens y posición
La arquitectura contiene una tabla de embeddings.
Si el vocabulario tiene 65 caracteres y cada embedding posee 384 valores, la matriz tendrá:
65 × 384También existe una tabla para representar las posiciones.
La representación inicial se obtiene sumando:
embedding del token
+
embedding de su posiciónQueries, keys y values
Dentro de la atención, cada representación se transforma en:
- query;
- key;
- value.
El modelo compara queries con keys y utiliza esas puntuaciones para combinar los values.
La máscara causal
Antes de normalizar las puntuaciones, el programa bloquea las posiciones futuras.
1 0 0 0
1 1 0 0
1 1 1 0
1 1 1 1Así, cada posición solo puede observarse a sí misma y a las posiciones anteriores.
Atención de múltiples cabezas
Nuestro modelo utiliza seis cabezas.
Cada una puede aprender diferentes patrones, como puntuación, nombres, saltos de línea, diálogos o secuencias frecuentes.
La red feed-forward
Después de la atención, cada posición atraviesa una red adicional.
384 valores
↓
1536 valores
↓
384 valoresLa atención combina información entre tokens.
La red feed-forward transforma la información resultante dentro de cada posición.
Dropout
Durante el entrenamiento, algunas conexiones pueden desactivarse temporalmente de forma aleatoria.
Esto ayuda a reducir el sobreajuste.
En PyTorch:
model.train()se utiliza para entrenamiento, y:
model.eval()para inferencia.
La salida del modelo
Después de los bloques Transformer, la representación final se proyecta hacia el tamaño del vocabulario.
Si existen 65 tokens posibles, el modelo produce 65 puntuaciones para cada posición.
Estas puntuaciones son los logits.
El paso completo de aprendizaje
logits, loss = model(x, y)
optimizer.zero_grad()
loss.backward()
optimizer.step()Podemos traducirlo así:
- el modelo recibe entradas y objetivos;
- calcula predicciones;
- calcula la pérdida;
- borra gradientes anteriores;
- obtiene los gradientes actuales;
- actualiza los parámetros.
Este es el corazón del entrenamiento.
Cómo decide qué token generar
Durante la inferencia, el modelo calcula las probabilidades del siguiente token.
Podríamos seleccionar siempre el más probable. Eso se denomina greedy decoding.
Sin embargo, normalmente se utiliza muestreo probabilístico.
Temperatura
Una temperatura baja concentra la probabilidad en los candidatos principales.
Una temperatura alta aumenta la variedad, pero también el riesgo de incoherencia.
Top-k
top_k limita la selección a los candidatos más probables.
Por ejemplo:
top_k = 20descarta todos los tokens excepto los 20 más probables.
Generación autorregresiva
Después de seleccionar un token, se agrega a la secuencia.
El modelo vuelve a calcular la siguiente distribución y repite el proceso.
Cada nuevo token pasa a formar parte del contexto.
Por eso los errores también pueden acumularse.
Segunda práctica: TinyStories
El experimento con Shakespeare permite comprender con claridad el mecanismo, pero tiene dos limitaciones:
- utiliza un dataset pequeño;
- trabaja con caracteres.
Ahora avanzaremos hacia un corpus mayor y tokenización por subpalabras.
Qué es TinyStories
TinyStories es un dataset formado por cuentos breves con vocabulario y estructuras sencillas.
Contiene:
- personajes;
- objetos;
- acciones;
- pequeños conflictos;
- relaciones causales;
- desenlaces simples.
Su lenguaje reducido permite que modelos relativamente pequeños aprendan a producir textos narrativos más coherentes.
Por qué es útil
Entrenar con texto adulto general exige aprender un vocabulario enorme, múltiples estilos, referencias culturales y estructuras complejas.
TinyStories reduce parte de esa complejidad.
El modelo puede concentrarse en patrones narrativos sencillos.
Diferencia principal con Shakespeare
El modelo de Shakespeare utiliza aproximadamente 65 caracteres.
TinyStories utiliza un tokenizador de subpalabras con decenas de miles de tokens.
Eso aumenta considerablemente el tamaño de las capas de embeddings y salida.
Descargar TinyStories
cd /workspace/tinystoriesgpt
mkdir -p dataLuego:
hf download roneneldan/TinyStories \
TinyStories-train.txt \
--repo-type dataset \
--local-dir dataAl finalizar tendremos:
data/TinyStories-train.txtTokenización inicial
El proyecto utiliza tiktoken.
encoder = tiktoken.get_encoding("gpt2")
tokens = encoder.encode(text)La salida ya no representa caracteres individuales.
Puede contener palabras completas, fragmentos frecuentes, signos y espacios asociados a palabras.
Configurar un modelo de aproximadamente 24 millones de parámetros
Utilizaremos:
python train.py data/TinyStories-train.txt \
--n_layer 6 \
--n_head 5 \
--n_embd 320 \
--max_steps 500Esta configuración utiliza:
- 6 capas;
- 5 cabezas de atención;
- embeddings de 320 dimensiones;
- aproximadamente 23,6 millones de parámetros;
- 500 pasos para una prueba inicial.
Los 500 pasos no bastarán para obtener un modelo de calidad.
Sí permitirán comprobar que:
- el dataset funciona;
- el modelo cabe en memoria;
- la pérdida comienza a descender;
- el checkpoint se guarda;
- podemos generar una primera muestra.
Entrenamiento más prolongado
python train.py data/TinyStories-train.txt \
--n_layer 6 \
--n_head 5 \
--n_embd 320 \
--max_steps 5000Con CPU puede tardar muchas horas.
Con GPU será más rápido, aunque el tamaño del lote y la memoria seguirán siendo importantes.
Reducir el tamaño del lote
Si aparece un error de memoria:
python train.py data/TinyStories-train.txt \
--n_layer 6 \
--n_head 5 \
--n_embd 320 \
--batch_size 8 \
--max_steps 500Un lote menor consume menos memoria.
La desventaja es que puede utilizar peor la GPU y producir gradientes más variables.
Interrumpir y continuar el entrenamiento
El entrenamiento puede guardarse en checkpoints.
Cada cierto número de pasos se actualiza:
checkpoint_latest.ptAl alcanzar el límite se genera:
checkpoint_final.ptPara continuar:
python train.py data/TinyStories-train.txt \
--resume checkpoint_latest.pt \
--max_steps 10000La cantidad indicada en --max_steps representa el total final deseado.
No significa “agregar 10.000 pasos”.
Si el checkpoint estaba en 5.000, continuará hasta 10.000.
Continuar desde una prueba corta
Si realizamos solamente 500 pasos, podremos continuar desde:
checkpoint_final.ptcon:
python train.py data/TinyStories-train.txt \
--resume checkpoint_final.pt \
--max_steps 5000Generar una historia
python generate.py checkpoint_final.pt \
--prompt "Once upon a time" \
--max_new_tokens 300En las primeras etapas podríamos obtener palabras sueltas, repeticiones y frases incompletas.
Con más entrenamiento comenzarán a aparecer:
- oraciones;
- personajes;
- acciones;
- estructuras narrativas;
- pequeños desenlaces.
Qué debemos observar
No debemos evaluar únicamente si el cuento “nos gusta”.
Conviene observar:
- si las palabras están bien formadas;
- si las oraciones tienen estructura;
- si mantiene personajes;
- si utiliza puntuación;
- si repite frases;
- si completa ideas;
- si la pérdida de validación mejora;
- si aparecen signos de sobreajuste.
Comparar Shakespeare y TinyStories
| Característica | Shakespeare | TinyStories |
|---|---|---|
| Tokenización | Caracteres | Subpalabras |
| Vocabulario | Aproximadamente 65 | Decenas de miles |
| Dataset | Cerca de 1 MB | Mucho mayor |
| Modelo | Aproximadamente 10,8 millones | Aproximadamente 23,6 millones |
| Aprendizaje inicial | Letras, palabras y estilo | Oraciones y narraciones sencillas |
| Tiempo | Relativamente corto | Varias horas según hardware |
| Objetivo | Comprender el mecanismo | Observar mayor coherencia lingüística |
Los dos experimentos utilizan el mismo principio:
predecir el siguiente token y ajustar los parámetros cuando la predicción resulta incorrecta.
Cuatro computadoras reales
Para este laboratorio compararemos cuatro equipos muy distintos.
MICHELLE
Una portátil Windows convencional con procesador Intel Core i5, 32 GB de RAM y gráficos integrados.
Representa el escenario de una computadora doméstica sin GPU dedicada.
LEON
Un equipo Windows con procesador Intel Core i9-14900HX, 32 GB de RAM y gráficos integrados.
Su CPU es mucho más potente, pero sigue sin disponer de una GPU NVIDIA dedicada.
PANTERA
Una estación Linux con procesador Xeon, 64 GB de RAM y una NVIDIA Quadro P3200 con 6 GB de VRAM.
Será el equipo más apropiado para observar la aceleración CUDA en una GPU convencional.
TURING
Un Jetson Orin Nano Super con arquitectura ARM64, 8 GB de memoria compartida y GPU integrada.
Representa un entorno de inteligencia artificial en el borde, con recursos limitados pero aceleración NVIDIA.
Qué compararemos
En cada equipo podremos medir:
- tiempo por paso;
- pasos por segundo;
- uso de CPU;
- uso de GPU;
- consumo de memoria;
- facilidad de instalación;
- estabilidad;
- capacidad para continuar entrenamientos largos.
Una prueba de 100 pasos con Shakespeare permitirá obtener una comparación inicial.
Después podremos repetir con TinyStories y tamaños de lote ajustados a cada equipo.
Qué habremos demostrado
Al finalizar este laboratorio habremos construido y entrenado dos modelos pequeños.
Habremos observado directamente:
- cómo el texto se transforma en tokens;
- cómo se preparan los ejemplos;
- cómo se ejecuta un Transformer;
- cómo se calcula la pérdida;
- cómo la retropropagación obtiene gradientes;
- cómo el optimizador modifica los parámetros;
- cómo se guarda el aprendizaje;
- cómo se genera texto token por token;
- cómo influyen el dataset y el hardware.
Nuestros modelos serán pequeños, limitados y muy inferiores a un sistema comercial.
Pero contendrán las piezas fundamentales.
Eso es precisamente lo que hace valioso el experimento.
Del concepto a la experiencia
En la primera parte vimos los tokens, embeddings, parámetros, atención y Transformers como conceptos.
Ahora los hemos convertido en archivos, comandos, matrices, pérdidas, checkpoints y muestras de texto.
El dragón dejó de ser solamente una metáfora.
Lo vimos aprender.
Lo vimos equivocarse.
Lo vimos mejorar.
Y, sobre todo, comprobamos que comprender un LLM no requiere comenzar con miles de millones de parámetros.
Puede comenzar con una terminal, un pequeño corpus, un modelo modesto y la curiosidad suficiente para observar cada paso.
Ahora sí hemos comenzado a entrenar nuestro propio dragón.
Primera parte de esta serie
Este laboratorio es la continuación de una introducción conceptual en la que explicamos qué son los tokens, embeddings, parámetros, Transformers, atención, contexto, entrenamiento e inferencia.
Si llegó directamente a esta segunda entrega, puede comenzar por aquí:
Entrena tu propio LLM: del dragón a un modelo de lenguaje
Fuentes, código y herramientas
- Gary Explains: repositorio de ejemplos — contiene los proyectos
tinynanogpt_chartokytinystoriesgpt. - Train Your Own LLM From Scratch
- nanoGPT, de Andrej Karpathy
- TinyStories: How Small Can Language Models Be and Still Speak Coherent English?
- Dataset TinyStories en Hugging Face
- Documentación oficial de PyTorch
- Documentación oficial de Docker