DeepSeek パフォーマンス最適化ガイド

シングルGPUからクラスターまで、DeepSeek モデルの推論パフォーマンスを包括的に最適化します。推論高速化、メモリ最適化、量子化技術、バッチ処理、KV Cache、投機的デコードまで網羅。

DeepSeek 性能最適化

なぜ性能最適化が必要か？

DeepSeek モデルは高性能ですが、推論コストも同様に無視できません。ローカル展開のシングルGPUユーザーでも、クラウドAPIの大量呼び出しでも、適切な性能最適化により2〜10倍の推論高速化が可能になり、ハードウェアとAPIコストを大幅に削減できます。このガイドでは、量子化、KV Cache、バッチ処理から分散推論までの完全な最適化チェーンをカバーしています。

第1章

性能指標体系

最適化を始める前に、まず正しい性能評価体系を確立する必要があります。指標がなければ、最適化は盲人が象を触るようなものです。以下は注目すべき6つの主要指標です。

6つの主要性能指標

指標	英語	説明	最適化目標
スループット	TPS / TGS	1秒あたりに生成されるトークン数（Tokens Per Second / Tokens Generated per Second）	高いほど良い
最初のトークンまでの時間	TTFT	Time To First Token、リクエスト送信から最初のトークン生成までの時間	低いほど良い
出力トークンあたりの時間	TPOT	Time Per Output Token、各出力トークンの平均生成時間	低いほど良い
GPU使用率	GPU Util	GPU計算コアの使用率。計算リソースが十分に活用されているかを反映	高いほど良い
VRAM使用量	VRAM	推論中に占有されるGPUメモリ（GB）。実行可能なモデルサイズを決定	低いほど良い
スループット・レイテンシ比	QPS/P99	P99レイテンシ要件を満たす最大スループット。SLAの主要指標	高いほど良い

スループット vs レイテンシ：トレードオフ

性能最適化の核心的な矛盾は、スループットとレイテンシのトレードオフにあります。バッチサイズを大きくするとスループットは向上しますが、TTFTが増加します。精度を下げると推論は高速化しますが、回答品質に影響する可能性があります。優れた最適化ソリューションは、両者の最適なバランスを見つける必要があります。

オフラインバッチ処理シナリオ（例：評価、データアノテーション）：スループットを優先し、レイテンシは許容可能
オンラインサービスシナリオ（例：チャットボット、API）：レイテンシ制御を優先し、TTFTは通常 < 500ms が必要
リアルタイム対話シナリオ（例：音声アシスタント）：レイテンシに非常に敏感で、TTFTは < 200ms が必要

性能監視ツール

# GPU リアルタイム監視
nvidia-smi dmon -s pucvmet -d 1

# vLLM 組み込みパフォーマンスメトリクス（Prometheus 形式）
# 起動時に --disable-log-requests を追加してログオーバーヘッドを削減
vllm serve deepseek-ai/DeepSeek-V3 \
  --host 0.0.0.0 --port 8000 \
  --disable-log-requests

# benchmark_serving.py を使用して負荷テスト
python benchmarks/benchmark_serving.py \
  --backend vllm \
  --model deepseek-ai/DeepSeek-V3 \
  --dataset-name sharegpt \
  --num-prompts 1000 \
  --request-rate 10

第2章

量子化技術の詳細

量子化は、モデルのパラメータを高精度（FP16/BF16）から低精度（INT8/INT4）に圧縮する技術です。適切な量子化により、精度をほとんど損なうことなく、GPUメモリ使用量を50%-75%削減し、推論速度を2〜4倍向上させることができます。

主要な量子化手法の比較

量子化手法	精度	メモリ削減	速度向上	精度損失	推奨シナリオ
GPTQ	INT4/INT8	約60%	2〜3倍	極小	GPU推論、精度重視
AWQ	INT4	約60%	2〜3倍	極小	GPU推論、速度重視
GGUF	Q2-Q8	40%-75%	1.5〜4倍	レベルによる	CPU/ハイブリッド推論、柔軟な展開
FP8	FP8	約50%	1.5〜2倍	ほぼなし	H100/H200、ネイティブサポート

GGUF量子化レベルの詳細

GGUFはQ2からQ8までの複数の量子化レベルを提供します。数字が大きいほど精度が高く、モデルも大きくなります。以下は、DeepSeek-R1-8Bの異なる量子化レベルでのパフォーマンスです：

量子化レベル	モデルサイズ	推論速度	MMLUスコア	推奨度
Q2_K	3.2 GB	非常に速い	~58.2	非推奨
Q3_K_M	4.0 GB	速い	~62.5	低スペック端末
Q4_K_M	5.2 GB	比較的速い	~65.8	強く推奨
Q5_K_M	6.4 GB	普通	~66.8	推奨
Q6_K	7.4 GB	普通	~67.5	高品質ニーズ
Q8_0	8.5 GB	普通	~67.9	最高精度

DeepSeek の GPTQ/AWQ 量子化の使用

# AutoGPTQ を使用して量子化モデルをロード
from transformers import AutoTokenizer
from auto_gptq import AutoGPTQForCausalLM

model = AutoGPTQForCausalLM.from_quantized(
    "deepseek-ai/DeepSeek-V3-GPTQ-Int4",
    device="cuda:0",
    use_triton=True,  # Triton を使用して推論を高速化
)
tokenizer = AutoTokenizer.from_pretrained("deepseek-ai/DeepSeek-V3-GPTQ-Int4")

# vLLM を使用して AWQ 量子化モデルをロード
# vllm serve deepseek-ai/DeepSeek-V3-AWQ --quantization awq

量子化方法選択の決定木

Ollama でローカル実行: GGUF Q4_K_M を選択、速度と精度の最適なバランス
vLLM でサービスをデプロイ: AWQ INT4 を優先、vLLM がネイティブサポート、最高のパフォーマンス
H100/H200 GPU: FP8 量子化を使用、ネイティブ Transformer Engine アクセラレーション
CPU 推論: GGUF Q4_K_M または Q5_K_M を使用、llama.cpp と組み合わせて最高のパフォーマンス

極限の精度ニーズ: GPTQ INT8 または非量子化を使用し、BF16 精度を保持

第3章

KV Cache 最適化

KV Cache は Transformer 推論の核心メカニズムであり、メモリ使用量の主な原因です。KV Cache を理解し最適化することは、推論性能を向上させる重要なステップです。

KV Cache の動作原理

自己回帰生成の過程で、各新しいトークンはすべての履歴トークンとアテンションを計算する必要があります。KV Cache は計算済みの Key と Value 行列をキャッシュし、重複計算を回避します。コンテキスト長 N、隠れ次元 d のモデルの場合、KV Cache のメモリ使用量はおおよそ次のようになります：

KV Cache サイズ = 2 * num_layers * N * d * num_heads * 2_bytes
    

DeepSeek-V3（671B パラメータ、MoE アーキテクチャ）を例にとると、128K コンテキストでは、KV Cache は数十 GB のメモリを占有する可能性があり、モデル重み自体をはるかに超えます。

KV Cache 量子化（FP8 KV Cache）

KV Cache を FP16 から FP8 または INT8 に量子化すると、精度をほとんど損なうことなく、KV Cache のメモリ使用量を半分に削減できます。これは現在最も成熟しており、効果が最も顕著な KV Cache 最適化手法です。

# vLLM で FP8 KV Cache を有効化
vllm serve deepseek-ai/DeepSeek-V3 \
  --kv-cache-dtype fp8 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.95

# SGLang で FP8 KV Cache を有効化
python -m sglang.launch_server \
  --model deepseek-ai/DeepSeek-V3 \
  --kv-cache-dtype fp8_e5m2 \
  --context-length 131072

プレフィックスキャッシング

マルチターン会話では、各ターンのシステムプロンプトと履歴会話内容は完全に同一です。プレフィックスキャッシングは計算済みの KV Cache を再利用し、同じプレフィックスに対する重複計算を回避します。これは以下のシナリオで特に効果的です：

マルチターン会話：システムプロンプト + 履歴メッセージが完全に再利用され、TTFT を 50%-80% 削減できます
バッチ評価：複数のサンプルが同じ指示プレフィックスを共有
Few-shot 推論：複数のリクエストが同じ few-shot 例プレフィックスを共有
RAG シナリオ：複数の質問が同じ検索コンテキストプレフィックスを共有

# vLLM で Automatic Prefix Caching を有効化（デフォルトで有効）
vllm serve deepseek-ai/DeepSeek-V3 \
  --enable-prefix-caching

# SGLang の RadixAttention はプレフィックスキャッシングを自動的に有効化
# 追加設定は不要、デフォルトで有効

マルチターン会話最適化の実践

# 最適化前：各リクエストで会話履歴全体を再計算
messages = [
    {"role": "system", "content": system_prompt},
    {"role": "user", "content": "質問1"},
    {"role": "assistant", "content": "回答1"},


{"role": "user", "content": "質問2"},  # system + 履歴を毎回再計算
]

# 最適化後：プレフィックスキャッシングを有効にし、システムプロンプトと履歴メッセージの KV Cache を再利用
# 2ターン目の TTFT が 500ms から 50ms に短縮

第4章

バッチ処理最適化

バッチ処理（Batching）はGPU利用率を向上させる最も直接的な手段です。しかし、従来の静的バッチ処理はLLM推論において深刻な課題に直面しています：リクエストごとの出力長が大きく異なるため、GPUがアイドル状態になります。Continuous Batchingがこの問題を解決します。

Static Batching vs Continuous Batching

比較項目	Static Batching	Continuous Batching
動作メカニズム	バッチ内のすべてのリクエストが完了するまで待ってから次のバッチを処理する	リクエスト完了後すぐに新しいリクエストに置き換え、動的に調整する
GPU利用率	低い。短いリクエストが長いリクエストを待つ	高い。GPUはほぼアイドル状態にならない
スループット	低い	高い。最大10倍の向上
実装フレームワーク	HuggingFace Transformers	vLLM, SGLang, TGI

最適なバッチサイズの選択

バッチサイズは大きければ大きいほど良いというわけではありません。大きすぎるとレイテンシが増加し、小さすぎるとGPUを十分に活用できません。最適なバッチサイズは以下の要因に依存します：

GPUメモリサイズ：バッチサイズはKV Cacheに利用可能なメモリに制限されます。24GBメモリ（RTX 4090）の場合、max_num_seqs=32-64が推奨されます。
リクエスト負荷：高並行シナリオではバッチサイズを適切に増やし、低負荷シナリオではレイテンシを下げるためにバッチサイズを小さく保ちます。
シーケンス長：長いコンテキストのシナリオでは、KV Cacheの消費が大きいためバッチサイズを小さくする必要があります。
モデルサイズ：大規模モデル（例：DeepSeek-V3）のバッチサイズは、小規模モデル（例：DeepSeek-R1-8B）よりも通常小さくなります。

vLLM Continuous Batching設定

# vLLMバッチ処理関連パラメータ
vllm serve deepseek-ai/DeepSeek-V3 \
  --max-num-seqs 64 \             # 最大同時シーケンス数（バッチサイズの上限）
  --max-num-batched-tokens 8192 \ # 各イテレーションで処理する最大トークン数
  --max-model-len 32768 \          # 最大コンテキスト長
  --gpu-memory-utilization 0.95    # GPUメモリ使用率

動的バッチ処理戦略

Chunked Prefill：長いプロンプトのprefillフェーズをチャンクに分割し、decodeフェーズと交互に実行することで、prefillがdecodeをブロックするのを防ぎます。
Priority Scheduling：リクエストごとに優先度を設定し、優先度の高いリクエストを先にバッチに含めます。
Length-aware Batching：類似した長さのリクエストを同じバッチにまとめ、パディングの無駄を減らします。
Iteration-level Scheduling：各イテレーションでバッチ構成を再評価し、動的に新しいリクエストを追加します。

第5章

投機的デコーディング（Speculative Decoding）

投機的デコーディングは、近年最も注目されている推論高速化技術の一つです。小型の「ドラフトモデル」が候補トークンを高速に生成し、大型の「ターゲットモデル」が並列に検証することで、精度を損なうことなく2〜3倍の推論高速化を実現します。

投機的デコーディングの原理

大規模モデルの推論のボトルネックは自己回帰生成にあります。毎回1トークンしか生成できず、並列化が不可能です。投機的デコーディングは「小モデルが推測し、大モデルが検証する」方式で、逐次生成を並列検証に変換します：

ドラフト段階：小モデル（Draft Model）がK個の候補トークンを高速生成（例：K=5）
検証段階：大モデル（Target Model）が1回のフォワードパスでK個すべてのトークンを検証
受理/拒否：確率分布に基づいて正しいトークンは受理し、不一致のトークンは拒否
繰り返し：最初に拒否された位置から上記のプロセスを続行

高速化率の分析

投機的デコーディングの高速化率は、ドラフトモデルの「受理率」（Acceptance Rate）に依存します。受理率が高いほど高速化効果が高まります。典型的なシナリオでは：

ターゲットモデル	ドラフトモデル	受理率	高速化率
DeepSeek-V3 (671B)	DeepSeek-V3-Lite (16B)	~85%	2.5倍
DeepSeek-R1 (671B)	DeepSeek-R1-Distill-Llama-8B	~80%	2.2倍
DeepSeek-Coder-V2	DeepSeek-Coder-1.3B	~90%	3.0倍

DeepSeek投機的デコーディングの実装

# vLLMを使用した投機的デコーディング
vllm serve deepseek-ai/DeepSeek-V3 \
  --speculative-model deepseek-ai/DeepSeek-V3-Lite \
  --num-speculative-tokens 5 \
  --speculative-draft-tensor-parallel-size 1

# HuggingFaceを使用した投機的デコーディング
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

target_model = AutoModelForCausalLM.from_pretrained(
    "deepseek-ai/DeepSeek-V3", torch_dtype=torch.bfloat16
).to("cuda")

draft_model = AutoModelForCausalLM.from_pretrained(
    "deepseek-ai/DeepSeek-V3-Lite", torch_dtype=torch.bfloat16
).to("cuda")

# assisted_decoding または prompt_lookup_decoding を使用
output = target_model.generate(
    input_ids,
    assistant_model=draft_model,
    max_new_tokens=256,
    do_sample=True,
    temperature=0.7,
)

ドラフトモデル選択の推奨事項

ドラフトモデルは3つの条件を満たす必要があります：1) ターゲットモデルと同じ系列またはアーキテクチャであること（高い受理率を確保するため）；2) パラメータ数がターゲットモデルの1/10〜1/50であること；3) 推論速度がターゲットモデルより明らかに速いこと。DeepSeek-V3では、ドラフトモデルとしてDeepSeek-V3-LiteまたはDeepSeek-R1-Distill-Qwen-1.5Bを推奨します。

).to("cuda") # assisted_decoding または prompt_lookup_decoding を使用 output = target_model.generate( input_ids, assistant_model=draft_model, max_new_tokens=256, do_sample=True, temperature=0.7, )

ドラフトモデル選択の推奨事項

第6章

メモリ最適化

メモリはLLM推論の最大のボトルネックです。671BパラメータのDeepSeek-V3モデルは、FP16でも約1.3TBのメモリが必要です。以下のテクニックを使うことで、限られたメモリでより大きなモデルを実行できます。

Gradient Checkpointing（勾配チェックポイント）

主にトレーニングで使用されますが、勾配チェックポイントの考え方は推論にも影響します。推論では、中間活性値を保存せず、計算と引き換えにスペースを節約することで、メモリ使用量を大幅に削減できます。これは長いコンテキストの推論で特に重要です。

CPU Offloading（CPUオフロード）

モデルの一部のレイヤーやKVキャッシュをCPUメモリにオフロードすると、速度は犠牲になりますが、本来実行できないモデルを実行できるようになります：

# llama.cppのGPUレイヤー数制御（Ollamaの基盤）
# 一部のレイヤーをCPUにオフロードし、GPUメモリ使用量を削減
ollama run deepseek-r1:8b

# Ollamaの会話でGPUレイヤー数を設定
# /set parameter num_gpu 20  # GPU上には20層のみ、残りはCPU

# HuggingFace AccelerateのCPUオフロード
from accelerate import infer_auto_device_map, dispatch_model
device_map = infer_auto_device_map(
    model,
    max_memory={0: "16GiB", "cpu": "64GiB"},
)
model = dispatch_model(model, device_map=device_map)

FlashAttention

FlashAttentionは、IOを意識した正確なアテンションアルゴリズムで、ブロック単位の計算と再計算戦略により、アテンション計算の時間とメモリの複雑さをO(N^2)からほぼO(N)に削減します。vLLMとSGLangはどちらもデフォルトでFlashAttentionを統合しています。

バージョン	主な改善点	速度向上	メモリ節約
FlashAttention-1	IOを意識したブロック計算、O(N^2)メモリを回避	2-3倍	10-20倍
FlashAttention-2	並列戦略を最適化、非行列乗算操作を削減	2倍（FA1比）	FA1と同等
FlashAttention-3	H100向けに最適化、非同期計算、FP8サポート	1.5-2倍（FA2比）	FA2と同等

PagedAttention

PagedAttentionはvLLMの中核的な革新であり、KVキャッシュをオペレーティングシステムの仮想メモリページングのように管理します。KVキャッシュを固定サイズの「ページ」（ブロック）に分割し、必要に応じて割り当て・解放することで、KVキャッシュの断片化と無駄を解決します：

メモリ使用率の向上：従来の20%-40%からほぼ100%に向上
より大きなバッチサイズのサポート：同じメモリでより多くの同時リクエストを処理可能
メモリ共有：並列サンプリング（ビームサーチ）中、複数のシーケンスが同じKVキャッシュページを共有
予約不要：各リクエストに最大長のKVキャッシュスペースを予約する必要がなくなる

# vLLMのPagedAttention設定
vllm serve deepseek-ai/DeepSeek-V3 \
  --block-size 16 \              # KVキャッシュのページサイズ（トークン数）
  --gpu-memory-utilization 0.95 \ # GPUメモリの95%を使用
  --max-num-seqs 128              # 最大同時シーケンス数

第7章

テンソル並列とパイプライン並列

単一のGPUにモデル全体を収容できない場合、分散推論技術が必要です。テンソル並列（TP）とパイプライン並列（PP）は、最も一般的な2つの分散戦略です。それらの違いと適用シナリオを理解することが重要です。

TP vs PP 比較

比較項目	テンソル並列（TP）	パイプライン並列（PP）
分割方法	単一層の重み行列を複数のGPUに分割	異なる層を異なるGPUに割り当て
通信量	高、各層でAllReduceが必要	低、層間の活性値のみ転送
GPU利用率	高、全GPUが同時に動作	バブルあり、一部GPUがアイドル
ノード間通信	非推奨、通信ボトルネックが深刻	適切、通信量が少ない
推奨GPU数	2〜8、単一ノード内	4〜32、ノードを跨げる

モデル規模別の最適構成

モデル	パラメータ数	推奨GPU	TP	PP	合計GPU
DeepSeek-R1-8B	8B	RTX 4090	1	1	1
DeepSeek-R1-70B	70B	A100 80GB	4	1	4
DeepSeek-V3	671B (37B active)	H100 80GB	8	1	8
DeepSeek-V3 (Full)	671B	A100 80GB	8	2	16

vLLM 分散推論構成

# 単一ノード8GPU、テンソル並列
vllm serve deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.95

# マルチノード: 各8GPUの2ノード、TP=8 PP=2
# ノード0
vllm serve deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 2

# 通信最適化: NCCL環境変数の使用
# export NCCL_SOCKET_IFNAME=eth0
# export NCCL_IB_DISABLE=0  # InfiniBand有効化
# export NCCL_NET_GDR_LEVEL=5  # GPUDirect RDMA

通信コスト最適化

分散推論における通信オーバーヘッドはパフォーマンスの敵です。以下の手段で通信コストを大幅に削減できます：

NVLink/NVSwitch：単一ノード内でNVLinkを使用してGPUを接続、帯域幅900GB/s、PCIeをはるかに超える
InfiniBand：ノード間通信にはInfiniBand（200-400GB/s）を使用し、イーサネットを避ける
GPUDirect RDMA：GPUがRDMAを介して直接通信し、CPUをバイパスしてレイテンシを削減
通信-計算オーバーラップ：AllReduce通信を次の層の計算とオーバーラップさせる

第8章

ハードウェア選定とコスト最適化

適切なハードウェアを選ぶことは、性能とコストの最適なバランスを見つける鍵です。GPUによって性能は大きく異なり、同じモデルでもハードウェアが異なると推論コストが数十倍になることがあります。

GPU性能比較

GPU	VRAM	FP16演算性能	帯域幅	クラウドレンタル価格	適したモデル
T4	16 GB	65 TFLOPS	320 GB/s	~$0.35/h	7B以下のモデル
A10	24 GB	125 TFLOPS	600 GB/s	~$0.75/h	8B-13Bモデル
A100 80GB	80 GB	312 TFLOPS	2,039 GB/s	~$1.50/h	70Bモデル、MoEモデル
H100 80GB	80 GB	989 TFLOPS	3,352 GB/s	~$2.80/h	DeepSeek-V3、FP8推論

トークンあたりのコスト見積もり

DeepSeek-R1-8B（Q4_K_M量子化）を例に、異なるGPUでの推論コスト：

GPU	TPS	1時間あたりのトークン数	100万トークンあたりのコスト
T4	~40	144K	$2.43
A10	~80	288K	$2.60
A100	~200	720K	$2.08
DeepSeek API	-	-	$0.14 (V3)

注意：DeepSeek公式APIの価格は、自前GPU推論のコストよりもはるかに低いです。ほとんどのシナリオでは、APIを使用する方が自前よりも経済的です。1日の呼び出し量が1000万トークンを超える場合のみ、自前GPUクラスターがコスト優位性を持つ可能性があります。

クラウド vs 自前

比較項目	クラウドGPU	自前データセンター
初期投資	ゼロ	高（H100 約$30K/枚）
柔軟性	高、いつでもスケール	低、ハードウェア固定
データセキュリティ	コンプライアンス評価が必要	完全に制御可能
日次コスト	従量課金	固定（電気代+運用）

スポットインスタンス戦略

クラウドプロバイダーのスポット/プリエンプティブルインスタンスを使用すると、GPUコストを60%-90%節約できます。ただし、スポットインスタンスはいつ回収されるかわからないため、フォールトトレラントな設計が必要です：

マルチリージョン展開：異なるアベイラビリティゾーンでスポットインスタンスを起動し、同時回収の確率を低減
チェックポイント機構：推論サービスの状態を定期的に保存し、回収後に迅速に復旧
ハイブリッド戦略：コアサービスはオンデマンドインスタンス、弾性負荷はスポットインスタンスを使用
ウォームプール：一定数のアイドルインスタンスをバッファとして維持し、スポット回収時にシームレスに切り替え

第9章

パフォーマンスベンチマーク

以下は実際の環境に基づくパフォーマンステストデータで、異なる推論フレームワークを異なるハードウェアで比較したものです。すべてのテストはDeepSeek-R1-8B（Q4_K_M量子化）を使用し、入力512トークン、出力256トークンです。

推論フレームワーク性能比較（RTX 4090 24GB）

フレームワーク	TPS	TTFT	並列8	並列32	VRAM使用量
Ollama	~65	~280ms	-	-	~5.5 GB
vLLM	~120	~150ms	~850 TPS	~2,400 TPS	~6.8 GB
SGLang	~135	~120ms	~920 TPS	~2,600 TPS	~6.5 GB
TGI	~110	~160ms	~800 TPS	~2,200 TPS	~7.0 GB

SGLangはDeepSeekモデルで最も優れた性能を示し、そのRadixAttentionと効率的なMoEスケジューリングによるものです。vLLMはそれに続き、エコシステムがより成熟しています。Ollamaは個人利用に適しており、高並列サービスには適していません。

モデル規模別性能比較（vLLM + A100 80GB）

モデル	量子化	単一GPU TPS	4GPU TP TPS	VRAM/GPU
DeepSeek-R1-8B	AWQ INT4	~180	-	~6 GB
DeepSeek-R1-32B	AWQ INT4	~70	-	~22 GB
DeepSeek-R1-70B	AWQ INT4	-	~180	~40 GB
DeepSeek-V3	FP8	-	~120	~65 GB

異なるハードウェアでのDeepSeek-R1-8B性能

ハードウェア	VRAM	Ollama TPS	vLLM TPS	用途
Apple M2 16GB	ユニファイドメモリ	~15	-	個人利用
RTX 4060 8GB	8 GB	~30	~50	入門開発
RTX 4090 24GB	24 GB	~65	~120	小規模チーム向けサービス
A100 80GB	80 GB	~90	~180	本番サービス
H100 80GB	80 GB	~130	~280	大規模生産

第10章

最適化チェックリスト

ベースラインから本番環境まで、以下のステップに従ってDeepSeek推論サービスを段階的に最適化します。各ステップで定量的なパフォーマンス向上が得られます。

フェーズ1: 基本最適化（即効性あり）

適切な推論フレームワークの選択: OllamaからvLLMまたはSGLangに切り替え、Continuous BatchingとPagedAttentionを利用し、スループットを2〜5倍向上
モデル量子化の有効化: AWQ INT4またはGGUF Q4_K_Mを使用し、VRAM使用量を60%削減、速度を2〜3倍向上
FlashAttentionの有効化: vLLM/SGLangではデフォルトで有効、追加設定は不要
適切なmax_model_lenの設定: 実際に必要なコンテキスト長を超えないようにし、KV Cacheの無駄を防ぐ
gpu_memory_utilizationの調整: デフォルトの0.90から0.95に上げ、VRAMを最大限活用

フェーズ2: 高度な最適化（大幅な改善）

FP8 KV Cacheの有効化: KV Cacheのメモリ使用量が半分になり、より大きなバッチサイズと長いコンテキストをサポート
Prefix Cachingの有効化: マルチターン会話シナリオでTTFTを50%〜80%削減
Chunked Prefillの設定: 長いプロンプトが他のリクエストのデコードをブロックするのを防ぐ
max_num_seqsのチューニング: GPUメモリと負荷に基づいて最適な同時実行数を見つける
投機的デコードの有効化: 適切な小規模モデルをドラフトモデルとして選択し、2〜3倍の高速化を実現

フェーズ3: 本番グレードの最適化（究極のパフォーマンス）

テンソル並列デプロイ: 大規模モデル（70B+）ではTPを使用して複数GPUに分割し、単一GPUのVRAM制限を打破
NVLink/InfiniBandの使用: 分散推論に高速インターコネクトを使用し、通信オーバーヘッドを削減
NCCL最適化の有効化: GPUDirect RDMA、NCCL_NET_GDR_LEVELなどのパラメータを設定
混合精度推論: H100ではFP8、他のGPUではBF16を使用し、精度と速度のバランスを取る
負荷テストとモニタリング: benchmark_serving.pyで定期的に負荷テスト、Prometheus + Grafanaでパフォーマンスメトリクスを監視

パフォーマンス最適化の決定クイックリファレンス

問題	最初に試すこと	期待される改善
モデル実行にVRAMが不足	AWQ/GPTQ INT4量子化 + CPUオフローディング	VRAM使用量60%以上削減
推論速度が遅すぎる	vLLM/SGLangへの切り替え + 量子化	速度3〜5倍向上
同時処理能力が不足	Continuous Batching + FP8 KV Cache	同時実行数3〜8倍向上
多ターン会話の最初のトークンが遅い	Prefix Caching	TTFT が 50%-80% 削減
長いコンテキスト推論で OOM	FP8 KV Cache + max_num_seqs を削減	コンテキスト長が 2 倍
GPU コストが高すぎる	Spot Instance + 量子化 + 小モデル	コストが 60%-90% 削減

パフォーマンス最適化 FAQ

DeepSeek パフォーマンス最適化のよくある質問

Ollama と vLLM のパフォーマンス差はどのくらいですか？ +

単一リクエストのシナリオでは、vLLM は Ollama より約 1.5〜2 倍高速です。しかし、高並行シナリオでは、vLLM の Continuous Batching と PagedAttention の利点が顕著で、スループットは Ollama の 5〜10 倍に達します。本番レベルの API サービスを構築する必要がある場合は、vLLM または SGLang の使用を強くお勧めします。個人利用のシナリオでは、Ollama のシンプルさと使いやすさが有利です。詳細は DeepSeek デプロイチュートリアルを参照してください。

AWQ と GPTQ の量子化、どちらを選ぶべきですか？ +

AWQ をお勧めします。AWQ は通常、推論速度で GPTQ より優れており（約 10%〜20%）、vLLM は AWQ をネイティブサポートしているため、統合が簡単です。GPTQ は精度保持で AWQ よりわずかに優れています（差は最小限で、通常 0.5% 未満）。精度を非常に重視する場合は、GPTQ INT8 を選択できます。ほとんどのシナリオでは、AWQ INT4 が速度と精度の最良のバランスです。モデル量子化の詳細については、DeepSeek オープンソースモデルを参照してください。

DeepSeek-V3 を実行するのに VRAM が足りない場合、どうすればよいですか？ +

DeepSeek-V3 は 671B パラメータの MoE モデルであり、量子化後でも 8 枚の A100/H100 が必要です。ハードウェアが不足している場合は、以下のオプションがあります：1) 公式の DeepSeek API を使用する（コストが非常に低く、入力 1 元/百万トークン）；2) DeepSeek-R1 蒸留版（1.5B〜70B）を使用する（性能は近いが、要件がはるかに低い）；3) クラウド GPU をオンデマンドでレンタルする。詳細は DeepSeek モデルアーキテクチャの詳細を参照してください。

投機的デコーディングはすべてのシナリオで効果的ですか？ +

すべてのシナリオではありません。投機的デコーディングは以下の場合に最も効果的です：1) 出力内容の決定性が高い（コード生成、翻訳など）；2) ドラフトモデルとターゲットモデルが同じアーキテクチャとトレーニングデータを持つ；3) 両方のモデルを同時にロードするのに十分な VRAM がある。創造的執筆などランダム性が高いシナリオでは、受容率が 60% 未満になる可能性があり、高速化の効果は限定的です。有効にする前に、小規模なテストで受容率を検証することをお勧めします。

Ollama の GGUF 量子化レベルを選択するには？ +

Q4_K_M はほとんどのシナリオで最適な選択であり、速度と精度のバランスが取れています。VRAM が限られている場合（8GB 未満）は Q3_K_M を選択；最高品質を追求する場合（16GB 以上の VRAM）は Q5_K_M または Q6_K を選択。Q2 レベルは精度損失が顕著で、推奨されません。ollama run deepseek-r1:8b を使用すると、デフォルトの Q4_K_M バージョンがダウンロードされます。ダウンロードガイドの詳細は DeepSeek モデルのダウンロードを参照してください。

Continuous Batching には特別な設定が必要ですか？ +

vLLM と SGLang はデフォルトで Continuous Batching が有効になっており、追加設定は不要です。注目すべき重要なパラメータは2つだけです：max_num_seqs（最大同時シーケンス数）と max_num_batched_tokens（各イテレーションの最大トークン数）。デフォルト値から始めて、実際の負荷と GPU メモリ使用量に応じて徐々に調整することをお勧めします。GPU 使用率が低い場合は max_num_seqs を増やし、OOM が発生した場合は max_num_seqs を減らすか、max_model_len を下げてください。

詳細情報

DeepSeek 関連チュートリアル

DeepSeek モデルのデプロイ、使用、開発について深く学びます。

デプロイチュートリアル

DeepSeek デプロイチュートリアル

Ollama、Docker、vLLM、K8s によるデプロイソリューション。シングルマシンからクラスターまで。

モデル詳細

DeepSeek モデルアーキテクチャ

技術アーキテクチャ、Benchmark、MoE の詳細、選定比較。

モデルリスト

DeepSeek オープンソースモデル

6 シリーズ、20 以上のモデルの完全なカタログと比較。

ダウンロードガイド

DeepSeek モデルのダウンロード

Ollama、Hugging Face、GitHub でのダウンロードガイド。

入門チュートリアル

DeepSeek モデルの使い方

4 つの使用方法、ゼロから始める入門チュートリアル。

ファインチューニング

DeepSeek ファインチューニングチュートリアル

LoRA、QLoRA、フルファインチューニングの完全ガイド。