Guía de ingeniería de LLM: 45 conceptos para sistemas en producción

Viacheslav Dubrov

2026-03-13 · Actualizado 2026-08-31 · 74 min · Ingeniería de modelos · Infraestructura de IA

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Un servicio de LLM puede incumplir su SLO de latencia porque el decode está limitado por el ancho de banda de memoria, porque el KV cache ha consumido el presupuesto del batch o porque la cola está ocultando ambos problemas. Un entrenamiento de fine-tuning puede fallar por una versión distinta del mismo motivo: el estado del modelo ya no cabe en el hardware. La solución adecuada se deduce del cuello de botella, no de la lista más larga de técnicas.

Esta es una referencia para ingenieros que ya conocen los conceptos básicos de ML y sistemas, y necesitan relacionar un síntoma de producción con la parte pertinente del stack. Cubre 45 conceptos de hardware, inferencia, entrenamiento, despliegue, aplicaciones y operaciones. Usa cada entrada para identificar el mecanismo, su consecuencia práctica y la condición que limita el resultado citado; después, consulta el análisis detallado enlazado o ejecuta tu propio benchmark antes de tomar la decisión.

Nota sobre el alcance

Esto es una referencia, no un tutorial lineal. Empieza por la parte que corresponda a la decisión que tengas delante.

Cómo utilizar esta guía como hub

Esta página es deliberadamente amplia. Úsala como mapa y salta después a los artículos más profundos cuando la decisión sea concreta.

Empieza por el cuello de botella, utiliza el stack más pequeño que lo haga visible, mide la carga de trabajo real y añade complejidad solo cuando los números lo justifiquen.

Parte I — Fundamentos del hardware

La intensidad aritmética, la jerarquía de memoria de la GPU y los términos de hardware de esta parte explican muchas de las decisiones que aparecen más adelante.

1. Limitado por memoria frente a limitado por cómputo y el modelo Roofline

El punto de partida para el rendimiento de los LLM es la intensidad aritmética: por cada byte de datos que la GPU carga desde memoria, ¿cuántos cálculos útiles realiza? Esta proporción determina si una operación está limitada por cómputo (esperando al procesador) o limitada por memoria (esperando a que se carguen los datos).

Toda GPU tiene un umbral de «intensidad crítica» en el que su throughput máximo de cómputo iguala su ancho de banda de memoria. Para una NVIDIA H100 SXM con Tensor Cores densos en BF16 o FP16 (989 TFLOPS; la especificación de 1.979 TFLOPS presupone sparsity estructurada):

$\frac{989 \text{ TFLOPS}}{3.35 \text{ TB/s}} \approx 295 \text{ FLOPs/byte}$

El decode con batch de uno y el prefill largo o con un batch suficientemente grande suelen situarse en lados opuestos de este umbral:

• El decode está limitado por memoria. Generar tokens uno a uno implica cargar desde memoria la matriz de pesos de varios gigabytes para multiplicarla por un único token nuevo. En un análisis simplificado de precisión densa de 16 bits con batch de uno, la operación tiene aproximadamente 1 FLOP/byte, unas 295 veces por debajo del umbral Roofline de la H100. Esta diferencia explica por qué el decode no puede acercarse al throughput máximo de cómputo en este régimen.
• El prefill largo o con un batch suficientemente grande suele estar limitado por cómputo. Procesar muchos tokens del prompt reutiliza los pesos en multiplicaciones de matrices grandes, lo que puede elevar la intensidad aritmética por encima del umbral Roofline. Los prompts cortos y los batches pequeños pueden estar limitados por el tráfico de memoria o por la sobrecarga de lanzar kernels.

Para acelerar el decode, trabaja sobre el ancho de banda de memoria: reduce el tamaño de los pesos mediante cuantización, disminuye la sobrecarga de memoria del KV con GQA y PagedAttention, y aumenta la intensidad mediante batching. Para prefills largos o con un buen batching, puede ayudar un cálculo matricial más rápido y una computación de menor precisión; perfila por separado las cargas con prefill corto.

2. Jerarquía de memoria de la GPU

Una GPU tiene cuatro niveles de memoria, dispuestos como una pirámide: una memoria principal grande pero lenta (HBM) en la base y registros diminutos pero muy rápidos en la cima. Mover datos por esta jerarquía es una restricción de rendimiento importante.

De más rápida a más lenta en una H100:

1. Los registros son la memoria más rápida y están conectados directamente a los hilos de procesamiento. En la WGMMA de Hopper, la matriz A puede proceder de los registros o de la memoria compartida, mientras que la matriz B procede de la memoria compartida.
2. SRAM (memoria compartida) es una memoria de trabajo rápida integrada en el chip y local a cada SM.
3. La caché L2 es una capa compartida de 50 MB. Puede servir datos reutilizados entre SM sin otra lectura desde HBM.
4. HBM3 es la memoria principal de 80 GB que contiene los pesos del modelo y el KV cache, con un ancho de banda de ~3,35 TB/s.

FlashAttention y la fusión de kernels reducen el tráfico hacia HBM al conservar o combinar trabajo intermedio en el chip. PagedAttention aborda un problema distinto: asigna bloques KV lógicos a bloques físicos no contiguos de la memoria de la GPU, reduciendo la fragmentación y permitiendo compartir bloques.

3. Glosario de hardware de GPU

Los términos siguientes aparecen a lo largo del resto de la guía.

HBM (High Bandwidth Memory) apila matrices de DRAM conectadas mediante vías a través del silicio (TSV) junto al die de la GPU. Entre sus generaciones se incluyen HBM2e (A100, 2 TB/s), HBM3 (H100, 3,35 TB/s) y HBM3e (H200/B200, 4,8–8 TB/s). El ancho de banda de HBM es una restricción directa sobre TPOT en regímenes de decode limitados por memoria.

GDDR (Graphics DDR) es la memoria gráfica tradicional utilizada en GPU de consumo y workstation, como la RTX 4090 y la L40S. Tiene menos ancho de banda que HBM, pero cuesta menos por GB. La GDDR6X de la RTX 4090 ofrece aproximadamente 1 TB/s, frente a los 3,35 TB/s de ancho de banda HBM3 de la H100.

Un SM (Streaming Multiprocessor) es el bloque básico de cómputo de una GPU NVIDIA. Cada SM contiene CUDA cores, Tensor Cores, memoria compartida y un planificador de warps. La H100 tiene 132 SM; la A100 tiene 108.

Los Tensor Cores son unidades especializadas de multiplicación y acumulación de matrices dentro de cada SM. Aceleran las operaciones matmul de precisión mixta que dominan el cómputo de los transformers. Los Tensor Cores de la H100 SXM ofrecen 494,5 TFLOPS densos o 989 TFLOPS dispersos en TF32; al comparar esta cifra, incluye siempre la precisión y el modo de sparsity.

Los CUDA Cores son unidades de propósito general para operaciones en coma flotante y enteras. Gestionan operaciones elemento a elemento, funciones de activación y otras tareas que no son matriciales mientras los Tensor Cores ejecutan operaciones matriciales compatibles.

Un warp es un grupo de 32 hilos que ejecutan en lockstep en un SM, por lo que constituye la unidad de planificación más pequeña de NVIDIA. La especialización de warps asigna distintos warps al movimiento de datos y al cómputo para que ambas tareas se solapen.

NVLink es el interconnect de alta velocidad de NVIDIA entre GPU dentro de un nodo. NVLink 4.0 en H100 ofrece 900 GB/s de ancho de banda bidireccional; NVLink 5.0 en B200 alcanza 1,8 TB/s. Este ancho de banda es importante para el tensor parallelism, porque las GPU intercambian resultados parciales en cada capa del transformer.

InfiniBand es un tejido de red de alta velocidad para la comunicación entre nodos. Los adaptadores InfiniBand de clase ConnectX proporcionan el tejido entre nodos para el tráfico de pipeline parallelism o distributed training; el ancho de banda depende del adaptador y de la configuración de los puertos.

RDMA (Remote Direct Memory Access) permite que un dispositivo acceda a la memoria de otra máquina sin encaminar el flujo de datos a través de la CPU. GPUDirect RDMA permite transferencias directas de GPU a GPU entre nodos, incluidos los traspasos de KV cache en serving desagregado.

NVMe (Non-Volatile Memory Express) es la interfaz SSD utilizada para descargar el KV cache y para el offloading de parámetros de ZeRO-Infinity cuando la memoria de la GPU y la CPU son insuficientes. El ancho de banda secuencial depende de la unidad y de la carga de trabajo, y sigue estando muy por debajo del ancho de banda de HBM.

TFLOPS y PFLOPS son billones y cuatrillones de operaciones en coma flotante por segundo. Un TFLOPS equivale a $10^{12}$ FLOPS. La H100 alcanza 989 TFLOPS dispersos de Tensor TF32, mientras que FlashAttention-3 declara aproximadamente 1,2 PFLOPS en FP8; esos valores utilizan formatos distintos y no deben compararse como si fueran una única métrica.

Parte II — Fundamentos de la inferencia

La inferencia convierte un modelo en un servicio visible para el usuario. Los conceptos siguientes separan el trabajo que retrasa el primer token del que ralentiza todos los tokens posteriores y ponen de manifiesto los límites de memoria que afectan a ambos.

4. Latencia: TTFT, TPOT y percentiles

Time to First Token (TTFT) es el retraso de extremo a extremo desde el envío de la petición hasta el primer token de salida. Incluye la espera en cola, la tokenización, la planificación, el prefill del prompt, el primer paso de decode y la entrega por red. Los prompts más largos suelen aumentar el componente de prefill, pero cualquiera de estas etapas puede dominar. Los objetivos dependen del producto; MLPerf Inference v5.0 utiliza un límite de TTFT P99 de $\leq$ 450 ms para su escenario interactivo con Llama 2 70B.

Time Per Output Token (TPOT) es el intervalo medio entre tokens consecutivos después del primero. Corresponde a la fase de decode. El decode con batch de uno o de baja intensidad suele estar limitado por el ancho de banda de memoria, mientras que los batches suficientemente grandes pueden quedar limitados por el cómputo:

$\text{TPOT} = \frac{\text{E2E Latency} - \text{TTFT}}{\text{Output Tokens} - 1}$

Esta definición requiere al menos dos tokens de salida; TPOT no está definido para una respuesta de un solo token.

La velocidad media de lectura silenciosa de un adulto en inglés es de unos 238 palabras por minuto para textos de no ficción (Brysbaert, 2019). Aun así, los objetivos de streaming deben establecerse mediante pruebas del producto; MLPerf utiliza un límite de TPOT P99 de $\leq$ 40 ms para su escenario interactivo.

La latencia P50 frente a P99 importa porque la mediana oculta la cola. Un sistema con un P50 bueno y un P99 malo puede tener problemas de batching, preemption, colas o sesgo de la carga de trabajo; hacen falta trazas para distinguirlos.

5. Throughput: tokens por segundo y el compromiso con la latencia

El throughput se mide en tokens de salida por segundo entre peticiones concurrentes. Las peticiones por segundo son una métrica más débil por sí solas, porque una respuesta de 10 tokens y otra de 1.000 tokens tienen costes muy distintos. Las cifras publicadas en benchmarks varían según el modelo, la precisión, el hardware, las longitudes del prompt y de la salida, la concurrencia y el SLO. Compara vLLM, SGLang y TensorRT-LLM con un mismo harness en lugar de combinar sus resultados destacados.

El compromiso es el siguiente: con poca concurrencia, cada petición obtiene una latencia excelente, pero la GPU está infrautilizada. Al aumentar el batch, el throughput crece casi linealmente hasta que el cómputo se satura; después, la latencia aumenta bruscamente. Goodput, la tasa de peticiones por segundo que cumplen tus objetivos de SLO, conecta el throughput bruto con la experiencia real de los usuarios.

6. KV cache: el cuello de botella que está detrás de muchos otros

Durante la generación autoregresiva, cada token nuevo atiende a todos los tokens anteriores. El KV cache almacena las proyecciones Key y Value de cada token en cada capa para evitar $O(n^2)$ recomputación. Sin él, generar el token $n$ exigiría volver a ejecutar el modelo sobre los $n-1$ tokens anteriores.

El KV cache puede convertirse en la principal fuente de presión sobre la memoria variable con secuencias largas o una concurrencia elevada, porque crece linealmente con la longitud de la secuencia, el tamaño del batch y el número de capas:

$KVcache = 2 \times L \times h_{kv} \times d_h \times s \times B \times \text{bytes}$

donde:

• $L$ = número de capas
• $h_{kv}$ = número de cabezas KV
• $d_h$ = dimensión de la cabeza
• $s$ = longitud de la secuencia
• $B$ = tamaño del batch
• $\text{bytes}$ = bytes por elemento almacenado en caché, determinados por la precisión del KV cache

Ejemplos concretos con FP16 y batch de tamaño 1: Llama 3.1 8B con 8.192 tokens utiliza ~1,0 GB de KV cache; con 128K tokens, 16 GB. Llama 3.1 70B con 128K tokens necesita ~40 GB para una sola secuencia, la mitad de la VRAM de una H100. Con una concurrencia elevada o un contexto largo, el KV cache puede superar la memoria de los pesos del modelo; el resultado depende de la longitud de la secuencia, el tamaño del batch activo, la precisión del KV y el número de cabezas KV. Las implementaciones ingenuas desperdician entre el 60 y el 80 % de la memoria KV asignada por fragmentación; ese es el problema que PagedAttention se diseñó para resolver.

Las principales optimizaciones son GQA (menos cabezas KV), la cuantización del KV cache (FP8/INT8), PagedAttention (asignación basada en bloques con menos del 4 % de desperdicio) y el offloading del KV cache a la CPU o a NVMe.

7. Prefill frente a decode: dos fases, dos cuellos de botella

La fase de prefill procesa el prompt de entrada en paralelo y rellena el KV cache. Los prefills largos o con un batch suficientemente grande suelen estar limitados por el cómputo porque utilizan multiplicaciones de matrices grandes; los prefills cortos pueden seguir limitados por el tráfico de memoria o por la sobrecarga de lanzar kernels. El prefill contribuye al time to first token (TTFT), junto con la espera en cola, la tokenización, la planificación, el primer paso de decode y la entrega por red. La fase de decode genera un token cada vez. Cada paso lee los pesos del modelo y el KV cache desde HBM, por lo que el decode con batch de uno está limitado por el ancho de banda de memoria y es el principal determinante del time per output token (TPOT).

Chunked prefill divide el prompt en fragmentos de tamaño fijo en lugar de procesarlo de una sola vez. Un scheduler puede intercalar esos fragmentos con trabajo de decode para que un prompt largo no monopolice una iteración. Sarathi-Serve comunica mejores compromisos entre throughput y latencia en las cargas de trabajo probadas, pero la mejora depende del modelo, el hardware, la distribución de longitudes de las peticiones, el tamaño del fragmento y la baseline de comparación. La sobrecarga adicional de planificación y los kernels más pequeños pueden aumentar el TTFT de la nueva petición.

El serving desagregado sitúa el prefill y el decode en pools de GPU separados, lo que permite que cada pool se centre en un cuello de botella diferente. Splitwise y DistServe describen este patrón. Los pools transfieren los datos del KV cache mediante un interconnect rápido como RDMA, por lo que el coste de comunicación forma parte del diseño.

8. GQA y MQA: reducir el KV cache

La Multi-Head Attention (MHA) estándar asigna a cada cabeza de consulta su propia cabeza K y V. Multi-Query Attention (MQA) comparte una única cabeza KV entre todas las cabezas de consulta, lo que supone una reducción extrema. Grouped-Query Attention (GQA) es el punto intermedio práctico: grupos de cabezas de consulta comparten una cabeza KV.

Llama 3 70B utiliza 64 cabezas de consulta, pero solo 8 cabezas KV, una reducción de 8x del KV cache frente a la misma arquitectura con una cabeza KV por cada cabeza de consulta. Llama 3.1 405B utiliza 128 cabezas de consulta y 8 cabezas KV, una reducción de 16x según el mismo cálculo (Meta, 2024). Ainslie et al. informan de una calidad de GQA cercana a MHA en los modelos probados, al tiempo que se aproxima a la velocidad de MQA. Un KV cache más pequeño puede admitir batches mayores, pero la mejora efectiva de latencia y throughput sigue dependiendo del kernel y de la carga de trabajo.

9. Cuantización: intercambiar bits por velocidad y memoria

La cuantización reduce la precisión de los pesos del modelo o de las activaciones, o de ambos. Sus compromisos principales son:

AWQ (Activation-Aware Weight Quantization) identifica canales de pesos relevantes a partir de las magnitudes de las activaciones y aplica escalado por canal para protegerlos. Sus necesidades de calibración dependen del modelo y de la configuración; en una comparación OPT-6.7B INT3-g128, AWQ utilizó 16 secuencias de calibración frente a las 192 de GPTQ. En una configuración reproducible, informa tanto del número de secuencias como de su longitud. GPTQ utiliza información aproximada de segundo orden para la cuantización por capas. bitsandbytes puede cuantizar durante la carga del modelo sin un paso de preprocesado independiente; su formato NF4 impulsa el fine-tuning con QLoRA. FP8 en hardware de clase Hopper reduce a la mitad la memoria de los pesos respecto a FP16/BF16, pero la calidad y la velocidad siguen dependiendo del modelo, la calibración y el kernel.

El kernel de serving puede importar tanto como el algoritmo de cuantización. La sección 10 ofrece un resultado acotado de Marlin y explica por qué la mejora depende de la configuración de serving.

Parte III — Optimizaciones de inferencia

Las optimizaciones de esta parte resuelven restricciones distintas. FlashAttention reduce el tráfico de HBM de la atención; PagedAttention mejora la asignación del KV; el continuous batching evita que las secuencias terminadas retengan capacidad del batch.

10. CUDA kernels y fusión de kernels

Un CUDA kernel es una función escrita para la GPU que se ejecuta en paralelo sobre miles de hilos. Cuando la CPU lanza un kernel, la GPU distribuye el trabajo entre sus SM: cada SM ejecuta varios warps de 32 hilos y cada hilo procesa una parte de los datos. Toda operación de inferencia de LLM, desde la multiplicación de matrices hasta el muestreo de tokens, termina siendo un lanzamiento de kernel. Un único forward pass a través de un modelo de 70B activa entre cientos y miles de lanzamientos de kernels, y la diferencia entre un kernel ingenuo y uno optimizado puede determinar si el sistema cumple su SLO de latencia.

Las principales categorías de kernels en serving de LLM son:

• Kernels GEMM para la multiplicación de matrices, que domina el cómputo tanto del prefill como del decode.
• Kernels de atención, como FlashAttention, que dividen el cálculo en bloques para mantenerlo en SRAM en lugar de volcarlo a HBM.
• Kernels fusionados, que combinan varias operaciones (como add + layer norm o la proyección QKV) en un único lanzamiento para evitar los viajes de ida y vuelta intermedios a HBM.
• Kernels de sampling, que convierten los logits en IDs de tokens mediante muestreo top-k, top-p o por temperatura.

La calidad del kernel puede determinar si los pesos comprimidos aportan una aceleración. El artículo de Marlin comunica hasta 2,8x de speedup de extremo a extremo frente a su baseline FP16 en las configuraciones de vLLM probadas con INT4 weight-only. Este resultado es específico de los modelos, GPU, tamaños de batch y configuración de serving del artículo, por lo que no constituye una mejora universal de INT4.

Triton reduce la barrera para escribir kernels personalizados al ofrecer programación de GPU mediante Python en lugar de CUDA C++ en bruto. Así, la optimización a nivel de kernel queda al alcance de los ingenieros de ML y no solo de los especialistas en GPU. La mayoría de las optimizaciones posteriores de esta parte (FlashAttention, kernels fusionados y PagedAttention) son mejores kernels o formas más inteligentes de orquestar los lanzamientos.

La fusión de kernels combina operaciones secuenciales en un único kernel de GPU y evita las escrituras intermedias en HBM. Entre las fusiones habituales están la proyección QKV, atención más softmax, add más RMSNorm (FlashNorm) y la activación SwiGLU (DeepFusionKernel). Triton hace accesibles estos kernels desde Python. Las mejoras exactas en el número de lanzamientos y en la utilización dependen del grafo del modelo, el compilador, la GPU y el framework de serving, así que perfila el stack desplegado en lugar de confiar en un porcentaje universal.

11. FlashAttention: dividir la atención en bloques para vivir en SRAM

La atención estándar materializa la matriz de atención completa de $N \times N$ en HBM, lo que consume $O(N^2)$ de memoria y genera mucho tráfico. La idea de FlashAttention es no materializar nunca esta matriz. Divide las matrices Q, K y V en bloques que caben en SRAM, calcula la atención parcial dentro de cada bloque y combina los resultados mediante un softmax online (realizando un seguimiento incremental del máximo y de la suma acumulados entre bloques). La memoria pasa de $O(N^2)$ a $O(N)$ y las lecturas desde HBM disminuyen en un orden de magnitud.

Cada versión se centra en el cuello de botella de su generación de GPU:

• FlashAttention v1 (A100, 2022) demostró que la idea de dividir en bloques más el softmax online funciona. El artículo comunicó una aceleración de 2–4x frente a la atención estándar, pero solo una utilización de GPU del 25–40 %, porque la planificación de kernels dejaba muchos SM inactivos.
• FlashAttention v2 (A100, 2023) rediseñó el paralelismo para dividirlo por la dimensión de secuencia en lugar de por batch y cabezas. Alcanzó una utilización del 50–73 % en A100, aproximadamente 2x más rápido que v1.
• FlashAttention v3 (H100 Hopper, 2024) añadió especialización de warps (warps separados para movimiento de datos y cálculo) y pipelining GEMM-softmax para solapar las cargas de memoria con el cómputo. El artículo comunica hasta 740 TFLOPS/s en FP16 (75 % de utilización) y cerca de 1,2 PFLOPS/s en FP8 en H100. Spotlight de NeurIPS 2024.
• FlashAttention v4 (B200 Blackwell, 2026) aborda un nuevo cuello de botella: en Blackwell, el throughput de los Tensor Cores escala tan rápido que las operaciones no matriciales (exponenciales del softmax y reescalado) se convierten en el factor limitante. FA4 emula por software la exponencial con aproximaciones polinómicas en unidades FMA, utiliza reescalado condicional para reducir la sobrecarga y almacena los valores intermedios en la memoria tensorial dedicada (TMEM) de Blackwell en lugar de en registros. El artículo comunica aproximadamente 1,6 PFLOPS en B200 con BF16, 1,3x más rápido que cuDNN 9.13 y 2,7x más rápido que Triton en sus pruebas.

12. FlashDecoding: paralelizar el cuello de botella del decode

FlashAttention estándar mantiene ocupada la GPU dividiendo el trabajo entre el tamaño del batch y la longitud de la consulta. Durante el decode, el modelo genera exactamente 1 token cada vez (longitud de consulta = 1). Si el tamaño del batch multiplicado por el número de cabezas de atención es menor que el número total de SM de la GPU (108 en una A100), la mayor parte de la GPU permanece inactiva mientras unas pocas unidades recorren secuencialmente el historial de tokens.

FlashDecoding resuelve esto añadiendo una nueva dimensión de paralelización: la propia longitud de la secuencia KV. Divide el KV cache en fragmentos más pequeños y los distribuye entre todos los procesadores de GPU que estarían inactivos para evaluarlos en paralelo; después combina sus cálculos parciales mediante una reducción log-sum-exp.

En el benchmark de CodeLlama-34B con batch de uno de Stanford, con longitudes de secuencia entre 512 y 64K tokens, FlashDecoding alcanzó hasta un speedup de extremo a extremo de 8x frente a las baselines probadas y mantuvo casi constante la latencia de atención hasta 64K. El resultado está acotado a ese hardware y benchmark, y no constituye una garantía general para el decode.

13. Continuous batching frente a static batching

El static batching espera a que todas las secuencias de un batch terminen antes de iniciar el siguiente, por lo que las secuencias cortas desperdician ciclos de GPU cuando alcanzan el end-of-sequence. El continuous batching (introducido por el artículo de Orca, OSDI 2022) trabaja con granularidad de iteración: en cada paso de decode se eliminan las secuencias terminadas y se insertan otras nuevas.

En el benchmark de OPT-13B de Anyscale, el static batching optimizado alcanzó 4x su baseline ingenua, el continuous batching alcanzó 8x y vLLM con continuous batching más PagedAttention alcanzó 23x (Anyscale, 2023). El continuous batching también aumenta la presión sobre la asignación del KV, por lo que suele combinarse con gestión de memoria paginada.

14. PagedAttention: memoria virtual para el KV cache

PagedAttention de vLLM aplica la idea de memoria virtual de los sistemas operativos a la gestión del KV cache. El KV cache se divide en bloques de tamaño fijo (normalmente 16 tokens), los bloques se asignan bajo demanda a medida que se generan tokens y las posiciones lógicas (secuenciales) se asignan a ubicaciones físicas (dispersas) mediante tablas de bloques. Varias peticiones que comparten un prefijo (system prompts, beam search) pueden apuntar a los mismos bloques físicos.

Los sistemas anteriores desperdiciaban entre el 60 y el 80 % de la memoria del KV cache por fragmentación y preasignación. PagedAttention reduce ese desperdicio a <4 %, lo que permite aumentar el throughput entre 2 y 4x con la misma latencia y hasta 24x frente a HuggingFace Transformers (vLLM Blog, 2023).

15. Speculative decoding: varios tokens por forward pass

En speculative decoding, un modelo draft pequeño genera $K$ tokens candidatos y, a continuación, el modelo target grande puntúa todas las posiciones $K$ en un único forward pass. El decoder acepta los tokens del draft de izquierda a derecha, con probabilidades derivadas de las distribuciones del target y del draft. Tras el primer rechazo, muestrea una corrección de la distribución residual del target y descarta los tokens restantes del draft. Este paso modificado de rejection sampling preserva la distribución de salida del modelo target dentro de la aritmética del hardware; la coincidencia exacta de tokens por sí sola no lo hace.

La mejora es más probable con batches de serving pequeños y longitudes de draft cortas, cuando puntuar el draft está dominado por el tráfico de pesos, KV cache o comunicación, en lugar del cómputo adicional de tokens. El artículo original sobre speculative sampling comunicó una aceleración del decode de 2–2,5x para su configuración probada con Chinchilla 70B; EAGLE-3 comunicó hasta 6,5x en sus pruebas. Entre las variantes están Medusa (cabezas de predicción adicionales, sin un modelo separado), prompt lookup decoding (comparación de n-grams con la entrada sin un forward pass independiente del modelo draft) y EAGLE (extrapolación a nivel de features).

Con tamaños de batch elevados, el trabajo adicional de draft y verificación puede eliminar la mejora. El speculative decoding es más prometedor cuando el batch de serving es suficientemente pequeño y la aceptación del draft es alta; mide el bucle completo de serving, no solo el kernel de verificación.

16. Prefix caching y reutilización del KV cache

En lugar de descartar el KV cache cuando termina una petición, el prefix caching lo conserva para reutilizarlo en nuevas peticiones que compartan los mismos tokens de prefijo. Esto reduce el prefill redundante de system prompts, ejemplos few-shot, contexto RAG e historial de conversaciones de varios turnos.

Automatic Prefix Caching de vLLM aplica hashes a los bloques KV y utiliza una tabla hash global para buscarlos. RadixAttention de SGLang mantiene un árbol radix de tensores KV en caché con granularidad a nivel de token. Ambos dependen de prefijos idénticos a nivel de token, por lo que debes comunicar la tasa de aciertos junto con la latencia o el throughput.

17. Streaming en la práctica

El streaming envía los tokens al cliente a medida que se generan, en lugar de esperar a la respuesta completa. Muchos frameworks de serving lo exponen mediante Server-Sent Events: el cliente abre una conexión HTTP de larga duración y el servidor envía cada token o batch de tokens como un evento data:. TTFT determina cuándo ve el usuario la primera salida; TPOT ayuda a determinar lo fluida que resulta. Establece el objetivo mediante pruebas del producto y según el modelo de interacción elegido.

En el cliente, el streaming obliga a tomar decisiones sobre el buffering. Renderizar token a token puede provocar saltos visuales, especialmente con Markdown o bloques de código que necesitan contexto de varios tokens para formatearse correctamente. Los patrones habituales son el buffering por palabras (acumular tokens hasta encontrar un límite de espacio), el buffering por líneas (esperar a un salto de línea antes de renderizar) y el buffering adaptativo (renderizar inmediatamente la prosa y aplicar buffering a los bloques de código). En la API de OpenAI Chat Completions, stream_options: {"include_usage": true} añade un chunk final de uso antes del mensaje data: [DONE]. Los servidores compatibles con OpenAI pueden comportarse de forma distinta, así que verifica la implementación seleccionada.

Chunked prefill es una forma de evitar que los prefills largos bloqueen la entrega de tokens a usuarios concurrentes. La planificación con prioridad al decode puede proteger las peticiones en curso, mientras que el serving desagregado aísla el prefill y el decode en pools de GPU separados.

Parte IV — Arquitectura del modelo

La arquitectura determina la huella de memoria, el comportamiento de la atención y la dinámica del entrenamiento que las secciones de serving y entrenamiento deben gestionar.

18. Fundamentos de la arquitectura Transformer

Un transformer moderno decoder-only (GPT, Llama) es una pila de capas idénticas, cada una con dos subbloques: atención y feed-forward. Cada subbloque está envuelto por una conexión residual y una normalización. Sus componentes principales son:

La Multi-Head Attention permite que cada token pondere la información de los tokens visibles según la attention mask. La entrada se proyecta en tres matrices: Queries (¿qué estoy buscando?), Keys (¿qué contengo?) y Values (¿qué información transporto?). A continuación se calculan las puntuaciones de atención:

$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$

El producto escalar $QK^T$ mide la similitud entre cada par de tokens. Dividir por $\sqrt{d_k}$ evita que los productos escalares crezcan demasiado (lo que llevaría al softmax a regiones con gradientes que se desvanecen). El softmax convierte las puntuaciones en probabilidades y la multiplicación por $V$ produce una combinación ponderada de los vectores de valores. Ejecutar esto en paralelo en varias cabezas permite que el modelo atienda simultáneamente a relaciones distintas (una cabeza para la sintaxis, otra para la correferencia, etc.).

La Feed-Forward Network (FFN) transforma cada representación de token de forma independiente después de que la atención haya mezclado la información entre tokens. Los LLM modernos suelen utilizar SwiGLU en lugar de la FFN ReLU original de dos matrices:

$\text{SwiGLU}(x) = \left(\text{Swish}(xW_{gate}) \odot xW_{up}\right)W_{down}$

SwiGLU tiene tres matrices de pesos, frente a las dos de una FFN ReLU, y utiliza la función Swish, más suave. Llama, Mistral y Qwen la utilizan; Gemma utiliza una GeGLU aproximada. La regla familiar de los dos tercios se aplica a un bloque convencional con MHA completa y $d_{ff} \approx 4d$: sus dos matrices FFN aportan aproximadamente $8d^2$ parámetros, frente a unos $4d^2$ de la atención. No es una estimación general para arquitecturas SwiGLU/GQA. En Llama 3 8B, $d=4{,}096$, $d_{ff}=14{,}336$ y ocho cabezas key/value hacen que la FFN aporte $3d \times d_{ff} \approx 176$M parámetros por capa, frente a aproximadamente 42M parámetros de proyección de atención: alrededor del 81 % de esos pesos de proyección, antes de embeddings y normalización.

Las conexiones residuales vuelven a sumar la salida de cada subbloque a su entrada: $\text{Output} = \text{Input} + \text{Sublayer}(\text{Input})$. La ruta de salto mejora la propagación de señales y gradientes a través de pilas profundas.

RMSNorm es habitual en las familias modernas de LLM. LayerNorm vuelve a centrar restando la media y reescala mediante la desviación estándar. RMSNorm omite la resta de la media y solo reescala; su artículo comunica aceleraciones del 7–64 % en los modelos probados, sin penalización de rendimiento en esos experimentos. También es habitual situar la pre-norm, que normaliza antes de la atención o de la FFN, porque mejora la estabilidad de los gradientes.

Estimación del número de parámetros de un modelo decoder-only:

$\text{Total} \approx V \times d + 12 \times L \times d^2$

donde $V$ es el tamaño del vocabulario, $d$ es la dimensión oculta y $L$ es el número de capas. El término $V \times d$ es la matriz de embeddings de entrada; el término $12 \times d^2$ aproxima los pesos de atención y FFN de cada capa. Para Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$), la estimación es de unos $0.53B + 6.44B = 6.97B$ parámetros. El total publicado de 8,03B es mayor porque la aproximación omite detalles arquitectónicos como el ancho exacto de la FFN y la proyección de salida independiente.

19. Modelos decoder-only para generación de propósito general

El Transformer original (2017) tenía un encoder y un decoder. Desde entonces, el campo se dividió en tres familias arquitectónicas, y una de ellas se convirtió en el estándar de la AI generativa.

Los modelos encoder-only (BERT, RoBERTa) utilizan atención bidireccional: cada token atiende a todos los demás tokens en ambas direcciones. Esto produce representaciones ricas para tareas de comprensión (clasificación, NER, similitud semántica), pero no pueden generar texto de forma autoregresiva. Los modelos encoder-only siguen siendo habituales como backbone de modelos de embedding, rerankers y clasificadores ligeros (por ejemplo, los routers basados en BERT de RouteLLM).

Los modelos encoder-decoder (T5, BART y el Transformer original) separan comprensión y generación. El encoder procesa toda la entrada con atención bidireccional; después, el decoder genera la salida de forma autoregresiva mientras atiende a las representaciones del encoder mediante cross-attention. Esto ofrecía una ventaja natural para tareas sequence-to-sequence como la traducción, donde la entrada y la salida son secuencias diferentes. T5, de Google, demostró que cualquier tarea de NLP podía formularse como text-to-text, y los modelos encoder-decoder siguen impulsando algunos sistemas especializados (Whisper para reconocimiento de voz y FLAN-T5 para seguimiento de instrucciones).

Los modelos decoder-only (GPT, Llama, Mistral, Gemini) utilizan atención causal (unidireccional): cada token atiende solo a los tokens anteriores. Son habituales para la generación de texto de propósito general porque un único objetivo de modelo de lenguaje causal escala sobre texto no emparejado, mientras que la inferencia trata las instrucciones, las demostraciones few-shot y la consulta como tokens de un mismo prefijo. El bloque decoder repetido también evita una pila encoder separada y una ruta de cross-attention. Los modelos encoder-decoder siguen siendo útiles cuando una tarea se beneficia de codificar la entrada por separado y generar a partir de esa representación, como ocurre en traducción y reconocimiento de voz.

20. Mixture of experts

MoE sustituye la FFN densa de cada capa del transformer por varias FFN expertas más un router de gating ligero. El router calcula una puntuación para cada experta (normalmente un softmax sobre proyecciones lineales aprendidas) y selecciona las $k$ mejores expertas por token. Solo calculan las expertas activadas, de modo que un modelo puede tener una capacidad total enorme manteniendo bajo el coste por token. Se trata de cómputo condicional disperso: el total de parámetros determina lo que el modelo puede representar y los parámetros activos determinan cuánto cuesta ejecutarlo.

La experta compartida de DeepSeek-V3 se activa para cada token. Proporciona una representación de base sobre la que las expertas routed pueden especializarse.

El entrenamiento de MoE presenta tres problemas recurrentes: desequilibrio de carga, colapso de expertas y sobrecarga de comunicación para el expert parallelism. Los modelos MoE tradicionales añaden una loss auxiliar para penalizar el routing desequilibrado, pero esta loss puede competir con el objetivo principal. DeepSeek-V3 utiliza principalmente una estrategia por batch sin loss auxiliar: unos términos de sesgo fuera de backpropagation reducen la puntuación de las expertas sobrecargadas y aumentan la de las infrautilizadas. También aplica una loss de balanceo complementaria, extremadamente pequeña y a nivel de secuencia, para evitar un desequilibrio extremo dentro de una secuencia. El artículo comunica un mejor equilibrio del routing sin el compromiso asociado a la loss auxiliar principal en su configuración.

21. Tokenización: BPE, SentencePiece y tiktoken

Los LLM no ven texto. Ven secuencias de IDs enteros de tokens. Un tokenizer divide el texto en bruto en tokens (fragmentos de subpalabras) y asigna un ID a cada uno. La elección del tokenizer afecta a la calidad del modelo, la velocidad de inferencia y la equidad multilingüe.

Byte Pair Encoding (BPE) es el algoritmo más habitual. Fusiona iterativamente los pares adyacentes más frecuentes del corpus de entrenamiento. Un ejemplo simplificado:

1. Empieza con un vocabulario a nivel de carácter: [l, o, w, e, r, _]
2. El par más frecuente es (l, o) → fusiónalo en lo → vocabulario: [l, o, w, e, r, _, lo]
3. El siguiente par más frecuente es (lo, w) → fusiónalo en low → el vocabulario añade low
4. Continúa hasta que el vocabulario alcanza el tamaño objetivo (por ejemplo, 128K tokens)

Palabras frecuentes como «the» se convierten en tokens individuales, mientras que palabras raras como «defenestration» se dividen en fragmentos de subpalabras como ["def", "en", "est", "ration"]. El compromiso se establece entre el tamaño del vocabulario y la longitud de la secuencia.

Tres implementaciones de tokenizer cubren la mayor parte del uso en producción:

• SentencePiece se entrena directamente sobre texto Unicode en bruto, sin un pre-tokenizer específico del idioma. Conserva los espacios mediante el metasímbolo ▁ y puede recurrir opcionalmente a tokens de bytes UTF-8. Admite modelos BPE y unigram, y lo utilizan Llama 1/2, T5 y Mistral.
• tiktoken es el tokenizer basado en Rust de OpenAI, que utiliza BPE a nivel de bytes. En su benchmark publicado de GPT-2, funcionó 3–6x más rápido que la configuración GPT2TokenizerFast probada. Llama 3 cambió de SentencePiece al algoritmo de tiktoken.
• Hugging Face Tokenizers es una biblioteca ampliamente utilizada basada en Rust que admite BPE, WordPiece y Unigram.

La fertilidad mide cuántos tokens produce un tokenizer por palabra u otra unidad de texto elegida. Varía según el tokenizer exacto, el idioma, la escritura, la normalización, el dominio y la muestra. Mídela sobre tráfico representativo en lugar de extrapolar a partir de un único tokenizer o idioma.

22. Ventanas de contexto y codificaciones posicionales

La ventana de contexto es el número máximo de tokens que un modelo puede procesar en un único forward pass. Ha crecido considerablemente:

La self-attention sin máscara es equivariante a permutaciones: si reordenas los tokens de entrada, sus salidas se reordenan de la misma manera. La máscara causal de un decoder ya limita cada token a su prefijo, por lo que invertir una frase no produce estados ocultos idénticos. Las codificaciones posicionales añaden información explícita sobre la posición y la distancia relativa dentro de ese prefijo visible.

Tres enfoques habituales son:

• RoPE (Rotary Position Embeddings) rota los vectores de consulta y clave mediante ángulos que dependen de la posición, de modo que su producto escalar depende de la posición relativa. El contenido del token sigue determinando la puntuación de atención; RoPE añade información posicional sin embeddings de posición absoluta aprendidos. Lo utilizan familias de modelos open como Llama, Mistral y Qwen.

• ALiBi (Attention with Linear Biases) omite las modificaciones de los embeddings y añade una penalización directamente a las puntuaciones de atención: cuanto más separados están dos tokens, mayor es el sesgo negativo. No tiene parámetros posicionales aprendidos. En el artículo original, un modelo de 1,3B entrenado con secuencias de 1.024 tokens obtuvo un rendimiento comparable con 2.048 tokens al de un modelo con posiciones sinusoidales entrenado con 2.048. El comportamiento más allá de los modelos y longitudes probados en el artículo depende del modelo.

• YaRN (Yet another RoPE extensioN) amplía un modelo RoPE más allá de su contexto de entrenamiento. Agrupa las dimensiones de frecuencia en tres categorías y escala cada una de forma diferente. El artículo comunica 10x menos tokens de fine-tuning y 2,5x menos pasos de entrenamiento que su baseline de interpolación posicional.

Parte V — Entrenamiento y alignment

Esta parte distingue entre el objetivo que crea las capacidades, las técnicas que hacen que el entrenamiento quepa en el hardware disponible y los métodos que dan forma al comportamiento posterior del modelo.

23. Pretraining, fine-tuning y alignment

El pretraining es una predicción autosupervisada del siguiente token sobre un corpus grande. Su cómputo abarca muchos órdenes de magnitud; Llama 3 405B, por ejemplo, utilizó $3.8 \times 10^{25}$ FLOPs. El Supervised fine-tuning (SFT) adapta el modelo preentrenado a datos etiquetados específicos de la tarea. RLHF / RLAIF utiliza datos de preferencias para dar forma al comportamiento: un pipeline convencional de RLHF recopila comparaciones, entrena un reward model y después optimiza la policy. RLAIF sustituye parte de las evaluaciones humanas por feedback generado por AI.

El cómputo depende del tamaño del modelo, la longitud de las secuencias, el volumen de datos, el optimizador y el método. PPO también mantiene más estado del modelo que SFT, porque una configuración habitual incluye los modelos de policy, reference, reward y critic. He cubierto el marco completo de decisión sobre fine-tuning en la Guía de fine-tuning de LLM.

24. LoRA y QLoRA: fine-tuning eficiente en parámetros

LoRA congela los pesos preentrenados e inyecta matrices entrenables de bajo rango $A$ ($r \times k$) y $B$ ($d \times r$), de modo que el peso actualizado es $W_0 + BA$. El artículo de LoRA redujo GPT-3 175B a unos 18 millones de parámetros entrenables en su configuración. El rango es un hiperparámetro de ajuste, no una regla sobre la complejidad de la tarea; selecciónalo mediante un barrido de calidad y memoria. Los adapters de LoRA pueden fusionarse con los pesos base después del entrenamiento para evitar una ruta de adapter independiente en inferencia.

QLoRA carga el modelo base con cuantización NF4 de 4 bits mientras entrena los adapters LoRA en BF16. NormalFloat4 coloca más niveles de cuantización cerca de cero, donde la densidad de pesos es mayor. El artículo hizo fine-tuning de un modelo de 65B en una única GPU de 48 GB y comunicó resultados cercanos a sus baselines de 16 bits. Sus compromisos de runtime y memoria son específicos del stack probado.

25. Entrenamiento con precisión mixta

Cada formato de coma flotante distribuye sus bits entre tres campos: signo (siempre 1 bit), exponente (determina el rango dinámico) y mantisa (determina la precisión). Más bits de exponente implican un rango más amplio de magnitudes representables; más bits de mantisa permiten distinguir mejor entre valores cercanos. Los formatos enteros no tienen exponente y solo representan números enteros equiespaciados dentro de un rango fijo.

BF16 tiene el mismo rango que FP32 porque el rango viene determinado por el campo del exponente, y BF16 conserva los 8 bits de exponente de FP32. En cambio, renuncia a bits de mantisa (7 frente a 23), intercambiando precisión por una reducción de memoria de 2x y evitando muchos problemas de rango que afectan al entrenamiento en FP16. FP16 solo tiene 5 bits de exponente, lo que limita su rango finito a unos 65K. Muchos gradientes son demasiado pequeños para FP16 y sufren underflow hacia cero. Loss scaling multiplica la loss antes de backpropagation para que esos gradientes sigan siendo representables y después deshace la escala antes del paso del optimizador; el escalado dinámico reduce el factor si se produce overflow. El rango de exponente más amplio de BF16 suele evitar esta necesidad.

Los formatos enteros no son habituales para la aritmética principal del entrenamiento porque la backpropagation necesita un rango dinámico amplio. Sí se utilizan mucho en inferencia, donde los pesos congelados pueden mapearse a escalas calibradas. La cuantización de pesos INT4 reduce un modelo de 7B de unos 14 GB a 3,5 GB antes de la sobrecarga del runtime; la calidad debe medirse para el modelo y el método elegidos.

El entrenamiento en FP8 en H100 mediante Transformer Engine utiliza E4M3 cuando importa la precisión y E5M2 cuando importa un rango mayor. El artículo FP8-LM comunica que su framework de precisión mixta entrenó GPT-175B un 75 % más rápido que su baseline BF16 de Megatron-LM y un 37 % más rápido que NVIDIA Transformer Engine en la configuración H100 probada. DeepSeek-V3 utilizó precisión mixta FP8 y comunicó aproximadamente $5,6 millones en cómputo equivalente de alquiler para su entrenamiento final, excluyendo I+D e infraestructura.

26. Gradient checkpointing

Cada capa del forward pass produce una salida intermedia llamada activación:

$\text{Input} \rightarrow [\text{Layer 1}] \rightarrow \text{activation}_1 \rightarrow [\text{Layer 2}] \rightarrow \text{activation}_2 \rightarrow [\text{Layer 3}] \rightarrow \text{output}$

Normalmente, todas las activaciones deben permanecer en memoria porque la backpropagation las necesita para calcular los gradientes. En un transformer profundo, las activaciones almacenadas pueden consumir más memoria que los propios pesos del modelo.

El gradient checkpointing intercambia cómputo por memoria: descarta la mayoría de las activaciones y las recalcula sobre la marcha durante la backpropagation. La estrategia estándar (Chen et al., 2016) divide una red de $n$ capas en $\sqrt{n}$ segmentos equiespaciados y guarda solo la activación límite de cada segmento. Esos límites son los «checkpoints». Todas las activaciones intermedias de un segmento se descartan inmediatamente.

Cuando el backward pass alcanza una capa dentro de un segmento, sus activaciones se recalculan desde el checkpoint más cercano. Con la estrategia de segmentación uniforme, la memoria de activaciones almacenada cae de $O(n)$ a $O(\sqrt{n})$. El ahorro real de memoria y la sobrecarga de recomputación dependen del modelo, los límites de los checkpoints, la longitud de la secuencia, el framework y la implementación, así que mide ambos aspectos en el entrenamiento objetivo. Actívalo en HuggingFace con gradient_checkpointing=True.

27. Etapas de DeepSpeed ZeRO

En el data parallelism estándar, cada GPU contiene una copia completa de los pesos del modelo, los gradientes y los estados del optimizador. Para Adam, cada parámetro ocupa 2 bytes para el peso FP16 + 4 bytes para el peso maestro FP32 + 4 bytes para el momentum + 4 bytes para la varianza + 2 bytes para el gradiente: 16 bytes por parámetro. Un modelo de 7,5B parámetros necesita ~120 GB por GPU y todas las GPU almacenan lo mismo. En 64 GPU son 64 copias idénticas de 120 GB. Un desperdicio considerable.

DeepSpeed ZeRO (Zero Redundancy Optimizer) elimina esta duplicación fragmentando estos componentes entre las GPU en lugar de replicarlos:

• Etapa 1 — particionar los estados del optimizador. Cada GPU almacena solo 1/N de los estados del optimizador (los pesos maestros FP32 y los primeros y segundos momentos de Adam, 12 bytes/parámetro). Cuando una GPU necesita actualizar un peso, actualiza solo su porción y difunde el resultado. Bajo las hipótesis siguientes, la memoria baja de ~120 GB a ~41,3 GB por GPU.
• Etapa 2 — particionar también los gradientes. Los gradientes (2 bytes/parámetro) ya no se reducen y difunden a todas las GPU. Cada GPU recibe solo la porción de gradiente que necesita mediante reduce-scatter. Con las mismas hipótesis, la memoria baja a ~28,1 GB por GPU.
• Etapa 3 — particionar también los pesos del modelo. Cada GPU contiene solo 1/N de los pesos FP16. Antes del forward o backward pass de cada capa, la GPU realiza un all-gather para reconstruir temporalmente los pesos completos de la capa a partir de todas las demás GPU; calcula y descarta los pesos reunidos. Con las mismas hipótesis, la memoria baja a ~15,0 GB por GPU.

Son valores aproximados de estado del modelo para un modelo de 7,5B parámetros en 8 GPU (world size $N=8$), con pesos y gradientes FP16 y pesos maestros, momentum y varianza de Adam en FP32. Excluyen las activaciones, los buffers temporales de all-gather, la fragmentación del allocator y la sobrecarga del framework/runtime. El límite del cálculo es $7.5B \times$ bytes por parámetro, y cada estado se divide entre $N$ solo cuando la tabla indica que está particionado.

El compromiso es la comunicación. La etapa 1 añade una sobrecarga mínima y la etapa 2 sustituye all-reduce por reduce-scatter con un coste similar. La etapa 3 necesita llamadas all-gather antes de cada capa, tanto en el forward como en el backward pass, con aproximadamente 1,5x de volumen de comunicación frente al data parallelism estándar.

ZeRO-Infinity amplía la etapa 3 descargando los estados particionados a la RAM de la CPU e incluso a SSD NVMe, lo que puede hacer posible entrenar modelos con billones de parámetros en clusters de GPU limitados. El offloading al almacenamiento añade costes de PCIe y de transferencia al almacenamiento; su impacto medido depende de la unidad, la topología PCIe, el particionado, el prefetch, el solapamiento de transferencias y la carga de trabajo. Úsalo para satisfacer requisitos de capacidad, no asumas una ralentización fija y perfila la configuración objetivo.

28. FSDP: sharding nativo de PyTorch

Fully Sharded Data Parallel (FSDP) es la respuesta integrada de PyTorch a DeepSpeed ZeRO-3. Fragmenta parámetros, gradientes y estados del optimizador entre las GPU con la misma idea central. La mecánica para cada capa es un bucle sencillo:

1. All-gather de los parámetros completos desde todas las GPU (reconstruir temporalmente la capa completa).
2. Calcular el forward o backward pass de esa capa.
3. Liberar inmediatamente los parámetros reunidos. Cada GPU conserva solo su propio shard.
4. Reduce-scatter de los gradientes para que cada GPU reciba solo su porción asignada.

Como FSDP es nativo de PyTorch, se integra directamente con las herramientas de depuración y profiling de PyTorch y con torch.compile. El rendimiento respecto a DeepSpeed ZeRO-3 depende de la política de wrapping, la topología de comunicación, la configuración de offloading y el tamaño del modelo, así que compáralos en el mismo cluster.

FSDP2 (2024–2025) es una reescritura que mejora la integración con torch.compile para una mejor fusión de kernels, añade soporte de entrenamiento FP8 mediante TorchAO y simplifica la API. Tanto FSDP como DeepSpeed están disponibles a través de HuggingFace Accelerate, lo que permite cambiar entre ellos con una única modificación de configuración.

29. Scaling laws y la trampa de Chinchilla

Chinchilla scaling (DeepMind, 2022) encontró una asignación casi óptima en cómputo de unos 20 tokens de entrenamiento por parámetro bajo sus hipótesis. Ese objetivo no incluye el coste de serving posterior. Si un modelo más pequeño entrenado con más datos alcanza la calidad requerida, puede costar menos a lo largo de un ciclo de vida de inferencia de alto volumen.

Una estrategia de coste de ciclo de vida consiste en entrenar un modelo más pequeño con muchos más datos:

Esta es la proporción de tokens por parámetro mostrada dividida entre el punto aproximado de 20 tokens por parámetro del artículo de Chinchilla. Es una proporción descriptiva, no un multiplicador medido de calidad o coste.

Para un modelo servido a gran escala, invertir más cómputo de entrenamiento en un modelo más pequeño puede reducir el coste de ciclo de vida. Llama 3 8B ilustra la estrategia, pero que resulte ventajosa depende de la calidad necesaria y del volumen de inferencia previsto. «Chinchilla-optimal» se refiere a la eficiencia del cómputo de entrenamiento, un objetivo diferente del coste de ciclo de vida.

30. RLHF, DPO, GRPO y el panorama del alignment

El alignment orienta un modelo preentrenado hacia instrucciones, preferencias y políticas de seguridad deseadas. Por sí solo no garantiza veracidad ni comportamiento seguro. Los métodos siguientes intercambian complejidad de implementación, requisitos de datos, exploración y estabilidad del entrenamiento.

El pipeline clásico de RLHF es: SFT → recopilar pares de preferencias humanas → entrenar un reward model con esos pares → hacer fine-tuning de la policy con PPO (Proximal Policy Optimization). PPO mantiene 4 copias del modelo en memoria simultáneamente (policy, reference, critic/value model y reward model) y es sensible a los hiperparámetros. También es propenso al reward hacking, cuando el modelo explota peculiaridades del reward model, como respuestas verbosas y que suenan seguras, en lugar de mejorar realmente la calidad.

DPO (Direct Preference Optimization) prescinde del reward model aprendido y del bucle de RL online al optimizar directamente una loss sobre pares de preferencias. Esto simplifica el pipeline de entrenamiento. El DPO estándar es offline: entrena con un dataset fijo y no explora respuestas nuevas durante el bucle de actualización. La importancia de esta limitación depende de la tarea y de la cobertura de los datos.

GRPO (Group Relative Policy Optimization, DeepSeek) elimina el critic aprendido de PPO generando varias completions por prompt y utilizando rewards relativos al grupo como baseline. Esto reduce la carga de estado del modelo respecto a una configuración PPO habitual. A diferencia de DPO, GRPO es on-policy: el modelo genera respuestas nuevas durante el entrenamiento. DeepSeek-R1 combina GRPO con RLVR (reinforcement learning from verifiable rewards), utilizando comprobaciones como respuestas matemáticas, compilación de código y tests unitarios. Estos rewards son más fáciles de auditar que una puntuación de preferencias aprendida, pero los tests incompletos y los objetivos proxy también pueden explotarse.

31. Distillation: comprimir conocimiento entre modelos

Knowledge distillation transfiere capacidades de un teacher grande a un student más pequeño. La distillation basada en logits entrena al student para que coincida con la distribución de salida del teacher. La distillation basada en datos hace que el teacher genere ejemplos con los que después se realiza fine-tuning del student. Los métodos basados en datos son habituales en LLM porque pueden funcionar entre arquitecturas y con teachers accesibles solo mediante API, pero su valor está limitado por la calidad del teacher, la cobertura de datos, el filtrado y el coste de generación.

DeepSeek-R1 seleccionó una mezcla de aproximadamente 800.000 ejemplos —unos 600.000 relacionados con razonamiento y 200.000 no relacionados con razonamiento— y la utilizó para hacer distillation de modelos Qwen2.5 y Llama 3 de entre 1,5B y 70B parámetros. En la evaluación del artículo:

• DeepSeek-R1-Distill-Qwen-32B obtiene un 72,6 % en AIME 2024 y un 94,3 % en MATH-500, por encima de las cifras de OpenAI o1-mini comunicadas en el artículo.
• DeepSeek-R1-Distill-Qwen-7B obtiene un 55,5 % en AIME 2024, por encima del resultado de QwQ-32B-Preview del artículo con un modelo más pequeño.

En los experimentos de DeepSeek-R1 con modelos pequeños, la distillation superó al GRPO directo sobre los modelos base probados. Este resultado respalda la distillation para esta configuración, pero no establece una clasificación universal entre distillation y RL.

32. Generación de datos sintéticos

Los datos de entrenamiento generados por LLM se utilizan en varios patrones recurrentes:

• Self-Instruct parte de un conjunto seed pequeño de instrucciones escritas por humanos: el LLM genera nuevas instrucciones, entradas y salidas, que se filtran y se reincorporan al conjunto. El proyecto Alpaca utilizó 52.000 ejemplos generados a partir de 175 seeds. Stanford comunicó una generación de datos inferior a $500 and fine-tuning under$100, lo que situaba el coste de reproducción inicial por debajo de $600; su comparación con GPT-3.5 fue una evaluación limitada del proyecto, no una equivalencia amplia.
• Evol-Instruct (WizardLM) toma instrucciones existentes y las evoluciona iterativamente a lo largo de ejes de complejidad (añadir restricciones, profundizar el razonamiento y hacer los problemas más concretos) para producir ejemplos de entrenamiento progresivamente más difíciles.
• Phi-4 de Microsoft (14B) utilizó datos sintéticos para gran parte del pretraining, incluyendo generación, crítica, autorrevisión e inversión de instrucciones. Su informe técnico compara el rendimiento STEM y de coding resultante con modelos mayores en los benchmarks seleccionados.

El riesgo relevante aquí es el colapso del modelo: cuando los modelos se entrenan recursivamente con datos sintéticos procedentes de generaciones anteriores, las colas de la distribución original desaparecen progresivamente. El modelo sobreestima los patrones comunes y pierde variaciones raras pero importantes (Shumailov et al., 2024). Un estudio independiente de clasificación de Ahrefs tomó una muestra de una página en inglés recién detectada por dominio entre 900.000 páginas en abril de 2025 y clasificó el 74,2 % como páginas con algún texto generado por AI. Ese estudio del proveedor no es un censo de la web. La mitigación empieza por combinar datos sintéticos y reales, filtrar y realizar seguimiento del linaje para poder medir el material generado recursivamente.

Parte VI — Escalado y despliegue

Cuando una carga de trabajo deja de caber o de cumplir su SLO en un único dispositivo, las decisiones son cómo dividir el trabajo, qué runtime ofrece los controles necesarios y si todas las peticiones necesitan el mismo modelo.

33. Cuatro formas de paralelismo

El Tensor Parallelism (TP) divide matrices de pesos individuales entre GPU y normalmente comunica los resultados después de cada capa. Los enlaces intra-nodo rápidos, como NVLink, hacen que sea más práctico dentro de un nodo. Más shards reducen la memoria y el cómputo por dispositivo, pero aumentan la comunicación, así que selecciona el grado mediante un benchmark de latencia.

El Pipeline Parallelism (PP) divide las capas secuencialmente entre las GPU y pasa las activaciones entre etapas. Su patrón de comunicación puede funcionar entre nodos, pero las burbujas del pipeline y los tiempos desiguales de las etapas reducen la utilización. Los despliegues grandes suelen combinar TP dentro de un nodo y PP entre nodos.

El Data Parallelism (DP) replica el modelo de serving para que cada réplica gestione peticiones independientes sin comunicación entre réplicas por petición. Es eficiente cuando el modelo cabe y el tráfico puede equilibrarse. En entrenamiento, DP se combina habitualmente con ZeRO o FSDP para fragmentar el estado.

El Expert Parallelism (EP) distribuye las expertas MoE entre GPU utilizando comunicación all-to-all para el routing de tokens. Su rendimiento depende del equilibrio de tokens, la ubicación de las expertas y la topología del interconnect; el tráfico all-to-all puede convertirse en el cuello de botella dominante.

Heurística inicial de paralelismo:

• El modelo cabe en una GPU: empieza con réplicas independientes y mide el escalado de DP.
• El modelo cabe en un nodo: prueba TP dentro del nodo y replica después el grupo si el tráfico lo requiere.
• El modelo ocupa varios nodos: prueba una combinación de TP y PP teniendo en cuenta el interconnect y el objetivo de latencia.
• Mixture of experts: añade EP solo cuando la ubicación de las expertas lo requiera.

34. Comparativa de frameworks de serving

vLLM ofrece asignación paginada de KV, continuous batching, una API compatible con OpenAI y varios modos de paralelismo. Su compatibilidad con modelos y hardware cambia con frecuencia, así que verifica el modelo objetivo en la matriz de compatibilidad actual.

SGLang combina RadixAttention para reutilizar prefijos, un scheduler personalizado y generación estructurada. Sus mejoras de throughput publicadas dependen de la carga de trabajo y la configuración; compáralo con vLLM y TensorRT-LLM utilizando prompts, salidas, hardware y SLO idénticos.

TensorRT-LLM busca una latencia baja para peticiones individuales mediante fusión de CUDA graphs y optimización de kernels, con soporte nativo para FP8/FP4. Sus cifras publicadas son específicas del hardware y del modelo. El compromiso es una curva de aprendizaje más pronunciada y una superficie de despliegue específica de NVIDIA.

TGI se integra con el ecosistema de Hugging Face y admite varios backends de hardware. Comprueba el estado actual de mantenimiento y funcionalidades del repositorio antes de seleccionarlo para un despliegue nuevo.

Ollama prioriza un flujo de trabajo local sencillo para modelos. Úsalo por comodidad durante el desarrollo; emplea otro stack de serving cuando importen la concurrencia elevada o el control explícito del SLO.

llama.cpp es un runtime portable en C/C++ con rutas para ARM, x86, Metal, CUDA, ROCm y Vulkan. GGUF admite varios niveles de cuantización. El rendimiento varía mucho según el modelo, la cuantización, el contexto y el backend, así que utiliza la herramienta de benchmark local para la máquina objetivo.

35. Selección de GPU para inferencia

La tabla compara características de hardware publicadas. El soporte de precisión del proveedor no hace que las cifras de cómputo máximo sean directamente comparables entre formatos, así que selecciona primero por capacidad de memoria y mide después la carga de trabajo objetivo. Consulta por separado los precios actuales en la nube, porque varían según el proveedor, la región, el compromiso y la disponibilidad.

Selecciona primero por capacidad de memoria y después por throughput medido en el objetivo de latencia. La capacidad de 141 GB de H200 puede simplificar algunos despliegues de modelos grandes, mientras que B200 añade soporte FP4, 180 GB de HBM3e y una generación más nueva de NVLink. Las GPU más pequeñas basadas en GDDR pueden ser económicas para modelos cuantizados cuando sus límites de memoria e interconnect encajan con la carga de trabajo.

AWQ y GPTQ sirven modelos de 4 bits descuantizando las operaciones matriciales compatibles a un formato de cómputo como FP16 o BF16. La compatibilidad y la velocidad siguen dependiendo de la arquitectura del modelo, el formato de cuantización, el backend de serving, el kernel y la GPU; consulta la matriz de soporte del backend y mide el artefacto exacto. Hopper (H100/H200) y Ada (L40S/4090) aceleran FP8 de forma nativa, y Blackwell (B200) añade Tensor Cores nativos para FP4. Todas las GPU de la lista admiten operaciones matriciales INT8.

El decode de LLM suele estar limitado por el ancho de banda de memoria, por lo que la capacidad y el ancho de banda de HBM pueden importar más que los TFLOPS máximos en cargas de serving. Compara las GPU manteniendo constantes el modelo, la precisión, la distribución del batch, la longitud del contexto y el objetivo de latencia.

36. Model cascading y routing

El model routing elige qué LLM gestiona cada consulta según su complejidad o capacidad predicha. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) comunica una reducción de costes del 85 % en su configuración de MT-Bench, manteniendo el 95 % de la calidad de su baseline GPT-4. Que el routing compense depende de los precios actuales, la mezcla de tráfico, los errores del router y el umbral mínimo de calidad.

Los routers van desde clasificadores ligeros hasta jueces basados en LLM. El cascading es la variante secuencial: una consulta empieza en un modelo más barato y escala a otro cuando una función de puntuación rechaza la respuesta. FrugalGPT comunica hasta un 98 % menos de coste o hasta un 4 % más de accuracy en el pool de modelos evaluado. Un cascade de producción necesita criterios de escalado calibrados y monitorización de las consultas que el modelo barato acepta incorrectamente.

Parte VII — Aplicaciones

Las aplicaciones añaden sus propias superficies de fallo. El retrieval puede fallar antes de que empiece la generación, los agentes pueden elegir una acción inválida y un cambio en el prompt puede mejorar una tarea mientras rompe otra.

37. Modelos de embedding frente a modelos generativos

Los modelos de embedding codifican texto en vectores de dimensión fija que capturan su significado semántico. A diferencia de los modelos generativos, que producen secuencias de tokens, generan un único vector denso para la entrada, normalmente con entre varios cientos y varios miles de dimensiones. Sus backbones incluyen transformers encoder-only bidireccionales y modelos derivados de decoder adaptados al aprendizaje de representaciones. Una capa de pooling suele colapsar las representaciones por token en un solo vector mediante mean pooling, un token especial de clasificación o un método last-token específico del modelo. El fine-tuning contrastivo acerca los textos semánticamente similares y aleja los diferentes.

Los sistemas actuales de embedding cubren distintas necesidades de despliegue. Qwen3-Embedding-8B admite dimensiones de salida configurables y muchos idiomas. Gemini Embedding 2 acepta texto, imágenes, vídeo, audio y documentos. pplx-embed-v1-4B estudia embeddings densos de menor precisión. OpenAI text-embedding-3-large admite embeddings acortados mediante su parámetro dimensions. Son ejemplos, no una clasificación: evalúa idioma, modalidad, tarea, dimensión y coste de serving sobre un mismo conjunto de retrieval.

Matryoshka Representation Learning (MRL, Kusupati et al., NeurIPS 2022) hace flexibles las dimensiones de los embeddings. Su nombre procede de las muñecas rusas encajables; MRL estructura un embedding de modo que sus primeras $m$ dimensiones sean tan informativas como un modelo de $m$ dimensiones entrenado de forma independiente. Durante el entrenamiento, MRL agrega losses sobre un conjunto $O(\log d)$ elegido de dimensiones prefijo, normalmente mitades coherentes; el ejemplo de 2.048 dimensiones del artículo utiliza $\{8, 16, \ldots, 1024, 2048\}$. La loss agregada hace que las dimensiones iniciales transporten información semántica general y que las posteriores añadan detalles más precisos.

Después del entrenamiento, un embedding MRL puede truncarse a una dimensión prefijo compatible. OpenAI comunica que text-embedding-3-large con 256 dimensiones supera a text-embedding-ada-002 con 1.536 dimensiones en la comparación MTEB citada. Esto proporciona una reducción de 6x en el almacenamiento bruto de vectores; la latencia de búsqueda y el coste de la base de datos también dependen del índice, los metadatos, los filtros y el hardware.

El modelo de embedding es un componente importante de un pipeline RAG, junto con el parsing, el chunking, la búsqueda, el reranking y la generación. Si no se recupera la evidencia relevante, un generador más potente no puede recuperarla de forma fiable.

38. Arquitectura RAG en producción

Retrieval-Augmented Generation proporciona a un LLM documentos recuperados en el momento de la consulta. Puede aportar evidencia actual o privada ausente de los pesos del modelo, pero el retrieval no garantiza que la respuesta utilice esa evidencia correctamente. Un sistema RAG de producción es un pipeline de varias etapas que necesita una evaluación independiente de cada etapa.

El pipeline de ingesta se ejecuta offline. Primero se parsean los documentos en bruto (PDF, HTML, Markdown y bases de datos) para obtener texto limpio, algo más difícil de lo que parece: el parsing de PDF por sí solo puede perder tablas, cabeceras y formato. Después, el texto se divide en chunks, que se embeben e indexan de forma independiente.

El chunking afecta tanto al recall del retrieval como al contexto disponible para el generador. Los tamaños útiles dependen de la estructura del documento, la granularidad de la consulta y los límites del embedder y del reranker. Los enfoques habituales son el tamaño fijo con solapamiento, la división recursiva siguiendo los límites del documento y el chunking semántico mediante similitud entre embeddings. Compáralos con etiquetas de relevancia a nivel de página o sección, en lugar de adoptar universalmente un único rango de tokens.

Después, cada chunk se embebe con un modelo como los de la sección 37 y se almacena en una base de datos vectorial (Pinecone, Weaviate, Qdrant, pgvector, etc.).

El pipeline de retrieval se ejecuta en tiempo de consulta. Empieza con una baseline medible y añade etapas cuando el análisis de errores demuestre que resuelven un fallo real:

• La búsqueda híbrida combina retrieval vectorial denso con retrieval disperso, como BM25, a menudo mediante Reciprocal Rank Fusion (RRF). La búsqueda densa gestiona paráfrasis semánticas; la dispersa detecta identificadores exactos, códigos de error y acrónimos. Los benchmarks de proveedores comunican mejoras frente a baselines solo vectoriales, pero la magnitud depende del corpus y de las etiquetas de relevancia.
• El reranking pasa los candidatos recuperados por un modelo que puntúa conjuntamente la consulta y el documento. Puede mejorar la relevancia fina a costa de otra llamada al modelo. El número de candidatos, el número conservado y la latencia deben ajustarse conjuntamente. He cubierto el pipeline completo de varias etapas en Building a Modern Search Ranking Stack.
• La transformación de consultas reescribe la consulta del usuario antes del retrieval para mejorar el recall. HyDE (Hypothetical Document Embeddings) hace que el LLM genere una respuesta hipotética, que después se embebe y se utiliza para el retrieval. La expansión multi-query genera varias formulaciones de la misma pregunta. El step-back prompting plantea primero una pregunta más general para recuperar un contexto más amplio.

Los modos de fallo habituales son:

• Fallo de retrieval — el documento correcto existe, pero no se recupera. Prueba el chunking, la transformación de consultas, la búsqueda híbrida y el filtrado de metadatos frente al fallo.
• Envenenamiento del contexto — los chunks irrelevantes recuperados inducen a error al LLM. Prueba el reranking, los filtros de contexto y conjuntos conservados más pequeños.
• Lost-in-the-middle — en las configuraciones probadas de question answering multi-documento y retrieval de pares clave-valor, Liu et al. encontraron que el rendimiento de las respuestas era generalmente mayor cuando la información relevante aparecía cerca del principio o del final de la entrada, y menor cuando aparecía en el centro.

GraphRAG (Microsoft, 2024) amplía el retrieval vectorial con un grafo de entidades y relaciones extraído. Su objetivo son preguntas a nivel de corpus y con muchas relaciones que el retrieval plano de chunks puede no detectar. El compromiso es el trabajo adicional de extracción, indexación, almacenamiento y evaluación.

Las guías para practitioners publican rangos de latencia para embedding, búsqueda, reranking y generación, pero esas cifras varían según la región, el corpus, el hardware y el modelo. Mide cada etapa en trazas y evalúa el cambio de calidad antes de aceptar la latencia adicional.

39. Arquitecturas de agentes y tool calling

Los agentes LLM utilizan modelos para seleccionar y secuenciar tool calls alrededor de un estado que evoluciona. Tres patrones de orquestación útiles son:

• ReAct — intercala la selección de acciones con observaciones. Puede adaptarse después de cada tool result, pero un historial creciente aumenta el coste en tokens y latencia.
• ReWOO — planifica tool calls con placeholders, ejecuta en paralelo el trabajo independiente y después sintetiza. Su artículo comunica ahorro de tokens frente a ReAct, pero el plan fijo necesita una ruta explícita de recuperación cuando falla una herramienta.
• Planner-executor — separa planificación y ejecución, y puede añadir una policy de replanning tras un fallo. Permite especializar modelos, pero añade estado de orquestación y otro punto de decisión.

El function calling es un mecanismo habitual para invocar herramientas. Las APIs exponen definiciones de herramientas y devuelven argumentos estructurados, lo que reduce la necesidad de parsear texto libre. Los argumentos válidos según el schema aún pueden seleccionar la herramienta equivocada o contener valores no válidos. El parallel function calling puede reducir los round trips cuando las operaciones son independientes.

Los structured outputs y el constrained decoding imponen un schema restringiendo los tokens disponibles en cada paso de generación. Engines como xgrammar, utilizados en vLLM y SGLang, pueden eliminar muchos fallos de sintaxis y parsing con una sobrecarga baja en configuraciones compatibles. No garantizan que los valores extraídos o las decisiones sean correctos. Schema-Guided Reasoning (SGR) utiliza el orden de los campos y la estructura del schema para hacer inspeccionable el estado intermedio antes de la decisión final. Sus tres patrones son Cascade (pasos secuenciales), Routing (union types como conmutadores semánticos) y Cycle (listas acotadas).

La calidad de selección de herramientas, la latencia de extremo a extremo y el coste en tokens suelen empeorar a medida que crecen el conjunto de herramientas y la profundidad de las acciones. Mide esas curvas con las descripciones de herramientas y la distribución de fallos reales. Frameworks como LangGraph pueden hacer explícitos el estado y las rutas de recuperación, pero no eliminan la necesidad de evaluar.

40. Prompt engineering para producción

El prompting en producción es un problema de evaluación: cambia una parte del prompt o del contexto y mide después la calidad de la tarea y los modos de fallo. Las técnicas siguientes son puntos de partida habituales, no un orden universal.

Los ejemplos few-shot suelen ser eficaces para controlar el formato de salida. Empieza con 3–5 ejemplos que cubran entradas vacías, consultas ambiguas y respuestas con varias partes, y mide el resultado sobre un conjunto reservado. Los ejemplos deben cubrir la distribución real de entradas, no solo el happy path. Más ejemplos consumen contexto y no garantizan mejoras adicionales.

El prompting de chain-of-thought (CoT) pide al modelo que exponga el razonamiento intermedio antes de responder. Kojima et al. comunicaron mejoras con el sufijo «Let’s think step by step» en las tareas de razonamiento probadas, pero el efecto varía según el modelo y las APIs de reasoning más recientes pueden no exponer las trazas ocultas. En producción, es preferible una descomposición de tareas inspeccionable o una justificación concisa cuando resulte útil para el evaluador. La self-consistency (Wang et al., 2023) muestrea varias rutas de razonamiento y agrega las respuestas, intercambiando coste de inferencia adicional por robustez en tareas adecuadas.

El structured output con schemas JSON explícitos (sección 39) elimina muchos fallos de parsing. Los engines de constrained decoding, como xgrammar, pueden imponer la gramática compatible durante la generación; la exactitud factual y la validez semántica siguen necesitando evaluación, y puede ser necesario gestionar las funcionalidades de schema no compatibles.

El prompt chaining divide una tarea en etapas centradas, por ejemplo: clasificar la intención → recuperar contexto → generar respuesta → validar la salida. Puede localizar fallos, permitir modelos diferentes por etapa y exponer estado intermedio cacheable. También añade interfaces y latencia, por lo que debes compararlo con una baseline de una sola llamada.

La temperatura cambia la distribución de muestreo. Los valores bajos son un punto de partida razonable para clasificación o extracción; los valores más altos pueden aumentar la diversidad en tareas de ideación. El comportamiento exacto varía entre APIs de modelo e interactúa con top_p, top_k y los valores por defecto del proveedor, así que explora los ajustes compatibles para la tarea en lugar de copiar un rango único.

La separación entre mensajes de sistema y de usuario mantiene la policy persistente separada del contenido de cada petición. Las plantillas de chat y el instruction tuning asignan prioridades diferentes a estos roles, pero no convierten un mensaje de sistema en una frontera de enforcement. Coloca el comportamiento estable en el mensaje de sistema, mantén los datos no confiables en el contenido de usuario o de herramientas y aplica también fuera del modelo las restricciones estrictas, como la eliminación de PII.

El context engineering amplía el trabajo sobre prompts a la composición de documentos recuperados, tool results, historial de conversación y ejemplos. Liu et al. encontraron un efecto lost-in-the-middle en los modelos de contexto largo que probaron, por lo que la posición debe formar parte de la evaluación en lugar de considerarse irrelevante. He cubierto el flujo de trabajo más amplio en Context Engineering for AI Agents.

Parte VIII — Operaciones en producción

Las operaciones en producción convierten los conceptos anteriores en límites de admisión, pruebas de carga, alertas y decisiones de capacidad bajo tráfico real.

41. Rate limiting para peticiones de coste variable

El rate limiting tradicional basado en peticiones por segundo presupone un coste aproximadamente igual por petición. Los LLM rompen esa hipótesis. Un prompt de clasificación de 10 tokens y un análisis documental de 100K tokens llegan al mismo endpoint de API, pero difieren en coste en cuatro órdenes de magnitud. Limitar por RPS permite que las peticiones caras pasen sin control o bloquea innecesariamente las baratas.

Los sistemas de producción necesitan rate limiting basado en tokens en varias dimensiones. OpenAI documenta límites de peticiones y tokens por nivel de uso. Anthropic separa los límites de tokens de entrada y de salida. Las cuotas y los algoritmos exactos pueden cambiar, así que trata la documentación del proveedor como fuente de verdad; el punto arquitectónico es presupuestar de forma independiente peticiones y tokens.

El patrón práctico de implementación es una jerarquía de límites multidimensional (usuario → aplicación → organización → global), con niveles de prioridad para el acceso premium. A nivel de petición, la técnica importante es reservar el presupuesto de tokens: estimar el total de tokens (entrada + max_tokens) al admitir la petición, descontarlo del bucket y ajustarlo al completarse con el uso real. Esto evita que una ráfaga de peticiones con generaciones largas agote la capacidad antes siquiera de empezar a producir salida.

En despliegues self-hosted, el equivalente es el throughput provisionado: reservar capacidad de GPU dedicada para tasas objetivo de tokens. En despliegues de vLLM, esto implica configurar el control de admisión alrededor de los slots de decode activos y de la presión del KV cache, no solo del número de peticiones. Como explica la sección 5, tanto el throughput como la admisión necesitan límites conscientes de los tokens.

42. Modos de fallo frente a los que diseñar

El serving de LLM añade modos de fallo vinculados a la longitud variable de las secuencias, la memoria KV y el trabajo de decode de larga duración. Diseña y prueba bajo carga las defensas antes de que el tráfico de producción dependa de ellas.

El Out-of-Memory (OOM) es un fallo habitual. Un modelo 70B en FP16 necesita aproximadamente 140 GB solo para los pesos, y el KV cache de una única secuencia de Llama 3.1 70B con contexto 128K puede añadir unos 40 GB bajo las hipótesis de la sección 6. La distancia entre «cabe en memoria» y «produce OOM bajo carga» es menor de lo que parece, porque un batch de peticiones con contexto largo puede consumir más memoria KV de la prevista. La prevención combina una reserva de memoria medida con cuantización y asignación paginada de KV. Para cargas con mucha presión sobre el KV, LMCache puede descargar datos KV a memoria de la CPU o al disco; utiliza sus resultados publicados como punto de partida y mide la jerarquía de memoria local.

La preemption ocurre cuando la presión del KV cache obliga al scheduler a expulsar o recomputar trabajo. La estrategia exacta depende de la versión y la configuración del serving. Desde el punto de vista del usuario, el síntoma es una latencia de extremo a extremo mayor sin un error evidente de la aplicación. Observa los recuentos de preemption y correlaciónalos con el uso de KV, la profundidad de la cola y las longitudes de las peticiones.

La latencia de cola puede dispararse cuando los prefills grandes retrasan el trabajo de decode. El chunked prefill (sección 7) y la planificación consciente de la longitud intentan limitar esta interferencia. Los artículos sobre el scheduler Learning-to-Rank y CascadeInfer comunican mejoras frente a sus baselines en las cargas evaluadas, pero el resultado exacto depende de la distribución de longitudes de las peticiones y de la configuración del scheduler.

Los fallos en cascada pueden comenzar cuando las peticiones lentas hacen crecer la cola, los clientes upstream agotan el tiempo de espera y los reintentos añaden más carga. Entre las defensas están el control de admisión, los límites de concurrencia por tenant, los límites de salida, los presupuestos de reintentos y los circuit breakers del gateway. Los pools de prefill y decode desagregados pueden ayudar cuando las pruebas de carga muestran una interferencia persistente entre fases.

43. Monitorización de sistemas LLM

La monitorización de LLM se diferencia de la monitorización de APIs tradicional en varios aspectos básicos. Cada petición tiene un coste variable, dos fases distintas con cuellos de botella diferentes y una huella de memoria que depende tanto de la longitud de entrada como de la de generación. Las métricas estándar, como la latencia y la tasa de errores, no capturan la mayor parte de lo importante.

Goodput es el número de peticiones por segundo que cumple todos los umbrales de SLO definidos, como TTFT, TPOT y latencia total. Es una medida combinada útil porque el throughput bruto puede parecer saludable mientras fallan los SLO de latencia: un sistema que procesa 100 peticiones por segundo, pero incumple sus umbrales en el 40 % de ellas, tiene un goodput de 60 peticiones por segundo. Optimizar para goodput mantiene visible la distribución del rendimiento en lugar de informar solo de la media.

vLLM expone un endpoint Prometheus en /metrics con peticiones en ejecución y en espera, uso del KV cache, distribuciones de longitud de generación y estadísticas de prefix cache. Los nombres de las métricas pueden cambiar entre versiones, así que vincula los dashboards a la versión desplegada. Un stack habitual utiliza Prometheus para las métricas, Grafana para la visualización y trazas compatibles con OpenTelemetry entre los componentes de aplicación y serving.

Entre los patrones de alerta útiles están los siguientes. Deriva sus umbrales de las pruebas de carga en lugar de copiar estos ejemplos sin cambios:

• Se disparan los recuentos de preemption — el runtime está intercambiando o recomputando trabajo, lo que añade latencia sin un error de aplicación.
• La utilización del KV cache se acerca a la región de preemption probada — añade capacidad o reduce carga antes de que las expulsiones se propaguen.
• La profundidad de la cola permanece por encima del envelope de batch probado — el control de admisión debería empezar a rechazar o degradar la prioridad.
• TTFT aumenta mientras TPOT permanece plano — esta divergencia apunta primero a colas, admisión, red o presión de prefill, no al throughput de decode. Utiliza trazas y métricas de cola para distinguirlos.

44. Optimización de costes: una estrategia acumulativa

Los precios de los proveedores y las proporciones de precio entre entrada y salida cambian. Consulta las tarifas actuales antes de decidir una compra; el tier del modelo y la longitud de salida pueden dominar la factura incluso antes de optimizar la infraestructura.

Se pueden combinar varios enfoques, pero solo después de medir cuáles se aplican a la carga de trabajo:

1. La cuantización de FP16 a INT4 reduce la memoria de pesos un 75 %. Que eso reduzca la factura depende de la velocidad del kernel, el tamaño del batch y la utilización del hardware (sección 9).
2. El model routing envía el tráfico elegible a modelos más baratos. Mide la tasa de falsos positivos del router y la calidad de extremo a extremo antes de aumentar la proporción gestionada por el modelo barato (sección 36).
3. El prompt caching reduce el trabajo de prefijos repetidos. Los descuentos del proveedor y el tratamiento en el rate limiting cambian con el tiempo, así que combina la tasa de aciertos medida con las condiciones actuales (sección 16).
4. Las batch APIs pueden ofrecer descuentos para trabajo no interactivo, como evaluaciones, generación de datos sintéticos y clasificación masiva. Comprueba los precios y las ventanas de finalización actuales.
5. El self-hosting puede resultar ventajoso con una utilización sostenida, pero no existe un punto de equilibrio universal por volumen de tokens. Incluye los costes de ingeniería, orquestación, observabilidad, margen de capacidad y guardias, además del alquiler de GPU.

Multiplicar los factores ilustrativos produce una gran reducción teórica, pero los inputs no son independientes: la cuantización cambia el throughput, el routing cambia la mezcla de calidad y el caching y el batching solo se aplican al tráfico elegible. Construye la estimación a partir de cuotas de tráfico medidas y valídala frente a la factura.

45. Planificación de capacidad y autoscaling

La planificación de capacidad para serving de LLM debe tener en cuenta el coste variable de las peticiones, el trabajo de decode de larga duración y la memoria dependiente de la secuencia. Según la carga, el recurso limitante puede ser la memoria KV, el ancho de banda de memoria, el cómputo o el interconnect.

El techo teórico de peticiones concurrentes viene dado por el presupuesto del KV cache:

$\text{max concurrent sequences} = \frac{\text{GPU memory} - \text{model weights} - \text{overhead}}{\text{per-sequence KV cache size}}$

Para los cálculos de capacidad, supón que el runtime expone un presupuesto de KV de 40 GiB para Llama 3.1 70B con un KV cache FP16. Cada secuencia de 4K utiliza aproximadamente 1,25 GiB y cada secuencia de 128K unos 40 GiB. Por tanto, ese presupuesto admite como máximo unas 32 secuencias de 4K o una secuencia de 128K antes de tener en cuenta la sobrecarga del allocator, el runtime, la variabilidad de la carga y el SLO. Por eso la selección de GPU y la optimización del KV cache impulsan directamente el plan de capacidad.

La fórmula de capacidad para dimensionar la flota es:

$\text{required GPUs} = \frac{\text{peak tokens/s} \times \text{safety-factor multiplier}}{\text{per-GPU tokens/s at target SLO}}$

Convierte ambas tasas a la misma unidad temporal antes de dividirlas. El detalle importante es «en el SLO objetivo». Un multiplicador de margen de seguridad como 1,3 reserva un 30 % de holgura; elígelo a partir de la intermitencia medida, los fallos y el tiempo de recuperación. El throughput máximo de tokens y el throughput que cumple el SLO pueden diferir mucho cuando aumenta la concurrencia. Mide con la distribución real de longitudes de prompt y salida, y con los umbrales TTFT y TPOT requeridos, en lugar de utilizar un máximo teórico.

La utilización de GPU no basta como única señal de autoscaling, porque puede mantenerse alta tanto durante un procesamiento saludable como durante una sobrecarga. Combínala con la profundidad de la cola, la utilización del KV cache y la degradación del goodput. Ajusta los umbrales a partir de pruebas de carga; valores como el 80 % de utilización del KV son puntos de partida, no límites universales. Estas métricas se introducen en la sección 43.

El scale-to-zero puede encajar en entornos de desarrollo y staging con largos periodos de inactividad. Las plataformas de inferencia serverless y los autoscalers basados en Kubernetes, como KEDA, pueden eliminar capacidad ociosa, pero el ahorro y el tiempo de cold start dependen del tamaño del modelo, el caching de la imagen y de los pesos, y la infraestructura. Mide el tiempo de arranque antes de utilizar la misma policy para tráfico de producción sensible a la latencia.

Utiliza la guía para elegir la siguiente medición

Los conceptos interactúan, pero aun así producen un conjunto pequeño de mediciones iniciales útiles. La demanda del KV cache limita el tamaño del batch junto con la memoria de los pesos, la sobrecarga del runtime y las longitudes de las peticiones. Los batches más grandes pueden aumentar la intensidad aritmética, mientras que el continuous batching incrementa la actividad de asignación de KV y PagedAttention reduce la fragmentación resultante.

En el lado del entrenamiento, el coste de ciclo de vida puede favorecer entrenar un modelo más pequeño con más tokens, como ilustra Llama 3 8B. GRPO reduce la carga de estado del critic de PPO. En la configuración probada de DeepSeek-R1 con modelos pequeños, la distillation superó al RL directo. Son opciones que evaluar, no una receta.

El routing, el caching, la cuantización y la elección de hardware solo se acumulan cuando cada uno se evalúa frente al mismo objetivo de calidad y latencia. Elige un síntoma, establece esa baseline y haz que el siguiente cambio sea fácil de revertir.

Lecturas adicionales

Análisis detallados relacionados de este blog, organizados por tema:

• Guía de fine-tuning de LLM — cuándo hacer fine-tuning frente a usar RAG o prompt engineering
• Variantes de LLM open source y formatos de archivo — cómo asociar variantes de modelos y formatos cuantizados al hardware
• Guía de LoRAX Serving — servir miles de adapters LoRA en producción
• Escalado de Large Language Models — estrategias multi-GPU y multi-nodo
• LLM locales en macOS — configuración práctica con llama.cpp y Ollama
• Bucles de razonamiento de AI Agent en 2026 — análisis detallado de los bucles ReAct, ReWOO y planner-executor
• Arquitectura de memoria de AI Agent en 2026 — checkpoints, vector stores y memoria documental para agentes con estado

Referencias

Organizadas por área temática.

Inferencia y atención

• FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness - Dao et al., NeurIPS 2022
• FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning - Dao, 2023
• FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision - Shah et al., NeurIPS 2024
• Flash-Decoding for long-context inference - Dao et al., 2023
• Efficient Memory Management for Large Language Model Serving with PagedAttention - Kwon et al., SOSP 2023
• Orca: A Distributed Serving System for Transformer-Based Generative Models - Yu et al., OSDI 2022
• GQA: Training Generalized Multi-Query Attention - Ainslie et al., 2023
• Triton: an intermediate language and compiler for neural network computations - Tillet et al., MAPL 2019
• FlashNorm: Fast Normalization for LLMs - 2024
• Deep Kernel Fusion for Transformers - DeepFusionKernel, 2026

Speculative decoding

• Accelerating Large Language Model Decoding with Speculative Sampling - Chen et al., 2023
• EAGLE-3: Scaling up Inference Acceleration of Large Language Models - Li et al., NeurIPS 2025
• Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads - ICML 2024

Cuantización

• AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration - MLSys 2024 Best Paper
• GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers - Frantar et al., ICLR 2023
• Marlin: Mixed-Precision (FP16xINT4) LLM Inference Kernel - Frantar et al., 2024

Entrenamiento y fine-tuning

• LoRA: Low-Rank Adaptation of Large Language Models - Hu et al., ICLR 2022
• QLoRA: Efficient Finetuning of Quantized LLMs - Dettmers et al., NeurIPS 2023
• ZeRO: Memory Optimizations Toward Training Trillion Parameter Models - Rajbhandari et al., SC20
• ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning - Rajbhandari et al., 2021
• Self-Instruct: Aligning Language Models with Self-Generated Instructions - Wang et al., ACL 2023
• WizardLM: Empowering Large Language Models to Follow Complex Instructions - Xu et al., ICLR 2024
• Phi-4 Technical Report - Microsoft, 2024
• AI models collapse when trained on recursively generated data - Shumailov et al., Nature 2024

Alignment

• Direct Preference Optimization: Your Language Model is Secretly a Reward Model - Rafailov et al., NeurIPS 2023
• DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models - Introdujo GRPO
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning - DeepSeek, 2025

Escalado y arquitectura

• The Llama 3 Herd of Models - Meta, 2024
• LLaMA: Open and Efficient Foundation Language Models - Touvron et al. (Meta), 2023
• Llama 2: Open Foundation and Fine-Tuned Chat Models - Touvron et al. (Meta), 2023
• Qwen3 Technical Report - Qwen Team (Alibaba), 2025
• Training Compute-Optimal Large Language Models - Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer: Enhanced Transformer with Rotary Position Embedding - Su et al., 2021
• YaRN: Efficient Context Window Extension of Large Language Models - Peng et al., ICLR 2024
• SGLang: Efficient Execution of Structured Language Model Programs - Zheng et al., NeurIPS 2024
• Mixtral of Experts - Jiang et al. (Mistral AI), 2024

Embeddings

• Matryoshka Representation Learning - Kusupati et al., NeurIPS 2022
• pplx-embed-v1: Diffusion-Pretrained Dense and Contextual Embeddings - Perplexity AI, 2026

Arquitecturas de agentes

• ReAct: Synergizing Reasoning and Acting in Language Models - Yao et al., ICLR 2023
• ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models - Xu et al., 2023

Routing

• RouteLLM: Learning to Route LLMs with Preference Data - Ong et al., ICLR 2025

Benchmarks

• MLPerf Inference v5.0 Results - MLCommons, abril de 2025

Arquitecturas de serving

• Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve - Agrawal et al., OSDI 2024 (Chunked prefill)
• Splitwise: Efficient Generative LLM Inference Using Phase Splitting - Patel et al., ISCA 2024 (Disaggregated Serving)
• DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving - Zhong et al., OSDI 2024 (Disaggregated Serving)

Frameworks de serving

• vLLM - Motor de serving basado en PagedAttention
• SGLang - RadixAttention y generación estructurada
• TensorRT-LLM - Inferencia optimizada de NVIDIA
• llama.cpp - Inferencia portable en C/C++
• DeepSpeed - Biblioteca de entrenamiento distribuido de Microsoft
• Ollama - Runner local de LLM

Operaciones

• Efficient LLM Scheduling by Learning to Rank - Fu et al., NeurIPS 2024 (vLLM-LTR)
• CascadeInfer: Length-Aware Scheduling of LLM Serving with Low Latency and Load Balancing - Yuan et al., 2025
• Goodput metric as measure of ML productivity - Google Cloud, 2024
• vLLM Optimization and Tuning - Documentación de vLLM
• vLLM Metrics - Documentación de vLLM
• LMCache: KV Cache Management for LLM Serving - Offloading del KV cache
• OpenAI Rate Limits - Documentación de OpenAI API
• Anthropic Rate Limits - Documentación de Anthropic API