同一のQwen3.6-27B-NVFP4モデルで、llama.cppの2つのビルドをテストしました。
llama-benchではモデルラベルがqwen35 27B NVFP4と報告されますが、実際にテストしたモデルはQwen3.6-27B-NVFP4です。
テスト環境
- GPU: NVIDIA GeForce RTX 5090
- CPU: AMD Ryzen 9 9950X3D
- RAM: 128 GB DDR5 5600 CL36
- バックエンド: CUDA
テストしたビルド
- b8966 — ネイティブNVFP4対応なしの最終ビルド
- b8967 — ネイティブNVFP4対応あり（ネイティブNVFP4対応の最初のビルド）
両方の実行では、同じモデルと設定を使用しました：Qwen3.6-27B-NVFP4、17.50 GiB、26.90Bパラメータ、CUDAバックエンド、ngl=999、fa=1。
主な結論
b8967におけるネイティブNVFP4対応は、プロンプト処理／プロンプト取り込み性能を大幅に改善しますが、トークン生成速度は実質的には変わりません。
実務的には：
- プロンプト処理は、ネイティブNVFP4で約43〜68%高速です。
- 平均的なプロンプト処理の向上幅は、およそ57%です。
- トークン生成はほぼ変わりません。
- 長いプロンプト、大きいコンテキスト、RAGワークロード、ドキュメント解析、コード中心のプロンプトで最も効果が出るはずです。
- 通常のチャット生成速度は、生成が始まってからは概ね同じ体感になります。
プロンプト処理の結果
| Test | b8966 — ネイティブNVFP4なし | b8967 — ネイティブNVFP4 | 改善 |
|---|---|---|---|
pp512 | 3295.10 t/s | 5546.93 t/s | +68.3% |
pp2048 | 3373.30 t/s | 5594.58 t/s | +65.8% |
pp512 @ d4096 | 3265.74 t/s | 5232.92 t/s | +60.2% |
pp2048 @ d4096 | 3231.69 t/s | 5272.82 t/s | +63.2% |
pp512 @ d8192 | 3152.71 t/s | 4995.34 t/s | +58.4% |
pp2048 @ d8192 | 3117.80 t/s | 5005.44 t/s | +60.5% |
pp512 @ d16384 | 2965.81 t/s | 4537.54 t/s | +53.0% |
pp2048 @ d16384 | 2934.26 t/s | 4547.25 t/s | +55.0% |
pp512 @ d32768 | 2514.70 t/s | 3586.58 t/s | +42.6% |
pp2048 @ d32768 | 2479.39 t/s | 3560.58 t/s | +43.6% |
ネイティブNVFP4ビルドは、プリフィル中に一貫して大幅に高速です。最大の伸びは、コンテキストサイズが短い場合および中程度の場合に見られ、このときb8967はb8966より約1.6×〜1.7×高速です。d32768のような非常に長いコンテキストでは優位性は縮小しますが、それでも1.43×高速程度で依然として大きな差があります。
トークン生成の結果
| Test | b8966 — ネイティブNVFP4なし | b8967 — ネイティブNVFP4 | 差 |
|---|---|---|---|
tg128 | 73.73 t/s | 73.62 t/s | -0.1% |
tg512 | 73.71 t/s | 73.68 t/s | ~0.0% |
tg128 @ d4096 | 72.60 t/s | 72.47 t/s | -0.2% |
tg512 @ d4096 | 72.47 t/s | 72.50 t/s | +0.0% |
tg128 @ d8192 | 71.70 t/s | 71.57 t/s | -0.2% |
tg512 @ d8192 | 71.65 t/s | 71.61 t/s | -0.1% |
tg128 @ d16384 | 70.10 t/s | 70.04 t/s | -0.1% |
tg512 @ d16384 | 70.08 t/s | 69.90 t/s | -0.3% |
tg128 @ d32768 | 67.00 t/s | 66.88 t/s | -0.2% |
tg512 @ d32768 | 66.98 t/s | 66.98 t/s | 0.0% |
トークン生成の性能は、2つのビルド間で本質的に同一です。わずかな差は、通常のベンチマークノイズの範囲内です。
つまり、ネイティブNVFP4対応はプリフィル経路を改善しますが、自律回帰的（autoregressive）デコードを目立って高速化するわけではありません。
コンテキスト長の挙動
両方のビルドで、コンテキスト長が増えるにつれて徐々に速度が低下します。トークン生成では低下の程度がほぼ同じです：
| Context | b8966 tg512 | b8967 tg512 |
|---|---|---|
| base | 73.71 t/s | 73.68 t/s |
d4096 | 72.47 t/s | 72.50 t/s |
d8192 | 71.65 t/s | 71.61 t/s |
d16384 | 70.08 t/s | 69.90 t/s |
d32768 | 66.98 t/s | 66.98 t/s |
ベースのテストからd32768へ進むと、生成速度は約73.7 t/sから67.0 t/sへ低下し、これは約9%の減少にとどまります。これは長いコンテキストにおける27Bモデルとして健全な結果です。
プロンプト処理については、b8967は全範囲で大幅に高速なままですが、非常に長いコンテキストサイズでは相対的な優位性が縮小します：
| Context | b8966 pp2048 | b8967 pp2048 | Improvement |
|---|---|---|---|
| base | 3373.30 t/s | 5594.58 t/s | +65.8% |
d4096 | 3231.69 t/s | 5272.82 t/s | +63.2% |
d8192 | 3117.80 t/s | 5005.44 t/s | +60.5% |
d16384 | 2934.26 t/s | 4547.25 t/s | +55.0% |
d32768 | 2479.39 t/s | 3560.58 t/s | +43.6% |
Final takeaway
ネイティブNVFP4サポートを備えたb8967は、RTX 5090システム上のQwen3.6-27B-NVFP4に対して、b8966より明らかに優れています。
これは大きなプロンプト処理の改善をもたらします――おおよそ1.4×〜1.7×高速なプリフィル――一方で、トークン生成速度は実質的に変わりません。
そのため実用上のメリットは、「生成中の1秒あたりトークン数が増えること」ではなく、むしろ大きなプロンプトの取り込みが大幅に速くなり、長いプロンプトでの最初のトークンまでの時間が短縮され、長いコンテキストのワークロードでの使い勝手が向上することです。
[link] [comments]
