DGX Spark, 128GB: is anything actually worth switching to from Qwen3.5-122B-A10B?

Do the bandwidth arithmetic first, because it usually settles this before quality even comes up.

Token generation on this class of machine is memory-bound. Your ceiling is roughly bandwidth divided by bytes read per token, and on a mixture-of-experts model the bytes read per token track the active parameters, not the total.

So, back of envelope: 10B active at 4 bits per weight is on the order of 5GB read per token, giving a theoretical ceiling somewhere around 50 tokens/sec at 273 GB/s. 13B active at 2.5 bits per weight is on the order of 4GB, so a similar ceiling. Real throughput lands well below both — there is router overhead, the shared expert, attention, and the OS is using that same memory — but the point stands: the bigger model at the lower quant does not buy you speed.

Which means the trade is: same speed class, worse weights, more memory pressure. That is not an upgrade, that is a sidegrade with a downside.

On the quant side, two things that get conflated.

First: dropping below roughly 3 bits per weight tends to hurt more on a model whose experts are already small. You are compressing something that has less redundancy to give. A 10B-active model at 2.5bpw is a rougher ride than a dense model of the same file size would be.

Second, and more annoying: "Q2" is not a standard. Different quantisation families keep different tensors at different precisions, so two files both labelled two-bit can be materially different objects. The advertised number is an average across a layout you cannot see from the filename.

So the honest answer to "is Q2 usable" is: for that specific file, from that specific publisher, on your specific tasks. Nobody can answer it for you from the label alone.

The genuine upgrade on a machine like that is usually not a bigger model. It is prefix caching, batching, and keeping the model you already like at a higher precision.

The thing that makes 128GB of coherent unified memory interesting is that you can hold a long working context and a decent model at once without shuffling anything across a PCIe bus. Spending that headroom on parameters you then have to crush down to two bits gives back exactly the advantage you paid for.

Build the harness and stop asking. It is half a day and then you never have this conversation again.

Twenty prompts drawn from work you actually did. Fixed seeds where the runtime lets you. Score them pass/fail by hand once so you know what you are measuring, then automate the re-run. Record tokens/sec and peak memory alongside the score, because on this box those constrain the decision as much as quality does.

And the obvious shortcut: get the model you already have to write the harness. Loading two models in sequence and diffing their outputs against a rubric is exactly the kind of tedious plumbing it is good at.

You have 128GB. 284B at around two and a half bits is somewhere near 85-90GB of weights. It fits. Just run it and see.

Decide on capability before you decide on scores. Qwen3.5 is a vision-language model — if any part of your workflow involves images, diagrams or screenshots, the comparison is over before the benchmarks load and you keep what you have.

Same for context: if you genuinely rely on very long inputs, the model that holds them at a usable speed on your bandwidth wins regardless of how it ranks on a coding eval.