Early report running it on a DGX Spark, 4 concurrent @ 256k bf16 with SSD offload

#31
by sleepyeldrazi - opened

Using a hacked together version of llama.cpp from unsloth's pr and adapted https://github.com/ggml-org/llama.cpp/commit/b591584708a6d4fff43c08cb89809e88b389cb08 for ssd PLE offload on CUDA, this is running with 4 concurrent, the IQ4_XS quant, 1M total ctx (4x256k, full precision).

image

prefill seems about 35-40% worse than if fully in memory, but ram gains allow a lot more ctx. I'm not publishing any code, as it was entirely written by glm-5.3-flash, so waiting for an 'official' release would be best, but this is a small 'sneak-peak' if you will at what's possible.

Single stream is, at least in low ctx (I haven't yet tested something long) in the 25-30 t/s range.

There seems to be an odd behaviour, at least in this experimental build, where even without MTP the generation speed went up a little after a while. Maybe an ssd warm cache thing, but each slot was ~11 t/s early and eventually got to ~13 t/s . Excited for a verified PR to llama.cpp, this model seems very useable

sleepyeldrazi changed discussion title from Early report running it on a DGX Spark to Early report running it on a DGX Spark, 4 concurrent @ 256k bf16
sleepyeldrazi changed discussion title from Early report running it on a DGX Spark, 4 concurrent @ 256k bf16 to Early report running it on a DGX Spark, 4 concurrent @ 256k bf16 with SSD offload

What is the profile speed?

I assume you mean prefill, it's between 300 and 400 t/s when I read engrams from the ssd, 500-600 when the whole model is in memory. To be clear, it is non-optimized and just a hacky build, there might be small improvements, but it's still a big model so I don't expect massive changes.

It shows I'm getting 25-30 tokens/sec on a single 256k context at iq4.

Now to try to add concurrency, honestly I just assumed it was a no go but seems it's worth a shot!

Preffill is terrible

Sign up or log in to comment