chore(vllm-cpp): bump the vllm.cpp pin to main; GGUF speculative decoding is real now

The pin sat at f384edcd while vllm.cpp main moved a long way. The ABI is
unchanged at v10 and both POD structs are field-identical to the pinned commit
(verified by diffing vllm_model_params and vllm_sampling_params across the
range), so the Go mirror needs no edit and this is a clean bump.

What it picks up matters for this backend:

- MTP speculative decoding from a GGUF target, gated end to end on GPU.
- DFlash speculative decoding with a GGUF draft AND a GGUF target.
- NVFP4 GGUF: dequant, plus a native fp4 compute path for dense and
  full-attention projections. On the 27B that closed a cross-container
  divergence entirely (the GGUF and safetensors builds of the same
  quantization run now emit identical tokens) and halved peak RSS.
- A real engine fix: the GDN speculative state gather/scatter was mis-striding
  the widened conv row, so speculation silently corrupted the target's own
  recurrent state on CPU.

Docs corrected accordingly. The section previously told users that mtp and
dflash are rejected on a .gguf target and called it a gap in the engine's GGUF
loader. That is no longer true, and leaving it would send people to safetensors
for no reason. A head-less GGUF is still refused, and the text now says so with
the actual cause.

The real-library ABI handshake was re-run against a libvllm.so built at the
exact pinned commit rather than a stale one: 43 specs pass, reported ABI 10.
make lint clean.

Signed-off-by: Ettore Di Giacinto <mudler@localai.io>
Assisted-by: Claude Code:claude-opus-5 [ClaudeCode]

backend/go/vllm-cpp/Makefile

@@ -11,7 +11,7 @@ JOBS?=$(shell nproc --ignore=1 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || e
 
 # vllm.cpp version
 VLLM_CPP_REPO?=https://github.com/mudler/vllm.cpp
-VLLM_CPP_VERSION?=f384edcd25950bdf785a17d9230f249b99bc841b
+VLLM_CPP_VERSION?=6d4fb5e7ae13eb8a30fdd3f5e8df8a3d8a83143b
 
 # The backend consumes only the stable C ABI (libvllm + include/vllm.h), so the
 # server, examples and tests of the engine are never built here.

docs/content/features/text-generation.md

@@ -978,13 +978,13 @@ defaults *on* for dense models - so write the key only when you mean to override
 > will not work regardless of checkpoint format. `ngram` needs no draft weights
 > and is not subject to this limit.
 
-> **Format limit.** `mtp` and `dflash` require a **safetensors** target and are
-> rejected at load on a `.gguf` target, with:
-> `speculative decoding requires a safetensors target checkpoint`.
-> This is a current gap in the engine's GGUF loader, not a property of the GGUF
-> format - GGUF can carry MTP weights (llama.cpp reads them as `nextn.*`
-> tensors plus a `<arch>.nextn_predict_layers` key), but vllm.cpp's GGUF path
-> does not map them yet. `ngram` works fine on GGUF.
+> **Format support.** `mtp` and `dflash` now work from a `.gguf` target as well
+> as safetensors. An MTP head is read from the GGUF's `nextn.*` tensors when the
+> file declares `<arch>.nextn_predict_layers`; a GGUF exported WITHOUT the head
+> (converted with `--no-mtp`, or predating llama.cpp's Qwen3.5 MTP support) is
+> refused at load naming that as the reason. A DFlash draft may itself be a
+> `dflash`-arch GGUF, and the target may be a GGUF too. `ngram` needs no draft
+> weights and works on any format.
 
 **MTP** (Multi-Token Prediction) uses a draft head shipped inside the target
 checkpoint's own `mtp.*` tensors, so there is no second model to download. It