Lo Que Nadie Te Dice de Correr LLMs Locales en Producción

Los tutoriales de “corre tu propio LLM” terminan donde empiezan los problemas reales. Instalar Ollama toma un comando. Descargar un modelo toma minutos. Hacer la primera petición toma segundos. Y en ese punto, el tutorial declara victoria.

Lo que no cubre es qué pasa tres meses después, cuando el servidor corre a 71°C en idle, el swap está al 97%, y nadie recuerda por qué hay cuatro servicios systemd que reinician modelos distintos cada vez que arranca la máquina.

Estas son las lecciones operativas que extrajimos de correr inferencia LLM local en producción sobre una DGX Spark durante meses. No son sobre qué modelo es mejor ni cuál framework usar — son sobre las cosas que salen mal cuando la inferencia deja de ser un experimento y empieza a ser infraestructura.

Anatomía de la deuda técnica en inferencia

Lección 1: Los servicios systemd se acumulan como deuda técnica

Esta fue la causa raíz de nuestra crisis operativa, y es un patrón que sospechamos se repite en muchos equipos que experimentan con múltiples frameworks de inferencia.

Cuando instalamos Ollama, creó un servicio systemd. Cuando configuramos TensorRT-LLM, creamos otro. Cuando probamos vLLM con un modelo diferente, creamos un tercero. Cada vez que una configuración “no funcionaba”, la solución rápida era crear un servicio nuevo en lugar de reemplazar el anterior.

El resultado: servicios en dos niveles de systemd (sistema y usuario) que se reiniciaban al arranque, cargaban modelos distintos, y competían por la misma memoria GPU. Ningún servicio individual era problemático. La combinación era catastrófica.

¿Cómo detectarlo?

La señal más clara no es el consumo de memoria — es la temperatura. Si la GPU está a 70°C+ sin ninguna petición activa, hay procesos consumiendo recursos que no deberían estar corriendo.

El diagnóstico requiere revisar ambas capas:

• Nivel sistema: los archivos en /etc/systemd/system/ que requieren privilegios de administrador
• Nivel usuario: los archivos en ~/.config/systemd/user/ que corren en el espacio del usuario

Una auditoría periódica de servicios activos — no solo los que están “running”, sino los que están “enabled” y se activarán en el próximo reinicio — debería ser parte de cualquier rutina de mantenimiento de servidores de inferencia.

La regla operativa

Cada servidor de inferencia debe tener exactamente un servicio que cargue modelos, en exactamente un nivel de systemd. Todo lo demás debe estar explícitamente deshabilitado, no solo detenido.

La diferencia entre stop y disable es la diferencia entre silenciar un problema y resolverlo. Un servicio detenido se reactiva en el siguiente reinicio. Un servicio deshabilitado no.

Lección 2: Ollama carga modelos sin pedir permiso

Ollama tiene una característica que es conveniente para desarrollo y problemática para producción: cuando un servicio hace una petición para un modelo que no está en memoria, Ollama lo carga automáticamente. Si no tiene espacio, intenta liberar memoria descargando otros modelos.

En un servidor dedicado exclusivamente a experimentación, esto es razonable. En un servidor de producción donde otros servicios (base de datos vectorial, proxy RAG, servicio de aplicación) dependen de memoria disponible, un modelo de 47 GB que se carga “de golpe” puede temporalmente desplazar servicios críticos.

El problema se amplifica cuando hay múltiples aplicaciones que usan modelos diferentes. Si la aplicación A usa un modelo de 47 GB y la aplicación B usa un modelo de 5 GB, y ambas tienen peticiones espaciadas, Ollama puede entrar en un ciclo de carga-descarga-recarga que consume más recursos en gestión de memoria que en inferencia útil.

La alternativa operativa

Motores como TensorRT-LLM, vLLM y SGLang usan un modelo de memoria pre-alocada: se reserva un bloque fijo de memoria al inicio y no se toca después. Esto hace que el consumo de memoria sea completamente predecible y permite planificar el presupuesto de recursos del servidor con exactitud.

La predecibilidad es más valiosa que la flexibilidad en producción.

Lección 3: El swap es un indicador silencioso de deuda técnica

En la mayoría de los servidores Linux, el swap está configurado y nadie piensa en él. Para servidores de inferencia, el swap es un indicador crítico que debería monitorearse activamente.

Cuando la memoria disponible no alcanza para todos los procesos, Linux mueve páginas de memoria al disco (swap). Para procesos normales, esto degrada el rendimiento ligeramente. Para inferencia LLM, donde los patrones de acceso a memoria son masivos y pseudo-aleatorios, el swap causa una degradación catastrófica: cada token generado puede requerir acceder a pesos del modelo que fueron movidos al disco, convirtiendo operaciones de nanosegundos en operaciones de milisegundos.

En nuestro caso, el swap a 15.6 de 16 GB no solo degradaba la inferencia — degradaba todo el sistema, incluyendo la base de datos vectorial y los servicios de aplicación que compartían la máquina.

La regla operativa

Para servidores de inferencia LLM, el swap usado debería estar por debajo del 5% de la capacidad. Cualquier valor superior es síntoma de que la combinación de servicios excede la memoria disponible y requiere intervención.

Mejor aún: configurar alertas automáticas que detecten swap creciente antes de que llegue a niveles críticos.

Lección 4: El hardware de oficina necesita protección térmica

Las DGX Spark y otros sistemas de inferencia diseñados para oficina (no datacenter) operan sin la refrigeración industrial que tienen los racks de servidores. La temperatura ambiente, la ventilación de la oficina, y la posición física del equipo afectan directamente el rendimiento térmico.

Cuando nuestra DGX estaba a 71°C en idle, no solo era un problema de eficiencia — era un riesgo de daño al hardware. Los componentes electrónicos tienen umbrales de temperatura que, una vez superados de forma sostenida, aceleran la degradación.

La solución: un watchdog térmico

Implementamos un servicio systemd (dgx-monitor.service) que monitorea dos métricas y actúa automáticamente:

1. Temperatura GPU ≥ 80°C: mata el proceso de inferencia LLM, permitiendo que la GPU se enfríe
2. Swap ≥ 15%: mata el proceso de inferencia LLM, liberando memoria

El watchdog no es sofisticado — es un script que corre cada 30 segundos, lee las métricas del sistema, y toma una decisión binaria. Pero es la diferencia entre un servidor que se protege a sí mismo y uno que corre hasta fallar.

¿Qué monitorear?

Para cualquier servidor de inferencia fuera de un datacenter, las métricas mínimas de monitoreo son:

• Temperatura GPU (idle y carga)
• Utilización GPU (idle debería ser ~0%)
• Swap usado (debería ser < 5%)
• Memoria total consumida vs. disponible
• Temperatura ambiente del espacio donde está el equipo

Lección 5: La API que elijas hoy es la deuda de migración de mañana

Cuando Ollama era nuestro motor principal de inferencia, tres aplicaciones estaban acopladas a su API nativa (/api/generate). Cuando decidimos migrar a TRT-LLM, cada una de esas aplicaciones necesitó cambios de código: nuevo formato de petición, nuevo parsing de respuesta, nuevos nombres de parámetros.

El volumen total fue modesto — 6 archivos, unas 160 líneas — pero el esfuerzo no fue cero. Y si hubiéramos tenido 20 aplicaciones en lugar de 4, el costo de migración habría sido proporcionalmente mayor.

La regla operativa

La API OpenAI-compatible (/v1/chat/completions) se ha convertido en el estándar de facto de la industria. La soportan TensorRT-LLM, vLLM, SGLang, Ollama (como opción), LiteLLM, y prácticamente todos los motores de inferencia relevantes.

Construir sobre esta API desde el inicio — incluso si el motor subyacente es Ollama — reduce el costo de migración futura a cambiar una variable de entorno. Es una de esas decisiones que no cuesta nada tomar correctamente y cuesta linealmente no haberla tomado.

Lección 6: Los modelos con “pensamiento” necesitan post-procesamiento

Los modelos recientes de lenguaje — Qwen3, DeepSeek-R1, y otros inspirados por el paradigma de chain-of-thought — generan tags de razonamiento interno (<think>...</think>) antes de la respuesta final. Este razonamiento mejora la calidad de la respuesta pero no debería llegar al usuario final ni a los sistemas que consumen la API.

En nuestra arquitectura, el proxy RAG ya eliminaba estos tags automáticamente. Pero las aplicaciones que llamaban directamente al motor de inferencia recibían el razonamiento completo, lo que causaba problemas en parsing de JSON, en la presentación al usuario, y en el conteo de tokens.

La regla operativa

Cualquier pipeline que consuma un modelo con modo de pensamiento necesita un paso de post-procesamiento que elimine los tags de razonamiento. Este paso debe existir en exactamente un lugar: o en un proxy centralizado (preferible) o en cada cliente individual (más frágil).

La implementación es trivial — un regex — pero la ausencia de este paso produce errores sutiles que son difíciles de diagnosticar porque la respuesta “casi funciona”: el contenido está ahí, solo que precedido por texto inesperado que rompe el parsing.

Lección 7: Documenta la arquitectura antes de que la olvides

Esta lección no es técnica — es organizacional. Cuando configuramos la DGX por primera vez, todo el conocimiento sobre qué servicios corrían, en qué puertos, con qué modelos, estaba en la cabeza de quien lo configuró. Cuando meses después necesitamos diagnosticar por qué el servidor se sobrecalentaba, el primer paso fue reconstituir ese conocimiento.

La regla operativa

Todo servidor de inferencia debería tener, como mínimo:

• Un inventario de servicios activos con sus puertos y modelos
• Un mapa de quién consume qué endpoint
• Un presupuesto de memoria que sume todos los servicios y confirme que cabe en el hardware
• Un procedimiento documentado para agregar, cambiar o eliminar modelos

No necesita ser un documento elaborado. Necesita existir.

Conclusión

La inferencia local de LLMs pasó de ser un hobby de entusiastas a ser infraestructura de producción para organizaciones reales. Pero el ecosistema de tooling y las prácticas operativas no han madurado al mismo ritmo.

Las lecciones documentadas aquí — servicios fantasma, carga dinámica impredecible, swap silencioso, ausencia de protección térmica, acoplamiento a APIs propietarias, post-procesamiento de thinking tags, y documentación inexistente — no son problemas teóricos. Son los problemas que encontramos y resolvimos en producción.

La brecha entre “instalar un LLM local” y “operar un LLM local en producción” es comparable a la brecha entre “escribir un script” y “operar un servicio en producción”. Las mismas disciplinas que la industria desarrolló para DevOps — monitoreo, alertas, documentación, presupuestos de recursos, estandarización de interfaces — aplican con la misma urgencia a la infraestructura de IA.

---

Referencias

• NVIDIA. (2025). DGX Spark Operations Guide. NVIDIA Developer Documentation.
• NVIDIA. (2025). TensorRT-LLM: Deployment Best Practices. NVIDIA Technical Blog.
• Ollama. (2025). Memory Management and Model Loading. Ollama Documentation.
• Red Hat. (2024). systemd Service Management: Best Practices. Red Hat Enterprise Linux Documentation.
• Qwen Team. (2025). Qwen3 Technical Report. Alibaba Cloud.