Inferencia de LLM de extremo a extremo: prefill, decode, caché KV y muestreo

De la tecla al token transmitido

Esta guía explica todo el proceso de inferencia: tokenizador, embeddings, atención, caché KV, muestreo y decodificación especulativa, respondiendo a las preguntas más difíciles en cada etapa. El objetivo es contar con un modelo mental listo para ser explicado, no un discurso promocional de un proveedor.

Parte 1: Dos cargas de trabajo, no una

P1. ¿Qué sucede entre la tecla Enter y la primera palabra?

Un seguimiento honesto de principio a fin:

1. Entrada. Llega una cadena UTF-8 como "¿Qué es la gravedad?". La capa de servicio suele envolverla en un plantilla de chat con tokens especiales para los turnos del sistema, el usuario y el asistente.
2. Tokenización. El texto se divide en fragmentos subpalabras y se asignan identificadores numéricos. Esa etapa es pura procesamiento de cadenas; aún no se utiliza ninguna red neuronal.

Búsqueda de incrustación. Cada ID selecciona una fila de la matriz de incrustación E ∈ ℝ^(V × d_model), lo que genera un tensor de tamaño (seq_len, d_model). La señal posicional se agrega aquí o más tarde dentro del mecanismo de atención (RoPE).

Relleno previo. Cada token de la prompt pasa por todos los N capas del transformador juntos. Cada capa almacena sus proyecciones K y V en la cache KV. Esta fase está limitada por cálculos.

Cabeza LM. Solo el estado oculto de la posición final se proyecta al tamaño del vocabulario (~128K logits).

Muestreo. Softmax convierte los logits en una distribución; una política (codiciosa, top-k, top-p, temperatura, …) elige un ID.

Bucle de decodificación. Ese ID se agrega, se incrusta y se pasa nuevamente a través de la pila junto con la caché KV, un nuevo token por paso, hasta que se active una regla de detención.

Destokenización y transmisión en flujo. Los IDs se convierten en fragmentos de texto; el servidor puede enviar cadenas parciales al cliente tan pronto como sean válidas.

El tiempo hasta el primer token es casi siempre el correspondiente a la fase de prellenado. Todo lo que sigue corresponde a la decodificación.

P2. ¿Por qué se denominan de manera diferente las tareas de inferencia?

El prellenado y la decodificación se encuentran en extremos opuestos del modelo roofline.

Cuello de botella FLOPs / cálculo Ancho de banda de memoria Intensidad aritmética Alta Aproximadamente 1–2 FLOPs/byte en el lote 1 A través de tokens Totalmente paralelo Estrictamente secuencial Lente de latencia TTFT TPOT / ITL Escala con Longitud del prompt Longitud de la salida MFU (lote 1) Suele ser del 40–60% Suele ser del 1–5%

En el modo de prellenado se cargan los pesos una vez y se aplican a miles de vectores de tokens. En el modo de decodificación se vuelven a cargar los mismos pesos para un único vector: se transfieren gigabytes de datos para realizar millones de FLOPs. La GPU espera a que esté lista la memoria HBM.

Casi todos los trucos de procesamiento — agrupación de datos, caché KV, cuantización, decodificación especulativa, FlashDecoding, prellenado y decodificación desagregados — existen para alimentar a esa unidad de cómputo con escasez de recursos.

P3. ¿Qué métricas de latencia son importantes y qué factores las influyen?

• TTFT — principalmente el prellenado; aumenta con la longitud del prompt (y empeora cuando predomina la atención). Se ve beneficiado por el caché de prefijos, el prellenado en bloques, una atención más rápida y prompts más cortos.
• TPOT / ITL — principalmente la decodificación; aproximadamente bytes_per_step / ancho de banda. Se ve beneficiado por la cuantización, GQA/MQA, la decodificación especulativa y modelos más pequeños.
• De extremo a extremo ≈ TTFT + TPOT × tokens de salida.
• Rendimiento (tokens/segundo/GPU) — una métrica relativa al conjunto de dispositivos; los lotes más grandes lo elevan, aunque generalmente perjudican el TPOT por usuario.

El rendimiento y la latencia se enfrentan entre sí. La política de servicio consiste en elegir un punto en esa curva.

P4. ¿Por qué la decodificación no puede paralelizarse como el prefill?

La generación es autoregresiva: cada nuevo token depende de todos los anteriores. El prefill ya conoce todo el prompt, por lo que las posiciones pueden calcularse juntas bajo una máscara causal. En la decodificación, el “futuro” aún no existe.

La decodificación especulativa es la solución alternativa: se elaboran conjeturas económicas y luego se verifican en un proceso paralelo dirigido al objetivo, convirtiendo una dependencia secuencial en una verificación paralela (Parte 8).

Parte 2 — Etapas uno y dos: ingreso de texto

P5. Defina un token: ¿y por qué las palabras completas o los caracteres brutos son los extremos incorrectos?

Un token es un átomo subpalabra dentro de un vocabulario fijo. Los extremos puros fallan:

• Vocabularios de palabras son ilimitados; los errores tipográficos y los nombres poco comunes se convierten en <UNK> y destruyen la información al hacer que la tabla de embeddings crezca exponencialmente.
• Vocabularios de caracteres evitan los valores fuera de vocabulario, pero amplían las secuencias entre 4 y 5 veces, lo que perjudica al mecanismo de atención cuadrática y obliga a las capas iniciales a redescubrir la morfología.

Las subpalabras mitigan este problema: las palabras comunes permanecen como un solo elemento; las formas poco frecuentes se dividen en fragmentos significativos; nada es realmente fuera de vocabulario.

P6. ¿Cómo se entrena BPE?

El codificado de pares de bytes parte de los caracteres (o bytes) y fusiona repetidamente la pareja adyacente más frecuente hasta alcanzar el tamaño deseado del vocabulario. Estas fusiones se almacenan como una lista ordenada. Durante la inferencia, se aplican las mismas fusiones de forma agresiva de izquierda a derecha. El entrenamiento se basa en estadísticas cuantitativas, no en descenso de gradiente; sin embargo, la segmentación resultante determina todo lo que ocurre posteriormente.

P7. BPE vs WordPiece vs Unigram / SentencePiece

• BPE — fusión por frecuencia; la decodificación es determinista dado el cuadro de fusión.
• WordPiece (época BERT) — fusiones similares pero evaluadas por probabilidad; suele utilizar marcadores de continuación ##.
• Unigram / SentencePiece — parte de un conjunto grande de candidatos y elimina elementos usando un LM unigramático; puede muestrear segmentaciones y maneja bytes brutos/Unicode de manera eficaz sin necesidad de pretokenizadores específicos del idioma.

Los LLMs de producción actuales tienden a utilizar variantes de BPE o SentencePiece a nivel de byte.

P8. ¿Por qué BPE a nivel de byte?

Trabajar con bytes brutos garantiza que toda cadena sea codificable, evitando fallos inexplicables relacionados con Unicode. El vocabulario sigue aprendiendo fragmentos comunes de varios bytes, por lo que el inglés mantiene su eficiencia, mientras que los sistemas de escritura poco comunes pasan gradualmente a soluciones basadas en bytes.

P9. ¿Por qué los modelos tienen dificultades para contar letras en “strawberry”?

Porque el modelo nunca ve caracteres; ve IDs de token. Si "strawberry" está formado por una o dos partes, la instrucción “cuenta las ‘r’” solicita una estructura que ya fue descartada en la primera capa. Las tareas a nivel de caracteres requieren un tokenizador que preserve los caracteres o una herramienta externa.

P10. ¿Tienen significado por sí solos los IDs de token?

No. Un ID es solo un índice en la tabla de embeddings de ese modelo. El ID 100 en un tokenizador no tiene relación con el ID 100 en otro. Nunca mezcles tokenizadores de modelos diferentes.

P11. Problemas comunes con los tokenizadores en producción

• Los templates de chat y los tokens especiales deben coincidir con el entrenamiento.
• A menudo, los espacios al inicio se convierten en tokens separados: " Hello" ≠ "Hello".

La truncación puede eliminar silenciosamente las instrucciones del sistema si se cuentan los caracteres en lugar de los tokens.

Los mecanismos de respaldo multilingüe basados en bytes aumentan la longitud y el costo.

Los tokens especiales multimodales para imágenes y audio modifican las reglas de empaquetado.

P12. Compromisos en el tamaño del vocabulario

Un V más grande acorta las secuencias y ayuda en la cobertura multilingüe, pero incrementa los parámetros de embedding y LM-head (V × d_model cada uno) así como el costo de decodificación con softmax. Los rangos típicos en la actualidad están entre 32K y 150K; más allá de eso se pagan costos adicionales en memoria y ancho de banda con beneficios decrecientes.

P6. Cómo se entrena realmente BPE

La codificación de pares de bytes es una técnica de compresión reutilizada para el aprendizaje del vocabulario:

1. Se inicia el vocabulario con símbolos básicos (en BPE a nivel de byte: los 256 bytes disponibles).
2. El corpus se expresa como secuencias de esos símbolos.
3. Se cuentan los pares adyacentes y se elige el más frecuente.

Fusiona esa pareja en un nuevo símbolo, áñádelo al vocabulario y registra la regla de fusión ordenada.

Repite el proceso hasta alcanzar el tamaño deseado (por ejemplo, entre ~100K y 128K en las arquitecturas modernas).

Artefactos: un mapa símbolo→ID y una lista de fusión ordenada. La codificación durante las reproducciones de inferencia realiza fusiones de forma agresiva en ese orden, de manera determinista, sin realizar una búsqueda global de segmentación más corta.

Sutilidad: las fusiones optimizan la frecuencia, no los aspectos lingüísticos. ing se convierte en un token porque es común; la elegancia morfológica es secundaria.

P7. BPE vs WordPiece vs Unigram / SentencePiece

• BPE (línea GPT, Llama): fusiones basadas en frecuencia; codificación determinista.

WordPiece (época BERT): ciclo similar, pero elige las fusiones que maximizan la verosimilitud de los datos de entrenamiento bajo un modelo unigramático, evaluando cuán informativo es un par cuando está junto o separado.

Unigram LM (a menudo a través de SentencePiece; categoría T5/Gemma): se comienza con un tamaño grande y se eliminan los tokens cuya eliminación afecta menos la verosimilitud. La segmentación probabilística permite la regularización subpalabra (seleccionando cortes alternativos durante el entrenamiento).

SentencePiece es una biblioteca que puede ejecutar BPE o Unigram. Su ventaja práctica radica en tratar los caracteres brutos con un marcador de espacio visible, lo que hace que la tokenización sea reversible y esté libre de pretokenización de espacios en blanco, algo crucial para el chino, japonés y tailandés.

Q8. El BPE a nivel de byte es importante porque…

Las iniciales formadas por caracteres Unicode requerirían unos 150K símbolos iniciales y aún así necesitarían <UNK>. Empezar con bytes UTF-8 significa que toda cadena —emoticonos, escrituras cirílicas, bytes dañados— puede ser codificada. Sin valores fuera de rango.

Costo: los emoticonos pueden consumir varios tokens; las escrituras no latinas suelen costar de 2 a 4 veces más que el inglés para expresar el mismo significado, por lo que quienes usan idiomas distintos al inglés alcanzan los límites de frecuencia y los topes de contexto más pronto. Existen vocabularios más amplios (con saltos de 32K a 128K) en parte para reducir esa brecha de equidad.

P9. ¿Por qué “¿cuántos ‘r’ hay en strawberry?” falla?

La red nunca ve letras; ve identificadores. Si strawberry está formado por varias subpalabras, contar caracteres requiere recuperar la ortografía a partir de los embeddings y realizar agregaciones; no existe una operación nativa para “recorrer caracteres”. La misma problemática afecta a anagramas, palíndromos, secuencias invertidas y cálculos aritméticos simples cuando el agrupamiento de dígitos es inconsistente entre los números. Los tokenizadores modernos a veces fuerzan la división de dígitos específicamente para que los cálculos aritméticos sean posibles.

P10. Identificadores de tokens por separado

Un identificador es un índice hacia las tablas de ese modelo. Combinar tokenizadores no tiene sentido. Incluso los identificadores “especiales” difieren entre las distintas familias de modelos.

P11. Problemas que surgen en producción

Es obligatorio utilizar el plantilla de chat de entrenamiento y el conjunto de tokens especiales correspondientes. Los espacios al inicio suelen considerarse tokens reales. Al contar caracteres para el cálculo de costos por parte de la API, las instrucciones se truncan silenciosamente. Los tokens centinela multimodales modifican la forma de empaquetar los datos. Las claves de caché deben incluir la versión del tokenizador. Un manejo incorrecto de los tokens BOS/EOS provoca que se violen las condiciones de detención y se alteren las auditorías de logprob.

P12. Compromisos en el tamaño del vocabulario

Un valor más grande de V acorta las secuencias y facilita el empaquetado multilingüe, pero aumenta los parámetros de embedding y LM-head, así como el cálculo softmax durante la decodificación. A partir de unos 100K–200K, generalmente se paga un costo adicional en memoria y ancho de banda por mejoras mínimas en la calidad, a menos que sea necesario para cubrir varios idiomas.

Parte 3 — Embeddings

P13. Embedding: gather vs matmul

La búsqueda por fila equivale a multiplicar un vector one-hot por E. Los métodos de tipo kernel realizan una recolección de datos; las operaciones matemáticas siguen siendo lineales.

P14. ¿Contextual o no?

Las filas de entrada son no contextuales. El contexto se construye mediante la atención entre capas. Los embeddings de recuperación suelen corresponder a estados más profundos, no a la fila de la tabla de entrada.

P15. Vinculación de pesos

Se comparten los pesos de los embeddings con la cabeza del LM (trasponiéndolos) para ahorrar parámetros, algo común en modelos más pequeños. Los LMs grandes suelen desvincularlos para mejorar la calidad. Las cabezas vinculadas no constituyen una matriz d × V independiente adicional.

P16. Información posicional

Los embeddings absolutos añaden vectores por índice. RoPE rota los valores de Q/K para que las desviaciones relativas aparezcan en las puntuaciones y colaboren con el caché KV. Los esquemas de sesgo relativo son alternativas; RoPE predomina en los nuevos LLMs.

P17. RoPE y extensión para contextos largos

La geometría relativa de RoPE permite una extrapolación mejor que las tablas absolutas simples. Las extensiones (interpolación de posición, escalado consciente de NTK, YaRN, etc.) reescalan las frecuencias rotativas para que los contextos más largos permanezcan estables sin necesidad de entrenamiento desde cero.

P18. El factor √d_model

Cuando se suman los vectores de token y posición, las escalas pueden entrar en conflicto; multiplicar las embeddings por √d_model los equilibra. Los stacks basados en rotación de RoPE a menudo omiten esa multiplicación.

Parte 4 — El bloque del transformador

P19–P23. Mecánicas de atención (ampliadas)

x → MultiHeadSelfAttention → Add & Norm → FFN → Add & Norm → out

Attention(Q, K, V) = softmax(QKᵀ / √d_k) V

Las consultas buscan, las claves anuncian y los valores entregan. El softmax sobre puntos escalados genera pesos de mezcla. Se divide por √d_k para que las puntuaciones no se saturen a medida que aumenta el ancho. Muchas cabezas diversifican los subespacios. Las máscaras causales escriben −∞ en futuros prohibidos para que la masa del softmax sea exactamente cero; sin embargo, los ceros en la máscara aún podrían filtrarse. Durante la decodificación pura con caché, el conjunto de claves no contiene posiciones futuras, por lo que la máscara es implícita; aun así, el relleno previo necesita máscaras (o un kernel causal).

Q24–Q26. Formas, costo y residuos

Cada proyección tiene un tamaño de ~d × d (modificado bajo GQA). Las FFN dominan los parámetros con una expansión de ~4×. El costo de la atención escala como O(n² d); las FFN, como O(n d²). Prompts cortos: límite impuesto por el peso/FFN. Contextos largos: la atención y la memoria KV son los elementos dominantes. Los residuos permiten que las pilas profundas sigan siendo entrenables al proporcionar vías de gradiente y refinamientos aditivos.

Q27–Q30. Normas, ancho de las FFN, activaciones, MoE

RMSNorm omite el centrado en media y es más económica que LayerNorm. Pre-norm estabiliza redes muy profundas frente a la clásica post-norm. Las FFN de ancho amplio (~4×) aumentan la capacidad por token entre los mezcladores de atención. Las no linealidades evitan que las capas lineales apiladas colapsen; SwiGLU ganó en muchas pruebas de ablatión de LLM. MoE dirige los tokens a unas pocas FFN especializadas, lo que hace que los parámetros escalen más rápido que las FLOPs por token: alto consumo de memoria, bajo uso computacional.

Q31–Q32. Profundidad/ancho y variantes de atención

La profundidad repite la mezcla; la anchura enriquece las características. Los laboratorios eligen según los límites de datos y clústeres. MHA almacena K/V por elemento; MQA comparte un único K/V entre consultas; GQA comparte por grupo; MLA comprime aún más los KV. El costo de servicio impulsó a la industria a seguir esa secuencia.

Parte 5 — El caché KV

Q33. ¿Qué es el caché KV, y por qué solo K y V?

En el paso de decodificación t llega un único token nuevo. Su consulta q_t debe consultar las claves y valores de las posiciones 1..t. Las claves y valores de 1..t−1 dependen únicamente de tokens anteriores y pesos congelados. La causalidad garantiza que la introducción del token t no puede reescribir esos tensores K/V anteriores, ya que son inmutables; por eso se calculan una vez y se almacenan.

Las consultas difieren: solo se necesita q_t para el paso actual. Las consultas anteriores ya generaron resultados antiguos y nunca serán leídas nuevamente, por lo que almacenar en caché el valor de Q es un desperdicio de memoria.

Sin caché, emitir el token t haría que se volviera a ejecutar todo el prefijo, una operación cuya complejidad aumenta drásticamente con la longitud. Con el caché, la atención en cada paso es proporcional linealmente a la longitud actual y el FFN requiere efectivamente un trabajo constante por cada nuevo token. La generación se vuelve proporcional linealmente al número de pasos de decodificación en lugar de ser cuadrática según el número de iteraciones.

Q34. Derivar el tamaño del caché KV con un número real

KV bytes = 2 (K and V)
         × n_layers
         × n_kv_heads × d_head
         × seq_len
         × batch_size
         × bytes_per_element

Se utiliza una estructura GQA del tipo Llama-3–70B: ochenta capas, ocho cabezales de clave/valor, ciento veintiocho dimensiones por cada cabeza, almacenadas en flotantes de dos bytes.

Multiplique esos factores: dos tensores (K y V) × ochenta × ocho × veintiocho entre cien × dos bytes da como resultado cerca de 320 KB por cada token de cada secuencia en tiempo real.

Si lo extiende a un diálogo de 8k tokens, se necesitarán alrededor de 2.6 GB por usuario. Al aumentar el contexto a 128k, la misma fórmula indica decenas de GB; cantidad suficiente para que una sola conversación ocupe una gran parte de un dispositivo de clase H100 antes incluso de contar los pesos.

Situación hipotética sin GQA (64 cabezas KV): la cifra de 8K sube a aproximadamente ~21 GB por secuencia. GQA marca la diferencia entre decenas de usuarios concurrentes y solo unos pocos.

Los pesos son un impuesto fijo que se paga una sola vez. La caché KV es un impuesto por usuario, por token y sin límite. Establece el tamaño máximo del lote, lo que a su vez determina el rendimiento y, por ende, los costos en dólares por millón de tokens. Por eso los diagramas lo señalan como el cuello de botella principal en la memoria.

P35. ¿Por qué la decodificación está limitada por la memoria? — La aritmética

Considere un modelo de 70B en formato fp16 que genera un solo token por lote:

• Bytes transferidos: ~140 GB de pesos más unos pocos GB de KV ≈ 142 GB.
• FLOPs: ≈ 2 × 70e9 × 1 = 140 GFLOPs.
• Intensidad: ≈ 1 FLOP/byte.

Una tarjeta H100 ofrece una velocidad de transferencia en HBM de alrededor de 3.35 TB/s y unos 1000 TFLOPs en formato fp16. El punto en el que el cálculo supera la capacidad de ancho de banda se alcanza a cientos de FLOPs/byte. Con 1 FLOP/byte se utiliza solo una fracción mínima de las unidades matemáticas disponibles; la GPU funciona principalmente como un transportador de datos entre memoria.

El tiempo de procesamiento ≈ 142 GB / 3.35 TB/s ≈ 42 ms → ~24 tok/s solo con el ancho de banda. Los sistemas reales se sitúan dentro de un factor de dos con respecto a esa estimación, lo que demuestra cuán decisivo es el ancho de banda en la decodificación.

Corolario: aumentar el tamaño del lote es prácticamente gratuito para el tráfico de pesos hasta que se llega a un límite por cálculo. Pasar de un lote de 1 a 32 permite reutilizar una carga de pesos en 32 secuencias, lo que puede multiplicar el rendimiento en tokens. Esa amortización es el hecho económico central en la prestación de modelos LLM.

P36. Si el agrupamiento en lotes es “gratuito”, ¿por qué no hacer lotes de 512?

Porque cada secuencia requiere su propio espacio de almacenamiento KV, y la memoria caché escala con batch × seq_len:

GPU memory = model weights + KV cache + activations + fragmentation overhead

Ejemplo: 140 GB de pesos en 2×H100 (160 GB) dejan ~20 GB para la caché. A 320 KB/token, eso equivale a ~65K tokens en total para todo el lote. Dieciséis usuarios con un contexto de 4K ya saturan ese presupuesto.

Por lo tanto, el límite de tamaño de KV limita el tamaño del lote, lo que a su vez limita el rendimiento. La GQA, la MLA, la cuantización de caché, la paginación y las políticas de expulsión son características de rendimiento que actúan como si fueran memoria.

P37. PagedAttention y el problema de la fragmentación

Los servidores ingenuos reservan un bloque contiguo de KV por solicitud hasta max_seq_len. Esto falla de dos maneras:

• Fragmentación interna — una completación de 100 tokens que reserva 4096 espacios desperdicia la mayor parte de la asignación.
• Fragmentación externa — las regiones liberadas de tamaños mixtos dejan huecos en los que no se pueden colocar nuevos bloques.

El desperdicio reportado en los asignadores ingenuos suele situarse entre el 60–80% de la memoria KV.

PagedAttention (popularizado por vLLM) copia la idea de memoria virtual del sistema operativo: bloques de tamaño fijo (por ejemplo, 16 tokens), además de una tabla de bloques que relaciona las posiciones lógicas con los bloques físicos en cualquier lugar del conjunto de memoria. Los bloques se asignan a medida que aumenta la longitud de la generación.

Ventajas:

• La fragmentación disminuye → a menudo se pueden procesar 2–4× más secuencias concurrentes en las mismas GPUs.
• Compartición de prefijos / copia al escribir — muchas solicitudes con un mismo prompt del sistema comparten bloques físicos hasta que sus sufijos difieren; ideal para agentes, instrucciones RAG y ejemplos de pocos casos.
• Las haces de muestras paralelas comparten el prefijo común en lugar de clonarlo.

El costo es la indirección y un núcleo de atención que recopila información de bloques no contiguos.

Q38. Agrupamiento estático vs. continuo

Batching estático espera a llenar un lote, ejecuta todas las secuencias al mismo ritmo que la más larga y completa con tokens adicionales. Las solicitudes cortas esperan a las largas; las GPUs gastan ciclos en esos tokens adicionales.

Batching continuo (a nivel de iteración) reconstruye el lote en cada paso de decodificación: las secuencias terminadas se eliminan, entran nuevas y la GPU solo permanece ocupada con los tokens en proceso. La variabilidad de la latencia disminuye y el rendimiento aumenta drásticamente; esto es algo básico en los motores modernos (vLLM, TensorRT-LLM, etc.).

Q39. Prefill por bloques y desagregación de prefill/decodificación

Un prefill de miles de tokens puede monopolizar la GPU y retrasar la decodificación para los usuarios interactivos. Prefill por bloques divide los prompts largos en fragmentos intercalados con pasos de decodificación, lo que hace que el TTFT aumente ligeramente mientras el TPOT se mantiene más estable.

La desagregación va aún más allá: se ejecuta el prefill en grupos optimizados para cálculos y la decodificación en grupos optimizados para memoria, enviando los pares KV a través de la red. Añade complejidad en la orquestación, pero adapta cada fase al hardware que realmente utiliza al máximo.

P40. Reducción de KV más allá de GQA

Las estrategias incluyen:

• MQA / GQA / MLA — menos cabezales KV o cabezales comprimidos.
• Cachés cuantizados (de tipo INT8/FP8/NF4) — a menudo casi sin pérdida para K/V.
• Atención en ventanas / deslizante — se descartan muchos tokens cuando la tarea lo permite.
• Políticas de expulsión / streaming para contextos extremos.
• Reutilización entre capas: ideas de investigación que comparten proyecciones a lo largo de la profundidad.

Cada una de estas estrategias sacrifica algo de calidad o generalidad a cambio de grandes ventajas en el uso de memoria.

P41. Caché de prefijos: cuando cambia la arquitectura

Si muchas llamadas comparten un prefijo largo e inmutable (prompt del sistema, esquemas de herramientas, contexto persistente recuperado), almacenar en caché el par clave-valor de ese prefijo evita tener que calcularlo nuevamente. Las arquitecturas prefieren entonces prefijos estables y sufijos mutables: se coloca el texto del usuario, que es volátil, al final, manteniendo el tronco compartido idéntico a nivel de bytes para que las claves de caché coincidan. El texto de los productos y los compiladores de prompts pasan a formar parte del factor que afecta el rendimiento.

Q42. ¿Cuándo se vuelve inválido el caché de KV?

Cada vez que los tokens anteriores se editan, y no solo se añaden: al regenerar durante la conversación, al reescribir un prompt del sistema, al cambiar las definiciones de herramientas o al aplicar ediciones no causales. Los cachés de prefijos deben indexarse según la identidad exacta de los tokens (y la versión de la plantilla). Los parámetros de muestreo no invalidan los pares K/V; solo modifican la forma en que los logits se convierten en el siguiente ID. Sin embargo, cambiar el adaptador del modelo, el modelo preliminar o la escala RoPE durante la ejecución sí puede hacerlo inválido.

Parte 6 — Cabeza LM (lineal + softmax)

P43. Qué hace la cabeza LM y sus formas

El último bloque emite h ∈ ℝ^(seq_len × d_model). Después de una normalización final, una transformación lineal genera los logits del vocabulario:

logits = h @ W_lm      W_lm ∈ ℝ^(d_model × V)

Para d_model = 4096 y V = 128,000, W_lm contiene 524M parámetros y produce un vector de 128K de ancho para cada posición evaluada.

P44. ¿Hay logits para cada posición durante la decodificación?

No. El prefill puede evaluar muchas posiciones para el entrenamiento o ciertas APIs, pero la decodificación normal solo necesita el estado oculto de la última posición. Las posiciones anteriores ya han elegido sus tokens.

P45. Costo de la cabeza LM durante la decodificación

Cada paso multiplica un vector d por d × V; esto implica aproximadamente 2 × d × V operaciones de punto flotante y una lectura completa de una cabeza potencialmente no vinculada. Cuando V es grande, esto compite con una capa FFN y justifica el uso de softmax adaptativo, particionamiento paralelo del vocabulario y embeddings vinculados cuando es aceptable.

P46. Logits frente a probabilidades

Los logits son puntuaciones sin límite. El softmax las normaliza:

p_i = exp(z_i) / Σⱼ exp(z_j)

Recuerde la invariancia al desplazamiento: añadir una constante a todos los logits no cambia las probabilidades; esto constituye la base de implementaciones estables y del uso de la temperatura como método para reescalar las diferencias.

P47. Softmax numéricamente estable

La expresión ingenua exp(z_i) provoca desbordamiento en formato fp16 para logits moderados y puede hacer que toda una fila se reduzca a cero, generando 0/0. La solución consiste en restar primero el valor máximo de la fila:

p_i = exp(z_i − max(z)) / Σⱼ exp(z_j − max(z))

El término más grande se convierte en exp(0) = 1; los demás están en el intervalo (0, 1]. Los algoritmos en línea (como FlashAttention) combinan esto con operaciones matmul para evitar la creación de matrices de puntuación enormes.

Q48. Perplexidad

La perplexidad es exp(media de la probabilidad negativa logarítmica) sobre los tokens: mide cuán “sorprendido” está el modelo. Se calcula desde la misma etapa de logits/softmax. Una menor perplexidad en un dominio indica una mejor calibración para el siguiente token, pero no es una medida directa de utilidad o seguridad.

Parte 7 — Estrategias de muestreo

Después de la cabeza del modelo de lenguaje se obtiene un vector de logits. El muestreo es el proceso mediante el cual ese vector se convierte en el siguiente ID.

Q49. Decodificación codiciosa: por qué decepciona

El algoritmo codicioso siempre elige argmax. Es determinista y económico, pero a menudo resulta insípido o terco a nivel local: los tokens de alta probabilidad en las etapas iniciales pueden atrapar a la secuencia en bucles repetitivos de alta probabilidad que un humano considera peores que alternativas con probabilidades ligeramente menores. Úsalo para tareas de extracción delicadas; evítalo como opción predeterminada para textos en prosa abierta.

Q50. ¿Por qué no buscar con haz?

El método de búsqueda por haz mantiene las B hipótesis parciales más destacadas. Es útil cuando el objetivo es breve y está restringido (como en la traducción). En chats abiertos tiende a generar texto genérico y seguro, con alta probabilidad, requiere B× cálculos y funciona mal con la diversidad de tipo nucleus. La mayoría de las aplicaciones basadas en LLM lo han descartado en favor del muestreo.

Q51. Top-k

Solo conservar los k logits más grandes, renormalizar y muestrear. Es simple, pero k es demasiado rígido: a veces la masa de probabilidad fuera del top-k sigue siendo importante; otras veces el top-k incluye valores irrelevantes cuando la distribución es muy puntiaguda. Un k fijo no puede adaptarse a este grado de puntiagudez.

Q52. Top-p (núcleo)

Ordenar por probabilidad, conservar el conjunto más pequeño cuya masa acumulada sea ≥ p y luego muestrear. Cuando el modelo está seguro, el núcleo se reduce; cuando duda, se amplía. Esa capacidad de adaptación es la razón por la cual top-p ha reemplazado al top-k fijo como opción predeterminada en muchos sistemas. Un valor típico de p está entre 0,9 y 0,95, ajustándose según el producto.

Q53. Temperatura: matemáticas e intuición

p_i = exp(z_i / T) / Σⱼ exp(z_j / T)

Dividir los logits entre T antes de aplicar softmax.

• T → 0 — las diferencias entre valores se amplían enormemente; la distribución se reduce al valor de argmax (enfoque agresivo).
• T = 1 — distribución del modelo sin escalar.

T > 1 — aplanar; más sorpresa y riesgo de incoherencia.

En la implementación, la temperatura por sí sola no “añade aleatoriedad”; más bien remodela la distribución de la que extrae el muestreador.

Q54. Orden: temperatura vs. truncamiento

Aplique la temperatura a los logits primero, y luego use top-k / top-p sobre la distribución resultante (o, de forma equivalente, trunque las probabilidades temperadas). Truncar antes de aplicar la temperatura cambia qué colas existen y suele ser una combinación incorrecta. Documente el orden que utiliza su servidor; los cambios silenciosos alteran el comportamiento.

Q55. Penalizaciones por repetición, frecuencia y presencia

• Repetición / frecuencia — disminuir la importancia de los tokens ya vistos, a menudo escalados según su conteo.
• Presencia — penalizar a un token una sola vez si ha aparecido al menos una vez, independientemente de su conteo.

Ellos luchan contra los bucles en la decodificación creativa, pero pueden perjudicar la repetición intencionada (código, poesía, frases legales). Prefieren sanciones leves y reglas estrictas de detención en lugar de medidas agresivas que obstaculicen el proceso.

P56. Más allá de top-p

Umbral min-p en relación con la probabilidad más alta (p_i ≥ min_p × p_max), que funciona mejor cuando la temperatura es alta y la distribución de probabilidades es difusa. Mirostat y otros controladores buscan un nivel de sorpresa determinado. La producción típica sigue centrada en la temperatura + top-p, aunque min-p va ganando importancia.

P57. La temperatura 0 sigue variando: ¿por qué?

Incluso las estructuras “codiciosas” difieren en:

• Reducciones no determinísticas en la GPU y núcleos fusionados.
• Diferentes esquemas de agrupamiento o lotes continuos.
• Rutas especulativas e implementaciones numéricamente distintas de softmax.
• Sanciones predeterminadas, cadenas de detención y plantillas del lado del servidor.

Ruido de enrutamiento MoE si está habilitado.

El método codicioso y estable en bits requiere kernels bloqueados, un tamaño de lote de 1 y revisiones de software idénticas; algo raro en flotas multiinquilinos.

P58. Forzar el uso de JSON o un esquema

Las opciones son las siguientes:

1. Forzar explícitamente el uso de JSON (frágil).
2. Decodificación restringida / máscaras gramaticales — eliminar tokens ilegales en cada paso (regex, esquema JSON, CFG).
3. Uso de herramientas o funciones que llamen a APIs que analicen canales laterales en lugar de texto libre.
4. Reparación posterior (último recurso).

La decodificación restringida es la solución fiable para sistemas donde la validez es obligatoria.

P59. Evaluación de los parámetros de muestreo

Mantenga el modelo fijo y pruebe los valores de temperatura/top-p en un conjunto etiquetado: éxito de la tarea, toxicidad, diversidad (distinct-n), tasa de repetición y latencia. Prefiera la evaluación offline junto con pruebas A/B en línea que muestren métricas claras del producto. No ajuste los parámetros basándose únicamente en un prompt seleccionado de forma selectiva.

Parte 8 — Decodificación especulativa

P60. Idea central

Un modelo borrador económico propone varios tokens futuros; el modelo objetivo los verifica en una operación paralela sobre todo el rango del borrador. El prefijo aceptado se convierte en la salida; ante el primer rechazo, se selecciona un sustituto de la distribución del modelo objetivo y se descartan los demás. Se utiliza la mayor parte de la capacidad del modelo objetivo en la verificación paralela en lugar de en pasos secuenciales de un solo token.

P61. Por qué la distribución de salida no cambia

La aceptación utiliza relaciones entre el p objetivo y el q preliminar de modo que los tokens aceptados más el muestreo residual reconstruyan exactamente a p:

P(emit x) = q(x)·min(1, p(x)/q(x)) + P(reject)·p'(x)

La ruta aceptada aporta min(q,p); el muestreo residual completa max(0, p−q). La suma da como resultado p. Por lo tanto, la decodificación especulativa es sin pérdidas en comparación con el muestreo objetivo habitual: representa una aceleración del sistema, no una aproximación del modelo.

Q62. Aceleración esperada

Con una tasa de aceptación α y una longitud preliminar k, los tokens esperados por paso hacia adelante objetivo son:

E[tokens] = (1 − α^(k+1)) / (1 − α)

Incluso si cada token preliminar falla, aún se obtiene un token durante la fase de verificación del objetivo. Con un costo preliminar c en relación con un paso objetivo:

speedup ≈ E[tokens] / (1 + k·c)

Ejemplo: α=0.8, k=4 → expectativa de ~3.36 tokens; con c=0.05 → ~2.8×. Las victorias publicadas suelen situarse en el rango de 2–3×. Un valor alto de k genera beneficios decrecientes, ya que la probabilidad de supervivencia disminuye según α^k.

Q63. Cuando la especulación perjudica

Baja aceptación (preguntas complejas, cambio de dominio, borradores débiles), costos excesivos en los borradores, o kernels que no pueden verificar de forma eficiente en paralelo. En estos casos los costos superan los beneficios; se debe aplicar un umbral basado en el valor medido de α.

Q64. Almacenamiento en caché KV en caso de rechazo

Se guardan las entradas de caché del objetivo de reversión (y del borrador) para las posiciones rechazadas. Las implementaciones limitan la longitud de los puntos de control y truncan el contenido; los errores en este proceso dañan la atención futura. Los tokens aceptados mantienen sus valores K/V.

Q65. Variantes modernas

Medusa / borradores de múltiples cabezales, generadores a nivel de características al estilo águila, borradores mediante búsqueda de prompts / n-gramas a partir del propio contexto, y generadores en cascada. Mismo principio de verificación con objetivo.

P66. Atención en árbol

Los borradores pueden proponer un árbol de candidatos, no solo una cadena lineal. La atención en árbol verifica múltiples ramas en una sola pasada hacia el objetivo, aumentando el número esperado de aceptaciones por llamada cuando la ramificación es económica.

Parte 9 — Destokenizador y streaming

P67. La destokenización no es un mero mapa inverso

Los destokenizadores deben eliminar los marcadores de espacio, manejar soluciones alternativas en bytes, componer grafemas de múltiples tokens y evitar emitir UTF-8 incompleto. La destokenización por streaming almacena en búfer hasta que un carácter/pieza completo esté listo para ser descargado; de lo contrario, los clientes verán caracteres de reemplazo.

P68. Cómo funciona el streaming y qué medir

Los servidores emiten tokens (o cadenas parciales) a medida que se generan. Mida TTFT, TPOT y el tiempo hasta el primer carácter legible después del procesamiento de destokenización. La experiencia de usuario del cliente da más importancia a ese último valor que a las marcas de tiempo brutas de los tokens.

P69. Las secuencias de detención son complicadas

Las señales de detención pueden extenderse más allá de los límites entre tokens (\n\n frente a un único token que contiene ambas saltos de línea). Es necesario verificar el texto descodificado (o una ventana de tokens cuidadosamente seleccionada), y no solo la igualdad de los IDs individuales. Cuando hay solapamiento con señales de detención parcialmente generadas, se debe revertir el proceso para que el texto de la señal no se muestre.

P70. ¿Qué pone fin a la generación?

EOS / IDs especiales de detención, cadenas de detención coincidentes, límites máximos de tokens, cancelación por parte del cliente o el mecanismo de vigilancia del servidor. Es preferible un manejo explícito de EOS que sea coherente con el modelo de chat.

Parte 10 — FlashAttention, cuantización, roofline

P71. FlashAttention: afirmaciones precisas

FlashAttention calcula la atención sin materializar toda la matriz de puntuaciones n × n en HBM, utilizando técnicas de mosaico y estadísticas de softmax en tiempo real. Esto reduce el tráfico de memoria y permite secuencias más largas o lotes más grandes. No modifica el resultado matemático de la atención (salvo por consideraciones numéricas); se trata de un algoritmo consciente del uso de E/S, no de un modelo diferente.

P72. ¿Ayuda en la decodificación?

La decodificación con caché suele utilizar longitudes de q de 1 para acceder a las claves n almacenadas en caché; la ventaja típica de FlashAttention (grandes puntuaciones cuadradas) es menor en este caso. Las variantes (FlashDecoding, etc.) siguen ayudando a optimizar las rutas de ancho de banda para los datos KV, pero la decodificación sigue estando dominada por la carga de pesos a menos que el lote sea grande.

P73. Cuantización

Almacene o compute los pesos (y a veces las activaciones/KV) en formatos más compactos (FP8, INT8, INT4, …). La memoria y el ancho de banda disminuyen aproximadamente con la anchura en bits; la pérdida de calidad depende del método utilizado (GPTQ, AWQ, cuantización suave, …). Una regla práctica según las notas de experiencia: el formato de 8 bits suele ser casi gratuito; el de 4 bits implica un costo menor, a veces dentro del ruido propio de las pruebas —siempre realice mediciones en sus tareas específicas.

P74. Límite teórico en un párrafo

Gráfique los FLOPs alcanzables en función de la intensidad aritmética. El proceso de prellenado se sitúa cerca del límite de cálculo; la decodificación en lotes de 1 se encuentra cerca del límite de ancho de banda, alrededor de 1 FLOP por byte. Las optimizaciones que aumentan la intensidad (como el uso de lotes o menos bits transferidos por cada FLOP útil) acercan el rendimiento al límite teórico; las mejoras puramente relacionadas con la velocidad del núcleo no pueden superar ese límite.

P75. Dividir un modelo grande entre GPUs

Paralelismo de tensores: divide los datos en fragmentos dentro de las capas (requiere una interconexión rápida). Paralelismo por pipeline: asigna rangos de capas a los diferentes nodos (riesgo de problemas de sincronización). Paralelismo experto: divide a los expertos de MoE en fragmentos. Paralelismo por réplicas/datos: copia el modelo para mejorar el rendimiento. Las implementaciones reales combinan estos enfoques; los datos KV deben particionarse o replicarse de manera consistente con la estructura de atención.

Parte 11 — Números del whiteboard

• Pesos de 70B en fp16: 70e9 × 2 ≈ 140 GB.
• FLOPs en el proceso de predicción: ~2 × parámetros × tokens (orden de magnitud).
• KV por token (Llama-3-70B-class GQA): ~dos · capas · kv_heads · head_dim · dtype_bytes, aproximadamente un tercio de megabyte por token.

Tok/s de decodificación en lote-1: ~ancho_de_banda / weight_bytes (clase H100: decenas de tok/s en formato fp16 antes que otros métodos).

Embedding + cabeza de LM sin vinculación a V=128K, d=4096: ~524M de parámetros cada uno.

Parámetros de atención vs FFN: aproximadamente 1:2 en un bloque estándar (4d² vs ~8d²).

Parte 12 — Advertencias sobre los diagramas

Los diagramas didácticos comunes omiten: plantillas de chat antes de la tokenización, el efecto de GQA/MQA en el ancho de KV, detalles sobre el orden de muestreo, el almacenamiento temporal para la destokenización, KV paginado y bucles de verificación especulativa. Considere los diagramas como mapas, no como contratos.

Cierre

La inferencia es un proceso que va de los bytes al texto en flujo, donde el prefill está limitado por el procesamiento y la decodificación por el ancho de banda; la cache KV domina la memoria en entornos multiusuario, y cada optimización importante —GQA, paginación, agrupamiento continuo, cuantización, FlashAttention, especulación— existe para trasladar el trabajo hacia los puntos óptimos del hardware sin modificar el modelo matemático más de lo necesario.

Análisis en profundidad A: Comparación práctica entre los costos de prefill y decodificación

Cuando se dimensiona una flota de GPUs, hay que partir del reparto de recursos según la línea del techo. Las tareas con datos prellenados prefieren los núcleos tensoriales: prompts largos en funciones de asistencia con código o volcados RAG pueden mostrar un uso eficiente de los recursos si los kernels son competentes. Las tareas de decodificación en el lote 1 parecen pruebas de memoria accidentales: los mismos pesos de 70 mil millones se procesan rápidamente a través del HBM para una sola operación GEMV. Por eso, un producto que genera respuestas de 500 tokens parece lento incluso en las GPUs más potentes, a menos que se utilicen lotes, se realice cuantización o se adopten estrategias especulativas.

Las regresiones en TTFT suelen deberse a que los prompts se han vuelto más largos (con historial, datos RAG o esquemas de herramientas) sin caché de prefijos. Las regresiones en TPOT suelen indicar que el procesamiento por lotes ha fallado, la ancho de banda disminuido o que la presión en las estructuras KV ha forzado el uso de lotes muy pequeños. La latencia de extremo a extremo no depende de un único parámetro: acortar las respuestas ayuda a reducir los tiempos en TPOT; el caché de prompts del sistema ayuda en TTFT; la decodificación especulativa mejora los tiempos en TPOT cuando la probabilidad de aceptación es alta.

Las métricas de rendimiento publicadas en los paneles de control son fáciles de manipular con lotes enormes que causan problemas a los usuarios interactivos. Es necesario publicar tanto los tokens por segundo por GPU como los valores p50/p95 de TPOT en una combinación realista. El procesamiento continuo en lotes mantiene la GPU ocupada sin la carga adicional de los lotes estáticos; el prellenado por bloques evita que una sola solicitud de 32K congele el proceso de decodificación del resto.

El prellenado/decodificación separados representa el reconocimiento arquitectónico de que estas dos tareas requieren máquinas diferentes. Los nodos de prellenado pueden contar con un procesamiento más intensivo, mientras que los nodos de decodificación necesitan capacidad de memoria y ancho de banda para manejar datos KV. La red debe transferir estos datos de forma eficiente, de lo contrario se pierde la ventaja. No todos los equipos deben implementar esto desde el primer día, pero todos deberían entender por qué existe este patrón.

Análisis en profundidad B: Tokenizador y costos multilingües

La universalidad de los BPE a nivel de byte es tanto un regalo como una carga. Las aplicaciones de chat en inglés subestiman el costo para textos en hindi, tailandés o con muchos emojis. Si su modelo de márgenes asume tokens en inglés por segundo, la expansión a múltiples idiomas puede agotar silenciosamente el presupuesto. Prefiera tokenizadores con una mayor cobertura multilingüe cuando ese tráfico sea importante; mida los tokens por clúster de grafemas en corpus reales, no en texto ficticio como lorem ipsum.

Los templates de chat forman parte de la identidad del modelo. Un solo token especial de finalización omitido puede causar generaciones excesivamente largas o textos incompletos. Almacene la versión del template junto con la revisión del modelo en su registro. Al depurar problemas como “el modelo ignora el prompt del sistema”, tokenice ambos lados y compare sus IDs antes de culpar a los pesos del modelo.

Las políticas de dígitos son importantes para los agentes de hojas de cálculo y los tutores de matemáticas. Si 1000 y 1,000 se procesan de manera diferente, los algoritmos de columnas se convierten en billetes de lotería. Al crear calculadoras basadas en LLMs, prefiera tokenizadores con reglas explícitas para los dígitos o dirija las operaciones aritméticas a herramientas especializadas.

Análisis profundo C: Atención, GQA y memoria

La historia de la atención multi-cabeza se trata de especialización dentro de un presupuesto limitado. La historia del GQA se refiere a los bytes KV. Pasar de la atención multi-cabeza al GQA puede reducir el tamaño del caché aproximadamente en la proporción entre los cabezas de consulta y los grupos KV, a menudo entre 4 y 8 veces, con una pérdida moderada de calidad al entrenarlo para ello. El MQA representa el extremo; el MLA y otras técnicas de compresión buscan resolver el mismo cuello de botella pero con métodos algebraicos diferentes.

El enmascaramiento causal con infinito negativo no es pedantería: cualquier valor de máscara finito genera fugas. Los errores en el entrenamiento que permiten accidentalmente la atención futura crean modelos que parecen sólidos en métricas impuestas por el entrenador pero fallan al utilizarse de forma autoregresiva real. Los kernels del momento de decodificación que asumen un diseño de caché deben coincidir con la geometría de entrenamiento (número de cabezas, base RoPE, escalamiento).

Los residuos y la pre-normalización son la razón por la cual las pilas de 80–100 capas son algo habitual. Cuando una arquitectura personalizada los elimina “para simplificar”, espere inestabilidad en el entrenamiento antes que cualquier ventaja. La funcionalidad de control de SwiGLU es un parámetro que afecta la calidad y tiene implicaciones en el uso de memoria; debe saber si su pila lo integra.

Análisis profundo D: paginación KV y estrategia de prefijo

PagedAttention reinterpreta los datos KV como un conjunto de bloques. Las consecuencias son:

• Los frameworks de agentes con grandes prompts del sistema compartidos deberían estandarizar ese prefijo para que los hashes de los bloques colisionen.

Las bibliotecas de pocos ejemplos deben mantener los ejemplares en un orden estable; reorganizarlos reduce las consultas al caché.

Los campos de personalización deben ir después del tronco compartido.

Las herramientas de depuración deben mostrar las tasas de éxito en la tabla de bloques de la misma manera que los CDN muestran las relaciones de consultas al caché.

La invalidación del caché con prefijo es un problema de corrección, no solo de rendimiento. Si el esquema de una herramienta cambia pero la clave del caché lo ignora, el modelo utilizará datos obsoletos para nuevas instrucciones: fallos sutiles pero problemáticos. Incluya en la clave el ID del tokenizador, el hash de la plantilla, el ID de LoRA y la escala de RoPE.

La expulsión de datos debido a presión de memoria requiere una política: LRU en conversaciones inactivas, límites estrictos para el contexto o compactación mediante resumen. Sea cual sea la opción elegida, hágala visible al producto; el truncamiento silencioso es un defecto que afecta la confianza.

Análisis profundo E: Softmax, muestreo y determinismo

El softmax estable es obligatorio en los caminos fp16/bf16. Los núcleos fusionados ocultan la operación max-subtract, pero el código de investigación personalizado sigue sufriendo desbordamientos. La perplejidad sigue siendo un indicador útil de regresión cuando se modifican los núcleos o los esquemas de cuantización: los picos indican que la distribución ha cambiado.

La composición de muestreo debe probarse con pruebas unitarias: primero la temperatura, luego el truncamiento, después las penalizaciones y finalmente el muestreo. Cambia el orden en un entorno de prueba y observa cómo las transcripciones de referencia divergen. La decodificación restringida para JSON debe probarse bajo carga; la generación de máscaras puede volverse un cuello de botella para el CPU si se implementa de forma ingenua.

Afirmar que una temperatura cero equivale a un resultado determinista es una frase de marketing, no una garantía matemática en GPUs reales. Si necesitas un registro de calidad auditiva, graba los IDs muestreados (o las semillas del generador aleatorio junto con los núcleos bloqueados del lote 1). Para la mayoría de las aplicaciones, basta con la reproducibilidad dentro de una misma versión; documenta eso.

Análisis profundo F: Operaciones de decodificación especulativa

La especulación sin pérdidas es poderosa porque los propietarios de productos temen la degradación de calidad. Aun así, las operaciones deben hacer un seguimiento de la tasa de aceptación por clase de prompt. La completación automática de código suele funcionar bien; sin embargo, los chats creativos abiertos pueden no hacerlo. Un ajuste dinámico de la longitud del borrador basado en las aceptaciones recientes es mejor que una suposición estática.

La especulación basada en árboles es útil cuando el borrador puede proponer alternativas de forma económica. Las pruebas de corrección de reversión KV deben realizarse en CI: rechazar intencionadamente las operaciones durante la ejecución y asegurarse de que las atenciones posteriores coincidan con un valor de referencia no especulativo.

Los modelos de borrador deben compartir el tokenizador (o una asignación compatible) con el modelo objetivo. Los tokenizadores incompatibles generan datos inválidos que parecen indicar que la especulación ha vuelto al modelo más lento.

Análisis profundo G: Experiencia de usuario en streaming y puntos de detención

Los usuarios perciben la fluidez a partir de los caracteres destokenizados, no de los IDs en bruto. Almacena temporalmente hasta que el Unicode sea válido; descarga el contenido cuando haya espacios en blanco, siempre que sea posible, para mejorar la experiencia de usuario en las conversaciones. Las secuencias de terminación que superponen tokens requieren una corrección cuidadosa para que el cliente nunca vea ese texto de terminación. Los límites máximos de tokens deberían incluir una señal clara de continuación si el producto permite continuar.

Análisis profundo H: FlashAttention y cuantización en el servicio

FlashAttention permite utilizar prefill más extenso y lotes más densos al ahorrar memoria HBM. Agradece este beneficio sin afirmar que modifica las reglas de decodificación. La cuantización es la herramienta clave para la decodificación: menos bytes por carga de pesos aumentan el número efectivo de tokens por segundo. Valida esto en tu conjunto de pruebas, especialmente en las llamadas a herramientas y en la recuperación de contextos largos, antes de declarar que el formato de 4 bits es gratuito.

El razonamiento basado en la estructura del techo mantiene los argumentos honestos: si estás limitado por el ancho de banda, comprar más TFLOPS sin más ancho de banda (o menos bytes) resulta decepcionante. Si estás limitado por el poder de cálculo en la fase de prellenado, una mejor implementación de GEMM y un planificación más eficiente de los bloques son más importantes que reducir el tamaño de KV.

Análisis en profundidad I — Realidades de las múltiples GPUs

La paralelización con tensores requiere una interconexión rápida, de lo contrario se detiene en las operaciones de reducción total. La paralelización por tuberías necesita microlotes para ocultar retrasos. Combinarlas con lotes continuos y KV paginado es la razón por la cual los motores de inferencia tienen bases de código tan grandes. Cuando alguien propone simplemente dividir el modelo, pregunta en qué dimensión y qué sucede con la estructura de KV.

Análisis en profundidad J — Armando el pipeline

Un camino de solicitud que vale la pena memorizar:

1. Plantilla más tokenización en la CPU
2. Incrustación y prellenado con atención causal, escritura de KV (GPU, limitado por el poder de cálculo)

Cabeza LM en la última posición y luego muestreo (GPU con política de CPU)

Bucle de decodificación con caché, agrupamiento continuo, especulación opcional (GPU, limitado por ancho de banda)

Destokenización, verificaciones de fin, procesamiento en CPU

Liberar o reutilizar bloques KV en el asignador

Cada optimización corresponde a una flecha en esa lista. Si no puedes señalarla, aún no estás razonando sobre la inferencia; solo estás recopilando frases hechas.

Aclaraciones adicionales al estilo de Preguntas Frecuentes

¿Aumentar la temperatura incrementa la creatividad de manera medible? Aumenta la entropía de la distribución del siguiente token. Que los humanos consideren el resultado creativo depende de la tarea; mide con métricas de diversidad y calidad, no solo con sensaciones subjetivas.

¿Es correcto ser codicioso alguna vez? Sí: la clasificación como generación, la extracción estructurada con decodificación restringida y algunos herramientas de evaluación. El diálogo abierto generalmente no es así.

¿Se puede eliminar la caché KV y volver a calcular? Siempre, pero con un costo cuadrático. Los dispositivos periféricos a veces funcionan con ventanas cortas sin caché; los servidores casi nunca deberían hacerlo.

¿Por qué los diagramas muestran softmax dentro de la atención y nuevamente en la cabeza del LM? Softmax diferentes: uno mezcla valores dentro de una capa; otro convierte los logits del vocabulario en una distribución categórica para muestreo. Misma familia de funciones, tareas diferentes.

¿Qué debería memorizar primero un nuevo ingeniero? Los cuellos de botella entre el prefill y la decodificación, la fórmula de bytes KV por token, TTFT frente a TPOT, y que el agrupamiento intercambia latencia por ancho de banda. Todo lo demás depende de estas cuatro ideas.

Guía ampliada: núcleos de prefill y mecanismos de TTFT

La calidad del prefill de servicio se refiere principalmente a la rapidez con la que se puede convertir una solicitud en un caché KV eficiente. Los núcleos de atención, las rutas MLP fusionadas y la forma en que se divide la solicitud determinan la forma de la curva TTFT. Cuando las solicitudes comparten un tronco largo, el caché de prefijo convierte el costo repetido del prefill en una búsqueda rápida; cuando no comparten ese tronco, cada nueva sesión debe pagar el precio completo.

El prefill dividido en fragmentos funciona tanto como herramienta de equidad como de reducción de latencia. Sin él, la inserción de 40 mil tokens puede bloquear el proceso de decodificación para todos los demás en la GPU. Con él, las transmisiones interactivas continúan funcionando mientras el trabajo largo avanza en fragmentos. El trade-off es un valor TTFT ligeramente más alto para el trabajo largo en sí, lo cual suele ser aceptable.

La ubicación del prefijo es una decisión relacionada con el producto. Coloca el texto volátil del usuario después del núcleo fijo para que las claves de caché permanezcan estables. Si el departamento de marketing reescribe el mensaje del sistema diariamente, considéralo un evento que rompe el caché y espere que TTFT aumente hasta que el nuevo núcleo vuelva a estar en uso.

Guía detallada: Explicar matemáticamente el ancho de banda

Imagínese leer todo el conjunto de pesos de HBM una vez por token generado, con un tamaño de lote de uno. La intensidad aritmética disminuye hasta quedar en un único proceso útil de multiplicación-acumulación por byte transferido. El hardware que es eficaz en operaciones GEMM densas parece inactivo porque espera a los controladores de memoria. El uso de lotes permite reutilizar cada carga de pesos en múltiples secuencias; la cuantización reduce la carga en sí; la verificación especulativa convierte varios pasos secuenciales en una sola comprobación paralela. Esas son diferentes formas de alcanzar el mismo objetivo.

Cuando alguien afirma que un kernel es “2× más rápido” en la decodificación, pregúntale bajo qué condiciones se realizó la prueba. Si el rendimiento está limitado por el ancho de banda, una optimización puramente en la ALU no puede lograr un aumento de 2×. Si además redujeron la cantidad de bytes transferidos, créales después de ver una captura de pantalla del perfilador.

Guía ampliada: políticas de servicio y SLOs

Escriba los SLOs por separado para TTFT y TPOT. Una versión que mejora el rendimiento mientras el p95 de TPOT se duplica representa una regresión en la experiencia de usuario del chat, incluso si el panel de control de capacidad lo celebra. Los parámetros de procesamiento en lotes continuos (número máximo de tokens por lote, cola de espera máxima, prioridad entre decodificación y carga previa de datos) son los ajustes prácticos que sustentan esos SLOs.

El control de admisión debe gestionarse junto con la contabilidad KV: rechace o coloque en cola nuevas sesiones cuando la memoria de caché proyectada supere un umbral establecido. De lo contrario, los cierres por falta de memoria parecerán fallos aleatorios del modelo para los clientes.

Guía ampliada: lista de verificación de operaciones del tokenizador

Antes de promocionar un modelo:

1. Congele los archivos del tokenizador y el texto de las plantillas de chat en el mismo almacén de artefactos que los pesos.
2. Ejecute pruebas de control con un número reducido de cadenas multilingües y emojis para detectar sorpresas en la longitud de los tokens.
3. Ejecute pruebas de control con cadenas ricas en dígitos si el producto realiza cálculos matemáticos.
4. Confirme que los IDs de los tokens de parada coincidan con los marcadores de finalización de la plantilla.
5. Confirme que las herramientas de logprob utilicen el mismo tokenizador que se emplea en la inferencia.

Si omite alguno de estos pasos, intentará solucionar problemas de “calidad del modelo” que en realidad son desviaciones en el empaquetado.

Guía detallada: variantes de atención como línea de tiempo

Los primeros modelos de lenguaje utilizaban MHA completo y lo pagaban mediante caché. La presión por la producción dio origen a MQA, y luego a GQA como solución de compromiso adoptada por la mayoría de los puntos de control avanzados. Las ideas relacionadas con MLA y KV de rango bajo continúan la misma dinámica: mantener la riqueza de las consultas mientras se reduce lo que se almacena por token anterior. Al leer un artículo, traduzca las afirmaciones a “bytes por token de KV” y “delta de calidad en nuestra evaluación”; el lenguaje de marketing sobre “atención eficiente” carece de sentido en otros contextos.

Revisión detallada: KV paginado y comportamiento multiinquilino

La matemática de la fragmentación es extremadamente compleja con reservas contiguas. La paginación convierte esto en un problema de asignador con bloques fijos. Los clústeres multiinquilino deben registrar los fallos de asignación, recuperar latencia de las tablas de bloques y monitorear la tasa de aciertos con prefijo. Una caída repentina en la tasa de aciertos suele indicar un cambio en el espacio en blanco del template o un aumento silencioso en el tokenizador.

El compartición por copia al escribir entre haces y muestras paralelas no es opcional para la decodificación similar a una búsqueda; sin ella se multiplica la memoria por el ancho del haz de forma innecesaria.

Guía ampliada: Muestreo para productos

Valores predeterminados de envío que coinciden con el trabajo:

• Parámetros de extracción/herramienta: temperatura baja, decodificación restringida, método codicioso o núcleo pequeño.
• Chat de soporte: temperatura moderada, núcleo alrededor de la banda común 0.9, penalización leve por repetición si aparecen bucles.
• Brainstorming creativo: temperatura más alta, consideración de min-p, advertencias más visibles para el usuario sobre la variabilidad.

Registre la tupla de muestreo con cada respuesta para los tickets de soporte. “El modelo dijo X ayer” es imposible de responder sin ella.

Guía ampliada: Implementación gradual de la decodificación especulativa

Lanzar detrás de una bandera. Medir la aceptación por punto final. Deshabilitar cuando α caiga por debajo del punto de equilibrio derivado de su costo preliminar c y longitud preliminar k. Mantener siempre una porción de tráfico canario no especulativa: es su referencia real de calidad.

Asegurarse de que las rutas de rechazo eliminen los valores KV. Agregar una prueba de caos que fuerce rechazos a mitad de secuencia bajo carga.

Guía ampliada: detalles del protocolo de streaming

Decidir si el formato de transmisión envía tokens, cadenas destokenizadas o ambos. Los clientes que realicen la re-tokenización de manera diferente no coincidirán en los límites. Preferir la destokenización del lado del servidor con eventos “flush” explícitos cuando esté listo un clúster de grafemas completo. Documentar cómo se eliminan las secuencias de detención para que el código de la interfaz no las maneje dos veces.

Guía ampliada: pruebas de aceptación de cuantización

Antes de habilitar pesos de 4 bits en producción:

• Ejecutar el conjunto estándar de pruebas eval.
• Ejecutar las pruebas de llamadas a herramientas.
• Ejecutar pruebas de contexto largo.
• Comparar las pruebas de rechazo y seguridad si es aplicable.
• Comparar el p95 TPOT con la VRAM.

Si la calidad está dentro del valor epsilon acordado y las ganancias en latencia son reales, proceder con el lanzamiento. De lo contrario, seguir utilizando 8 bits para ese modelo.

Guía detallada: respuestas a los ejercicios en formato prosa

La memoria necesaria para un punto de control con setenta mil millones de parámetros en formato fp16 asciende a aproximadamente ciento cuarenta gigabytes solo para los pesos. Una pasada forward requiere alrededor de dos FLOPs por parámetro y por token. El crecimiento de KV es lineal en función de los tokens activos y del número de cabezas clave/valor que realmente se almacenan. La velocidad de decodificación en lotes de uno está relacionada con el ancho de banda de memoria dividido por los bytes manipulados en cada paso. Las tablas de embeddings y las cabezas LM independientes pueden consumir cientos de millones de parámetros en vocabularios grandes; esto no se debe a errores de redondeo. Dentro de un bloque, la ruta feed-forward suele tener aproximadamente el doble de parámetros de proyección que la atención.

Guía ampliada: enseñando honestidad en los diagramas

Cuando dibuje el flujo de trabajo para principiantes, anote las partes omitidas: plantillas, paginación, loteo continuo, especulación y buffers de destokenización. De lo contrario, los ingenieros implementarán el diagrama y se sorprenderán con el rendimiento en producción.

Apéndice final: cómo se ve “terminado” para el propietario de la inferencia

Puedes explicar, sin diapositivas, por qué un incidente específico afectó negativamente a TTFT en comparación con TPOT. Puedes estimar la memoria KV para un objetivo de concurrencia y contexto propuesto. Puedes indicar qué mecanismo —batch, cuantización, GQA, especulación, caché de prefijos— es aplicable al síntoma. Tratas a los tokenizadores y plantillas como dependencias con versiones específicas. Esa es la alfabetización operativa necesaria para la inferencia de LLMs; todo lo demás son detalles que puedes consultar.

Narrativa del estudio de caso: un servicio interactivo de 70B

Supongamos que expones un modelo de chat de 70B en formato fp16 en un par de GPUs con alta capacidad de memoria. Solo los pesos ocupan alrededor de ciento cuarenta gigabytes, por lo que el par de GPUs está casi lleno antes incluso de que comience cualquier conversación. El espacio restante debe cubrir la memoria KV para todas las sesiones en curso, las activaciones y la fragmentación del asignador.

Estableció un objetivo para el producto: dieciséis usuarios concurrentes, contextos de cuatro mil tokens y respuestas en streaming. Según cálculos aproximados de tipo KV, con unos pocos cientos de kilobytes por token, dieciséis multiplicado por cuatro mil da decenas de gigabytes, lo cual es demasiado para la memoria restante. Inmediatamente surgen opciones: pasar a un punto de control GQA, cuantizar la caché, reducir la concurrencia, acortar el contexto o añadir GPUs. Esa simple conversación aritmética marca la diferencia entre una petición vaga como “necesitamos más GPUs” y un plan de capacidad preciso.

También se observan picos en TTFT al inicio de cada hora, cuando muchos clientes se reconectan con prompts del sistema idénticos. El caché de prefijos evita esos picos una vez que el stem se fija. Si no se fija el stem después de editar un prompt, en el panel de métricas parece una regresión del modelo.

Narrativa del estudio de caso: bucles de agente y claves de caché

Un agente envía el mismo esquema de herramienta en cada turno. Si el JSON del esquema se serializa con un orden de claves inestable, los hashes de prefijo fallan y se tienen que volver a llenar miles de tokens por paso. La codificación JSON canónica se convierte así en una optimización para las inferencias. De manera similar, insertar el perfil del usuario antes del esquema interrumpe el uso compartido entre usuarios; insertarlo después mantiene la estructura común de la herramienta.

Narrativa del estudio de caso: Decodificación especulativa en código versus chat

En un endpoint de completación de código, un modelo preliminar entrenado con datos similares acepta la mayoría de los tokens; la latencia de extremo a extremo disminuye aproximadamente en un 2×. En un endpoint creativo de tipo abierto, la tasa de aceptación cae drásticamente y el mismo modelo preliminar desperdicia capacidad. Los indicadores de funcionalidad por ruta son más eficaces que un interruptor global de especulación.

Narrativa del estudio de caso: Errores en secuencias de detención

Un equipo establece un punto de detención en un marco Markdown. La mitad de las veces el marco consta de un único token; la otra mitad está dividido. Los usuarios ven comillas invertidas al final. La solución verifica las ventanas de texto decodificado y anula el rango de detención. Los puntos de detención basados únicamente en ID de token fueron la causa raíz del error.

Narrativa del estudio de caso: la sorpresa de cuantización

Los pesos de cuatro bits mejoraron la tasa de tokens por segundo en aproximadamente un 40% en rutas de decodificación limitadas por la memoria. Las evaluaciones que involucraban llamadas a herramientas disminuyeron en tres puntos. El compromiso fue mantener 8 bits para las rutas relacionadas con herramientas y 4 bits para borradores de blogs extensos. Un artefacto del modelo, dos perfiles de servicio: algo permitido por la redirección en el gateway.

Lista de verificación práctica: preparación para el lanzamiento

• [ ] La historia de Roofline está documentada para el prefill y la decodificación
• [ ] Se miden los bytes/KV por token en el punto de control real
• [ ] La concurrencia × presupuesto de contexto cabe en la memoria de la GPU con margen
• [ ] Está habilitado el agrupamiento continuo con una política de prioridad para la decodificación

[ ] Las claves de caché del prefijo incluyen plantilla, tokenizador, LoRA y escala RoPE

[ ] La tupla de muestreo se registra por cada respuesta

[ ] Decodificación restringida para cualquier contrato JSON

[ ] Destokenización en flujo de buffers incompletos UTF-8

[ ] Secuencias de detención probadas a través de los límites de tokens

[ ] Decodificación especulativa activada según la tasa de aceptación medida

[ ] Cuantización validada mediante pruebas específicas para la tarea

[ ] El plan paralelo de tensores/pipeline coincide con la realidad de las interconexiones

Lista de verificación práctica — Triaje de incidentes

1. ¿Está roto TTFT o TPOT?
2. ¿Cambió la longitud del prompt o la composición del lote?
3. ¿Está la memoria KV cerca del límite establecido?
4. ¿Han variado las versiones del tokenizador/plantilla?
5. ¿Ha cambiado algún indicador de kernel/cuantificación?
6. ¿La decodición especulativa tiene baja tasa de aceptación?
7. ¿Estamos limitados por ancho de banda o por capacidad de cálculo en un perfil específico?

Trabaje la lista en orden; la mayoría de las páginas que indican “el modelo es lento hoy” se resuelven en el paso cuatro.

Glosario en un solo lugar

TTFT — tiempo hasta el primer token emitido después del inicio de la solicitud. TPOT / ITL — tiempo promedio entre tokens sucesivos. Prefill — procesamiento paralelo de la solicitud que llena los valores KV. Decode — pasos autoregresivos que emiten nuevos tokens. KV cache — claves/valores almacenados de tokens anteriores. GQA — atención a consultas agrupadas que reduce los cabezales KV. PagedAttention — asignación de KV por bloques. Nucleus (top-p) — truncamiento adaptativo de la cola de probabilidades. Speculative decoding — aceleración mediante borrador y verificación posterior. Roofline — modelo que relaciona la intensidad con el pico de FLOPs en función del ancho de banda.

Párrafo final de síntesis

Considere la inferencia como una línea de producción. Los tokenizadores definen los contenedores de piezas. Las representaciones vectoriales y los bloques son las máquinas. La caché KV es el inventario en proceso que ocupa espacio de almacén por cada pedido abierto. El muestreo es el control de calidad de cada unidad. La transmisión en tiempo real es el muelle de envío. El decodificación especulativa es una vía de inspección paralela. Si optimiza una estación sin vigilar el inventario y ancho de banda, generará montones de trabajo inconcluso y clientes enojados, aunque cada estación “parezca más rápida” por separado.

Apéndice: Comparación de modelos mentales que escuchará en las entrevistas

Los entrevistadores suelen pedirte que concilies tres eslóganes: “los transformadores son paralelos”, “la decodificación es secuencial” y “la atención es cuadrática”. Todos son ciertos en diferentes contextos. El entrenamiento y el prefill aprovechan el paralelismo entre posiciones que ya existen. La decodificación no puede inventar tokens futuros con antelación sin especulación. El término cuadrático de la atención es más importante cuando la longitud de la secuencia es grande en relación con las operaciones matemáticas basadas en el ancho. Una respuesta sólida indica primero el contexto antes de mencionar el eslogan.

Otra trampa común es equiparar la cantidad de parámetros con la velocidad de decodificación. Los parámetros determinan los bytes que se mueven por paso; el diseño (GQA), el tipo de dato y el agrupamiento deciden cómo esos bytes se traducen en tokens por segundo. Dos modelos de 70B pueden diferir en un factor de 2 en cuanto a latencia interactiva tras considerar estos factores.

Una tercera trampa es tratar el muestreo como “solo RNG”. La temperatura, la truncación, las penalizaciones y las restricciones transforman cada una la distribución categórica; el RNG solo elige entre lo que queda. Para depurar resultados extraños, hay que comenzar por registrar esa tupla.

Apéndice: ecuaciones mínimas que vale la pena memorizar

KV bytes ≈ 2 × layers × kv_heads × head_dim × bytes × seq_len × batch. Intensidad para la decodificación de batch-1 ≈ 2 × params / weight_bytes ≈ O(1) FLOP/byte para fp16 denso. Tokens especulativos esperados por verificación ≈ (1 − α^(k+1)) / (1 − α). Estabilidad de softmax: restar el máximo antes de aplicar exp. Máscara causal: escribir −∞, y no cero, en las puntuaciones prohibidas.

Si puedes volver a derivar esas fórmulas en una pizarra y explicar cada símbolo, ya superas a la mayoría de las explicaciones vagas.

Apéndice: hacia dónde profundizar a continuación

Después de esta visita por el pipeline, las continuaciones naturales son: leer una ruta de asignador al estilo PagedAttention en un motor abierto, realizar el perfilamiento de un paso de prefill y uno de decodificación con un herramienta de perfilamiento del proveedor, e implementar un pequeño bucle de decodificación agresiva con una caché KV explícita en NumPy o PyTorch para comprender las estructuras de los datos. Estos ejercicios convierten el vocabulario mencionado anteriormente en memoria muscular sin necesidad de utilizar un conjunto completo de herramientas de entrenamiento.

Otra pasada: Vincular las métricas al problema del usuario

Cuando un ticket de soporte indica “la IA es lenta”, hay que traducir ese mensaje. Si el indicador de carga aparece antes de cualquier texto, investigar los factores TTFT: longitud del prompt, prefijos no utilizados, congestión en el proceso de prefill o ausencia de caché. Si el texto aparece rápidamente pero luego avanza lentamente, investigar los factores TPOT: sobrecarga de lotes, memoria KV que obliga a usar lotes pequeños, pesos no cuantizados en una tarjeta con ancho de banda limitado, o la desactivación de la especulación en una ruta que antes funcionaba bien.

Cuando el ticket indica “las respuestas empeoraron después del martes”, compare las tuplas de muestreo, los hashes de plantillas y las banderas de cuantización antes de volver a entrenar nada. Las regresiones de servicio se disfrazan constantemente de regresiones de inteligencia.

Cuando el ticket dice “inventa JSON”, deje de ajustar la temperatura y utilice una decodificación restringida. El muestreo no puede imponer una gramática; el enmascaramiento sí.

Las reuniones de planificación de capacidad son más efectivas cuando alguien escribe tres números en la pizarra: bytes por token KV, concurrencia objetivo y contexto objetivo. Multiplique, sume el impacto en recursos y compárelo con la memoria de la GPU. Los argumentos sobre “la magia de la IA” terminan; comienza la matemática de adquisiciones.

Ese es el propósito de toda esta visita por el pipeline: reemplazar lo misterioso por métricas, y las métricas por palancas que puede tirar.

Nota final sobre el alcance

Esta reescritura se mantiene dentro del proceso de inferencia: lo que ocurre después de que existen los pesos, cuando un cliente envía texto, y antes de que el equipo de operaciones comience a hablar sobre el ajuste fino. Las consideraciones relacionadas con el entrenamiento —mezclas de datos, optimizadores, horarios de entrenamiento en paralelo— son sumamente importantes, pero corresponden a un tema distinto. Si puedes mantener en mente bajo presión la división entre prefill y decode, el costo asociado a KV y la composición de muestreo, ya cuentas con los cimientos sobre los cuales se basan esos otros temas.

Ejercicio para el lector

Tome una solicitud de producción de sus registros. Anote la cantidad de tokens de entrada, la cantidad de tokens de salida y el valor observado de TTFT/TPOT, si los tiene. Estime la memoria KV utilizando la fórmula por token correspondiente al diseño de las capas y la cabeza de su modelo. Determine si la solicitud se acercó más a un proceso de prellenado limitado por cálculos o a uno de decodificación limitado por ancho de banda. Indique un factor que podría haber influido en la métrica que más le interesa: caché de prefijo, tamaño del lote, cuantización, GQA o especulación. Si puede completar este ejercicio sin volver a abrir este artículo, la reescritura cumplió su objetivo.

Mantenga una hoja de referencia personal breve: prefill versus decode, fórmula de los bytes KV, TTFT versus TPOT y orden de muestreo. Revísela antes de las revisiones de capacidad y antes de culpar al modelo por los errores en el servicio. Pequeños hábitos como ese se convierten con el tiempo en una intuición fiable.

Lecturas relacionadas

• Optimización de la inferencia de LLM: prefill, decodificación y LLMOps empresariales — Cuellos de botella entre prefill y decodificación, procesamiento por lotes continuo, FlashAttention, cuantización, PagedAttention, decodificación especulativa, prefill por bloques y servicio desagregado.
• Decodificación especulativa y salida temprana: acelerando la decodificación autoregresiva — Proceso de redacción seguido de verificación y salidas por capas basadas en confianza reducen la latencia de decodificación cuando lo permiten los presupuestos de aceptación y precisión.
• La cache KV es la base de datos invisible que consume memoria GPU en la decodificación de LLM — Comparación entre prefill y decodificación, cálculos KV, GQA/MQA, PagedAttention, cuantización y eliminación de datos para inferencia en producción.