# Kazeia-Engine — handoff intégration (MAJ 26/05/2026)

Point d'entrée unique. Remplace le LLM ExecuTorch/Genie par llama.cpp (fork ql) + Hexagon.
GGUF, pas de `.pte`. STT reste ORT-QAIRT (inchangé).

## Décisions figées cette session
- **Modèle Speaker = Qwen3.5-4B en variante `q35-lmq4.gguf`** (embeds en Q4 au lieu du Q6_K
  par défaut → 2.38 GB, decode +5%, qualité ≈ Q4_0 mesurée). Choisi sur l'éval qualité
  (`../eval/VERDICT.md`) : gagne le SAFETY (cite 3114/15) et la majorité du SUPPORT vs le dense.
- **9B écarté** (decode ~4-5 t/s réel, trop lent ; pas de gain qualité justifiant). Cascade
  éventuelle = Guard-4B (thinker) + 4B (speaker), pas 9B.
- **Kernel GDN = chantier clos** : son calcul n'est PAS le goulot (cf RAPPORT_RD §7). Ne pas
  y retoucher pour la perf. Decode au plafond BW CPU (~25 GB/s).

## État du bridge JNI (`jni/kazeia_engine_jni.cpp`) — ce qui est CÂBLÉ
Config déjà correcte et alignée :
- `n_threads=4`, `flash_attn=ENABLED`, `n_batch=512`, sampler **greedy**.
- Thinking OFF déterministe (ChatML + `<think></think>` vide injecté) → pas de ramble.
- API : `load(path,nCtx) → generate(h,sys,usr,maxTok) → reset(h) / free(h)`.
- **`n_gpu_layers = 0` → tout CPU** (pas de HTP). Choix après le ping-pong ngl99 (decode 0.2 t/s).

## Décisions (vérifiées 27/05, batterie 90%, device froid)
1. **KV = f16 (RÉSOLU, corrigé dans le JNI).** Mesuré : decode q35-lmq4 f16=**10.9** vs q8_0=**6.5**
   (−40%, idem à d=512). Le déquant KV en flash-attn coûte plus que le BW épargné. `type_k/v`
   repassé en `GGML_TYPE_F16`. → **rebuild `libkazeia_engine.so` avant de shipper** (le .so livré
   contient encore l'ancien q8_0). q8_0 seulement si OOM KV en très long contexte.
2. **Prefill : CPU-only vs HTP (à toi).** Le JNI est CPU-only (`ngl0`) → prefill **14 t/s** (t4).
   Le HTP fait **189 t/s** avec q35-lmq4 (≈2× le Q4_0=98 : ses embeds Q4 restent sur NPU au lieu de
   retomber CPU). Câbler le prefill HTP vaut donc le coup (prompt 500 tok : ~2,6 s HTP vs ~35 s CPU).
   Obstacle : ping-pong du mono-contexte ngl99 (decode GDN rebondit NPU↔CPU = 0,2 t/s). Vrai fix =
   2 contextes (prefill HTP → transfert d'état → decode CPU ngl0) ou état partagé. **CPU-only suffit
   pour des tours courts ; câbler HTP si prompts longs / RAG.**

## Perf (sains, 27/05, device froid)
| | prefill | decode | RAM |
|---|--:|--:|--:|
| q35-lmq4 — JNI actuel (CPU-only) | 14 (CPU t4) | **10.9** (t4+fa, KV f16) | 2.4 GB |
| q35-lmq4 — capacité HTP (si câblé) | **189** | — | +~3.3 ION |
| dense Qwen3-4B (repli) | 98 HTP / ~14 CPU | 11.7 | 2.2 GB |

## Système (prompt) — `system_fr.txt` fourni
Inclut les garde-fous (3114, pas de prescription) + 2 correctifs issus de l'éval :
tutoiement constant, et « ne présume pas du pire, fais préciser » (le modèle lisait
« le départ de ma fille » comme un décès). À passer tel quel en `sys` de `generate()`.

## Paquet à intégrer
- `lib/*.so` → `app/src/main/jniLibs/arm64-v8a/` (libkazeia_engine.so **statique** + ggml/htp ;
  htp-v79 = celui de cette session, fp16 derrière env `KZ_F16` OFF par défaut = comportement inchangé).
- `jni/kazeia_engine_jni.cpp` + `jni/EngineLlmEngine.kt` + `include/` → projet app.
- `q35-lmq4.gguf` → external storage (2.38 GB, hors git ; le pousser ou le reproduire, cf MODELS.md).
- `./package.sh` réassemble `lib/` depuis le build `ql/b` + recopie le prompt.

## Détails
INTEGRATION.md (build/CMake), MODELS.md (modèle + recette), PERF.md (mesures+leviers morts),
PITFALLS.md (pièges vécus), STATUS.md (limites). Verdict qualité : `../eval/VERDICT.md`.