Motivos por los que la inteligencia artificial con agentes necesita una stack de inferencia abierta

«En este momento, todos los laboratorios de inteligencia artificial pierden dinero al prestar servicios a tu empresa. Ellos lo saben. Y lo hacen a propósito».

Esa fue la primera línea de un artículo que llegó a mi bandeja de entrada la misma semana en que tres números se cristalizaban para dejar claro por qué la inferencia abierta ya no es opcional.

Un desarrollador diseñó una aplicación de notas sencilla durante un fin de semana con un agente de codificación open source con una clave de API directa. Una página, una función. Costo: 50 USD. Al día siguiente, una suscripción de 20 USD al mes proporcionaba 50 veces más tokens.

Un ingeniero de nuestro equipo de inferencia utilizó 300 millones de tokens a través de modelos de peso abierto en dos días, realizando el mismo trabajo que habría costado miles de dólares con las API propietarias.

Los dos primeros números muestran el subsidio. El tercero revela la salida. Y la razón por la que necesitamos esa salida son los agentes.

El modelo de precios está en transición

Los proveedores de modelos de vanguardia han hecho algo extraordinario. Han logrado que la inteligencia artificial de primer nivel esté al alcance de millones de desarrolladores a precios que habrían sido impensables hace dos años. Esa accesibilidad ha disparado la adopción. También ha creado una estructura económica que podría no ser sostenible al ritmo actual.

El sitio web Is AI profitable yet? hace un seguimiento del panorama financiero general del sector de la inteligencia artificial. En la actualidad, las empresas de inteligencia artificial invierten aproximadamente el 195 % de sus ingresos. Un colaborador del debate calculó que, en el equivalente en dólares de 2024, el gasto total de capital en inteligencia artificial en diez años ha sido aproximadamente tres veces el coste de todo Estados Unidos. Interstate Highway System. Estos son los tipos de inversiones que acabarán reflejándose en los precios de los servicios.

Ya aparecen señales de esa transición. Circularon informes de que algunas grandes empresas están reconsiderando las licencias de herramientas de codificación de inteligencia artificial, ya que la facturación basada en tokens reemplaza a las suscripciones de tarifa plana, con costos por ingeniero de entre 500 y 2000 USD al mes. Los modelos de vanguardia más nuevos ofrecen mejoras modestas en los indicadores y consumen entre un 10 % y un 25 % más de tokens por tarea. El suministro de GPU ya está asegurado para los próximos 3 o 4 años, y varios proveedores de nube de GPU ya han agotado su capacidad.

Nada de esto es una crítica a los proveedores. Están construyendo el futuro y fijando precios de manera agresiva para acelerar la adopción. Es probable que los costos unitarios por token sigan disminuyendo, y Gartner prevé una reducción del 90 % para el 2030. Sin embargo, como señala el mismo análisis, las cargas de trabajo con agentes consumen tantos tokens por tarea que se espera que el gasto total de inferencia empresarial aumente a pesar de que las unidades sean más baratas. Goldman Sachs prevé que el consumo de tokens se multiplique por 24 para el 2030. Las empresas que planifican los próximos 3 a 5 años deben prepararse para costos agregados más altos, no más bajos. Los modelos open source que se ejecutan en una infraestructura autogestionada son la válvula de escape que permitirá que la inteligencia artificial siga siendo accesible a medida que aumente el consumo.

Figura 1: La paradoja del costo de la inferencia con agentes Los costos por token disminuyen un 90 % (Gartner), pero el consumo total aumenta 24 veces (Goldman Sachs), lo que da como resultado un mayor gasto empresarial total a pesar de que las unidades son más baratas.

Los agentes cambiaron la ecuación

El modelo de precios por suscripción se diseñó para humanos que escriben a velocidad humana. Los agentes generan órdenes de magnitud más de llamadas a la API, y ningún modelo de precios actual se diseñó para eso.

Un colaborador de OpenClaw consumió 1,3 millones de USD en tokens de la API de OpenAI en un solo mes. Esto equivale a 603000 millones de tokens en 7,6 millones de solicitudes de aproximadamente 100 instancias de Codex operadas por tres personas. En un solo día, esa cuenta registró 19985,84 USD en gastos.

Jensen Huang afirmó que el consumo de tokens de los agentes ha aumentado aproximadamente 1000 veces en comparación con el uso de los modelos tradicionales. En el podcast Latent Space, Marc Andreessen dijo que su círculo gasta 1000 USD al día en tokens de Claude para ejecutar agentes, con una demanda latente de entre 5000 y 10000 USD al día por cada agente personal completamente implementado. Incluso con una mejora del precio de 10 veces, seguirían siendo 100 USD al día. «Sigue estando muy por encima de lo que la gente puede pagar».

Algunos proveedores ya han tenido que restringir el uso de marcos de agentes de terceros en las suscripciones de tarifa plana porque las demandas de cómputo excedían lo que el modelo de precios podía soportar. La estructura de los precios de tarifa plana y las cargas de trabajo de los agentes autónomos no encajan.

El costo es solo una parte del problema. Las cargas de trabajo con agentes tienen requisitos técnicos para los que las API propietarias nunca se diseñaron.

Fragmentación de las API: El panorama de las API con agentes cuenta con varios estándares contrapuestos. Chat Completions (formato sin estado original de OpenAI), Responses API (formato con estado más nuevo de OpenAI con herramientas integradas e integración del Protocolo de Contexto de Modelos), Messages API (formato de Anthropic) e Interactions API (protocolo con agentes de Google). Cada uno gestiona de forma distinta las llamadas a herramientas, la gestión de estados y el razonamiento. Cada arnés elige uno diferente.

Cada familia de modelos también envuelve la misma llamada a la herramienta en etiquetas completamente diferentes. Al enviar get_weather(city="Seattle") a cinco modelos, se obtienen cinco formatos diferentes: Llama usa la sintaxis de Python con <|python_tag|>, Mistral usa [TOOL_CALLS] con matrices JSON, Gemma usa etiquetas <tool_code>y Hermes usa <tool_call>XML. El motor de inferencia necesita un analizador independiente para cada familia de modelos.

Llamada a herramientas: Detrás de una API propietaria, obtienes el analizador que ofrece el proveedor. No puedes personalizarlo. No puedes corregir un modelo que genera sintaxis Pythonic en lugar de su formato de entrenamiento. Eres un pasajero.

Enrutamiento de modelos: La ejecución de un solo agente genera subtareas heterogéneas: algunas requieren un razonamiento profundo, otras una clasificación rápida y otras la generación de código. El enrutamiento de estas tareas a diferentes modelos requiere el control de la capa de servicio. Detrás de la API de un único proveedor, todas las tareas se envían al mismo modelo por el mismo precio.

Ingeniería de contexto: Gestionar lo que llega al modelo a lo largo de muchos turnos es la optimización de mayor impacto disponible. Un canal de contexto bien ajustado puede reducir el uso de tokens entre un 60 % y un 80 % y, al mismo tiempo, mejorar la calidad de los resultados. Sin embargo, la ingeniería de contexto eficaz requiere acceso al comportamiento del modelo en el nivel de inferencia. Es necesario medir lo que el modelo realmente atiende, identificar qué tokens de contexto contribuyen a la calidad del resultado y ajustar las estrategias de resumen y recuperación basadas en patrones de atención reales en lugar de conjeturas.

Disyuntores: Sin el control de la capa de inferencia, no puedes implementar presupuestos por agente, detección de anomalías ni apagado automático en el servidor de modelos. Como he estado en el extremo receptor de un bucle infinito, puedo decirte que el proveedor no te salvará.

Los economistas llaman a esto la paradoja de Jevons. William Stanley Jevons observó el patrón en 1865. A medida que las máquinas de carbón se volvieron más eficientes, aumentó el consumo total de carbón. Los tokens de inteligencia artificial siguen la misma trayectoria. Cada mejora de la eficiencia abre nuevos casos de uso que consumen más de lo que se ahorra. Las empresas que logren resultados por token utilizarán más inteligencia artificial, no menos.

Los modelos abiertos están listos para el trabajo con agentes

Como mencionamos anteriormente, nuestro equipo de inferencia procesó 300 millones de tokens con modelos de peso abierto en dos días. Nemotron 3 Super, Gemma 4 y Qwen 3.6, ejecutándose en la stack de inferencia de Red Hat AI. El resultado fue lo suficientemente sólido para las revisiones de pull requests, implementaciones de primer paso e investigaciones específicas, delegando el trabajo que, de otro modo, se destinaría a los modelos de vanguardia y acumularía costos de tokens.

La diferencia de costos no es marginal. Los indicadores de las Blackwell GPUs para consumidores muestran que una GPU de 500 USD que ejecuta modelos de peso abierto puede procesar 30 millones de tokens al día. Con ese volumen, el costo del hardware se recupera en un plazo de tres meses, en comparación con lo que costaría la misma carga de trabajo con los proveedores de API de nivel económico a unos 0,20 USD por millón de tokens. En comparación con los precios de las API de vanguardia, el periodo de retorno de la inversión se reduce a días.

Un investigador diseñó un agente de codificación que logró un 87 % en los indicadores utilizando un modelo que activa solo 4000 millones de parámetros por token. Los agentes que utilizaron modelos de 14000 millones de parámetros obtuvieron una puntuación del 75 %. La diferencia no era el modelo, sino las herramientas compuestas y un bucle de retroalimentación de errores. El arnés hizo el trabajo pesado , no el tamaño del modelo.

Para que los modelos abiertos funcionen bien en escenarios con agentes, se requiere ingeniería real, y esa ingeniería es exactamente lo que permite el open source. Una demostración reciente de Gemma 4 ejecutándose con OpenCode y Claude Code muestra cómo es esto en la práctica, con ajustes de plantillas de chat personalizados, perfeccionamiento del analizador de llamadas a herramientas para cada familia de modelos y formato de peticiones en varios estándares de API. El modelo de 4000 millones de parámetros necesitaba un tratamiento diferente al de la versión cuantificada de 26000 millones de parámetros, que a su vez necesitaba un tratamiento diferente al del modelo de 31000 millones de parámetros.

Este es el tipo de trabajo que reduce la brecha entre el rendimiento de referencia y el rendimiento real de los agentes. Implica la traducción entre las API de completado de chat, mensajes y respuestas, y el análisis de los resultados del modelo con lógica difusa, ya que los modelos a veces pierden sus tokens de inicio de llamada de herramienta o generan una sintaxis inesperada influenciada por los peticiones del sistema del arnés.

Este trabajo se está realizando upstream en vLLM, en las plantillas de chat de los proveedores de modelos y en los informes de errores de los arneses. Y solo puede ocurrir en el open source. Con un servidor de inferencia propietario, no puedes enviar una corrección de plantilla de chat, ajustar un analizador de llamada de herramienta ni observar por qué falla la salida de tu agente. Con el open source, cada corrección beneficia a cada usuario y cada actualización del analizador es permanente. Este trabajo de integración upstream, que hace que los modelos de peso abierto sean confiables para las cargas de trabajo con agentes en toda la stack de servicio, es un objetivo central de Red Hat AI.

La stack de inferencia con agentes

Hay ocho capas que deben funcionar en conjunto para realizar inferencias con agentes a escala empresarial. Cada capa interactúa con todas las demás.

Figura 2: La stack de inferencia con agentes, desde el agente y el arnés en la parte superior hasta la traducción de la API, la puerta de enlace, las medidas de seguridad, el servicio desagregado, la configuración del servidor de modelos, el motor de inferencia y, por último, el hardware en la parte inferior. Los bordes rojos resaltan las dos capas en las que se encuentra la mayor parte del trabajo de compatibilidad con agentes. El límite discontinuo del sandbox envuelve la capa de agentes donde la ejecución del código y los controles de seguridad son más estrictos.

Es posible ensamblar estas capas a partir de proyectos open source individuales, pero resulta costoso desde el punto de vista operativo. El valor de una plataforma de inferencia autogestionada como Red Hat AI es que se integra en una stack probada y compatible que se ejecuta en tu infraestructura. De este modo, tus datos nunca salen de tu límite de seguridad y tú controlas el ciclo de actualización, la selección del modelo y la política de enrutamiento.

La capa de API con agentes

El problema de la diversidad de las API es real. Los arneses utilizan Chat Completions, Responses, Messages API o Interactions API, y el servidor del modelo subyacente no siempre es compatible con todos ellos. La capa de API con agentes se sitúa entre el arnés y la infraestructura para ayudar a cerrar esta brecha. Proyectos como OGX (anteriormente Llama Stack) ofrecen implementaciones abiertas de las propias API con agentes: Chat Completions, Responses API, Messages API e Interactions API, junto con funciones complementarias como almacenes de vectores, gestión de archivos y ejecución de herramientas, todo sobre cualquier capa de servicio de modelos que ejecutes.

En este momento, ningún estándar de API único está destinado a ganar la carrera, a pesar de la ventaja de ser los primeros en actuar de algunas API. Lo importante es contar con implementaciones open source de todos ellos, para que puedas adaptar cualquier arnés a cualquier modelo siempre que lo necesites. Cuando la capa de traducción es open source, conserva el contrato completo de llamada a herramientas y puedes ver exactamente qué ocurre con tu solicitud. Cuando un proveedor propietario se encarga de la traducción, nunca sabrás qué se pierde.

llm-d: Escalado de la inferencia con agentes

vLLM de instancia única funciona para un ingeniero que ejecuta agentes, pero no para cien ingenieros que utilizan los mismos modelos simultáneamente. llm-d es la capa de servicio desagregada que divide la inferencia en fases separadas de precarga y decodificación, permitiendo que escalen de forma independiente en hardware diferente. Para las cargas de trabajo con agentes, donde muchas solicitudes cortas se entrelazan con largas cadenas de razonamiento, esta arquitectura es cada vez más esencial.

Medidas de seguridad y aislamiento de procesos (sandboxing)

La seguridad del contenido también forma parte de esta stack y debe tener en cuenta a los agentes. Los marcos de medidas de seguridad que funcionan como proxies deben conservar todo el contrato de la API con agentes, incluyendo las definiciones de herramientas, la elección de las mismas y los parámetros de razonamiento, o corren el riesgo de degradar silenciosamente el comportamiento de los agentes.

Las medidas de seguridad efectivas con agentes también requieren acceso a datos de nivel de inferencia que el simple filtrado de texto de entrada/salida no puede proporcionar. Esto incluye rastreos de razonamiento para evaluar si la cadena de pensamiento del modelo contiene pasos inseguros, parámetros de llamadas a herramientas para validar argumentos según la política, probabilidades logarítmicas (logprobs) para detectar alucinaciones y metadatos de generación para auditorías. Esta es otra razón por la que la capa de inferencia debería ser abierta. Las medidas de seguridad que solo pueden ver el texto que entra y sale son insuficientes para las cargas de trabajo con agentes. 

Si tu proxy de medidas de seguridad es una caja negra que elimina los parámetros de llamada a herramientas, cuando tus agentes fallen, no podrás diagnosticar el motivo. Las medidas de seguridad open source (como el endpoint sin proxy /v1/guardrails/checks de NVIDIA NeMo Guardrails) garantizan la seguridad del contenido sin romper el contrato de la API con agentes.

El aislamiento de procesos (sandboxing) es otro factor. Los agentes ejecutan código, escriben archivos e invocan herramientas. La defensa en profundidad requiere un aislamiento por capas, lo cual incluye el confinamiento a nivel de contenedor, políticas de red, restricciones del sistema de archivos y aplicación del tiempo de ejecución. No basta con colocar un agente en un contenedor. El límite del sandbox en el diagrama de la stack envuelve al agente y al arnés porque es ahí donde puede ocurrir la ejecución de código arbitrario y donde los controles de seguridad deben ser más estrictos.

Por qué gana el open source

No puedes probar una stack de ocho capas cuando no puedes ver lo que hace la mitad de ellas. No puedes depurar las llamadas a herramientas que fallan cuando no puedes ver el analizador. No puedes imponer la seguridad cuando el proxy de las medidas de seguridad elimina silenciosamente los parámetros que los agentes necesitan. La stack está demasiado acoplada para que una sola capa sea opaca. La integración y el fortalecimiento de estas capas juntas, para que las empresas no tengan que ensamblar la stack por sí mismas, es el problema que Red Hat AI se diseñó para resolver.

Más allá del argumento técnico, la inferencia abierta es inevitable por razones estructurales que van más allá del costo.

Figura 3 Inferencia abierta frente a API propietarias para cargas de trabajo con agentes Las API propietarias lideran en facilidad de configuración y calidad de los modelos de vanguardia. La inferencia abierta lidera en las siete habilidades de las que dependen las cargas de trabajo con agentes en producción: enrutamiento de modelos, depuración de llamadas a herramientas, personalización de dominios, presupuestos por agente, residencia de datos, independencia del proveedor y medidas de seguridad a nivel de inferencia.

La educación acelera todo el sector: El open source ofrece dos cosas: software libre y conocimiento gratis. DeepSeek R1 lo demostró claramente. Las capacidades de razonamiento existieron en los modelos propietarios durante meses antes de que la comunidad en general pudiera replicarlas. Una vez que DeepSeek publicó el código y el artículo, todos los laboratorios importantes dispusieron de capacidades de razonamiento en tres meses. El efecto de difusión del conocimiento es más valioso que el propio modelo. Si se aplica a la inferencia con agentes, todas las correcciones de llamadas a herramientas, mejoras en las plantillas de chat y parches para los arneses se convierten en infraestructura compartida que se suma a todo el ecosistema.

La confianza requiere transparencia: No todas las organizaciones están dispuestas a dirigir todos sus datos y flujos de trabajo a través de unos pocos proveedores de modelos en la nube. Para algunas, es una cuestión de cumplimiento estricto. Sectores como la sanidad y las finanzas se enfrentan a requisitos normativos rígidos en torno a la privacidad y residencia de los datos. Para otras, es una elección estratégica para evitar la dependencia del proveedor y conservar la propiedad completa de su propiedad intelectual.

El open source ofrece a las organizaciones la opción de ejecutar modelos bajo sus propios términos, dentro de sus propios límites de seguridad y con total visibilidad de cómo funciona el sistema. Para los sectores regulados, el sector público y las cargas de trabajo sensibles a la seguridad, esto es un requisito. La normativa avanza en la misma dirección: las obligaciones de transparencia de la Ley de inteligencia artificial de la UE, aplicables a partir de agosto de 2026, requieren documentación técnica que abarque la arquitectura del modelo, los procedimientos de entrenamiento y las características de rendimiento. Los modelos open source que ya publican esta información reúnen los requisitos para las exenciones que los modelos cerrados no tienen.

La personalización requiere pesos propios: Detrás de una API cerrada, todas las organizaciones ejecutan el mismo modelo. Cuando eres el propietario de los pesos en tu propia infraestructura, puedes realizar un ajuste fino para tu dominio, tus herramientas internas y las convenciones de tu base de código sin enviar datos propietarios al exterior. Las organizaciones sanitarias realizan ajustes finos para la terminología clínica y los formatos de los registros de pacientes. Los equipos legales adaptan los modelos al lenguaje y a las estructuras contractuales específicas de cada jurisdicción. Las instituciones financieras entrenan sus propios modelos de riesgo y marcos de cumplimiento. Para las cargas de trabajo con agentes, esta es la diferencia entre un agente de propósito general y uno que ya entiende cómo funcionan tus sistemas.

El open source genera una fuerza de gravedad en el ecosistema: Cuando los proveedores de hardware invierten en software de inferencia open source, disponer de modelos más accesibles impulsa una mayor adopción del hardware. Las inversiones en las optimizaciones de vLLM (el tiempo de ejecución de la inferencia) y las mejoras en la stack de servicio open source hacen que cada GPU sea más capaz para las cargas de trabajo con agentes y permiten la reutilización del hardware. El resultado es un círculo virtuoso en el que las mejoras del software open source se combinan en todo el ecosistema.

La siguiente fase favorece los modelos distribuidos: El patrón emergente está «centrado en el contexto compartido», con muchos modelos que funcionan sobre grafos de conocimiento y almacenes de contexto compartidos. Esto desplaza el enfoque de un único modelo masivo a un ecosistema de modelos especializados coordinados por un arnés inteligente. No necesitas necesariamente un modelo que pueda hacerlo todo. Lo más frecuente es que necesites muchos modelos especializados, cada uno rindiendo bien en su tarea, trabajando juntos como un sistema compuesto. Esa arquitectura es intrínsecamente más abierta y distribuida.

Arquitecturas de agentes emergentes como Pi y OpenClaw, entre otras, ya se construyen de esta manera. Su diseño es mínimo y suele incluir un modelo de lenguaje de gran tamaño (LLM), un bash shell, un sistema de archivos, archivos de estado markdown y un cron loop. El estado reside en los archivos, no en los pesos, por lo que puedes intercambiar el LLM sin perder la memoria del agente. Estos agentes funcionan con cualquier modelo, ya sea cerrado o abierto. Sin embargo, cuando la stack completa es open source, desde los pesos del modelo hasta la infraestructura de servicio, todas las ventajas estructurales se suman: perfeccionas tu dominio, enrutas a través de modelos que controlas, observas con herramientas que posees y cambias cualquier capa sin interrumpir el resto. Eso es lo que convierte a la inferencia abierta en una base natural para la inteligencia artificial con agentes y a Red Hat AI en la plataforma que la impulsa. 

Cómo prepararse

Tres cosas que debes realizar ahora, antes de que lleguen los cambios de precios.

Figura 4 Tres acciones para prepararse para la inferencia con agentes open source, cada una con herramientas específicas de la stack de Red Hat AI. El cronograma muestra un aumento de 12 meses desde la portabilidad de la API hasta la infraestructura con agentes completamente autogestionada.

Crea arneses agnósticos. La forma en que diseñes tu arnés con agentes y tus agentes importa tanto como el modelo que ejecutes, si no más. Si tus agentes están vinculados a la API de un solo proveedor, te habrás bloqueado antes de que lleguen los cambios de precios. Debes construir pensando en la portabilidad de modelos y API. Aquí es donde encajan proyectos como OGX, disponible a través de Red Hat AI, que proporciona la capa de traducción abierta para las API de Chat Completions, Responses, Messages e Interactions, de modo que tus agentes sigan siendo portátiles independientemente de qué modelo o proveedor haya debajo.

Aloja el volumen en una infraestructura gestionada. Una sola GPU que ejecute un modelo cuantificado de Gemma 4 o Qwen ya puede gestionar revisiones de pull requests, documentación y resúmenes de código. Utiliza suscripciones a API para las cargas de trabajo que realmente necesiten un razonamiento de vanguardia, o donde estos modelos aún tengan una clara ventaja de calidad, y aloja el resto en la infraestructura que controlas. Una plataforma de inferencia autogestionada maneja la complejidad operativa del servicio de modelos, el escalado, el enrutamiento y la observabilidad para que tu equipo pueda centrarse en construir agentes en lugar de mantener la stack de servicio. 

A medida que los modelos open source sigan cerrando la brecha con las capacidades de vanguardia, las cargas de trabajo que puedes autohospedar no dejarán de crecer. Si empiezas ahora, desarrollarás la preparación operativa que necesitarás cuando los modelos abiertos cubran toda la stack. La investigación sobre el enrutamiento de modelos muestra que dirigir la mayoría de las solicitudes a modelos más pequeños o autoalojados, escalando solo las tareas complejas a las API de vanguardia, puede reducir los costos entre un 60 % y un 85 % con una pérdida de calidad mínima.

Realiza pruebas integrales en toda la stack con agentes. Un modelo que supera los puntos de referencia puede fallar si el arnés le da instrucciones incorrectas, el analizador de herramientas lee mal la salida o la puerta de enlace enruta las tareas equivocadas. El enfoque correcto es probar el trío modelo-arnés-configuración.

Incorpora también el presupuesto de tokens a tu proceso. Límites por agente Atribución por función Detección de anomalías MLflow Tracing , que ya forma parte de la stack de Red Hat AI, captura peticiones, pasos de razonamiento, invocaciones de herramientas y costos de tokens con total compatibilidad con OpenTelemetry. Deseas recibir las alertas de presupuesto antes de necesitarlas.

Diseño para el futuro

El hardware suele depreciarse. Las GPU para inferencia abierta están haciendo lo contrario. Los chips no cambian, pero el software que se ejecuta en ellos no deja de mejorar. La mejora del procesamiento por lotes y los kernels de atención en vLLM envían más tokens por segundo a través del mismo silicio. Los avances en la cuantificación permiten que modelos que antes requerían 80 GB quepan en 20 GB con una calidad comparable. La distribución desagregada divide las cargas de trabajo para que el mismo clúster gestione más agentes simultáneos. Una GPU empresarial adquirida hace tres años produce más inferencias útiles hoy que el día en que se instaló. Esto se debe a que la stack open source ha mejorado a su alrededor.

Esa capitalización es el hilo conductor de todo este argumento. Los analizadores de llamadas a herramientas abiertas mejoran para todos. Las plantillas de chat abiertas corrigen la compatibilidad de una vez por todas. Las medidas de seguridad abiertas que preservan el contrato de la API con agentes protegen cada implementación, no solo a los clientes de un único proveedor. La distribución desagregada abierta escala en el hardware que ya posees.

Para esto sirven las plataformas de inteligencia artificial open source. No se trata solo de servir modelos, sino de poseer toda la stack de inferencia con agentes en tu propia infraestructura, desde la capa de API que traduce entre el arnés y el modelo, pasando por la puerta de enlace que enruta y mide, hasta el motor de servicio y el hardware en el que se ejecuta, lo que llamamos «metal to agents». Tus datos permanecen dentro de tus límites de seguridad. Tus modelos se ejecutan donde tú elijas. Tus costos son predecibles porque tú controlas cada capa. Cada capa es abierta. Cada capa se puede depurar. Cada mejora se comparte.

Los modelos son lo suficientemente buenos (y mejoran día tras día). La stack está tomando forma. La economía está clara. La pregunta no es si ocurrirá la inferencia con agentes abierta (ya ha ocurrido), sino si estarás preparado cuando llegue la factura.