Por qué autoalojar Jan en un VPS
Jan funciona con un motor de inferencia local (Cortex/llama.cpp) que carga modelos GGUF directamente en la máquina. En un equipo personal es monousuario; en un VPS, usted expone el servidor de inferencia de Jan a través de su API compatible con OpenAI en el puerto 1337, lo que permite que sus aplicaciones, scripts y compañeros consuman el mismo modelo privado. Ningún dato sale hacia un proveedor externo: los prompts y las respuestas permanecen en la memoria del VPS. Es la opción ideal cuando la confidencialidad no es negociable o cuando quiere eliminar cualquier factura de API aprovechando modelos de pesos abiertos.
Beneficios concretos del autoalojamiento
- Inferencia 100% local: ningún prompt se envía a un servicio externo
- API compatible con OpenAI en el puerto 1337, conectable desde cualquier cliente existente
- Coste de API nulo: solo cuentan los recursos del VPS, no una cuota de tokens
- Centralización de los modelos GGUF en un servidor compartido, en vez de una descarga por puesto
- Control de las versiones de los modelos y reproducibilidad de las respuestas para sus pruebas
- Posibilidad de servir a varias aplicaciones internas detrás de una sola instancia
Requisitos de hardware y software
Jan ejecuta los modelos en la CPU por defecto, y la RAM es el factor determinante. Un modelo cuantizado 7B en Q4 necesita unos 6 a 8 GB de RAM para funcionar con holgura; apunte por tanto a un VPS de 8 GB de RAM y 4 vCPU para obtener tiempos de respuesta aceptables, más 20 a 40 GB de disco según el número de modelos GGUF almacenados. Para modelos de 13B o más, suba a 16 GB. En cuanto al software: Docker y Docker Compose, un dominio apuntando al VPS y un reverse proxy con autenticación, ya que la API de Jan no impone ninguna clave por defecto.
Despliegue headless de Jan
Aprovisionar el VPS
Elija una oferta con suficiente RAM para sus modelos. Instale Docker y cree
/opt/jan/models, que servirá de volumen persistente para los archivos GGUF y así evitará volver a descargarlos en cada actualización.Lanzar el servidor Jan en un contenedor
Arranque la imagen del servidor Jan montando el volumen de los modelos y exponiendo el puerto 1337 únicamente en la interfaz local:
docker run -d -p 127.0.0.1:1337:1337 -v /opt/jan/models:/root/jan/models --name jan menloltd/cortex. Restringirlo a 127.0.0.1 evita cualquier exposición directa.Descargar un modelo
Mediante la API o la CLI de Cortex, obtenga un modelo, por ejemplo
cortex pull llama3.1:8b-gguf. Compruebe que se carga correctamente con una petición de prueba ahttp://127.0.0.1:1337/v1/models.Probar la API compatible con OpenAI
Envíe una respuesta de prueba:
curl http://127.0.0.1:1337/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"llama3.1:8b","messages":[{"role":"user","content":"Hola"}]}'y confirme la respuesta.Asegurar con un reverse proxy y una clave
Coloque Caddy o Nginx delante del puerto 1337, active el HTTPS de Let's Encrypt y añada una capa de autenticación (auth basic o cabecera
Authorizationverificada) para prohibir cualquier acceso anónimo a su servidor de inferencia.Exponer el dominio
Publique
https://ia.sudominio.com/v1y reconfigure sus clientes apuntando subase_urla esta dirección. Sus aplicaciones consumen a partir de ahora Jan como si se tratara de OpenAI.
Sin GPU, el rendimiento en tokens por segundo depende en gran medida del número de hilos de CPU. Fije explícitamente --n-threads al número de vCPU reales del VPS y opte por cuantizaciones Q4_K_M: el compromiso entre calidad y velocidad es óptimo para un servidor CPU y divide por dos la huella de memoria frente a un modelo sin cuantizar.
