i am running stepfun's new step 3.7 flash on a dgx spark right now. 198b vision model, on a box that sits on a desk. here's how to save yourself about 3 hours of head scratching getting it loaded, because i already did the head scratching for you. the official README tells you you need stepfun's own llama.cpp fork. you don't, mainline ggml-org runs it fine, vision and all, at 64k. don't burn an hour building a fork just to find out the model loads without it. this is the one that'll actually eat your evening: the model is 104gb of your ~121gb unified pool, and the spark has no swap. ask for too much context and it doesn't crash clean, it silently thrashes, the kernel evicts model pages and re-reads them from disk in a loop while you stare at "loading" forever. the tell is read_bytes. if it climbs past the 104gb model size and keeps going while the process is pinned at 99% memory with no log progress, it's wedged. kill it, it won't recover on its own. with the vision projector loaded on a q8 kv cache, 64k is your ceiling on a 128gb box, push past it and it thrashes in the clip loader, the model plus KV plus vision buffers all fighting over the ~17gb you have left. want the full 256k context? drop vision and switch to a q4 kv cache, then it fits, 114 of 121gb. that's the trade their README doesn't spell out: the big context is real, it's just q4 cache, text-only. and it's a reasoning model. ask it something, if you get a blank reply, you didn't break it, you capped max_tokens too low and it spent the whole budget thinking. the answer's sitting in reasoning_content. give it room. that's the 3 hours. exact working flags and the weights in the reply.