Yes thank you! However, I had an issue with the Docker command not running to start VLLM and dying w/out any logs. Unfortunately, I have the patience of gnat, so I tried a couple of things at once then it ran. Also, I am using the .env file approach and not the setup.sh.
Thanks for the quick fixes! I will try the new version. At least the version from yesterday starts without errors. When i check the IP of the used interface in the container it shows the correct IB IP.
I don’t think you can expect significantly more speed from a dense model, even on two Sparks. The memory throughput (which defines token generation speed) on Spark is only 273 GB/s.
What quant are you using? Can you post your VLLM commandline arguments?
In any case, as a rule of thumb, max inference speed for a dense model is roughly memory_bandwidth_in_GB / model_weights_in_GB.
So, for a 70B dense model, like llama 3.3, it would be:
BF16: 273/140 = 1.95 t/s
FP8/INT8: 3.9 t/s
FP4/NVFP4/INT4: 7.8 t/s
Running this model in the cluster will not improve inference performance, and will likely make it slower due to communication overhead. It will only improve overall throughput (parallel requests) and prompt processing (as it is more compute bound than bandwidth bound).
Generally, I would avoid running anything more than 32B active parameters on Spark, as it will be just way too slow. Also, 8-bit quants generally perform at the same level as BF16 model, so there is very little reason to serve full model, use FP8 version instead (if available) or other quants (AWQ 8-bit, for instance).
The sweet spot for Spark are MOE models. Your dual Spark setup will allow you to run Qwen3-235B-A22B FP4 quant at about 12 tokens/s.
For a single Spark, gpt-oss-120b is a great choice. You will get between 40-60 tps (depending on inference engine) and decent prompt processing speed.