OpenAI advierte que la inferencia agéntica de LLM convierte una solicitud del usuario en varias llamadas al modelo, lo que aumenta los costos y la latencia, mientras los laboratorios reducen la latencia de los modelos casi a la mitad y recortan los costos un 83%.

La inferencia agéntica de LLM consiste en hacer que un modelo de lenguaje realice una tarea de varios pasos con herramientas, reintentos y memoria, en lugar de dar una sola respuesta; así, una solicitud del usuario se convierte en varias llamadas al modelo. La evidencia publicada muestra ahora que los laboratorios están reduciendo la latencia de los modelos casi a la mitad, recortando los costos un 83% en algunos niveles de API y rediseñando los sistemas de servicio para que estas cadenas más largas puedan usarse en producción.

En resumen

• Los sistemas con agentes no son simplemente «chat, pero más». Multiplican los tokens, los tiempos de espera y los puntos de fallo, porque una sola tarea suele convertirse en un plan, varias llamadas a herramientas, una o más comprobaciones y, al menos, una respuesta final.

• El mayor factor de costo suele ser la decodificación, la etapa en la que el modelo genera tokens uno por uno. Por eso, el ancho de banda de memoria, la política de procesamiento por lotes y la longitud de salida importan tanto como la potencia de cálculo bruta.

• La configuración de producción fiable más económica suele combinar varios modelos: modelos más pequeños para el enrutamiento, la extracción y la verificación; modelos más grandes solo para los pasos difíciles; y una telemetría rigurosa para detectar reintentos, tiempos de espera en cola y errores de herramientas antes de que se disparen las facturas.

Por qué la inferencia de LLM con agentes es diferente

Una llamada normal a un chatbot es sencilla: se envía una instrucción y se recibe una respuesta. En cambio, la inferencia de LLM con agentes requiere que el modelo planifique, decida qué herramienta usar, llame a un sistema de búsqueda o a una base de datos, lea los resultados, revise su plan y solo entonces responda al usuario, lo que multiplica las llamadas al modelo y las interacciones con herramientas.

Esa estructura adicional multiplica los costos. La llamada directa al modelo es solo una parte de la factura. El tiempo de espera de las herramientas, los tokens que se usan para devolver al modelo la descripción de sus resultados, las llamadas adicionales cuando el agente verifica su propio trabajo y los reintentos cuando falla un paso aumentan tanto el costo como la latencia de cola.

El artículo sobre razonamiento dinámico concluyó que las distribuciones de latencia de extremo a extremo de un sistema de agentes al estilo ReAct eran muy diferentes de las de un servicio convencional sin agentes. En otras palabras, la cola de la distribución se alarga. Un usuario puede recibir rápidamente una respuesta mediana, pero las solicitudes más lentas tardan mucho más.

La consecuencia práctica es sencilla: la unidad de trabajo ya no es una sola solicitud, sino un flujo de trabajo. El análisis de Fathom sugiere que cualquier equipo que mida únicamente el costo promedio por llamada al modelo podría estar pasando por alto la verdadera economía de la inferencia de LLM con agentes.

El presupuesto de latencia se rompe en los pasos intermedios

La mayoría de la gente piensa que la latencia equivale a la velocidad del modelo. En producción, la latencia es un presupuesto con varios componentes: enrutamiento de solicitudes, espera en cola, construcción de instrucciones, prellenado, decodificación, llamadas a herramientas, comprobaciones de seguridad y posprocesamiento. Los agentes son más lentos porque añaden más pasos intermedios, no solo porque el modelo en sí sea más lento.

OpenAI afirmó en su guía sobre latencia que las principales palancas son la elección del modelo y la cantidad de tokens generados. Si un agente produce una larga cadena de pensamientos, esquemas de herramientas, JSON, resultados de herramientas y una explicación final, la longitud de salida encarece tanto el tiempo como el gasto.

A menudo, los equipos optimizan la redacción de las instrucciones, pero pasan por alto la orquestación. Una instrucción optimizada no puede salvar un sistema que espera 400 milisegundos por el enrutamiento, 800 milisegundos por una herramienta de búsqueda, 1 segundo para que el modelo lea los resultados de la herramienta y otro segundo para que el modelo verificador compruebe la respuesta.

En muchos sistemas reales, el modelo no es la única fuente de demora. Es solo la parte más visible, y ese costo adicional de orquestación se refleja directamente en los costos de la inferencia de LLM con agentes.

Divide el tiempo de espera del usuario en dos objetivos de servicio. La latencia hasta el primer token indica lo rápido que el sistema parece estar activo. El tiempo hasta la respuesta final es lo que les importa a los usuarios cuando la tarea requiere un resultado terminado. En atención al cliente o asistencia para programar, la transmisión en continuo puede disimular parte de la demora. En los agentes de navegador o los bots de flujo de trabajo que deben actuar antes de hablar, ayuda menos. Estas compensaciones son fundamentales para diseñar la inferencia de LLM con agentes.

Si una solicitud del usuario activa cuatro llamadas al modelo, una mejora del 15 % en el modelo no supone una mejora del 15 % en el sistema, a menos que ese modelo domine todo el proceso. OpenAI informó que GPT-4.1 igualó o superó a GPT-4o en las evaluaciones de inteligencia, a la vez que redujo la latencia casi a la mitad y el costo un 83 %. Esto demuestra cómo las mejoras simultáneas de velocidad y precio pueden cambiar las decisiones arquitectónicas para la inferencia de LLM con agentes.

La decodificación es la parte costosa

Dos etapas dominan la inferencia con transformadores: el prellenado (cuando el modelo lee la instrucción y crea su estado interno) y la decodificación (cuando genera la salida token por token). Los agentes suelen perjudicarse durante la decodificación, porque cada frase adicional de planificación, argumento de herramienta y explicación final prolonga la fase más lenta.

La decodificación suele estar limitada por la memoria. A menudo, el chip pasa más tiempo moviendo los pesos del modelo y los datos de la caché de clave-valor que realizando cálculos brutos. Por eso, un mayor ancho de banda de memoria ayuda tanto durante la generación y la publicidad de hardware centrada únicamente en el rendimiento máximo de cálculo puede inducir a error a los compradores. AMD señaló que la memoria de alto ancho de banda es importante para la fase de decodificación.

Los agentes penalizan la falta de disciplina en las respuestas. Una traza de razonamiento oculta que se convierte en salida o se serializa en instrucciones posteriores genera costos dos veces: primero al escribirla y luego cuando las llamadas posteriores la leen. Ese efecto aumenta el costo operativo de la inferencia de LLM con agentes.

La misma lógica explica por qué los modelos más pequeños pueden superar a los más grandes en la economía de los flujos de trabajo, aunque obtengan peores resultados en las pruebas de rendimiento más destacadas. El artículo sobre modelos de lenguaje pequeños sostenía que estos se adaptan bien a muchas subtareas de agentes. El enrutamiento, la extracción, el resumen, la reparación de esquemas y las verificaciones sencillas suelen ser tareas específicas para las que un modelo de primer nivel es excesivo.

En la inferencia de LLM con agentes, elegir el modelo adecuado para cada subtarea suele importar más que seleccionar un único modelo que sea el mejor para todo. Una fórmula aproximada puede servir: el costo total de una solicitud de un agente es…

Costo total = suma del costo en tokens de todas las llamadas a modelos + desperdicio de cómputo por esperas inactivas + costo de las llamadas a herramientas + costo de los reintentos + gastos generales de seguridad y registro. La mayoría de los equipos solo ve el primer componente, porque aparece en la factura de la API.

Quienes alojan sus propios modelos vigilan la ocupación de la GPU, pero podrían no darse cuenta de que una herramienta lenta deja el acelerador infrautilizado mientras el usuario sigue esperando. Una buena economía de agentes implica usar los tokens eficientemente y mantener el sistema ocupado en vez de dejarlo inactivo.

Las decisiones de hardware establecen el límite

El hardware no lo determina todo, pero establece los límites externos de cuánto puede abaratarse y acelerarse un servicio. El hardware inadecuado puede atrapar a un equipo en una economía desfavorable mucho antes de que se optimicen las instrucciones o la orquestación, sobre todo en cargas de trabajo de inferencia de LLM con agentes dominadas por la decodificación y con tráfico irregular.

Nvidia afirmó que Transformer Engine del H100 podía aumentar hasta 30 veces el rendimiento de inferencia —es decir, la cantidad de trabajo realizado por segundo— en aplicaciones de baja latencia. Esa cifra destacada depende de la carga de trabajo, y los equipos no deberían suponer que se aplica directamente a su infraestructura. Pero muestra por qué las generaciones de hardware pueden cambiar la economía de forma repentina, en lugar de hacerlo gradualmente.

Nvidia también informó de mejores resultados de inferencia con H100, L4 y Orin en MLPerf. La lección para producción es que los distintos trabajos requieren distintos tipos de silicio. Los componentes de clase L4 pueden ser adecuados para cargas de trabajo más livianas o sensibles al costo, mientras que los de clase H100 son apropiados para objetivos estrictos de latencia, modelos grandes o alta concurrencia.

La guía de servicio para H100 y TensorRT-LLM reveló una compensación clave. Se puede optimizar los servidores para el rendimiento (más trabajo por segundo) o para la latencia (respuestas individuales más rápidas). El procesamiento por lotes agresivo reduce el costo por unidad, pero aumenta los tiempos de espera. Los lotes pequeños mantienen la capacidad de respuesta, pero reducen la utilización del hardware. Esta compensación es más marcada en la inferencia de LLM con agentes, porque los patrones de llegada son irregulares y muchas llamadas posteriores son breves e impredecibles.

El hardware alternativo importa sobre todo cuando la carga de trabajo es específica o está limitada por el consumo de energía. Hugging Face publicó que AWS Inferentia2 se centra en el rendimiento, la latencia, el rendimiento por vatio y la escala. AMD anunció opciones de particionamiento de GPU, y afirmó que su línea de FPGA con HBM ofrece un ancho de banda de memoria de 460 Gb/s. Estas opciones destacan en implementaciones especializadas, pero suelen importar menos en los servicios de inferencia de LLM con agentes de propósito general.

El aspecto económico clave es concreto en la inferencia de LLM con agentes. Cuando predomina la decodificación, el ancho de banda de memoria y el comportamiento de la caché afectan directamente el rendimiento de generación y el costo. Cuando las cargas de trabajo son irregulares y constan de varios pasos, importan funciones como el particionamiento, el control detallado de las colas y la programación optimizada para la latencia.

Y, cuando se opera a gran escala, el rendimiento por vatio se convierte en una partida real, porque los costos de energía se acumulan durante la inferencia continua. Estas son las palancas de producción que influyen en la economía de los agentes más que las tablas comparativas de proveedores.

El diseño de modelos ahora supera a la escala bruta

La información reciente de los proveedores sugiere que las mayores mejoras provienen de una integración más estrecha entre el modelo y el sistema de servicio, no solo de escalar un único modelo. OpenAI afirmó que servir GPT-5.5 con la latencia de GPT-5.4 exigió replantear la inferencia como un sistema integrado, y escribió que GPT-5.6 combinó capacidades de vanguardia con una pila de menor latencia, más capacidad y menores costos para los usuarios.

Esas declaraciones muestran que ahora los modelos se evalúan, en parte, por lo barato que resulta servirlos, un cambio importante para la inferencia de LLM con agentes. Si un modelo mantiene su calidad y se vuelve mucho más rápido, el operador puede trasladar los ahorros a los usuarios mediante precios más bajos, reinvertirlos en más uso de herramientas y autocontrol, o ampliar sus márgenes.

Para los compradores empresariales, la opción intermedia —usar los ahorros para financiar una segunda pasada de validación— puede mejorar la fiabilidad más de lo que reduce los costos, especialmente en las canalizaciones de inferencia de LLM con agentes. Los modelos de pesos abiertos añaden otra dimensión. OpenAI presentó gpt-oss-120b y gpt-oss-20b como opciones de pesos abiertos y menor costo. Para los operadores con tráfico estable, cargas de trabajo predecibles y equipos de infraestructura sólidos, los pesos abiertos pueden mejorar la economía al evitar las tarifas por token de las API.

Pero trasladan el riesgo a la empresa. Ahora el equipo es responsable del tiempo de actividad, las actualizaciones, los errores del kernel, el ajuste de memoria y la seguridad, factores que afectan la fiabilidad y el costo de la inferencia de LLM con agentes.

El umbral para decidir si alojar los modelos por cuenta propia está cambiando. A medida que mejora la eficiencia de los modelos, se necesita una carga de trabajo menor para justificar la gestión de la infraestructura de servicio. Los productos con agentes que realizan tareas internas estables, como extraer datos de facturas o revisar código, podrían llegar a ese umbral antes que las aplicaciones de chat para consumidores, cuya demanda es muy variable.

Figura o afirmación Por qué importa en producción Fuente Aumento de hasta 30 veces en el rendimiento de inferencia para aplicaciones de baja latencia con Transformer Engine del H100 Muestra cuánto puede cambiar la economía del servicio con modificaciones de hardware y kernel Blog de Nvidia sobre H100 GPT-4.1 redujo la latencia casi a la mitad y el costo un 83 % frente a GPT-4o Ejemplo de cómo las mejoras simultáneas en precio y velocidad pueden cambiar el diseño de productos Publicación de OpenAI sobre GPT-4.1 GPT-5.5 se sirve con la latencia de GPT-5.4 Indica un rediseño del servicio a nivel de sistema, no solo un mejor modelo base Publicación de OpenAI sobre GPT-5.5 gpt-oss se lanzó en tamaños de 120B y 20B Señala una mayor variedad de opciones para dirigir tareas pequeñas a modelos más económicos Publicación de OpenAI sobre gpt-oss La línea de FPGA de AMD anuncia un ancho de banda HBM de 460 Gb/s Reafirma que el movimiento de memoria es fundamental en las cargas de trabajo dominadas por la decodificación Página de FPGA de AMD

También puedes leer: OpenAI refuerza la seguridad de su entrenamiento de IA mientras copiar modelos robados cuesta casi cero

El software de servicio determina la utilización

Una vez comprado el hardware y elegido el modelo, el software de servicio suele determinar si la operación es rentable en la inferencia de LLM con agentes. El procesamiento por lotes, la reutilización de la caché de clave-valor, la paginación de memoria y la programación de solicitudes determinan la utilización. vLLM se describió como un motor de inferencia y servicio capaz de gestionar muchas solicitudes y usar la memoria eficientemente.

Su crecimiento refleja la realidad de la industria: el modelo por sí solo no basta. Los operadores necesitan software que agrupe muchas solicitudes en el mismo hardware sin incumplir los objetivos de latencia.

Para la inferencia de LLM con agentes, eso significa gestionar ráfagas breves, longitudes de salida variadas y muchas sesiones que se reanudan después de llamadas a herramientas. La decodificación especulativa es un tema muy comentado en las pilas de servicio. Un modelo preliminar más pequeño predice varios de los siguientes tokens y un modelo más grande los verifica para reducir el tiempo de generación.

En la práctica, el artículo sobre procesamiento por lotes para agentes concluyó que la decodificación especulativa puede perjudicar la inferencia por lotes en cargas de trabajo con agentes e incluso ser más lenta que la decodificación autorregresiva normal. Esto se debe a que el tráfico de los agentes es irregular y las herramientas interrumpen el modelo con frecuencia, lo que afecta el rendimiento de la inferencia de LLM con agentes.

La política de colas se convierte en una cuestión económica. Si una capa de servicio espera demasiado para formar lotes más grandes, los costos bajan, pero aumenta la demora para los usuarios. Si atiende cada solicitud de inmediato, la demora disminuye, pero parte del hardware queda inactivo.

En la inferencia de LLM con agentes, una buena programación suele implicar clasificar las solicitudes según su longitud prevista y urgencia, para que los pequeños pasos de extracción no esperen detrás de largas generaciones de código y las llamadas de verificación reciban objetivos de latencia más estrictos. El trabajo de la CPU importa más de lo que muchos equipos creen. El artículo centrado en CPU mostró que la inferencia de agentes incluye importantes cuellos de botella del lado de la CPU y analizó cómo elegir el tamaño máximo de lote para cargas de trabajo como LangChain, Haystack y SWE-Agent.

En la práctica, los profesionales ven la generación de tokens en los aceleradores, mientras que la preparación de solicitudes, la orquestación de herramientas, la serialización y el registro de datos recaen primero en la CPU. En la inferencia de LLM con agentes, un sistema mal equilibrado puede desperdiciar GPU costosas mientras una capa de CPU más económica se convierte en el cuello de botella.

La telemetría ya forma parte del producto

No se puede controlar lo que no se mide, y los agentes generan demasiadas rutas ocultas como para operar a ciegas. Por eso, en la inferencia de LLM con agentes son esenciales las trazas por paso, la latencia del planificador, la tasa de éxito de las llamadas a herramientas, el tamaño de las cargas útiles de las herramientas, la tasa de desacuerdo entre verificadores, la cantidad de reintentos y el tiempo total de principio a fin, desde que el usuario hace clic hasta que se completa la tarea.

No sirve de mucho saber que una solicitud tarda 6 segundos si el operador no sabe si 4 segundos se debieron a una búsqueda web, 1 segundo a la espera en cola y 1 segundo a la generación del modelo. Si la misma solicitud utilizó tres modelos y un sistema de recuperación de información, el equipo necesita una traza que abarque todos ellos.

En el debate sobre la telemetría de vLLM se planteó añadirla de forma predeterminada al uso de la CLI y Docker, con opciones para desactivarla. Incluso en la capa de servicio de código abierto, la tendencia es evidente. Los operadores quieren ver los patrones de uso reales, no solo las tablas de pruebas de rendimiento, porque esa visibilidad importa tanto para la fiabilidad como para los costos. Si se reintenta el 15 % de los trabajos porque falla un esquema JSON, la factura aumenta antes de que el cliente sepa por qué.

Una buena telemetría también cambia la elección del modelo. Las trazas pueden revelar que la mayoría de los costos proviene de pasos de clasificación de poco valor que podrían trasladarse a un modelo más pequeño, o lo contrario. Un planificador más económico puede provocar suficientes reintentos posteriores para que todo el flujo de trabajo acabe costando más.

Los mejores productos con agentes ahora consideran la observabilidad parte de la experiencia del usuario, para que los equipos de operaciones puedan determinar si un trabajo lento se debe a la elaboración de instrucciones, el enrutamiento, una herramienta, el planificador o el modelo.

Metodología

Este artículo analizó la ingeniería y la economía de la inferencia de LLM con agentes a partir de documentación pública y artículos de Nvidia, OpenAI, AMD, Hugging Face, el proyecto vLLM y arXiv sobre la latencia de los agentes y el comportamiento de los sistemas de servicio. Todo el material provino del conjunto de fuentes fijo proporcionado para el martes 27 de octubre de 2026.

El análisis se centró en cuatro capas: hardware, eficiencia del modelo, software de servicio y telemetría. Se buscaron cifras concretas sobre velocidad, costo, tamaño del modelo, ancho de banda de memoria y compensaciones arquitectónicas.

Cuando una fuente ofrecía una métrica relativa, como «latencia casi a la mitad» o «costo reducido un 83 %», se informó directamente de ella. Cuando ninguna fuente pública del conjunto proporcionaba valores exactos de costo por dólar y por token o de milisegundos para una configuración de producción específica, este artículo no los inventó.

La evidencia es escasa en tres aspectos. Primero, la mayoría de los laboratorios no publica desgloses completos de costos para las cargas de trabajo con agentes, especialmente cuando se incluyen los reintentos y los fallos de herramientas.

Segundo, las cifras de las pruebas de rendimiento de los proveedores no se corresponden directamente con el tráfico real mixto. Tercero, la telemetría de código abierto sigue fragmentada, lo que dificulta las comparaciones entre sistemas. El resultado es un panorama de producción respaldado por pruebas sólidas de tendencias generales y un conjunto limitado de cifras públicas concretas, no una lista universal de precios para la inferencia de LLM con agentes.

El contraargumento

El argumento más sólido contra la tesis de que «los agentes son caros por naturaleza» es que muchos costos son transitorios. La eficiencia de los modelos mejora rápidamente. Los modelos de enrutamiento más pequeños y mejores pueden asumir gran parte del flujo de trabajo. El software de servicio mejora en el procesamiento por lotes y la gestión de caché. Y algunas tareas con agentes ahorran suficiente trabajo como para que incluso una factura elevada de inferencia siga siendo una buena inversión en implementaciones de inferencia de LLM con agentes.

OpenAI ha publicado mejoras reiteradas de velocidad y costo entre distintos modelos. Las opciones de pesos abiertos están mejorando. Los fabricantes de hardware siguen ampliando los límites del rendimiento. Si un flujo de trabajo sustituye treinta minutos de trabajo humano, el modelo puede ser lento o costoso en términos absolutos y aun así tener sentido económico.

También existe un argumento técnico. Si los modelos siguen mejorando, puede disminuir la cantidad de pasos, y un modelo futuro podría planificar de forma menos explícita, llamar a menos herramientas y necesitar menos comprobaciones. En ese escenario, el costo adicional de los agentes en la inferencia de LLM con agentes se reduce porque el propio flujo de trabajo se acorta.

Ese argumento debe tomarse en serio. Aun así, la evidencia publicada actualmente sugiere que las mejoras no eliminarán las compensaciones fundamentales. Los modelos mejores reducen el costo por paso, pero muchos equipos de producto responden añadiendo más pasos, mejores comprobaciones y herramientas más completas. A menudo, las mejoras de eficiencia se gastan en lugar de ahorrarse. Lo más probable es que el objetivo siga cambiando y que la disciplina continúe siendo importante para la economía de la inferencia de LLM con agentes.

Cómo es una buena operación en producción

Las mejores configuraciones de producción saben qué trabajos merecen cada modelo, cuánto debería durar cada paso y cuándo dejar de gastar. Para la inferencia de LLM con agentes, el patrón sostenible está claro: usar un modelo pequeño o mediano para el enrutamiento, la extracción, la creación de argumentos para herramientas y las verificaciones sencillas. Reservar el modelo más capaz para la síntesis abierta, el razonamiento ambiguo o las acciones de alto riesgo.

Mantén las respuestas breves, salvo que los usuarios realmente necesiten detalles. Establece límites estrictos para los reintentos. Usa la caché de forma intensiva cuando vuelva a aparecer el mismo contexto. Registra cada paso para agrupar los fallos según su causa, en lugar de clasificarlos en categorías vagas como «solicitud lenta». Elige el objetivo de servicio adecuado. Algunos productos necesitan ofrecer rápidamente la primera acción útil; otros, completar la tarea de forma determinista.

Los operadores con la economía más saludable tratarán el diseño de agentes como ingeniería de sistemas, no como simple elaboración de instrucciones. Se plantearán pronto preguntas operativas: ¿Qué porcentaje de las solicitudes llama a una herramienta? ¿Qué herramienta falla con mayor frecuencia? ¿Cuántos tokens se generan solo para comprobaciones internas? ¿Cuál es el tiempo de extremo a extremo en el percentil 95? ¿Cuántos reintentos se producen antes de derivar el caso a una persona? Las respuestas afectan de forma sustancial el costo y la fiabilidad de la inferencia de LLM con agentes.

Conclusión

Hay dos cosas que conviene seguir de cerca: más lanzamientos públicos de modelos que mejoren la velocidad y el costo a la vez, y una mejor telemetría abierta para los flujos de trabajo de varios pasos. Ambas son fundamentales para que la inferencia de LLM con agentes se convierta en software de uso habitual y deje de ser una demostración costosa. Probablemente, los equipos ganadores harán menos con los modelos grandes, no más. Solo recurrirán a la inferencia prémium cuando cambie los resultados, y harán que todos los demás pasos sean más pequeños, breves y fáciles de medir.

Leer a continuación: la IA de DeepSeek podría abaratarse después de que los investigadores redujeran un 75 % su uso de memoria