UNLISTED / BENCH NOTES

Qwen3.8-27B on a Split Pascal + Ampere Pair

Raw numbers, measured 14 August 2026. No write-up, just the run.

What was measured

Model	Qwen3.8-27B, Unsloth Dynamic `UD-Q5_K_XL`
Reported size	18.82 GiB, 27.32 B parameters
Architecture	`qwen35`, dense (not mixture of experts)
Native context	262144
License	Apache 2.0
GPUs	Tesla P100 16 GB (compute 6.0) + RTX 3060 12 GB (compute 8.6)
Combined VRAM	28.2 GB usable
Settings	all layers on GPU, flash attention on, no CPU offload

Dense means every parameter is used for every token. A mixture of experts model only wakes up a small slice of itself per token. That one difference explains most of what follows.

Results

Test	Result
Prompt processing (pp512)	198.47 ± 0.12 tok/s
Token generation (tg128)	12.07 ± 0.00 tok/s

How the model split across the two cards

Card	Benchmark run	As a live server, 32k context
RTX 3060	8,763 MiB	9,059 MiB
Tesla P100	11,171 MiB	11,979 MiB
Total	19.9 GB	21.0 GB

Context for the numbers

A 35B mixture of experts model with roughly 3B active parameters reaches about 62 tok/s on this same pair of cards. This dense 27B reaches 12. That is the dense penalty, and it is about five times.
Prompt processing stays healthy at 198 tok/s because that work is limited by compute, not by memory bandwidth. Generation is the opposite.
A different 27B model squeezed down to roughly 2 bits runs at about 10 tok/s on a 16 GB Apple M2 Pro. So this setup is a little faster while keeping a far better quantization.
No 4 bit build of a dense 27B fits inside 16 GB. The 4 bit file is 17.11 GB. Two cards, or one big card, is the honest requirement.

Turning the thinking off, and why it can backfire

This model reasons before it answers. The reasoning comes back in its own field, separate from the reply. You can switch it off per request. The obvious guess is that switching it off always makes things faster. That guess is wrong.

Task	Mode	Seconds	Tokens	Reasoning chars	Answer chars
Write a haiku	thinking	23.74	268	823	71
Write a haiku	off	1.64	17	0	59
Define an acronym	thinking	6.16	59	202	43
Define an acronym	off	1.54	10	0	43
Arithmetic word problem	thinking	105.86	1248	3361	6
Arithmetic word problem	off	169.01	1994	0	6033

Task	Speed change with thinking off	Token change
Write a haiku	14.5x faster	15.8x fewer
Define an acronym	4.0x faster	5.9x fewer
Arithmetic word problem	0.6x, meaning slower	0.6x, meaning more

On the two easy tasks, switching thinking off is a big win. On the task that actually needed reasoning it made things worse. The model did not stop reasoning. It moved the reasoning into the visible answer, used 60 percent more tokens, and took longer.

Look at the answer length on the last row. With thinking on, the reply was 6 characters, just the number asked for, because the working happened in the reasoning field. With thinking off, the reply was 6,033 characters of working out loud.

That is the part worth knowing if you care about context. The reasoning field is usually dropped by the client when it builds the next turn of a conversation. The answer field is not. So on reasoning heavy work, turning thinking off can grow a conversation faster rather than slower, which is the opposite of what people expect.

Rule of thumb: turn it off for lookups, formatting, and short creative output. Leave it on for anything with steps in it.

Notes

The model reports its architecture as qwen35, so a llama.cpp build from June 2026 loaded it with no source changes.
It is a reasoning model. Replies come back with a separate reasoning block before the answer, so give it a generous token budget or the reply comes back empty.
It also ships a vision tower and a separate projector file, which was not exercised here.

Measured with llama-bench, 3 repetitions per test. Hardware and software details generalized on purpose.