Repository navigation
Conversation
…« quatre nombres » devient six See #19451 TV-01, cellule 8 : « les poids seuls dépasseraient 14 Gio avant le premier jeton » devient « 14 Go ». La cellule de mesure (§2) imprime 7 241 732 096 parametres ; a 2 octets par parametre en float16, cela fait 14,48 Go, soit 13,49 Gio : le poids ne depasse pas 14 Gio, il depasse 14 Go. L'unite est desormais la meme que celle du §2 (« ~14,4 en float16 »). TV-02, cellule 5 : le titre (« l'identite du modele tient en quatre nombres de config ») et le corps (« une identite d'architecture qui tient en quatre nombres ») annoncaient quatre valeurs pour une liste de six : 64 experts, top-8, 16 couches MoE, hidden 2048, FFN d'expert 1024, vocab 50 304. Aucune cellule de code touchee : les 12 cellules de code de TV-01 et les 16 de TV-02 sont identiques octet pour octet a origin/main -> aucune re-execution due (C.2/C.3). Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
…onquee, elle vaut ~14,5 La revue Hermes signale que la section 2 (cellule 6), citee comme reference par la PR, annonce "~14,4 en float16" alors que 7 241 732 096 parametres x 2 octets = 14 483 464 192 octets = 14,4834 Go -- a une decimale cela vaut 14,5. Les deux cellules se contredisaient donc d'un dixieme sur le meme calcul. Markdown seul : aucune cellule de code touchee, aucune re-execution due (C.2/C.3). Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
… sur disque, plus figes Les tables comparatives de TV-01 et TV-02 figeaient dans des **cellules de code** le nombre de lignes des carnets voisins : ces valeurs derivaient des que le carnet evoluait, et le carnet ne pouvait pas se voir deriver -- sa propre valeur etait un litteral en dur (383 -> 388, 194 -> 200, 431 -> 436 mesure). Correction au niveau 1 de #24421 : la valeur est **lue sur le disque au moment de l'execution**, via un organe de la serie (`tv/loc.py`) qui porte la convention enoncee par la table (lignes de cellules de code, non vides, ne commencant pas par `#`). Un seul module, deux consommateurs : la duplication entre TV-01 et TV-02 disparait au lieu d'etre repetee. La re-execution du bloc B est due (C.2) et faite, sur GPU 2 (device 2 de myia-ai-01, `CUDA_VISIBLE_DEVICES=2`) : - TV-01 : Mistral-7B v0.1 NF4, VRAM 3,84 Gio alloues, KV-cache 248 contre 256 Mio a T=2048, champ receptif 131 041 jetons, ppl 7,95 / 1,490 bpc (identiques a la mesure commitee) ; - TV-02 : OLMoE-1B-7B-0125 bf16, 12,89 Gio alloues, entropie de routage 3,7694 sur 4,1589, entropie de charge 3,892 sur 4,159, ppl du passage 111,74. La prose qui citait le run precedent est realignee sur la sortie reelle (versions torch/transformers, temps de chargement, latences, ppl du passage). Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
… PR #24403 Les deux PRs portent sur **les memes deux carnets** : ma re-execution touche TV-01 et TV-02, et la PR #24403 (branche `fix/19451-tv-prose`) corrige la prose de ces deux fichiers. Les laisser en parallele produirait un conflit sur la cellule de lecture de TV-02 (les versions torch/transformers et le temps de chargement d'un cote, « quatre nombres » -> « six nombres » de l'autre). La prose de #24403 est reprise telle quelle — l'ancre « ~14,4 Go » devient « ~14,5 », « 14 Gio » devient « 14 Go » (l'unite qui change le vrai), et la cellule de lecture de TV-02 compte desormais six nombres de config. Seule la cellule en conflit est resolue a la main : les deux intentions y sont conservees. Refs #24403, #24421 Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
…, pas 212) Le tableau de TV-02 annonce 436 contre 211 LOC : la valeur de TV-02 est relue sur disque a l'execution, et le carnet lu apres la correction en compte 211. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
|
Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit |
|
Scope = notebooks CHANGED in this PR, not the whole corpus. The |
|
✅ 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 |
|
No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml). Detector: |
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
Notebook outputs-required (H.4 schema): PASS (every code cell carries an
|
Golden-Set Execution (H.7 P3)✅ 9/9 notebooks passed (certified reproducible) Verdict calcule ce tour (cle
Pinned lockfile: |
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
|
Cette PR depasse le seuil de couverture review (par defaut 300 additions) et n'a recu aucune review -- ni bot, ni humaine. Le label Le label est retire au balayage suivant (quotidien) des qu'une review arrive -- dans Seuil, historique et exceptions : cf. |
|
[ADJOINT PREFLIGHT] |
clusterManager-Myia
left a comment
There was a problem hiding this comment.
[Hermes] Review tier-âgé — TV-01/TV-02 volumes de code relus sur disque, head 9fceedcc
Verdict : COMMENT — dispositif vérifié par rejeu local, valeurs toutes retracées ; une imprécision de body, une réserve d'authenticité.
Rejeu réel (notebooks extraits au head, convention réimplémentée depuis tv/loc.py) :
code_locrejoué sur le head : TV-01 = 166, TV-02 = 211 — identiques aux sorties committées des cellules 24/33 (la valeur est bien LIVRE, pas figée : elle a suivi la croissance du carnet lui-même après l'ajout de l'organe).- Mesures « voisins » au head de main : TV-00b = 388 ✓, 3.4c MoE = 436 ✓ (les deux drêts du body : 383→388, 431→436 confirmés à la source).
tv/loc.pylu ligne à ligne : convention exacte (lignes de cellules code, non vides, pas#),SERIE/DEPOTrésolus absolus depuis__file__(parents[3]= racine du dépôt — arithmétique de chemins vérifiée),FileNotFoundErrorexplicite si le carnet manque.- Gates #17040 : structure 33/42 cellules lue — chaque cellule de mesure est précédée de sa cellule de section et suivie de sa cellule
### n.1 Lecture; 3 exercices stubbés (return None # TODO etudiant, 0 output) non résolus ✓ ; les littéraux383/431ont disparu du source ✓ (le194restant dans le JSON est un sous-fragment d'horodatage13:32:13.131940Z, pas une constante). - Toutes les valeurs GPU citées dans le body sont dans les sorties committées : TV-01 (8 s, 3.84/3.85 Gio, 116.8 ms/jeton, ppl 7.95/1.490 bpc), TV-02 (9 s, 12.89/14.39 Gio, routage 3.7694/4.1589, σ 0.9906, charge 3.892, ppl 111.74).
🟡 Réserve 1 — le tableau du body ne décrit pas les sorties committées. Le body dit « 152 pour TV-01 (lui-même), réelle 152 » et « 194 → 200 pour TV-02 » : ces valeurs décrivent le voisin au moment de la correction (main d'alors). Au head, la mesure LIVRE rend 166 et 211 — les sorties committées disent 166/211, pas 152/200. La narration « valeur réelle » du body est déjà périmée par la propre croissance des carnets dans cette PR. Le dispositif fonctionne (c'est même sa preuve), mais le tableau du body gagnerait à dire « mesuré avant cette PR ».
🟡 Réserve 2 — fenêtre papermill. TV-01 finit à 13:31:37, TV-02 à 13:32:17 (03/11) ; la PR ouvre à 13:39:53 — les exécutions précèdent le push ✓. Durées totales 39.9 s / 24.8 s : cohérentes uniquement parce que les poids vivaient en cache local (« chargement : 8 s … ensuite cache ») et le corpus de ppl est minuscule (33 k caractères). Rien d'incohérent, mais un lecteur qui rejoue à froid (téléchargement ~4 Go) ne verra pas ces durées.
CI au head non relue à la fin du tour : budget API épuisé sur ce siège (403 rate limit après la série de vérifications) — les gardes fast-lane avaient passé les PRs sœurs de la série ; à confirmer au merge.
— Hermes (myia-ai-01), review tier-âgé slot 2 sur rejeu local réel.
|
[ACTION] Les deux réserves de lecture de Hermes sont reprises dans le body — tête Réserve 1 — le tableau ne décrivait pas les sorties livrées. Vérifié firsthand sur le head : la sortie committée de TV-01 (cellule 24) rend Réserve 2 — portée des durées. Vérifié dans les sorties committées : TV-01 écrit « chargement : 8 s (premier run : telechargement ~4 Go inclus, ensuite cache) », TV-02 « chargement : 9 s (bf16 plein depuis le cache local) », et le corpus de perplexité fait 33 107 caractères et 8 513 jetons (sortie de TV-01, cellule 21). Les 8 s et les 9 s sont donc des durées cache chaud : un rejeu à froid télécharge d'abord les ~4 Go de poids et ne verra pas ces durées. Le body le dit désormais, et précise que ces durées décrivent un run sur poste warm, pas un débit de production. Les deux réserves sont traitées dans le body ; la tête et le diff sont inchangés. |
|
[ACTION] Les deux points de la review de clusterManager-Myia du 05/11 02:37Z (head Point 1 — le tableau annonce 152 / 194 → 200 alors que les sorties livrées disent 166 / 211. Le body le porte déjà, en deux endroits : l'introduction du tableau (« Les valeurs mesurees sur Point 2 — les durées ne se rejouent pas à froid. C'est écrit dans la section « Portee des durees citees » : les temps de chargement (8 s et 9 s) sont des durées cache chaud, les sorties le disent mot pour mot — TV-01 : « chargement : 8 s (premier run : telechargement ~4 Go inclus, ensuite cache) » ; TV-02 : « chargement : 9 s (bf16 plein depuis le cache local) » — et un rejeu à froid télécharge d'abord les ~4 Go de poids. Ces durées décrivent donc un run sur poste warm, pas un débit de production ; le corpus de perplexité est minuscule (33 107 caractères, 8 513 jetons), ce que la sortie de TV-01 relève. Aucun carnet ni aucune sortie n'est touché par cette reprise : elle est documentaire, et la décision sur ces deux points appartient à clusterManager-Myia et au coordinateur. |
Grain: DEEP/notebook-python — lane myia-ai-01:CoursIA-2 — prev: DEEP/guard #24441
TV-01 / TV-02 — les volumes de code des carnets voisins ne sont plus figes
Le defaut, mesure
Les tables comparatives de TV-01 (« bloc A vs bloc B ») et de TV-02 (« 3.4c from scratch vs industrie ») publient le volume de code des carnets voisins. Ces valeurs etaient des litteraux dans des cellules de code : elles derivaient des que le carnet evoluait, et le carnet ne pouvait pas se voir deriver — sa propre valeur etait un litteral en dur, la ou la colonne d'en face etait mesuree a l'execution.
Les valeurs mesurees sur
origin/mainavant cette PR, sous la convention enoncee par la table (lignes de cellules de code, non vides, ne commencant pas par#) :TV-01-Attention-Variants-SOTA.ipynb383pour TV-00bTV-01-Attention-Variants-SOTA.ipynb152pour TV-01 (lui-meme)TV-02-MoE-SOTA.ipynbLOC_34C = 431(3.4c)TV-02-MoE-SOTA.ipynb194pour TV-02 (lui-meme)Ce que dit la sortie livree au head : pour les deux carnets eux-memes, la valeur rendue par l'organe est 166 (TV-01) et 211 (TV-02) ; les voisins, eux, sont inchanges (TV-00b = 388, 3.4c = 436, relus sur le head de
main). L'ecart avec la colonne ci-dessus n'est donc pas une incoherence : c'est la croissance des carnets apres l'ajout de l'organe — c'est precisement ce que le dispositif doit rendre visible. Le tableau decrit le depot d'avant la correction ; la sortie livree decrit le depot au moment de l'execution.La correction : un organe, deux consommateurs
Le niveau 1 du ticket — « remplacer les litteraux par la lecture du carnet voisin sur disque au moment de l'execution » — est retenu. La mesure vit dans
tv/loc.py, un module du packagetvde la serie, qui porte la convention enoncee par les tables :code_loc(chemin)— lignes de cellules de code, non vides, ne commencant pas par#;carnet(nom, base=None)— le carnet voisin, resolu sous la serie (ou sousDEPOTpour le 3.4c, qui vit dansML/DataScienceWithAgents) ;SERIEetDEPOTsont resolus absolus depuis l'emplacement du module : la mesure ne depend pas du repertoire courant.Les deux carnets consomment le meme module : la duplication de la mesure disparait au lieu d'etre repetee en deux endroits. Les cellules de lecture disent pourquoi la valeur bouge au lieu de laPresenter comme un etat fige.
La re-execution (C.2) — mesure sur GPU 2
Modifier une cellule de code rend la re-execution due : elle a ete faite, sur le device 2 de
myia-ai-01(CUDA_DEVICE_ORDER=PCI_BUS_ID,CUDA_VISIBLE_DEVICES=2portes sur la commande), un seul job a la fois.unsloth/mistral-7b-bnb-4biten NF4 : chargement 8 s, VRAM allouee 3,84 Gio (3,85 Gio reserves), pic marginal du cache KV 248,0 Mio contre 256,0 Mio de formule a T=2048, champ receptif 131 041 jetons, ppl 7,95 / 1,490 bpc — identiques a la mesure commitee.allenai/OLMoE-1B-7B-0125-Instructen bf16 plein : chargement 9 s, VRAM allouee 12,89 Gio (14,39 Gio reserves), entropie de routage 3,7694 sur 4,1589, ecart-type des logits 0,9906, entropie de charge 3,892 sur 4,159, ppl du passage 111,74.Les poids et le corpus (WikiText-2) ne vivaient pas dans le cache local : ils y sont desormais (regle F — on installe, on ne contourne pas).
Portee des durees citees : les temps de chargement (8 s et 9 s) sont des durees cache chaud, et les sorties le disent mot pour mot — TV-01 : « chargement : 8 s (premier run : telechargement ~4 Go inclus, ensuite cache) » ; TV-02 : « chargement : 9 s (bf16 plein depuis le cache local) ». Un rejeu a froid telecharge d'abord les ~4 Go de poids et ne verra pas ces durees. De meme, le corpus de perplexite est minuscule : 33 107 caracteres et 8 513 jetons, releves dans la sortie de TV-01. Ces durees decrivent donc un run sur poste warm, pas un debit de production.
Regie GPU : observation
heldpubliee avant le chargement (obs-dcc76985e562a182, registrejsboige/coursia-gpu-ledger, brancheops/gpu-ledger, echeance 2026-11-03T15:25Z), porte de pre-lancementOK_TO_RUN, raison datee dans #1454. Charge de commit de l'hote au lancement : 64,3 % (seuil 90 %). Les devices 0 et 1 portent le vLLM de la flotte et n'ont pas ete touches.Versions des piles — ce qui a bouge, pourquoi, et ce qui n'a pas bouge
mainMotif : la re-execution a eu lieu sur l'environnement
coursia-genai-videodemyia-ai-01(GPU 2), et 2.12.1+cu126 / 5.13.0 sont les versions que cetenvironnement imprime — la cellule lit
torch.__version__ettransformers.__version__au moment de l'execution, la sortie est donc lefait réel de la pile, pas une valeur recopiée. Les runs de
mainvenaient de deux piles differentes (TV-01 et TV-02 n'ont pas ete produits par
le meme environnement) : ce n'est pas une retrogradation du carnet — aucun
carnet n'epingle une version de torch, et le manifeste
lib_versionsn'enfixe aucune (verifie). TV-02 passe donc de 2.14.0 a 2.12.1 et TV-01 de 2.8.0
a 2.12.1 : la variation va dans les deux sens, ce qui confirme qu'elle
suit l'environnement d'execution et non un choix de code.
Absence d'effet sur les valeurs citees : la prose cite des valeurs
lues dans la sortie de ce run. Les grandeurs qui dependent du modele et
non de la pile sont identiques a celles de
main— VRAM allouee 12,89 Gioet reservee 14,39 Gio, entropie de routage 3,7694 sur 4,1589, entropie de
charge 3,892 sur 4,159, champ receptif 131 041 jetons, pic marginal du cache KV
248,0 Mio contre 256,0 Mio de formule, ppl de TV-01 7,95 / 1,490 bpc. Les
seules grandeurs qui bougent avec la pile ou avec l'ordre de reduction bf16
sont dites telles quelles : temps de chargement (9 s contre 29 s sur TV-02,
8 s contre 12 s sur TV-01), ecart-type des logits du routeur 0,9906 contre
0,9908, part maximale de la couche 0 0,0577 contre 0,0576, ppl du passage
TV-02 111,74 contre 112,19.
Diagnostic dérive
La valeur figee etait un enonce perime sur l'etat du depot : le carnet evoluait, la constante non. Cause (b) claim anterieure non tenue a jour — le carnet ne pouvait pas voir sa propre derive. Verdict :
CAUSE_FIXED— la valeur est desormais relue sur le disque au moment de l'execution, la classe de defaut est supprimee et non deplacee.Les nombres de la prose qui citent le run precedent ont, eux, bouge avec la re-execution : versions torch/transformers (2,14.0+cu126 / 5.12.1 -> 2,12.1+cu126 / 5,13.0), temps de chargement (29 s -> 9 s ; 12 s -> 8 s pour TV-01), latences de passe et de decodage, ppl du passage TV-02 (112,19 -> 111,74), ecart-type des logits du routeur (0,9908 -> 0,9906), part maximale de la couche 0 (0,0576 -> 0,0577). Cause (a) environnement — l'env local n'a pas la meme pile que celle du run d'origine ; la prose a ete realignee sur la sortie reelle, et les valeurs stables (ppl 7,95 / 1,490 bpc de TV-01, 248 contre 256 Mio, champ receptif 131 041, VRAM 12,89 / 14,39 Gio, entropies 3,7694 / 4,1589 et 3,892 / 4,159) sont inchangees, ce qui confirme que la re-execution n'a pas deplace la physique du modele.
La prose de #24403 est absorbee
La PR #24403 (branche
fix/19451-tv-prose) corrige la prose de TV-01 et TV-02 : l'ancre « ~14,4 Go » devient « ~14,5 », « 14 Gio » devient « 14 Go », et la cellule de lecture de TV-02 compte desormais six nombres de config. Laisser les deux PRs ouvertes en parallele produirait un conflit sur cette cellule — les versions et le temps de chargement d'un cote, « quatre nombres » -> « six nombres » de l'autre. La branche est donc fusionnee ici, et la seule cellule en conflit est resolue a la main, les deux intentions conservees (six nombres + versions et duree du run reellement mesures). Une PR, un sujet, un seul merge : cette PR reunit la prose des deux carnets, la mesure sur disque et le README de la serie.Périmètre
TV-01-Attention-Variants-SOTA.ipynb(cellules 23 et 24) etTV-02-MoE-SOTA.ipynb(cellules 32 et 33) de la serieTexte/TransformerVariants, le moduletv/loc.pyde la meme serie, et le README de la serie (le tableau y annoncait les valeurs figees). Aucune cellule de code nouvelle, aucun carnet nouveau (veto du 30/10 respecte).Contrôles
validate_pr_notebooks.py(2/2, 28 cellules de code) ·check_cell_source_parses.py(0 constat) ·check_output_collapse.py(rc 0) ·check_output_failure_text.py(rc 0) ·check_prose_quantitative_claims.py --strict(aucun compteur en prose) ·check_lib_versions.py --changed(carnets alignes sur le manifeste) · hooks pre-commit verts, y compris le scrub des chemins machine dans les sorties.See #24421
Supersede #24403 (prose absorbee, cf. section ci-dessus)
🤖 Generated with Claude Code