common : do not propagate n_seq_decision to speculative (MTP) context

[akudo7]

Hi Anirban —

I've been running your parallel-decision work in production: the
POST /v1/decision endpoint on Qwen3.8-27B (2x RTX 3090, fully local),
plugged into a LangGraphJS workflow engine. For closed decision tasks
(routing / classification / scoring) it has been a structural fix —
~18-20x faster per decision vs json_mode, zero output tokens, and it
eliminated three silent data-loss paths we were hitting in production.

This PR: with MTP speculative decoding (--spec-type draft-mtp),
the decision path propagates n_seq_decision into the speculative
context and hits an assert. A one-line guard fixes it. Verified with a
production MTP config: MTP + /v1/decision coexist, no assert crash.

Repro

Before this patch, the server does not start with MTP + decision sequences:

./build/bin/llama-server -m <mtp-capable model>.gguf -ngl 99 -c 32768 \
  --decision-seqs 8 --spec-type draft-mtp --spec-draft-n-max 2 --port 8096

-> dies at startup on the n_outputs_max <= cparams.n_outputs_max assert in
common/speculative.cpp — common_base_params_to_speculative propagates
n_seq_max = n_parallel + n_seq_decision into the MTP draft context.

After: the same command starts, and decisions work next to MTP:

curl http://localhost:8096/v1/decision -H "Content-Type: application/json" -d '{
  "model": "any",
  "schema": {"ok": {"type": "boolean"}},
  "contexts": ["ping"]
}'

Verified on master e85e15c (CPU build, Qwen3.8-27B-UD-Q4_K_XL): MTP draft
context created, clear inputs score as expected (p=0.9991 / 0.9998,
ambiguous 0.7908), grid number field stays on-grid.

Separately I opened #14 with a hybrid decision extension (closed
fields + one bounded open field in a single call) — feel free to close
it if it is not wanted.

The question before I go further: are you interested in upstreaming
/v1/decision to ggml-org/llama.cpp? Your patches are already rebased
onto current master (clean apply, compile + functional verification
pass) — happy to prepare a joint PR with proper credit, or you can drive
and I'll support. If not, no pressure: we'll keep running the fork and
contribute fixes here. I'm also writing up the production experience as
an article (links to your repo).

Either way, thanks for the work — it is doing real production duty.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 0387f35f-59bd-43b9-baec-17ce68cfa183

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[akudo7]

Hi @thecodacus — a gentle nudge on this one (and on #14). We've been running the parallel-decision fork in production since late September, and this one-line MTP guard is the only change we need to keep it tracking your newer commits.

No pressure at all — even a quick "not interested" would be enough for us to plan (we'd just keep maintaining the fork privately). If you are open to it, the patch also rebases cleanly onto current ggml-org master (verified 2026-09-25), so a joint upstream PR is an option too.

Thanks!