Deployed as requested, then verified. On the same problem 4096 and 16384
give the same correct answer, but 16384 uses 17417 tokens instead of 5325
(~6 min vs ~2 min) and spends the extra budget in a repetition loop
("Maybe it's a^2+b^2=c^2+7?" repeated) rather than converging.
The premise for raising it -- thinking was truncated, so it needs room --
did not survive measurement. Documented; the value is left at 16384 as
requested rather than reverted unilaterally.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Measured: with --predict 8192 a request sending max_tokens=9000 returned
8893 tokens (finish_reason stop), while a request sending no max_tokens was
cut at exactly 8192 (finish_reason length). The flag is a default for
clients that omit max_tokens, not a ceiling anyone can hit.
That default still matters on a -np 1 server, where an unbounded client
would fill the 128k window and block the only slot for ~50 minutes. 32768
bounds that to ~12 minutes without truncating realistic long answers, which
8192 was doing silently to any client that omits max_tokens.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Hybrid SSM+attention MoE (qwen35moe): only 10 of 40 layers use full
attention, so 128k of KV costs ~1.3 GiB. The binding constraint is the
20.6 GiB of weights against 22 GiB of VRAM, handled with --n-cpu-moe.
Two findings drive the config:
- --n-cpu-moe strips experts from the first N layers, which -sm layer
assigns to CUDA0, so CUDA1 inherits every heavy layer and OOMs at any
offload level. -ts 24,16 rebalances it.
- --threads 8 (physical cores) beats 16 by 44% on generation; the expert
matmuls are bandwidth-bound and SMT siblings only contend.
Ships ncmoe=10 (53 t/s @8k, 34 t/s @97k) over the faster ncmoe=8 to keep
~1.3 GiB spare on CUDA0, which is shared with the desktop.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DATAandClaude Opus 5