Un LLM (Large Language Model, modelo de lenguaje grande) es un programa entrenado con cantidades masivas de texto que aprende a predecir, dada una secuencia de palabras, cuál es la siguiente palabra más probable. No "entiende" en el sentido humano: calcula probabilidades. Su conocimiento está codificado en lo que se llaman parámetros, que son números que determinan cómo conecta una palabra con otra. ChatGPT, Claude, Gemini y Llama son LLMs.
01
¿Qué es un LLM?
Antes de meternos con cables y tarjetas gráficas, conviene saber qué es exactamente eso a lo que llamamos "la IA".
Imagina a alguien que ha leído todos los libros, periódicos, foros y manuales del mundo. No para memorizarlos, sino para aprender el truco de cómo se encadenan las palabras. Cuando le preguntas algo, no busca en una base de datos: predice cuál es la siguiente palabra que tendría sentido escribir, una detrás de otra, hasta formar la respuesta. Es como ese amigo que siempre sabe cómo va a terminar la frase que estás diciendo, pero a lo bestia.
02
¿Dónde vive la IA?
La gente dice "está en la nube" y se queda tan ancha. La nube no existe. Existen edificios.
El modelo no flota en ningún sitio etéreo. Vive cargado en la memoria de unas tarjetas especiales llamadas GPUs (Graphics Processing Unit), que están físicamente metidas en servidores dentro de datacenters. Cuando le hablas a una IA por internet, tu mensaje viaja por cable hasta uno de esos edificios, una GPU lo procesa y la respuesta vuelve por cable a tu pantalla. Las GPUs más potentes para IA hoy son las NVIDIA H100, con 80GB de memoria ultra rápida (HBM, High Bandwidth Memory).
La "nube" es un nombre con marketing. La realidad: salas industriales, frías, llenas de ordenadores apilados, con ventiladores rugiendo y cables por todas partes. Cuando le escribes a Claude desde tu móvil en el sofá, tu mensaje cruza media Europa por cable, llega a una habitación llena de máquinas, una de ellas piensa la respuesta, y vuelve. Todo en menos de un segundo. Si esa sala se inunda, tu IA deja de funcionar. La nube tiene fontanería.
03
Parámetros: el "tamaño" del modelo
Cuando lees "GPT-4", "Llama 70B" o "modelo 7B", esa B no es una nota. Es de billion (mil millones).
Los parámetros son los números internos del modelo: las conexiones entre palabras que ha aprendido durante el entrenamiento. Se miden en miles de millones (B = billion en inglés). Un modelo 7B tiene 7.000 millones de parámetros. Un 70B, setenta mil millones. GPT-4 se cree que ronda 1.7 trillones (1.700.000 millones). Más parámetros suelen significar más capacidad de matiz, pero también más memoria necesaria, más coste de inferencia y más lentitud.
| Tamaño | VRAM mínima (FP16) | VRAM mínima (4-bit) | Dónde corre |
|---|---|---|---|
| 7B | ~14 GB | ~4-6 GB | GPU doméstica de gama alta |
| 13B | ~26 GB | ~8-12 GB | GPU seria |
| 70B | ~140 GB | ~40-50 GB | Multi-GPU / H100 |
| 400B+ | ~800 GB+ | Cientos de GB aún cuantizado | Datacenter puro |
Regla rápida: en formato FP16, cada parámetro pesa unos 2 bytes. La cuantización a 4-bit reduce mucho el tamaño, pero no toca el KV cache (eso lo vemos luego).
Imagina que el cerebro de la IA es como el cuaderno de recetas de un cocinero. Un cocinero con 7.000 millones de recetas memorizadas (modelo 7B) ya es bastante bueno. Uno con 70.000 millones (70B) es un crack. Uno con 1.7 trillones (GPT-4) es algo que no existía antes. Pero ojo: cuanto más grande es el cuaderno, más estantería necesita para que entre, más cara la cocina, y más tarda el cocinero en buscar la receta cada vez que pides algo. La cuantización es como reescribir las recetas con menos detalle: ocupan menos, pero pierdes algún matiz fino.
04
VRAM: la encimera de la cocina
La memoria de una GPU se llama VRAM, y es donde pasa la fiesta. Pero no solo entra el modelo.
La VRAM (Video RAM) es la memoria de la GPU. Aunque la gente piense que solo guarda los pesos del modelo, en realidad tiene que sostener varias cosas a la vez:
VRAM ≈ pesos + KV cache + activaciones + batch + overheadPesos del modelo: los parámetros cargados (suele ocupar entre el 50% y el 60%).
KV cache: la memoria por cada token ya procesado (puede crecer al 30% o más en contextos largos).
Activaciones y batch: los cálculos intermedios y los usuarios simultáneos (~12%).
Overhead / cola: buffers, runtime, gestión (~6%).
Cuanto más larga la conversación y más usuarios al mismo tiempo, más crece la parte de KV cache, y antes se queda corta la VRAM.
Imagina la encimera de un cocinero. La gente piensa que solo necesita espacio para el cuaderno de recetas. Falso. En esa encimera tiene que caber a la vez:
El cuaderno (los pesos del modelo). Los apuntes de cada pedido en marcha (el KV cache, que crece según la conversación). Los ingredientes que está manejando ahora (las activaciones). Los pedidos de todas las mesas a la vez (el batch). Los trapos, los cuchillos, los hierros (overhead).
Si la encimera es pequeña, el cocinero apila, se le caen cosas, va más lento. Si es grande pero está atendiendo a 200 mesas a la vez con conversaciones larguísimas, también colapsa. Esto explica por qué a veces las IAs van lentas a ciertas horas: la encimera está saturada.
Distribución típica de la VRAM
05
¿Qué es un token?
La IA no lee palabras. Lee trozos. Y por esos trozos te facturan.
Un token es la unidad mínima de texto que el modelo procesa. No equivale exactamente a una palabra: puede ser una palabra entera, una sílaba, un símbolo o incluso un espacio. La conversión de texto a tokens se llama tokenización, y la hace un componente llamado tokenizer. En español, un token equivale aproximadamente a 0.6 palabras (o sea, 100 palabras ≈ 165 tokens). Las palabras comunes suelen ser 1 token; las raras o largas, varios.
Ejemplos:
"Hola" → 1 token
"Konnexia" → probablemente 3 tokens (Kon-nex-ia)
"anticonstitucionalmente" → 5 o 6 tokens
Los proveedores de API (OpenAI, Anthropic, Google) cobran por token: tantos céntimos los de entrada, tantos los de salida.
Imagina que enseñas a leer a un niño y le partes las palabras en sílabas: "ca-sa", "pe-rro". La IA hace algo parecido: no lee palabras enteras, las trocea en piezas LEGO. Una palabra fácil como "casa" es 1 pieza. Una palabra rara como "esternocleidomastoideo" puede ser 7 piezas. Y cada pieza que entra y cada pieza que sale, te la facturan. Por eso una conversación larga con archivos pesados puede salir cara: no es por las palabras, es por el número de piezas que se mueven.
06
La ventana de contexto: tu mesa de trabajo
La IA no se acuerda de todo. Solo de lo que cabe en su mesa.
La ventana de contexto (context window) es el número máximo de tokens que el modelo puede procesar en una sola petición. Incluye absolutamente todo lo que entra: tu mensaje actual, el historial de la conversación, los archivos adjuntos, las instrucciones del sistema, las herramientas disponibles, los resúmenes de memoria. Cuando la suma se acerca al límite, la información más antigua empieza a salirse o a comprimirse.
Tamaños actuales aproximados:
GPT-4o: ~128k tokens
Claude Sonnet/Opus: ~200k tokens
Gemini 1.5 Pro: hasta 1M tokens (y subiendo)
Modelos open source pequeños: 8k a 32k
Y dentro de esa ventana, no todo pesa igual. El orden importa:
1. Instrucciones estables (cacheables, baratas de mantener)
2. Archivos y decisiones (recuperar solo lo necesario)
3. Historial reciente (útil, pero genera ruido si has cambiado de tema)
4. Respuesta actual (los tokens de salida que se están generando)
Imagina una mesa de trabajo grande pero finita. Encima pones todo lo que quieres que la IA tenga en cuenta: tu pregunta de ahora, los archivos que le has mandado, lo que se dijo antes, las normas del juego. Si la mesa son 200.000 papelitos y has metido 198.000, queda casi sin sitio. Lo nuevo entra, pero los papeles más antiguos se van cayendo por los bordes (o se comprimen en un resumen).
Y aquí va el truco: la IA mira con más atención los papeles que están al principio y al final de la mesa. Los del medio se le difuminan. Por eso si le metes un PDF de 80 páginas y la pregunta clave está en la página 41, igual no la pilla. (Lo veremos en la lección 09: "lost in the middle".)
Capas de la ventana de contexto (por prioridad)
1. Instrucciones estables
Cacheables, baratas de mantener
2. Archivos y decisiones
Recuperar solo lo necesario
3. Historial reciente
Útil, pero genera ruido si cambias de tema
4. Respuesta actual
Tokens de salida que se van generando
07
Cómo procesa un mensaje: el flujo real
Cuando pulsas "enviar", pasan cuatro cosas en orden. No una. Cuatro.
El procesamiento de cada petición sigue 4 fases:
1. Tokenización. Tu texto + adjuntos + instrucciones se convierten en tokens.
2. Selector de contexto. El sistema decide qué partes del historial, archivos y memoria son relevantes y entran en la ventana. Lo demás se descarta o se comprime.
3. Prefill. El modelo procesa todo el prompt completo de golpe y construye el "estado de atención" inicial. Aquí es donde más crece el coste con el tamaño del contexto.
4. Decode. El modelo genera la respuesta token a token. Cada token nuevo mira los anteriores y el KV cache para decidir cuál escribir a continuación.
Cuando le mandas un mensaje a una IA, no es que ella lo lea como tú lees un WhatsApp. Pasa esto:
1. Trocear. Lo primero, parte tu texto en piezas LEGO (tokens).
2. Filtrar. Mira el historial, los archivos, las instrucciones, y decide qué cabe en la mesa y qué deja fuera.
3. Empollar. Se lee del tirón todo lo que ha entrado en la mesa, como un actor estudiando el guion entero antes del primer take.
4. Responder. Empieza a escribir palabra por palabra, mirando lo que ha escrito antes para que cuadre.
La fase del "empollar" (prefill) es la cara: cuanto más le pongas en la mesa, más tarda y más cuesta. La de "responder" (decode) es más barata pero más lenta visualmente, porque va token por token (por eso ves la respuesta apareciendo "como tecleada").
Flujo de procesamiento
Entrada
→
Selector
→
Prefill
→
Decode
↑ Prompt cache (reutiliza cómputo)
↑ RAM / VRAM del servidor
08
La caché: cómputo reutilizado, no recuerdos
Cuando ves "cached" o "cache hit" en una factura de API, no es magia. Es un atajo.
La caché son trozos del prompt cuyo cálculo ya se hizo antes y se reutiliza, en lugar de recalcular desde cero. Hay dos tipos relevantes:
Prompt cache. Si una parte del prompt es estable y se repite (instrucciones del agente, documentos base, estructura del proyecto), el proveedor la marca y la reutiliza en peticiones siguientes. Sigue formando parte del contexto, pero no entra como trabajo nuevo. Suele ser entre un 50% y un 90% más barata que un token "fresco".
KV cache. Por cada token ya procesado, el modelo guarda en memoria unas matrices llamadas "claves" (K) y "valores" (V) de atención. Eso le permite, al generar el siguiente token, no tener que volver a procesar todo desde el principio. No es texto: son números puros, estado interno del modelo.
Cuidado: si cambias de tema de golpe en medio de la conversación, arrastras el contexto viejo (sigues pagándolo) y añades el nuevo (también lo pagas). Y la caché útil se rompe.
Dos tipos de "atajo":
Prompt cache es como cuando llamas al fontanero por segunda vez. La primera vez le explicas cómo entrar al edificio, dónde está la cocina, que el grifo es el de la izquierda. La segunda vez ya no le explicas todo eso: lo tiene apuntado. La IA hace lo mismo con las instrucciones que se repiten en cada petición. Por eso sale más barato si tu sistema es estable.
KV cache es más interno. Imagínate que la IA, según va leyendo tu mensaje, va tomando apuntes mentales rapidísimos en una libreta. Luego, cuando empieza a escribir la respuesta, no tiene que volver a leerse todo: mira la libreta. Si tuviese que releer todo cada vez que escribe una palabra de respuesta, tardaría una eternidad.
Y el aviso importante: si en medio de una conversación sobre el presupuesto cambias de golpe a hablar del cumpleaños de tu hija, la libreta entera tiene que actualizarse, los atajos se rompen, y pagas más. Por eso es mejor abrir un chat nuevo cuando cambias de tema.
09
Lost in the middle: por qué se le pierde la mitad
Le metes un PDF de 80 páginas y la respuesta solo cita el principio y el final. No es casualidad.
El fenómeno "lost in the middle" es un efecto bien documentado en LLMs: cuando el contexto es muy largo, la atención del modelo no se reparte uniformemente. La precisión es alta para información que está al principio o al final de la ventana, y baja en la zona central. La gráfica de "atención útil" tiene forma de U.
Implicaciones prácticas:
Si tienes información crítica, ponla al principio o al final del prompt. No confíes en que un modelo encuentre un dato suelto enterrado en el medio de un PDF largo. Mejor: extrae lo relevante antes y mételo limpio. Esto pasa incluso en modelos con ventanas de 1M tokens.
¿Has leído un libro largo y te acuerdas perfectamente del principio (cuando todo era nuevo y prestabas atención) y del final (cuando ya querías saber cómo acababa), pero la mitad la tienes difuminada? A la IA le pasa lo mismo. La curva de su atención dibuja una U: presta mucha atención al inicio, se relaja en el medio, se vuelve a enchufar al final.
Por eso, si le mandas un dossier de 80 páginas con la cifra clave en la página 41, te puede contestar perfectamente de qué va el dossier y como termina, pero la cifra clave se le ha perdido en el agujero del medio. La solución no es darle más contexto. Es darle MEJOR contexto: extraer lo importante y servírselo limpio.
Curva de atención: "lost in the middle"
10
Compacting: resumir para no morir
Cuando una conversación se hace muy larga, alguien tiene que hacer la limpieza. Eso es el compacting.
El compacting es el proceso de comprimir una conversación larga en un resumen estructurado que conserve lo esencial: decisiones tomadas, objetivos, archivos tocados, próximos pasos. Cuando la sesión crece y se acerca al límite de la ventana de contexto, el sistema (o un agente bien diseñado) sustituye la conversación cruda por su versión compactada. Si el compacting se hace bien, libera tokens y mantiene la continuidad. Si se hace mal, se pierden matices y el modelo "olvida" detalles relevantes.
[Historial crudo] → [Compacting] → [Contexto útil]
mucho ruido extracción menos tokens
muchos errores decisiones mejor foco
cambios de tema objetivos continuidadImagina que has estado trabajando con tu asesora 4 horas seguidas en una reunión. Hay decisiones tomadas, ideas descartadas, café derramado, anécdotas de la nieta de no sé quién, y al final un acuerdo importante.
Si al día siguiente le pides a tu asesora que te recuerde "en qué quedamos", no te lee la grabación de 4 horas: te da el resumen. Tres puntos clave, dos decisiones, un siguiente paso. Eso es compacting bien hecho.
Si lo hace mal, te dice "hablamos de muchas cosas" y has perdido información valiosa. Por eso un agente serio (un Claude Code bien montado, por ejemplo) no se fía de la conversación gigante: cada cierto tiempo la compacta, la guarda en archivos, y empieza con la mesa más limpia.
11
Por qué un agente serio usa árbol de archivos
La conversación larga es enemiga. Los archivos son aliados.
Un agente bien diseñado no confía toda la información a una conversación gigantesca. En su lugar, mantiene un árbol de archivos estructurado en disco, y solo carga en el contexto lo que necesita para la tarea actual.
Principio clave: los archivos no sustituyen al modelo. Lo que hacen es organizar la información para que el modelo no tenga que buscar una aguja en un pajar dentro de una ventana de contexto saturada.
Imagina que llevas un negocio. Tienes dos opciones para organizarte:
Opción A: Un único cuaderno gigantesco donde apuntas TODO en orden cronológico: facturas, ideas, llamadas, recetas de la abuela, contraseñas, decisiones. Cuando necesitas algo, hojeas las 800 páginas hasta encontrarlo.
Opción B: Un despacho con carpetas etiquetadas. "Decisiones tomadas". "Proyectos en marcha". "Lo que hago hoy". "Skills que tengo". Cuando necesitas algo, abres SOLO la carpeta que toca.
Un agente bien hecho (un Claude Code, por ejemplo) trabaja como la Opción B. La conversación contigo se va resumiendo en archivos, los archivos se organizan en carpetas, y cuando le pides algo nuevo, solo abre las carpetas necesarias. Por eso aguanta proyectos largos sin perderse y sin que la factura se dispare.
Estructura típica de un workspace de agente
workspace-agente/
├── agend.md # qué toca hacer ahora y prioridad
├── memoria-operativa.md # hechos estables que no se pueden perder
├── decisiones.md # decisiones tomadas y por qué
├── skills/
│ ├── servidores-llm/SKILL.md
│ ├── memoria-contexto/SKILL.md
│ └── automatizacion/SKILL.md
├── proyectos/
│ └── clase-hardware/
│ ├── objetivos.md
│ ├── fuentes.md
│ └── guion.md
├── sesiones/
│ ├── estado-actual.md
│ └── resumen-compactado.md
└── entregables/
├── infografia.md
└── clase-final.html
12
API vs ordenador local: ¿importa tu PC?
Si llamas a Claude por API, el cerebro está en otro sitio. Pero tu PC sigue importando, aunque por otro motivo.
Cuando usas una IA por API (OpenAI, Anthropic, Google), el modelo corre en la VRAM de las GPUs del proveedor. Tu ordenador no contribuye nada a la VRAM ni amplía la ventana de contexto del modelo. La inferencia entera sucede en su datacenter.
Pero tu PC sí afecta a:
Las herramientas que orquestan la IA: Claude Code, Codex, editores de IDE, agentes locales, MCP servers. El navegador con varias pestañas abiertas mientras la usas. Los procesos de captura, indexación, renderizado, vídeo, build. La capacidad de mover proyectos pesados sin congelarse.
Lo que un PC potente SÍ aporta: soportar agentes complejos sin que el sistema se ahogue. Preprocesar bien el contexto (limpiar, filtrar, comprimir antes de enviarlo). Mover IDEs, screenshots, builds y procesos auxiliares en paralelo.
Lo que un PC potente NO aporta: no agranda la ventana de contexto del modelo. No aumenta la VRAM disponible para el modelo. No rompe los límites del proveedor.
Llamar a una IA por API es como pedir comida a domicilio. La cocina del restaurante no la pones tú: la pone el restaurante. El plato llega igual de bueno tengas en casa una mesa de un metro o de cinco.
Pero si tu casa está hecha un caos, con cosas por encima de la mesa, sin sitio para abrir el envoltorio, y la lavadora rota inundándolo todo, disfrutar de la comida sí depende de ti. Eso es lo que pasa cuando trabajas con agentes (Claude Code, Codex, automatizaciones): la IA en sí va igual de rápida, pero TU lado (el local) puede saturarse y volverte loca.
Un PC potente no hace que la IA sea más lista. Hace que TÚ puedas mover proyectos grandes a su alrededor sin que se te congele todo.
13
Diferencia clave: RAM, VRAM y ventana de contexto NO son lo mismo
La gente las mezcla. Vamos a separarlas.
| Concepto | Qué es | Dónde está |
|---|---|---|
| RAM | Memoria principal del ordenador. Sostiene programas, sistemas operativos, procesos. | En tu PC o en el servidor. |
| VRAM | Memoria de la GPU. Sostiene pesos del modelo, KV cache, activaciones, batches. | Solo en GPUs. |
| Ventana de contexto | Límite lógico de tokens que el modelo puede atender en una petición. | Es una propiedad del modelo, no del hardware. |
Implicaciones:
Tener más RAM no agranda la ventana de contexto. Tener más VRAM permite servir modelos más grandes y contextos más largos, pero no garantiza que el modelo "entienda mejor". La ventana de contexto la decide el modelo (su arquitectura), no la máquina donde corre.
Tres cosas que la gente confunde:
RAM es como la mesa del salón de tu casa. Sirve para tener cosas a mano mientras vives.
VRAM es como la encimera de la cocina del restaurante. Solo está donde se cocina (en la GPU). No la tienes tú en casa.
Ventana de contexto es el "tamaño máximo del menú" del restaurante. Es algo que decide el chef, no la encimera. Por mucho que amplíes la cocina, si el chef diseñó un menú de 10 platos, sigue siendo de 10 platos.
Por eso cambiar de ordenador no te da "más memoria de IA". Lo que decide cuánto contexto hay es el modelo que estás usando, no tu máquina.
Resumen final: Modelo + servidor + caché + archivos = IA útil de verdad
Una IA "útil de verdad" no depende solo de lo listo que sea el modelo. Depende de cuatro capas funcionando bien:
1. El modelo genera tokens. Si es flojo, todo lo demás da igual.
2. El servidor sostiene los pesos, la KV cache y los buffers. Si está saturado, todo va lento.
3. La caché reutiliza cómputo y reduce coste. Si se rompe (cambios de tema constantes), se pagan tokens de más.
4. Los archivos del agente estructuran el contexto. Si todo está en una conversación gigante sin organización, el modelo se pierde.
Si una capa falla, la IA parece torpe aunque el modelo en sí sea potente.
Una IA buena no es un genio mágico. Es un equipo:
El cocinero (el modelo) tiene que saber cocinar.
La cocina (el servidor) tiene que estar montada y no saturarse.
Los atajos (la caché) tienen que estar bien usados.
El despacho (los archivos del agente) tiene que estar ordenado.
Si el cocinero es genial pero la cocina está rota, la cena llega tarde. Si la cocina es perfecta pero el despacho es un desastre, el cocinero no sabe qué se ha pedido. Si todo está bien excepto que cambias el menú cada cinco minutos, los atajos se rompen y pagas más.
La próxima vez que una IA te parezca tonta, no asumas que el cocinero es malo. Suele ser el despacho.