Speed benchmarking 2xSpark vs 2xRTX Pro 6000

#71
by whistlercapital - opened

image

image

worth flagging for anyone reading this thread later: the 0731 weights being benchmarked here are a different model from V4.1 Flash. V4.1 Flash has no weights on the hub yet, so it will not show up in any comparison in this thread. two separate things, easy to conflate in search results.

that said, the tok/s caveat applies to both. bridgemind clocked V4.1 Flash at 344 tok/s on a lava lamp render with a 99.7% cache hit and it still finished behind fable 5.1 and gpt-6 astra, because it burns more tokens getting to the same answer. throughput is real, wall clock is not. seconds per completed task is the number that survives contact with a real workload.

and it is not flat on quality either: around 98% of astra's score overall on design work, but #4 on landing pages and #10 on dashboards and admin panels. per category breakdown if useful: https://automatio.ai/read/ai/deepseek-v4-1-flash-matches-gpt-6-astra-in-design-tests

I've been running countless optimizations across the GB10, RTX6000 and GB300 processors, including because of the speed of the model (900-1100 tok/s on the GB300 with batching/multiple agents), an incremental harness on top of an optimized model for real world tasks that layers rapid validation/verification loops. I have a large library of coding benchmark questions (not contaminated with any existing benchmark queries, for those that are publicly available), that I've created with Sol, Astra, Fable and Opus. Its a great way to see token spend efficiency vs accuracy across serving parameters.

Here are some of the variables:

  1. Runtime engine and serving stack: SGLang vs vLLM; exact venv, SGLang/vLLM/FlashInfer versions, compiled artifact set.
  2. Speculation: target-only versus DSpark; draft depth.
  3. Native reasoning mode: HIGH versus MAX; thinking template enabled.
  4. Effective sampling: temperature, top-p, top-k, seed, min-p, repetition/presence/frequency penalties.
  5. MoE execution: Marlin versus FlashInfer TRTLLM; routed-expert activation path, MXFP8 versus BF16/W4A16.
  6. Attention implementation: FlashMLA/FlashInfer route, sparse prefill on/off, DSV4 quantization path.
  7. KV and indexer cache formats: FP8 versus alternative representations; page/block size.
  8. Prefix caching: disabled cold-cache measurement versus enabled cache reuse.
  9. Concurrency and scheduling: workers, max_num_seqs, batched-token ceiling, chunked-prefill size.
  10. Context and generation ceilings: input context, output cap, near-horizon allocation.
  11. CUDA graph strategy: full/piecewise versus alternatives; capture-size ceiling.
  12. FlashInfer autotuning: enabled versus disabled.
  13. wo_a projection implementation: FP8 DeepGEMM path and its version-specific scale layout.
  14. Shared-expert execution/fusion.
  15. GPU memory reservation and resulting KV capacity.
  16. Hardware/topology: TP degree, GPU count, interconnect, and expert-parallel routing.

Getting close to an optimized conclusion and the performance on the benchmarking and real world tests are quite wide depending upon variable. Goal is to have the optimized config for multiagent tasks or have one of the frontiers orchestrate 8-12 agents at a time to offload token consumption. happy to post back here when the recursive optimizations are complete.

Sign up or log in to comment