モデル別実行レシピ
最終更新
CMP 170HXでQwen3.8-27Bを最速で実行するには？
測定された1枚構成では、約3.2K入力のデコード平均はvLLM DFlash2の方が高速でした。
CMP 170HXでQwen3.8-27Bを実行するには、GGUF1 Q4_K_MまたはW4A16 AutoRoundの重みをサービングエンジンに読み込み、テキスト要求に回答します。10月10日の1枚測定における約3.2Kトークン2の個別要求では、vLLM DFlash2が109.42 tok/s、open-jet MTP3 d=4が77.20 tok/sでした。別途、greedy 5プロンプト4の平均はそれぞれ181.8と94.1 tok/sでした。
短い入力で素早く回答を生成したいなら、まずvLLM DFlash2構成を検討してください。長文には、open-jetで18,976入力トークンを最後まで処理した公開記録があります。以下で生成速度、最初の回答までの待ち時間、実行方法を比べます。
速度表ではデコードと入力処理を分けて見ます
要求を受けて入力を処理し最初のトークンを出すまでがprefill5、その後に回答を続ける速度がdecode6です。10月10日の180W比較では、greedy 5プロンプトの平均がvLLM DFlash2 k=7で181.8 tok/s、open-jet megakernel MTP d=4で94.1 tok/sでした。thinkingを有効にした4プロンプトの平均も、vLLMが156.3、open-jetが75.6 tok/sでした。
| 作業・入力条件 | vLLM DFlash2 k=7 | open-jet MTP d=4 |
|---|---|---|
| 個別chat・入力3,163 / 3,158トークン | 109.42 tok/s · TTFT 1.6515秒・出力58/128トークン | 77.20 tok/s · TTFT 2.0662秒・MTPなし: 48.74 tok/s |
| greedy平均・5プロンプト | 181.8 tok/s | 94.1 tok/s |
| thinking平均・4プロンプト | 156.3 tok/s | 75.6 tok/s |
この比較は64GiB・SM 74基、HBM 1,728MHz、PCIe Gen2 x16のCMPを180Wに制限し、強制送風で1要求ずつ処理しました。vLLM 0.27.1は標準ゲストドライバー580.178.04とホスト側unlock commit 88e39ce、open-jetは公開コミット93c2b9aを使用しました。
サーバーを稼働し続ける場合と再起動する場合
両方の実行でQwen3.8-27Bの4ビット重みを使いましたが、ファイルは異なります。open-jetは特定revisionのQwen3.8-27B-Q4_K_M.gguf、vLLMはW4A16 AutoRoundモデルとDFlash2 drafterを使用しました。量子化7形式とチェックポイント8は出力や速度に影響するため、この表は二つの構成を比較した結果です。
vLLMサーバーはCUDA9 graph captureとDFlash2の準備を含め427秒後に利用可能になり、open-jetは数秒で起動しました。1日に一度起動して使い続けるなら初期準備時間は1日一回のコストですが、開発中に頻繁に再起動すると待ち時間が繰り返されます。サーバーを稼働し続ける場合は、要求ごとのdecode速度がより直接的な比較基準です。
再現する場合は公開されたvLLMレシピの固定情報に従います
測定ではvLLM 0.27.1を使っています。リンク先のsyv.aiレシピの69ba4d0688c6ae76cb9d3c4a5c3b36445e1b040cコミットとrequirements.lockを基に準備してください。サーバーはSPEC=dflash2、CTX=fast、MAX_SEQS=1、DFLASH_TOKENS=7、GPU_UTIL=0.90、BF1610 KVキャッシュ11に設定されました。文脈長12の設定値は65,536で、モデルファイルと実行手順はreproduce.ipynbとrecipe.jsonにあります。
新しい環境で再現する際は、CUDAコンパイラーのインストール先も確認してください。公開ノートブックではnvidia-cuda-nvcc 13.4.92がnvidia/cu13/に入り、import nvidia.cuda_nvccが失敗しました。研究者が行ったパス修正はappendixに記録されています。
open-jetを試す場合は、測定に使われたコミットを取得してGA100用にビルドしてください。下のコマンドはCUDA 12.8.93とリポジトリの依存関係を用意した環境で実行します。モデルの取得とサーバー起動は、リンク先の再現ノートブックに従ってください。
git clone https://github.com/L-Forster/open-jet.git
cd open-jet
git checkout 93c2b9abee50ea2ea41981c406cfd201989e4d58
make ARCH=sm_80
自分が使う文脈長で改めて判断します
短いプロンプトで高いdecode速度を求めるなら、公開された1枚構成ではvLLM DFlash2が有力な出発点です。サーバーの再起動時間を重視する場合や短時間で起動する経路が必要な場合は、open-jetの起動の速さも検討できます。ただし180Wでのopen-jetとvLLMはチェックポイント形式も異なるため、決定前に同じ入力と応答設定で比較してください。
入力を増やした試験では、リクエスト方式によって結果が異なりました。vLLMは6,603トークンの/v1/completions課題を完了しましたが、9,472トークンのチャット要求ではXid 31で終了しました。open-jetは18,976トークン入力まで完了しています。長文を扱うなら、この完了記録を基にエンジンを選び、自分の文書で試してください。
決定前に、実作業でよく使うプロンプト長と回答長を固定します。エンジンが要求を最後まで処理したか、最初のトークンまでの時間、生成速度、完了状況をそれぞれ記録してください。より長い入力が必要な場合は、設定上限へ一度に伸ばすのではなく、使うエンジンとチェックポイントで正常に完了する長さを段階的に確認し、失敗した長さは検証範囲外として記録します。
用語の注釈
GGUF — モデル情報を格納するファイル形式で、llama.cpp系のツールで広く使われます。
本文に戻るトークン — モデルが入力や出力を分けて処理する単位です。
本文に戻るMTP — 複数の将来トークンを一度に予測する学習目標、またはそれを行うモデル構成です。投機的デコーディングでは、その予測を候補トークンとして提案できます。
本文に戻るプロンプト — モデルに送る入力文です。生成モデルでは作りたい結果を説明する文になり、出力の構成や内容を大きく左右します。
本文に戻るプリフィル — LLMが入力プロンプトを読み、各トークンの内部表現を計算する段階です。プロンプトが長いほど処理するトークンが増えます。
本文に戻るトークンのデコード — 入力とそれまでの回答をもとに、次の出力トークンを順に生成する段階です。
本文に戻る量子化 — モデルの重みや計算値を少ないビット数で表し、保存容量やメモリ使用量を減らす方法です。表現が粗くなるため、精度にも影響することがあります。
本文に戻るチェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。
本文に戻るCUDA — NVIDIA GPUで汎用計算を行うソフトウェア基盤です。
本文に戻るBF16 — モデルの数値に使う16ビット浮動小数点形式です。指数部はFP32と同じ幅で、同程度に広い値の範囲を表せます。
本文に戻るKVキャッシュ — 過去トークンのAttention用キー・バリューを保存し、後続トークン生成で再利用するメモリです。容量はコンテキスト長やバッチサイズで変わります。
本文に戻るコンテキスト長 — 1回のリクエストでモデルが扱える入力と生成内容のトークン範囲です。上限や実際のメモリ使用量はモデルと実行設定によります。
本文に戻る
よくある質問
- この記事で最初に確認すべきことは何ですか？
- CMP 170HXでQwen3.8-27Bを実行するには、GGUF Q4_K_MまたはW4A16 AutoRoundの重みをサービングエンジンに読み込み、テキスト要求に回答します。10月10日の1枚測定における約3.2Kトークンの個別要求では、vLLM DFlash2が109.42 tok/s、open-jet MTP d=4が77.20 tok/sでした。別途、greedy 5プロンプトの平均はそれぞれ181.8と94.1 tok/sでした。