Resumen Técnico: Observación, No Predicción – Programación Desagregada a Nivel de Conversación para el Servicio de Agentes

1. Declaración del Problema

Los sistemas actuales de servicio de Modelos de Lenguaje de Gran Escala (LLM) están diseñados en torno al "request" (petición) como la unidad atómica de programación, un modelo adecuado para la inferencia de un solo paso donde un prompt se realiza en el prefill y se decodifica de una sola vez. Sin embargo, las cargas de trabajo de agentes rompen este contrato. La tarea de un agente se resuelve mediante una secuencia de llamadas de inferencia dependientes intercaladas con el uso de herramientas, retroalimentación del entorno y acumulación de estado.

Este cambio crea un desajuste entre la programación y el valor:

• Vista del Sistema: Optimiza la latencia por turno (Time-to-First-Token, TTFT) para cada turno intermedio, muchos de los cuales son llamadas a herramientas internas invisibles para el usuario.
• Vista del Usuario: Espera por la salida final y externamente significativa de la conversación. La métrica relevante es el Time-to-First-Effective-Token (TTFET) —la latencia hasta el primer token de progreso genuino visible para el usuario.

Los sistemas multi-turno actuales intentan optimizar esto decidiendo, turno a turno, si desagregar la fase de prefill (limitada por cómputo) de la fase de decode (limitada por memoria). Para tomar esta decisión, los programadores deben predecir cantidades no observables: cuántos tokens decodificará un turno, si llamará a una herramienta y cuánto crecerá el caché KV. Esta dependencia de la predicción introduce una fragilidad estructural; cualquier error de predicción conduce a un enrutamiento subóptimo, retrasos en las colas y una eficiencia energética degradada.

2. Metodología: ConServe

El artículo presenta ConServe, un sistema que eleva la unidad de programación del turno a la conversación. La idea central es que, si bien las conversaciones de agentes exhiben irregularidad a nivel de turno, poseen una estructura estable de dos fases a nivel de conversación:

1. Fase 1 (Limitada por Cómputo): Un único y pesado prefill de la descripción de la tarea inicial larga (turno 1).
2. Fase 2 (Limitada por Memoria): Una cola larga que consiste en el primer decode y todos los turnos subsiguientes, que involucran append-prefills cortos y decodificación sobre un caché KV acumulado.

Principios de Diseño Clave

• Observación sobre Predicción: ConServe elimina la necesidad de predecir resultados a nivel de turno (por ejemplo, futuras longitudes de decode o comportamientos de herramientas). Las decisiones de colocación se basan enteramente en el estado directamente observable:
  • El recuento de tokens de entrada del prompt del primer turno (determina la carga de prefill).
  • La ocupación actual del caché KV de las réplicas de decoder (determina la carga limitada por memoria).
• Anclaje a Nivel de Conversación (Conversation-Level Pinning):
  • El prefill del primer turno se enruta a un nodo de prefiller dedicado de alto rendimiento.
  • El caché KV resultante se transfiere exactamente una vez a una réplica de decoder seleccionada.
  • La conversación se ancla (pinning) a ese decoder específico durante toda su vida útil. Todos los turnos subsiguientes (append-prefills y decodes) se ejecutan localmente en ese decoder, reutilizando el caché KV sin más transferencias de red.
• Programación Reactiva: El programador admite nuevas conversaciones basándose en la capacidad actual del sistema (tasa de entrada de prefill frente al throughput del prefiller; ocupación total de KV frente a la capacidad del pool de decoders). No migra las conversaciones una vez colocadas.
• Mapeo Heterogéneo: La estructura de dos fases mapea naturalmente a niveles de GPU heterogéneos. El prefill del primer turno (limitado por cómputo) se ejecuta en GPUs de alta potencia, mientras que la cola limitada por memoria se ejecuta en GPUs de menor potencia con suficiente ancho de banda de memoria, ya que el rendimiento de la cola está limitado por la memoria más que por el cómputo bruto.

3. Contribuciones Clave

1. Paradigma de Programación a Nivel de Conversación: El artículo identifica que la unidad de programación (el turno) es la fuente de fragilidad en el servicio de agentes. Al cambiar a la conversación, el sistema reemplaza la predicción por el estado observable, eliminando la necesidad de modelos de costo aprendidos o predictores complejos.
2. Sistema ConServe: Una instanciación mínima de este principio que enruta los prefills del primer turno a GPUs de alta potencia, transfiere el estado KV una vez y ancla la conversación a un único decoder. Optimiza el TTFET y la eficiencia energética sin modelos aprendidos.
3. Demostración Empírica de Fragilidad Estructural: Los autores muestran que la programación por turno (como en las líneas base como AMPD) sufre linealmente de errores de predicción. A medida que la tasa de error aumenta, las violaciones de SLO y la ineficiencia energética se degradan linealmente. En contraste, el rendimiento de ConServe permanece constante por construcción porque no toma decisiones de enrutamiento por turno.
4. Eficiencia Energética mediante Heterogeneidad: El artículo demuestra que la división de fases a nivel de conversación permite la asignación de GPUs por niveles sin maquinaria adicional, mejorando significativamente la eficiencia energética (tokens por Joule) mientras mantiene el rendimiento de latencia.

4. Resultados Experimentales

Evaluado en trazas de agentes (SWE-bench) utilizando un modelo Qwen3-0.6B en un clúster NVIDIA A40, ConServe fue comparado contra líneas base colocalizadas, totalmente desagregadas y basadas en predicción por turno (AMPD).

• Latencia (TTFET): ConServe reduce el p95 TTFET en un 51.08% en comparación con la línea base de predicción por turno (AMPD). Logra esto evitando los retrasos de cola causados por turnos mal enrutados en el prefiller.
• Adherencia a SLO: ConServe mantiene cero violaciones de SLO en todas las tasas de solicitud probadas, incluyendo los puntos de saturación. Las líneas base fallan en la saturación: los sistemas colocalizados sufren de contención entre prefill y decode, y los sistemas por turno acumulan errores de enrutamiento.
• Eficiencia Energética:
  • En entornos homogéneos, ConServe mejora la eficiencia energética en un 7.51% sobre la línea base por turno.
  • En entornos heterogéneos (prefiller de 300W, decoders de 200W), ConServe logra una ganancia adicional del 22.75% en eficiencia energética (tokens por Joule) manteniendo el rendimiento de latencia. Esto se debe a que la cola limitada por memoria es insensible a la reducción de la potencia de cómputo de las GPUs limitadas.
• Robustez: A diferencia de AMPD, cuyo rendimiento se degrada linealmente con las tasas de error de predicción (por ejemplo, un error del 10% conduce a violaciones significativas de SLO), ConServe es inmune a tales errores ya que se basa en el estado observable.

5. Significado y Reivindicaciones

El artículo sostiene que la abstracción fundamental para el servicio de agentes es la conversación, no el turno. Al reconocer la estructura estable de dos fases de las cargas de trabajo de agentes, ConServe demuestra que:

• La colocación debe ser reactiva, no predictiva. Confiar en el estado observable (longitud de entrada, ocupación de KV) es suficiente y más robusto que predecir futuros comportamientos de turno.
• La granularidad de la programación dicta la estabilidad del sistema. La fragilidad de los sistemas multi-turno actuales no es una propiedad inherente de la carga de trabajo, sino una consecuencia de programar al nivel del turno.
• La eficiencia energética es un corolario natural. La división de fases a nivel de conversación permite un mapeo heterogéneo eficiente sin una orquestación compleja, gastando cómputo de alta potencia solo donde es necesario (el prefill inicial) y utilizando hardware de menor potencia para la cola limitada por memoria.

Los autores presentan ConServe no como un sistema complejo y aprendido, sino como una "instanciación mínima" de un paradigma basado en principios que alinea la optimización del sistema con el valor real para el usuario (la finalización de la conversación) en lugar de métricas intermedias del sistema (latencia por turno).