Vast.ai : loue un GPU et branche un agent IA non censuré sur VS Code — le guide complet

Tu veux un agent de développement qui ne te dise pas « désolé, je ne peux pas t’aider » toutes les cinq minutes. Tu veux un modèle qui comprenne le code, qui appelle des outils, qui lise tes fichiers, qui exécute des commandes — sans se censurer. Et tu veux que ça tourne sur du matériel sérieux, pas sur ton MacBook qui chauffe comme un four.

La solution : louer un GPU sur Vast.ai, y installer un Qwen3 abliterated (un modèle non censuré qui garde intact son function calling), le servir en API OpenAI-compatible, puis y accéder depuis ton VS Code local via un tunnel VPS. Tout ça pour quelques dollars de l’heure, avec la possibilité de tout éteindre quand tu as fini.

Ce tutoriel est un guide technique de bout en bout. Chaque commande est testée, chaque étape est reproductible. On ne va pas te raconter que c’est révolutionnaire ou que tu vas passer de zéro à héros. On va te montrer comment ça marche, point.

Ce qu'il te faut

Avant de commencer, assure-toi d’avoir :

• Un compte Vast.ai (https://cloud.vast.ai/) avec au moins 5 $ de crédit (Stripe, BitPay ou Crypto.com). Le dépôt minimum est de 5 $, et c’est suffisant pour une nuit de travail.
• Un VPS (n’importe lequel : OVH, Hetzner, DigitalOcean, même un Raspberry Pi en colocation si tu es maso). Il sert de relais stable entre ton instance GPU éphémère et ta machine locale. Si tu n’en as pas, tu peux sauter cette étape et utiliser directement le port forwarding SSH de Vast.ai, mais c’est moins propre.
• VS Code installé sur ta machine locale, avec au moins une des extensions suivantes : Continue, Cline ou Roo Code.
• Des bases en SSH : savoir générer une clé, se connecter à une machine distante. Rien de sorcier, mais si tu ne sais pas ce que c’est, commence par là.
• Un terminal, du café, et un peu de patience. Les images Docker peuvent mettre du temps à se télécharger.

Étape 1 — Louer une instance GPU sur Vast.ai

Créer un compte et créditer son solde

1. Va sur https://cloud.vast.ai/ et crée un compte. Vérifie ton adresse e-mail (obligatoire, sinon tu ne pourras pas louer de machine).
2. Ajoute du crédit via Billing → Add Credit. Moyens de paiement acceptés : carte bancaire (Stripe), crypto (BitPay, Crypto.com). Minimum : 5 $.

Astuce : active l’autobilling si tu veux éviter de te retrouver à court de crédit en pleine session. Configure un seuil de recharge et une alerte e-mail pour être prévenu avant que ça ne coupe.

Trouver la bonne offre

Rends-toi sur https://cloud.vast.ai/create/. C’est là que tu vas filtrer les offres pour trouver la perle rare.

Filtres à appliquer (selon ton besoin) :

• Type de GPU : pour ce tutoriel, on va cibler soit une RTX 4090 24 Go (économique), soit une RTX A6000 48 Go (pour plus de marge).
• Mémoire GPU (VRAM) : 24 Go minimum pour notre exemple.
• Prix : entre 0,25 $/h et 0,50 $/h pour une RTX 4090, 0,30–0,50 $/h pour une A6000.
• Fiabilité (Reliability Score) : privilégie les machines avec un score > 80 %. Toutes les machines démarrent à 60 %, mais celles qui montent au-dessus ont fait leurs preuves.
• Type d’instance : on-demand pour une session critique (priorité maximale), interruptible pour économiser (jusqu’à -50 %, mais tu peux te faire déconnecter à tout moment).

Note : Vast.ai est un marché. Les prix fluctuent en temps réel. Une RTX 4090 peut coûter 0,29 $/h en interruptible ou 0,51 $/h en on-demand. Vérifie toujours le prix affiché avant de louer.

Lancer l’instance

Une fois que tu as trouvé une offre qui te convient, clique dessus. Voici les paramètres à configurer :

• Image Docker : pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime (ou une version plus récente si disponible). C’est une image officielle PyTorch avec CUDA préinstallé.
• Mode de lancement : SSH only (on n’a pas besoin de Jupyter pour ce tutoriel).
• Taille du disque : 50 Go minimum (tu peux monter à 100 Go si tu prévois d’installer plusieurs modèles). Attention : cette taille est définitive. Si tu manques de place, il faudra recréer une instance avec un disque plus grand.
• On-start Script : laisse vide pour l’instant. On verra plus tard comment l’utiliser pour automatiser le démarrage de vLLM.

Piège : ne pas préciser de tag de version pour l’image Docker peut provoquer une erreur server_error au moment de louer. Toujours utiliser un tag explicite.

Une fois l’instance lancée, attends qu’elle passe en statut Connect. Ça peut prendre entre 2 et 5 minutes (plus long si c’est un pull à froid de l’image Docker).

Clés SSH et connexion

1. Génère une paire de clés SSH si tu n’en as pas déjà une :

   ssh-keygen -t ed25519 -C "ton_email@example.com"

Cela crée deux fichiers dans ~/.ssh/ : id_ed25519 (clé privée, à ne jamais partager) et id_ed25519.pub (clé publique).

1. Ajoute ta clé publique à ton compte Vast.ai :

- Affiche ta clé publique : cat ~/.ssh/id_ed25519.pub

- Copie son contenu et colle-le dans https://cloud.vast.ai/manage-keys/ (section SSH Keys → +New).

1. Connecte-toi à l’instance :

- Sur la page de ton instance, clique sur l’icône SSH pour obtenir la commande de connexion. Elle ressemble à ça :

     ssh -p 50983 root@154.64.230.50

- -p 50983 : le port SSH externe (aléatoire, mappé sur le port 22 interne).

- root : l’utilisateur est toujours root sur Vast.ai.

- 154.64.230.50 : l’IP publique de l’instance (souvent partagée entre plusieurs machines).

Note : l’authentification par mot de passe est désactivée. Seules les clés SSH sont acceptées.

1. Transfert de fichiers (si besoin) :

   # Envoyer un fichier VERS l'instance
   scp -P 50983 mon_fichier.txt root@154.64.230.50:/workspace/

   # Récupérer un fichier DEPUIS l'instance
   scp -P 50983 root@154.64.230.50:/workspace/mon_fichier.txt ./

Note : scp utilise -P (majuscule) pour le port, contrairement à ssh qui utilise -p (minuscule).

Cycle de vie de l’instance

• Stop (icône carré) : met l’instance en pause. Les données sont conservées, mais le stockage continue d’être facturé (le GPU est libéré).
• Destroy (icône corbeille) : suppression définitive de l’instance et de toutes ses données. C’est la seule façon d’arrêter complètement la facturation.
• Restart (icône play) : tente de relancer l’instance si elle est arrêtée.

Règle d’or : une instance visible dans ton compte n’est jamais gratuite, même arrêtée. Le stockage est facturé en continu. Détruis les instances inutiles.

Exemple de coût

Voici ce que ça coûte pour une nuit de travail (10 heures) sur une RTX 4090 :

• Location GPU : 10 h × ~0,35 $/h ≈ 3,50 $
• Stockage : 10 h × ~0,10 $/Go/h (pour un disque de 50 Go) ≈ 0,05 $
• Bande passante : quelques Go téléchargés ≈ négligeable (quelques centimes)

Total estimé : 4 à 6 $ pour une session de 10 heures.

À retenir : le stockage est facturé même quand l’instance est arrêtée. Si tu laisses traîner une instance avec un disque de 200 Go pendant une semaine, ça peut coûter plus cher que la location du GPU elle-même.

Étape 2 — Choisir le modèle non censuré

Abliterated vs Dolphin : la différence qui compte

Il existe trois familles de modèles « non censurés ». Pour un agent de développement, seul l’abliterated est vraiment adapté.

• Abliterated : on identifie dans l’espace d’activation du modèle une « direction de refus » (la tendance à dire « je ne peux pas t’aider »), puis on la projette hors des matrices de poids. Résultat : le modèle n’a plus ce réflexe, sans perdre ses autres capacités (comme le function calling). C’est une édition sans entraînement, donc rapide et peu coûteuse.

• Dolphin : le modèle est fine-tuné sur un jeu de données dont les refus ont été filtrés. Il « n’apprend jamais » à refuser. Problème : le fine-tune peut dégrader la qualité ou l’alignement du modèle, et le function calling est moins fiable.

• Hermes 3/4 (de Nous Research) : d’excellents modèles de chat, mais orientés conversation. Pour un usage agentique (tool use intensif), ils sont moins adaptés que Qwen3 abliterated.

Pourquoi Qwen3 abliterated ?

1. Function calling natif et fiable : Qwen3 est entraîné pour appeler des outils. L’abliteration retire uniquement la direction de refus, sans toucher au tool-calling.
2. Grand contexte : Qwen3 supporte jusqu’à 128k tokens. Hermes Agent exige ≥ 64 000 tokens pour fonctionner correctement.
3. Licence permissive (Apache 2.0) et écosystème bien outillé (vLLM, Ollama, llama.cpp).

Tableau des tailles, VRAM et GPU recommandés

Voici les modèles abliterated disponibles, leur taille, et le GPU Vast.ai qui convient.

Règle de calcul de la mémoire des poids :

• FP16 / BF16 : 2 octets × paramètres → 8B ≈ 16 Go, 14B ≈ 28 Go, 32B ≈ 64 Go, 70B ≈ 140 Go.
• 4-bit (GGUF Q4_K_M, AWQ, GPTQ) : ≈ 0,5–0,55 octet × paramètres → 8B ≈ 5 Go, 14B ≈ 9 Go, 32B ≈ 19 Go, 70B ≈ 40 Go.

Il faut ajouter le cache KV + les activations (environ 2 à 6 Go selon le contexte). Les valeurs « VRAM totale » ci-dessous incluent une marge réaliste pour ~64k de contexte.

Repères de prix Vast.ai (indicatifs, très fluctuants) :

• RTX 4060 Ti 16GB ≈ 0,10–0,15 $/h
• RTX 3090 24GB ≈ 0,15–0,25 $/h
• RTX 4090 24GB ≈ 0,25–0,40 $/h
• RTX A6000 48GB ≈ 0,30–0,50 $/h
• A100 80GB ≈ 0,70–1,00 $/h
• H100 80GB ≈ 1,50–2,50 $/h

Recommandation pratique :

• Pour un agent de dev, Qwen3-32B-abliterated en 4-bit sur une RTX A6000 48GB est le meilleur rapport qualité/prix.
• Le Huihui-Qwen3.8-27B-abliterated en 4-bit sur RTX 4090 24GB est l’option la plus économique pour une capacité quasi équivalente.

Attention : un Qwen3-32B en BF16 pèse ~64 Go de poids. Il ne tient pas sur une seule RTX 4090 (24 Go) ni sur une RTX A6000 (48 Go) en FP16. Pour l’exemple bout-en-bout, on utilisera donc une quantification 4-bit (AWQ ou GPTQ), qui réduit la taille à ~19 Go.

Étape 3 — Servir le modèle en API OpenAI-compatible

Trois options s’offrent à toi, par ordre de préférence pour un agent de développement :

Option 1 — vLLM (recommandé)

vLLM est le choix pour un agent : débit élevé, continuous batching, et surtout, un support natif du tool calling avec les bons flags.

Installation (sur l’instance GPU Vast.ai) :

pip install vllm

Authentification HuggingFace (pour les modèles gated comme huihui-ai) :

huggingface-cli login
# Suis les instructions pour te connecter et accepter les conditions d'accès au modèle.
export HF_TOKEN=hf_xxxxxxxx

Servir le modèle (exemple avec Qwen3-32B-abliterated en 4-bit AWQ) :

vllm serve huihui-ai/Qwen3-32B-abliterated \
  --host 0.0.0.0 \
  --port 8000 \
  --served-model-name qwen3-32b-abliterated \  # nom logique pour l'API
  --max-model-len 65536 \
  --gpu-memory-utilization 0.95 \
  --tensor-parallel-size 1 \
  --enable-auto-tool-choice \
  --tool-call-parser hermes \
  --quantization awq  # pour un checkpoint AWQ/GPTQ

Explications des flags :

• --host 0.0.0.0 : écoute sur toutes les interfaces (nécessaire pour le tunnel).
• --port 8000 : le port sur lequel l’API sera accessible.
• --served-model-name : le nom du modèle tel qu’il apparaîtra dans l’API. Doit correspondre à ce que tu utiliseras dans les configs VS Code.
• --max-model-len 65536 : fixe le contexte à 64k (Hermes Agent exige ≥ 64k).
• --gpu-memory-utilization 0.95 : utilise 95 % de la VRAM disponible.
• --tensor-parallel-size 1 : utilise un seul GPU (mets à 2 si tu as deux GPUs).
• --enable-auto-tool-choice : requis pour que Hermes Agent puisse utiliser tool_choice: "auto".
• --tool-call-parser hermes : requis pour que les appels d’outils Qwen soient reconnus. Sans ce flag, les tool calls ressortent en texte brut et ne sont pas interprétés.
• --quantization awq : pour un checkpoint AWQ. Utilise --quantization gptq pour GPTQ, ou --quantization gguf pour un GGUF.

Test rapide :

# Vérifier que le modèle est bien servi
curl http://localhost:8000/v1/models
# Doit retourner un JSON avec "id": "qwen3-32b-abliterated"

# Envoyer une requête de test
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3-32b-abliterated","messages":[{"role":"user","content":"Bonjour, qui es-tu ?"}]}'

Note : si tu utilises un modèle non quantifié (FP16/BF16), assure-toi que ton GPU a assez de VRAM. Pour un Qwen3-32B en FP16, il te faut au moins 68 Go de VRAM (poids + cache KV).

Option 2 — Ollama (simple mais limité)

Ollama est idéal pour démarrer rapidement, mais il a quelques pièges.

Installation :

curl -fsSL https://ollama.com/install.sh | sh

Télécharger et servir le modèle :

# Télécharger le modèle (les abliterated sont dans la bibliothèque huihui_ai)
ollama pull huihui_ai/Qwen3.8-abliterated   # le 27B en Q4_K_M
ollama pull huihui_ai/qwen3-abliterated     # la série Qwen3 8B

# Servir avec un contexte suffisant (64k)
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Pièges à éviter :

• Piège n°1 : sans OLLAMA_CONTEXT_LENGTH=64000, Hermes Agent refuse de démarrer (il exige ≥ 64k de contexte).
• Piège n°2 : on ne peut pas fixer le contexte via l’API /v1/chat/completions. Il faut le régler côté serveur ou via un Modelfile :

  echo -e 'FROM huihui_ai/Qwen3.8-abliterated\nPARAMETER num_ctx 64000' > Modelfile
  ollama create qwen3.8-64k -f Modelfile

API : accessible sur http://localhost:11434/v1.

Option 3 — llama.cpp (pour les puristes)

llama.cpp est une option légère, surtout utile si tu veux tourner sur du CPU ou de l’Apple Silicon. Mais pour un GPU datacenter, vLLM est bien plus performant.

Build :

cmake -B build && cmake --build build --config Release

Servir :

./build/bin/llama-server \
  --jinja -fa \
  -c 64000 \
  -ngl 99 \
  -m models/Qwen3-32B-abliterated-Q4_K_M.gguf \
  --port 8080 --host 0.0.0.0

Flags importants :

• --jinja est obligatoire pour le tool calling. Sans lui, le serveur ignore le paramètre tools et Hermes ne verra que du JSON brut.
• -fa : active toutes les optimisations GPU.
• -c 64000 : contexte à 64k.
• -ngl 99 : utilise toutes les couches GPU.

API : accessible sur http://localhost:8080/v1.

Note : pour utiliser llama.cpp, il te faut un modèle au format GGUF. Tu peux en trouver sur HuggingFace (filtre library=gguf). Q4_K_M est le meilleur compromis qualité/mémoire.

Étape 4 — Installer Hermes Agent (ou ton agent de dev)

Hermes Agent est un agent de développement open-source qui peut appeler des outils, lire des fichiers, exécuter des commandes, et bien plus. Il est conçu pour fonctionner avec n’importe quel endpoint OpenAI-compatible.

Installation

# Linux / macOS / WSL2
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Une fois installé, tu peux lancer le setup interactif :

hermes model
# → Choisir "Custom endpoint (self-hosted / VLLM / etc.)"
# → URL : http://localhost:8000/v1   (vLLM) — ou :11434/v1 (Ollama) — ou :8080/v1 (llama.cpp)
# → API key : laisser vide (serveur local)
# → Nom du modèle : celui chargé par le serveur (ex: qwen3-32b-abliterated)

Configuration manuelle — ~/.hermes/config.yaml

Si tu préfères tout configurer à la main, édite le fichier ~/.hermes/config.yaml :

# ~/.hermes/config.yaml
model:
  default: huihui-ai/Qwen3-32B-abliterated   # nom exact servi par vLLM/Ollama
  provider: custom                            # "custom" = endpoint OpenAI-compatible
  base_url: http://localhost:8000/v1          # vLLM ; http://localhost:11434/v1 pour Ollama
  context_length: 65536                       # Hermes exige ≥ 64000 ; s'aligne sur --max-model-len

Variante Ollama :

model:
  default: huihui_ai/Qwen3.8-abliterated
  provider: custom
  base_url: http://localhost:11434/v1
  context_length: 65536

Points importants :

• provider: custom couvre vLLM, Ollama et llama.cpp (les alias ollama, vllm, llamacpp pointent tous vers custom).
• Si l’auto-détection du contexte échoue (proxy sans /v1/models), fixe context_length manuellement.
• Une fois configuré, tu peux basculer de modèle en session avec /model custom:<nom>.

Vérification

hermes doctor        # inspecte la config et vérifie que tout est bon
hermes chat          # ouvre une session ; le modèle local doit répondre
# En session : /model custom   → auto-détecte le modèle servi (s'il n'y en a qu'un)

Note : si tu as installé Hermes Agent sur ta machine locale mais que le modèle tourne sur l’instance Vast.ai, il te faudra un tunnel pour y accéder (voir Étape 5).

Étape 5 — Le tunnel VPS

Pourquoi un tunnel ?

Ton instance Vast.ai est derrière un NAT/pare-feu : ses ports ne sont pas joignables directement depuis Internet. Or, vLLM écoute sur http://localhost:8000/v1 à l’intérieur de l’instance. Pour que ton VS Code local puisse lui parler, il faut faire transiter le trafic à travers une machine à adresse publique stable : ton VPS.

Deux approches existent :

• Tunnel inverse (ssh -R, frp, cloudflared) : l’instance sort vers le VPS.
• Port forwarding direct (ssh -L) : ta machine locale sort vers l’instance.

On va combiner les deux : l’instance pousse le port 8000 vers le VPS (ssh -R), puis ta machine locale tire ce port vers elle (ssh -L).

Le principe du tunnel inverse SSH (ssh -R)

Commande de base (depuis l’instance Vast.ai) :

ssh -R 8000:localhost:8000 user@IP_DU_VPS

Lecture : « Quand tu es connecté sur le VPS, ouvre le port 8000 et renvoie tout ce qui y arrive vers localhost:8000 sur la machine qui lance la commande (c’est-à-dire l’instance Vast.ai). »

Résultat : sur le VPS, un service écoute sur 127.0.0.1:8000 et le relaie vers vLLM.

Les pièges classiques

Piège n°1 — Le port n’est joignable que depuis le VPS lui-même. Par défaut, OpenSSH lie le port redirigé sur l’interface loopback (127.0.0.1) du serveur, pas sur 0.0.0.0. Pour que IP_DU_VPS:8000 soit joignable depuis l’extérieur, il faut :

# Sur le VPS, dans /etc/ssh/sshd_config :
GatewayPorts yes        # ou "clientspecified"
# puis :
sudo systemctl reload ssh   # ou sshd

Avec GatewayPorts yes, la commande devient :