Pretty good :) but ... looping :(

#4
by jbourny - opened

I'm testing since few minutes only for now but it seems pretty good :)
I'm surprised it's super fast between each turn, the ttft is weirdly too fast, it practically replies before I even send the message :D

The only downside for now is the decoding of the filler data, which is very poor; perhaps there is a way to optimize the dflash?

Here is my tests on a single Dgx Spark:

  🔍 Engine: vLLM 0.23.1rc1.dev1353+g81f51a780.d20260721

╭──────────────────────────────────────────────────────────────────────────────────────────────────────────── 🔮 Speculative Decoding Benchmark ─────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ poolside/Laguna-S-2.1-NVFP4                                                                                                                                                                                                                                │
│ tg=128  depth=[0, 16384, 32768]  prompts=['filler', 'code', 'structured']  method=auto                                                                                                                                                                     │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Prometheus /metrics acceptance-rate counters are server-wide aggregates. If other models are serving concurrent traffic on this endpoint, per-request acceptance rate measurements will be inaccurate. For clean measurements: use a single-model server with no concurrent load.

  ✓     filler @ d0  19.2 eff t/s  19.9 stream t/s  α=7.7%  waste=92%  τ=1.2  win=15
  ✓       code @ d0  48.3 eff t/s  53.6 stream t/s  α=36.3%  waste=64%  τ=5.5  win=15
  ✓ structured @ d0  85.6 eff t/s  104.4 stream t/s  α=82.0%  waste=18%  τ=12.3  win=15
  ✓     filler @ d16384  19.2 eff t/s  19.9 stream t/s  α=7.9%  waste=92%  τ=1.2  win=15
  ✓       code @ d16384  45.2 eff t/s  49.6 stream t/s  α=33.7%  waste=66%  τ=5.0  win=15
  ✓ structured @ d16384  85.3 eff t/s  103.7 stream t/s  α=82.0%  waste=18%  τ=12.3  win=15
  ✓     filler @ d32768  21.3 eff t/s  22.3 stream t/s  α=10.3%  waste=90%  τ=1.5  win=15
  ✓       code @ d32768  42.7 eff t/s  46.8 stream t/s  α=32.2%  waste=68%  τ=4.8  win=15
  ✓ structured @ d32768  85.3 eff t/s  103.6 stream t/s  α=82.0%  waste=18%  τ=12.3  win=15
  vllm serve poolside/Laguna-S-2.1-NVFP4 \
    --host 0.0.0.0 \
    --moe-backend marlin \
    --port 8000 \
    --max-model-len 180000 \
    --max-num-batched-tokens 16384 \
    --max-num-seqs 32 \
    --gpu-memory-utilization 0.85\
    --dtype auto \
    --attention-backend flashinfer \
    --tokenizer-mode auto \
    --load-format instanttensor \
    --async-scheduling \
    --enable-chunked-prefill \
    --enable-prefix-caching \
    --trust-remote-code \
    --reasoning-parser poolside_v1 \
    --enable-auto-tool-choice \
    --tool-call-parser poolside_v1 \
    --kv-cache-dtype fp8_e4m3 \
    --speculative-config '{"method":"dflash","num_speculative_tokens":15,"model":"poolside/Laguna-S-2.1-DFlash-NVFP4"}' \
    --override-generation-config '{"temperature":0.7,"top_p":0.95}'

EDIT
After few hours I got an issue, there is a looping, he thinks, he writes, he uses tool, rethink (the same reasoning), writes (the same text), he uses tool (the same) infinitly...

I had some issues with vLLM 0.23 and used this instead:

sudo apt install -y python3.12-dev
curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv ~/venvs/vllm025 -p 3.12

uv pip install -p ~/venvs/vllm025 vllm==0.25.1 --torch-backend=cu130

uv pip install -p ~/venvs/vllm025 \
  "flashinfer-python==0.6.15.dev20260712" \
  "flashinfer-cubin==0.6.15.dev20260712" \
  "flashinfer-jit-cache==0.6.15.dev20260712" \
  --extra-index-url https://flashinfer.ai/whl/nightly/ \
  --extra-index-url https://flashinfer.ai/whl/nightly/cu130/ \
  --index-strategy unsafe-best-match
export CUTE_DSL_ARCH=sm_121a
export MAX_JOBS=4
source ~/venvs/vllm025/bin/activate

vllm serve poolside/Laguna-S-2.1-NVFP4 \
    --host 0.0.0.0 \
    --port 8000 \
    --max-model-len 262144 \
    --max-num-batched-tokens 16384 \
    --max-num-seqs 32 \
    --gpu-memory-utilization 0.85 \
    --moe-backend marlin \
    --dtype auto \
    --attention-backend flashinfer \
    --load-format instanttensor \
    --async-scheduling \
    --enable-chunked-prefill \
    --enable-prefix-caching \
    --trust-remote-code \
    --kv-cache-dtype fp8_e4m3 \
    --reasoning-parser poolside_v1 \
    --enable-auto-tool-choice \
    --tool-call-parser poolside_v1 \
    --default-chat-template-kwargs '{"enable_thinking": true}' \
    --speculative-config '{"method":"dflash","num_speculative_tokens":5,"model":"poolside/Laguna-S-2.1-DFlash-NVFP4"}' \
    --override-generation-config '{"temperature":0.7,"top_p":0.95}'

Without enable_thinking it leaks a </think> token at the start of responses. "num_speculative_tokens":5 has much better draft acceptance 20-42%

You got a better token generation rate in filler with 5 in speculative token? From experience I never really found a difference in increasing the acceptance rate with the dflash method. Technically it's supposed to be slower to have to generate 15 tokens (at least in ttft) but for me it's quite insignificant, I prefer to always keep 15 tokens for structure and code but I can decrease to 12-13 I think.
For the thinking leak I didnt get this issue for now but I didnt get enough time to test in big projects for now.

Edit : Ive tested 7 and I got 10 tokens/s in filler (Ive now 26tok/s) thank you, usally I never get better results... On the other hand, I lost in structure but I prefer to have a little more filler and a little less structure

jbourny changed discussion title from Pretty good :) to Pretty good :) but ... looping :(

Yeah for me it went from 3-8% acceptance rate with 15 tokens to 20-42% with 5. Allegedly this recipe got much better performance though, might be worth checking out: https://github.com/MiaAI-Lab/Laguna-S-2.1-DGX-Spark-RTX-6000-PRO. My use case was agentic coding/deep research with lots of tool calls though, it might work better when generating prose.

Sign up or log in to comment