Cómo ejecutar DeepSeek en tu propio servidor: memoria, configuración y privacidad total

Los servicios públicos de LLM son cómodos, pero tienen un fallo estructural: no sabes qué ocurre con tus datos. DeepSeek se puede desplegar en tu propio servidor en la nube. Así, las conversaciones se quedan solo contigo, los bloqueos regionales desaparecen y los costes pasan a ser previsibles.

Por qué migrar a tu propio servidor El problema de las API públicas no es solo el dinero.

Incluso con planes de pago, en la práctica envías tus consultas a una infraestructura ajena sin garantías de confidencialidad. Alibaba, OpenAI y otros proveedores tienen sus propias políticas de uso de datos, y tú no controlas qué pasa con ellos en el servidor. Algunas empresas recogen expresamente en sus ToS el derecho a usar las conversaciones para seguir entrenando sus modelos, salvo que se desactive de forma explícita.

A esto se suma la censura estricta de algunos modelos, que bloquean sin explicación respuestas a consultas perfectamente legítimas de trabajo, y los bloqueos repentinos por geolocalización. Como resultado, cualquier proceso de negocio que dependa de una API pública queda expuesto a decisiones externas del proveedor. El self-hosting resuelve todos estos problemas: Privacidad: las consultas no salen de tu infraestructura Sin censura: el modelo funciona sin restricciones externas de contenido Sin bloqueos regionales: el servicio está disponible desde cualquier país Costes previsibles: solo pagas la instancia en la nube, sin sorpresas en las tarifas * Control total: entrenamiento adicional, fine-tuning e integración en tus propios productos ## Requisitos de memoria y hardware El parámetro clave al elegir la configuración es la cantidad de memoria de vídeo, que depende del tamaño del modelo y del grado de cuantización.

DeepSeek-R1 en su variante 7B con formato Q4 necesita unos 6-8 GB de VRAM, algo que puede asumir incluso una GPU económica en la nube. La versión 14B ocupa 10-12 GB, y la 32B, alrededor de 20 GB. El DeepSeek-V3 completo, con 685 mil millones de parámetros y cuantización de 8 bits, requerirá varios cientos de gigabytes: eso ya es terreno de clústeres de GPU.

Para la mayoría de escenarios de trabajo, las variantes 7B o 14B son las más adecuadas, porque ofrecen un equilibrio razonable entre la calidad de las respuestas y el coste de la infraestructura. También es posible ejecutarlo en CPU, aunque mucho más despacio; el mínimo recomendado es de 32 GB de RAM y un disco NVMe rápido. La cuantización Q4 reduce los requisitos de memoria aproximadamente a la mitad frente a FP16, con una pérdida de calidad mínima.

Cómo ponerlo en marcha y configurarlo La vía más sencilla es **Ollama**.

Se instala con un solo comando en Linux, macOS o Windows, y el modelo se descarga con `ollama pull deepseek-r1:7b`. El servicio levanta automáticamente una API REST en el puerto 11434 con una interfaz compatible con OpenAI, a la que se conectan sin configuración adicional Open WebUI, Cursor, n8n y la mayoría de clientes populares. Para producción con cargas elevadas encaja mejor vLLM: admite batching, peticiones en paralelo y varias GPU a la vez.

llama.cpp ofrece la máxima flexibilidad: funciona en cualquier plataforma, es compatible con todos los formatos de cuantización GGUF y consume un mínimo de recursos. Ambas opciones ofrecen una API compatible con OpenAI.

Hay varios parámetros críticos desde el primer arranque: `context_length`: ajústalo a tus tareas; el valor por defecto suele quedarse corto para diálogos largos `num_threads`: en modo CPU, iguálalo al número de núcleos físicos, no lógicos `gpu_layers`: número de capas del modelo que se descargan en la GPU; se ajusta de forma experimental `temperature` y `top_p`: influyen en el determinismo de las respuestas, algo importante en producción > «La principal ventaja de un LLM self-hosted es la previsibilidad. Sin sorpresas por cortes de acceso, cambios repentinos de política o censura en la próxima actualización».

Qué significa esto El self-hosting de LLM ha dejado de ser cosa de entusiastas.

Hoy, desplegar DeepSeek en un servidor en la nube es cuestión de unas pocas horas, incluso sin una gran experiencia en DevOps. Para las empresas que trabajan con datos confidenciales, ya no es una alternativa a las API públicas, sino una necesidad práctica.