Lo confidencial, en tu propio Qwen y sin riesgos.

Datos que no puedes pegar en una IA externa: ¿te pasa esto?

Sabes que con IA iría más rápido. Pero esa conversación no puede salir de la empresa.

Como no puede salir, no se usa IA. Entre esas dos opciones hay una tercera: ejecutarla en tu propio servidor.

* Los casos 1 y 2 se basan en ejemplos contados en vídeos explicativos (Lo que cuentan los vídeos).

Lo que querías: lo confidencial, en el Qwen de tu empresa

Los mismos documentos, las mismas reuniones. La IA ayuda y los datos no salen de la empresa.

Todo esto se consigue con los pasos y la checklist de esta página. Cómo repartir también la organización del trabajo tras la reunión está en Qué papel tiene SIMY.

Qué es un LLM local y por qué ejecutar Qwen en tu empresa

Un LLM local consiste en ejecutar los pesos publicados de un modelo en tu propio PC o en un servidor de la empresa. El texto que introduces no sale de esa máquina.

Qué puedes hacer con un LLM local

• Resumir y redactar documentos confidenciales: actas, contratos, especificaciones de diseño, comunicaciones con clientes.
• Buscar y preguntar sobre documentos internos (RAG): le das normativas y manuales internos y responde preguntas.
• Traducción y ayuda con código: traducir entre chino, inglés y español, explicar código interno o proponer cambios.

Los modelos pequeños no son tan capaces como los grandes modelos en la nube. Si los usas para hacer un «primer borrador» y no la versión final, habrá menos sorpresas.

Por qué Qwen

• Hay modelos Apache 2.0
• Multilingüe, español incluido
• Tamaños a elegir

• Licencia: muchos modelos, como Qwen3 o Qwen3.8-27B, se publican con Apache 2.0. Pero no todos (ver la tabla de abajo).
• Idiomas: en el anuncio de la generación Qwen3 se mencionan 119 idiomas y dialectos, entre ellos el español.
• Tamaño: desde 0,6B–8B, que funcionan en un PC, pasando por 27B–32B, que cuantizados caben en una sola GPU, hasta 235B, que necesita varias GPU.

La licencia cambia según el modelo

Puedes desplazar la tabla en horizontal →

Verificado el 1 de octubre de 2026 en la información de modelos de la organización Qwen en Hugging Face. No es cierto que «todo Qwen sea Apache 2.0». Antes de un uso comercial, revisa con tu equipo legal el archivo LICENSE del repositorio del modelo que vayas a usar.

Elegir motor: Ollama, llama.cpp, vLLM, SGLang o LM Studio

El software que ejecuta el modelo es el «motor de inferencia». En seguridad, la mayor diferencia es dónde escucha si no tocas nada.

Puedes desplazar la tabla en horizontal →

Verificado en la documentación oficial de cada proyecto (en vLLM, también en el código fuente) en octubre de 2026. En la fila de LM Studio, lo que no pudimos verificar del todo figura como «Consultar la documentación oficial».

• Para comprobar primero: llama.cpp u Ollama, para ver si sirve para tu trabajo.
• Para toda la empresa: vLLM. Mantiene la velocidad aunque lo usen muchas personas a la vez.
• Agentes que envían muchas veces las mismas instrucciones largas: SGLang.

Ojo con vLLM: su página oficial de Security explica que --api-key solo protege rutas como /v1, y que /invocations o /pooling, entre otras, quedan fuera. Por eso la propia documentación considera que lo más eficaz es ponerlo detrás de un proxy inverso que deje pasar solo los endpoints que quieras publicar.

Hardware: memoria de GPU necesaria según el modelo de Qwen

La memoria de GPU necesaria se calcula como una suma de tres partes.

• PesosNúmero de parámetros × bytes por parámetro (BF16: 2, FP8: 1, 4 bits: ~0,5)
• + Caché KVProporcional a la longitud del contexto × usuarios simultáneos
• + MargenEspacio de trabajo en ejecución

Puedes desplazar la tabla en horizontal →

Los valores de Qwen3 son los del benchmark de velocidad oficial de Qwen (memoria de GPU justo tras el arranque, procesando una entrada corta con transformers). Para Qwen3.8-27B no hay tabla oficial, así que son estimaciones calculadas a partir de los parámetros y un caso medido por un particular, sin la caché KV. La cantidad necesaria cambia mucho según la cuantización y la longitud del contexto (octubre de 2026).

• Qwen3.8-27B y una GPU de 32 GB: en BF16 solo los pesos ocupan ~54 GB (estimación), así que no cabe en una RTX 5090 (32 GB). La versión FP8 oficial ocupa ~28,8 GB solo en pesos, y se ha publicado un cálculo según el cual con el contexto al máximo no entra en 32 GB. Se ajusta usando una versión de 4 bits o bajando el límite de contexto.
• Dos GPU de 16 GB no equivalen a una de 32 GB: al repartir, se pierde por la comunicación entre tarjetas y por el espacio de trabajo que necesita cada una.
• Los contextos largos alargan la espera: en un caso medido por un particular, con una entrada de ~250 000 tokens, el primer carácter tardó más de 4 minutos.
• Mac: en Apple Silicon la memoria se comparte con la GPU. Necesitas bastante más memoria que el tamaño del archivo del modelo.

Cómo dimensionar: decide primero cuántas personas lo usarán a la vez y qué longitud tendrán los documentos de cada consulta. La caché KV crece en proporción a ambos, así que si solo cuentas los pesos, te quedarás corto en producción.

Montaje en red aislada: Qwen + vLLM en un servidor interno

El ejemplo usa la versión FP8 de Qwen3.8-27B con vLLM (Docker) en un servidor Linux. Los comandos siguen la documentación oficial de octubre de 2026. Si no te llega la memoria de GPU, baja el límite de contexto (--max-model-len) o elige una versión de 4 bits.

* Arquitectura de ejemplo con fines ilustrativos

Cómo leer los comandos: sustituye lo que va entre ángulos, como <SHA-del-commit-verificado>, por los valores de tu empresa. Los números de versión son ejemplos de octubre de 2026.

1. Descargar el modelo con la versión fijada

   Equipo de entrada (lado internet)

   Descarga del repositorio de la organización oficial Qwen/, indicando el commit. Guarda también el contenedor del motor de inferencia con la versión fijada.

   bash

   pip install -U huggingface_hub
   hf download Qwen/Qwen3.8-27B-FP8 \
     --revision <SHA-del-commit-verificado> \
     --local-dir ./Qwen3.8-27B-FP8
   
   docker pull vllm/vllm-openai:v0.30.0
   docker inspect --format '{{index .RepoDigests 0}}' vllm/vllm-openai:v0.30.0
   docker save vllm/vllm-openai:v0.30.0 -o vllm-openai-v0.30.0.tar

   Copia en el registro el digest que muestra docker inspect (el valor que empieza por sha256:).

   Por qué fijar la versión: en un mismo repositorio, una revisión nueva puede cambiar el contenido. Se ha contado el caso de una versión cuantizada cuya revisión nueva eliminó las capas de decodificación especulativa (MTP), y la aceleración dejó de activarse.

2. Crear el registro de SHA-256

   Equipo de entrada

   El lfs.oid que devuelve la API de Hugging Face es el SHA-256 de los archivos grandes (LFS). Compara ese valor con tus archivos locales.

   bash

   # Extraer los valores de Hugging Face (solo archivos LFS)
   curl -s "https://huggingface.co/api/models/Qwen/Qwen3.8-27B-FP8/tree/<SHA-del-commit-verificado>?recursive=true&expand=true" \
     | jq -r '.[] | select(.lfs) | "\(.lfs.oid)  ./\(.path)"' > HF.sha256
   
   # Comparar con los archivos locales y crear el registro de todos los archivos
   cd Qwen3.8-27B-FP8
   sha256sum -c ../HF.sha256
   find . -type f ! -path './.cache/*' -print0 | sort -z | xargs -0 sha256sum > ../MODEL.sha256
   cd .. && sha256sum vllm-openai-v0.30.0.tar > IMAGE.sha256

   Una persona distinta de quien descargó firma el registro como verificado (el método de firma sigue el estándar de tu empresa).

3. Trasladar en soporte físico y verificar antes de cargar

   Servidor en red aislada

   Pasa el registro y los archivos en un soporte físico y vuelve a comparar en el lado aislado. Si aparece un solo FAILED, no se usa.

   bash

   cd /srv/llm/models/Qwen3.8-27B-FP8 && sha256sum -c /srv/llm/incoming/MODEL.sha256
   cd /srv/llm/incoming && sha256sum -c IMAGE.sha256
   docker load -i vllm-openai-v0.30.0.tar

4. Arrancar escuchando solo en 127.0.0.1

   Servidor en red aislada

   Sin --host, vLLM escucha en todas las interfaces. Escribe siempre --host 127.0.0.1 y pasa la clave por archivo (en la línea de comandos se ve con ps).

   bash · vLLM (Docker)

   # Crear el archivo de la clave con permisos 600
   sudo install -D -m 600 /dev/null /etc/llm/vllm.env
   echo "VLLM_API_KEY=$(openssl rand -hex 32)" | sudo tee /etc/llm/vllm.env > /dev/null
   
   sudo docker run -d --name qwen --gpus all --ipc=host --network host \
     -v /srv/llm/models:/models:ro \
     -e HF_HUB_OFFLINE=1 -e VLLM_NO_USAGE_STATS=1 -e DO_NOT_TRACK=1 \
     --env-file /etc/llm/vllm.env \
     vllm/vllm-openai:v0.30.0 \
     --model /models/Qwen3.8-27B-FP8 \
     --served-model-name qwen3.8-27b \
     --host 127.0.0.1 --port 8000 \
     --max-model-len 65536 --gpu-memory-utilization 0.90
   
   # Comprobar que solo escucha en 127.0.0.1:8000
   ss -ltnp | grep 8000

   • No uses --trust-remote-code. Así no se ejecuta el código incluido con el modelo.
   • No uses VLLM_SERVER_DEV_MODE=1 en producción. Expone endpoints de desarrollo.
   • Modo de razonamiento y llamadas a herramientas: la documentación oficial de Qwen pone como ejemplo para Qwen3 --reasoning-parser qwen3 y --enable-auto-tool-choice --tool-call-parser hermes. Para la generación 3.8, consulta la ficha del modelo.
   bash · con Ollama (systemd)

   sudo systemctl edit ollama
   # En el archivo que se abre, escribe estas 3 líneas y guarda
   [Service]
   Environment="OLLAMA_HOST=127.0.0.1:11434"
   Environment="OLLAMA_NO_CLOUD=1"
   
   sudo systemctl restart ollama

   bash · con SGLang o llama.cpp

   python3 -m sglang.launch_server --model-path /models/Qwen3.8-27B-FP8 \
     --host 127.0.0.1 --port 30000 --api-key <clave> --admin-api-key <clave-admin>
   
   llama-server -m /models/qwen.gguf --host 127.0.0.1 --port 8080 \
     --api-key-file /etc/llm/keys --offline --no-webui --jinja

   En el ejemplo de SGLang tampoco escribas la clave directamente: en la práctica, pásala desde un archivo o una variable de entorno. Los ejemplos de la ficha del modelo usan --host 0.0.0.0, así que no los copies tal cual.

5. TLS, lista de permitidos y autenticación con nginx

   Servidor en red aislada (gateway)

   Los usuarios solo tocan nginx. Deja pasar solo lo necesario de /v1 y devuelve 404 para todo lo demás.

   nginx

   server {
     listen 443 ssl;
     server_name llm.internal.example;
     ssl_certificate     /etc/pki/llm.crt;
     ssl_certificate_key /etc/pki/llm.key;
     ssl_protocols TLSv1.2 TLSv1.3;
   
     allow 10.20.0.0/16;   # solo el segmento interno
     deny  all;
   
     location = /v1/chat/completions {
       auth_request /_auth;
       auth_request_set $user $upstream_http_x_auth_request_user;
       proxy_set_header Authorization "Bearer <clave-upstream>";
       proxy_pass http://127.0.0.1:8000;
       proxy_buffering off;   # para respuestas en streaming
     }
     location = /v1/models {
       auth_request /_auth;
       auth_request_set $user $upstream_http_x_auth_request_user;
       proxy_set_header Authorization "Bearer <clave-upstream>";
       proxy_pass http://127.0.0.1:8000;
     }
     location = /_auth {
       internal;
       proxy_pass http://127.0.0.1:4180/oauth2/auth;   # integración con el IdP interno, p. ej. con oauth2-proxy
     }
     location / { return 404; }   # no exponer /metrics, /invocations, etc.
   }

   Los usuarios se identifican con el SSO de la empresa (OIDC o SAML) y la clave de la API upstream no se reparte. auth_request es un módulo de nginx; puedes comprobar si está incluido con nginx -V.

6. Bloquear el tráfico saliente

   Servidor en red aislada

   Bloquea por defecto todo el tráfico del servidor hacia internet. Solo se permiten el DNS interno, la sincronización horaria y el destino de los logs.

   bash · ufw

   sudo ufw default deny incoming
   sudo ufw default deny outgoing
   sudo ufw allow in on <IF-gestión> to any port 22 proto tcp    # si no se permite antes, se corta el SSH
   sudo ufw allow in on <IF-interna> to any port 443 proto tcp
   sudo ufw allow out to <DNS-interno> port 53 proto udp
   sudo ufw allow out to <NTP-interno> port 123 proto udp
   sudo ufw allow out to <colector-de-logs> port 514 proto tcp
   sudo ufw enable
   
   # Comprobar que no se puede salir (si falla, está bien)
   curl -m 5 https://huggingface.co

   Si publicas un puerto con -p de Docker, Docker añade sus propias reglas de paquetes, y puede ser accesible desde fuera aunque creas haberlo cerrado con ufw. En estos pasos se usan --network host y --host 127.0.0.1 para limitar la escucha al equipo local.

   bash · si usas -p

   # Publicar en el host solo en 127.0.0.1 (-p 8000:8000 publica en todas las interfaces)
   sudo docker run -d --name qwen --gpus all --ipc=host \
     -p 127.0.0.1:8000:8000 \
     -v /srv/llm/models:/models:ro \
     -e HF_HUB_OFFLINE=1 -e VLLM_NO_USAGE_STATS=1 -e DO_NOT_TRACK=1 \
     --env-file /etc/llm/vllm.env \
     vllm/vllm-openai:v0.30.0 \
     --model /models/Qwen3.8-27B-FP8 --served-model-name qwen3.8-27b \
     --host 0.0.0.0 --port 8000 --max-model-len 65536
   # ↑ dentro del contenedor escucha en 0.0.0.0; en el host solo sale por 127.0.0.1

   Así, vLLM escucha en 0.0.0.0 dentro del contenedor, pero no es accesible desde fuera del host. Bloquea también el tráfico saliente en el firewall de la red.

7. Guardar logs y auditoría

   Gateway y monitorización

   Registra en los logs de nginx quién usó qué endpoint y cuándo, y envíalos a la plataforma de logs de la empresa (SIEM, etc.). Los tokens se contabilizan con /metrics (formato Prometheus), expuesto solo en la red de monitorización.

   nginx · dentro de http { }

   log_format llm '$time_iso8601 user=$user ip=$remote_addr "$request" '
                  'status=$status bytes=$body_bytes_sent rt=$request_time';
   access_log /var/log/nginx/llm.log llm;

   Si activas --enable-log-requests en vLLM con nivel DEBUG, el texto de los prompts queda en los logs. Decide si se guarda y durante cuánto tiempo según tus normas de datos personales y confidencialidad.

8. Definir usuarios y permisos

   Interfaz (Open WebUI, etc.)

   Si se va a usar como chat, pon una interfaz como Open WebUI en la misma red aislada y separa qué modelos puede usar cada rol y grupo. Haz que las bajas de empleados se bloqueen desde el IdP interno.

   env · Open WebUI

   OFFLINE_MODE=true
   ENABLE_SIGNUP=false
   DEFAULT_USER_ROLE=pending
   ENABLE_COMMUNITY_SHARING=false

   Con OFFLINE_MODE activado, la búsqueda en documentos (RAG) no funciona si no has instalado antes el modelo de embeddings. El modelo de embeddings también se traslada con el mismo flujo de los pasos 1 a 3.

9. Definir el flujo de actualización

   Equipo de entrada → validación → producción

   vLLM publica versiones cada dos semanas aproximadamente, y casi siempre con correcciones de seguridad. Aun en red aislada, actualiza con regularidad siguiendo el flujo «descarga → validación → registro → producción».

   bash

   # 1. Descargar, comparar y trasladar la versión nueva igual que en los pasos 1 a 3
   # 2. En validación, lanzar las mismas preguntas a la versión anterior y a la nueva y comparar
   # 3. Listar las variables de entorno en uso y comprobar en las notas de versión que no desaparecen
   sudo docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' qwen \
     | grep -E '^(VLLM_|HF_)' | cut -d= -f1
   # 4. Al pasar a producción, dejar una línea con quién subió, cuándo y cuándo se revirtió
   echo "$(date -I) vllm <versión-anterior>→<versión-nueva> responsable:<nombre> validación:OK rollback:<versión-anterior>.tar" >> /srv/llm/CHANGELOG

   Conserva el contenedor y el modelo de la versión anterior, con su digest anotado, para poder volver atrás. Compara antes y después los valores que cambian entre versiones, como el límite de longitud del contexto.

Seguridad del LLM local: 20 puntos antes de producción

Revísalos en orden, antes y después del montaje. Las casillas solo funcionan en esta pantalla y no se envían a ninguna parte.

0 / 20 comprobados

Errores frecuentes: cuando «creíamos que era seguro»

A la izquierda, el error habitual; a la derecha, la solución con los pasos de esta página.

• --host 0.0.0.0 sin autenticaciónUsar tal cual el comando de ejemplo y dejarlo abierto a toda la LAN.
  127.0.0.1 + nginxEscucha solo en local. Los usuarios pasan por el gateway.
• Versiones modificadas de origen dudosoUsar GGUF comunitarios, como los «Uncensored», sin comprobar su procedencia.
  Desde Qwen/ oficial, con SHA fijadoSi usas versiones de terceros, registra autor y proceso.
• «Con api-key ya es seguro»Dar por hecho que la clave de vLLM protege todos los endpoints.
  Filtrar con lista de permitidosPasa solo lo necesario, como /v1/chat/completions.
• «Es on-premise, así que es seguro»Saltarse permisos, logs y control de acceso del RAG porque está dentro de la empresa.
  Dentro, la misma gestión que fueraSSO, roles, logs y búsqueda que respeta los permisos de lectura.
• Usarlo desde fuera con un túnelPublicar al exterior algo interno con Cloudflare Tunnel u otro.
  Solo desde la red internaSi hace falta acceso externo, usa el acceso remoto oficial de la empresa.
• No ver el tráfico externo por defectoLas estadísticas de uso de vLLM o la actualización automática de Ollama de escritorio.
  Con variables de entorno y bloqueo salienteDesactívalo en la configuración y bloquéalo también en el firewall.
• Confiar demasiado en un modelo pequeñoEn agentes o llamadas a herramientas, inventa archivos o enlaces que no existen.
  Usarlo como primer borradorEjecución en sandbox y resultados revisados por una persona.
• Se rompe al actualizarTras subir de versión, deja de funcionar por variables eliminadas o límites cambiados.
  Comparar en validaciónContrasta con las notas de versión y anota quién actualizó.

Lo que cuentan los vídeos: casos reales de Qwen autoalojado

Revisamos, hasta la transcripción del audio, 18 vídeos explicativos en inglés, chino y japonés publicados entre febrero y octubre de 2026.

SIMY y Qwen: dentro de la red, Qwen; fuera, SIMY

Seamos claros: hoy SIMY no funciona con Qwen, ni dentro de una red aislada ni sin conexión.

* Reparto de ejemplo con fines ilustrativos

• Lo recoge de reuniones y chats
• A tu manera
• Solo te devuelve decisiones

El texto confidencial, en el Qwen de la red aislada. Después, de «quién hace qué y para cuándo», SIMY avanza la parte que la empresa ha decidido que puede salir, dentro de las herramientas que la empresa autoriza.

• Cómo funciona SIMY: la ejecución en la nube funciona con tu cuenta de ChatGPT (Codex). El uso de Codex entra dentro de tu plan de ChatGPT.
• Ejecución en el PC: la app de escritorio de SIMY puede usar Claude Code de tu PC para ejecutar el trabajo. Descárgala aquí.
• Lectura del historial de conversaciones: la app de escritorio lee el historial de Claude Code y Codex y convierte el trabajo que repites en «Sugerencias de SIMY». El texto de las conversaciones no se guarda en el servidor. Decide en tu normativa interna en qué PC y con qué alcance se usa.

Dónde trazar la línea: qué información se queda en la red aislada y qué puede tratarse con herramientas externas lo decide la normativa de tu empresa. Cómo trata SIMY los datos está publicado en Seguridad y en la Política de privacidad.

Preguntas frecuentes sobre LLM local y Qwen

Fuentes

Los pasos, la configuración por defecto y las licencias se verificaron en estas fuentes oficiales (fecha de verificación: 1 de octubre de 2026). Las versiones y los valores por defecto cambian a menudo, así que consulta cada página oficial antes de montar nada.

• Security (documentación de vLLM), Usage Stats Collection, vllm serve
• Notas de versión de vLLM (GitHub)
• Server Arguments (documentación de SGLang)
• FAQ (documentación de Ollama)
• README de llama.cpp server (GitHub)
• Despliegue con vLLM (documentación de Qwen), Speed Benchmark (documentación de Qwen)
• Qwen (Hugging Face), ficha del modelo Qwen3.8-27B
• Hugging Face CLI, Variables de entorno (Hugging Face Hub)
• ngx_http_auth_request_module (documentación de nginx), ngx_http_ssl_module
• Environment Variable Configuration (documentación de Open WebUI)
• Packet filtering and firewalls (documentación de Docker)
• qwen3.8 (biblioteca de Ollama)