¿Qué pasa dentro de un LLM cuando pulsas enter?
Los dos tiempos de la inferencia
Llevo tiempo trabajando con modelos de lenguaje, y hay un detalle del que casi nadie habla porque parece demasiado obvio para mencionarlo: cuando le escribes a un chatbot, la respuesta no llega a una sola velocidad, sino a dos.
Pulsas enter y esperas un momento, porque hay una pausa antes de que aparezca la primera palabra. Y después el texto sale mucho más rápido, palabra tras palabra, hasta completar la respuesta. La pausa del principio y el chorro que viene a continuación no van al mismo ritmo, y esa diferencia no es culpa de tu conexión ni de un servidor saturado.
Es la consecuencia directa de cómo genera texto un modelo por dentro. Entender por qué ocurre explica muchas cosas que solemos dar por hechas: por qué un prompt largo tarda más en arrancar, por qué la respuesta fluye una vez ha empezado, y por qué escribir la respuesta le cuesta más que leer la pregunta.
En el artículo anterior terminamos de montar el transformer, la pieza que aprende a predecir qué palabra viene a continuación mirando todo el contexto a la vez. Pero un modelo entrenado no es lo mismo que un modelo en marcha. Lo que vamos a ver hoy es la inferencia(inference): el proceso de usar un modelo ya entrenado para generar una respuesta. Y casi todo lo que ocurre durante ese proceso se explica por un único hecho: la inferencia tiene dos tiempos, y cada uno funciona con una física distinta.
Primer tiempo: leer todo de un vistazo
Cuando pulsas enter, lo primero que hace el modelo no es escribir, es leer. Lee tu prompt entero —la pregunta, las instrucciones, el documento que hayas pegado y toda la conversación previa— y lo procesa de una sola vez. A esta fase se le llama prefill (que podríamos traducir como “rellenado previo”), y es la responsable de la pausa que notas antes de que aparezca la primera palabra.
Esa pausa tiene un nombre técnico: TTFT (time to first token, el tiempo hasta el primer token). Es una de las dos métricas habituales para medir la velocidad de un modelo, y es la que percibes mientras esperas mirando la pantalla.
Aquí se aprovecha una propiedad del transformer que vimos en el artículo anterior: procesa todas las palabras a la vez, no una detrás de otra. El prefill es el momento en que esa propiedad rinde al máximo. El modelo no lee tu prompt palabra por palabra, como lo lees tú ahora: toma todos los tokens de tu prompt y los hace pasar por la torre entera —todas las capas y todas las cabezas de atención— en una única pasada, procesándolos en paralelo.
Una forma de verlo es pensar en la revisión de un contrato. Para entender bien una cláusula tienes que compararla con las demás: las definiciones, las excepciones, lo que dice una página sobre otra. Si lo haces tú solo, avanzas y retrocedes cláusula por cláusula. Pero si tuvieras un ayudante para cada cláusula, y todos pudieran hablar entre sí al mismo tiempo, en una sola ronda cada cláusula sabría cómo encaja con el resto. El prefill es esa ronda, y la pausa que notas es lo que cuesta completarla.
Por eso la pausa crece con el tamaño de tu prompt. Un “hola” se procesa en un instante. Pegar un informe de cuarenta páginas y pedir un resumen tarda bastante más en arrancar, aunque la respuesta final sea de tres líneas. Esto sorprende a mucha gente: si la respuesta es corta, ¿por qué tarda tanto en empezar? Porque la pausa no mide lo que vas a leer tú, sino lo que el modelo tiene que leer antes de poder escribir.
Hay un detalle que conecta con el artículo sobre por qué los LLMs olvidan. Esa ronda de comparaciones tiene un coste cuadrático: cada token se compara con todos los demás, de modo que duplicar la longitud del prompt no duplica el trabajo de la atención, sino que lo cuadruplica. La pausa del prefill es donde ese coste se vuelve tangible.
Al terminar esta fase, el modelo ha hecho una sola cosa: ha leído todo tu contexto y está listo para hacer su primera apuesta sobre qué palabra viene a continuación. A partir de ese momento empieza el segundo tiempo, que funciona de una manera completamente distinta.
Segundo tiempo: escribir palabra a palabra
Al terminar el prefill, el modelo todavía no ha escrito nada. Lo que tiene es una predicción: un reparto de probabilidades sobre qué token viene a continuación. Es la apuesta de Shannon que vimos en el artículo anterior, el softmax que asigna un porcentaje a cada palabra posible del vocabulario. De ese reparto el modelo elige un token —enseguida veremos cómo lo elige—, y ese token es la primera palabra de la respuesta. La pausa ha terminado y empieza el chorro.
Pero aquí está la diferencia clave con el prefill. Para generar la segunda palabra, el modelo no puede seguir adelante sin más, porque necesita la primera. Toma la palabra que acaba de escribir, la añade al final de la secuencia, y vuelve a pasarlo todo por la torre entera para obtener un nuevo reparto de probabilidades. Elige la segunda palabra, la añade, y repite. Una palabra, una pasada completa por el modelo. Otra palabra, otra pasada. Y así hasta terminar la respuesta.
A esta fase se le llama decode (o generación), y a su forma de trabajar, generación autorregresiva (autoregressive): cada palabra que el modelo produce se convierte en parte de la entrada que usará para producir la siguiente. El modelo escribe una palabra, vuelve a leer todo lo que lleva —tu prompt más lo que ya ha escrito— y solo entonces decide la palabra que sigue.
La razón de que esto tenga que ser así, una palabra detrás de otra, la dejamos plantada en el artículo anterior. El transformer que genera texto lleva una regla incorporada: cada token solo puede atender a los que tiene detrás, nunca a los que vienen después. Es la máscara causal. Y tiene todo el sentido, porque cuando el modelo está escribiendo la quinta palabra todavía no ha decidido la sexta, que sencillamente no existe aún. Por eso no hay forma de generar las palabras en paralelo, como sí se hacía en el prefill: cada palabra depende de la anterior, y no se puede calcular algo que depende de un resultado que todavía no tienes.
Esto explica por qué la velocidad del chorro se mide con su propia métrica, distinta del TTFT: el tiempo por token de salida, es decir, cuánto tarda el modelo en producir cada palabra una vez ha arrancado. Y explica también la asimetría que da título a este artículo. El prefill procesa muchos tokens en una sola pasada; el decode hace una pasada completa por cada token. Leer es un acto en paralelo, y escribir es un acto secuencial.
Visto así, queda una pregunta incómoda. Si el modelo vuelve a leerlo todo cada vez que añade una palabra, debería ir cada vez más lento a medida que la respuesta crece. Es justo lo que ocurriría, si no fuera por el truco que vemos a continuación.
Por qué la segunda palabra llega más rápido
Acabamos de ver un problema. Si el modelo vuelve a leer todo el texto cada vez que añade una palabra, cuanto más larga sea la respuesta, más lento debería ir cada paso. Una respuesta de quinientas palabras terminaría escribiéndose a cámara lenta. En la práctica no ocurre: el chorro se mantiene a un ritmo bastante estable de principio a fin. La razón es un truco de eficiencia que ya nombramos en el artículo sobre por qué los LLMs olvidan, y que ahora podemos entender por dentro: el KV cache (la caché de claves y valores).
Recupera por un momento la mecánica de la atención del artículo anterior. Cada token genera tres vectores: una consulta (query), una clave (key) y un valor (value). Para decidir la palabra siguiente, el modelo lanza la consulta del último token contra las claves de todos los tokens anteriores, y mezcla sus valores según esas comparaciones.
Aquí está la observación clave. Las claves y los valores de tu prompt y de las palabras ya escritas no cambian cuando se añade una palabra nueva. La clave del token número tres es la misma tanto si la respuesta va por la palabra cuatro como si va por la cuatrocientas. Recalcularlas en cada paso, una y otra vez, es desperdiciar trabajo.
El KV cache es exactamente lo que su nombre indica: una memoria donde el modelo guarda las claves y los valores de todos los tokens que ya ha procesado. Cuando genera una palabra nueva, no recalcula el pasado. Calcula solo la clave y el valor del último token, los añade a la caché, y reutiliza todo lo demás que ya tenía guardado. En lugar de releer el contrato entero en cada palabra, el modelo conserva sus notas de las lecturas anteriores y solo añade la nota de la línea nueva.
Y esto responde por fin a la pregunta del título. La primera palabra es la más lenta de toda la respuesta porque su espera incluye el prefill completo: leer y procesar todo tu prompt desde cero para llenar la caché por primera vez. La segunda palabra llega mucho más rápido porque ese trabajo ya está hecho y guardado, y solo hay que procesar un token, el que se acaba de escribir. La pausa que notas al principio es, en buena medida, el coste de construir la caché. El chorro que viene después es la recompensa de tenerla.
El KV cache no sale gratis, y conviene saber lo que cuesta, porque explica un límite muy real. Esa memoria crece con cada palabra de la conversación, y ocupa un sitio considerable en la memoria de la GPU. Cuanto más larga es la conversación, más caché hay que guardar y mover en cada paso. Esta es la otra cara de la factura cuadrática de la que hablamos hace semanas: no solo cuesta construir el contexto, también cuesta mantenerlo vivo mientras el modelo escribe. Buena parte de la ingeniería de los modelos actuales consiste en gestionar bien esa caché.
De porcentajes a palabra: cómo elige el modelo
Quedó un cabo suelto en el segundo tiempo. Dije que, en cada paso, el modelo produce un reparto de probabilidades sobre el vocabulario y “elige” una palabra. Esa elección no es un detalle menor, porque es uno de los pocos puntos donde tú, desde fuera, puedes cambiar el comportamiento del modelo sin tocar el modelo en sí.
Recupera el ejemplo del artículo anterior. Después de leer “el perro”, el modelo reparte sus probabilidades para la palabra siguiente: pongamos un 41% para “ladra”, un 13% para “come”, un 9% para “duerme”, y porcentajes cada vez más pequeños repartidos entre miles de palabras más. ¿Cuál escribe?
La opción más simple es coger siempre la más probable, “ladra”, sin dudar. A esto se le llama elección voraz (greedy), y tiene una ventaja y un defecto. La ventaja es que es predecible: misma pregunta, misma respuesta. El defecto es que resulta monótona, porque un texto que siempre toma la palabra más probable suena plano, se repite y tiende a meterse en bucles.
Por eso casi todos los sistemas, en lugar de coger siempre la favorita, introducen algo de azar: tiran un dado cargado según los porcentajes. Con el reparto anterior, “ladra” saldría el 41% de las veces, pero de vez en cuando saldría “come” o “duerme”. Ese azar se regula con dos mandos.
El primero es la temperatura (temperature). Es un número que controla cuánto se respeta el reparto original. Con temperatura baja, los porcentajes altos se vuelven todavía más altos y los bajos casi desaparecen, de modo que el modelo se acerca a la elección voraz: conservador y repetible. Con temperatura alta, los porcentajes se aplanan, las palabras que tenían un 2% pasan a ser opciones reales, y el texto se vuelve más variado e impredecible. La temperatura es, literalmente, el mando de “creatividad” que algunas herramientas te dejan tocar.
El segundo mando es el top-p, también llamado muestreo por núcleo (nucleus sampling), propuesto por Ari Holtzman y sus colegas en 2019. En vez de considerar las miles de palabras posibles, el modelo las ordena de mayor a menor probabilidad y se queda solo con las que suman, juntas, un porcentaje p; por ejemplo, el 90%. Descarta así la larguísima cola de palabras improbables y elige solo dentro de ese grupo, lo que evita que, por mala suerte, el dado saque una palabra absurda de entre las decenas de miles que tenían una probabilidad mínima pero no nula. Existe una variante parecida, el top-k, que se queda con un número fijo de candidatos en lugar de con un porcentaje.
Conviene entender qué controlan de verdad estos mandos, porque se malinterpretan a menudo. No hacen al modelo más listo ni más veraz, solo regulan cuánto se aparta de su apuesta más segura. Subir la temperatura aporta variedad y ayuda a escribir, pero también aumenta la probabilidad de que el modelo se desvíe hacia continuaciones menos sólidas. Bajarla aporta consistencia y conviene cuando quieres respuestas estables, como extraer datos de un documento. Y hay un límite importante: estos mandos cambian cómo elige el modelo entre sus opciones, pero no inventan opciones que no estuvieran ya en el reparto. Si la información correcta no estaba entre las probabilidades, ninguna temperatura la va a hacer aparecer.
El truco para acelerar lo secuencial: speculative decoding
El segundo tiempo, el decode, tiene un problema de fondo que va más allá de la velocidad que notas. Cuando el modelo genera una palabra por pasada, la GPU que lo ejecuta se queda en buena parte ociosa. Una GPU está hecha para realizar miles de operaciones a la vez, y procesar un solo token apenas le da trabajo en paralelo: el tiempo se va sobre todo en mover datos dentro de la memoria, no en calcular. Hay capacidad de sobra sin aprovechar.
La pregunta natural es si se puede usar esa capacidad ociosa para ir más rápido, y la respuesta más ingeniosa se llama speculative decoding (decodificación especulativa). La propusieron Yaniv Leviathan y sus colegas de Google en 2022, y parte de una observación sencilla: verificar es más barato que generar. Comprobar si una palabra es la correcta se puede hacer en paralelo para muchas palabras a la vez, igual que en el prefill, mientras que generarlas hay que hacerlo una a una.
El truco usa dos modelos. Uno pequeño y rápido, el borrador (draft), y el grande de siempre, el que de verdad quieres usar. El modelo pequeño se lanza a adivinar, por ejemplo, las cinco palabras siguientes, una detrás de otra. Como es pequeño, lo hace muy deprisa. Después, el modelo grande coge esas cinco palabras propuestas y las verifica todas en una sola pasada, en paralelo, comprobando para cada una si es la que él mismo habría elegido.
Lo que ocurre a continuación es lo elegante. El modelo grande acepta las palabras correctas desde el principio hasta la primera que no coincide con su criterio. Esa primera discrepancia la corrige él mismo y descarta el resto de la propuesta del borrador. En el mejor caso, si el modelo pequeño acertó las cinco, el grande ha producido cinco palabras en el tiempo de una sola pasada. En el peor caso, si el borrador falló ya en la primera, se ha gastado una pasada para producir una sola palabra, igual que sin el truco. La mayoría de las veces el resultado queda en un punto intermedio, y de ahí sale la ganancia.
Hay un detalle que hace que todo esto sea aceptable y no una chapuza: el resultado es estadísticamente idéntico al que habría producido el modelo grande por su cuenta. No es una aproximación, ni se sacrifica calidad a cambio de velocidad. El borrador solo propone, quien decide siempre es el grande, y el procedimiento está diseñado para que la respuesta final tenga exactamente la misma distribución que si el pequeño no hubiera existido. En la práctica, esto acelera la generación entre dos y tres veces.
Puedes verlo como un experto y un becario trabajando juntos. El becario escribe rápido un borrador de las próximas frases. El experto lo lee de un vistazo, da por buenas las que habría escrito igual y reescribe a partir del primer error. Como leer y dar el visto bueno es mucho más rápido que redactar desde cero, los dos juntos terminan antes que el experto trabajando solo, y el texto final es exactamente el que el experto habría firmado.
Lo que cambia para quien construye con esto
Hasta aquí, la mecánica que vive cualquiera que use un chatbot. Pero si construyes productos sobre estos modelos, la asimetría de los dos tiempos deja de ser una curiosidad y se convierte en la base de casi todas tus decisiones de coste y de velocidad. Vale la pena traducirla.
Empecemos por la factura. Si miras los precios de cualquier proveedor de modelos, verás que cobran por separado los tokens de entrada y los de salida, y que los de salida son varias veces más caros, a menudo el triple o más. Ahora ya sabes por qué. Los tokens de entrada se procesan en el prefill, de una sola pasada y en paralelo, que es justo el tipo de trabajo que una GPU hace barato. Los tokens de salida se generan en el decode, uno a uno, con una pasada completa por cada palabra y la máquina infrautilizada. No te cobran más por la salida por capricho: es que cuesta más producirla.
De aquí sale un consejo práctico. El precio de pegar un documento largo en el prompt es real, pero contenido; el precio de pedir respuestas largas se dispara. Si quieres controlar el gasto, el sitio donde más se nota es la longitud de lo que el modelo escribe, más que la de lo que lee.
La segunda traducción es la diferencia entre dos formas de medir la velocidad que se confunden a menudo: la latencia y el throughput. La latencia es lo que tarda un usuario concreto en recibir su respuesta, y se descompone justo en los dos tiempos que hemos visto: la pausa inicial (TTFT) más el tiempo por cada palabra. El throughput es cuántos tokens es capaz de producir el sistema en total por segundo, sumando todos los usuarios a la vez. No son lo mismo, y a veces tiran en direcciones opuestas.
Esto también explica un detalle de la interfaz que damos por hecho. Las respuestas se muestran en streaming, palabra a palabra, y no es un efecto estético: es que el modelo realmente las produce así, una detrás de otra, y enseñarlas según salen hace la espera más llevadera que mostrar todo de golpe al final.
La pieza que conecta latencia y throughput es el batching (procesamiento por lotes). Como el decode deja la GPU medio ociosa, los proveedores no atienden a un usuario cada vez: agrupan las peticiones de muchos usuarios y las procesan juntas en la misma pasada, aprovechando la capacidad que sobraba. Eso dispara el throughput y abarata el coste por token, que es como estos servicios pueden ofrecer precios bajos. El matiz es que llenar el lote puede hacer esperar un poco a cada usuario. Ahí está la tensión que gestiona cualquiera que ponga uno de estos modelos en producción: exprimir el throughput para bajar el coste sin estropear la latencia que percibe la persona del otro lado.
Y hay un cambio de oficio que conviene nombrar. Durante años, optimizar un sistema de software era, sobre todo, optimizar el código. Con los modelos de lenguaje, una parte enorme del trabajo es optimizar la inferencia: elegir el tamaño de modelo adecuado para cada tarea, recortar los prompts, limitar la longitud de las respuestas, decidir cuándo compensa el speculative decoding y gestionar bien la caché. Es una disciplina nueva, y nace entera de la física que acabamos de describir.
Dos tiempos, una sola apuesta
Hemos seguido el viaje completo, desde que pulsas enter hasta la última palabra de la respuesta, y todo encaja en una sola idea: la inferencia tiene dos tiempos con físicas opuestas. Primero el prefill, donde el modelo lee tu prompt entero de una sola pasada y en paralelo, y de ahí viene la pausa inicial. Después el decode, donde escribe la respuesta palabra a palabra, con una pasada completa por cada una, y de ahí viene el chorro. El KV cache es lo que mantiene ese chorro a un ritmo estable, el sampling es cómo se elige cada palabra del reparto de probabilidades, y el speculative decoding es el truco para que lo secuencial duela menos.
Si te quedas con una sola idea, que sea esta: el modelo no “genera texto” como un acto único. Hace la misma apuesta de Shannon que vimos en el artículo anterior —¿qué palabra viene ahora?— una y otra vez, una pasada por cada palabra. Toda la asimetría que notas, y casi todo lo que se paga por ella, sale de un hecho simple: leer se puede hacer de golpe, y escribir no.
Con esto la serie queda redonda. El token es la moneda, el contexto es la memoria, el embedding es el mapa, el transformer es el motor, y la inferencia es el viaje: lo que ocurre cada vez que pones el motor en marcha.
Pero hemos dado por hecho lo más importante, que el modelo apuesta bien. ¿De dónde sale ese criterio? Un modelo recién entrenado sabe predecir la palabra siguiente, pero no sabe, de entrada, comportarse como un asistente útil y prudente. Eso se le enseña en una segunda fase, y ahí aparece el RLHF que dejé plantado en el artículo anterior, con la penalización de Kullback-Leibler haciendo de correa. Cómo se entrena y se alinea un modelo será el próximo artículo.
Y te dejo con la pregunta práctica de siempre. La próxima vez que esperes mirando una respuesta, fíjate en los dos tiempos: cuánto tarda en arrancar y cómo de rápido fluye después. Si trabajas con estos modelos, lleva esa mirada a tu caso concreto: ¿estás pagando, en dinero o en tiempo, por respuestas largas que en realidad nadie necesita tan largas? Casi siempre, el ahorro más fácil no está en lo que el modelo lee, sino en lo que le dejamos escribir.