Fix PocketTTS Mimi decoder CPU crash: restore context-tensor backing removed in d98123e

[adambenhassen]

Problem

On --backend cpu, every PocketTTS synthesis aborts with:

ggml-backend.cpp:327: GGML_ASSERT(buf != NULL && "tensor buffer not set") failed

The flow-LM stage runs fine; the crash is on entry to the Mimi codec decoder, deterministically, in both the server and the CLI. CUDA is unaffected.

Repro

scripts/build_linux.sh --backend cpu --target audiocpp_cli
audiocpp_cli --task tts --family pocket_tts --model <pocket-tts> --backend cpu \
  --load-option language=english --voice-id alba --text "hi" --out out.wav
# -> GGML_ASSERT abort on main; valid 24 kHz WAV with this PR

Cause

d98123e ("Harden PocketTTS Mimi decoder graph allocation") removed every ggml_backend_alloc_ctx_tensors(ggml_ctx_, backend_) call in mimi_decoder.cpp, leaving allocation to ggml_gallocr_alloc_graph alone. That call gave the decoder's context tensors (graph inputs plus persistent state: KV-cache prefixes, positions, attention mask, latents) stable lifetime-long backend buffers. The CPU path uses a persistent graph plan and repeated run() writes into those tensors; gallocr's graph-scoped allocation leaves them unbacked, so on CPU they hit buffer == NULL. CUDA's path kept them backed, hiding the regression.

Fix

Restore ggml_backend_alloc_ctx_tensors (buffer member + destructor free) in the 5 runtime constructors, while keeping d98123e's gallocr null-checks and release_partial_graph_runtime helper. +25/-0, no deletions.

Verification

CPU build; PocketTTS-100M english; --backend cpu, 4 threads on an Intel N100: valid 24 kHz mono WAV via both CLI and the OpenAI-compatible server (POST /v1/audio/speech), 3 back-to-back requests, no crash, RTF ~0.7.

---

UPDATE:

• a590f43: gated the restored ggml_backend_alloc_ctx_tensors behind core::is_host_backend(backend_) in all 5 runtime constructors, per review. CUDA/Metal/Vulkan keep the gallocr-only allocation from d98123e, so the pocket_tts: failed CUDA alloc in MimiDecoder::decode aborts the whole server (GGML_ASSERT) — same class as the voice-prep issue fixed in 1627694 #55 VRAM reduction is preserved; only the CPU path (which uses the persistent graph plan) gets the context-tensor backing. Rebuilt and re-verified on CPU.
• c215af6: failure-path hardening on top: ggml_backend_alloc_ctx_tensors result is now null-checked (immediate runtime_error instead of a later GGML_ASSERT abort), and release_partial_graph_runtime also frees the params buffer so a constructor throw after gallocr failure no longer leaks it.

[0xShug0]

Thank you @adambenhassen!

I validated the PR locally. The CPU issue is real, and this patch does fix the crash.

One concern: the restored ggml_backend_alloc_ctx_tensors(...) path also runs on CUDA, which causes the VRAM usage regression. d98123e was introduced to reduce the memory usage on CUDA #55

So I think the extra context tensor backing should be gated to CPU only. That should keep the CPU fix while avoiding a CUDA peak-memory regression.

[0xShug0]

@adambenhassen Let me know if the PR is ready (just testing and see updates...).

[adambenhassen]

@adambenhassen Let me know if the PR is ready (just testing and see updates...).

Ready! Gating done in a590f43: context-tensor backing now only runs when core::is_host_backend(backend_), so CUDA/Metal/Vulkan keep the gallocr-only allocation.

Also, while testing the failure paths I found a small leak: if graph allocation throws in a constructor, the destructor never runs and the params buffer leaked. c215af6 fixes that (cleanup helper now frees it) plus null-checks the alloc so it fails with a clear error instead of a later GGML_ASSERT. Verified with a standalone harness replaying the failure path 200x: peak RSS 490MB before vs 76 MB after.

If CUDA peak VRAM looks good on your side, should be all set 👍

[0xShug0]

@adambenhassen Thanks! Tested and worked well. Merged.