Constat (verifie sur main ce jour)
MyIA.AI.Notebooks/GenAI/Texte/10e_LLamaSharp_DotNet_BakeOff.ipynb — les fixtures des exercices 2 et 3 (cellules code 19 et 21) portent encore les nombres de la lignee GGUF d'origine, alors que le run de reference commite (S2) est celui de la lignee courante du harnais verse par #15508/#15572. La cellule 21 le dit elle-meme en prose : S1 = run d'un autre jour, lignee GGUF d'origine (fbe1d5ed…).
Ce residuel est nomme par l'auteur de #15572 dans le body de cette PR (« 2e commit reste en file — fixtures des exercices 2/3 (cellules code 19/21) encore sur les nombres de la lignee d'origine, leur edition declenchant C.2 (re-execution complete) alors bloquee par la saturation GPU ») — il est hors perimetre de #15570 (dont la Route 1 est livree) et merite son propre grain.
Pourquoi ce n'est pas cosmetique
Les fixtures sont le substrat des exercices pedagogiques : un etudiant qui re-execute le harnais obtient les nombres de la lignee courante, que les enonces lui demandent de comparer a des valeurs d'une lignee qui n'est plus celle du depot. La re-execution complete (C.2) est le prix d'entree — c'est exactement ce qui avait differe la livraison.
Faisabilite mesuree (po-2027, ce jour)
| Precondition |
Etat |
Harnais source sur main |
present : tools/llamasharp-bakeoff/{Program.cs,test.csproj} |
dotnet publish self-contained CUDA12 |
executable localement (.NET 9 present) |
GGUF qwen3-4b-q4km |
absent localement — telechargement requis (~2,5 Go) |
| VRAM |
RTX 4060 8 Go — un 4B en q4_km tient |
Acceptance
- Fixtures des cellules 19 et 21 re-derivees du run de reference courant (lignee du depot, pas
fbe1d5ed).
- Re-execution complete du notebook (C.2) :
execution_count reels, 0 erreur, ratchets output/source verts.
- La prose des enonces reste pedagogiquement coherente avec les nouveaux nombres (la comparaison S1/S2 garde son sens : deux regimes, invites identiques, Temperature = 0.0).
- Si la re-execution GPU echoue malgre tout : verdict SOTA ecrit (RECOVERABLE-*), pas de sortie fabriquee.
See #15041 (EPIC Astra G06 dont ce notebook releve), #15570, #15572.
Constat (verifie sur main ce jour)
MyIA.AI.Notebooks/GenAI/Texte/10e_LLamaSharp_DotNet_BakeOff.ipynb— les fixtures des exercices 2 et 3 (cellules code 19 et 21) portent encore les nombres de la lignee GGUF d'origine, alors que le run de reference commite (S2) est celui de la lignee courante du harnais verse par #15508/#15572. La cellule 21 le dit elle-meme en prose :S1 = run d'un autre jour, lignee GGUF d'origine (fbe1d5ed…).Ce residuel est nomme par l'auteur de #15572 dans le body de cette PR (« 2e commit reste en file — fixtures des exercices 2/3 (cellules code 19/21) encore sur les nombres de la lignee d'origine, leur edition declenchant C.2 (re-execution complete) alors bloquee par la saturation GPU ») — il est hors perimetre de #15570 (dont la Route 1 est livree) et merite son propre grain.
Pourquoi ce n'est pas cosmetique
Les fixtures sont le substrat des exercices pedagogiques : un etudiant qui re-execute le harnais obtient les nombres de la lignee courante, que les enonces lui demandent de comparer a des valeurs d'une lignee qui n'est plus celle du depot. La re-execution complete (C.2) est le prix d'entree — c'est exactement ce qui avait differe la livraison.
Faisabilite mesuree (po-2027, ce jour)
maintools/llamasharp-bakeoff/{Program.cs,test.csproj}dotnet publishself-contained CUDA12qwen3-4b-q4kmAcceptance
fbe1d5ed).execution_countreels, 0 erreur, ratchets output/source verts.See #15041 (EPIC Astra G06 dont ce notebook releve), #15570, #15572.