V30 (suite) — la question du modèle plus gros, mesurée : 1,43 Go achète cinq réponses fausses de plus

[dapiced]

La V30 a livré le banc paramétrable et laissé la question du propriétaire ouverte d'une ligne : « le second volet est une commande, pas une opinion ». Cette PR exécute la commande et écrit le résultat.

La mesure

Mêmes 55 questions, même runtime CPU (onnxruntime-node), même prompt, même décodage contraint. Seul le modèle change.

modèle	téléchargement	modèle seul	appli
Qwen3-0.6B-DQ — livré	355 Mo	41 / 7 / 7	42 / 7 / 6
Qwen3-1.7B	1,43 Go	39 / 12 / 4	40 / 12 / 3

Quatre fois la bande passante achètent cinq réponses fausses de plus.

Pourquoi, précisément

Le gros modèle n'est pas uniformément moins bon — il est meilleur là où on l'attend et moins bon là où on ne l'attend pas :

• Il gagne les quatre comparaisons de groupes que le 0.6B refusait : « did women pay more than men? », « survival rate by sex », « est-ce que le prix du billet dépendait de la classe ? ».
• Il perd les comptages simples. « Count the passengers older than 60 » lui fait écrire {"kind":"aggregate","op":"count","column":"age","filter":…} — une forme valide de la grammaire, mais qui compte les lignes ayant un âge plutôt que les lignes. Sur Titanic, 177 âges manquent : ce n'est pas la même réponse.
• Il confond filtre et groupBy sur « average age of women » et « âge moyen des hommes », répondant par un groupBy sex là où la question désigne un sous-ensemble.

Latence médiane CPU : 9,6 s contre 18,2 s — deux fois plus lent, en plus d'être quatre fois plus lourd.

Deux limites, écrites plutôt qu'enfouies

1. Le prompt a été réglé contre le 0.6B. Les exemples, l'exemple de refus, le choix de la colonne-grandeur : tout a été arrêté sur les échecs du petit modèle cet après-midi. Un prompt ajusté au 1.7B donnerait plausiblement autre chose. Le chiffre ci-dessus décrit cette paire, pas le modèle — c'est exactement l'erreur que V27 avait commise en ajustant son prompt sur son banc, et je ne vais pas la refaire dans l'autre sens.
2. C'est un seul barreau. 764 Mo (gemma-3-1b-it) et 1,09 Go (Llama-3.2-1B) n'ont pas été essayés : leurs licences sont plus strictes que l'Apache-2.0 sous lequel LabML redistribue le reste, et le barreau qui a été essayé est parti dans le mauvais sens.

Ce que la mesure tranche, ce n'est pas « les gros modèles sont mauvais » — c'est la forme de la décision : « plus gros » n'est pas une direction d'amélioration sur cette tâche, c'est un compromis dont le signe doit être mesuré. Et il peut l'être, en une commande.

Diff

PLAN.md § N et README.md seulement — aucun changement de code.

Validation

lint + format:check + tsc --noEmit + 557 tests unitaires — tout vert.

---

Generated by Claude Code

[Copilot]

🟡 Changes recommended

The docs currently imply the larger-model comparison is “one command” without stating the prerequisite that the non-shipped model weights must already be present locally under LABML_LLM_CACHE.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Updates the project documentation to record the measured trade-off of trying a larger local LLM (Qwen3-1.7B) in the V30 CPU bench, and to frame “bigger model” as a measurable (benchable) decision rather than an assumption.

Changes:

• Document how to run the LLM bench with an alternate model repo parameter.
• Record the measured accuracy/latency trade-offs of Qwen3-1.7B vs the shipped 0.6B model.
• Add the same measurement narrative and limits to the Cap 6 plan log (PLAN.md § N).

File summaries

File	Description
README.md	Adds a short “bigger model” bench command + summarized result, pointing to PLAN.md § N.
PLAN.md	Adds the detailed measurement write-up (table + interpretation + limits) in the V30 section.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.