El enfoque de HuggingFace acierta con la utilización y se equivoca con los agentes
El artículo reciente de HuggingFace sobre capacidad de GPU infrautilizada presenta el silicio subutilizado como desperdicio. Eso es correcto para inferencia por lotes: si tu GPU está ociosa entre solicitudes, estás quemando costos fijos en rendimiento variable. Las métricas de servicio tradicionales como utilización % tienen sentido allí.
Para equipos de agentes, la historia es diferente. GPU utilización % es una métrica del lado del servicio. Para agentes, la solicitud no es un único pase hacia adelante—es una trayectoria. Un bucle ReAct de 6 pasos con 3 llamadas de herramientas pasa 60-80% de su tiempo de reloj de pared completamente fuera de la GPU: realizando solicitudes HTTP a herramientas, esperando recuperaciones de bases de datos, reensamblando indicaciones. La GPU no está ociosa entre solicitudes. Está ociosa entre pasos de una única solicitud.
Por eso un modelo más rápido—incluso un LLM de difusión que corta el tiempo de decodificación a la mitad—apenas mejora la latencia de tu agente. Ahorraste 150ms en decodificación. Tu trayectoria pasó de 8.5s a 8.35s. El cuello de botella no era la GPU. Era la solicitud de base de datos o la cola de herramientas delante de ti.
La gestión de GPU para agentes no es un problema de empaque de contenedores. Es un problema de orquestación de latencia.
Dónde vive realmente el impuesto de latencia en una ejecución de agente
Antes de comprar más capacidad, sabe dónde va el tiempo. En los bucles de agentes que hemos implementado, un desglose de trayectoria típico se ve así: ~15% decodificación, ~25% recuperación (viajes de ida y vuelta de BD vectorial o Postgres), ~40% E/S de herramientas (HTTP, autenticación, colas de proveedores), ~20% sobrecarga de orquestación (reensamblaje de indicaciones, re-tokenización, marco de orquestación). Tu experiencia puede variar. La mayoría de equipos que no miden nada no tienen visibilidad en su propio cuello de botella.
Los viajes de ida y vuelta de llamadas de herramientas son el enemigo. Un bucle ReAct que llama a una herramienta, espera la respuesta, luego decide qué hacer a continuación está serializando lo que podría ser paralelo. Los saltos de recuperación contra pgvector o una BD vectorial administrada añaden latencia por paso. El reensamblaje de indicaciones y la re-tokenización se componen en todos los pasos. Para cuando estés en el paso 5 de 6, has re-tokenizado la misma indicación del sistema de 4K tokens cuatro veces.
También está la división entre tiempo hasta el primer token (TTFT) y tiempo total de trayectoria. Un agente se preocupa por el tiempo total. No puedes optimizar TTFT si significa serializar llamadas de herramientas.
El movimiento es instrumentar esto antes de optimizar. Trazas por paso: qué modelo se ejecutó, si el caché fue un acierto, qué herramienta se llamó, tokens dentro y fuera. Trayectoria-nivel p50 y p95 de reloj de pared. Una vez que ves el desglose, las correcciones de mayor apalancamiento se hacen obvias.
El almacenamiento en caché de contexto vence al empaque de contenedores—si realmente mides aciertos
El almacenamiento en caché de indicaciones de Anthropic y los precios de entrada en caché de OpenAI son ganancias reales. Un bucle de 6 pasos lleva la misma indicación del sistema de 4K tokens y esquema de herramientas a través de todos los pasos. Almacenas ese prefijo una vez, luego lees desde caché 5 veces más. Son 4,000 tokens que no recomputes ni repagues.
El desafío es mantener tu prefijo estable. Si tu indicación del sistema cambia, tu esquema de herramientas cambia, o tus ejemplos de pocos disparos cambian, tienes un fallo de caché. Un fallo de caché en el paso 4 de un bucle de 6 pasos es caro. Repagues el prefijo completo, desperdiciando tokens y tiempo de reloj de pared. El TTL de caché de 5 minutos de Anthropic se ajusta bien a bucles de agentes—la mayoría se ejecutan dentro de esa ventana—pero la estabilidad del prefijo requiere disciplina. Almacena tu indicación del sistema y definiciones de herramientas en Redis o Postgres como la única fuente de verdad. Construye el prefijo idéntico en bytes en todos los pasos.
Luego mide cache_read_input_tokens por paso, no por solicitud. La mayoría de equipos habilitan almacenamiento en caché y asumen que funciona. Rara vez vemos equipos midiendo realmente tasas de acierto. Apunta a >70% en bucles de prefijo estable. Si estás por debajo de eso, tienes un problema de desviación de prefijo, no un problema de hardware.
Decodificación especulativa por lotes y llamadas de herramientas paralelas: los dos movimientos que la gente omite
La llamada de herramientas paralelas es la ganancia más fácil. tool_choice de OpenAI y el uso de herramientas paralelas de Anthropic permiten que el modelo decida qué herramientas llamar juntas. Tu trabajo es apoyarlo. Deja de implementar ReAct serial. Las llamadas paralelas cortan el tiempo de reloj de pared inmediatamente.
La decodificación especulativa para los pasos de razonamiento es el segundo movimiento. vLLM e Inferencia de Generación de Texto (TGI) ambos soportan modelos de borrador. Usa un modelo más pequeño para especular sobre tokens de razonamiento, luego verifica con tu modelo fronterizo. La ganancia de latencia se compone en toda una flota.
La parte más difícil es el procesamiento por lotes entre sesiones de agentes concurrentes a nivel de token, no a nivel de solicitud. Si tienes 50 agentes ejecutándose en paralelo, todos están reensamblando indicaciones, haciendo llamadas de herramientas, esperando respuestas. El procesamiento por lotes de tokens en esos 50 puede ocultar latencia de recuperación. Las claves de idempotencia y reintentos con retroceso protegen contra cargos dobles aguas abajo. Las colas de letras muertas capturan fallos de herramientas que de otro modo detendrían una trayectoria.
Cuando un flujo de trabajo—n8n, Temporal—vence a un bucle de agente es exactamente aquí. Si tu agente está principalmente orquestando pasos paralelos y esperando resultados, tienes un flujo de trabajo, no un bucle de agente. La distinción vale la pena acertar; el costo de mantenimiento es muy diferente.
Descargar a puntos finales más baratos es una decisión de latencia, no solo de costo
Enruta clasificación, reformulación, y pasos de enrutamiento a Haiku, GPT-4o-mini, o un 8B autohospedado en vLLM. Reserva tu modelo fronterizo para el único paso que realmente lo necesita. Una Puerta de Enlace de IA de Vercel o un enrutador casero te permite elegir el modelo por paso, no por solicitud.
La razón para enrutar no es solo $/token. Es latencia p50. Un modelo más pequeño implementado en Google TPU v5e (el impulsor de ingresos del producto principal de Google Cloud ahora) devuelve resultados más rápido que un modelo fronterizo en una cola de API, incluso con menor rendimiento. Establece presupuestos de latencia por paso: 200ms para enrutamiento, 800ms para síntesis de recuperación, 3s para el paso de razonamiento. Cumple esos presupuestos con el modelo más pequeño que pueda.
La economía se compone en toda una flota. Ahorra 400ms por trayectoria × 2 millones de trayectorias por día = 800,000 segundos de GPU ahorrados por día. Eso es equivalente a dejar docenas de A100s ociosos. Excepto que no los estás dejando ociosos. Estás enrutando más inteligentemente.
Qué instrumentar antes de comprar más GPUs
Dedica una tarde a esto antes de negociar capacidad reservada. Añade tramos por paso en OpenTelemetry con modelo, cache_hit, tool_name, tokens_in y tokens_out. Trayectoria-nivel p50 y p95 de reloj de pared, no latencia de solicitud. Tasa de acierto de caché como un SLO de primera clase.
Rastrea tasa de error de llamada de herramientas y profundidad de cola de letras muertas. Costo por trayectoria exitosa, no costo por token. Cuando puedas responder "en un bucle de 4 pasos, ¿cuál es mi p95 de reloj de pared?" y "¿cuántos tokens leyó el paso 1 desde caché versus el paso 5?", sabrás si tu problema es silicio u orquestación.
Los equipos atrapados por encima de 8s p95 en un bucle de 4 pasos generalmente tienen un error de almacenamiento en caché o serialización, no un problema de hardware. Eso es cuando comunicarse. Antes de eso, arregla la estabilidad del prefijo, habilita llamadas de herramientas paralelas, y enruta pasos pequeños a modelos pequeños.
El siguiente movimiento: compara cache_read_input_tokens en los pasos 1 y N de la misma trayectoria. Ese único gráfico te dice si tu problema es física o fontanería.