Cómo desplegar un LLM local sin afectar el almacenamiento ni las aplicaciones

Desplegar un LLM local en un NAS doméstico no es difícil porque el primer comando sea complicado. Es difícil porque el modelo, caché, contenedor, servidor API y trabajos en segundo plano compiten con el mismo almacenamiento y recursos del sistema que su NAS ya usa para archivos, copias de seguridad, medios, bases de datos y aplicaciones.

El objetivo más seguro no es hacer que el LLM sea lo más rápido posible desde el primer día. El objetivo más seguro es darle una ruta de almacenamiento conocida, límites estrictos de recursos, paralelismo limitado y una rutina de verificación. Un modelo local un poco más lento suele ser mejor que uno rápido que llena la unidad del sistema, provoca presión de memoria o hace que otras aplicaciones autoalojadas sean poco fiables.

Resumen rápido: Dé al LLM su propio espacio y límites

Un LLM local debe tener su propio espacio antes de tener su primer modelo. Eso significa que debe saber dónde vivirán los archivos del modelo, cachés, índices, registros y datos de la aplicación antes de ejecutar una descarga de modelo o conectar una WebUI. Si esos archivos se almacenan dentro de una ruta oculta de Docker o en una unidad de arranque pequeña, el despliegue puede parecer exitoso mientras consume silenciosamente espacio necesario para el NAS.

También necesita límites. Los tiempos de ejecución de LLM pueden usar mucha RAM, VRAM, hilos de CPU y memoria de contexto, especialmente cuando se habilitan múltiples modelos o solicitudes paralelas. Las restricciones de recursos de Docker explican que los contenedores pueden usar recursos del host según lo permita el planificador del kernel, y la presión de memoria puede provocar comportamientos de falta de memoria que afectan a otros procesos.

Para un NAS compartido, eso importa más que los números máximos de referencia. Plex, Jellyfin, Home Assistant, bases de datos, trabajos de sincronización, copias de seguridad y compartición de archivos no deben volverse inestables porque un servidor de modelos intenta responder a un solo prompt largo. Un despliegue seguro de un LLM local comienza con el mapeo de almacenamiento, límites de recursos, elección del modelo y verificación.

Qué confirmar antes de descargar el primer modelo

Antes de descargar el primer modelo, defina el primer trabajo. Un LLM local usado para chat ligero tiene requisitos diferentes a un asistente RAG, un trabajador de incrustaciones, un ayudante de codificación o un agente de automatización que puede leer y escribir archivos. Si no define primero el caso de uso, es fácil descargar un modelo que sea demasiado grande, lento o disruptivo para el servidor.

Comience con estas comprobaciones:

• Casos de uso: chat, RAG, incrustaciones, resumen, automatización, codificación o asistencia en búsquedas.
• Tamaño del modelo: qué tan grande es el archivo del modelo y si mantendrá múltiples variantes.
• Cuantización: si el modelo está lo suficientemente comprimido para el servidor.
• Ruta de almacenamiento: dónde vivirán los archivos de modelos y caché en el host.
• Ruta del contenedor: cómo se mapea la ruta del host dentro del contenedor.
• RAM y VRAM: cuánta memoria queda para otras aplicaciones.
• Capacidad de CPU: cuántos hilos puede usar el modelo sin afectar al NAS.
• Paralelismo: cuántas solicitudes o modelos cargados pueden ejecutarse a la vez.
• Carga de trabajo existente: respaldos, transmisión de medios, bases de datos, sincronización y compartición de archivos.
• Plan de verificación: cómo demostrará que el NAS sigue saludable después.

Este paso previo no es trabajo inútil. Previene el problema local más común en el despliegue de LLM en un NAS: el modelo responde, pero el sistema a su alrededor se vuelve menos confiable.

Mantenga los archivos de modelos fuera de la unidad del sistema

Los archivos de modelos pueden crecer más rápido de lo esperado. Un solo modelo puede ser manejable, pero varios modelos, variantes de cuantización, embeddings, índices, datos de WebUI y registros pueden convertirse rápidamente en decenas o cientos de gigabytes. Si esos archivos se almacenan en la unidad del sistema o en la raíz de Docker, el NAS puede quedarse sin espacio crítico incluso cuando el pool de almacenamiento principal aún parece saludable.

Las preguntas frecuentes de Ollama enumeran las ubicaciones predeterminadas de modelos para diferentes sistemas operativos y explican que el directorio de almacenamiento de modelos puede cambiarse con la variable de entorno OLLAMA_MODELS. En un NAS o servidor doméstico, ese detalle es importante porque la ruta predeterminada puede no ser donde desea que vivan los archivos de modelos a largo plazo.

Si ejecuta Ollama u otro motor de modelos en Docker, recuerde que una ruta de contenedor no es lo mismo que una ruta del host. Un directorio como /root/.ollama dentro del contenedor debe mapearse a una ubicación deliberada en el host si desea un almacenamiento predecible. Sin un mapeo de volumen, los archivos del modelo pueden permanecer dentro del almacenamiento gestionado por Docker, lo que dificulta ver el crecimiento y limpiarlo.

Un patrón más seguro es crear un directorio dedicado para modelos antes del despliegue, como una carpeta de almacenamiento de IA en un pool de datos o volumen de almacenamiento de aplicaciones. Manténgalo separado de los destinos de respaldo, bases de datos críticas y datos irremplazables de aplicaciones. El directorio de modelos debe ser lo suficientemente grande, fácil de inspeccionar y documentado para que pueda eliminar modelos antiguos más adelante.

También decide dónde vivirán los archivos relacionados. Los índices RAG, embeddings, bases de datos vectoriales, registros y documentos subidos pueden convertirse en consumidores de almacenamiento separados. Si solo planeas para el archivo del modelo, el resto de la pila de IA aún puede sorprenderte.

Establece límites de memoria, CPU y paralelismo

Límites de memoria

Los LLM locales consumen mucha memoria. Necesitan memoria para los pesos del modelo, el contexto, la sobrecarga en tiempo de ejecución y a veces múltiples modelos cargados. Si el servidor también ejecuta bases de datos, servicios de medios, sincronización de archivos, contenedores y trabajos de respaldo, no se debe permitir que el LLM consuma toda la memoria disponible.

Docker soporta límites de memoria para contenedores que pueden evitar que un contenedor acapare el host. Para un NAS compartido, esto tiene menos que ver con hacer que el modelo sea más rápido y más con proteger el resto del sistema. Si el contenedor del LLM alcanza su propio límite, eso suele ser mejor que permitir que todo el servidor sufra presión de memoria.

Deja espacio para los servicios principales. Si el NAS tiene 32 GB de RAM y las aplicaciones normales usan entre 8 GB y 12 GB durante los períodos de mayor actividad, no le des el resto al LLM. Deja espacio para la caché del sistema de archivos, trabajos de respaldo, bases de datos y picos cortos. Un modelo que solo funciona cuando no hay nada más en ejecución no es una opción segura para un servidor doméstico compartido.

La VRAM también es importante cuando se usa inferencia con GPU. Las preguntas frecuentes de Ollama explican que la inferencia con CPU usa la memoria del sistema, mientras que la inferencia con GPU usa VRAM, y que la carga concurrente de modelos depende de la memoria o VRAM disponible. Eso significa que una GPU puede ayudar mucho, pero no elimina la necesidad de un plan de memoria.

Límites de CPU

Los límites de CPU protegen la capacidad de respuesta. Un LLM local puede usar muchos hilos durante el procesamiento de indicaciones o la generación de tokens. Si satura la CPU, el panel del NAS puede retrasarse, las transmisiones de medios pueden almacenar en búfer, las automatizaciones pueden demorarse y las bases de datos pueden responder lentamente.

Docker proporciona controles de CPU como --cpus, --cpu-quota, y --cpuset-cpusNo siempre necesitas límites agresivos, pero debes decidir cuánto CPU se le permite usar al LLM durante la actividad normal del NAS. Un modelo que tarda un poco más en responder mientras mantiene el servidor receptivo suele ser una mejor opción que uno que consume todos los hilos.

La inferencia solo con CPU es especialmente sensible a los límites. Sin una GPU o NPU, el LLM compite directamente con todos los demás servicios que dependen de la CPU. Si el NAS ya maneja transcodificación de medios, indexación, compresión, copias de seguridad o bases de datos, el LLM no debería ejecutarse sin restricciones durante las horas pico.

Cantidad de modelos y solicitudes paralelas

El paralelismo es fácil de pasar por alto. Un solo modelo respondiendo a un solo prompt puede estar bien. Múltiples usuarios, una WebUI, un flujo de trabajo de automatización y una herramienta RAG pueden crear rápidamente solicitudes apiladas. Cada solicitud puede añadir memoria de contexto y carga de CPU.

Las preguntas frecuentes de Ollama describen solicitudes paralelas y el comportamiento de modelos cargados, incluyendo configuraciones como OLLAMA_MAX_LOADED_MODELS, OLLAMA_NUM_PARALLEL y OLLAMA_MAX_QUEUE. Estas configuraciones importan en un NAS porque la concurrencia puede convertir un despliegue estable de un solo usuario en un pico de recursos.

Para un servidor doméstico compartido, comienza con límites conservadores. Un modelo cargado y una solicitud activa es una base más segura. Aumenta solo después de confirmar que el almacenamiento, la memoria, la CPU y otros servicios permanecen estables.

Elige un modelo que coincida con el servidor, no con el bombo publicitario

El primer modelo adecuado no es el modelo más grande que puedas descargar. Es el modelo más pequeño que pueda completar la tarea con calidad aceptable. En un NAS, la elección del modelo es parte de la protección del sistema.

Los modelos cuantizados suelen ser el punto de partida práctico. llama.cpp documenta cómo los modelos cuantizados reducen la precisión del peso del modelo, como convertir archivos de modelo GGUF de mayor precisión en formatos más pequeños. Esto puede reducir el tamaño del modelo y mejorar la inferencia práctica, pero también puede implicar compromisos de calidad.

Esa compensación suele ser aceptable para muchos casos de uso de NAS doméstico: chat simple, resumen, embeddings, asistencia RAG, organización de archivos y pequeños ayudantes de automatización. Es menos aceptable si la tarea requiere razonamiento profundo, contexto largo, rendimiento multiusuario o alta precisión en codificación.

Usa la condición del servidor como punto de partida:

Una implementación segura comienza pequeña porque te da una base estable. Después de eso, puedes probar un modelo más grande, un contexto más largo o una integración WebUI. Si el sistema se vuelve lento, sabrás qué cambio causó el problema.

Mantén el LLM alejado de aplicaciones críticas y copias de seguridad

Un LLM local no debe compartir límites de fallo con los servicios de los que dependes más. Si el almacenamiento del modelo de IA, las copias de seguridad, las bases de datos de aplicaciones y los archivos temporales viven en la misma ubicación mal planificada, una carga de trabajo puede crear problemas para el resto.

Mantén la caché de modelos y los datos temporales de IA alejados de los destinos de respaldo. Un directorio de modelos suele ser reproducible; un repositorio de respaldo no. Llenar un destino de respaldo con archivos de modelos o datos temporales de IA puede causar copias de seguridad perdidas, trabajos de sincronización fallidos o puntos de restauración confusos.

Mantén las bases de datos de las aplicaciones separadas cuando sea posible. Home Assistant, servidores multimedia, bibliotecas de fotos, gestores de contraseñas y otras aplicaciones autoalojadas pueden depender de bases de datos pequeñas que no toleran presión repentina de E/S o poco espacio en disco. No permitas que una descarga grande de modelos o un trabajo de indexación RAG ocupe el mismo espacio de almacenamiento sin planificación.

También considera el tiempo. Si las copias de seguridad se ejecutan por la noche, no programes indexación pesada en la misma ventana. Si la transmisión de medios ocurre por la tarde, no ejecutes inferencia de contexto largo solo con CPU en ese momento. Un NAS suele tener suficiente capacidad para varios trabajos, pero no todos en sus picos.

Para flujos de trabajo LLM que pueden escribir archivos o llamar herramientas, añade medidas de seguridad. Usa rutas en sandbox, pasos de confirmación y registros. Deja que el modelo sugiera acciones, pero usa código determinista o confirmación del usuario para escrituras, eliminaciones, movimientos y cambios en la aplicación. Una implementación segura de LLM protege no solo los recursos del sistema, sino también los datos que puede tocar.

Señales de advertencia de que el LLM está privando a otros servicios

Una mala implementación no siempre falla de inmediato. Más a menudo, crea síntomas que al principio parecen no estar relacionados.

Una señal de advertencia es el crecimiento repentino del disco. Si la unidad del sistema, la raíz de Docker o el almacenamiento de la aplicación crecen rápidamente después de descargar modelos, la ruta del modelo puede no estar mapeada donde esperabas. Revisa la ruta real del host, no solo la ruta del contenedor.

Los reinicios de contenedores son otra señal. Si el contenedor LLM, la base de datos, Home Assistant, el servidor multimedia o la WebUI se reinician constantemente, revisa la presión de memoria, los registros OOM y la saturación de CPU. El LLM puede mantenerse activo mientras otros servicios pierden recursos.

Un panel de control NAS lento también importa. Si la interfaz web se vuelve lenta durante las indicaciones, el LLM local puede estar usando demasiados hilos de CPU, demasiada memoria o demasiada E/S de disco. Que el modelo responda correctamente no significa que la implementación esté saludable.

El almacenamiento en búfer de medios, las automatizaciones retrasadas, las comparticiones de archivos lentas y las ventanas de respaldo perdidas son señales más fuertes. Estas son tareas centrales del NAS. Si se degradan después de desplegar el LLM, el LLM necesita un modelo más pequeño, límites más estrictos, mejor programación o un host de cómputo separado.

Observe también el comportamiento de la API. Si la API del LLM se cuelga, se queda en cola indefinidamente o se vuelve poco confiable cuando se conecta una WebUI, herramienta RAG o sistema de automatización, el paralelismo puede ser demasiado alto para el servidor. Limite los modelos cargados, las solicitudes activas y la longitud de la cola antes de agregar más integraciones.

Un orden de implementación más seguro para LLM local en NAS

No comience instalando todas las herramientas de IA a la vez. Empiece con un servicio LLM local, un modelo, una ruta de almacenamiento y un caso de uso de prueba. Esto hace que la implementación sea más fácil de entender y más segura para depurar.

Un orden de implementación más seguro es así:

1. Seleccione un caso de uso, como chat ligero, incrustaciones o prueba RAG.
2. Elija el modelo más pequeño que pueda hacer el trabajo.
3. Cree un directorio dedicado para el modelo en una ruta de almacenamiento conocida.
4. Mapee ese directorio dentro del contenedor o configure el ejecutor para usarlo.
5. Establezca límites de memoria y CPU.
6. Limite las solicitudes paralelas y los modelos cargados.
7. Comience con un comando de prueba o un índice RAG pequeño.
8. Observe el disco, RAM, CPU, GPU, registros y tiempo de respuesta durante la ejecución.
9. Confirme que las aplicaciones y copias de seguridad existentes sigan funcionando normalmente.
10. Solo entonces agregue integraciones como Open WebUI, herramientas RAG o flujos de trabajo de automatización.

Este orden puede parecer más lento que una guía rápida de instalación, pero reduce sorpresas. Si algo falla, sabrá si el problema provino del modelo, la ruta, los límites de recursos, la WebUI, el índice RAG u otra integración.

Cómo verificar que el almacenamiento y las aplicaciones siguen seguros

La verificación no debe detenerse en “el modelo respondió”. Un LLM local puede responder a un comando mientras llena el disco equivocado, agota otros contenedores o retrasa trabajos de respaldo.

Comience con la verificación del almacenamiento. Confirme que los archivos del modelo se ubicaron en la ruta esperada del host. Verifique que la unidad del sistema aún tenga espacio libre. Compruebe que la raíz de Docker no haya crecido inesperadamente. Confirme que la caché del modelo, los registros, los índices y los datos de la aplicación no estén mezclados con copias de seguridad críticas o bases de datos.

Luego revise los recursos. La CPU debería volver a la normalidad después de los comandos o la indexación. La memoria debe mantenerse por debajo del límite que planificó. El intercambio (swap) no debería crecer bajo uso normal. Si la inferencia por GPU está habilitada, verifique que el modelo realmente use la GPU y que la presión sobre la VRAM sea aceptable.

Verifique a continuación la estabilidad de la aplicación. Abra comparticiones de archivos, transmita medios, active una automatización de Home Assistant, navegue por el panel del NAS y confirme que las bases de datos o paneles de la aplicación siguen respondiendo. Si estos servicios se retrasan solo mientras el LLM está activo, necesita límites más estrictos de CPU, memoria o programación.

Revisa los registros. Busca bucles de reinicio, mensajes OOM, cargas fallidas de modelos, errores de permisos, falta de acceso a GPU, fallos en el montaje de volúmenes y tiempos de espera repetidos en la API. Los registros suelen ser donde una implementación “funcionando” revela que apenas es estable.

Finalmente, verifica el límite del endpoint. Si el servidor del modelo expone una API, sabe dónde es accesible. Un endpoint LLM local no debe volverse público por accidente. Mantenlo interno a menos que lo hayas colocado intencionalmente detrás de autenticación, reglas de proxy inverso, acceso VPN u otro límite controlado.

Cómo ZimaOS AI Search Muestra un Patrón de Implementación AI Controlada

Un flujo de trabajo AI en NAS controlado debe tener una ruta de modelo definida, requisitos de recursos, expectativas de tiempo de ejecución y una ruta de verificación. No debe comportarse como un servicio en segundo plano ilimitado que descarga modelos, consume tiempo de GPU y escribe datos donde quiera.

ZimaOS-AI es un ejemplo útil de este patrón controlado. La guía de ZimaSpace para búsqueda AI explica que el módulo está diseñado para servir a la búsqueda de ZimaOS usando un LLM local para extraer características de imágenes, audio y video. Ese enfoque es importante: la carga de trabajo de IA soporta la búsqueda y extracción de características en lugar de convertir el NAS en un servidor de chat sin restricciones.

La misma guía hace visible el límite de recursos. Describe rutas de instalación separadas para sistemas con GPU discreta NVIDIA y sistemas con GPU integrada Intel. La ruta NVIDIA depende del soporte de GPU compatible con CUDA, mientras que la ruta de GPU integrada Intel requiere al menos 8GB de RAM libre y recomienda un CPU i5-1235U o superior con gráficos integrados. También lista al menos 20GB de espacio libre en el sistema y señala que los archivos del modelo se almacenan bajo /media/ZimaOS-HD/AppData/.models a menos que AppData haya sido migrado.

Ese es el tipo de información que una implementación segura de LLM necesita antes de comenzar. Un dispositivo de nube privada como ZimaCube 2 AI NAS puede soportar flujos de trabajo de IA local más completos cuando la ruta del modelo, el soporte de GPU o iGPU, la RAM, el espacio de almacenamiento y la programación coinciden con la carga de trabajo. Pero la lección importante es el límite, no el nombre de la marca: conoce dónde vive el modelo, qué ruta de hardware usa y cuándo se le permite consumir recursos.

Los detalles para la solución de problemas también muestran cómo es la verificación del despliegue. Si la búsqueda AI no devuelve resultados relacionados con AI, el modelo puede estar aún descargándose, la extracción de características puede estar en curso, el acceso a Hugging Face puede no estar disponible o la VRAM puede ser demasiado baja y forzar la caída a CPU/memoria. La guía también orienta a los usuarios hacia el Historial de Llamadas, tráfico de red y journalctl -xef -u zimaos-ai para verificar el estado.

Ese es un patrón útil para cualquier despliegue local de LLM en un NAS: define la ruta, define los recursos, revisa los registros, confirma que la función realmente funciona y programa la actividad pesada para que el NAS siga siendo usable.

Preguntas frecuentes

¿Dónde debería almacenar los archivos del modelo LLM local en un NAS?

Almacena los archivos del modelo en un directorio dedicado y documentado para modelos en un volumen de datos o ubicación de almacenamiento de aplicaciones con suficiente espacio. Evita que los modelos se guarden silenciosamente en la unidad de arranque, la raíz de Docker o un destino de respaldo. La ruta debe ser fácil de inspeccionar, limpiar y migrar.

¿Debería ejecutar Ollama directamente o en Docker?

Cualquiera puede funcionar. Docker facilita el aislamiento y el despliegue, pero debes mapear correctamente el almacenamiento del modelo y establecer límites de recursos. Una instalación directa puede ser más simple en algunos sistemas, pero aún necesitas confirmar el directorio del modelo, permisos, uso de memoria y límites del servicio.

¿Cuánta RAM debería reservar para otras aplicaciones?

Reserva suficiente RAM para el sistema operativo del NAS, caché del sistema de archivos, bases de datos, servicios multimedia, copias de seguridad y contenedores normales antes de asignar memoria al LLM. No dimensione el modelo según la RAM total. Dimensione según la RAM disponible después de que los servicios principales tengan margen.

¿Puede un LLM local romper mis otros contenedores Docker?

Puede interrumpirlos si consume demasiada memoria, CPU, E/S de disco o espacio de almacenamiento. Puede que no los “rompa” directamente, pero puede causar lentitud, ciclos de reinicio, eventos OOM, ventanas de respaldo perdidas o fallos en operaciones de base de datos si se despliega sin límites.

¿Cuándo debería mover el LLM a una máquina separada?

Mueve el LLM a una máquina separada cuando necesites modelos más grandes, contexto largo, múltiples usuarios, cargas de trabajo intensivas en GPU o respuestas rápidas que hagan que el NAS se vuelva lento. En esa configuración, el NAS puede seguir siendo el almacenamiento y la fuente de datos mientras un escritorio con GPU, mini PC o servidor AI maneja la inferencia.

Un despliegue seguro de un LLM local en un NAS comienza con límites, no con el bombo del modelo. Dale al modelo una ruta conocida, establece límites de recursos para el contenedor, protege las aplicaciones críticas y las copias de seguridad, y verifica todo el servidor después del primer comando. El despliegue solo es exitoso cuando el LLM funciona y el NAS sigue comportándose como un NAS confiable.