← Volver al blog
steply / blog · infraestrutura-agente-especialista-llm-producao.md
$ steply blog open infraestrutura-agente-especialista-llm-producao
▸ loading article…
✓ ready

Infraestructura para Sostener un Agente Especialista de IA en Producción: Stack Completo, Costos y Decisiones Arquitectónicas

porSteply5 min de lectura

Poner un agente especialista de IA en producción exige mucho más que contratar una API de LLM. Necesitas una infraestructura que sostenga baja latencia, costo previsible, seguridad, observabilidad, evolución continua, recuperación de fallas y gobernanza. En 2026 este stack está razonablemente estabilizado, pero las decisiones equivocadas cuestan meses de retrabajo y facturas de cinco cifras al mes desperdiciadas.

Esta guía muestra el stack completo por capa, las decisiones arquitectónicas críticas, los costos típicos y las trampas que solo descubres cuando el agente está a full y algo se rompe a las 23 h.

Las 8 capas de la infra de un agente en producción

1. Modelo (LLM): API gestionada (Anthropic, OpenAI, Google) o modelo self-hosted (Llama, Mistral, Qwen). La API gestionada gana en time-to-market y calidad media. El self-hosted gana en compliance estricto y, a partir de un volumen muy alto, en costo.

2. Gateway / proxy de IA: capa que centraliza las llamadas a los LLMs. Resuelve el enrutamiento entre proveedores, el fallback automático, el rate limit, el cache de respuestas, la observabilidad y el enforcement de políticas. LiteLLM, Helicone, OpenRouter y gateways propios son opciones comunes.

3. Harness y orquestación: framework que corre el loop del agente. Mastra, LangGraph, Claude Agent SDK, Vercel AI SDK, o un harness propio. Corre en compute serverless o en un contenedor según el perfil de uso.

4. Servidor MCP y herramientas: servidores MCP que exponen tools internas y externas al agente. Por lo general viven como microservicios o como módulos del mismo deploy del agente.

5. RAG y vector DB: pipeline de ingesta (extracción, chunking, embedding), vector DB (pgvector, Qdrant, Pinecone) y capa de retrieval con filtros y re-ranking.

6. Cache y mensajería: Redis (cache de respuestas, rate limit, sesiones), Postgres o Kafka para la cola de tareas asíncronas y eventos.

7. Observabilidad y evals: trace de ejecución (LangSmith, Phoenix, Helicone), logs estructurados, métricas (Prometheus + Grafana), alertas (PagerDuty, Slack), datasets de evaluación corriendo en CI.

8. Seguridad y gobernanza: secret manager (Vault, AWS Secrets), políticas de acceso, auditoría, aislamiento por tenant, control del blast radius en las acciones.

Decisiones críticas: serverless vs contenedor vs bare-metal

Serverless (Vercel, Cloudflare Workers, Lambda) brilla para tráfico irregular y baja latencia de cold start. Limitación: los timeouts cortos pueden matar agentes con loops largos. Contenedor en Kubernetes gana para tráfico sostenido, control fino de recursos e integración con microservicios internos. Bare-metal o GPU dedicada solo tiene sentido si corres tu propio modelo con volumen alto y quieres optimizar el costo de forma agresiva.

Para la mayoría de los agentes corporativos en 2026, la combinación que funciona es: Cloudflare Workers o Vercel en el borde para baja latencia, con workers en Kubernetes o serverless de larga duración para los pasos pesados del loop.

Costo: cómo modelar y controlar

La cuenta de IA se descontrola fácil. Modela el costo en cuatro frentes. 1. Tokens del LLM: entrada × salida × pasos del loop × número de llamadas. 2. Embeddings: ingesta inicial + reindexación ocasional. 3. Vector DB: almacenamiento + solicitudes. 4. Compute y bandwidth: harness, MCP, integraciones.

Prácticas para controlar. El cache en queries comunes reduce el costo de LLM y la latencia. Un modelo más pequeño para tareas livianas (clasificación, parsing) ahorra 5-10x. Un límite de tokens por sesión previene un loop salvaje y caro. Una cuota por tenant o por usuario evita que un solo cliente consuma todo tu margen. Un dashboard de costo por feature muestra dónde realmente se va el dinero.

Latencia: la métrica que convierte un buen producto en uno malo

El usuario tolera 1-2 segundos de espera. Por encima de 5 segundos, el producto se vuelve frustrante. La latencia del agente viene de cuatro fuentes: la llamada al LLM (200ms a algunos segundos), las llamadas de tools (red y backend), el retrieval (vector DB y re-ranker), el overhead del harness.

Estrategias para reducirla. El streaming de la respuesta del LLM al cliente mejora la percepción aun sin reducir el tiempo total. Tools en paralelo cuando el agente decide llamar a varias. Cache de retrieval en queries repetidas. Edge deploy cerca del usuario. Precálculo de respuestas previsibles (por ejemplo, saludos, FAQ frecuente).

Seguridad de la infra: más allá del guardrail del agente

Cuatro frentes críticos. 1. Segregación de credenciales: cada tool tiene su propia credencial, con alcance mínimo. Sin credencial "dios" expuesta al LLM. 2. Aislamiento por tenant: el dato y el contexto del cliente A nunca se filtran a la sesión del cliente B; ACL en el vector DB, en el MCP y en el log. 3. Auditoría inmutable: log de ejecución en storage append-only, con retención compatible con los requisitos legales. 4. Pen test y red team periódicos enfocados en prompt injection, exfiltración de contexto y abuso de tools.

Observabilidad: trace, métrica, log y eval

Sin una observabilidad decente, debuggear un agente es arqueología. Mínimo viable. Trace: cada ejecución tiene un trace_id; cada paso del loop es un span con prompt, respuesta, tool, latencia y costo. Métricas: latencia p50/p95/p99, costo por ejecución, tasa de error, uso de fallback. Logs estructurados: JSON con un correlation_id en todo el stack. Evals en CI: pipeline que corre el dataset de evaluación en cada cambio de prompt/modelo/tool, con un gate de calidad automatizado.

Recuperación de fallas y resiliencia

El modelo se cae. La API aplica rate-limit. Una tool queda fuera del aire. El vector DB se pone lento. Todo esto pasa. Fallback de modelo entre proveedores. Retry con backoff en errores transitorios. Circuit breaker en tools que fallan repetidamente. Graceful degradation (responder sin RAG si el vector DB se cae, escalando a un humano si es necesario). Idempotencia en acciones con efecto colateral. Estos patrones convierten fallas puntuales en eventos invisibles para el usuario.

Stack de referencia para un agente corporativo

Una combinación que funciona en 2026 para la mayoría de las empresas. LLM: Claude vía API, con fallback a GPT en rate limit. Gateway: un gateway propio liviano o LiteLLM. Harness: Mastra o Claude Agent SDK. MCP: servidores propios para sistemas internos + un marketplace de servidores comunitarios para integraciones genéricas. RAG: pgvector o Qdrant + Cohere Rerank. Cache y cola: Redis + BullMQ. Observabilidad: LangSmith o Phoenix + Grafana + Loki. Deploy: Kubernetes o serverless en Vercel/Cloudflare según el caso.

No es la única, no es "la mejor", es una combinación de decisiones defendibles con buena documentación y un ecosistema vivo. Lo importante es la coherencia interna: cada capa necesita conversar bien con las otras, con una observabilidad que atraviesa todo.

El factor humano

Una infra perfecta sin equipo no entrega. Un agente en producción necesita un product owner que defienda el caso de uso, un ingeniero responsable que entienda el stack y responda por los incidentes, un analista de calidad que mantenga los evals y monitoree el drift, y una operación que haga triage de incidentes y genere mejora continua. Sin estos roles, la mejor infra del mundo se pudre en meses.