Elige el modelo que tu infraestructura de inferencia puede ejecutar

Para un agente o copiloto, el compromiso en la capa de modelo es capacidad frente a coste de serving: un modelo de base más grande puede responder a prompts más difíciles, pero aumenta el precio por token, la demanda de GPU y la latencia. A mediados de 2025, el gasto empresarial en LLM fue de $8.4B, con el gasto empresarial en API liderado por Anthropic con 32%, OpenAI con 25%, Google con 20%, Llama de Meta con 9% y DeepSeek con 1%. Esa dispersión es la verificación aritmética antes de elegir un modelo.

La escala define el hardware mínimo

Trata un modelo de base como una decisión de serving: la escala de preentrenamiento define el hardware mínimo, la ventana de contexto y el presupuesto de prompt, no el precio por token, la profundidad de cola o la latencia de cola. A finales del verano de 2026, las plataformas empresariales de agentes como AWS Bedrock AgentCore, Google Gemini Enterprise, Microsoft Foundry y Salesforce Agentforce 360 dependen de uno o más modelos de base. Esa dependencia empuja la elección del modelo al presupuesto de serving.

La escala de preentrenamiento también moldea la carga de trabajo de evaluación. Los modelos más grandes pueden necesitar prompts más largos, más ejemplos y una suite de regresión más amplia; los modelos más pequeños pueden superar la misma prueba de producto con un prompt más corto y un endpoint más económico. Incluye la longitud del prompt, la ventana de contexto y el tamaño del hardware en el plan de pruebas.

La modalidad cambia la ruta de serving

Los modelos solo de texto pueden compartir una ruta de solicitud sencilla. Los modelos de imagen, audio o vídeo añaden preprocesamiento, almacenamiento y transferencia de datos; un agente multimodal puede necesitar un pool de workers separado, una GPU más grande y una política de caché diferente. En Build 2026, Microsoft Foundry se describió como un host de más de 11,000 modelos, incluida la familia MAI de Microsoft, GPT-5.5 y Claude. Un catálogo amplio es un problema de adquisición, no una respuesta de serving.

Los modelos de texto a menudo pueden reutilizar el mismo endpoint para chat, extracción y clasificación. Los modelos multimodales a menudo necesitan colas separadas para ingesta de imágenes, transcripción de audio y muestreo de fotogramas de vídeo. Esas colas cambian el modelo de coste antes de que se facturen los tokens.

El comportamiento de inferencia decide el coste

Modelos con puntuaciones de benchmark similares pueden tener costes de serving diferentes. Uno puede emitir respuestas largas, llamar a herramientas con frecuencia o necesitar una ventana de contexto grande; otro puede terminar en unos pocos tokens y encajar en un batch pequeño. Mide tokens por solicitud, tasa de llamadas a herramientas, latencia de cola y segundos de GPU por tarea.

A mediados de 2026, Model Context Protocol, un estándar de llamadas a herramientas, tenía SDKs Tier 1 que se acercaban a 500 millones de descargas mensuales, y tanto los SDKs de TypeScript como los de Python habían superado cada uno los mil millones de descargas totales. La adopción de herramientas cambia el coste de integración, no la calidad bruta del modelo.

Los modelos afinados cambian el coste de serving. Un modelo pequeño afinado puede reducir la longitud del prompt, disminuir las llamadas a herramientas y bajar la latencia de cola, pero también puede encadenarte a una tarea más estrecha. Si el afinamiento es para clasificación, extracción o enrutamiento, puede pertenecer a un endpoint económico. Si es para generación abierta, mantenlo detrás de los mismos controles de serving que el modelo base.

La ruta de serving viene antes que el modelo

Usa la matriz de serving de tres ejes: escala de preentrenamiento, modalidad y comportamiento de inferencia. Compara las rutas por API, autoalojada e híbrida frente a latencia, ruta de datos y volumen mensual de solicitudes.

• Serving por API: maneja gran escala de preentrenamiento y trabajo multimodal, pero el gasto en tokens escala con el uso y la tarifa del proveedor.
• Autoalojado: encaja con comportamiento de inferencia conocido y modalidad estable, pero tú asumes las GPUs, las actualizaciones y la capacidad ociosa.
• Híbrido: divide modalidad y comportamiento de inferencia entre rutas, pero el enrutamiento añade trabajo de política y registro.

Un enrutador híbrido necesita una política clara: enrutar por clase de tarea, presupuesto de tokens, sensibilidad de datos y objetivo de latencia.

AWS Bedrock AgentCore alcanzó disponibilidad general en 2026 y tuvo más de un millón de descargas de SDK de clientes como Cox Automotive, Druva, Cohere Health, Ericsson, Sony y Thomson Reuters. La adopción demuestra demanda, pero no demuestra que tu producto pueda servir el mismo modelo con tu objetivo de latencia. VMware AI Factory de Broadcom puede comprimir la ventana de despliegue de bare-metal al primer modelo de semanas a horas. Los clientes de VMware Cloud Foundation pueden ejecutar más de 150 modelos open-source y comerciales, incluidos Nemotron 3, Gemma 4, cotomi, Qwen y GLM 5.2. Una ruta autoalojada más corta no elimina el coste de GPU, el mantenimiento ni la planificación de capacidad.

Al construir un agente o copiloto, empieza con serving por API para el trabajo más difícil y un modelo autoalojado pequeño para llamadas rutinarias. Si tu ruta de datos o tu objetivo de latencia descartan las APIs externas, mueve todo el stack a autoalojado. Si necesitas ambos, construye un enrutador híbrido y mide la distribución. Registra la ruta elegida para cada solicitud y ajusta la distribución cuando cambien los datos de coste o latencia.