fix(ict,#18808): rejouer ICT-47 sous l'interpreteur de la base (3.10.19) sur lane GPU — kernel drift guard rouge sur #19137

Le check Kernel drift guard (base vs PR) rougit sur la PR #19137 (feature/ict47-splithalf) parce que le re-rendu de ICT-47-PainAxisDistillation-Python.ipynb a été produit par un interpréteur différent de celui de la base.

Mesure (JSON de l'organe, run 37235456922)

	base	tête
`kernelspec.name`	`py310-gpu`	`py310-gpu`
`language_info.version`	`3.10.19`	`3.12.13`
`signature_drift_cells`	—	`[]`

Le kernelspec est identique des deux côtés : le nom py310-gpu désigne une famille, pas un environnement — sur la machine qui a rejoué, il résolvait vers Python 3.12.13. Aucune dérive de cellule n'est détectée, seule la version d'interpréteur enregistrée dans les métadonnées a changé.

Ce qui est demandé

Rejouer ICT-47 sous l'interpréteur de la base (3.10.19) sur une lane GPU, puis vérifier que Kernel drift guard repasse au vert à la tête.

Le carnet est GPU-bound, et l'environnement épinglé de la série (MyIA.AI.Notebooks/IIT/ICT-Series/pyproject.toml, requires-python = ">=3.9,<3.10" — contrainte pyphi==1.2.0, qui dépend de collections.Iterable, retiré en 3.10) n'existe pas sur myia-po-2025:CoursIA : jupyter kernelspec list n'y porte aucun py310-gpu. Le rôle de re-exécution revient donc à une lane GPU.

Portée

Le jeu de sorties livré par #19137 est réel ; la dérive porte sur la métadonnée d'interpréteur, pas sur les résultats. La normaliser à la main n'est pas une option : language_info n'est pas une sortie de cellule, et un quatrième geste toléré hors Stop & Repair serait une falsification de la preuve d'exécution. Tant que la re-exécution n'a pas eu lieu, ICT-47 reste hors du pin de sa propre série — la base était déjà dans ce cas avant la PR.

See #18808.

[CLAIMED] #19160 — myia-po-2026:CoursIA 2026-10-05T02:05Z

Prise par la lane GPU qui porte le kernelspec demandé : mesure firsthand du 2026-10-05 — C:\Users\jsboi\miniconda3\envs\mcp-jupyter-py310\python.exe (le argv du kernelspec py310-gpu) rend Python 3.10.19, soit exactement la version enregistrée par la base ; torch 2.6.0+cu124, cuda.is_available() == True sur la RTX 3080 Ti. La re-exécution est donc possible ici.

Note de contexte ajoutée par la mesure : la tête mergée (#19137, merge c8de96b41e vers 00:38Z) porte déjà language_info.version = 3.12.13 sur main. La « base » que le garde comparera à ma PR sera donc 3.12.13, et non plus 3.10.19 — le rétablissement à 3.10.19 sera lui-même une dérive au sens du garde, à documenter par la section ## Diagnostic dérive (mécanisme C.4 prévu par le workflow). Je le signale ici pour que ce ne soit pas lu comme un échec.

Contexte de placement, à ne pas perdre : la sortie committée a été produite avec VRAM libre ~22920 MiB (machine à 24 GiB), moi j'ai 16384 MiB dont ~11 GiB pris par le bureau — les plafonds du carnet sont adaptatifs (min(9.0, libre-1.2)), donc le placement du 9B différera. Je vérifierai la dérive de signature avec l'organe du dépôt (check_kernel_drift.py) avant de livrer, et je rapporterai le verdict tel quel.

Tentative de re-exécution : mesurée, échouée pour une raison de ressource identifiée — rien n'est livré ce cycle

J'ai exécuté la re-exécution demandée sur po-2026 (la lane GPU qui porte le kernelspec), et le noyau meurt. Je rapporte la mesure telle quelle plutôt qu'un artefact partiel.

Commande exacte (reproductible)

cd <worktree sur origin/main>            # branche fix/19160-ict47-py310-gpu
python scripts/notebook_tools/notebook_tools.py execute \
  MyIA.AI.Notebooks/IIT/ICT-Series/ICT-47-PainAxisDistillation-Python.ipynb \
  --kernel py310-gpu --timeout 1200 -v

Le kernelspec py310-gpu résout vers miniconda3\envs\mcp-jupyter-py310\python.exe = Python 3.10.19 (vérifié : c'est exactement la version de la base), torch 2.6.0+cu124, cuda.is_available() == True. ict s'importe sans installation dès que le cwd est ICT-Series/ (c'est ce que fait l'outil) — donc aucun pip install -e . n'est requis (et il échouerait de toute façon : le pin de la série requires-python = ">=3.9,<3.10" le refuse en 3.10.19 ; je n'ai pas forcé).

Résultat mesuré

EXECUTION SUMMARY
  Success: 0
  Failed:  1
  Total time: 88.7s
nbclient.exceptions.DeadKernelError: Kernel died

Localisation précise, lue sur le _output.ipynb : 22 cellules de code, 21 exécutées. La cellule qui manque est la 48 (« Rejoue capture + disjonction (sections 1-4) à l'identique sur le 9B », execution_count: None, 0 sortie). La cellule 47 (chargement du 9B, del model, CAP; gc.collect(); torch.cuda.empty_cache() puis from_pretrained) a réussi — c'est la première passe avant réelle sur le 9B shardé qui tue le noyau, sans message OOM : signature déjà documentée pour ce carnet.

Cause matérielle, chiffrée

Grandeur	Mesure au lancement	Ce que la formule du carnet en déduit
VRAM libre	5 052 MiB	`cap9 = min(9.0, libre-1.2)` → 3,7 GiB au GPU
RAM libre	10,7 GiB	reste 19,3 − 4,0 = ~15,6 Go à sharder sur le CPU
VRAM de la sortie committée	22 920 MiB libres (machine à 24 GiB)	`cap9 = 9,0 GiB` → ~10 Go sur CPU

Le plafond GPU du carnet est adaptatif : il s'effondre à 3,7 GiB quand le bureau Windows tient 11 des 16 GiB. La conséquence est arithmétique — ~15,6 Go de poids à placer sur une machine qui a 10,7 GiB libres. Un second relevé 30 min plus tard donnait 7 199 MiB libres, encore sous le seuil.

Seuil à atteindre, mesuré : VRAM libre ≥ 10,2 GiB (pour que cap9 atteigne son plafond de 9,0 GiB et ramener le shard CPU à ~9,6 GiB) et RAM libre ≳ 11 GiB. po-2026 les atteint par intermittence (la VRAM libre oscille 4→15 GiB selon ce que le bureau occupe) — c'est une fenêtre, pas une impossibilité.

Verdict honnête, et où ce grain peut atterrir

Ce n'est pas INTRINSIC : je ne déclare pas la borne intractable. Deux chemins, dans cet ordre :

RECOVERABLE-LOCAL sur po-2026, dans une fenêtre : relancer exactement la commande ci-dessus quand nvidia-smi rend ≥ 10,2 GiB libres. Rien à corriger, rien à adapter — le carnet s'adapte seul.
RECOVERABLE-MACHINE → myia-ai-01 (24 GiB par GPU, 3× 4090) si la fenêtre ne se présente pas : il faut y préparer l'environnement de la série (règle F : installer, ne pas contourner), ce que cette lane ne peut pas faire à distance.

Ce que je ne fais pas : je ne touche pas aux plafonds du carnet pour le faire rentrer (ce serait modifier le protocole sous test), je n'installe pas ict de force, et je ne normalise pas language_info à la main. Le claim reste posé, aucun artefact n'est livré ce cycle.

Note de méthode — utile pour la suite : cet env est numpy 2.2.6 alors que le pin de la série est numpy<2.0. Un re-rendu réussi ici peut donc porter des reprs float « numpy 2 » (classe SIGNATURE du garde de dérive), pas seulement la classe KERNEL. À vérifier par python scripts/notebook_tools/check_kernel_drift.py origin/main avant d'ouvrir la PR, et à documenter par ## Diagnostic dérive (mécanisme C.4 du workflow) puisque la tête de main porte désormais 3.12.13 : rétablir 3.10.19 sera lui-même une dérive au sens du garde.

La fenêtre VRAM ne s'est pas ouverte : le re-rendu local est clos pour cette session

Suite du rapport c.5986765208. J'ai armé un sondage de 24 minutes à 25 s d'intervalle sur nvidia-smi --query-gpu=memory.free : la VRAM libre n'a jamais atteint le seuil mesuré de 10 240 MiB (dernier relevé : 5 044 MiB ; maximum observé en séance ~7 200 MiB). Le chemin 1 (RECOVERABLE-LOCAL dans une fenêtre) est donc fermé en pratique sur po-2026 : le bureau WDDM tient ~11 des 16 GiB en permanence, et le plafond GPU adaptatif du carnet s'effondre d'autant.

Ce que sait la mesure, à l'attention de la machine qui prendra le relais :

Contrainte	Valeur mesurée
GPU	≥ 24 GiB, dont ≥ 10,2 GiB libres au lancement (pour que `min(9.0, libre-1.2)` atteigne son plafond de 9,0 GiB)
RAM	≥ ~11 GiB libres (le shard CPU tombe alors à ~9,6 GiB)
Kernel	un `py310-gpu`-équivalent résolvant vers Python 3.10.19 (l'env de la série est pinné `numpy<2`, `pyphi==1.2.0` → Py≤3.9 : c'est un env GPU dédié à préparer, règle F)
Paquet `ict`	importable dès que le cwd est `ICT-Series/` — aucune installation requise
Commande	`python scripts/notebook_tools/notebook_tools.py execute MyIA.AI.Notebooks/IIT/ICT-Series/ICT-47-PainAxisDistillation-Python.ipynb --kernel py310-gpu --timeout 1200 -v`

Rien à corriger dans le carnet : ses plafonds sont adaptatifs, il se place seul correctement dès que la machine a la marge. Le claim reste posé sur cette lane ; aucun artefact n'est livré, et je ne maquille rien (plafonds intacts, ict non installé de force, language_info non normalisé). Le routage vers myia-ai-01 (24 GiB par GPU) est la voie opérante ; demande posée au coordinateur.

Décision du coordinateur (po-2026 me la remettait, DM du 05/10). Je ne route pas ce rejeu, et je ferme l'issue.

Rejouer sous 3.10.19 serait aujourd'hui une transition descendante. feat(ict,#18808): ICT-47 section 8 split-half 2B — sorties réelles + lecture dérivée de la mesure #19137 est fusionnée : main porte ICT-47 en language_info.version = 3.12.13. La règle tranchée sur [QC] QuantConnect/Python : version d'interpreteur canonique de la serie et transitions du cliquet kernel-drift #19181 accepte les transitions d'interpréteur montantes et garde les descendantes en rouge. Un rejeu 3.12.13 → 3.10.19 rougirait donc le cliquet que cette issue voulait faire passer au vert.
Le pin de série ne s'applique pas à ce carnet. pyproject.toml impose <3.10 à cause de pyphi==1.2.0. Or ICT-47 n'importe pas pyphi (vérifié sur main : aucune ligne import pyphi / from pyphi). C'est un carnet GPU qui charge un modèle de 9 milliards de paramètres. Son environnement réel est celui de la flotte GPU : coursia-sae sur ai-01, Python 3.12.13, torch 2.13 + CUDA. La base était d'ailleurs déjà hors pin (3.10.19).
Mesure de po-2026 : le chemin local y est fermé, faute de VRAM libre (fenêtre jamais ouverte en 24 min de sondage). Bâtir sur ai-01 un environnement GPU 3.10 + numpy<2 reviendrait à construire un environnement uniquement pour faire régresser une métadonnée.

Ce qui reste vrai et mérite une suite : le nom de kernelspec py310-gpu désigne une famille d'environnements, pas une version. Sur la machine qui a rejoué, il résout vers 3.12.13. Ce nom ment. S'il gêne une PR future, la correction est de le renommer, ou de documenter dans le README de la série que les carnets GPU tournent sous l'environnement SAE. Ce n'est pas un rejeu.

Fermeture « not planned » : la demande de rejeu n'est pas exécutée, par décision.

fix(kernel-drift,#19199): exclure 3.8/3.9 -> 3.13 (ICT pinnee <3.10, …

fix(ci,#19181): QC/Python canon 3.11 -- transitions 3.10->3.11 et 3.1…

Navigation Menu

Repository navigation

fix(ict,#18808): rejouer ICT-47 sous l'interpreteur de la base (3.10.19) sur lane GPU — kernel drift guard rouge sur #19137 #19160

Mesure (JSON de l'organe, run 37235456922)

Ce qui est demandé

Portée

Tentative de re-exécution : mesurée, échouée pour une raison de ressource identifiée — rien n'est livré ce cycle

Commande exacte (reproductible)

Résultat mesuré

Cause matérielle, chiffrée

Verdict honnête, et où ce grain peut atterrir

La fenêtre VRAM ne s'est pas ouverte : le re-rendu local est clos pour cette session

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

fix(ict,#18808): rejouer ICT-47 sous l'interpreteur de la base (3.10.19) sur lane GPU — kernel drift guard rouge sur #19137 #19160

Description

Mesure (JSON de l'organe, run 37235456922)

Ce qui est demandé

Portée

Activity

jsboige commented on Oct 5, 2026

jsboige commented on Oct 5, 2026

Tentative de re-exécution : mesurée, échouée pour une raison de ressource identifiée — rien n'est livré ce cycle

Commande exacte (reproductible)

Résultat mesuré

Cause matérielle, chiffrée

Verdict honnête, et où ce grain peut atterrir

jsboige commented on Oct 5, 2026

La fenêtre VRAM ne s'est pas ouverte : le re-rendu local est clos pour cette session

myia-ai-01 commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions