La deuxième jambe

Open Weights & modèles locaux

Une pratique Claude-native ne se comprend qu'avec son complément open-weight

Ancrer une pratique sur Anthropic ne veut pas dire s'y enfermer. Un cabinet sérieux doit pouvoir répondre quand un client demande « et si demain vous n'avez plus accès au modèle frontier ? ». Notre réponse : ce qui suit.

Pourquoi une pratique open-weight

Quatre raisons qui ne sont pas idéologiques mais opérationnelles.

Résilience

Un fournisseur central peut, à tout moment, restreindre, suspendre ou dégrader l'accès à un modèle frontier, pour des raisons réglementaires, commerciales, ou opérationnelles. Une pratique open-weight est une assurance : le code continue de tourner.

Gouvernance libre

Poids ouverts + audit public = transparence vérifiable. La sécurité d'un modèle ne se démontre pas par sa fermeture, elle se démontre par la possibilité qu'a la communauté de l'inspecter. La meilleure gouvernance est celle qui est libre et partagée.

Souveraineté du code

Pour un client français ou EU, faire tourner l'IA sur sa propre infrastructure (ou hors des juridictions du fournisseur historique) devient une exigence, pas un caprice. L'open-weight est le seul chemin qui rend cette exigence tenable techniquement.

Alternatives frontier

GLM 5.3 (Z.ai), Kimi K3 (Moonshot), DeepSeek V4. Sans ces modèles, le marché frontier serait un monopole. Notre pratique intègre ces alternatives dans la boîte à outils réelle, pas seulement dans un discours.

Les modèles utilisés

Ce qu'on fait tourner en pratique : local ou distant, dense ou MoE, texte ou multimodal.

ornith-1.5

local · MoE 35B, 3B actifs · Q8

Ornith-1.5-35B-A3B-Q8_0 + vision

Notre 35B local quotidien sur Loom. Experts en RAM, attention en VRAM, 14,2 t/s de décode mesurés, contexte 65 536 tokens, chargé en ~15 s depuis le NVMe. C'est le modèle de nos deux PR llama.cpp.

GGUF Q8llama.cpp--cpu-moemmproj

qwen3.6-35b-a3b

local · MoE 35B, 3B actifs · Q4

Qwen3.6-35B-A3B (abliterated) Q4_K_M + vision

L'alternative à Ornith dans la même classe, en Q4 (20 Go) avec encodeur vision. Même recette d'offload, contexte 32 768 tokens.

GGUF Q4_K_Mllama.cppmmproj

gemma-4-12b

local · dense 12B · Q4

gemma-4-12b-it Q4_K_M + vision

Le dense de Google en 12B, 6,8 Go, avec vision. Tient en RAM d'un portable ordinaire : le candidat pour un poste sans GPU.

GGUF Q4_K_Mllama.cppmmproj

bonsai-2

local · ternaire 4B et 9B

Ternary-Bonsai-2 (Prism ML) Q2_0 + vision

Modèles ternaires : 1,2 Go pour le 4B, 2,4 Go pour le 9B. Mis au banc le 18 octobre 2026 face à Ornith. Le 4B sert de raffineur de prompts pour nos pipelines image.

GGUF Q2_0llama.cppmmproj

glm-5.2 / 5.3

API distante · défaut

GLM 5.2 et GLM 5.3 FlashX (Z.ai)

Notre distant par défaut : GLM 5.2, 1M de contexte, API OpenAI-compatible, remises de cache 94-98 % mesurées. GLM 5.3 FlashX câblé à côté dans le store. L'alternative frontier au tarif réel.

API OpenAI-compatcache_controlstreaming

glm-4.7-flash

API distante · dispatch

GLM 4.7 Flash (Z.ai), MoE 30B-A3B

Palier gratuit utilisé pour les sous-agents (dispatch_agent) : premier essai gratuit, repli vers GLM 5.2. Optimise le coût des tâches courtes.

API OpenAI-compatdispatch subagent

deepseek-v4

API distante · comparaison

DeepSeek V4 Flash

Frontier distant de comparaison, câblé dans le store. Sert à étalonner les réponses des modèles locaux sur nos évals.

API OpenAI-compat

kimi-k3

API distante · long-context

Kimi K3 (Moonshot AI)

Modèle exploré pour l'ingestion de gros corpus documentaires. Câblé côté remote dans notre store de modèles.

API distantelong context

Cette liste n'est pas un catalogue commercial, c'est ce qu'on charge et fait tourner concrètement. Les hébergeurs (Hugging Face pour la distribution, Z.ai / OpenRouter pour les distants) font partie du même écosystème.

La stack

Les briques qu'on utilise, comment elles s'assemblent, pourquoi elles.

Runtime

  • llama.cpp

    moteur d'inférence, roi du GGUF et de l'offload CPU/GPU

  • llama-swap

    proxy multi-modèles avec hot-swap sans redémarrage

  • vLLM

    alternative datacenter (batching continu, PagedAttention) : quand le matos suit

Distribution

  • Hugging Face

    hub central des poids ouverts, formats GGUF/safetensors, huggingface-hub CLI

  • Format GGUF

    conteneur binaire quantizé (Q4, Q8) pour l'inférence CPU/GPU

Techniques

  • Quantization

    Q4 / Q8 : compression 16→4/8 bits, divise mémoire et débit nécessaires

  • MoE + offload

    Mixture of Experts : experts en RAM, attention en VRAM. Rend le 24B+ jouable

  • KV cache

    mémoire de travail de la conversation : clé de la latence

Outillage

  • uv

    gestionnaire Python moderne, remplace pip/venv

  • Playwright

    vérification headless du rendu (pour que l'agent PROUVE qu'une page marche)

  • ruff

    lint/format Python, hook post-tool-use pour tenir la qualité

Notre position, en une phrase

La meilleure gouvernance de l'IA est celle qui est libre et partagée. Sans les acteurs open-weight (GLM, Kimi, Gemma, Qwen, DeepSeek), le marché frontier serait un monopole, et le discours « on vous protège » deviendrait sans contre-pouvoir.

Ce n'est pas un choix contre Anthropic, dont on utilise Claude en production sur plusieurs déploiements. C'est un choix pour la résilience : deux jambes valent mieux qu'une, même très bonne.

Intéressé par cette approche ?

On peut discuter d'un pilote open-weight sur votre stack : local, hybride, ou en fallback d'une intégration frontier existante.