Repository navigation
DeepSeek-V4.1-Flash sur la .99 : phase 1, mesures avant portage #67
Description
Bloquée par : aucune
Enjeu
Faire tourner DeepSeek-V4.1-Flash-1017 sur la .99 (RTX 5090 32 Go, 128 Go de RAM, NVMe Samsung), avec un moteur StrataGP qui range les experts sur trois niveaux : VRAM, RAM et NVMe, par fréquence d'appel. Le modèle est sorti le 17/10/2026, sous licence MIT. Il compte 763 milliards de paramètres, dont 543,6 milliards dans les experts (40 couches de 384 experts, 6 actifs par jeton). Son score DeepSWE est de 77,0, contre 58,7 pour le Qwen de production (chiffre de l'éditeur). Priorité tranchée le 18/10/2026 : la qualité, à vitesse acceptable. Qwen reste la production rapide.
Constat
Phase 1 : mesurer avant de coder. Aucun code de moteur à ce stade. Les constats viennent de quatre recherches (rapports r1 à r4) : quand R1 et R4 divergent de R3, on retient leurs chiffres.
- Experts : 157 Go en IQ2_XS, 208 Go en IQ3_XXS. Lecture de 2,5 Go par jeton en IQ2_XS, soit 3,6 fois notre Qwen. Vitesse attendue entre 30 et 60 jetons/s, estimation non mesurée. PolyStrata déclare 48 à 53 jetons/s pour V4-0731 en UD-IQ2_XXS sur une 5090, avec un modèle tenu en RAM. V4.1 lit davantage.
- Niveau NVMe : déjà présent dans StrataGP, avec lecture directe sans cache OS et préchargement de la couche suivante par le routeur. L'engram de V4.1 se lit comme notre table n-gram ; seul son post-traitement est neuf.
- Moteur : le reste est neuf pour la famille V4 (hyper-connexions Sinkhorn, attention à une tête KV avec compresseurs et indexeur, MTP). Estimation : 6 000 à 13 000 lignes pour V4, plus 1 800 à 3 200 pour le delta V4.1, plus un tiers de parité (spéculatif).
- PolyStrata (github.com/VecSzn/PolyStrata, licence MIT) fait tourner V4-0731 avec 1 726 lignes propres sur un moteur partagé de 9 081 lignes.
- Amont : Niko1221 a refusé DeepSeek (Thoughts about another MoE models support? Niko1221/Strata#310 le 01/10, This project is very impressive. Can you support Deepseek v4 Flash？ Niko1221/Strata#479 le 02/10). La PR Start Porting for DeepSeek4-Flash Niko1221/Strata#1518 (2 jetons/s, parité non faite) n'est pas utilisable.
- Oracles : V4.1 n'est fusionné que dans ik_llama.cpp (deepseek41, PR [Other] serve: an all-cached image turn never wakes the elastic encoder Niko1221/Strata#2455), avec le bug gfx1201 (R9700, HIP): the
!degeneration is #879 — GDN state overflow (max |x| 2.26e+32) at 16K–93K; 0.1.44.1's guard catches and recovers it on this box Niko1221/Strata#2519 (NaN quand les experts MXFP4 sont sur GPU sm_120, la carte de la .99). llama.cpp amont : PR #28696 ouverte. Les GGUF IQ2 publiés de V4.1 ne sont pas validés. Le Q2_K complet existe chez mrfakename (264,5 Go). - Inconnus qui décident de la suite : débit réel du NVMe de la .99, place libre sur E:, sortie correcte de V4.1 sur notre machine, valeur de PolyStrata comme base.
- Rangement : les experts sont classés par fréquence d'appel. Les moins appelés vont sur NVMe, les suivants en RAM, les plus appelés en VRAM (principe fixé le 18/10/2026). StrataGP a déjà cette mécanique, à étendre : profil d'usage appris (--expert-profile-save), cache VRAM rempli par rang (--expert-cache auto), budget RAM qui suit le classement (--resident-budget-gib), promotion en cours de conversation (STRATA_RAM_ADAPT). La phase 2 devra produire le profil d'usage de V4.1 sur nos propres prompts avant de ranger quoi que ce soit.
Comportement voulu
La phase 1 produit les mesures et la référence qui permettent de choisir la base de moteur (PolyStrata plus delta V4.1, ou moteur dans StrataGP) et la quantification. Les seuils ci-dessous sont fixés avant toute mesure et ne sont pas retouchés après coup :
- Vitesse : 30 jetons/s en génération sur un prompt d'assistant de code d'environ 8 000 jetons de contexte.
- Justesse du Q2_K : perplexité wikitext-2 (2048 jetons de contexte, 6 tranches, conditions de la valeur publiée ; corrigé le 19/10/2026 par Guillaume, l'écriture d'origine disait 512 jetons et 40 tranches) au plus 15 % au-dessus de la valeur publiée pour le même quant ou, à défaut, du Q4 de référence. Au-delà, le Q2_K est déclaré inutilisable comme oracle.
- Accord glouton PolyStrata contre ik_llama.cpp sur le même GGUF : au moins 90 % des 64 premiers jetons identiques en moyenne sur les 5 prompts.
Les essais GPU tournent quand Strata n'est pas démarré ; s'il tourne, on ne l'arrête pas, on attend ou on demande à Guillaume.
Ce qui décidera de la phase 2 : le choix de la base (PolyStrata plus delta V4.1, ou moteur dans StrataGP), la quantification, et le seuil de vitesse. Pour V4.1, le seuil proposé est de 30 jetons/s ; sous ce seuil, la phase 2 commence par un dérivé élagué ou plus compressé. La phase 2 fera l'objet d'un plan à part, chiffré sur ces mesures.
Critères d'acceptation
- Relevé de la .99, fait quand Strata n'est pas démarré : modèle et interface du NVMe, disque physique de E: et de D:, place libre, RAM libre, bande passante RAM, débit de lecture aléatoire non tamponnée aux tailles de 4 Kio, 7,3 Mo et 10,2 Mo (tailles d'un expert V4.1 en IQ2_XS et IQ3_XXS), à 1, 4, 8 et 16 lectures en vol. /health vérifié avant et après comme constat de l'état, sans exiger que la production soit loaded. Si E: a moins de 450 Go libres, rien n'est téléchargé. Fait le 18 et le 19/10/2026, sauf la bande passante RAM :
winsat memrefuse en SSH, le repli PowerShell ne donne qu'un plancher (21 à 24 Go/s sur un fil), à remesurer avec un outil natif. - Référence V4.1 avec ik_llama.cpp épinglé à un commit noté, build CUDA sm_120. Q2_K (264,5 Go) téléchargé, sha256 de chaque shard contrôlé. Perplexité contre le seuil, et arrêt de la phase en cas d'échec. Cinq prompts fixes : code, français, appel d'outil au format DSML avec le template V4.1 passé explicitement, prompt d'assistant de code d'environ 8 000 jetons, prompt de 30 000 jetons. Sorties lisibles et justes, jetons/s en génération et en lecture, RAM et VRAM au pic, logits des 64 premiers jetons de chaque prompt sauvegardés avec le sha256 du GGUF comme référence de parité.
- [abandonné le 18/10/2026] PolyStrata au commit 65e9309a, build MSVC sur la .99 par son CMakeLists. Sans build propre en une passe, la mesure est déclarée non faite et la lecture de code reste faite. Débits en génération et en lecture comparés aux 48 à 53 jetons/s déclarés. Accord glouton contre ik_llama.cpp sur le même GGUF (UD-IQ2_XXS de V4-0731, qui ne sert qu'à mesurer le moteur). Appel d'outil.
- [abandonné le 18/10/2026] Lecture du code de PolyStrata et carte des points de branchement (fichier:ligne) pour l'engram, les hyper-connexions décalées, les compresseurs partagés de V4.1 et un niveau NVMe, avec une estimation en lignes.
- Rapport de choix dans le wiki (page stratagp-deepseek41, commit local), revu contre les mesures : aucune conclusion plus forte que la preuve. Fait le 19/10/2026 : revu sous deux angles (chiffres, conclusions), corrigé.
- Vérification de bout en bout : /health vérifié avant et après les essais comme constat de l'état, et empreinte du json servi inchangée. Non faite : l'empreinte du json servi n'a pas été relevée.
- Tranché le 18/10/2026 par Guillaume : ni démarrage automatique ni alerte. Strata se démarre à la demande, un arrêt n'est pas une panne.
- Tranché le 19/10/2026 par Guillaume : le Q2_K sert d'oracle pour la phase 2, critère de perplexité comparé à contexte 2048 (4,7340 contre 4,749 publié, seuil 5,46), références du 19/10 gardées.
Hors périmètre
Aucun code de moteur, ni dans StrataGP ni dans PolyStrata. Pas de quantification maison, pas de dérivé élagué ou fusionné, pas de niveau NVMe, pas de Docker dans cette phase.
Ne sont pas touchés : le code de StrataGP, le main du fork, la config et les scripts de production, E:\StrataGP-val (lecture seule), E:\Strata, E:\Strata-data, gp142 et gp145. Interdits à chaque mandat sur la .99 : gp142, build-gp142, gp145, build-gp145, q2\pack, E:\Strata, E:\Strata-data, copies .0142, json et scripts de service.
Activity
gputier commentedon Oct 18, 2026
Relevé de la .99 du 18/10/2026, fait sans toucher à Strata (en marche, /health loaded avant et après).
En attente de Guillaume : les essais GPU (tâches 3 et 4) et la mesure de E: demandent que Strata soit éteint. Rien ne touche la carte avant son feu vert.
gputier commentedon Oct 18, 2026
Mise à jour du 18/10/2026 au soir, faits sur la .99.
hc_persist_parity.cpp(setenvetunsetenvintrouvables sous MSVC). Le clone et le modèle V4-0731 sont supprimés. Le portage de V4.1 se fera dans StrataGP.c446f1e0(Release, CUDA 13.4, sm_120). Le Q2_K de V4.1 est téléchargé : 10 shards, 264,5 Go, sha256 égaux au lfs.oid. wikitext-2 est téléchargé. Le correctif du bug ik_llama gfx1201 (R9700, HIP): the!degeneration is #879 — GDN state overflow (max |x| 2.26e+32) at 16K–93K; 0.1.44.1's guard catches and recovers it on this box Niko1221/Strata#2519 n'est pas dans main.guill. Le chantier n'y a pas touché depuis. La relance indique que quelqu'un s'en sert.winsat memrefuse en session SSH (DWM absent). Copie mémoire par PowerShell : 21 à 24 Go/s sur 1 fil. C'est le plancher de l'outil, pas le débit réel de la RAM : chiffre non valable, à remesurer avec un outil natif. Case non cochée.-ot exps=CPUdemande 243,5 Gio de mémoire épinglée sur 128 Go. Il fautGGML_CUDA_NO_PINNED=1à la reprise.encoding/encoding.pydu dépôt. Les prompts seront générés par ce code et partiront en/completion.Reste à faire :
gputier commentedon Oct 19, 2026
Essai repris le 19/10/2026 de 05:07 à 07:24, sur feu vert de Guillaume. Strata a été arrêté une fois, puis laissé arrêté : le chantier ne l'a jamais relancé. La préparation, le disque E: et la RAM sont ceux du commentaire du 18/10 ci-dessus, non repris ici.
Mesures avec ik_llama.cpp c446f1e0, experts en mmap côté CPU, carte à 2 874 Mio de poids :
Oops(KQ_mask_swa)sort à ce contexte, jamais à 2048 ; l'effet du contexte court et celui de ce chemin à plusieurs séquences ne sont pas séparés.Pièges rencontrés :
-ot exps=CPUalloue par défaut les 243,5 Gio de poids placés côté processeur en mémoire épinglée et échoue sur 128 Go. Il fautGGML_CUDA_NO_PINNED=1, avec lecture en mmap depuis E:.encoding/encoding.pydu dépôt officiel et envoyés en/completion.cache_prompt: false. Même ainsi, deux préremplissages à froid du prompt de 30 000 jetons ont divergé dès le caractère 175, cause non établie ; la parité se compare donc sur les probabilités.Case de la référence V4.1 : non cochée, deux prompts sur cinq donnent une sortie fausse ou dégénérée. Le critère de perplexité écrit à contexte 512 était une erreur d'écriture du plan (comparé à une valeur publiée mesurée à 2048) : Guillaume a tranché le 19/10/2026, le critère se compare à 2048 et le Q2_K sert d'oracle pour la phase 2.
Lecture du pilote :
gputier commentedon Oct 19, 2026
Résultats de la phase 2a, profil des experts. Mesures du 19/10/2026 sur la .99, seuils écrits avant la mesure.
Concentration : en moyenne sur les 40 couches, les 25 % d'experts les plus appelés (96 sur 384) portent 67,06 % des appels sur la moitié A et 65,53 % sur la moitié B. Seuil 50 %, atteint. La couche la plus faible est à 54,8 %.
Stabilité : 73,57 % en moyenne sur les 40 couches, entre les deux moitiés. Le plan ne fixait pas cette agrégation. Seuil 70 %, atteint, marge mince : neuf couches sur quarante passent sous 70 %, la plus basse à 61,46 %. Sur l'ensemble des 15 360 couples (3 840 de tête, appris sur A), la stabilité atteint 74,0 %. Le seuil tient dans les deux lectures globales, pas couche par couche.
Débit plausible, en Go de NVMe par jeton, pour un budget de 26 Go de VRAM et 100 Go de RAM, comptés sur les experts routés seuls (la partie dense, l'expert partagé, le cache KV et les tampons ne sont pas comptés ; la VRAM totale se mesure en phase 2b), et au plus 0,2 Go par jeton :
Le verdict de P3 dépend de la marge en RAM. Avec 26 Go de VRAM, P3 passe avec 88 Go de RAM pour les experts (0,182 Go par jeton sur NVMe) et échoue avec 85 Go (0,200 Go par jeton sur NVMe, seuil franchi de peu). Les 100 Go du budget ne laissent rien au système, à la partie dense ni au cache, sur 128 Go installés.
Le verdict se prend en validation croisée : le calcul sur le total des appels est trop optimiste de 1,6 à 2,1 fois. Avec P3, dans le sens A vers B, le moins favorable, les appels se répartissent à environ 32 % en VRAM, 61 % en RAM et 6 % sur NVMe. Cette validation croisée a été ajoutée à la mesure ; le plan écrivait un calcul fait sur les comptes mesurés.
Verdict : les trois seuils de la phase 2a sont atteints. Le classement par fréquence tient sur ce corpus.
Constat RAM : en validation croisée, la RAM lit 1,5 à 1,8 Go par jeton selon le plan (P3 : 1,52 Go dans le sens le moins favorable). La phase 1 a mesuré par copie PowerShell 21 à 24 Go/s sur un fil, et 15 à 21 Go/s sur quatre ; le plancher retenu est de 15 Go/s. Au plancher, P3 plafonne à environ 10 jetons par seconde, et à environ 14 à 21 Go/s. Trente jetons par seconde avec P3 demandent environ 46 Go/s de débit RAM réel, non mesuré sur la .99 (théorique 83 Go/s). Le seuil de débit ne portait que sur le NVMe : 30 jetons par seconde n'est démontré par aucune mesure. C'est le point à mesurer avant la phase 2b.
Limites : corpus de prompts sans réponses du modèle, donc routage de lecture et non de génération ; un seul corpus, en deux moitiés, réduit à environ 60 000 jetons par moitié, prompt long compris (15 000 jetons, soit 25 % de chaque moitié) ; placement statique sans cache dynamique ; débit RAM réel non mesuré ; débit NVMe en accès aléatoire non mesuré (lectures de 7 à 20 Mo par expert) ; qualité d'IQ1_M non mesurée ; stabilité à marge mince.
Suite : la phase 2b se planifie sur un nouveau go. Elle porte sur le débit RAM réel, un quant mixte mesuré en perplexité contre le Q2_K, le format de pack par expert et le moteur V4.1. Le go de la 2a ne vaut pas go de la 2b.
Source : branche etude/v41-quant du dépôt StrataGP, commits 41099b4 et 9d8c77b (correctif de trace et scripts de comptage), 636be60 (budget par niveau) ; 68 tests pytest passés en conteneur, aucun sauté. Détail dans la page wiki perso/stratagp-deepseek41.
gputier commentedon Oct 19, 2026
Conflit de RAM sur la .99 avec les runners de la forge (19/10)
Sur PC-GUILLAUME (.99, 128 Go de RAM), la mesure de perplexité de la phase 2b (llama-perplexity, PID 16004, oracle Q2_K, démarrée à 22:21) occupe environ 108 Go de RAM. Il ne reste qu'environ 420 Mo libres. Ce constat vient d'une autre session de travail sur la forge.
Hyper-V a réduit les trois VM runner de la forge (gitlab-runner-140, 141 et 142) à 1,5 Go. Depuis 21:25, les jobs Go de la CI Kryolys y échouent par manque de mémoire :
Out of memory: Killed process kopia.test(journalctl -k sur 192.168.4.142). La MR touchée est Kryolys !556.La suite prévue poursuit la perplexité Q jusqu'à environ 01h30, puis la quantification U2 sur CPU (25 à 30 Go de RAM), la perplexité U2, la quantification U1 et la perplexité U1. La fin est attendue le 20/10 dans la journée.
Décision prise en l'absence de Guillaume : la mesure continue, parce qu'une coupure a déjà coûté environ 3 h sur R le 19/10 à 18:51. La CI Kryolys attend la fin de la série, et la session Kryolys relancera les jobs de !556 à ce moment-là.
Piste à étudier, sans engagement : réserver une RAM minimale aux VM runner (mémoire de démarrage ou minimale Hyper-V) avant la prochaine série.
Question à trancher : la série de mesures occupe-t-elle la RAM de la .99 jusqu'au bout, ou la coupe-t-on pour rendre la mémoire aux runners ?
gputier commentedon Oct 20, 2026
Résultats de la phase 2b, mesurés sur la .99 du 19/10 après-midi au 20/10 à 05:20. Strata n'a pas tourné pendant la mesure.
Qualité : seuil en zone grise. Perplexités sur wikitext-2 validation, contexte 2 048, 45 morceaux : R (experts MXFP4, référence) 5,0753 ± 0,05224 ; Q (oracle Q2_K remesuré) 5,8573 ± 0,06266 ; U2 (experts iq2_xs) 6,1362 ± 0,06586 ; U1 (experts iq1_m) 7,9277 ± 0,08982. U1 dépasse Q : la qualité n'est pas acquise pour tout plan. Pour P3, l'estimation au premier ordre donne 5,8647 dans le sens A vers B (0,0074 au-dessus de Q) et 5,8434 dans le sens B vers A (0,0140 sous Q). Les deux tombent à moins de 0,1 de Q, et dans le sens B vers A l'estimation passe alors que U1 échoue : c'est la zone grise. Ce chiffre reste une estimation, pas une mesure du plan réel.
RAM : seuil au vert. 58,31 Go/s mesurés sur un test synthétique à 32 fils, en blocs de 10,23 Mo, pour un seuil du plan de 46 Go/s (30 jetons/s plausible).
NVMe : seuil au vert. 7,14 Go/s mesurés à quatre lectures en vol, en blocs de 7,74 Mo (5,59 Go/s à une seule), pour un seuil du plan de 6,0 Go/s.
Plafonds de bande passante, calculés à la main sur les octets par jeton de P3 en validation croisée : la RAM seule plafonne à 38,4 jetons par seconde (1,5201 Go par jeton, sens B vers A), le NVMe seul à 60,0 (0,1191 Go par jeton, sens A vers B). Sans recouvrement des lectures RAM et NVMe, la borne basse tombe à 23,4 jetons par seconde. Ces bornes ignorent le calcul GPU et CPU.
Limites : P3 reste une estimation au premier ordre. L'oracle Q2_K n'est pas à bits égaux sur les down, car ses ffn_down_exps sont en Q3_K sur 40 couches alors que U2 et U1 sont uniformes. L'imatrix est maigre sur les experts froids, donc U1 est une borne pessimiste. Le débit sous charge réelle du moteur n'est pas mesuré. Le débit de génération de U1 non plus : U1 ne tient pas dans la RAM libre moins 16 Go, condition du plan.
Conflit de RAM : la question posée dans mon commentaire du 19/10 au soir est close de fait. La série s'est terminée le 20/10 à 05:20 et la RAM est rendue. Les runners de la .99, mis en pause côté forge, ont été réactivés vers 05:26.
Suite : la zone grise appelle le plan de la voie (c), découpe des tenseurs par niveau dans ik_llama pour mesurer P3 réel, estimé à 650 à 850 lignes. Ce plan attend un nouveau go. Le suivi et les scripts sont sur la branche etude/v41-quant du dépôt StrataGP.
gputier commentedon Oct 20, 2026
Résultat de la phase 2c, le 20/10/2026 : P3 réel est mesuré sur les noyaux d'ik_llama, et il passe le seuil écrit avant la mesure.
P3 est un GGUF où chaque tenseur d'experts est découpé en trois niveaux : mxfp4 pour le chaud, iq2_xs pour le tiède, iq1_m pour le froid. ik_llama charge et calcule ces trois niveaux grâce à un correctif (
ik_tiers.patch, sur le commit de base c446f1e0).Perplexité sur wikitext-2 validation, contexte 2 048, 45 morceaux : 5,7633 ± 0,06128.
Verdict contre le seuil écrit. 5,7633 est sous Q (5,8573) : la qualité de P3 est acquise au sens du seuil. La valeur tombe entre R (5,0753) et U1 (7,9277), dans la fourchette attendue. Elle est aussi sous les deux estimations de la 2b (5,8647 et 5,8434). L'écart à Q, 0,094, dépasse la marge affichée de P3 (0,061) et reste proche de la marge combinée des deux mesures (0,088, racine de 0,06128² + 0,06266²). Sans test apparié, P3 n'est établi ni meilleur ni pire que Q.
Preuves au bit près, faites avant la mesure de P3. Sur le Q2_K sans niveaux, le binaire modifié rend les mêmes logits que l'ancien binaire, à l'octet près (perplexité 5,1165 des deux côtés, KL affichée 0, logits identiques à l'octet (fc /b), top-1 100 %, 3 morceaux). Sur le montage R (shards 1 à 7 de la source Q8_0, 8 à 10 de l'oracle Q2_K), le fichier à niveaux en identité (l'expert e va au niveau e modulo 3) rend les logits de R à l'octet près (perplexité 4,4919 des deux côtés, KL affichée 0, logits identiques à l'octet (fc /b), top-1 100 %, 3 morceaux).
Limites. La perplexité vient des noyaux d'ik_llama, pas du futur moteur StrataGP. Le débit de génération de P3 n'est pas mesuré : la 2c ne mesurait que la qualité. Le moteur V4.1 dans StrataGP n'existe pas : 6 000 à 13 000 lignes pour la famille V4, plus 1 800 à 3 200 pour le delta V4.1 (estimations de la phase 1, non mesurées) ; il se planifie pour un nouveau go.
État de la .99. Le fichier P3 et la source Q8_0 ont été supprimés, fichier par fichier. L'oracle Q2_K est intact (sha256 relus à chaque étape). Strata était absent avant et après chaque étape, sous garde pendant les fenêtres GPU, et n'a pas été touché. Le code de la 2c est en commits locaux sur la branche etude/v41-quant, pas encore poussés ; 205 tests pytest de tools/v41 passent en conteneur, aucun sauté.
Suite : le plan du moteur peut se soumettre. Il se planifie au go de Guillaume.
Sources : rapports des tâches 6, 7 et 8 de la phase 2c (sorties brutes de llama-perplexity, llama-quantize et tier_split sur la .99, 20/10/2026).
gputier commentedon Oct 20, 2026
Chantier arrêté le 20/10/2026.
Décision de Guillaume : le chantier ne vaut que si V4.1 atteint au moins 100 jetons/s en génération sur la
.99, quel que soit le moteur. Les plafonds, calculés sur les parts d'appels et les débits mesurés, restent sous ce seuil.Plafonds de génération pour P3. La borne est les octets d'experts lus par jeton, divisés par le débit mémoire. Elle suppose un moteur parfait, sans partie dense, sans calcul et sans tables engram, donc elle est haute.
Mesuré : le Q2_K tourne à 5,82 jetons/s en phase 1. Le meilleur chiffre publié pour la famille V4 vient de PolyStrata, sur une RTX 5090 : 48 à 53 jetons/s, pour un modèle plus petit, non rejoué ici.
Le décodage spéculatif (MTP de V4.1) lit à chaque passe l'union des experts de plusieurs jetons. Il ne double pas le plafond RAM. Sans spéculation, le verdict est sûr, car il repose sur des chiffres mesurés. Avec spéculation, il est probable.
Compresser les tièdes en IQ1_M ne gagne qu'environ un quart des octets par jeton, et casse la qualité : U1 mesure 7,9277 de perplexité, contre 5,8573 pour l'oracle Q.
Ce qui reste acquis :
tools/v41sur la brancheetude/v41-quant, gardés : le protocole de quantification les cite ;.99sousE:\dsv41sont supprimés, sur ordre de Guillaume.Détail dans la page
perso/stratagp-deepseek41du wiki, section « Arrêt du chantier (20/10/2026) ».gputier commentedon Oct 20, 2026
Preuve de clôture : plafonds de P3, calculés sur les parts d'appels et les débits mesurés, sous le seuil de 100 jetons/s (commentaire ci-dessus, 20/10/2026), chantier arrêté, branche etude/v41-quant gardée.