I’ve pushed llama.cpp pretty far for Qwen3.8-Flash-Next — is there any reason not to move to vLLM for 200K+ context?

I'm currently running Qwen3.8-Flash-Next on a CMP 170HX 64GB + RTX 3090 24GB, with 80GB system RAM.

With llama.cpp I've already spent quite a bit of time tuning it: layer split across the two GPUs, PLE on CPU, q8 KV, Flash Attention, detached MTP draft on the 170HX, and some custom MTP/runtime work.

My current results are roughly:

Short context: ~900 tok/s prefill, ~70–80 tok/s decode with MTP 100K: ~600 tok/s cumulative prefill 140K: ~520 tok/s cumulative prefill 262K: ~355 tok/s cumulative prefill, only ~17–18 tok/s decode

So short-context performance is actually pretty good, but QSA performance falls off a cliff as context grows. The current llama.cpp QSA implementation still appears to do top-k selection followed by effectively dense/full-KV work, which seems to defeat much of the point of QSA.

I've seen the recent sparse-gather experiments/forks, so I'm still testing llama.cpp-side fixes, but I'm starting to wonder whether I'm just fighting the wrong inference engine.

For someone who actually wants to use 100K–260K contexts for coding/agent workloads, is vLLM basically the only practical answer right now?

My main complication is the asymmetric GPUs: 64GB + 24GB, so normal TP in vLLM isn't ideal. I've also been looking at vllm-backport, AWQ W4A16, selective expert CPU/UVA offload, and NVMe/mmap PLE as possible ways to run Flash-Next primarily on the 170HX.

I'm interested in anything that can materially improve long-context PP and TG without pruning the model: llama.cpp forks/patches, SGLang, custom vLLM builds, asymmetric placement tricks, etc.

Basically: am I missing a good llama.cpp path here, or is moving to vLLM the sensible thing to do?