Tráfico de agentes más rápido y barato: tres configuraciones de serving detrás de los resultados de AgentX de vLLM

El serving de agentes intercambia la reutilización de caché por la localidad de rank. Si cada turno repite el contexto anterior, el trabajo de prefill crece con el número de turnos; si la caché sobrevive, solo crece con los tokens nuevos. Esa aritmética decide la latencia y el costo antes que la elección del modelo. En AgentX, vLLM reportó hasta 130,000 tokens totales por segundo de GPU en DeepSeek V4 Pro y hasta 376 tokens por segundo de interactividad en MiniMax M3. vLLM reportó una ventaja de costo de serving de 14.6x a 106x frente a la tarifa de la API de Opus 5 en DeepSeek V4 Pro, MiniMax M3 y Kimi K3.

Aplicá tres cambios de serving:

• Habilitá la retención de estado KV/lineal por intervalos en los límites de turno.
• Usá identificadores de sesión o subagente para dirigir las solicitudes al rank que ya retiene su caché.
• Escalá prefill y decode por separado contra un objetivo de costo por token.

El estado por turno reduce el prefill repetido

Habilitá la retención por intervalos en los límites de turno. La política de retención basada en intervalos de vLLM preserva las cachés de fin de prompt o los estados lineales en cada turno para su reutilización agéntica posterior. Un agente de múltiples turnos puede entonces reutilizar la cola del prompt anterior en lugar de reconstruirla, lo que reduce los lotes de prefill y la rotación de memoria. La expulsión por defecto es el modo de fallo: bajo carga, el estado del último turno desaparece antes de que llegue la siguiente llamada de subagente, y el turno siguiente paga de nuevo el precio completo del prefill.

Guardá el estado donde los turnos realmente terminan. Una llamada a herramienta, una respuesta del usuario o una transferencia a un subagente pueden terminar un turno. Tratar cada llamada como un nuevo prompt desperdicia la oportunidad de reutilización. Marcá el fin del prompt, no la conversación completa, para que la siguiente llamada parta del último punto estable.

La fijación de sesión reduce la perturbación de caché

Enrutá por ID de sesión o subagente al rank que ya retiene la caché. En despliegues de atención en paralelo de datos, el tráfico puede dirigirse al rank que retiene la caché relevante mediante el identificador de sesión o subagente, reduciendo la perturbación repetida de caché. Una sesión debería llegar a un solo rank a lo largo de los turnos, con menos expulsiones entre llamadas. Fijar por dirección de red o por usuario deja la caché en el rank equivocado y reinicia el thrashing de la caché de prefijo.

Los subagentes son claves de caché separadas, por lo que un planificador, un llamador de herramientas y un verificador deberían llevar cada uno su propio ID de enrutamiento. Eso mantiene la caché donde la siguiente solicitud la necesita.

Tratá el enrutamiento consciente de sesión como una decisión de balanceo de carga. El enrutador necesita una clave estable que sobreviva a las llamadas a herramientas y a los reintentos. Cuando la clave cambia, cambia el rank, y el beneficio de caché desaparece. Mantené la clave vinculada a la ejecución lógica del agente, no a la conexión de transporte.

La separación prefill-decode controla el costo

Escalá prefill y decode por separado contra un objetivo de costo por token. Las cifras de AgentX al inicio son el marco: los nodos de prefill absorben prompts largos mientras los nodos de decode mantienen los flujos de tokens estables, y la flota se ajusta a un costo objetivo por token. La separación importa porque prefill y decode tensionan partes diferentes del stack. El prefill es trabajo paralelo; el decode es una larga secuencia de salidas pequeñas. Escalarlos juntos desperdicia capacidad en el lado que no es el cuello de botella.

Fijá el objetivo de costo por token antes de escalar. El objetivo debería provenir de la mezcla de tráfico, no de una sola ejecución de benchmark. Una ejecución de agente con prompt largo y una de chat corto alcanzarán proporciones diferentes de prefill y decode. Si no se alcanza el objetivo, cambiá la configuración de serving antes que el modelo. Mantené la decisión vinculada al stack de serving.

Seguí los cambios upstream que mueven las cifras

Verificá la lista de cambios upstream antes de copiar una configuración. SemiAnalysis vinculó más de 50 pull requests upstream a trabajo de optimización relacionado con AgentX. Una revisión de serving debería listar qué cambios de caché, enrutamiento y kernel movieron las cifras de latencia y costo. Las cargas de trabajo de agentes exponen bugs de serving que el tráfico de chat oculta. Configuraciones que funcionan para solicitudes de un solo turno pueden fallar cuando una sesión regresa después de una llamada a herramienta. Vinculá cada cambio a la carga de trabajo que corrige, y luego reejecutá la misma traza del agente después del cambio.

Mantené la misma traza del agente a lo largo de los cambios. La traza debería incluir el orden de turnos, las llamadas a herramientas y los límites de subagente. Cambiar la traza también cambia la comparación. Usá la traza para ver si una corrección de enrutamiento o caché movió la cifra, no si un modelo nuevo cambió la carga de trabajo.