DeepSeek V4のローカル導入：Pro・Flashのメモリ、必要ハードウェア、API選択

DeepSeek V4 は、通常の 7B および 32B モデルと同じように理解することはできません。公式に発表された 2 つのバージョンはどちらも MoE モデルです。

• DeepSeek-V4-Pro: 合計パラメータ約 1.6T、各トークンは約 49B のパラメータを有効にします。
• DeepSeek-V4-Flash: 合計パラメータ約 284B、各トークンは約 13B パラメータをアクティブにします。

「少ない起動パラメータ」は主にシングルステップの計算量に影響し、起動パラメータ用にビデオメモリを用意するだけでよいというわけではありません。完全な重みがルーティングに含まれる場合でも、すべてのエキスパートの重みを保存する必要があります。単一のコンシューマ グラフィック カードの場合、多くの場合、完全なオンプレミス展開よりも公式 API の方がはるかに現実的です。

公式情報と本記事の推定を分ける

公式リリース ノートでは、モデル名、全体的なパラメーター、アクティベーション パラメーター、コンテキスト、および API の変更が確認されています。以下の低ビット ボリュームは数学的な推定値であり、公式 GGUF ファイルの実測値ではありません。また、コミュニティが直接実行できる量子化パッケージを提供していることを意味するものでもありません。

最も基本的な重量体積の公式は次のとおりです。

1

权重体积（GiB）≈ 参数量 × 每参数位数 ÷ 8 ÷ 1024³

量子化では、グループ化スケール、メタデータ、およびアライメントのオーバーヘッドも増加します。推論には KV キャッシュ、ランタイム バッファ、および通信スペースも必要となるため、実際のメモリはベアウェイトよりも大きくなければなりません。

理論上の重みサイズ

これらの数字は、「少なくともどのくらいの重さですか?」という答えにすぎません。たとえば、フラッシュの 4 ビットの重みは理論的には約 132 GiB です。実際の展開では、定量化されたメタデータ、KV キャッシュ、およびバックエンド バッファリング用にスペースを予約する必要があります。 Pro が 4 ビットであっても、すでにマルチマシンまたはハイエンド マルチカード サーバーの範囲内にあります。

コンテキストでメモリが増える理由

KV キャッシュは次の要因に関連しています。

• コンテキスト トークンの数。
• 同時リクエストの数とバッチサイズ。
• KV キャッシュ データ タイプ。
• モデル層の数、アテンション構造、バックエンド実装。
• プレフィックス キャッシュまたはその他の最適化を有効にするかどうか。

したがって、「1M コンテキストのサポート」は、ローカル コンピュータを 1M で起動する必要があるという意味ではなく、ビデオ メモリが変更されないままであるという意味でもありません。導入評価は、4K または 8K コンテキスト、単一同時実行から開始し、ピークを増やして記録する必要があります。

検証に値するハードウェア

「ロードできる」と「インタラクティブに使用できる」は別のことです。 CPU オフロードが大量に発生すると、最初のトークンと生成速度が非常に遅くなり、実用的な価値がなくなる可能性があります。

公式 API を使用した最小限の検証

DeepSeek 公式説明 V4 は OpenAI Chat Completions と互換性のある呼び出しを提供します。まずキーを環境変数に保存してから、最小限のリクエストを送信します。

1
2
3
4
5

$env:DEEPSEEK_API_KEY = "你的密钥"
curl.exe https://api.deepseek.com/chat/completions `
  -H "Authorization: Bearer $env:DEEPSEEK_API_KEY" `
  -H "Content-Type: application/json" `
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"只回复 OK"}]}'

は成功すると JSON を返し、応答内の choices のヘルパー メッセージを確認する必要があります。 401 が返された場合は、まずキーを確認してください。返されたモデルが存在しない場合は、公式のモデル リストを確認し、古い記事の名前を使用せずに再試行してください。

公式発表では、V4 がオンラインになった後、古い deepseek-chat と deepseek-reasoner が移行プロセスに入ったと指摘しています。モデル名、価格、および廃止日は変更される可能性があり、実稼働構成は最新の API ドキュメントに従う必要があります。

ローカル量子化パッケージのチェックリスト

将来、V4 の定量化された重みがコミュニティに表示される場合は、少なくとも以下を確認してください。

1. アップストリームが DeepSeek 公式ウェイト ウェアハウスを指しているかどうか。
2. ファイルがすべてのシャードとエキスパートをカバーしているかどうか。
3. 定量化アルゴリズム、校正データ、および推論バックエンドが公開されているかどうか。
4. バックエンドは、ファイル ヘッダーを読み取ることができるだけでなく、MoE アーキテクチャを明確にサポートしていますか。
5. テスト結果は、GPU、CPU、RAM、コンテキスト、同時実行性、およびトークン/秒を示していますか。
6. ハッシュ、ライセンス、ダウンロード ソースが検証可能かどうか。

実際のファイルやバックエンド テストがない場合、公開できるのは「容量の見積もり」だけであり、「特定のグラフィック カードは実際のテストに従って動作可能」と書くことはできません。

入手したものを最初に確認する

V4のローカル導入を論じる前に、ダウンロード対象を次の4種類に分けます。

1. 公式の完全重量;
2. 公式 API モデル名。
3. 第三者による重量の定量化または変換。
4. 名前が似ている非公式派生モデルのみ。

API 名を使用して重みが公開されていることを証明することはできません。また、Hugging Face リポジトリは、タイトルのみに基づいて完全な V4 が含まれていることを証明することもできません。ファイルが数 GB しかない場合は、アダプター、構成、トークナイザー、インデックス、または不完全なシャードである可能性が高くなります。

数百ギガバイトのファイルをダウンロードする前に、リポジトリ ファイルのリストと合計サイズをチェックし、すべてのシャード番号が連続していることを確認してください。

生の重みからサーバー下限を見積もる

キャパシティ プランニングでは、「ビデオ メモリの合計が重量に正確に等しい」ことを解決策として使用することはできません。例として、V4 フラッシュの理論上の 4 ビット値を約 132 GiB とすると、以下も予約する必要があります。

• 定量化スケール、グループ化情報およびメタデータ。
• KVキャッシュ;
• CUDA/ROCm コンテキスト;
• アクティブ化および一時的な計算バッファー。
• 推論の枠組みがそれ自体で占められている。
• マルチカード通信とフォールトトレランスマージン。

エンジニアリングでは、すべてのカードを 100% にするのではなく、かなりのマージンを残す必要があることがよくあります。具体的な比率は対象フレームワークの実ログで確認する必要があります。

合計VRAMは最初の条件にすぎない

複数の GPU の合計ビデオ メモリがフラッシュに対応できると仮定すると、次のことを確認する必要があります。

• フレームワークが V4 のエキスパート ルーティングをサポートしているかどうか。
• 専門家またはテンソルによって重みを合理的に分割できるかどうか。
• カード間で NVLink、PCIe、またはクロスマシン ネットワークを使用するかどうか。
• 追加の埋め込み、出力レイヤー、またはバッファリングを担当するカードがあるかどうか。
• 最も遅いリンクがリクエスト全体を遅らせるかどうか。
• 単一マシンの電源、冷却、およびマザーボードのチャネルが十分かどうか。

ビデオ メモリの追加は、容量が可能であることを示すだけで、速度が利用可能であることはおろか、推論を開始できることも証明できません。

サーバー構成を段階的に検証する

ローカル V4 を本格的に学習したい場合は、受け入れを次のレベルに分けることをお勧めします。

レベル 1: 構成の特定

構成と重みインデックスのみを読み取り、モデル タイプ、シャードの数、dtype、エキスパート パラメーターが現在のフレームワークで認識できることを確認します。現時点ではすべての GPU を割り当てないでください。

レベル 2: 短いコンテキストをロードする

単一のリクエスト、つまり利用可能な最短のコンテキストから開始します。各 GPU とホストのメモリ使用量を記録し、CPU またはディスク マッピングへのサイレント フォールバックがないことを確認します。

レベル 3: 固定の短い回答を生成する

確定的なプロンプトを使用して 32 ～ 64 個の出力トークンをテストし、最初のトークンの遅延、生成速度、エラー ログ、およびカード間通信を観察します。

レベル 4: コンテキストを徐々に増やします

4K、8K、16K ごとに成長し、極端なコンテキストを直接テストしないでください。毎回再起動してピー​​ク値を記録し、以前のキャッシュの影響を排除します。

レベル 5: 同時実行性の向上

単一リクエスト後の同時実行性のテストのみが安定します。同時実行によりキャッシュ、スケジューリング、スループットが変更され、単一のリクエストに対して即座に OOM で構成が利用できるようになる可能性があります。

信頼できるマルチカードの実際のテストにはどのようなデータが必要ですか?

少なくとも公には：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

模型仓库与 commit：
权重格式与量化方法：
推理框架与 commit：
GPU 型号、数量、单卡显存：
CPU、系统内存、NUMA：
卡间连接与网络：
上下文、输入/输出 token：
并发与批大小：
每卡峰值显存：
首 token 延迟、tokens/s、总吞吐：
是否使用 CPU offload 或磁盘映射：

モデル ファイルとフレームワークのバージョンが見つからない場合、速度数値を再現できません。コンテキストと同時実行性が欠落している場合、メモリ数は比較の意味がありません。

公式APIの本番受け入れテスト

最小限のリクエストが成功した後は、レイテンシ、使用状況、エラー処理、およびモデルの切り替えも検証する必要があります。

PowerShell はリクエストの合計時間を記録できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$headers = @{
  Authorization = "Bearer $env:DEEPSEEK_API_KEY"
  'Content-Type' = 'application/json'
}

$payload = @{
  model = 'deepseek-v4-flash'
  messages = @(
    @{ role = 'user'; content = '将这段日志归纳为三条排错建议。' }
  )
  temperature = 0
} | ConvertTo-Json -Depth 5

$elapsed = Measure-Command {
  $response = Invoke-RestMethod `
    -Uri 'https://api.deepseek.com/chat/completions' `
    -Method Post `
    -Headers $headers `
    -Body $payload
}

$elapsed.TotalSeconds
$response.usage
$response.choices[0].message.content

レコード usage は、入力、出力、およびキャッシュの請求を確認するのに役立ちます。特定のフィールドと価格は、現在の公式 API ドキュメントに準拠します。

古いモデル名からの移行

構成ファイル内の文字列を単に置き換えないでください。完全な移行チェックを行うには、次の手順を実行します。

• 新しいモデル名が現在のアカウントおよび地域で利用可能かどうか。
• システム プロンプトとサンプリング パラメータに互換性があるかどうか。
• ストリーミング応答イベントが変化するかどうか。
• ツール呼び出し構造がクライアントによって正しく解析されるかどうか。
• 最大出力、コンテキスト、タイムアウトを調整する必要があるかどうか。
• 古いモデルのロールバック入口がまだ保持されているかどうか。

まずシャドウ テスト用の実動リクエストをコピーし、応答の品質、遅延、トークンの使用量、失敗率を比較し、その後トラフィックを徐々に切り替えます。

エラーコードはレイヤーで処理する必要があります

キーとデータの境界

API キーは、環境変数、システム認証情報ストア、またはチーム シークレット マネージャーに配置する必要があります。 Markdown、Git 構成、フロントエンド JavaScript で記述したり、スクリーンショットを共有したりしないでください。

企業データをクラウド API に送信する前に、次のことも明確にする必要があります。

• どのフィールドに個人情報または企業秘密が含まれるか。
• 減感作が必要かどうか。
• ログにはリクエスト本文が保持されるか、それともメトリクスのみが保持されるか。
• チームメンバーがキーを共有するかどうか。
• キー漏洩後のローテーションおよび失効プロセス。

データ ポリシーで完全にオフラインにする必要がある場合は、不透明なサードパーティ仲介者を使用して「オンプレミス」であるふりをするのではなく、既存のハードウェアに安定して展開できる小規模なオープンウェイト モデルを選択する必要があります。

誇張されたシングル カード プロモーションを見分ける方法

次の陳述には追加の証拠が必要です。

• 「49B がアクティブなので、必要なビデオ メモリは 49B だけです。」;
• 「4 ビットは、合計パラメータを直接 2 で割った値に等しい」;
• 「1M コンテキストではビデオ メモリは増加しません」;
• 「単一のカードが正常にロードされたため、スムーズに実行できます。」;
• 「同じ名前のモデルを使用しているので、正式な V4 である必要があります。」;
• 「スクリーンショットには 20GB が表示されており、使用量は完全なモデルです。」

信頼できるレポートでは、重みが完全であるかどうか、CPU 上のレイヤーの数、リモート API が使用されているかどうか、および速度の測定方法を説明する必要があります。

API とローカル モデルのどちらを選択するか

選択は、パラメーターの量を単に比較するのではなく、タスク、データ境界、レイテンシー、総コストに基づいて行う必要があります。

実用上の判断

• 個人および一般開発チーム: 公式 API の使用を優先します。
• データはイントラネットから流出できません。V4 を強制的にロードするのではなく、最初に小さいオープンウェイト モデルを評価します。
• 推論フレームワークについて調査します。フラッシュ、短いコンテキスト、単一同時実行から始めて、ソフトウェアとハ​​ードウェアを完全に記録します。
• 正確なシングル カード速度またはメモリ テーブルを確認するには、まず定量的なファイル、バックエンド ログ、およびテスト構成が公開されているかどうかを確認します。

DeepSeek公式資料

• DeepSeek V4 公式リリースノート
• DeepSeek API ドキュメント