DEPLOY.md

# Endpoint Anthropic pour Claude Code, sur une RTX 6000 Ada à 0,84 $/h

Un pod RunPod, deux modèles au choix, une API compatible Anthropic. Le pod ne
connaît qu'une URL : toute la configuration vit dans `vllm_bootstrap.sh` publié
sur le Hub, et **publier une nouvelle version suffit à reconfigurer la machine

sans jamais la recréer**.


> **Mis à jour le 23/08/2026 au soir.** Le modèle servi est désormais Nemotron
> et non Ornith, la RTX 6000 Ada est passée à **0,74 $/h**, et la configuration
> retenue a changé sur deux drapeaux. Voir
> [« Configuration retenue »](#configuration-retenue-23082026-soir) en fin de
> document — les sections antérieures restent valables pour l'historique et le
> raisonnement, pas comme consigne de déploiement.

## Choix de la machine (mesures du 23/08)

| | 2×A40 | **1× RTX 6000 Ada** |
|---|---:|---:|
| prix | 0,88 $/h | **0,84 $/h** |
| solo, contexte court | 117 tok/s | **134,1** |
| solo à 85 k | 100 | **109,4** |
| 6 agents (par flux) | **26,4** | 24,7 |
| contexte max | **1 M** | 786 k (KV 957 122 jetons) |

L'Ada gagne en solo et coûte moins cher ; la paire d'A40 garde l'avantage en multi-agents
et sur le 1 M. Une seule carte supprime aussi le TP=2 sans P2P, qui coûtait du rendement
(0,25 tok/s par Go/s sur une carte seule contre 0,17 sur la paire).

## Bureau Linux distant

`VL_DESKTOP=on` (ou `bash /opt/desktop.sh` à chaud) lance Xvfb + x11vnc + websockify/noVNC +
XFCE. Accès navigateur, aucun client VNC nécessaire :

```

https://<podid>-6080.proxy.runpod.net/vnc.html?autoconnect=1&resize=remote

mot de passe : $VNC_PASSWORD (défaut SECRET)

```

x11vnc n'écoute que sur la loopback (`-localhost`) ; tout passe par websockify, et le port 6080
doit être exposé en `http` sur le pod. Détails de la pile et raison de chaque option dans
`desktop_setup.sh`.

**Après un restart de conteneur**, les paquets survivent mais les processus meurent : relancer
`bash /opt/desktop.sh`. (Un *Stop*, lui, efface tout le disque conteneur.)

## Mise en service

```

image            registry.hf.space/patdev-ornith-pod:latest  (vLLM precompile)

GPU              1x RTX 6000 Ada (49 Go, sm_89)   0,84 $/h

disque           200 Go  (conteneur ; efface au Stop, pas au restart)

port expose      8080/http

commande         bash -c 'apt-get update -qq >/dev/null 2>&1;

                          apt-get install -y -qq curl ca-certificates >/dev/null 2>&1;

                          curl -sL https://huggingface.co/patdev/k3-a40-bootstrap/resolve/main/vllm_bootstrap.sh -o /run.sh;

                          bash /run.sh'

env              HF_TOKEN, HF_XET_HIGH_PERFORMANCE=1, VL_MODEL=qwen|kimi

```

`create-pod` de l'API RunPod **n'expose pas de champ `args`** : il faut passer
par `create-template` avec `dockerStartCmd`, puis déployer avec `templateId`.
Si la création échoue sur « This machine does not have the resources », c'est
transitoire — préciser `dataCenterIds: ["EU-SE-1"]` suffit généralement.

### Épingler la version CUDA de l'hôte — indispensable

RunPod place le pod sur une machine en CUDA 12.4, 12.8 ou 13.0 **au hasard**.
Le vLLM installé par pip embarque un torch compilé pour CUDA 13.x, qui meurt à
l'initialisation du moteur sur un hôte 12.8 :

```

RuntimeError: The NVIDIA driver on your system is too old (found version 12080)

```

Le même script marche ou échoue selon le tirage. L'outil MCP n'expose pas le
champ, mais **l'API REST l'accepte** :

```bash

curl -X POST https://rest.runpod.io/v1/pods   -H "Authorization: Bearer $RUNPOD_API_KEY" -H "Content-Type: application/json"   -d '{"name":"a40","templateId":"<id>","gpuTypeIds":["NVIDIA A40"],

       "gpuCount":1,"cloudType":"SECURE","dataCenterIds":["EU-SE-1"],

       "allowedCudaVersions":["13.0"]}'

```

Vérifier ensuite `cudaVersion` dans la réponse : il doit valoir `13.0`. Le
bootstrap journalise aussi `pilote <version>, CUDA runtime <x>` au démarrage.

## Branchement de Claude Code

```

ANTHROPIC_BASE_URL=https://<podId>-8080.proxy.runpod.net

ANTHROPIC_API_KEY=peu-importe          # le pont ne verifie rien

```

Le port exposé sert l'API **Anthropic** (`/v1/messages`), c'est-à-dire celle que
Claude Code consomme. vLLM tourne en interne sur 8081 ; le pont relaie aussi
`/v1/chat/completions`, `/v1/completions` et `/metrics` pour les clients OpenAI
et les outils de mesure.

## Les deux modèles

| | Qwen3-Coder-30B-A3B | Kimi-Linear-48B-A3B |
|---|---|---|
| dépôt | `cyankiwi/Qwen3-Coder-30B-A3B-Instruct-AWQ-4bit` | `cyankiwi/Kimi-Linear-48B-A3B-Instruct-AWQ-4bit` |
| poids | 16,9 Gio | 28,4 Gio |
| contexte | 262 144 | **1 048 576** |
| cache de préfixe | **oui (16×)** | non |
| spéculation | **oui (+86 % en édition de code)** | non — elle corrompt le code |
| `VL_MODEL` | `qwen` | `kimi` |

**Ils ne tiennent pas ensemble sur une seule A40** : 16,9 + 28,4 = 45,3 Gio de
poids avant le moindre KV, sur une carte de 46 Go. `VL_MODEL` choisit lequel est
servi ; un endpoint bi-modèle simultané demande deux cartes.

## Réglages, par variable d'environnement

| variable | défaut | effet |
|---|---|---|
| `VL_MODEL` | `qwen` | `qwen` ou `kimi` |
| `VL_CTX` | 262144 / 1048576 | longueur de contexte |
| `VL_SPEC` | `auto` | `off` pour couper la spéculation |
| `VL_SPEC_N` | 12 | profondeur des brouillons |
| `VL_LOOK_MIN` / `VL_LOOK_MAX` | 3 / 8 | fenêtre de correspondance n-gram |
| `VL_BATCHED` | 16384 | `max-num-batched-tokens` |
| `VL_SEQS` | 32 | flux concurrents |
| `VL_UTIL` | 0.90 | fraction de VRAM. **Ne pas monter à 0,93** : l'OOM tombe au tout dernier pas, dans le rejection sampler |

Changer une valeur demande de recréer le pod (les env sont figées) ; changer un
**défaut dans le script** et le publier se propage en 30 s sans rien recréer.

## Correctifs indispensables, et pourquoi

**Tokenizer Kimi.** `tokenization_kimi.py` importe `bytes_to_unicode` depuis
`transformers.convert_slow_tokenizer`, supprimé en transformers ≥ 5.5.3 —
qu'exige tout vLLM ≥ 0.24. Aucun dépôt Kimi-Linear ne fournit de
`tokenizer.json` rapide, donc le tokenizer Python est obligatoire. Corrigé par
`patdev/kimi-linear-tokenizer-fix` : mêmes fichiers, avec une redéfinition
locale de repli, vérifiée identique octet pour octet à la référence transformers
avant tout déploiement.

**Parser d'outils.** `hermes` ne produit aucun appel sur Kimi-Linear. Son
gabarit de chat utilise `<|tool_calls_section_begin|>` / `<|tool_call_begin|>`,
le schéma **K2** — donc `kimi_k2`. (`kimi_k3` vise `<|open|>`/`<|close|>`/
`<|sep|>` et ne s'applique pas.) Pour Qwen, c'est `qwen3_coder`.

**Guillemets.** `--speculative-config` prend du JSON, et les `args` d'un pod
RunPod transitent par un shell qui **mange les guillemets** : il faut entourer
le JSON d'apostrophes et n'y mettre aucun espace. Le bootstrap le fait pour
vous ; le piège ne concerne que les configurations passées en dur.

**Tensor parallelism.** Sur une paire d'A40 RunPod, `NCCL_P2P_DISABLE=1` est
nécessaire, sinon l'initialisation NCCL ne rend jamais la main.

## Image précompilée (depuis le 21/08/2026)

Le pod ne réinstalle plus rien au démarrage : l'image Docker est construite
par le Space `patdev/ornith-vllm-a40` (sdk docker, gratuit, sur CPU) et tirée
par RunPod depuis `registry.hf.space/patdev-ornith-vllm-a40:latest` avec un
`containerRegistryAuthId` (user `patdev`, mot de passe = token HF). Elle
contient vLLM 0.27.1 (cu13) dans `/opt/venv`, `cuda-compat-13-0`, `nvcc` et
les en-têtes CUDA 13. Le bootstrap (v35+) lit `/opt/.image_prebaked` et saute
la phase d'installation : **~15 s** entre le démarrage du conteneur et
`vllm serve`, contre ~8 min avant.

Création : `scratchpad/create_pod.py` (template `ornith-vllm-a40-prebaked`,
`dockerStartCmd: ["/start_pod.sh"]` = sshd en arrière-plan + bootstrap du Hub).

Pièges :
- **Un pod arrêté peut refuser de redémarrer** ("not enough free GPUs on the
  host machine") : l'hôte a été reloué. Recréer, le disque est perdu de toute
  façon (volume 0).
- **Premier pull ~9 min** (18 Go, une seule couche) ; ensuite l'hôte le met en
  cache. L'image v2 sépare les couches et retire le torch cu128 de la base.
- **`NCCL_P2P_DISABLE=1` est obligatoire** (bootstrap v37) : sur deux A40
  placées sur deux nœuds NUMA (`nvidia-smi topo` = SYS), le premier collectif
  après la capture des graphes CUDA tourne en attente active — GPU à 100 %,
  0 % d'activité mémoire, workers en `futex_wait`, "No available shared memory
  broadcast block" toutes les 60 s. Rien dans le journal ne dit "NCCL".
- **Le watcher de rechargement n'est actif qu'une fois vLLM sain.** Si vLLM
  est bloqué au démarrage, publier une nouvelle version ne suffit pas : tuer
  le serveur (`pkill -9 -f "vllm [s]erve"` — les crochets évitent que pkill se
  tue lui-même) ; le bootstrap passe en `fatal`, scrute le Hub et recharge.
- **Hôte malade, signature complète** (pod `udpfa0l4z65m09`, 21/08) : première
  génération → `CUDA error: unspecified launch failure` dans `synchronize()` ;
  ensuite un GPU disparaît pour CUDA (`No CUDA GPUs are available` en le
  ciblant seul, `nvidia-smi` le liste encore, pstate P0 avec puissance N/A) ;
  `torch.cuda.device_count()` dit 2 mais `get_device_name(1)` échoue ; vLLM
  TP=2 meurt sur "DP adjusted local rank 1 is out of bounds for 1 devices" ;
  et `POST /pods/{id}/restart` répond 500 "context deadline exceeded" vers
  `hapi.runpod.net`. Rien de tout ça ne se répare depuis le conteneur : supprimer
  le pod et recréer (la création choisit un autre hôte).
- `vllm --version` dans un Dockerfile meurt sur un constructeur sans GPU
  ("Failed to infer device type") ; vérifier via `importlib.metadata`.

## Leviers mesurés (bootstrap v41, bloc EXPERIENCE en tête de script)

| Variable | Valeurs | Effet mesuré (2×A40, Ornith, 22/08) |
|---|---|---|
| `VL_KV` | `""` (bf16) / `turboquant_k3v4_nc` (défaut) / `turboquant_k8v4` / `fp8` | TurboQuant : KV ×4,33 (12,08 M jetons), débit −6 % à 32 sessions, +7 % solo |
| `VL_SPEC` | `off` (défaut) / `dspark` / `mtp` / `on` (ngram) | DSpark : +71 % solo, −1 % à 32 sessions, KV −6 % ; incompatible avec TurboQuant |
| `VL_DSPARK_N` | 8 | jetons proposés (tête de confiance adaptative) |
| `VL_SWAP` | `ornith:ornithnvfp4,qwen38:qwen38nvfp4` (défaut) | v70 : noms servis → clés de modèle interchangeables ; une requête pour un modèle non chargé déclenche le swap (`/travail/modele_demande`, re-exec avec `VL_MODEL`). Mesuré 28/08 : 368 s à la 1re compilation, pings SSE pendant l'attente (pont v71) |
| `VL_SPEC_AUTO` | `on` (défaut) / `off` | v70 : spéculation par modèle — MTP k=3 sur Qwen3.8-27B (73–83 j/s solo sur PRO 5000 NVFP4), off sur Ornith ; `off` rend la main à `VL_SPEC` |
| `VL_PRECHARGE` | dépôts HF séparés par des espaces | v70 : poids préchargés en tâche de fond après le premier service, pour un swap sans téléchargement |
| `VL_FLASHINFER` | `off` (défaut) | le sampler flashinfer a produit une faute CUDA sur un hôte 580 |
| `VL_NUMA`, `VL_EP`, `VL_OPT` | `off` / `off` / `""` (défaut) | mesurés neutres (v43d) ; membind refusé sans `SYS_NICE` ; O3 == O2 |
| `VL_FASTOK` | `1` (défaut) | fastokens (tokenizer Rust) : −12 % TTFT médian, +1,5 % solo ; installé à la volée si absent |
| `VL_KVBYTES` | `""` (défaut) | `--kv-cache-memory-bytes` : **+22 % de capacité KV** sur Flash-Next (26/08), voir « Le cache KV » ; une valeur trop haute tue le moteur en service, pas au démarrage |
| `VL_MM_IMAGES` | `4` | plafond d'images par requête. **À `0`, vLLM rejette toute capture par un 400** dont le texte est le plafond lui-même ; voir « Les images » |
| `VL_DP` | `1` (défaut) | parallélisme de données (un réplica par GPU) : +15 % à 32 sessions sur Qwen3.8, perd le solo et la moitié du KV |

Modifier les défauts, republier `vllm_bootstrap.sh` sur `patdev/k3-a40-bootstrap` :
le pod recharge à chaud (~4 min, poids conservés). `scratchpad/drive_pod.py`
automatise publication → attente → banc (`pod_bench.py`).

## Pièges d'exploitation

- Le **proxy HTTP de RunPod coupe à ~125 s** (Cloudflare, `error code: 524`).
  Un prefill à froid plus long ne passe pas en un seul appel — découper le
  prompt, chaque requête étendant le préfixe caché.
- Un **`wait` sans argument** dans le script attend aussi le serveur lancé en
  arrière-plan, indéfiniment : le serveur répond, mais le watcher ne démarre
  jamais et les mises à jour publiées sont ignorées en silence. Toujours
  `wait "$pid"` explicite. Idem pour `%1`, qui désigne le job du serveur.
- **Redémarrer un pod efface son disque conteneur.** Le rechargement en place
  par le watcher évite de retélécharger les poids.

---

## Branchement de Claude Code — validé de bout en bout

```bash

export ANTHROPIC_BASE_URL=https://<podId>-8080.proxy.runpod.net

export ANTHROPIC_API_KEY=dummy          # le pont ne verifie rien

export CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1

claude --model claude-kimi-k3

```

**Les identifiants de modèle doivent commencer par `claude-`.** Claude Code
valide le nom avant d'émettre la requête et refuse tout le reste. Le pont expose
donc des alias conformes et ignore le nom reçu pour router vers l'unique modèle
chargé : le client choisit une étiquette, pas un moteur.

```

claude-kimi-k3          claude-kimi-k3-linear     claude-qwen3-coder

claude-sonnet-4-5       claude-3-5-haiku

```

Les deux derniers existent parce que certains clients codent en dur un modèle
« rapide » et un « lent ».

`CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1` évite que Claude Code
plafonne la session à 200k alors que l'endpoint en sert 262 144. L'alternative
propre est de déclarer le modèle dans le réglage `modelOverrides`.

### Preuve d'exécution

Édition réelle d'un fichier via les outils, en 45 s :

```python

# avant

def divide(a, b):

    return a / b



# apres

def divide(a: Union[int, float], b: Union[int, float]) -> Union[int, float]:

    """Divide two numbers.



    Raises:

        ZeroDivisionError: If b is zero

    """

    if b == 0:

        raise ZeroDivisionError("Cannot divide by zero")

    return a / b

```

Claude Code a lu le fichier, appelé les outils, appliqué les annotations, ajouté
la garde et documenté. Deux avertissements bénins subsistent : le modèle n'est
pas au catalogue (fenêtre supposée), et l'outil Advisor se désactive faute de
rang dans ce catalogue.

### `/v1/models` sert deux protocoles

La distinction se fait sur l'en-tête `anthropic-version` :

```

avec l'en-tete    {"data":[{"type":"model","id":"claude-kimi-k3",...}], "has_more":false}

sans              la reponse native de vLLM, dont les bancs lisent max_model_len

```

## Configuration finale (bootstrap v50, 22/08/2026)

Ornith-1.5-35B-A3B AWQ, TP=2, YaRN ×4 (1M validé à 634 k en bf16),
`VL_KV=turboquant_k3v4_nc` (KV ~10,6 M à util 0,85 ; 12,08 M à 0,93),
`VL_SPEC=off`, `VL_UTIL=0.85` (marge VRAM pour le prefill TurboQuant),
`VL_BATCHED=16384`, fastokens on, numa/EP/O3/kvbytes off (mesurés neutres).
Variante vitesse solo : `VL_KV=` + `VL_SPEC=dspark` (171 j/s, KV 2,6 M).
Qwen3.8-27B : `FORCE_MODEL="dense"` (W4A16, MTP k=3, 262 k natif ; 1M possible
avec YaRN+TurboQuant mais ~12 min de prefill et 3,7 sessions).

Pièges de la nuit du 22 :
- **TurboQuant + prefill long = marge VRAM obligatoire** : le backend déquantifie
  le K en cache en bf16 dense à chaque tranche (`turboquant_attn.py

  _continuation_prefill`) ; à 0,93 d'utilisation, un prompt de 700 k tue le

  moteur (OOM 516 Mio). 0,85 le règle pour −12 % de KV.

- **Banc de prefill et cache de préfixe** : des textes qui partagent un préfixe

  avec des requêtes précédentes donnent un « froid » à 40 k j/s, faux. Saler

  chaque prompt (`prefill_bench.py` le fait).
- `--max-num-batched-tokens 65536` : neutre sur A40 (prefill borné par le
  calcul). `--numa-bind` demande `--numa-bind-nodes 0 1` dans un conteneur, et
  le membind est refusé sans `SYS_NICE`.
- Le proxy RunPod renvoie **403 à l'User-Agent Python par défaut** : toujours
  poser un `User-Agent` dans les clients de test.

## Raisonnement : trois correctifs du pont (22/08 soir, mesurés)

1. **Le raisonnement n'arrivait jamais à Claude Code.** vLLM 0.27.1 diffuse le
   raisonnement en flux sous `delta.reasoning` (et `reasoning_content` en
   non-flux) ; le pont ne lisait que le second → jetons dépensés, rien montré.
   Corrigé : les deux clés. Mesure : 0 → 246 car. de bloc `thinking` sur la même
   question.
2. **Le niveau de raisonnement (budget) n'était pas transmis.** Anthropic
   `thinking.budget_tokens` → vLLM `thinking_token_budget` (sampling params, il
   ferme le bloc à ce nombre de jetons). Mesure sur un problème à étapes :
   budget 64 → 168 car. de raisonnement, réponse fausse ; 512 → 1 155 car.,
   juste ; 8 000 → 1 443 car. (le modèle s'arrête seul), juste. `disabled` →
   0 car., 49 jetons de sortie. `adaptive` (ce qu'envoie Claude Code) = actif
   sans plafond.
3. **Le raisonnement de l'historique était jeté.** Dans les boucles d'outils,
   Claude Code renvoie le bloc `thinking` du tour précédent ; le pont l'ignorait
   → le modèle perdait son plan entre deux appels. Corrigé : les blocs
   `thinking` d'un tour assistant deviennent `reasoning_content` du message
   OpenAI ; le gabarit Qwen3.5 le conserve pour le dernier tour (même
   sémantique qu'Anthropic). Vérifié : historique thinking + tool_use +

   tool_result accepté par vLLM, réponse cohérente.

## Audit du pont (22/08 soir) — `audit_pont.py`, 13 cas contre le pod



Bugs trouvés et corrigés (tous vérifiés avant/après) :

- **non-flux** : le raisonnement n'était pas rendu en bloc `thinking` (seul le

  flux l'était) → `to_anthropic` le fait, avec `signature`.
- **`cache_read_input_tokens` jamais exposé** : deux causes — le pont ne lisait

  pas `prompt_tokens_details.cached_tokens`, et vLLM ne le renseigne qu'avec

  `--enable-prompt-tokens-details` (bootstrap v51). Claude Code affichait 0 %

  de cache alors que vLLM en servait ~68 %.

- **`count_tokens` ignorait système et outils** (len/4 des seuls messages : 13
  jetons pour un appel qui en pesait 398) → compte réel via `/tokenize` de
  vLLM en forme chat, repli sur l'estimation.
- **`stop_sequences`** : la chaîne coupait bien mais `stop_reason` disait

  `end_turn` → `stop_sequence` + champ `stop_sequence` (vLLM le rapporte dans

  `choice.stop_reason`).

- **`signature_delta`** absent avant la fermeture des blocs thinking → émis aux
  deux points de fermeture (passage au texte, fin de flux).

Vérifiés OK sans changement : `max_tokens` → `stop_reason=max_tokens`, système
en liste de blocs + `cache_control`, `tool_use` en flux (`input_json_delta`
reconstitue un JSON valide, `stop_reason=tool_use`), `tool_result.is_error`,
`redacted_thinking` dans l'historique, `temperature/top_p/top_k/metadata`,
préremplissage par un dernier message assistant, modèle inconnu (repli sur le
modèle servi, 200).

Vérifié après v51 : `cache_read_input_tokens` = 23 360 sur 24 047 au second
appel d'un prompt de 24 k (bloc de cache = 784 jetons en mode mamba align : un
prompt d'un seul bloc ne rapporte rien, c'est normal). Audit : **13/13**.

### Le pont est-il encore nécessaire ? (vLLM 0.27.1 sert `/v1/messages` nativement)

Oui, vLLM expose déjà `/v1/messages` et `/v1/messages/count_tokens` sur le même
port que l'API OpenAI (`vllm/entrypoints/anthropic/`) : blocs `thinking` avec
signature, `tool_use`/`input_json_delta`, images, `stop_sequence`, `ping`,
`cache_read_input_tokens`, `redacted_thinking`, raisonnement de l'historique
→ `reasoning`, fusion des messages système inline. Testé sur le pod :
`curl 127.0.0.1:18081/v1/messages` répond correctement.

Ce que le pont ajoute encore (mesuré ou vérifié dans les sources) :
- le **niveau de raisonnement** : `thinking.budget_tokens` → `thinking_token_budget`
  (absent du serveur natif, qui ne connaît que `output_config.effort`) ;
- les **alias** `claude-*` / `[1m]` avec `context_window` dans `/v1/models`
  (Claude Code lit `id`/`display_name` pour la découverte) ;
- le **keepalive pendant le préremplissage** (ping toutes les 15 s : le proxy
  RunPod coupe à ~125 s de silence — un prefill de 634 k dure 4 min) ;
- le **garde agentique** (refus des commandes destructrices, 4/4 au test), la
  console, la trace par requête, la transmission intacte des erreurs amont.
Pour un usage direct sans RunPod ni garde, le natif suffit : pointer
`ANTHROPIC_BASE_URL` sur le port vLLM et `ANTHROPIC_MODEL=ornith`.

## Pont optionnel (bootstrap v52) : `VL_BRIDGE`



| `VL_BRIDGE` | Ce qui écoute sur 8080 | Ce que ça donne |
|---|---|---|
| `on` | le pont (`anthropic_proxy.py`), vLLM derrière en 18081 | budget de raisonnement respecté, keepalive de prefill (proxy RunPod), `/v1/models` au format Anthropic, garde agentique, console, trace |
| `off` | vLLM lui-même (natif) | `/v1/messages` + `count_tokens` natifs vLLM (thinking + signature, outils, images, ping, cache), `/v1/models` au format OpenAI ; **pas** de budget de raisonnement ; keepalive de prefill non garanti derrière le proxy RunPod |

Dans les deux modes vLLM sert les alias `--served-model-name ornith claude-ornith
"claude-ornith[1m]"` : `ANTHROPIC_MODEL=claude-ornith[1m]` marche partout, et

`connect.ps1` aussi (il vérifie l'`id` dans `/v1/models`). Bascule : une ligne du

bloc EXPERIENCE + republication (vLLM redémarre, ~4 min).



Test du mode natif (`VL_BRIDGE=off`, 22/08 19:13, via le proxy RunPod) :
`/v1/models` liste `ornith`, `claude-ornith`, `claude-ornith[1m]` (max_model_len
1 000 000) ; `/v1/messages` non-flux → blocs `thinking` + `text`, usage avec
`cache_read_input_tokens` ; flux → `message_start … thinking_delta … message_stop` ;
`count_tokens` compte le système. `budget_tokens: 64` → 267 car. de raisonnement :
**le budget est ignoré en natif**, comme prévu. Défaut final v53 : `VL_BRIDGE=on`.

### 22/08 soir : natif par défaut (v54), garde corrigé

Sur demande, `VL_BRIDGE=off` est le défaut : vLLM écoute 8080 directement. Comme
vLLM natif ne répond qu'aux ids servis, `VL_ALIASES` ajoute les noms que Claude
Code et ses agents envoient : `claude-3-5-haiku claude-haiku-4-5 claude-sonnet-5
claude-opus-5 deepseek-v4-flash deepseek-v4-pro` (tous → le modèle servi).
Le garde-fou du pont (si `VL_BRIDGE=on`) ne couvre plus que les écritures de
fichier entier (`write/write_file/create_file`) et ne réagit qu'aux marqueurs
explicites (`... rest of file`, `[... previous ...]`, `(reste du fichier`,
`<unchanged>`) — les faux positifs `[...]` / `# ...` observés en session réelle
sont retirés.

### Temps de démarrage (mesuré v54, caches chauds) : 2 min 33

36 s init API server (tokenizer 248 k, processeurs image/vidéo, appels Hub) ·
24 s NCCL/TP + noyaux · 32 s poids · 7 s compile (cache ; 71 s à froid) · 2 s
warmup (65 s à froid) · 5 s graphes CUDA. v55 (préparée, non publiée) :
`--limit-mm-per-prompt '{"video":0}'` et `HF_HUB_OFFLINE=1` quand le modèle est
en cache → visé ~1 min 45. Le vrai levier reste le nombre de redémarrages : en
natif tout changement de flag/alias en coûte un ; le pont rechargeait en 5 s.

### Niveau de raisonnement en natif : patch vLLM (v55)

Constat (sources 0.27.1) : le serveur Anthropic natif ne lit pas `thinking`
(champ absent de `AnthropicMessagesRequest`, jeté par pydantic) et ne traduit
`output_config.effort` qu'en `reasoning_effort`, que seul Harmony/GPT-OSS
honore. Sur Ornith, effort low = max, et `disabled` n'agit pas.

`vllm_anthropic_effort_patch.py` (appliqué par le bootstrap avant `vllm serve`,
idempotent, `VL_EFFORT_PATCH=off` pour le couper) ajoute le champ `thinking` et
mappe : effort low/medium/high/xhigh/max → `thinking_token_budget`
1 024 / 4 096 / 16 384 / 32 768 / illimité ; `thinking.budget_tokens` explicite
gagne ; `thinking.type=disabled` → `enable_thinking=false`. Même mécanisme que
le pont (le bloc de raisonnement est fermé au plafond côté échantillonnage).

Mesure après v55 (natif, patch actif, problème à étapes « trains ») :
`thinking disabled` → 0 car. de raisonnement (avant : ignoré) ; `budget_tokens 64`
→ 164 car., réponse fausse (plafond appliqué) ; effort low/medium/max → ~1 125
car. chacun, justes : le modèle n'a eu besoin que d'~300 jetons de raisonnement,
sous le plafond `low` (1 024) — la plomberie agit (preuve par budget/disabled),
le niveau ne devient visible que sur des problèmes plus longs. Seuils
modifiables dans `vllm_anthropic_effort_patch.py` (`_BUDGET`).
Démarrage v55 : 4 min 37 — le changement de `--limit-mm-per-prompt` a invalidé
le cache torch.compile (73 s) et le warmup (67 s) une fois ; la phase avant les
poids est passée de 85 s à 64 s (Hub hors-ligne + vidéo off). Prochain
redémarrage à config identique attendu ~2 min.

## Régime multi-agents (22/08 soir, bootstrap v56 → v62) — le diagnostic par `/metrics`

Symptôme : six sous-agents Claude Code (65–120 k de contexte chacun) « lents ».
Ce que disaient les métriques vLLM (`GET /metrics` passe par le proxy RunPod) :
6 requêtes en cours, 0 en attente, KV à 7 %, **génération agrégée 2–85 j/s**,
prefill 5–8,6 k j/s quasi continu, cache de préfixe 62 % → ~25 k jetons
re-prefillés par tour, et pendant chaque tranche de 16 384 jetons les autres
flux n'avançaient que d'un jeton par pas (~2,5 s). Un rejeu de boucle agent
(thinking + tool_use + tool_result × 7) a montré que **le préfixe ne se casse

pas** : hits exactement sur les multiples du bloc. Les ratés sont réels
(gros `tool_result`, démarrages à froid, alignement du bloc).

Deux faits de structure :
- avec TurboQuant, vLLM monte le **bloc d'attention à 4 672 jetons** pour égaler
  la page Mamba (784 en bf16) : granularité du cache et re-prefill par tour ;
- `--max-num-batched-tokens 16384` gèle les décodes pendant chaque tranche.

Banc `agent_bench.py` (6 agents × 4 tours × ~80 k, flux SSE, `claude-ornith[1m]`) :

| Version | Config | Décodage / flux | Agrégé | Cache | TTFT (cache chaud) |
|---|---|---:|---:|---:|---:|
| v55 (avant) | TurboQuant, pas 16 384 | 2–12 j/s (agents réels) | ~25 | 62 % | — |
| **v59 = v62** | **bf16, pas 4 096, FA2** | **26,4** | **55** | **99 %** | 2–3 s |
| v60 | bf16, pas 4 096, FlashInfer | 28,5 | 61 | 99 % | 2–4 s |
| v61 | TurboQuant, pas 4 096 | 15,0 | 40 | 97 % | 2–4 s |

Un flux seul fait **100 j/s à 85 k** comme 117 à 1 k : le long contexte ne
coûte rien seul. En concurrence, 6 × 85 k × 10 Ko de KV bf16 par GPU = 5 Go lus
à chaque pas sur une A40 à 696 Go/s, plus le noyau de décodage : ni FlashInfer
(= bruit) ni TurboQuant (déquantification à chaque pas, pire) ne lèvent la
limite. Au-delà, c'est la bande passante de la carte, pas un flag.
Le prefill à froid de 6 × 80 k se fait en série (~6,7 k j/s, 12 s chacun) :
`--max-num-partial-prefills` ne changerait pas le total (borné par le calcul).

DSpark (v56–v58) a été essayé puis **écarté** : vLLM 0.27.1 ne l'implémente que
dans le Model Runner V2, et V2 **rejette toute requête** portant
`thinking_token_budget` (`VLLMValidationError … not yet supported by the V2
model runner`) — or le patch effort en pose un dès que Claude Code envoie
`effort`/`budget` : Claude Code recevait des 500. DSpark et niveaux d'effort
s'excluent ; `VL_SPEC=dspark` coupe désormais le patch effort automatiquement.
À 0,93 d'utilisation, DSpark a aussi frôlé l'OOM à la capture des graphes
(220 Mio libres) : 0,90 dans ce cas.

Deux bugs de bootstrap corrigés au passage : le brouillon DSpark n'était pas
téléchargeable parce que `HF_HUB_OFFLINE=1` était posé dès qu'Ornith était en
cache (v57 : pré-téléchargement) ; et `exec bash /run.sh` **hérite de

l'environnement**, donc le `HF_HUB_OFFLINE=1` du run précédent survivait au
rechargement (v58 : `unset` en tête).

Effort en v59+ (natif, patch actif, problème « trains ») : `disabled` → 0 car.,
`budget 64` → 179 car., `low` → 1 569, `max` → 3 463 (plafonné par
max_tokens) : les niveaux se distinguent.



Configuration par défaut depuis v62 : `VL_KV=` (bf16), `VL_SPEC=off`,

`VL_BATCHED=4096`, `VL_ATTN=` (FA2), util 0,93, KV 2,84 M jetons (1M solo

tient ; ~20 agents à 120 k aussi). `VL_KV=turboquant_k3v4_nc` reste là pour
>10 sessions à 1M simultanées (util 0,85 automatique).
Une requête restée **silencieuse** plus de ~125 s prend un 524 du proxy RunPod.

> **Précision du 23/08.** Le critère n'est pas « non streamée » mais « aucun octet
> émis » : vLLM n'envoie rien avant la fin du prefill, donc une requête *streamée*
> avec un gros prompt froid se fait couper aussi. Mesuré : 352 230 jetons passent
> en 97 s, ~427 k rendent un 524 à 126 s, et le délai est le même quelle que soit
> la taille. Ce qui protège Claude Code n'est pas le streaming, c'est le **ping

> SSE du pont sur `/v1/messages`** — vérifié à ~500 k de prompt froid : premier
> jeton à 221,7 s avec 30 pings, et à ~780 k premier jeton à **538,8 s** avec
> 72 pings, soit une connexion tenue neuf minutes. Le relais
> `/v1/chat/completions`, lui, n'a pas ce keepalive.

### MTP native (v63–v64) : chargée, mesurée, écartée

La tête MTP d'`ulkaa/Ornith-1.5-35B-A3B-AWQ-INT4` est en BF16 ; seul le `ignore` du
config.json manquait (`re:.*mtp\..*`). Le bootstrap patche le snapshot (glob sur `$HUBDIR`,
idempotent, trace `/tmp/mtp_patch.log`) quand `VL_SPEC=mtp`. Mesure n=2 : solo 1 k 100,7 j/s
(117 sans), solo 85 k **27,6** (100 sans), 6 agents 14,2/flux (26,4 sans) ; acceptation pos0
55 %, pos1 9 %. Défaut : `VL_SPEC=off` (v65). Détail dans `reports/`.

### Agents « lecteurs », A/B du pas, coupure proxy, pont par défaut (v66 → v68)

Régime observé pendant un vrai audit (5 sous-agents à ~150 k qui lisent des fichiers) :
+177 k jetons de prompt en 30 s (5,9 k j/s = le max de la carte) pour 667 jetons générés
(22 j/s agrégé, ~5 j/s par agent) — **le GPU est saturé par le prefill**, pas bloqué (0 en
attente, 0 abandon, TTFT < 20 s). Banc `agent_bench.py 6 3 50 300 15` (6 agents, +65 k de
contexte par tour, 80 → 144 k) :

| Pas | Décodage / flux | Agrégé | TTFT (cache chaud) | Mur |
|---|---:|---:|---:|---:|
| 2 048 (v66) | 7,0 j/s | 15 | 37 s | 330 s |
| 4 096 (v67) | 7,1 j/s | 15 | 41 s | 304 s |

Identique : ce régime est borné par le **calcul** de prefill (390 k jetons par tour de table ≈
60 s), pas par l'ordonnanceur. Pas gardé à 4 096.

**Coupure proxy** : quand le TTFT dépasse ~100 s (file de prefill), le proxy RunPod ferme la
connexion (« Response ended prematurely » ; 524 à 125 s en non-flux). vLLM natif n'émet rien
avant le premier jeton. Le pont envoie un `ping` SSE toutes les 15 s → **`VL_BRIDGE=on` par

défaut depuis v68** ; le pont mappe désormais aussi `output_config.effort` (mêmes seuils que le

patch natif). `VL_BRIDGE=off` = natif + patch effort, pour un usage léger.



Leviers réels pour ce régime : moins de réflexion pour les sous-agents (`effort: low`), moins

d'agents en parallèle, outils qui renvoient moins de texte ; au-delà, du calcul GPU

(`reports/2026-08-22-materiel-prix-runpod-hf.md`).



### Pont muet sous charge (22/08 nuit) : fuite de flux amont, pool httpx saturé



Symptôme : agents Claude Code à 0 jeton / « failed », `/metrics` via le proxy en timeout ; sur

le pod : vLLM sain (health 2 ms, 0 requête, GPU 0 %), **pont vivant (3 % CPU, 117 fd) mais

`/health` en timeout**. Journal du pont : 189 `POST /v1/messages` pour 100 traces de fin ;

`ss` : 45 connexions amont vers vLLM pour 2 clients. Les flux abandonnés côté client (retry de

Claude Code, coupure proxy) gardaient leur connexion amont — vLLM générait pour personne — et à

100 connexions (limite httpx par défaut) le pool bloquait tout, `/health` compris (il passe par

l'amont).



Correctifs : (1) `stream_anthropic` reçoit la `Request` et **ferme l'amont quand le client est
parti** (`request.is_disconnected()` à chaque ping et tous les 32 jetons) → vLLM annule la
génération ; (2) `httpx.Limits(max_connections=512, max_keepalive_connections=64)` et
`httpx.Timeout(TIMEOUT, connect=10, pool=10)` → une saturation devient un 503 rapide, plus un
blocage ; (3) chien de garde dans le watcher du bootstrap (v69) : deux `/health` KO d'affilée
→ relance du pont seul, journal conservé dans `/tmp/proxy.hung.*.log` (et, posé à la main ce
soir, `/opt/pont_watchdog.sh`). Le pont se recharge à chaud depuis le Hub sans toucher à vLLM.

## Intégration Claude Code : les quatre pièges côté pont/client (23/08)

Une fois le débit compris, les problèmes restants étaient côté pont ou côté Claude Code, jamais
le modèle. Détail et mesures : `reports/2026-08-23-pont-et-integration-claude-code.md`.

1. **Pont muet sous charge** — flux abandonnés par le client → connexions amont fuitées (45 pour
   2 clients, 189 requêtes / 100 fins) → pool httpx (100) saturé → `/health` bloqué, agents à
   0 jeton. Corrigé : `request.is_disconnected()` ferme l'amont, `httpx.Limits(512)` +
   `Timeout(pool=10)`, chien de garde du pont (relance sur 2 `/health` KO). Diagnostic :
   `ss -tn | grep -c :18081` vs nombre de clients.
2. **`[1m]` obligatoire dans le nom de modèle** — sans lui, Claude Code suppose ~200 k et lance
   la compaction automatique à ~150 k. Sous-agents = `deepseek-v4-flash[1m]` /
   `deepseek-v4-pro[1m]` ; alias `[1m]` ajoutés à `VL_ALIASES` (v69).
3. **Réponse sans texte → compaction vide** — le modèle mettait tout dans le raisonnement
   (`texte=0c`). Le pont a un repli : pas de texte ni d'outil → raisonnement rendu en texte.
4. **Compteur de jetons figé** — le pont n'émettait qu'un `message_delta` final ; il émet
   désormais un `message_delta` toutes les 0,5 s avec `output_tokens` cumulé
   (`continuous_usage_stats`), comme l'API Anthropic (11 événements au lieu de 1).

**Débit solo** : un agent seul = 86–106 tok/s (le plafond solo d'Ornith sur A40), cache de
préfixe 94 %. Ça paraît lent parce que c'est un seul flux avec beaucoup de raisonnement (jusqu'à
~3 900 jetons de réflexion en un tour = ~43 s) ; le débit ne monte qu'en parallélisant. Leviers
côté client : `effort: low`, plus d'agents en parallèle, sorties/outils moins bavards.

**v69 (préparé, non publié)** rassemble : chien de garde du pont, alias `[1m]`, correction de la
fuite de connexions, repli réponse vide, usage incrémental. À publier hors charge (un `publish`
relance vLLM). Les correctifs du pont ont été déployés à chaud sur le pod entre-temps.


## Bascule NVFP4 (bootstrap v74, 23/08/2026) — configuration servie aujourd'hui

    VL_MODEL=ornithnvfp4   VL_SPEC=off   VL_CTX=1048576


`ornith-ai/Ornith-1.5-35B-A3B-NVFP4` remplace `ulkaa/…-AWQ-INT4`. Raison, calculée
sur les formes de tenseurs (octets **lus par jeton** en décodage, tour visuelle
exclue) :

| dépôt | dense | `lm_head` | 8/256 experts | actif | plafond |
|---|---:|---:|---:|---:|---:|
| `ulkaa` AWQ-INT4 | 2,86 | 1,02 | 0,63 | 4,51 Go | 213 t/s |
| `ornith-ai` FP8 | 2,46 | 1,02 | 1,06 | 4,54 Go | 211 t/s |
| **`ornith-ai` NVFP4** | **1,40** | **0,29** | **0,62** | **2,30 Go** | **416 t/s** |

L'AWQ ne quantifiait que les experts routés — 531 entrées dans `ignore` — donc
**86 % de ce qui est lu à chaque jeton restait en BF16**. Le FP8 officiel est un
piège symétrique : il grossit les experts, qui ne pèsent que 14 % de la lecture,
sans alléger le dense.

**Ce que vLLM en fait sur sm89** : `MarlinNvFp4LinearKernel` et backend MoE
`MARLIN` (les autres candidats exigent Blackwell). Poids 21,94 Gio, et la config
modelopt impose un **KV en fp8** : cache de **2 103 356 jetons**, soit 2,01× de
concurrence à 1 048 576. Le vrai 1 M tient sur une carte, sans TurboQuant.

### Débits mesurés (sortie contrôlée en 4-grammes, 0,82 à 0,99)

| session unique | 3 k | 32 k | 114 k | 282 k | 1 011 609 |
|---|---:|---:|---:|---:|---:|
| AWQ-INT4 | 132,3 | 125,4 | 103,1 | 73,2 | *impossible* |
| **NVFP4** | **201,0** | **187,2** | **156,5** | **119,7** | **58,9** |

| sessions | 1 | 2 | 4 | 8 | 16 |
|---|---:|---:|---:|---:|---:|
| agrégé | 127 | 274 | 398 | 646 | **1 108** |

Loi de décodage : `t(L) = 4,936 ms + 0,01274 µs × L`, vérifiée à 5 % près à 1 M.

### `VL_SPEC` doit rester à `off`



La MTP avait déjà été écartée sur l'AWQ (v63–v65). Elle reste perdante sur le

NVFP4, et plus nettement : **66 tok/s contre 201**. La chaîne est causale et vaut

la peine d'être retenue — le KV fp8 interdit FA2 sur sm89, vLLM bascule sur

FlashInfer, et FlashInfer refuse `CUDAGraphMode.FULL_AND_PIECEWISE` sous

spéculation ; vLLM coupe en plus `--async-scheduling`. La spéculation émettait

pourtant 1,93 jeton par passe (acceptation 75,7 / 15,4 / 1,8 % par position) :

c'est le surcoût par passe, ×3,9, qui noie le gain.



### Nouveautés du bootstrap v74



- `FORCE_MODEL="${VL_MODEL:-ornith}"` : le défaut ne change pas, mais `VL_MODEL`
  redevient surchargeable — **seul levier quand on n'a pas de shell sur le pod**.
- **Journal distant** : la fin de `/tmp/boot.log` et de `/tmp/vllm.log` est
  republiée toutes les 25 s sur
  `patdev/k3-a40-bootstrap/etat/<POD_ID>.log`, tant que `/v1/models` ne répond
  pas. Sans lui, un démarrage raté est invisible dès que SSH est indisponible.
- Le correctif de config MTP couvre aussi `ornithnvfp4` (sans effet : ce dépôt
  exclut déjà `mtp*` de la quantification).

### Ce qui est ferme, et qu'il ne faut plus retenter

- **TRT-LLM sur MoE Ada** : noyau MoE 4 bits réservé à sm90.
- **EP TensorRT sur l'ONNX d'Ornith** : il ne prend que 181 nœuds sur 988, tous
  de plomberie ; les 441 qui portent les poids restent sur CUDA, et le graphe
  partagé interdit la capture CUDA.
- **Réécriture QDQ du MoE** : TensorRT gagne 2,14× à index d'experts fixe, mais
  refuse de construire le moteur dès qu'un `Gather` s'intercale entre la
  constante quantifiée et son `DequantizeLinear`. La sparsité dynamique est
  incompatible avec un moteur compilé statiquement.

Détail complet et chiffré :
`reports/2026-08-23-plafond-solo-et-dtype-du-chemin-dense.md`.

---

# Configuration retenue (23/08/2026, soir)

Ce que 23 mesures de la journée désignent, toutes sur
`nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4`.

## Branchement de Claude Code — la version qui marche

```powershell

Remove-Item Env:\ANTHROPIC_API_KEY -ErrorAction SilentlyContinue

$env:ANTHROPIC_BASE_URL   = "https://<podId>-8080.proxy.runpod.net"

$env:ANTHROPIC_AUTH_TOKEN = "x"

$env:ANTHROPIC_MODEL      = "claude-nemotron[1m]"

$env:CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT = "1"

$env:CLAUDE_CODE_AUTO_COMPACT_WINDOW = "1000000"

$env:ANTHROPIC_SMALL_FAST_MODEL     = "claude-3-5-haiku"

$env:ANTHROPIC_DEFAULT_HAIKU_MODEL  = "claude-3-5-haiku"

$env:ANTHROPIC_DEFAULT_SONNET_MODEL = "claude-nemotron[1m]"

$env:ANTHROPIC_DEFAULT_OPUS_MODEL   = "claude-nemotron[1m]"

claude

```

Ou simplement `.\connect.ps1`, qui lit l'identifiant du pod dans
`.pod-nemotron.json`, vérifie l'endpoint, choisit le meilleur identifiant servi
et lance Claude Code.

**`ANTHROPIC_API_KEY` doit être effacé.** Il prend le pas sur `AUTH_TOKEN` et
envoie les requêtes vers l'API officielle : on croit tester le modèle local, et
la facture arrive avec. C'est ce qui faisait que Claude Code « ne voyait pas »
les modèles servis.

**Le 1 M exige les deux variables `CLAUDE_CODE_*`.** Claude Code suppose 200 k

pour tout identifiant inconnu et compacte à cette limite ; la première lève la

présomption, la seconde est plafonnée par elle et reste sans effet seule. Le

suffixe `[1m]` ne suffit pas non plus.



**Ne rien publier sur `patdev/k3-a40-bootstrap` pendant qu'un pod sert.** Le
bootstrap surveille sa propre URL et se recharge : publier coupe l'endpoint
pendant 3 à 5 minutes.

## Cycle de vie du pod

```

python pod.py create      # cree (--gpu, --cloud, --replis, --max-prix, --sans-volume)

python pod.py wait        # bloque jusqu'au service

python pod.py status      # etat, cout, endpoint

python pod.py stop        # arrete -- facturation A LA MINUTE, couper tot economise

python pod.py stock       # cartes disponibles, avec leurs id RunPod exacts

```

## La commande

```

vllm serve nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 \

  --trust-remote-code \

  --max-model-len 1048576 \

  --moe-backend marlin \

  --kv-cache-dtype fp8 \

  --enable-prefix-caching \

  --gpu-memory-utilization 0.85 \

  --mamba-backend flashinfer \

  --mamba-cache-mode align \

  --async-scheduling \

  --max-num-batched-tokens 8192 \

  --reasoning-parser nemotron_v3 \

  --tool-call-parser qwen3_coder \

  --enable-auto-tool-choice

```

Par variables du bootstrap : `VL_MODEL=nemotron VL_SPEC=off VL_CTX=1048576`
**`VL_BATCHED=8192`** (défaut actuel 4096) `VL_ASYNC=on` (déjà le défaut).



**Un seul changement par rapport à ce qui tournait** : `VL_BATCHED` de 4096 à
8192. Tout le reste était déjà en place.

## Ce que chaque drapeau vaut, mesuré

Dix leviers testés un par un sur RTX PRO 6000, contexte 131 072 :

| levier | solo | agrégé@8 | prefill j/s |
|---|---:|---:|---:|
| référence | 275,3 | 910 | 22 015 |
| **`--async-scheduling`** | 281,4 | **995** | 23 845 |
| **`--max-num-batched-tokens 8192`** | 276,9 | **1 003** | **24 050** |
| `-O3` | 279,0 | 979 | 23 757 |
| graphes CUDA `FULL` | 280,3 | 853 | 21 799 |
| `--attention-backend TRITON_ATTN` | 280,5 | 902 | **14 918** |
| `--mamba-cache-mode all` | 271,3 | 877 | 22 093 |
| `--kv-cache-dtype auto` | 277,8 | 904 | 21 700 |
| `--max-num-seqs 8` | 278,9 | 830 | 21 935 |
| sans cache de préfixe | **283,9** | 911 | 23 021 |

**Le débit solo ne bouge pas** : 4,6 % d'écart entre le meilleur et le pire,
l'ordre du bruit. Les deux drapeaux retenus rendent ~+10 % **en agrégé et en

prefill uniquement** — ils agissent sur l'ordonnancement, pas sur le calcul par
jeton.

Trois pièges dans ce tableau :

- **Ne jamais forcer `TRITON_ATTN`** : −32 % de prefill pour un décodage

  identique. Notre ancien banc Blackwell le forçait, ce qui explique une partie

  de ses 237,7 périmés.

- **`--kv-cache-dtype fp8` ne rend rien** (277,8 en `auto` contre 275,3). Il est

  gardé pour la capacité KV, pas pour la vitesse.

- **Le meilleur solo est un piège.** « Sans cache de préfixe » donne 283,9, mais

  le cache rend **×16 sur le TTFT** dès que le préfixe est réutilisé : 2,90 s à

  froid contre 0,18 s à chaud, sur 63 895 jetons lus dans `usage.prompt_tokens`.

  Claude Code renvoie le même prompt système à chaque tour. On garde le cache.



## `mamba-cache-mode` : garder `align` partout



**Correction du 23/08 au soir.** Une version antérieure de ce document
recommandait `all` sur Ada pour ses « +11 % ». **C'était faux**, et l'erreur
était une comparaison à deux variables : les 238,5 étaient en mode `all` avec le
dtype de cache SSM par défaut, les 215,2 en mode `align` **avec

`mamba-ssm-cache-dtype float16`** — et à des contextes différents, 1 M contre
131 k. L'écart a été attribué au mode de cache alors qu'il ne l'était pas.

Mesure où le mode de cache est la **seule** variable (Ada, recette + v83,
contexte 131 072) :

| mode | solo | agrégé@8 | cache KV |
|---|---:|---:|---:|
| `align` | **209,9** | 648 | **5 108 531** |
| `all` | 208,5 | 638 | 1 257 472 |

`all` ne rapporte rien et divise la capacité KV par quatre. **Garder `align`

partout.** Sur Blackwell le constat était déjà celui-là (271,3 contre 275,3).

Lequel des autres facteurs portait les +11 % n'est pas établi — le dtype du
cache SSM est le suspect le plus probable, mais il n'a pas été isolé.

## La machine

Même modèle, même banc, mode `align`, contexte 1 M :

| carte | $/h | solo | agrégé | remarque |
|---|---:|---:|---:|---|
| RTX 6000 Ada | **0,84** | 209,9 | 648 @8 | contrôle direct, config v83, ctx 131 072 |
| RTX PRO 6000 Blackwell | 1,69 | **282,0** | 1 045 @8 | +31 % de solo |
| A100 PCIe 80 Go | 1,19 | 154,2 | 2 257 @48 | 18,5 M de KV, 17,64× à 1 M |
| H200 SXM | 3,59 | **351,6** | — | meilleur absolu, hors budget |

**Sous 2 $/h et pour la latence d'une session unique : RTX PRO 6000 à 1,69 $/h.**
Pour le meilleur rapport qualité-prix : l'Ada à 0,74 $/h.

**Réserve levée le 23/08 au soir.** Contrôle exécuté sur un pod RunPod avec
l'image publique `vllm/vllm-openai:v0.27.1` — la même que les jobs — et la
commande identique, contexte 131 072 :

| | Ada | RTX PRO 6000 | écart |
|---|---:|---:|---:|
| solo | 200,7 | 275,3 | **+37,2 %** |
| agrégé @8 | 627 | 910 | **+45,2 %** |
| prefill j/s | 11 556 | 22 015 | **+90,5 %** |

Les +31 % annoncés étaient donc **conservateurs** : l'écart réel de silicium est
de +37 %, et le prefill de la Blackwell est presque le double. Pile de noyaux
identique des deux côtés (`FLASHINFER` / `MARLIN` / `MarlinNvFp4LinearKernel`).

À noter : ces 200,7 sont *inférieurs* aux 215,2 de notre ancienne configuration
de pod (`gpu-memory-utilization 0.93`, `max-num-batched-tokens 4096`,
`mamba-ssm-cache-dtype float16`, contexte 1 M), qui était donc mieux réglée pour
cette carte que la recette NVIDIA brute.

## Ce qui est fermé, et qu'il ne faut plus retenter

- **Toute spéculation.** MTP, DSpark, DFlash, à la recette exacte de NVIDIA, sur
  Ada **et** sur Blackwell — l'architecture que NVIDIA déclare supportée :
  −62 % à −73 % de débit solo. DSpark n=5 émet *plus* de jetons par passe que
  n=3 (3,25 contre 2,72) et rend *moins* de débit : le brouillon fait son
  travail, c'est la passe avant qui s'effondre quand vLLM coupe
  `--async-scheduling` et les graphes CUDA complets. `VL_SPEC` reste à `off`.
- **Chercher un autre noyau.** `--moe-backend humming` et
  `--linear-backend humming` donnent le même chiffre que Marlin à 1 % près, sur
  trois architectures. Le noyau MoE porte 36 % du socle actif, le linéaire 64 % :
  les deux moitiés sont insensibles.
- **Requantifier le dépôt en W4A4.** Le format débloquerait cinq noyaux, et les
  cinq sont plus lents (−20 % à −33 %). Vérifié à 0,61 $ sur
  `nvidia/Qwen3-8B-FP4`, déjà au bon format, au lieu de 5 à 10 $ de conversion.
- **Compter sur une carte plus large.** Rendement mémoire 69,3 % sur Ada, 47,5 %
  sur Blackwell, **22,6 % sur H200** : le socle actif est de 2,880 Gio par jeton,
  et le terme dominant n'est pas la mémoire mais un coût fixe par jeton.

Détail chiffré : `reports/2026-08-23-plafond-solo-et-dtype-du-chemin-dense.md`,
sections 22 à 28.

---

# Qwen3.8-Flash-Next sur UNE carte, derrière le pont Anthropic (26/08/2026)

Validé de bout en bout : Claude Code parle à `claude-flashnext`, 262 144 de
contexte natif, sur **une seule** RTX PRO 6000 à 1,69 $/h.

## Reconstruire le pod

`dockerStartCmd` :

```

curl -sL https://huggingface.co/patdev/k3-a40-bootstrap/resolve/main/lancer_flashnext.sh -o /run.sh && bash /run.sh

```

Exigences du pod : image `vllm/vllm-openai:qwen38-flash-next`, 1 GPU de 96 Go,
**plus de 110 Go de RAM**, 200 Go de disque conteneur, port `8080/http`.
Env : `HF_TOKEN`. Compter ~25 min au premier démarrage (135 Go à télécharger),
~6 min ensuite.

## Les quatre réglages sans lesquels rien ne marche

| réglage | ce qui arrive sans lui |
|---|---|
| `VLLM_PLE_CPU_OFFLOAD=1` | 125,9 Go de poids pour 96 Go de VRAM |
| `--distributed-executor-backend mp` | aucun ouvrier PLE, blocage **muet et sans fin** après la capture des graphes |
| `patch_ple.py` | échec au 205e shard sur 206, `ngram_embedding.weight_scale` |
| `--gpu-memory-utilization 0.93` | à 0,88 le cache KV plafonne à 309 594 jetons et les requêtes s'empilent pour cause de capacité |

Ne **pas** poser `PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True` :
`pidfd_getfd: Operation not permitted`, faute de `CAP_SYS_PTRACE`.

### Le cache KV, et pourquoi ne pas suivre la suggestion de vLLM

Mesuré le 26/08, une seule variable changée :

| `--gpu-memory-utilization` | cache KV | jetons | concurrence max à 262 k |
|---|---|---|---|
| 0.88 | 7,52 GiB | 309 594 | 1,18× |
| **0.93** | **12,26 GiB** | **504 841** | **1,93×** |

À 0,88, vLLM refusait d'admettre des requêtes —
`num_requests_waiting_by_reason{reason="capacity"} = 5` avec 2 seulement en
cours. À 0,93 la file est vide.

Ne **pas** suivre le `--kv-cache-memory` « to fully utilize gpu memory » que
vLLM propose (17,92 GiB ici) : il ne garde aucune marge au-dessus du pic
d'activation mesuré à vide (1,55 GiB), et sous charge réelle ce pic est plus
haut — c'est cette valeur-là qui avait tué le serveur en plein service.

### Mais l'intervalle, lui, se prend : `--kv-cache-memory-bytes`

Mesuré le 26/08. **Le KV est strictement linéaire en octets**, à 26 078 octets
par jeton aux trois points :

| réglage | cache KV | jetons | concurrence à 262 k | tient 2 prefills pleins ? |
|---|---|---|---|---|
| `--gpu-memory-utilization 0.93` | 12,26 GiB | 504 841 | 1,93× | oui |
| **`--kv-cache-memory-bytes 16106127360`** | **15 GiB** | **617 633** | **2,36×** | **oui — retenu** |
| `--kv-cache-memory-bytes 18253611008` | 17 GiB | 700 087 | 2,67× | **NON — `EngineDeadError`** |

**Le test qui décide n'est pas un prefill, c'est deux.** À 17 GiB, une requête
à pleine fenêtre passe très bien ; deux simultanées tuent le moteur. La VRAM
libre le dit :

```

             au repos   1 prefill   2 prefills simultanes

17 Gio        269 Mo      273 Mo      83 Mo  -> EngineDeadError

15 Gio       4353 Mo     2289 Mo    1137 Mo  -> OK

```

Deux prefills concurrents consomment **~3,2 GiB transitoires**. La réserve
`1.55 GiB for peak activation` annoncée par vLLM en couvre à peu près *un* :
elle est profilée sur une forme de lot, **ce n'est pas une borne pire-cas**.
Ne jamais valider une capacité sur une seule requête.

### `--kv-sharing-fast-prefill` : RETIRE le 27/08, il tuait le moteur

**Ne pas l'activer.** Mesure et contre-mesure, dans cet ordre :

| | KV | solo | agrégé à 8 | prefill chaud | aiguilles |
|---|---|---|---|---|---|
| 15 GiB | 617 633 | 83,2 | 426,0 | 259 858 | 5/5 |
| **15 GiB + `--kv-sharing-fast-prefill`** | **617 633** | **87,3** | **445,4** | **297 085** | **5/5** |

Capacité identique au jeton près. **Attention au piège de mesure :** sous
`--gpu-memory-utilization`, ce même drapeau semblait coûter −8,6 % de cache
(504 841 → 461 280), parce que c'est vLLM qui arbitre et que ses tampons
sortent du budget KV. Sous `--kv-cache-memory-bytes`, le cache est *fixé* et
le surcoût sort de la marge. Les deux mesures sont exactes et racontent
l'inverse : le mode d'allocation est une seconde variable, invisible dans la
ligne de commande.

Exactitude vérifiée en A/B — cinq aiguilles à 10/30/50/70/90 % de profondeur
dans 120 906 jetons, raisonnement coupé : **5/5 des deux côtés**.

**Et pourtant il est retiré.** Trois morts du moteur en douze heures, toutes
avec ce drapeau actif, aucune sans, sur des dizaines de configurations :

```

File "vllm/v1/ple_offload/connector.py", line 389, in _launch

    self._request_queue.put_nowait(request)     # queue.Queue(maxsize=1)

queue.Full

```

Le commentaire du code dit l'invariante : *« each forward consumes its output

before the next launch »*. Elle suppose des forwards **sérialisés** ; ce drapeau
modifie l'ordonnancement du prefill juste assez pour la casser sous concurrence.

Preuve par contraste, mesurée le 27/08 :

| | concurrence atteinte | survie |
|---|---|---|
| avec `--kv-sharing-fast-prefill` | 4 requêtes | **14 min → `queue.Full`** |
| sans | **5 à 6 requêtes** | 49 min et plus, zéro incident |

La charge sans le drapeau était **supérieure de moitié** à celle qui avait tué
le moteur avec. Une seule paire d'observations, donc pas une preuve formelle —
mais 4,6 % d'agrégé ne paient pas un moteur qui meurt sous la charge réelle.

**Piège de lecture** : pendant 40 min après le retrait, la concurrence n'a
jamais dépassé 3. Les « quarante minutes sans incident » ne prouvaient alors
rien du tout — comparer deux régimes de charge différents ne vaut pas mieux ici
qu'ailleurs. Le résultat n'existe qu'à partir du moment où la charge a repassé
le seuil.

### Le bug qui tue le moteur : la file du déchargement PLE

Une requête très au-delà de la fenêtre (mesurée à 580 000 jetons, 2,2×) ne
rend pas une erreur — elle **tue le moteur** :

```

File "vllm/v1/ple_offload/connector.py", line 389, in _launch

    self._request_queue.put_nowait(request)

queue.Full

```

```python

# PLE rejects DBO, and each forward consumes its output before the

# next launch, so one pending request is sufficient.

self._request_queue = queue.Queue(maxsize=1)

```

C'est une **invariante violée**, pas une file sous-dimensionnée : augmenter
`maxsize` ferait courir deux requêtes sur des tampons de sortie partagés.

Non atteignable depuis Claude Code (`CLAUDE_CODE_MAX_CONTEXT_TOKENS = 262144`).
Juste au-dessus de la limite, à 262 085 jetons, le serveur rejette proprement
avec un `BadRequestError` transmis intact dans le flux SSE, et reste debout.
Le symptôme à reconnaître : `/v1/models` répond `200` alors que toute vraie
requête rend `500` — le pont survit au moteur qu'il sert.

### Ne pas activer la spéculation MTP sur une seule carte

Le modèle embarque bien sa tête brouillon (31 tenseurs `mtp.*` dans le dépôt,
`hc_count=4`, `mtp_num_hidden_layers=1`) et vLLM l'accepte. Mais elle consomme
**5,79 GiB de VRAM** : le cache KV tombe de 12,26 à 6,47 GiB, alors qu'une
seule requête à 262 144 en réclame 7,25 — le moteur refuse de démarrer.

```

ValueError: To serve at least one request with the model's max seq len (262144),

7.25 GiB KV cache is needed, which is larger than the available KV cache

memory (6.47 GiB). ... estimated maximum model length is 231264.

```

Même au maximum de mémoire, on obtiendrait ~423 000 jetons contre 504 841 sans
MTP : au moins 16 % de capacité cédés pour un gain de décodage plafonné à 2×,
alors que la capacité est justement ce qui bride le serveur. Les seules portes
de sortie sont de descendre `--max-model-len` à 231 264 ou moins, ou d'ajouter
une deuxième carte.

## Côté client

```powershell

Remove-Item Env:ANTHROPIC_API_KEY -ErrorAction SilentlyContinue

$env:ANTHROPIC_BASE_URL   = "https://<pod>-8080.proxy.runpod.net"

$env:ANTHROPIC_AUTH_TOKEN = "x"



# Alias NU, sans prefixe claude- : voir ci-dessous, c'est ce qui debloque 262 k

$env:ANTHROPIC_MODEL                = "flashnext"

$env:ANTHROPIC_DEFAULT_OPUS_MODEL   = "flashnext"

$env:ANTHROPIC_DEFAULT_SONNET_MODEL = "flashnext"

$env:ANTHROPIC_DEFAULT_HAIKU_MODEL  = "flashnext"

$env:ANTHROPIC_SMALL_FAST_MODEL     = "flashnext"



$env:CLAUDE_CODE_MAX_CONTEXT_TOKENS = "262144"

$env:CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT = "1"

claude

```

`ANTHROPIC_API_KEY` doit être effacée : elle prime sur `ANTHROPIC_AUTH_TOKEN` et
renvoie vers l'API officielle, facturée, sans le dire.

**Le nom servi doit être NU.** Corrigé le 26/08 en décompilant le binaire
2.1.239 : la fonction `JFd` refuse toute fenêtre personnalisée à un identifiant
commençant par `claude-`.

```js

let n = CLAUDE_CODE_MAX_CONTEXT_TOKENS;

if (n !== undefined && n > 0 && !id.startsWith("claude-")) return n;

return /* defaut */ 200_000

```

Avec `claude-flashnext`, ni `CLAUDE_CODE_MAX_CONTEXT_TOKENS` ni
`CLAUDE_CODE_AUTO_COMPACT_WINDOW` n'ont le moindre effet et `/context` affiche
200 k quoi qu'on fasse. La bonne variable est
**`CLAUDE_CODE_MAX_CONTEXT_TOKENS`**, pas `AUTO_COMPACT_WINDOW` ; il en faut
toujours deux, car la présomption de 200 k est rabattue tant que
l'application de la règle est active. Le pont ajoute donc `MODEL` nu en tête
d'`ALIASES` (`anthropic_proxy.py`).

Ne pas utiliser le suffixe `[1m]` : d'autres branches de `JFd` renvoient `1e6`
en dur, ce qui ferait croire à Claude Code qu'il dispose d'un million alors que
le moteur plafonne à 262 144, et ferait compacter trop tard.

**Contrepartie de l'alias nu.** Tout outil qui déduit la fenêtre du NOM du
modèle casse. Une ligne d'état qui attend `claude-<fournisseur>/<modele>`
retombe sur son défaut de 200 k et affiche `172k/200k` pendant que `/context`
affiche 262,1 k. Le correctif est de consulter la même source que Claude Code,
avec sa condition :

```js

const env = Number(process.env.CLAUDE_CODE_MAX_CONTEXT_TOKENS);

if (Number.isFinite(env) && env > 0 && !base.startsWith("claude-")) return env;

return 200_000;

```

## Ce qu'on obtient

Configuration retenue, corrigée le **27/08** après trois morts du moteur en
service :

```

--kv-cache-memory-bytes 16106127360   (15 Gio)

--enable-flashinfer-autotune

```

`--kv-sharing-fast-prefill` a été **retiré** — voir plus haut : il rendait
+4,6 % d'agrégé et déclenchait `queue.Full` dans le connecteur PLE sous
concurrence. Les chiffres du 26/08 le comprenaient ; ceux-ci ne le comprennent
plus.

```

                    26/08 matin      27/08 retenu   gain

solo                 75,3 tok/s      83,2           +10,5 %

agrege a 8          335,2 tok/s     426,0           +27,1 %

KV                  297 148 jetons  617 633        +107,9 %

concurrence a 262k    1,13x           2,36x        +108,8 %

prefill froid         8 535 j/s      11 200         +31,2 %

prefill chaud             -         259 858 j/s    (x23 sur le froid)

```

Tenue en charge vérifiée le 27/08 : **5 à 6 requêtes concurrentes** soutenues,
1 228 j/s de prefill et 322 j/s de génération, sans incident — contre 14 min de
survie à 4 requêtes avec le drapeau retiré.

**Le prefill froid n'a été amélioré par aucun levier de la soirée** — les 31 %
viennent de `0.93` et de l'autotune, acquis plus tôt. Tous les leviers qui le
visaient sont fermés : déchargement KV et `prefix-match-unit` par l'alignement
Mamba (groupes `[800, 4, 800, 800, 800, 800]`), `indexer_budget` par le noyau
`persistent_topk` qui n'accepte que k ∈ {512, 1024, 2048}, soit un budget déjà
au plancher.

Le vrai gain de prefill est **indirect** : le contrôle d'éviction donne
`gain_eviction = 1,00` — un bloc chassé du GPU est définitivement perdu. Seule
la taille du cache protège un préfixe. À ~130 k par session, on passe de ~2,3 à
~4,7 sessions dont chaque tour coûte 1,14 s au lieu de 21 s.

Trois fois et demie plus lent que Nemotron en solo. Le pari reste que la
capacité compense.

Détail complet : `reports/2026-08-23-plafond-solo-et-dtype-du-chemin-dense.md`,
sections 33 à 36.

## Les images : un 400 qui accuse le modèle et désigne notre réglage

### Le symptôme

Une capture collée dans Claude Code fait tomber le tour entier :

```

API Error: 400 {"error":{"message":"At most 0 image(s) may be provided in one

prompt. (parameter=image)","type":"BadRequestError","param":"image","code":400}}

```

Le message ressemble à une limite du modèle. C'est **notre** drapeau, lu à voix
haute : `--limit-mm-per-prompt '{"image":0,"video":0}'`. vLLM le confirme au
démarrage, en clair, dans son propre journal :

```

All limits of multimodal modalities supported by the model are set to 0,

running in text-only mode.

```

Le piège de diagnostic est là : l'erreur est renvoyée au client comme une
erreur de requête, alors que la cause est une option de service. Chercher dans
le modèle ou dans le pont fait perdre l'heure ; il faut lire le journal de
démarrage du moteur.

### Ce qui n'était PAS en cause

Deux couches vérifiées avant de toucher au moteur, et toutes deux saines :

* **le pont** traduit déjà correctement les blocs Anthropic vers OpenAI
  (`_image_part`, `anthropic_proxy.py`) — `source.base64` devient une URI de
  données, `source.url` passe tel quel, et les images portées par un
  `tool_result` sont extraites pour être rattachées au tour utilisateur ;
* **les poids de vision sont dans le dépôt** : 333 tenseurs `model.visual.*`,
  soit **0,90 Go sur les 135,16** du checkpoint (0,449 B paramètres BF16).
  Décompte complet par catégorie :

| | paramètres | taille |
|---|---:|---:|
| experts MoE | 67,948 B | 67,95 Go |
| table PLE n-grammes | 51,200 B | 51,20 Go |
| reste (attention, embeddings, `lm_head`) | 4,948 B | 9,90 Go |
| tête MTP (non chargée) | 2,607 B | 5,21 Go |
| **tour de vision** | **0,449 B** | **0,90 Go** |

La tour est donc déjà résidente : le plafond ne gouvernait que la validation
des requêtes et le profilage, pas le chargement.

### Pourquoi il a fallu rendre 0,5 GiB de KV en même temps

Mesure sur le pod en service avant bascule :

```

VRAM : 96 612 MiB utilisés sur 97 887   ->  1,25 GiB libres

```

Et surtout, dans le journal :

```

reserved 15.0 GiB memory for KV Cache as specified by kv_cache_memory_bytes

config and skipped memory profiling.

```

**`--kv-cache-memory-bytes` fait sauter le profilage mémoire.** vLLM ne
recalculera donc rien tout seul : il réservera ses 15 GiB quoi qu'il arrive, y
compris si l'encodage d'images demande des activations transitoires qu'on n'a
jamais mesurées ici. Avec 1,25 GiB libres et trois morts de ce moteur déjà au
compteur pour avoir visé trop haut, on rend la marge :

| | avant | après |
|---|---:|---:|
| `--kv-cache-memory-bytes` | 16 106 127 360 (15,0 GiB) | **15 569 256 448 (14,5 GiB)** |
| cache KV | 617 633 jetons | ~597 000 |
| concurrence à 262 144 | 2,36× | ~2,28× |
| images par requête | **0** | **4** |

−3,3 % de capacité pour que les captures fonctionnent. La vidéo reste à `0` :
`temporal_patch_size 2` et plusieurs images par seconde feraient exploser le
budget d'activation, et Claude Code n'en envoie jamais.

### Les deux pièges de la manœuvre

**Le chien de garde doit porter le même drapeau.** `chien.py` a sa propre
`MOTEUR_CMD`. Si on ne la met pas à jour, la première « réparation » relance le
moteur en mode texte seul et la panne revient sans que rien ne l'explique.

**Aucun `pkill -f` sur ce pod.** L'agent qui exécute les commandes porte le
**texte complet du script** dans sa ligne de commande : tout motif présent
littéralement dans le fichier matche l'agent et le tue — constaté, `[FIN]
code=-15` dès la première ligne. Soit on brise l'égalité littérale
(`vllm [s]erve`, à appliquer à *chaque* motif), soit — plus sûr quand le script
arrête plusieurs choses — on lit `/proc/*/cmdline` et on exclut toute son
ascendance en remontant `ppid`. Recette dans `bascule_images.sh`.

### La vraie cause : `transformers` ne connaît pas le modèle du tout

Le 400 levé, les images sont acceptées et encodées — 223 jetons pour un
448×448 — mais le modèle **ne voit rien de juste** : 0/4 sur des couleurs
unies, 0/3 sur du comptage de carrés, et « droite » que le carré soit à gauche
ou à droite. Un 200 ne prouvait rien.

Premier indice, dans le journal du moteur, répété cinq fois :

```

[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default':

               {'mrope_section', 'mrope_interleaved'}

```

J'ai d'abord conclu « le mRoPE est jeté ». **C'était incomplet**, et l'écart
compte : un avertissement sur des clés inconnues ne prouve pas qu'elles sont
supprimées. En sondant le vrai chemin de code sur le pod :

```

ValueError: The checkpoint you are trying to load has model type `qwen4_exp`

            but Transformers does not recognize this architecture.

processeur      : Qwen3VLProcessor        <-- repli sur un AUTRE modèle

image_processor : Qwen2VLImageProcessor

```

`transformers` **5.15.1**, embarqué dans l'image vLLM d'aperçu, ne connaît pas
`qwen4_exp` : `AutoConfig` **lève**, au lieu de construire un `Qwen4ExpConfig`.
Le modèle ne reçoit donc jamais sa configuration propre — `mrope_section

[11, 11, 10]` compris, qui est ce qui donne aux patchs d'image leurs positions

en 3D. Le texte n'en souffre pas ; l'image perd toute géométrie, tandis que le

nombre de jetons, lui, reste plausible.



**Deux fausses pistes que la réparation a démenties, et qu'il faut nommer :**



* j'ai d'abord accusé `AutoProcessor`, qui tombait en repli sur

  `Qwen3VLProcessor`. **Faux** : après correction, le processeur est *toujours*

  `Qwen3VLProcessor` / `Qwen2VLImageProcessor` et la vision marche — c'est

  simplement le processeur légitime de ce modèle ;

* l'avertissement `Unrecognized keys in rope_parameters` **subsiste** dans le
  journal avec 5.16.1, vision fonctionnelle à l'appui. Il n'a jamais été le
  mécanisme. C'était le symptôme le plus visible, et le plus trompeur.

C'est la signature à retenir : *le compte de jetons peut être juste pendant que

le contenu est faux*. Le seul test qui tranche est un test qui **discrimine** —
trois couleurs distinctes, deux comptages, deux latéralités.

Deux fausses pistes écartées au passage : la tour de vision est **exclue de la

quantification** (`model.visual.*` dans `exclude_modules` de
`hf_quant_config.json`), donc intacte en BF16 ; et le pont traduisait déjà
correctement les blocs Anthropic. Le `smoke_report.json` du dépôt RadixArk est
d'ailleurs **purement textuel** : personne n'avait validé la vision de ce quant.

**Le correctif est une montée de version** : `transformers 5.16.1` (publié sur
PyPI) contient `transformers/models/qwen4_exp/`. L'opération se fait dans le
conteneur, avec **revert automatique** vers 5.15.1 si la reconnaissance échoue
ou si le moteur ne redémarre pas — un endpoint texte qui marche vaut mieux
qu'une vision hypothétique. Script : `monter_transformers.sh`, aides dans
`aides/` sur le dépôt bootstrap.

### Résultat mesuré (27/08, 19 h 31)

```

transformers   5.15.1 -> 5.16.1        tokenizers 0.22.2 -> 0.23.1

config class   ValueError -> Qwen4ExpConfig / Qwen4ExpTextConfig

mrope_section  absent -> [11, 11, 10]

KV             596 630 jetons, concurrence 2,28x

redemarrage    200 s

```

| épreuve | avant | après |
|---|---:|---:|
| couleurs unies (rouge, vert, bleu) | 0/3 | **3/3** |
| comptage (1 et 3 carrés) | 0/2 | **2/2** |
| latéralité (gauche, droite) | 0/2 | **2/2** |
| **total** | **0/7** | **7/7** |

Confirmé indépendamment depuis l'extérieur, par le proxy RunPod — la sonde du
pod tapait sur `127.0.0.1`, ce qui ne prouve pas le chemin client. Sur une
scène composite : « deux carrés noirs situés à gauche, l'un au-dessus de
l'autre », plus le carré rouge ; et une forme en T lue comme un T.

### Deuxième épreuve : lire une vraie capture d'écran

Les 7/7 ci-dessus portent sur de la **géométrie** — couleurs, comptage,
latéralité. Ils prouvent que le pipeline d'image est correctement câblé, pas
que le modèle sait lire un terminal à 14 px. Ce sont deux régimes différents,
et c'est le second que Claude Code envoie. Rendu sur le pod avec Pillow et
DejaVuSansMono, à des densités réalistes :

| épreuve | image | jetons | résultat |
|---|---|---:|---|
| erreur de build (terminal sombre, 16 px) | 1200×400 | 501 | **OK** — `TS2345 \| src/services/auth.ts \| 142` |
| extrait de code (fond clair, 16 px) | 1200×400 | 499 | **OK** — `fibonacci` / `4096` |
| transcription à **13 px** | 1200×200 | 258 | **OK** — mot pour mot |
| disposition d'interface (deux boutons) | 900×300 | 287 | **OK** — « Enregistrer », bleu |

**4/4.** Le troisième est le plus significatif : à 13 px, la ligne
`EngineDeadError: ple_offload/connector.py queue full` est restituée
exactement, sans approximation.

**Budget à connaître : une capture plein écran coûte ~500 jetons de contexte.**
Sur un cache de 596 630 jetons partagé entre agents, une dizaine de captures
dans une conversation restent négligeables ; une centaine ne le sont plus.

**Coût de l'opération** : `--kv-cache-memory-bytes` 15,0 → 14,5 GiB, soit
617 633 → 596 630 jetons de cache (−3,4 %). C'est le prix de la marge pour
l'encodeur d'images, pas celui du multimodal lui-même.

Le redémarrage coûte plus cher que d'habitude : changer `--limit-mm-per-prompt`
**invalide le cache `torch.compile` et le warmup**, soit ~4-5 min au lieu de
2 min 30. Une seule fois ; le redémarrage suivant à configuration identique
retrouve son temps normal.