私はRTX 5090でQwen3.6 27B NVFP4をしばらくテストしたので、数値を共有したいと思いました。最近の良い投稿の多くが、48GBカードやFP8、あるいはllama.cpp/GGUFあたりに寄っているように見えたためです。
これは「最適な構成」を主張するものではありません。もっと言うと、こちらで動いたのがこれで、正確なパラメータはこれで、数値はこうでした。そして、他の5090オーナーが推測に時間をかけずに済むなら役に立つかもしれない、という話です。
要約すると：
- 単体のRTX 5090、32GB VRAM
- モデル:
Peutlefaire/Qwen3.6-27B-NVFP4 - vLLM:
0.20.1.dev0+g88d34c640.d20260502 - Torch:
2.13.0.dev20260430+cu130 - ドライバ:
595.58.03 - 量子化:
compressed-tensors - 注意（Attention）バックエンド:
flashinfer - KVキャッシュ:
fp8_e4m3 - MTPを有効化（推論を3つのスペキュレーティブトークンで行う）
- テキストのみモード
- 私が納得して言える公開主張: 200kコンテキスト、220k/262kではない
vLLMのモデルエンドポイントは max_model_len: 230400 と報告しますが、ベンチマークは200kコンテキスト深度までしか実施していません。実際に繰り返し実行で検証できたのが200kなので、意図的に200kの主張に留めています。
主要なvLLM引数は以下です:
bash vllm serve Peutlefaire/Qwen3.6-27B-NVFP4 \
--host 0.0.0.0 --port 8082 \
--safetensors-load-strategy=prefetch \
--tensor-parallel-size 1 \
--attention-backend flashinfer \
--performance-mode interactivity \
--language-model-only \
--skip-mm-profiling \
--kv-cache-dtype fp8_e4m3 \
--gpu-memory-utilization 0.95 \
--max-model-len 230400 \
--max-num-seqs 1 \
--max-num-batched-tokens 4096 \
--enable-chunked-prefill \
--enable-prefix-caching \
--no-disable-hybrid-kv-cache-manager \
--reasoning-parser qwen3 \
--default-chat-template-kwargs '\''{"enable_thinking": false}'\'' \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--quantization compressed-tensors \
--speculative-config '\''{"method":"mtp","num_speculative_tokens":3}'\'' \
--trust-remote-code
起動ログには、私が見たかった重要な部分がありました:
Using FlashInferCutlassNvFp4LinearKernel for NVFP4 GEMM- 利用可能なKVキャッシュメモリ:
8.3 GiB - リクエストあたり
230,400トークン時の最大同時実行数:1.00x
実行後の nvidia-smi では、使用量がだいたい 30478 MiB / 32607 MiB で、vLLM EngineCoreプロセスが 29998 MiB ほど使っていました。
llama-benchy の数値
これらはすべて次の条件で行いました:
llama-benchy 0.3.7--pp 2048--tg 480--latency-mode generation--skip-coherence- concurrency 1
- 長文コンテキストソースとして「戦争と平和」テキスト
コンテキスト・ラダー
| context depth | prefill tok/s | generation tok/s | TTFT |
|---|---|---|---|
| 0 | 28470 | 86.3 | 0.2s |
| 1k | 20901 | 94.5 | 0.3s |
| 5k | 14593 | 82.3 | 0.6s |
| 10k | 12805 | 88.8 | 1.0s |
| 20k | 10564 | 88.3 | 2.2s |
| 50k | 7277 | 89.0 | 7.3s |
| 100k | 4834 | 62.7 | 21.2s |
| 150k | 3617 | 75.5 | 42.1s |
| 200k | 2893 | 63.4 | 69.9s |
その後、--exit-on-first-fail を付けた別の10回実行による安定性チェックを200kで行いました。たまたま1回だけ上手くいったのではないことを確認するためです。
200k 安定性ラン
pp=2048、tg=480、depth=200000、runs=10、キャッシュなし:
- 10/10回完了
- 終了ステータス 0
- 平均 prefill:
2883 tok/s - 平均 generation:
73.6 tok/s - generation 標準偏差:
13.5 tok/s - 平均 TTFT:
70.2s - 総実行時間:
12:48.79
実行ごとの generation 速度:
text 73.04, 75.12, 63.24, 75.94, 59.02, 110.71, 64.11, 68.18, 72.55, 74.37 tok/s
なので、少ないスイープの結果から200kで93 tok/sだけをつまみ上げるようなことはしません。この構成でのより正直な数字は、おそらく200kでの generation は実行によって多少変動しますが、だいたい65〜75 tok/sあたりです。
プレフィックスキャッシュの挙動
また、プレフィックスキャッシュを個別にテストしました。200kにて:
| run | prefill tok/s | generation tok/s | TTFT |
|---|---|---|---|
| cold | 2911 | 65.2 | 68.8s |
| warm | 761 | 59.6 | 2.8s |
warmキャッシュのprefillは、cold時のprefillと単純には比較できませんが、TTFTの低下が重要なポイントです。ローカルでのコーディング／エージェントのワークフローのように、大きいプレフィックスを何度も再利用する場合に、実際に「体感で」違いが出るのはここです。
MTP テレメトリ
ベンチマーク実行中のvLLMログから:
- 平均MTP受理長:
2.28 - 平均ドラフト受理率:
42.7% - 観測された最大GPU KVキャッシュ使用率:
88.0%
受理率はかなり変動したので、num_speculative_tokens=3ではなくnum_speculative_tokens=2のほうが良い結果になる人がいるのか気になっています。ここでは安定していたので3から始めましたが、それが最適だとは主張しません。
注意点（Caveats）
はっきりと言っておく価値のあることがいくつかあります:
- ここでは精度（accuracy）のベンチマークは実行していません。パフォーマンス／安定性のみです。
- vLLMは、NVFP4のグローバルスケールが精度を下げる可能性があると警告します。コーディング品質を重視するなら、自分で評価してください。
- Mambaキャッシュの整列モードでのプレフィックスキャッシュは、vLLMではまだ実験的（experimental）として扱われています。
- FlashInfer + spec decode により、CUDAGraphモードがピースワイズで強制されます。
- ビジョン／マルチモーダルはテストしていません。これはテキストのみです。
- 220kまたは262kは検証していません。この実行で私が自信を持って言えるのは200kです。
現時点では、この5090のローカル構成としてかなり満足しています。完璧ではありませんし、すべてのクラウドモデルに取って代わると言いたいわけでもありませんが、長時間のローカルコーディングセッションでは、ようやく「買った目的どおりの動きをしてくれている」感じがします。
もし他の誰かが5090でQwen3.6 27Bを動かしていて、とくにvLLMならNVFP4やFP8を使っているなら、パラメータとMTP設定をぜひ比較したいです。加えて、MTPでのmax_num_batched_tokensをより綺麗に（適切に）設定できる人がいるかも気になります。というのも、vLLMは4096が最適ではない可能性があると警告しているからです。
私は、元の llama-benchy のJSON／stdout／stderrと、完全なvLLMログをローカルに保存しています。必要なら、全監査（audit trail）を確認したい人向けにどこかにアップロードできます。
私はボットです。この操作は自動的に実行されました。
[リンク] [コメント]
