1203d7ce5d
cp_load: les tenseurs F16 du gguf restent F16 en mémoire (sauf *_norm.weight qui restent F32 — ggml_mul exige même type que xn). ggml_mul_mat gère mul_mat(W_f16, x_f32) -> out_f32 nativement, donc aucun changement dans cp_forward_cached_step / cp_forward_lastpos. Mesure tablette Pad3 (KZTTS_CP_CACHE=1, seed=42, 31 frames): baseline f32 oracle : CP 227.9 ms/frame, RTF 4.99 baseline f32 cached : CP 137.8 ms/frame, RTF 3.45 f16 weights oracle : CP 223.8 ms/frame, RTF 4.58 (peu de gain : oracle compute-heavy) f16 weights cached : CP 108.3 ms/frame, RTF 3.07 (-52% CP cumulé vs baseline) codes_ref.bin == codes_cache.bin (cmp) + out_*.wav md5 identiques Toujours BIT-EXACT contre l'oracle f32 : les sums f16->f32 dans mul_mat restent suffisamment stables pour que les argmax post-softmax tombent sur les mêmes indices. Bonus inattendu. Restants pour <1 : - Decoder RTF 1.33 dominant (~50% du temps total maintenant) - Fusion graphes CP multi-step : incertain, ~lourd Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .claude | ||
| dist | ||
| docs | ||
| eval | ||
| ql@6e0edba837 | ||
| .gitignore | ||
| CHANTIER_HMX_DENSE.md | ||
| CLAUDE.md | ||
| RAPPORT_RD.md | ||
| c4.sh | ||
| casc.sh | ||
| casc2.sh | ||
| casc3.sh | ||
| cascade_test.sh | ||
| cf.sh | ||
| qcmp.sh | ||
| spk.sh | ||