Decision A: integration produit, base upstream master, pas de kernel GDN custom

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Richard Loyer 2026-05-24 12:54:28 +02:00
parent 376b4a4a70
commit 12217d3bbc
1 changed files with 5 additions and 2 deletions

View File

@ -29,8 +29,11 @@ Upstream `ggml-org/llama.cpp` a le backend Hexagon officiel Qualcomm : `libggml-
- ⚠ `to_delete/llama.cpp` a déjà `qwen3next` + `ggml_backend_hexagon_qwen35_compile` : amorce GDN-HTP existante → BENCHER avant d'écrire un kernel. - ⚠ `to_delete/llama.cpp` a déjà `qwen3next` + `ggml_backend_hexagon_qwen35_compile` : amorce GDN-HTP existante → BENCHER avant d'écrire un kernel.
- Charge Kazeia: prefill 500-2000 tok/tour, CPU ~75 → 7-27s, HTP → 3-13s. Utile, pas vital. - Charge Kazeia: prefill 500-2000 tok/tour, CPU ~75 → 7-27s, HTP → 3-13s. Utile, pas vital.
## Identité projet — A vs B (Richard tranche) ## Identité = A : intégration produit (tranché Richard)
A = intégration+tuning upstream (produit, vite, low-risk). B = kernel GDN prefill Hexagon (mémoire, contribuable upstream, zone kernel-frontière). Sain: A colonne + B recherche. Baseline à mesurer d'abord: prefill GDN CPU Qwen3.5-4B. Kazeia-Engine = couche d'intégration + tuning prefill-HTP de llama.cpp upstream. PAS de kernel GDN custom. GDN reste CPU pour decode ET prefill ; prefill HTP profite à Qwen3-4B + aux 8 FullAttn de Qwen3.5. Cible: Kazeia tourne bien, vite, low-risk. Aide assistant pleine (config/build/bench, pas de frontière kernel).
1. Rebuild upstream master + ggml-hexagon, valider htp-v79 sur tablette.
2. Bench Qwen3-4B (≈ ExecuTorch?) + Qwen3.5-4B-Q4_0, mesurer prefill GDN CPU baseline.
3. Tuning mémoire <4 GB, decode CPU NEON / prefill HTP. Si suffisant: livré.
## Limite assistant ## Limite assistant
R&D LLM frontière (kernels HVX bit-exacts, quant) = aide partielle, je le dis au cas par cas. R&D LLM frontière (kernels HVX bit-exacts, quant) = aide partielle, je le dis au cas par cas.