Qwen 3.8 27B on a 5060 Ti: 64 t/s Local Coding and a Car Configurator That Actually Works

TL;DR: Qwen 3.8 27B Dense is the first local Qwen model on my RTX 5060 Ti where the creative-code benchmark ended with a finished, interactive result rather than an interesting near miss. With the IQ3_XXS GGUF and llama.cpp’s built-in Multi-Token Prediction (MTP), it reached 63.89 tok/s at 4K, 45.48 tok/s at 32K, and 39.06 tok/s at 64K. It also handled a real 96K-token active prompt. The standout result was a one-shot sports-car configurator: paint swatches work, the wheels switch and spin, headlights toggle, and the showroom rotates.

The previous creative-code tests had a familiar failure mode: a model would produce something ambitious, but the generated program stopped mid-file or needed a repair pass before it could be shown to anyone. This time I made completion an explicit constraint, then checked the result in headless Chromium. The payoff is much more concrete than a token-per-second number.

The Test That Matters: Does It Ship a Working Thing?

I gave Qwen 3.8 one self-contained prompt: no external assets, a side-view car, paint swatches, wheel-style buttons, a headlight toggle, animated showroom, responsive layout, and a request to prioritize a finished source file over extra detail.

It returned a complete 8.9 KB HTML document in 61.83 seconds, at 59.42 decode tok/s. The output ended normally, not at the token limit. In Chromium it rendered with the requested control elements and animation hooks; manually using it is the better verification: the paint changes, the wheel style changes, the headlights toggle, and clicking the car spins the wheels.

That distinction matters. A broad Formula 1 canvas prompt still hit a 4,096-token cap halfway through its JavaScript. Qwen 3.8 is not magic about output length. But a concise, completion-oriented prompt turned the same one-shot setup into a small, working app.

One-shot task	Profile	Result
Animated Formula 1 canvas scene	Thinking off, MTP n=3	4,023 tokens at 57.33 tok/s; stopped mid-JavaScript at the output cap
Interactive sports-car configurator	Thinking off, MTP n=3	3,659 tokens at 59.42 tok/s; completed, rendered, and interactive

The practical lesson is not “make prompts shorter.” It is: if the deliverable must run in one pass, state the implementation budget and completion priority. That gives the model a useful trade-off instead of inviting it to spend all its output budget on decorative complexity.

The Speed Result: MTP Is the Default, N-gram Is Not

This was measured on an RTX 5060 Ti 16 GB, using Qwen 3.8 27B UD-IQ3_XXS, current upstream llama.cpp build ad1de39e0, full GPU offload, Flash Attention, q4_0 K/V cache, and one parallel slot. Each short-context value is the median of five post-warm-up responses. The 32K and 64K values use the same retained long prefix and five matched responses per configuration.

Active context	Baseline	MTP n=2	MTP n=3	Best result
4K	29.18 tok/s	56.91 tok/s	63.89 tok/s	n=3, +119.0%
32K	23.62 tok/s	42.53 tok/s	45.48 tok/s	n=3, +92.5%
64K	19.77 tok/s	34.95 tok/s	39.06 tok/s	n=3, +97.6%

Depth 3 won every comparison. Depth 2 remains useful if I want its slightly higher acceptance rate and around 150 MiB more VRAM margin at long contexts, but it is not the throughput winner.

I also tested ngram-mod using its current upstream options. It came in at 29.66 tok/s versus 29.17 tok/s baseline on a 512-token Python-module workload: only +1.7%. That is a useful correction to an old assumption from prior Qwen tests. On this model and runtime, MTP is the normal coding preset; n-gram is not a substitute.

Context: 96K Is Real, 131K Is Only a Capacity Setting

The 16 GB card can start a server configured for 131,072 tokens, but a startup value is not an active-context benchmark. The meaningful test was a non-cached 96,033-token prompt plus a response: it completed at 617.73 prompt tok/s and 36.74 decode tok/s, consuming 15,732 MiB after the request.

So 96K is genuinely usable, but it is a near-ceiling mode with little room for other GPU work or a second slot. My practical policy is straightforward:

• 32K: comfortable default for coding-agent sessions.
• 64K: still responsive and a good choice for large repositories.
• 96K: use when the task really needs it; expect little VRAM slack.
• 131K: do not treat the server flag as a promise of 131K active context.

Thinking: Powerful Is Not the Same as Productive

Qwen 3.8’s default reasoning behavior attracted a lot of discussion because it can deliberate for a very long time. The concern was visible in the controlled visual-code test. With a 2,048-token output cap, thinking-off generated 5,428 characters of final HTML. Medium and Xhigh generated only reasoning content—6,453 and 8,298 characters respectively—and no final code.

That does not mean those modes are bad. It means they need an explicit task and budget. For normal interactive coding, I start with thinking disabled. For a difficult debugging or design task, I can opt into a thinking profile, give it enough output room, and decide whether preserving that reasoning is worth the context cost.

One small surprise: on the fixed MTP coding workload, temperature 0.6 and 1.0 were effectively tied (63.78 versus 64.58 tok/s). The popular rule that a higher temperature must hurt MTP acceptance did not reproduce here. I would choose sampling for output quality and verify it on the actual workload, not cargo-cult a single temperature.

Copy-Paste Configuration

The complete flag reference is in Qwen 3.8 27B MTP Server (RTX 5060 Ti). This is the short version:

llama-server \
  -m /path/to/Qwen3.8-27B-UD-IQ3_XXS.gguf \
  -ngl 99 --ctx-size 98304 \
  -fa on -ctk q4_0 -ctv q4_0 \
  --parallel 1 \
  --spec-type draft-mtp --spec-draft-n-max 3 \
  --jinja \
  --host 0.0.0.0 --port 11433

For ordinary coding or visual HTML, send the request-level template option and concise sampling profile:

{
  "temperature": 0.7,
  "top_p": 0.8,
  "top_k": 20,
  "chat_template_kwargs": { "enable_thinking": false }
}

The one thing I would not do is silently replace the existing Qwen 3.6 service yet. The new model has earned a dedicated local endpoint and a final coding-agent validation first. That is the next step: connect this measured profile to OpenCode, give it one bounded task, and judge completion, tool use, and total time—not just the pretty car.