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:
parent
376b4a4a70
commit
12217d3bbc
|
|
@ -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.
|
||||
- Charge Kazeia: prefill 500-2000 tok/tour, CPU ~75 → 7-27s, HTP → 3-13s. Utile, pas vital.
|
||||
|
||||
## Identité projet — A vs B (Richard tranche)
|
||||
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.
|
||||
## Identité = A : intégration produit (tranché Richard)
|
||||
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
|
||||
R&D LLM frontière (kernels HVX bit-exacts, quant) = aide partielle, je le dis au cas par cas.
|
||||
|
|
|
|||
Loading…
Reference in New Issue