Skip to content
Published on

オープンソースLLM全体像ガイド:2026年のモデル・ツール・デプロイ戦略

Authors

目次

  1. なぜオープンソースLLMなのか?
  2. 主要モデルファミリー
  3. モデルアーキテクチャ詳細解説
  4. ローカル推論ツール
  5. vLLMによるプロダクション運用
  6. LoRAとQLoRAによるファインチューニング
  7. Hugging Faceエコシステム
  8. 量子化手法
  9. 適切なモデルの選び方
  10. オープンソース vs プロプライエタリ:使い分けの指針

1. なぜオープンソースLLMなのか?

1.1 オープンモデルを使う理由

数年前まで、GPT-4やClaudeといったプロプライエタリモデルが品質面で圧倒していました。しかしその差は急速に縮まっています。2025〜2026年には、最上位のオープンソースモデルがほとんどのベンチマークでプロプライエタリモデルに匹敵し、特定の専門分野では上回るケースも出てきました。

オープンソースLLMを使う理由:

理由詳細
データプライバシーデータが自社インフラの外に出ない
大規模コスト削減トークン課金なし;GPU費用を分散償却
カスタマイズ自社ドメインデータでファインチューニング可能
コンプライアンス医療・金融・法律はオンプレミス要件が多い
レイテンシ制御アプリケーションとモデルを同じインフラに配置
ベンダーロックイン回避API変更なしでモデルを切り替え可能
研究と透明性重み・アーキテクチャ・学習データを直接確認

1.2 定義:Open vs Open-Weight vs 真のオープンソース

LLMコミュニティでは「オープンソース」という言葉が緩く使われています。

  • 真のオープンソース:重み・学習コード・学習データがすべて公開されているモデル(例:OLMo、Pythia)
  • オープンウェイト:重みはダウンロード可能だが、学習データやコードは非公開のモデル(例:Llama 3、Mistral、Gemma)
  • 制限付き公開重み:重みは公開されているが利用目的に制限があるモデル(例:Llamaのコミュニティライセンスは大規模商用プロバイダーを除外)

「オープンソース」と呼ばれるほとんどのモデルは実際にはオープンウェイトです。この区別は法的・研究的な観点から重要です。


2. 主要モデルファミリー

2.1 Meta Llama

LlamaファミリーはMeta AIがリリースした、最も支配的なオープンウェイトモデルシリーズです。

Llama 3.1 / 3.2 / 3.3(2024〜2025年)

モデルパラメータ数コンテキスト備考
Llama 3.1 8B8B128K小型モデル中最高クラス
Llama 3.1 70B70B128K多くのタスクでGPT-4oに匹敵
Llama 3.1 405B405B128K最大規模、フロンティア級品質
Llama 3.2 1B / 3B1B, 3B128Kエッジデプロイ、マルチモーダル
Llama 3.2 11B / 90B11B, 90B128Kビジョン・言語モデル
Llama 3.3 70B70B128K3.1 70Bから改良

主な強み:強力な推論・コーディング・多言語対応(8言語)。70Bモデルはほとんどのアプリケーションで信頼できる選択肢です。

ライセンス:Llamaコミュニティライセンス — ほとんどの用途で無料。月間アクティブユーザー7億人以上の製品はMetaの承認が必要。

2.2 Mistral AI

Mistralはパラメータ数に対して優れた性能を発揮する高効率モデルを提供しています。

モデルパラメータ数備考
Mistral 7B v0.37Bオリジナルの高効率モデル、インストラクションチューニング済み
Mistral NeMo 12B12BNVIDIAとの協業、コーディングに強い
Mistral Small 324B効率的な商用グレードモデル
Codestral22Bコード特化、80以上の言語に対応
Mixtral 8x7B56B(12.9B active)Mixture of Experts、高速推論
Mixtral 8x22B141B(39B active)最高のMoE汎用モデル

ライセンス:ベースモデルはApache 2.0(許容的、商用利用フレンドリー)。

Mistralの核心的革新:Mixture of Experts(MoE) アーキテクチャがトークンごとにパラメータの一部のみ活性化することで、7B activeパラメータの推論コストで70B近くの品質を実現します。

2.3 Google Gemma

GemmaはGemini技術をベースにしたGoogleのオープンウェイトモデルシリーズです。

モデルパラメータ数備考
Gemma 2 2B2B2Bモデル中最高クラス
Gemma 2 9B9B複数のベンチマークでLlama 3.1 8Bを上回る
Gemma 2 27B27B強力で効率的な27Bモデル
CodeGemma 7B7Bコード特化
PaliGemma3Bビジョン・言語モデル

ライセンス:Gemma利用規約 — 許容的だがApache 2.0ではない。商用利用可。

2.4 Qwen(Alibaba)

AlibabaCloudのQwenシリーズは、トップクラスのオープンウェイトファミリーとして定着しています。

モデルパラメータ数備考
Qwen2.5 0.5B〜72B複数サイズ強力な多言語対応(中国語/英語)
Qwen2.5-Coder 7B〜32B7B, 32B優れたコード生成
Qwen2.5-Math 7B〜72B7B, 72B数学的推論
QwQ 32B32B推論モデル、o1スタイルの思考連鎖
Qwen2-VL7B, 72B強力なビジョン・言語

ライセンス:ほとんどのモデルにApache 2.0を適用。

Qwenモデルは中国語タスクや多言語アプリケーションで特に強力です。

2.5 DeepSeek

DeepSeekは効率的な学習アプローチで注目すべきモデルを開発しています。

モデルパラメータ数備考
DeepSeek-V2236B MoE(21B active)非常にコスト効率の高い推論
DeepSeek-V3671B MoE(37B active)GPT-4に近い品質、オープンウェイト
DeepSeek-R1複数サイズ思考過程が見える推論モデル
DeepSeek-Coder-V2236B MoE強力なコード生成

ライセンス:DeepSeekモデルライセンス — ほとんどの商用利用に許容的。

DeepSeekの主な成果:競合他社と比べて大幅に低い計算コストでフロンティア級モデルを学習。

2.6 その他の注目モデル

モデル組織強み
Phi-3 / Phi-4Microsoft小型サイズ(3.8B〜14B)で強力
Command R+Cohere検索拡張タスク
Falcon 180BTII大規模オープンモデル
Yi 34B01.AI強力な多言語対応
Orca 3Microsoft指示追従
SOLAR 10.7BUpstage韓国語/英語バイリンガル

3. モデルアーキテクチャ詳細解説

3.1 Grouped Query Attention(GQA)

現代のLLMのほとんどは、標準的なMulti-Head Attention(MHA)の代わりにGQAを使用しています。GQAはクエリをグループ化してキー・バリューヘッドを共有することで、品質の損失なくKVキャッシュのメモリを大幅に削減します。

Multi-Head Attention (MHA):
Q heads: 32    K heads: 32    V heads: 32
KV cache: 2 × 32 × seq_len × d_head

Grouped Query Attention (GQA):
Q heads: 32    K heads: 8    V heads: 8
KV cache: 2 × 8 × seq_len × d_head   (4倍削減!)

Multi-Query Attention (MQA):
Q heads: 32    K heads: 1    V heads: 1
KV cache: 2 × 1 × seq_len × d_head   (32倍削減、若干品質低下)

3.2 Rotary Position Embeddings(RoPE)

RoPEは、トークン埋め込みに位置埋め込みを加算する代わりに、回転変換を通じてクエリ・キーベクトルに位置情報をエンコードします。主な利点:

  • 学習時より長いシーケンスへの外挿が可能
  • 効率的な相対位置計算
  • YaRN、LongRoPEで非常に長いコンテキストまで拡張可能

3.3 Mixture of Experts(MoE)

MoEは密なフィードフォワード層を複数の「専門家」ネットワークで置き換え、ルーターがトークンごとに一部を選択します。

# MoE層のコンセプト(簡略化)
class MoELayer:
    def __init__(self, num_experts=8, top_k=2, d_model=4096, d_ff=14336):
        self.experts = [FeedForward(d_model, d_ff) for _ in range(num_experts)]
        self.router = nn.Linear(d_model, num_experts)
        self.top_k = top_k  # トークンごとにtop_k専門家のみ活性化

    def forward(self, x):
        # ルーターがtop-k専門家を選択
        logits = self.router(x)
        weights, indices = logits.topk(self.top_k)
        weights = F.softmax(weights, dim=-1)

        # 選択された専門家の出力の重み付き和
        output = sum(
            weights[:, i] * self.experts[indices[:, i]](x)
            for i in range(self.top_k)
        )
        return output

Mixtral 8x7Bは層ごとに8つの専門家を持ち、トークンごとに2つを活性化します。総パラメータ数は56Bですが、推論時のアクティブパラメータは約12.9Bに過ぎず、56Bの密なモデルよりもはるかに高速です。

3.4 KVキャッシュとコンテキスト長

KV(キー・バリュー)キャッシュは過去のトークンのアテンションキー・バリューを保存することで、自己回帰的な生成の際にシーケンス全体を再計算しなくて済むようにします。

KVキャッシュのメモリ:

KV cache size = 2 × num_layers × num_kv_heads × head_dim × seq_len × dtype_bytes

例:Llama 3.1 8B、fp16、128Kコンテキスト
= 2 × 32 × 8 × 128 × 131072 × 2 bytes
=17.2 GBKVキャッシュのみ)

長いコンテキストのリクエスト処理がメモリ集約的な理由、そして量子化されたKVキャッシュとスライディングウィンドウアテンションが重要な理由がここにあります。


4. ローカル推論ツール

4.1 Ollama

OllamaはLLMをローカルで実行する最も簡単な方法です。コマンド一つでモデルをダウンロードして実行できます。

# インストール(macOS/Linux)
curl -fsSL https://ollama.com/install.sh | sh

# モデルをインタラクティブに実行
ollama run llama3.1:8b

# 特定の量子化で実行
ollama run llama3.1:70b-instruct-q4_K_M

# 実行せずにダウンロードのみ
ollama pull mistral:7b

# インストール済みモデルの一覧
ollama list

# APIサーバーとして実行(OpenAI互換!)
ollama serve  # localhost:11434で起動

OllamaはOpenAI互換APIを公開しているため、OpenAI SDKをそのまま利用できます:

from openai import OpenAI

# ローカルOllamaに接続
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # 必須だが無視される
)

response = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "トランスフォーマーを簡単に説明してください。"}]
)
print(response.choices[0].message.content)

4.2 llama.cpp

llama.cppはGGUF量子化モデル向けのC++推論エンジンです。CPU、GPU、またはその両方で動作し、Ollamaの内部エンジンでもあります。

# ビルド
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DLLAMA_CUDA=ON  # CUDA GPUサポート
cmake --build build --config Release -j

# GGUFモデルをダウンロード(例)
# Hugging Faceから: bartowski/Meta-Llama-3.1-8B-Instruct-GGUF

# 推論を実行
./build/bin/llama-cli \
  -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -n 512 \
  --prompt "トランスフォーマーのアテンションメカニズムを説明してください。"

# OpenAI互換サーバーとして実行
./build/bin/llama-server \
  -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  -c 4096 \
  -ngl 35  # GPUにオフロードする層数

4.3 Transformers(Hugging Face)

Hugging Faceのtransformersライブラリは、PythonでモデルをもっともフレキシブルにするHFれる方法です:

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_id = "meta-llama/Meta-Llama-3.1-8B-Instruct"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.bfloat16,
    device_map="auto",          # 利用可能なGPUに自動分散
)

messages = [
    {"role": "system", "content": "You are a helpful assistant."},
    {"role": "user", "content": "トランスフォーマーアーキテクチャとは何ですか?"}
]

input_ids = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True,
    return_tensors="pt"
).to(model.device)

with torch.no_grad():
    outputs = model.generate(
        input_ids,
        max_new_tokens=512,
        temperature=0.7,
        do_sample=True,
        pad_token_id=tokenizer.eos_token_id,
    )

response = tokenizer.decode(outputs[0][input_ids.shape[-1]:], skip_special_tokens=True)
print(response)

4.4 ローカル推論ツールの比較

ツール最適な用途GPU必要セットアップ難易度パフォーマンス
Ollama開発者、クイックスタート不要(CPU可)とても簡単良好
llama.cppCPU推論、埋め込み任意普通優秀
Transformers研究、カスタムコード推奨簡単〜普通良好
vLLMプロダクション運用必要普通優秀
TGIプロダクション運用必要普通優秀
ExLlamaV2高スループットGPU必要普通〜難しい優秀

5. vLLMによるプロダクション運用

5.1 なぜvLLMなのか?

vLLMはプロダクション用途をリードするオープンソースLLMサービングエンジンです。核心的な革新:

  • PagedAttention:KVキャッシュをOSの仮想メモリのように管理し、スループットを大幅向上。
  • 継続的バッチ処理:実行中のバッチに動的にリクエストを追加し、GPU利用率を最大化。
  • テンソル並列処理:複数のGPUにシームレスにモデルを分散。
  • OpenAI互換API:OpenAI APIのドロップイン代替。

5.2 vLLMサーバーの起動

# インストール
pip install vllm

# サーバー起動(シングルGPU)
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Meta-Llama-3.1-8B-Instruct \
  --dtype bfloat16 \
  --max-model-len 32768 \
  --port 8000

# テンソル並列処理でマルチGPU(4枚)
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Meta-Llama-3.1-70B-Instruct \
  --dtype bfloat16 \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --port 8000

# 量子化適用(AWQ)
python -m vllm.entrypoints.openai.api_server \
  --model TheBloke/Llama-3-70B-Instruct-AWQ \
  --quantization awq \
  --dtype float16 \
  --tensor-parallel-size 2

5.3 vLLMサーバーの使用

vLLMはOpenAI互換APIを提供するため、クライアントコードはOpenAIと同一です:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

response = client.chat.completions.create(
    model="meta-llama/Meta-Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "PagedAttentionとは何ですか?"}],
    max_tokens=256,
    temperature=0.7,
)
print(response.choices[0].message.content)

# ストリーミング
with client.chat.completions.stream(
    model="meta-llama/Meta-Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "RAGについて詳しく説明してください。"}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

5.4 DockerでvLLMを実行

# Dockerfile
FROM vllm/vllm-openai:latest

ENV HUGGING_FACE_HUB_TOKEN=""

CMD ["--model", "meta-llama/Meta-Llama-3.1-8B-Instruct", \
     "--dtype", "bfloat16", \
     "--max-model-len", "16384"]
docker run --gpus all \
  -p 8000:8000 \
  -e HUGGING_FACE_HUB_TOKEN=hf_xxx \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  my-vllm-server

6. LoRAとQLoRAによるファインチューニング

6.1 ファインチューニングが必要な場合

ファインチューニングが常に必要なわけではありません。まずプロンプトエンジニアリングとRAGを試してください。以下の場合にファインチューニングを検討します:

  • プロンプトで誘導しにくい特定の出力フォーマットが必要な場合
  • ベースモデルに十分に表現されていないドメイン固有の用語や慣習がある場合
  • レイテンシが重要で、指示をモデルの重みに組み込みたい場合
  • 数千の高品質サンプルを持っており、一貫した動作を望む場合

6.2 LoRA:Low-Rank Adaptation

LoRAは事前学習済みモデルの重みを凍結し、各アテンション層に小さな学習可能な行列(アダプター)を追加します。学習可能なパラメータを1000倍以上削減します。

from peft import LoraConfig, get_peft_model, TaskType
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_id = "meta-llama/Meta-Llama-3.1-8B-Instruct"
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.bfloat16,
    device_map="auto"
)

# LoRA設定
lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,               # 適応行列のランク
    lora_alpha=32,      # スケーリングファクター
    lora_dropout=0.05,
    target_modules=[    # 適応する層
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj"
    ],
    bias="none",
)

peft_model = get_peft_model(model, lora_config)
peft_model.print_trainable_parameters()
# trainable params: 83,886,080 || all params: 8,114,474,240 || trainable%: 1.03%

6.3 QLoRA:量子化されたLoRA

QLoRAは4ビット量子化とLoRAを組み合わせ、シングルA100 GPUで70Bモデルのファインチューニングを可能にします:

from transformers import BitsAndBytesConfig
from peft import prepare_model_for_kbit_training

# 4ビット量子化設定
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_use_double_quant=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16
)

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    quantization_config=bnb_config,
    device_map="auto"
)

# kビット学習の準備(層正規化をfp32にキャストなど)
model = prepare_model_for_kbit_training(model)

# 量子化モデルの上にLoRAを適用
peft_model = get_peft_model(model, lora_config)

6.4 SFTTrainerによる完全ファインチューニング

from trl import SFTTrainer, SFTConfig
from datasets import load_dataset

dataset = load_dataset("your-org/your-dataset", split="train")

def format_example(example):
    return {
        "text": f"<|user|>\n{example['instruction']}\n<|assistant|>\n{example['output']}"
    }

dataset = dataset.map(format_example)

trainer = SFTTrainer(
    model=peft_model,
    tokenizer=tokenizer,
    train_dataset=dataset,
    args=SFTConfig(
        output_dir="./checkpoints",
        num_train_epochs=3,
        per_device_train_batch_size=4,
        gradient_accumulation_steps=4,
        warmup_ratio=0.03,
        learning_rate=2e-4,
        fp16=True,
        logging_steps=10,
        save_steps=100,
        dataset_text_field="text",
        max_seq_length=2048,
    ),
)

trainer.train()
trainer.model.save_pretrained("./fine-tuned-model")

6.5 LoRAアダプターをベースモデルにマージする

from peft import PeftModel

# ベースモデルをロード
base_model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.bfloat16,
    device_map="cpu"
)

# LoRA重みをロードしてマージ
model = PeftModel.from_pretrained(base_model, "./fine-tuned-model")
merged_model = model.merge_and_unload()

# マージされたモデルを保存(標準HF形式、vLLM等と互換)
merged_model.save_pretrained("./merged-model")
tokenizer.save_pretrained("./merged-model")

7. Hugging Faceエコシステム

7.1 Hub:モデルの探索

Hugging Face Hubには80万以上のモデルがホストされています。主な探索のヒント:

from huggingface_hub import list_models, model_info

# モデルを検索
models = list_models(
    filter="text-generation",
    sort="downloads",
    direction=-1,
    limit=10
)
for m in models:
    print(m.id, m.downloads)

# モデル情報を取得
info = model_info("meta-llama/Meta-Llama-3.1-8B-Instruct")
print(info.tags)
print(info.cardData)

7.2 モデルカードとライセンス

プロダクションでモデルを使用する前に、必ずモデルカードを確認してください。確認事項:

  • ライセンスの種類(Apache 2.0、Llamaコミュニティ、MIT、カスタム)
  • 意図された用途と対象外の用途
  • 既知のバイアスと制限事項
  • 評価結果

7.3 GGUFモデルリポジトリ

llama.cpp / Ollama向けには、信頼できる量子化提供者のGGUFモデルを探してください:

  • bartowski — 高品質GGUFモデル、複数の量子化レベル
  • TheBloke — 大規模カタログ(現在はメンテナンスが少ない)
  • lmstudio-community — LM Studio向けにキュレーション

GGUFの命名規則:

Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
│                            │
└─ モデル名                  └─ 量子化方式

主な量子化サフィックス:
Q4_K_M  - 4ビット、品質/速度のバランス(ほとんどの用途で推奨)
Q5_K_M  - 5ビット、より高品質、より多いメモリ
Q6_K    - 6ビット、準無損失、高メモリ
Q8_0    - 8ビット、事実上無損失
Q2_K    - 2ビット、非常に低品質、非常に少ないメモリ
IQ4_XS  - 4ビット「重要度量子化」、Q4_K_Mより高品質

7.4 Spaces:ブラウザでモデルを試す

Hugging Face Spacesを使えば、ダウンロード前にモデルを体験できます:

# Space APIを経由して呼び出す
from gradio_client import Client

client = Client("meta-llama/Llama-3.1-8B-Instruct")
result = client.predict(
    message="トランスフォーマーのアテンションメカニズムを説明してください",
    api_name="/chat"
)
print(result)

8. 量子化手法

8.1 なぜ量子化するのか?

Llama 3.1 70BをbflO16で実行するには約140GBのGPUメモリが必要です — コンシューマ向けシングルGPUでは不可能です。量子化はわずかな品質劣化を許容することでメモリを削減し、推論速度を向上させます。

Llama 3.1 70Bのメモリ比較:

精度メモリ品質用途
bfloat16約140 GB基準値マルチGPU A100
int8約70 GB-0.1%A100 80GB 1枚
Q4_K_M(GGUF)約43 GB-0.5%コンシューマ24GB GPU 2枚
int4(AWQ/GPTQ)約35 GB-1.0%A100 40GB 1枚
Q2_K約24 GB-5%以上プロダクション非推奨

8.2 GPTQ:学習後量子化

from transformers import AutoModelForCausalLM, GPTQConfig

# 一回限りの量子化(キャリブレーションデータが必要)
quantization_config = GPTQConfig(
    bits=4,
    dataset="c4",
    block_size=128
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Meta-Llama-3.1-8B-Instruct",
    quantization_config=quantization_config,
    device_map="auto"
)

model.save_pretrained("./llama-3.1-8b-gptq")

8.3 AWQ:活性化認識重み量子化

AWQは一般的にGPTQより精度が高く好まれます:

# インストール
pip install autoawq

# 量子化
python -c "
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = 'meta-llama/Meta-Llama-3.1-8B-Instruct'
quant_path = './llama-3.1-8b-awq'

model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)

quant_config = {'zero_point': True, 'q_group_size': 128, 'w_bit': 4, 'version': 'GEMM'}
model.quantize(tokenizer, quant_config=quant_config)

model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)
print('量子化完了')
"

8.4 学習時のbitsandbytes(BnB)

ファインチューニング(特にQLoRA)の場合、bitsandbytesは別途量子化ステップなしにランタイム量子化を提供します:

# 上記のQLoRAセクションで既に示した方法
# load_in_4bit=TrueのBitsAndBytesConfigを使用
# NF4量子化がQLoRAファインチューニングに最適

9. 適切なモデルの選び方

9.1 意思決定フレームワーク

                 ┌──────────────────────┐
                 │  タスクは何ですか?   │
                 └──────────┬───────────┘
          ┌─────────────────┼─────────────────┐
          ▼                 ▼                 ▼
    コード生成          多言語処理          一般チャット
          │                │                  │
    Qwen2.5-Coder     Qwen2.5 / Llama    Llama 3.1 8B
    DeepSeek-Coder    / Mistral NeMo     Mistral 7B
    CodeGemma                            Gemma 2 9B

   ローカル実行が
   必要ですか?
    ┌─────┴─────┐
    │はい       │いいえ
    ▼           ▼
 RAMは十分?  vLLMを使用
+ Llama 70B
  ┌─┴──┐    または405B
  │    │
 <=8GB >8GB
  │    │
 8B   70B
 Q4   Q4_K_M

9.2 ハードウェア要件

モデル最小GPUメモリ推奨量子化
Gemma 2 2B3 GBRTX 3060fp16
Llama 3.1 8B5 GBRTX 3060 12GBQ4_K_M
Mistral 7B5 GBRTX 3060 12GBQ4_K_M
Gemma 2 27B16 GBRTX 3090Q4_K_M
Llama 3.1 70B40 GBA6000 2枚Q4_K_M
Mixtral 8x7B26 GBA100 40GBQ4_K_M
Llama 3.1 405B200 GBA100 80GB 4枚Q4_K_M

9.3 ベンチマークに基づく選択(2026年3月)

プロダクションモデルの選定には、LMSYS Chatbot ArenaとOpen LLM Leaderboardを出発点として活用しますが、必ず自社ドメインの評価を行ってください。ベンチマークのランキングは新モデルのリリースとともに毎月変わります。

一般的なガイドライン:

  • 最良の小型モデル(8B以下):Llama 3.1 8BまたはGemma 2 9B
  • 最良の中型モデル(7B〜30B):Llama 3.3 70BまたはMistral Small 3
  • 最良のオープンウェイト全体:DeepSeek-V3またはLlama 3.1 405B
  • 最良のコードモデル:Qwen2.5-Coder 32BまたはDeepSeek-Coder-V2
  • 最良の推論モデル:QwQ 32BまたはDeepSeek-R1

10. オープンソース vs プロプライエタリ:使い分けの指針

10.1 直接比較

次元オープンソースプロプライエタリ
品質の上限やや低い(2026年時点では差は小さい)最先端タスクでは高い
大規模コスト低い(ハードウェアコストのみ)トークンごとに高い
データプライバシー完全なコントロールデータがインフラ外に出る
セットアップ複雑性高い低い(APIキーのみ)
カスタマイズ完全(ファインチューニング、プロンプト)限定的(プロンプト、一部ファインチューニング)
信頼性自己責任プロバイダーのSLA
レイテンシ自社インフラ可変(共有)
コンテキストウィンドウ最大128K以上最大200K以上
マルチモーダル限定的(最高モデルはテキスト専用)強力(GPT-4o、Claude 3.5)

10.2 オープンソースを選ぶべき場合

オープンソースを強く推奨する場合:

  • 機密データの処理(医療、法律、金融、個人情報)
  • 大容量・コスト重視のアプリケーション(1日100万トークン超)
  • コンプライアンスによりデータの所在地要件がある場合
  • ドメイン固有のファインチューニングが必要な場合
  • ベンダーロックインを避けたい場合

プロプライエタリを強く推奨する場合:

  • すぐに使える最高品質が重要な場合
  • 最新のマルチモーダル機能が必要な場合
  • チームにMLOpsの専門知識が不足している場合
  • プロトタイプを素早く構築したい(APIの方が開始が速い)
  • 非常に長いコンテキスト(128Kトークン超)が必要な場合

10.3 ハイブリッド戦略

多くのプロダクションシステムは両方を組み合わせています:

def route_request(request: dict) -> str:
    """要件に基づいてオープンソースまたはプロプライエタリにルーティング。"""

    # 機密データは常にオープンソースを使用
    if request.get("contains_pii") or request.get("confidential"):
        return "local_llama_70b"

    # 大容量の単純タスクはオープンソースを使用
    if request.get("task_type") in ["classification", "extraction", "summarization"]:
        if request.get("volume") == "high":
            return "local_llama_8b"

    # 複雑な推論やマルチモーダルはプロプライエタリを使用
    if request.get("requires_vision") or request.get("complexity") == "high":
        return "gpt_4o"

    # デフォルト:コスト削減のためローカルモデル
    return "local_llama_70b"

まとめ

2026年のオープンソースLLMエコシステムは前例のない水準の性能を提供しています:

レイヤートップの選択肢
小型モデル(8B以下)Llama 3.1 8B、Gemma 2 9B、Phi-4
中型(8B〜30B)Mistral Small 3、Qwen2.5 32B、Gemma 2 27B
大型(70B以上)Llama 3.1 70B、Qwen2.5 72B
フロンティアDeepSeek-V3、Llama 3.1 405B
コードQwen2.5-Coder 32B、DeepSeek-Coder-V2
推論DeepSeek-R1、QwQ 32B
ローカル推論Ollama、llama.cpp
プロダクション運用vLLM、TGI
ファインチューニングLoRA + SFTTrainer、QLoRA

2024年から2026年にかけての最も重要な変化は、プロプライエタリモデルとの品質差が縮まったことです。RAG、チャットボット、コード生成、情報抽出など、ほとんどのアプリケーションで最上位のオープンソースモデルはGPT-4やClaudeと十分に競合します。プライバシー、コスト、カスタマイズ — オープンソースを選ぶ理由はかつてないほど強力です。

知識確認クイズ

Q1. 「オープンウェイト」モデルと「真のオープンソース」モデルの違いは何ですか?

答え: オープンウェイトモデルはモデルの重みを公開しますが、学習データ、学習コード、完全な学習方法論は公開しません(例:Llama 3、Mistral、Gemma)。真のオープンソースモデルは重み、学習コード、学習データをすべて公開します(例:OLMo、Pythia)。この区別は再現性、研究、データ汚染の理解という観点から重要です。

解説: この違いはライセンスや商用利用の可否だけでなく、研究者がモデルの挙動を完全に検証できるかどうかにも影響します。真のオープンソースモデルは少数ですが、科学的な透明性という面で非常に価値があります。

Q2. Mixture of Experts(MoE)とは何ですか?また推論効率にどう影響しますか?

答え: MoEは密なフィードフォワード層を複数の「専門家」サブネットワークに置き換え、ルーターがトークンごとに少数(例:8つ中2つ)を選択します。これにより同じ推論コストの密なモデルよりも多くの総パラメータを持てます。例えばMixtral 8x7Bは総56Bパラメータを持ちますが、トークンごとのアクティブパラメータは約12.9Bで、約13Bの推論コストで70B近くの品質を実現します。

解説: MoEは「総パラメータ数」と「推論コスト」を切り離す革新的な設計です。モデルが大きな知識ベースを持ちながら、実際の推論時には小さなモデルと同程度の計算量で済みます。

Q3. QLoRAとは何ですか?どのようなハードウェア制約を解決しますか?

答え: QLoRAは4ビット量子化(bitsandbytes NF4)とLoRAアダプターを組み合わせたものです。ベースモデルを4ビットに量子化してメモリを4分の1に削減し、学習可能なLoRAアダプターは高い精度を維持します。これにより、フル精度ファインチューニングでは不可能(モデルとオプティマイザ状態だけで約280GBが必要)な70Bモデルのファインチューニングを、シングル80GB A100 GPUで実現できます。

解説: QLoRAの核心は「推論時は量子化した低精度モデルを使いながら、学習させる部分(LoRAアダプター)は高精度に保つ」という巧みな設計にあります。

Q4. vLLMのPagedAttentionとは何ですか?どんな問題を解決しますか?

答え: PagedAttentionはOSの仮想メモリ管理から借用したページングメカニズムでKVキャッシュを管理します。従来のLLMサーバーはリクエストごとに最大長に合わせた固定メモリブロックを事前割り当てするため、シーケンスが短い場合にメモリを無駄にしていました。PagedAttentionは必要に応じて小さなページ単位でメモリを割り当て、リクエスト間でページを共有できるため、GPU メモリの利用効率を大幅に高め、同じハードウェアでより高いスループットを実現します。

解説: これによりvLLMは同じGPUで従来のサーバーに比べて数倍のリクエストを並行処理できるようになります。PagedAttentionはvLLMが業界標準となった最大の理由の一つです。