La tecnología de base.

Cómo un modelo sirve una petición

Prefill / decode

Las dos fases de la generación. El prefill procesa el prompt entero en una pasada paralela y está limitado por cómputo puro. El decode emite un token cada vez, cada uno dependiendo del anterior, y está limitado por ancho de banda de memoria. Tienen cuellos de botella opuestos, y por eso cada aceleración de este número se indica para una u otra — una ganancia de 9,5× en prefill puede no hacer nada por el decode.

KV cache

Cada token generado atiende a todos los anteriores. En vez de recalcular en cada paso los vectores de clave y valor de todos esos tokens previos, se almacenan. La caché crece linealmente con la longitud de contexto, y en contextos largos supera de forma habitual el tamaño de los propios pesos — por eso comprimirla (n. 01 §2) rinde más que comprimir pesos en trabajo de contexto largo.

Prefix caching

Cuando muchas peticiones empiezan igual — el mismo system prompt, el mismo documento cargado — la KV cache de esa apertura compartida se puede calcular una vez y reutilizar en lugar de rehacer el prefill en cada petición. El clonado de caché de llama.cpp (n. 01 §1) es esta idea expuesta como endpoint del servidor.

Ventana de contexto

El número máximo de tokens que el modelo puede atender a la vez. Las cifras de titular de n. 01 §3 (262K, 1M) son lo que la arquitectura soporta, no necesariamente lo que aprovecha bien ni lo que te cabe en memoria.

Decision models
(estilo JEV)

Modelos que responden preguntas tipadas sobre un estado — elige una de estas etiquetas, sí o no, una puntuación — con una probabilidad calibrada por opción, en una sola pasada y sin generar texto. Toman el nombre de Jev, de TypeSafe, cuyo formato /v1/systemone adoptaron los modelos abiertos y llama.cpp. Sustituyen a "generar y luego parsear" en enrutado, moderación y decisiones de agentes; la pega es que una respuesta bien formada y segura puede seguir siendo errónea (n. 05 §3).

La atención, y por qué hay tantos tipos

Atención
(completa, densa, softmax)

La operación central: cada token se compara con todos los demás para decidir de qué tirar. Exacta, y cuadrática — duplica la secuencia y cuadruplicas el coste. Todo lo de abajo es un intento de no pagar eso.

Flash attention

No es una aproximación. Las mismas matemáticas exactas, calculadas por baldosas para que la matriz de atención completa nunca se escriba en memoria. Ganancia pura, y por eso está en todas partes.

MHA / GQA / MLA

La atención multi-cabeza ejecuta varias operaciones de atención en paralelo. La grouped-query hace que las cabezas compartan vectores de clave y valor, encogiendo la caché. La multi-head latent comprime claves y valores a un espacio latente de bajo rango, encogiéndola más. Sobre todo son reducciones de tamaño de caché, no de cómputo.

Sliding window
attention (SWA)

Cada token atiende solo a los últimos N tokens. La caché deja de crecer y pasa a ser de tamaño fijo — a costa de que el modelo realmente no pueda ver más atrás desde esa capa.

Attention sink

Los primeros tokens de una secuencia, a los que las cabezas de atención siguen atendiendo con fuerza sea cual sea el contenido. Si se conservan, una sliding window se comporta; si se eliminan, la calidad se hunde. Relevante esta semana porque la SWA con sinks igualó a los retrofits post-entrenados de linear attention (n. 03 §2).

Sparse attention

Atender a un subconjunto elegido de tokens anteriores en vez de a todos, con una selección estructural o aprendida. La Compressed Sparse Attention de DeepSeek-V4 consolida la caché en bloques y luego escoge los k mejores, que es como llega al millón de tokens con el 27% del cómputo de la generación anterior.

Atención lineal

Reformula la atención para que cueste linealmente en vez de cuadráticamente, llevando un estado recurrente de tamaño fijo en lugar de una caché que crece sin parar. Barata y de memoria constante — pero el estado pierde información, así que olvida. Toda la pregunta de diseño es qué olvida y a qué velocidad.

Atención híbrida

Mezclar dos o más de las anteriores dentro de un mismo modelo, normalmente intercalando capas. El intercambio es directo: las capas lineales y de ventana deslizante son baratas pero pierden información, las completas y dispersas son exactas pero caras. Intercalarlas captura casi todo el ahorro de coste conservando suficientes capas exactas para un recuerdo real a larga distancia. Esta es la arquitectura dominante de 2026 — Kimi K3 combina KDA con MLA, DeepSeek-V4 intercala atención dispersa comprimida con atención muy comprimida, y Qwen3 y Granite intercalan capas de ventana deslizante con capas completas. Cuando este número dice "híbrida", esto es lo que quiere decir.

KDA

Kimi Delta Attention, la variante lineal de K3. Su rasgo distintivo es el control por canal de la velocidad a la que decae cada dimensión del estado recurrente — un olvido de grano más fino que una única tasa de decaimiento global.

NoPE

Entrenar un modelo sin ninguna codificación posicional, dejando que la máscara causal aporte el orden de forma implícita. Cambia el aspecto de una caché: sin rotación aplicada a las claves, en la fila almacenada sobrevive una noción de saliencia independiente de la query, y por eso un evictor puede funcionar antes de que exista ninguna query — y por eso el mismo truco se hunde en un modelo con RoPE (n. 04 §2).

RoPE

Rotary position embeddings: cómo se codifica la posición de un token, rotando sus vectores de query y key un ángulo proporcional a la posición. El enfoque estándar, y lo que normalmente hay que estirar para ampliar una ventana de contexto.

Estructura del modelo

Denso vs MoE

Un modelo denso ejecuta todos sus parámetros para cada token. Una mixture of experts tiene muchos "expertos" feed-forward en paralelo y un router selecciona unos pocos por token, de modo que la mayor parte del modelo está inactiva en cualquier token dado.

Parámetros totales
vs activos

Por qué los modelos MoE se anuncian como "2,4T totales, 95B activos". Los totales determinan cuánta memoria necesitas para alojar el modelo; los activos, cuánto cómputo cuesta cada token. Esta es toda la razón por la que un modelo de un billón largo de parámetros se puede servir, y también por la que sigue siendo enorme de alojar.

Router /
expertos compartidos

El router es la red pequeña que elige qué expertos atienden cada token — entrenarlo para que reparta carga de forma pareja es una dificultad persistente. Los expertos compartidos se ejecutan para todos los tokens, sosteniendo la capacidad general para que los enrutados puedan especializarse.

Offload y caché
de expertos

Mantener los expertos de un MoE en la RAM del sistema, o en SSD, porque el modelo entero no cabe en la VRAM, y traer solo los que elige el router. Funciona porque cada token usa pocos expertos; es lento porque esos pocos, sean cuales sean, tienen que cruzar el bus. La pregunta de diseño es qué se queda residente: una caché LRU de expertos usados recientemente en la GPU, o un predictor que conoce de antemano los expertos de la capa siguiente (n. 05 §1, §2).

MTP

Multi-token prediction: entrenar al modelo para predecir varios tokens por delante en vez de uno. Las cabezas de predicción extra hacen luego de drafter integrado para speculative decoding, y por eso el soporte de MTP y el de especulación aparecen juntos una y otra vez en n. 01 §1.

Residuales e
hiperconexiones

Las conexiones residuales son los atajos que dejan fluir señal y gradiente por una pila profunda sin obstáculos. El trabajo reciente los generaliza — hiperconexiones con restricción de variedad, residuales de atención que permiten a una capa recuperar representaciones de cualquier capa anterior — porque en modelos dispersos y profundos un atajo simple es un cuello de botella.

Modelos en bucle
(looped)

Modelos que ejecutan el mismo bloque de capas varias veces por token en lugar de apilar más capas distintas, de modo que la profundidad cuesta cómputo pero no parámetros. Compran razonamiento por byte de pesos, y por eso interesan a quien está limitado por memoria; las preguntas abiertas son cómo servirlos — una KV cache por bucle sale cara — y qué sacrifican, con indicios tempranos de que es el conocimiento almacenado (n. 05 §2).

Cómo hacer un modelo más pequeño

Cuantización

Almacenar pesos, y a veces activaciones, con menor precisión numérica. La técnica de compresión dominante y, según n. 01 §2, la que menos daña el comportamiento del modelo.

PTQ vs QAT

La cuantización post-entrenamiento convierte un modelo ya terminado — barata, de minutos a horas, sin entrenar. El quantization-aware training simula la baja precisión durante el entrenamiento para que el modelo se adapte — caro, pero es lo único que funciona con anchos de bit realmente agresivos.

Calibración

La PTQ necesita una muestra de datos para elegir sus factores de escala. Se trató mucho tiempo como un detalle; n. 01 §2 es en buena medida la historia de esa suposición rompiéndose — calibrar con los datos adecuados es lo que hizo funcionar la cuantización ternaria de modelos de razonamiento.

Formatos de bits

FP16 y BF16 son la referencia de 16 bits; FP8 e INT8 la reducen a la mitad; 4 bits la reducen otra vez. Q4_K y compañía son los formatos de cuantización por bloques propios de llama.cpp. MXFP4 y NVFP4 son formatos de microescalado de 4 bits en los que un bloque pequeño de valores comparte un factor de escala — NVFP4 usa bloques más pequeños, captura mejor el rango dinámico local y necesita hardware de la generación Blackwell para ejecutarse de forma nativa.

Solo pesos
vs W4A4

Solo pesos almacena los pesos a 4 bits pero vuelve a subir de precisión para calcular, así que ahorra memoria pero no tanto ancho de banda. W4A4 cuantiza también las activaciones, de modo que la aritmética misma corre a 4 bits. Ese es el problema difícil y el que de verdad desbloquea los matrix engines de baja precisión.

STE

Straight-through estimator: el truco que hace que el QAT sea entrenable siquiera. El redondeo tiene gradiente cero en todas partes, así que la pasada hacia atrás simplemente finge que el redondeo era la función identidad y deja pasar el gradiente sin tocarlo.

Interferencia proactiva

Un modo de fallo en la recuperación, tomado de la investigación sobre memoria de trabajo humana: cuando un valor se sobrescribe repetidamente en el contexto, las versiones anteriores siguen interfiriendo y la precisión sobre la actual cae a medida que se acumulan las sobrescrituras. Importa aquí porque es un comportamiento que los benchmarks habituales no miden, así que la compresión puede empeorarlo de forma medible mientras las cifras agregadas parecen intactas.

Pruning

Borrar partes del modelo directamente. El pruning no estructurado pone a cero pesos individuales, produciendo una esparsidad que al hardware le cuesta aprovechar. El estructurado elimina unidades enteras — cabezas, capas, expertos, entradas de vocabulario — y sí encoge el modelo de verdad. Según n. 01 §2, también daña el razonamiento más que la cuantización.

On-policy distillation (OPD)

Destilación en la que el alumno se entrena con sus propias trayectorias generadas, y el profesor puntúa cada token que el alumno ha producido de verdad, en lugar de un corpus fijo de salidas del profesor. Corrige los errores que el alumno comete realmente, y por eso supera a la destilación off-policy con mucho menos dato. Su límite es la otra cara: la señal es por token y por tanto local, así que puede parchear un paso malo sin llegar a mostrar nunca un camino completo correcto — el problema del que va n. 02 §2.

Destilación

Entrenar un modelo alumno pequeño para que reproduzca el comportamiento de un profesor grande. Distinto de la compresión propiamente dicha: estás entrenando un modelo pequeño nuevo, no encogiendo el grande.

Destilación
off-policy vs
on-policy

La off-policy entrena al alumno sobre texto que produjo el profesor. La on-policy hace que el alumno genere y el profesor califique los intentos del propio alumno — así los estados con los que el alumno entrena son los que se va a encontrar desplegado. Ese desajuste es lo que la destilación off-policy hace mal, y cerrarlo es la razón de que la on-policy se impusiera este año.

KL directa
vs inversa

Las dos direcciones de la divergencia que un estudiante minimiza frente a su profesor. La KL directa (forward) penaliza al estudiante por no cubrir algo que el profesor considera probable, así que se extiende para cubrirlo todo. La KL inversa (reverse), la habitual en on-policy distillation, lo penaliza por poner masa donde el profesor no la pondría, así que se asienta en los modos que ya alcanza. Esa diferencia es la razón de que OPD afile las habilidades que el estudiante ya tiene pero transfiera poco conocimiento nuevo (n. 05 §2).

LoRA / QLoRA

Hacer fine-tuning entrenando pequeñas matrices adaptadoras de bajo rango junto a pesos congelados, en vez de actualizar el modelo entero. QLoRA lo hace sobre una base ya cuantizada, que es lo que permite hacer fine-tuning de modelos grandes en una sola GPU.

Cómo hacer la inferencia más rápida

Speculative
decoding

Algo barato propone los siguientes tokens; el modelo real los verifica todos en una única pasada paralela y se queda con los que acepta. Como la verificación es paralela y la generación es secuencial, esto convierte pasos de decode limitados por memoria en pasos limitados por cómputo. Y algo crítico: la distribución de salida no cambia — es una aceleración, no una aproximación.

Tasa de aceptación

La proporción de tokens propuestos por el draft que el modelo objetivo acaba aceptando. Es lo que se convierte en speedup, y depende muchísimo del contenido: una salida repetitiva y estructurada es fácil de adivinar y la prosa abierta no, así que una única cifra media de speculative decoding esconde casi todo lo que necesitas saber.

Longitud comprometida
y el bin del techo

Cuántos tokens propuestos acepta de verdad el modelo objetivo en cada ronda de verificación. Un block drafter propone un bloque de tamaño fijo, así que cuando el objetivo lo acepta entero la ronda queda limitada por el tamaño del bloque y no por la pericia del drafter: la media lo esconde y el histograma lo enseña como un pico en el bin superior — aceleración que pagaste al entrenar y nunca recoges (n. 04 §2).

Draft model

El modelo pequeño que hace las propuestas. Tiene que estar residente en memoria y más o menos alineado con el modelo objetivo, que es el coste principal de la técnica. Desde DFlash2, el draft muchas veces no es un hermano pequeño sino una cabeza entrenada a medida contra un objetivo concreto, publicada como su propio checkpoint pequeño y prediciendo un bloque de tokens por pasada (n. 03 §1).

Suffix decoding

Especulación sin draft model alguno: un índice sobre el texto ya visto propone continuaciones, cosa que funciona bien porque la generación real se repite a sí misma — código, nombres, contexto citado. Elimina por completo el coste en memoria del draft model (n. 01 §1).

Prefill
desagregado

Ejecutar la fase de prefill en workers separados para que un prompt largo no pare la generación de tokens del resto de usuarios del servidor.

KV-cache eviction

Descartar entradas de la KV cache para que un contexto largo deje de costar memoria. Los papers compiten en la regla de selección, pero la memoria solo vuelve si el almacenamiento se reorganiza físicamente por cabeza — una selección guardada como máscara no libera nada, y los rankings que lo ignoran miden contabilidad, no selección (n. 03 §2).

Etapas de entrenamiento

Pre- vs
post-entrenamiento

El preentrenamiento es la gran tirada no supervisada que construye el modelo base. El post-entrenamiento es todo lo posterior — fine-tuning supervisado, aprendizaje por refuerzo, destilación. Que GLM-5.3 se mueva veinte puntos sobre la misma base (n. 01 §4) es la razón de que el post-entrenamiento se trate ya como un eje de escalado propio.

SFT

Supervised fine-tuning: entrenar sobre demostraciones del comportamiento deseado. Lo más simple y todavía la columna vertebral del post-entrenamiento.

RL / RLVR / GRPO

El aprendizaje por refuerzo optimiza contra una recompensa en vez de contra objetivos fijos. RLVR usa recompensas comprobables de forma automática — los tests pasan, la respuesta es correcta — y por eso funciona tan bien en código y matemáticas. GRPO es el algoritmo de optimización de política relativa a grupo que se convirtió en la forma estándar de ejecutarlo.