モデル別実行レシピ

DeepSeek-V4-Flash:304Bモデルの分散実行設定

4×GB300サーバーでDeepSeek-V4-Flashをserveします

DeepSeek-V4-Flash-0731は質問やコードを入力し、テキスト回答とコードを生成するMoE1モデルです。公式vLLM例は4基のGB300で構成された単一ノードで、全304Bチェックポイント2をexpert parallelismで実行します。チーム用コードレビューサーバーの起動と質問の送信手順を説明します。

この手順では、チームのrepositoryから変更された関数、呼び出し元、関連テストを受け取り、影響と確認すべきファイルを返す社内ツールを想定します。まず公式サーバー環境とcheckpointを用意し、16K contextで1件のリクエストを確認してから、local API3のstreamingと実際のテストに関する回答を調べます。

実行条件と要点
  • 13B activeはtokenごとの計算経路で、公式checkpoint全体は304Bです。
  • 公式vLLMコマンドは4×GB300ノード、expert parallel、DSpark構成を組み合わせます。
  • 127.0.0.1のlocal bindと16Kの初期contextで、まず1件のリクエストを確認します。
機器別の実行設定へ移動

13B activeと304B totalが示す内容を分けます

DeepSeek-V4-Flash-0731はMixture-of-Expertsモデルで、token4ごとに選ばれた専門家経路が計算に参加します。active約13Bはtokenごとに使われる規模で、公式checkpoint全体は約304Bです。runtime5はリクエストに応じて選ばれる全重みにアクセスする必要があるため、サーバーへの搭載条件を13Bだけで計算できません。

公式vLLM例は単一の4×GB300ノードとexpert parallelを使います。acceleratorを別のカード4枚に置き換えても同じ実行環境にはなりません。各機器のメモリと接続、必要なkernel、runtime対応が例と合うか確認してください。

小さなブロックと書類が漏斗を通って大きな格子ブロックにつながり、下にノートPC4台が接続された図
tokenごとに使う約13Bの経路と、用意する全304B checkpointを区別します。

公式サーバー環境を用意し16K contextから始めます

このコマンドはデータ並列サイズ 4、expert parallelism、DSpark speculative decoding6 を設定します。データ並列はリクエスト処理グループを作り、expert parallelism は専門家重みの計算経路を分割します。

この組み合わせは重み全体を 4 回複製する設定ではありません。以下のオプションは、このモデルと対応するサーバーソフトウェア向けの例です。別のエンジンに切り替える場合は、そのエンジンが対応する設定を使ってください。

contextは16Kから確認します。短い接続リクエストが成功してから実務入力を送ると、サーバー読み込みの問題と長い入力の処理問題を区別できます。model repositoryのコード実行を許可するoptionがあるため、開始前にrepositoryと使用versionを確認し、組織で承認されたコード経路か確認してください。

vLLMの公式分散構成(マルチGPUサーバーノード)
vllm serve deepseek-ai/DeepSeek-V4-Flash-0731   --host 127.0.0.1   --port 8000   --trust-remote-code   --data-parallel-size 4   --enable-expert-parallel   --kv-cache-dtype fp8   --block-size 256   --moe-backend deep_gemm_mega_moe   --attention-config '{"use_fp4_indexer_cache": true}'   --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'   --max-model-len 16384   --gpu-memory-utilization 0.90
公式4×GB300 vLLM・DSpark例を16K context、127.0.0.1 local bindで実行します。

local API接続と実際のコード質問を順に確認します

サーバーの準備ができたら、まず短いストリーミングリクエストを送ります。応答チャンクが届き、リクエストが正常に終了することを確認してください。以下のテストは 127.0.0.1:8000 の chat completion API に最大 512 トークンを要求します。

接続できたら、変更した関数と呼び出し側、関連テストを入力し、影響範囲と確認すべきファイルを尋ねます。回答に実際のテストファイルが含まれているかも確認してください。

最初のtoken到着時刻と回答終了時刻を、実際の出力token数と一緒に記録します。同じリクエストを3回繰り返す場合は先にwarm-upを行い、初回入力とcache再利用入力を区別してください。リクエストが完了しても情報が抜ける場合、変更関数とテストが入力に含まれていたか、モデルが示したpathとファイル内容が実際に正しいか確認します。

DSpark実行では提案候補数ではなく、モデルの検証を通って実際の出力に含まれたtoken数と完了時間を比べます。チームの複数リクエストを同時に送る試験は、1件ずつ送った記録と分けてください。全体処理量が増えても各ユーザーの初回応答や完了待ちが長くなることがあります。

ローカルのチャット補完ストリーミングをテスト
curl -N http://127.0.0.1:8000/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "deepseek-ai/DeepSeek-V4-Flash-0731",
    "messages": [
      {"role": "user", "content": "DeepSeek-V4-Flash 분산 서빙 테스트."}
    ],
    "max_tokens": 512,
    "stream": true
  }'
127.0.0.1:8000 APIからstreaming応答のchunkが届くか確認します。
色の印がある長い紙がサーバーの区画につながり、虫眼鏡で出力ブロック列を調べる図
streamingのchunk、実際の出力token数、応答完了時刻を一緒に記録します。

実行が失敗した段階に応じて最初の確認先を変えます

短いリクエストも始まらない場合は、サーバーログでcheckpoint読み込み、分散設定、kernel互換性のエラーを確認します。短い質問は動くのに長い入力だけ失敗する場合は、入力token数、peak memory、入力長を並べて記録してください。16K contextに戻して入力を少しずつ増やすと、どこから停止するか分かります。

メモリは合計だけでなく、同じ時点の機器ごとの使用量とエラーが起きたnodeを確認します。他のprocessがacceleratorを使っていたかも記録すると、搭載容量不足と実行中の競合を区別しやすくなります。expert parallelの分配が一部機器に偏ったり、KV cache7が特定nodeで先に上限に達したりする場合があります。

リクエストが完了したのに誤ったテストを示した場合、GPU8構成を変える前に入力したファイル範囲と回答の根拠を確認します。読み込み段階で止まるなら、最後に動作したcheckpointと分散設定へ戻してください。条件を一つずつ変え、同じ基準質問を再送すると原因を絞り込めます。

NVFP4経路では検証済みacceleratorとkernelを別に確認します

公式の検証対象はB200です。RTXとSparkでは別途互換kernelが必要で、DSpark headは別の精度を維持します。これらの条件を公式serveコマンドと混同せず、NVFP49実行で使うruntimeとkernelの組み合わせが対応するか確認してください。

直接運用が実際の課題を解決し責任範囲に合うか判断します

導入理由はモデルの大きさではなく、現在のツールが実際に見落とす業務条件から探します。小型モデルが変更影響を繰り返し見落とすか、チームの同時リクエストが待ち行列を作るか、基準質問で記録してください。一人の作業に小型候補で足りるなら4×GB300サーバーを用意する必要はありません。

サーバー運用を決めたら、checkpointとruntimeのversion、GPUごとの使用量、各リクエストの初回応答・完了時刻、エラー後に戻す設定を記録します。機能確認に通った後、同じ種類の質問を同時に送り、処理量と各ユーザーの待ち時間を別々に測定すると、必要機器と管理負担を実際の運用要件に合わせられます。

色とりどりのブロックが収納棚に入り、反対側の線が人の持つ黄色い多面体へ集まる図
サーバーを直接運用する必要性は、繰り返し発生する業務課題とチームの保守責任で判断します。

用語の注釈

  1. MoE — 複数の専門家サブネットワークから入力に応じて一部を選ぶモデル構造です。総パラメータ数と1トークン処理時に有効な数は異なることがあります。

    本文に戻る
  2. チェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。

    本文に戻る
  3. API — 別のコードからプログラムの機能を呼び出すための決められたインターフェースです。

    本文に戻る
  4. トークン — モデルが入力や出力を分けて処理する単位です。

    本文に戻る
  5. ランタイム — プログラムの実行時に必要な機能を提供するソフトウェア環境です。ローカルAIではモデル実行エンジンを指すこともあります。

    本文に戻る
  6. 投機的デコーディング — ドラフトモデル、MTPヘッド、反復文脈の検索が出力候補を先に作り、メインモデルが検証して確定する生成手法です。

    本文に戻る
  7. KVキャッシュ — 過去トークンのAttention用キー・バリューを保存し、後続トークン生成で再利用するメモリです。容量はコンテキスト長やバッチサイズで変わります。

    本文に戻る
  8. GPU — 多くの計算を並列に処理するプロセッサーです。AIモデルの実行ではモデル計算を担います。

    本文に戻る
  9. NVFP4 — NVIDIAが定義した4ビット浮動小数点データ形式です。対応状況はGPU世代、モデル、ソフトウェア実装によって異なります。

    本文に戻る

よくある質問

この記事で最初に確認すべきことは何ですか?
DeepSeek-V4-Flash-0731は質問やコードを入力し、テキスト回答とコードを生成するMoEモデルです。公式vLLM例は4基のGB300で構成された単一ノードで、全304Bチェックポイントをexpert parallelismで実行します。チーム用コードレビューサーバーの起動と質問の送信手順を説明します。
必要なメモリはどのくらいですか?
公式vLLM例は単一の4×GB300ノードとexpert parallelを使います。acceleratorを別のカード4枚に置き換えても同じ実行環境にはなりません。各機器のメモリと接続、必要なkernel、runtime対応が例と合うか確認してください。

実行レシピ

機器別の設定

1人で使う場合

使う機器を選ぶと、起動コマンドと調整できる設定が表示されます。

使用可能メモリ: 236GB / 帯域幅: 1200GB/s

Apple Mac Studio M5 Ultra (256GB)

実験的な構成

推奨ランタイム: 圧縮ランタイム検証が必要 (Q4圧縮重み(アーテファクト・ランタイム検証が必要)) · 実験的な構成(検証が必要)

プロファイルのコンテキスト長

4,096 トークン

デコード速度の推定値

112.5 ~ 125 tok/s

1人で使う場合の推定値

最初のトークンまでの推定時間

10.8 ~ 18.8秒

プリフィル: 218 ~ 378 tok/s

推定メモリ使用量

約 180.53GB / 236GB

残余の余裕:少ない 55.5GB

サーバーアドレス

http://127.0.0.1:1234

ローカルのみ · 127.0.0.1

推定値は、計算ツールが推奨する量子化・高速化設定と 4,096トークンを基準にしています。上記の実行設定を測定した値ではありません。

このプロファイルの設定

設定値この設定にする理由
量子化とモデルファイルQ4量子化済みの重み(ファイルとランタイムの検証が必要)· $MODEL_PATH1人でのデコード時に、重みの転送量と読み込みに必要なメモリをまず減らす初期設定です。
開始時のコンテキスト長4,096トークン重み・KVキャッシュ・ランタイムの余裕を残したまま、ネイティブ1024Kを即座に割り当てるものではない
バインド先アドレス127.0.0.1:1234認証のないローカルサーバーが外部ネットワークに露出しないように、ループバックにのみバインディングする
GPUオフロードと分割単一ユニファイドメモリ全体のロード検証重みを高速メモリに置き、CPU・RAMへのオフロードによるボトルネックを避けます。
Flash Attentionモデルの互換性を確認した後、選択ランタイムでアクティブ化するプリフィル時や長いコンテキストで、アテンションのメモリ使用量を減らす設定です。
KVキャッシュ基本精度でロード後、q8_0を別途検証メモリ使用量を抑えつつ、ランタイムが対応する精度だけを使います。
プリフィルのバッチとマイクロバッチランタイム設定で確認llama.cppのbatch-sizeとubatch-sizeを、MLXの設定値としてそのまま使わないでください。
同時要求数1個サーバー全体の処理量より、1人で使うときの最初のトークンまでの時間とデコードの遅延を優先します。

メモリに収まることと、実際に実行できることは別です。圧縮されたモデルファイルとランタイムの互換性を確認するまでは、コピー用の実行コマンドを表示しません。

使う際の注意点

  • 公式のvLLMサンプルでは、DP=4・EP構成の4×GB300ノードが使用されています。現在のカタログ設備については、同様のパスで表示していません。

1つずつ調整

高速化の手順

複数の値を一括で変更すると原因を特定するのが難しいです。

  1. STEP 1

    基準値を保存

    初回入力とキャッシュ再利用を分け、それぞれ3回記録します。プリフィル、デコード、ピークメモリを一緒に比較します。

    とき: エラーがある場合やメモリの余裕が2GB未満の場合は、次の段階へ進まないでください。

  2. STEP 2

    プリフィルのチャンクサイズを調整

    1,024 → 2,048 → 4,096の順に増やし、長い入力のTTFTとピークメモリを比べます。

    とき: TTFTが短くならない場合やピークメモリが急増する場合は、直前の値へ戻します。

  3. STEP 3

    KVキャッシュ調整

    コンテキスト長を確保したいときだけ、同じ質問でQ8キャッシュとF16/BF16の基準値を比較します。

    とき: 出力に差が出る場合や、必要なコンテキスト長をすでに確保できている場合は、標準の精度を維持します。

  4. STEP 4

    MTP・投機的デコーディング

    対応モデルだけで有効にし、コードと通常の文章を分けて、採用率と実際のデコードtok/sを測定します。

    とき: 3回の中央値が基準値より良くならなければ、無効に戻します。

  5. STEP 5

    コンテキスト拡張

    実際に必要な長さまで段階的に2倍ずつ伸ばし、入力途中の情報を見つけられるかと、スワップの有無を確認します。

    とき: 情報を探す精度が落ちたり、スワップ・メモリ圧縮が始まったりしたら、一段階短くします。

自分の機器の測定記録を送る

同じ条件で3回以上測定したJSONを読み込んでください。送信ボタンを押すまでは、このブラウザ内でのみ確認します。

受け付けるのは機器・モデル・実行条件と測定値だけです。プロンプト・回答・元のログ・ファイルパスは含めないでください。

記録ファイルがなければ、起動中のローカルサーバーと測定ツールで作成できます。Node.js 20以上が必要です。結果の自動送信は行いません。

内容を確認したユーザーの投稿記録です。このサイトが直接測定した結果とは区別しています。

変更履歴

サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。

  1. 機器・プロファイルの保存と再表示を追加

    実行可能なプロファイルを機器の選択と一緒にこのブラウザに最大5件保存し、ガイド一覧から再び開けるようにしました。保存後に公開設定が変わったりプロファイルの提供が終了したりした場合は、実行前の再確認を案内します。

  2. 実行エンジンの説明へのリンクを追加

    設定に表示されるエンジン名から、該当する実行プログラムの説明へ移動できるようにしました。エンジンを特定できない経路に、推測で別のプログラムをリンクすることはありません。