Summary
The llama.cpp (GGUF / AMD-Vulkan, kite4) engine does not emit per-token logprobs in the streaming chat path. Every GGUF model in the battery failed the logprobs-parity test with top_logprobs requested, while the same request shape works on the MLX engine.
Evidence (live, dev, 2026-06-23 battery)
logprobs-parity failed on all 5 GGUF models across both llama.cpp cells:
- gguf-llama-cpp:
Llama-3.2-1B-Instruct-GGUF
- gguf-big:
Qwen2.5-7B-Instruct-GGUF, Qwen3-Coder-30B-A3B-Instruct-GGUF, Llama-3.3-70B-Instruct-GGUF, openai_gpt-oss-120b-GGUF
Each: Expected per-token logprobs but the stream returned none, output empty for that test. The other tests (concise-factual, ordered-integers, tool-call-path) passed on the same models, so generation and tool-calling are fine; only logprobs are missing.
Scope / likely cause
logprobs was part of the AMD v1 llama.cpp capability-parity work, so this is probably a streaming-specific gap: the non-streaming path may attach logprobs while the SSE/streaming path drops them (or logprobs=true / top_logprobs is not being threaded into the llama-cpp-python streaming call, or the per-chunk choices[].logprobs.content is not populated). The harness reads logprobs at the OpenAI-standard choices[0].logprobs.content location, which MLX populates.
Suggested next step
Confirm whether non-streaming /bench/chat/completions returns logprobs for a GGUF model; if it does and streaming does not, fix the streaming emitter to carry per-token logprobs (and top_logprobs alternatives) the same way MLX does.
Impact
Any logprobs-dependent client feature (token confidence, MTP acceptance analysis, structured-output scoring) is unavailable on AMD/llama.cpp nodes, silently returning no logprobs rather than erroring.
Summary
The llama.cpp (GGUF / AMD-Vulkan, kite4) engine does not emit per-token logprobs in the streaming chat path. Every GGUF model in the battery failed the
logprobs-paritytest withtop_logprobsrequested, while the same request shape works on the MLX engine.Evidence (live, dev, 2026-06-23 battery)
logprobs-parityfailed on all 5 GGUF models across both llama.cpp cells:Llama-3.2-1B-Instruct-GGUFQwen2.5-7B-Instruct-GGUF,Qwen3-Coder-30B-A3B-Instruct-GGUF,Llama-3.3-70B-Instruct-GGUF,openai_gpt-oss-120b-GGUFEach:
Expected per-token logprobs but the stream returned none, output empty for that test. The other tests (concise-factual, ordered-integers, tool-call-path) passed on the same models, so generation and tool-calling are fine; only logprobs are missing.Scope / likely cause
logprobswas part of the AMD v1 llama.cpp capability-parity work, so this is probably a streaming-specific gap: the non-streaming path may attach logprobs while the SSE/streaming path drops them (orlogprobs=true/top_logprobsis not being threaded into the llama-cpp-python streaming call, or the per-chunkchoices[].logprobs.contentis not populated). The harness reads logprobs at the OpenAI-standardchoices[0].logprobs.contentlocation, which MLX populates.Suggested next step
Confirm whether non-streaming
/bench/chat/completionsreturns logprobs for a GGUF model; if it does and streaming does not, fix the streaming emitter to carry per-token logprobs (andtop_logprobsalternatives) the same way MLX does.Impact
Any logprobs-dependent client feature (token confidence, MTP acceptance analysis, structured-output scoring) is unavailable on AMD/llama.cpp nodes, silently returning no logprobs rather than erroring.