Misc. bug: /slots save/restore never persists the draft-model context (ctx_dft) on speculative-decoding deployments #28619

Name and Version

$ llama-server --version
version: 0.3.0-dev (build 1, commit 0f3a71b)
built with GNU 15.2.0 for Linux x86_64

Reproduced against ggml-org/llama.cpp commit 0f3a71be15af836d277c9f918adfafb45732677e.

Operating systems

Linux

Which llama.cpp modules do you know to be affected?

llama-server

Command line

llama-server \
  -m Qwen3.8-27B-UD-Q4_K_XL.gguf \
  --model-draft mtp-Qwen3.8-27B-Q8_0.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  --parallel 1 \
  -c 262144 -ctk q4_0 -ctv q4_0 -fa on \
  --slot-save-path /slot-cache

Problem description

POST /slots/{id}?action=save|restore only persists ctx_tgt (via
llama_state_seq_save_file/llama_state_seq_load_file) — on a deployment
running speculative decoding (--model-draft/--spec-type), the draft
model's own context (ctx_dft) is never captured or restored at all.

This is a separate, narrower gap from #25913 (checkpoints not persisted,
addressed by #26004): even once #26004 lands, a restored slot's draft
model only gets its state back if a checkpoint happened to already exist
at save time (checkpoints carry their own data_dft) — a short
conversation that hasn't hit its first checkpoint yet restores with an
empty draft-model KV cache and no fallback. The raw, currently-live
ctx_dft state is simply discarded on save, independent of checkpoint
existence.

Not directly observable as a crash or an error — the restore reports
success either way — but on a speculative-decoding deployment it means
the draft model silently starts cold after every restore whenever no
checkpoint happens to cover the request, undermining part of the benefit
--slot-save-path is meant to provide alongside #26004's fix.

Steps to reproduce

1. Start llama-server with a draft model (--model-draft/--spec-type)
   and --slot-save-path.
2. Send a short prompt (short enough that it completes before the first
   context checkpoint would be created) with cache_prompt: true.
3. POST /slots/0?action=save.
4. Inspect the save file: only the ctx_tgt payload
   (llama_state_seq_save_file's own format) is present; there is no
   companion draft-model state anywhere.
5. POST /slots/0?action=erase, then POST /slots/0?action=restore.
6. The restore succeeds and reports the correct token count, but
   ctx_dft was never touched — the draft model's KV cache is empty,
   identical to a slot that just came up cold, regardless of what server : preserve context checkpoints across slot save/restore #26004
   restores for ctx_tgt/checkpoints.

First bad commit

Not a regression — SLOT_SAVE/SLOT_RESTORE have never captured
ctx_dft; this predates both this report and #26004.

Relationship to other issues/PRs

• Misc. bug: /slots save/restore silently loses all prompt reuse on hybrid/recurrent models — checkpoints are never persisted #25913 / server : preserve context checkpoints across slot save/restore #26004: separate root cause (missing checkpoint persistence
  for ctx_tgt's reuse-validity check), already well covered there. This
  report is about ctx_dft specifically, which server : preserve context checkpoints across slot save/restore #26004 does not touch.
• We have a working fix (raw ctx_dft capture/restore via
  llama_state_seq_get_size_ext/get_data_ext/set_data_ext, stored as
  a companion <save-file>.dft, verified live on a production
  Vulkan/AMD-APU draft-mtp deployment) and are happy to open it as a PR,
  either standalone or as a follow-up once server : preserve context checkpoints across slot save/restore #26004 merges (to avoid
  competing for review attention on the same file/handlers at once) —
  see our comment on server : preserve context checkpoints across slot save/restore #26004 for details.