---
title: "Cómo funciona un LLM: la máquina de predecir el siguiente token"
description: "Un LLM no razona ni consulta nada: calcula probabilidades y muestrea. Entender ese único bucle te da criterio de ingeniero y explica casi todo."
pubDate: "2026-05-25"
category: "programacion"
language: "es"
tags: ["llm", "ia", "fundamentos", "tokens", "transformers", "inferencia", "desarrollo"]
---
Llevo meses escribiendo sobre cómo construir cosas con LLMs —[token optimization](/blog/token-optimization/), [agent teams](/blog/agent-teams-claude-code/), [harness engineering](/blog/harness-engineering/)— y me he dado cuenta de algo: casi todo dev que usa Claude o GPT a diario no tiene ni idea de qué está pasando ahí dentro. No lo digo con sorna: usar la herramienta a diario no obliga a abrir esa caja, y la mayoría no lo hace. Pasa que pedimos cosas, salen cosas, y el modelo se trata como una caja negra mágica que a veces acierta y a veces inventa.

El problema de esa caja negra es que cuando algo va mal, no sabes ni dónde mirar. ¿Por qué alucina? ¿Por qué generar 1.000 tokens cuesta diez veces más que leer 1.000? ¿Por qué la conversación "se acuerda" si el modelo es estático? Si no entiendes el bucle de dentro, todo te parece arbitrario.

Este artículo es la primera lección del curso de IA que estoy preparando. La idea: explicarte qué hace un LLM por dentro **sin matemáticas demostradas, con criterio de ingeniero**. Si lo terminas, vas a poder explicarle a otro dev el camino completo de un token desde que entra hasta que sale —y un montón de cosas que parecían magia van a empezar a tener sentido.


## La única cosa que hace un LLM

Empezamos por la frase que necesitas grabarte:

> **Un LLM no consulta una base de datos ni razona con lógica. Calcula una distribución de probabilidad sobre su vocabulario y muestrea de ella.**

Eso es. Toda la IA que usas se construye sobre ese único bucle.

Por dentro, un Large Language Model es una **función matemática enorme** con miles de millones de parámetros —los famosos *pesos*, que se aprenden durante el entrenamiento—. Esa función toma una secuencia de tokens de entrada y devuelve, para cada uno de los ~100.000-200.000 tokens posibles de su vocabulario, **la probabilidad de que sea el siguiente**. Y ya está. Eso es todo lo que hace en una pasada, lo que se llama un *forward pass*.

¿"Miles de millones" suena abstracto? Son lo que ves cada día. Cuando en Hugging Face o en un model card aparecen nombres como **Mistral 7B**, **Llama 3 8B**, **Llama 3 70B** o **Llama 3.1 405B**, esa **B** final es justo eso: *billions* de parámetros. La cifra te dice cuántos pesos lleva el modelo por dentro —siete mil millones, setenta mil millones, cuatrocientos cinco mil millones—. Es la métrica más visible y la que más se compara entre modelos abiertos. Los cerrados (GPT-4, Claude) no la publican, pero juegan en el mismo orden de magnitud.

¿Y cómo aparece entonces una respuesta entera de varios párrafos? Pues con un bucle. La generación —técnicamente *inferencia autoregresiva*— es así:

```
1. Tomar la secuencia de tokens de entrada (el prompt).
2. Forward pass → distribución de probabilidad sobre los
   ~100.000-200.000 tokens del vocabulario.
3. Muestrear UN token de esa distribución.
4. Añadir ese token a la secuencia.
5. Volver al paso 2, ahora con un token más.
6. Parar cuando se muestrea el token especial de fin o se
   alcanza un límite.
```

Antes de seguir, vale la pena aterrizar qué es esa *"distribución de probabilidad sobre el vocabulario"* del paso 2, porque suena abstracto y no lo es. **Es literalmente una lista de unos 100.000 números, uno por cada token del vocabulario.** Cada número está entre 0 y 1, todos suman 1. El paso 3 —muestrear— es elegir uno de esos tokens **proporcionalmente** a su probabilidad.

Para hacerlo tangible, vamos con dos casos.

**Caso 1.** Imagina que el contexto que le has dado al modelo termina en:

> *"El sol sale por el ___"*

El forward pass devuelve una lista de cien mil probabilidades. La forma que tiene es algo así:

| Token candidato | Probabilidad |
|---|---|
| `este` | 0,87 (87 %) |
| `horizonte` | 0,05 (5 %) |
| `amanecer` | 0,02 (2 %) |
| `valle` | 0,005 |
| `mar` | 0,003 |
| *(los otros ~99.995 tokens)* | suman 0,052 entre todos |

Casi toda la masa de probabilidad está en `este`. Tires la moneda las veces que tires, vas a sacar `este` casi siempre. Esto es una **distribución concentrada**.

**Caso 2.** Ahora el contexto termina en:

> *"Mi color favorito es el ___"*

La distribución se aplasta:

| Token candidato | Probabilidad |
|---|---|
| `azul` | 0,18 |
| `rojo` | 0,12 |
| `verde` | 0,10 |
| `negro` | 0,08 |
| `amarillo` | 0,06 |
| *(otros colores y palabras válidas como `mismo`, `color`, `que`)* | reparten ~0,40 |
| *(el resto de ~99.990 tokens)* | casi 0 |

Aquí el sampling sí marca la diferencia: una vez sale `azul`, otra `rojo`, otra `verde`. Esto es una **distribución dispersa**.

Dos cosas para llevarse de aquí:

1. **Para cualquier contexto concreto, solo un puñado de tokens tiene probabilidad real.** Aunque el vocabulario sean cien mil, el conjunto de "siguientes tokens plausibles" en un punto cualquiera es siempre pequeño —cinco, diez, veinte tokens como mucho—. El resto está efectivamente a 0.

2. **La forma de la distribución determina el comportamiento del modelo.** Concentrada → respuestas estables, casi deterministas. Dispersa → creatividad y variabilidad. Cuando alguien dice que un modelo *"es creativo"* o *"se repite mucho"*, está hablando, sin saberlo, de la forma de estas distribuciones. Y los famosos parámetros de sampling (*temperature*, *top-p*, *top-k*) son controles que **dispersan o concentran** esa masa de probabilidad antes de tirar la moneda. Pero eso es para otro día.

Cuando ves a Claude o a GPT escribiendo en streaming, palabra a palabra, **cada palabra es una vuelta completa de ese bucle**. El modelo no "tiene en mente" la frase entera y te la va revelando: la construye de verdad token a token, y cada uno se decide releyendo todo lo anterior.

Volviendo al sampling del paso 3: la imagen mental es la de **lanzar un dado de cien mil caras donde cada cara pesa distinto**. Los tokens con más probabilidad saldrán más a menudo, pero ninguno está garantizado. Por eso la misma pregunta da respuestas distintas cada vez. Lo que sale son **remixes inspirados por los datos de entrenamiento** — estadísticamente parecidos, no idénticos.

Esto que parece un detalle académico **es la base operativa de todo**. Si te lo crees de verdad, varias cosas dejan de ser sorprendentes.


## Cuatro consecuencias incómodas (y útiles)

Vamos a las implicaciones. Son cuatro y, si las internalizas, dejas de pelearte con el modelo y empiezas a diseñar para él.

### 1. Las alucinaciones no son un bug. Son el mecanismo.

Esto se repite mucho y se entiende poco. Cuando un modelo cita con total convicción una función de librería que no existe, o un paper con su autor inventado, **no se ha "equivocado"**. Está haciendo exactamente para lo que se le entrenó: producir la **continuación más probable**, no la **verdadera**.

Si tu prompt induce un contexto donde lo estadísticamente plausible es "aquí debería ir un nombre de función", el modelo va a poner un nombre de función. Si su entrenamiento le sugiere que ese tipo de método se llama `parseAndValidate`, lo va a escribir, exista o no en la librería que le has dicho que use.

La consecuencia operativa es brutal y a la vez liberadora: **la verificación no es opcional, es estructural**. Cualquier disciplina seria con agentes —tests obligatorios, type-checks, navegador headless, otro agente revisor— sale de aquí. No estás "ayudando" al modelo; estás cerrando el agujero por donde se cuela la naturaleza probabilística del bicho. La verificación no es desconfianza: es ingeniería.

### 2. Generar es caro y leer es barato (y por eso pagas lo que pagas)

Cada token de salida requiere un forward pass completo sobre miles de millones de parámetros. Cada uno. Si el modelo genera 1.000 tokens, son 1.000 forward passes secuenciales —no se pueden paralelizar porque cada token depende del anterior—.

Los 1.000 tokens de entrada, en cambio, se procesan **de golpe** en una fase llamada *prefill*. Por eso en la mayoría de APIs el coste de input es mucho más barato que el de output: en Claude, por ejemplo, los output tokens cuestan unas 5x los input. No es marketing: es física computacional.

Cuando alguien te dice *"prompts más cortos para ahorrar"*, está mirando el lado fácil. **El gran ahorro está en pedirle al modelo respuestas concisas**, no en escribir prompts telegráficos. Lo mismo con la latencia: tu prompt de 50.000 tokens se procesa en un par de segundos; los 500 tokens de respuesta van a tardar diez veces más, uno detrás de otro.

Y por eso existe la **KV cache** —una optimización que veremos en otra lección— que evita reprocesar lo ya procesado entre llamadas. Si entiendes el bucle, entiendes por qué la primera respuesta de una sesión tarda y las siguientes vuelan.

### 3. El modelo es una función pura. No tiene memoria.

Esta es la que más alucinante me parece cuando alguien la descubre. **El modelo no aprende de tus conversaciones, no guarda nada entre llamadas, no tiene estado**.

Cada vez que mandas un mensaje, técnicamente se ejecuta el modelo desde cero. Los pesos son los mismos para ti, para mí y para todo el mundo: no cambian. La "memoria" de una conversación con Claude es una ilusión muy bien construida que se logra de una sola forma: **reenviándole todo el historial cada vez**.

¿Que parece que Claude se acuerda de lo que le dijiste hace 20 turnos? Lo que pasa por debajo es que el cliente le manda toda la conversación entera —tus mensajes y los suyos— en cada petición. Por eso la ventana de contexto importa tanto. Por eso una sesión larga es cada vez más cara —cada nueva petición lleva más texto—. Y por eso en cuanto el contexto se llena, hay que **sacar cosas a memoria externa**: ficheros, una base de datos, lo que sea, pero fuera del modelo.

Toda la disciplina de memoria de la que he hablado en artículos anteriores viene de aquí. El modelo no recuerda nada: tu trabajo es darle la información justa en cada llamada.

Aquí hay una analogía que me parece especialmente útil, y se la robo a Andrej Karpathy de su [deep dive de tres horas y media sobre LLMs en YouTube](https://www.youtube.com/watch?v=7xTGNNLPyMI) (vídeo muy recomendable si te quedas con ganas de más después de este artículo): **los pesos del modelo son memoria vaga; el contexto es memoria de trabajo precisa**. Los pesos son como recordar un libro que leíste hace meses —las ideas generales están, los detalles exactos no, y a veces te inventas el detalle—. El contexto, en cambio, es como tener el libro abierto delante: lo que está ahí es exacto. Esa es la razón por la que **RAG funciona** (mete el dato exacto en la memoria de trabajo en vez de fiarse de la vaga del entrenamiento), por la que **un buen `CLAUDE.md` cambia el resultado**, y por la que todo el harness engineering del que escribo gira alrededor de **gestionar qué entra en el contexto**.

### 4. "Razonar" es generar tokens. No hay un segundo proceso oculto.

Cuando ves a un modelo de razonamiento "pensar" —esos bloques `<thinking>` o el "Reasoning" de o1 y derivados—, lo que está haciendo no es magia. Está **generando tokens de borrador antes de la respuesta final**. Ese borrador suele ser tokens privados (no se te muestran o se te muestran resumidos) en los que el modelo escribe su propio razonamiento intermedio.

No hay un procesador lógico aparte. **Pensar es escribir**. Esto explica varias cosas. Por qué los modelos de razonamiento son más lentos (están generando más tokens) y más caros (los tokens de pensamiento también se pagan). Y por qué prompts como *"piensa paso a paso"* funcionan en modelos no-razonadores: les estás dando permiso a escribir más antes de la respuesta, lo que en la práctica los hace pensar.

Si has trabajado con Chain-of-Thought, lo has hecho a mano. Los modelos de razonamiento lo han metido en el propio modelo, en vez de pedirlo en el prompt.


## La anatomía de una llamada que ya leíste mil veces sin leer

Con todo lo anterior, los términos que aparecen en la documentación de cualquier API de LLM dejan de ser ruido. Esto es lo que debes saber leer:

- **Prompt / input tokens** — lo que mandas. Se procesa en bloque en la fase de *prefill*. Es lo barato.
- **Output / completion tokens** — lo que el modelo genera, uno a uno, en la fase de *decode*. Es lo caro y lo lento.
- **Parámetros / pesos** — los miles de millones de números del modelo. No cambian entre llamadas. La función es **pura**.
- **Logits** — la salida cruda del forward pass. Son los números antes de convertirse en probabilidades (con un *softmax*) y antes de muestrear. Te interesan si haces evaluación fina o constrained generation; normalmente no los ves.
- **Vocabulario** — el conjunto cerrado de tokens que el modelo conoce, típicamente 100.000-200.000 entradas. Cada token es un trozo de texto (a veces una palabra, a veces parte de una palabra, a veces un signo).
- **Forward pass** — una pasada del modelo. Un token de salida = un forward pass.
- **Inferencia autoregresiva** — el bucle de generar token a token releyendo lo anterior. El núcleo de todo.

Cuando entiendes que cada palabra que aparece en streaming es un forward pass completo sobre miles de millones de parámetros, **el precio de una API empieza a tener sentido** —y empiezas a tomar mejores decisiones de diseño—.


## Tres preguntas para ver si lo tienes

Antes de cerrar, prueba a contestarte estas tres. Si las tienes claras, has interiorizado la lección.

1. **¿Por qué un LLM puede citar con total seguridad un paper o una función que no existen?** (Pista: la confianza no sale de saber; sale de que la continuación es la más probable.)
2. **¿Por qué generar 1.000 tokens de salida cuesta mucho más que procesar 1.000 de entrada?** (Pista: forward passes secuenciales vs. prefill en bloque.)
3. **Si el modelo es estático y no tiene estado, ¿dónde "vive" la memoria de una conversación larga con Claude?** (Pista: en ningún sitio del modelo. Vive en el cliente que reenvía el historial.)

Si una se te resiste, vuelve arriba. Si las tres son obvias, **ya tienes el cimiento de todo lo que viene**.


## Lo que viene después

Lo que acabas de leer es la lección 1.1 del curso de IA *Zero to Hero* que estoy preparando. La PARTE 1 entera está dedicada a las tripas del modelo —porque todo lo demás (prompting, contexto, agentes, arnés) se apoya en esto—:

- **1.2** Tokenización: por qué *"tokenización"* se parte en varios tokens y por qué el español y el código consumen más que el inglés.
- **1.3** Embeddings: cómo cada token se convierte en un vector y por qué la "cercanía semántica" se mide con geometría.
- **1.4** La arquitectura Transformer de un vistazo, sin mates, con criterio de ingeniero.
- **1.5** El mecanismo de atención —la pieza que hace todo esto posible—.
- **1.6 a 1.9** Pre-training, scaling laws, sampling, KV cache. Cuando alguien te diga *"el modelo nuevo es 10x mejor"*, vas a saber dónde mirar.

Si esto te interesa y quieres acceso anticipado y descuento de lanzamiento cuando salga el curso, déjame tu email en la [lista de espera de **Agentes e IA: Zero to Hero**](/curso-agentes-ia/). Estoy escribiendo cada lección al nivel de la que acabas de leer; el curso será operativo, sin paja, con criterio.

Y como esto es la entrada al primer módulo, la pregunta natural para ti es: ¿qué parte de las cuatro consecuencias te ha removido más cuando la has leído? Si quieres, contestas a este artículo en redes o me lo dices en respuesta a la newsletter. Las dudas reales son lo que va dando forma al curso final.

---

*Si quieres profundizar: dentro de este blog, [harness engineering](/blog/harness-engineering/) cuenta lo que va alrededor del modelo y por qué pesa más que el propio modelo, y [optimización de tokens](/blog/token-optimization/) baja a tierra mucho de lo que aquí queda en concepto.*

**P.D.**: Si te quedan dudas con alguna pieza del bucle, o quieres que profundice en algo concreto antes de la próxima lección del curso, me encuentras en Twitter como [@lm_martinbar](https://x.com/lm_martinbar).