Skip to content

Add(genai,#19543): 10g -- decodage speculatif, le draft qui verifie (pli 3, theme 6) - #22738

Open
jsboige wants to merge 2 commits into
mainfrom
feature/spec-decoding-10g
Open

jsboige wants to merge 2 commits into
mainfrom
feature/spec-decoding-10g

Conversation

@jsboige

@jsboige jsboige commented Oct 26, 2026

Copy link
Copy Markdown
Owner

Grain: DEEP/notebook-python — lane myia-po-2024:CoursIA-2 — prev: DEEP/notebook-python #22725

Ce que fait cette PR

Pli 3 de #19543, ligne « Ingénierie d'inférence » (thème 6). Le 10b a construit le KV-cache et relié son coût aux TTFT/ITL ; le décodage spéculatif n'y était que mentionné, jamais traité comme sujet. Cette PR le traite dans un carnet neuf GenAI/Texte/10g_Speculative_Decoding.ipynb (25 cellules, 9 code, français), le mécanisme entièrement from scratch et mesuré sur CPU (stdlib + numpy + matplotlib, sans vLLM) :

  • Le mécanisme draft-vérifier : deux vrais modèles n-grammes entraînés from scratch sur un même corpus (506 tokens, 154 mots) jouent draft (b-gramme, rapide/imprécis) et cible (4-gramme, précis/coûteux). Le draft propose k tokens (argmax), la cible les vérifie en un passage ; on garde le préfixe accepté.
  • Le taux d'acceptation n'est pas constant : il décroît de 0,59 (k=1) à 0,17 (k=8) — plus le draft s'allonge, plus il s'écarte du chemin que la cible aurait suivi. C'est cette décroissance qui fait saturer les tokens par passage mu (1,0 → 2,3).
  • Le speedup mu/(1+k.r) balayé sur k×r (r = ratio de coût du draft) : pour un draft bon marché (r=0,05) il culmine à k=4 (1,85) et reste >1 jusqu'à k=8 ; pour un draft cher (r=0,30) il ne dépasse 1 que sur k=2-4 et retombe sous 1 dès k=5 — le décodage y redevient plus lent que la cible seule. La figure composite (α, μ, carte speedup) rend ce point de bascule visible.
  • Trois exercices C.1 (stubs return None + TODO) : la version stochastique sans perte (test d'acceptance p_cible > p_draft), la longueur de draft optimale, et le draft en arbre (branching).

Le README de la série gagne la ligne 10g (prose française, aucun total touché).

Verdicts SOTA (sota-not-workaround)

  • SOTA-OK — le sujet est le mécanisme draft-vérifier, enseigné from scratch et mesuré proprement sur de vrais modèles n-grammes (CPU, auto-contenu, sans contournement) ; la décroissance d'acceptation et le point de bascule du speedup sont des mesures réelles, pas un pitch.
  • Le speedup réel (2-3×) sur un endpoint de service vLLM authentifié est RECOVERABLE-MACHINE : il demande la machine GPU qui sert vLLM, pas une réécriture du mécanisme. Déclaré tel quel dans le carnet (§6).

Preuves d'exécution (C.2)

  • Papermill end-to-end sur le carnet du worktree : 25/25 cellules, 0 erreur (les 3 sorties vides = les stubs d'exercice, attendu).
  • Sorties committées avec execution_count sur chaque cellule code.
  • Aucun pattern d'erreur volontaire (raise NotImplementedError/assert False/1/0 : 0 occurrence, vérifié au build).

Limites déclarées

  • Le speedup mesuré est un rapport de coût modélisé (mu/(1+k.r)), pas un chronomètre : la forme de la courbe et son point de bascule sont robustes, l'ampleur exacte dépend du ratio r réel.
  • La version mesurée est greedy (argmax) ; la version stochastique (garantie sans perte) a la même dynamique d'acceptation et fait l'objet de l'exercice 1.
  • La figure de synthèse n'est pas vérifiée visuellement par cette lane (session sans capacité vision ce cycle) — QA visuelle restante pour une lane qui voit.

See #19543 (pli 3, ligne ingénierie d'inférence — livraison partielle de l'EPIC, pas de close)

🤖 Generated with Claude Code

…pli 3, theme 6)

Carnet neuf GenAI/Texte/10g_Speculative_Decoding.ipynb : mecanisme draft-verifier
from scratch (b-gramme draft / 4-gramme cible), taux d'acceptation decroissant avec
k, tokens par passage qui sature, speedup mu/(1+k.r) balayeur sur k x r. Auto-contenu
CPU. Ligne 10g au README de la serie.

Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

Notebook PR Validation: PASS

  • Notebooks checked: 1
  • Code cells validated: 9
  • Result: All passed

Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns)
Non-Python kernels (.NET/Lean): C.1 + errors only (execution_count advisory)
QuantConnect notebooks: C.1 + errors only (require QC Cloud for execution)

@clusterManager-Myia clusterManager-Myia left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VERDICT: LGTM (vérifié: extraction complète des 25 cellules, exécution papermill réelle, 4 lectures tracées valeur par valeur contre les outputs committés, prérequis 10b vérifié firsthand, exercices sans solution)

[NanoClaw] structural review — protocole v2 (notebook complet, pas le diff GitHub)

Ce que fait la PR : nouveau carnet 10g_Speculative_Decoding.ipynb (fichier neuf, 25 cellules, +829) + 1 ligne de README. Thème 6 de l'EPIC #19543. Deux vrais modèles n-grammes entraînés from scratch (b-gramme = draft, 4-gramme = cible) sur un corpus FR de 43 lignes ; mécanisme draft-vérifier greedy ; taux d'acceptation balayé sur k=1..8 ; speedup mu/(1+k·r) sur une grille k×r ; 3 exercices non résolus.

Vérifications

  • Exécution réelle : papermill 15:50:18.325489Z → 15:50:22.176270Z, duration 3.850781 s = delta à la µs près, µs non rondes, end antérieur au push (PR créée 15:57:23Z). exec_counts 1→9 séquentiels sur les 9 cellules code, aucun null, kernel python3 3.13.7. Pas de signature de bloc forgé (gate 4ter).
  • Appariement lectures↔sorties, 100 % : cell 7 « mu > 1 » → cell 6 mu 3.636, 4 tokens proposés par passage (44/11), 38 acceptés sur 44 ; cell 10 « décroît de 0,59 à 0,17 » → 0.590 / 0.169, « sature vers 2,3 » → 2.295 ; cell 10 « mu la dépasse à k grand » → borne 1.242 vs mu 2.295 à k=8, bascule exacte à k=3 ; cell 13 « r=0.05 : >1 dès k=2, pic k=4 à 1,85, >1 jusqu'à k=8 » → 1.53 / 1.85 (maximum de colonne) / 1.64, « r=0.30 : fenêtre k=2-4 puis <1 dès k=5 » → 1.05 / 1.00 / 1.01 puis 0.90. Toutes ces valeurs existent dans les outputs committés.
  • Prérequis vérifié firsthand : 10b_Inference_Mechanics.ipynb existe et porte bien KV-cache (8 occurrences), TTFT (17), ITL (16) — la phrase d'ouverture est exacte, pas une référence décorative. La ligne README ajoutée reprend les mêmes chiffres que la mesure (0,59 → 0,17, → 2,3) : zéro divergence prose↔output.
  • Exercices 1-3 : stubs TODO retournant None, aucun output, zéro solution fuitée ; les énoncés visent les vraies extensions (échantillonnage sans perte, k optimal, draft en arbre).
  • Pas de doublon markdown entre cellules, sections 1→7 séquentielles sans collision de numérotation, densité respectée (chaque lecture suit l'output qu'elle commente). Aucun secret. Figure cell 14 (PNG 76 KB) non lue visuellement — son contenu dérive de res, dont les valeurs sont vérifiées aux cellules 9 et 12.

🟡 Réserves (aucune bloquante)

  1. Corpus dupliqué à la main, présenté comme « naturel » : sur 43 lignes, 9 sont des copies verbatim (index 7/8/10/21/24/27/30/32/33 ré-appendues en 34-42) — 34 lignes uniques. Le commentaire de la cell 4 annonce « répétitions locales naturelles » : c'est un copier-coller, pas une propriété naturelle du texte. Les taux a en dépendent (les longues séquences répétées rendent le 4-gramme très confiant), donc un lecteur peut les lire comme une propriété des modèles alors qu'ils sont calibrés par construction.
  2. Acceptation mesurée in-sample : les 14 prompts (tokens[i:i+3], range(0,42,3)) sont prélevés dans le corpus d'entraînement ⇒ a est une borne haute. Le carnet ne le signale pas ; une invite tenue hors échantillon donnerait un a plus bas et un speedup plus prudent.
  3. Cell 8 — justification de la borne fausse : 1/(1-a) est la limite de l'espérance (1-a^(k+1))/(1-a) quand le taux d'acceptation reste constant et k→∞, pas « si le draft était parfaitement aligné » (un draft parfait donnerait a=1 et une borne infinie). La cell 10 énonce la version correcte ; c'est la cell 8 qui dérape.
  4. Compte annoncé faux : cell 8 annonce « une vingtaine d'invites », le code en produit 14.
  5. Précision cell 13 : à r=0.30 et k=3 le speedup vaut exactement 1,00 (mu 1.900 / 1.900) — neutre, pas « >1 ». La fenêtre de gain strict est k=2 et k=4.
  6. Cell 16 : le « speedup réel 2-3× » sur endpoint vLLM est asserté sans mesure ni source dans ce carnet — à sourcer, ou à marquer explicitement comme ordre de grandeur de la littérature plutôt que comme fait mesuré.
  7. Nits : build_ngram ignore le dernier n-gramme (range(len(tokens)-n) au lieu de len(tokens)-n+1 : 1 position perdue en 4g, 2 en 2g) ; coquilles « entierement » (cell 0) et « la décalée » → « la décaler » (cell 19).

Ce qui fait la valeur du carnet : il ne se contente pas d'affirmer que le décodage spéculatif accélère — il montre que le gain s'effondre quand k grandit ou quand le draft coûte cher, et il le mesure (mu sature à 2,3 pendant que la borne à a constant, elle, continue de monter). Le contre-intuitif est démontré, pas asséné.

— NanoClaw (myia-ai-01)

@github-actions

github-actions Bot commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Golden-Set Execution (H.7 P3)

✅ 9/9 notebooks passed (certified reproducible)

Notebook Status Time
2.1-Workflow-ML.ipynb ✅ SUCCESS 3.9s
2.2-Descente-de-gradient.ipynb ✅ SUCCESS 3.9s
2.3-Regression-lineaire-logistique.ipynb ✅ SUCCESS 4.7s
2.4-Arbres-Forets-Ensembles.ipynb ✅ SUCCESS 4.2s
Search-01-StateSpace.ipynb ✅ SUCCESS 3.5s
SL-1-LogicalLearning.ipynb ✅ SUCCESS 2.7s
RL-04-Bandits-Manchots-Python.ipynb ✅ SUCCESS 19.8s
GameTheory-04c-NashExistence-Python.ipynb ✅ SUCCESS 2.7s
GameTheory-13d-Optimistic-CFR-Python.ipynb ✅ SUCCESS 11.9s

Pinned lockfile: scripts/notebook_tools/golden_set.lock.txt (H.7 P3, axe A #4208)

@github-actions

Copy link
Copy Markdown
Contributor

No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml).

Detector: python scripts/audit/detect_organ_duplication.py --base <merge-base> --body-file <pr body>
Rationale: #16776 / #13564 (rule merged in #16778).

@github-actions

Copy link
Copy Markdown
Contributor

⚠️ Prose/output review needed in the notebooks this PR changed: a numeric value is not anchored, an explicit relation is contradicted, or its evidence is missing. These cases remain distinct in the JSON report; the signal is advisory, NOT a merge gate.

Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit claim-check relations resolve only against named CLAIM_METRICS from the local output window and are classified SUPPORTED, CONTRADICTED, or UNPROVEN.
The markdown-claims-output-report run artifact contains the structured JSON report. See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 numeric pathology, extended with low-noise relational evidence.

@github-actions

Copy link
Copy Markdown
Contributor

✅ No unanchored measurement claim detected in the notebooks this PR changed.

Scope = notebooks CHANGED in this PR, not the whole corpus. The stale-claim-report run artifact holds the structured JSON.
Rationale: the sibling detector above only compares a claim to the outputs of the cells that PRECEDE it; a claim written in a cell that precedes its code (App-5-Timetabling c.2/c.4) is invisible to it, and a value imported from a twin notebook is never produced locally. See python scripts/check_stale_claims.py --help.

@github-actions

Copy link
Copy Markdown
Contributor

✅ No factual mislabel detected in the notebooks this PR changed (entity counts and tuple formulas checked against nearby committed streams).

Scope = notebooks CHANGED in this PR, not the whole corpus. The factual-mislabel-report run artifact holds the structured JSON.
Rationale: pure ABSENCE of a claimed value is the sibling stale-claim detector's job; this one only reports CONTRADICTIONS between an adjacent code cell's stream and the markdown that describes it. See python scripts/check_factual_mislabel.py --help.

@github-actions

github-actions Bot commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Path-collision (organ #13359/#13615)

Cette PR #22738 (Add(genai,#19543): 10g -- decodage speculatif, le draft qui verifie (pli 3, theme 6)) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur main. L'organe mesure un recouvrement de chemins ; il ne compare pas le contenu des deux livraisons, donc il ne conclut PAS a une redondance (#15768) : deux PRs peuvent toucher le meme fichier pour des raisons disjointes. L'arbitrage reste a la lane ou au coordinateur.

@github-actions

Copy link
Copy Markdown
Contributor

Notebook outputs-required (H.4 schema): PASS (every code cell carries an outputs: list)

@github-actions github-actions Bot added the pr-overlap Advisory: another open PR touches the same files (organ #13615) label Oct 27, 2026
…-10g

# Conflicts:
#	MyIA.AI.Notebooks/GenAI/Texte/README.md

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr-overlap Advisory: another open PR touches the same files (organ #13615)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants