同じGPUのまま、Qwen3.8 27B + DFlash2の生成速度が 35.04 → 58.53 tok/s、約67%増になった。使ったのは24 GBのRTX PRO 4000 Blackwell SFF。公称70 W、補助電源コネクタなしのカードだ。
ただし、電力制限を120 Wに上げ、GDDR7とコアのクロックも調整した結果である。「電力制限を外すだけで67%」ではない。もう一つのQwenでは、同じ調整方針が通用しなかった。
この検証で収穫だったのは、最大tok/sの値そのものより、電力・メモリクロック・prefill・decodeを分けて測ると、選ぶべき設定が変わると分かったことだ。以下では158リクエストの探索で確認した数値、VBIOSの制約、CSVからの検算方法を整理する。
本稿は、私自身の英語版検証記事を、日本語の技術記事として再構成したものだ。
1. まず、67%の比較条件を固定する
主な比較は入力8,000トークン、GPU ECC OFF。いずれも同じ改変VBIOSを使い、70 W・クロックオフセット0を各モデルの基準とした。
| 構成 | 70 W・オフセット0 | 観測された最高の生成速度 | 設定 |
|---|---|---|---|
| Qwen3.8 27B、NVFP4、DFlash2あり | 35.04 tok/s | 58.53 tok/s（+67.05%） | 120 W、メモリクロック+20%、コア+180 MHz |
| Qwen3.6 35B A3B、Q4_K_S、drafterなし | 84.97 tok/s | 115.56 tok/s（約+36%） | 120 W、メモリクロック+33.3%、コア0 |
27Bは1リクエストあたり512出力トークン、35Bは640出力トークン。モデル、量子化、投機的デコードの有無が違うので、これはdenseとMoEの優劣や回答品質を比べた実験ではない。それぞれの構成が、自分自身の基準からどう変化したかを読む。
158回は実験全体のリクエスト数で、各設定を158回ずつ測ったわけではない。GPU ECC OFFが79回、ONが79回。集計セルはn=1〜3で、27Bの70 W基準はn=1、最高値のセルはn=2だ。35Bの基準と最高値はともにn=2。小さな差を確定的な順位として扱える精度ではない。
また、70 W基準も改変VBIOS上の測定である。工場出荷時VBIOSと改変VBIOSの厳密なA/B比較ではない。
2. 106 Wと表示されても、実際の消費電力は約70 Wだった
最初に制限値を変えたとき、ソフトウェアの表示は106 Wになった。しかし負荷をかけても、GPUの消費電力は約70 Wのままだった。
設定できる上限と、負荷時に実際に使える電力は同じではなかった。最終イメージでは、パーサーが次の名前でデコードするフィールドを変更した。
| デコードされたフィールド名 | 変更前 | 変更後 |
|---|---|---|
power_max_w |
70 W | 120 W |
board_fixed_rated_w |
70 W | 120 W |
slot_power_max_w |
66 W | 120 W |
slot_power_rated_w |
66 W | 120 W |
input_current_max_ma |
6,600 mA | 10,200 mA |
input_current_rated_ma |
6,600 mA | 10,200 mA |
input_current_policy7_limit_ma |
6,600 mA | 10,200 mA |
これはGPU VBIOS内のポリシーフィールドを解釈した名前だ。各フィールドが独立した物理保護回路の作動点に対応すると確認したわけではない。マザーボードのBIOSは変更していないし、ソフトウェアを書き換えてもスロットや配線の許容電流は増えない。
電圧フィールドは引き上げていない。デコードされたREL上限は850 mVのままだった。ただし、これはイメージ内の値であり、実動作電圧を850 mVと測定したという意味ではない。この測定系列にはコア電圧のテレメトリがない。
3. EEPROMへの書き込みではなく、実行時のVBIOSオーバーライド
使用したのはPanchovixのLinux VBIOS Vix Loader。パッチを当てたNVIDIA open kernel modulesを通じ、改変イメージをメモリ上に読み込む方式だ。
コード上ではNV_VBIOS_OVERRIDE_MODE_KEYがRmLinuxVbiosOverrideに対応し、RmLinuxVbiosOverrideImageからイメージを読む。アドレスとサイズはvbiosOverrideArgsを通じてGPU System Processor側へ渡される。EEPROMの内容を恒久的に置き換える操作とは区別している。
この検証ではEEPROMのフラッシュ、はんだ付け、シャント改造は行っていない。冷却も標準ブロワーと自動ファン制御のままだった。
バックアップでも、成功表示だけは信用できなかった。NVFlashの保存は成功を返したのにファイルは0バイト。sysfsからの読み出しは4,096バイトしかなかった。メンテナンス中にGDBでNVFlashのバッファを解放前に取り出し、独立した2回の読み出しで4 MiBのイメージが一致することをSHA-256で確かめた。
ここで重要なのはGDBの手順をまねることより、操作の終了表示と、得られた実物を別々に確認することだ。電力制限も同じだった。
4. 電力だけを増やすと、二つのQwenは違う曲線になった
入力8,000トークン、GPU ECC OFF、メモリとコアのオフセット0で電力制限だけを変えた。
| 電力制限 | 27B + DFlash2の生成速度 | 35B A3Bの生成速度 |
|---|---|---|
| 70 W | 35.04 tok/s | 84.97 tok/s |
| 90 W | 47.05 tok/s | 93.63 tok/s |
| 106 W | 52.05 tok/s | 96.21 tok/s |
| 120 W | 54.18 tok/s | 96.43 tok/s |
27Bは120 Wまで伸び、電力だけで約55%増。35Bは合計約13.5%増で、106 Wから先の変化は小さい。
したがって、冒頭の67%を電力制限の解除だけの成果とは書けない。120 Wに加えて、メモリとコアを調整した結果である。逆に「35Bは電力を増やしても速くならない」と一般化するのも誤りだ。この構成・入力長・測定系列で、最後の電力増加に対する伸びが小さかった。
5. GDDR7は速くすればするほどよい、とは限らない
電力制限を120 W、コアオフセットを0に固定し、メモリ周波数を約10%、20%、33.3%増やした。オフセットの適用にはnvmlDeviceGetClockOffsets()とnvmlDeviceSetClockOffsets()を使い、P0とP2の両パフォーマンスステートを対象にして読み戻しも確認した。
ここでの増加率の基準は120 W・メモリOCなし。70 W基準の67%とは別の比較だ。
| メモリ周波数の増加 | 27Bの生成速度増加率 | 35Bの生成速度増加率 |
|---|---|---|
| +10% | +4.4% | +7.3% |
| +20% | +6.5% | +14.0% |
| +33.3% | +5.0% | +19.8% |
入力8,000トークン、GPU ECC OFF。線は測定点を結んだもので、未測定条件の予測ではない。各セルn=1〜3。
27Bではメモリ+20%で57.70 tok/s、+33.3%では56.91 tok/sだった。高いメモリ設定で生成中の実SMクロックも下がっていた。メモリと演算が同じ電力予算を分け合う、という説明とは整合するが、原因を分離した実験ではなく、約0.79 tok/sの逆転が再現するかどうかは追加測定が必要だ。
35Bは測定した範囲では伸び続け、+33.3%で115.56 tok/sに達した。探索範囲の端で最高値だったので、真の最適点を見つけたとは言えない。
27Bではメモリ+20%にコア+180 MHzを加えたセルが58.53 tok/sになった。コア+360 MHzでは58.49 tok/s。生成はこの測定精度ではほぼ同率だが、prefillは+360 MHz側が速かった。生成速度の小数点以下だけを追うと、別の改善を見落とす。
6. decodeが速い設定でも、回答全体は遅くなり得る
prefillは入力の処理、decodeは出力の生成だ。長い入力を毎回処理する用途では、decodeのtok/sだけで設定を選べない。
入力32,000トークンの35Bで、次の二つを比べた。電力制限はいずれも120 W。
| 設定 | prefill | decode | 500トークン回答の推定時間 |
|---|---|---|---|
| メモリ+20%、コア+360 MHz | 2,121.56 tok/s | 82.07 tok/s | 21.18秒 |
| メモリ+33.3%、コア0 | 1,972.45 tok/s | 82.28 tok/s | 22.30秒 |
後者は生成がわずかに速い。しかし入力処理が遅く、二つのフェーズを足した推定では前者が約5%短い。
input_tokens = 32_000
output_tokens = 500
profiles = {
"balanced": (2121.56, 82.07),
"memory_heavy": (1972.45, 82.28),
}
for name, (prefill, decode) in profiles.items():
seconds = input_tokens / prefill + output_tokens / decode
print(name, f"{seconds:.2f} s")
これは640出力トークンの測定レートを使った、500トークン回答への外挿だ。500トークンのリクエストを直接計時した値ではない。ロード時間、キュー、ネットワーク、ツール呼び出しは含めない。まず候補を絞るための式として使い、最終判断は実アプリケーションの計時で行う。
同じ理由で、生成スループットが67%増えても、回答全体の時間が67%減るわけではない。出力長を固定した生成フェーズだけなら約40%の時間短縮になる。
7. 106 → 120 WをABBA順序で測り直す
電力差をもう少し確かめるため、同じモデルをロードしたまま、106 → 120 → 120 → 106 Wの順序でも測った。メモリ+20%、コア0、各電力・入力長あたり2リクエストだ。
ABBA順序は、おおむね線形な時間ドリフトの偏りを均すためのもので、温度変化やノイズをすべて打ち消すわけではない。また、オフセット0の電力スイープや、67%を記録したコア+180 MHzとは別の条件である。
106 Wから120 Wにすると、27Bの生成は約8.6%増。35Bは入力長により約2.2〜3.0%増だった。一方、測定されたGPU電力あたりの生成スループットは、4つの比較すべてで低下し、低下率は2.47〜7.30%だった。
電力は約1 HzのGPUテレメトリ。サーバー全体の壁コンセント電力や、アプリケーション1タスクあたりのエネルギーではない。
最短の待ち時間と、GPU電力あたりの生成効率では、選ぶ設定が変わる。どちらを優先するかを決めずに「最適化できた」とは言いにくい。
8. CSVから67%を検算する
下のコードはGPU設定を変更しない。model-grid-summary.csvを保存し、同じディレクトリで実行すると、比較条件を固定して生成速度の増加率を計算できる。
import csv
from pathlib import Path
with Path("model-grid-summary.csv").open(newline="") as f:
rows = list(csv.DictReader(f))
model = "Qwen3.8-27B-iMatrix-NVFP4-256K-DFlash2"
def cell(power, memory, core):
matches = [r for r in rows
if r["model"] == model and r["ecc"] == "OFF"
and int(r["prompt_n"]) == 8000
and int(r["power_w"]) == power
and int(r["memory_offset"]) == memory
and int(r["core_offset"]) == core]
assert len(matches) == 1, matches
return matches[0]
base = cell(70, 0, 0)
tuned = cell(120, 3600, 180)
a, b = float(base["decode_tps"]), float(tuned["decode_tps"])
print(f"{a:.2f} -> {b:.2f} tok/s; +{(b/a-1)*100:.2f}%")
print("n:", base["n"], tuned["n"])
print(f"fixed-output generation time: {(1-a/b)*100:.2f}% less")
期待される値は35.04 → 58.53 tok/s、+67.05%、n=1と2。固定出力長での生成時間は約40.14%減になる。CSVのmemory_offset=3600は、この環境でメモリ周波数+20%に対応したAPI側のオフセット値だ。別ツールの同じ数字が同じ周波数変化を意味するとは限らない。
原記事には全158リクエスト、集計グリッド、8K主要結果、ABBA比較、アンカードリフト、回答時間推定の6種類のCSVがある。数値の検算はできるが、元ログ、全プロンプト、モデル資材、完全な実行環境をすべて同梱した再現パッケージではない。
9. 120 Wを日常設定として勧めない理由
このカードに補助電源コネクタはない。120 Wは標準PCIeスロットの75 W予算を超える。90 Wと106 Wも同様だ。実行時にVBIOSを読み込む方式でも、電源経路の物理的な負担は残る。
全グリッドで記録したGPU温度の最大は92°Cだった。VRAM、VRM、スロット接点の温度は直接測っていない。ベンチマークが完走したことは、長期安定性や電気的安全性の証明にならない。
測定環境は次のとおり。実験日は2026年10月24〜25日。
- CPU：AMD Ryzen 7 7700、8コア、65 W
- マザーボード：ASRock B650M Pro RS（Micro ATX）
- メモリ：DDR5-6000 32 GB（2×16 GB）、CL30
- SSD：Lexar NM790 2 TB、M.2 2280、PCIe 4.0 x4 NVMe
- もう1枚のGPU：RTX 2000 Ada 16 GB、OCなし
- OS：Debian 13.7、kernel
6.12.38+deb13-amd64 - ドライバー：NVIDIA Open
615.71.10
私が次に絞って測るなら、候補設定の反復、工場出荷時VBIOSの基準、実アプリケーションの応答時間、壁電力と電源経路の直接測定になる。
GPUを買い替えずに67%増は得られた。ただし120 Wとクロック調整を必要とし、別のQwenは別の設定を求めた。設定欄の最大値を探す前に、自分がどの処理の時間を短くしたいのかを決める必要があった。