vLLM・SGLang・Ollama・Kubernetes GPU設定コンパイラ

--gpu-memory-utilization、--tensor-parallel-size、--max-model-len を試行錯誤で推測する必要はもうありません。オープンウェイトモデル、量子化、目標コンテキスト長、GPU構成を選ぶだけで本番投入可能な起動コマンドとコンテナマニフェストを生成します。

クラスタ & ランタイムパラメータ

32,768 トークン
16

事前メモリ & 並列整合性チェック

メモリ不足 (OOM)
必要メモリ合計
101.42 / 80 GB
デバイスあたり割当量: 101.42 GB
gpu-memory-utilization
0.95
TP Head Split: 64Q / 8KV OK
推定単一ストリーム速度
0.0 tok/s
推定バッチ総スループット: 0.0 tok/s
OOM到達前の最大コンテキスト
21,770
トークン
bash · vLLM
vllm serve Qwen/Qwen3-32B \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --max-num-seqs 16 \
  --gpu-memory-utilization 0.95 \
  --quantization fp8 \
  --kv-cache-dtype fp8 \
  --enable-prefix-caching \
  --port 8000

自動コンパイルされる主要フラグの安全設計

テンソル並列はアテンションヘッドとMLP行列をNVLinkやPCIeデバイスへ分割するため、--tensor-parallel-size はクエリヘッド数およびKVヘッド数を割り切れる値にしつつ、NCCL all-reduceバッファとCUDAグラフ確保用の余裕を残す必要があります。

KVキャッシュ量子化(FP8 E4M3 または Q8_0)を選択すると、VRAMLabは vLLM 向けに --kv-cache-dtype fp8、SGLang 向けに --kv-cache-dtype fp8_e4m3、さらに OLLAMA_KV_CACHE_TYPE=q8_0 / --cache-type-k フラグを出力し、重み精度を落とさずに長文脈の同時処理数を倍増させます。

大雑把な経験則は、現代のオープンウェイト推論を左右する3つの主要因を見落としています。GGUFスーパーブロック量子化のスケール係数(Q4_K_Mの実効平均は4.00ではなく4.85 bits/weight)、長大コンテキストや連続バッチ処理の同時スロットに伴うKVキャッシュ膨張、そしてMixture-of-Experts(MoE)において全671Bや235BパラメータがVRAMに常駐しつつトークン生成ごとに37Bや22Bのみが読み出される挙動です。