Dónde vive realmente la latencia del agente
Hemos pasado suficiente tiempo en trazas de producción para decirlo claramente: la velocidad de decodificación casi nunca es tu cuello de botella en un sistema de agentes. Así es como se ve una cascada de latencia p50 real:
- Incrustación vectorial: 80ms
- Recuperación + rerank (Pinecone/pgvector): 600ms
- Llamada LLM (incluido RTT de red a Anthropic/OpenAI): 80ms + 400ms decodificación = 480ms
- Ejecución de herramientas (HTTP saliente, consultas de base de datos, APIs externas): 900ms
- Sobrecarga de orquestación (serialización, gestión de estado, reintentos): 500ms
- Total: ~2,4 segundos
La decodificación es aproximadamente el 17% del tiempo de pared. La recuperación domina. Las llamadas de herramientas dominan. El viaje de ida y vuelta de la red a tu punto final de inferencia a menudo cuesta 80–200ms antes de que llegue un solo token.
Los puntos de referencia de rendimiento (tokens por segundo) miden algo diferente de lo que importa para los agentes: tiempo para salida útil. Un modelo de difusión podría generar una respuesta completa en 600ms donde un modelo autorregresivo tarda 1,2 segundos. Pero si la recuperación ya tardó 600ms y la llamada de herramientas está pendiente, tu usuario no experimenta ninguna diferencia. La historia de latencia de cola es peor: los tiempos de espera de herramientas y los inicios en frío de Lambda superan cualquier mejora de decodificador en p99.
Lo que los LLMs de difusión realmente cambian sobre la inferencia
Los modelos de lenguaje basados en difusión funcionan de manera suficientemente diferente que necesitas un modelo mental claro antes de implementarlos en producción.
Los modelos autorregresivos generan tokens de izquierda a derecha. Cada token se condiciona en todos los tokens anteriores. Obtienes un token, luego solicitas el siguiente, en un bucle cerrado. Los modelos de difusión utilizan difusión hacia adelante más muestreo inverso: los tokens emergen en paralelo en múltiples pasos de desruido, refinados iterativamente hacia una salida final. No hay un flujo natural token por token.
Nemotron-Labs posiciona esto como un tiempo de pared más rápido para respuestas completas. Tienen razón sobre las matemáticas. Pero "más rápido" oculta un cambio arquitectónico real: o materializas toda la salida de una vez, o transmites pasadas de refinamiento de grueso a fino en lugar de tokens. No hay término medio. Eso cambia todo sobre cómo lo implementas.
El perfil de alucinación también cambia. Los modelos autorregresivos confabulan cuando el acondicionamiento de tokens anteriores sale mal. Los modelos de difusión refinan toda la salida conjuntamente, lo que puede reducir algunos errores pero introduce modos de fallo diferentes — toda la muestra puede divergir si los pasos de desruido temprano se desvían. Los patrones de confabulación difieren de maneras que aún no hemos caracterizado completamente.
La UX de transmisión se rompe cuando no hay nada que transmitir
La mayoría de las interfaces frontales de agentes se basan en eventos enviados por servidor (SSE) o transmisión WebSocket para sentirse ágiles. Vercel AI SDK, stream=true de OpenAI, message_stream de Anthropic — todos asumen emisión de tokens autorregresiva.
La difusión rompe este patrón. No puedes transmitir tokens que no existen hasta que termina el muestreo inverso. Tus opciones son: transmitir pasadas de desruido (salida borrador → refinada → final) o renunciar a la transmisión y renderizar una vez.
La compensación de UX es real. La latencia percibida importa más que la latencia real en el chat. Los usuarios toleran un spinner de 1 segundo antes de que aparezca la salida, luego ven tokens transmitirse. Con difusión, o muestras un esqueleto y un salto de corte de 600ms a la respuesta completa, o transmites pasadas de refinamiento y esperas que sean visualmente interesantes para no parecer un estancamiento. Ninguno coincide con la UX de transmisión de tokens que los usuarios esperan.
La detección de llamadas de herramientas también se vuelve más difícil. En un flujo autorregresivo transmitido, puedes interrumpir tan pronto como veas un token de llamada de herramienta. La difusión te da toda la salida estructurada de una vez. Si el modelo cometió un error en la llamada de herramienta, lo descubres después de que se completa el muestreo, no a mitad de la transmisión.
El punto de control y el bucle de orquestación necesitan una reescritura
Los bucles de agentes estilo ReAct asumen que puedes interrumpir la generación a mitad de camino en un token de llamada de herramienta, ejecutar la herramienta, alimentar los resultados de vuelta y reanudar desde allí. La difusión fuerza un modelo de punto de control diferente.
Con generación autorregresiva, la granularidad del punto de control es por token. Puedes pausar, llamar a una herramienta y reanudar. Con difusión, la unidad es la pasada de desruido completa o la muestra completa. Eso significa:
- La estrategia de reintento cambia: Re-muestrear un modelo de difusión es más barato por llamada, pero no puedes reanudar desde una decodificación parcial. Re-muestreas todo o pierdes trabajo.
- Las claves de idempotencia importan más: Las llamadas de herramientas de salidas de difusión necesitan deduplicación más fuerte porque las re-ejecuciones son atómicas.
- El almacenamiento de estado cambia: Postgres y Redis ahora contienen salidas intermedias completas, no estado token por token. Las colas de letra muerta para trabajos de muestreo inverso atascados se vuelven necesarias.
- Enrutamiento de modelos: Considera usar un modelo autorregresivo barato (Claude Haiku) para turnos de transmisión orientados al usuario y difusión para pasos de planificación silenciosos en el backend donde la transmisión no importa.
Aquí es donde las estrategias de enrutamiento de modelos dan resultados. Ya no estás eligiendo un modelo para todos los turnos del agente; estás haciendo coincidir curvas de inferencia con casos de uso.
Dónde la difusión realmente gana
No estamos diciendo que la difusión sea incorrecta. Es genuinamente útil en contextos específicos.
Resumen por lotes, reescritura en tiempo de incrustación, generación de evaluación sin conexión — ninguno de estos necesita transmisión. Salida JSON estructurada donde una respuesta parcial es inútil de todas formas: la difusión brilla. Pasos de planificación en flujos de múltiples turnos donde un plan completo de 600ms supera un plan transmitido de 1,2 segundos: elige difusión.
Las matemáticas de costos se componen. Si el desruido de difusión reduce tu p50 en un 40%, esa ventaja se escala en bucles de agentes de 8 pasos. Los turnos silenciosos del backend (investigación, planificación, calificación) son más baratos y rápidos con difusión. El turno orientado al usuario se mantiene con GPT-4o o Claude.
Este es el patrón que vemos en producción: usa difusión para la columna vertebral del flujo de trabajo, autorregresivo para la interfaz de chat.
Cómo evaluar realmente un modelo de difusión para producción
No ejecutes puntos de referencia de proveedores. Construye un arnés que enrute la misma carga de trabajo del agente a backends autorregresivos y de difusión, mide de extremo a extremo.
Rastrea estas métricas: tiempo para primera salida útil (no tokens/seg), latencia p50/p95/p99, tasa de éxito de tareas y costo por finalización de tarea exitosa (no $/millones de tokens). Ejecuta pruebas de alucinación en tareas fundamentadas en recuperación — los patrones de confabulación cambian con el muestreo de difusión. Verifica la adherencia del esquema de llamadas de herramientas en modo de salida estructurada. Implementa en sombra en el 5% del tráfico durante una semana antes de comprometerte.
Luego pregunta: ¿la curva de inferencia de este modelo coincide con nuestro presupuesto de latencia y UX de transmisión? Si la recuperación ya es tu cuello de botella, la decodificación más rápida es invisible. Si necesitas transmisión token por token, la difusión rompe tu frontend. Sé honesto sobre qué problema estás resolviendo.
Si estás decidiendo si la difusión se ajusta a tu pila de agentes — o simplemente quieres un segundo par de ojos en una cascada de latencia — habla con nosotros en /contact. Hemos implementado ambas arquitecturas y tenemos opiniones.