Qwen3.8 Flash-NextをDGX Sparkで動かす：SGLang・PLE・MTPレシピ

このレシピはQwen3.8-Flash-Next用の特定NVFP4 checkpointを使います。全tensorを一律4bitにしたファイルという意味ではありません。attention⁹やMTPなど高い精度を保つ部分もあるため、ファイル全体と実際の読み込みを確認します。

Sparkのユニファイドメモリ¹⁰はCPU¹¹とGPU¹²で共有されます。この構成の中心は、大きなPLE tableをNVMeに置き、必要な項目を参照する専用mmap patchです。stock SGLangにオプションを足すだけでは同じメモリ配置になりません。table全体を常にメモリに置く必要はありませんが、requestごとに必要項目を探して移動する時間は発生します。

repositoryとpatchのversionや内容を確認し、本番環境とは分けて準備します。downloadと変換用の一時領域も必要です。scriptが示すNVMe空き容量約140GB以上を目安にしつつ、現在のdownloadファイルサイズを再確認します。NVMeの保存容量と、実行中のpage cacheや他processが使うメモリは別々に確認します。

公開scriptはTP 1、メモリ比率0.85、prefill chunk 2,048から始まります。prefill backendはTriton、decode¹³ backendはtrtllm_mhaです。MTPはNEXTN、3 steps、top-k 1、draft token¹⁴ 4つに設定します。この値は再現するprofileであり、公開測定時の全条件が確認できたという意味ではありません。

最初のcommand群でrepositoryと重みを取得し、patch済み環境を準備し、server portをlocal addressだけに公開します。Dockerと約140GB以上のNVMe空き容量が必要です。準備後にverify.pyでserver応答を確認します。起動時にscripts/serve.shはrepository付属の設定を読むため、別の場所のファイルを混在させないようpathを確認します。

取得と準備は最初のターミナルで進めます。起動後はログのターミナルを残し、リポジトリフォルダーで2番目を開いてpython3 verify.pyを実行してください。ブロック末尾の確認も2番目で送ります。

長文脈profileではメモリ比率0.79とprefill chunk 1,024を使い、メモリpeakに余裕を作るところから始めます。公開された長文脈測定はメモリ比率0.85、request 1件の条件なので、以下のcommandはその測定を正確に再現するものではありません。文脈上限を262,144に設定できても、すべての機器や文書でその長さを安定処理できるという意味ではありません。

まず短い入力で正常動作を確認し、8K・32K・128Kのように段階的に増やします。各長さで文書の途中に答えを知っている文を置き、実際に見つかるか確認します。prefill chunkを小さくするとメモリpeakを下げられますが、短い入力の処理量が下がる場合があります。chunk sizeは一度に処理する単位を調整するもので入力token自体をなくさないため、後半の根拠も回答に反映されるか確認します。

単一request profileは同時処理量の測定ではありません。同時requestを増やすと、それぞれのprefillとKV cache¹⁵が機器資源を共有します。まずrequest 1件で文脈長¹⁶ごとのメモリと初回token待ちを確認し、実運用で同時処理が必要なら別途試験します。CTX=262144はserverの許容上限であり、実際に送信した入力長とは分けて記録します。

長い会議記録の途中に出てくる決定日を探す必要があるなら、入力を増やすたびにその日付を原文と照合します。前半は正しくても中盤や後半の条件を見落とすなら、server設定だけでなく根拠が入力に含まれていたか確認します。設定可能な最大文脈と実際の文書作業の成功は別の確認項目です。

長い文脈へ切り替える前にサーバーターミナルでCtrl+Cを押し、コンテナーも終了したか確認します。下のブロックはリポジトリの親フォルダーで開いた新ターミナル用です。すでに中ならcd行を省略します。新サーバーの準備後、別ターミナルから確認してください。

準備後、実行logで意図したNVFP4 checkpointとPLE fileが開かれたか、prefill・decode backendが選択されたか確認します。実際の経路が設定値と異なるなら、runtime¹⁷がdefault pathを使った可能性があります。適用logを先に確認すると、patch未適用と正しい経路で性能が期待と異なる問題を分けられます。

公開scriptが許可する最大同時request数は、実際に同時送信した数とは異なります。まずrequest 1件でserverが対象文書を処理するか確認します。Docker portが127.0.0.1だけに公開されているかも確認します。共有serverにする場合はアクセス制御とfirewallを別途準備します。

公開実行記録では英語コードが約41.5 tok/s、スペイン語の一般文が約22.8 tok/sと報告されています。言語と回答形式が異なるため、差し引いたり割ったりして直接比較しません。prefill 1,910 tok/sの記録は、入力cache再利用による測定汚染が原文で示され、cacheを消した反復試験が完了していないため比較基準から除外します。tok/sはその条件での生成区間の記録であり、韓国語PDF依頼の全体完了時間ではありません。

表は別途報告されたoMLX 0.7.0の実行結果で、Qwen3.8-Flash-Next oQ4e、temperature 0、Lightning MTP、TurboQuant KV 8bit、aggressive memory guardを使用しています。各点は1台のMacで1回実行した結果なので、DGX SparkのSGLang実験と同条件で比較できません。

専用patchで大型モデルをSpark 1台に載せることと、毎日快適に使うことは異なる目標です。実際の文書やコードを処理し、完了時間とメモリ状態を確認します。安定したSpark 1台の構成で業務が完了するなら、2台目を追加する理由は小さくなります。より長い文脈や同時requestが必要なら、その条件を別に試します。

最後にNVFP4 file、PLE配置経路、実行環境の組み合わせを記録します。モデルファイルを変えるとPLEのメモリ配置や必要容量が変わる場合があります。vLLM・SGLang用のNVFP4配布物を選ぶときも、checkpoint形式とruntimeの対応を合わせて確認します。

NVFP4でPLE tableをどう読み込むかは実行環境とpatchによって異なります。Spark 1台では専用offload経路が適用されたかlogを確認します。vLLMやSGLang用の配布版を選ぶときは、取得したnvidia/Qwen3.8-Flash-Next-NVFP4 checkpointがruntimeに合うか先に確認します。