Pourquoi self-héberger Jan sur un VPS
Jan fonctionne avec un moteur d'inférence local (Cortex/llama.cpp) qui charge des modèles GGUF directement sur la machine. Sur un poste personnel, c'est mono-utilisateur ; sur un VPS, vous exposez le serveur d'inférence Jan via son API compatible OpenAI sur le port 1337, ce qui permet à vos applications, scripts et collègues de consommer le même modèle privé. Aucune donnée ne part vers un fournisseur tiers : les prompts et complétions restent dans la mémoire du VPS. C'est l'option idéale quand la confidentialité est non négociable ou quand vous voulez supprimer toute facture d'API en exploitant des modèles open weights.
Bénéfices concrets de l'auto-hébergement
- Inférence 100% locale : aucun prompt n'est envoyé à un service externe
- API compatible OpenAI sur le port 1337, branchable depuis n'importe quel client existant
- Coût d'API nul : seuls comptent les ressources du VPS, pas un quota de tokens
- Centralisation des modèles GGUF sur un serveur partagé plutôt qu'un téléchargement par poste
- Contrôle des versions de modèles et reproductibilité des réponses pour vos tests
- Possibilité de servir plusieurs applications internes derrière une seule instance
Prérequis matériels et logiciels
Jan exécute les modèles sur le CPU par défaut, et la RAM est le facteur déterminant. Un modèle quantifié 7B en Q4 demande environ 6 à 8 Go de RAM pour tourner confortablement ; visez donc un VPS de 8 Go de RAM et 4 vCPU pour des temps de réponse acceptables, plus 20 à 40 Go de disque selon le nombre de modèles GGUF stockés. Pour des modèles 13B ou plus, montez à 16 Go. Côté logiciel : Docker et Docker Compose, un domaine pointant vers le VPS, et un reverse proxy avec authentification, car l'API Jan n'impose pas de clé par défaut.
Déploiement headless de Jan
Provisionner le VPS
Choisissez une offre avec suffisamment de RAM pour vos modèles. Installez Docker, créez /opt/jan/models qui servira de volume persistant pour les fichiers GGUF afin de ne pas les retélécharger à chaque mise à jour.
Lancer le serveur Jan en conteneur
Démarrez l'image du serveur Jan en montant le volume des modèles et en exposant le port 1337 uniquement sur l'interface locale : docker run -d -p 127.0.0.1:1337:1337 -v /opt/jan/models:/root/jan/models --name jan menloltd/cortex. Restreindre à 127.0.0.1 évite toute exposition directe.
Télécharger un modèle
Via l'API ou la CLI Cortex, récupérez un modèle, par exemple cortex pull llama3.1:8b-gguf. Vérifiez qu'il se charge correctement avec une requête de test sur http://127.0.0.1:1337/v1/models.
Tester l'API compatible OpenAI
Envoyez une complétion de test : curl http://127.0.0.1:1337/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"llama3.1:8b","messages":[{"role":"user","content":"Bonjour"}]}' et confirmez la réponse.
Sécuriser avec un reverse proxy et une clé
Placez Caddy ou Nginx devant le port 1337, activez le HTTPS Let's Encrypt et ajoutez une couche d'authentification (auth basic ou en-tête Authorization vérifié) pour interdire tout accès anonyme à votre serveur d'inférence.
Exposer le domaine
Publiez https://ia.votredomaine.ma/v1 et reconfigurez vos clients en pointant leur base_url vers cette adresse. Vos applications consomment désormais Jan comme s'il s'agissait d'OpenAI.
Sans GPU, le débit en tokens/seconde dépend fortement du nombre de threads CPU. Fixez explicitement --n-threads au nombre de vCPU réels du VPS et privilégiez des quantifications Q4_K_M : le compromis qualité/vitesse est optimal pour un serveur CPU et divise par deux l'empreinte mémoire face à un modèle non quantifié.
