Ce que c'est. Tout ce qu'il faut pour comprendre, reproduire et contester les tests d'optimisation effectués sur une Tesla V100-PCIE-32GB (sm_70, Volta) servant Qwen3.8-27B Q6_K_M + MTP (draft-mtp n_max=3), KV q8_0, flash attention, ctx 200k via un fork Ollama/llama.cpp optimisé Volta (fenêtre de référence : 3 → 16 octobre 2026).
Ce que le kit contient (voir arborescence plus bas) :
- un README d'entrée (celui-ci) — architecture et démarrage à contexte vide ;
- un historique technique honnête (
docs/HISTORIQUE.md) — validé / expérimental / limites ; - les harnais génériques pour reproduire les essais sur une V100 (
bench/) : superviseur, auto_bench, bench_direct, bench_gen ; - les résultats bruts des benchs préfill/génération, de l'autopsie Q8_0 et de p7
(
results/,autopsy/,p7/) et le protocole du superviseur (docs/protocols/) ; - licences, dépendances, prérequis (
LICENSE,NOTICE.md,REQUIREMENTS.md) ; - aucun secret : les tokens sont lus de fichiers 0600 hors repo, les chemins locaux
sont remplacés par la config explicite
config/kit.env.example.
La mission H2 n'est plus dans ce kit. Le kernel FA Q8 tensor-core rows==4
(« mission Kolbo » 8-16/10, GO le 15/10 puis NO-GO le 18/10 — surpassé par T3)
ainsi que son archive complète (journal, protocoles, A/B run8-9c3, CUPTI run7,
patches, prompts, libs) ont été extraits le 01/11/2026 dans le repo
pitouche/opti-h2 — le 7ᵉ repo de la pile
pitouche/llama-v100-opti. Ce kit
conserve le contexte de la période 3-16/10 (docs/HISTORIQUE.md) et les harnais
génériques.
┌─────────────────────────────────────────────────────────────────────────┐
│ MACHINE DE RÉFÉRENCE │
│ GPU : Tesla V100-PCIE-32GB (sm_70, Volta, 32 Go, ~794 GB/s mesurés) │
│ + GTX 1070 (reranker, écartée des tests) │
│ OS : Linux, driver NVIDIA 580.178.04, CUDA 12.6 │
├─────────────────────────────────────────────────────────────────────────┤
│ PRODUCTION (NE JAMAIS TOUCHÉE PAR LES TESTS) │
│ service systemd ollama-v100 : port 11434 │
│ Ollama v0.34.4-5 (pin 16b4376a) + fork llama.cpp b11081-v100-full │
│ .so prod : libggml-cuda.so md5 e4afbb4a (build 2026-10-04) │
│ modèle : qwen3.8-27b-q6-mtp (GGUF 23 088 409 504 o) │
│ kernels custom Volta dans le .so : W4R4 Q6_K, Q5_X4, Q8 FA TC, │
│ GDN 128×4, shortlist-head MTP, defer-prompt │
├─────────────────────────────────────────────────────────────────────────┤
│ ZONE DE TEST (ce que le kit orchestre) │
│ 1. SERVEUR DE CAPTURE : llama-server DIRECT sur port dédié (44901/44911)│
│ - .so de test via GGML_BACKEND_PATH (REF / H2 / H2b) │
│ - même modèle, même env prod (W4R4, shortlist, defer-prompt) │
│ - la prod est stoppée/restaurée par trap (jamais modifiée) │
│ 2. SUPERVISEUR (bench/supervisor_bench.py) : │
│ - lance le bench, survive à la coupure du service (setsid/--detach) │
│ - restaure le service si le bench a échoué, reprend la génération │
│ OWUI en erreur (voir docs/protocols/01) │
│ 3. OBSERVATION : CUPTI 12.9 (shim LD_PRELOAD — cupath_shim*.c, │
│ désormais dans opti-h2) — perf, nvidia-smi — nsys/CUPTI 13.x INOP. │
└─────────────────────────────────────────────────────────────────────────┘
Règle d'or de tous les essais (invariant vérifié après chaque run, consigné dans
docs/HISTORIQUE.md) : le .so déployé, l'unité systemd et le GGUF sont
md5-vérifiés identiques avant et après — un A/B ne change que
GGML_BACKEND_PATH sur le serveur de capture.
- Lire
docs/HISTORIQUE.md(ce qui est validé) — 10 min : l'état de la période 3-16/10, les faits validés, les limites des mesures. Pour la suite (T3, FA16, b2048, n-max) : le meta-repopitouche/llama-v100-opti(OPTI.md). - Reproduire une mesure (la plus courte, ~5 min) : le bench de test du superviseur
(
bench/terminal_test_bench.py) ou unauto_bench.pysur le port de capture. Prérequis : une machine comme celle de la §1 +config/kit.env(copierconfig/kit.env.exampleet adapter les chemins). - Contester un résultat H2 : suivre
docs/protocols/02-AB-ref-h2.mddansopti-h2— le protocole complet (gates, seuils fixés AVANT la mesure, ordre alterné, mesure canonique) et les données brutes pour recalculer sans re-lancer. Le verdict NO-GO (18/10, T3 > H2 même sur rows==4) est raconté dansopti-t3-volta-smalletopti-h2.
README.md ← vous êtes ici
LICENSE MIT (code du kit)
NOTICE.md licences des composants repris (llama.cpp, Ollama, CUPTI, modèle)
REQUIREMENTS.md prérequis machine, dépendances, pins
config/
kit.env.example TOUS les chemins machine-dépendants, explicites
docs/
HISTORIQUE.md historique technique honnête 3-16/10 (validé/expérimental/limites)
SYNTHSE-20261008.md état global au 8 oct (avant la bascule H2) — document de référence
protocols/
01-superviseur-bench.md mécanique du superviseur + watchdog (reprise OWUI)
bench/ harnais génériques (superviseur, auto_bench, bench_direct, bench_gen)
results/ résultats bruts des benchs préfill/génération (1-2 oct)
autopsy/ autopsie Q8_0 (P0→P7a, 5-7 oct) : ETAT + design note + swap/revert
p7/bench kernel Q6_K X4/hoisting (8 oct) — clôturé, non intégré
tools/ scripts d'assainissement (chemins → env) + gpu_uuid.py (invariant n°1)
Extraits le 01/11/2026 → opti-h2 :
h2/ (journal ETAT-raw.md, PROTOCOLE.md, audit, patches H2/H2b, e2-src, nightrun8
- protocoles run9b/c/c2/c3, ab_results_*/nmax_runs/sync_runs/perf-n3, prompts
107k/41k, shim CUPTI),
docs/protocols/02-AB-ref-h2.md+03-build-lib-h2.md, et les binaires de la sectionbigfiles/(libs H2/H2b + microbench, manifest sha256). Ce kit conserve l'historique de la période et les harnais génériques.
## 4. Repro sur une V100 — niveau d'effort par essai
| Essai | Script | Durée | Effort |
|---|---|---|---|
| Bench préfill/gén vs contexte | `bench/auto_bench.py` | ~30 min | config/kit.env + service ollama-v100 |
| A/B REF vs H2 @107k (le GO) | **opti-h2** `bench/run9c3_bench.py` | ~25 min | + libs (bigfiles opti-h2) + prompt |
| A/B de conflit H2 ON/OFF (le NO-GO) | **opti-t3-volta-small** (t3_h2_bench) | ~20 min | .so T3 prod |
| Trace CUPTI d'un decode MTP | **opti-h2** `run_cupath_llama.sh` | ~20 min | + build du shim (cu 12.6, ~2 min) |
| Microbench kernel attention | **opti-h2** `e2-src/e1_bench.cu` | ~10 min | nvcc sm_70 |
| Build des libs H2/H2b | **opti-h2** `docs/protocols/03` + `e2-src/h2lib/` | ~30 min | + fork source (voir NOTICE) |
**Tous** les essais stoppent/restaurent le service de prod (fenêtre 15-25 min max, trap
de restauration) et sont conçus pour être lancés via `bench/supervisor_bench.py run
<script> --detach` (survie à la coupure, reprise de l'agent).
## 5. Ce qu'il faut savoir avant de relancer quoi que ce soit
- **H2 a eu un GO (15/10) puis un NO-GO (18/10)** : le gain (−12,5 % @107k, lié à la
longueur de contexte, et changeant la séquence générée — associativité fp32) a été
supplanté par T3 qui bat H2 **même sur rows==4** → `GGML_CUDA_VOLTA_Q8_FATTN_TC=0`
(+15-17 % decode). Toute l'histoire, les données et la re-validation : **opti-h2**
(et le verdict dans `opti-t3-volta-small`).
- **nsys / CUPTI 13.x ne tournent PAS sur Volta/driver 580** (verdict documenté, puis
CUPTI 12.9 qui fonctionne, en prefix isolé) — ne pas gaspiller du temps dessus.
- **Les compteurs MTP du log serveur sont cumulatifs par processus** et réinitialisés
à chaque rechargement de modèle : fenêtre de mesure = delta des 2 dernières lignes
`spec common_specu` (c'est ce que fait le harnais de référence).
- **La mesure canonique** est la ligne `eval time = X ms / N tokens` du log serveur,
pas le mur HTTP du bench (le mur inclut le transport + le sampling du client).