Qwen3.8-Flash-Nextの調整：DGX Spark 1台で動かすSGLang設定

ハードウェア別速度チューニングおよびサーバーリシピ要約

重み、KVキャッシュ、プリフィルバッチ、同時リクエストと加速機能を分離し、バランス・速度・長い文脈プロファイルで提供します。

詳細ページから、プロフィール別に実行コマンド、適用値、停止すべき条件、および測定順序を確認できます。実行コマンドは、モデルファイルと実行プログラムが確認された組み合わせにのみ表示されます。

モデル名が同じでも、構成が同じとは限らない

この構成は、Qwen3.8-Flash-Nextの特定のNVFP4チェックポイントを使います。すべてのテンソルが一律に4ビットという意味ではありません。アテンションやMTPなど高い精度を保つ部分もあるため、ファイル全体の容量と読み込み後のメモリ使用量を確認してください。

Spark 1台のユニファイドメモリ内で重みをCPU側へ移すだけでは、物理的な空き容量は増えません。大きなPLEテーブルをNVMe上のファイルに置き、必要な部分を参照する専用のmmapパッチが要点です。標準のSGLangにフラグを足すだけの方法とは区別してください。

実験用のファイルとスクリプトはバージョンと内容を確認し、正常に動いている環境とは分けて準備します。ダウンロードや変換のための一時領域も必要です。下の構成では約140GB以上の空き容量を目安としていますが、現在の配布ファイルに必要な総容量を改めて確認してください。

32Kの記録を再現するための出発点

現在の公開スクリプトは、TP 1、メモリ比率0.85、プリフィルのチャンクサイズ2,048から始めます。プリフィルはTriton、デコードはtrtllm_mhaを使い、MTPはNEXTN、3段階、top-k 1、draft token 4個です。この初期値によって、公開測定当時の条件がすべて確認できたわけではありません。

公開されたデコード記録は、英語のコード回答が約41.5 tok/s、スペイン語の通常の文章が約22.8 tok/sです。韓国語でも同じ速度が出るという意味ではありません。以前紹介したプリフィル1,910 tok/sは比較の基準から外しました。原著者が入力キャッシュの再利用による測定への影響を報告しており、キャッシュを空にした反復測定もまだ完了していないためです。この値を新しい文書の入力処理速度として使わないでください。

準備スクリプトと検証が完了したら、リクエストを1件ずつ送って基準値を残します。サーバーが許可する最大リクエスト数と、測定中に同時送信する数は別です。Dockerのポートが127.0.0.1だけに公開されているかも確認してください。

git clone https://github.com/hashd1ve/qwen38-flash-next-one-dgx-spark.git
cd qwen38-flash-next-one-dgx-spark

./scripts/download.sh
./scripts/prepare.sh
sed -i.bak 's/-p "$PORT":30000/-p "127.0.0.1:$PORT:30000"/' scripts/serve.sh
MEMFRAC=0.85 PREFILL=2048 CTX=32768 ./scripts/serve.sh
python3 verify.py

# Docker 포트는 127.0.0.1:30000에만 게시
--tp-size 1
--prefill-attention-backend triton
--decode-attention-backend trtllm_mha
--quantization modelopt_fp4
--ple-offload-embedding
--mamba-radix-cache-strategy extra_buffer
--mem-fraction-static 0.85
--chunked-prefill-size 2048
--max-running-requests 4
--speculative-algorithm NEXTN
--speculative-num-steps 3
--speculative-eagle-topk 1
--speculative-num-draft-tokens 4
--speculative-draft-model-quantization unquant

コンテキスト長だけを増やせばよいわけではない

長いコンテキストでは、余裕を残す初期値としてメモリ比率0.79、プリフィルのチャンクサイズ1,024を使います。公開された長文測定はメモリ比率0.85、リクエスト1件の条件なので、下のコマンドはその測定を正確に再現するものではありません。262,144というコンテキスト長を設定できるだけで、手元の文書を安定して処理できるとは限りません。

まず短い入力で正常動作を確認し、8K・32K・128Kのように段階的に増やします。各長さで、正解を確認できる情報を文書の途中にも入れ、モデルが実際に見つけられるか試してください。他のGPU作業を減らし、リクエスト1件の条件でメモリと最初のトークンまでの時間を測ります。

チャンクを小さくしてピークメモリを抑えると、短い入力の処理量が下がることがあります。長いコンテキストが不要なら、最大の設定を維持する必要はありません。普段の入力長で結果を比べ、残すプロファイルを決めてください。

# 앞의 다운로드·준비 및 로컬 포트 설정을 마친 뒤 실행
# 서버 주소: http://127.0.0.1:30000
cd qwen38-flash-next-one-dgx-spark
sed -i.bak 's/--max-running-requests 4/--max-running-requests 1/' scripts/serve.sh
MEMFRAC=0.79 PREFILL=1024 CTX=262144 ./scripts/serve.sh
python3 verify.py

公開記録より遅いときの確認手順

まずチェックポイント、パッチ、コンテナのバージョンと、PLEファイルが実際にNVMe上にあるかを確認します。次にログを見て、プリフィル・デコードのバックエンドとMTPの重みの精度が意図どおりかを確かめます。候補生成の段階数からむやみに増やさないでください。

初回のディスクアクセスと、ページキャッシュが残った状態での繰り返しアクセスも分けて扱います。準備直後の数値と、普段どおり複数のアプリを開いた状態の数値は異なることがあります。コードと通常の文章を分け、それぞれ同じ条件でMTPの無効時・有効時を記録してください。

実行が頻繁に失敗するなら、速度を追う前に安定した基準設定へ戻します。ポートが外部に開いている場合はアクセス範囲を制限し、共有サーバーにする際は認証とファイアウォールを別途用意してください。

この構成で何を実現したいか

専用パッチで大きなモデルを1台に載せるのは、意義のある実験です。ただ、設定を再現できたことと、毎日気軽に使える道具ができたことは同じではありません。必要な文書やコードを使い、実際の作業を最後まで試してください。

1台の安定した構成で必要な作業ができているなら、もう1台を買う理由は小さくなります。より長いコンテキストや複数リクエストが必要なら、その条件で2台構成と比べてください。購入の判断には、公開記録の最高速度より、自分の環境で繰り返し得られる結果を使います。