3.6 KiB

Raw Blame History

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)

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.
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.

3.6 KiB Raw Blame History Unescape Escape