Las matemáticas detrás de los LLMs explicadas

Las matemáticas detrás del entrenamiento de LLM no son un misterio académico: son las que determinan cuánto te cuesta cada token y por qué algunos modelos responden en 200ms y otros en 4 segundos. Si alguna vez te preguntaste por qué GPT-4 es más lento que Llama en producción, o por qué DeepSeek puede ser tan barato, la respuesta está en los números.

La matemática fundamental: Transformers y atención

Un Large Language Model (LLM) es un sistema de aprendizaje automático basado en la arquitectura transformer que predice tokens usando mecanismos de atención sobre representaciones vectoriales de alta dimensión, con cientos de miles de millones de parámetros ajustados mediante gradientes.

Ponele que le pedís a Claude que complete una oración técnica. Lo que pasa internamente no es magia: el modelo toma cada palabra (o subpalabra) y la convierte en tres vectores: Query (Q), Key (K) y Value (V). Después calcula cuánto “presta atención” cada posición a cada otra mediante la fórmula:

Attention(Q, K, V) = softmax(Q×K⊤ / √d_k) × V

La división por √d_k evita que los productos escalares exploten en magnitud cuando las dimensiones son grandes. El softmax convierte esos números en probabilidades que suman 1. Multiplicar por V pondera cada vector de valor según esa distribución. El resultado es un vector que “mezcla” información de todas las posiciones según cuán relevantes son entre sí.

Lo que hace que esto sea poderoso es el multi-head attention: en vez de calcular atención una sola vez, el modelo lo hace en paralelo con 8, 16 o más cabezas simultáneas, cada una aprendiendo a capturar relaciones distintas. Una puede enfocarse en sujeto-verbo, otra en referencias pronominales, otra en coherencia temática. Los resultados se concatenan y proyectan de nuevo. Todo eso es multiplicación de matrices, y es por eso que las GPUs con sus miles de núcleos CUDA son tan eficientes para esto: están diseñadas para hacer exactamente eso a escala.

Entrenamiento: backpropagation y gradient descent

El entrenamiento de un LLM es, en esencia, optimización a escala ridícula.

El modelo arranca con parámetros aleatorios. Para cada batch de texto, calcula una predicción, compara con la realidad usando una función de pérdida (cross-entropy), y propaga el error hacia atrás por toda la red usando la regla de la cadena (backpropagation). Cada parámetro recibe un gradiente que indica en qué dirección y cuánto moverse para reducir el error. Después viene gradient descent: actualizar todos esos parámetros un pequeño paso en la dirección correcta.

Repetís eso miles de millones de veces, con épocas sobre los datos, learning rate scheduling, y técnicas como gradient clipping para evitar explosiones numéricas. Los modelos de 2026 agregan RLHF (Reinforcement Learning from Human Feedback) con PPO (Proximal Policy Optimization): una fase donde respuestas humanas calificadas moldean el comportamiento del modelo más allá de la predicción de texto.

DeepSeek-R1, lanzado en enero de 2026, demostró mejoras notables en razonamiento matemático usando precisamente estas técnicas de RL extendido. El entrenamiento con RL post-preentrenamiento no es un detalle menor: es la razón por la que los modelos razonan mejor, y también es caro. Lo explicamos a fondo en proteger modelos en producción.

El factor dominante: tamaño de lote (batch size)

Acá viene lo bueno: el dato más contraintuitivo de todo el pipeline.

Según el análisis de Reiner Pope (investigador de sistemas de ML), sin lotes grandes el costo de servir un modelo puede ser 1000 veces peor. No un 20% peor. No el doble. Mil veces. El tamaño de lote óptimo ronda aproximadamente 300 × factor de esparcidad del modelo. Para un modelo MoE (Mixture of Experts) como DeepSeek, eso implica procesar ~2,400 secuencias simultáneas para operar cerca del óptimo.

La diferencia entre batch 1 y batch 256 puede ser un factor de 100× en costo por token. La razón es puramente matemática: los pesos del modelo están en memoria. Cargarlos tiene un costo fijo. Si procesás un solo prompt, ese costo se amortiza sobre una sola secuencia. Si procesás 256 al mismo tiempo, se divide entre 256. El ancho de banda de memoria se usa igual, pero el trabajo útil se multiplica.

Esto tiene implicaciones directas en cómo pensás la arquitectura de producción. Un servicio con poca concurrencia es inherentemente ineficiente, sin importar qué hardware uses.

Memoria y ancho de banda: el cuello de botella real

¿Por qué los benchmarks de FLOPs no predicen bien la latencia de inferencia? Porque la restricción no es computación sino ancho de banda de memoria.

Pensalo así: un H100 tiene 3.35 TB/s de ancho de banda HBM. Un H200 tiene 4.8 TB/s (43% más). La latencia de acceso a HBM ronda los 20ms. Si tenés un modelo de 70B parámetros en FP16 (2 bytes por parámetro), eso son 140 GB de datos. Dividido por 3.35 TB/s: el H100 tarda ~42ms solo en cargar los pesos, incluso antes de hacer un solo cálculo.

El ratio hardware relevante es de ~300 FLOPs por byte de ancho de banda, y se ha mantenido estable entre generaciones de GPU. Eso significa que la “potencia de cómputo” cruda importa menos de lo que parece: el cuello de botella en inferencia decode casi siempre es memoria, no ALUs.

La fórmula simple: tiempo de memoria ≈ parámetros del modelo ÷ ancho de banda. Con eso podés estimar la latencia de primer token antes de tocar un benchmark.

Paralelismo y distribución: cómo escalar a billones de parámetros

Un modelo de 70B parámetros no entra en una sola GPU. Un modelo de 405B menos todavía. De ahí el paralelismo. Más contexto en cómo se entrena ChatGPT.

Los modelos MoE como DeepSeek usan paralelismo de expertos: diferentes “expertos” (subredes especializadas) se distribuyen entre GPUs. Con la arquitectura Blackwell de NVIDIA, el patrón all-to-all (donde cada GPU se comunica con todas las demás) funciona dentro de un rack de 72 GPUs con latencia tolerable. El problema llega cuando necesitás más de 72 GPUs: la comunicación inter-rack es ~8 veces más lenta que intra-rack, lo que impone límites reales a la escala.

Un dato contraintuitivo: el paralelismo de tubería (pipeline parallelism) no mejora la latencia en inferencia. Sí ayuda en throughput de entrenamiento, pero en inferencia introduce burbujas de inactividad y no amortiza los cachés KV (de los que hablo en la próxima sección). Muchos equipos aprenden esto de la manera difícil.

Prefill vs. decode: dos problemas matemáticos distintos

Cuando mandás un prompt largo a un LLM, la inferencia tiene dos fases bien distintas.

Prefill: el modelo procesa todos los tokens del contexto en paralelo. Es compute-bound: muchas operaciones matriciales simultáneas, las GPUs trabajan al límite de sus FLOPs. Si tenés un contexto de 50,000 tokens, todo se procesa de golpe.

Decode: el modelo genera tokens de a uno. Es memory-bound: cargás los pesos completos del modelo para producir un solo token nuevo. Por eso es inherentemente más lento y más caro por token generado.

Según análisis de costos en producción, la inferencia (decode) es ~5 veces más cara que el prefill. El caché KV es la optimización clave: en vez de recalcular los estados de atención de tokens anteriores, los guardás en memoria (key-value cache). Reutilizás ese estado para cada nuevo token generado.

¿Y qué pasa con contextos muy largos? Gemini cobra 50% más en prompts de más de 200,000 tokens. La razón matemática: a ese tamaño, el caché KV se vuelve enorme (puede pesar decenas de GB por secuencia), y el balance entre memoria y compute se desplaza. El modelo deja de estar puramente en el régimen memory-bound.

Optimización en el mundo real: cuantización, batching y caché

En producción, ningún modelo corre en sus pesos originales sin ajuste.

La cuantización reduce los pesos de FP32 o FP16 a INT8 o INT4 (8 bits o 4 bits). Un modelo de 70B en FP16 pesa 140 GB. En INT4, ~35 GB. Eso no solo reduce el consumo de memoria: también acelera la carga desde HBM. Con 4.8 TB/s en un H200, la diferencia entre cargar 140 GB o 35 GB es ~29ms vs ~7ms de solo lectura de pesos. Para latencia de primer token, eso es enorme. Tema relacionado: arquitectura de modelos modernos.

El batching dinámico con frameworks como Triton + FastAPI agrupa requests en vuelo para maximizar la utilización de GPU. Si llegaron 50 requests en los últimos 50ms, los procesás juntos. La complejidad está en manejar secuencias de longitudes distintas sin desperdiciar cómputo en padding excesivo.

Las métricas que importan en producción: TPOT (time per output token), TTFT (time to first token), y throughput total. Un H200 con batching bien configurado y cuantización INT8 puede procesar 2-3 veces más requests que un A100 (2 TB/s de BW) corriendo el mismo modelo en FP16, para modelos de 70B.

El sobre-entrenamiento: 100 veces más allá del óptimo Chinchilla

En 2022, el paper de Chinchilla estableció la ley de escala “óptima”: para un modelo de N parámetros, entrenar con ~20×N tokens maximiza la performance por FLOP de entrenamiento. Un modelo de 70B debería ver ~1.4 billones de tokens.

Los modelos de 2026 ignoran eso. Llama 3 se entrenó con 15 billones de tokens. Otros modelos actuales van más lejos todavía. Eso es ~100 veces más de lo que dice Chinchilla.

¿Por qué? Tres razones concretas:

• El RL post-preentrenamiento (RLHF, DPO, PPO) funciona mejor sobre modelos que vieron más datos.
• En inferencia, un modelo que vio más datos es más rápido y barato de servir para la misma calidad (podés usar uno más chico).
• El costo total no es solo preentrenamiento: incluye la generación de datos sintéticos para RL y la inferencia de millones de usuarios.

El óptimo Chinchilla minimiza el costo de entrenamiento. Los modelos reales minimizan el costo total del ciclo completo. Son objetivos distintos.

Tabla comparativa: hardware de inferencia en 2026

*Datos preliminares. La aceleración real depende de la carga de trabajo específica.

Errores comunes al razonar sobre costos de LLM

Confundir FLOPs con latencia

Muchos comparan modelos por “petaFLOPs de entrenamiento” o “FLOPs por token” y concluyen que más FLOPs = más lento. En inferencia decode, el cuello de botella es el ancho de banda de memoria, no los FLOPs. Un modelo con más FLOPs pero con cuantización INT4 puede ser más rápido que uno con menos FLOPs en FP16.

Subestimar el impacto del batch size en costo

Equipos que despliegan un modelo con concurrencia baja (5-10 requests simultáneos) y después se preguntan por qué el costo por token es tan alto. Con batch 1, pagás el costo fijo de cargar pesos por cada token generado. Con batch 256, lo dividís entre 256 usuarios. Si tu servicio no tiene suficiente tráfico para mantener el batch lleno, considerá serverless o APIs de terceros. En infraestructura de IA Google profundizamos sobre esto.

Ignorar la diferencia prefill/decode al estimar costos

Un prompt de 10,000 tokens + 500 tokens de respuesta no cuesta lo mismo que 100 tokens de prompt + 500 de respuesta. El decode (500 tokens de respuesta) cuesta ~5 veces más por token que el prefill. Si tu aplicación genera respuestas largas, ese es el driver de costo, no el prompt. Muchos APIs reflejan esto con precios distintos para input y output tokens.

Asumir que el pipeline parallelism mejora latencia

Pipeline parallelism distribuye capas del modelo entre GPUs. En entrenamiento tiene sentido. En inferencia de un solo request, introduce latencia de comunicación entre etapas sin mejorar el TTFT. Para latencia de un solo usuario, tensor parallelism (distribuir cada capa entre GPUs) funciona mejor.

Preguntas Frecuentes

¿Cuáles son las matemáticas fundamentales detrás de los LLMs?

Los LLMs se basan en álgebra lineal (multiplicaciones matriciales masivas), cálculo diferencial (backpropagation con regla de la cadena), estadística (distribuciones de probabilidad sobre vocabulario) y teoría de la optimización (gradient descent con Adam). El mecanismo de atención (Q×K⊤×V / √d_k con softmax) es la operación central que diferencia los transformers de arquitecturas anteriores.

¿Por qué el ancho de banda de memoria es más importante que los FLOPs en LLM?

En la fase de decode (generación token a token), el modelo carga todos sus pesos desde memoria para producir un único token. Con un modelo de 70B en FP16 (140 GB) y un H100 (3.35 TB/s), eso toma ~42ms solo de lectura, sin contar cómputo. El tiempo de transferencia de datos domina el tiempo de cómputo, haciendo del ancho de banda el factor limitante real.

¿Cuál es la diferencia entre entrenar e inferir un LLM matemáticamente?

En entrenamiento, calculás forward pass (predicción), backward pass (gradientes via backprop) y actualizás parámetros. Necesitás guardar activaciones intermedias para el backward pass, lo que triplica o cuadruplica el uso de memoria. En inferencia solo hacés forward pass, sin gradientes, con técnicas como el caché KV para evitar recalcular atención sobre tokens anteriores. La inferencia consume menos memoria pero el decode secuencial crea un cuello de botella distinto.

¿Cómo se optimiza el costo de servir un LLM en producción?

Las tres palancas principales son: cuantización (reducir de FP16 a INT8/INT4 para bajar uso de memoria y acelerar carga de pesos), batching dinámico (procesar múltiples requests simultáneos para amortizar el costo fijo de cargar pesos), y caché KV (reutilizar estados de atención de tokens anteriores para evitar recalcularlos). La combinación de estas tres puede reducir el costo por token entre 5x y 20x respecto a una implementación naive.

¿Por qué los modelos actuales se entrenan más allá del óptimo de Chinchilla?

El paper de Chinchilla (2022) optimiza el costo de preentrenamiento por FLOP. Pero el costo total de un LLM incluye también el fine-tuning con RL (que funciona mejor sobre modelos que vieron más datos) y la inferencia de millones de usuarios (donde un modelo más pequeño pero mejor entrenado es más barato de servir). Los modelos modernos se entrenan ~100 veces más allá de Chinchilla porque minimizan el costo total del ciclo, no solo el del preentrenamiento.

Conclusión

Las matemáticas detrás del entrenamiento de LLM no son solo teoría: determinan directamente cuánto pagás por token, cuánto tarda la primera respuesta y qué hardware necesitás para una operación rentable. El mecanismo de atención define la capacidad del modelo; el ancho de banda de HBM define la velocidad en producción; el batch size define la eficiencia económica.

Si estás desplegando modelos en 2026, los números que más te van a importar son: ancho de banda de tu GPU, tamaño del modelo en los bits que vas a usar, y la concurrencia promedio de tu servicio. Con esos tres datos podés estimar latencia y costo antes de arrancar. Para alojar infraestructura de IA en la región, donweb.com tiene opciones de servidores dedicados que permiten este tipo de despliegues sin depender de nubes de un solo proveedor.

El gap entre “entiendo transformers conceptualmente” y “puedo tomar decisiones de arquitectura y costo” pasa exactamente por acá: entender qué parte del pipeline es compute-bound, cuál es memory-bound, y cómo el batch size conecta las dos cosas.

Fuentes

• Reiner Pope en Dwarkesh Podcast — matemáticas de inferencia LLM a escala
• Redwerk — Técnicas de optimización de inferencia LLM
• Databricks — LLM inference performance engineering best practices
• Aprende Machine Learning — Cómo funcionan los transformers
• Blog Donweb — Aprendizaje inverso y límites de escalado en LLM