ローカルLLM選定｜MoE（gpt-oss-20b）とDense（Gemma 3 12B）の比較と業務での選び方

概要

ローカルLLMの導入検討では、近年公開が相次ぐ MoE（Mixture of Experts）モデル を採用すべきか、従来型の Denseモデル を採用すべきかという論点が頻繁に挙がります。MoEは「巨大なのに軽い」と紹介されることが多く、ローカル運用でも有利だと誤解されがちです。

本稿では、MoEの代表例である gpt-oss-20b と、Denseの実用機である Gemma 3 12B を題材に、両アーキテクチャの本質的な違い、実効パラメータ数の考え方、そして業務用途での選定指針をDigitalBaseの視点で整理します。結論を先に述べると、20B前後のローカルLLMでは、多くの業務でDenseモデルの素直な性能が勝るというのがDigitalBaseの評価です。

---

MoEとDenseモデルの基本的な違い

アーキテクチャの根本的な差

Denseモデル（従来型）

• すべてのパラメータが常に動作する
• 構造がシンプルで動作が安定している
• ファインチューニングが比較的容易

MoEモデル（Mixture of Experts）

• 複数の「専門家（Expert）」ネットワークを内包する
• ゲーティングネットワークがトークンごとに使用するExpertを選択する
• 各トークン処理時は一部のパラメータのみが動作する

「専門性」という言葉の実態

MoEは「タスクごとに専門家を使い分ける」と説明されることが多いものですが、実際には以下の点に注意が必要です。

事前学習時の挙動

• 各Expertは自然に異なるパターンを学習する
• ただし「コード専門」「翻訳専門」のような明確な分業ではない
• ゲーティングネットワークが確率的に振り分ける

ファインチューニング後の挙動

• 特定タスクに強いExpertが育つことはある
• ただしDenseモデルをファインチューニングしても同様の効果は得られる

したがって、MoEの「専門性」は人間が直感的に期待するほど明確なものではなく、MoEの本質的な利点は計算効率とスケーラビリティにあると整理するのが妥当です。

---

実例比較: gpt-oss-20b と Gemma 3 12B

基本スペック

重要な視点: 実効パラメータ数

gpt-oss-20bは総パラメータ数こそ21Bですが、各トークンの処理で実際に動作するのは約3.6Bにとどまります。一方、Gemma 3 12Bは常に全12Bが動作します。

gpt-oss-20b: 総パラメータ21B → 実際に動くのは3.6B
Gemma 3 12B: 総パラメータ12B → 実際に動くのは12B

トークンあたりの実効計算量で比較すると、Gemma 3 12Bのほうが約3倍以上大きく（12B対3.6B）、この差が指示理解や複雑なタスクでの精度差として現れやすい点が、ローカル運用における重要な考慮事項です。

パフォーマンス比較

処理速度（1000トークン生成時）

※実測値であり、環境・量子化条件により変動します。

タスク別の精度傾向

速度面ではアクティブパラメータの小さいMoEが優位ですが、指示理解や日本語会話の品質ではDenseが優位という傾向が確認できます。

---

MoEの利点と限界

MoEが真価を発揮するケース

1. 超大規模モデル（数百B〜兆パラメータ規模）
   • 大規模なフロンティアモデルやMixtral系などで採用が進む
   • 推論コストの削減が事業上の重要課題となる規模
2. クラウドAPIサービス
   • リクエスト数が膨大
   • レイテンシとスループットの両立が求められる
3. 専用ハードウェアでの最適化
   • TPU/GPUクラスタでの大規模並列推論
   • エッジ向けの効率化

20B規模のローカルLLMでMoEが不利になりやすい理由

1. 精度が速度に優先される場面が多い

ローカル運用では、多少応答が遅くても精度が高いほうが業務価値につながる場合が多く、3.6Bよりも12Bが全動作するDenseのほうが安定して賢い傾向があります。

2. 専門性より汎用性が求められる

社内業務では、様々なタスクを「過不足なく」こなせるモデルのほうが扱いやすく、特定タスクへの特化が必要ならファインチューニングのほうが効果的です。

3. ファインチューニングの難度

Denseモデルのほうが学習が安定します。MoEは各Expertのロードバランスを調整する必要があり、運用ノウハウの要求が高くなります。

---

業務用途での選び方

Denseモデル（Gemma 3 12B）が適するケース

推奨シナリオ

• 汎用的な社内チャットボット
• カスタマーサポートのFAQ応答
• 文書要約・文章生成
• ファインチューニングを予定している用途

具体例

• 社内ナレッジベースへの問い合わせ応答
• 議事録の自動作成
• メール文面の自動生成

実装例（Ollama）

# Gemma 3 12Bのダウンロード
ollama pull gemma3:12b

# 実行
ollama run gemma3:12b

import ollama

response = ollama.chat(
    model='gemma3:12b',
    messages=[{
        'role': 'user',
        'content': '以下の議事録を要約してください: ...'
    }]
)

MoEモデル（gpt-oss-20b）が適するケース

推奨シナリオ

• 大量のリクエスト処理（1日数万件以上）
• 構造化データ抽出に特化した処理
• エッジ環境での高速応答が必須となる用途

具体例

• APIサーバーでの大量処理
• JSON/XML抽出専用エンジン
• IoTデバイス上でのリアルタイム推論

実装例

import ollama

response = ollama.chat(
    model='gpt-oss:20b',
    messages=[{
        'role': 'user',
        'content': 'Extract structured data: {"name": ..., "price": ...}'
    }],
    format='json'  # 構造化出力に強い
)

推奨アプローチ

1. 初期導入はGemma 3 12B（Dense）から
   • 汎用性が高く、様々な業務に対応できる
   • ファインチューニングの実績が豊富
   • 精度が安定している
2. 特定用途への特化はタスク別に検討
   • コールセンター（会話）: Gemma 3 12B
   • データ抽出・分類: gpt-oss-20bも選択肢
   • 文書生成: Gemma 3 12B
3. ファインチューニング前提ならDenseを推奨
   • 学習の安定性
   • 全パラメータが均等に学習される
   • 社内データでの精度向上を見込みやすい

---

コスト比較（オンプレミス環境・4bit量子化＋LoRA前提）

現代的なアプローチ: 4bit量子化でコストを抑える

2026年時点のローカルLLM運用では、4bit量子化（GGUF/GPTQ）とLoRAファインチューニングが標準的な構成です。これにより、いずれのモデルも16GB VRAMクラスのGPUで動作させられます。

4bit量子化時のVRAM使用量

初期導入コスト（推奨GPU）

※価格は市場の変動が大きく、調達時点での確認を推奨します。

LoRAファインチューニングの利点

• 学習対象パラメータが少ない（全体の1%程度）
• 16GB VRAMでもファインチューニングが可能
• 複数のLoRAアダプタを切り替えて運用できる

実装例（Ollama + 4bit量子化）

# 4bit量子化モデルの使用
ollama pull gemma3:12b-q4_K_M  # 4bit量子化版
ollama pull gpt-oss:20b

# 推論実行
ollama run gemma3:12b-q4_K_M

月間ランニングコスト（24時間稼働・電気代の目安）

• RTX 4060 Ti: 約8,000円
• RTX 3090: 約12,000円
• RTX 4090: 約15,000円
• 保守・メンテナンスは別途見込みが必要です。

---

段階的な移行戦略

ユースケースの成熟度に応じて、モデルを段階的に見直す戦略が有効です。

フェーズ1: プロトタイプ（1〜3か月）

• Gemma 3 12Bで迅速に実装・検証する
• 汎用性を活かして幅広いユースケースを試す
• ユーザーフィードバックを収集する

フェーズ2: 本格導入（3〜6か月）

• ユースケースを明確化する
• 必要に応じてファインチューニングを実施する
• パフォーマンスのボトルネックを特定する

フェーズ3: 最適化（6か月以降）

• タスク別にモデルを選定する
• 高頻度・構造化タスクではMoEの採用を検討する
• 高精度が要求されるタスクではDenseを継続する

class HybridLLMSystem:
    """用途別にモデルを使い分けるシステム"""

    def __init__(self):
        # 汎用タスク: Gemma 3 12B
        self.general_model = 'gemma3:12b'
        # 構造化データ抽出: gpt-oss-20b
        self.extraction_model = 'gpt-oss:20b'

    def process(self, task_type, content):
        if task_type == 'extraction':
            return ollama.chat(
                model=self.extraction_model,
                messages=[{'role': 'user', 'content': content}],
                format='json'
            )
        else:
            return ollama.chat(
                model=self.general_model,
                messages=[{'role': 'user', 'content': content}]
            )

---

まとめ: どちらを選ぶべきか

ローカルLLM選定における一般的な指針は以下のとおりです。

Denseモデル（Gemma 3 12B）が適するケース

• 汎用的なビジネス用途（実務の大半を占めるケース）
• ファインチューニングを予定している
• 精度を重視する
• チーム内の運用ノウハウがまだ少ない

MoEモデル（gpt-oss-20b）を検討すべきケース

• 超高頻度のリクエスト処理
• 構造化データ抽出に特化した処理
• 推論速度を最優先する
• 十分な技術リソースと運用体制がある

結論

20B前後のローカルLLMでは、まず Gemma 3 12B（Dense）から始める ことを推奨します。理由は次のとおりです。

1. 指示理解が安定している（実効12B対3.6B）
2. ファインチューニングがしやすい
3. コストパフォーマンスが高い
4. 汎用性が高く、様々な業務に対応できる

重要なのは、プロジェクト初期から過度に最適化しようとせず、実際のユースケースで検証しながら調整することです。自社の業務データでA/Bテストを行い、どちらのアーキテクチャが適しているかをデータに基づいて判断することをおすすめします。

MoEは本質的には「超大規模モデルを効率的に動かす技術」であり、20B規模のローカルモデルにおいては、Denseモデルの素直な性能が勝る場面が多いというのがDigitalBaseの評価です。