2026-03-13 · Actualizado 2026-07-15

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

LLM Guía de ingeniería: 45 conceptos sobre inferencia, entrenamiento, arquitectura y operaciones

Los sistemas de producción LLM integran simultáneamente recursos provenientes del hardware GPU, de la ingeniería de sistemas y de la teoría ML. Ese mismo conjunto reducido de conceptos es relevante tanto al ajustar parámetros de TTFT para un chatbot como al configurar DeepSpeed ZeRO para una ejecución fine-tuning. Esta guía los reúne en un único lugar.

TL;DR: Esta referencia abarca 45 conceptos distribuidos en ocho secciones, que van desde el hardware y la inferencia hasta el entrenamiento, el despliegue y las operaciones. Cada entrada define el concepto, explica su impacto práctico, incluye cifras cuando estas ayudan a comprender la escala del fenómeno, y establece enlaces hacia secciones relacionadas. Los datos citados corresponden al período comprendido entre 2024 y principios de 2026.

Esta guía parte de la presunción de que el lector ya cuenta con conocimientos básicos sobre ML (retropropagación, descenso de gradiente, softmax), así como de nociones fundamentales sobre sistemas informáticos (jerarquías de memoria, conceptos básicos de redes).

[!NOTE] Una nota sobre el alcance

Se trata de una referencia extensa, no de un tutorial lineal. Utilice la tabla a continuación para acceder a la sección que corresponda a su decisión actual.

Cómo utilizar esta guía como centro de referencia

Esta página está diseñada de forma intencionadamente amplia. Úsala como mapa inicial y, una vez que la decisión adquiera mayor claridad, dirígete a las publicaciones más detalladas.

La estrategia que genera los mayores rendimientos suele ser la siguiente: identificar el cuello de botella, seleccionar la pila tecnológica más reducida capaz de abordarlo con la carga de trabajo real, benchmark, y luego añadir complejidad únicamente donde los datos lo justifiquen.

Parte I — Fundamentos de hardware

Los conceptos que se presentan aquí —la intensidad aritmética, la jerarquía de memoria GPU y los términos relacionados con el hardware— aparecen en todas las demás secciones de esta guía.

1. Limitaciones por memoria frente a limitaciones por cálculo y el modelo roofline

El punto de partida para evaluar el rendimiento de LLM es la intensidad aritmética: por cada byte de datos que el GPU carga desde la memoria, ¿cuántos cálculos útiles se realizan? Esa relación determina si una operación es limitada por el procesamiento (debido a la espera del procesador) o limitada por la memoria (debido a la espera a que se carguen los datos).

Cada GPU dispone de un umbral de “intensidad crítica” en el que su capacidad de cálculo equilibra exactamente su ancho de banda de memoria. En el caso de una NVIDIA H100 (Ficha técnica, 2023):

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

Las dos fases de la inferencia de LLM se encuentran en lados opuestos de este umbral:

• La decodificación está limitada por la memoria. Al generar tokens uno por uno, es necesario cargar la matriz de pesos de varios gigabytes desde la memoria para multiplicarla con cada nuevo token. En un análisis simplificado de 16 bits y lote único, la operación requiere aproximadamente 1 FLOP/byte, lo que representa casi 300 veces menos que el umbral máximo del H100. Esta diferencia explica por qué la decodificación no puede alcanzar el rendimiento computacional óptimo en este escenario.
• Prefill está limitado por el procesamiento. Al procesar la entrada prompt, los pesos se cargan una sola vez, pero se multiplican simultáneamente contra cientos o miles de tokens. La intensidad de cálculo supera con creces los 295 y satura las unidades de procesamiento.

Por lo tanto, para acelerar la decodificación, es necesario trabajar en el ancho de banda de memoria: reducir el tamaño de los pesos con cuantización, reducir la sobrecarga de memoria KV mediante GQA y PagedAttention, y aumentar la intensidad con procesamiento por lotes. Para acelerar prefill, es necesario trabajar en la computación bruta: realizar operaciones de GPUs y FP8 más rápidas.

2. Jerarquía de memoria GPU

Un GPU cuenta con cuatro capas de memoria dispuestas en forma de pirámide: una memoria principal grande pero lenta (HBM) en la base, y registros diminutos pero extremadamente rápidos en la cima. El movimiento de datos hacia arriba y hacia abajo por esta pirámide representa el principal cuello de botella. El obstáculo más severo se encuentra entre HBM y la SRAM, ya que esta última es aproximadamente 10 veces más rápida.

De más rápido a más lento en un H100:

1. Registros — la memoria más rápida, conectada directamente a los hilos de procesamiento. Aquí es donde realmente se ejecutan las operaciones matemáticas; los datos deben cargarse aquí para que los Tensor Cores puedan utilizarlos.
2. SRAM (Memoria compartida) — la memoria de trabajo con una velocidad aproximada de 33 TB/s.
3. Cache L2 — una capa intermedia de 50 MB con una velocidad cercana a los 12 TB/s. Funciona como búfer para que, cuando varios SM necesiten los mismos pesos, no tengan que buscarlos todos en HBM.
4. HBM3 — la memoria principal de 80 GB que almacena los pesos del modelo y KV cache, con una velocidad de ~3.35 TB/s.

FlashAttention, la fusión de kernels y PagedAttention reducen el tráfico entre estas capas. Permiten mantener los datos en la SRAM rápida durante más tiempo y evitan transferencias repetidas a HBM.

3. Glosario de hardware GPU

Los términos que se indican a continuación aparecen a lo largo de todo el resto de la guía.

HBM (Memoria de alta ancho de banda) — Celdas DRAM apiladas conectadas mediante vías a través del silicio (TSVs), montadas dentro del paquete junto a la celda GPU. Generaciones: HBM2e (A100, 2 TB/s), HBM3 (H100, 3,35 TB/s), HBM3e (H200/B200, 4,8–8 TB/s). La razón por la que esto es relevante para LLMs es que la decodificación está limitada por el ancho de banda de la memoria; por lo tanto, el ancho de banda de HBM determina directamente el TPOT.

GDDR (Graphics DDR) — Memoria gráfica tradicional (GDDR6, GDDR6X) utilizada en tarjetas gráficas para consumo GPUs (RTX 4090, L40S). Presenta un ancho de banda inferior al de HBM, pero es más económica por GB. La versión GDDR6X en RTX 4090 Ofrece aproximadamente 1 TB/s, frente a los 3,35 TB/s de HBM3 del H100.

SM (Streaming Multiprocessor): es la unidad de cálculo básica de NVIDIA GPUs. Cada SM incluye núcleos CUDA, Tensor Cores, memoria compartida (SRAM) y un planificador de warps. H100 cuenta con 132 SMs; A100 cuenta con 108.

Tensor Cores: unidades especializadas en multiplicación y acumulación de matrices integradas dentro de cada SM. Estas aceleran las operaciones de multiplicación de matrices de precisión mixta (FP16, BF16, FP8, INT8), que son fundamentales en los cálculos de los modelos transformadores. Los Tensor Cores del H100 ofrecen 989 TFLOPS en TF32 frente a los ~67 TFLOPS que solo ofrecen los núcleos de CUDA.

CUDA Núcleos — Unidades de punto flotante e enteros de uso general. Estas se encargan de las operaciones elemento a elemento, las funciones de activación y las tareas que no implican multiplicación matricial. Los Tensor Cores realizan la mayor parte del trabajo relacionado con LLMs; los núcleos CUDA se ocupan de todo lo demás.

Warp — Un grupo de 32 hilos que se ejecutan sincrónicamente en un SM. Es la unidad de programación más pequeña en NVIDIA GPUs. Especialización de deformación Asigna distinto tipo de deformaciones a tareas diferentes (carga de datos frente a cálculos) con el fin de implementar un procesamiento en tubería.

NVLink: interconexión de alta velocidad entre GPU y GPU dentro de un nodo. NVLink 4.0 (H100) ofrece una velocidad bidireccional de 900 GB/s; NVLink 5.0 (B200) alcanza los 1,8 TB/s. Es esencial para el paralelismo de tensores, ya que GPUs debe intercambiar activaciones en cada capa.

InfiniBand — Estructura de red de alta velocidad para la comunicación entre nodos GPU. NVIDIA ConnectX-7 Ofrece 400 Gb/s por puerto. Se emplea para lograr pipeline de paralelismo y para el entrenamiento distribuido entre nodos.

RDMA (Acceso Directo a Memoria Remota) — Permite que un GPU lea/escriba en la memoria de otro equipo sin pasar por el CPU, lo que minimiza la latencia. GPUDirect RDMA Permite realizar transferencias directas de GPU a GPU entre nodos. Se emplea en estructuras serving desagregadas para las transferencias de KV cache.

NVMe (Non-Volatile Memory Express): interfaz de SSD de alta velocidad que se utiliza para la descarga externa de KV cache. ZeRO-Infinity El descarga de parámetros cuando la memoria GPU/CPU es insuficiente. Las velocidades de lectura secuencial alcanzan entre 5 y 7 GB/s por unidad (PCIe Gen 4), mientras que las unidades más recientes de Gen 5 pueden llegar a 10–14 GB/s.

TFLOPS / PFLOPS — Operaciones en punto flotante de tera/peta por segundo. 1 TFLOPS equivale a 10¹² FLOPS. Es la unidad estándar para medir el rendimiento de cálculo de GPU. El H100 ofrece 989 TFLOPS (en modo TF32); el FlashAttention-3 alcanza aproximadamente 1,2 PFLOPS en FP8.

Parte II — Fundamentos de la inferencia

La inferencia es la parte del sistema que perciben realmente los usuarios. La latencia, el KV cache, el modelo de ejecución en dos fases, la atención y la cuantización definen hasta qué punto se puede ofrecer un servicio rápido, económico y fiable.

4. Latencia: TTFT, TPOT y percentiles

Tiempo hasta el primer token (TTFT) se refiere al retraso desde la presentación de la solicitud hasta que se genera el primer token de salida. Este valor está determinado por la fase prefill: el modelo debe procesar todo el prompt antes de poder generar cualquier contenido, por lo que tiempos de prompts más prolongados suelen incrementar el TTFT. Los objetivos asociados son específicos de cada producto; MLPerf Inference v5.0 Utiliza un límite P99 TTFT de $\leq$ 450 ms en su escenario interactivo con Llama 2 70B.

Tiempo por token de salida (TPOT) es el intervalo promedio entre tokens consecutivos a partir del primero. Se relaciona con la fase de decodificación, en la cual cada paso está limitado por el ancho de banda de la memoria:

$\text{TPOT} = \frac{\text{Latencia E2E} - \text{TTFT}}{\text{Tokens de salida} - 1}$

La velocidad media de lectura en silencio de un adulto inglés es de aproximadamente 238 palabras por minuto para textos de no ficción.Brysbaert, 2019). Los objetivos de streaming deben seguir proveniendo de las pruebas del producto; MLPerf establece un límite P99 TPOT de $\leq$ 40 ms para su escenario interactivo.

La latencia P50 frente a la P99 es importante porque la mediana oculta las extremidades de la distribución. Un sistema con un buen valor de P50 pero un mal valor de P99 podría presentar problemas relacionados con el agrupamiento de solicitudes, la preemisión, la formación de colas o una distribución desigual de la carga de trabajo; para diferenciar estos casos se necesitan registros detallados de las operaciones.

5. Rendimiento: tokens por segundo y el equilibrio entre latencia y velocidad

El rendimiento se mide en tokens de salida por segundo para solicitudes concurrentes. El simple número de solicitudes por segundo no es suficiente, ya que una respuesta de 10 tokens y una de 1.000 tokens implican costos muy diferentes. Las cifras publicadas para benchmark varían en función del modelo, la precisión, el hardware, prompt y la longitud de la salida, así como de la concurrencia y los SLO. Compare vLLM, SGLang, y TensorRT-LLM utilizando un único harness en lugar de combinar sus resultados principales.

El compromiso: a baja concurrencia, cada solicitud presenta una alta latencia, pero el GPU no se utiliza al máximo. Aumentar el tamaño del lote eleva el rendimiento de forma casi lineal hasta que la capacidad de cálculo se satura, momento en el cual la latencia aumenta drásticamente. Goodput, que representa la fracción de solicitudes que cumplen con los objetivos de desempeño establecidos, es la métrica que relaciona el rendimiento bruto con la satisfacción real del usuario.

6. KV cache: el cuello de botella que subyace a la mayoría de los demás cuellos de botella

Durante la generación autoregresiva, cada nuevo token toma en consideración todos los tokens anteriores. El KV cache almacena las proyecciones de Clave y Valor de cada token en cada capa, con el fin de evitar una recálculo de orden $O(n^2)$. Sin él, generar el token $n$ requeriría ejecutar nuevamente el modelo sobre los $n-1$ tokens anteriores.

El KV cache suele ser la principal causa de presión en la memoria, ya que aumenta de forma lineal con la longitud de la secuencia, el tamaño del lote 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 lote

Ejemplos concretos utilizando FP16 y un tamaño de lote de 1: Llama 3 8B, con 8,192 tokens, consume aproximadamente 1,0 GB de KV cache; con 128K tokens, la cifra asciende a 16 GB. Por su parte, Llama 3 70B, al procesar 128K tokens, requiere alrededor de 40 GB para una sola secuencia, lo que representa la mitad de la capacidad de VRAM de un H100. Con tamaños de lote típicos en entornos de producción, KV cache supera con facilidad la memoria destinada al peso del modelo. Las implementaciones ingenuas desperdician entre el 60 % y el 80 % de la memoria KV asignada debido a la fragmentación, y ese es precisamente el problema. PagedAttention Fue desarrollado para resolverlo.

Las principales optimizaciones son GQA (menos cabezales KV), cuantización KV cache (FP8/INT8). PagedAttention (asignación basada en bloques con un <4% de desperdicio>), y el traslado de KV cache a CPU o a NVMe.

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

La fase prefill procesa la entrada prompt de forma paralela y rellena el KV cache. Debido a sus multiplicaciones matriciales de gran escala, su rendimiento está limitado por cálculos intensivos, por lo que prefill determina en gran medida el tiempo hasta el primer token (TTFT). La fase de decodificación genera un token a la vez; en cada paso se leen los pesos del modelo y el KV cache desde HBM, Hacer que la decodificación quede limitada por el ancho de banda de la memoria se convierte en el principal factor que determina el tiempo por token de salida (TPOT).

El procesamiento en bloques prefill divide el prompt en bloques de tamaño fijo (por ejemplo, 512 tokens) en lugar de procesarlo todo de una sola vez. Un prefill muy largo ya no bloquea las solicitudes de decodificación en curso; las tareas limitadas por cálculos y por memoria se programan simultáneamente en el mismo GPU, lo que permite que vLLM benchmarks logren un +50% de rendimiento.Agrawal y colaboradores, 2024). El costo es ligeramente más elevado en TTFT para la nueva solicitud.

Desagregación de serving que separa los prefill y su decodificación en pools independientes GPU, lo que permite que cada pool se enfoque en un cuello de botella distinto. Splitwise y DistServe Describe el patrón. Los grupos transfieren datos del caché KV a través de una interconexión rápida como RDMA, Por lo tanto, el costo de comunicación pasa a formar parte del diseño.

8. GQA y MQA: reducción del tamaño de KV cache

Estándar Atención Multicabeza (AMC) Asigna a cada cabeza de consulta su propia cabeza K y V. Atención multi-pregunta (MQA) Comparte una única cabeza KV entre todas las cabezas de consulta, lo que representa una reducción extrema. Atención de consulta agrupada (GQA) Se trata del punto intermedio práctico: los grupos de cabezas de consulta comparten una única cabeza KV.

Llama 3 70B emplea 64 cabezales de consulta pero únicamente 8 cabezales KV, lo que supone una reducción de 8x KV cache en comparación con la misma arquitectura que cuenta con un cabezal KV por cada cabezal de consulta. Llama 3.1 405B utiliza 128 cabezales de consulta y 8 cabezales KV, lo que representa una reducción de 16x según el mismo cálculo.Meta, 2024). Ainslie y colaboradores indican que la calidad de GQA en los modelos que probaron es similar a la de MHA, al tiempo que se aproximan a la velocidad de MQA. Un KV cache más pequeño permite manejar lotes de mayor tamaño, pero las mejoras en latencia y rendimiento obtenidas siguen dependiendo del núcleo y de la carga de trabajo.

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

La cuantización disminuye la precisión de los pesos y/o activaciones del modelo. Los principales compromisos:

AWQ (Activación-Aware Weight Quantization) identifica el <1% de pesos relevantes analizando las magnitudes de activación y aplica una escala por canal para protegerlos. Solo requiere entre 128 y 1,024 tokens de calibración, y ganó el premio al Mejor Artículo Científico en MLSys 2024. GPTQ Utiliza información del Hessian de segundo orden para la cuantización por capas y requiere más datos de calibración. bitsandbytes (La biblioteca de Tim Dettmers) realiza la cuantización durante la carga del modelo sin necesidad de un paso de preprocesamiento separado; su formato NF4 permite el funcionamiento de QLoRA fine-tuning. La FP8 en hardware de tipo Hopper reduce la memoria dedicada a los pesos en comparación con FP16/BF16, pero la calidad y la velocidad siguen dependiendo del modelo, de la calibración y del kernel.

El núcleo serving puede ser tan importante como el algoritmo de cuantización. En la comparación que se analizó anteriormente Sección 10, Los mismos pesos cuantizados presentan una diferencia de 2,6 veces en el rendimiento entre los distintos kernels.

Parte III — Optimizaciones de inferencia

Esta sección trata de las técnicas de software que permiten transformar un sistema de inferencia funcional en uno de alto rendimiento. Cada una de ellas aborda un cuello de botella específico: FlashAttention aprovecha la brecha entre la SRAM y HBM, PagedAttention elimina la fragmentación de KV cache, mientras que el agrupamiento continuo mantiene ocupado al GPU.

10. Núcleos CUDA y fusión de núcleos

Un CUDA kernel es una función desarrollada para el GPU que se ejecuta de forma paralela a través de miles de hilos. Cuando el CPU llama a un kernel, el GPU distribuye el trabajo entre ellos. SMs: Cada SM ejecuta múltiples warps compuestos por 32 hilos, y cada hilo procesa una porción específica de los datos. Toda operación durante la inferencia en LLM, desde la multiplicación de matrices hasta el muestreo de tokens, se reduce en última instancia a un lanzamiento de kernel. Una sola pasada forward a través de un modelo de 70 mil millones de parámetros desencadena cientos o incluso miles de lanzamientos de kernel, y la diferencia entre un kernel tradicional y uno optimizado puede determinar si el sistema cumple con sus objetivos de latencia establecidos.

Las principales categorías de núcleo en LLM serving:

• Núcleos GEMM para la multiplicación de matrices, los cuales dominan tanto las operaciones de prefill como las de decodificación.
• Núcleos de atención como FlashAttention que distribuyen las operaciones en bloques para mantenerse dentro de SRAM en lugar de producirse un derrame hacia HBM.
• Núcleos fusionados que combinan múltiples operaciones (como suma + normalización por capa o proyección QKV) en una sola ejecución para evitar los viajes de ida y vuelta intermedios HBM.
• Núcleos de muestreo que convierten los logits en IDs de tokens mediante muestreo top-k, top-p o de temperatura.

La calidad del kernel suele ser más importante que el algoritmo de cuantización. Los mismos pesos INT4-cuantizados se distribuyen a través de Marlin Un núcleo optimizado para FP16xINT4 alcanzó 712 tokens/s, frente a los 276 tokens/s del GPTQ estándar, lo que representa una diferencia de rendimiento de 2,6 veces debida exclusivamente a una mejor utilización de los GPU. Marlin logra esto gracias a la obtención asíncrona de memoria y a colas de memoria compartida que mantienen alimentados a los Tensor Cores en lugar de hacer esperas por parte de los HBM. Tritón Reduce la barrera para desarrollar kernels personalizados al permitir la programación con GPU a través de Python en lugar de utilizar directamente el CUDA C++ puro, lo que hace que la optimización a nivel de kernel esté al alcance de los ingenieros ML y no solo de los especialistas en GPU. La mayoría de las optimizaciones que se tratan más adelante en esta sección (FlashAttention, kernels fusionados, PagedAttention) se reducen, en esencia, a kernels mejorados o a formas más inteligentes de gestionar el inicio de dichos kernels.

La fusión de kernels combina operaciones secuenciales en un único kernel GPU y omite las escrituras intermedias HBM. Las fusiones más habituales son la proyección QKV, la atención sumada a softmax, y la suma sumada a RMSNorm.FlashNorm), y la activación SwiGLU (DeepFusionKernel). Tritón Hace que estos núcleos sean accesibles a través de Python. Las ganancias exactas en cuanto al número de ejecuciones y a la utilización dependen del grafo del modelo, del compilador, de GPU y de serving framework; por lo tanto, es necesario realizar un análisis detallado de la pila desplegada en lugar de confiar en un porcentaje universal.

11. FlashAttention: atención por mosaico para su implementación en SRAM

La atención estándar materializa toda la matriz de atención $N \times N$ en HBM, lo que implica un consumo de memoria de orden $O(N^2)$ y genera una gran cantidad de tráfico de memoria. La idea detrás de FlashAttention es evitar por completo la materialización de esta matriz. Para ello, divide las matrices Q, K y V en bloques que caben dentro de SRAM, Calcula la atención parcial dentro de cada tile y fusiona los resultados mediante un softmax en tiempo real (se registra de forma incremental el máximo y la suma acumulados a lo largo de los bloques). La memoria disminuye de $O(N^2)$ a $O(N)$, y las lecturas de HBM se reducen en una orden de magnitud.

Cada versión aborda el cuello de botella en la generación de su GPU:

• FlashAttention v1 (A100, 2022) demostró que el enfoque de mosaico combinado con softmax en tiempo real es efectivo. Se logra una aceleración de 2–4 veces respecto a la atención estándar, pero la utilización de GPU solo alcanza entre el 25 % y el 40 %, ya que la planificación de núcleos deja muchos SM inactivos. FlashAttention v2 (A100, 2023) rediseñó el modelo para distribuir el paralelismo a lo largo de la dimensión de secuencias en lugar de hacerlo entre lotes y cabezales. Logró una utilización del 50–73 % en las tarjetas A100, lo que representa aproximadamente 2 veces más velocidad que la versión v1.
• FlashAttention v3 (H100 Hopper, 2024) incorpora una especialización de warps (warps independientes para el movimiento de datos y para operaciones matemáticas), además de un enfoque por tuberías GEMM-softmax, con el objetivo de superponer las cargas de memoria y los cálculos. Se logra una utilización del 75–85 % en la GPU H100 y una potencia de cálculo de hasta ~1,2 PFLOPS en FP8. Destacado en NeurIPS 2024. FlashAttention v4 (B200 Blackwell, 2026) aborda un nuevo cuello de botella: en Blackwell, el rendimiento por núcleo tensorial aumenta con tal rapidez que las operaciones que no son matmul (exponenciales de softmax, reescalamiento) pasan a ser el factor limitante. El software FA4 emula la función exponencial mediante aproximaciones polinomiales en las unidades FMA, emplea reescalamiento condicional para reducir la sobrecarga y almacena los resultados intermedios en la memoria tensorial dedicada de Blackwell (TMEM) en lugar de en registros. El resultado es una velocidad de 1,605 TFLOPS/s en el B200 en BF16, lo que supone una velocidad 1,3 veces mayor que la de cuDNN 9.13 y 2,7 veces mayor que la de Triton.

Cada generación se topaba con un límite de hardware distinto, y cada versión de FlashAttention se rediseñaba desde el núcleo hacia arriba para superar dicho problema.

12. FlashDecoding: paralelización del cuello de botella en la decodificación

El FlashAttention estándar mantiene ocupado al GPU al distribuir el trabajo entre el tamaño del lote y la longitud de la consulta. Durante la decodificación, el modelo genera exactamente 1 token a la vez (longitud de la consulta = 1). Si el tamaño del lote multiplicado por la cantidad de cabezas de atención es menor que el recuento total de SM del GPU (108 en un A100), la mayor parte de los GPU permanece inactiva, mientras que unas pocas unidades procesan secuencialmente el historial de tokens.

FlashDecoding Resuelve este problema al añadir una nueva dimensión de paralelización: la longitud de la secuencia KV en sí misma. Este enfoque divide la KV cache en fragmentos más pequeños y los distribuye entre todos los procesadores GPU que, de otro modo, estarían inactivos, para que los evalúen de forma paralela; posteriormente, se fusionan sus cálculos parciales mediante una reducción log-sum-exp.

El resultado es una aceleración de hasta 8 veces en la velocidad de decodificación integral para secuencias largas (contexto de 64 K), manteniendo un tiempo de decodificación prácticamente constante por token. Generar el token 60.000 sigue siendo casi tan rápido como generar el token 100.

13. Agrupación continua vs. agrupación estática

El batching estático espera a que finalice cada secuencia de un lote antes de iniciar la siguiente, por lo que las secuencias cortas desperdician ciclos de GPU en estado inactivo una vez llegan al final de la misma. El batching continuo (introducido por el Artículo de Orca, OSDI 2022) funciona a nivel de iteración: en cada paso de decodificación, las secuencias ya completadas se eliminan y se insertan nuevas.

En OPT-13B benchmark de Anyscale, el agrupamiento estático optimizado logró un rendimiento 4 veces superior al de la versión básica sin optimización, mientras que el agrupamiento continuo alcanzó un valor 8 veces mayor; además, mediante el uso de vLLM junto con PagedAttention en el contexto del agrupamiento continuo, se obtuvo un rendimiento de 23 veces superior (Anyscale, 2023). El agrupamiento continuo también aumenta la presión sobre la asignación de KV, y por eso se combina habitualmente con una gestión de memoria paginada.

14. PagedAttention: memoria virtual para KV cache

el PagedAttention de vLLM Aplica el concepto de memoria virtual del SO a la gestión de KV cache. El KV cache se divide en bloques de tamaño fijo (generalmente 16 tokens); estos bloques se asignan según sea necesario a medida que se generan los tokens, y las posiciones lógicas (secuenciales) se corresponden con ubicaciones de memoria física (dispersas) a través de tablas de bloques. Múltiples solicitudes que comparten un prefijo (system prompts, búsqueda por haz) pueden apuntar a los mismos bloques físicos.

Los sistemas anteriores desperdiciaban del 60–80 % de la memoria KV cache debido a la fragmentación y a la preasignación. PagedAttention reduce esta cifra a menos del 4 %, lo que permite que el rendimiento aumente entre 2 y 4 veces manteniendo la misma latencia, e incluso hasta 24 veces en comparación con HuggingFace Transformers.vLLM Blog, 2023).

15. Decodificación especulativa: múltiples tokens por paso hacia adelante

Un pequeño modelo de boceto genera $K$ tokens candidatos, y posteriormente el gran modelo objetivo verifica todos esos $K$ tokens en una sola pasada forward. Los tokens correctos son aceptados, mientras que el primero que resulte incorrecto es rechazado. La calidad de la salida es matemáticamente idéntica a la del modelo objetivo por sí solo, por lo que se trata de una aceleración sin pérdida de calidad.

Funciona porque la decodificación con LLM está limitada por el ancho de banda de memoria: verificar $K$ tokens cuesta aproximadamente lo mismo que generar 1, ya que en ambos casos se cargan todos los pesos del modelo una sola vez. Las mejoras de rendimiento típicas se sitúan entre 1,5 veces y 3 veces, con métodos como EAGLE-3 alcanzando hasta 6.5x. Las variantes incluyen Medusa (cabezas de predicción adicionales, sin modelo separado), decodificación por búsqueda con prompt (coincidencia de n-gramas con la entrada, de forma libre), y EAGLE (extrapolación a nivel de características).

Con tamaños de lote elevados, el trabajo adicional de redacción preliminar y verificación puede anular los beneficios obtenidos; un informe de evaluación mencionado indica una ralentización de 1,4 a 1,8 veces en dichas condiciones. La decodificación especulativa resulta más prometedora cuando el lote serving es lo suficientemente pequeño y la tasa de aceptación de las versiones preliminares es alta.

16. Caché de prefijos y reutilización de KV cache

En lugar de descartar el KV cache una vez finalizada una solicitud, el caché por prefijo mantiene dicho elemento disponible para su reutilización en nuevas solicitudes que comparten los mismos tokens de prefijo. Esto reduce la generación de prefill redundantes para los system prompts, ejemplos de pocos ejemplos, el contexto RAG y el historial de conversaciones multietapa.

El caché automático de prefijos de vLLM Hasha los bloques clave-valor y emplea una tabla de hash global para las búsquedas. RadixAttention de SGLang Mantiene un árbol radicular de tensores KV almacenados en caché con una granularidad a nivel de token. Dado que ambos dependen de prefijos idénticos entre tokens, es necesario informar tanto sobre la tasa de aciertos como sobre la latencia o el rendimiento.

17. El streaming en la práctica

Transmisión en tiempo real envía los tokens al cliente a medida que se generan, en lugar de esperar a recibir la respuesta completa. Muchos serving frameworks lo hacen posible mediante Server-Sent Events: el cliente establece una conexión HTTP de larga duración, y el servidor envía cada token o lote de tokens de forma incremental. data: evento. TTFT determina el momento en que el usuario ve por primera vez la salida; TPOT ayuda a definir qué tan fluida se percibe dicha salida. Se debe establecer el valor objetivo mediante pruebas del producto y el modelo de interacción seleccionado.

En el lado del cliente, la transmisión en flujo obliga a tomar decisiones sobre el almacenamiento temporal de datos. Renderizar token por token puede provocar fluctuaciones visuales, especialmente con bloques de Markdown o código que requieren un contexto formado por varios tokens para ser formateados correctamente. Los patrones más comunes son el almacenamiento temporal a nivel de palabra (acumular tokens hasta encontrar un límite de espacio en blanco), el almacenamiento temporal a nivel de línea (esperar a un salto de línea antes de renderizar) y el almacenamiento temporal adaptativo (renderizar de inmediato el texto prosaico y almacenar temporalmente los datos de los bloques de código). stream_options: {"include_usage": true} El parámetro en las APIs compatibles con OpenAI APIs devuelve los recuentos de tokens en el evento SSE final, lo que permite realizar un seguimiento preciso de los costes en las respuestas transmitidas por streaming.

Procesamiento por bloques prefill Es lo que permite que el streaming mantenga su rendimiento bajo carga. Sin ello, un único prefill largo puede bloquear la entrega de tokens para todos los demás usuarios que operen de forma concurrente.

Parte IV — Arquitectura del modelo

Cómo se construyen los LLMs: el bloque transformer, la tokenización, el manejo del contexto y las variantes arquitectónicas que se convirtieron en las predeterminadas. Todo esto sienta las bases tanto para la inferencia como para el entrenamiento.

18. Conceptos esenciales de la arquitectura Transformer

Un transformador moderno exclusivamente de decodificación (GPT, Llama) está compuesto por una serie de capas idénticas, cada una con dos subbloques: atención y feed-forward. Cada subbloque cuenta con una conexión residual y una operación de normalización asociadas. Los componentes clave son:

Atención multi-cabeza — el mecanismo que permite a cada token analizar todos los demás tokens para determinar qué información es relevante. La entrada se proyecta en tres matrices: Consultas (¿qué estoy buscando?), Claves (¿qué contengo?) y Valores (¿qué información llevo?). A continuación, se calculan las puntuaciones de atención de la siguiente manera:

$\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. Al dividir por $\sqrt{d_k}$ se evita que los productos escalares crezcan excesivamente (lo cual llevaría al softmax a regiones con gradientes nulos). El softmax convierte las puntuaciones en probabilidades, y la multiplicación por $V$ genera una combinación ponderada de los vectores de valor. Ejecutar este proceso en múltiples cabezas de forma paralela permite al modelo prestar atención a diferentes relaciones al mismo tiempo (una cabeza para la sintaxis, otra para la coreferencia, etc.).

Red de retroalimentación directa (RRD) — una vez que la atención ha determinado cuáles tokens son relevantes, la RRD decide qué hacer con esa información. Los modelos modernos LLMs utilizan SwiGLU en lugar de la FFN ReLU original con dos matrices:

$\text{SwiGLU}(x) = \text{Swish}(xW_1) \otimes xW_2$

SwiGLU emplea tres matrices de pesos en lugar de dos, así como una función de activación Swish suave en sustitución de ReLU. Es utilizado por familias de modelos como Llama, Mistral, Qwen y Gemma. Por lo general, la capa FFN representa alrededor de dos tercios de los parámetros totales del modelo, aunque la proporción exacta depende de la arquitectura.

Conexiones residuales — cada subbloque suma su salida a su entrada: $\text{Output} = \text{Input} + \text{Sublayer}(\text{Input})$. Sin esta conexión de salto, los gradientes desaparecen al propagarse hacia atrás a través de 80–128 capas. La conexión residual establece una vía que permite que la información y los gradientes fluyan directamente desde las capas tempranas hasta las tardías.

RMSNorm — es común en las familias modernas de LLM. LayerNorm normaliza al centrar nuevamente los valores (restando la media) y escalarlos de nuevo (dividiendo entre la desviación estándar). RMSNorm Omite la sustracción de la media y únicamente realiza una rescalado; el artículo correspondiente indica aceleraciones del 7–64 % en los modelos probados, sin que se observe ninguna pérdida de rendimiento en dichos experimentos. La colocación Pre-norm, que normaliza los datos antes de aplicar la atención o la capa FFN, también es frecuente, ya que contribuye a mejorar la estabilidad de los gradientes.

Estimación del número de parámetros para un modelo exclusivamente de decodificación:

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

Donde $V$ representa el tamaño del vocabulario, $d$ la dimensión oculta y $L$ el número de capas. El término $V \times d$ corresponde a la matriz de entrada embedding; el término $12 \times d^2$ aproxima los pesos de atención y de las funciones FFN en cada capa. En el caso de Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$), la estimación resulta ser aproximadamente $0.53B + 6.44B = 6.97B$ parámetros. El valor total publicado de 8.03B es más alto porque esta aproximación omite detalles arquitectónicos como la anchura exacta de las funciones FFN y la proyección de salida independiente.

19. Por qué las arquitecturas de solo decodificador dominan

El original Transformer En el trabajo de (2017) se empleaban tanto un codificador como un decodificador. Desde entonces, el campo se ha dividido en tres familias arquitectónicas, y una de ellas se ha convertido en la opción predeterminada para los modelos generativos AI.

Los modelos solo con codificador (BERT, RoBERTa) emplean atención bidireccional: cada token presta atención a todos los demás tokens en ambas direcciones. Esto genera representaciones ricas para tareas de comprensión (clasificación, NER, similitud semántica), pero no permiten generar texto de forma autoregresiva. No obstante, los modelos solo con codificador siguen siendo la base fundamental para embedding modelos, rerankers, y clasificadores ligeros (por ejemplo, los enrutadores basados en BERT) RouteLLM).

Los modelos encoder-decoder (T5, BART y el Transformer original) separan la fase de comprensión de la de generación. El encoder procesa toda la entrada mediante atención bidireccional, mientras que el decoder genera la salida de forma autoregresiva, tomando en consideración las representaciones del encoder a través de cross-attention. Esto supone una ventaja inherente para tareas de secuencia a secuencia como la traducción, donde la entrada y la salida son secuencias fundamentalmente distintas. T5, desarrollado por Google, demostró que cualquier tarea de NLP podía formularse como un proceso de texto a texto, y los modelos encoder-decoder siguen siendo la base de algunos sistemas especializados (como Whisper para el reconocimiento de voz o FLAN-T5 para el seguimiento de instrucciones).

Los modelos solo decodificadores (GPT, Llama, Mistral, Gemini) emplean atención causal (unidireccional): cada token solo presta atención a los tokens anteriores. Estos modelos formulan todo como una predicción del siguiente token: la “entrada” es el inicio de la secuencia y la “salida” su continuación. Cuatro razones por las que esta arquitectura se ha impuesto:

1. Eficiencia KV cache. El KV cache obtenido a partir de los tokens anteriores sigue siendo válido mientras se generan nuevos tokens, por lo que nunca es necesario descartarlo ni volver a calcularlo. Los modelos de codificador-descodificador deben mantener dos cachés de atención independientes (atención propia más atención cruzada sobre la salida del codificador), lo cual incrementa la carga de memoria y la complejidad arquitectónica.

2. Simplicidad en el entrenamiento. El objetivo del entrenamiento consiste en una sencilla predicción del siguiente token a partir de texto sin procesar. No se requieren datos de entrada-salida emparejados (como son necesarios para los modelos de traducción) ni reconstrucción de tokens enmascarados (como lo exigen los modelos BERT). Es posible entrenar con prácticamente cualquier tipo de texto proveniente de Internet, libros o código, sin necesidad de ningún preprocesamiento especial, lo cual representa una ventaja enorme al escalar los datos hasta billones de tokens.

3. Simplicidad arquitectónica. Un único módulo se encarga de todo: el mismo bloque transformador, repetido $L$ veces. No existen capas de atención cruzada entre codificador y decodificador, ni tampoco una pila separada de codificadores. Esto hace que las estrategias de paralelización sean más sencillas de implementar (Sección 33), Y reduce la superficie de ingeniería disponible para la optimización. FlashAttention, la cuantización y el decodificación especulativa solo necesitan adaptarse a un único patrón de atención.

4. Aprendizaje in-contexto. Los modelos de decodificador único son naturalmente adecuados para el aprendizaje con pocos ejemplos, ya que los ejemplos, las instrucciones y la consulta son simplemente tokens dentro de la misma secuencia. El modelo no distingue entre “entrada” y “salida”; predice el siguiente token basándose en todo lo anterior. GPT-3 fue el primero en demostrar esto a gran escala, lo que convirtió a los modelos de decodificador único en una opción muy adecuada para el papel de asistente multiusos.

20. Mezcla de expertos

MoE sustituye la densa FFN presente en cada capa del transformador por múltiples FFNs especializadas más pequeñas, junto con un enrutador de compuerta de bajo consumo. Este enrutador calcula una puntuación para cada FFN especializada (generalmente mediante una función softmax sobre proyecciones lineales aprendidas) y selecciona las $k$ mejores entre ellas para cada token. Solo las FFN especializadas activadas realizan cálculos, lo que permite que un modelo tenga una capacidad total enorme manteniendo un costo por token bajo. Se trata de una computación condicional dispersa: los parámetros totales determinan qué puede representar el modelo, mientras que los parámetros activos determinan cuánto cuesta ejecutarlo.

El experto compartido de DeepSeek-V3 se activa para cada token. Proporciona una representación de referencia sobre la cual los expertos enrutados pueden especializarse.

El entrenamiento de MoE presenta tres problemas recurrentes: desequilibrio de carga, colapso de los expertos y sobrecarga por comunicación para paralelismo experto. Los modelos tradicionales MoE añaden una pérdida auxiliar para sancionar la distribución desequilibrada de las rutas, pero dicha pérdida puede competir con el objetivo principal. DeepSeek-V3

21. Tokenización: BPE, SentencePiece y tiktoken

LLMs No perciben el texto en sí; en su lugar, ven secuencias de identificadores de tokens enteros. Un tokenizador divide el texto bruto en tokens (fragmentos subpalabras) y asigna a cada uno de ellos un identificador específico. La elección del tokenizador influye directamente en la calidad del modelo, en la velocidad de inferencia y en la equidad al trabajar con múltiples idiomas.

Codificación de pares de bytes (BPE) Se trata del algoritmo más habitual. Este procede de forma iterativa para fusionar las parejas adyacentes más frecuentes del corpus de entrenamiento. Un ejemplo simplificado:

1. Comience con el vocabulario a nivel de carácter: [l, o, w, e, r, _]
2. La pareja más frecuente es (l, o) → fusionar con lo → vocabulario: [l, o, w, e, r, _, lo]
3. La siguiente pareja más frecuente es (lo, w) → fusionar con low → el vocabulario se amplía low
4. Continúe hasta que el vocabulario alcance el tamaño objetivo (p. ej., 128 K de tokens).

Las palabras comunes como “el” se convierten en tokens individuales, mientras que términos poco frecuentes como “defenestration” se dividen en fragmentos subpalabras. ["def", "en", "est", "ration"]El equilibrio se da entre el tamaño del vocabulario y la longitud de la secuencia.

Tres implementaciones de tokenizador cubren la mayoría de los casos de uso en producción:

• SentencePiece trata la entrada como un flujo de bytes en bruto sin ningún tipo de preprocesamiento específico del idioma (sin pretokenización basada en espacios o signos de puntuación), lo que lo hace agnóstico a los idiomas y resulta de gran importancia para los scripts no latinos. Soporta tanto BPE como unigramas. Es utilizado por Llama 1/2, T5 y Mistral. tiktoken Se trata del tokenizador de OpenAI basado en Rust que utiliza un procesamiento a nivel de byte BPE. Su núcleo compilado en Rust es de 3 a 6 veces más rápido que las alternativas basadas en Python. Llama 3 pasó de utilizar SentencePiece al algoritmo de tiktoken.
• Hugging Face Tokenizadores Se trata de una biblioteca muy utilizada basada en Rust que soporta BPE, WordPiece y Unigram.

El tamaño del vocabulario ha ido aumentando de forma constante, lo que tiene implicaciones significativas para la eficiencia:

Fertilidad (tokens por palabra) mide la eficiencia de compresión. Cuanto menor sea, mejor: menos tokens implican secuencias más cortas, un costo inferior y mayor capacidad para incluir contenido en la ventana de contexto. En inglés, este valor suele situarse entre ~1,0 y 1,3 tokens/palabra, pero los sistemas de escritura no latinos (chino, japonés, coreano, árabe) pueden presentar valores 2 a 4 veces mayores cuando se utilizan vocabularios centrados en el inglés. El mismo contenido requiere de 2 a 4 veces más tokens para los usuarios que no hablan inglés, lo cual constituye un problema persistente de equidad que los vocabularios más amplios y equilibrados solo logran abordar parcialmente.

22. Ventanas de contexto y codificaciones posicionales

La ventana de contexto representa el número máximo de tokens que un modelo puede procesar en una sola pasada forward. Este valor ha aumentado significativamente:

Existe un problema fundamental aquí: el mecanismo de atención trata su entrada como un conjunto y no como una secuencia. No cuenta con una noción integrada del orden de las palabras. Sin información posicional, frases como “el gato se sentó en la alfombra” y “la alfombra se sentó sobre el gato” generarían representaciones idénticas. Las codificaciones posicionales introducen este orden para que el modelo sepa dónde se encuentra cada token.

Tres enfoques comunes son:

• RoPE (Rotación de posición Embeddings) codifica la posición de cada token rotando sus vectores de consulta y clave por un ángulo proporcional a dicha posición. Los tokens que se encuentran cerca entre sí reciben rotaciones similares, por lo que su producto escalar (puntuación de atención) permanece alto. En cambio, los tokens muy separados experimentan rotaciones muy distintas, lo que permite representar la distancia relativa. RoPE es el estándar en casi todos los modelos abiertos modernos LLMs (Llama, Mistral, Qwen), ya que gestiona eficazmente las posiciones relativas y requiere un bajo costo computacional.

• ALiBi (Atención con sesgos lineales) omite las modificaciones realizadas por embedding e introduce directamente una penalización en las puntuaciones de atención: cuanto mayor sea la distancia entre dos tokens, mayor será el sesgo negativo aplicado. No requiere parámetros aprendidos ni genera cálculos adicionales. Permite cierta extrapolación más allá de la longitud de entrenamiento, pero su rendimiento disminuye de forma notable cuando se utiliza un contexto 2 veces o más largo que el utilizado durante el entrenamiento.

• YaRN (Otra extensión de RoPE) permite ampliar el alcance de un modelo RoPE más allá de su contexto de entrenamiento. Este enfoque agrupa las dimensiones de frecuencia en tres categorías y aplica escalas diferentes a cada una de ellas. El artículo indica que se logran 10 veces menos tokens fine-tuning y 2,5 veces menos pasos de entrenamiento en comparación con la versión base basada en interpolación de posiciones.

Parte V — Entrenamiento y alineación

El entrenamiento es el proceso mediante el cual se desarrollan las capacidades del modelo. Esta sección aborda el preentrenamiento, el uso eficiente de fine-tuning (LoRA, precisión mixta), las leyes de escalamiento y los métodos de alineación.

23. Preentrenamiento, fine-tuning, y alineación

Preentrenamiento consiste en la predicción autoguiada del siguiente token a partir de un corpus de gran tamaño. El cálculo necesario para llevarlo a cabo abarca varios órdenes de magnitud. Llama 3 405B, Por ejemplo, se emplearon $3.8 \times 10^{25}$ FLOPs. El aprendizaje supervisado fine-tuning (SFT) adapta el modelo preentrenado a datos etiquetados específicos para una tarea concreta. RLHF / RLAIF utiliza datos de preferencias para dar forma al comportamiento: un RLHF pipeline convencional recopila comparaciones, entrena un modelo de recompensas y, a continuación, optimiza la política. RLAIF sustituye algunos juicios humanos por retroalimentación generada mediante AI.

El cálculo depende del tamaño del modelo, de la longitud de la secuencia, del volumen de datos, del optimizador y del método utilizado. PPO también almacena más estado del modelo que SFT, ya que una configuración típica incluye modelos de política, referencia, recompensa y crítico. Ya he tratado en profundidad el proceso completo de toma de decisiones fine-tuning mediante framework. Guía de LLM y Fine-Tuning.

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

LoRA Congela los pesos preentrenados e introduce matrices de rango bajo entrenables $A$ ($r \times k$) y $B$ ($d \times r$), de modo que el peso actualizado sea $W_0 + BA$. El artículo LoRA logró reducir los 175 mil millones de parámetros de GPT-3 a aproximadamente 18 millones de parámetros entrenables en su configuración. El rango constituye un parámetro de ajuste y no una regla relacionada con la complejidad de la tarea; se debe seleccionar mediante pruebas de calidad y análisis de consumo de memoria. Los adaptadores LoRA pueden fusionarse con los pesos base tras el entrenamiento, evitando así la necesidad de utilizar un camino independiente para ellos durante la inferencia.

QLoRA Carga el modelo base con cuantización NF4 de 4 bits durante el entrenamiento de adaptadores LoRA en BF16. NormalFloat4 distribuye más niveles de cuantización cerca de cero, donde la densidad de pesos es más alta. El artículo describe el ajuste fino de un modelo de 65 mil millones de parámetros en una única unidad de memoria de 48 GB GPU, y muestra resultados similares a los obtenidos con versiones de 16 bits. Sus compromisos entre rendimiento runtime y consumo de memoria son específicos de la arquitectura probada.

25. Entrenamiento de precisión mixta

Cada formato de punto flotante distribuye sus bits en tres campos: signo (siempre 1 bit), exponente (que determina el rango dinámico) y mantisa (que define la precisión). Cuantos más bits tenga el exponente, mayor será el rango de magnitudes que se pueden representar; cuanto más bits tenga la mantisa, mayores serán las distinciones entre valores cercanos. Los formatos enteros, por su parte, no cuentan con exponente alguno y solo permiten representar números enteros equidistantes dentro de un rango fijo.

BF16 tiene el mismo rango que FP32, ya que dicho rango está determinado por el campo del exponente, y BF16 conserva los 8 bits de exponente de FP32. En cambio, renuncia a los bits de la mantisa (7 frente a 23), sacrificando precisión a cambio de una reducción del 2 × en el consumo de memoria, al tiempo que se evitan los problemas de desbordamiento e insuficiencia de flujo que afectan al entrenamiento de FP16. FP16 dispone únicamente de 5 bits de exponente, lo que limita su rango a aproximadamente 65 K. Las gradientes suelen superar este valor, y por eso el entrenamiento de FP16 requiere escalamiento de la pérdida: se multiplica la pérdida por una constante grande antes del paso de retropropagación y, posteriormente, se dividen las gradientes. BF16 hace que el escalamiento de la pérdida sea innecesario.

Los formatos enteros son poco habituales en la aritmética de entrenamiento principal, ya que la retropropagación requiere un amplio rango dinámico. En cambio, se emplean ampliamente en inferencia, donde los pesos congelados pueden mapearse a escalas calibradas. La cuantización de pesos de INT4 reduce el tamaño de un modelo de 7 mil millones de parámetros de aproximadamente 14 GB a 3,5 GB, tras tener en cuenta la sobrecarga generada por runtime; es necesario evaluar la calidad del resultado según el modelo y el método seleccionados.

FP8 entrenamiento en H100 mediante Motor Transformer Utiliza E4M3 cuando es crucial la precisión y E5M2 cuando se requiere un rango más amplio. Según NVIDIA, en una configuración de 175 mil millones de parámetros probada, se logra un tiempo de ejecución hasta un 75 % más rápido en tiempo real. DeepSeek-V3 Se empleó FP8 de precisión mixta y se registró un gasto en cálculos equivalente a alquileres de aproximadamente 5,6 millones de dólares durante la fase final de entrenamiento, sin incluir los costes relacionados con I+D e infraestructura.

26. Punto de control del gradiente

Cada capa de la pasada forward genera una salida intermedia denominada activación:

$\text{Entrada} \rightarrow [\text{Capa 1}] \rightarrow \text{activación}_1 \rightarrow [\text{Capa 2}] \rightarrow \text{activación}_2 \rightarrow [\text{Capa 3}] \rightarrow \text{Salida}$

Por lo general, todas las activaciones deben permanecer en memoria, ya que la retropropagación las necesita para calcular los gradientes. En el caso de un transformador profundo, las activaciones almacenadas pueden ocupar más memoria que los propios pesos del modelo.

El checkpointing de gradientes compagina el consumo de recursos computacionales con el uso de memoria al descartar la mayor parte de esas activaciones y volver a calcularlas dinámicamente durante la retropropagación. La estrategia estándar (Chen et al., 2016) Divide una red formada por $n$ capas en $\sqrt{n}$ segmentos equidistantes entre sí y guarda únicamente la activación en los bordes de cada uno de ellos. Dichas activaciones de borde guardadas son las “checkpoints.” Todas las activaciones intermedias dentro de un segmento se descartan de inmediato.

Cuando el paso hacia atrás llega a una capa dentro de un segmento, sus activaciones se vuelven a calcular a partir del checkpoint más cercano. Esto reduce la memoria de activaciones de $O(n)$ a $O(\sqrt{n})$, lo que supone una reducción del 60–70% en la práctica, a un costo de aproximadamente un paso hacia adelante adicional (~20–33% más cálculos). FlashAttention aplica el mismo principio dentro de los mecanismos de atención al no materializar toda la matriz de atención. Se puede habilitar en HuggingFace con gradient_checkpointing=True.

27. Etapas ZeRO de DeepSpeed

En el paralelismo de datos estándar, cada GPU alberga una copia completa de los pesos del modelo, las gradientes y los estados del optimizador. En el caso de Adam, cada parámetro ocupa 2 bytes para el FP16 peso, 4 bytes para el FP32 peso maestro, 4 bytes para el momento, 4 bytes para la varianza y 2 bytes para la gradiente, lo que suma 16 bytes por parámetro. Un modelo con 7,5 mil millones de parámetros requiere aproximadamente 120 GB por GPU, y cada GPU almacena exactamente lo mismo. En 64 GPUs, esto equivale a 64 copias idénticas de 120 GB cada una. Es una gran pérdida de recursos.

DeepSpeed ZeRO (Optimizador de Cero Redundancia) elimina esta duplicación al distribuir estos componentes en GPUs en lugar de replicarlos:

• Etapa 1: particionado de los estados del optimizador. Cada GPU almacena únicamente 1/N de los estados del optimizador (el momento y la varianza de Adam, 8 bytes/párametro). Cuando un GPU necesita actualizar un peso, solo actualiza su porción correspondiente y difunde el resultado. La memoria disminuye de ~120 GB a ~31 GB por GPU.
• Etapa 2: particionado también de los gradientes. Los gradientes (2 bytes/párametro) ya no se reducen en su totalidad para cada GPU. Cada GPU recibe únicamente la porción de gradiente que necesita mediante la técnica reduce-scatter. La memoria se reduce a ~16 GB por GPU.
• Etapa 3: particionado también de los pesos del modelo. Cada GPU contiene solo 1/N de los pesos de FP16. Antes de la pasada forward o backward de cada capa, el GPU realiza una operación all-gather para reconstruir temporalmente los pesos completos de la capa a partir de todos los demás GPUs, realiza los cálculos necesarios y descarta dichos pesos. La memoria se reduce a ~1,9 GB por GPU.

El compromiso radica en la comunicación entre nodos. La Etapa 1 añade una sobrecarga mínima; la Etapa 2 sustituye el algoritmo all-reduce por reduce-scatter, manteniendo un costo similar. Sin embargo, la Etapa 3 requiere llamadas de tipo all-gather antes de cada capa, tanto en las pasadas hacia adelante como hacia atrás, lo que supone aproximadamente 1,5 veces más volumen de comunicación en comparación con el paralelismo de datos estándar.

ZeRO-Infinity Amplía la Etapa 3 al transferir los estados particionados a la RAM de CPU e incluso a SSDs NVMe, lo que permite entrenar modelos con billones de parámetros en clústeres GPU de recursos limitados. El costo es una reducción significativa en la velocidad (el NVMe es aproximadamente 500 veces más lento que HBM); por eso, ZeRO-Infinity es la opción a emplear cuando el modelo realmente no cabe en la memoria GPU + CPU.

28. FSDP: particionamiento nativo de PyTorch

Paralelismo de datos completamente shardizado (FSDP) Se trata de la solución integrada de PyTorch frente a DeepSpeed ZeRO-3. Esta técnica distribuye los parámetros, los gradientes y los estados del optimizador entre GPUs siguiendo el mismo principio fundamental. La lógica detrás de cada capa consiste en un bucle sencillo:

1. Reunir todos los parámetros desde todos los GPUs (reconstruyendo temporalmente la capa completa).
2. Calcular la pasada hacia adelante o hacia atrás para dicha capa.
3. Liberar de inmediato los parámetros reunidos. Cada GPU conserva únicamente su propio fragmento.
4. Reducir y dispersar los gradientes de modo que cada GPU reciba solo la porción de gradiente que le corresponde.

Dado que FSDP es nativo de PyTorch, se integra directamente con las herramientas de depuración, los perfiladores y PyTorch de dicho entorno. torch.compile. El rendimiento en comparación con DeepSpeed ZeRO-3 depende de la política de envoltura, la topología de comunicación, los parámetros de descarga y el tamaño del modelo; por lo tanto, es necesario compararlos en el mismo clúster.

FSDP2 (2024–2025) es una reescritura que mejora torch.compile integración para una mejor fusión de kernels, que añade soporte de entrenamiento mediante FP8 TorchAO, y simplifica el API. Tanto FSDP como DeepSpeed son accesibles a través de HuggingFace Accelerate, lo que permite alternar entre ellos con un único cambio en la configuración.

29. Leyes de escala y la trampa de Chinchilla

Escalado de Chinchilla (DeepMind, 2022) determinó que, bajo sus suposiciones, existía una asignación óptima desde el punto de vista computacional de aproximadamente 20 tokens de entrenamiento por parámetro. Dicho objetivo no tiene en cuenta el costo asociado a las operaciones posteriores con serving. Si un modelo más pequeño, entrenado con mayor cantidad de datos, logra alcanzar la calidad requerida, es posible que su costo total durante un ciclo de inferencia a gran escala sea menor.

La solución consiste en sobreentrenar modelos más pequeños con una cantidad mucho mayor de datos. La evolución es sorprendente:

Para un modelo que se sirve a gran escala, invertir más recursos de cómputo en entrenamiento en un modelo más pequeño puede reducir los costes a lo largo de su ciclo de vida. Llama 3 8B ilustra esta estrategia, pero el hecho de que sea ventajosa depende de la calidad requerida y del volumen previsto de inferencias. El término «óptimo para Chinchilla» se refiere a la eficiencia en el uso del cómputo para el entrenamiento, lo cual es un objetivo distinto de los costes a lo largo del ciclo de vida.

30. RLHF, DPO, GRPO, y el panorama de alineación

Alineación sirve para orientar un modelo preentrenado hacia las instrucciones, preferencias y políticas de seguridad deseadas. Por sí sola, no garantiza la veracidad ni un comportamiento seguro. Los métodos que se describen a continuación establecen un equilibrio entre la complejidad de implementación, los requisitos de datos, la exploración y la estabilidad del entrenamiento.

El clásico RLHF pipeline: SFT → recopilar pares de preferencias humanas → entrenar un modelo de recompensas con dichos pares → ajustar finamente la política mediante PPO (Optimización de Políticas Proximal). PPO mantiene 4 copias del modelo en memoria al mismo tiempo (la política, el modelo de referencia, el modelo crítico/valor y el modelo de recompensas); es sensible a los hiperparámetros y está propenso al reward hacking, fenómeno por el cual el modelo explota peculiaridades del modelo de recompensas (como respuestas extensas y que suenan seguras) en lugar de mejorar realmente la calidad.

DPO (Optimización de Preferencias Directas) omite el modelo de recompensa aprendido y el bucle de RL en tiempo real, al optimizar directamente una función de pérdida basada en pares de preferencias. Esto simplifica el proceso de entrenamiento pipeline. El DPO estándar es offline: se entrena con un dataset fijo y no explora nuevas respuestas durante el bucle de actualización. La importancia de esta limitación depende de la tarea y del grado de cobertura de los datos.

GRPO (Group Relative Policy Optimization, DeepSeek) elimina el crítico aprendido por PPO al generar múltiples completaciones para cada prompt y utilizar recompensas relativas entre grupos como línea de referencia. De este modo, se reduce la carga en el estado del modelo en comparación con una configuración típica de PPO. A diferencia de DPO, GRPO funciona según la política: el modelo genera respuestas nuevas durante el proceso de entrenamiento. DeepSeek-R1 Combina GRPO con RLVR (aprendizaje por refuerzo a partir de recompensas verificables), mediante la realización de comprobaciones como respuestas matemáticas, compilación de código y pruebas unitarias. Estas recompensas resultan más fáciles de auditar que una puntuación de preferencia aprendida, pero aún así es posible explotar pruebas incompletas u objetivos sustitutivos.

31. Destilación: comprimir conocimiento entre modelos

La destilación de conocimiento permite transferir capacidades desde un modelo “maestro” de gran tamaño hacia uno “estudiante” más pequeño. La destilación basada en logit entrena al modelo estudiante para que reproduzca la distribución de salidas del modelo maestro. Por su parte, la destilación basada en datos hace que el modelo maestro genere ejemplos sobre los cuales el modelo estudiante se ajusta mediante entrenamiento fino. Los métodos basados en datos son frecuentes en LLMs, ya que pueden aplicarse en distintas arquitecturas e incluso con modelos maestros basados únicamente en API; no obstante, su eficacia está limitada por la calidad del modelo maestro, el grado de cobertura de los datos, los procesos de filtrado y el costo asociado a la generación de estos últimos.

DeepSeek-R1 Se generaron 800.000 ejemplos de razonamiento y se emplearon para refinar los modelos Qwen2.5 y Llama 3, reduciendo sus parámetros de 1,5 mil millones a 70 mil millones. En la evaluación presentada en el artículo:

• DeepSeek-R1-Distill-Qwen-32B obtiene un 72,6 % en AIME 2024 y un 94,3 % en MATH-500, cifras superiores a los resultados reportados por OpenAI para el modelo o1-mini en el artículo correspondiente.
• DeepSeek-R1-Distill-Qwen-7B alcanza un 55,5 % en AIME 2024, valor también superior al resultado obtenido con el modelo más pequeño QwQ-32B-Preview según se indica en el estudio.

En los experimentos con modelos pequeños de DeepSeek-R1, la destilación obtuvo mejores resultados que el método directo GRPO en los modelos base probados. Dicho resultado respalda el uso de la destilación para este escenario; no establece, sin embargo, una clasificación universal entre este enfoque y el aprendizaje por refuerzo.

32. Generación de datos sintéticos

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

• Autoinstrucción Se inicia con un conjunto inicial reducido de instrucciones escritas por humanos: el LLM genera nuevas instrucciones, entradas y salidas, las cuales se filtran y se vuelven a incorporar al conjunto. Alpaca El proyecto utilizó 52.000 ejemplos provenientes de 175 semillas y registró un costo de generación aproximado de 600 dólares; su comparación con GPT-3.5 constituyó una evaluación limitada del proyecto, y no representa una equivalencia total.
• Evol-Instruct (WizardLM) toma las instrucciones existentes y las evoluciona de forma iterativa a lo largo de los ejes de complejidad (añadiendo restricciones, profundizando el razonamiento y haciendo que los problemas sean más concretos) para generar ejemplos de entrenamiento cada vez más difíciles.
• Microsoft’s Phi-4** (14B) utilizó datos sintéticos para la mayor parte del preentrenamiento, incluyendo tareas de generación, crítica, auto-revisión e inversión de instrucciones. Su informe técnico compara el rendimiento obtenido en áreas como las STEM y la programación con el de modelos más grandes en el conjunto de datos seleccionado benchmarks.

El riesgo relevante en este contexto es el colapso del modelo: cuando los modelos se entrenan de forma recursiva con datos sintéticos generados por generaciones anteriores, las partes periféricas de la distribución original desaparecen progresivamente. El modelo sobreestima los patrones comunes y pierde las variaciones raras pero importantes (Shumailov et al., 2024). Un estudio independiente realizado por Ahrefs clasificó al 74,2 % de las páginas web recién creadas en su muestra de 900.000 páginas como contenientes texto generado por AI; se trata de un resultado obtenido mediante un clasificador de terceros, y no de un censo completo de la web. La mitigación de este problema comienza con la combinación de datos sintéticos y reales, la filtración y el seguimiento de la línea de origen, de modo que sea posible medir el material generado de forma recursiva.

Parte VI — Escalado e implementación

Escalar de un GPU a un clúster implica distribuir el trabajo entre varios dispositivos. Esta sección aborda las estrategias de paralelismo, la selección de serving frameworks, GPU, así como los mecanismos de enrutamiento.

33. Cuatro formas de paralelismo

Paralelismo de tensores (PT) consiste en distribuir las matrices de pesos individuales entre GPUs y, por lo general, se realiza la comunicación después de cada capa. Los enlaces rápidos dentro del mismo nodo, como NVLink, lo hacen especialmente práctico dentro de un único nodo. Un mayor número de fragmentos disminuye la memoria y el cálculo por dispositivo, pero aumenta la comunicación; por ello, es necesario elegir el grado adecuado teniendo en cuenta una latencia benchmark.

Pipeline Paralelismo (PP) distribuye las capas de forma secuencial a lo largo de GPUs, transfiriendo las activaciones entre las distintas etapas. Su patrón de comunicación puede funcionar entre nodos, pero pipeline los fenómenos de burbuja y las diferencias en el tiempo de ejecución de las etapas reducen la eficiencia de uso. Las implementaciones a gran escala suelen combinar el TP dentro de un mismo nodo con el PP entre varios nodos.

Paralelismo de datos (PD) replica el modelo serving de modo que cada réplica gestione solicitudes independientes, sin necesidad de comunicación entre réplicas para cada petición. Resulta eficiente cuando el modelo cabe dentro de los límites y se puede equilibrar el tráfico. Durante el entrenamiento, el PD se combina habitualmente con ZeRO o FSDP para dividir el estado del modelo.

Paralelismo experto (PE) distribuye los MoE expertos a lo largo de GPUs mediante comunicación todo-con-todo para la gestión del enrutamiento de tokens. Su rendimiento depende del equilibrio de tokens, de la ubicación de los expertos y de la topología de interconexión; el tráfico todo-con-todo puede convertirse en el cuello de botella principal.

Una heurística de paralelismo inicial:

• El modelo cabe en un único GPU: se empieza con réplicas independientes y se mide la escala del DP.
• El modelo cabe dentro de un nodo: se prueba el TP dentro del nodo y, si el tráfico lo exige, se replica el grupo.
• El modelo abarca varios nodos: se prueba una combinación de TP y PP teniendo en cuenta los requisitos de interconexión y los límites de latencia.
• Mezcla de expertos: solo se añaden EP cuando es necesario por la ubicación de los expertos.

34. Comparación de Serving y frameworks

vLLM Ofrece una asignación de KV paginada, procesamiento por lotes continuo, un API compatible con OpenAI, y varios modos de paralelismo. Los cambios en su soporte para modelos y hardware ocurren con frecuencia, por lo que es necesario verificar el modelo objetivo contra la matriz de compatibilidad actual.

SGLang Combina RadixAttention para el reutilizzo de prefijos, un planificador personalizado y una generación estructurada. Las mejoras en el rendimiento publicadas dependen del trabajo a realizar y de la configuración; compárelo con vLLM y TensorRT-LLM utilizando los mismos prompts, resultados, hardware y SLOs.

TensorRT-LLM Logra una baja latencia por solicitud gracias a la fusión de grafos y la optimización de kernels mediante CUDA, además de contar con soporte nativo para FP8/FP4. Las cifras publicadas son específicas del hardware y del modelo, por lo que es necesario compararlas con las de otros frameworks en un mismo harness. La contrapartida es una curva de aprendizaje más pronunciada y una superficie de despliegue propia de NVIDIA.

TGI Se integra con el ecosistema de Hugging Face y es compatible con varios backends de hardware. Antes de elegirlo para una nueva implementación, consulte el estado actual de mantenimiento y las funcionalidades disponibles en el repositorio.

Ollama Resalta un flujo de trabajo sencillo con modelos locales. Úsalo para facilitar el desarrollo; benchmark otro stack de serving cuando sea necesario gestionar una alta concurrencia o aplicar un control explícito de SLO.

llama.cpp Se trata de una implementación portátil en C/C++ runtime que funciona con arquitecturas ARM, x86, Metal, CUDA, ROCm y Vulkan. GGUF admite varios niveles de cuantización. El rendimiento varía significativamente en función del modelo, el nivel de cuantización, el contexto y las backend, por lo que es necesario utilizar la herramienta local benchmark correspondiente a la máquina destino.

35. Selección de GPU para la inferencia

La tabla muestra un estado actualizado a marzo de 2026 de los precios de hardware y servicios en la nube. Las etiquetas de precisión corresponden a las capacidades ofrecidas por los proveedores, y los precios pueden variar según el proveedor, la región, el nivel de compromiso contractual y la disponibilidad; es necesario verificarlos antes de realizar la compra.

Primero, seleccione el modelo en función de su capacidad de memoria adecuada, y posteriormente según el rendimiento medido al alcanzar el objetivo de latencia. La capacidad de 141 GB del H200 puede simplificar la implementación de algunos modelos grandes, mientras que el B200 incluye soporte para FP4, 192 GB de HBM3e y una generación más reciente de NVLink. Los GPUs más pequeños basados en GDDR pueden resultar económicos para modelos cuantizados cuando sus limitaciones de memoria e interconexión se ajustan al trabajo a realizar.

La compatibilidad con cuantización nativa en hardware tiene una gran influencia en el rendimiento. AWQ y GPTQ (con pesos de INT4) pueden ejecutarse de forma eficiente en cualquier arquitectura al ser decuantizados en registros FP16, pero la verdadera aceleración nativa mediante núcleos Tensor depende de la generación del hardware. Hopper (H100/H200) y Ada (L40S/4090) aceleran de forma nativa las operaciones FP8, mientras que Blackwell (B200) incorpora núcleos Tensor FP4 nativos que permiten obtener mayores ganancias de rendimiento. Todos los modelos GPUs mencionados admiten operaciones matriciales INT8.

LLM La decodificación suele estar limitada por el ancho de banda de la memoria, por lo que HBM La capacidad y el ancho de banda pueden ser más importantes que los TFLOPS pico para serving Cargas de trabajo. Comparar GPUs con el modelo, la precisión, la distribución por lotes, la longitud de contexto y el objetivo de latencia manteniéndose constantes.

36. Cascado y enrutamiento de modelos

La ruta de modelos selecciona qué LLM procesará cada consulta en función de la complejidad o capacidad predicha. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) informa de una reducción del 85 % en los costes en su configuración de MT-Bench, manteniendo al mismo tiempo el 95 % del nivel de calidad base del GPT-4. El hecho de que la redirección sea rentable depende de los precios actuales, la composición del tráfico, los errores del router y el umbral mínimo de calidad exigible.

Los routers van desde clasificadores ligeros hasta evaluadores basados en LLM. La variante en cascada consiste en que una consulta comienza con un modelo menos costoso y pasa a utilizar uno más potente cuando la función de puntuación rechaza la respuesta obtenida. FrugalGPT

Parte VII — Aplicaciones

Patrones a nivel de aplicación que convierten las capacidades brutas del modelo en sistemas útiles. La recuperación de Embeddings potencia dichos sistemas, RAG permite fundamentar las respuestas en conocimientos externos, los agentes orquestan flujos de trabajo de múltiples pasos, y prompt engineering sirve como elemento unificador de todo ello.

37. Embedding modelos frente a modelos generativos

Los modelos Embedding codifican el texto en vectores de dimensión fija que capturan el significado semántico. A diferencia de los modelos generativos de decodificador que producen secuencias de tokens, estos emiten un único vector denso (con 768–4,096 dimensiones) que representa todo el contenido de entrada. La mayoría de los modelos embedding emplean transformadores con solo encoder (atención bidireccional) en lugar de decodificadores. El encoder procesa todos los tokens de entrada al mismo tiempo y genera una representación contextualizada para cada uno de ellos. A continuación, una capa de agrupamiento reduce esas representaciones por token a un único vector, generalmente mediante pooling promedio (al calcular la media de todas las embeddings del token) o pooling CLS (utilizando la salida de un token especial de clasificación). Finalmente, el modelo se ajusta mediante aprendizaje contrastivo: los textos semánticamente similares se acercan entre sí en el espacio vectorial, mientras que los textos no similares se separan.

Modelos embedding seleccionados y sus puntuaciones reportadas (2025–2026):

La tabla combina los informes de los modelos con las versiones de benchmark, por lo que se trata de una lista preliminar y no de un ranking estricto. Algunos sistemas más recientes de tipo embedding emplean arquitecturas de decodificador basadas en atención bidireccional y mecanismos de agrupamiento de información. Otros, en cambio, generan embeddings de menor precisión o de tipo multimodal. Es necesario evaluar el idioma, la modalidad, la tarea, la dimensión y el costo asociado a serving en un único conjunto de recuperación de datos.

Aprendizaje de representaciones tipo Matryoshka (MRL, Kusupati et al., NeurIPS 2022) Hace que las dimensiones de embedding sean flexibles. Llamadas así por las muñecas rusas matryoshka, las estructuras MRL organizan un embedding de tal manera que sus primeras $m$ dimensiones contengan tanta información como un modelo $m$-dimensional entrenado de forma independiente. Durante el entrenamiento, en lugar de calcular una única pérdida sobre todo el embedding, MRL calcula múltiples pérdidas de forma paralela en dimensiones espaciadas logarítmicamente (64, 128, 256, 512, 1024, 2048, 3072). La pérdida agregada hace que las dimensiones más importantes transmitan información semántica gruesa, mientras que las dimensiones posteriores aportan detalles más precisos.

Tras el entrenamiento, un MRL embedding puede ser truncado a una dimensión de prefijo compatible. OpenAI indica que text-embedding-3-large con 256 dimensiones supera en rendimiento a text-embedding-ada-002 con 1.536 dimensiones en la comparación MTEB que mencionan. Esto supone una reducción de 6 veces en el almacenamiento de vectores brutos; además, la latencia de búsqueda y el costo del banco de datos también dependen del índice, los metadatos, los mecanismos de filtrado y el hardware utilizado.

El modelo embedding es un componente fundamental dentro de un RAG pipeline, junto con el análisis sintáctico, el chunking, la búsqueda, reranking y la generación. Si no se recuperan pruebas relevantes, un generador más potente no podrá recuperarlas de forma fiable.

38. Arquitectura RAG en entorno de producción

La generación reforzada por recuperación proporciona un LLM con documentos obtenidos en el momento de la consulta. Puede ofrecer evidencias actuales o privadas que no forman parte de los pesos del modelo, pero la recuperación no garantiza que la respuesta utilice dichas evidencias de forma correcta. Un sistema RAG en entorno de producción es un pipeline de múltiples etapas cuyas fases requieren una evaluación independiente.

La ingesta pipeline se realiza de forma offline. Los documentos en bruto (PDF, HTML, Markdown, bases de datos) se analizan primero para convertirlos en texto limpio, una tarea más compleja de lo que parece, ya que solo el análisis de PDF puede hacer que se pierdan tablas, encabezados y formato. A continuación, el texto se divide en trozos, los cuales se incrustan e indexan de manera independiente.

El particionamiento afecta tanto a la recuperación y al recuerdo como al contexto disponible para el generador. Los tamaños óptimos dependen de la estructura del documento, de la granularidad de la consulta, de los límites del módulo de incrustación y de los límites de reranker. Los enfoques más habituales son el particionamiento de tamaño fijo con solapamiento, la división recursiva a lo largo de los límites del documento y el particionamiento semántico basado en la similitud mediante embedding. Es recomendable compararlos mediante etiquetas de relevancia a nivel de página o sección, en lugar de adoptar un rango de tokens único para todos los casos.

Cada fragmento se incrusta posteriormente con un modelo similar a aquellos de Sección 37 y se almacena en una base de datos vectorial (Pinecone, Weaviate, Qdrant, pgvector, etc.).

La recuperación de pipeline se ejecuta en el momento de la consulta. Comience con una línea de base medible y, posteriormente, añada etapas siempre que el análisis de errores demuestre que estas abordan fallos reales:

• Búsqueda híbrida: combina la recuperación vectorial densa con métodos de recuperación dispersos como BM25, y suele integrarse mediante Reciprocal Rank Fusion (RRF). La búsqueda densa gestiona las paráfrasis semánticas, mientras que la búsqueda dispersa detecta identificadores exactos, códigos de error y acrónimos. Los proveedores benchmarks informan de mejoras respecto a las soluciones basadas únicamente en vectores, pero el tamaño del conjunto de resultados depende del corpus y de las etiquetas de relevancia.
• Reranking hace pasar los candidatos recuperados por un modelo que evalúa tanto la consulta como el documento. Esto permite lograr una relevancia más detallada, aunque a costa de realizar una llamada adicional al modelo. Es necesario ajustar de forma conjunta el número de candidatos, el número de resultados conservados y la latencia. He tratado en profundidad el proceso multietapa completo de pipeline en Desarrollo de una pila moderna para el ranking de búsquedas.
• La transformación de consultas reescribe la consulta del usuario antes de la recuperación de información con el objetivo de mejorar el recuerdo. HyDE (Documento hipotético Embeddings) cuenta con la capacidad de LLM para generar una respuesta hipotética, la cual se incorpora posteriormente y se utiliza en el proceso de recuperación. La expansión de múltiples consultas crea varias formulaciones de la misma pregunta. El prompting por retroceso consiste en plantear primero una pregunta más general a fin de obtener un contexto más amplio.

Los modos de fallo más habituales:

• Error de recuperación — el documento correcto existe pero no se recupera. Pruebe la particionación en fragmentos, la transformación de consultas, la búsqueda híbrida y el filtrado de metadatos frente a este caso de fallo.
• Envenenamiento de contexto — los fragmentos recuperados irrelevantes inducen a error al LLM. Pruebe el reranking, los filtros de contexto y conjuntos más reducidos de información conservada.
• Perdido en medio — el LLM ignora el contexto relevante que se encuentra en medio de un prompt largo.Liu y colaboradores, 2024 Se observó que los modelos prestan mayor atención al principio y al final de la ventana de contexto).

GraphRAG (Microsoft, 2024) mejora la recuperación de vectores mediante un grafo de entidades y relaciones extraído. Está orientado a consultas a nivel de corpus que contienen muchas relaciones y que podrían pasar desapercibidas con métodos de recuperación basados en fragmentos planos. El costo que conlleva es el trabajo adicional necesario para realizar la extracción, indexación, almacenamiento y evaluación.

Las guías para profesionales publican rangos de latencia para embedding, búsqueda, reranking y generación, pero dichas cifras varían en función de la región, el corpus, el hardware y el modelo. Es necesario medir cada etapa a través de trazas y evaluar los cambios en la calidad antes de aceptar el aumento de latencia que se genera.

39. Arquitecturas de agente y llamadas a herramientas

Los LLM emplean modelos para seleccionar y secuenciar tool calls en torno a un estado en constante evolución. Tres patrones de orquestación útiles son:

• ReAct — entrelaza la selección de acciones con las observaciones. Puede adaptarse tras cada tool result, pero un historial cada vez más extenso incrementa los costes en términos de tokens y latencia. ReWOO — planifica tool calls con marcadores de posición, ejecuta tareas independientes en paralelo y, posteriormente, realiza la síntesis. El artículo correspondiente indica un ahorro de tokens respecto a ReAct, pero el plan fijo requiere un camino de recuperación explícito cuando alguna herramienta falla.
• Planner-executor — separa la fase de planificación de la de ejecución y permite incorporar una política de replanificación tras un fallo. Aunque facilita la especialización del modelo, introduce un estado de orquestación adicional así como otro umbral de decisión.

Function calling es un mecanismo habitual para la invocación de herramientas. Las APIs permiten exponer las definiciones de las herramientas y devolver argumentos estructurados, lo que disminuye la necesidad de analizar texto en formato libre. Aun así, los argumentos que cumplen con la validación del esquema pueden seleccionar la herramienta incorrecta o contener valores no válidos. La ejecución paralela function calling puede reducir los viajes de ida y vuelta cuando las operaciones son independientes.

Structured output y constrained decoding imponen un esquema al restringir los tokens disponibles en cada paso de generación. Motores como xgrammar, Se emplea en vLLM y SGLang, y permite eliminar numerosos errores de sintaxis y análisis con un bajo coste adicional en las configuraciones compatibles. No garantizan que los valores ni las decisiones extraídas sean correctos. Razonamiento guiado por esquema (SGR) emplea el orden de los campos y la estructura del esquema para permitir inspeccionar el estado intermedio antes de tomar la decisión final. Sus tres patrones son Cascade (pasos secuenciales), Routing (tipos union como conmutadores semánticos) y Cycle (listas acotadas).

La calidad en la selección de herramientas, la latencia de extremo a extremo y el costo por token suelen empeorar a medida que aumenta el conjunto de herramientas y la profundidad de las acciones. Es necesario medir esas curvas utilizando las descripciones reales de las herramientas y la distribución de fallos. Frameworks como LangGraph Se pueden especificar de forma explícita los estados y las rutas de recuperación, pero esto no elimina la carga asociada a la evaluación.

40. Prompt engineering para entornos de producción

La generación de prompts en entorno de producción constituye un problema de evaluación: se modifica una parte del prompt o del contexto, y a continuación se mide la calidad de la tarea así como los modos de fallo asociados. Las técnicas que se describen a continuación son puntos de partida habituales, pero no representan un orden universal.

Ejemplos de few-shot suelen ser eficaces para controlar el formato de la salida. Comience con 3–5 ejemplos que abarquen entradas vacías, consultas ambiguas y respuestas multifacéticas, y luego evalúe los resultados en un conjunto reservado. Los ejemplos deben reflejar la distribución real de las entradas, y no solo los casos fáciles. Un mayor número de ejemplos consume más contexto y no garantiza mejoras adicionales.

Chain-of-thought (CoT), el prompting consiste en solicitar a un modelo que exponga su razonamiento intermedio antes de dar una respuesta. Kojima y colaboradores informaron sobre mejoras al incluir el sufijo “Vamos a pensar paso a paso” en las tareas de razonamiento que probaron, pero este efecto varía según el modelo, y los métodos de razonamiento más recientes APIs podrían no revelar rastros ocultos. En entornos de producción, es preferible utilizar una descomposición de la tarea claramente observable o una justificación concisa siempre que sea útil para el evaluador. Autoconsistencia (Wang et al., 2023) prueba varios caminos de razonamiento y agrega las respuestas obtenidas, sacrificando un costo adicional de inferencia a cambio de una mayor robustez en tareas adecuadas.

Structured output con esquemas JSON explícitosSección 39) Elimina numerosos fallos de análisis sintáctico. Los motores Constrained decoding como xgrammar pueden hacer cumplir la gramática admitida durante la generación; no obstante, la precisión factual y la validez semántica siguen requiriendo evaluación, y es posible que aún sea necesario gestionar las características del esquema que no estén soportadas.

Prompt chaining consiste en dividir una tarea en fases específicas, como por ejemplo: clasificar la intención → recuperar el contexto → generar la respuesta → validar la salida. Este enfoque permite localizar las fallas, utilizar modelos diferentes en cada fase y exponer estados intermedios que puedan guardarse en caché. No obstante, también introduce interfaces adicionales y aumenta la latencia, por lo que es conveniente compararlo con un escenario basado en una sola llamada.

La temperatura modifica la distribución de muestreo. Valores bajos constituyen un punto de partida razonable para tareas de clasificación o extracción; valores más altos pueden aumentar la diversidad en procesos de generación de ideas. El comportamiento exacto varía según el modelo APIs e interactúa con top_p, top_k, así como los valores predeterminados del proveedor; por lo tanto, se deben recorrer los parámetros compatibles de la tarea en lugar de copiar un único rango.

Separación entre mensajes del sistema y del usuario permite mantener la política persistente independiente del contenido de cada solicitud. Las plantillas de chat y el ajuste de instrucciones otorgan prioridades diferentes a estos roles, pero no convierten a un mensaje del sistema en un límite para la aplicación de reglas. Coloca el comportamiento estable en los mensajes del sistema, guarda los datos no fiables en el contenido del usuario o de las herramientas, y aplica también restricciones estrictas como la eliminación de PII fuera del modelo.

Context engineering amplía el alcance de prompt para incluir la compilación de los documentos recuperados, tool results, el historial de conversaciones y los ejemplos. Liu y colaboradores detectaron un efecto de tipo “perdido en el medio” en los modelos de contexto largo que probaron; por lo tanto, la posición debe formar parte de la evaluación en lugar de considerarse irrelevante. He explicado el flujo de trabajo más amplio en Context Engineering para Agentes AI.

Parte VIII — Operaciones en producción

Esta sección trata sobre la limitación de tasas, los modos de fallo, la monitorización, la optimización de costes y la planificación de capacidad en entornos con tráfico real.

41. Limitación de tasa para solicitudes de costo variable

La limitación de velocidad tradicional basada en solicitudes por segundo parte del supuesto de que el costo por solicitud es más o menos constante. LLMs rompe dicho supuesto. Una clasificación con 10 tokens prompt y un análisis de documento con 100K tokens acceden al mismo punto final API, pero su costo difiere en cuatro órdenes de magnitud. La limitación por RPS puede hacer que las solicitudes costosas pasen desapercibidas o, por el contrario, privar innecesariamente de recursos a las solicitudes económicas.

Los sistemas de producción requieren una limitación de tasa basada en tokens en múltiples dimensiones. OpenAI Documenta los límites de solicitudes y tokens según el nivel de uso. Anthropic Separa los límites de tokens de entrada y de salida. Las cuotas exactas y los algoritmos pueden variar, por lo que la documentación del proveedor debe considerarse como la fuente de verdad; el objetivo arquitectónico es poder gestionar de forma independiente las solicitudes y los tokens disponibles.

El patrón de implementación práctico consiste en una jerarquía de límites multidimensional (usuario → aplicación → organización → global), que incluye niveles de prioridad para el acceso premium. A nivel de solicitud, la técnica relevante es la reserva de presupuesto de tokens: se estima la cantidad total de tokens necesarios (entrada + max_tokens) En el momento de la admisión, se deduce del bucket correspondiente, y posteriormente se realiza un ajuste una vez finalizada la solicitud según el consumo real. De este modo, se evita que un aumento repentino de solicitudes de generación prolongada agote la capacidad antes de que siquiera comiencen a generar salida.

En los entornos de implementación autohospedados, lo equivalente es el ancho de banda reservado: se asigna una capacidad dedicada de GPU para alcanzar las tasas de tokens deseadas. En el caso de las implementaciones de vLLM, esto implica configurar un control de admisión basado en los slots de decodificación activos y en la presión generada por KV cache, en lugar de solo en el número total de solicitudes. As Sección 5 Explica que tanto el rendimiento como la admisión requieren límites sensibles a tokens.

42. Modos de fallo contra los que diseñar

LLM serving introducen modos de fallo relacionados con la longitud variable de las secuencias, la memoria KV y las operaciones de decodificación de larga duración. Es necesario diseñar y probar estas medidas de protección bajo carga antes de que el tráfico en producción dependa de ellas.

Out-of-Memory (OOM) es un fallo muy frecuente. Un modelo de 70 mil millones de parámetros FP16 necesita aproximadamente 140 GB solo para sus pesos, y KV cache, al procesar una secuencia con contexto de 128 K, puede añadir unos 40 GB más bajo las suposiciones establecidas. Sección 6. La diferencia entre que algo “quepa en la memoria” y sufrir OOM bajo carga es menor de lo que parece, ya que un lote de solicitudes con contexto largo puede consumir más memoria KV de lo esperado. La prevención implica combinar una reserva de memoria calculada cuidadosamente con cuantización y asignación de KV paginada. En cargas de trabajo con alta presión sobre la memoria KV, LMCache Puede descargue los datos KV en la memoria o el disco de CPU; puede utilizar sus resultados publicados como punto de partida y benchmark la jerarquía de memoria local.

La preemptión se produce cuando la presión generada por KV cache obliga al planificador a expulsar o volver a calcular tareas. La estrategia exacta depende de la versión y la configuración de serving. Desde el punto de vista del usuario, el síntoma es una mayor latencia total sin que aparezca un error evidente en la aplicación. Es necesario monitorizar los conteos de preemptión y correlacionarlos con el uso de estructuras KV, la profundidad de las colas y la longitud de las solicitudes.

La latencia de cola puede aumentar drásticamente cuando los prellenados de gran tamaño retrasan el proceso de decodificación. Los datos se procesan en bloques prefill (Sección 7) Además, la planificación consciente de la longitud ayuda a mitigar esta interferencia. Los trabajos sobre el scheduler Learning-to-Rank y CascadeInfer muestran mejoras significativas con respecto a sus bases de referencia, pero el resultado exacto depende de la distribución de la longitud de las solicitudes y de la configuración del scheduler.

Las fallas en cascada pueden iniciarse cuando las solicitudes lentas hacen que la cola crezca, los clientes ascendentes se agotan en el tiempo de espera y las reintentos generan aún más carga. Las medidas de defensa incluyen el control de admisión, límites de concurrencia por tenant, topes de salida, presupuestos de reintentos y disyuntores de circuito en la pasarela. La desagregación de prefill y los grupos de decodificación pueden resultar útiles cuando las pruebas de carga muestran una interferencia persistente entre fases.

43. Monitoreo de sistemas LLM

El LLM difiere del API tradicional en varios aspectos fundamentales. Cada solicitud conlleva un costo variable, presenta dos fases distintas con cuellos de botella diferentes, y su huella de memoria depende tanto de la longitud de la entrada como de la longitud de la generación. Métricas estándar como la latencia de las solicitudes o la tasa de errores no capturan la mayor parte de los factores relevantes.

Goodput representa la cantidad de solicitudes por segundo que cumplen con todos los umbrales SLO definidos, como TTFT, TPOT y la latencia total. Se trata de una métrica combinada muy útil, ya que el ancho de banda bruto puede parecer adecuado aunque los umbrales de latencia no se cumplan: un sistema que procesa 100 solicitudes por segundo pero falla en satisfacer dichos umbrales en el 40 % de ellas presenta un goodput de 60. Optimizar en función de goodput permite mantener visible la distribución del rendimiento, en lugar de limitarse a informar únicamente el valor promedio.

vLLM expone un endpoint de Prometheus en /metrics Con solicitudes en ejecución y en espera, se deben utilizar KV cache, distribuciones de longitud de generación y estadísticas del caché de prefijos. Los nombres de las métricas pueden variar entre versiones, por lo que es necesario vincular los paneles de control a la versión desplegada. Una arquitectura típica emplea Prometheus para las métricas, Grafana para la visualización, y trazas compatibles con OpenTelemetry en toda la aplicación y en los componentes serving.

Los patrones de alerta útiles incluyen los siguientes. Derive sus umbrales a partir de pruebas de carga en lugar de copiar estos ejemplos sin modificaciones:

• Aumentos bruscos en la cuenta de preemptions: las solicitudes se eliminan y se reinician; los usuarios experimentan un doblamiento silencioso de la latencia.
• La utilización de KV cache se acerca a la zona de preemptions ya probada: es necesario añadir capacidad o reducir la carga antes de que se produzca una cascada de eliminaciones.
• La profundidad de la cola permanece constantemente por encima del límite establecido para los lotes: el control de admisión debería comenzar a rechazar solicitudes o a darles menor prioridad.
• El TTFT aumenta mientras que el TPOT se mantiene estable: esta divergencia indica, en primer lugar, problemas relacionados con la cola, el control de admisión, la red o la presión generada por prefill, y no tanto con el ancho de banda de decodificación. Se deben utilizar registros de trazas y métricas de cola para diferenciar entre estas causas.

44. Optimización de costes: una estrategia de composición

Como referencia histórica, los precios de marzo de 2026 API presentaban diferencias abismales entre las distintas categorías de modelos. Dado que los costes exactos varían con gran rapidez, es necesario utilizar la calculadora actual del proveedor para tomar una decisión de compra. Lo importante a tener en cuenta es que la elección del modelo y la longitud de la salida pueden influir de forma determinante en el costo, incluso antes de aplicar cualquier optimización en la infraestructura.

En la instantánea de marzo de 2026 utilizada para esta sección, los tokens de salida cuestan varias veces más que los tokens de entrada en los niveles del modelo mencionados. Dicha asimetría refleja el trabajo de decodificación secuencial descrito anteriormente. Sección 7. En cuanto a esas estructuras de precios, reducir la cantidad de salida innecesaria puede ser más efectivo que recortar la misma cantidad de tokens de entrada.

Se pueden combinar varios enfoques, pero únicamente tras evaluar cuáles son adecuados para la carga de trabajo:

1. La cuantización de FP16 a INT4 reduce la memoria dedicada a los pesos en un 75 %. Si esto disminuye el costo depende de la velocidad del núcleo, del tamaño del lote y de la utilización del hardware (Sección 9).
2. Enrutamiento de modelos envía el tráfico apto a modelos más económicos. A Estudio de caso del proveedor Maxim AI Se informó de una reducción en la factura mensual, pasando de 42.000 dólares a 29.000 dólares; es necesario reproducir la puerta de calidad antes de tomar prestada su cuota de enrutamiento.Sección 36).
3. Prompt caching reduce el trabajo relacionado con prefijos repetidos. Los descuentos de los proveedores y las políticas de límite de frecuencia cambian con el tiempo, por lo que es necesario combinar la tasa de aciertos medida con las condiciones actuales.Sección 16).
4. El procesamiento por lotes APIs permite abaratar tareas que no son en tiempo real, como las evaluaciones, la generación de datos sintéticos y la clasificación masiva. Consulte los precios actuales y los plazos de finalización.
5. La opción de autohospedaje resulta ventajosa cuando se logra una utilización sostenida, pero no existe un punto de equilibrio universal en cuanto al volumen de tokens. Además del alquiler de GPU, deben tenerse en cuenta los costes relacionados con la ingeniería, la orquestación, la capacidad de observabilidad, el margen de reserva y los servicios de soporte técnico.

Al multiplicar los factores ilustrativos se obtiene una reducción teórica considerable, pero las variables de entrada no son independientes: la cuantización afecta al ancho de banda, el enrutamiento modifica la composición de calidad, y el caché y el agrupamiento por lotes solo son aplicables al tráfico apto. Construya la estimación a partir de las proporciones de tráfico medidas y válidela comparándola con la factura.

A Informe de proveedor de 2024 de TrueFoundry Los atributos que generan la mayor parte del costo de despliegue en estos ejemplos se deben a los esfuerzos de ingeniería asociados a ML y no al consumo de recursos computacionales. Se debe considerar esa cifra como un prompt que incluye los costes laborales y operativos relacionados con el modelo, y no como una proporción universal aplicable en todos los casos.

45. Planificación de capacidad y escalado automático

La planificación de capacidad para LLM serving debe tener en cuenta el costo variable de las solicitudes, los procesos de decodificación de larga duración y la memoria dependiente de la secuencia. Según la carga de trabajo, el recurso limitante puede ser la memoria KV, el ancho de banda de memoria, los recursos de cómputo o la interconexión.

El límite máximo para las solicitudes concurrentes es el presupuesto de memoria KV cache, y no los FLOPS:

$\text{max secuencias concurrentes} = \frac{\text{memoria GPU} - \text{pesos del modelo} - \text{gasto adicional}}{\text{tamaño por secuencia KV cache}}$

En un ejemplo simplificado de Llama 3 70B INT4, unos 35 GB de pesos en una GPU H100 de 80 GB dejan aproximadamente 40 GB una vez reservada la sobrecarga adicional. Con un contexto de 4K, suponiendo 160 MB por secuencia, el límite teórico se sitúa cerca de 250 secuencias; con un contexto de 128K, la misma cálculo arroja un valor de unos cinco. La capacidad real es aún menor si se tienen en cuenta el comportamiento del asignador, los buffers runtime, la variabilidad en la longitud de las solicitudes y los requisitos de latencia establecidos. Por esta razón proceso de selección GPU y optimización KV cache impulsar directamente el plan de capacidad.

La fórmula de capacidad para el cálculo del tamaño de la flota:

$\text{Requisito mínimo GPUs} = \frac{\text{tokens máximos por minuto} \times \text{margen de seguridad medido}}{\text{rendimiento por GPU en el SLO objetivo}}$

Lo importante es que se cumpla el SLO establecido. El rendimiento máximo por token y el rendimiento que sí cumple con los requisitos del SLO pueden diferir significativamente a medida que aumenta la concurrencia. Benchmark, teniendo en cuenta la distribución real de prompt y la longitud de las salidas en los umbrales requeridos de TTFT y TPOT, en lugar de basarse en un valor máximo teórico.

La utilización de GPU resulta insuficiente como único indicador de escalado automático, ya que puede mantenerse elevada tanto durante un procesamiento normal como en situaciones de sobrecarga. Es necesario combinarla con la profundidad de la cola, la utilización de KV cache y el degradación de goodput. Los umbrales deben ajustarse mediante pruebas de carga; valores como el 80 % de utilización de KV sirven como puntos de partida, no como límites universales. Estas métricas se introducen en Sección 43.

La estrategia de escalar a cero resulta útil para entornos de desarrollo y de pruebas con largos períodos de inactividad. Las plataformas de inferencia serverless y los mecanismos de autoescalamiento basados en Kubernetes, como KEDA, permiten liberar capacidad no utilizada, pero los ahorros obtenidos y el tiempo necesario para el arranque en frío dependen del tamaño del modelo, de la caché de imágenes y pesos, así como de la infraestructura empleada. Es necesario medir el tiempo de inicio antes de aplicar esta misma política al tráfico de producción, donde la latencia es un factor crítico.

El sistema interconectado

Estos 45 conceptos no constituyen una colección aleatoria. Forman un sistema interconectado. El tamaño de KV cache determina el tamaño del lote, el tamaño del lote a su vez afecta la intensidad aritmética, esta última controla si la decodificación está limitada por la memoria, lo cual influye en el TPOT, y el TPOT define el rendimiento global. GQA provoca una reducción en KV cache, lo que permite utilizar lotes más grandes, aumentando así la intensidad aritmética y mejorando el grado de utilización de GPU. FlashAttention aprovecha la brecha de ancho de banda entre la SRAM y HBM. La agrupación continua de operaciones resuelve el problema de la baja utilización de los recursos de cómputo, pero genera fragmentación de memoria, problema que es precisamente el que soluciona PagedAttention. La distribución por bloques de prefill permite programar de forma coordinada las tareas dependientes del cómputo y las que dependen de la memoria; el modelo roofline explica por qué esta complementariedad funciona eficazmente.

En el ámbito del entrenamiento, el costo asociado al ciclo de vida puede favorecer la creación de un modelo más pequeño que utilice una mayor cantidad de tokens, como lo ilustra Llama 3 8B. GRPO reduce la carga en el estado del crítico de PPO. En la configuración de modelo pequeño probada en DeepSeek-R1, el método de destilación obtuvo mejores resultados que el RL directo. Se trata de opciones de diseño que deben evaluarse, y no de una única receta para el entrenamiento.

El patrón operativo es más estable que cualquier curva de precios: la enrutación, el caché, la cuantización y el hardware de tamaño adecuado solo surten efecto conjunto cuando cada uno se evalúa con respecto al mismo objetivo de calidad y latencia.

Principios clave

1. LLM la inferencia consta de dos fases bien diferenciadas. En los regímenes típicos de serving, prefill se centra en el procesamiento y la decodificación en el ancho de banda de memoria; la forma del trabajo puede desplazar este límite.
2. El KV cache suele ser una restricción fundamental. Su tamaño influye tanto en la capacidad de procesamiento por lotes como en la presión sobre la memoria. GQA, la asignación paginada y la cuantización KV abordan aspectos distintos de dicha restricción.
3. La jerarquía de memoria GPU explica muchas de las optimizaciones aplicables. La FlashAttention y la fusión de kernels reducen los costosos movimientos de datos en lugar de modificar la función del modelo.
4. El procesamiento por lotes continuo y PagedAttention funcionan en conjunto. Un estudio publicado indica un rendimiento 23 veces superior respecto al método básico; debe medirse el beneficio dentro de su stack de serving.
5. Un diseño óptimo para Chinchilla no es necesariamente óptimo para la inferencia. Por ejemplo, Llama 3 8B se entrenó con aproximadamente 1.875 tokens por parámetro, con el objetivo de obtener más capacidad de cálculo durante el entrenamiento a cambio de una inferencia más económica.
6. GRPO y la destilación han transformado las herramientas de alineación. DeepSeek-R1 mostró resultados más sólidos con modelos pequeños mediante la destilación que con sus experimentos directos basados en RL.
7. La optimización de costes solo se potencia en tráfico apto. La cuantización de modelos, el enrutamiento, el caché y el procesamiento por lotes APIs requieren mediciones separadas de cobertura y calidad antes de que sus ahorros puedan sumarse entre sí.
8. Serving el hardware debe coincidir con el cuello de botella. Las cargas de trabajo con muchos procesos de decodificación suelen beneficiarse de la capacidad y ancho de banda de HBM; las cargas de trabajo intensivas en prefill ponen más énfasis en el poder de cómputo.

Lecturas adicionales

Artículos relacionados de mayor profundidad de este blog, organizados por tema:

• Guía de LLM y Fine-Tuning — ¿Cuándo aplicar ajuste fino frente a RAG y frente a prompt engineering? Variantes y formatos de archivo de código abierto LLM — asociación de variantes de modelo y formatos cuantizados con el hardware Guía de LoRAX Serving — serving miles de adaptadores LoRA en producción
• Escalar modelos de lenguaje grandes — estrategias multi-GPU y multi-nodo Ejecutar LLMs localmente en macOS — configuración práctica con llama.cpp y Ollama AI Bucles de razonamiento de agente en 2026 — Análisis en profundidad de ReAct, ReWOO y los bucles planificador-ejecutor
• AI Arquitectura de memoria de agente en 2026 — checkpoints, almacenes vectoriales y memoria de documentos para agentes con estado.

Referencias

Organizado por área temática; los números de sección aparecen entre paréntesis cuando procede.

Inferencia y atención

• FlashAttention: Atención exacta rápida y eficiente en memoria con conciencia de E/S - Dao et al., NeurIPS 2022 FlashAttention-2: Atención más rápida gracias a un mejor paralelismo y una mayor partición del trabajo. - Dao, 2023
• FlashAttention-3: Atención rápida y precisa mediante asincronía y baja precisión. - Shah et al., NeurIPS 2024 Decodificación flash para inferencia en contextos largos - Dao et al., 2023
• Gestión eficiente de la memoria para modelos de lenguaje grandes Serving mediante PagedAttention - Kwon et al., SOSP 2023
• Orca: Un sistema distribuido Serving para modelos generativos basados en transformadores - Yu et al., OSDI 2022 GQA: Entrenamiento de atención multi-pregunta generalizada - Ainslie et al., 2023
• Triton: un lenguaje intermedio y compilador para cálculos de redes neuronales - Tillet et al., MAPL 2019
• FlashNorm: Normalización rápida para LLMs - 2024
• Fusión profunda de kernels para transformadores - DeepFusionKernel, 2026

Decodificación especulativa

• EAGLE-3: Escalado de la aceleración de inferencia para modelos de lenguaje grandes - Li et al., NeurIPS 2025 Medusa: Una solución sencilla de LLM aceleración de inferencia Framework que cuenta con múltiples cabezales de decodificación. - ICML 2024

Cuantización

• AWQ: Cuantización de pesos sensible a la activación para la compresión y aceleración de LLM - Mejor artículo de MLSys 2024 GPTQ: Cuantización precisa posterior al entrenamiento para transformadores generativos preentrenados - Frantar et al., ICLR 2023
• Marlin: Núcleo de inferencia de precisión mixta (FP16xINT4) LLM - Frantar et al., 2024

Entrenamiento y fine-tuning

• LoRA: Adaptación de rango bajo de modelos de lenguaje grandes - Hu et al., ICLR 2022 QLoRA: Afinado eficiente de LLMs cuantizado - Dettmers et al., NeurIPS 2023
• ZeRO: Optimizaciones de memoria para el entrenamiento de modelos con billones de parámetros - Rajbhandari et al., SC20 ZeRO-Infinity: Superando la barrera de memoria GPU para el aprendizaje profundo a escala extrema - Rajbhandari et al., 2021
• Autoinstrucción: Alineación de modelos de lenguaje con instrucciones autogeneradas - Wang et al., ACL 2023
• WizardLM: Capacitando a los modelos de lenguaje grandes para seguir instrucciones complejas - Xu et al., ICLR 2024 Informe Técnico Phi-4 - Microsoft, 2024 AI Los modelos colapsan al entrenarse con datos generados de forma recursiva. - Shumailov et al., Nature 2024

Alineación

• Optimización de preferencias directas: su modelo de lenguaje es, en realidad, un modelo de recompensas. - Rafailov et al., NeurIPS 2023 DeepSeekMath: Superando los límites del razonamiento matemático en modelos de lenguaje abiertos - Se introdujo GRPO
• DeepSeek-R1: Fomento de la capacidad de razonamiento en LLMs mediante aprendizaje por refuerzo - DeepSeek, 2025

Escalado y arquitectura

• El rebaño de modelos Llama 3 - Meta, 2024 LLaMA: Modelos de lenguaje fundamentales abiertos y eficientes - Touvron et al. (Meta), 2023
• Llama 2: modelos de chat de fundación abierta y ajustados finamente - Touvron et al. (Meta), 2023 Informe Técnico de Qwen3 - Qwen Team (Alibaba), 2025 Entrenamiento de modelos de lenguaje grandes óptimos desde el punto de vista computacional - Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer: Transformador mejorado con posición rotativa Embedding - Su et al., 2021 YaRN: Ampliación eficiente de la ventana de contexto en modelos de lenguaje grandes - Peng et al., ICLR 2024 SGLang: Ejecución eficiente de programas de modelos de lenguaje estructurados - Zheng et al., NeurIPS 2024
• Mixtral de Expertos - Jiang et al. (Mistral AI), 2024

Embeddings

• Aprendizaje de representaciones tipo Matryoshka - Kusupati et al., NeurIPS 2022 pplx-embed-v1: Densidad y contexto preentrenados por difusión Embeddings - Perplexidad AI, 2026

Arquitecturas de agente

• ReAct: Sinergizar el razonamiento y la acción en los modelos de lenguaje - Yao et al., ICLR 2023 ReWOO: Desacoplamiento del razonamiento de las observaciones para modelos de lenguaje aumentados eficientes - Xu et al., 2023

Enrutamiento

• RouteLLM: Aprendizaje para enrutar LLMs mediante datos de preferencias - Ong et al., ICLR 2025

Benchmarks

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

Arquitecturas Serving

• SARATHI: Inferencia eficiente de LLM mediante el aprovechamiento de decodificaciones con rellenos por bloques. - Agrawal et al., 2023 (Chunked Prefill)
• Splitwise: Inferencia generativa eficiente de LLM mediante particionamiento por fases - Patel et al., ISCA 2024 (Desglose de Serving)
• DistServe: Desagregación de Prefill y decodificación para modelos de lenguaje grande optimizados para Goodput Serving - Zhong et al., OSDI 2024 (Serving desagregado)

Serving frameworks

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

Operaciones

• Programación eficiente de LLM mediante el aprendizaje para la clasificación por orden - Fu et al., NeurIPS 2024 (vLLM-LTR) CascadeInfer: Baja latencia y equilibrio de carga LLM Serving mediante programación sensible a la longitud de las secuencias - 2024
• la métrica Goodput como indicador de la productividad ML - Google Cloud, 2024 vLLM Optimización y ajuste - vLLM Documentación vLLM Métricas - vLLM Documentación
• LMCache: Gestión de KV Cache para LLM Serving - KV cache descarga de carga Límites de tasa de OpenAI - Documentación de OpenAI API Límites de tasa de Anthropic - Documentación de Anthropic API