chantier B TTS #9: CP weights f16 conservés, CP -52% cumulé, bit-exact
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>
1203d7ce5d