Skip to content

About

V100 study and results QWEN3.8_27b_Q6 K_V Q8 + vision based

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

4 Commits

Folders and files

Repository files navigation

v100-bench-kit — tests d'optimisation V100 : kit transmissible

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.


1. L'architecture en une figure

┌─────────────────────────────────────────────────────────────────────────┐
│  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.

2. Démarrage à contexte vide (5 min)

  1. 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-repo pitouche/llama-v100-opti (OPTI.md).
  2. Reproduire une mesure (la plus courte, ~5 min) : le bench de test du superviseur (bench/terminal_test_bench.py) ou un auto_bench.py sur le port de capture. Prérequis : une machine comme celle de la §1 + config/kit.env (copier config/kit.env.example et adapter les chemins).
  3. Contester un résultat H2 : suivre docs/protocols/02-AB-ref-h2.md dans opti-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é dans opti-t3-volta-small et opti-h2.

3. Arborescence

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 section bigfiles/ (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).

About

V100 study and results QWEN3.8_27b_Q6 K_V Q8 + vision based

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages