LLM local en producción – Docker, rendimiento, seguridad y estrategia

 

Por Daniel Contreras

¡Saludos, entusiasta de la tecnología! Llegamos al tramo final de la serie: aquí pasamos del uso individual a la operación robusta en equipo.

Esta entrega te ayudará a convertir un setup funcional en una práctica sostenible: despliegue, optimización, seguridad y criterios para decidir cuándo local gana frente a la nube y cuándo conviene un enfoque híbrido.

Si ya montaste Ollama y lo conectaste a tu IDE LLMs en local: Monta tu copiloto local — Ollama, tu IDE y casos de uso reales, esta entrega cierra la serie con despliegue para equipos, optimización, seguridad, la decisión local frente a nube y un resumen para responsables técnicos.

¿Llegas directamente aquí? Repasa primero la LLMs en local: Por qué importan y qué necesitas en 2026 (contexto y hardware) y la LLMs en local: Monta tu copiloto local — Ollama, tu IDE y casos de uso reales (instalación básica).

Índice de esta entrega

. Integración avanzada con IDEs (opcional)

. Despliegue avanzado: Docker, Kubernetes y exposición segura

. Optimización y rendimiento

. Seguridad, privacidad y consideraciones prácticas

. Pros y contras: cuándo elegir local frente a nube

. Conclusión de la serie

1. Integración avanzada con IDEs (opcional)

1.1. Cursor: subagentes y Skills (paraleliza y reutiliza tu “know-how”)

Cuando el trabajo crece, un patrón que escala bien es dividir: que el agente principal coordine y delegue en subagentes o use skills (capacidades reutilizables) según convenga.

1.1.1. Subagentes: aislar contexto y trabajar en paralelo

Los subagentes son asistentes especializados que operan en su propio contexto. El agente principal puede delegarles tareas como explorar el repositorio, revisar logs, o hacer una comprobación específica, y luego recoger un resultado resumido.

• Por qué ayudan:

1. Paralelización: investigar varias cosas a la vez (p. ej., “localiza endpoints”, “revisa tests”, “encuentra la configuración de build”).
2. Aislamiento de contexto: reduces el “ruido” en el hilo principal y mantienes el foco.

Documentación: Cursor: Subagents

1.1.2. Skills: automatizar flujos repetibles (y compartirlos)

Las skills son paquetes reutilizables de instrucciones/procedimientos para que el agente ejecute tareas de forma consistente (por ejemplo: generar un checklist, seguir un estándar de componentes, auditar algo, etc.). La diferencia práctica:

Usa una skill cuando el flujo es repetible y quieres que salga siempre “igual de bien”.

Usa un subagente cuando necesitas exploración puntual o trabajo paralelo con aislamiento.

Dos puntos importantes antes de instalarlas:

1. Revisión: trata una skill como tratarías un script: revisa el origen y lo que hace.
2. Seguridad: evita ejecutar skills “a ciegas” en repositorios con secretos o entornos sensibles.

Descubrimiento/instalación (ejemplo con una colección pública):

Recursos para empezar:

• The Agent Skills Directory (skills.sh)
• Colección de skills de ejemplo: google-labs-code/stitch-skills

1.2. VS Code / GitHub Copilot: Custom Agents con archivos .agent.md

En el ecosistema de VS Code / GitHub Copilot puedes definir custom agents (roles/personalidades) mediante ficheros Markdown con frontmatter YAML, normalmente con extensión .agent.md. Sirven para estandarizar comportamientos tipo “Planner”, “Implementer”, “Reviewer”, limitar herramientas disponibles y definir “handoffs” entre agentes.

Documentación: Custom agents in VS Code

Ubicación típica en el repo: .github/agents/ (por ejemplo, .github/agents/planner.agent.md).

Ejemplo mínimo de agente de planificación (ajusta herramientas/modelo a tu entorno):

1.3. Integración con MCP y Slack (opcional)

Si quieres que las respuestas de tu agente de IA se envíen automáticamente a canales de Slack, puedes usar un MCP (Middleware de Comunicación de Proyectos) como puente. Requiere un bot de Slack configurado y un script en Python o Node.js que reciba la respuesta del LLM y la reenvíe a Slack según la configuración del proyecto.

Ejemplo mínimo en Python:

En Cursor puedes usar Custom Actions para ejecutar scripts externos; en VSCode, Tasks o un snippet de automatización. Con esto, puedes seleccionar la respuesta del agente y enviarla al canal de Slack correspondiente con un solo clic.

Configuración de Custom Action en Cursor (ejemplo en cursor.json):

Así puedes seleccionar la respuesta del agente en el chat y ejecutar la acción para enviarla al canal configurado.

2. Despliegue avanzado: Docker, Kubernetes y exposición segura

2.1. Ollama en Docker

Para entornos más controlados o para compartir el servicio en red:

Esto expone Ollama en localhost:11434 y persiste los modelos en un volumen. Para descargar modelos dentro del contenedor:

2.2. Despliegue en Kubernetes

Para equipos que quieran un Ollama compartido en el clúster, un manifiesto básico permite tener el servicio disponible dentro de la red interna. Los desarrolladores pueden conectarse mediante kubectl port-forward o un Ingress si se expone internamente.

Consideraciones para Kubernetes: Ollama es stateful en el sentido de que los modelos se almacenan en disco. Usa un PersistentVolumeClaim en lugar de emptyDir si quieres que los modelos persistan entre reinicios del pod. Si tienes nodos con GPU NVIDIA, añade el recurso nvidia.com/gpu: 1 en los limits del contenedor y asegúrate de que el nodo tenga los device plugins de NVIDIA instalados. Para cargas altas, considera varios réplicas detrás de un Service; ten en cuenta que cada réplica cargará su propia copia del modelo en memoria.

Acceso desde fuera del clúster:

2.3. Exposición con ngrok (y riesgos de seguridad)

Si necesitas acceder a tu Ollama desde fuera de tu red (por ejemplo, para usar Cursor en un equipo remoto o probar una app móvil):

El flag --host-header es importante: Ollama puede rechazar peticiones que no vengan con el host correcto.

Advertencia de seguridad: Al exponer tu LLM con ngrok, cualquiera con la URL puede usar tu GPU. Configura autenticación (Basic Auth en ngrok, restricciones de IP, etc.) y cierra el túnel cuando no lo necesites.

2.4. Alternativa: localhost.run

Sin instalar ngrok:

Obtendrás una URL pública que redirige a tu Ollama local. Útil para pruebas rápidas.

2.5. Persistencia de modelos en Docker

Si usas Docker, los modelos se almacenan en el volumen. Para pre-cargar modelos al construir una imagen personalizada:

Así, al levantar el contenedor, los modelos ya estarán disponibles sin tener que descargarlos en cada arranque.

2.6. Servidor Ollama compartido para equipos

Si varios desarrolladores quieren usar un LLM local sin que cada uno tenga que descargar modelos y consumir recursos en su máquina, una opción es montar un servidor Ollama en un equipo de la red local (o en un servidor de desarrollo).

Requisitos: Un equipo con su ficiente RAM/VRAM (por ejemplo, 32 GB RAM para modelos 7B–14B, o una GPU dedicada para modelos más grandes). Ollama escucha por defecto en 0.0.0.0:11434, así que acepta conexiones desde cualquier host de la red.

Configuración en el equipo servidor:

Configuración en los clientes (VSCode, Cursor, etc.): En lugar de http://localhost:11434, usa la IP del servidor:

Consideraciones de seguridad: En una red interna de confianza esto puede ser aceptable. Si la red es más abierta, considera poner Ollama detrás de un reverse proxy con autenticación (por ejemplo, Nginx con Basic Auth) o restringir el acceso por firewall.

Experiencia de un equipo real: Un equipo de 8 desarrolladores montó un servidor Ollama en un Mac Mini M2 con 24 GB de RAM. Descargaron Llama 3 y Qwen 2.5 Coder. Cada desarrollador configuró su VSCode o Cursor para apuntar a la IP del Mac Mini. El resultado: todos compartían los mismos modelos sin duplicar descargas, y el servidor aguantaba entre 2 y 3 peticiones simultáneas sin problemas. Para equipos más grandes, un servidor con GPU dedicada o más RAM sería recomendable.

3. Optimización y rendimiento: hacer que tu LLM vuele

3.1. Cuantización

La cuantización reduce el tamaño del modelo y el uso de memoria. Q4_K_M es el punto dulce: ~72 % menos VRAM con una pérdida de calidad de solo 3–5 % respecto a FP16. Ollama aplica cuantización automáticamente en muchos modelos; si usas GGUF manualmente, elige variantes Q4_K_M o Q5_K_M.

3.2. GPU y drivers

• NVIDIA: Instala los drivers más recientes y CUDA. Ollama los detecta automáticamente.
• AMD: Soporte experimental; revisa la documentación de Ollama para tu GPU.
• Apple Silicon: Metal se usa por defecto; no suele requerir configuración.

3.3. Recorta el contexto

Cada token adicional aumenta el tiempo de inferencia. Pasa solo el código o el contexto necesario. En lugar de enviar todo el proyecto, selecciona el archivo o la función relevante.

3.4. Ajusta temperatura y longitud

• Temperatura baja (0,1–0,3): Respuestas más deterministas, ideal para código.
• Temperatura alta (0,7–0,9): Más creatividad, útil para brainstorming.
• max_tokens: Limita la longitud de la respuesta para evitar respuestas interminables.

3.5. Modelos por tarea

• Autocompletado: Modelos pequeños (3B–7B) para latencia mínima.
• Chat y refactorización: 7B–14B suelen ser suficientes.
• Razonamiento complejo: 32B+ o modelos MoE como DeepSeek R1.

3.6. MLX: alternativa optimizada para Apple Silicon

Si usas un Mac con Apple Silicon, MLX es un framework de Apple optimizado para sus chips. En benchmarks recientes, MLX puede ser entre un 15 % y un 20 % más rápido que Ollama para modelos soportados. La contrapartida es que el ecosistema de modelos es más limitado que el de Ollama. Si buscas el máximo rendimiento en un M3 o M4 y tus modelos están disponibles en MLX, vale la pena probarlo. Para la mayoría de usuarios, Ollama ofrece el mejor equilibrio entre compatibilidad y rendimiento.

3.7. Solución de problemas frecuentes

«Ollama no responde» o «Connection refused»

• Comprueba que el servidor está corriendo: ollama list o curl http://localhost:11434/api/version.
• En Linux: ollama serve en una terminal o configurar el servicio systemd.

«Out of memory» o cierre inesperado

• Reduce el tamaño del modelo: usa 7B en lugar de 14B.
• Cierra otras aplicaciones que consuman mucha RAM.
• En Mac con poca RAM, el sistema puede usar swap; la inferencia será más lenta pero puede funcionar.

Respuestas muy lentas (1–2 palabras por segundo)

• Verifica que la GPU se está usando: en Ollama, revisa los logs al iniciar.
• En NVIDIA: instala drivers y CUDA correctamente.
• Prueba un modelo más pequeño o una cuantización más agresiva (Q4 en lugar de Q5).

El IDE no conecta a localhost

• Algunos IDEs o extensiones bloquean conexiones a localhost por políticas de seguridad.
• Prueba con 127.0.0.1 en lugar de localhost.
• Si usas Cursor, el workaround con ngrok puede ser necesario.

Modelo descargado pero no aparece

• ollama list muestra solo modelos ya descargados. Si acabas de hacer ollama pull, espera a que termine la descarga.
• Verifica espacio en disco: ~/.ollama puede estar lleno.

3.8. Errores frecuentes y cómo evitarlos

Copiar código sin revisar. El error más grave no es técnico, sino humano: confiar ciegamente en el output del modelo. Siempre lee, entiende y prueba el código antes de integrarlo. Los modelos pueden inventar nombres de paquetes, versiones de API o patrones que no existen en tu stack.

Elegir un modelo demasiado grande. Si tu máquina se queda colgada o tarda minutos en responder, no insistas: baja a un modelo más pequeño. Un 7B rápido es mejor que un 32B que no termina.

No configurar el host correctamente en Docker. Si Ollama corre en Docker y tu IDE está en el host, usa host.docker.internal (Mac/Windows) o la IP del host en Linux para que el contenedor pueda acceder a servicios externos si hace falta. Para que el host acceda al Ollama del contenedor, el mapeo de puertos - p 11434:11434 es su ficiente.

Olvidar el flag --host-header con ngrok. Si usas ngrok para exponer Ollama y las peticiones fallan, añade --host-header="localhost:11434" al comando ngrok. Ollama puede rechazar peticiones sin el header correcto.

4. Seguridad, privacidad y consideraciones prácticas

4.1. Ventajas de local

• Los datos no salen de tu máquina.
• No hay riesgo de que un proveedor use tu código para entrenar modelos.
• Cumplimiento más sencillo con políticas de confidencialidad y regulaciones (RGPD, HIPAA, etc.).

 

4.2. Riesgos a tener en cuenta

• Alucinaciones: Los modelos pequeños pueden inventar código o hechos. Siempre revisa y prueba. Un modelo 7B puede «inventar» nombres de funciones o librerías que no existen; es tu responsabilidad validar.
• Exposición con ngrok: Si expones tu API, protégela con autenticación. Cualquiera con la URL puede consumir tu GPU y generar contenido sin tu control.
• Dependencias: Mantén Ollama y los modelos actualizados por posibles vulnerabilidades.
• Uso de recursos: Un modelo cargado consume RAM/VRAM aunque no lo uses; ciérralo si necesitas liberar recursos.

 

4.3. Modelo de amenazas simplificado

4.4. Buenas prácticas

• No copies y pegues código a producción sin revisar.
• Usa modelos locales para datos sensibles; combina con la nube para tareas que requieran máxima
• capacidad.
• Documenta la configuración de tu equipo para que otros puedan replicarla.

4.5. Cumplimiento normativo y políticas empresariales

En sectores regulados (sanidad, finanzas, administración pública), el uso de servicios de IA en la nube puede chocar con normativas como el RGPD, HIPAA o políticas internas de tratamiento de datos. Un LLM local ejecutado en infraestructura controlada por la organización reduce el riesgo de transferencia de datos a terceros y facilita las auditorías. Si tu empresa tiene un comité de seguridad o un DPO (Data Protection Officer), plantear la opción local puede ser un argumento sólido para adoptar IA en proyectos sensibles sin bloquear la innovación.

5. Pros y contras: cuándo elegir local frente a nube

Cuándo elegir local: Proyectos con datos sensibles, equipos con presupuesto limitado para APIs, necesidad de trabajar offline, autocompletado y refactorización en tiempo real.

Cuándo elegir nube: Tareas que requieren el máximo razonamiento (arquitectura compleja, análisis profundo), equipos sin hardware adecuado, necesidad de soporte y SLA.

Comparativa rápida local vs nube:

Enfoque híbrido recomendado: Usar modelos locales para código sensible, autocompletado y tareas repetitivas; y modelos en la nube (Claude, GPT-4) para arquitectura, diseño y tareas que exigen el máximo nivel de capacidad.

5.1. Análisis de costes: ¿cuándo compensa local?

Un cálculo aproximado: un desarrollador que hace 500 preguntas al mes a un LLM en la nube (GPT-4o o similar) puede gastar entre 20 y 50 euros al mes en API, dependiendo de la longitud de las conversaciones.

En un año, son 240–600 euros. Un portátil con 16 GB de RAM que ya tienes no tiene coste marginal; un MacBook Pro M3 de 1.800 euros se amortiza en 3–4 años si evitas suscripciones de API. Si además valoras la privacidad, el break-even puede ser inmediato.

Para equipos de 5–10 desarrolladores, un servidor Ollama compartido en un equipo con 32–64 GB de RAM y una GPU opcional puede costar 2.000–4.000 euros una vez, frente a facturas mensuales de 100–500 euros en APIs. En 6–12 meses, la inversión local suele quedar amortizada.

6. Conclusión de la serie

Ejecutar LLMs en local ha pasado de ser un experimento a una opción sólida para profesionales de TI. En 2026, herramientas como Ollama, LM Studio o LocalAI permiten tener un asistente de IA potente en tu propio equipo, con privacidad, control y costes predecibles.

Resumen de recomendaciones:

1. Empieza con Ollama si eres desarrollador: es estable, sencillo y se integra bien con IDEs.
2. Prueba modelos 7B–8B (Llama 3, Qwen 2.5 Coder) en tu hardware antes de subir a modelos más grandes.
3. Configura Continue o Cline en VSCode para tener el modelo en tu flujo de trabajo diario.
4. Si usas Cursor, explora el endpoint personalizado o el workaround con ngrok si el soporte local es limitado.
5. Considera un enfoque híbrido: local para lo sensible y repetitivo, nube para lo más exigente.

La IA generativa está transformando cómo desarrollamos, documentamos y analizamos. Tener un LLM local es como tener un compañero de código que no cobra extra, no duerme y no comparte tus secretos. Con la configuración adecuada, puede convertirse en una pieza central de tu productividad técnica.

Resumen ejecutivo para responsables técnicos

Si eres CTO, lead técnico o responsable de innovación y estás evaluando la adopción de LLMs locales en tu organización, estos son los puntos clave:

1. Viabilidad técnica: En 2026, modelos de 7B–14B ofrecen calidad suficiente para tareas de desarrollo (refactorización, documentación, generación de código) en hardware estándar (16 GB RAM o GPU de 8 GB).
2. Privacidad: Los datos no salen de la infraestructura controlada. Crucial para sectores regulados.
3. Coste: Amortización típica en 6–12 meses frente a APIs en la nube para equipos de 5+ desarrolladores.
4. Integración: Ollama expone API compatible con OpenAI; la integración con IDEs y herramientas existentes es directa.
5. Riesgo: Los modelos pueden alucinar; el código generado debe revisarse siempre. Establece guías de uso y formación para que el equipo aproveche la IA sin introducir errores o vulnerabilidades en el código base.

 

Tendencias a seguir en los próximos años

El ecosistema de LLM locales evoluciona rápido. Algunas direcciones que vale la pena vigilar:

 

• Modelos cada vez más eficientes: Las técnicas de destilación y cuantización siguen mejorando. Es probable que modelos de 7B en 2027 igualen en calidad a los 14B de hoy con los mismos requisitos de hardware.
• Integración nativa en IDEs: Cursor y otros editores podrían ofrecer soporte oficial para modelos locales si la demanda de la comunidad sigue creciendo. Mientras tanto, el workaround con endpoint personalizado funciona bien.
• Especialización por dominio: Modelos fine-tuned para código, para SQL, para documentación técnica o para un lenguaje concreto (por ejemplo, español jurídico o médico) serán más accesibles y fáciles de desplegar en local.
• Edge y dispositivos móviles: Ya existen modelos que corren en smartphones (Phi-4 Mini, Llama 3.2 3B). La tendencia es llevar la IA a más dispositivos sin depender de la nube.

Próximos pasos concretos

• Si tienes un Mac con Apple Silicon: Aprovecha la memoria unificada. Un M3 con 16 GB puede con Llama 3 y Qwen 2.5 Coder sin problemas. Si puedes, sube a 24 GB o más para modelos 14B–32B.
• Si tienes una GPU NVIDIA: Asegúrate de tener drivers y CUDA actualizados. Ollama los detecta automáticamente y el salto de rendimiento es notable.
• Si trabajas en equipo: Plantéate un servidor Ollama compartido en la red local para que todos disfruten de la IA sin duplicar descargas ni consumo de recursos.
• Si tienes datos sensibles: Prioriza la ruta local para cualquier código o información que no deba salir de tu entorno.

¿Ya has probado a desconectar el cable de red y seguir programando con IA? ¿Qué modelo local te ha sorprendido más? El futuro de la IA en el desarrollo pasa por combinar lo mejor de ambos mundos: la potencia de la nube cuando hace falta, y la soberanía de lo local cuando importa la privacidad y el control.

Te animamos a que experimentes: instala Ollama, descarga un modelo 7B y pruébalo en tu IDE. Si tu máquina aguanta, sube a 14B o 32B. Compara la experiencia con la de ChatGPT o Claude y decide qué encaja mejor en tu flujo. La IA local no es una sustitución total de la nube; es una herramienta más en tu caja, con ventajas claras en privacidad, coste y latencia. Aprovecharla está en tus manos.

¡A programar, con el cerebro en casa!

Palabras finales

La tecnología avanza rápido. Lo que hoy requiere un MacBook Pro con 16 GB puede que en dos años funcione en un portátil de gama media. Los modelos se comprimen mejor, el hardware se abarata y las herramientas se pulen. Los modelos mejoran, las cuantizaciones se afinan y las herramientas maduran. Lo que no cambia es el valor de tener el control: tus datos, tu infraestructura, tu decisión sobre qué modelo usar y cuándo. Eso no tiene precio, y es lo que la IA local te ofrece. La IA local no es una moda; es una opción estratégica para quienes priorizan privacidad, costes predecibles y autonomía. Esperamos que esta serie te haya dado las herramientas para dar el primer paso —o el siguiente— en ese camino.

Recursos de la comunidad y soporte

La comunidad alrededor de Ollama y los LLMs locales es muy activa. El repositorio de Ollama en GitHub tiene issues y discusiones donde se resuelven dudas técnicas. Para problemas específicos de integración con VSCode o Cursor, los foros de Continue y Cline son útiles. En Reddit, los subreddits r/LocalLLaMA y r/Ollama concentran experiencias de usuarios y comparativas de modelos. Si trabajas en una empresa y necesitas soporte empresarial, algunas distribuciones de Ollama y herramientas como LocalAI ofrecen opciones comerciales.

Referencias y recursos

• Documentación oficial de Ollama
• Continue en VSCode Marketplace
• Cline – Documentación y configuración con Ollama
• LM Studio
• LocalAI
• Open Web
• UI – Frontend para Ollama
• ngrok – Exposición segura de servicios locales
• Guía de requisitos de VRAM para LL Ms (2026)
• Comparativa Ollama vs LM Studio vs LocalAI (2026)
• Mejores LLM para Mac con Apple Silicon (2026)

Tarjeta de referencia rápida

Fin de la serie

Has recorrido el camino completo: por qué local, cómo montarlo y cómo escalarlo con criterio.

¡A programar, con el cerebro en casa!

Despedida

Gracias por acompañar toda la serie. Esperamos que te lleves una hoja de ruta clara para implantar IA local con cabeza técnica, foco en seguridad y resultados medibles. Si lo aplicas por fases, empezarás a notar valor desde la primera semana.