Ciclo petición respuesta LLM explicado paso a paso

En pocas palabras: Cuando presionás Enter, el prompt se tokeniza en números (vocabulario de 100,256 tokens en OpenAI), el modelo de 1.76 billones de parámetros infiere el siguiente token, y lo transmite en tiempo real por streaming, repitiendo hasta completar la respuesta.

Cuando presionás “Enter” en ChatGPT, Claude o cualquier chat con IA, lo que pasa entre ese click y la primera palabra que aparece en pantalla es mucho más que magia neuronal. Es una cadena de etapas bien definidas que se ejecutan en milisegundos: armado de JSON, autenticación, tokenización, inferencia y streaming. Entender este ciclo no es un capricho técnico — es la diferencia entre integrar un LLM que funcione en producción y uno que falle estrepitosamente (y en la factura de API).

El ciclo de petición y respuesta de un LLM es el proceso completo que recorre un modelo de lenguaje grande desde que recibe un prompt en texto plano hasta que devuelve una respuesta legible, pasando por tokenización numérica, ensamblado del contexto, inferencia a través de capas transformer y generación de tokens uno a uno que se transmiten de vuelta al cliente en tiempo real. Las APIs de OpenAI, Anthropic y Google operan todas con variantes de este mismo pipeline, documentado en detalle por la herramienta de benchmarking iamspeed.dev.

¿Qué etapas recorre un prompt desde que presionás Enter hasta que ves la respuesta?

El recorrido arranca en tu aplicación cliente. Ya sea un chat web, una app mobile o un script en Python, lo primero que pasa es que el cliente arma un JSON estructurado con el prompt y todos los metadatos necesarios. Según el análisis publicado en dev.to por el creador de iamspeed.dev, este JSON incluye el texto del mensaje, el historial de la conversación, parámetros como temperatura y top_p, y el identificador del modelo que querés usar.

Ese JSON viaja por HTTPS hasta un API gateway. Ahí se hace la autenticación (tu API key), se aplican las reglas de rate limiting, y se decide a qué instancia del modelo se enruta la solicitud. Si algo falla en esta etapa — una key vencida, un límite de requests superado — ni siquiera llegás a quemar tokens.

Con el gateway satisfecho, el prompt llega al motor de inferencia. Ahí se disparan tres pasos en secuencia: tokenización del texto de entrada, ensamblado del contexto (que incluye el system prompt, el historial y el mensaje nuevo) y ejecución del modelo propiamente dicha. Lo interesante es que estas etapas no son simétricas con la respuesta: el modelo empieza a generar tokens y a mandarlos de vuelta mientras sigue procesando, sin esperar a tener la respuesta completa. Lo explicamos a fondo en nuestra guía sobre seguridad de Microsoft Intune.

¿Cómo se tokeniza el texto de entrada y se arma el contexto?

Tokenizar es convertir texto en números. Cada palabra, subpalabra o carácter se mapea a un ID numérico usando el vocabulario del modelo. “¿Cuál es la capital de India?” se transforma en algo como [1234, 567, 890, 234, 4567, 89, 12]. Lo que parece un detalle menor define todo lo que sigue: si tu prompt está mal tokenizado, el modelo arranca con información ruidosa.

Una vez tokenizado, el prompt se ensambla dentro de la ventana de contexto del modelo. Esta ventana es el límite máximo de tokens que el modelo puede procesar en una sola solicitud. Los modelos más usados manejan amplias ventanas de contexto. El ensamblado se ordena así: los tokens del system prompt (instrucciones base que vos no ves pero que condicionan el comportamiento del modelo), los tokens del historial de conversación y, al final, los tokens de tu mensaje nuevo. Si la suma excede la ventana de contexto, se recorta desde el inicio del historial (y ahí es cuando el modelo “se olvida” de las primeras partes de la charla).

¿En qué consiste el forward pass y la predicción token a token?

Acá es donde el modelo hace el trabajo pesado. El forward pass es una pasada completa de la secuencia de entrada por todas las capas transformer del modelo. En cada capa, los mecanismos de atención calculan qué partes de la secuencia son relevantes para cada token, y las redes feed-forward aplican transformaciones no lineales. El resultado de este cómputo masivo — estamos hablando de miles de millones de parámetros — es una distribución de probabilidad sobre todo el vocabulario del modelo para el próximo token.

El modelo elige el token más probable (o samplea según la temperatura que le hayas configurado), lo emite, y lo agrega a la secuencia de entrada para la siguiente iteración. Supongamos que el prompt es “La capital de India es”. El modelo predice “Nueva”, emite ese token, y ahora la secuencia es “La capital de India es Nueva”. Siguiente forward pass: predice “Delhi”. Emite. Siguiente: predice un token de fin de secuencia (EOS). Ciclo terminado. Más contexto en la guía completa de ChatGPT que preparamos.

Este proceso se repite token por token hasta que el modelo genera el token EOS o hasta que alcanza el límite de tokens de salida que configuraste. Cada iteración implica un forward pass completo — sí, con toda la secuencia acumulada hasta ese punto. Por eso generar 100 tokens es mucho más caro computacionalmente que generar 10. Y por eso el costo de API se mide en tokens de entrada + tokens de salida.

¿Cómo se mide el rendimiento: tokens por segundo y time to first token?

Dos métricas mandan en producción. Tokens por segundo (TPS) mide cuántos tokens genera el modelo por unidad de tiempo una vez que arrancó a responder. Es el throughput puro de inferencia. Time to first token (TTFT) mide cuánto tarda en aparecer el primer token de respuesta desde que mandaste el request. Incluye todo: red, autenticación, tokenización, armado del contexto y el primer forward pass.

Un TTFT bajo hace que la respuesta se sienta instantánea. Un TPS alto hace que la respuesta completa llegue rápido. Pero no siempre van de la mano. Un modelo chico con poca latencia de red puede tener TTFT bajísimo y TPS mediocre. Uno enorme con hardware de punta puede tener TPS altísimo pero TTFT alto porque tarda en cargar la ventana de contexto. Herramientas como iamspeed.dev, que mide ambas métricas desde el navegador contra APIs reales, permiten comparar proveedores con datos concretos y no con la ficha técnica que te manda el fabricante (que suele ser el mejor caso posible en condiciones ideales, tomalo con pinzas).

¿Por qué la respuesta aparece palabra por palabra y no toda junta?

Por el streaming de tokens. Apenas el modelo genera un token, ese token se codifica y se manda al cliente por la conexión abierta. El cliente lo decodifica de vuelta a texto y lo muestra en pantalla. No hay un paso de “juntar todo y después enviar”. Por eso la experiencia es ver cómo el texto se va tipeando solo, palabra por palabra, como si alguien del otro lado estuviera escribiendo en vivo. Para más detalles técnicos, mirá en nuestra guía de modelos de lenguaje y razonamiento.

Hay APIs que permiten desactivar el streaming y recibir la respuesta completa de una sola vez. El cliente espera a que el modelo termine de generar todos los tokens, los junta, y te manda el blob completo. Esto puede ser útil para procesamiento batch o cuando necesitás validar la respuesta entera antes de mostrarla. Pero para chats, el streaming es el estándar porque la percepción de velocidad es mucho mejor: ver que algo empieza a aparecer a los 200 milisegundos es psicológicamente distinto a esperar 3 segundos y recibir todo de golpe, aunque el tiempo total sea idéntico.

¿Qué rol cumple el API gateway en toda esta cadena?

El API gateway es el guardia de seguridad y el recepcionista del backend del LLM. Autentica tu request contra la API key, verifica que tengas crédito o suscripción activa, aplica rate limiting por minuto y por día, y enruta la solicitud a una instancia del modelo que tenga capacidad disponible. Todo esto antes de que el prompt llegue a tokenizarse siquiera.

Si el gateway rechaza tu solicitud, no gastaste un solo token de cómputo. Pero también introduce latencia: cada capa de autenticación y enrutamiento suma milisegundos al TTFT. Los proveedores grandes optimizan esto con gateways distribuidos geográficamente y cachés de autenticación. Cuando usás un proveedor más chico o auto-hosteás un modelo, esta capa puede ser un cuello de botella si no está bien configurada.

Comparación: streaming vs respuesta completa

Herramientas para depurar y monitorear el ciclo

No hace falta adivinar qué está pasando en cada etapa. Tenés opciones concretas:

• iamspeed.dev: herramienta gratuita basada en navegador que mide TTFT y TPS contra APIs reales de OpenAI, Anthropic y Google. Ideal para comparar modelos antes de decidir cuál integrar.
• Logs de API del proveedor: OpenAI, Anthropic y Google ofrecen dashboards con latencia por request, tokens consumidos y errores. Si estás en producción, activá los logs de auditoría sí o sí.
• OpenTelemetry + trazas distribuidas: instrumentando tu aplicación con trazas, podés ver exactamente cuánto tarda cada etapa — desde tu servidor hasta el gateway y de vuelta — e identificar cuellos de botella en la red o en la serialización del JSON.

Errores comunes al integrar el ciclo petición-respuesta

Medir solo el tiempo total y no el TTFT

El tiempo total de respuesta puede ser aceptable pero el TTFT terrible. Si tu app muestra un spinner durante 4 segundos antes de que aparezca la primera palabra, el usuario ya se fue a otra pestaña. Medí las dos métricas por separado y optimizá el TTFT primero — reducir la latencia del gateway, usar un modelo más chico para el primer token o mantener conexiones persistentes con el backend. Complementá con como explicamos en la guía de Google.

Ignorar el manejo de errores en streaming

Con streaming, un error de red o un timeout puede cortar la respuesta a la mitad y tu app tiene que decidir qué hacer: ¿mostrar lo que llegó? ¿descartarlo y reintentar? ¿avisarle al usuario que la respuesta está incompleta? Si no pensaste estos casos, tu integración es una bomba de tiempo. Implementá reintentos con backoff exponencial y un fallback que muestre lo generado hasta el momento con un aviso claro.

Subestimar el costo de tokens de entrada largos

Meter todo el historial de conversación en cada request suena práctico. Pero si tu ventana de contexto tiene 50K tokens de historial y el prompt nuevo son solo 200 tokens, estás pagando 50.200 tokens de entrada por cada respuesta. Con tráfico real, eso escala mal. Implementá resúmenes progresivos del historial o caching semántico para no reprocesar lo mismo una y otra vez. Hay servicios de caching específicos para LLMs que almacenan los embeddings de fragmentos de conversación y evitan recomputarlos.

Preguntas Frecuentes

¿Qué es el ciclo de petición y respuesta de un LLM?

Es la secuencia de etapas que un modelo de lenguaje grande ejecuta desde que recibe un prompt hasta que devuelve la respuesta: armado del JSON de solicitud, paso por API gateway con autenticación y rate limiting, tokenización del texto de entrada, ensamblado del contexto, forward pass por capas transformer para predecir un token a la vez, y streaming de vuelta al cliente donde cada token se decodifica a texto legible. El ciclo se repite token por token hasta que el modelo emite una señal de fin de secuencia.

¿Cuánto tarda un ciclo completo de petición y respuesta?

Depende del modelo, del proveedor y de la longitud del prompt y la respuesta. El time to first token (TTFT) en APIs como OpenAI o Anthropic suele estar entre 200 ms y 1 segundo en condiciones normales. El tiempo total varía con la cantidad de tokens generados: un modelo que produce 50 tokens por segundo va a tardar 2 segundos extra para una respuesta de 100 tokens después del primer token. Con modelos más pesados o prompts muy largos (100K+ tokens), el TTFT puede estirarse a varios segundos.

¿Qué diferencia hay entre streaming y respuesta completa en un LLM?

Con streaming, el modelo envía cada token al cliente apenas lo genera, y la respuesta se muestra palabra por palabra en tiempo real. Con respuesta completa, el modelo acumula todos los tokens generados y los envía en un solo bloque al terminar. La experiencia de usuario es muy distinta: streaming da sensación de inmediatez aunque el tiempo total sea el mismo. Técnicamente, el costo de API es idéntico porque se generan los mismos tokens en ambos modos.

¿Cómo puedo medir la velocidad de respuesta de un LLM?

Con herramientas de benchmarking como iamspeed.dev, que mide tokens por segundo (TPS) y time to first token (TTFT) desde el navegador contra APIs reales. También podés instrumentar tu propia aplicación con trazas distribuidas usando OpenTelemetry para medir la latencia de cada etapa del ciclo: red, autenticación, tokenización e inferencia. Los dashboards de los proveedores (OpenAI, Anthropic, Google) incluyen métricas de latencia por request.

¿Por qué se corta la conversación cuando el historial es muy largo?

Porque la suma de tokens del system prompt, el historial de conversación y el nuevo mensaje supera la ventana de contexto del modelo. Cuando eso pasa, el sistema recorta los tokens más antiguos del historial para hacer espacio, y el modelo pierde acceso a las primeras partes de la charla. La solución es implementar resúmenes del historial o usar modelos con ventanas de contexto más grandes.

Conclusión

El ciclo de petición y respuesta de un LLM no es una caja negra mágica. Es una cadena de ingeniería concreta: JSON, gateway, tokenización, forward passes y streaming. Conocer cada etapa no es curiosidad académica — es lo que te permite elegir entre proveedores con criterio (midiendo TTFT y TPS reales, no los números del brochure), optimizar costos al no reenviar 50K tokens de historial en cada request, y diseñar una UX que no haga que el usuario se vaya mientras el modelo “piensa”.

Si estás integrando LLMs en producción, medí. Medí TTFT, medí TPS, medí latencia de gateway. Con herramientas como iamspeed.dev podés comparar proveedores en condiciones reales. Y si estás hosteando tu propia infraestructura, acordate de que el API gateway es parte del ciclo — no lo trates como un detalle administrativo. Con servicios cloud como donweb.com podés montar instancias con GPU en Latinoamérica y reducir la latencia de red para usuarios de la región, que suele ser un componente subestimado del TTFT.

Fuentes

• How Does an LLM Request and Response Cycle Work? – dev.to (QAInsights) — artículo técnico original que desglosa etapa por etapa el ciclo completo, basado en la experiencia construyendo la herramienta de benchmarking iamspeed.dev.
• How Does an LLM Request and Response Cycle Work? – QAInsights — versión extendida del análisis con diagramas y flujo documentado de cada componente del pipeline.