Capítulo 01

Facsímil 3 · Arquitecturas y modelos

Capítulo 01: Qué es un LLM: modelo, parámetros y escala

El objeto que hay detrás del chat

Cuando alguien dice «he usado una IA», casi nunca se refiere al sistema completo. Se refiere a una experiencia: una caja de texto, una respuesta, quizá una voz o una imagen. Pero debajo de esa experiencia hay varias piezas: una interfaz, una API, reglas de producto, herramientas, bases de datos, filtros, cachés y, en el centro, un modelo.

Este capítulo va de ese centro. No del producto de chat. No del proveedor. No del envoltorio. Del objeto técnico que hace posible que escribas una frase y recibas otra frase: un LLM, un Large Language Model, o modelo de lenguaje de gran escala.

La pregunta no es solo «qué es». La pregunta buena es: ¿qué tipo de máquina matemática estoy usando?, ¿qué significan sus parámetros?, ¿por qué la escala cambia tanto el comportamiento?, ¿qué puedo esperar de él y qué no debería pedirle sin apoyo externo?

Qué no es un LLM

Un LLM no es una base de datos. Puede devolver datos que parecen almacenados, pero su mecanismo no consiste en buscar una fila exacta y traerla de vuelta. Si necesitas el saldo de una cuenta, el precio de un pedido o el estado real de un envío, necesitas consultar el sistema que contiene ese dato. El LLM puede ayudar a formular, resumir o explicar; no sustituye a la fuente de verdad.

Tampoco es un programa clásico lleno de reglas escritas a mano. Nadie ha codificado millones de condiciones del tipo «si el usuario pregunta por una receta, responde así». El comportamiento emerge de muchos números ajustados durante entrenamiento, no de una lista legible de instrucciones.

Y, aunque produzca lenguaje muy convincente, un LLM no es una persona que recuerda, razona y decide con intención. La forma honesta de pensarlo es más sobria: recibe tokens, los transforma en vectores, aplica muchas capas de álgebra lineal y devuelve una distribución de probabilidad sobre el siguiente token. Esa frase suena menos espectacular, pero es justo lo que necesitamos para poder construir con criterio.

Qué sí es un LLM

Un LLM es un modelo probabilístico que aprende patrones del lenguaje a gran escala. Su tarea base es sencilla de enunciar: dado un contexto, estimar qué token viene después.¹

Si el contexto es:

La capital de Francia es

el modelo asigna puntuaciones a muchos tokens posibles. «París» debería recibir una puntuación alta. «azul» debería recibir una puntuación baja. «porque» quizá tenga una puntuación pequeña pero no imposible, dependiendo del contexto.

La idea moderna no empieza con los LLM actuales. Los modelos neuronales de lenguaje ya buscaban representar palabras como vectores y estimar probabilidades de secuencias antes de la explosión generativa reciente.² Lo que cambió después fue la arquitectura, los datos, el cómputo y la escala.

Por eso un LLM no es «una IA» en abstracto. Es una familia concreta de modelos: redes neuronales profundas entrenadas sobre enormes cantidades de texto y, en modelos multimodales, también otros tipos de datos. En este facsímil abriremos esa familia pieza a pieza.

Un poco de historia: cuándo empezó eso de «LLM»

Aquí hay una pequeña trampa histórica. Si preguntas «cuál fue el primer LLM», la respuesta depende de qué estés llamando LLM.

La expresión large language model aparece en la literatura bastante antes de ChatGPT. Un ejemplo temprano y muy claro es el paper de Google “Large Language Models in Machine Translation”, publicado en 2007, donde Brants y sus coautores hablaban de modelos de lenguaje enormes para mejorar traducción automática.³ Pero aquellos modelos no eran lo que hoy imaginas cuando dices LLM. Eran modelos estadísticos grandes, muy útiles, pero no redes Transformer generativas de propósito general.

La familia moderna se entiende mejor como una cadena:

Año	Hito	Por qué importa
1948	Shannon modela el lenguaje como una fuente estadística.	Abre la puerta a pensar el texto como secuencia de símbolos con probabilidades.
2003	Bengio y coautores proponen un modelo neuronal probabilístico de lenguaje.	Las palabras empiezan a representarse como vectores aprendidos, no solo como cuentas discretas.
2017	Transformer.	La atención permite entrenar modelos grandes de secuencias de forma mucho más paralela.⁴
2018	GPT-1.	OpenAI muestra que el preentrenamiento generativo seguido de adaptación a tareas funciona muy bien.⁵
2019	GPT-2.	La escala empieza a enseñar una idea fuerte: un modelo de lenguaje puede comportarse como aprendiz multitarea sin entrenarlo de nuevo para cada tarea.⁶
2020	GPT-3.	Con 175B parámetros, el paper populariza la idea de modelos capaces de hacer tareas con ejemplos en el propio prompt.⁷
2022	Modelos instruidos y chat.	El post-entrenamiento para seguir instrucciones convierte modelos generativos en asistentes mucho más útiles.

Así que, si somos precisos: el término «large language model» ya se usaba en papers antes de los Transformers modernos. Pero el LLM moderno que solemos tener en la cabeza nace de la combinación de Transformer, preentrenamiento generativo, escala, post-entrenamiento e interfaz conversacional.

Tres capas que conviene no mezclar

Para entender bien un LLM hay que separar tres niveles que en una app aparecen pegados. Si no los separamos, acabamos discutiendo frases como «este modelo es educado», «este modelo sabe usar herramientas» o «este modelo recuerda mi proyecto» sin saber qué parte del sistema produce cada comportamiento.

Modelo base. Es el modelo entrenado sobre grandes cantidades de texto para predecir el siguiente token. Aprende regularidades del lenguaje, código, formatos, estilos, relaciones estadísticas y patrones de razonamiento presentes en los datos. Pero un modelo base no tiene por qué comportarse como un asistente amable. Si le escribes una pregunta, puede continuar la pregunta, imitar un documento, cerrar una lista o producir algo extraño. Su entrenamiento principal no dice «ayuda al usuario»: dice «predice bien la continuación».

Modelo instruido. Después del preentrenamiento, muchos modelos pasan por una fase de ajuste para seguir instrucciones, responder en formato conversacional, rechazar peticiones que no debe completar y preferir respuestas útiles según ejemplos humanos o sintéticos.⁸ Esta capa explica por qué un modelo puede contestar «claro, te ayudo» en vez de limitarse a completar texto.

Sistema completo. Es lo que tú usas en producción: modelo, prompt de sistema, contexto recuperado, herramientas, validadores, memoria conversacional, permisos, logs, interfaz, evaluaciones y reglas de negocio. Cuando un asistente consulta una base de datos o llama a una función, eso no significa que el LLM sea una base de datos. Significa que el sistema que rodea al LLM le ha dado una herramienta y ha decidido cómo usar su salida.

Nivel	Qué aprende o contiene	Qué no conviene atribuirle
Modelo base	Patrones estadísticos del lenguaje y del código.	Obediencia conversacional fiable o conocimiento actualizado.
Modelo instruido	Preferencias de respuesta, formato, seguimiento de instrucciones y estilo de ayuda.	Acceso real a tus datos, herramientas o estado de la aplicación.
Sistema completo	Contexto externo, permisos, herramientas, validadores, trazas y experiencia de usuario.	Que todo el comportamiento venga «de dentro» del modelo.

Esta separación volverá mucho. En el facsímil 4, cuando hablemos de APIs y RAG, estaremos construyendo parte del sistema completo. En el facsímil 5, cuando hablemos de agentes, estaremos añadiendo decisiones, herramientas y memoria alrededor del modelo. En el facsímil 7, cuando evaluemos, tendremos que medir cada capa por separado: no es lo mismo fallar por un mal modelo que fallar por un mal contexto o por una herramienta mal diseñada.

La arquitectura interna de un LLM base

El LLM base típico de la familia GPT es un Transformer decoder-only autoregresivo. Suena largo, pero se puede leer despacio:

Transformer porque usa bloques de atención, MLP, conexiones residuales y normalización.

Decoder-only porque usa la parte generativa de la arquitectura Transformer: recibe una secuencia previa y genera continuación.

Autoregresivo porque predice el siguiente token usando tokens anteriores, añade ese token al contexto y repite el proceso.

La arquitectura interna mínima es esta:

Pieza	Qué hace	Qué debes recordar
Tokenizador	Convierte texto en IDs de token.	El modelo no recibe palabras; recibe enteros.
Embedding de token	Convierte cada ID en un vector.	Aquí el texto entra al espacio numérico.
Información de posición	Indica orden o distancia entre tokens.	Sin posición, la atención no sabe qué va antes o después.
Bloques Transformer	Repiten atención, MLP, residual y normalización.	Aquí se transforma la representación capa a capa.
Atención causal	Permite mirar hacia atrás, no hacia tokens futuros.	Hace honesta la predicción de izquierda a derecha.
MLP	Reprocesa cada token después de mezclar contexto.	No todo ocurre en atención; el MLP aporta mucha capacidad.
Cabeza de lenguaje	Proyecta el último vector al tamaño del vocabulario.	De aquí salen los logits.
Softmax y muestreo	Convierte logits en probabilidades y elige token.	Aquí aparecen temperature, `top_p`, `top_k` y decisiones de generación.

El flujo completo, dicho como sistema, sería:

texto -> tokens -> embeddings + posición -> bloques Transformer -> logits -> softmax -> siguiente token

En el capítulo 02 abriremos el tramo tokens -> embeddings -> tensores -> atención. En el capítulo 03 nos detendremos en Q, K, V y máscara causal. En el capítulo 04 veremos lo que pasa entre atenciones y cómo los logits se convierten en texto. Este capítulo solo coloca el mapa.

Dónde se encuentran los LLMs

Un LLM no vive solo en una web de chat. Puede aparecer en varios sitios, con formas muy distintas:

Lugar	Qué significa	Ejemplo de uso
API de proveedor	El modelo vive en infraestructura externa y tú lo llamas por red.	Chat, extracción, clasificación, generación de código, análisis de documentos.
Producto final	El usuario no ve el modelo; ve una función integrada.	Asistente en un editor, buscador mejorado, soporte interno, copiloto de datos.
Repositorio de pesos abiertos	Descargas pesos o variantes cuantizadas y los sirves tú.	Prototipos locales, investigación, privacidad, control de coste.
Runtime local	Un programa carga el modelo en tu máquina o servidor.	Ollama, LM Studio, Transformers, vLLM, SGLang o TensorRT-LLM, según caso.
Dispositivo o edge	Modelo pequeño o cuantizado ejecutado cerca del usuario.	Móvil, portátil, navegador, dispositivo industrial, app sin conexión estable.
Sistema de agentes	El LLM decide o ayuda a decidir pasos dentro de un bucle con herramientas.	Revisar un repositorio, consultar documentos, preparar tareas, ejecutar flujos internos.

La diferencia práctica es enorme. Un modelo por API puede darte calidad alta sin ocuparte del hardware, pero dependes de red, coste por uso y condiciones del proveedor. Un modelo local te da control y privacidad, pero te obliga a pelear con memoria, cuantización, runtime y actualizaciones. Un modelo dentro de un producto puede parecer «inteligente» porque el sistema le da contexto y herramientas, no porque el modelo por sí solo lo sepa todo.

Qué tipos de LLM podrías encontrarte

No todos los LLMs son iguales. Algunos nombres describen arquitectura, otros describen acceso, otros describen entrenamiento y otros describen despliegue. Mezclarlos es una fuente deliciosa de confusión.

Tipo	Qué significa	Pregunta útil
Base	Entrenado para continuar texto.	¿Necesito adaptarlo o usar una versión instruida?
Instruct o chat	Ajustado para seguir instrucciones y conversar.	¿Sigue bien formato, tono, límites y herramientas?
Denso	Activa casi todos sus parámetros relevantes por token.	¿Cuánto cuesta cada token frente a un MoE?
MoE	Tiene expertos y activa solo algunos por token.	¿Cuántos parámetros son totales y cuántos activos?
Text-only	Entrada y salida principalmente texto.	¿Mi caso necesita imagen, audio, vídeo o documentos complejos?
Multimodal	Acepta o genera más de un tipo de dato.	¿Qué modalidades acepta y cuáles produce realmente?
Open weights	Los pesos están disponibles bajo una licencia.	¿Puedo servirlo, modificarlo o usarlo comercialmente?
Propietario cerrado	Se usa por API o producto, sin acceso a pesos.	¿Me compensa calidad y mantenimiento frente a dependencia externa?
Modelo pequeño	Optimizado para coste, latencia o dispositivo.	¿La tarea requiere un modelo grande o solo uno fiable y barato?
Modelo de razonamiento	Dedica más presupuesto a pasos internos o deliberación.	¿La mejora compensa coste y latencia en mi evaluación?

Una misma familia puede ocupar varias filas a la vez: puede ser instruct, MoE, multimodal, open weights y además tener variantes cuantizadas para local. Por eso conviene leer las fichas con calma. El nombre comercial rara vez basta.

El mecanismo matemático mínimo

Un modelo de lenguaje autoregresivo factoriza una secuencia token a token. Si tenemos una secuencia:

x_1, x_2, \ldots, x_T

el modelo estima la probabilidad conjunta así:

P(x_1, x_2, \ldots, x_T) = \prod_{t=1}^{T} P(x_t \mid x_{<t}; \theta)

Símbolo	Significado	Ejemplo
$x_t$	Token en la posición $t$ .	En «la casa azul», $x_2$ podría ser «casa».
$x_{<t}$	Todos los tokens anteriores a la posición $t$ .	Para predecir «azul», el contexto previo es «la casa».
$T$	Longitud total de la secuencia.	Una frase de 12 tokens tiene $T = 12$ .
$\theta$	Conjunto de parámetros aprendidos del modelo.	Los miles de millones de pesos de una red.
$P(x_t \mid x_{<t}; \theta)$	Probabilidad de un token dado el contexto anterior y los parámetros.	$P(\text{azul} \mid \text{la casa})$ .

La expresión puede intimidar, pero dice algo cotidiano: para escribir una frase, el modelo predice el primer token, luego el segundo condicionado al primero, luego el tercero condicionado a los dos anteriores, y así hasta terminar. La respuesta larga aparece porque este paso se repite muchas veces.

Durante entrenamiento, el objetivo típico es minimizar la sorpresa del modelo ante el siguiente token correcto. Una forma de escribirlo es la pérdida de entropía cruzada negativa:

\mathcal{L}(\theta) = - \sum_{t=1}^{T} \log P_{\theta}(x_t \mid x_{<t})

Símbolo	Significado	Ejemplo
$\mathcal{L}(\theta)$	Pérdida que queremos reducir durante entrenamiento.	Cuanto menor, mejor predice el texto de entrenamiento.
$\log$	Logaritmo de la probabilidad.	Penaliza mucho asignar probabilidad muy baja al token correcto.
$P_{\theta}$	Probabilidad producida por el modelo con parámetros $\theta$ .	Si el modelo da 0,80 al token correcto, la pérdida baja.
$\sum_{t=1}^{T}$	Suma sobre todas las posiciones de la secuencia.	Se evalúa token por token.

Ejemplo pequeño. Imagina que el texto correcto es:

la casa azul

y el modelo asigna estas probabilidades a los tokens correctos:

Paso	Contexto previo	Token correcto	Probabilidad asignada
1	Inicio	la	0,50
2	la	casa	0,25
3	la casa	azul	0,80

La pérdida sería:

\mathcal{L} = -(\log 0{,}50 + \log 0{,}25 + \log 0{,}80)

Con logaritmo natural:

\mathcal{L} \approx -( -0{,}693 -1{,}386 -0{,}223 ) = 2{,}302

Si después de entrenar el modelo asigna 0,80, 0,60 y 0,95 a esos mismos tokens, la pérdida baja. Eso es aprender: ajustar parámetros para que el texto observado resulte menos sorprendente.

De logits a probabilidades

El modelo no empieza devolviendo probabilidades limpias. Primero produce logits: puntuaciones sin normalizar, una por cada token del vocabulario. Después usamos softmax para convertir esas puntuaciones en probabilidades:

P(x_i \mid c) = \frac{e^{z_i}}{\sum_{j=1}^{V} e^{z_j}}

Símbolo	Significado	Ejemplo
$x_i$	Token candidato número $i$ .	«París», «Madrid», «azul»...
$c$	Contexto que recibe el modelo.	«La capital de Francia es».
$z_i$	Logit del token $x_i$ .	$z_{\text{París}} = 5{,}1$ .
$V$	Tamaño del vocabulario del modelo.	50 000, 100 000 o más tokens posibles.
$e^{z_i}$	Exponencial del logit.	Convierte puntuaciones en valores positivos.

Supongamos tres candidatos:

Token	Logit
París	5,0
Lyon	2,0
azul	0,0

Aplicamos softmax:

P(\text{París}) = \frac{e^5}{e^5 + e^2 + e^0} \approx \frac{148{,}41}{156{,}80} \approx 0{,}947

P(\text{Lyon}) \approx 0{,}047, \quad P(\text{azul}) \approx 0{,}006

El modelo no «elige la verdad». Calcula una distribución. Luego el sistema de generación decide si toma el token más probable, si muestrea con temperatura, si restringe candidatos con top_p, o si aplica alguna regla adicional. Volveremos a esto en el capítulo 04.

Parámetros: la memoria no es una carpeta

La palabra parámetro suele crear confusión. Un parámetro no es una página guardada. No es una ficha con «París = capital de Francia». Es un número dentro de una matriz o un vector. Durante entrenamiento, esos números se ajustan para que las predicciones mejoren.⁹

Una capa lineal simple transforma una entrada así:

y = xW + b

Símbolo	Significado	Ejemplo
$x$	Vector o matriz de entrada.	Un token representado con $d_{in}=4$ números.
$W$	Matriz de pesos aprendidos.	Una tabla de $4 \times 3$ números.
$b$	Sesgo aprendido que se suma al resultado.	Un vector de 3 números.
$y$	Salida transformada.	Nuevo vector de $d_{out}=3$ números.

El número de parámetros de esa capa es:

N_{\text{params}} = d_{in} \cdot d_{out} + d_{out}

Si $d_{in}=4$ y $d_{out}=3$ :

N_{\text{params}} = 4 \cdot 3 + 3 = 15

Doce pesos en la matriz y tres sesgos. En un LLM real, estas matrices tienen miles de dimensiones y se repiten capa tras capa. Por eso hablamos de millones, miles de millones o billones de parámetros.

La intuición importante es esta: los parámetros son la forma en la que el modelo ha comprimido regularidades del entrenamiento. No guarda el mundo como una biblioteca; guarda transformaciones numéricas que suelen producir continuaciones plausibles.

Escala: tamaño, datos, cómputo y contexto

La escala de un LLM no es una sola cifra. Cuando alguien dice «este modelo es grande», puede estar mezclando al menos cinco dimensiones:

Dimensión	Qué mide	Por qué importa
Parámetros	Cuántos números aprendidos tiene el modelo.	Aumentan capacidad, memoria necesaria y coste de servirlo.
Datos	Cuántos tokens se usaron durante entrenamiento.	Determinan cobertura de patrones, idiomas, estilos y dominios.
Cómputo de entrenamiento	Cuántas operaciones se invirtieron en ajustar parámetros.	Marca el coste de crear el modelo y parte de su calidad.
Contexto	Cuántos tokens puede leer de una vez.	Afecta a documentos largos, RAG, agentes y memoria de conversación.
Cómputo de inferencia	Cuánto trabajo cuesta generar cada token.	Impacta en latencia, precio y capacidad de escalar un producto.

Las leyes de escalado mostraron que, durante una etapa importante del desarrollo de modelos de lenguaje, aumentar parámetros, datos y cómputo de forma coordinada mejoraba de manera predecible la pérdida.¹⁰ Más tarde, el trabajo conocido como Chinchilla subrayó algo muy práctico: no basta con hacer modelos enormes; hay que equilibrar tamaño del modelo y cantidad de tokens de entrenamiento.¹¹

Esto nos deja una regla de lectura útil: más parámetros no significa automáticamente mejor modelo para tu caso. Un modelo menor, bien entrenado, bien alineado con tu idioma, más barato de servir y con buena ventana de contexto puede ser mejor elección que uno mucho mayor.

Leer una ficha de modelo sin marearse

Una model card es una ficha técnica. Puede estar en Hugging Face, en la documentación de un proveedor o en un paper. No siempre trae todo lo que querríamos, pero cuando está bien hecha responde a una pregunta muy práctica: «¿puedo usar este modelo para mi caso sin engañarme?».

La forma de leerla no es empezar por el benchmark más vistoso. Es ir de lo más operativo a lo más fino:

Dato de la ficha	Pregunta que responde	Dónde volverá
Arquitectura	¿Es denso, MoE, multimodal, encoder-decoder, decoder-only?	Facsímil 3, capítulo 2 y capítulo 5.
Parámetros totales	¿Cuánta capacidad y memoria bruta puede requerir?	Facsímil 3, capítulo 5 y capítulo 7.
Parámetros activos	Si es MoE, ¿cuánto cómputo se activa por token?	Facsímil 3, capítulo 5.
Context window	¿Cuánto texto puede recibir sin RAG ni resumen previo?	Facsímil 4, facsímil 5 y facsímil 6.
Tokenizer y vocabulario	¿Cómo trocea idiomas, código, números o nombres raros?	Facsímil 1, capítulo 9.
Precisión y cuantización	¿FP16, BF16, FP8, INT8, 4-bit? ¿Cabe y con qué pérdida?	Facsímil 3, capítulo 7.
Licencia	¿Puedo usarlo, modificarlo, servirlo o vender un producto encima?	Facsímil 4 y bloque de licencia del proyecto.
Benchmarks	¿Qué mide realmente la tabla y con qué metodología?	Facsímil 7.
Runtime recomendado	¿Transformers, vLLM, SGLang, Ollama, TensorRT-LLM?	Facsímil 4, facsímil 6 y facsímil 7.
Limitaciones declaradas	¿En qué idiomas, dominios o tareas falla más?	Facsímil 7, facsímil 8 y facsímil 9.

Ejemplo: si una ficha dice «70B, contexto 128k, instruct, FP16», no has terminado de leer. Has empezado. Falta preguntar: ¿tengo memoria para servirlo?, ¿necesito realmente 128k tokens?, ¿qué latencia tolera mi usuario?, ¿hay versión cuantizada?, ¿funciona en español?, ¿qué licencia tiene?, ¿qué benchmark se parece a mi tarea?, ¿necesito RAG aunque tenga mucho contexto?

Otra trampa: comparar una ficha de modelo base con una ficha de modelo instruido. Puede que compartan arquitectura y tamaño, pero no comportamiento. El modelo base puede ser excelente para continuar texto y torpe para seguir instrucciones; el instruido puede ser mucho más útil en chat aunque tenga el mismo número de parámetros. Por eso, cuando alguien diga «uso tal modelo», la pregunta completa es: ¿base o instruct?, ¿qué versión?, ¿qué cuantización?, ¿qué contexto?, ¿qué parámetros de generación?, ¿qué sistema lo rodea?

Cuánto pesa un modelo

La primera consecuencia de los parámetros es física: ocupan memoria. Si un modelo tiene $N$ parámetros y cada parámetro ocupa $B$ bytes, la memoria aproximada solo para pesos es:

M_{\text{pesos}} \approx N \cdot B

Símbolo	Significado	Ejemplo
$M_{\text{pesos}}$	Memoria necesaria para guardar los pesos del modelo.	14 GB para 7B en FP16, aproximadamente.
$N$	Número de parámetros.	$7\,000\,000\,000$ .
$B$	Bytes por parámetro según precisión.	FP16 usa 2 bytes; INT8 usa 1 byte; 4-bit usa 0,5 bytes.

Ejemplo:

M_{\text{pesos}} \approx 7\,000\,000\,000 \cdot 2 = 14\,000\,000\,000 \text{ bytes}

Es decir, unos 14 GB decimales solo para los pesos. Y eso no incluye todo lo demás: memoria de activaciones, caché KV durante generación, buffers del runtime, batch, contexto ni el sistema que rodea al modelo.

Para verlo con código:

def memoria_pesos(parametros_miles_millones, bytes_por_parametro):
    parametros = parametros_miles_millones * 1_000_000_000
    gb_decimales = parametros * bytes_por_parametro / 1_000_000_000
    gib_binarios = parametros * bytes_por_parametro / (1024 ** 3)
    return gb_decimales, gib_binarios

for nombre, bytes_param in [("FP16", 2), ("INT8", 1), ("4-bit", 0.5)]:
    gb, gib = memoria_pesos(7, bytes_param)
    print(f"{nombre}: {gb:.1f} GB decimales / {gib:.1f} GiB binarios")

Salida esperada:

FP16: 14.0 GB decimales / 13.0 GiB binarios
INT8: 7.0 GB decimales / 6.5 GiB binarios
4-bit: 3.5 GB decimales / 3.3 GiB binarios

Este cálculo no decide si un modelo cabe en tu máquina, pero evita autoengaños. Cuando alguien dice «tengo una GPU de 8 GB, ¿puedo servir un 7B?», la respuesta empieza aquí: pesos, precisión, contexto, batch y runtime.

El contexto también pesa

Hay una segunda memoria que al principio se nos escapa: la memoria de generación. Cuando el modelo genera token a token, no recalcula todo desde cero. Guarda una caché de claves y valores de atención, normalmente llamada KV cache. Esa caché crece con el número de capas, la longitud de contexto, la dimensión interna, la precisión y el batch.

Una aproximación útil es:

M_{\text{KV}} \approx 2 \cdot L \cdot n \cdot d \cdot B

Símbolo	Significado	Ejemplo
$M_{\text{KV}}$	Memoria aproximada de la caché de atención.	Alrededor de 2 GiB en el ejemplo de abajo.
$2$	Guardamos claves $K$ y valores $V$ .	Dos tensores por capa.
$L$	Número de capas del modelo.	$L = 32$ .
$n$	Tokens de contexto almacenados.	$n = 4096$ .
$d$	Dimensión interna aproximada por token.	$d = 4096$ .
$B$	Bytes por valor.	FP16 usa $B = 2$ .

Con esos números:

M_{\text{KV}} \approx 2 \cdot 32 \cdot 4096 \cdot 4096 \cdot 2 = 2\,147\,483\,648 \text{ bytes}

Unos 2 GiB solo para la caché, en batch 1 y con una aproximación simplificada. En modelos reales hay optimizaciones, variantes de atención y detalles de implementación, pero la intuición se mantiene: más contexto no es gratis. Si duplicas el contexto, sube la memoria de la caché. Si subes el batch, también. Por eso un modelo puede caber con un prompt corto y quedarse sin memoria cuando le pasas un documento largo.

Esta idea conecta directamente con RAG, agentes y producto. No todo documento largo debe meterse entero en contexto. A veces conviene recuperar fragmentos, resumir, estructurar, hacer varias llamadas o diseñar una memoria externa. El contexto es una herramienta, no un trastero infinito.

En el día a día

Entender qué es un LLM cambia cómo eliges tecnología.

Elegir modelo para un producto. No empiezas por «el más grande». Empiezas por la tarea: extracción, soporte, programación, razonamiento, redacción, búsqueda, resumen, clasificación. Luego preguntas: ¿qué calidad necesito?, ¿qué latencia tolero?, ¿cuánto contexto requiere?, ¿qué presupuesto por llamada tengo?, ¿necesito modelo local por privacidad o coste? La arquitectura viene después del problema.

Leer una ficha de modelo. Cuando veas parámetros, contexto, tamaño de vocabulario, arquitectura densa o MoE, precisión, cuantización y benchmarks, no lo leas como marketing suelto. Léelo como restricciones de ingeniería. Cada número te dice algo sobre memoria, latencia, coste, calidad esperable o compatibilidad con tu runtime.

Diseñar una aplicación con IA. Un LLM no debería vivir solo. A su alrededor suelen aparecer recuperación de documentos, herramientas, validadores, observabilidad, pruebas y revisión humana cuando la salida importa. El modelo predice tokens; el sistema completo convierte esa predicción en una experiencia útil y responsable.

Diagnosticar un fallo. Si una respuesta sale mal, no basta con decir «el modelo falla». Puede fallar el prompt, el contexto, el retrieval, el formato esperado, el parámetro de generación, la herramienta llamada, la validación posterior o la expectativa del producto. Separar modelo base, modelo instruido y sistema completo te permite depurar con lupa en vez de cambiar de modelo cada vez que algo se tuerce.

Por qué debería importarte

Porque el error más común al empezar con LLMs es tratarlos como cajas opacas intercambiables. «Ponemos un modelo potente y ya está». Esa frase suele ocultar casi todas las decisiones importantes.

Si sabes qué es un parámetro, entiendes por qué un modelo ocupa memoria. Si sabes qué es un logit, entiendes por qué la salida no es una verdad sino una distribución. Si sabes qué es escala, entiendes por qué comparar modelos exige mirar más que una cifra. Si sabes qué es una KV cache, entiendes por qué el contexto largo tiene coste real. Y si sabes que el modelo predice tokens, entiendes por qué muchas aplicaciones necesitan datos externos, restricciones, evaluación y trazabilidad.

Dónde volverá a aparecer

Este capítulo es una bisagra. Parece que solo habla de «qué es un modelo», pero en realidad deja colocadas varias piezas que volverán una y otra vez en el temario. Conviene verlas ahora como conexiones, no como conceptos aislados.

Concepto de este capítulo	Dónde vuelve en el libro	Por qué se conecta
Token	Facsímil 1, capítulo 9; facsímil 3, capítulo 2 y capítulo 3; facsímil 4.	En el capítulo 9 aprendimos que el texto se trocea. Aquí vemos que el LLM predice tokens. En los próximos capítulos esos tokens se convertirán en tensores, entrarán en atención y después condicionarán coste, contexto, RAG y prompts.
Embedding y vector	Facsímil 1, capítulo 9; facsímil 3, capítulo 2; facsímil 4.	Un LLM no trabaja con palabras, trabaja con vectores. Esa misma idea reaparece cuando expliquemos Transformer por dentro y cuando usemos embeddings para búsqueda semántica.
Parámetros	Facsímil 1, capítulos 5, 6 y 10; facsímil 3, capítulo 5, capítulo 6 y capítulo 7.	En redes neuronales ya vimos pesos y entrenamiento. Aquí los escalamos a miles de millones. Más adelante nos servirán para entender MoE, destilación, modelos abiertos, cuantización, memoria y hardware.
Pérdida	Facsímil 1, capítulo 7; facsímil 3, capítulo 6; facsímil 7.	La pérdida explica cómo aprende un modelo durante entrenamiento. Después reaparece en fine-tuning, destilación y evaluación: si no medimos algo, no sabemos si hemos mejorado.
Logits y softmax	Facsímil 3, capítulo 4; facsímil 7.	Aquí aparecen como mecanismo mínimo. Luego veremos cómo temperature, `top_p`, `top_k` y calibración convierten esas puntuaciones en salidas útiles o engañosamente seguras.
Contexto	Facsímil 4; facsímil 5; facsímil 6.	El contexto no es memoria humana: son tokens disponibles. Esa diferencia será clave para RAG, agentes con herramientas, handoffs, compaction y observabilidad.
KV cache	Facsímil 3, capítulo 7; facsímil 6.	La caché explica por qué contexto, batch y latencia son decisiones de arquitectura, no detalles invisibles del runtime.
Modelo base vs modelo instruido	Facsímil 3, capítulo 6; facsímil 4; facsímil 7.	Separar entrenamiento base, post-entrenamiento y evaluación evita comparar modelos distintos como si fueran la misma cosa.
Modelo ≠ base de datos	Facsímil 2, capítulo 12; facsímil 4.	Cuando necesitemos hechos verificables, no bastará con pedirle al modelo que recuerde. Conectaremos LLMs con grafos, documentos, consultas, fuentes y sistemas de recuperación.
Escala	Facsímil 3, capítulo 5 y capítulo 7; facsímil 6; facsímil 11.	La escala no es presumir de tamaño: decide coste, latencia, despliegue, experiencia de usuario y viabilidad de producto. Un modelo que no cabe o tarda demasiado no sirve para ese caso.
Sistema completo	Facsímil 2, capítulo 8; facsímil 4, facsímil 5, facsímil 6, facsímil 7 y facsímil 9.	El LLM predice tokens; el sistema decide qué contexto entra, qué herramientas puede usar, qué validadores revisan la salida, qué métricas se registran y cuándo participa una persona.

Una forma útil de leer el resto del libro es esta: cada vez que aparezca una palabra grande —RAG, agente, evaluación, modelo abierto, inferencia local, gobernanza— pregúntate qué parte toca del mecanismo de este capítulo. ¿Cambia el contexto? ¿Cambia los parámetros? ¿Cambia la forma de elegir tokens? ¿Añade una fuente externa? ¿Mide mejor la salida? Así el temario deja de ser una lista de temas y se convierte en un mapa.

Dónde solía tropezar yo

Error	Por qué es un error	Antídoto
Confundir modelo con producto	El chat que usas incluye interfaz, herramientas, reglas y memoria de conversación. El LLM es solo una pieza. Si comparas experiencias completas como si fueran modelos puros, sacas conclusiones débiles.	Pregunta siempre qué parte estás evaluando: modelo base, modelo instruido, API, app, RAG, tool use o sistema completo.
Creer que parámetros son conocimiento literal	Un parámetro no guarda una frase ni una tabla. Es un número dentro de una transformación. Hablar de «memoria» del modelo puede ser útil como metáfora, pero mala como descripción técnica.	Traduce «memoria» por «regularidades comprimidas en pesos». Para hechos exactos, usa fuentes externas verificables.
Pensar que más grande siempre gana	Más parámetros suelen dar más capacidad, pero también más coste, memoria y latencia. Además, datos, entrenamiento, post-entrenamiento y evaluación importan muchísimo.	Compara con una eval propia y restricciones reales: calidad, coste, latencia, contexto, privacidad y mantenimiento.
Olvidar que genera token a token	Una respuesta larga no aparece de golpe. Cada token depende de lo anterior y consume cómputo. Por eso salidas largas cuestan más y tardan más.	Mide tokens de entrada y salida. Diseña límites, streaming y presupuestos antes de producción.
Leer softmax como certeza	Un 94 % de probabilidad para un token no significa que la afirmación sea verdadera. Significa que ese token encaja muy bien con el contexto según el modelo.	Diferencia probabilidad lingüística de veracidad factual. Para hechos, conecta fuentes, citas y validadores.
No separar base, instruct y sistema	Puedes culpar al modelo de un fallo que viene del contexto, de una herramienta o de una regla de producto. También puedes atribuir al modelo capacidades que en realidad vienen del sistema que lo envuelve.	Cuando algo funcione o falle, pregunta: ¿lo produjo el modelo base, el post-entrenamiento, el prompt, el contexto, una herramienta o un validador?

Manos a la obra

La práctica real está en kit descargable. El kit convierte dos ideas básicas en cálculos reproducibles: pérdida token a token y memoria mínima de pesos por precisión. No necesitas GPU ni librerías externas.

Archivo	Qué contiene
`data/loss_memory_case.json`	Probabilidades antes/después y tamaños de modelo.
`contracts/loss_memory_policy.json`	Umbrales mínimos: la pérdida debe bajar y la memoria debe cuadrar.
`ops/estimate_loss_memory.py`	Calcula pérdida, perplexity y memoria por precisión.
`output/loss_memory_report.json`	Resultados estructurados.
`output/loss_memory_decision.md`	Informe legible para entregar.

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/estimate_loss_memory.py --write
cat output/loss_memory_decision.md

Como gate:

python3 ops/estimate_loss_memory.py --write --fail-on-invalid

Qué entregaría un alumno. El Markdown generado, una secuencia nueva de probabilidades, una precisión nueva y una decisión: qué falta todavía para saber si un modelo cabe de verdad en una máquina.

Cómo encaja todo

Este mapa se lee de izquierda a derecha: primero recupera los cimientos del facsímil 1, después separa qué es el modelo y qué es el sistema, y finalmente muestra por qué arquitectura, herramientas, operación y evaluación no son temas sueltos.

La decisión nueva de este capítulo es llamar a cada cosa por su nombre: parámetros, contexto, logits, KV cache y sistema completo. Si esa separación queda clara aquí, los próximos capítulos dejan de parecer una colección de siglas.

graph TD
    F1["Facsímil 1: cimientos<br/>tokens · embeddings · pérdida · entrenamiento"]
    C1["Este capítulo<br/>LLM = modelo que predice el siguiente token"]
    CAPAS["Tres capas<br/>modelo base → modelo instruido → sistema completo"]
    MATH["Mecanismo mínimo<br/>contexto → logits → softmax → token"]
    SCALE["Escala operativa<br/>parámetros · contexto · KV cache · coste"]
    F3A["Facsímil 3, capítulos 2-4<br/>Transformer · QKV · máscara · sampling"]
    F3B["Facsímil 3, capítulos 5-7<br/>MoE · modelos abiertos · inferencia · hardware"]
    F2["Facsímil 2<br/>restricciones, planificación y conocimiento simbólico"]
    F4["Facsímil 4<br/>APIs · RAG · herramientas · modelos locales"]
    F5["Facsímil 5<br/>agentes · memoria · permisos · orquestación"]
    F6["Facsímil 6<br/>operación · observabilidad · despliegue"]
    F7["Facsímil 7<br/>evaluación · calibración · métricas"]
    PRODUCT["Criterio de producto<br/>elegir modelo, coste, latencia y calidad"]

    F1 -->|"prepara vocabulario para"| C1
    C1 -->|"se separa en"| CAPAS
    C1 -->|"se calcula con"| MATH
    C1 -->|"se decide por"| SCALE
    MATH -->|"abre"| F3A
    SCALE -->|"abre"| F3B
    F2 -->|"aporta reglas y fuentes a"| F4
    CAPAS -->|"se vuelve aplicación en"| F4
    F4 -->|"se orquesta como"| F5
    F5 -->|"se opera con"| F6
    F6 -->|"se mide con"| F7
    F7 -->|"retroalimenta"| PRODUCT
    F3A -->|"explica arquitectura para"| PRODUCT
    F3B -->|"explica viabilidad para"| PRODUCT
    PRODUCT -->|"obliga a volver a"| C1

    style C1 fill:#F5F5F5,stroke:#000000,stroke-width:2
    style CAPAS fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MATH fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SCALE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style F1 stroke-dasharray: 5 5
    style F2 stroke-dasharray: 5 5
    style F3A stroke-dasharray: 5 5
    style F3B stroke-dasharray: 5 5
    style F4 stroke-dasharray: 5 5
    style F5 stroke-dasharray: 5 5
    style F6 stroke-dasharray: 5 5
    style F7 stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición
LLM	Modelo de lenguaje de gran escala entrenado para predecir el siguiente token a partir de un contexto.
Modelo	Función matemática con parámetros aprendidos que transforma entradas en salidas.
Parámetro	Número aprendido durante entrenamiento. Los parámetros determinan cómo se transforman los vectores dentro de la red.
Escala	Conjunto de tamaño del modelo, datos, cómputo, contexto e inferencia. No es solo número de parámetros.
Logit	Puntuación no normalizada para un token candidato.
Softmax	Función que transforma logits en probabilidades que suman uno.
Contexto	Tokens disponibles para que el modelo calcule la siguiente predicción.
KV cache	Memoria que guarda claves y valores de atención para no recalcular todo el contexto en cada token generado.
Modelo base	Modelo entrenado principalmente para continuar texto, antes de adaptarlo para conversar o seguir instrucciones.
Modelo instruido	Modelo ajustado para seguir instrucciones y producir respuestas más útiles en interacción humana.
Model card	Ficha técnica que documenta arquitectura, tamaño, contexto, licencia, evaluación y límites de un modelo.
Inferencia	Uso del modelo ya entrenado para generar respuestas o predicciones.
Cuantización	Técnica que guarda pesos con menos bits para reducir memoria y acelerar inferencia, a cambio de posible pérdida de precisión.

Antes de pasar página

En resumen

Idea fuerza	Detalle
Un LLM predice el siguiente token.	La respuesta larga aparece porque esa predicción se repite una y otra vez, token a token.
Los parámetros son números aprendidos, no recuerdos literales.	Comprimen regularidades del entrenamiento en matrices y vectores que transforman representaciones.
La salida es una distribución, no una garantía de verdad.	Softmax convierte logits en probabilidades lingüísticas; la veracidad requiere contexto, fuentes y validación.
Modelo base, modelo instruido y sistema completo no son lo mismo.	Separarlos permite depurar fallos y elegir mejor arquitectura, contexto, herramientas y evaluación.
La escala tiene varias dimensiones.	Parámetros, datos, cómputo, contexto, KV cache e inferencia afectan calidad, coste, latencia y viabilidad técnica.

Para saber más

Bender, E. M., Gebru, T., McMillan-Major, A. y Shmitchell, S. (2021). On the dangers of stochastic parrots: can language models be too big? En Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency (pp. 610-623). https://doi.org/10.1145/3442188.3445922

Bengio, Y., Ducharme, R., Vincent, P. y Janvin, C. (2003). A neural probabilistic language model. Journal of Machine Learning Research, 3, 1137-1155. https://www.jmlr.org/papers/volume3/bengio03a/bengio03a.pdf

Brown, T. B. et al. (2020). Language models are few-shot learners. En Advances in Neural Information Processing Systems 33 (pp. 1877-1901). https://papers.nips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html

Goodfellow, I., Bengio, Y. y Courville, A. (2016). Deep learning. MIT Press. https://www.deeplearningbook.org

Hoffmann, J. et al. (2022). Training compute-optimal large language models. En Advances in Neural Information Processing Systems 35. https://doi.org/10.48550/arXiv.2203.15556

Kaplan, J. et al. (2020). Scaling laws for neural language models. arXiv preprint. https://doi.org/10.48550/arXiv.2001.08361

Ouyang, L. et al. (2022). Training language models to follow instructions with human feedback. En Advances in Neural Information Processing Systems 35 (pp. 27730-27744). https://arxiv.org/abs/2203.02155

Shannon, C. E. (1948). A mathematical theory of communication. The Bell System Technical Journal, 27(3), 379-423. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x

Vaswani, A. et al. (2017). Attention is all you need. En Advances in Neural Information Processing Systems 30 (pp. 5998-6008). https://papers.nips.cc/paper/7181-attention-is-all-you-need

Notas

Shannon, C. E. (1948). A mathematical theory of communication. The Bell System Technical Journal, 27(3), 379-423. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x. Shannon formalizó el lenguaje como una fuente estadística de símbolos, una idea que está en la raíz de los modelos probabilísticos de secuencias. ↩
Bengio, Y., Ducharme, R., Vincent, P. y Janvin, C. (2003). A neural probabilistic language model. Journal of Machine Learning Research, 3, 1137-1155. https://www.jmlr.org/papers/volume3/bengio03a/bengio03a.pdf. El artículo introdujo una forma neuronal de modelar lenguaje mediante representaciones distribuidas. ↩
Brants, T., Popat, A. C., Xu, P., Och, F. J. y Dean, J. (2007). Large language models in machine translation. En Proceedings of EMNLP-CoNLL 2007 (pp. 858-867). https://aclanthology.org/D07-1090/. Ojo: estos «large language models» eran modelos estadísticos a escala masiva, no LLMs Transformer conversacionales como los actuales. ↩
Vaswani, A. et al. (2017). Attention is all you need. En Advances in Neural Information Processing Systems 30 (pp. 5998-6008). https://papers.nips.cc/paper/7181-attention-is-all-you-need. El Transformer hizo viable una arquitectura basada en atención que acabaría dominando los LLM modernos. ↩
Radford, A., Narasimhan, K., Salimans, T. y Sutskever, I. (2018). Improving language understanding by generative pre-training. OpenAI. https://cdn.openai.com/research-covers/language-unsupervised/language_understanding_paper.pdf. El paper introdujo el enfoque GPT original: preentrenar un Transformer decoder y adaptarlo después a tareas. ↩
Radford, A. et al. (2019). Language models are unsupervised multitask learners. OpenAI. https://cdn.openai.com/better-language-models/language_models_are_unsupervised_multitask_learners.pdf. ↩
Brown, T. B. et al. (2020). Language models are few-shot learners. En Advances in Neural Information Processing Systems 33 (pp. 1877-1901). https://papers.nips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html. ↩
Ouyang, L. et al. (2022). Training language models to follow instructions with human feedback. En Advances in Neural Information Processing Systems 35 (pp. 27730-27744). https://arxiv.org/abs/2203.02155. El trabajo muestra cómo el ajuste con instrucciones y feedback humano cambió el comportamiento observable de modelos de lenguaje sin cambiar la idea base de predicción token a token. ↩
Goodfellow, I., Bengio, Y. y Courville, A. (2016). Deep learning. MIT Press. https://www.deeplearningbook.org. El libro explica los parámetros como pesos aprendidos que definen transformaciones entre representaciones. ↩
Kaplan, J. et al. (2020). Scaling laws for neural language models. arXiv preprint. https://doi.org/10.48550/arXiv.2001.08361. El trabajo formalizó relaciones empíricas entre tamaño del modelo, datos, cómputo y pérdida. ↩
Hoffmann, J. et al. (2022). Training compute-optimal large language models. En Advances in Neural Information Processing Systems 35. https://doi.org/10.48550/arXiv.2203.15556. El artículo mostró que muchos modelos grandes estaban infraentrenados respecto al cómputo disponible y propuso un equilibrio distinto entre parámetros y datos. ↩

Capítulo 02

Facsímil 3 · Arquitecturas y modelos

Capítulo 02: Transformer por dentro: de texto a tensores y atención

El momento en que el texto deja de ser texto

En el capítulo anterior vimos el LLM desde fuera: contexto, parámetros, logits, escala y sistema completo. Ahora vamos a abrir una puerta más pequeña y más concreta: ¿qué ocurre justo después de tokenizar?

Para nosotros, una frase sigue siendo una frase. Para el modelo, ya no. La frase se convierte en una tabla de números. Esa tabla tiene filas, columnas, tamaño, memoria y operaciones permitidas. Cuando un modelo «lee» una oración, en realidad está multiplicando matrices, sumando vectores y calculando pesos de atención.

Este capítulo va de ese paso. No vamos todavía a exprimir Q, K, V, máscara causal y softmax con todo detalle; eso será el capítulo 03. Aquí queremos entender la carretera principal: texto → tokens → tensores → atención → representación contextual.

Qué no es un Transformer

Un Transformer no es una lista de reglas gramaticales. No tiene una tabla escrita a mano con «si aparece sujeto, busca verbo». Aprende transformaciones numéricas durante entrenamiento y las aplica a vectores.

Tampoco es una memoria que recorra el texto palabra por palabra como una persona leyendo en voz alta. Antes de los Transformers, muchas arquitecturas secuenciales procesaban una posición tras otra y llevaban un estado interno hacia delante.¹ Eso funcionaba, pero tenía un cuello de botella: si cada paso depende del paso anterior, paralelizar se vuelve más difícil.

Y no es «atención humana» en sentido psicológico. La palabra atención es útil, pero técnica: significa calcular pesos para mezclar información. Si un token atiende a otro, no está «pensando» en él. Está usando su vector para decidir cuánto de otro vector debe entrar en la nueva representación.

Qué sí es un Transformer

Un Transformer es una arquitectura de red neuronal diseñada para procesar secuencias mediante atención y operaciones paralelas sobre matrices.²

La idea central es sencilla de decir y potente de ejecutar: cada token empieza con un vector, y cada capa transforma ese vector usando información de otros tokens. Al final, el vector de cada posición ya no representa solo ese token aislado, sino ese token dentro de su contexto.

Por ejemplo, en estas dos frases:

Me senté en el banco
El banco aprobó el préstamo

El token «banco» podría empezar con un embedding parecido en ambos casos. Pero tras pasar por atención, su representación debería cambiar: en la primera frase se acerca a asiento; en la segunda, a entidad financiera. El Transformer no recibe una definición explícita: aprende a usar el contexto.

La atención moderna no apareció de la nada. Antes del Transformer, Bahdanau, Cho y Bengio ya habían mostrado que un modelo de traducción podía aprender a alinear partes de una frase origen con partes de una frase destino.³ Luong, Pham y Manning estudiaron variantes eficaces de atención para traducción neuronal.⁴ El salto del Transformer fue llevar esa intuición al centro de la arquitectura.

El paper original: por qué fue tan raro y tan importante

El paper “Attention Is All You Need” se envió a arXiv el 12 de junio de 2017 y fue presentado en NeurIPS 2017.⁵ Lo firmaron ocho autores: Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Łukasz Kaiser e Illia Polosukhin.

La propuesta era incómoda para su época porque quitaba dos muletas habituales en modelos de secuencia: recurrencia y convolución. Hasta entonces, para traducir o generar secuencias era normal procesar tokens en orden, mantener un estado oculto y apoyarse en atención como complemento. El Transformer dijo: probemos a construir toda la arquitectura alrededor de atención.

El paper original no nació pensando en chats modernos. Su tarea principal era traducción automática. La entrada era una frase en un idioma y la salida una frase en otro. La arquitectura completa tenía dos mitades:

Parte del paper	Qué hacía	Cómo lo leemos hoy
Encoder	Leía toda la frase de entrada y construía representaciones contextuales.	Se parece a modelos de comprensión como BERT.
Decoder	Generaba la frase de salida token a token mirando lo ya generado.	Se parece a la familia GPT cuando hablamos de generación autoregresiva.
Atención encoder-decoder	Permitía que cada token generado mirase partes relevantes de la entrada.	Es una forma temprana de conectar generación con contexto fuente.
Multi-head attention	Usaba varias atenciones en paralelo para capturar relaciones distintas.	En el capítulo 03 veremos por qué varias cabezas miran patrones distintos.
Feed-forward, residual y normalización	Completaba cada bloque para hacerlo entrenable y expresivo.	En el capítulo 04 lo abriremos despacio.

La idea que debemos llevarnos no es «inventaron los LLMs de golpe». Es más precisa: inventaron una arquitectura que hacía mucho más natural entrenar modelos grandes de secuencias con paralelismo y atención directa. Los LLMs modernos heredan esa carretera y la llevan a otra escala.

De tokens a tensores

Empezamos con texto:

El banco aprobó el préstamo

El tokenizador lo convierte en identificadores. No importa ahora si salen cinco o seis tokens; usemos cinco para entender el mecanismo:

I = [i_1, i_2, i_3, i_4, i_5]

Símbolo	Significado	Ejemplo
$I$	Secuencia de identificadores de token.	$[42, 981, 774, 42, 1503]$ .
$i_t$	Identificador del token en la posición $t$ .	$i_2 = 981$ para «banco».
$t$	Posición dentro de la secuencia.	$t=1$ es el primer token.

Cada identificador selecciona una fila de la matriz de embeddings:

E \in \mathbb{R}^{V \times d_{\text{model}}}

Símbolo	Significado	Ejemplo
$E$	Matriz de embeddings aprendida.	Una tabla gigante de vectores.
$V$	Tamaño del vocabulario.	100 000 tokens posibles.
$d_{\text{model}}$	Dimensión interna del modelo.	4096 números por token.
$\mathbb{R}$	Conjunto de números reales.	Valores como 0,37 o -1,12.

Después de buscar esas filas, obtenemos una matriz:

X = E[I] + P_{1:n}

Símbolo	Significado	Ejemplo
$X$	Tensor de entrada al Transformer.	Una matriz de $5 \times 4096$ .
$E[I]$	Filas de embedding seleccionadas por los IDs.	Los vectores de «El», «banco», «aprobó»...
$P_{1:n}$	Información de posición para las $n$ posiciones.	Permite distinguir «perro muerde hombre» de «hombre muerde perro».
$n$	Número de tokens de la secuencia.	$n=5$ .

Este punto es importante: el Transformer no recibe una frase como texto. Recibe un tensor. Esa forma de pensar —representar datos como vectores, matrices y transformaciones diferenciables— es la base común del deep learning moderno.⁶ En la práctica, si procesamos una sola frase con 5 tokens y $d_{\text{model}}=4$ para simplificar, podríamos imaginar algo así:

Token	Vector interno simplificado
El	$[0{,}20,\ 0{,}10,\ -0{,}30,\ 0{,}40]$
banco	$[0{,}80,\ -0{,}20,\ 0{,}10,\ 0{,}50]$
aprobó	$[0{,}10,\ 0{,}70,\ 0{,}20,\ -0{,}10]$
el	$[0{,}18,\ 0{,}08,\ -0{,}25,\ 0{,}36]$
préstamo	$[0{,}60,\ 0{,}40,\ 0{,}70,\ 0{,}20]$

En un modelo real no habría 4 columnas, sino cientos o miles. Pero la idea es la misma: una fila por token, una columna por dimensión interna.

La atención como mesa de mezclas

La atención responde a una pregunta: para actualizar la representación de este token, ¿cuánto debería mezclar información de los demás tokens?

En una capa de atención simplificada, el modelo calcula tres proyecciones desde $X$ :

Q = XW_Q,\quad K = XW_K,\quad V = XW_V

Símbolo	Significado	Ejemplo
$Q$	Consultas (queries): qué busca cada token.	«banco» pregunta qué contexto le da sentido.
$K$	Claves (keys): qué ofrece cada token para ser encontrado.	«préstamo» ofrece pista financiera.
$V$	Valores (values): información que se mezclará si recibe atención.	Vector que aporta contenido al resultado.
$W_Q, W_K, W_V$	Matrices aprendidas que proyectan $X$ .	Parámetros entrenados.

Después se calculan puntuaciones comparando consultas con claves:

S = \frac{QK^T}{\sqrt{d_k}}

Símbolo	Significado	Ejemplo
$S$	Matriz de puntuaciones de atención.	Una tabla $n \times n$ .
$QK^T$	Producto entre consultas y claves.	Mide afinidad entre posiciones.
$d_k$	Dimensión de las claves.	64, 128 u otra dimensión por cabeza.
$\sqrt{d_k}$	Escalado para estabilizar valores.	Si $d_k=64$ , dividimos por 8.

Convertimos esas puntuaciones en pesos con softmax:

A = \operatorname{softmax}(S)

Símbolo	Significado	Ejemplo
$A$	Matriz de atención.	Cada fila suma 1.
$\operatorname{softmax}$	Convierte puntuaciones en pesos positivos.	2,0 se vuelve más importante que 0,2.
$A_{ij}$	Peso con el que el token $i$ mira al token $j$ .	«banco» mira a «préstamo» con peso alto.

Por último, mezclamos los valores:

O = AV

Símbolo	Significado	Ejemplo
$O$	Salida de atención.	Nueva representación contextual.
$A$	Pesos de mezcla.	Cuánto mirar a cada token.
$V$	Valores disponibles para mezclar.	Información que aporta cada posición.

Leído sin símbolos: cada token produce una pregunta, compara esa pregunta con las claves de todos los tokens, convierte las coincidencias en pesos y mezcla valores según esos pesos. Eso es atención.

Cómo funcionaría una pasada completa

Ahora juntemos las piezas sin perdernos. Imagina que queremos generar una respuesta a partir del prompt:

Resume este contrato en tres puntos

Una pasada de inferencia, simplificada, seguiría estos pasos:

Tokenizar. El texto se trocea en IDs: el modelo no recibe caracteres, recibe números.
Buscar embeddings. Cada ID selecciona una fila de la matriz $E$ .
Añadir posición. A cada vector se le suma o aplica información de orden para distinguir la primera posición de la segunda.
Construir el tensor $X$ . La entrada queda como una matriz $n \times d_{\text{model}}$ .
Proyectar a $Q$ , $K$ , $V$ . Cada capa aprende tres formas de mirar la misma entrada: qué busca, qué ofrece y qué información puede mezclar.
Calcular atención. Se comparan consultas y claves, se aplica softmax y se obtiene una matriz de pesos.
Mezclar valores. Cada token recibe una combinación ponderada de información del contexto.
Pasar por residual, normalización y MLP. La representación se estabiliza y se transforma dentro del bloque.
Repetir capas. Un modelo real tiene muchas capas; cada una refina las representaciones.
Proyectar a logits. El último vector se convierte en puntuaciones para todos los tokens del vocabulario.
Elegir el siguiente token. El sistema aplica temperatura, top_p, top_k u otra política de generación.
Volver a empezar. El token elegido se añade al contexto y la siguiente pasada genera el siguiente token.

Si lo escribimos como pseudocódigo conceptual:

ids = tokenizador(texto)
X = embeddings(ids) + posicion(ids)

para cada bloque Transformer:
    Q = X W_Q
    K = X W_K
    V = X W_V
    A = softmax(Q K^T / sqrt(d_k))
    X = normalizacion(X + A V)
    X = normalizacion(X + MLP(X))

logits = X_ultimo W_vocab
siguiente_token = muestrear(logits)

Ese pseudocódigo no sirve para entrenar un modelo real, pero sí para orientarse. Si alguna vez te pierdes, vuelve a la pregunta: ¿en qué punto estoy? ¿Tokenizando, mezclando contexto, transformando representación o eligiendo el siguiente token?

Un ejemplo pequeño con números

Usemos solo tres tokens para mirar la fila de atención de «banco»:

El banco aprobó

Imagina que, después de proyectar consultas y claves, las puntuaciones de «banco» hacia cada token son:

Token al que mira «banco»	Puntuación
El	0,2
banco	2,0
aprobó	1,0

Aplicamos softmax:

\operatorname{softmax}([0{,}2,\ 2{,}0,\ 1{,}0]) \approx [0{,}108,\ 0{,}652,\ 0{,}240]

Valor	Significado	Lectura
0,108	Peso hacia «El».	Aporta poco.
0,652	Peso hacia «banco».	Mantiene mucho de sí mismo.
0,240	Peso hacia «aprobó».	Aporta contexto de acción.

Ahora supongamos valores simplificados de dos dimensiones:

Token	Valor $V$
El	$[0{,}1,\ 0{,}0]$
banco	$[1{,}0,\ 0{,}2]$
aprobó	$[0{,}4,\ 1{,}0]$

La nueva representación de «banco» es la mezcla ponderada:

o_{\text{banco}} = 0{,}108[0{,}1,\ 0{,}0] + 0{,}652[1{,}0,\ 0{,}2] + 0{,}240[0{,}4,\ 1{,}0]

Resultado:

o_{\text{banco}} \approx [0{,}759,\ 0{,}370]

Símbolo	Significado	Ejemplo
$o_{\text{banco}}$	Vector contextualizado del token «banco».	Ya no es solo el embedding inicial.
$0{,}652[1{,}0,\ 0{,}2]$	Parte que conserva de sí mismo.	El token sigue siendo «banco».
$0{,}240[0{,}4,\ 1{,}0]$	Parte que recibe de «aprobó».	El verbo cambia el sentido posible.

Esto es pequeño, casi de juguete, pero contiene la intuición completa. La atención no reemplaza el token: lo contextualiza.

Dentro de un bloque Transformer hay más piezas además de atención. Las conexiones residuales permiten que la información original siga circulando a través de capas profundas, una idea que se volvió central tras ResNet.⁷ La normalización por capa ayuda a estabilizar las activaciones dentro de la red.⁸ En el capítulo 04 entraremos con calma en residual, normalización, MLP y logits.

Simuladores para verlo funcionando

Hay conceptos que se entienden mejor cuando los ves moverse. Estos recursos no sustituyen al capítulo, pero ayudan mucho a mirar la arquitectura con las manos:

Recurso	Qué puedes mirar	Cuándo abrirlo
Transformer Explainer	Visualiza un GPT-2 pequeño en el navegador, con flujo de tokens, componentes internos y predicción del siguiente token.⁹	Después de «Cómo funcionaría una pasada completa».
LLM Visualization	Un recorrido 3D por un Transformer estilo GPT, con capas, atención y operaciones internas.¹⁰	Cuando quieras una intuición espacial de las capas.
The Illustrated Transformer	Explicación visual paso a paso del Transformer original, muy buena para fijar encoder, decoder y atención.¹¹	Antes o después de leer el bloque del paper original.
The Annotated Transformer	Implementación anotada del paper, con código y explicación matemática.¹²	Cuando ya quieras pasar de dibujo a código.

Una forma útil de usarlos: primero abre Transformer Explainer y escribe una frase corta. Mira cómo cambia la distribución del siguiente token. Después vuelve al pseudocódigo de este capítulo y localiza en qué parte del simulador está cada paso. Si una visualización te abruma, no intentes entender todo a la vez: busca solo tokens, atención y logits.

Por qué el Transformer cambió el juego

La ventaja práctica del Transformer está en dos ideas que se refuerzan.

Primera: paralelismo. En una arquitectura recurrente clásica, procesar el token 200 depende de haber procesado antes los 199 tokens previos. En un Transformer, muchas operaciones se expresan como multiplicaciones de matrices. Eso encaja muy bien con GPU y TPU, que son máquinas excelentes para operar con bloques grandes de números.

Segunda: acceso directo al contexto. Si el token de la posición 200 necesita información de la posición 12, la atención puede crear una conexión directa dentro de la matriz. No necesita transportar todo a través de un único estado oculto. Esa es una de las razones por las que el Transformer se volvió la arquitectura dominante para modelos grandes de lenguaje.

Pero no todo es gratis. La atención estándar compara cada token con cada token. Si hay $n$ tokens, la matriz de atención tiene $n \times n$ entradas:

\text{coste de atención} \propto n^2

Símbolo	Significado	Ejemplo
$n$	Número de tokens de contexto.	1 000 tokens.
$n^2$	Comparaciones entre posiciones.	1 000 000 relaciones posibles.
$\propto$	«Proporcional a».	Si duplicas $n$ , el coste crece aproximadamente por cuatro.

Esto explica por qué el contexto largo es tan valioso y tan caro. No basta con decir «metamos más texto». El diseño del sistema debe decidir qué entra, qué se resume, qué se recupera con RAG y qué conviene dejar fuera.

Además, no todos los Transformers leen igual. BERT usa una arquitectura orientada a entender texto mirando a ambos lados del contexto, muy útil para tareas de comprensión.¹³ La familia GPT usa el enfoque autoregresivo: predice el siguiente token mirando el contexto disponible hacia atrás, que es la base de los LLMs generativos modernos.¹⁴

Esto en un proyecto real

Cuando integras un modelo en una aplicación, rara vez manipulas $Q$ , $K$ , $V$ a mano. Pero sí pagas sus consecuencias.

Diseñar prompts largos. Si añades instrucciones, documentos, historial y ejemplos, estás aumentando $n$ . Más tokens significan más memoria, más latencia y más coste. Este capítulo te ayuda a entender por qué el contexto debe diseñarse, no solo rellenarse.

Elegir entre modelos. Dos modelos pueden tener calidades parecidas, pero arquitecturas internas distintas. Uno puede ser más rápido con contexto corto; otro puede estar optimizado para contexto largo. Cuando leas una ficha técnica, «context window», «attention implementation», «KV cache» y «throughput» dejan de ser palabras decorativas.

Depurar respuestas raras. A veces el problema no está en que el modelo «no sepa», sino en que la información relevante no está en el contexto, queda enterrada entre demasiado ruido o llega en un formato difícil de usar. Entender atención te recuerda que el modelo mezcla señales: si la señal útil está muy diluida, la salida también puede estarlo.

Conectar con RAG. En RAG, no meteremos todos los documentos en el prompt. Recuperaremos fragmentos. La razón no es solo comodidad: es arquitectura. El contexto es una ventana cara y limitada.

Por qué debería importarte

Porque el Transformer es la bisagra entre «texto» y «sistema de IA moderno». Si solo sabes que los LLMs predicen tokens, entiendes el comportamiento externo. Si además entiendes tensores y atención, empiezas a leer por dentro por qué el contexto importa, por qué el orden importa, por qué el coste crece y por qué algunos errores se arreglan cambiando el contexto en vez de cambiando de modelo.

También te prepara para el capítulo siguiente. Q, K, V, máscara causal y softmax no son nombres sueltos: son las piezas concretas que hacen posible esta mesa de mezclas.

Dónde volverá a aparecer

Concepto de este capítulo	Dónde vuelve en el libro	Por qué se conecta
Tensor $X$	Facsímil 1, capítulo 9; facsímil 3, capítulo 3.	Los embeddings dejan de ser una idea abstracta: se convierten en una matriz que entra en el Transformer.
Atención	Facsímil 3, capítulo 3; capítulo 4; capítulo 7.	Primero veremos Q, K, V; después cómo la salida llega a logits; y más adelante cómo se optimiza la inferencia.
Posición	Facsímil 3, capítulo 3; facsímil 5.	El orden del contexto afecta a qué puede usar el modelo y a cómo diseñamos memoria conversacional.
Coste $n^2$	Facsímil 3, capítulo 7; facsímil 6.	Contexto, batch, caché y latencia se vuelven decisiones de operación.
Representación contextual	Facsímil 4; facsímil 7.	RAG y evaluación dependen de que el modelo use bien las señales que le damos.
Encoder y decoder	Facsímil 3, capítulo 5.	BERT, GPT, encoder-decoder y modelos multimodales comparten familia, pero no la misma dirección de lectura.
Simuladores visuales	Facsímil 3, capítulo 3; facsímil 3, capítulo 7.	Los volveremos a usar para mirar cabezas de atención, KV cache y coste de inferencia con más criterio.

Dónde solía tropezar yo

Error	Por qué es un error	Antídoto
Pensar que el tensor es un detalle de implementación	El tensor $X$ define cuántos tokens hay, cuántas dimensiones maneja el modelo y qué coste tendrá procesar la entrada.	Cuando leas una arquitectura, pregunta siempre por las formas: $n$ , $d_{\text{model}}$ , capas y cabezas.
Creer que atención es explicación perfecta	Un peso de atención alto indica mezcla de información, pero no equivale automáticamente a una explicación humana completa.	Úsala como pista técnica, no como prueba definitiva de causalidad.
Olvidar la posición	Si solo sumas embeddings de tokens sin posición, pierdes orden. Y en lenguaje, el orden cambia el significado.	Repite mentalmente: token + posición = entrada útil para secuencia.
Meter todo en contexto por tranquilidad	Más contexto puede añadir ruido, coste y latencia. No todo lo disponible es útil.	Recupera, resume y ordena. El contexto es una superficie de diseño.
Separar demasiado los capítulos	Tokens, embeddings, atención, logits y evaluación parecen temas distintos, pero son una cadena.	Sigue el flujo: texto → tensor → atención → logits → decisión de producto.

Manos a la obra

La práctica real está en kit descargable. El kit calcula una fila de atención en Python puro y muestra cómo un token mezcla vectores de valor. La idea no es optimizar: es ver el mecanismo completo antes de hablar de Transformers grandes.

Archivo	Qué contiene
`data/attention_case.json`	Tokens, puntuaciones y vectores de valor.
`contracts/attention_policy.json`	Token observado y umbrales de suma de pesos.
`ops/run_attention_mixer.py`	Softmax estable y mezcla ponderada.
`output/attention_mixer_report.json`	Pesos y vector contextual.
`output/attention_mixer_decision.md`	Lectura técnica.

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/run_attention_mixer.py --write
cat output/attention_mixer_decision.md

Como gate:

python3 ops/run_attention_mixer.py --write --fail-on-invalid

Qué entregaría un alumno. El Markdown generado, una variante de puntuaciones y una explicación de qué token domina el vector contextual y por qué.

Cómo encaja todo

Este mapa baja un nivel respecto al capítulo anterior. Ya no miramos solo el LLM como producto matemático: miramos cómo una frase se vuelve tensor, cómo la posición evita perder el orden y cómo la atención empieza a mezclar señales.

La conexión importante es práctica: cada vez que en facsímiles posteriores hablemos de contexto, RAG, coste o latencia, estaremos pagando decisiones que nacen aquí, en el tamaño de $n$ , $d_{\text{model}}$ y la matriz de atención.

graph TD
    F1C09["Facsímil 1, capítulo 9<br/>tokens y embeddings"]
    F3C01["Facsímil 3, capítulo 1<br/>LLM, contexto, logits y escala"]
    C2["Este capítulo<br/>texto → tensor → atención"]
    TENSOR["Tensor X<br/>tokens como matriz"]
    POS["Posición<br/>orden dentro del contexto"]
    ATT["Atención<br/>mezcla información entre tokens"]
    COST["Coste n²<br/>contexto, latencia y memoria"]
    F3C03["Facsímil 3, capítulo 3<br/>Q, K, V, máscara y softmax"]
    F3C04["Facsímil 3, capítulo 4<br/>MLP, residual, LayerNorm y logits"]
    F3C07["Facsímil 3, capítulo 7<br/>KV cache, inferencia y hardware"]
    F4["Facsímil 4<br/>RAG, APIs y modelos locales"]
    F6["Facsímil 6<br/>operación y observabilidad"]
    F7["Facsímil 7<br/>evaluación y calibración"]

    F1C09 -->|"entrega vocabulario a"| C2
    F3C01 -->|"abre la arquitectura de"| C2
    C2 -->|"convierte texto en"| TENSOR
    TENSOR -->|"se completa con"| POS
    TENSOR -->|"alimenta"| ATT
    POS -->|"ordena"| ATT
    ATT -->|"produce"| COST
    ATT -->|"se despieza en"| F3C03
    ATT -->|"continúa hacia"| F3C04
    COST -->|"condiciona"| F3C07
    COST -->|"obliga a diseñar"| F4
    F3C07 -->|"se opera en"| F6
    F7 -->|"mide si se usó bien"| F4
    F4 -->|"retroalimenta"| C2

    style C2 fill:#F5F5F5,stroke:#000000,stroke-width:2
    style TENSOR fill:#F5F5F5,stroke:#000000,stroke-width:2
    style POS fill:#F5F5F5,stroke:#000000,stroke-width:2
    style ATT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style COST fill:#F5F5F5,stroke:#000000,stroke-width:2
    style F1C09 stroke-dasharray: 5 5
    style F3C01 stroke-dasharray: 5 5
    style F3C03 stroke-dasharray: 5 5
    style F3C04 stroke-dasharray: 5 5
    style F3C07 stroke-dasharray: 5 5
    style F4 stroke-dasharray: 5 5
    style F6 stroke-dasharray: 5 5
    style F7 stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición
Tensor	Estructura numérica con dimensiones. Una matriz $n \times d$ es un tensor de dos dimensiones.
$d_{\text{model}}$	Dimensión interna del modelo: cuántos números representan cada token dentro del Transformer.
Embedding posicional	Información que indica la posición de cada token para que el modelo no pierda el orden.
Atención	Mecanismo que calcula pesos para mezclar información entre posiciones de una secuencia.
Matriz de atención	Tabla $n \times n$ donde cada fila indica cuánto mira un token a los demás.
Consulta, clave y valor	Tres proyecciones aprendidas que permiten preguntar, comparar y mezclar información.
Residual	Conexión que suma la entrada del bloque a su salida para no perder señal y entrenar mejor.
Normalización	Operación que estabiliza activaciones dentro de la red.
Paralelismo	Capacidad de ejecutar muchas operaciones a la vez, especialmente multiplicaciones de matrices.

Antes de pasar página

En resumen

Idea fuerza	Detalle
El texto entra al Transformer como tensor.	Después de tokenizar y buscar embeddings, la entrada tiene forma $n \times d_{\text{model}}$ : filas para tokens, columnas para dimensiones internas.
La atención contextualiza cada token.	Cada posición calcula pesos sobre otras posiciones y mezcla valores para construir una representación dependiente del contexto.
El Transformer ganó por paralelismo y acceso directo.	Procesa secuencias con operaciones matriciales y permite que posiciones lejanas se conecten sin pasar por un único estado oculto.
El contexto largo tiene coste real.	La matriz de atención crece como $n^2$ , así que diseñar contexto es una decisión técnica y de producto.

Para saber más

Alammar, J. (2018). The Illustrated Transformer. https://jalammar.github.io/illustrated-transformer/

Ba, J. L., Kiros, J. R. y Hinton, G. E. (2016). Layer normalization. https://arxiv.org/abs/1607.06450

Bahdanau, D., Cho, K. y Bengio, Y. (2015). Neural machine translation by jointly learning to align and translate. En International Conference on Learning Representations. https://arxiv.org/abs/1409.0473

Brown, T. B. et al. (2020). Language models are few-shot learners. En Advances in Neural Information Processing Systems 33 (pp. 1877-1901). https://papers.nips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html

Bycroft, B. (2023). LLM Visualization. https://bbycroft.net/llm

Cho, A., Kim, G. C., Karpekov, A., Helbling, A., Wang, Z. J., Lee, S., Hoover, B. y Chau, D. H. (2025). Transformer Explainer: interactive learning of text-generative models. En Proceedings of the AAAI Conference on Artificial Intelligence. https://ojs.aaai.org/index.php/AAAI/article/download/35347/37502

Devlin, J., Chang, M. W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. En Proceedings of NAACL-HLT (pp. 4171-4186). https://doi.org/10.18653/v1/N19-1423

Goodfellow, I., Bengio, Y. y Courville, A. (2016). Deep learning. MIT Press. https://www.deeplearningbook.org

He, K., Zhang, X., Ren, S. y Sun, J. (2016). Deep residual learning for image recognition. En Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 770-778). https://doi.org/10.1109/CVPR.2016.90

Luong, M.-T., Pham, H. y Manning, C. D. (2015). Effective approaches to attention-based neural machine translation. En Proceedings of the 2015 Conference on Empirical Methods in Natural Language Processing (pp. 1412-1421). https://doi.org/10.18653/v1/D15-1166

Rush, A. M. (2018). The Annotated Transformer. https://nlp.seas.harvard.edu/annotated-transformer/

Sutskever, I., Vinyals, O. y Le, Q. V. (2014). Sequence to sequence learning with neural networks. En Advances in Neural Information Processing Systems 27 (pp. 3104-3112). https://papers.nips.cc/paper/5346-sequence-to-sequence-learning-with-neural-networks

Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł. y Polosukhin, I. (2017). Attention is all you need. En Advances in Neural Information Processing Systems 30 (pp. 5998-6008). https://papers.nips.cc/paper/7181-attention-is-all-you-need

Notas

Sutskever, I., Vinyals, O. y Le, Q. V. (2014). Sequence to sequence learning with neural networks. En Advances in Neural Information Processing Systems 27 (pp. 3104-3112). https://papers.nips.cc/paper/5346-sequence-to-sequence-learning-with-neural-networks. Los modelos sequence-to-sequence con redes recurrentes fueron un paso clave para traducir y generar secuencias antes del dominio del Transformer. ↩
Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł. y Polosukhin, I. (2017). Attention is all you need. En Advances in Neural Information Processing Systems 30 (pp. 5998-6008). https://papers.nips.cc/paper/7181-attention-is-all-you-need. El artículo presentó una arquitectura sin recurrencia ni convolución, basada en atención, capaz de entrenar modelos de secuencia de forma mucho más paralela. ↩
Bahdanau, D., Cho, K. y Bengio, Y. (2015). Neural machine translation by jointly learning to align and translate. En International Conference on Learning Representations. https://arxiv.org/abs/1409.0473. El trabajo introdujo un mecanismo de atención para traducción neuronal que permitía al decodificador consultar partes relevantes de la entrada. ↩
Luong, M.-T., Pham, H. y Manning, C. D. (2015). Effective approaches to attention-based neural machine translation. En Proceedings of the 2015 Conference on Empirical Methods in Natural Language Processing (pp. 1412-1421). https://doi.org/10.18653/v1/D15-1166. El artículo comparó formas prácticas de calcular atención en traducción automática neuronal. ↩
Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł. y Polosukhin, I. (2017). Attention is all you need. En Advances in Neural Information Processing Systems 30 (pp. 5998-6008). https://arxiv.org/abs/1706.03762. La página de arXiv muestra la fecha de envío, los autores y el resumen del trabajo. ↩
Goodfellow, I., Bengio, Y. y Courville, A. (2016). Deep learning. MIT Press. https://www.deeplearningbook.org. El libro presenta las redes profundas como composiciones de funciones diferenciables sobre tensores, justo el marco matemático que usamos aquí para leer el Transformer. ↩
He, K., Zhang, X., Ren, S. y Sun, J. (2016). Deep residual learning for image recognition. En Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 770-778). https://doi.org/10.1109/CVPR.2016.90. Aunque ResNet nació en visión por computador, popularizó las conexiones residuales que ayudan a entrenar redes muy profundas. ↩
Ba, J. L., Kiros, J. R. y Hinton, G. E. (2016). Layer normalization. https://arxiv.org/abs/1607.06450. LayerNorm normaliza activaciones dentro de una capa y se convirtió en una pieza habitual de arquitecturas Transformer. ↩
Cho, A., Kim, G. C., Karpekov, A., Helbling, A., Wang, Z. J., Lee, S., Hoover, B. y Chau, D. H. (2025). Transformer Explainer: interactive learning of text-generative models. En Proceedings of the AAAI Conference on Artificial Intelligence. https://ojs.aaai.org/index.php/AAAI/article/download/35347/37502. El artículo describe la herramienta como una visualización web interactiva que ejecuta un modelo GPT-2 localmente en el navegador. ↩
Bycroft, B. (2023). LLM Visualization. https://bbycroft.net/llm. Visualización interactiva 3D de un modelo Transformer estilo GPT. ↩
Alammar, J. (2018). The Illustrated Transformer. https://jalammar.github.io/illustrated-transformer/. Recurso visual ampliamente usado para entender la arquitectura Transformer. ↩
Rush, A. M. (2018). The Annotated Transformer. https://nlp.seas.harvard.edu/annotated-transformer/. Implementación comentada de la arquitectura Transformer original. ↩
Devlin, J., Chang, M. W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. En Proceedings of NAACL-HLT (pp. 4171-4186). https://doi.org/10.18653/v1/N19-1423. BERT popularizó el preentrenamiento bidireccional con Transformer encoder para comprensión de lenguaje. ↩
Brown, T. B. et al. (2020). Language models are few-shot learners. En Advances in Neural Information Processing Systems 33 (pp. 1877-1901). https://papers.nips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html. GPT-3 mostró que un Transformer decoder autoregresivo a gran escala podía realizar muchas tareas mediante ejemplos en el propio prompt. ↩

Capítulo 03

Facsímil 3 · Arquitecturas y modelos

Capítulo 03: Q, K, V, máscara causal y softmax

La mesa de mezclas ya tiene mandos

En el capítulo anterior dijimos que la atención era una mesa de mezclas: cada token decide cuánto tomar de otros tokens para construir una representación contextual. Pero dejamos sin abrir los mandos concretos.

Ahora entran tres letras que aparecen por todas partes cuando alguien explica Transformers: Q, K y V. Al principio parecen una contraseña. En realidad son tres formas distintas de mirar el mismo tensor: qué busca cada token, qué ofrece cada token y qué información se mezcla al final.

También aparece una regla silenciosa pero decisiva: la máscara causal. Sin ella, un modelo generativo haría trampas durante entrenamiento: para predecir el token 3 podría mirar el token 4, que en generación real todavía no existe.

Qué no son Q, K y V

Q, K y V no son tres bases de datos internas. No hay una tabla llamada «preguntas», otra llamada «claves» y otra llamada «valores» con significado humano directo. Son proyecciones lineales aprendidas a partir del tensor de entrada.

Tampoco son conceptos nuevos separados del capítulo anterior. En el capítulo 02 ya teníamos una matriz $X$ con una fila por token. Q, K y V salen de esa misma matriz, multiplicándola por tres matrices de pesos distintas.

Y la máscara causal no es un filtro moral ni una regla de producto. Es una restricción geométrica sobre qué posiciones pueden verse entre sí. Su función es mantener honesta la generación de izquierda a derecha.

Qué sí son Q, K y V

En self-attention, cada token produce tres vectores: una consulta (query), una clave (key) y un valor (value). El Transformer original formalizó este mecanismo como atención escalada por producto punto y lo convirtió en la pieza central de la arquitectura.¹

La intuición:

Letra	Nombre	Pregunta informal
$Q$	Query / consulta	¿Qué estoy buscando desde esta posición?
$K$	Key / clave	¿Qué tipo de información ofrezco para que otros me encuentren?
$V$	Value / valor	Si alguien me mira, ¿qué información le entrego?

Como lectura pedagógica complementaria, Alyona Vert resume esta intuición de forma muy útil: Q busca, K permite decidir si algo merece atención y V transporta el contenido que se mezcla; además conecta esa separación con la KV cache que veremos en inferencia.²

Imagina la frase:

El banco aprobó el préstamo

Para la posición «banco», la consulta puede aprender a buscar señales que aclaren el sentido. Las claves de «aprobó» y «préstamo» pueden ofrecer pistas financieras. Los valores son la información que realmente se mezcla cuando esas posiciones reciben peso.

Las proyecciones lineales

Partimos de la matriz $X$ :

X \in \mathbb{R}^{n \times d_{\text{model}}}

Símbolo	Significado	Ejemplo
$X$	Tensor de entrada a la capa de atención.	4 tokens por 3 dimensiones en el ejemplo pequeño.
$n$	Número de tokens.	$n=4$ .
$d_{\text{model}}$	Dimensión interna del modelo.	En un modelo real, 768, 4096 o más.

Calculamos:

Q = XW_Q,\quad K = XW_K,\quad V = XW_V

Símbolo	Significado	Ejemplo
$W_Q$	Matriz aprendida para consultas.	Transforma cada fila de $X$ en lo que busca.
$W_K$	Matriz aprendida para claves.	Transforma cada fila de $X$ en lo que ofrece.
$W_V$	Matriz aprendida para valores.	Transforma cada fila de $X$ en lo que se mezclará.
$Q, K, V$	Tres matrices derivadas de la misma entrada.	Tres versiones útiles del contexto.

Estas multiplicaciones son capas lineales, una idea básica de redes neuronales profundas.³ Lo interesante no es que la operación sea exótica, sino que el entrenamiento aprende qué proyecciones convienen para comparar tokens.

Puntuaciones: comparar lo que busco con lo que ofreces

Para saber cuánto debe mirar cada token a cada otro token, comparamos consultas con claves:

S = \frac{QK^T}{\sqrt{d_k}}

Símbolo	Significado	Ejemplo
$S$	Matriz de puntuaciones antes de softmax.	Una tabla $n \times n$ .
$QK^T$	Producto entre consultas y claves.	Afinidad entre cada par de posiciones.
$K^T$	Transpuesta de $K$ .	Convierte columnas en filas para multiplicar.
$d_k$	Dimensión de las claves.	Si las claves tienen 64 dimensiones, $d_k=64$ .
$\sqrt{d_k}$	Factor de escala.	Evita puntuaciones demasiado grandes.

El escalado por $\sqrt{d_k}$ ayuda a que las puntuaciones no crezcan demasiado cuando la dimensión aumenta. Si las puntuaciones llegan enormes a softmax, la distribución puede volverse muy extrema y los gradientes menos útiles. Esto lo verás también al estudiar optimización y estabilidad numérica.

La máscara causal: no mirar el futuro

En un modelo generativo autoregresivo, la posición $i$ solo puede mirar posiciones anteriores o la misma posición. No puede mirar posiciones futuras. La máscara causal se puede escribir así:

M_{ij} = \begin{cases} 0 & \text{si } j \le i \ -\infty & \text{si } j > i \end{cases}

Símbolo	Significado	Ejemplo
$M_{ij}$	Valor de la máscara para la fila $i$ , columna $j$ .	Fila 2 no puede mirar columna 4.
$j \le i$	Posición visible.	El token actual puede mirar lo anterior.
$j > i$	Posición futura.	Se bloquea antes de softmax.
$-\infty$	Valor ideal que softmax convierte en peso 0.	El futuro queda con probabilidad cero.

Aplicamos la máscara a las puntuaciones:

\tilde{S} = S + M

Después:

A = \operatorname{softmax}(\tilde{S})

Símbolo	Significado	Ejemplo
$\tilde{S}$	Puntuaciones ya enmascaradas.	Futuro sustituido por $-\infty$ .
$A$	Matriz final de atención.	Cada fila suma 1.
$\operatorname{softmax}$	Función que convierte puntuaciones en pesos positivos.	Muy usada en clasificación y en LLMs.⁴

La máscara causal es una de las diferencias importantes entre un modelo que genera texto de izquierda a derecha y un modelo de comprensión que puede mirar ambos lados del texto. GPT usa atención causal para generación autoregresiva.⁵ BERT, en cambio, usa una arquitectura bidireccional pensada para comprensión.⁶

Cómo leer la matriz sin perderse

La matriz de atención se lee fila a fila. Cada fila responde a una pregunta concreta: «desde este token, ¿cuánto miro a cada posición disponible?». Por eso no tiene sentido mirar un número aislado sin saber en qué fila vive.

En una frase de cuatro tokens, la máscara causal deja esta forma:

Fila	Token que mira	Puede mirar	No puede mirar todavía	Lectura
1	El	El	banco, aprobó, préstamo	No hay pasado; solo se ve a sí mismo.
2	banco	El, banco	aprobó, préstamo	Tiene un poco de contexto, pero no sabe lo que viene después.
3	aprobó	El, banco, aprobó	préstamo	Puede usar el sujeto y el verbo, pero no el objeto futuro.
4	préstamo	El, banco, aprobó, préstamo	—	Ya puede mirar toda la frase disponible.

Después de aplicar softmax, cada fila suma 1. Eso significa que el token reparte toda su atención entre las posiciones permitidas. Si una fila tiene cuatro posiciones posibles, no significa que las cuatro importen igual; significa que el reparto completo se hace dentro de esas cuatro posiciones.

Una forma sana de leerlo es esta:

Elige una fila.
Mira qué columnas permite la máscara.
Aplica softmax solo a esas puntuaciones útiles.
Usa esos pesos para mezclar los valores $V$ .

Si sigues esos cuatro pasos, la fórmula deja de ser una pared y se convierte en una receta.

Valores: mezclar la información

Una vez tenemos los pesos de atención $A$ , mezclamos los valores:

O = AV

Símbolo	Significado	Ejemplo
$O$	Salida de la atención.	Nueva matriz con representaciones contextualizadas.
$A$	Pesos de atención.	Cuánto mira cada token a cada posición permitida.
$V$	Valores.	Información que se mezcla.

Esta fórmula es la parte más importante para la intuición: $Q$ y $K$ deciden cuánto mirar; $V$ decide qué información se toma cuando miras.

Un ejemplo pequeño con máscara causal

Usemos cuatro tokens:

El banco aprobó préstamo

Tras las proyecciones, supongamos que obtenemos estas matrices pequeñas:

Token	$Q$	$K$	$V$
El	$[-0{,}01,\ -0{,}04]$	$[0{,}18,\ -0{,}19]$	$[-0{,}02,\ 0{,}24]$
banco	$[0{,}47,\ 0{,}00]$	$[0{,}17,\ -0{,}23]$	$[0{,}51,\ -0{,}04]$
aprobó	$[-0{,}03,\ 0{,}51]$	$[0{,}51,\ 0{,}21]$	$[0{,}23,\ 0{,}50]$
préstamo	$[0{,}43,\ 0{,}58]$	$[0{,}45,\ 0{,}25]$	$[0{,}75,\ 0{,}16]$

La matriz de puntuaciones enmascarada queda así, redondeada:

Token que mira	El	banco	aprobó	préstamo
El	0,004	—	—	—
banco	0,060	0,056	—	—
aprobó	-0,072	-0,087	0,065	—
préstamo	-0,023	-0,043	0,241	0,239

El guion largo significa «posición futura bloqueada por la máscara». Cuando aplicamos softmax por fila:

Token que mira	El	banco	aprobó	préstamo
El	1,000	0,000	0,000	0,000
banco	0,501	0,499	0,000	0,000
aprobó	0,319	0,315	0,366	0,000
préstamo	0,218	0,214	0,284	0,284

Mira la segunda fila. El token «banco» solo puede mirar «El» y «banco». Aunque «aprobó» y «préstamo» serían pistas útiles, todavía son futuro para esa posición en generación autoregresiva. Por eso su peso es 0.

Después multiplicamos por $V$ :

O = AV

La salida redondeada es:

Token	Salida contextualizada
El	$[-0{,}020,\ 0{,}240]$
banco	$[0{,}245,\ 0{,}100]$
aprobó	$[0{,}238,\ 0{,}247]$
préstamo	$[0{,}383,\ 0{,}231]$

Esta tabla enseña una idea que cuesta ver al principio: el mismo mecanismo sirve para todos los tokens, pero cada fila tiene una frontera temporal distinta.

El mapa operativo de Q, K, V

Antes de hablar de varias cabezas, dejemos el circuito en un mapa. Este Mermaid no es decoración: sirve para comprobar que el orden mental está bien colocado.

flowchart TD
    F3C02["Cap. 02<br/>texto a tensor"]
    X["X<br/>una fila por token"]
    PROJ["Proyecciones aprendidas<br/>WQ · WK · WV"]
    Q["Q<br/>qué busca"]
    K["K<br/>qué ofrece"]
    V["V<br/>qué entrega"]
    SCORE["Puntuaciones<br/>QKᵀ / √dk"]
    MASK["Máscara causal<br/>bloquear futuro"]
    SOFT["Softmax por fila<br/>pesos que suman 1"]
    OUT["O = AV<br/>mezcla contextual"]
    F3C04["Cap. 04<br/>logits y sampling"]
    F3C07["Cap. 07<br/>KV cache"]
    F4["Fasc. 04<br/>RAG y contexto"]

    F3C02 -->|"produce"| X
    X -->|"entra en"| PROJ
    PROJ -->|"consulta"| Q
    PROJ -->|"clave"| K
    PROJ -->|"valor"| V
    Q -->|"comparar"| SCORE
    K -->|"comparar"| SCORE
    SCORE -->|"bloquear futuro"| MASK
    MASK -->|"normalizar"| SOFT
    SOFT -->|"pesar"| V
    V -->|"mezclar"| OUT
    OUT -->|"continuar"| F3C04
    K -->|"guardar"| F3C07
    V -->|"guardar"| F3C07
    MASK -->|"diseñar contexto"| F4

    style X fill:#F5F5F5,stroke:#000000,stroke-width:2
    style PROJ fill:#F5F5F5,stroke:#000000,stroke-width:2
    style Q fill:#F5F5F5,stroke:#000000,stroke-width:2
    style K fill:#F5F5F5,stroke:#000000,stroke-width:2
    style V fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SCORE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MASK fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SOFT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style OUT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style F3C02 stroke-dasharray: 5 5
    style F3C04 stroke-dasharray: 5 5
    style F3C07 stroke-dasharray: 5 5
    style F4 stroke-dasharray: 5 5

Si quieres auditar tu propia comprensión, recorre las flechas en voz alta. Si en algún punto dices «esto pasa porque sí», ahí está el hueco que hay que volver a mirar.

Varias cabezas: mirar relaciones distintas

El Transformer no usa una sola atención. Usa varias cabezas en paralelo:

\operatorname{head}_h = \operatorname{Attention}(XW_Q^{(h)}, XW_K^{(h)}, XW_V^{(h)})

Símbolo	Significado	Ejemplo
$h$	Índice de la cabeza de atención.	Cabeza 1, cabeza 2, etc.
$W_Q^{(h)}, W_K^{(h)}, W_V^{(h)}$	Proyecciones propias de la cabeza $h$ .	Cada cabeza aprende una mirada distinta.
$\operatorname{head}_h$	Salida de una cabeza.	Una matriz contextual.

Después concatena las cabezas y proyecta:

\operatorname{MultiHead}(X) = \operatorname{Concat}(\operatorname{head}_1,\ldots,\operatorname{head}_H)W_O

Símbolo	Significado	Ejemplo
$H$	Número de cabezas.	12, 32, 64... según modelo.
$\operatorname{Concat}$	Concatenación de salidas.	Une las cabezas por dimensión.
$W_O$	Matriz de salida aprendida.	Recombina lo que miraron las cabezas.

La intuición: una cabeza puede aprender relaciones de proximidad, otra relaciones sintácticas, otra dependencias de nombres, otra patrones de formato. No hay que imaginarlo como roles fijos garantizados, pero sí como capacidad de mirar varios tipos de relación en paralelo.

Recursos como The Illustrated Transformer ayudan a ver esta estructura con dibujo.⁷ The Annotated Transformer la baja además a código comentado.⁸

Qué aprende una cabeza de atención

Una cabeza no viene de fábrica con una misión escrita. No podemos decir «esta cabeza es la de fechas» como si fuera una etiqueta estable. Lo que sí podemos decir es que cada cabeza tiene sus propias matrices $W_Q^{(h)}$ , $W_K^{(h)}$ y $W_V^{(h)}$ , así que dispone de una forma propia de comparar y mezclar.

Eso permite que distintas cabezas se especialicen de manera útil:

Patrón que puede capturar	Qué significa en una frase	Por qué ayuda
Proximidad	Mirar mucho a tokens cercanos.	Muchas dependencias locales viven cerca: artículo, nombre, puntuación, formato.
Referencia	Conectar una palabra con otra anterior.	Ayuda a mantener entidades: «Marta llegó. Ella...».
Estructura	Detectar patrones de frase o de código.	Un cierre de paréntesis, una coma o una indentación pueden depender de señales previas.
Tema	Mantener pistas semánticas repartidas por el contexto.	Si una conversación habla de medicina, finanzas o cocina, algunas posiciones arrastran ese marco.
Formato	Seguir listas, tablas, JSON o Markdown.	La forma del texto también es información que el modelo usa para continuar.

La clave para el lector es no convertir esto en una caja negra. Una cabeza calcula pesos; varias cabezas calculan varios repartos; la proyección final recombina esos repartos. La complejidad emerge de repetir este patrón muchas veces, no de que una pieza aislada «entienda» el texto como una persona.

Para verlo en pantalla

Aquí conviene jugar un poco:

Recurso	Qué mirar en este capítulo
Transformer Explainer	Escribe una frase corta y observa cómo la predicción del siguiente token cambia con el contexto. Busca la parte de atención y fíjate en qué posiciones reciben más peso.⁹
The Annotated Transformer	Localiza la función de atención y compara el código con la fórmula $\operatorname{softmax}(QK^T/\sqrt{d_k})V$ .
The Illustrated Transformer	Repasa el dibujo de Q, K y V después de leer este capítulo.

No intentes verlo todo a la vez. Una buena práctica es abrir el simulador con una frase de cuatro o cinco tokens y preguntar: ¿qué fila estoy mirando?, ¿qué columnas quedan permitidas?, ¿qué pesos suman 1?

En el día a día

Diseñar contexto. Si sabes que cada fila de atención reparte peso entre posiciones disponibles, empiezas a cuidar dónde pones la información importante. No es lo mismo abrir un prompt con instrucciones claras que enterrarlas al final de un bloque enorme.

Entender por qué existe la KV cache. En inferencia, $K$ y $V$ de tokens ya procesados pueden guardarse para no recalcularlos una y otra vez. En el capítulo 07 conectaremos esta idea con memoria, latencia y hardware.

Leer parámetros de generación. Después de la atención y las capas siguientes llegan logits. Softmax reaparece cuando convertimos puntuaciones en probabilidades y elegimos tokens. Métodos como top_p y top_k se entienden mejor cuando ya has visto qué significa normalizar una distribución.¹⁰

No sobrerreaccionar a un mapa de atención. Mirar pesos de atención puede ser útil, pero no basta para explicar todo un comportamiento. La red tiene muchas capas, cabezas, MLPs y proyecciones. La atención es una ventana técnica, no una explicación completa del sistema.

Por qué debería importarte

Porque Q, K, V y la máscara causal son el punto donde la arquitectura deja de ser una caja negra total. No necesitas memorizar cada matriz, pero sí entender la película: el modelo proyecta, compara, bloquea lo que no debe ver, normaliza y mezcla.

Si entiendes eso, muchas decisiones dejan de sonar arbitrarias: por qué los modelos autoregresivos generan token a token, por qué el contexto largo cuesta, por qué la KV cache importa, por qué el orden del prompt afecta y por qué softmax no significa «verdad», sino distribución de pesos.

Dónde volverá a aparecer

Concepto de este capítulo	Dónde vuelve en el libro	Por qué se conecta
Softmax	Facsímil 1, capítulo 7; facsímil 3, capítulo 4; facsímil 7.	Aparece en atención, logits, muestreo y calibración.
Máscara causal	Facsímil 3, capítulo 4; facsímil 5.	La generación token a token condiciona cómo diseñamos memoria y herramientas.
Q, K, V	Facsímil 3, capítulo 7; facsímil 6.	La KV cache guarda claves y valores; por eso latencia y memoria dependen de estas matrices.
Multi-head attention	Facsímil 3, capítulo 5; facsímil 7.	Las arquitecturas modernas cambian cabezas, tamaños y patrones; evaluación ayuda a medir si compensa.
Pesos de atención	Facsímil 4; facsímil 7.	RAG y evaluación necesitan saber si el contexto útil está entrando de forma aprovechable.

Dónde solía tropezar yo

Error	Por qué es un error	Antídoto
Pensar que Q, K y V tienen significado humano fijo	Son proyecciones aprendidas. Una dimensión o una cabeza no trae una etiqueta estable como «sujeto» o «fecha».	Usa las metáforas como andamio, no como definición literal.
Olvidar que softmax se aplica por fila	Cada token reparte su atención entre posiciones permitidas. Si normalizas toda la matriz de golpe, rompes la interpretación.	Pregunta siempre: ¿qué fila estoy leyendo?
No ver la máscara causal	Sin máscara, parece que todos miran a todos. En generación autoregresiva, eso sería mirar tokens futuros.	Dibuja el triángulo inferior de la matriz antes de calcular softmax.
Confundir atención alta con importancia total	Un peso alto indica mezcla en una cabeza y una capa, pero el comportamiento final depende de muchas operaciones.	Lee atención como señal local, no como explicación completa.
Creer que V es menos importante que Q y K	Q y K deciden pesos, pero V contiene lo que se mezcla. Sin V, no hay salida contextual.	Recita la película: comparar con $QK^T$ , normalizar con softmax, mezclar con $V$ .

Manos a la obra

La práctica real está en kit descargable. El kit implementa una self-attention causal mínima con Q, K, V y comprueba que ningún token mira al futuro.

Archivo	Qué contiene
`data/qkv_case.json`	Matriz de entrada y pesos `Wq`, `Wk`, `Wv`.
`contracts/causal_attention_policy.json`	Tolerancia y regla de no mirar al futuro.
`ops/audit_causal_attention.py`	Matmul, softmax, atención causal y checks.
`output/causal_attention_report.json`	Q, K, V, pesos y salida.
`output/causal_attention_decision.md`	Informe legible.

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/audit_causal_attention.py --write
cat output/causal_attention_decision.md

Como gate:

python3 ops/audit_causal_attention.py --write --fail-on-invalid

Qué entregaría un alumno. El Markdown generado, una fila nueva de entrada y una explicación de qué posiciones están enmascaradas.

Cómo encaja todo

Este mapa coloca Q, K, V y la máscara causal en la cadena completa. El capítulo anterior entrega el tensor; este capítulo decide qué posiciones pueden mirarse, cómo se normalizan los pesos y qué información se mezcla.

La conexión hacia delante es igual de importante: las mismas claves y valores que aquí parecen una fórmula serán memoria real en la KV cache, coste real en serving y criterio real cuando diseñemos contexto, RAG o evaluación.

graph TD
    F3C02["Facsímil 3, capítulo 2<br/>texto → tensor → atención"]
    C3["Este capítulo<br/>Q, K, V, máscara causal y softmax"]
    Q["Q<br/>qué busca cada token"]
    K["K<br/>qué ofrece cada token"]
    V["V<br/>qué información entrega"]
    SCORE["Puntuaciones<br/>QKᵀ / √dk"]
    MASK["Máscara causal<br/>bloquear futuro"]
    SOFT["Softmax por fila<br/>pesos que suman 1"]
    OUT["Salida O = AV<br/>representación contextual"]
    F3C04["Facsímil 3, capítulo 4<br/>MLP, residual, logits y sampling"]
    F3C07["Facsímil 3, capítulo 7<br/>KV cache e inferencia"]
    F4["Facsímil 4<br/>RAG y diseño de contexto"]
    F6["Facsímil 6<br/>operación y latencia"]
    F7["Facsímil 7<br/>evaluación y calibración"]

    F3C02 -->|"prepara"| C3
    C3 -->|"proyecta"| Q
    C3 -->|"proyecta"| K
    C3 -->|"proyecta"| V
    Q -->|"compara con"| SCORE
    K -->|"compara con"| SCORE
    SCORE -->|"se restringe con"| MASK
    MASK -->|"se normaliza con"| SOFT
    SOFT -->|"mezcla"| OUT
    V -->|"aporta contenido a"| OUT
    OUT -->|"pasa a"| F3C04
    K -->|"se guarda como"| F3C07
    V -->|"se guarda como"| F3C07
    MASK -->|"condiciona"| F4
    F3C07 -->|"impacta en"| F6
    SOFT -->|"reaparece en"| F7

    style C3 fill:#F5F5F5,stroke:#000000,stroke-width:2
    style Q fill:#F5F5F5,stroke:#000000,stroke-width:2
    style K fill:#F5F5F5,stroke:#000000,stroke-width:2
    style V fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SCORE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MASK fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SOFT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style OUT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style F3C02 stroke-dasharray: 5 5
    style F3C04 stroke-dasharray: 5 5
    style F3C07 stroke-dasharray: 5 5
    style F4 stroke-dasharray: 5 5
    style F6 stroke-dasharray: 5 5
    style F7 stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición
Query $Q$	Proyección que representa lo que una posición busca en el contexto.
Key $K$	Proyección que representa lo que una posición ofrece para ser encontrada.
Value $V$	Proyección que contiene la información que se mezclará al final.
Producto punto	Suma de productos entre dos vectores; mide afinidad en atención.
Máscara causal	Regla que pone peso cero a posiciones futuras durante generación autoregresiva.
Softmax por fila	Normalización de cada fila de puntuaciones para convertirla en pesos que suman 1.
Cabeza de atención	Una atención independiente con sus propias proyecciones $Q$ , $K$ y $V$ .
Multi-head attention	Varias cabezas trabajando en paralelo y recombinadas al final.

Antes de pasar página

¿Puedo explicar Q, K y V sin decir solo «consulta, clave y valor»? (Si no, vuelve a «Qué sí son Q, K y V».)
¿Entiendo por qué $QK^T$ produce una matriz $n \times n$ ? (Si no, vuelve a «Puntuaciones».)
¿Puedo escribir la máscara causal y explicar qué significa $j > i$ ? (Si no, vuelve a «La máscara causal».)
¿Sé por qué softmax se aplica por fila? (Si no, vuelve a «La máscara causal».)
¿Puedo explicar por qué $O = AV$ mezcla información? (Si no, vuelve a «Valores».)
¿Puedo recorrer el mapa operativo Q → K → máscara → softmax → V sin saltarme pasos? (Si no, vuelve a «El mapa operativo de Q, K, V».)
¿Entiendo por qué BERT y GPT no miran el texto de la misma forma? (Si no, vuelve a «La máscara causal».)
¿Puedo ejecutar el código y explicar por qué aparecen ceros en la parte derecha de cada fila? (Si no, vuelve a «Manos a la obra».)
¿Sé conectar $K$ y $V$ con la futura KV cache? (Si no, vuelve a «Dónde volverá a aparecer».)

En resumen

Idea fuerza	Detalle
Q, K y V son tres proyecciones aprendidas de la misma entrada.	Q busca, K permite comparar y V aporta la información que se mezcla.
La atención compara todos los pares permitidos de posiciones.	$QK^T/\sqrt{d_k}$ produce puntuaciones; softmax las convierte en pesos.
La máscara causal hace honesta la generación.	Una posición no puede mirar tokens futuros, así que esos pesos acaban siendo cero.
Multi-head attention permite varias miradas en paralelo.	Distintas cabezas pueden aprender patrones de relación diferentes y luego recombinarse.

Para saber más

Alammar, J. (2018). The Illustrated Transformer. https://jalammar.github.io/illustrated-transformer/

Bishop, C. M. (2006). Pattern recognition and machine learning. Springer.

Brown, T. B. et al. (2020). Language models are few-shot learners. En Advances in Neural Information Processing Systems 33 (pp. 1877-1901). https://papers.nips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html

Cho, A., Kim, G. C., Karpekov, A., Helbling, A., Wang, Z. J., Lee, S., Hoover, B. y Chau, D. H. (2025). Transformer Explainer: interactive learning of text-generative models. En Proceedings of the AAAI Conference on Artificial Intelligence. https://ojs.aaai.org/index.php/AAAI/article/download/35347/37502

Devlin, J., Chang, M. W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. En Proceedings of NAACL-HLT (pp. 4171-4186). https://doi.org/10.18653/v1/N19-1423

Goodfellow, I., Bengio, Y. y Courville, A. (2016). Deep learning. MIT Press. https://www.deeplearningbook.org

Holtzman, A., Buys, J., Du, L., Forbes, M. y Choi, Y. (2020). The curious case of neural text degeneration. En International Conference on Learning Representations. https://openreview.net/forum?id=rygGQyrFvH

Rush, A. M. (2018). The Annotated Transformer. https://nlp.seas.harvard.edu/annotated-transformer/

Vert, A. (2026, 13 de mayo). AI 101: Your Ultimate Guide to Attention: Mechanism, QKV, and KV Cache. Turing Post. https://www.turingpost.com/p/your-ultimate-guide-to-attention-mechanism-qkv-and-kv-cache

Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł. y Polosukhin, I. (2017). Attention is all you need. En Advances in Neural Information Processing Systems 30 (pp. 5998-6008). https://papers.nips.cc/paper/7181-attention-is-all-you-need

Notas

Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł. y Polosukhin, I. (2017). Attention is all you need. En Advances in Neural Information Processing Systems 30 (pp. 5998-6008). https://papers.nips.cc/paper/7181-attention-is-all-you-need. El paper define la atención como $\operatorname{softmax}(QK^T / \sqrt{d_k})V$ , que es la fórmula que vamos a desmenuzar aquí. ↩
Vert, A. (2026, 13 de mayo). AI 101: Your Ultimate Guide to Attention: Mechanism, QKV, and KV Cache. Turing Post. https://www.turingpost.com/p/your-ultimate-guide-to-attention-mechanism-qkv-and-kv-cache. Consultado el 10 de junio de 2026. ↩
Goodfellow, I., Bengio, Y. y Courville, A. (2016). Deep learning. MIT Press. https://www.deeplearningbook.org. Las capas lineales y las composiciones de funciones diferenciables forman la base matemática de las redes profundas. ↩
Bishop, C. M. (2006). Pattern recognition and machine learning. Springer. Bishop explica softmax como transformación de puntuaciones en probabilidades normalizadas, una pieza común en modelos probabilísticos y clasificación. ↩
Brown, T. B. et al. (2020). Language models are few-shot learners. En Advances in Neural Information Processing Systems 33 (pp. 1877-1901). https://papers.nips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html. GPT-3 es un ejemplo de Transformer decoder autoregresivo a gran escala. ↩
Devlin, J., Chang, M. W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. En Proceedings of NAACL-HLT (pp. 4171-4186). https://doi.org/10.18653/v1/N19-1423. BERT popularizó el uso de Transformer encoder bidireccional para comprensión de lenguaje. ↩
Alammar, J. (2018). The Illustrated Transformer. https://jalammar.github.io/illustrated-transformer/. Recurso visual para seguir el flujo de Q, K, V y multi-head attention. ↩
Rush, A. M. (2018). The Annotated Transformer. https://nlp.seas.harvard.edu/annotated-transformer/. Implementación anotada del Transformer original con código y explicación matemática. ↩
Cho, A., Kim, G. C., Karpekov, A., Helbling, A., Wang, Z. J., Lee, S., Hoover, B. y Chau, D. H. (2025). Transformer Explainer: interactive learning of text-generative models. En Proceedings of the AAAI Conference on Artificial Intelligence. https://ojs.aaai.org/index.php/AAAI/article/download/35347/37502. La herramienta permite visualizar componentes de un GPT-2 pequeño en navegador. ↩
Holtzman, A., Buys, J., Du, L., Forbes, M. y Choi, Y. (2020). The curious case of neural text degeneration. En International Conference on Learning Representations. https://openreview.net/forum?id=rygGQyrFvH. El artículo analiza cómo distintas estrategias de muestreo afectan a la calidad del texto generado. ↩

Capítulo 04

Facsímil 3 · Arquitecturas y modelos

Capítulo 04: MLP, residual, LayerNorm, logits y sampling

Después de mirar, hay que pensar y decidir

En el capítulo anterior abrimos la atención por dentro: $Q$ , $K$ , $V$ , máscara causal y softmax. Vimos cómo cada token mezcla información de posiciones permitidas. Pero un bloque Transformer no termina ahí.

Después de la atención queda trabajo: estabilizar números, dejar pasar información antigua, transformar cada posición con una red interna y, al final de muchas capas, convertir el último vector en una lista enorme de puntuaciones para tokens posibles.

Este capítulo va de ese tramo menos vistoso y muy importante. La atención decide de dónde tomar información. El MLP ayuda a transformar qué significa esa información. Las conexiones residuales permiten que las capas se apilen sin destruir lo anterior. LayerNorm mantiene los números en una zona manejable. Los logits y el sampling convierten todo eso en una palabra, un signo, un salto de línea o un fragmento de código.

Qué no es esta parte del Transformer

El MLP no es una memoria externa. No guarda documentos ni hechos como una base de datos. Es una transformación aprendida que se aplica a cada posición del tensor.

LayerNorm tampoco es una limpieza semántica del texto. No corrige ideas ni comprueba si algo es cierto. Normaliza números para que el entrenamiento y la inferencia sean más estables.

Y sampling no es una votación de verdad. Cuando el modelo elige el siguiente token, está usando una distribución de probabilidad lingüística. Que un token tenga mucha probabilidad significa que encaja con el contexto y con lo aprendido, no que la frase resultante sea necesariamente cierta.

Qué sí ocurre dentro de un bloque

Un bloque Transformer moderno suele seguir una idea parecida a esta:

entrada
  -> normalización
  -> atención
  -> suma residual
  -> normalización
  -> MLP
  -> suma residual
salida

El Transformer original ya combinaba atención, red feed-forward, normalización y conexiones residuales.¹ Muchas implementaciones actuales usan una variante llamada pre-norm: normalizan antes de la atención y antes del MLP.

Una forma compacta de escribirlo es:

a_l = x_l + \operatorname{Attention}(\operatorname{LN}(x_l))

x_{l+1} = a_l + \operatorname{MLP}(\operatorname{LN}(a_l))

Símbolo	Significado	Ejemplo
$x_l$	Entrada del bloque $l$ .	Tensor después del bloque anterior.
$a_l$	Estado intermedio después de atención y residual.	Lo que sale antes del MLP.
$x_{l+1}$	Salida del bloque.	Entrada del siguiente bloque.
$\operatorname{LN}$	LayerNorm.	Normaliza cada vector de posición.
$\operatorname{Attention}$	Atención causal vista en el capítulo 03.	Q, K, V, máscara y softmax.
$\operatorname{MLP}$	Red interna aplicada por posición.	Dos o tres proyecciones con una activación.

La lectura humana es sencilla: no borramos lo anterior, sumamos una transformación nueva encima. Esa suma residual es una de las razones por las que podemos apilar muchas capas.

Un ejemplo entendible: autocompletar un mensaje

Imagina que escribes en una aplicación de correo:

Nos vemos mañana a las

El modelo no piensa en castellano con una libreta al lado. Lo que tiene es una representación numérica del contexto y debe decidir el siguiente token. Aun así, podemos traducir las piezas del bloque a una historia bastante humana:

Pieza	En el ejemplo	Qué aporta
Atención	Mira «vemos», «mañana» y «a las».	Recupera que probablemente viene una hora.
Residual	Conserva la frase completa mientras añade señales nuevas.	No pierde que estamos hablando de una cita.
LayerNorm	Pone las señales numéricas en una escala comparable.	Evita que una dimensión grande domine solo por tamaño.
MLP	Transforma la representación de la última posición.	Refuerza patrones como «a las» → hora o número.
Logits	Asigna puntuaciones a tokens candidatos.	«10», «9», «reunión», «azul» reciben valores distintos.
Sampling	Elige el siguiente token según la distribución y la configuración.	Puede elegir «10» de forma conservadora o explorar alternativas.

Supongamos que, tras muchas capas, la cabeza de lenguaje produce estos logits:

Token candidato	Logit	Lectura informal
10	4,2	Muy compatible con «a las».
9	3,9	También muy compatible.
reunión	1,1	Tiene relación con el contexto, pero encaja peor justo después de «a las».
azul	-0,7	Gramatical y semánticamente flojo aquí.

Si usamos temperatura baja, el sistema tenderá a elegir entre «10» y «9». Si subimos la temperatura o abrimos mucho top_p, aumenta la posibilidad de tokens menos esperados. Esto no vuelve al modelo más profundo; cambia el margen de exploración.

Este ejemplo resume el capítulo entero: el bloque procesa la frase, los logits proponen continuaciones y el sampling decide cuánto riesgo aceptamos al elegir una.

Residual: dejar una vía abierta

Una conexión residual suma la entrada original con una transformación:

y = x + F(x)

Símbolo	Significado	Ejemplo
$x$	Representación que llega a una subcapa.	Vector de un token antes de la atención.
$F(x)$	Transformación aprendida.	Atención o MLP.
$y$	Resultado después de sumar entrada y transformación.	Vector actualizado.

La idea se popularizó con ResNet en visión por computador: una red profunda entrena mejor si cada bloque puede aprender una corrección sobre lo que ya venía circulando.²

En un LLM, la intuición práctica es esta:

Sin residual	Con residual
Cada subcapa tiene que reconstruir todo lo útil.	Cada subcapa puede añadir una corrección.
Es más fácil degradar información anterior.	La representación anterior sigue disponible.
Entrenar muchas capas se vuelve más frágil.	Apilar capas profundas es más viable.

Ejemplo pequeño:

x = [2,\ -1,\ 0{,}5]

F(x) = [0{,}1,\ 0{,}4,\ -0{,}2]

y = x + F(x) = [2{,}1,\ -0{,}6,\ 0{,}3]

La transformación ha modificado el vector, pero no lo ha sustituido por completo. Ese matiz importa mucho en redes profundas.

LayerNorm: poner los números en una escala manejable

LayerNorm normaliza cada vector de activaciones usando su propia media y desviación típica.³ Para un vector $x$ , calculamos:

\mu = \frac{1}{d}\sum_{i=1}^{d} x_i

\sigma = \sqrt{\frac{1}{d}\sum_{i=1}^{d}(x_i-\mu)^2+\epsilon}

\operatorname{LN}(x)_i = \gamma_i \frac{x_i-\mu}{\sigma} + \beta_i

Símbolo	Significado	Ejemplo
$x_i$	Componente $i$ del vector.	$x_2=-1$ .
$d$	Dimensión del vector.	$d=3$ .
$\mu$	Media del vector.	Media de $[2,-1,0{,}5]$ .
$\sigma$	Desviación típica con estabilidad numérica.	Incluye $\epsilon$ .
$\epsilon$	Número pequeño para evitar división por cero.	$10^{-5}$ .
$\gamma_i$	Escala aprendida.	Permite ajustar la salida normalizada.
$\beta_i$	Sesgo aprendido.	Permite desplazar la salida.

Si tomamos:

x = [2,\ -1,\ 0{,}5]

La media es:

\mu = \frac{2-1+0{,}5}{3}=0{,}5

Las diferencias respecto a la media son:

[1{,}5,\ -1{,}5,\ 0]

La desviación típica, ignorando $\epsilon$ para leer el ejemplo, es:

\sigma = \sqrt{\frac{1{,}5^2 + (-1{,}5)^2 + 0^2}{3}} \approx 1{,}225

Si $\gamma=[1,1,1]$ y $\beta=[0,0,0]$ , la salida aproximada es:

\operatorname{LN}(x) \approx [1{,}225,\ -1{,}225,\ 0]

LayerNorm no cambia el orden de las ideas por sí sola. Cambia la escala de los números para que las siguientes operaciones trabajen en una zona más estable.

MLP: transformar cada posición por dentro

Después de la atención, el bloque Transformer aplica una red feed-forward por posición. En muchos textos se llama MLP, aunque técnicamente es una red pequeña aplicada a cada token por separado.

Una versión clásica es:

\operatorname{MLP}(x)=W_2\phi(W_1x+b_1)+b_2

Símbolo	Significado	Ejemplo
$x$	Vector de una posición.	Representación contextual de «banco».
$W_1$	Primera matriz aprendida.	Expande la dimensión interna.
$b_1$	Sesgo de la primera proyección.	Vector sumado antes de la activación.
$\phi$	Función de activación.	GELU, ReLU o una variante con puerta.
$W_2$	Segunda matriz aprendida.	Devuelve la dimensión al tamaño del modelo.
$b_2$	Sesgo final.	Ajuste aprendido de salida.

Las redes profundas usan activaciones no lineales para poder representar funciones más ricas que una sola multiplicación de matrices.⁴ En Transformers modernos, GELU se hizo muy común en modelos de lenguaje.⁵ También hay variantes con puertas, como GLU y SwiGLU, que permiten modular qué información pasa.⁶

La intuición:

Pieza	Qué hace
Atención	Mezcla información entre posiciones.
MLP	Transforma cada posición internamente.
Residual	Conserva una vía para lo que ya estaba.
LayerNorm	Mantiene los números en una escala razonable.

Si la atención es una mesa de mezclas entre tokens, el MLP es el taller interno de cada token. No decide a qué otros tokens mirar; trabaja con lo que ya recibió.

Del último vector a los logits

Tras repetir muchos bloques, el modelo tiene una representación final. Para predecir el siguiente token, toma el vector de la última posición y lo proyecta al tamaño del vocabulario:

z = h W_{\text{vocab}} + b

Símbolo	Significado	Ejemplo
$h$	Vector final de la última posición.	Representación de todo el contexto disponible.
$W_{\text{vocab}}$	Matriz que lleva de dimensión interna a vocabulario.	De $d_{\text{model}}$ a 50 000 tokens.
$b$	Sesgo de vocabulario.	Una puntuación adicional por token.
$z$	Vector de logits.	Una puntuación por token candidato.

Un logit no es una probabilidad. Puede ser negativo, positivo, grande o pequeño. Para convertir logits en una distribución usamos softmax, igual que vimos en el capítulo 01 y en el capítulo 03:

p_i = \frac{e^{z_i}}{\sum_{j=1}^{V}e^{z_j}}

Símbolo	Significado	Ejemplo
$p_i$	Probabilidad asignada al token $i$ .	$p_{\text{Madrid}}=0{,}256$ .
$z_i$	Logit del token $i$ .	$z_{\text{París}}=4{,}0$ .
$V$	Tamaño del vocabulario.	50 000 tokens candidatos.
$\sum_{j=1}^{V}$	Suma sobre todos los tokens.	Normaliza para que las probabilidades sumen 1.

Bishop presenta softmax como una transformación estándar de puntuaciones en probabilidades normalizadas.⁷ En LLMs, esa transformación no juzga la verdad de una frase: convierte puntuaciones de continuación en una distribución de tokens.

Temperatura: abrir o cerrar el abanico

La temperatura modifica los logits antes de softmax:

p_i(T) = \frac{e^{z_i/T}}{\sum_{j=1}^{V}e^{z_j/T}}

Símbolo	Significado	Ejemplo
$T$	Temperatura.	$T=0{,}5$ , $T=1$ , $T=2$ .
$z_i/T$	Logit ajustado por temperatura.	Si $T<1$ , las diferencias crecen.
$p_i(T)$	Probabilidad después de aplicar temperatura.	Distribución más concentrada o más suave.

Supongamos cuatro tokens candidatos:

Token	Logit
París	4,0
Madrid	3,0
Lyon	1,0
azul	0,0

Con $T=1$ :

Token	Probabilidad aprox.
París	0,696
Madrid	0,256
Lyon	0,035
azul	0,013

Con $T=0{,}5$ , las diferencias se agrandan:

Token	Probabilidad aprox.
París	0,879
Madrid	0,119
Lyon	0,002
azul	0,000

Con $T=2$ , las diferencias se suavizan:

Token	Probabilidad aprox.
París	0,509
Madrid	0,309
Lyon	0,114
azul	0,069

Temperatura baja no significa «más inteligente». Significa más conservadora en la elección del siguiente token. Temperatura alta no significa «mejor creatividad». Significa más dispersión en la distribución. En producto, esto se decide según la tarea: extracción estructurada, redacción, lluvia de ideas, código, resumen o conversación.

Top-k y top-p: limitar candidatos

Además de temperatura, se suelen aplicar reglas para limitar el conjunto de tokens candidatos.

Top-k conserva los $k$ tokens con mayor probabilidad y pone el resto a cero:

C_k = \operatorname{TopK}(p, k)

p'_i = \begin{cases} \frac{p_i}{\sum_{j \in C_k}p_j} & \text{si } i \in C_k \ 0 & \text{si } i \notin C_k \end{cases}

Símbolo	Significado	Ejemplo
$C_k$	Conjunto de tokens conservados.	Con $k=2$ : París y Madrid.
$p'_i$	Probabilidad renormalizada.	Probabilidad después de eliminar candidatos.
$i \notin C_k$	Token descartado por top-k.	Lyon y azul reciben 0.

Top-p, también llamado nucleus sampling, conserva el conjunto mínimo de tokens cuya probabilidad acumulada alcanza un umbral $p$ . Holtzman y coautores popularizaron esta estrategia para reducir degeneraciones en generación abierta.⁸

Si ordenamos de mayor a menor:

Token	Probabilidad	Acumulada
París	0,696	0,696
Madrid	0,256	0,952
Lyon	0,035	0,987
azul	0,013	1,000

Con $p=0{,}9$ , top-p conserva París y Madrid, porque con esos dos ya alcanza 0,952. Después renormaliza solo dentro de ese conjunto.

La diferencia importante:

Regla	Qué fija	Qué cambia
Top-k	Número de candidatos.	La masa de probabilidad conservada.
Top-p	Masa de probabilidad mínima.	El número de candidatos.

En una distribución muy concentrada, top-p puede conservar pocos tokens. En una distribución muy plana, puede conservar muchos. Esa elasticidad es la gracia.

El mapa operativo del capítulo

Este es el circuito que conviene tener en la cabeza antes de seguir. No hace falta memorizarlo como una lista; basta con poder recorrerlo de izquierda a derecha.

flowchart TB
    C03["Cap. 03<br/>atención causal"]
    BLOCK["Bloque Transformer<br/>LayerNorm · atención · residual · MLP"]
    LOGITS["Cabeza de lenguaje<br/>logits"]
    SOFT["Softmax con temperatura<br/>distribución"]
    FILTER["Top-k / top-p<br/>candidatos"]
    TOKEN["Token elegido<br/>nuevo contexto"]
    C05["Cap. 05<br/>arquitecturas modernas"]
    C07["Cap. 07<br/>inferencia y hardware"]
    F04["Fasc. 04<br/>APIs y RAG"]
    F07["Fasc. 07<br/>evaluación"]

    C03 -->|"entrega contexto a"| BLOCK
    BLOCK -->|"produce vector final para"| LOGITS
    LOGITS -->|"normalizar con"| SOFT
    SOFT -->|"limitar con"| FILTER
    FILTER -->|"elegir"| TOKEN
    BLOCK -->|"evoluciona hacia"| C05
    FILTER -->|"se configura en"| F04
    TOKEN -->|"se repite en"| C07
    SOFT -->|"se calibra en"| F07

    style BLOCK fill:#F5F5F5,stroke:#000000,stroke-width:2
    style LOGITS fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SOFT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style FILTER fill:#F5F5F5,stroke:#000000,stroke-width:2
    style TOKEN fill:#F5F5F5,stroke:#000000,stroke-width:2
    style C03 stroke-dasharray: 5 5
    style C05 stroke-dasharray: 5 5
    style C07 stroke-dasharray: 5 5
    style F04 stroke-dasharray: 5 5
    style F07 stroke-dasharray: 5 5

Simuladores para verlo en pantalla

Dos recursos ayudan especialmente aquí:

Recurso	Qué mirar
LLM Visualization	Recorre las capas y localiza el paso desde bloques internos a logits.⁹
Transformer Explainer	Cambia texto de entrada y observa cómo varía la distribución del siguiente token.¹⁰

Úsalos con una pregunta concreta: ¿dónde se convierte el vector final en logits?, ¿dónde aparece softmax?, ¿qué cambia si modifico el texto anterior?

En el día a día

Cuando quieres salida estable. Para extracción JSON, clasificación o tareas con formato rígido, normalmente quieres menos variación: temperatura baja, pocos candidatos y validación posterior. No porque el modelo «sepa más», sino porque reduces el abanico de continuaciones posibles.

Cuando quieres explorar. Para escritura creativa, alternativas de copy o lluvia de ideas, puedes permitir más variedad. Ahí temperatura y top-p se convierten en mandos de exploración. Conviene medir resultados, no elegir parámetros por superstición.

Cuando depuras una respuesta extraña. Si una salida cambia mucho entre ejecuciones, no siempre es un problema de prompt. Puede haber temperatura alta, top-p amplio o muestreo activado. Antes de cambiar de modelo, mira la configuración de generación.

Cuando eliges arquitectura. MLP, normalización y residuales parecen detalles internos, pero afectan a estabilidad, velocidad, memoria y calidad. En el capítulo 05 veremos cómo modelos modernos cambian estas piezas: MoE, activaciones con puerta y variaciones de arquitectura.

Por qué debería importarte

Porque esta parte une dos mundos: arquitectura interna y comportamiento visible. El lector ve texto, pero por debajo hay logits, temperatura, filtros de candidatos y muestreo. Entender esa cadena evita explicaciones vagas.

Si un modelo responde siempre igual, puede ser por una distribución muy concentrada o por una configuración conservadora. Si responde con demasiada dispersión, quizá la temperatura o top-p están abriendo demasiado el abanico. Si un modelo grande cuesta mucho, parte del coste está en repetir bloques con atención, MLP y proyecciones a vocabulario miles de veces por segundo.

Dónde volverá a aparecer

Concepto de este capítulo	Dónde vuelve en el libro	Por qué se conecta
MLP	Facsímil 3, capítulo 05; facsímil 6.	MoE cambia la forma de usar redes internas; operación y coste dependen de estas capas.
Residual y LayerNorm	Facsímil 3, capítulo 06; facsímil 7.	Ajuste, destilación y evaluación heredan decisiones de estabilidad de la arquitectura base.
Logits	Facsímil 1, capítulo 07; facsímil 7.	Calibración, confianza y evaluación necesitan separar puntuación de verdad.
Temperatura, top-k y top-p	Facsímil 4; facsímil 5.	APIs, agentes y herramientas exponen estos parámetros como decisiones de producto.
Sampling	Facsímil 6; facsímil 11.	Operación y UX dependen de cuánta variación aceptas en una tarea real.

Dónde solía tropezar yo

Error	Por qué es un error	Antídoto
Pensar que LayerNorm entiende el texto	Normaliza números; no valida significado.	Pregunta siempre si una pieza trabaja con escala numérica o con decisión de contenido.
Confundir logit con probabilidad	Un logit es una puntuación cruda; puede ser negativa y no suma nada.	No hables de probabilidad hasta aplicar softmax.
Creer que temperatura baja equivale a verdad	Solo concentra la distribución en tokens más probables.	Para verdad factual, usa contexto, fuentes y validación.
Olvidar que el MLP no mezcla posiciones	La mezcla entre tokens la hizo la atención; el MLP transforma cada posición.	Repite: atención mezcla entre posiciones, MLP transforma dentro de una posición.
Usar top-k y top-p como si fueran lo mismo	Top-k fija número de candidatos; top-p fija masa acumulada.	Mira una tabla ordenada de probabilidades y calcula ambos a mano una vez.

Manos a la obra

La práctica real está en kit descargable. El kit aísla LayerNorm, softmax con temperatura, top-k y top-p para que puedas ver qué cambia cada mando sin construir un LLM completo.

Archivo	Qué contiene
`data/sampling_case.json`	Vector, logits, tokens y parámetros de sampling.
`contracts/sampling_policy.json`	Umbrales de distribución válida.
`ops/run_sampling_controls.py`	LayerNorm, softmax, top-k, top-p y entropía.
`output/sampling_controls_report.json`	Distribuciones y métricas.
`output/sampling_controls_decision.md`	Lectura técnica.

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/run_sampling_controls.py --write
cat output/sampling_controls_decision.md

Como gate:

python3 ops/run_sampling_controls.py --write --fail-on-invalid

Qué entregaría un alumno. El Markdown generado, una configuración nueva de temperatura/top-p y una decisión sobre estabilidad frente a diversidad.

Cómo encaja todo

Este mapa enseña el tramo que suele quedar invisible entre “atención” y “respuesta”. La atención entrega una representación contextual; residual, LayerNorm y MLP la estabilizan y transforman; logits, softmax y sampling la convierten en comportamiento visible.

Por eso el capítulo conecta arquitectura con producto: temperatura, top_k y top_p no son adornos de API, sino controles sobre una distribución que nace de todo el bloque Transformer.

graph TD
    F3C01["Facsímil 3, capítulo 1<br/>LLM, logits y escala"]
    F3C03["Facsímil 3, capítulo 3<br/>Q, K, V y atención"]
    C4["Este capítulo<br/>residual, LayerNorm, MLP y sampling"]
    RES["Conexión residual<br/>conservar señal"]
    LN["LayerNorm<br/>estabilizar activaciones"]
    MLP["MLP<br/>transformar cada posición"]
    LOGITS["Logits<br/>puntuaciones de vocabulario"]
    SOFT["Softmax<br/>probabilidades"]
    SAMPLING["Sampling<br/>temperatura · top-k · top-p"]
    F3C05["Facsímil 3, capítulo 5<br/>MoE y variantes modernas"]
    F3C07["Facsímil 3, capítulo 7<br/>inferencia optimizada"]
    F4["Facsímil 4<br/>APIs y RAG"]
    F7["Facsímil 7<br/>evaluación y calibración"]

    F3C03 -->|"entrega atención a"| C4
    F3C01 -->|"anticipa"| LOGITS
    C4 -->|"usa"| RES
    C4 -->|"usa"| LN
    C4 -->|"usa"| MLP
    RES -->|"permite apilar"| MLP
    LN -->|"estabiliza"| MLP
    MLP -->|"alimenta tras capas"| LOGITS
    LOGITS -->|"se normalizan con"| SOFT
    SOFT -->|"se decide mediante"| SAMPLING
    MLP -->|"se especializa en"| F3C05
    SAMPLING -->|"afecta a"| F4
    SAMPLING -->|"repite durante"| F3C07
    SOFT -->|"se audita en"| F7

    style C4 fill:#F5F5F5,stroke:#000000,stroke-width:2
    style RES fill:#F5F5F5,stroke:#000000,stroke-width:2
    style LN fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MLP fill:#F5F5F5,stroke:#000000,stroke-width:2
    style LOGITS fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SOFT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SAMPLING fill:#F5F5F5,stroke:#000000,stroke-width:2
    style F3C01 stroke-dasharray: 5 5
    style F3C03 stroke-dasharray: 5 5
    style F3C05 stroke-dasharray: 5 5
    style F3C07 stroke-dasharray: 5 5
    style F4 stroke-dasharray: 5 5
    style F7 stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición
Conexión residual	Suma que conserva la entrada y añade una transformación aprendida.
LayerNorm	Normalización que usa media y desviación típica dentro de cada vector.
MLP	Red interna aplicada por posición después de la atención.
Activación	Función no lineal que permite representar transformaciones más ricas.
Logit	Puntuación cruda de un token antes de softmax.
Temperatura	Parámetro que concentra o suaviza la distribución de salida.
Top-k	Muestreo que conserva solo los $k$ candidatos principales.
Top-p	Muestreo que conserva candidatos hasta alcanzar una probabilidad acumulada.
Sampling	Proceso de elegir el siguiente token a partir de una distribución.

Antes de pasar página

¿Puedo explicar por qué una conexión residual suma en vez de reemplazar? (Si no, vuelve a «Residual: dejar una vía abierta».)
¿Sé calcular la media y desviación típica de una LayerNorm pequeña? (Si no, vuelve a «LayerNorm».)
¿Entiendo por qué el MLP transforma cada posición pero no mezcla tokens? (Si no, vuelve a «MLP».)
¿Puedo distinguir logit, probabilidad y token elegido? (Si no, vuelve a «Del último vector a los logits».)
¿Puedo explicar el ejemplo de «Nos vemos mañana a las» usando residual, LayerNorm, MLP, logits y sampling? (Si no, vuelve a «Un ejemplo entendible».)
¿Sé qué cambia cuando bajo o subo la temperatura? (Si no, vuelve a «Temperatura».)
¿Puedo calcular top-k y top-p con una tabla de cuatro tokens? (Si no, vuelve a «Top-k y top-p».)
¿He ejecutado el código y cambiado al menos un parámetro de muestreo? (Si no, vuelve a «Manos a la obra».)
¿Puedo conectar estos mandos con APIs, agentes y evaluación futura? (Si no, vuelve a «Dónde volverá a aparecer».)

En resumen

Idea fuerza	Detalle
Un bloque Transformer no es solo atención.	Residual, LayerNorm y MLP hacen que la información circule, se estabilice y se transforme.
Los logits son puntuaciones, no probabilidades.	Softmax convierte esas puntuaciones en una distribución sobre el vocabulario.
Sampling es una decisión de comportamiento.	Temperatura, top-k y top-p cambian cuánta variación permitimos al generar.
La arquitectura interna afecta al producto visible.	Estabilidad, coste, latencia y estilo de respuesta dependen de estas piezas.

Para saber más

Ba, J. L., Kiros, J. R. y Hinton, G. E. (2016). Layer normalization. https://arxiv.org/abs/1607.06450

Bishop, C. M. (2006). Pattern recognition and machine learning. Springer.

Brown, T. B. et al. (2020). Language models are few-shot learners. En Advances in Neural Information Processing Systems 33 (pp. 1877-1901). https://papers.nips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html

Bycroft, B. (2023). LLM Visualization. https://bbycroft.net/llm

Cho, A., Kim, G. C., Karpekov, A., Helbling, A., Wang, Z. J., Lee, S., Hoover, B. y Chau, D. H. (2025). Transformer Explainer: interactive learning of text-generative models. En Proceedings of the AAAI Conference on Artificial Intelligence. https://ojs.aaai.org/index.php/AAAI/article/download/35347/37502

Goodfellow, I., Bengio, Y. y Courville, A. (2016). Deep learning. MIT Press. https://www.deeplearningbook.org

He, K., Zhang, X., Ren, S. y Sun, J. (2016). Deep residual learning for image recognition. En Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 770-778). https://doi.org/10.1109/CVPR.2016.90

Hendrycks, D. y Gimpel, K. (2016). Gaussian Error Linear Units (GELUs). https://arxiv.org/abs/1606.08415

Holtzman, A., Buys, J., Du, L., Forbes, M. y Choi, Y. (2020). The curious case of neural text degeneration. En International Conference on Learning Representations. https://openreview.net/forum?id=rygGQyrFvH

Radford, A., Wu, J., Child, R., Luan, D., Amodei, D. y Sutskever, I. (2019). Language models are unsupervised multitask learners. https://cdn.openai.com/better-language-models/language_models_are_unsupervised_multitask_learners.pdf

Shazeer, N. (2020). GLU variants improve Transformer. https://arxiv.org/abs/2002.05202

Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł. y Polosukhin, I. (2017). Attention is all you need. En Advances in Neural Information Processing Systems 30 (pp. 5998-6008). https://papers.nips.cc/paper/7181-attention-is-all-you-need

Notas

Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł. y Polosukhin, I. (2017). Attention is all you need. En Advances in Neural Information Processing Systems 30 (pp. 5998-6008). https://papers.nips.cc/paper/7181-attention-is-all-you-need. El artículo introduce capas de atención multi-cabeza, redes feed-forward por posición, conexiones residuales y normalización. ↩
He, K., Zhang, X., Ren, S. y Sun, J. (2016). Deep residual learning for image recognition. En Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 770-778). https://doi.org/10.1109/CVPR.2016.90. Las conexiones residuales ayudaron a entrenar redes mucho más profundas al permitir que la información y el gradiente circularan con menos degradación. ↩
Ba, J. L., Kiros, J. R. y Hinton, G. E. (2016). Layer normalization. https://arxiv.org/abs/1607.06450. LayerNorm normaliza las activaciones de una capa para cada ejemplo, lo que resulta útil en arquitecturas de secuencia y Transformer. ↩
Goodfellow, I., Bengio, Y. y Courville, A. (2016). Deep learning. MIT Press. https://www.deeplearningbook.org. El libro explica cómo las capas lineales y activaciones no lineales permiten componer funciones complejas. ↩
Hendrycks, D. y Gimpel, K. (2016). Gaussian Error Linear Units (GELUs). https://arxiv.org/abs/1606.08415. GELU propone una activación suave que se adoptó en varias arquitecturas de lenguaje. ↩
Shazeer, N. (2020). GLU variants improve Transformer. https://arxiv.org/abs/2002.05202. El trabajo estudia variantes con puertas para mejorar el bloque feed-forward de Transformers. ↩
Bishop, C. M. (2006). Pattern recognition and machine learning. Springer. Softmax aparece como una forma de convertir puntuaciones reales en probabilidades multinomiales. ↩
Holtzman, A., Buys, J., Du, L., Forbes, M. y Choi, Y. (2020). The curious case of neural text degeneration. En International Conference on Learning Representations. https://openreview.net/forum?id=rygGQyrFvH. El artículo analiza problemas de decodificación y propone nucleus sampling como alternativa a estrategias demasiado rígidas. ↩
Bycroft, B. (2023). LLM Visualization. https://bbycroft.net/llm. Visualización interactiva 3D de un Transformer estilo GPT. ↩
Cho, A., Kim, G. C., Karpekov, A., Helbling, A., Wang, Z. J., Lee, S., Hoover, B. y Chau, D. H. (2025). Transformer Explainer: interactive learning of text-generative models. En Proceedings of the AAAI Conference on Artificial Intelligence. https://ojs.aaai.org/index.php/AAAI/article/download/35347/37502. La herramienta permite visualizar componentes de un GPT-2 pequeño en navegador. ↩

Capítulo 05

Facsímil 3 · Arquitecturas y modelos

Capítulo 05: Arquitecturas modernas: familias, MoE, razonamiento y multimodalidad

Tres formas de hacer que un modelo sea más capaz

Hasta ahora hemos mirado el Transformer clásico por dentro: tokens, tensores, atención, $Q$ , $K$ , $V$ , residual, LayerNorm, MLP, logits y sampling. Ya tenemos la maquinaria básica. Ahora aparece una pregunta natural: si eso funciona, ¿cómo lo hacemos más capaz sin limitarnos a hacerlo todo más grande?

Las arquitecturas modernas suelen tocar tres palancas:

Palanca	Pregunta que responde	Ejemplo
Capacidad	¿Cómo meto más conocimiento y patrones sin pagar todo el coste en cada token?	Mixture of Experts, o MoE.
Proceso	¿Cómo doy más tiempo de cálculo a problemas que necesitan varios pasos?	Razonamiento, varias muestras, verificación.
Entrada	¿Cómo hago que el modelo trabaje con texto, imágenes, audio o acciones?	Modelos multimodales.

Este capítulo va de esas tres palancas. No son trucos aislados. Son respuestas distintas a la misma tensión: queremos modelos más útiles, pero tenemos límites de memoria, latencia, coste, datos y evaluación.

Qué no significan estas palabras

MoE no significa que haya expertos humanos dentro del modelo. La palabra experto engaña un poco. En la práctica, un experto suele ser una red interna, normalmente parecida al MLP del capítulo anterior, y un router decide qué expertos se activan para cada token.

Razonamiento no significa que el modelo piense como una persona. En IA moderna, muchas veces llamamos razonamiento a dedicar más pasos de generación, probar varias rutas, verificar resultados o entrenar el modelo para resolver tareas paso a paso. Eso puede mejorar resultados, pero no convierte al modelo en una mente humana.

Multimodal no significa que el modelo vea como tú. Un modelo puede procesar una imagen, pero lo hace transformándola en representaciones numéricas. A veces esas representaciones son muy útiles; otras veces fallan en detalles espaciales, texto pequeño, conteos o relaciones visuales delicadas.

Más moderno no significa automáticamente mejor para tu caso. Un modelo MoE puede ser excelente, pero más complejo de servir. Un modelo multimodal puede ser muy útil, pero más caro y más difícil de evaluar. Un modelo con razonamiento puede resolver mejor ciertas tareas, pero tardar más o necesitar controles de calidad distintos.

El mapa amplio de arquitecturas

Antes de entrar en MoE, razonamiento y multimodalidad, conviene abrir el plano completo. No existe una lista cerrada de «todas las arquitecturas», porque la investigación mezcla familias continuamente. Pero sí hay un mapa útil para no perderse.

Una primera separación:

Nivel	Qué es	Ejemplo
Arquitectura neuronal	La forma interna de la red.	Transformer, CNN, RNN, MoE, Mamba, difusión.
Modelo entrenado	Una arquitectura con pesos aprendidos en datos concretos.	BERT, GPT-2, T5, Mixtral, CLIP.
Arquitectura de sistema	Cómo conectas modelos, datos, herramientas y validadores.	RAG, agente con herramientas, pipeline multimodal.

Esta distinción evita una confusión muy común: RAG, por ejemplo, no es una capa neuronal como LayerNorm. Es una arquitectura de sistema que combina recuperación de información con generación.¹

Familias neuronales clásicas y actuales

Familia	Idea central	Se usa mucho en	Qué debes recordar
MLP	Capas densas que transforman vectores.	Tabular, bloques internos de Transformers.	No mezcla posiciones; transforma representaciones.
CNN	Filtros locales que detectan patrones espaciales.	Imagen, audio, visión industrial.	Muy fuertes cuando importa la vecindad local.²
RNN / LSTM / GRU	Procesan secuencias manteniendo un estado.	Series temporales, lenguaje antes del dominio Transformer.	Buen punto histórico para entender secuencia, aunque hoy compiten con Transformers y SSM.³
Transformer	Atención para mezclar información entre posiciones.	LLMs, traducción, visión, multimodalidad.	Es la familia dominante en lenguaje moderno, pero no la única.
GNN	Mensajes entre nodos de un grafo.	Moléculas, redes, conocimiento estructurado.	Sirven cuando la estructura no es una secuencia sino un grafo.⁴
Autoencoders / VAE	Comprimir y reconstruir datos mediante una representación latente.	Generación, compresión, representación.	Enseñan la idea de espacio latente.⁵
Diffusion models	Aprenden a quitar ruido paso a paso.	Imagen, audio, vídeo, generación visual.	Generan invirtiendo un proceso de ruido.⁶
State Space Models	Mantienen un estado y procesan secuencias con coste favorable.	Secuencias largas, lenguaje, audio, señales.	Mamba reabrió el interés por alternativas al Transformer puro.⁷

Familias Transformer en lenguaje

Dentro de Transformers hay varias arquitecturas que conviene distinguir:

Familia	Cómo lee	Cómo genera	Ejemplo	Uso típico
Encoder-only	Mira el texto completo a ambos lados.	No está pensado principalmente para generar de izquierda a derecha.	BERT.⁸	Clasificación, búsqueda semántica, extracción, embeddings.
Decoder-only	Mira solo el pasado disponible.	Predice el siguiente token.	GPT-2.⁹	Chat, completado, código, generación libre.
Encoder-decoder	Un encoder lee la entrada; un decoder genera la salida.	Genera condicionándose en lo leído.	T5 y BART.¹⁰ BART combina un encoder bidireccional y un decoder autoregresivo.¹¹	Traducción, resumen, transformación de texto.
Vision Transformer	Divide imágenes en parches tratados como tokens.	Depende de la tarea: clasificar, detectar, generar en sistemas híbridos.	ViT.¹²	Visión y multimodalidad.
MoE Transformer	Usa atención y sustituye partes densas por expertos.	Igual que su base, pero con cómputo disperso.	Switch, Mixtral.	Más capacidad con menos parámetros activos por token.
Long-context / eficiente	Cambia atención, memoria o estado para manejar contextos largos.	Puede ser decoder, encoder o híbrido.	Mamba, variantes de atención eficiente.	Documentos largos, audio, series, agentes con memoria.

La pregunta útil no es «¿cuál es mejor?», sino «¿qué forma de leer y generar necesita mi problema?».

Arquitecturas de sistema que parecen arquitectura neuronal, pero no lo son

Sistema	Qué combina	Cuándo aparece
RAG	Recuperador, base documental, modelo generativo y citas o validadores.	Preguntas sobre conocimiento cambiante o privado.
Agente con herramientas	Modelo, herramientas, permisos, memoria, evaluadores y orquestación.	Tareas de varios pasos con acciones externas.
Pipeline multimodal	Codificadores de imagen/audio/documento, conectores y LLM.	Facturas, fotos, capturas, vídeo, voz.
Modelo local cuantizado	Pesos comprimidos, runtime local y límites de hardware.	Privacidad, coste, edge AI, baja latencia local.

Esto importa porque a veces se intenta resolver con arquitectura neuronal lo que en realidad es un problema de sistema. Si tu modelo falla porque no tiene el documento correcto, quizá no necesitas cambiar de LLM: necesitas recuperación, trazabilidad y evaluación.

flowchart TD
    ARCH["Arquitecturas de IA"]
    NEURAL["Arquitectura neuronal"]
    MODEL["Modelo entrenado"]
    SYSTEM["Arquitectura de sistema"]

    SEQ["Secuencia<br/>RNN · Transformer · SSM"]
    VISION["Visión<br/>CNN · ViT · difusión"]
    GRAPH["Grafos<br/>GNN"]
    GENERATIVE["Generación<br/>VAE · difusión · decoder"]

    ENCODER["Encoder-only<br/>BERT"]
    DECODER["Decoder-only<br/>GPT"]
    ENCDEC["Encoder-decoder<br/>T5 · BART"]
    MOE_NODE["MoE<br/>Switch · Mixtral"]
    MULTI_NODE["Multimodal<br/>CLIP · LLaVA"]

    RAG_NODE["RAG"]
    AGENT_NODE["Agentes"]
    LOCAL_NODE["Local / edge"]

    ARCH --> NEURAL
    ARCH --> MODEL
    ARCH --> SYSTEM
    NEURAL --> SEQ
    NEURAL --> VISION
    NEURAL --> GRAPH
    NEURAL --> GENERATIVE
    MODEL --> ENCODER
    MODEL --> DECODER
    MODEL --> ENCDEC
    MODEL --> MOE_NODE
    MODEL --> MULTI_NODE
    SYSTEM --> RAG_NODE
    SYSTEM --> AGENT_NODE
    SYSTEM --> LOCAL_NODE

    style ARCH fill:#F5F5F5,stroke:#000000,stroke-width:2
    style NEURAL fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MODEL fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SYSTEM fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SEQ fill:#FFFFFF,stroke:#000000
    style VISION fill:#FFFFFF,stroke:#000000
    style GRAPH fill:#FFFFFF,stroke:#000000
    style GENERATIVE fill:#FFFFFF,stroke:#000000
    style ENCODER fill:#FFFFFF,stroke:#000000
    style DECODER fill:#FFFFFF,stroke:#000000
    style ENCDEC fill:#FFFFFF,stroke:#000000
    style MOE_NODE fill:#FFFFFF,stroke:#000000
    style MULTI_NODE fill:#FFFFFF,stroke:#000000
    style RAG_NODE fill:#FFFFFF,stroke:#000000
    style AGENT_NODE fill:#FFFFFF,stroke:#000000
    style LOCAL_NODE fill:#FFFFFF,stroke:#000000

Un ejemplo cotidiano: el ticket de soporte

Imagina que una tienda recibe este mensaje:

Compré unos auriculares ayer. Han llegado rotos y necesito cambiarlos antes del viernes porque son para un regalo.

Un sistema sencillo podría mandar todo el texto al mismo modelo denso y pedir una respuesta. Eso funciona muchas veces. Pero una arquitectura moderna puede repartir mejor el trabajo:

Parte del problema	Qué necesita entender
«han llegado rotos»	Incidencia de producto o envío.
«cambiarlos»	Política de cambios y devoluciones.
«antes del viernes»	Urgencia temporal.
«son para un regalo»	Tono empático y prioridad percibida.

Un MoE intentaría activar rutas internas útiles para ese tipo de patrón. Un sistema con razonamiento podría separar pasos: identificar intención, comprobar restricciones, decidir respuesta, revisar si falta información. Un modelo multimodal entraría si el usuario adjunta una foto de los auriculares dañados o una captura del pedido.

Esta es la idea del capítulo: no nos interesan las siglas por sí mismas. Nos interesa qué problema resuelve cada arquitectura.

MoE: más capacidad sin activar todo

En el capítulo 04 vimos que cada bloque Transformer tiene un MLP. En muchos modelos MoE, esa parte se sustituye por varios MLPs llamados expertos. Para cada token, un router elige uno o varios expertos y solo esos se ejecutan.

La idea de activar partes del modelo según la entrada aparece en las capas sparsely-gated Mixture-of-Experts de Shazeer y coautores.¹³

Después, GShard llevó esta idea a escalado con sharding automático y cómputo condicional.¹⁴ Switch Transformer simplificó el routing activando un experto por token.¹⁵

La fórmula básica:

s = W_r x

g = \operatorname{softmax}(s)

C_k = \operatorname{TopK}(g,k)

\operatorname{MoE}(x)=\sum_{i \in C_k}\frac{g_i}{\sum_{j \in C_k}g_j}E_i(x)

Símbolo	Significado	Ejemplo
$x$	Vector del token o posición que entra al bloque.	Representación de «rotos».
$W_r$	Matriz del router.	Produce puntuaciones para expertos.
$s$	Logits del router.	Una puntuación por experto.
$g$	Pesos tras softmax.	Probabilidad de usar cada experto.
$C_k$	Expertos seleccionados.	Si $k=2$ , se activan dos expertos.
$E_i(x)$	Salida del experto $i$ .	MLP especializado por entrenamiento.
$\operatorname{MoE}(x)$	Mezcla final de expertos activados.	Sustituye o complementa al MLP denso.

Ejemplo pequeño con cuatro expertos:

Experto	Peso del router $g_i$
$E_1$	0,62
$E_2$	0,24
$E_3$	0,09
$E_4$	0,05

Si usamos top-2, conservamos $E_1$ y $E_2$ . Renormalizamos:

\hat{g}_1=\frac{0{,}62}{0{,}62+0{,}24}\approx 0{,}721

\hat{g}_2=\frac{0{,}24}{0{,}62+0{,}24}\approx 0{,}279

La salida sería:

\operatorname{MoE}(x)\approx 0{,}721E_1(x)+0{,}279E_2(x)

La clave: el modelo puede tener muchos parámetros, pero no los usa todos en cada token. Eso aumenta capacidad sin multiplicar de la misma forma el coste por token. Mixtral 8x7B es un ejemplo conocido de modelo de lenguaje sparse MoE: tiene varios expertos por capa y activa solo una parte para cada token.¹⁶

La parte incómoda de MoE

MoE suena precioso en una frase: más capacidad, menos cómputo activo. Pero la ingeniería no sale gratis.

Problema	Qué ocurre	Por qué importa
Balanceo	El router puede mandar demasiados tokens a pocos expertos.	Algunos expertos se saturan y otros apenas aprenden.
Comunicación	En entrenamiento distribuido, los tokens viajan hacia expertos en distintos dispositivos.	Puede aumentar latencia y complejidad.
Servicio	No basta con contar parámetros totales.	Importa cuántos expertos se activan, dónde viven y cómo se cargan.
Interpretación	Un experto activado no siempre tiene una etiqueta humana clara.	No podemos decir sin prueba: «este experto sabe medicina».

Una analogía útil: MoE no es una empresa con departamentos perfectamente etiquetados. Se parece más a un edificio con varias salas de trabajo y un recepcionista que aprende a enviar cada ficha a unas salas concretas. Algunas salas acaban especializándose, pero esa especialización no tiene por qué coincidir con nuestras categorías humanas.

Razonamiento: más proceso, no solo más parámetros

En el uso cotidiano decimos que un modelo razona cuando resuelve algo que parece necesitar pasos: un problema matemático, una planificación, una comparación de opciones, una depuración de código o una decisión con restricciones.

En términos técnicos, muchas mejoras de razonamiento vienen de cambiar cómo se usa el modelo durante inferencia o entrenamiento:

Técnica	Qué hace	Ejemplo
Chain-of-thought	Usa ejemplos o instrucciones con pasos intermedios.	«Primero calcula el tiempo, luego comprueba la restricción».
Self-consistency	Genera varias soluciones y elige la respuesta más consistente.	Cinco rutas llegan a «14:30»; una ruta llega a «14:00».
Tree of Thoughts	Explora varias ramas de solución y evalúa avances parciales.	Planificar una agenda probando varias secuencias.
Verificación	Comprueba el resultado con reglas, código, tests o herramientas.	Ejecutar una consulta SQL o un test unitario.

El paper de chain-of-thought mostró que dar ejemplos con pasos intermedios podía mejorar tareas de razonamiento en modelos grandes.¹⁷ Self-consistency propuso generar varias rutas y escoger la respuesta que aparece de forma más consistente.¹⁸ Tree of Thoughts extendió esa idea hacia búsqueda sobre pasos intermedios.¹⁹

Podemos escribir self-consistency de forma simple:

r^{(m)} \sim p(r \mid x)

a^{(m)} = \operatorname{extraer\_respuesta}(r^{(m)})

\hat{a} = \operatorname{moda}(a^{(1)},a^{(2)},\ldots,a^{(M)})

Símbolo	Significado	Ejemplo
$x$	Problema de entrada.	«¿A qué hora debo salir?»
$r^{(m)}$	Ruta de solución número $m$ .	Un intento de resolver paso a paso.
$M$	Número de rutas generadas.	$M=5$ .
$a^{(m)}$	Respuesta extraída de la ruta $m$ .	«14:30».
$\hat{a}$	Respuesta final por consistencia.	La que más se repite o mejor verifica.

Ejemplo:

Ruta	Respuesta
1	14:30
2	14:30
3	14:00
4	14:30
5	14:45

La moda es 14:30. No garantiza verdad absoluta, pero reduce la dependencia de una sola muestra. En tareas profesionales, lo fuerte no es pedir «razona más» sin más. Lo fuerte es combinar pasos, herramientas, verificaciones y criterios de aceptación.

Un ejemplo entendible: planificar una salida

Supongamos:

La reunión empieza a las 16:00. Tardo 25 minutos en taxi. Quiero llegar 10 minutos antes. Necesito 15 minutos para preparar la mochila. ¿A qué hora empiezo a prepararme?

Un modelo que responde rápido podría saltar a una respuesta plausible. Un proceso más cuidadoso separa restricciones:

Paso	Cálculo	Resultado
Llegar 10 minutos antes	16:00 - 10 min	15:50
Restar taxi	15:50 - 25 min	15:25
Restar preparación	15:25 - 15 min	15:10

La respuesta es: empezar a prepararse a las 15:10.

La lección no es que el modelo tenga una calculadora perfecta dentro. La lección es que algunas tareas mejoran cuando obligamos al sistema a separar pasos, comprobar restricciones y, si hace falta, usar una herramienta externa. Esto conecta directamente con facsímil 5, donde hablaremos de agentes y herramientas, y con facsímil 7, donde hablaremos de evaluación.

Multimodalidad: convertir otros mundos en tokens útiles

Un modelo de lenguaje trabaja con tokens. Para trabajar con imágenes, audio, vídeo o acciones, necesita convertir esas señales en representaciones que puedan relacionarse con el lenguaje.

Hay varias familias de aproximaciones:

Familia	Idea	Ejemplo
Alineación contrastiva	Aprender que una imagen y su texto cercano deben quedar cerca en un espacio común.	CLIP.
Conectores visuales	Usar un codificador de imagen y proyectar sus salidas al LLM.	LLaVA.
Cross-attention	Dejar que el modelo de lenguaje atienda a representaciones visuales.	Flamingo.
Modelos incorporados en entornos	Combinar lenguaje, visión y señales de acción u observación.	PaLM-E.

CLIP entrenó un codificador de imagen y otro de texto para acercar pares imagen-texto correctos y separar pares incorrectos.²⁰ Una similitud típica es el coseno:

\operatorname{sim}(v,t)=\frac{v \cdot t}{\|v\|\|t\|}

Símbolo	Significado	Ejemplo
$v$	Vector de imagen.	Representación de una foto de un perro.
$t$	Vector de texto.	Representación de «foto de un perro».
$v \cdot t$	Producto punto.	Mide alineación entre vectores.
$\\|v\\|$ , $\\|t\\|$	Normas de los vectores.	Sirven para normalizar magnitudes.
$\operatorname{sim}(v,t)$	Similitud coseno.	Cerca de 1 si encajan mucho.

Ejemplo:

Texto candidato	Similitud con la imagen
«auriculares rotos»	0,82
«caja de zapatos»	0,31
«perro en un parque»	0,08

El sistema no «ve» como una persona; compara representaciones. Esa comparación puede ser muy útil para buscar, clasificar o describir, pero hay que evaluarla en el dominio real.

Modelos posteriores conectaron visión y lenguaje de formas más generativas. Flamingo combinó modelos visuales y de lenguaje para manejar secuencias intercaladas de imágenes, vídeo y texto.²¹ LLaVA conectó un codificador visual con un LLM y usó ajuste con instrucciones visuales para diálogo imagen-texto.²² PaLM-E exploró modelos que integran lenguaje, visión y señales de entornos físicos.²³

El patrón común: adaptar representaciones

Aunque las arquitecturas cambien, hay una receta recurrente:

entrada no textual -> codificador -> vectores -> conector -> modelo de lenguaje -> salida

Para una imagen:

u = f_{\text{vision}}(I)

\tilde{u} = P(u)

y \sim p(y \mid \tilde{u}, x_{\text{text}})

Símbolo	Significado	Ejemplo
$I$	Imagen de entrada.	Foto del producto dañado.
$f_{\text{vision}}$	Codificador visual.	Convierte píxeles en vectores.
$u$	Tokens o vectores visuales.	Representaciones de regiones o parches.
$P$	Proyector o conector.	Adapta dimensión y formato al LLM.
$\tilde{u}$	Representación visual ya conectada.	Lo que el LLM puede consumir.
$x_{\text{text}}$	Texto del usuario.	«¿Me lo cambian?»
$y$	Respuesta generada.	Explicación o siguiente acción.

El punto importante: multimodalidad no es solo añadir una imagen al prompt. Hay que decidir cómo se codifica, cómo se alinea, en qué capas se integra, qué datos se usaron para entrenar y cómo se evalúa el resultado.

El mapa operativo del capítulo

Este mapa no intenta vender una arquitectura ganadora. Ordena tres formas de aumentar utilidad: más capacidad interna, más proceso durante inferencia y más tipos de entrada. Cada una trae un coste distinto.

flowchart TD
    C04["Cap. 04<br/>MLP, logits y sampling"]
    MODERN["Este capítulo<br/>arquitecturas modernas"]
    MOE["MoE<br/>más capacidad activa parcial"]
    ROUTER["Router<br/>elige expertos"]
    REASON["Razonamiento<br/>más proceso de inferencia"]
    VERIFY["Verificación<br/>tests, herramientas, consistencia"]
    MULTI["Multimodalidad<br/>más tipos de entrada"]
    ALIGN["Alineación<br/>vectores compatibles"]
    C06["Cap. 06<br/>transfer y modelos abiertos"]
    C07["Cap. 07<br/>inferencia y hardware"]
    F04["Fasc. 04<br/>herramientas y RAG"]
    F05["Fasc. 05<br/>agentes"]
    F07["Fasc. 07<br/>evaluación"]

    C04 -->|"prepara"| MODERN
    MODERN -->|"aumenta capacidad con"| MOE
    MOE -->|"usa"| ROUTER
    MODERN -->|"aumenta deliberación con"| REASON
    REASON -->|"necesita"| VERIFY
    MODERN -->|"amplía entrada con"| MULTI
    MULTI -->|"requiere"| ALIGN
    ROUTER -->|"impacta en"| C07
    MOE -->|"se publica y adapta en"| C06
    REASON -->|"se orquesta en"| F05
    MULTI -->|"se integra con"| F04
    VERIFY -->|"se mide en"| F07

    style MODERN fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MOE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style ROUTER fill:#F5F5F5,stroke:#000000,stroke-width:2
    style REASON fill:#F5F5F5,stroke:#000000,stroke-width:2
    style VERIFY fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MULTI fill:#F5F5F5,stroke:#000000,stroke-width:2
    style ALIGN fill:#F5F5F5,stroke:#000000,stroke-width:2
    style C04 stroke-dasharray: 5 5
    style C06 stroke-dasharray: 5 5
    style C07 stroke-dasharray: 5 5
    style F04 stroke-dasharray: 5 5
    style F05 stroke-dasharray: 5 5
    style F07 stroke-dasharray: 5 5

En el día a día

Elegir un modelo para soporte. Si atiendes miles de tickets diarios, un MoE puede parecer atractivo por capacidad y coste activo. Pero tienes que medir latencia real, disponibilidad, memoria, precio por token y calidad en tus casos. No basta con leer «8x7B» o «experts» en una ficha.

Diseñar un flujo con razonamiento. Para una tarea legal, médica, financiera o de ingeniería, no deberías conformarte con una respuesta directa si hay pasos verificables. Puedes pedir estructura, usar herramientas, ejecutar comprobaciones y registrar evidencias. El razonamiento útil se diseña como proceso, no como decoración textual.

Añadir imágenes a un producto. Si un usuario sube una foto de un daño, una factura o una pizarra, el sistema debe saber qué espera extraer. No es lo mismo describir la imagen que localizar un número de serie, leer una tabla o decidir si falta información.

Evaluar de verdad. Cada palanca trae fallos distintos. MoE puede fallar por routing o servicio. Razonamiento puede fallar por pasos plausibles pero incorrectos. Multimodalidad puede fallar por lectura visual, alineación o detalle espacial. La evaluación debe cubrir esos modos, no solo una puntuación global.

Por qué debería importarte

Porque aquí empiezas a leer fichas técnicas con criterio. Cuando alguien dice «modelo MoE», ya no preguntas solo cuántos parámetros tiene: preguntas cuántos expertos se activan, cómo se sirve y qué latencia tiene. Cuando alguien dice «modelo de razonamiento», preguntas si mejora en tus tareas, cuánto tarda y cómo se verifica. Cuando alguien dice «multimodal», preguntas qué modalidades entran, cómo se alinean y qué errores has medido.

También importa por coste. Una arquitectura moderna no es una pegatina comercial; cambia memoria, inferencia, datos, evaluación y producto. Elegir mal puede darte un sistema caro, lento o difícil de depurar. Elegir bien puede convertir una tarea imposible en una herramienta útil.

Dónde volverá a aparecer

Concepto de este capítulo	Dónde vuelve en el libro	Por qué se conecta
MoE y routing	Facsímil 3, capítulo 07; facsímil 6.	Servir expertos afecta memoria, paralelismo y latencia.
Razonamiento como proceso	Facsímil 5; facsímil 7.	Agentes y evaluación necesitan pasos, herramientas y verificación.
Multimodalidad	Facsímil 4; facsímil 8.	RAG, documentos, datos e imágenes exigen tratar entradas no textuales.
Alineación imagen-texto	Facsímil 7; facsímil 11.	UX y evaluación deben comprobar si la interpretación visual sostiene la respuesta.
Familias de arquitectura	Facsímil 3, capítulo 06; facsímil 8.	Transfer, destilación, datos y ciencia aplicada dependen de saber qué familia estás usando.
Arquitecturas de sistema	Facsímil 4; facsímil 5.	RAG, herramientas y agentes combinan modelos con recuperación, permisos y validación.
Compromisos de arquitectura	Facsímil 6.	Operar IA es elegir entre calidad, coste, velocidad y mantenibilidad.

Dónde solía tropezar yo

Error	Por qué es un error	Antídoto
Pensar que los expertos tienen profesiones humanas	Un experto MoE es una subred aprendida, no un departamento etiquetado.	Habla de routing y activación, no de «el experto de derecho» sin evidencia.
Comparar parámetros totales sin mirar parámetros activos	En MoE, no todos los parámetros se usan en cada token.	Pregunta cuántos expertos se activan y cuál es el coste por token.
Creer que razonar es escribir más texto	Un texto largo puede sonar convincente y estar mal.	Diseña verificación: cálculo, tests, fuentes o consistencia.
Tratar multimodalidad como OCR con esteroides	Una imagen no siempre se reduce a leer texto. Puede implicar objetos, posición, contexto y ambigüedad.	Define qué tarea visual necesitas y evalúala con ejemplos reales.
Meter una arquitectura moderna sin cambiar evaluación	Cada arquitectura trae fallos propios.	Añade pruebas específicas para routing, latencia, pasos y entrada visual.

Manos a la obra

La práctica real está en kit descargable. El kit simula tres piezas del capítulo con datos pequeños: routing MoE, self-consistency y alineación imagen-texto mediante similitud coseno.

Archivo	Qué contiene
`data/modern_architecture_case.json`	Scores de expertos, respuestas y vectores multimodales.
`contracts/modern_architecture_policy.json`	Top-k, umbrales y experto esperado.
`ops/probe_modern_architectures.py`	Routing, self-consistency y similitud coseno.
`output/modern_architecture_report.json`	Resultados estructurados.
`output/modern_architecture_decision.md`	Informe legible.

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/probe_modern_architectures.py --write
cat output/modern_architecture_decision.md

Como gate:

python3 ops/probe_modern_architectures.py --write --fail-on-invalid

Qué entregaría un alumno. El Markdown generado, un ticket nuevo con routing distinto y una decisión sobre qué señal usaría para activar revisión humana.

Cómo encaja todo

Este mapa relaciona las familias modernas con lo aprendido antes y con lo que vendrá después. MoE hereda el MLP y cambia coste activo; razonamiento hereda sampling y añade proceso; multimodalidad hereda embeddings y exige alineación.

La decisión de ingeniería no es “usar lo más moderno”, sino saber qué compromiso estás moviendo: memoria, latencia, datos, evaluación, herramientas o UX.

graph TD
    F3C01["Facsímil 3, capítulo 1<br/>LLM, escala y sistema"]
    F3C04["Facsímil 3, capítulo 4<br/>MLP, logits y sampling"]
    C5["Este capítulo<br/>MoE, razonamiento y multimodalidad"]
    MOE["MoE<br/>capacidad dispersa"]
    ROUTER["Router<br/>selección por token"]
    REASON["Razonamiento<br/>más pasos o más muestras"]
    CONSISTENCY["Self-consistency<br/>agregar respuestas"]
    MULTI["Multimodalidad<br/>texto + imagen + otras señales"]
    CLIP["Alineación contrastiva<br/>imagen-texto"]
    F3C06["Facsímil 3, capítulo 6<br/>transfer, destilación, modelos abiertos"]
    F3C07["Facsímil 3, capítulo 7<br/>inferencia, edge y hardware"]
    F04["Facsímil 4<br/>herramientas, RAG y documentos"]
    F05["Facsímil 5<br/>agentes y orquestación"]
    F07["Facsímil 7<br/>evaluación"]

    F3C01 -->|"plantea escala"| C5
    F3C04 -->|"aporta MLP y sampling"| C5
    C5 -->|"usa"| MOE
    MOE -->|"depende de"| ROUTER
    C5 -->|"usa"| REASON
    REASON -->|"puede agregar con"| CONSISTENCY
    C5 -->|"usa"| MULTI
    MULTI -->|"necesita"| CLIP
    MOE -->|"se adapta y publica como"| F3C06
    ROUTER -->|"condiciona"| F3C07
    MULTI -->|"entra en"| F04
    REASON -->|"se organiza con"| F05
    CONSISTENCY -->|"se mide en"| F07
    CLIP -->|"se evalúa en"| F07

    style C5 fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MOE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style ROUTER fill:#F5F5F5,stroke:#000000,stroke-width:2
    style REASON fill:#F5F5F5,stroke:#000000,stroke-width:2
    style CONSISTENCY fill:#F5F5F5,stroke:#000000,stroke-width:2
    style MULTI fill:#F5F5F5,stroke:#000000,stroke-width:2
    style CLIP fill:#F5F5F5,stroke:#000000,stroke-width:2
    style F3C01 stroke-dasharray: 5 5
    style F3C04 stroke-dasharray: 5 5
    style F3C06 stroke-dasharray: 5 5
    style F3C07 stroke-dasharray: 5 5
    style F04 stroke-dasharray: 5 5
    style F05 stroke-dasharray: 5 5
    style F07 stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición
Mixture of Experts	Arquitectura con varios expertos donde solo algunos se activan por token o ejemplo.
Router	Módulo que asigna tokens a expertos mediante puntuaciones aprendidas.
Cómputo disperso	Uso de una parte del modelo en cada paso, no de todo el modelo.
Parámetros activos	Parámetros que participan realmente en una pasada concreta.
Encoder-only	Transformer orientado a comprender una entrada completa y producir representaciones.
Decoder-only	Transformer causal orientado a generar el siguiente token.
Encoder-decoder	Arquitectura que lee una entrada con encoder y genera salida con decoder.
State Space Model	Modelo de secuencia que mantiene un estado interno y puede escalar bien en secuencias largas.
Diffusion model	Modelo generativo que aprende a quitar ruido progresivamente.
Graph Neural Network	Red que opera sobre nodos y aristas de un grafo.
Arquitectura de sistema	Diseño que combina modelos, datos, herramientas, memoria, recuperación y validadores.
Chain-of-thought	Técnica que usa pasos intermedios para resolver tareas de varios pasos.
Self-consistency	Generar varias soluciones y escoger la respuesta más consistente.
Multimodalidad	Integración de texto, imagen, audio, vídeo u otras señales.
Alineación contrastiva	Entrenar representaciones para acercar pares relacionados y separar pares no relacionados.
Conector multimodal	Proyección que traduce representaciones visuales u otras señales al espacio que usa el LLM.

Antes de pasar página

En resumen

Idea fuerza	Detalle
No hay una sola familia de arquitectura.	MLP, CNN, RNN, Transformer, GNN, difusión, SSM y sistemas RAG resuelven problemas distintos.
Hay que separar arquitectura neuronal, modelo y sistema.	BERT, GPT, T5 o RAG no son el mismo tipo de cosa aunque aparezcan juntos en conversaciones de producto.
MoE aumenta capacidad activando solo parte del modelo.	El router decide qué expertos procesan cada token, pero eso añade retos de balanceo y servicio.
Razonamiento es proceso, no eslogan.	Más pasos, varias muestras y verificación pueden mejorar tareas complejas si se evalúan bien.
Multimodalidad convierte señales distintas en representaciones compatibles.	Imagen y texto deben alinearse antes de que el LLM pueda usarlos de forma útil.
Las arquitecturas modernas cambian compromisos.	Calidad, coste, latencia, memoria y evaluación se mueven a la vez.

Para saber más

Alayrac, J.-B. et al. (2022). Flamingo: a visual language model for few-shot learning. Advances in Neural Information Processing Systems 35, 23716-23736. https://arxiv.org/abs/2204.14198

Devlin, J., Chang, M.-W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. Proceedings of NAACL-HLT, 4171-4186. https://doi.org/10.18653/v1/N19-1423

Dosovitskiy, A. et al. (2021). An image is worth 16x16 words: Transformers for image recognition at scale. International Conference on Learning Representations. https://arxiv.org/abs/2010.11929

Driess, D. et al. (2023). PaLM-E: An embodied multimodal language model. https://arxiv.org/abs/2303.03378

Fedus, W., Zoph, B. y Shazeer, N. (2022). Switch Transformers: Scaling to trillion parameter models with simple and efficient sparsity. Journal of Machine Learning Research, 23(120), 1-39. https://jmlr.org/papers/v23/21-0998.html

Gu, A. y Dao, T. (2023). Mamba: Linear-time sequence modeling with selective state spaces. https://arxiv.org/abs/2312.00752

Ho, J., Jain, A. y Abbeel, P. (2020). Denoising diffusion probabilistic models. Advances in Neural Information Processing Systems 33, 6840-6851. https://papers.nips.cc/paper/2020/file/4c5bcfec8584af0d967f1ab10179ca4b-Abstract.html

Jiang, A. Q. et al. (2024). Mixtral of experts. https://arxiv.org/abs/2401.04088

Kingma, D. P. y Welling, M. (2014). Auto-encoding variational Bayes. International Conference on Learning Representations. https://arxiv.org/abs/1312.6114

Kipf, T. N. y Welling, M. (2017). Semi-supervised classification with graph convolutional networks. International Conference on Learning Representations. https://arxiv.org/abs/1609.02907

Lepikhin, D. et al. (2021). GShard: Scaling giant models with conditional computation and automatic sharding. International Conference on Learning Representations. https://arxiv.org/abs/2006.16668

Lewis, M. et al. (2020). BART: Denoising sequence-to-sequence pre-training for natural language generation, translation, and comprehension. Proceedings of ACL, 7871-7880. https://doi.org/10.18653/v1/2020.acl-main.703

Lewis, P. et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems 33, 9459-9474. https://papers.nips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html

Liu, H., Li, C., Wu, Q. y Lee, Y. J. (2023). Visual instruction tuning. Advances in Neural Information Processing Systems 36. https://arxiv.org/abs/2304.08485

Radford, A. et al. (2021). Learning transferable visual models from natural language supervision. Proceedings of the 38th International Conference on Machine Learning, 8748-8763. https://arxiv.org/abs/2103.00020

Radford, A., Wu, J., Child, R., Luan, D., Amodei, D. y Sutskever, I. (2019). Language models are unsupervised multitask learners. https://cdn.openai.com/better-language-models/language_models_are_unsupervised_multitask_learners.pdf

Raffel, C. et al. (2020). Exploring the limits of transfer learning with a unified text-to-text Transformer. Journal of Machine Learning Research, 21(140), 1-67. https://www.jmlr.org/papers/v21/20-074.html

Shazeer, N. et al. (2017). Outrageously large neural networks: The sparsely-gated mixture-of-experts layer. International Conference on Learning Representations. https://arxiv.org/abs/1701.06538

Sutskever, I., Vinyals, O. y Le, Q. V. (2014). Sequence to sequence learning with neural networks. Advances in Neural Information Processing Systems 27, 3104-3112. https://papers.nips.cc/paper/5346-sequence-to-sequence-learning-with-neural-networks

Wang, X. et al. (2023). Self-consistency improves chain of thought reasoning in language models. International Conference on Learning Representations. https://arxiv.org/abs/2203.11171

Wei, J. et al. (2022). Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems 35, 24824-24837. https://arxiv.org/abs/2201.11903

Yao, S. et al. (2023). Tree of thoughts: Deliberate problem solving with large language models. https://arxiv.org/abs/2305.10601

Notas

Lewis, P. et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems 33, 9459-9474. https://papers.nips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html. RAG combina memoria paramétrica del modelo con recuperación externa de documentos. ↩
LeCun, Y., Bengio, Y. y Hinton, G. (2015). Deep learning. Nature, 521(7553), 436-444. https://doi.org/10.1038/nature14539. El artículo revisa CNNs, redes recurrentes y aprendizaje profundo moderno. ↩
Sutskever, I., Vinyals, O. y Le, Q. V. (2014). Sequence to sequence learning with neural networks. Advances in Neural Information Processing Systems 27, 3104-3112. https://papers.nips.cc/paper/5346-sequence-to-sequence-learning-with-neural-networks. El trabajo mostró modelos secuencia-a-secuencia basados en redes recurrentes para traducción. ↩
Kipf, T. N. y Welling, M. (2017). Semi-supervised classification with graph convolutional networks. International Conference on Learning Representations. https://arxiv.org/abs/1609.02907. El trabajo presenta una forma eficiente de aplicar redes convolucionales a datos con estructura de grafo. ↩
Kingma, D. P. y Welling, M. (2014). Auto-encoding variational Bayes. International Conference on Learning Representations. https://arxiv.org/abs/1312.6114. El VAE aprende una representación latente probabilística que permite generación y reconstrucción. ↩
Ho, J., Jain, A. y Abbeel, P. (2020). Denoising diffusion probabilistic models. Advances in Neural Information Processing Systems 33, 6840-6851. https://papers.nips.cc/paper/2020/file/4c5bcfec8584af0d967f1ab10179ca4b-Abstract.html. DDPM formaliza generación como un proceso de denoising iterativo. ↩
Gu, A. y Dao, T. (2023). Mamba: Linear-time sequence modeling with selective state spaces. https://arxiv.org/abs/2312.00752. Mamba propone modelos de espacio de estados selectivos para modelar secuencias en tiempo lineal. ↩
Devlin, J., Chang, M.-W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. Proceedings of NAACL-HLT, 4171-4186. https://doi.org/10.18653/v1/N19-1423. BERT usa una arquitectura encoder bidireccional orientada a comprensión. ↩
Radford, A., Wu, J., Child, R., Luan, D., Amodei, D. y Sutskever, I. (2019). Language models are unsupervised multitask learners. https://cdn.openai.com/better-language-models/language_models_are_unsupervised_multitask_learners.pdf. GPT-2 popularizó el Transformer decoder autoregresivo a escala. ↩
Raffel, C. et al. (2020). Exploring the limits of transfer learning with a unified text-to-text Transformer. Journal of Machine Learning Research, 21(140), 1-67. https://www.jmlr.org/papers/v21/20-074.html. T5 convierte tareas de NLP a un formato texto-a-texto con arquitectura encoder-decoder. ↩
Lewis, M. et al. (2020). BART: Denoising sequence-to-sequence pre-training for natural language generation, translation, and comprehension. Proceedings of ACL, 7871-7880. https://doi.org/10.18653/v1/2020.acl-main.703. ↩
Dosovitskiy, A. et al. (2021). An image is worth 16x16 words: Transformers for image recognition at scale. International Conference on Learning Representations. https://arxiv.org/abs/2010.11929. ViT aplica Transformers a imágenes dividiéndolas en parches. ↩
Shazeer, N., Mirhoseini, A., Maziarz, K., Davis, A., Le, Q., Hinton, G. y Dean, J. (2017). Outrageously large neural networks: The sparsely-gated mixture-of-experts layer. International Conference on Learning Representations. https://arxiv.org/abs/1701.06538. El trabajo introduce una capa MoE con una red de gating que selecciona una combinación escasa de expertos por ejemplo. ↩
Lepikhin, D. et al. (2021). GShard: Scaling giant models with conditional computation and automatic sharding. International Conference on Learning Representations. https://arxiv.org/abs/2006.16668. ↩
Fedus, W., Zoph, B. y Shazeer, N. (2022). Switch Transformers: Scaling to trillion parameter models with simple and efficient sparsity. Journal of Machine Learning Research, 23(120), 1-39. https://jmlr.org/papers/v23/21-0998.html. ↩
Jiang, A. Q. et al. (2024). Mixtral of experts. https://arxiv.org/abs/2401.04088. El artículo presenta Mixtral 8x7B como un modelo sparse MoE donde cada capa usa varios expertos feed-forward y selecciona algunos por token. ↩
Wei, J. et al. (2022). Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems 35, 24824-24837. https://arxiv.org/abs/2201.11903. El trabajo estudia cómo ejemplos con razonamiento paso a paso mejoran el rendimiento en tareas que requieren varios pasos. ↩
Wang, X. et al. (2023). Self-consistency improves chain of thought reasoning in language models. International Conference on Learning Representations. https://arxiv.org/abs/2203.11171. El método muestrea múltiples cadenas de solución y agrega respuestas para mejorar robustez. ↩
Yao, S. et al. (2023). Tree of thoughts: Deliberate problem solving with large language models. https://arxiv.org/abs/2305.10601. El marco explora unidades de pensamiento como nodos de búsqueda y permite evaluar caminos parciales. ↩
Radford, A. et al. (2021). Learning transferable visual models from natural language supervision. Proceedings of the 38th International Conference on Machine Learning, 8748-8763. https://arxiv.org/abs/2103.00020. CLIP aprende representaciones visuales usando supervisión en lenguaje natural y permite transferencia zero-shot. ↩
Alayrac, J.-B. et al. (2022). Flamingo: a visual language model for few-shot learning. Advances in Neural Information Processing Systems 35, 23716-23736. https://arxiv.org/abs/2204.14198. Flamingo integra información visual y textual con mecanismos que permiten few-shot learning multimodal. ↩
Liu, H., Li, C., Wu, Q. y Lee, Y. J. (2023). Visual instruction tuning. Advances in Neural Information Processing Systems 36. https://arxiv.org/abs/2304.08485. LLaVA conecta un encoder visual y un LLM, y ajusta el sistema con datos de instrucciones multimodales. ↩
Driess, D. et al. (2023). PaLM-E: An embodied multimodal language model. https://arxiv.org/abs/2303.03378. PaLM-E integra observaciones multimodales en un modelo de lenguaje para tareas encarnadas. ↩

Capítulo 06

Facsímil 3 · Arquitecturas y modelos

Capítulo 06: Transfer learning, destilación y modelos abiertos

Casi nadie empieza desde cero

Entrenar un modelo grande desde cero es caro, lento y exige datos, infraestructura, evaluación y experiencia. La mayoría de equipos no empieza ahí. Empieza con un modelo que ya sabe mucho y lo adapta a una tarea concreta.

Ese cambio de mentalidad es enorme. En vez de preguntar «¿cómo entreno mi propio LLM desde cero?», preguntamos:

Pregunta práctica	Técnica que suele aparecer
¿Puedo reutilizar un modelo ya entrenado?	Transfer learning.
¿Puedo ajustarlo a mi dominio?	Fine-tuning o instruction tuning.
¿Puedo entrenar pocos parámetros?	LoRA, adapters, QLoRA.
¿Puedo hacerlo más pequeño?	Destilación y cuantización.
¿Puedo ejecutarlo y modificarlo legalmente?	Modelos abiertos, licencias y documentación.

Este capítulo une esas piezas. Es menos espectacular que hablar de billones de parámetros, pero mucho más cercano a la realidad profesional: elegir una base, adaptarla, medirla, comprimirla si hace falta y entender qué te permite su licencia.

Cuando aparezcan herramientas, catálogos, modelos abiertos o librerías de evaluación, toma la sección como estado observado a 10 de junio de 2026. Las ideas estables son el mecanismo y el criterio de decisión; los nombres, versiones, licencias y capacidades concretas deben revisarse antes de usarlos en un proyecto real.

Qué no es adaptar un modelo

Adaptar un modelo no es «meterle documentos» como quien mete libros en una estantería. Si haces fine-tuning, cambias pesos. Si haces RAG, conectas recuperación externa. Si haces prompt engineering, cambias el contexto. Son mecanismos distintos.

Tampoco conviene pensar que fine-tuning arregla cualquier problema. Si el modelo falla porque no tiene el dato actualizado, puede que necesites recuperación. Si falla porque no sigue un formato, quizá necesitas mejores ejemplos, validación o una interfaz más estricta. Si falla porque la tarea requiere cálculo exacto, puede que necesites una herramienta.

Y un modelo abierto no siempre significa lo mismo. A veces puedes descargar pesos, pero no tienes datos de entrenamiento. A veces la licencia permite investigación pero limita uso comercial. A veces hay código, tokenizer y evaluación; otras veces solo un checkpoint. La palabra «abierto» exige mirar detalles.

Transfer learning: reutilizar una base

Transfer learning significa usar conocimiento aprendido en un contexto para mejorar otro. En NLP moderno, el patrón se volvió muy claro con modelos preentrenados: primero se entrena una base con grandes cantidades de texto; después se adapta a tareas concretas.¹ T5 lo llevó a una formulación texto-a-texto muy amplia.²

Una forma simple de verlo:

modelo base -> adaptación -> modelo útil para una tarea concreta

Fase	Qué aprende	Ejemplo
Preentrenamiento	Patrones generales del lenguaje y del mundo textual.	Continuar texto, relacionar conceptos, estilo, idiomas.
Instruction tuning	Seguir instrucciones humanas en formato pregunta/respuesta.	«Resume esto», «extrae estos campos», «clasifica».
Fine-tuning de dominio	Patrones de un sector o tarea concreta.	Soporte técnico, documentos jurídicos, código interno.
Evaluación	Si la adaptación ayuda o daña.	Tests propios, casos reales, comparación contra base.

Instruction tuning se volvió central para convertir modelos base en asistentes útiles.³ Pero no hay que confundirlo con una capacidad espontánea: es entrenamiento sobre ejemplos de comportamiento deseado.

Datasets: qué se entrena realmente

Cuando hablamos de entrenamiento, la palabra “datos” se queda corta. Un LLM no se entrena con “internet” como una masa uniforme. Se entrena con mezclas de documentos, código, conversaciones, instrucciones, comparaciones, problemas, imágenes, etiquetas, filtros y evaluaciones. Cada familia de datos empuja una capacidad distinta.

Un dataset no es solo una carpeta con archivos. Es una decisión de producto y de ingeniería:

Pregunta	Por qué importa
¿De dónde sale?	Derechos, licencia, idioma, sesgo de dominio y calidad.
¿Qué formato tiene?	Texto libre, pares pregunta-respuesta, preferencias, imagen-texto, código, tablas.
¿Qué enseña?	Continuar texto, seguir instrucciones, razonar, preferir una respuesta, ver imágenes.
¿Qué no enseña?	Ningún dataset cubre todo; cada mezcla tiene huecos.
¿Cómo se filtra?	Duplicados, baja calidad, datos sensibles, idioma, toxicidad, contenido roto.
¿Cómo se mezcla?	La proporción entre web, código, matemáticas o diálogo cambia el modelo.
¿Cómo se evalúa?	Sin conjunto de evaluación separado, puedes entrenar para memorizar tus pruebas.

La arquitectura de entrenamiento cambia según el tipo de dataset.

Tipo de dataset	Forma típica	Qué entrena	Ejemplos conocidos
Preentrenamiento textual	Texto largo no etiquetado.	Predicción del siguiente token o reconstrucción.	C4/T5, The Pile.⁴
Código	Repositorios, archivos, funciones, comentarios.	Sintaxis, APIs, patrones de programación.	The Stack.⁵
SFT / instrucciones	`instrucción -> respuesta esperada`.	Seguir tareas, formato, tono, extracción, resumen.	FLAN, Dolly-15K.⁶
Preferencias	`prompt, respuesta A, respuesta B, preferida`.	Elegir entre salidas plausibles.	HH-RLHF, UltraFeedback.⁷
Razonamiento	Problema, solución, pasos o verificador.	Matemáticas, cadenas de inferencia, comprobación.	GSM8K.⁸
Multimodal	Imagen-texto, imagen-instrucción-respuesta, vídeo-texto.	Alinear señales visuales y lenguaje.	LAION-5B, LLaVA.⁹
Evaluación	Preguntas con respuesta esperada o rúbrica.	No entrena; mide.	MMLU, BEIR, MTEB.¹⁰

No confundas dataset de entrenamiento con dataset de evaluación. El primero mueve el modelo. El segundo mide si el modelo se comporta mejor. Si una pregunta de evaluación se cuela en entrenamiento, la nota puede subir sin que el modelo haya aprendido a generalizar. A eso se le suele llamar contaminación de datos.

Arquitecturas de datos para entrenar y adaptar

La palabra arquitectura no solo habla de capas del Transformer. También habla de cómo conectas datos, filtros, pérdidas, modelo base, evaluadores y artefactos finales. Aquí tienes el mapa de las arquitecturas de entrenamiento más comunes.

El SVG muestra seis arquitecturas porque no todas optimizan lo mismo. Preentrenar busca capacidad general. SFT enseña formato y seguimiento de instrucciones. Preferencias enseñan criterios comparativos. Razonamiento necesita problemas verificables. Destilación pasa señales de un profesor a un estudiante. Multimodalidad alinea señales no textuales con lenguaje.

Qué optimiza cada arquitectura

Para leer bien un dataset hay que mirar tres cosas a la vez: entrada, pérdida y artefacto final. Dos datasets pueden tener el mismo tamaño y servir para cosas muy distintas.

Arquitectura	Entrada real	Objetivo matemático	Artefacto que produce	Qué debes comprobar
Preentrenamiento causal	Texto tokenizado $x_1, x_2, \dots, x_T$ .	Predecir el siguiente token: $\mathcal{L}=-\sum_t \log p(x_t \mid x_{<t})$ .	Modelo base.	Mezcla, deduplicación, idiomas, licencias y benchmarks filtrados.
Preentrenamiento texto-a-texto / denoising	Texto con huecos o transformación entrada-salida.	Reconstruir partes ocultas o salida esperada.	Modelo base transferible.	Cómo se generan corrupciones, tareas y plantillas.
SFT / instruction tuning	Instrucción, contexto opcional y respuesta ideal.	Entropía cruzada sobre los tokens de respuesta.	Modelo que sigue formato y tarea.	Calidad de respuestas, diversidad de instrucciones y ejemplos contradictorios.
Preferencias	Prompt, respuesta elegida y respuesta descartada.	Aumentar la probabilidad relativa de la elegida; en DPO aparece una pérdida logística sobre diferencias de log-probabilidad.	Modelo o adaptador alineado con una rúbrica.	Quién decide la preferencia, con qué criterio y si hay sesgo de longitud o estilo.
Razonamiento verificable	Problema, solución, pasos y a veces verificador.	Premiar soluciones que llegan a una respuesta comprobable.	Modelo mejor en problemas estructurados.	Separar entrenamiento y test; comprobar que no aprende plantillas memorizadas.
Destilación	Entradas y salidas del profesor: logits, respuestas o trazas.	Acercar distribución del estudiante a la del profesor, por ejemplo con KL.	Modelo estudiante más barato.	Qué capacidades pierde el estudiante fuera de la tarea.
Multimodal	Pares imagen-texto, imagen-instrucción-respuesta, audio-texto o vídeo-texto.	Alinear representaciones y generar texto condicionado por otra señal.	Modelo capaz de razonar sobre varias modalidades.	Calidad de pares, resolución, licencias y si la descripción textual corresponde a la señal.
Evaluación	Preguntas, respuestas esperadas, qrels, rúbricas o casos no respondibles.	No debería optimizar el modelo; mide una versión.	Métrica, traza y decisión de publicación.	Que no se mezcle con entrenamiento y que represente uso real.

La mezcla de datos también es una arquitectura. Si tienes familias $D_1, D_2, \dots, D_n$ , no basta con juntarlas.

Ejemplo de fórmula. Para razonar de forma pedagógica sobre una mezcla, podemos escribir un conjunto de entrenamiento como suma ponderada de familias:

D_{\text{train}} = \lambda_1 D_1 + \lambda_2 D_2 + \dots + \lambda_n D_n

Aquí $D_i$ representa una familia de datos —web filtrada, código, instrucciones, preferencias, razonamiento, imagen-texto— y $\lambda_i$ representa su peso relativo en la mezcla. Esta fórmula no describe por sí sola cómo se implementa un data loader de entrenamiento real: sirve para recordar que cambiar proporciones cambia capacidades, sesgos, coste y contaminación posible. En un sistema real habría que documentar muestreo, filtros, deduplicación, licencias, idioma, fechas, splits y evaluación.

Símbolo	Significado
$D_i$	Familia de datos: web, código, matemáticas, conversación, imagen-texto...
$\lambda_i$	Peso o proporción de esa familia en la mezcla.
$D_{\text{train}}$	Conjunto efectivo que verá el entrenamiento.

Subir $\lambda_{\text{código}}$ puede mejorar programación y cambiar estilo de respuesta. Subir $\lambda_{\text{math}}$ puede ayudar en problemas formales y no mover demasiado tareas conversacionales. Por eso los informes técnicos serios hablan de mezcla, filtros y etapas; no solo de “tamaño del dataset”.

Tipos de dataset con ejemplos

1. Preentrenamiento textual. Aquí el modelo aprende a predecir texto. No recibe una tarea humana explícita; recibe secuencias y aprende regularidades. C4 y The Pile son ejemplos conocidos de corpora grandes. Lo importante no es solo el tamaño: importan filtros, deduplicación, idiomas, licencias, dominios y contaminación de evaluación.

2. Código. Entrenar con código no es igual que entrenar con prosa. Un dataset como The Stack contiene repositorios y lenguajes de programación. Eso ayuda a aprender sintaxis, patrones de APIs, comentarios, tests y estructura de proyectos. También obliga a mirar licencias y duplicados con mucho cuidado.

3. SFT o instruction tuning. Aquí cada ejemplo suele tener una instrucción y una respuesta deseada. FLAN mezcla tareas y plantillas para enseñar a seguir instrucciones. Dolly-15K ilustra un dataset más pequeño y humano de instrucciones/respuestas. Esta familia enseña comportamiento, no conocimiento vivo.

4. Preferencias. En DPO/RLHF no basta con una respuesta correcta. El dataset dice cuál de dos respuestas se prefiere. HH-RLHF y UltraFeedback ilustran esta familia. La arquitectura cambia: el modelo aprende de comparaciones, no solo de una salida ideal.

5. Razonamiento y verificación. GSM8K contiene problemas matemáticos con soluciones. Sirve para entrenar o evaluar razonamiento paso a paso, pero hay que evitar que los ejemplos de evaluación entren en entrenamiento. En razonamiento, la solución no debe ser una decoración: debe poder comprobarse.

6. Multimodalidad. LAION-5B ilustra pares imagen-texto a gran escala; LLaVA usa instrucción visual para conectar imagen y diálogo. Aquí el dataset no solo enseña palabras. Enseña alineación entre una representación visual y lenguaje.

7. Evaluación. MMLU, BEIR o MTEB no deberían tratarse como entrenamiento de conveniencia. Son instrumentos de medida. Puedes inspirarte en ellos, pero tu producto necesita evaluación propia, como vimos en el capítulo 10 del facsímil 4.

Qué debe mirar un ingeniero en un dataset

La ficha de un dataset debería leerse como una ficha de arquitectura:

Campo	Qué preguntas hacer
Procedencia	¿Quién creó los datos? ¿Con qué permisos? ¿De qué dominios vienen?
Formato	¿Texto libre, instrucciones, preferencias, código, imagen-texto, tablas?
Tamaño	¿Número de ejemplos, tokens, documentos o pares?
Calidad	¿Hay filtros, deduplicación, revisión humana o heurísticas claras?
Licencia	¿Permite entrenamiento, redistribución, uso comercial o derivados?
Cobertura	¿Qué idiomas, dominios, estilos y tareas incluye?
Huecos	¿Qué casos no cubre o cubre mal?
Riesgos	¿Datos personales, duplicados, baja calidad, sesgos de fuente?
Contaminación	¿Se mezcló con benchmarks o tests que luego se reportan?
Trazabilidad	¿Puedo reconstruir versión, filtros y mezcla usada?

Una regla simple: un dataset pequeño y muy bueno puede ganar a un dataset enorme y sucio en una adaptación concreta. Para preentrenamiento, el volumen importa mucho; para SFT, preferencias o destilación, la calidad y la cobertura del caso real pesan muchísimo.

Software que ayuda a auditar datasets y evaluar modelos

Sí, existe software para ayudar, pero conviene no meterlo todo en el mismo saco. Una herramienta puede limpiar datos, otra puede detectar ejemplos sospechosos, otra puede ejecutar benchmarks y otra puede evaluar un RAG. “Evaluar el dataset” no es una única operación.

Herramienta	Qué evalúa o cura	Cuándo usarla	Qué no debes pedirle
DataTrove	Procesa, filtra, deduplica y calcula estadísticas sobre texto a gran escala.¹¹	Antes de preentrenar o construir un corpus grande.	No decide por sí sola si una respuesta SFT es pedagógicamente buena.
NVIDIA NeMo Curator	Curation multimodal: texto, imagen, vídeo y audio; filtrado, deduplicación y calidad a escala.¹²	Cuando el volumen exige pipelines distribuidos o multimodales.	No sustituye tu criterio de dominio ni una licencia clara.
Cleanlab TLM / Studio	Detecta ejemplos problemáticos en pares instrucción-respuesta: baja calidad, prompts vagos, PII, lenguaje tóxico, gramática, etc.¹³	Para revisar SFT, datasets de preferencias o conjuntos de evaluación con respuestas.	No convierte automáticamente una mala rúbrica en una buena.
Deepchecks	Integridad de datos, distribuciones, splits, comparación de modelos y validación clásica de ML.¹⁴	En datasets tabulares, visión o ML tradicional; también para detectar problemas de splits.	No es el evaluador principal de un LLM conversacional.
Hugging Face Evaluate	Métricas, mediciones y comparaciones reproducibles para modelos y datasets.¹⁵	Cuando necesitas métricas conocidas y resultados reproducibles.	No entiende tu negocio si no defines bien la tarea.
LightEval	Evaluación de LLMs en múltiples backends, tareas existentes, tareas propias y resultados muestra a muestra.¹⁶	Después de adaptar un modelo o comparar variantes.	No audita por sí solo el dataset de entrenamiento.
lm-evaluation-harness	Benchmarks académicos y tareas reproducibles para modelos de lenguaje.¹⁷	Para comparar contra MMLU, GSM8K, BBH y otros benchmarks públicos.	No sustituye tu evaluación privada de producto.
HELM	Evaluación holística: escenarios, métricas, robustez, transparencia y comparación amplia.¹⁸	Como marco mental o benchmark amplio.	No te dice si tu asistente responde bien a tus usuarios concretos.

Un flujo profesional mínimo sería:

Antes de entrenar: perfilar, filtrar, deduplicar, detectar idioma, longitud, PII, duplicados y baja calidad con DataTrove, NeMo Curator, Cleanlab o checks propios.
Antes de tocar pesos: congelar splits train, validation y test, con hashes y versión de dataset.
Después de adaptar: evaluar con LightEval, lm-evaluation-harness, Hugging Face Evaluate o un harness propio.
Antes de publicar: pasar tu dataset privado de evaluación, no solo benchmarks públicos.
Si es RAG: usar evaluación por capas como la del facsímil 4, capítulo 10: retrieval, contexto, groundedness, citas y abstención.

La idea importante es esta: el software ayuda a encontrar problemas, pero no define por ti qué significa “bueno”. Esa definición sigue siendo del equipo: tarea, rúbrica, usuario, coste, licencia y riesgo de error.

Fine-tuning completo: mover todos los pesos

En fine-tuning completo, partimos de unos pesos $\theta$ y los actualizamos con nuevos datos:

\theta' = \theta - \eta \nabla_{\theta}\mathcal{L}

Símbolo	Significado	Ejemplo
$\theta$	Pesos iniciales del modelo base.	Pesos de un LLM preentrenado.
$\theta'$	Pesos después del ajuste.	Modelo especializado.
$\eta$	Tasa de aprendizaje.	$2 \times 10^{-5}$ .
$\nabla_{\theta}\mathcal{L}$	Gradiente de la pérdida respecto a los pesos.	Dirección para reducir error.
$\mathcal{L}$	Función de pérdida.	Error en respuestas esperadas.

Esto puede funcionar muy bien, pero tiene costes:

Ventaja	Coste
Gran capacidad de adaptación.	Mucha memoria y cómputo.
Puede modificar profundamente el comportamiento.	Riesgo de olvidar capacidades útiles si los datos son estrechos.
Produce un único modelo ajustado.	Guardar y servir muchas variantes puede ser caro.

En equipos pequeños, fine-tuning completo no suele ser la primera opción. Antes se prueba prompt, RAG, evaluación, datos mejores y métodos eficientes como LoRA.

La pérdida y los gradientes: qué cambia de verdad

Cuando decimos «ajustar pesos», estamos diciendo algo muy concreto: calcular una pérdida, derivarla y mover parámetros para reducirla.

Supongamos que queremos enseñar al modelo a continuar esta frase:

El cliente quiere cambiar unos auriculares porque llegaron...

Y el token correcto en nuestro ejemplo es:

rotos

El modelo produce logits para tres candidatos:

Token candidato	Logit
factura	2,0
rotos	1,0
saludo	0,0

Aplicamos softmax:

p_i = \frac{e^{z_i}}{\sum_j e^{z_j}}

Token	Probabilidad $p_i$	Etiqueta $y_i$	Gradiente $p_i-y_i$
factura	0,665	0	0,665
rotos	0,245	1	-0,755
saludo	0,090	0	0,090

La pérdida de entropía cruzada para el token correcto es:

\mathcal{L} = -\log(p_{\text{rotos}})

\mathcal{L} \approx -\log(0{,}245) \approx 1{,}408

La derivada respecto a cada logit, cuando usamos softmax y entropía cruzada, queda así:

\frac{\partial \mathcal{L}}{\partial z_i}=p_i-y_i

Símbolo	Significado	Ejemplo
$z_i$	Logit del token candidato $i$ .	$z_{\text{factura}}=2{,}0$ .
$p_i$	Probabilidad tras softmax.	$p_{\text{rotos}}=0{,}245$ .
$y_i$	Etiqueta real en formato one-hot.	Para «rotos», $y=1$ .
$p_i-y_i$	Gradiente respecto al logit.	Para «rotos», $-0{,}755$ .

Lectura práctica:

Token	Qué le dice el gradiente al entrenamiento
factura	«Te estás pasando con este token; baja su puntuación».
rotos	«Este era el bueno; sube su puntuación».
saludo	«También está algo alto; bájalo un poco».

Si la última capa calcula:

z = hW

entonces el gradiente llega a $W$ así:

\frac{\partial \mathcal{L}}{\partial W}=h^T(p-y)

En la práctica no entrenamos con una frase, sino con lotes de ejemplos. Si tenemos $B$ ejemplos, una pérdida media sería:

\mathcal{L}_{\text{lote}}=-\frac{1}{B}\sum_{b=1}^{B}\log p(y^{(b)}\mid x^{(b)})

El optimizador no ve «atención al cliente», «factura» o «tono educado». Ve números. Si el lote contiene muchos ejemplos donde una devolución debe terminar en un formato concreto, los gradientes empujan al modelo hacia ese patrón. Si los ejemplos son pobres, repetidos o demasiado estrechos, el modelo puede mejorar esa plantilla y empeorar fuera de ella.

Técnica	Por dónde dejamos pasar el gradiente	Qué queda congelado	Lectura práctica
Fine-tuning completo	Casi todo el modelo.	Poco o nada.	Máxima capacidad de cambio, máximo coste y más riesgo de tocar cosas que funcionaban.
LoRA / QLoRA	Matrices pequeñas $A$ y $B$ .	Matriz grande $W$ y la mayor parte del modelo.	Adaptas el comportamiento con una pieza pequeña que se puede guardar aparte.
Adapters	Módulos añadidos entre capas.	La red base.	Útil si quieres muchas tareas sobre una base común.
Prompt tuning / prefix tuning	Vectores continuos aprendidos.	Los pesos del modelo.	Cambia la entrada interna, no el modelo base.
IA3	Vectores que escalan activaciones.	Casi todos los pesos.	Ajuste muy ligero: más fino, pero también menos expresivo.
DPO	Pesos o adaptadores a partir de preferencias.	Depende de la implementación.	Enseña qué respuesta preferimos cuando hay varias plausibles.
Destilación	El estudiante.	El profesor.	El grande enseña señales; el pequeño aprende a imitar lo suficiente.

Esa es la diferencia real entre técnicas: por dónde dejamos pasar el gradiente. Y por eso la pérdida no basta como única brújula. Puede bajar la pérdida en tus ejemplos y aun así empeorar una tarea real si el conjunto de evaluación no representa el uso diario.

No todo es LoRA: mapa de técnicas de adaptación

LoRA y QLoRA son importantes, pero no son las únicas opciones. Esta tabla sirve como brújula rápida. No hace falta memorizar todos los nombres; lo importante es saber qué parte se entrena, qué problema resuelve y qué puede salir mal.

Técnica	Qué se entrena	Cuándo encaja	Cuidado
Prompting	Nada. Solo contexto escrito.	Primer intento, prototipos, tareas simples.	Si el contexto cambia mucho, puede volverse frágil.
RAG	Normalmente nada del modelo; se entrena o configura recuperación.	Conocimiento privado o cambiante.	Si recupera mal, el modelo contesta con mala base.
Fine-tuning completo	Todos o casi todos los pesos.	Cambio profundo de dominio o comportamiento.	Caro; riesgo de olvidar capacidades útiles.
SFT / instruction tuning	Pesos del modelo, con pares instrucción-respuesta.	Enseñar formato, estilo y seguimiento de tareas.	La calidad de ejemplos manda más que el nombre de la técnica.
Adapters	Módulos pequeños insertados en capas.	Muchas tareas con una base compartida.	Añaden algo de latencia y complejidad.¹⁹
Prompt tuning	Vectores de prompt continuos.	Modelos grandes, tareas concretas y bajo coste.	No es texto legible; es un prompt aprendido.²⁰
Prefix tuning	Vectores de prefijo para condicionar capas.	Generación controlada con pocos parámetros.	Requiere saber dónde insertar el prefijo.²¹
P-tuning v2	Prompts continuos profundos, a menudo en varias capas.	Cuando quieres prompt tuning más expresivo en tareas de comprensión.	Sigue siendo menos interpretable que ejemplos escritos.²²
BitFit	Principalmente sesgos del modelo.	Prueba barata cuando tienes pocos datos.	Puede quedarse corto si la tarea exige cambiar representaciones profundas.²³
LoRA	Matrices pequeñas $A$ y $B$ .	Ajuste eficiente y práctico en LLMs.	Depende de rango, capas elegidas y datos.
QLoRA	LoRA sobre modelo base cuantizado.	Ajustar modelos grandes con poca memoria.	Cuantización y configuración importan mucho.
IA3	Vectores que escalan activaciones.	Ajuste muy ligero con pocos ejemplos.	Menos flexible que métodos con más parámetros.²⁴
AdaLoRA	Bajo rango con presupuesto adaptativo.	Cuando no quieres repartir el mismo rango a todas las matrices.	Más configuración; no siempre merece la complejidad.²⁵
DoRA	Magnitud y dirección del peso, usando bajo rango para la dirección.	Cuando LoRA se queda algo corto y quieres más capacidad.	Es una variante más especializada; conviene validar contra LoRA simple.²⁶
DPO / preferencias	Pesos o adaptadores usando pares preferido/rechazado.	Alinear estilo y preferencias tras SFT.	No sustituye datos correctos ni evaluación.²⁷
Destilación	Un estudiante que imita al profesor.	Reducir tamaño o coste.	Puede perder capacidades fuera de la tarea.
Cuantización	A veces nada; a veces calibración.	Reducir memoria e inferencia.	Puede bajar calidad si se aprieta demasiado.

Una regla práctica: si no tienes evaluación, no elijas técnica todavía. Primero crea diez, cincuenta o cien casos reales que puedas revisar. Sin eso, fine-tuning, LoRA o DPO son formas sofisticadas de adivinar.

Casos cercanos: elegir sin ponerse solemne

La tienda online. El catálogo cambia cada día, pero el tono de atención al cliente debe ser siempre claro y amable. Para el catálogo, RAG: recuperar precio, stock, plazo y política vigente. Para el tono y el formato, quizá basten buenos ejemplos; si se repite mucho, LoRA o adapters pueden fijar esa forma de responder.

El departamento de compras. Recibe presupuestos en PDF y quiere extraer proveedor, importes, plazos y condiciones. Si el problema es leer documentos nuevos, empieza por extracción, validación y RAG. Si el problema es que el modelo devuelve JSON desordenado, SFT o LoRA con ejemplos muy buenos puede ayudar. Si las respuestas son largas y caras, destilar un modelo pequeño para esa tarea empieza a tener sentido.

La app que debe funcionar en un portátil normal. Aquí la pregunta no es solo «qué modelo sabe más», sino «qué modelo cabe, responde rápido y no quema presupuesto». Un modelo open weights cuantizado puede ser suficiente. Si además quieres una tarea muy concreta, QLoRA para adaptar y cuantización para servir son dos piezas que se hablan entre sí.

El equipo docente. Quiere un asistente para generar ejercicios de práctica con el estilo del curso. No necesita memorizar todos los materiales: necesita seguir una plantilla, respetar nivel y producir soluciones revisables. Puedes empezar con prompting y evaluación; si funciona pero se repite cada semana, una adaptación ligera puede ahorrar trabajo.

LoRA: adaptar sin tocar todo

LoRA, Low-Rank Adaptation, parte de una observación práctica: quizá no necesitamos actualizar toda una matriz grande para adaptar un modelo. Podemos congelar el peso original $W$ y aprender una actualización de bajo rango.²⁸

En una capa lineal:

y = Wx

LoRA usa:

y = Wx + \frac{\alpha}{r}BAx

Símbolo	Significado	Ejemplo
$W$	Matriz original congelada.	No se entrena durante LoRA.
$A$	Matriz pequeña entrenable.	Reduce dimensión hacia rango $r$ .
$B$	Matriz pequeña entrenable.	Vuelve a la dimensión original.
$r$	Rango de la adaptación.	$r=8$ , $r=16$ , $r=64$ .
$\alpha$	Escala de la adaptación.	Controla fuerza de LoRA.
$BA$	Actualización de bajo rango.	Aproxima el cambio necesario en $W$ .

Si $W$ mide $4096 \times 4096$ , tiene:

4096 \cdot 4096 = 16\,777\,216

parámetros.

Con LoRA de rango $r=16$ :

16(4096 + 4096)=131\,072

parámetros entrenables.

Método	Parámetros entrenables en la matriz del ejemplo
Fine-tuning completo	16 777 216
LoRA con $r=16$	131 072

No es gratis ni siempre suficiente, pero cambia la escala del problema. Puedes adaptar un modelo grande entrenando una fracción pequeña de sus parámetros.

QLoRA: adaptar con menos memoria

QLoRA combina cuantización y LoRA: mantiene el modelo base cuantizado y entrena adaptadores LoRA encima.²⁹

La idea:

pesos base cuantizados y congelados + adaptadores LoRA entrenables

Si un modelo tiene $N$ parámetros y cada parámetro usa $b$ bits, la memoria aproximada solo para pesos es:

\operatorname{memoria} \approx \frac{N \cdot b}{8}

Símbolo	Significado	Ejemplo
$N$	Número de parámetros.	$7 \times 10^9$ .
$b$	Bits por parámetro.	16, 8, 4.
$8$	Bits por byte.	Conversión a bytes.

Para un modelo de 7B:

Precisión	Cálculo aproximado	Memoria aproximada
16 bits	$7B \cdot 16 / 8$	14 GB
8 bits	$7B \cdot 8 / 8$	7 GB
4 bits	$7B \cdot 4 / 8$	3,5 GB

La realidad añade metadatos, activaciones, KV cache y sobrecostes del runtime, pero la intuición sirve: menos bits reducen memoria. En el capítulo 07 conectaremos esto con inferencia, hardware y ejecución local.

Destilación: enseñar a un modelo más pequeño

Destilación significa entrenar un modelo estudiante para imitar señales de un modelo profesor. Hinton, Vinyals y Dean popularizaron la idea de transferir conocimiento usando las probabilidades suaves del profesor, no solo etiquetas duras.³⁰

La intuición:

Etiqueta dura	Distribución suave del profesor
«La respuesta es París».	París 0,82; Lyon 0,10; Madrid 0,05; azul 0,03.

La segunda señal enseña más. No solo dice cuál es la respuesta más probable; también dice qué alternativas eran más plausibles.

Con temperatura $T$ :

p_t^{(T)} = \operatorname{softmax}\left(\frac{z_t}{T}\right)

p_s^{(T)} = \operatorname{softmax}\left(\frac{z_s}{T}\right)

Una pérdida habitual combina etiqueta real y distilación:

\mathcal{L} = (1-\lambda)\operatorname{CE}(y,p_s) + \lambda T^2 \operatorname{KL}(p_t^{(T)} \parallel p_s^{(T)})

Símbolo	Significado	Ejemplo
$p_t^{(T)}$	Distribución del profesor con temperatura.	Probabilidades suaves.
$p_s^{(T)}$	Distribución del estudiante con temperatura.	Lo que intenta imitar.
$y$	Etiqueta real o respuesta esperada.	Token correcto o clase correcta.
$\operatorname{CE}$	Entropía cruzada.	Pérdida con etiqueta real.
$\operatorname{KL}$	Divergencia KL.	Distancia entre distribuciones.
$\lambda$	Peso de la parte de distilación.	0,5, 0,7...
$T$	Temperatura.	Suaviza probabilidades.

DistilBERT es un ejemplo clásico: reduce tamaño y mejora velocidad manteniendo buena parte del rendimiento de BERT en tareas de comprensión.³¹

Un ejemplo entendible: la academia que prepara apuntes

Imagina una academia con una profesora experta y una ayudante nueva. La profesora corrige exámenes desde hace años. La ayudante todavía está aprendiendo.

Podemos enseñar a la ayudante de tres maneras:

Método	Qué recibe la ayudante	Equivalente en modelos
Solo soluciones finales	«Esta respuesta está bien, está mal».	Etiquetas duras.
Explicaciones y matices	«Esta está bien; esta otra casi, pero confunde una fecha».	Distribuciones suaves o razonamiento.
Casos seleccionados	Ejercicios representativos del curso.	Datos curados para adaptación.

La destilación se parece al segundo caso. No obliga al estudiante a ser idéntico al profesor, pero intenta que aprenda su criterio de salida. En producto, esto puede servir para tener un modelo más barato o rápido que mantiene suficiente calidad en una tarea concreta.

Modelos abiertos: abrir qué, exactamente

La palabra «abierto» se usa demasiado deprisa. Conviene separar piezas:

Pieza	Pregunta que debes hacer
Pesos	¿Puedo descargar y ejecutar el checkpoint?
Licencia	¿Puedo usarlo comercialmente? ¿Puedo redistribuir adaptaciones?
Código	¿Está el código de entrenamiento o inferencia?
Tokenizer	¿Está disponible y versionado?
Configuración	¿Conozco arquitectura, contexto, formato de chat y parámetros?
Datos	¿Sé qué datos o mezcla de datos se usaron?
Receta de entrenamiento	¿Puedo reproducir el proceso?
Evaluación	¿Hay benchmarks, limitaciones y resultados verificables?
Model card	¿Hay descripción de uso previsto, límites y supuestos?

La Open Source Initiative publicó en 2024 la versión 1.0 de su definición de Open Source AI, centrada en libertades para usar, estudiar, modificar y compartir sistemas de IA.³² En la práctica, muchos modelos populares son open weights: los pesos están disponibles, pero no necesariamente todo el sistema cumple una definición estricta de open source.

Ejemplos de familias abiertas o de pesos disponibles, con matices:

Familia	Qué ilustra	Matiz
Llama 3	Pesos y documentación técnica ampliamente usados.³³	Licencia propia; no equivale automáticamente a open source completo.
Mistral 7B	Modelo eficiente de 7B con publicación técnica.³⁴	Hay que mirar licencia y versión concreta.
Qwen2.5	Familia de modelos con informe técnico amplio.³⁵	Cada tamaño y variante puede tener condiciones propias.

La conclusión importante: abierto no es binario. Hay grados de apertura y permisos concretos. Para uso profesional, mirar solo si «se puede descargar» es insuficiente.

Qué elegir según el caso

Situación	Primera opción razonable	Por qué
Necesitas datos actualizados o privados.	RAG antes que fine-tuning.	No quieres reentrenar para cada documento nuevo.
Necesitas formato muy específico.	Instruction tuning o ejemplos muy cuidados.	Enseñas patrón de salida.
Tienes pocos recursos de entrenamiento.	LoRA o QLoRA.	Entrenas pocos parámetros.
Necesitas baja latencia o edge.	Destilación, cuantización o modelo pequeño.	Reducen coste de inferencia.
Necesitas control local.	Modelo open weights con licencia compatible.	Puedes ejecutar y adaptar en tu infraestructura.
Necesitas máxima calidad general.	Modelo grande servido por API o modelo abierto fuerte bien evaluado.	A veces el coste compensa.

La decisión profesional no es «fine-tuning sí o no». Es una secuencia:

definir tarea -> crear evaluación -> probar base -> probar prompt/RAG -> adaptar si hace falta -> comprimir si compensa -> revisar licencia

El mapa operativo del capítulo

Este mapa es una regla de decisión, no un catálogo de técnicas. Parte de una tarea medida, pregunta si falta conocimiento vivo, formato, preferencia o coste, y solo entonces propone RAG, SFT, PEFT, DPO, destilación, cuantización o revisión de licencia.

flowchart TD
    C05["Cap. 05<br/>familia base"]
    TAREA["Tarea real<br/>casos y límites"]
    EVAL["Evaluación mínima<br/>antes de adaptar"]
    BASE["Modelo base<br/>sin tocar"]
    DATO{"¿Falta dato<br/>cambiante?"}
    RAG["RAG<br/>recuperar contexto"]
    FORMATO{"¿Falla formato<br/>tono o patrón?"}
    PROMPT["Prompting<br/>y ejemplos"]
    SFT["SFT<br/>instruction tuning"]
    PEFT["PEFT<br/>adapters · LoRA · IA3"]
    PREF{"¿Hay preferencias<br/>entre respuestas?"}
    DPO["DPO<br/>pares preferidos"]
    COSTE{"¿Pesa coste<br/>memoria o latencia?"}
    COMP["Destilación<br/>cuantización"]
    OPEN["Open weights<br/>licencia y trazabilidad"]
    C07["Cap. 07<br/>inferencia y hardware"]
    F04["Fasc. 04<br/>RAG y herramientas"]
    F06["Fasc. 06<br/>operación"]
    F07["Fasc. 07<br/>evaluación"]

    C05 --> BASE
    TAREA --> EVAL
    EVAL --> BASE
    BASE --> DATO
    DATO -->|"sí"| RAG
    DATO -->|"no"| FORMATO
    RAG --> F04
    FORMATO -->|"leve"| PROMPT
    FORMATO -->|"estable"| SFT
    FORMATO -->|"eficiente"| PEFT
    SFT --> PREF
    PEFT --> PREF
    PREF -->|"sí"| DPO
    PREF -->|"no"| COSTE
    DPO --> COSTE
    COSTE -->|"sí"| COMP
    COSTE -->|"no"| OPEN
    COMP --> C07
    COMP --> OPEN
    OPEN --> F06
    OPEN --> F07

    style TAREA fill:#F5F5F5,stroke:#000000,stroke-width:2
    style EVAL fill:#F5F5F5,stroke:#000000,stroke-width:2
    style BASE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style RAG fill:#F5F5F5,stroke:#000000,stroke-width:2
    style PROMPT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SFT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style PEFT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DPO fill:#F5F5F5,stroke:#000000,stroke-width:2
    style COMP fill:#F5F5F5,stroke:#000000,stroke-width:2
    style OPEN fill:#F5F5F5,stroke:#000000,stroke-width:2
    style C05 stroke-dasharray: 5 5
    style C07 stroke-dasharray: 5 5
    style F04 stroke-dasharray: 5 5
    style F06 stroke-dasharray: 5 5
    style F07 stroke-dasharray: 5 5

En el día a día

Un equipo de soporte. Tiene 3 000 respuestas históricas y quiere que el modelo use un tono concreto. Primero conviene crear evaluación y probar prompt/RAG. Si el problema es estilo y formato, LoRA puede bastar. Si el problema es conocimiento cambiante, RAG será más natural.

Un producto local. Necesita funcionar en una máquina pequeña. Aquí pesan cuantización y destilación. Tal vez un modelo de 7B cuantizado o un estudiante destilado sea más útil que un modelo enorme que no cabe en memoria.

Una empresa con restricciones de licencia. No basta con que el modelo esté en internet. Hay que revisar licencia, redistribución, uso comercial, obligación de atribución, datos, documentación y compatibilidad con el producto.

Un laboratorio universitario. Puede usar modelos abiertos para enseñar, reproducir experimentos y comparar adaptaciones. Pero debe enseñar también la diferencia entre pesos descargables y apertura completa.

Por qué debería importarte

Porque adaptar mal sale caro. Puedes gastar semanas afinando un modelo cuando bastaba con recuperar documentos. Puedes comprimir demasiado y perder justo la capacidad que necesitabas. Puedes usar un modelo con licencia incompatible con tu producto. O puedes entrenar LoRA sin evaluación y creer que ha mejorado porque responde con más confianza.

La buena noticia es que el mapa es manejable: primero define tarea y métricas; luego prueba una base; después decide si necesitas adaptación, destilación, cuantización o un modelo abierto específico. La arquitectura importa, pero el proceso de decisión importa igual.

También importa no enamorarse de una sigla. LoRA puede ser perfecta para un caso y excesiva para otro. Prompt tuning puede bastar si la tarea es estrecha. DPO puede ayudar cuando hay preferencias claras entre dos respuestas, pero no arregla una base de datos mala. Destilar puede ahorrar dinero, pero solo si el estudiante conserva lo que de verdad usas. La técnica correcta suele ser la más pequeña que resuelve el problema medido.

Dónde volverá a aparecer

Concepto de este capítulo	Dónde vuelve en el libro	Por qué se conecta
Pérdidas y gradientes	Facsímil 7.	Evaluar y ajustar modelos exige entender qué optimizas y qué mides.
LoRA y QLoRA	Facsímil 4; facsímil 6.	Adaptar modelos y operar variantes exige herramientas, registros y despliegue.
Adapters, prompt tuning, IA3, AdaLoRA y DoRA	Facsímil 6.	En producción aparecen como artefactos, versiones, costes y decisiones de mantenimiento.
DPO y preferencias	Facsímil 7; facsímil 9.	Las preferencias conectan con evaluación, criterios humanos y gobernanza.
Destilación	Facsímil 3, capítulo 07; facsímil 6.	Modelos pequeños y rápidos conectan con inferencia y edge AI.
Cuantización	Facsímil 3, capítulo 07.	Bits, memoria y hardware aparecen directamente al servir modelos.
Modelos abiertos	Facsímil 4; facsímil 9.	Herramientas, licencias, privacidad y gobernanza dependen del grado de apertura.
Evaluación antes de adaptar	Facsímil 7.	Sin evaluación no sabes si la adaptación mejora o solo cambia el estilo.
Datasets de entrenamiento y evaluación	Facsímil 4, capítulo 10; facsímil 7.	Entrenar y evaluar no son lo mismo; separar ambos evita contaminación y falsas mejoras.

Dónde solía tropezar yo

Error	Por qué es un error	Antídoto
Tratar un dataset como una lista de ejemplos	El dataset define formato, pérdida, cobertura, sesgos, permisos y trazabilidad. Es parte de la arquitectura.	Léelo como leerías una model card: procedencia, estructura, licencia, mezcla y versión.
Mezclar entrenamiento y evaluación	Si el modelo ve tus preguntas de test, puede mejorar la nota sin mejorar la capacidad real.	Mantén splits separados, guarda hashes y crea conjuntos de regresión aparte.
Usar fine-tuning para meter conocimiento cambiante	Si los datos cambian cada semana, reentrenar no es la forma más cómoda de mantenerlos vivos.	Pregunta primero si el problema es conocimiento, formato, estilo o razonamiento.
Confundir LoRA con modelo completo	LoRA suele ser una adaptación que necesita el modelo base compatible.	Guarda siempre base, adaptador, tokenizer, configuración y versión.
Pensar que destilar conserva todo	Un estudiante pequeño puede perder capacidades fuera del dominio usado para destilar.	Evalúa dentro y fuera de la tarea principal.
Decir open source cuando solo hay pesos	Descargar pesos no implica conocer datos, receta, licencia completa ni reproducibilidad.	Usa categorías: pesos abiertos, código abierto, datos abiertos, sistema abierto.
Cuantizar sin medir	Menos bits ahorran memoria, pero pueden afectar calidad en tareas sensibles.	Compara respuestas, latencia, memoria y errores antes y después.

Manos a la obra

La práctica real está en kit descargable. El kit calcula parámetros entrenables de LoRA/adapters, gradientes de logits, memoria por bits y una pérdida KL de destilación.

Archivo	Qué contiene
`data/adaptation_case.json`	Dimensiones, logits, objetivo y tamaños de modelo.
`contracts/adaptation_policy.json`	Umbrales de LoRA, memoria y KL.
`ops/estimate_adaptation_budget.py`	Cálculos de parámetros, gradientes, memoria y KL.
`output/adaptation_budget_report.json`	Resultados estructurados.
`output/adaptation_budget_decision.md`	Informe legible.

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/estimate_adaptation_budget.py --write
cat output/adaptation_budget_decision.md

Como gate:

python3 ops/estimate_adaptation_budget.py --write --fail-on-invalid

Qué entregaría un alumno. El Markdown generado, otro rango LoRA, otra precisión y una decisión: LoRA, adapter, cuantización, destilación o no adaptar.

Cómo encaja todo

Este mapa conecta adaptación con todo el temario. El capítulo 6 no vive aislado: usa pérdidas y gradientes del facsímil 1, familias de arquitectura del capítulo 5 y prepara inferencia, operación, evaluación y gobernanza.

La idea que debe quedar es operativa: antes de tocar pesos hay que definir tarea, dataset, evaluación y coste. Después se decide qué parte se mueve: contexto, recuperador, adaptador, estudiante, precisión o modelo base.

graph TD
    F1["Facsímil 1<br/>pérdida, gradiente, entrenamiento e inferencia"]
    C5["Capítulo 5<br/>familias modernas y MoE"]
    C6["Este capítulo<br/>transfer, datasets, PEFT, destilación y apertura"]
    TAREA["Tarea real<br/>qué debe cambiar"]
    EVAL["Evaluación propia<br/>antes de adaptar"]
    DATA["Dataset y mezcla<br/>procedencia · licencia · splits"]
    DECISION["Decisión de adaptación<br/>contexto, pesos o estudiante"]
    RAG["RAG<br/>conocimiento vivo"]
    PEFT["LoRA · QLoRA · adapters<br/>comportamiento estable"]
    PREF["DPO y preferencias<br/>criterio comparativo"]
    COMP["Destilación · cuantización<br/>coste, memoria y latencia"]
    OPEN["Open weights<br/>licencia y trazabilidad"]
    C7["Capítulo 7<br/>inferencia y hardware"]
    F4["Facsímil 4<br/>APIs, RAG y modelos locales"]
    F6["Facsímil 6<br/>operación y despliegue"]
    F7["Facsímil 7<br/>evaluación profunda"]
    F9["Facsímil 9<br/>gobernanza y licencias"]

    F1 -->|"explica cómo se mueven pesos"| C6
    C5 -->|"aporta arquitectura base"| C6
    C6 -->|"empieza por"| TAREA
    TAREA -->|"obliga a construir"| EVAL
    TAREA -->|"define"| DATA
    DATA -->|"puede contaminar si mezcla tests"| EVAL
    EVAL -->|"habilita"| DECISION
    DECISION -->|"si falta dato cambiante"| RAG
    DECISION -->|"si falla formato o tono"| PEFT
    DECISION -->|"si hay respuestas preferidas"| PREF
    DECISION -->|"si no cabe o tarda"| COMP
    DECISION -->|"si hay control local"| OPEN
    RAG -->|"se implementa en"| F4
    PEFT -->|"se versiona en"| F6
    PREF -->|"se mide en"| F7
    COMP -->|"condiciona"| C7
    OPEN -->|"se revisa en"| F9
    C7 -->|"retroalimenta coste de"| DECISION

    style C6 fill:#F5F5F5,stroke:#000000,stroke-width:2
    style TAREA fill:#F5F5F5,stroke:#000000,stroke-width:2
    style EVAL fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DATA fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DECISION fill:#F5F5F5,stroke:#000000,stroke-width:2
    style RAG fill:#F5F5F5,stroke:#000000,stroke-width:2
    style PEFT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style PREF fill:#F5F5F5,stroke:#000000,stroke-width:2
    style COMP fill:#F5F5F5,stroke:#000000,stroke-width:2
    style OPEN fill:#F5F5F5,stroke:#000000,stroke-width:2
    style F1 stroke-dasharray: 5 5
    style C5 stroke-dasharray: 5 5
    style C7 stroke-dasharray: 5 5
    style F4 stroke-dasharray: 5 5
    style F6 stroke-dasharray: 5 5
    style F7 stroke-dasharray: 5 5
    style F9 stroke-dasharray: 5 5

Vocabulario aprendido

Término	Definición
Transfer learning	Reutilizar un modelo entrenado como punto de partida para otra tarea.
Fine-tuning	Ajustar pesos de un modelo base con datos específicos.
Gradiente de pérdida	Señal numérica que indica cómo cambiar parámetros para reducir el error.
Instruction tuning	Ajuste con ejemplos de instrucciones y respuestas deseadas.
PEFT	Familia de técnicas de ajuste eficiente de parámetros.
Adapters	Módulos pequeños añadidos al modelo para adaptar tareas sin tocar toda la base.
Prompt tuning / prefix tuning	Vectores aprendidos que condicionan el modelo manteniendo congelados sus pesos.
BitFit	Ajuste de sesgos del modelo como técnica mínima de adaptación.
LoRA	Adaptación de bajo rango que entrena matrices pequeñas con el modelo base congelado.
QLoRA	LoRA sobre pesos base cuantizados para reducir memoria de entrenamiento.
IA3	Ajuste con vectores que escalan activaciones internas.
AdaLoRA / DoRA	Variantes de bajo rango que intentan aprovechar mejor los parámetros entrenables.
DPO	Ajuste con pares de respuestas preferidas y no preferidas.
Destilación	Entrenar un modelo pequeño usando señales de un modelo mayor.
Cuantización	Reducir bits por peso o activación para ahorrar memoria y coste.
Open weights	Pesos descargables, no necesariamente apertura completa.
Modelo abierto	Modelo con permisos, documentación y artefactos suficientes para uso, estudio y adaptación.
Dataset de preentrenamiento	Corpus grande usado para aprender patrones generales antes de adaptar.
Dataset SFT	Pares de instrucción-respuesta para enseñar formato, tono y seguimiento de tareas.
Dataset de preferencias	Comparaciones entre respuestas para enseñar criterios de elección.
Dataset de razonamiento	Problemas con solución, pasos o verificador para entrenar o medir resolución estructurada.
Dataset multimodal	Datos que combinan texto con imágenes, audio, vídeo u otras señales.
Data mixture	Proporción de familias de datos en entrenamiento.
Data contamination	Presencia de ejemplos de evaluación dentro del entrenamiento.

Antes de pasar página

En resumen

Idea fuerza	Detalle
Casi nadie entrena un LLM grande desde cero.	Lo habitual es reutilizar una base y adaptarla con datos, instrucciones o herramientas.
Los datasets son arquitectura.	Preentrenamiento, SFT, preferencias, razonamiento, código y multimodalidad tienen formatos, pérdidas y riesgos distintos.
La pérdida baja moviendo gradientes.	Cada técnica decide qué partes reciben esa señal: todo el modelo, adaptadores, matrices LoRA, prompts continuos o un estudiante.
LoRA y QLoRA cambian la escala del ajuste, pero no están solas.	Adapters, prompt tuning, prefix tuning, BitFit, IA3, AdaLoRA, DoRA y DPO son piezas distintas del mismo mapa.
Destilación y cuantización comprimen, pero hay que medir.	Ahorran coste y memoria, aunque pueden perder capacidades.
Abierto no significa solo descargable.	Pesos, licencia, tokenizer, datos, receta, evaluación y model card importan.

Para saber más

Dettmers, T., Pagnoni, A., Holtzman, A. y Zettlemoyer, L. (2023). QLoRA: Efficient finetuning of quantized LLMs. Advances in Neural Information Processing Systems 36. https://arxiv.org/abs/2305.14314

Devlin, J., Chang, M.-W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. Proceedings of NAACL-HLT, 4171-4186. https://doi.org/10.18653/v1/N19-1423

Gao, L. et al. (2020). The Pile: An 800GB Dataset of Diverse Text for Language Modeling. https://arxiv.org/abs/2101.00027

Longpre, S. et al. (2023). The Flan Collection: Designing Data and Methods for Effective Instruction Tuning. https://arxiv.org/abs/2301.13688

Databricks. (2023). databricks-dolly-15k. https://huggingface.co/datasets/databricks/databricks-dolly-15k

Bai, Y. et al. (2022). Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback. https://arxiv.org/abs/2204.05862

Cui, G. et al. (2023). UltraFeedback: Boosting Language Models with High-quality Feedback. https://arxiv.org/abs/2310.01377

Cobbe, K. et al. (2021). Training Verifiers to Solve Math Word Problems. https://arxiv.org/abs/2110.14168

Kocetkov, D. et al. (2022). The Stack: 3 TB of permissively licensed source code. https://arxiv.org/abs/2211.15533

Schuhmann, C. et al. (2022). LAION-5B: An open large-scale dataset for training next generation image-text models. https://arxiv.org/abs/2210.08402

Liu, H. et al. (2023). Visual Instruction Tuning. https://arxiv.org/abs/2304.08485

Hendrycks, D. et al. (2021). Measuring Massive Multitask Language Understanding. https://arxiv.org/abs/2009.03300

Thakur, N. et al. (2021). BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models. https://arxiv.org/abs/2104.08663

Muennighoff, N. et al. (2023). MTEB: Massive Text Embedding Benchmark. https://arxiv.org/abs/2210.07316

Dubey, A. et al. (2024). The Llama 3 herd of models. https://arxiv.org/abs/2407.21783

Hinton, G., Vinyals, O. y Dean, J. (2015). Distilling the knowledge in a neural network. https://arxiv.org/abs/1503.02531

Houlsby, N. et al. (2019). Parameter-efficient transfer learning for NLP. International Conference on Machine Learning. https://arxiv.org/abs/1902.00751

Hu, E. J. et al. (2022). LoRA: Low-rank adaptation of large language models. International Conference on Learning Representations. https://arxiv.org/abs/2106.09685

Jacob, B. et al. (2018). Quantization and training of neural networks for efficient integer-arithmetic-only inference. Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, 2704-2713. https://doi.org/10.1109/CVPR.2018.00286

Jiang, A. Q. et al. (2023). Mistral 7B. https://arxiv.org/abs/2310.06825

Lester, B., Al-Rfou, R. y Constant, N. (2021). The power of scale for parameter-efficient prompt tuning. Proceedings of EMNLP, 3045-3059. https://doi.org/10.18653/v1/2021.emnlp-main.243

Li, X. L. y Liang, P. (2021). Prefix-tuning: Optimizing continuous prompts for generation. Proceedings of ACL, 4582-4597. https://doi.org/10.18653/v1/2021.acl-long.353

Liu, H. et al. (2022). Few-shot parameter-efficient fine-tuning is better and cheaper than in-context learning. https://arxiv.org/abs/2205.05638

Liu, S.-Y. et al. (2024). DoRA: Weight-decomposed low-rank adaptation. International Conference on Machine Learning. https://arxiv.org/abs/2402.09353

Liu, X. et al. (2022). P-Tuning v2: Prompt tuning can be comparable to fine-tuning universally across scales and tasks. Proceedings of ACL. https://arxiv.org/abs/2110.07602

Open Source Initiative. (2024). The Open Source AI Definition -- 1.0. https://opensource.org/ai/open-source-ai-definition

Ouyang, L. et al. (2022). Training language models to follow instructions with human feedback. Advances in Neural Information Processing Systems 35, 27730-27744. https://arxiv.org/abs/2203.02155

Rafailov, R. et al. (2023). Direct preference optimization: Your language model is secretly a reward model. Advances in Neural Information Processing Systems 36. https://arxiv.org/abs/2305.18290

Raffel, C. et al. (2020). Exploring the limits of transfer learning with a unified text-to-text Transformer. Journal of Machine Learning Research, 21(140), 1-67. https://www.jmlr.org/papers/v21/20-074.html

Sanh, V., Debut, L., Chaumond, J. y Wolf, T. (2019). DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter. https://arxiv.org/abs/1910.01108

Yang, A. et al. (2024). Qwen2.5 technical report. https://arxiv.org/abs/2412.15115

Ben-Zaken, E., Ravfogel, S. y Goldberg, Y. (2022). BitFit: Simple parameter-efficient fine-tuning for transformer-based masked language-models. Proceedings of ACL. https://arxiv.org/abs/2106.10199

Zhang, Q. et al. (2023). AdaLoRA: Adaptive budget allocation for parameter-efficient fine-tuning. International Conference on Learning Representations. https://arxiv.org/abs/2303.10512

Notas

Devlin, J., Chang, M.-W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. Proceedings of NAACL-HLT, 4171-4186. https://doi.org/10.18653/v1/N19-1423. BERT popularizó el esquema de preentrenar representaciones de lenguaje y ajustarlas en tareas posteriores. ↩
Raffel, C. et al. (2020). Exploring the limits of transfer learning with a unified text-to-text Transformer. Journal of Machine Learning Research, 21(140), 1-67. https://www.jmlr.org/papers/v21/20-074.html. T5 estudia transferencia en un marco unificado donde muchas tareas se expresan como entrada de texto y salida de texto. ↩
Ouyang, L. et al. (2022). Training language models to follow instructions with human feedback. Advances in Neural Information Processing Systems 35, 27730-27744. https://arxiv.org/abs/2203.02155. El trabajo muestra cómo el ajuste con instrucciones y preferencias humanas mejora la capacidad de seguir peticiones. ↩
Raffel et al. (2020) crearon C4 para T5 como corpus web filtrado. Gao, L. et al. (2020). The Pile: An 800GB Dataset of Diverse Text for Language Modeling. https://arxiv.org/abs/2101.00027. ↩
Kocetkov, D. et al. (2022). The Stack: 3 TB of permissively licensed source code. https://arxiv.org/abs/2211.15533. ↩
Longpre, S. et al. (2023). The Flan Collection. https://arxiv.org/abs/2301.13688. Databricks. (2023). databricks-dolly-15k. https://huggingface.co/datasets/databricks/databricks-dolly-15k. ↩
Bai, Y. et al. (2022). Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback. https://arxiv.org/abs/2204.05862. Cui, G. et al. (2023). UltraFeedback. https://arxiv.org/abs/2310.01377. ↩
Cobbe, K. et al. (2021). Training Verifiers to Solve Math Word Problems. https://arxiv.org/abs/2110.14168. ↩
Schuhmann, C. et al. (2022). LAION-5B. https://arxiv.org/abs/2210.08402. Liu, H. et al. (2023). Visual Instruction Tuning. https://arxiv.org/abs/2304.08485. ↩
Hendrycks, D. et al. (2021). Measuring Massive Multitask Language Understanding. https://arxiv.org/abs/2009.03300. BEIR y MTEB aparecen en los capítulos de embeddings y evaluación. ↩
Hugging Face. (2026). DataTrove. https://github.com/huggingface/datatrove. La documentación lo presenta como una librería para procesar, filtrar y deduplicar texto a gran escala, con bloques de estadísticas, filtros, tokens y deduplicación. ↩
NVIDIA. (2026). Overview of NeMo Curator. https://docs.nvidia.com/nemo/curator/latest/about. La documentación describe una plataforma abierta para curation de datos escalable y consciente de privacidad para datasets de entrenamiento de IA generativa. ↩
Cleanlab. (2026). Discover Bad Data/Responses in any LLM/Human-Written Dataset. https://help.cleanlab.ai/tlm/use-cases/instruction_tuning_data/. El tutorial muestra cómo puntuar pares prompt-respuesta y localizar ejemplos de baja calidad en datasets de instruction tuning o evals. ↩
Deepchecks. (2026). Welcome to Deepchecks. https://docs.deepchecks.com/0.8/getting-started/welcome.html. La documentación lo define como herramienta para validar datos y modelos: integridad, distribuciones, splits y comparación entre modelos. ↩
Hugging Face. (2026). Evaluate. https://huggingface.co/docs/evaluate/index. La documentación lo presenta como librería para evaluar modelos y datasets con métodos de evaluación de NLP, visión, RL y otros dominios. ↩
Hugging Face. (2026). Lighteval. https://huggingface.co/docs/lighteval/index. La documentación lo describe como toolkit para evaluar LLMs con distintos backends, tareas, métricas y resultados detallados. ↩
EleutherAI. (2026). Language Model Evaluation Harness. https://github.com/EleutherAI/lm-evaluation-harness. El repositorio lo describe como framework unificado para probar modelos generativos en muchas tareas, con benchmarks públicos y soporte para modelos locales, APIs y adaptadores. ↩
Liang, P. et al. (2022). Holistic Evaluation of Language Models. https://arxiv.org/abs/2211.09110. HELM propone evaluar modelos con múltiples escenarios y métricas para evitar una lectura estrecha del rendimiento. ↩
Houlsby, N. et al. (2019). Parameter-efficient transfer learning for NLP. International Conference on Machine Learning. https://arxiv.org/abs/1902.00751. El trabajo propone adaptar modelos de lenguaje con módulos pequeños manteniendo la mayoría de parámetros congelados. ↩
Lester, B., Al-Rfou, R. y Constant, N. (2021). The power of scale for parameter-efficient prompt tuning. Proceedings of EMNLP, 3045-3059. https://doi.org/10.18653/v1/2021.emnlp-main.243. El método aprende soft prompts manteniendo congelado el modelo base. ↩
Li, X. L. y Liang, P. (2021). Prefix-tuning: Optimizing continuous prompts for generation. Proceedings of ACL, 4582-4597. https://doi.org/10.18653/v1/2021.acl-long.353. Prefix tuning optimiza vectores continuos de prefijo con el modelo base congelado. ↩
Liu, X. et al. (2022). P-Tuning v2: Prompt tuning can be comparable to fine-tuning universally across scales and tasks. Proceedings of ACL. https://arxiv.org/abs/2110.07602. P-tuning v2 muestra que prompts continuos bien optimizados pueden acercarse al fine-tuning con pocos parámetros. ↩
Ben-Zaken, E., Ravfogel, S. y Goldberg, Y. (2022). BitFit: Simple parameter-efficient fine-tuning for transformer-based masked language-models. Proceedings of ACL. https://arxiv.org/abs/2106.10199. BitFit ajusta solo términos de sesgo y aun así puede competir en algunos escenarios. ↩
Liu, H. et al. (2022). Few-shot parameter-efficient fine-tuning is better and cheaper than in-context learning. https://arxiv.org/abs/2205.05638. El trabajo introduce IA3, que aprende vectores de escala para adaptar activaciones con pocos parámetros. ↩
Zhang, Q. et al. (2023). AdaLoRA: Adaptive budget allocation for parameter-efficient fine-tuning. International Conference on Learning Representations. https://arxiv.org/abs/2303.10512. AdaLoRA reparte el presupuesto entrenable según la importancia estimada de cada matriz. ↩
Liu, S.-Y. et al. (2024). DoRA: Weight-decomposed low-rank adaptation. International Conference on Machine Learning. https://arxiv.org/abs/2402.09353. DoRA separa magnitud y dirección para acercarse más al fine-tuning completo con pocos parámetros. ↩
Rafailov, R. et al. (2023). Direct preference optimization: Your language model is secretly a reward model. Advances in Neural Information Processing Systems 36. https://arxiv.org/abs/2305.18290. DPO optimiza preferencias directamente sin entrenar un modelo de recompensa separado. ↩
Hu, E. J. et al. (2022). LoRA: Low-rank adaptation of large language models. International Conference on Learning Representations. https://arxiv.org/abs/2106.09685. LoRA congela los pesos preentrenados e introduce matrices entrenables de bajo rango para adaptar modelos grandes con muchos menos parámetros. ↩
Dettmers, T., Pagnoni, A., Holtzman, A. y Zettlemoyer, L. (2023). QLoRA: Efficient finetuning of quantized LLMs. Advances in Neural Information Processing Systems 36. https://arxiv.org/abs/2305.14314. QLoRA reduce memoria al ajustar modelos grandes cuantizados en 4 bits mientras entrena adaptadores de bajo rango. ↩
Hinton, G., Vinyals, O. y Dean, J. (2015). Distilling the knowledge in a neural network. https://arxiv.org/abs/1503.02531. El trabajo propone entrenar modelos más pequeños usando la distribución de salida de modelos más grandes o conjuntos de modelos. ↩
Sanh, V., Debut, L., Chaumond, J. y Wolf, T. (2019). DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter. https://arxiv.org/abs/1910.01108. DistilBERT usa destilación durante preentrenamiento para obtener un modelo más pequeño y rápido que conserva gran parte de las capacidades de BERT. ↩
Open Source Initiative. (2024). The Open Source AI Definition -- 1.0. https://opensource.org/ai/open-source-ai-definition. La definición busca aclarar qué condiciones debería cumplir un sistema de IA para considerarse open source. ↩
Dubey, A. et al. (2024). The Llama 3 herd of models. https://arxiv.org/abs/2407.21783. El informe presenta modelos Llama 3 preentrenados y postentrenados, incluyendo tamaños grandes y variantes para distintos usos. ↩
Jiang, A. Q. et al. (2023). Mistral 7B. https://arxiv.org/abs/2310.06825. El trabajo presenta un modelo de 7B con decisiones de eficiencia como sliding window attention y grouped-query attention. ↩
Yang, A. et al. (2024). Qwen2.5 technical report. https://arxiv.org/abs/2412.15115. El informe describe la familia Qwen2.5 y resultados en múltiples tareas. ↩

Capítulo 07

Facsímil 3 · Arquitecturas y modelos

Capítulo 07: Inferencia optimizada, edge AI y hardware

La IA también es esperar

Hay una escena muy común: eliges un modelo, haces una demo, todo parece brillante... y luego alguien lo prueba con diez usuarios a la vez. El primer token tarda demasiado. La respuesta completa llega tarde. La GPU se llena aunque el modelo «cabía». El portátil se calienta. La factura sube. El problema ya no es si el modelo sabe contestar; es si puede contestar a tiempo, con memoria suficiente y a un coste razonable.

Este capítulo trata de esa parte menos vistosa y absolutamente decisiva: la inferencia. En el capítulo anterior hablamos de adaptar, destilar, cuantizar y elegir modelos abiertos. Ahora preguntamos qué pasa cuando ese modelo se usa de verdad: cuánta memoria consume, qué limita la velocidad, qué pinta la caché KV, por qué el hardware importa y cuándo tiene sentido llevar IA al dispositivo.

La idea de fondo es sencilla: un modelo útil no es solo el que responde bien. Es el que responde bien dentro de tus restricciones.

Estado del arte con fecha de corte

Fecha de corte: 10 de junio de 2026.
Fuentes consultadas ese día: papers de FlashAttention, PagedAttention/vLLM, speculative decoding, GQA y cuantización; documentación vigente de vLLM, TensorRT-LLM, llama.cpp y MLPerf Inference; y una lectura pedagógica de Turing Post sobre QKV y KV cache.

Esta sección no pretende congelar el mercado. Los nombres de runtimes, formatos y aceleradores cambian. Lo que sí es más estable son las tensiones técnicas: memoria, ancho de banda, lotes, caché KV, latencia, calidad y coste.

Capa del problema	Estado observado a 10 de junio de 2026	Qué debes mirar
Kernels de atención	FlashAttention y variantes IO-aware son referencia para reducir movimiento de memoria en atención exacta.¹	Si tu runtime usa kernels modernos para tu GPU y tu longitud de contexto.
KV cache	PagedAttention y cachés paginadas reducen desperdicio y fragmentación al servir muchas peticiones.²	Memoria real con batch, contexto largo y usuarios simultáneos.
Planificación de peticiones	Continuous batching, chunked prefill, prefix caching y separación prefill/decode aparecen en runtimes modernos como vLLM y TensorRT-LLM.³	Latencia p50/p95, no solo tokens/s máximos.
Decodificación	Speculative decoding acelera cuando un modelo pequeño propone tokens que el grande puede aceptar.⁴	Si la tasa de aceptación compensa el coste del modelo auxiliar.
Arquitectura del modelo	MQA y GQA reducen el número de cabezas de clave/valor y, por tanto, la memoria de KV cache.⁵	No solo tamaño en parámetros: también número de capas, contexto y cabezas KV.
Cuantización	INT8, FP8, INT4, GPTQ, AWQ, SmoothQuant y GGUF conviven según hardware, runtime y objetivo.⁶	Calidad tras cuantizar, memoria, velocidad y soporte real del runtime.
Edge AI	llama.cpp/GGUF, MLX, ONNX Runtime, NPUs y GPUs integradas permiten casos locales, pero con límites térmicos y de memoria.⁷	Si necesitas privacidad, offline, baja latencia local o menor coste por uso.
Benchmarking	MLPerf Inference sigue siendo una referencia neutral para medir sistemas completos, no solo modelos.⁸	Comparar sistema completo: modelo, runtime, hardware, batch, precisión y latencia.

La lectura corta: a fecha de corte, optimizar inferencia no significa tocar un botón. Significa coordinar modelo, caché, kernel, cuantización, scheduler, hardware y evaluación.

Qué no es optimizar inferencia

Optimizar inferencia no es solo elegir un modelo más pequeño. Un modelo pequeño puede ser más rápido, sí, pero quizá no tenga la calidad mínima. Un modelo grande puede ser aceptable si usa buen batching, buena caché y cuantización adecuada. La pregunta no es «pequeño o grande», sino «qué combinación cumple calidad, latencia, memoria y coste».

Tampoco es medir una única petición. Si pruebas un prompt aislado en local, quizá veas 80 tokens/s. En producción, con varias peticiones simultáneas, contexto largo y respuestas de distinta longitud, la historia cambia. Importan la cola, los percentiles, el tamaño de lote, el tiempo hasta primer token y el comportamiento cuando el sistema se llena.

Y optimizar no es perseguir el número más alto de tokens por segundo. A veces un sistema con menos throughput bruto da mejor experiencia porque entrega antes el primer token. O porque no se cae cuando llegan peticiones largas. O porque mantiene calidad tras cuantizar.

El bucle real: prefill y decode

Cuando escribes una petición a un LLM, desde fuera parece una sola acción: envías texto y el modelo responde. Por dentro no ocurre así. La inferencia tiene dos momentos con personalidad muy distinta.

Primero está el prefill. El modelo lee todo lo que ya existe: instrucciones del sistema, conversación previa, documentos recuperados, pregunta del usuario y cualquier otro token de contexto. En esta fase todavía no está «escribiendo» la respuesta. Está construyendo una representación interna de ese contexto y llenando la caché que usará después. Si el prompt es largo, el prefill pesa mucho. Si metes veinte páginas de documentación en contexto, el coste no aparece solo al final: aparece aquí.

Después viene el decode. Ahora el modelo ya ha leído el contexto y empieza a generar. Pero un LLM autoregresivo genera de forma secuencial: produce un token, lo añade al contexto, usa ese nuevo contexto para producir el siguiente, y así sucesivamente. Por eso generar 300 tokens no es como calcular una tabla de 300 celdas independientes; es una cadena donde cada eslabón depende del anterior.

Una forma humana de verlo: el prefill es leer el enunciado completo antes de contestar; el decode es dictar la respuesta palabra a palabra. Leer mucho puede retrasar el arranque. Dictar mucho puede alargar el final.

También hay una diferencia técnica importante: el prefill suele aprovechar mejor el paralelismo porque procesa muchos tokens de entrada juntos; el decode tiene menos margen, porque el token $t+1$ depende de haber generado antes el token $t$ . Por eso algunas mejoras optimizan el arranque de la respuesta y otras optimizan la velocidad de escritura. Si mezclamos ambas fases en una sola métrica, dejamos de ver dónde duele de verdad.

Fase	Qué hace	Qué suele limitar
Prefill	Procesa todos los tokens de entrada y construye la KV cache.	Cómputo y longitud del contexto.
Decode	Genera tokens nuevos uno a uno usando la KV cache.	Memoria, ancho de banda y planificación.

Esta separación explica por qué dos usuarios pueden sentir experiencias muy distintas con el mismo modelo. Un usuario con un prompt corto y una respuesta larga puede ver el primer token pronto, pero esperar bastante hasta el final. Otro usuario con un prompt enorme puede esperar mucho al principio aunque luego la respuesta salga a buen ritmo.

Piénsalo con situaciones concretas. En una asesoría, alguien pega un contrato de treinta páginas y pregunta «¿qué cláusulas debo revisar primero?». Ahí el prefill manda: el sistema tiene que leer mucho antes de empezar. En una app de escritura, alguien pide «redáctame una propuesta completa de dos páginas». El contexto puede ser corto, pero el decode pesa: hay que producir muchos tokens seguidos. En un panel de soporte, veinte personas preguntan cosas parecidas con las mismas instrucciones del sistema. Ahí no basta con un modelo rápido; importa reutilizar prefijos, organizar lotes y no desperdiciar KV cache.

Si el usuario manda una entrada de $n_{\text{entrada}}$ tokens y queremos generar $n_{\text{salida}}$ tokens, conviene separar lectura de contexto y generación.

Ejemplo de fórmula. Como calculadora de primer orden, no como benchmark universal, podemos escribir:

T_{\text{total}} \approx T_{\text{prefill}} + n_{\text{salida}} \cdot T_{\text{decode}}

Símbolo	Significado	Ejemplo
$T_{\text{total}}$	Tiempo total de respuesta.	7,5 segundos.
$T_{\text{prefill}}$	Tiempo de procesar el contexto inicial.	0,85 segundos.
$n_{\text{salida}}$	Tokens generados.	300 tokens.
$T_{\text{decode}}$	Tiempo medio por token generado.	0,022 segundos/token.

En producto solemos mirar dos métricas porque responden a preguntas distintas. La primera mide cuándo empieza la sensación de respuesta; la segunda mide cuánto tarda en completarse.

Métrica	Pregunta que responde
TTFT (time to first token)	¿Cuánto tarda el usuario en ver que algo empieza?
Tokens/s	¿A qué velocidad se completa la respuesta una vez empieza?

Con tokens por segundo, la misma idea se escribe así:

T_{\text{total}} \approx \frac{\operatorname{TTFT}_{ms}}{1000} + \frac{n_{\text{salida}}}{\operatorname{tokens/s}}

Ejemplo:

T_{\text{total}} \approx 0{,}85 + \frac{300}{45} \approx 7{,}52 \text{ s}

Esto explica una sensación habitual: el sistema puede «empezar rápido» pero terminar lento, o empezar lento pero luego escribir deprisa. Ambas cosas importan.

La memoria invisible: KV cache

En los capítulos de atención vimos $Q$ , $K$ y $V$ . Durante inferencia, las claves y valores del contexto pasado se vuelven especialmente importantes. Si el modelo ya procesó los primeros 4096 tokens, no queremos recalcularlos enteros cada vez que genera un token nuevo. Sería como releer todo el libro antes de escribir cada palabra de un resumen.

La solución es guardar parte de ese trabajo en una KV cache. Esa caché permite que el decode consulte el pasado sin recomputarlo desde cero. A cambio, consume memoria. Y esa memoria crece con cuatro cosas que suelen crecer justo cuando el producto tiene éxito: más usuarios simultáneos, más contexto, más capas y más cabezas de clave/valor.

Alyona Vert lo explica con una imagen muy clara: durante generación autoregresiva, las claves y valores de tokens anteriores se guardan para que el modelo no tenga que recalcular todo el pasado en cada nuevo token.⁹ Esa lectura no sustituye los papers de inferencia, pero ayuda a que la intuición técnica aterrice.

Ejemplo de fórmula. Una aproximación de memoria para KV cache es:

M_{\text{KV}} \approx 2 \cdot L \cdot B \cdot S \cdot H_{\text{KV}} \cdot d_h \cdot \operatorname{bytes}

El factor 2 aparece porque guardamos claves y valores. $L$ son capas, $B$ es batch o conversaciones simultáneas, $S$ es longitud de contexto, $H_{\text{KV}}$ son cabezas de clave/valor, $d_h$ es dimensión por cabeza y bytes depende de la precisión usada. Esta aproximación ayuda a detectar órdenes de magnitud; el consumo real depende del runtime, paginación de caché, fragmentación, buffers, activaciones, paralelismo y margen operativo.

Símbolo	Significado	Ejemplo
$2$	Guardamos claves y valores.	$K$ y $V$ .
$L$	Número de capas.	32 capas.
$B$	Batch o peticiones activas.	8 peticiones.
$S$	Tokens de contexto mantenidos.	4096 tokens.
$H_{\text{KV}}$	Cabezas de clave/valor.	32 en MHA, 8 en GQA, 1 en MQA.
$d_h$	Dimensión por cabeza.	128.
$\operatorname{bytes}$	Bytes por valor.	2 para FP16/BF16.

Con $L=32$ , $B=8$ , $S=4096$ , $d_h=128$ y 2 bytes por valor, el mismo modelo puede tener memorias de caché muy distintas según cómo organice sus cabezas $K/V$ :

Atención	$H_{\text{KV}}$	KV cache aproximada
Multi-head attention	32	17,18 GB
Grouped-query attention	8	4,29 GB
Multi-query attention	1	0,54 GB

Aquí aparece una lección importante: dos modelos con los mismos parámetros pueden tener costes de inferencia distintos si gestionan de forma distinta $K$ y $V$ . Por eso GQA o MQA no son detalles académicos: afectan directamente a cuántas conversaciones caben a la vez.

Otro ejemplo sencillo: imagina un asistente de una universidad que responde dudas de matrícula. El modelo cabe en memoria cuando lo prueba una persona. Pero el primer lunes de septiembre entran cien estudiantes con conversaciones largas, documentos de normativa y respuestas a medio generar. Lo que antes era «el modelo cabe» se convierte en «el modelo más la caché de todas las conversaciones no cabe». La KV cache es ese coste que no se ve en la ficha del modelo, pero aparece justo cuando el sistema empieza a usarse de verdad.

Qué acelera de verdad

La inferencia no tiene un único cuello de botella. A veces el problema es que la atención mueve demasiados datos entre memorias. A veces la caché KV está fragmentada o ocupa demasiado. A veces la GPU está medio vacía porque las peticiones llegan en tamaños raros. A veces el decode es lento porque cada token depende del anterior. Y a veces el modelo simplemente no cabe.

Por eso las técnicas de optimización no son intercambiables. Cada una toca una parte distinta del sistema. Antes de elegir una, conviene preguntar: ¿mi problema está en leer el contexto, en generar tokens, en servir muchos usuarios, en memoria, en coste o en calidad?

Técnica	Qué mejora	Intuición
FlashAttention	Atención más rápida y con menos memoria intermedia.	No cambia la fórmula; cambia cómo se mueven los datos.
PagedAttention	Gestión de KV cache con menos desperdicio.	Trata la caché como páginas, no como bloques rígidos enormes.
Continuous batching	Throughput con muchas peticiones.	Entra y sale gente del lote sin esperar a que todas las respuestas terminen.
Prefix caching	Peticiones con prefijos repetidos.	Si muchas consultas comparten sistema o contexto, no recalculas todo.
Speculative decoding	Menos tiempo por tokens generados.	Un modelo pequeño propone; el grande verifica.
Cuantización	Memoria y a veces velocidad.	Menos bits por peso o activación.
GQA/MQA	Memoria de KV cache.	Menos cabezas $K/V$ compartidas entre cabezas de consulta.
Distilación	Tamaño y coste.	Un estudiante más pequeño imita una parte útil del profesor.

Si el cuello está en el prefill, suelen importar kernels de atención, longitud de contexto, chunked prefill y reutilización de prefijos. Si el cuello está en el decode, suelen importar KV cache, speculative decoding, batching y ancho de banda de memoria. Si el cuello está en coste o despliegue, entran cuantización, destilación, edge y elección de hardware.

No todas se suman limpiamente. Una técnica puede mejorar throughput y empeorar TTFT. Otra puede funcionar bien en una GPU y no tener soporte real en otra. Por eso el estado del arte no se adopta leyendo una lista: se adopta midiendo tu caso.

En una empresa pequeña, por ejemplo, puede parecer natural pasar de una API a un modelo local para ahorrar. Si cada consulta usa un prompt enorme con políticas internas, quizá el ahorro se pierde porque el prefill consume mucho. Si las consultas comparten el mismo contexto base, prefix caching puede cambiar la película. Si el problema es que cada respuesta debe ser larga, speculative decoding puede ayudar más que seguir recortando bits. La técnica correcta depende de dónde está el dolor.

Edge AI: cuando el modelo vive cerca

Edge AI significa ejecutar el modelo cerca del usuario, del sensor o del dispositivo: portátil, móvil, mini PC, servidor local, navegador, fábrica, aula o consulta. No siempre es mejor. Es una decisión de producto e infraestructura.

La pregunta no es «¿puedo correrlo local?», sino «¿qué gano al correrlo local y qué pierdo?». A veces ganas privacidad y respuesta sin red. A veces pierdes calidad, facilidad de actualización o estabilidad térmica. La tabla ayuda a separar motivos razonables de entusiasmo tecnológico.

Motivo	Por qué puede interesar
Offline	El sistema sigue funcionando sin red.
Latencia local	Evitas ida y vuelta a un servidor lejano.
Control de datos	Algunos datos no salen del dispositivo o de la red local.
Coste marginal	Muchas inferencias locales pueden salir más baratas que llamadas remotas.
Personalización	El sistema puede adaptarse al entorno concreto.

Pero edge también trae límites:

Límite	Qué implica
Memoria	El modelo debe caber junto con KV cache y aplicación.
Energía	Un portátil o móvil no puede sostener carga alta indefinidamente.
Temperatura	El rendimiento puede bajar si el dispositivo se calienta.
Runtimes	No todos los formatos corren igual en CPU, GPU, NPU o Apple Silicon.
Mantenimiento	Actualizar modelos locales puede ser más complejo que cambiar una API.

Una NPU no convierte cualquier modelo en viable. Una GPU no siempre gana. Una CPU moderna con un modelo cuantizado puede ser suficiente para una tarea pequeña. La pregunta buena es: ¿qué calidad necesito, con qué latencia, para cuántos usuarios, durante cuánto tiempo y con qué presupuesto térmico?

Un caso cercano: el asistente de almacén

Imagina una empresa con un almacén grande. Quiere un asistente que lea incidencias de pedidos y proponga la siguiente acción: reponer, avisar, revisar lote, generar etiqueta o pedir foto.

Hay tres diseños posibles:

Diseño	Ventaja	Coste
API externa potente	Calidad alta y mantenimiento simple.	Depende de red y coste por uso.
Servidor local con GPU	Control y buen rendimiento para muchos puestos.	Compra, operación y monitorización.
Modelo cuantizado en cada terminal	Funciona incluso con mala red.	Menor calidad y límites de memoria/temperatura.

No hay una respuesta universal. Si el almacén necesita funcionar sin conexión, edge pesa mucho. Si la tarea cambia cada semana y necesita consultar políticas vivas, RAG y servidor central pueden ser más naturales. Si hay muchas peticiones simultáneas, la clave quizá no sea el modelo, sino batching, KV cache y colas.

Ahora bajémoslo un poco más. Si cada terminal manda una foto convertida a descripción, el número de tokens de entrada puede ser pequeño y el decode de la acción recomendada domina poco. Un modelo local pequeño puede bastar. Si cada incidencia arrastra historial de cliente, condiciones de entrega, normativa interna y correos anteriores, el prefill se vuelve caro y conviene pensar en servidor, caché de prefijos y recuperación selectiva. Si el turno de mañana genera cientos de incidencias a la vez, el problema ya no es «qué modelo responde mejor», sino cómo se ordenan las peticiones para que ninguna persona espere demasiado.

El mapa operativo del capítulo

Este mapa separa el ciclo de inferencia en dos fases. Prefill paga la lectura del contexto; decode paga la generación secuencial. La KV cache une ambas y convierte memoria en una decisión de producto.

flowchart TD
    ENTRADA["Entrada del usuario<br/>tokens de contexto"]
    PREFILL["Prefill<br/>procesar contexto"]
    KVCACHE["KV cache<br/>memoria del pasado"]
    DECODE["Decode<br/>generar token a token"]
    SALIDA["Respuesta<br/>tokens generados"]
    OPTMEM["Optimizar memoria<br/>paged attention · GQA · cuantización"]
    OPTTIME["Optimizar tiempo<br/>FlashAttention · batching · especulativa"]
    EDGE["Edge AI<br/>CPU · GPU · NPU · memoria local"]
    EVAL["Evaluar<br/>TTFT · tokens/s · p95 · calidad"]

    ENTRADA --> PREFILL
    PREFILL --> KVCACHE
    KVCACHE --> DECODE
    DECODE --> SALIDA
    OPTMEM --> KVCACHE
    OPTTIME --> PREFILL
    OPTTIME --> DECODE
    EDGE --> OPTMEM
    EDGE --> EVAL
    SALIDA --> EVAL
    EVAL -->|"si no cumple"| OPTMEM
    EVAL -->|"si no cumple"| OPTTIME

    style ENTRADA fill:#F5F5F5,stroke:#000000,stroke-width:2
    style PREFILL fill:#F5F5F5,stroke:#000000,stroke-width:2
    style KVCACHE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DECODE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SALIDA fill:#F5F5F5,stroke:#000000,stroke-width:2
    style OPTMEM fill:#F5F5F5,stroke:#000000,stroke-width:2
    style OPTTIME fill:#F5F5F5,stroke:#000000,stroke-width:2
    style EDGE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style EVAL fill:#F5F5F5,stroke:#000000,stroke-width:2

En el día a día

En una aplicación de soporte. El usuario no mide tu media. Siente la espera. Si el primer token tarda cinco segundos, la experiencia parece rota aunque luego escriba rápido. TTFT importa tanto como tokens/s.

En un dashboard interno. Muchas personas lanzan consultas parecidas por la mañana. Prefix caching y batching pueden valer más que cambiar de modelo, porque el cuello está en repetir contexto y servir picos.

En un producto local. Un modelo GGUF de 4 bits puede ser perfecto para resumir notas privadas en un portátil, pero quizá no sirva para razonamiento largo. La decisión no es ideológica; es medición.

En una demo ejecutiva. Una sola petición luce bien. Lo profesional es enseñar también qué pasa con 20 peticiones, contexto largo y una respuesta de 500 tokens. Ahí aparece la verdad del sistema.

Por qué debería importarte

Porque la arquitectura se vuelve coste. El número de capas, la longitud de contexto, el tipo de atención, los bits de precisión, la KV cache y el runtime acaban convertidos en euros, segundos, vatios y temperatura.

También porque la optimización sin evaluación puede engañar. Si cuantizas y el modelo responde más rápido pero falla justo en los casos delicados, no has optimizado: has movido el problema. Si subes batch y mejora throughput pero empeora p95, quizá has hecho feliz al benchmark y triste al usuario.

Dónde volverá a aparecer

Este capítulo no termina aquí. La inferencia es una bisagra: une arquitectura, herramientas, operación, evaluación y experiencia de usuario. Por eso varios conceptos vuelven más adelante con otro nivel de detalle.

Concepto de este capítulo	Dónde vuelve en el libro	Por qué se conecta
KV cache	Facsímil 6.	Operar modelos exige mirar memoria, concurrencia, colas y límites reales.
Cuantización	Facsímil 4; facsímil 6.	Modelos locales, despliegue y coste dependen de formatos y runtimes.
Speculative decoding y batching	Facsímil 6.	Son decisiones de serving, no solo de arquitectura.
Edge AI	Facsímil 4; facsímil 11.	Herramientas locales y experiencia de usuario dependen de dónde vive el modelo.
Benchmarks y percentiles	Facsímil 7.	Evaluar un sistema de IA exige medir calidad y rendimiento juntos.

Dónde solía tropezar yo

Estos son los tropiezos que más distorsionan decisiones reales. Casi todos tienen la misma raíz: mirar una métrica aislada y olvidarse del sistema completo.

Error	Por qué es un error	Antídoto
Mirar solo parámetros	Dos modelos de 7B pueden tener inferencias muy distintas por contexto, GQA, runtime y cuantización.	Mide pesos, KV cache, TTFT y tokens/s.
Confundir tokens/s con buena experiencia	El usuario nota mucho el primer token y los percentiles altos.	Mide TTFT, latencia total y p95/p99.
Cuantizar sin comparar calidad	Menos bits pueden romper justo los casos que importan.	Crea una evaluación antes y después.
Olvidar la KV cache	El modelo cabe, pero las conversaciones simultáneas no.	Calcula memoria de pesos y memoria de KV cache.
Creer que edge siempre es mejor	Local puede ser lento, caliente o difícil de actualizar.	Decide por caso: offline, datos, coste, latencia y mantenimiento.

Manos a la obra

La práctica real está en kit descargable. El kit calcula memoria de pesos, KV cache y latencia aproximada con varios usuarios. No es un benchmark; es una calculadora de ingeniería para no prometer serving sin números.

Archivo	Qué contiene
`data/serving_scenario.json`	Parámetros, bits, capas, batch, contexto, heads y throughput.
`contracts/serving_policy.json`	Umbrales de memoria y degradación de latencia.
`ops/estimate_serving_budget.py`	Calculadora de pesos, KV cache y latencia.
`output/serving_budget_report.json`	Resultados estructurados.
`output/serving_budget_decision.md`	Informe legible.

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/estimate_serving_budget.py --write
cat output/serving_budget_decision.md

Como gate:

python3 ops/estimate_serving_budget.py --write --fail-on-invalid

Qué entregaría un alumno. El Markdown generado, una variante de batch/contexto y una decisión sobre MHA/GQA/MQA, cuantización y concurrencia.

Cómo encaja todo

Este mapa conecta inferencia con los capítulos anteriores y con la operación futura. QKV deja de ser una fórmula: se vuelve caché. Sampling deja de ser un parámetro: se vuelve experiencia de usuario. Cuantización deja de ser una tabla de bits: se vuelve memoria, calidad y coste.

La decisión que prepara el siguiente facsímil es clara: no basta con elegir modelo; hay que elegir dónde vive, cómo se sirve, qué latencia promete y cómo se mide.

graph TD
    C1["Capítulo 1<br/>LLM, contexto y escala"]
    C23["Capítulos 2-3<br/>atención, QKV y máscara"]
    C4["Capítulo 4<br/>logits y sampling"]
    C6["Capítulo 6<br/>modelos abiertos y cuantización"]
    C7["Este capítulo<br/>inferencia, edge y hardware"]
    PREFILL["Prefill<br/>leer contexto y llenar caché"]
    KVCACHE["KV cache<br/>memoria por capas, tokens y batch"]
    DECODE["Decode<br/>generar token a token"]
    OPT["Optimización<br/>kernels, batching, cache y especulación"]
    EDGE["Edge AI<br/>CPU, GPU, NPU y límites térmicos"]
    METRICAS["Métricas reales<br/>TTFT · tokens/s · p95 · calidad"]
    F4["Facsímil 4<br/>APIs, local, RAG y herramientas"]
    F6["Facsímil 6<br/>operación, colas y observabilidad"]
    F7["Facsímil 7<br/>evaluación y calibración"]
    F11["Facsímil 11<br/>producto y experiencia"]

    C1 -->|"define tamaño y contexto"| C7
    C23 -->|"produce K y V reutilizables"| KVCACHE
    C4 -->|"controla salida durante"| DECODE
    C6 -->|"condiciona memoria y runtime"| C7
    C7 -->|"empieza por"| PREFILL
    PREFILL -->|"llena"| KVCACHE
    KVCACHE -->|"alimenta"| DECODE
    DECODE -->|"se percibe como"| METRICAS
    PREFILL -->|"se mejora con"| OPT
    DECODE -->|"se mejora con"| OPT
    KVCACHE -->|"se optimiza con"| OPT
    EDGE -->|"elige dónde ejecutar"| C7
    C7 -->|"se integra en"| F4
    OPT -->|"se opera en"| F6
    METRICAS -->|"se juzgan en"| F7
    METRICAS -->|"afectan a"| F11
    F6 -->|"retroalimenta límites de"| C7

    style C7 fill:#F5F5F5,stroke:#000000,stroke-width:2
    style PREFILL fill:#F5F5F5,stroke:#000000,stroke-width:2
    style KVCACHE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DECODE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style OPT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style EDGE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style METRICAS fill:#F5F5F5,stroke:#000000,stroke-width:2
    style C1 stroke-dasharray: 5 5
    style C23 stroke-dasharray: 5 5
    style C4 stroke-dasharray: 5 5
    style C6 stroke-dasharray: 5 5
    style F4 stroke-dasharray: 5 5
    style F6 stroke-dasharray: 5 5
    style F7 stroke-dasharray: 5 5
    style F11 stroke-dasharray: 5 5

Vocabulario aprendido

Nos quedamos con las palabras que conviene tener a mano para leer documentación de runtimes, benchmarks y hardware sin perder el hilo.

Término	Definición
Inferencia	Uso de un modelo entrenado para responder a una entrada nueva.
Prefill	Fase que procesa el contexto inicial antes de generar tokens.
Decode	Fase que genera tokens de salida uno a uno.
TTFT	Tiempo hasta recibir el primer token visible.
Throughput	Trabajo procesado por unidad de tiempo, por ejemplo tokens/s.
KV cache	Caché de claves y valores de atención para reutilizar el contexto pasado.
FlashAttention	Kernel de atención que reduce movimiento de memoria.
PagedAttention	Gestión paginada de KV cache para servir muchas peticiones con menos desperdicio.
Continuous batching	Técnica para mezclar peticiones activas y mejorar uso del hardware.
Speculative decoding	Método donde un modelo pequeño propone tokens y el grande los verifica.
Cuantización	Reducir precisión numérica para ahorrar memoria y, a veces, ganar velocidad.
Edge AI	Ejecutar modelos cerca del usuario o dispositivo.
NPU	Acelerador especializado para redes neuronales.

Antes de pasar página

¿Puedo explicar la diferencia entre prefill y decode? (Si no, vuelve a «El bucle real».)
¿Entiendo por qué la KV cache puede ocupar varios GB? (Si no, vuelve a «La memoria invisible».)
¿Sé distinguir TTFT, tokens/s y throughput? (Si no, vuelve a «El bucle real».)
¿Puedo explicar por qué GQA reduce memoria de inferencia? (Si no, vuelve a la tabla de KV cache.)
¿Sé por qué cuantizar no basta sin medir calidad? (Si no, vuelve a «Dónde solía tropezar yo».)
¿Puedo decidir cuándo edge AI tiene sentido? (Si no, vuelve a «Edge AI».)
¿He ejecutado el código y cambiado batch, secuencia y usuarios? (Si no, vuelve a «Manos a la obra».)

En resumen

La versión corta del capítulo no es una lista de herramientas: es una forma de pensar. Primero entiende qué fase estás pagando, después mide y solo entonces optimiza.

Idea fuerza	Detalle
Inferir no es una llamada simple.	Hay prefill, decode, KV cache, scheduler, kernels y hardware.
La memoria no son solo pesos.	La KV cache puede dominar cuando hay contexto largo y usuarios simultáneos.
Optimizar es medir compromisos.	TTFT, tokens/s, p95, calidad, coste y temperatura cuentan juntos.
Edge AI es una decisión de producto.	Sirve cuando offline, datos, latencia o coste local compensan sus límites.
El estado del arte tiene fecha.	A 10 de junio de 2026, las prácticas cambian rápido; el mecanismo importa más que la marca concreta.

Para saber más

Ainslie, J. et al. (2023). GQA: Training generalized multi-query Transformer models from multi-head checkpoints. Proceedings of EMNLP. https://arxiv.org/abs/2305.13245

Dao, T., Fu, D. Y., Ermon, S., Rudra, A. y Ré, C. (2022). FlashAttention: Fast and memory-efficient exact attention with IO-awareness. Advances in Neural Information Processing Systems 35. https://arxiv.org/abs/2205.14135

Dettmers, T., Lewis, M., Belkada, Y. y Zettlemoyer, L. (2022). LLM.int8(): 8-bit matrix multiplication for Transformers at scale. Advances in Neural Information Processing Systems 35. https://arxiv.org/abs/2208.07339

Frantar, E., Ashkboos, S., Hoefler, T. y Alistarh, D. (2022). GPTQ: Accurate post-training quantization for generative pre-trained Transformers. https://arxiv.org/abs/2210.17323

ggml-org. (2026). llama.cpp: LLM inference in C/C++. Consultado el 10 de junio de 2026. https://github.com/ggml-org/llama.cpp

Kwon, W. et al. (2023). Efficient memory management for large language model serving with PagedAttention. Proceedings of SOSP. https://arxiv.org/abs/2309.06180

Leviathan, Y., Kalman, M. y Matias, Y. (2023). Fast inference from Transformers via speculative decoding. Proceedings of ICML. https://arxiv.org/abs/2211.17192

Lin, J. et al. (2024). AWQ: Activation-aware weight quantization for LLM compression and acceleration. Proceedings of Machine Learning and Systems. https://arxiv.org/abs/2306.00978

MLCommons. (2026). MLPerf Inference: Datacenter benchmark. Consultado el 10 de junio de 2026. https://mlcommons.org/benchmarks/inference-datacenter/

NVIDIA. (2026). TensorRT-LLM documentation. Consultado el 10 de junio de 2026. https://docs.nvidia.com/tensorrt-llm/index.html

vLLM Project. (2026). vLLM documentation. Consultado el 10 de junio de 2026. https://docs.vllm.ai/en/stable/

Vert, A. (2026, 13 de mayo). AI 101: Your Ultimate Guide to Attention: Mechanism, QKV, and KV Cache. Turing Post. https://www.turingpost.com/p/your-ultimate-guide-to-attention-mechanism-qkv-and-kv-cache

Xiao, G. et al. (2023). SmoothQuant: Accurate and efficient post-training quantization for large language models. Proceedings of ICML. https://arxiv.org/abs/2211.10438

Notas

Dao, T., Fu, D. Y., Ermon, S., Rudra, A. y Ré, C. (2022). FlashAttention: Fast and memory-efficient exact attention with IO-awareness. Advances in Neural Information Processing Systems 35. https://arxiv.org/abs/2205.14135. La idea central es optimizar lecturas y escrituras entre memorias rápidas y lentas, no cambiar la matemática de la atención. ↩
Kwon, W. et al. (2023). Efficient memory management for large language model serving with PagedAttention. Proceedings of SOSP. https://arxiv.org/abs/2309.06180. vLLM se construye sobre esta idea para gestionar KV cache con menos memoria desperdiciada. ↩
vLLM Project. (2026). vLLM documentation. https://docs.vllm.ai/en/stable/. Consultado el 10 de junio de 2026. La documentación lista serving online/offline, prefix caching, speculative decoding, cuantización y métricas de producción. ↩
Leviathan, Y., Kalman, M. y Matias, Y. (2023). Fast inference from Transformers via speculative decoding. Proceedings of ICML. https://arxiv.org/abs/2211.17192. El método aprovecha un modelo auxiliar para proponer varios tokens y verificar en paralelo con el modelo principal. ↩
Ainslie, J. et al. (2023). GQA: Training generalized multi-query Transformer models from multi-head checkpoints. Proceedings of EMNLP. https://arxiv.org/abs/2305.13245. GQA ocupa un punto intermedio entre multi-head attention y multi-query attention. ↩
Dettmers, T., Lewis, M., Belkada, Y. y Zettlemoyer, L. (2022). LLM.int8(): 8-bit matrix multiplication for Transformers at scale. Advances in Neural Information Processing Systems 35. https://arxiv.org/abs/2208.07339. El trabajo muestra una ruta para inferencia 8-bit en modelos grandes cuidando valores atípicos. ↩
ggml-org. (2026). llama.cpp: LLM inference in C/C++. https://github.com/ggml-org/llama.cpp. Consultado el 10 de junio de 2026. El proyecto documenta GGUF, cuantización, servidor compatible con OpenAI y herramientas de conversión. ↩
MLCommons. (2026). MLPerf Inference: Datacenter benchmark. https://mlcommons.org/benchmarks/inference-datacenter/. Consultado el 10 de junio de 2026. MLPerf publica resultados, divisiones, categorías de disponibilidad y metadatos de sistemas completos. ↩
Vert, A. (2026, 13 de mayo). AI 101: Your Ultimate Guide to Attention: Mechanism, QKV, and KV Cache. Turing Post. https://www.turingpost.com/p/your-ultimate-guide-to-attention-mechanism-qkv-and-kv-cache. Consultado el 10 de junio de 2026. ↩

Capítulo 08

Facsímil 3 · Arquitecturas y modelos

Capítulo 08: Lo que deberías saber: arquitecturas y modelos

Entrando en el tema

Este facsímil empezó con una pregunta que parece sencilla: ¿qué hay dentro de un LLM? La respuesta no era “un chat”, ni “una API”, ni “un modelo grande”. Era una cadena de decisiones técnicas: tokens, embeddings, tensores, atención, MLP, normalización, logits, sampling, adaptación, memoria, inferencia y hardware.

Este capítulo es una revisión activa. No pretende que memorices nombres. Pretende que puedas mirar una ficha de modelo, una demo de producto o una discusión sobre hardware y preguntar con calma: qué arquitectura hay debajo, qué coste tiene usarla, qué se adaptó, qué se cuantizó, qué se está midiendo y qué parte pertenece al modelo o al sistema que lo sirve.

No es el final de la historia. Es el punto donde dejamos de hablar de modelos como cajas negras y empezamos a hablar de sistemas con piezas.

1. Qué es un LLM: modelo, parámetros y escala

Un LLM es un modelo entrenado para predecir tokens a partir de contexto. No guarda frases como una biblioteca. Ajusta parámetros para transformar una secuencia de entrada en una distribución de probabilidad sobre el siguiente token.¹

La idea que debes conservar es esta: los parámetros son memoria aprendida, el contexto es memoria temporal y la salida es una distribución. Si mezclas esas tres cosas, empiezan los malentendidos.

Caso cercano: una persona pega una política interna y pregunta “¿puedo aprobar este gasto?”. El modelo no “abre una carpeta” donde está la política. Procesa el texto pegado, lo mezcla con lo aprendido durante entrenamiento y produce una respuesta probable. Si falta un dato, puede sonar seguro igualmente. Por eso el contexto y la verificación no son decoración.

Vuelve al capítulo 01 si no puedes explicar la diferencia entre parámetros, contexto, token, embedding y salida.

2. Transformer: de texto a tensores y atención

El Transformer convirtió texto en operaciones paralelizables sobre tensores.² El texto se tokeniza, cada token busca su vector, se añade posición y el bloque Transformer transforma esas representaciones capa tras capa.

La intuición importante: el modelo no lee palabras como las leemos nosotros. Trabaja con matrices. Cada capa reescribe la representación de cada posición usando información de otras posiciones.

Caso cercano: cuando escribes “el banco cerró la cuenta”, el token “banco” cambia de significado según “cuenta”. No basta con un diccionario. La atención permite que las posiciones se miren entre sí para construir significado contextual.

Vuelve al capítulo 02 si no puedes dibujar el camino mínimo: texto → tokens → ids → embeddings → bloques Transformer → logits.

3. Q, K, V, máscara causal y softmax

La atención no es una metáfora bonita: es una operación concreta. Cada posición produce consultas $Q$ , claves $K$ y valores $V$ . Las consultas se comparan con claves, se normalizan con softmax y se usan para mezclar valores.

La forma mínima de la atención escalada es:

\operatorname{Attention}(Q,K,V)=\operatorname{softmax}\left(\frac{QK^\top}{\sqrt{d_k}}\right)V

Símbolo	Qué significa	Imagen mental
$Q$	Qué busca una posición.	“Necesito saber a qué se refiere esto”.
$K$	Qué ofrece cada posición para ser encontrada.	“Tengo información relevante para cierto tipo de pregunta”.
$V$	Qué contenido se mezcla si una posición importa.	“Esto es lo que aporto a la respuesta”.
$d_k$	Dimensión de las claves.	Escala para que softmax no se vuelva extremo demasiado pronto.

La máscara causal impide que una posición mire tokens futuros durante generación. Sin ella, entrenaríamos un modelo que ve la respuesta antes de producirla.

Caso cercano: en una frase como “Marta dejó el portátil en la mesa porque estaba cansada”, la atención ayuda a decidir si “estaba cansada” apunta a Marta o al portátil. No hay una regla universal simple: depende del contexto aprendido y de cómo cada cabeza atiende.

Vuelve al capítulo 03 si no puedes explicar por qué softmax convierte puntuaciones en pesos que suman 1.

4. MLP, residual, LayerNorm, logits y sampling

La atención mezcla información entre posiciones. El MLP transforma cada posición por dentro. La conexión residual mantiene una vía de continuidad. LayerNorm estabiliza escalas. Los logits convierten el último vector en candidatos de token. Sampling decide qué token sale.

El modelo no “elige una palabra” directamente. Produce logits, los pasa por softmax y obtiene una distribución:

p_i=\frac{e^{z_i/T}}{\sum_j e^{z_j/T}}

Símbolo	Qué significa	Qué controla
$z_i$	Logit del token candidato $i$ .	Preferencia bruta antes de normalizar.
$T$	Temperatura.	Cuánto se abre o cierra el abanico de opciones.
$p_i$	Probabilidad final del token $i$ .	Opción que puede muestrearse.

Caso cercano: si un asistente escribe un email formal, temperatura baja puede mantener tono estable. Si le pides diez nombres creativos para un proyecto, una temperatura algo mayor puede abrir opciones. En ambos casos, el modelo no cambia de personalidad: cambia cómo se muestrea la distribución.

Vuelve al capítulo 04 si no puedes explicar la diferencia entre logit, probabilidad, temperatura, top-k y top-p.

5. Arquitecturas modernas: familias, MoE, razonamiento y multimodalidad

El Transformer base no es el único diseño posible. Hay modelos encoder-only, decoder-only, encoder-decoder, MoE, multimodales, híbridos con recuperación, modelos de razonamiento con más cómputo en inferencia y arquitecturas pensadas para contexto largo. BERT popularizó encoder-only para comprensión.³ T5 mostró la potencia de formular muchas tareas como texto-a-texto.⁴

La idea importante no es coleccionar siglas. Es entender qué compromiso cambia cada familia: memoria, velocidad, calidad, entrenabilidad, multimodalidad, coste de servir y facilidad de adaptación.

MoE añade expertos y un router: no se activa todo el modelo para cada token. Esa idea permite aumentar capacidad manteniendo coste activo menor, aunque complica entrenamiento, balanceo y serving.⁵

Caso cercano: una plataforma que atiende dudas legales, técnicas y administrativas puede beneficiarse de rutas internas distintas. Pero si el router se equivoca, no basta con tener “muchos expertos”: hay que medir qué experto se activa, cuándo y con qué resultado.

Vuelve al capítulo 05 si no puedes explicar qué gana y qué complica un modelo MoE.

6. Transfer learning, destilación y modelos abiertos

La mayoría de proyectos no entrena desde cero. Parte de un modelo base, lo adapta o lo rodea de herramientas. Fine-tuning cambia pesos. LoRA entrena matrices pequeñas sobre pesos congelados.⁶ QLoRA permite adaptar con menos memoria combinando cuantización y LoRA.⁷

La pregunta práctica es: ¿quiero cambiar comportamiento, aportar conocimiento, reducir coste o controlar despliegue? Cada objetivo apunta a una técnica distinta.

Caso cercano: una academia quiere que un modelo corrija entregas con una rúbrica concreta. Si el modelo ya entiende el tema pero no sigue bien el formato, quizá bastan ejemplos y validación. Si necesita tono y criterios muy específicos, LoRA puede tener sentido. Si falta información cambiante, RAG será mejor que ajustar pesos.

Vuelve al capítulo 06 si no puedes distinguir fine-tuning, LoRA, QLoRA, destilación, cuantización y modelo abierto.

7. Inferencia optimizada, edge AI y hardware

Un modelo no se usa en abstracto. Se sirve. Y servirlo significa gestionar memoria, colas, caché, kernels, precisión, batch, latencia y coste. El capítulo anterior separó prefill y decode, que es una de las divisiones más útiles para pensar rendimiento.

Ejemplo de fórmula. Una aproximación sencilla de latencia, útil para discutir producto antes de medir con un runtime real, es:

T_{\text{total}} \approx T_{\text{prefill}} + n_{\text{salida}}\cdot T_{\text{decode}}

Pieza	Qué pregunta responde	Por qué importa
$T_{\text{prefill}}$	¿Cuánto tarda en leer el contexto?	Contextos largos retrasan el primer token.
$n_{\text{salida}}$	¿Cuánto texto generará?	Respuestas largas encarecen decode.
$T_{\text{decode}}$	¿Cuánto cuesta cada token nuevo?	Generar es secuencial y depende de KV cache.

La KV cache puede ocupar varios GB con usuarios simultáneos. FlashAttention reduce movimiento de memoria en atención.⁸ PagedAttention organiza mejor esa caché en serving.⁹ GQA reduce memoria de claves y valores.¹⁰

Caso cercano: si tu asistente legal recibe contratos largos y genera respuestas cortas, el cuello puede estar en prefill. Si tu herramienta redacta informes largos desde un prompt breve, el cuello puede estar en decode. Si veinte personas lo usan a la vez, quizá el problema no es el modelo, sino la KV cache y el scheduler.

Vuelve al capítulo 07 si no puedes explicar TTFT, tokens/s, KV cache y por qué un modelo que cabe solo puede no caber con varios usuarios.

Diseccionando un LLM: de una petición al siguiente token

Hasta ahora hemos repasado el facsímil capítulo a capítulo. Ahora hagamos lo que más se usa en la vida real: seguir una petición completa. No como dibujo bonito, sino como herramienta de depuración. Cuando una respuesta sale lenta, cara, repetitiva, truncada o falsa, necesitas saber en qué capa mirar.

La inspiración visual de esta sección viene de explicaciones interactivas como The Anatomy of an LLM, de Roy van Rijn, que recorre tokenización, embeddings, atención, logits, sampling, post-training, KV cache y cuantización en una cadena visual.¹¹ Aquí lo rehacemos con la mirada del libro: qué cambia, qué medimos y qué decisión tomaría un equipo.

La escena: una llamada que parece sencilla

Imagina una aplicación de soporte interno. El usuario pregunta:

Un alumno pide ampliar el plazo de entrega porque ha tenido una incidencia técnica documentada.
¿Qué categoría, riesgo y siguiente acción recomiendas?

La aplicación no manda solo esa frase. Normalmente ensambla una petición con varias capas:

Capa de entrada	Ejemplo	Por qué importa
Instrucción de sistema	“Responde solo con JSON válido y cita la política usada.”	Define el contrato de comportamiento.
Documentos	Políticas internas sobre ampliaciones e incidencias.	Aportan conocimiento vivo que no debería inventarse.
Mensaje de usuario	La consulta concreta.	Es la tarea que cambia en cada llamada.
Contrato de salida	Campos `categoria`, `riesgo`, `accion_recomendada`, `fuente`.	Permite validar automáticamente.
Parámetros	`temperature`, `top_p`, `max_tokens`, `stop`, `seed`.	Controlan variabilidad, longitud y parada.

La primera lección práctica es esta: el prompt real no es el texto que escribe el usuario. Es el paquete completo que la aplicación construye. Si no registras ese paquete, luego no sabes qué ha visto el modelo.

Fase 1: texto, tokens e IDs

El modelo no recibe letras como tú las ves. Recibe IDs de tokens. El tokenizer parte el texto en piezas y asigna a cada pieza un número. Esa conversión afecta a coste, contexto, truncamiento y rarezas: código, acentos, números largos, JSON y nombres propios pueden partirse de formas poco intuitivas.

Lo que ve una persona	Lo que necesita el modelo	Riesgo de ingeniería
“incidencia técnica documentada”	IDs de tokens	Puede ocupar más tokens de lo esperado.
Un JSON de salida	Tokens con llaves, comillas y campos	Si el modelo añade texto extra, el parser falla.
Un documento largo	Miles de tokens	Puede desplazar instrucciones o fragmentos relevantes.
Código o logs	Subtokens raros	Puede encarecer y romper patrones.

No hay que memorizar IDs. Hay que entender que el presupuesto empieza aquí. Si el tokenizer transforma una petición en 12 000 tokens, eso condiciona latencia, coste y KV cache antes de que el modelo “piense” nada.

Fase 2: embeddings y posición

Un ID de token por sí solo no tiene geometría. El token 15339 no está cerca de 15340 por tener un número parecido. El embedding layer busca una fila en una matriz aprendida y devuelve un vector. Ese vector es el punto de partida del token dentro del modelo.

Una forma sencilla de escribirlo es:

x_i = E[t_i] + p_i

Símbolo	Qué significa	Ejemplo
$t_i$	ID del token en la posición $i$ .	ID del token `incidencia`.
$E$	Matriz de embeddings aprendida.	Una tabla de tamaño vocabulario × dimensión.
$E[t_i]$	Fila de embedding seleccionada.	Vector de 4096 números en un modelo concreto.
$p_i$	Información posicional.	RoPE u otra codificación de posición.
$x_i$	Representación inicial del token.	Vector que entra al primer bloque.

La parte importante: el embedding inicial no es el significado final. El token “plazo” empieza con una representación, pero las capas siguientes la reescriben según “entrega”, “incidencia”, “política” y “ampliación”. La semántica útil aparece al procesar contexto.

Aquí aparece un detalle que en ingeniería se nota mucho: posición no significa “pegar un número al token y olvidarse”. En modelos modernos es frecuente usar RoPE, que codifica posición rotando las representaciones de consulta y clave para que la atención capture relaciones relativas entre posiciones.¹² Una forma intuitiva de verlo es:

q_i^{\text{rot}} = R(\theta_i)q_i,\qquad k_j^{\text{rot}} = R(\theta_j)k_j

Símbolo	Qué significa	Por qué importa
$q_i$	Consulta del token en posición $i$ .	Lo que esa posición busca en el contexto.
$k_j$	Clave del token en posición $j$ .	Lo que otra posición ofrece para ser encontrada.
$R(\theta_i)$	Rotación dependiente de posición.	Mete orden sin convertir la posición en un simple contador.
$q_i^{\text{rot}}(k_j^{\text{rot}})^\top$	Comparación ya sensible a distancia relativa.	Ayuda a que “qué mira a qué” dependa también de dónde está.

Esto no convierte el contexto largo en memoria perfecta. El trabajo Lost in the Middle mostró que los modelos pueden recuperar peor información situada en zonas intermedias de contextos largos que información al principio o al final.¹³ Para una aplicación RAG esto es muy práctico: no basta con “meter más documentos”. Hay que ordenar evidencias, repetir señales críticas, chunkear con criterio y medir recuperación en la posición donde realmente cae el dato.

Fase 3: bloques Transformer

Un Transformer decoder-only repite un bloque muchas veces. Cada bloque suele tener atención, normalización, conexión residual y MLP. En lenguaje de ingeniería, cada capa toma un tensor de forma aproximada:

[batch, secuencia, d_model]

y devuelve otro tensor con la misma forma, pero con representaciones más contextualizadas.

Pieza	Qué hace	Cómo se rompe en producción
Atención causal	Permite que cada posición use tokens anteriores.	Contexto largo aumenta coste y memoria.
Q, K, V	Calculan qué busca cada token, qué ofrecen los demás y qué contenido se mezcla.	Más heads y contexto implican más trabajo.
Residual	Mantiene una vía de continuidad entre capas.	Sin ella, entrenar redes profundas sería mucho más inestable.
LayerNorm/RMSNorm	Mantiene escalas numéricas manejables.	Cambios de precisión pueden afectar estabilidad.
MLP/SwiGLU/MoE	Reescribe cada posición por dentro.	En MoE aparece routing, balanceo y coste activo.

Si un alumno se queda solo con “la atención mira palabras”, pierde la ingeniería. La atención mueve información entre posiciones; el MLP transforma la representación de cada posición; la normalización estabiliza; la residual conserva señal; y repetir esto muchas capas produce el vector final desde el que saldrán logits.

Hay tres matices que conviene dejar claros porque aparecen mucho cuando se leen implementaciones reales, model cards y artículos técnicos como la guía visual de Kato.¹⁴

1. Las cabezas de atención no son trozos mágicos del texto. Cada head aprende proyecciones distintas:

Q_h=XW_h^Q,\qquad K_h=XW_h^K,\qquad V_h=XW_h^V

Pieza	Qué cambia	Lectura de ingeniería
$X$	Representaciones actuales de los tokens.	No son palabras originales; son vectores ya reescritos por capas previas.
$W_h^Q$	Proyección de consultas para la cabeza $h$ .	Define qué tipo de relación puede buscar esa cabeza.
$W_h^K$	Proyección de claves.	Define cómo se ofrece cada posición a ser atendida.
$W_h^V$	Proyección de valores.	Define qué contenido se mezcla cuando una posición importa.

En producción esto importa porque attention_heads, kv_heads, head_dim y d_model no son números decorativos. Condicionan memoria, throughput, compatibilidad con kernels y tamaño de KV cache. GQA, por ejemplo, permite que varias cabezas de consulta compartan menos cabezas de claves y valores; por eso puede reducir memoria de KV cache sin eliminar todas las cabezas de atención.¹⁵

2. El residual stream es la autopista por la que viaja la señal. En muchos decoders modernos, una capa se parece más a esto que a un bloque lineal limpio:

x' = x + \operatorname{Attention}(\operatorname{RMSNorm}(x))

x_{\text{next}} = x' + \operatorname{MLP}(\operatorname{RMSNorm}(x'))

RMSNorm normaliza por raíz cuadrática media y prescinde del centrado de LayerNorm, lo que puede simplificar y acelerar ciertos diseños.¹⁶ La idea práctica: si cuantizas, cambias precisión o miras activaciones, no estás tocando “texto”; estás tocando el flujo numérico por el que cada capa suma pequeñas correcciones. Por eso un modelo puede degradarse de manera rara: no siempre falla todo, a veces se vuelven frágiles ciertos formatos, idiomas, longitudes o tareas.

3. El MLP no es relleno entre atenciones. En muchos modelos, el MLP usa variantes tipo SwiGLU:

\operatorname{SwiGLU}(x)=\big(\operatorname{swish}(xW_{\text{gate}})\odot xW_{\text{up}}\big)W_{\text{down}}

Parte	Qué hace	Ejemplo de intuición
$W_{\text{gate}}$	Abre o cierra rutas internas.	“Este patrón semántico sí aplica aquí”.
$W_{\text{up}}$	Expande dimensión intermedia.	Permite más capacidad de transformación.
$\odot$	Producto elemento a elemento.	Combina activación y contenido.
$W_{\text{down}}$	Devuelve al tamaño del modelo.	Reintegra la señal al residual stream.

SwiGLU y otras variantes de GLU se usan porque mejoran el bloque feed-forward frente a activaciones más simples en Transformers.¹⁷ Esta es una buena vacuna contra una frase peligrosa: “la atención lo hace todo”. No. La atención enruta información entre posiciones; el MLP transforma cada posición; y ambas piezas se alternan capa a capa.

Fase 4: logits, softmax y política de decoding

Cuando el modelo termina de procesar el contexto, todavía no ha escrito texto. Produce logits: una puntuación por token candidato del vocabulario. Después convertimos esas puntuaciones en probabilidades.

P(t_i \mid contexto)=\frac{e^{z_i/T}}{\sum_j e^{z_j/T}}

Símbolo	Qué significa	Decisión práctica
$z_i$	Logit del token candidato $i$ .	Preferencia bruta antes de normalizar.
$T$	Temperatura.	Baja para JSON estricto; más alta para ideación.
$j$	Todos los tokens candidatos considerados.	En vocabularios reales pueden ser cientos de miles.
$P(t_i \mid contexto)$	Probabilidad del token $i$ dado el contexto.	No es verdad: es probabilidad de continuación.

Después llegan filtros y penalizaciones:

Parámetro	Qué cambia	Cuándo tocarlo	Qué medir
`temperature`	Aplana o concentra la distribución.	Bajar en salidas estructuradas; subir en generación creativa.	Entropía, tasa de JSON válido, diversidad.
`top_k`	Limita a los $k$ tokens más probables.	Evitar candidatos raros sin cerrar demasiado.	Repetición, calidad, diversidad.
`top_p`	Conserva el conjunto mínimo con probabilidad acumulada $p$ .	Generación abierta con control de cola.	Degeneración, diversidad, factualidad.
`min_p`	Elimina tokens demasiado pequeños frente al máximo.	Runtimes locales donde quieres cortar ruido extremo.	Tokens extraños, estabilidad.
`logit_bias`	Empuja o bloquea tokens concretos.	Forzar o evitar vocabulario técnico, formatos o palabras prohibidas.	Cumplimiento de formato y efectos secundarios.
`max_tokens`	Limita longitud de salida.	Control de coste y truncamiento.	Respuestas cortadas, coste por tarea.
`stop`	Para al encontrar secuencias concretas.	Evitar texto extra tras JSON o secciones delimitadas.	Tasa de salida limpia.

Aquí conviene repetirlo porque evita mucho humo: los parámetros de decoding no hacen al modelo saber más. Cambian cómo se selecciona el siguiente token a partir de lo que el modelo ya ha calculado.

También puede aparecer speculative decoding. No cambia la arquitectura mental de “siguiente token”, pero sí la ingeniería de serving: un modelo pequeño o una cabeza rápida propone varios tokens candidatos y el modelo grande verifica cuáles acepta.¹⁸ Si los acepta, ganas velocidad; si no, vuelves al modelo grande. No es una técnica para mejorar calidad: es una técnica para reducir latencia manteniendo la distribución objetivo bajo ciertas condiciones.

Pieza	Qué hace	Cuándo merece la pena
Modelo draft	Propone tokens baratos.	Cuando sus propuestas suelen coincidir con el modelo grande.
Modelo target	Verifica y corrige.	Cuando no quieres cambiar la calidad del modelo principal.
Ratio de aceptación	Porcentaje de tokens draft aceptados.	Si es bajo, el mecanismo añade complejidad sin acelerar.
Métrica útil	Tokens/s y p95 de latencia.	El objetivo es rendimiento, no “razonamiento mejor”.

Fase 5: prefill, decode y KV cache

La generación tiene dos fases operativas muy distintas:

Fase	Qué ocurre	Métrica típica	Problema típico
Prefill	El modelo procesa todo el contexto inicial.	TTFT, tiempo hasta primer token.	Contextos largos, documentos pegados, RAG excesivo.
Decode	El modelo genera token a token.	tokens/s, tiempo total, coste de salida.	Respuestas largas, batch, GPU saturada.

Durante decode, el modelo no quiere recalcular todo el contexto una y otra vez. Guarda claves y valores de atención ya calculados: la KV cache. Esa caché no es “memoria del usuario” ni “recuerdo semántico”. Es memoria de cálculo para acelerar generación autoregresiva.

Ejemplo de fórmula. Para estimar orden de magnitud de KV cache:

M_{\text{KV}} \approx 2 \cdot L \cdot B \cdot S \cdot H_{\text{KV}} \cdot d_h \cdot \operatorname{bytes}

Símbolo	Qué significa	Ejemplo
$2$	Guardamos claves y valores.	K y V.
$L$	Número de capas.	32.
$B$	Batch o secuencias activas.	4 usuarios simultáneos.
$S$	Contexto reservado o usado.	4096 tokens.
$H_{\text{KV}}$	Cabezas KV.	8 si hay GQA.
$d_h$	Dimensión por cabeza.	128.
$\operatorname{bytes}$	Bytes por valor.	2 en FP16/BF16.

Esta fórmula no sustituye a medir en vLLM, SGLang, llama.cpp, Ollama o el proveedor que uses. Sirve para no prometer imposibles. Si duplicas contexto o batch, la KV cache crece. Si el modelo “cabe” sin usuarios, quizá no cabe con veinte sesiones largas.

Fase 6: el token sale y el bucle vuelve a empezar

El token elegido se añade a la secuencia. Si hay streaming, el usuario puede verlo enseguida. Si hay salida estructurada, tu aplicación no debería confiar todavía: debe parsear, validar schema, comprobar campos obligatorios y decidir si acepta, reintenta, corrige o escala.

graph LR
    APP["Aplicación<br/>instrucciones + datos + contrato"]
    TOK["Tokenizer<br/>texto a IDs"]
    EMB["Embeddings + posición<br/>IDs a vectores"]
    BLOCKS["Bloques Transformer<br/>atención + MLP + residual"]
    LOGITS["Cabeza de lenguaje<br/>logits"]
    DECODER["Decoding<br/>temperature · top_p · stop"]
    TOKEN["Token generado"]
    VALID["Validador<br/>schema · citas · límites"]
    KVC["KV cache<br/>K/V reutilizados"]

    APP -->|"ensambla"| TOK
    TOK -->|"indexa"| EMB
    EMB -->|"procesa"| BLOCKS
    BLOCKS -->|"produce"| LOGITS
    LOGITS -->|"normaliza y filtra"| DECODER
    DECODER -->|"elige"| TOKEN
    TOKEN -->|"se añade al contexto"| BLOCKS
    BLOCKS -.->|"guarda K/V"| KVC
    KVC -.->|"acelera decode"| BLOCKS
    TOKEN -->|"comprueba salida"| VALID

    style APP fill:#F5F5F5,stroke:#111111,stroke-width:2
    style TOK fill:#FFFFFF,stroke:#111111,stroke-width:2
    style EMB fill:#FFFFFF,stroke:#111111,stroke-width:2
    style BLOCKS fill:#F5F5F5,stroke:#111111,stroke-width:2
    style LOGITS fill:#FFFFFF,stroke:#111111,stroke-width:2
    style DECODER fill:#F5F5F5,stroke:#111111,stroke-width:2
    style TOKEN fill:#111111,stroke:#111111,stroke-width:2,color:#FFFFFF
    style VALID fill:#FFFFFF,stroke:#111111,stroke-width:2
    style KVC fill:#FFFFFF,stroke:#777777,stroke-width:2,stroke-dasharray:5 5

Si algo falla, dónde miro primero

Esta es la parte más útil para ingeniería. La disección no sirve para recitar arquitectura; sirve para depurar.

Síntoma	Primera capa que miraría	Qué comprobaría
Respuesta truncada	Contrato de salida	`max_tokens`, `stop`, timeout, longitud esperada.
JSON inválido	Decoding y contrato	Temperatura, salida estructurada, schema, texto extra.
Tarda mucho en empezar	Prefill	Tokens de entrada, documentos pegados, RAG demasiado amplio.
Empieza rápido pero tarda mucho en terminar	Decode	Tokens de salida, tokens/s, batch, GPU, streaming.
Se queda sin memoria	Runtime	Pesos + KV cache + batch + contexto + margen.
Repite frases	Sampling	`repeat_penalty`, `frequency_penalty`, temperatura, prompt.
Responde sin citar	Contexto y validación	Retrieval, contrato de salida, groundedness, abstención.
Parece seguro pero se equivoca	Evaluación	Dataset propio, slices, referencias, revisión humana.
Cambia demasiado entre ejecuciones	Reproducibilidad	`seed`, temperatura, modelo exacto, proveedor, cache, herramientas.
Usa mal una herramienta	Agente/tooling	Schema, permisos, argumentos, trazas, validadores.

Una frase que debería quedarse: la salida visible es el final de una cadena, no el lugar donde empieza la explicación. Si el sistema falla, no preguntes solo “qué ha dicho el modelo”; pregunta qué texto entró, cuántos tokens ocupó, qué contexto recibió, qué logits se filtraron, qué parámetros estaban activos, qué memoria se reservó y qué validador aceptó la salida.

Corte anatómico de una generación

El siguiente esquema resume la disección. No pretende mostrar todos los detalles de un modelo real; pretende poner en una misma mesa las piezas que más se tocan cuando se construye una aplicación: entrada, tensores, bloques, logits, decoding, KV cache, salida y métricas.

Qué debería llevarse un ingeniero

Después de esta disección, un ingeniero no debería decir “el modelo ha fallado” como si fuera una explicación suficiente. Debería poder formular hipótesis:

si falla el formato, miro contrato, decoding y validador;
si falla la evidencia, miro retrieval, contexto y citas;
si falla la latencia inicial, miro prefill y tokens de entrada;
si falla la latencia total, miro decode y longitud de salida;
si falla memoria, miro pesos, KV cache, batch, contexto y precisión;
si falla estabilidad, miro parámetros, versión de modelo, seed, proveedor y evaluación repetida.

Esa mirada es la diferencia entre usar LLMs como una caja negra y trabajar con ellos como sistemas de ingeniería.

Arquitectura, pesos, post-training y producto no son lo mismo

Una de las ideas más útiles del artículo de Kato es separar piezas que en conversación se mezclan demasiado. Dos modelos pueden compartir “familia Transformer” y comportarse de forma muy distinta; dos despliegues pueden servir pesos parecidos y dar experiencias distintas; una API puede esconder optimizaciones que no están en el paper del modelo.

Plano	Qué es	Qué pregunta responde	Error típico
Arquitectura	Forma del modelo: capas, atención, MLP, normalización, tokenizer, contexto, MoE o no MoE.	¿Qué recorrido computacional hace cada token?	Creer que “Transformer” ya explica el comportamiento final.
Pesos	Números aprendidos durante entrenamiento y adaptación.	¿Qué patrones ha aprendido el modelo?	Llamar abierto a un modelo solo porque hay una demo pública.
Post-training	SFT, preferencias, RLHF/RLAIF/RLVR, herramientas, formatos y políticas.	¿Por qué responde como asistente y no como modelo base?	Atribuir al pretraining cosas que vienen de alineamiento o instrucciones.
Runtime	vLLM, SGLang, llama.cpp, servidor propietario, batching, cache, cuantización.	¿Cuánto cuesta, cuánto tarda y cuántos usuarios aguanta?	Comparar modelos sin comparar configuración de serving.
Producto	UI, memoria externa, RAG, herramientas, guardrails, evaluación, permisos.	¿Qué experiencia real tiene la persona?	Decir “el modelo puede” cuando realmente puede el sistema completo.

Esta separación ayuda mucho cuando se comparan modelos cerrados, pesos abiertos y código abierto. Un modelo con pesos descargables puede no tener datos de entrenamiento abiertos. Un modelo con licencia permisiva puede exigir un runtime concreto para rendir bien. Un proveedor cerrado puede ofrecer gran calidad y tooling, pero menos control sobre pesos, tokenizer, kernels o cambios de versión. La decisión profesional no es ideológica: es trazabilidad, coste, privacidad, capacidad de depuración, licencia, evaluación y riesgo operativo.

El mapa completo del facsímil

El facsímil tiene una forma: empieza en el objeto “LLM”, entra en sus capas internas, abre el abanico de arquitecturas, baja a adaptación y termina en el coste real de usarlo. Este mapa intenta mostrar esa escalera.

En el día a día

Este facsímil aparece cada vez que alguien dice “usemos IA” y todavía no ha dicho qué modelo, para qué tarea, con qué contexto, con qué coste y bajo qué límites.

En producto, te ayuda a no elegir por fama. Un modelo enorme puede ser peor decisión si tu caso necesita baja latencia, ejecución local o una licencia concreta. Un modelo más pequeño puede ser suficiente si el dominio está bien acotado, hay recuperación externa y la evaluación es clara.

En ingeniería, te ayuda a separar problemas. Si la salida es mala, puede ser arquitectura, prompt, datos, decoding, herramienta, evaluación o expectativa. Si la latencia es mala, puede ser prefill, decode, KV cache, batch, hardware o red. Poner nombre a la pieza ahorra semanas de confusión.

En aprendizaje, te da una brújula: ya no estás leyendo “modelos” como si fueran marcas. Estás leyendo decisiones de diseño.

Por qué debería importarte

Porque el modelo que eliges condiciona todo lo demás: qué datos necesitas, cómo integras herramientas, cuánto cuesta servir, qué privacidad puedes prometer, qué evals debes construir y qué experiencia tendrá la persona que lo use.

También porque la mayoría de errores caros no nacen de no saber una sigla. Nacen de mezclar planos: pedirle a fine-tuning que actualice conocimiento cambiante, creer que cuantizar no afecta calidad, evaluar solo una demo, ignorar la KV cache o llamar “open source” a cualquier descarga de pesos.

Dónde volverá a aparecer

Este cierre prepara el siguiente bloque. En el facsímil 4 bajaremos de arquitectura a caja de herramientas: APIs, modelos locales, RAG, embeddings aplicados, workbench, evaluación práctica y laboratorios.

Antes de llegar allí, conviene tener claras estas conexiones:

Idea de este facsímil	Dónde vuelve	Por qué importa
Tokens y embeddings	Facsímil 4 y facsímil 8.	Recuperar información y analizar datos exige representar texto como vectores.
Atención y contexto	Facsímil 4 y facsímil 5.	RAG y agentes dependen de qué contexto entra y cómo se usa.
Sampling y formato	Facsímil 4 y facsímil 7.	Configurar generación y evaluar salidas son la misma conversación vista desde dos lados.
Adaptación y modelos abiertos	Facsímil 4 y facsímil 6.	Elegir entre API, local, fine-tuning o RAG es una decisión de sistema.
Inferencia y hardware	Facsímil 6 y facsímil 11.	Operación y UX dependen de latencia, coste y límites del entorno.

Dónde solía tropezar yo

Estos tropiezos son útiles porque suenan razonables. Precisamente por eso conviene nombrarlos.

Error	Por qué es un error	Antídoto
Comparar modelos solo por tamaño	Los parámetros no dicen latencia, contexto útil, licencia, coste ni calidad en tu tarea.	Comparar con una tabla de criterios y pruebas propias.
Creer que Transformer equivale a chat	Transformer es arquitectura; el chat es una interfaz y un post-training.	Separar modelo base, modelo instruct y producto.
Meter conocimiento cambiante en fine-tuning	Ajustar pesos no es buena forma de actualizar datos vivos cada semana.	Usar recuperación o herramientas cuando el dato cambia.
Confundir cuantización con pérdida gratis	Menos bits pueden cambiar calidad, estabilidad o compatibilidad.	Medir antes/después con casos reales.
Ignorar serving	Una demo local no revela colas, KV cache, p95 ni coste por usuario.	Probar concurrencia, contexto largo y respuestas largas.
Depurar solo mirando la respuesta final	La salida puede fallar por tokenización, contexto, decoding, runtime, retrieval, schema o validador.	Diseccionar la llamada: entrada, tokens, logits, parámetros, KV cache y validación.
Recapitular como lista de siglas	Saber decir QKV, MoE o LoRA no significa entender el sistema.	Reexplicar cada pieza con entrada, salida, coste y ejemplo.

Manos a la obra

Este capítulo tiene dos prácticas breves porque cierra dos habilidades distintas. La primera sirve para diseccionar una llamada y entender qué capa tocar. La segunda sirve para elegir estrategia de modelo con criterios ponderados. Una mira el mecanismo por dentro; la otra mira la decisión de arquitectura.

Práctica 1: diseccionar una llamada a un LLM

La práctica real está en kit descargable. El kit simula una petición de soporte interno con instrucciones, documentos, contrato JSON y parámetros de generación. No construye un LLM real; entrena la mirada que sí usarás en sistemas reales: tokens, embeddings, formas de tensores, logits, sampling, KV cache, TTFT y validación.

Archivo	Qué contiene
`data/request_case.json`	Prompt ensamblado, documentos, contrato JSON, parámetros y forma del modelo.
`data/toy_vocab.json`	Logits candidatos para ver cómo cambia el primer token.
`contracts/dissection_policy.json`	Umbrales de tokens, entropía, TTFT, KV cache y token esperado.
`ops/dissect_llm_request.py`	Simulación de tokenización, embeddings, softmax, top-k, top-p, min-p y runtime.
`output/dissection_report.md`	Informe humano de la disección.
`output/dissection_report.json`	Evidencia estructurada para validar el caso.

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
make run
cat output/dissection_report.md

Como gate:

make test

Qué deberías ver. El informe debe mostrar el número de tokens aproximado, una vista de IDs y embeddings, formas de tensores, candidatos tras sampling, memoria de KV cache y una decisión de ingeniería. Si subes temperature, deberías ver más entropía. Si subes num_ctx o batch_size, debería crecer la KV cache. Si bajas max_output_tokens, baja el tiempo máximo de decode.

Qué entregaría un alumno. El Markdown generado, una variante propia de data/request_case.json y una explicación breve: qué parámetro tocó, qué métrica cambió y qué decisión tomaría en una aplicación real.

Vamos a programarlo

Ahora que hemos mirado una llamada por dentro, toca tomar una decisión de arquitectura. Esta segunda práctica convierte el criterio del facsímil en una matriz ponderada.

La práctica real está en kit descargable. No decide por ti, pero obliga a escribir qué pesa más: calidad, latencia, coste, privacidad, mantenimiento, adaptación y contexto externo.

Archivo	Qué contiene
`data/model_strategy_case.json`	Opciones, criterios y pesos.
`contracts/model_strategy_policy.json`	Mínimos de privacidad/contexto y opción esperada.
`ops/score_model_strategy.py`	Scoring ponderado y razones de decisión.
`output/model_strategy_report.json`	Puntuaciones estructuradas.
`output/model_strategy_decision.md`	Memo de decisión.

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
make run
cat output/model_strategy_decision.md

Como gate:

make test

Qué entregaría un alumno. El Markdown generado, una opción nueva, pesos ajustados a su caso y una decisión defendible. El laboratorio final del facsímil sigue después y trabaja con un caso más completo.

Cómo encaja todo

Este mapa no es un índice bonito: es la lectura operativa del facsímil. La primera fila responde a cómo un texto entra en un modelo y termina como token elegido. La segunda fila responde a qué decisiones aparecen cuando ese modelo deja de ser un dibujo y se convierte en una pieza que hay que adaptar, servir y mantener.

También sirve de puente. Lo aprendido en el facsímil 1 explica por qué existen pérdida, métricas y aprendizaje; el facsímil 2 enseña a pensar en estados, coste y restricciones; y el facsímil 4 tomará estas piezas para construir herramientas, RAG, APIs y sistemas locales.

graph TD
    subgraph "Facsímil 03: Arquitecturas y modelos"
        LLM["LLM<br/>parámetros y contexto"]
        TOK["Tokens y embeddings"]
        TRANS["Transformer"]
        ATT["Atención QKV"]
        BLOCK["MLP, residual y LayerNorm"]
        OUT["Logits y sampling"]
        ARCH["Familias modernas"]
        ADAPT["Adaptación y compresión"]
        SERVE["Inferencia y serving"]
        DISECT["Disección de una llamada"]
        CRITERIO["Criterio de elección"]
    end
    subgraph "Facsímiles anteriores"
        BASE["Redes y aprendizaje<br/>fasc. 1"]
        METRICAS["Métricas y validación<br/>fasc. 1"]
        CLASICA["Estado, coste y restricciones<br/>fasc. 2"]
    end
    subgraph "Facsímiles posteriores"
        TOOLS["APIs, local y RAG<br/>fasc. 4"]
        AGENTS["Agentes y orquestación<br/>fasc. 5"]
        OPS["Operar sistemas IA<br/>fasc. 6"]
        EVALS["Evaluación profunda<br/>fasc. 7"]
        UX["Producto y UX<br/>fasc. 11"]
    end

    BASE -->|"sostiene"| LLM
    TOK -->|"entra en"| TRANS
    LLM --> TOK
    TRANS --> ATT
    ATT --> BLOCK
    BLOCK --> OUT
    OUT -->|"produce"| SERVE
    ARCH -->|"elige forma de"| TRANS
    ADAPT -->|"modifica comportamiento de"| LLM
    SERVE -->|"convierte en producto"| LLM
    OUT -->|"permite depurar"| DISECT
    SERVE -->|"aporta TTFT y KV cache"| DISECT
    METRICAS -->|"juzga"| CRITERIO
    CLASICA -->|"aporta coste y restricciones"| CRITERIO
    LLM --> CRITERIO
    ARCH --> CRITERIO
    ADAPT --> CRITERIO
    SERVE --> CRITERIO
    DISECT --> CRITERIO
    CRITERIO --> TOOLS
    CRITERIO --> AGENTS
    CRITERIO --> OPS
    CRITERIO --> EVALS
    CRITERIO --> UX

    style LLM fill:#F5F5F5,stroke:#000000,stroke-width:2
    style TOK fill:#F5F5F5,stroke:#000000,stroke-width:2
    style TRANS fill:#F5F5F5,stroke:#000000,stroke-width:2
    style ATT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style BLOCK fill:#F5F5F5,stroke:#000000,stroke-width:2
    style OUT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style ARCH fill:#F5F5F5,stroke:#000000,stroke-width:2
    style ADAPT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style SERVE fill:#F5F5F5,stroke:#000000,stroke-width:2
    style DISECT fill:#F5F5F5,stroke:#000000,stroke-width:2
    style CRITERIO fill:#F5F5F5,stroke:#000000,stroke-width:2
    style BASE stroke-dasharray: 5 5
    style METRICAS stroke-dasharray: 5 5
    style CLASICA stroke-dasharray: 5 5
    style TOOLS stroke-dasharray: 5 5
    style AGENTS stroke-dasharray: 5 5
    style OPS stroke-dasharray: 5 5
    style EVALS stroke-dasharray: 5 5
    style UX stroke-dasharray: 5 5

Vocabulario aprendido

Antes de cerrar, conviene comprobar que estas palabras ya no son ruido. No hace falta recitarlas perfectas; hace falta poder usarlas en una conversación técnica sin perder el hilo.

Término	Definición
LLM	Modelo de lenguaje grande entrenado para predecir tokens desde contexto.
Parámetro	Número aprendido durante entrenamiento.
Contexto	Tokens disponibles en una petición concreta.
Embedding	Vector que representa un token o fragmento de texto.
Transformer	Arquitectura basada en atención y bloques paralelizables.
Atención	Mecanismo que mezcla información entre posiciones.
Máscara causal	Restricción que evita mirar tokens futuros durante generación.
MLP	Subred que transforma cada posición dentro del bloque.
Residual	Conexión que conserva información entre capas.
LayerNorm	Normalización que estabiliza activaciones.
Logit	Puntuación previa a convertir candidatos en probabilidades.
Sampling	Elección del siguiente token desde una distribución.
MoE	Arquitectura con expertos y router que activa solo una parte del modelo.
Multimodalidad	Capacidad de trabajar con texto, imagen, audio u otros datos convertidos a representaciones compatibles.
LoRA	Técnica de adaptación con matrices de bajo rango.
QLoRA	LoRA sobre modelo cuantizado para reducir memoria.
Destilación	Entrenar un modelo pequeño para imitar uno mayor.
Cuantización	Representar números con menos bits para ahorrar memoria y coste.
KV cache	Memoria de claves y valores usada durante inferencia.
Serving	Sistema que ejecuta modelos para usuarios reales.
Disección de LLM	Recorrido técnico de una petición desde texto y tokens hasta logits, sampling, KV cache y salida validada.
Prefill	Fase en la que el modelo procesa todo el contexto inicial antes de emitir el primer token.
Decode	Fase autoregresiva en la que el modelo genera un token, lo añade al contexto y repite.
TTFT	Tiempo hasta el primer token visible para el usuario.
Entropía de salida	Medida de dispersión de la distribución de candidatos; ayuda a comparar estabilidad y diversidad.
RoPE	Codificación posicional rotatoria que incorpora orden en consultas y claves de atención.
GQA	Atención agrupada donde varias cabezas de consulta comparten menos cabezas de claves y valores para reducir KV cache.
RMSNorm	Normalización basada en raíz cuadrática media usada en muchos decoders modernos.
Residual stream	Flujo principal de activaciones al que cada subcapa suma correcciones.
Speculative decoding	Técnica de inferencia donde un modelo rápido propone tokens y el modelo principal los verifica.

Antes de pasar página

Responde sin mirar los capítulos. Si dudas, el enlace te dice dónde volver.

En resumen

La versión corta del facsímil no es “los LLMs son Transformers”. Es más concreta: un modelo es una arquitectura entrenada, adaptada y servida bajo restricciones.

Idea fuerza	Detalle
Un LLM no es una API.	Es una arquitectura con parámetros, contexto, tokens, atención y sampling.
La atención no es una caja negra.	Q, K, V y softmax explican cómo una posición usa otras posiciones.
Generar texto es decidir tokens.	Logits, temperatura, top-k y top-p controlan el abanico de salida.
La arquitectura es compromiso.	MoE, multimodalidad, contexto largo y modelos híbridos cambian coste y capacidades.
Adaptar no siempre es entrenar.	RAG, fine-tuning, LoRA, QLoRA, destilación y cuantización resuelven problemas distintos.
Servir un modelo es ingeniería.	Prefill, decode, KV cache, hardware y p95 importan tanto como la calidad media.
Diseccionar una llamada ayuda a depurar.	Formato, latencia, memoria, evidencia y coste suelen fallar en capas distintas.
Elegir modelo es explicitar restricciones.	Tarea, datos, coste, privacidad, latencia, licencia, evaluación y mantenimiento.

Para saber más

Ainslie, J. et al. (2023). GQA: Training generalized multi-query Transformer models from multi-head checkpoints. Proceedings of EMNLP. https://arxiv.org/abs/2305.13245

Brown, T. B. et al. (2020). Language models are few-shot learners. Advances in Neural Information Processing Systems 33, 1877-1901. https://papers.nips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html

Dao, T. et al. (2022). FlashAttention: Fast and memory-efficient exact attention with IO-awareness. Advances in Neural Information Processing Systems 35. https://arxiv.org/abs/2205.14135

Dettmers, T. et al. (2023). QLoRA: Efficient finetuning of quantized LLMs. Advances in Neural Information Processing Systems 36. https://arxiv.org/abs/2305.14314

Devlin, J., Chang, M.-W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. Proceedings of NAACL-HLT, 4171-4186. https://doi.org/10.18653/v1/N19-1423

Fedus, W., Zoph, B. y Shazeer, N. (2022). Switch Transformers: scaling to trillion parameter models with simple and efficient sparsity. Journal of Machine Learning Research, 23(120), 1-39. https://www.jmlr.org/papers/v23/21-0998.html

Hu, E. J. et al. (2022). LoRA: Low-rank adaptation of large language models. International Conference on Learning Representations. https://arxiv.org/abs/2106.09685

Kwon, W. et al. (2023). Efficient memory management for large language model serving with PagedAttention. Proceedings of SOSP. https://arxiv.org/abs/2309.06180

Kato. (2026). How LLMs actually work. https://www.0xkato.xyz/how-llms-actually-work/

Leviathan, Y., Kalman, M. y Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding. Proceedings of the 40th International Conference on Machine Learning. https://arxiv.org/abs/2211.17192

Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F. y Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157-173. https://doi.org/10.1162/tacl_a_00638

Raffel, C. et al. (2020). Exploring the limits of transfer learning with a unified text-to-text Transformer. Journal of Machine Learning Research, 21(140), 1-67. https://www.jmlr.org/papers/v21/20-074.html

Shazeer, N. (2020). GLU Variants Improve Transformer. https://arxiv.org/abs/2002.05202

Su, J., Lu, Y., Pan, S., Murtadha, A., Wen, B. y Liu, Y. (2024). RoFormer: Enhanced Transformer with Rotary Position Embedding. Neurocomputing, 568, 127063. https://doi.org/10.1016/j.neucom.2023.127063

Van Rijn, R. (2026). The Anatomy of an LLM. https://www.royvanrijn.com/anatomy-of-an-llm/

Vaswani, A. et al. (2017). Attention is all you need. Advances in Neural Information Processing Systems 30, 5998-6008. https://papers.nips.cc/paper/7181-attention-is-all-you-need

Zhang, B. y Sennrich, R. (2019). Root Mean Square Layer Normalization. Advances in Neural Information Processing Systems 32. https://arxiv.org/abs/1910.07467

Laboratorio

Este laboratorio cierra el facsímil convirtiendo arquitectura en criterio. No vamos a “probar un modelo porque sí”. Vamos a formular una decisión técnica, justificarla y dejar una resolución que otra persona pueda discutir.

Vas a practicar cuatro gestos del facsímil:

Del capítulo 1 al 4: leer qué entra al modelo, cómo se transforma y cómo se genera la salida.
Del capítulo 5: distinguir familias de arquitectura y sus compromisos.
Del capítulo 6: decidir si conviene adaptar, recuperar, cuantizar o elegir otro modelo.
Del capítulo 7: estimar memoria, latencia y coste de inferencia antes de prometer nada.

La intención es que salgas con un reflejo profesional: cuando alguien diga “pongamos IA aquí”, tú puedas responder “vale, definamos tarea, contexto, calidad, latencia, coste y evaluación”.

El kit real está en:

kit/

Ejecuta:

# Descomprime el ZIP del capítulo y ejecuta estos comandos dentro de esa carpeta
python3 ops/score_architecture_strategy.py --write
python3 ops/estimate_inference_budget.py --write
python3 ops/check_student_submission.py --submission-dir solutions/reference --write --fail-on-missing

Qué produce:

Archivo	Qué demuestra
`output/strategy_scorecard.json`	Comparación ponderada entre prompt largo, RAG y fine-tuning.
`output/strategy_decision.md`	Decisión técnica sobre conocimiento cambiante y citas.
`output/inference_budget.json`	Pesos, KV cache, memoria total y tiempo de decode.
`output/deployment_memo.md`	Memo para rediseñar serving antes de prometer producto.

El checker exige que la entrega hable de RAG, fine-tuning, evaluación, KV cache y decode. Es deliberado: en este facsímil la práctica no termina cuando “el modelo cabe”; termina cuando puedes defender si serviría para usuarios reales.

Reto 1: elegir estrategia para un asistente de normativa interna

Contexto

Una organización quiere un asistente que responda preguntas sobre normativa interna: vacaciones, gastos, permisos, compras y seguridad laboral. Las normas cambian varias veces al año. Las respuestas deben citar el documento usado y no inventar políticas.

El equipo baraja tres opciones:

Opción	Descripción
A	Usar una API potente con prompt largo que incluya documentos pegados.
B	Usar un modelo abierto local con RAG sobre documentos internos.
C	Hacer fine-tuning mensual con ejemplos de preguntas y respuestas.

Objetivo

Elegir una estrategia inicial y justificarla con conceptos del facsímil. No basta con “la B porque suena bien”. Debes explicar qué problema resuelve, qué problemas deja abiertos y cómo lo medirías.

Esto sale del capítulo 1 cuando distinguimos parámetros y contexto, del capítulo 6 cuando separamos fine-tuning y RAG, y del capítulo 7 cuando miramos inferencia, coste y contexto largo.

Resolución paso a paso

Primero identificamos el rasgo crítico: la normativa cambia. Eso descarta tratar el conocimiento cambiante como si viviera cómodamente en pesos. Fine-tuning mensual puede enseñar formato, tono o criterios de respuesta, pero no es la forma más limpia de mantener normas vivas.

Después miramos trazabilidad. El asistente debe citar documentos. Eso apunta a recuperación: buscar fragmentos relevantes, meterlos en contexto y exigir respuesta con evidencia.

Luego miramos coste de contexto. Pegar documentos completos en cada prompt puede disparar prefill y coste. RAG reduce contexto si recupera fragmentos bien seleccionados.

Por último miramos privacidad y operación. Si los documentos son internos, un modelo local puede tener sentido, pero no es obligatorio: depende de política de datos, latencia, mantenimiento y calidad.

Respuesta modelo

La estrategia inicial más razonable es B: modelo abierto local con RAG, siempre que el modelo alcance calidad suficiente en evaluación. La razón no es que “local sea mejor”, sino que el problema pide conocimiento cambiante, citas y control de documentos. RAG permite actualizar el corpus sin reentrenar y reduce el contexto frente a pegar documentos enteros.

La opción A puede servir como prototipo rápido, pero tiene dos riesgos: prompts largos y dependencia de enviar documentos a una API externa. La opción C no la descartaría para el futuro, pero la usaría para mejorar formato o estilo, no para memorizar normativa viva.

Cómo lo mediría

Crearía un conjunto de 80 preguntas reales:

Métrica	Qué comprueba
Exactitud de respuesta	Si responde lo correcto según normativa vigente.
Cita correcta	Si el documento citado realmente sostiene la respuesta.
Abstención	Si sabe decir que no hay evidencia suficiente.
Latencia	TTFT y tiempo total con documentos recuperados.
Coste	Coste por pregunta y coste de mantenimiento del índice.

Por qué funciona

Funciona porque separa lo que cambia de lo que debe aprenderse. La normativa viva queda en documentos recuperables. El modelo aporta comprensión lingüística, síntesis y formato. La evaluación comprueba que no estamos premiando una respuesta bonita sin evidencia.

Cómo explicarlo a otra persona

No queremos que el modelo “se aprenda” el reglamento. Queremos que consulte el reglamento correcto, lo lea bien y responda citando de dónde lo sacó.

Variaciones

Repite la decisión si los documentos no pueden salir del portátil de cada usuario.
Repite la decisión si las preguntas deben responderse en menos de 800 ms.
Repite la decisión si la organización exige que todas las respuestas pasen por revisión humana.

Reto 2: dimensionar un modelo para una herramienta de informes

Contexto

Un equipo quiere una herramienta que genere primeras versiones de informes técnicos a partir de notas breves. Cada usuario escribe unas 600 palabras de entrada y espera una respuesta de unas 900 palabras. La herramienta tendrá 30 usuarios activos en las horas punta.

El equipo propone usar un modelo de 7B cuantizado a 4 bits en un servidor propio. Quieren saber si la idea tiene sentido antes de comprar hardware.

Objetivo

Hacer una estimación inicial de memoria y latencia. No buscamos un benchmark perfecto. Buscamos detectar preguntas que el equipo debe responder antes de comprometerse.

Esto sale del capítulo 7 cuando separamos pesos, KV cache, prefill y decode; y del capítulo 6 cuando vimos cuantización.

Datos de partida

Usaremos números aproximados:

Variable	Valor
Parámetros	7B
Cuantización de pesos	4 bits
Capas	32
Contexto por usuario	2048 tokens
Usuarios simultáneos en lote	16
Cabezas KV con GQA	8
Dimensión por cabeza	128
Bytes por valor KV	2
Tokens de salida	1200
Capacidad total decode	240 tokens/s

Resolución paso a paso

Primero estimamos pesos. Un modelo de 7B a 4 bits ocupa aproximadamente:

M_{\text{pesos}} \approx 7\,000\,000\,000 \cdot \frac{4}{8} = 3{,}5\text{ GB}

Ejemplo de fórmula. Después estimamos KV cache:

M_{\text{KV}} \approx 2 \cdot L \cdot B \cdot S \cdot H_{\text{KV}} \cdot d_h \cdot \operatorname{bytes}

Esta estimación no incluye runtime, buffers, fragmentación, margen de seguridad ni diferencias entre implementaciones. Sirve para detectar si una propuesta está en el orden de magnitud correcto antes de prometer latencia o comprar hardware.

Con los valores del enunciado:

def gb(x):
    return x / 1_000_000_000

parametros = 7_000_000_000
peso_bits = 4
peso_gb = gb(parametros * peso_bits / 8)

capas = 32
batch = 16
contexto = 2048
kv_heads = 8
head_dim = 128
bytes_valor = 2
kv_gb = gb(2 * capas * batch * contexto * kv_heads * head_dim * bytes_valor)

tokens_salida = 1200
capacidad_decode = 240
usuarios = 16
tokens_por_usuario = capacidad_decode / usuarios
tiempo_decode = tokens_salida / tokens_por_usuario

print("pesos:", round(peso_gb, 2), "GB")
print("KV cache:", round(kv_gb, 2), "GB")
print("decode por usuario:", round(tokens_por_usuario, 2), "tokens/s")
print("tiempo decode aproximado:", round(tiempo_decode, 2), "s")

Salida esperada:

pesos: 3.5 GB
KV cache: 4.29 GB
decode por usuario: 15.0 tokens/s
tiempo decode aproximado: 80.0 s

Respuesta modelo

La memoria mínima no parece imposible: unos 3,5 GB de pesos y unos 4,29 GB de KV cache para ese lote, sin contar runtime, activaciones, sistema operativo y margen. Pero la latencia sí enciende una alarma: si 16 usuarios comparten 240 tokens/s y cada uno espera 1200 tokens, la generación puede tardar unos 80 segundos por usuario, más prefill y cola.

La propuesta no está descartada, pero necesita rediseño. Posibles caminos:

Reducir longitud de salida con plantillas y secciones progresivas.
Usar streaming para mejorar sensación inicial, aunque no reduzca tiempo total.
Separar usuarios en colas o aumentar capacidad de serving.
Probar un modelo más pequeño o una destilación si la calidad aguanta.
Medir con prompts reales, no con una sola petición feliz.

Por qué funciona

La estimación separa memoria de pesos, memoria de KV cache y velocidad de decode. Esa separación evita una trampa típica: pensar que “el modelo cabe” equivale a “el producto responde bien”.

Cómo explicarlo a otra persona

El modelo puede caber en la máquina y aun así ser demasiado lento para el uso esperado. Caber es una condición. Servir bien es otra.

Variaciones

Cambia usuarios a 4 y 32.
Cambia tokens_salida a 300.
Cambia contexto a 8192.
Cambia kv_heads a 1 para simular MQA.

Cierre del laboratorio

Si estos dos retos te han obligado a preguntar por datos vivos, contexto, citas, memoria, latencia y evaluación, el facsímil ha hecho su trabajo. A partir de aquí, el siguiente bloque puede hablar de herramientas sin caer en la trampa de pensar que una herramienta sustituye al criterio.

Notas

Brown, T. B. et al. (2020). Language models are few-shot learners. Advances in Neural Information Processing Systems 33, 1877-1901. https://papers.nips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html. GPT-3 popularizó la escala como variable central para capacidades emergentes de uso general. ↩
Vaswani, A. et al. (2017). Attention is all you need. Advances in Neural Information Processing Systems 30, 5998-6008. https://papers.nips.cc/paper/7181-attention-is-all-you-need. El paper introdujo una arquitectura basada en atención que evitaba recurrencia y facilitaba paralelismo. ↩
Devlin, J., Chang, M.-W., Lee, K. y Toutanova, K. (2019). BERT: pre-training of deep bidirectional transformers for language understanding. Proceedings of NAACL-HLT, 4171-4186. https://doi.org/10.18653/v1/N19-1423. ↩
Raffel, C. et al. (2020). Exploring the limits of transfer learning with a unified text-to-text Transformer. Journal of Machine Learning Research, 21(140), 1-67. https://www.jmlr.org/papers/v21/20-074.html. ↩
Fedus, W., Zoph, B. y Shazeer, N. (2022). Switch Transformers: scaling to trillion parameter models with simple and efficient sparsity. Journal of Machine Learning Research, 23(120), 1-39. https://www.jmlr.org/papers/v23/21-0998.html. ↩
Hu, E. J. et al. (2022). LoRA: Low-rank adaptation of large language models. International Conference on Learning Representations. https://arxiv.org/abs/2106.09685. ↩
Dettmers, T. et al. (2023). QLoRA: Efficient finetuning of quantized LLMs. Advances in Neural Information Processing Systems 36. https://arxiv.org/abs/2305.14314. ↩
Dao, T. et al. (2022). FlashAttention: Fast and memory-efficient exact attention with IO-awareness. Advances in Neural Information Processing Systems 35. https://arxiv.org/abs/2205.14135. ↩
Kwon, W. et al. (2023). Efficient memory management for large language model serving with PagedAttention. Proceedings of SOSP. https://arxiv.org/abs/2309.06180. ↩
Ainslie, J. et al. (2023). GQA: Training generalized multi-query Transformer models from multi-head checkpoints. Proceedings of EMNLP. https://arxiv.org/abs/2305.13245. ↩
Van Rijn, R. (2026). The Anatomy of an LLM. https://www.royvanrijn.com/anatomy-of-an-llm/. Consultado el 14 de junio de 2026. El recurso se declara en progreso; aquí se usa como inspiración pedagógica, no como fuente única ni como especificación técnica. ↩
Su, J., Lu, Y., Pan, S., Murtadha, A., Wen, B. y Liu, Y. (2024). RoFormer: Enhanced Transformer with Rotary Position Embedding. Neurocomputing, 568, 127063. https://doi.org/10.1016/j.neucom.2023.127063 ↩
Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F. y Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157-173. https://doi.org/10.1162/tacl_a_00638 ↩
Kato. (2026). How LLMs actually work. https://www.0xkato.xyz/how-llms-actually-work/. Consultado el 14 de junio de 2026. ↩
Ainslie, J. et al. (2023). GQA: Training generalized multi-query Transformer models from multi-head checkpoints. Proceedings of EMNLP. https://arxiv.org/abs/2305.13245 ↩
Zhang, B. y Sennrich, R. (2019). Root Mean Square Layer Normalization. Advances in Neural Information Processing Systems 32. https://arxiv.org/abs/1910.07467 ↩
Shazeer, N. (2020). GLU Variants Improve Transformer. https://arxiv.org/abs/2002.05202 ↩
Leviathan, Y., Kalman, M. y Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding. Proceedings of the 40th International Conference on Machine Learning. https://arxiv.org/abs/2211.17192 ↩