モデル別実行レシピ
最終更新
Qwen3.6 35B-A3Bの実行設定：Mac・RTX・DGX SparkのNVFP4
DGX SparkでvLLMを使いQwen3.6 35B-A3Bを実行します
Qwen3.6-35B-A3Bはテキスト入力を受けて回答を生成するMoE1モデルです。DGX Spark 1台ではNVIDIA ARM64・Blackwell向けvLLM containerと公式NVFP42 checkpoint3を組み合わせます。本稿ではモデルを読み込み、loopback API4で最初の応答を確認してからメモリと文脈optionを調整します。
NVFP4重み形式、container version、model IDを合わせる必要があります。NVFP4は重み形式で、FP85 KV cache6は文脈状態を保存する別設定です。まずTP1・文脈8K・request 1件でendpointを確認し、その後長文脈、同時request、MTP7を一つずつ試します。
速度推定とserver実測をまず区別します
以下3機器の速度ページは、入力4,096 token8・利用者1人の条件による計算上の推定値です。稼働中serverの測定結果ではないため、導入後の記録と混ぜません。
Q4_K_M・加速なしのMac mini M4 32GBでは、生成7.8～22.5 tok/s、初回token 5.5～15.7秒、入力処理263～757 tok/s、必要メモリ21.3GB、使用可能27GBと表示されます。NVFP4・MTPのDGX Spark 128GBでは、それぞれ61.2～111.1 tok/s、1.5～3.1秒、1,341～2,661 tok/s、必要24.3GB、使用可能116GBです。
DGX Spark 2台・256GB、Q4_K_M・加速なしの推定値は、生成17～61.4 tok/s、初回token 0.91～2.4秒、入力処理1,763～4,563 tok/s、必要メモリ21.3GB、使用可能232GBです。合計メモリでmodelを分割できますが、回答速度が自動的に2倍になるわけではありません。接続と分散設定が別途必要です。
containerとmodel fileを一つの構成として合わせます
DGX Sparkでは画像生成用や別architecture向けcontainerではなく、Spark用NVIDIA vLLM recipeを使います。本稿はGB10単体nodeを扱います。複数機器でRayやtensor parallel9を設定するrecipeは、networkと分散processが異なる別deploymentです。
Spark単体NVFP4 profileはvLLM v0.28.0 containerとnvidia/Qwen3.6-35B-A3B-NVFP4 repositoryを指定します。NVIDIA recipeにはRTX 5090とRTX PRO 6000向けprofileもありますが、このGB10設定をそれらのカードへコピーしません。各機器向け経路でkernel・メモリ設定・model fileへのaccessを確認します。
NVFP4はmodel重みに使う精度で、--kv-cache-dtype fp8はrequest文脈状態の保存形式を指定します。FP8 KV cache、MTP、文脈optionを一度に追加せず、まず公式Spark単体設定でendpointが起動するか確認します。
loopback endpointを開き最初の応答を確認します
基本確認はcontainer v0.28.0、TP1、文脈8K、同時request 1件で始めます。公式GB10経路のFlashInfer・Marlin・FP8 KV・メモリ利用率0.5を保ち、文脈とrequest数だけを下げたprofileです。host networkingでもserverを127.0.0.1にbindし、local accessに限定します。
logで重み読み込みとengine準備の完了を確認してから/v1/modelsをrequestします。一覧にqwen3.6-35b-a3bがあれば、chat completionのmodel欄にもその名前を使います。choices[0].message.contentに回答があればAPI接続を確認できています。この短い関数説明は動作確認でありbenchmarkではありません。
docker run --rm --gpus all --ipc=host --network host -v "$HOME/.cache/huggingface:/root/.cache/huggingface" vllm/vllm-openai:v0.28.0 nvidia/Qwen3.6-35B-A3B-NVFP4 --served-model-name qwen3.6-35b-a3b --host 127.0.0.1 --port 8000 --tensor-parallel-size 1 --trust-remote-code --kv-cache-dtype fp8 --attention-backend flashinfer --moe-backend marlin --gpu-memory-utilization 0.5 --max-model-len 8192 --max-num-seqs 1curl --fail-with-body http://127.0.0.1:8000/v1/models
curl --fail-with-body http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"qwen3.6-35b-a3b","messages":[{"role":"user","content":"Explain this function's empty-input behavior in one sentence: def first_item(items): return items[0]"}],"temperature":0,"max_tokens":64}'問題が起きた段階に合わせてoptionを変えます
serverが応答した後、既存recipeのFP8 KV、context limit、同時sequence設定を必要に応じて調整します。長い入力はrequestごとのcache使用量を増やし、同時requestは複数cacheを使うため、両方を同時に上げず一つずつ試します。
containerが起動しない場合はlogでimage tag、model IDとfile access、architecture対応を確認します。modelは読み込めてもrequest中にメモリエラーが出たら文脈か同時sequenceのどちらかを下げます。playbookにないoptionを足すより、起動時とrequest時の失敗をまず分けます。
2台のSparkにmodelを分割するRay構成を単一node commandに混ぜません。個人利用の応答性が目的なら、Spark 1台での回答時間とメモリ状態が十分か先に確認します。複数Sparkはnetworkと分散実行が必要な別の運用選択です。
同じ実作業で結果を評価します
短い関数確認の後、普段の作業をそのまま送ります。コード修正なら入出力条件とtestも含め、文書質問なら日付や項目など照合できる内容を尋ねます。起動command、container tag、model revision、prompt10、出力上限を記録するとoption変更の影響を比較できます。
自分で測定する場合はwarm-upを除き、反復requestの全体完了時間、GPU11 memory、回答精度を記録します。公式対応情報や計算上の速度推定は実行実測とは別の資料です。Qwen3 reasoning parserを使う場合は、vLLM 0.19.0以上でparserとmodelが実際に対応するか確認し、version番号だけで動作を判断しません。
公開されたoMLX 0.7.0のM5 Ultra結果は別platformの参考値です。M5 Ultra 256GB・80-core GPUでQwen3.6-35B-A3B 4-bit code_python試験を出力上限128 token、temperature 0で行い、4K prefill12は9,126 tok/s、decode13は158.3 tok/sでした。0.7.0rc1はそれぞれ7,931 tok/sと158.2 tok/sで、この項目ではprefillが増えましたがdecodeはほぼ同じです。この表だけでQwen3.6のMTPがdecodeを加速すると言うことはできません。
次の二分探索リクエストは汎用のモデルIDを使う例です。上のSparkコマンドでサーバーを起動した場合は、modelをqwen3.6-35b-a3bに変更します。別のサーバーでは/v1/modelsで実際の名前を調べます。LM Studioならポート1234とアプリで読み込んだモデル識別子を使います。
curl -N http://127.0.0.1:8000/v1/chat/completions -H "Content-Type: application/json" -d '{
"model": "Qwen/Qwen3.6-35B-A3B",
"messages": [
{"role": "user", "content": "파이썬으로 이진 탐색 함수를 작성하고 시간 복잡도를 설명해줘."}
],
"max_tokens": 1024,
"stream": true
}'
文脈と同時requestは必要に応じて一つずつ増やします
24GBのデスクトップでQ4変換版を選ぶなら、重みファイルは約20GBを出発点として確認します。実際のダウンロードサイズを調べ、KVキャッシュと実行環境の領域も残します。ここで紹介するSparkのNVFP4経路とはファイル形式と実行ツールが異なります。
24GBで余裕が少ないなら、まずrequest 1件・短い文脈で基準回答を確認します。必要な入力長を段階的に増やすたびcacheとpeak memoryを確認し、server上限と実入力token数を別に記録します。system instructionと以前の会話も入力長に含まれる場合があります。
MTPを追加したら、同じcode requestで採用長と最初のtoken後のdecode時間が変わるか確認します。code生成の結果を一般文章作成に一般化しません。cache精度、prefill chunk、MTPを同時に変更せず、実際に遅かった区間から試します。
短い基準requestは正常で長文脈だけOOMやswapが起きるなら、まずcontextまたは同時sequenceを下げます。target自体が読み込めない、あるいは短いrequestでもメモリ不足が続くなら、重みfileと実行メモリ条件を見直します。確認されたボトルネックに合わせて大容量メモリを検討します。
公式実行資料でversionを再確認します
以下の資料でSpark単体NVFP4 containerと公式vLLM checkpoint経路を確認できます。command実行前に現在のimage tag、model revision、対応optionを再照合します。
LM StudioではQ4ファイルを先に取得し、lms lsで確認してlms loadの一覧から選びます。API別名はqwen36-localです。LM Studioへは1234ポートとその別名を使い、前のSpark vLLMリクエストは8000ポートと既存別名を維持してください。
GPU_COUNT=8 # The official example uses 8 GPUs; change this to match your system
vllm serve Qwen/Qwen3.6-35B-A3B --host 127.0.0.1 --port 8000 --tensor-parallel-size "$GPU_COUNT" --max-model-len 8192 --reasoning-parser qwen3 --gpu-memory-utilization 0.92lms ls
lms load --gpu=max --context-length=8192 --identifier qwen36-local
lms server start --port 1234用語の注釈
MoE — 複数の専門家サブネットワークから入力に応じて一部を選ぶモデル構造です。総パラメータ数と1トークン処理時に有効な数は異なることがあります。
本文に戻るNVFP4 — NVIDIAが定義した4ビット浮動小数点データ形式です。対応状況はGPU世代、モデル、ソフトウェア実装によって異なります。
本文に戻るチェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。
本文に戻るAPI — 別のコードからプログラムの機能を呼び出すための決められたインターフェースです。
本文に戻るFP8 — 一つの値を8ビットで表す浮動小数点形式です。
本文に戻るKVキャッシュ — 過去トークンのAttention用キー・バリューを保存し、後続トークン生成で再利用するメモリです。容量はコンテキスト長やバッチサイズで変わります。
本文に戻るMTP — 複数の将来トークンを一度に予測する学習目標、またはそれを行うモデル構成です。投機的デコーディングでは、その予測を候補トークンとして提案できます。
本文に戻るトークン — モデルが入力や出力を分けて処理する単位です。
本文に戻るテンソル並列 — モデルの層内の行列や演算を複数の装置に分割して計算する方式です。部分結果をまとめるために装置間通信が必要です。
本文に戻るプロンプト — モデルに送る入力文です。生成モデルでは作りたい結果を説明する文になり、出力の構成や内容を大きく左右します。
本文に戻るGPU — 多くの計算を並列に処理するプロセッサーです。AIモデルの実行ではモデル計算を担います。
本文に戻るプリフィル — LLMが入力プロンプトを読み、各トークンの内部表現を計算する段階です。プロンプトが長いほど処理するトークンが増えます。
本文に戻るトークンのデコード — 入力とそれまでの回答をもとに、次の出力トークンを順に生成する段階です。
本文に戻る
よくある質問
- この記事で最初に確認すべきことは何ですか？
- Qwen3.6-35B-A3Bはテキスト入力を受けて回答を生成するMoEモデルです。DGX Spark 1台ではNVIDIA ARM64・Blackwell向けvLLM containerと公式NVFP4 checkpointを組み合わせます。本稿ではモデルを読み込み、loopback APIで最初の応答を確認してからメモリと文脈optionを調整します。
- 必要なメモリはどのくらいですか？
- Q4_K_M・加速なしのMac mini M4 32GBでは、生成7.8～22.5 tok/s、初回token 5.5～15.7秒、入力処理263～757 tok/s、必要メモリ21.3GB、使用可能27GBと表示されます。NVFP4・MTPのDGX Spark 128GBでは、それぞれ61.2～111.1 tok/s、1.5～3.1秒、1,341～2,661 tok/s、必要24.3GB、使用可能116GBです。
実行レシピ
機器別の設定
1人で使う場合
使う機器を選ぶと、起動コマンドと調整できる設定が表示されます。
プロファイル
Apple MacBook Pro M5 Pro (64GB)
メモリに収まる推奨ランタイム： oMLX (MLX 4ビット（GGUF Q4_K_Mとは別形式）) · ドキュメントに基づくランタイム設定
インストール後の初回実行や、毎日安定して使いたいときに
プロファイルのコンテキスト長
16,384 トークン
ランタイムのドキュメントに基づく初期設定です。下の手順に沿って調整し、速度を比べてください。
デコード速度の推定値
22.6 ~ 54.1 tok/s
1人で使う場合の推定値
最初のトークンまでの推定時間
8.9 ~ 21.2秒
プリフィル: 774 ~ 1,854 tok/s
推定メモリ使用量
約 21.91GB / 56GB
残余の余裕：少ない 34.1GB
サーバーアドレス
http://127.0.0.1:8000
ローカルのみ · 127.0.0.1
推定値は、計算ツールが推奨する量子化・高速化設定と 16,384トークンを基準にしています。上記の実行設定を測定した値ではありません。
このプロファイルの設定
| 設定値 | この設定にする理由 |
|---|---|
| 重みMLX 4ビット（GGUF Q4_K_Mとは別形式） | MLXモデルのディレクトリを使います。Q4_K_MのGGUFとはファイル形式が異なります。 |
| 入力長の確認16,384 | リクエスト前にモデル設定の入力上限を確認してください。この起動コマンドではコンテキスト長を指定していません。 |
| KVキャッシュモデル設定で確認 | この起動コマンドではKVキャッシュの精度を指定していません。 |
| プリフィルのバッチサイズランタイム設定で確認 | llama.cppのbatch-sizeとubatch-sizeを、MLXの設定値としてそのまま使わないでください。 |
| 同時リクエスト数1 | 1件のリクエストの速度を測ります。複数リクエストを合わせた処理量とは分けて確認します。 |
| メモリの余裕2GB以上 | モデルの読み込み後に、実際のメモリ使用量とスワップの有無を確認します。 |
MBP M5 Pro 64GB 実行コマンド（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、ピークメモリをまとめて記録し、その後は一項目ずつ変更します。
変わる点と注意点
- コンテキスト長と同時リクエスト数を控えめにしているため、機器の最大処理量より低い結果になることがあります。
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以上が必要です。結果の自動送信は行いません。
内容を確認したユーザーの投稿記録です。このサイトが直接測定した結果とは区別しています。
設定の問題を報告
この設定でどこにつまずいたかを教えてください。報告を読めるのは管理者だけです。
報告する設定 · MBP M5 Pro 64GB · Qwen3.6 35B-A3B (MoE) · バランス
変更履歴
サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。
Macのモデル形式と実行設定を訂正
MacのMLX実行経路をGGUF Q4_K_Mと区別し、エンジン名・モデル形式・コマンドの表記を揃えました。コマンドで指定していないKVキャッシュ精度とプリフィルのバッチ設定は、モデル・ランタイム設定で確認する案内に変更しました。
コマンドは同じなのにバッチだけが大きくなるように見えていたMLX速度プロファイルも削除しました。
初回入力とキャッシュ再利用の記録を分離
検証手順を変更し、初めて読む入力と同じ入力を繰り返した結果を別々に記録するようにしました。キャッシュの効果を初回プリフィル処理量や機器の差に含めません。
機器・プロファイルの保存と再表示を追加
実行可能なプロファイルを機器の選択と一緒にこのブラウザに最大5件保存し、ガイド一覧から再び開けるようにしました。保存後に公開設定が変わったりプロファイルの提供が終了したりした場合は、実行前の再確認を案内します。
実行エンジンの説明へのリンクを追加
設定に表示されるエンジン名から、該当する実行プログラムの説明へ移動できるようにしました。エンジンを特定できない経路に、推測で別のプログラムをリンクすることはありません。