Step-3.7-Flash is supported in community Docker on DGX Spark!

The Community Docker has been updated with support for StepFun Step 3.7 Flash multimodal model.

The model requires at least two Sparks in a cluster.

Both FP8 and NVFP4 checkpoints are supported, however NVFP4 is recommended due to memory constraints.

To run the model, follow the instructions below.

Update from the repo and build a fresh container first:

git pull
./build-and-copy.sh --cleanup -c

To run NVFP4 version:
Download the model:

./hf-download.sh stepfun-ai/Step-3.7-Flash-NVFP4 -c

Run:

./run-recipe.sh step-3.7-flash-nvfp4 --no-ray

To run FP8 version:
Download the model:

./hf-download.sh stepfun-ai/Step-3.7-Flash-FP8 -c

Run:

./run-recipe.sh step-3.7-flash-fp8 --no-ray

Please note that --no-ray is required for FP8 to fit with full context!

HuggingFace model card: stepfun-ai/Step-3.7-Flash-NVFP4 · Hugging Face

Don’t forget sparkrun ;-)

$ sparkrun run @eugr/step-3.7-flash-nvfp4

Waiting on the DS4 vllm build. The model is very good for its size. In the mean time I’m loading StepFun this weekend and will bench it.

Lets go @eugr_nv day 0 support on the DGX Spark

I remain really impressed by Step-3.5-Flash and am excited to see 3.7!

Single Spark users can run the capable IQ4_XS quant using llama.cpp - full context definitely works text-only, adding vision may cut down KV cache a little. Sweet spot is definitely 2 Sparks.

thanks egur , Day 0 Support

Built fresh container images, downloaded the model, tried to launch the FP8 recipe and when I launch the cluster it just fails on both nodes:

Traceback (most recent call last):
  File "/usr/local/bin/vllm", line 10, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/local/lib/python3.12/dist-packages/vllm/entrypoints/cli/main.py", line 18, in main
    import vllm.entrypoints.cli.benchmark.main
  File "/usr/local/lib/python3.12/dist-packages/vllm/entrypoints/cli/benchmark/main.py", line 10, in <module>
    from vllm.entrypoints.utils import VLLM_SUBCMD_PARSER_EPILOG
  File "/usr/local/lib/python3.12/dist-packages/vllm/entrypoints/utils.py", line 20, in <module>
    from vllm.engine.arg_utils import EngineArgs
  File "/usr/local/lib/python3.12/dist-packages/vllm/engine/arg_utils.py", line 35, in <module>
    from vllm.config import (
  File "/usr/local/lib/python3.12/dist-packages/vllm/config/__init__.py", line 6, in <module>
    from vllm.config.compilation import (
  File "/usr/local/lib/python3.12/dist-packages/vllm/config/compilation.py", line 22, in <module>
    from vllm.platforms import current_platform
  File "/usr/local/lib/python3.12/dist-packages/vllm/platforms/__init__.py", line 278, in __getattr__
    _current_platform = resolve_obj_by_qualname(platform_cls_qualname)()
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/dist-packages/vllm/utils/import_utils.py", line 109, in resolve_obj_by_qualname
    module = importlib.import_module(module_name)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/importlib/__init__.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/dist-packages/vllm/platforms/cuda.py", line 21, in <module>
    import vllm._C  # noqa
    ^^^^^^^^^^^^^^
ImportError: libtorch_cuda.so: cannot open shared object file: No such file or directory

Do the published 3 day old wheels have the vLLM patches as well? The vLLM repo only had [Model]Support Step-3.7-Flash (#43859) merge in a few hours ago.

No, the recipe contains a mod with a patch that can be applied to the currently published wheels.

If anyone has this issue, please rebuild with ./build-and-copy.sh --cleanup -c

I’ve changed the way the version checks work to avoid rate limit errors with GitHub APIs, so if you already had flashinfer wheels it may not pick it up automatically.

Yeah I always build with --cleanup, didn’t help.
It looks like something pulls in torch cpu, so I just installed it back in the Dockerfile:

+RUN --mount=type=cache,id=uv-cache,target=/root/.cache/uv \
+     uv pip install --reinstall torch==2.11.0 torchvision torchaudio triton --index-url https://download.pytorch.org/whl/cu130

Also the KV cache in the FP8 recipe doesn’t seem to fit either.
I bumped it up to my max of gpu_memory_utilization_gb: 111.0 and it still wasn’t happy:

(EngineCore pid=136) ValueError: To serve at least one request with the model’s max seq len (262144), (6.18 GiB KV cache is needed, which is larger than the available KV cache memory (5.45 GiB). Based on the available memory, the estimated maximum model length is 230336. Try increasing gpu_memory_utilization or gpu_memory_utilization_gb, or decreasing max_model_len when initializing the engine (gpu_memory_utilization also controls CPU memory on the CPU backend). See Conserving Memory - vLLM for more details.

Sorry, my bad, used NVFP4 recipe as a basis for FP8 and forgot to include fp8 cache and limit max-num-seqs to 2. Pushed an update to the repo.

Just FYI this does not fix it - same exact issue.

This is weird, maybe pypi cache related - I will look into it

I’ve just merged a fix, please pull from the repo and rebuild the container from wheels (./build-and-copy.sh -c) - it should work now.

If anyone has already launched this model, please share the results of the token generation rate per second.

Thank you for the sparkrun! Was always wondering if there is a way to pass “–no-ray” arg when launching through sparkrun? Thank you

Output from quick run of tool-eval-bench (h/t @serapis):

2-node cluster using the @eugr/step-3.7-flash-nvfp4 sparkrun recipe.

tg seems a bit low for the model of this size? I wonder if FP8 will be not slower. @eugr_nv Do you happen to know if we should expect any tangible NVFP4 decode performance increase when all sm120 PRs related to nvfp4 support get merged?

I can confirm this speed on nvfp4 version

For FP8 version, it’s around 18-20 for single session depends on context length.