モデル別実行レシピ
DGX Sparkでllama.cppのMTPサーバーを起動する：Qwen3.6エージェント向け
モデルを起動するだけでなく、前のthinking履歴が次のリクエストに引き継がれるか確認します。
DGX Sparkでローカルエージェント向けのQwen3.6-35B-A3B MTP1サーバーを立てるには、GB10向けのllama.cpp CUDA2ビルドを用意し、MTPを含むQ4_K_XL GGUF3を選びます。`preserve_thinking`はQwenのinterleaved thinking履歴を後続ターンに保持します。モデルの応答、MTP draftの初期化、複数ターンAPI4の順に確認します。
35Bという数字より、Sparkで確認済みのモデルファイルから始める
コードエージェントがリポジトリの修正案を出し、テストログを受け取って修正する場面を考えます。チャットURLを入力するだけに見えても、サーバーのモデルにMTP headが含まれ、リクエスト形式がthinking履歴を引き継ぐ必要があります。このレシピでは1台のDGX SparkからQwen3.6-35B-A3BをOpenAI互換endpointで提供します。
NVIDIAのllama.cpp playbookはDGX Spark、DGX OS、128GB unified memory5、CUDA architecture `121a-real`を指定しています。モデルのダウンロードは約35GBで、llama.cppのビルドにも容量が必要なため、空きディスクを確認してください。playbookはモデル重みとKV cache6用に約30GBの空きメモリを挙げていますが、実際の必要量は同時に使うアプリやcontext長で変わります。
使用するモデルは`unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q4_K_XL`です。名前にMTPとあっても、別の量子化7リポジトリや通常のQ4ファイルにMTPが含まれるとは限りません。大きなファイルなのでHugging Faceへのアクセス、ネットワーク、ダウンロード再開を準備してください。
Spark専用のCUDAビルドを用意する
DGX SparkでLinuxターミナルを開き、Git、CMake、CUDA Toolkitが使えることを確認します。以下はNVIDIA文書にある依存関係の導入とソースビルド手順です。`-DGGML_CUDA=ON`はCUDA backendをビルドし、`121a-real`はSparkのGB10 GPU8 architectureを指定します。同じcloneで再ビルドする場合、実行ファイルのバージョンとソースrevisionを記録してください。
ビルド後、`build/bin/llama-server --version`で実行ファイルの生成を確認します。CUDAが見つからない場合は`nvcc --version`とPATHを確認してください。別のGPU architecture向けビルドは成功してもSparkのGPUを認識しないことがあるため、RTX向け設定を流用しないでください。
sudo apt update
sudo apt install -y git clang cmake libcurl4-openssl-dev libssl-dev
git clone https://github.com/ggml-org/llama.cpp ~/llama.cpp
cd ~/llama.cpp
cmake -B build -DGGML_NATIVE=ON -DGGML_CUDA=ON -DGGML_CURL=ON -DGGML_RPC=ON -DCMAKE_CUDA_ARCHITECTURES=121a-real
cmake --build build --config Release --target llama-server -j
./build/bin/llama-server --versionまずローカル専用endpointを起動する
このSpark上のエージェントアプリだけが接続するため、`--host 127.0.0.1`でloopbackにバインドします。NVIDIAの例にある`0.0.0.0`は他の端末からも接続できるので、ネットワークに公開する意図がなければ使わないでください。`-hf`はHugging Face GGUFをcacheにダウンロードし、モデルが対応していればvision projectorも自動で読み込みます。
初回起動には数十GBのモデルのダウンロードとCUDAへの読み込みが含まれます。サーバーターミナルに`server is listening`と表示されるまではAPIを利用できません。CPU9とGPUは128GB unified memoryを共有するため、モデル容量を差し引くだけでは空き容量を保証できません。context、OS、ほかのアプリの使用量も記録してください。
MTPを有効にするコマンドには`--spec-type draft-mtp`と`--spec-draft-n-max 3`を指定します。これはNVIDIAの互換例の値であり、似た名前のcheckpoint10や別モデルにそのまま適用しないでください。`preserve_thinking`はテンプレートが生成したthinking blockを次のturn履歴に残し、エージェントが済ませた推論を会話から失わないようにします。
cd ~/llama.cpp/build
./bin/llama-server -hf unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q4_K_XL --host 127.0.0.1 --port 30000 --chat-template-kwargs '{"preserve_thinking":true}' --spec-type draft-mtp --spec-draft-n-max 3 --alias qwen3.6-35b-a3b --ctx-size 8192 -ngl 99
health checkの後に短いAPIリクエストを送る
サーバーログでモデルの読み込みと`speculative decoding11 context initialized`を確認してから、別のSparkターミナルでhealth endpointを確認します。このログはMTP contextの初期化を示すもので、常に速くなるという測定結果ではありません。起動に失敗したら、まずモデルのダウンロード、CUDA build、メモリエラーを確認します。
次に、サーバー上のmodel IDを指定し、OpenAI互換の`/v1/chat/completions`へ一文のリクエストを送ります。応答が返ればendpointへの接続を確認できました。ここまではsmoke testであり、速度測定ではありません。コードエージェントは同じ会話IDとhistoryで修正依頼を続けます。アプリがthinking blockを削除または書き換えると、`preserve_thinking`でも失われた内容は保持できません。
複数ターンの確認では、最初のturnで関数と要件を送り、2回目は同じ会話にテストログを加えて、失敗原因だけを直すよう依頼します。回答が先の修正案とテスト結果を結び付けるか確認してください。API wrapperがmessage historyを再送するか、raw responseにthinking contentを表示するかは、アプリ設定とモデルのresponse formatによって異なります。
curl --fail-with-body http://127.0.0.1:30000/health
curl --fail-with-body http://127.0.0.1:30000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"qwen3.6-35b-a3b","messages":[{"role":"user","content":"Review this Python function for empty-list input and suggest a minimal fix: def first_item(items): return items[0]"}],"max_tokens":128,"temperature":0}'
エージェント会話と速度試験を分ける
最初の応答を確認したら、同じ会話historyで2回目のリクエストを送り、thinkingが引き継がれるか確認します。長いcontextを使うコードエージェントでは履歴とコードファイルの両方がcontextを消費します。NVIDIAのplaybookはagentic/coding作業で最低32K、できれば100K以上を推奨しますが、すべてのSpark構成で余裕をもって使える保証はありません。実際のリポジトリ入力と他のアプリのメモリを考慮して設定してください。
速度を比較する際は、model revision、入力、生成上限を固定し、ウォームアップ後に測定します。初期化ログとserver timingsまたはspeculative統計でMTPが有効か確認します。応答速度を比較するには、baseline commandからMTPオプションだけを外し、同じ質問を複数回送ります。初回ダウンロードとモデル読み込み時間はgeneration結果に含めません。NVIDIAのplaybookはこの組み合わせの直接比較tok/s値を示していないため、数値を推定したり作ったりしないでください。
まずmodel ID、backend、メモリを見直す
`curl: (7) Failed to connect`はモデル速度の問題ではありません。サーバーがlistening状態か、clientとserverが同じSpark上の`127.0.0.1`とport `30000`を使うか確認します。起動中に終了した場合は、標準エラーでHugging Faceのモデル名の誤り、ダウンロード失敗、CUDA初期化問題、OOMメッセージを探します。
サーバーは起動したのに応答がない、または文章が不自然な場合は、MTP互換GGUFを選んだか、実行ファイルが`draft-mtp`を初期化したか、エージェントが同じmodel IDとchat templateを使うか確認します。`preserve_thinking`をtrueにしてもアプリがhistoryを自動保持するわけではありません。2回目のリクエストのmessagesに必要な過去turnが含まれているか確認してください。
メモリ不足なら、まず他のアプリと不要なcontextを減らし、必要なら`--ctx-size`で明示的な上限を設定します。長いエージェントセッションでcontextを減らすと履歴の一部をモデルが参照できなくなるため、単なる速度設定として扱わないでください。別の量子化ファイルに変える場合、新しいファイルのMTP headと対応状況も確認します。
公式の実行資料
インストールと対応条件は以下の公式資料で確認しました。再現する際は使用したモデルとランタイム12のバージョンも記録してください。
用語の注釈
MTP — 複数の将来トークンを予測する学習方式またはモデル構成です。生成速度への効果は実装や実行条件によります。
本文に戻るCUDA — NVIDIA GPUで汎用計算を行うソフトウェア基盤です。CUDA向けのプログラムが他のGPUでそのまま動くとは限りません。
本文に戻るGGUF — モデル情報を格納するファイル形式で、llama.cpp系のツールで広く使われます。形式だけで特定ハードウェアへの対応や速度が保証されるわけではありません。
本文に戻るAPI — 別のコードからプログラムの機能を呼び出すための決められたインターフェースです。APIという言葉だけで外部サーバーへの送信を意味するわけではありません。
本文に戻るユニファイドメモリ — CPUとGPUが同じ物理メモリ領域を共有する構造です。メモリ総量が増えるわけではなく、利用可能量はシステムによります。
本文に戻るKVキャッシュ — 過去トークンのAttention用キー・バリューを保存し、後続トークン生成で再利用するメモリです。容量はコンテキスト長やバッチサイズで変わります。
本文に戻る量子化 — モデルの数値を少ないビット数で表す方法です。メモリ使用量のほか、精度や実行速度も変わることがあり、影響は形式と実装によります。
本文に戻るGPU — 多くの計算を並列に処理するプロセッサーです。AIモデルの実行ではモデル計算を担います。
本文に戻るCPU — コンピューターで汎用のプログラム命令を実行する中央処理装置です。AI処理ではGPUなど他のプロセッサーと役割を分けることがあります。
本文に戻るチェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。
本文に戻る投機的デコーディング — 出力候補を先に提案し、メインモデルが検証する生成手法です。候補は別のドラフトモデル、MTPヘッド、文脈内の反復箇所の検索などで作れます。速度への効果は実装や条件によって異なります。
本文に戻るランタイム — プログラムの実行時に必要な機能を提供するソフトウェア環境です。ローカルAIではモデル実行エンジンを指すこともあり、GPUランタイムライブラリと完成したサービングアプリは別の構成要素です。
本文に戻る