Dominando los Agentes de IA e1b1f3s y la Infraestructura Local de LLM: Streaming, Sandboxing y Firewalls de Prompt

Los servidores LLM locales y los frameworks de agentes son ahora comunes en flujos de trabajo cercanos a producción. Los ingenieros ejecutan Ollama, llama.cpp o vLLM en su propio hardware y lo exponen a través de un túnel inverso. Conectan agentes a herramientas mediante el Protocolo de Contexto del Modelo (MCP), y delegan algunas subtareas a modelos alojados. Cada una de estas opciones genera sus propios problemas de infraestructura. Las generaciones largas se cortan por timeouts de proxy. El buffering rompe el streaming token por token. Los servidores de herramientas de terceros amplían la superficie de ataque. Datos sensibles pueden salir de la máquina dentro de un prompt.

Este artículo cubre tres patrones para estos problemas:

1. Mantener vivas las generaciones en streaming prolongadas mediante túneles y proxies.
2. Limitar lo que el código de herramientas MCP no confiables puede hacer con un entorno de WebAssembly (Wasm).
3. Redactar secretos y PII en el borde antes de que un prompt llegue a un modelo en la nube.

Para cada patrón se indica qué hace la técnica y qué no.

1. Generaciones de larga duración: Mantener los streams vivos mediante túneles y proxies

El desbordamiento de la ventana de contexto es un problema separado. Ocurre cuando el input supera la longitud de contexto configurada del modelo, y la solución está en el servidor del modelo (para Ollama, la configuración num_ctx), no en la ruta de red. La falla que aborda esta sección es que una respuesta larga o lenta se corte o se retrase entre el modelo local y el cliente.

[Servidor LLM local]
      │  (localhost HTTP)
      ▼
[Tu proxy / demonio de túnel en el borde] ──(HTTP en bloques / SSE)──► [Cliente remoto o gateway]
      ▲
 (buffering desactivado, latidos, timeouts ajustados)

Ollama escucha por defecto en el puerto 11434. Expone un endpoint compatible con OpenAI /v1/chat/completions, y stream: true devuelve Eventos Enviados por el Servidor (SSE). Las generaciones de estilo razonamiento pueden durar minutos, y el camino entre el modelo y el cliente tiene varios puntos donde pueden fallar.

Dónde se rompen los streams

1. Timeouts de inactividad y respuesta. El proxy_read_timeout de Nginx por defecto es 60 segundos. Mide la brecha entre dos lecturas sucesivas del upstream, no el tiempo total de la solicitud. Si un modelo tarda más que eso en procesar un prompt grande antes de emitir su primer token, Nginx cierra la conexión. El proxy de Cloudflare devuelve un error 524 cuando el origen no responde en unos 100 segundos. Ese límite solo puede cambiarse en planes Enterprise, y aplica a la espera de la respuesta, por lo que una fase larga de