なぜシャーディングが必要なのか？
You reach for sharding when 1 of 4 things is true:- The model is too large for 1 GPU. A 70B dense model at FP16 needs ~140 GB. Even at Q4 quantization (~35 GB), it fills a single RTX 4090 (24 GB). You need at least 2 GPUs to hold the weights.
- You need lower latency per token. When every GPU contributes to each token simultaneously, the wall-clock time per token drops.
- スループットを向上させたい場合 GPUの数が増えれば同時に処理できるユーザー数も増加します。
- 冗長性が必要な場合 ロードバランサーの背後で2個のレプリカを運用すれば、1基のGPUに障害が生じてもサービス停止を防げます。
GPUメモリが実際にどのように消費されるか
シャーディング戦略を選ぶ前に、VRAMを消費する要素が何かを把握しておきましょう。単にモデルの重みだけではありません。
容量が24ギガバイトのRTX 4090で70B Q4モデルを実行すると、重みデータのサイズは約35ギガバイトにもなります。これでは1 GPUには到底収まりません。TPを2に設定すると、各GPUに格納される重みデータは約17.5ギガバイトとなり、KVキャッシュやその他のオーバーヘッド用に約6.5ギガバイトが残ります。この量であれば短い文脈の処理や少数の同時接続ユーザーに対応可能ですが、それ以上は難しいでしょう。
実際に利用可能なメモリ量は総VRAM量より少ない。DGX Spark（統合メモリ量 128ギガバイト）では、OSやランタイムが必要分を確保した後、モデルやKVキャッシュ用に約110ギガバイトしか使えない。個別GPUの場合、vLLMの
--gpu-memory-utilizationパラメータ（デフォルト値は 0.90）がこの量を制御する。メモリ不足に陥る場合はこの値を下げて設定する必要がある。
こうした理由からエキスパート並列処理が存在するのだ。全ての231ギガバイト分のエキスパートを各GPUに読み込む代わりに、各GPUは割り当てられたエキスパートのみを保持する。下記の エキスパート並列処理 もご覧ください。
2つの判断基準：まず収容可能にし、次に高速化する
シャーディング機能は以下の2つの質問に順に答える 収容可能にする — 重みデータ（およびKVキャッシュ用の余裕領域）をGPUメモリの予算内に収める- まず量子化を行う。 FP16形式からQ4形式へ変換することで重みデータのメモリ使用量が約4倍削減できる。これが最も低コストで効果的な手段だ。 量子化ガイド も参照されたい。
- GPU間でシャーディングする。 量子化だけでは不十分な場合、TPやPP、EPを用いてモデルを分割する。
- Prune experts (MoE only). For MoE models with 256 experts where only 6 fire per token, REAP-style expert pruning cuts routed-expert weights roughly in half without touching active compute.
- 適切な並列化方式を選ぶ TPはトークンごとのレイテンシを最小にします。PPは通信速度が遅い環境でも耐性があります。DPはスループットを増大させます。
- Use the model’s documented speculative path. For
DeepSeek-V4-Flash-0731, enable the bundled DSpark module with the official vLLM or SGLang flags. Do not configure a separate draft checkpoint. See model serving and scaling. - KVキャッシュとバッチサイズを調整 KVキャッシュの余裕が多いほど同時接続可能なユーザー数が増えます。DGX Sparkメモリ調整もご参照ください。
The 4 sharding strategies at a glance
DeepSeek-V4-Flash-0731は実用的なシャーディング例です。13B個のパラメータのみが実際の計算に使われますが、全284B個のパラメータ分の重みメモリが必要です。DeepSeek V4 Flashローカルハードウェアにて各2デバイス経路の最低メモリ要件や実用性を確認できます。テンサー並列化：GPU間でレイヤーを分割する手法
テンサー並列化では各レイヤーの重み行列が複数のGPUに分散される。各GPUは各レイヤーの一部のみを保持し、全GPUが同一トークンの処理を同時に行う。1/N of the model weights, where N is the TP degree. A 70B model at Q4 (~35 GB) with TP=2 puts ~17.5 GB of weights per GPU.
レイテンシ：トークン単位で最も低い値となる。全GPUが各トークンの計算に参加するため、実際の処理時間は計算時間とAllReduce同期時間の合計となる。
Best for: 2–4 GPUs connected by NVLink or a fast PCIe bus. The 200Gb/s QSFP link between 2 DGX Sparks is ideal.
vLLMフラグ: --tensor-parallel-size 2
PCIe delivers 3–5× less bandwidth than NVLink for AllReduce operations. Tensor parallelism over PCIe still works — 2× RTX 4090 at TP=2 is a common setup — but expect 20–30% lower decode throughput than the same model on NVLink-connected GPUs.
Example: 70B on 2× RTX 4090
パイプライン並列化：レイヤーを順次分割する方式
パイプライン並列化（PP）では隣接するレイヤー群を異なるGPUに割り当てる。GPU 0はレイヤー 0～19を、GPU 1はレイヤー 20～39を担当する。トークンは組立ラインのようにパイプライン内を流れていく。--pipeline-parallel-size 2
いかなる場合にPPがTPよりも有利となるか
以下の場合にはテンサー並列化よりもパイプライン並列化を利用すべきだ：- GPUが異なるマシン上にあり、ネットワークで接続されている場合（10GbE～100GbE）。
- GPU同士はPCIeで接続されており、モデル自体も十分に小さいため、パイプライン並列化によるメモリ消費の増加分がテンソル並列化のためのAllReduce通信コストよりも少なくて済む。
- 複数の3+ノードを連結して利用する場合、これら全ノードでテンソル並列化を行うと相互接続帯域が飽和してしまう。
データ並列化とは、複数のGPU上で同一のモデルを実行することだ。
データ並列化（DP）では各GPUにモデルの完全なコピーが配置され、受信したリクエストが各GPUに分散される。推論時にはGPU間の通信は一切発生せず、各GPUはそれぞれ独自に処理を実行する。/v1/chat/completions件のリクエストを両ポート間で分散させる。
エキスパート並列化はミックスド・オブ・エキスパーツモデル向けの手法だ。
Expert parallelism (EP) applies only to mixture-of-experts (MoE) models. In an MoE model, each token activates only a small subset of the model’s “experts” — for example, Qwen3-235B has 256 routed experts but only 6 fire per token (~22B active parameters out of 235B total). EP puts different experts on different GPUs so you do not waste memory storing inactive experts everywhere.--enable-expert-parallel combined with --tensor-parallel-size
各戦略の組み合わせ：TP、PP、DP
GPUが多数存在する場合、これらの戦略を階層的に組み合わせる。- ノード内TP： 相互接続速度が速い環境で用いる。
- ノード間PP： 相互接続速度が遅い環境で用いる。
- スループット向上用DP： TPとPPを組み合わせた構成の複数レプリカを実行する。
4個のGPU：TP=2＋PP=2
8個のGPU：TP=4＋DP=2
Run 2 replicas of a 4-way tensor-parallel setup. Each replica uses 4 GPUs for TP, and a load balancer distributes requests between the 2 replicas. This gives you the low latency of TP=4 with 2× the throughput.大まかな指針として
- まずTP — 利用可能な中で最速の相互接続手段（NVLink、QSFP、PCIe）を活用する。
- 次にPP — より速度の遅いリンク（イーサネットやマシン間ネットワーク）を利用する。
- 最後にDP — より高いスループットが必要で、レプリカ用に余剰なGPUがある場合に用いる。
TP × PP = total GPUs used for one replicaが必須となる。--tensor-parallel-size 4 --pipeline-parallel-size 2を設定すれば、vLLMは8基のGPUを使って1個のレプリカを作成する。
シャーディングの判断基準表
70B台、2基分のRTX 4090（PCIe接続）
PPが適している。 PCIeの帯域幅では効率的なオールリデュースが行えない。パイプライン並列処理ならこのボトルネックを回避できる。
70B台、2基分のA100（NVLink接続）
TPが適している。 NVLinkならオールリデュースに十分な帯域幅が確保でき、トークンごとの遅延も低減できる。
235BのMoE、DGX Spark
EP. ネイティブなMoE処理機能 — 各GPUは全モデルではなく自身が担当するエキスパートのみを保持します。つまり全235Bを保持する必要はありません。
7B、高負荷なトラフィック環境
DP. モデルは単一の1 GPUに収まります。スループット向上のため複数のGPUでデプロイします。
70B、4台のA100マシン（NVLink接続）
TP=4 （レイテンシよりスループットを重視する場合はTP=2 + DP=2でも可）。
70B台、2台のマシン
PP=2. マシン間のネットワーク帯域はTP実行には不十分です。パイプライン方式なら帯域制限の問題を回避できます。
実際に使えるコマンド例
シャーディングが正しく機能しているか確認する方法
各GPU上でnvidia-smiを実行します。参加している全GPUでモデル用のメモリが割り当てられているはずです：
よくある失敗例
速度が遅いPCIe環境でのTPの利用法 AllReduce処理では各レイヤーの後で活性化データが送信される。PCIe 3.0を使用する場合、これがデコード処理のスループットを著しく低下させる。GPUにNVLinkが搭載されていない場合は、PP方式も試して比較してみるべきだ。 バッチサイズ 1を用いたPPの利用法 一度に処理されるトークン数が 1個のみの場合、パイプライン内で無駄な計算が大量に発生する。vLLMの継続的バッチ処理機能はこの問題を緩和してくれるので、パイプラインが十分に活用されるよう十分な数の同時リクエストを送信する必要がある。 DP方式ではモデルメモリがN倍必要になることを見落とさないこと 4個の 70B Q4モデル（各々約35GB）を運用する場合、合計で 140GBのメモリが必要となる。レプリカを追加する前に必ずメモリ計画を立てるべきだ。 KVキャッシュの存在を考慮しないこと GPUメモリの使用量はモデル重みだけではない。KVキャッシュが残りのメモリを占めることになる。2個のGPUに重みを分散配置する際、KVキャッシュも同様に分散されるため、同時接続可能なユーザー数が実質的に倍増する。しかし重み分のみを考慮してメモリを確保するとメモリ不足に陥る。分散配置方式を選定する前に、重み分・KVキャッシュ分・さらに約3GBのオーバーヘッド分も含めたメモリを確保する必要がある。 TPとPPの適用順序を誤らないこと vLLMでは各パイプライン段階内でTPが適用される。--tensor-parallel-sizeには単一ノード内のGPU数を、--pipeline-parallel-sizeにはノード数を設定する。逆に設定するとノード内でPPが適用され高速な相互接続が無駄になり、またノード間でTPが適用されることでネットワークがAllReduce処理で飽和してしまう。
次に行うべき手順
テンサー並列処理とパイプライン並列処理の違い
TPとPPの詳細な比較および性能ベンチマーク結果
DGX Sparkを一台使用する場合と二台使用する場合
いつ二つ目のスパークを追加し、どのようにして200ギガビット/秒のリンクを設定すればよいか。
DGX Sparkにおけるメモリチューニング方法
分散配置時のKVキャッシュの計算方法およびメモリパラメータについて
モデルの提供とスケーリング
推論エンジンがバッチ処理や精度管理、並列処理をどのように実施するかについて。