local-llm

Deux façons de faire travailler un LLM local (Qwen3.6-35B-A3B-AWQ servi par vLLM sur une Jetson AGX Orin) à la place de Claude, pour les sous-tâches mécaniques ou volumineuses.

La distinction compte : passer par l'outil MCP oblige Claude à recopier le contenu dans l'argument prompt, ce qui coûte plus cher en tokens de sortie que de ne rien déléguer. delegate.py évite ça — Claude ne voit que le résultat.

Installation

python3 -m venv .venv
.venv/bin/pip install -r requirements.txt

Related MCP server: cn-llm-mcp

delegate.py

.venv/bin/python delegate.py --file '<fichier_ou_glob>' --task "<instruction>" [--out <sortie>]

--file est répétable et accepte les globs. Options : --system, --max-tokens (2048), --temperature (0.3), --think (raisonnement interne, plus lent), --out.

server.py (MCP)

Déclaration dans .mcp.json :

{
  "mcpServers": {
    "local-llm": {
      "command": "/chemin/vers/.venv/bin/python",
      "args": ["/chemin/vers/server.py"],
      "env": {
        "VLLM_URL": "http://localhost:8000/v1/chat/completions",
        "VLLM_MODEL": "cyankiwi/Qwen3.6-35B-A3B-AWQ-4bit"
      }
    }
  }
}

Configuration

Tout passe par l'environnement, rien n'est codé en dur :

• VLLM_URL — défaut http://localhost:8000/v1/chat/completions

• VLLM_MODEL — défaut cyankiwi/Qwen3.6-35B-A3B-AWQ-4bit

Timeout des requêtes : 900 s (génération longue sur Jetson).

Bon à savoir

Le modèle local est plus petit et moins fiable : ses sorties sont des brouillons à relire, pas des vérités. À éviter pour les décisions d'architecture et le code sensible (sécurité, auth, paiement).

Testé avec Python 3.10, httpx 0.28.1, mcp 1.9.4.