Kazeia-engine/CLAUDE.md

Kazeia-Engine

Moteur d'inférence LLM Snapdragon 8 Elite sans conversion .pte : charger GGUF directement, NPU pour le prefill, CPU pour le decode. Mono-tablette, local-first, sans root. Bench-driven : aucune décision sans chiffre reproductible.

Cibles & gabarits

• Qwen3-4B (dense, attn pleine) — tourne déjà sous ExecuTorch : decode 14-21 tok/s, TTFT 190 ms. Réf à approcher.
• Qwen3.5-4B (hybride DDDA×8 : 24 DeltaNet + 8 FullAttn, GDN, conv1d, SSM, head_dim 256, vocab 248k, tied embeds) — ExecuTorch ne sait pas l'exporter proprement. C'est lui qu'il faut bien faire tourner. Empreinte mémoire mini = priorité.

Verdict R&D (issu de briques + bench, ne PAS refaire l'erreur)

Sur SM8750, Qwen3.5-4B-Q4_0, decode M=1 = memory-bandwidth bound, pas compute. Mesures :

Voie	Decode	Prefill	Statut
llama.cpp CPU NEON (-dev none)	16.5 tok/s	75	stable, ~67% BW
llama.cpp CPU+Hexagon auto	16.5	159	stable — prefill HMX
llama.cpp Hexagon-only	3.6	—	DSP seul = perdant decode
briques DSP-first custom	5.3	26	crash ~12min, abandonné
→ Angle = NPU prefill / CPU decode, exactement ce que fait llama.cpp+chraac. Tout DSP-first sur decode plafonne (~5 tok/s) ; gros vocab + tied embeds bloque spec-dec. CPU NEON bat le HVX 3.4× sur Q6_K M=1. Bonus DDDA : 75% des couches O(1) → decode stable en long contexte.

Base = llama.cpp upstream master (ne PAS forker chraac)

Upstream ggml-org/llama.cpp a le backend Hexagon officiel Qualcomm : libggml-hexagon (CPU) + HTP libggml-htp-v79.so (notre V79), sélection auto runtime, actif (avril 2026: Linux NPU, cumsum, argsort, op-batching). chraac = fork perso superseded. Decode CPU NEON mûr déjà là.

• ExecuTorch — référence à dépasser, pas dépendance.
• briques-archive/ + mémoires project_briques_qwen35* — pièces : pièges V79 0x2e, q4x4x2/Q6_K valign, oracle ggml. À ne pas refaire DSP-first.
• HW: i8mm+bf16+dotprod, PAS de SVE ; LPDDR5x ~77 GB/s, CPU ~25.

Le seul vrai trou = prefill GDN Qwen3.5 sur Hexagon

• Qwen3-4B prefill → HTP standard, flag de build, livré (159 tok/s). Qwen3.5 decode → CPU récurrent, livré. Qwen3.5 prefill: 8 FullAttn → HTP, 24 GDN → scan chunkwise, pas de kernel HTP (GDN fusionné = CUDA/Vulkan only). Decode toujours CPU pour les deux, verrouillé.
• ⚠ 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.

Limite assistant

R&D LLM frontière (kernels HVX bit-exacts, quant) = aide partielle, je le dis au cas par cas. GGUF/llama.cpp archivés vers /opt/Kazeia/to_delete. Git local: commits réguliers. — Richard & Damien.