モデル別実行レシピ
Qwen3.8-Flash-Nextの調整：DGX Spark 1台で動かすSGLang設定
Spark 1台でもFlash-Nextが速く動くという記録を見ると、同じコマンドを試したくなります。ただ、この構成はモデルをダウンロードするだけでは動きません。専用の圧縮版、PLE SSDパッチ、MTP、バックエンド設定をまとめて合わせる必要があります。まず、どの構成を再現するのか確認しましょう。
実行レシピ
機器別の設定
1人で使う場合
使う機器を選ぶと、起動コマンドと調整できる設定が表示されます。
プロファイル
Apple Mac Studio M4 Max (128GB)
メモリに収まる推奨ランタイム： oMLX (MLX 4ビット（GGUF Q4_K_Mとは別形式）) · ドキュメントに基づくランタイム設定
インストール後の初回実行や、毎日安定して使いたいときに
プロファイルのコンテキスト長
8,192 トークン
ランタイムのドキュメントに基づく初期設定です。下の手順に沿って調整し、速度を比べてください。
デコード速度の推定値
24.7 ~ 48.2 tok/s
1人で使う場合の推定値
最初のトークンまでの推定時間
8.8 ~ 17.1秒
プリフィル: 479 ~ 936 tok/s
推定メモリ使用量
約 107.85GB / 114GB
残余の余裕：少ない 6.2GB
サーバーアドレス
http://127.0.0.1:8000
ローカルのみ · 127.0.0.1
推定値は、計算ツールが推奨する量子化・高速化設定と 8,192トークンを基準にしています。上記の実行設定を測定した値ではありません。
このプロファイルの設定
| 設定値 | この設定にする理由 |
|---|---|
| モデルの重みMLX 4ビット（GGUF Q4_K_Mとは別形式） | MLXモデルのディレクトリを使います。Q4_K_MのGGUFとはファイル形式が異なります。 |
| 入力長の確認8,192 | リクエスト前にモデル設定の入力上限を確認してください。この起動コマンドではコンテキスト長を指定していません。 |
| KVキャッシュモデル設定で確認 | この起動コマンドではKVキャッシュの精度を指定していません。 |
| プリフィルのバッチサイズランタイム設定で確認 | llama.cppのbatch-sizeとubatch-sizeを、MLXの設定値としてそのまま使わないでください。 |
| 同時リクエスト数1 | 1件のリクエストの速度を測ります。複数リクエストを合わせた処理量とは分けて確認します。 |
| メモリの余裕2GB以上 | モデルの読み込み後に、実際のメモリ使用量とスワップの有無を確認します。 |
Studio M4 Max 128GB 実行コマンド（oMLX)
MODEL_DIR="$HOME/.omlx/models"
omlx serve \
--model-dir "$MODEL_DIR" \
--host 127.0.0.1 \
--port 8000 \
--max-concurrent-requests 1 \
--memory-guard balanced起動後の確認
- 01起動ログで、モデルの読み込み完了と実際のコンテキスト長を確認します。
- 02ウォームアップ後はリクエストを1件ずつ送ります。同じ長さの異なる入力を3つ使い、キャッシュを再利用しない初回の処理時間を記録します。
- 03同じ入力を繰り返した結果は、キャッシュ再利用の記録として分けます。初回入力の結果と混ぜないでください。
- 04プリフィルtok/s、デコードtok/s、ピークメモリをまとめて記録し、その後は一項目ずつ変更します。
変わる点と注意点
- コンテキスト長と同時リクエスト数を控えめにしているため、機器の最大処理量より低い結果になることがあります。
使う際の注意点
- 内蔵n-gramテーブルも常に存在しているため、表示された総ロードメモリに基づいて文脈を取得する必要があります。
1つずつ調整
高速化の手順
複数の値を一括で変更すると原因を特定するのが難しいです。
- STEP 1
基準値を保存
初回入力とキャッシュ再利用を分け、それぞれ3回記録します。プリフィル、デコード、ピークメモリを一緒に比較します。
とき： エラーがある場合やメモリの余裕が2GB未満の場合は、次の段階へ進まないでください。
- STEP 2
プリフィルのチャンクサイズを調整
1,024 → 2,048 → 4,096の順に増やし、長い入力のTTFTとピークメモリを比べます。
とき： TTFTが短くならない場合やピークメモリが急増する場合は、直前の値へ戻します。
- STEP 3
KVキャッシュ調整
コンテキスト長を確保したいときだけ、同じ質問でQ8キャッシュとF16/BF16の基準値を比較します。
とき： 出力に差が出る場合や、必要なコンテキスト長をすでに確保できている場合は、標準の精度を維持します。
- STEP 4
MTP・投機的デコーディング
対応モデルだけで有効にし、コードと通常の文章を分けて、採用率と実際のデコードtok/sを測定します。
とき： 3回の中央値が基準値より良くならなければ、無効に戻します。
- STEP 5
コンテキスト拡張
実際に必要な長さまで段階的に2倍ずつ伸ばし、入力途中の情報を見つけられるかと、スワップの有無を確認します。
とき： 情報を探す精度が落ちたり、スワップ・メモリ圧縮が始まったりしたら、一段階短くします。
自分の機器の測定記録を送る
同じ条件で3回以上測定したJSONを読み込んでください。送信ボタンを押すまでは、このブラウザ内でのみ確認します。
受け付けるのは機器・モデル・実行条件と測定値だけです。プロンプト・回答・元のログ・ファイルパスは含めないでください。
記録ファイルがなければ、起動中のローカルサーバーと測定ツールで作成できます。Node.js 20以上が必要です。結果の自動送信は行いません。
内容を確認したユーザーの投稿記録です。このサイトが直接測定した結果とは区別しています。
設定の問題を報告
この設定でどこにつまずいたかを教えてください。報告を読めるのは管理者だけです。
報告する設定 · Studio M4 Max 128GB · Qwen3.8-Flash-Next · バランス
モデル名が同じでも、構成が同じとは限らない
この構成は、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台構成と比べてください。購入の判断には、公開記録の最高速度より、自分の環境で繰り返し得られる結果を使います。
NVFP4で実行するには
PLEの格納方式によってファイルサイズが変わります。Spark単体では専用パッチの実行経路を確認してください。
vLLM / SGLang · nvidia/Qwen3.8-Flash-Next-NVFP4
変更履歴
サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。
Flash-Nextの記事と実行プロファイルの設定を統一
本文のプリフィルチャンクを公開スクリプトと同じ2,048に修正し、長いコンテキストのコマンドにもリクエスト上限1件を反映しました。公開測定の言語条件と、余裕を見た開始設定を区別しています。
Spark 1台でのFlash-Nextプリフィル値を訂正
キャッシュ再利用が混在した1,910 tok/sを、初回入力のプリフィル速度として示していた記述を削除しました。キャッシュを再利用しない条件での再測定が必要な状態に変更しました。
Flash-Next長文脈設定のリクエスト上限を調整
Spark 1台の262K文脈用コマンドで、実行リクエスト上限を4件から1件に減らしました。古いQSAパッチによる誤った出力を確認する手順も追加しました。
Macのモデル形式と実行設定を訂正
MacのMLX実行経路をGGUF Q4_K_Mと区別し、エンジン名・モデル形式・コマンドの表記を揃えました。コマンドで指定していないKVキャッシュ精度とプリフィルのバッチ設定は、モデル・ランタイム設定で確認する案内に変更しました。
コマンドは同じなのにバッチだけが大きくなるように見えていたMLX速度プロファイルも削除しました。
初回入力とキャッシュ再利用の記録を分離
検証手順を変更し、初めて読む入力と同じ入力を繰り返した結果を別々に記録するようにしました。キャッシュの効果を初回プリフィル処理量や機器の差に含めません。
機器・プロファイルの保存と再表示を追加
実行可能なプロファイルを機器の選択と一緒にこのブラウザに最大5件保存し、ガイド一覧から再び開けるようにしました。保存後に公開設定が変わったりプロファイルの提供が終了したりした場合は、実行前の再確認を案内します。
実行エンジンの説明へのリンクを追加
設定に表示されるエンジン名から、該当する実行プログラムの説明へ移動できるようにしました。エンジンを特定できない経路に、推測で別のプログラムをリンクすることはありません。