Pourquoi j’ai monté un serveur Qwen 3.6 27B plutôt que de payer Cursor

Cursor est un excellent IDE agentique. En revanche, les modèles qu’il propose en natif m’ont vite frustré : quotas, facturation au token, sessions agent qui s’arrêtent au pire moment, et une qualité/prix difficile à justifier quand on enchaîne les revues de code, les refactors et les essais MCP toute la journée.

Le vrai problème

Ce n’était pas « je veux héberger un LLM pour le plaisir ». C’était : je veux utiliser l’agent sans regarder la jauge de tokens toutes les dix minutes. Mes projets (MCP, prototypes Gradio, gros diffs GitHub) consomment beaucoup de contexte. Payer Cursor pour chaque itération, c’est acceptable une fois de temps en temps — pas en boucle sur du travail perso et open source.

Ce que le serveur distant m’apporte

• Tokens gratuits côté inférence : je paie le GPU à l’heure, pas chaque prompt. Je peux relancer l’agent dix fois sur le même bug sans culpabiliser.
• Un Qwen 3.6 27B branché en API OpenAI-compatible — Cursor, mes serveurs MCP et mes scripts parlent au même endpoint.
• Même workflow qu’avant dans l’IDE ; seul le modèle change. Pas besoin de quitter Cursor.
• Indépendance : si demain les tarifs ou les limites bougent encore, mon stack reste le mien.

Comment c’est monté (en bref)

Instance GPU sur AWS (48 Go VRAM), vLLM pour servir Qwen 3.6 27B, reverse proxy en TLS + token Bearer devant. vLLM expose l’API OpenAI-compatible (`/v1/chat/completions`) — Cursor, ai-code-reviewer-mcp et redbee-mcp pointent tous vers ce endpoint avec les mêmes `OPENAI_API_BASE` / `OPENAI_API_KEY`.

Pourquoi vLLM sur AWS (et pas Ollama ici)

Pour un 27B en prod agent — gros contexte, requêtes parallèles, uptime — vLLM est plus adapté : throughput, batching, API stable. Ollama brille ailleurs (voir git-mentor ci-dessous). Sur AWS je lance le modèle quantifié une fois ; je paie l’instance GPU, pas les tokens Cursor.

Pourquoi du 4 bits (AWQ / GPTQ)

Un 27B en FP16 demande ~54 Go de VRAM — hors budget sur une seule carte « classique ». En quantification 4 bits (AWQ ou GPTQ, le format que vLLM charge nativement), le poids tombe autour de 16 Go : le modèle tient sur le GPU avec de la marge pour le contexte long et plusieurs requêtes agent. On perd un peu de finesse vs le full precision, mais pour du code review, du refactor et des appels MCP, la différence est rarement bloquante — surtout comparée au coût d’un gros modèle cloud facturé au token.

• FP16 : meilleure qualité, VRAM ×3 — utile si tu as 80 Go+ ou plusieurs GPUs.
• AWQ / GPTQ 4 bits : bon compromis qualité / prix / latence pour vLLM au quotidien.
• Q8 : milieu si tu veux gratter un peu de qualité sans doubler la facture EC2.

# Sur l'instance AWS (exemple vLLM + poids AWQ)
vllm serve Qwen/Qwen3-27B-Instruct-AWQ \
  --quantization awq \
  --host 127.0.0.1 --port 8000

# Côté Cursor / MCP (via le proxy TLS)
OPENAI_API_BASE=https://llm.example.com/v1
OPENAI_API_KEY=<token-proxy>
OPENAI_MODEL=Qwen/Qwen3-27B-Instruct-AWQ

Ollama en local pour git-mentor

git-mentor, c’est un autre cas d’usage : analyse de profil GitHub avec un PAT qui ne doit pas transiter par un serveur distant si je peux l’éviter, sessions courtes, modèle plus petit suffisant. Là j’utilise Ollama sur ma machine — zéro coût cloud, offline possible, `localhost:11434/v1`. Le gros Qwen AWS reste pour Cursor et les MCP ; git-mentor reste local-first par design.

# Mac / laptop — git-mentor en local
ollama run llama3.2

export OPENAI_API_BASE=http://localhost:11434/v1
export OPENAI_API_KEY=ollama
git-mentor analyze --user Tamsi

Le bilan

Deux stacks complémentaires : vLLM sur AWS pour l’agent « à fond » (tokens gratuits côté inférence), Ollama en local pour git-mentor. Le setup AWS m’a pris une après-midi ; le gain, c’est surtout mental et économique. Cursor reste mon interface ; le cerveau lourd tourne chez moi sur GPU, le cerveau léger sur le laptop.