なぜ DeepSeek V3.2 を読むべきか
DeepSeek V3.2 は MIT ライセンスで公開されているにもかかわらず、複数の独立ベンチマークで GPT-4o や Claude 3.5 Sonnet 系列に肉薄するスコアを出している MoE モデルである。総パラメータ 671B のうち推論時に活性化されるのは約 37B にとどまり、HuggingFace に公開されたモデルカードによれば、入力 1M トークンあたりの公式 API 価格は $0.14 という安さである。アーキテクチャ自体に新規性が多く、後続の Qwen / GLM / MiniMax 系の参考実装にも影響を与えている。
Multi-head Latent Attention (MLA)
V3.2 が継承する最大の独自要素が MLA だ。標準の MHA では K/V を head 数ぶん持つ必要があり、長文推論時の KV キャッシュサイズが GPU メモリを圧迫する。MLA は K/V を低ランクの潜在ベクトルに圧縮した上で、推論時に必要な head に投影しなおす。実装上は学習時のオーバーヘッドが軽く、推論時は `kv_cache_quant=fp8` と組み合わせると 128k コンテキストでも 1.7 倍ほどメモリを節約できる、というのが社内 R&D での観測値である。
```python # 概念コード: MLA の K/V 圧縮 class MLA(nn.Module): def __init__(self, d_model, n_heads, kv_lora_rank=512): super().__init__() self.kv_a_proj = nn.Linear(d_model, kv_lora_rank, bias=False) self.kv_b_proj = nn.Linear(kv_lora_rank, n_heads * d_head * 2, bias=False)
def forward(self, x): kv_latent = self.kv_a_proj(x) # 低ランクへ圧縮 kv = self.kv_b_proj(kv_latent) # 必要時に展開 return kv ```
補助損失なし MoE 負荷分散
通常の MoE モデルは expert 利用率を平準化するために auxiliary loss を導入するが、V3.2 では各 expert に学習可能なバイアスを足すだけで済ませている。バイアスは over-utilized な expert に対して引き下げられ、under-utilized な expert に対して引き上げられる、というシンプルな更新規則だ。論文では auxiliary loss を撤廃したことで MMLU スコアで +0.7 ポイントの改善が報告されている。
| 設定 | MMLU | GSM8K | HumanEval | | --- | --- | --- | --- | | Aux loss あり | 87.1 | 89.3 | 82.6 | | Bias 補正のみ | 87.8 | 89.5 | 83.4 |
FP8 ネイティブ学習
V3.2 は H800 クラスタで FP8 を主要な学習データ型として採用した最初の大規模モデルである。BF16 と比較して通信帯域は半分、MFU は 1.4 倍程度改善する。安定化のため、forward は per-tile 量子化、backward は per-block 量子化、master weight だけは BF16 で保持する設計である。
日本語ベンチでの所感
JMMLU、JCommonSenseQA、AI王 で社内 R&D テストを行った範囲では、Qwen2.5-72B-Instruct と同等以上、Claude 3.5 Sonnet にはやや及ばないが GPT-4o-mini と互角という体感である。日本語コーディング（Python ライブラリ呼び出し）では Tools 系のフォーマットがやや弱く、出力フォーマットの厳格化プロンプトが必要だった。
デプロイ指針
- vLLM 0.7+ または SGLang 0.4+ で MLA とFP8 KV キャッシュを有効化
- 4×H100 80GB 構成なら 32k コンテキスト・150 tok/s 程度
- API 利用なら DeepSeek 公式 + バックアップに OpenRouter 二重化が無難
- 機密データを扱う場合は中国国内サーバ経由を避け、OSS 重みを Tokyo の GPU でセルフホストする経路を選ぶ