💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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 8B | 8B | 128K | 小型モデル中最高クラス |

| Llama 3.1 70B | 70B | 128K | 多くのタスクでGPT-4oに匹敵 |

| Llama 3.1 405B | 405B | 128K | 最大規模、フロンティア級品質 |

| Llama 3.2 1B / 3B | 1B, 3B | 128K | エッジデプロイ、マルチモーダル |

| Llama 3.2 11B / 90B | 11B, 90B | 128K | ビジョン・言語モデル |

| Llama 3.3 70B | 70B | 128K | 3.1 70Bから改良 |

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

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

2.2 Mistral AI

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

| モデル | パラメータ数 | 備考 |

| ---------------- | ------------------- | ------------------------------------------------------------ |

| Mistral 7B v0.3 | 7B | オリジナルの高効率モデル、インストラクションチューニング済み |

| Mistral NeMo 12B | 12B | NVIDIAとの協業、コーディングに強い |

| Mistral Small 3 | 24B | 効率的な商用グレードモデル |

| Codestral | 22B | コード特化、80以上の言語に対応 |

| Mixtral 8x7B | 56B（12.9B active） | Mixture of Experts、高速推論 |

| Mixtral 8x22B | 141B（39B active） | 最高のMoE汎用モデル |

**ライセンス**：ベースモデルはApache 2.0（許容的、商用利用フレンドリー）。

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

2.3 Google Gemma

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

| モデル | パラメータ数 | 備考 |

| ------------ | ------------ | ---------------------------------------- |

| Gemma 2 2B | 2B | 2Bモデル中最高クラス |

| Gemma 2 9B | 9B | 複数のベンチマークでLlama 3.1 8Bを上回る |

| Gemma 2 27B | 27B | 強力で効率的な27Bモデル |

| CodeGemma 7B | 7B | コード特化 |

| PaliGemma | 3B | ビジョン・言語モデル |

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

2.4 Qwen（Alibaba）

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

| モデル | パラメータ数 | 備考 |

| --------------------- | ------------ | -------------------------------- |

| Qwen2.5 0.5B〜72B | 複数サイズ | 強力な多言語対応（中国語/英語） |

| Qwen2.5-Coder 7B〜32B | 7B, 32B | 優れたコード生成 |

| Qwen2.5-Math 7B〜72B | 7B, 72B | 数学的推論 |

| QwQ 32B | 32B | 推論モデル、o1スタイルの思考連鎖 |

| Qwen2-VL | 7B, 72B | 強力なビジョン・言語 |

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

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

2.5 DeepSeek

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

| モデル | パラメータ数 | 備考 |

| ----------------- | ---------------------- | --------------------------------- |

| DeepSeek-V2 | 236B MoE（21B active） | 非常にコスト効率の高い推論 |

| DeepSeek-V3 | 671B MoE（37B active） | GPT-4に近い品質、オープンウェイト |

| DeepSeek-R1 | 複数サイズ | 思考過程が見える推論モデル |

| DeepSeek-Coder-V2 | 236B MoE | 強力なコード生成 |

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

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

2.6 その他の注目モデル

| モデル | 組織 | 強み |

| ------------- | --------- | ----------------------------- |

| Phi-3 / Phi-4 | Microsoft | 小型サイズ（3.8B〜14B）で強力 |

| Command R+ | Cohere | 検索拡張タスク |

| Falcon 180B | TII | 大規模オープンモデル |

| Yi 34B | 01.AI | 強力な多言語対応 |

| Orca 3 | Microsoft | 指示追従 |

| SOLAR 10.7B | Upstage | 韓国語/英語バイリンガル |

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 GB（KVキャッシュのみ）

長いコンテキストのリクエスト処理がメモリ集約的な理由、そして量子化された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

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 ローカル推論ツールの比較

| ------------ | ------------------------ | ------------- | ------------------ | -------------- |

| llama.cpp | CPU推論、埋め込み | 任意 | 普通 | 優秀 |

| vLLM | プロダクション運用 | 必要 | 普通 | 優秀 |

| TGI | プロダクション運用 | 必要 | 普通 | 優秀 |

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

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 2B | 3 GB | RTX 3060 | fp16 |

| Llama 3.1 8B | 5 GB | RTX 3060 12GB | Q4_K_M |

| Mistral 7B | 5 GB | RTX 3060 12GB | Q4_K_M |

| Gemma 2 27B | 16 GB | RTX 3090 | Q4_K_M |

| Llama 3.1 70B | 40 GB | A6000 2枚 | Q4_K_M |

| Mixtral 8x7B | 26 GB | A100 40GB | Q4_K_M |

| Llama 3.1 405B | 200 GB | A100 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が業界標準となった最大の理由の一つです。

目次

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

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

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

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

2.1 Meta Llama

2.2 Mistral AI

2.3 Google Gemma

2.4 Qwen（Alibaba）

2.5 DeepSeek

2.6 その他の注目モデル

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

3.1 Grouped Query Attention（GQA）

3.2 Rotary Position Embeddings（RoPE）

3.3 Mixture of Experts（MoE）

MoE層のコンセプト（簡略化）

ルーターがtop-k専門家を選択

選択された専門家の出力の重み付き和

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

4. ローカル推論ツール

4.1 Ollama

インストール（macOS/Linux）

モデルをインタラクティブに実行

特定の量子化で実行

実行せずにダウンロードのみ

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

APIサーバーとして実行（OpenAI互換！）

ローカルOllamaに接続

4.2 llama.cpp

ビルド

GGUFモデルをダウンロード（例）

Hugging Faceから: bartowski/Meta-Llama-3.1-8B-Instruct-GGUF

推論を実行

OpenAI互換サーバーとして実行

4.3 Transformers（Hugging Face）

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

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

5.1 なぜvLLMなのか？

5.2 vLLMサーバーの起動

インストール

サーバー起動（シングルGPU）

テンソル並列処理でマルチGPU（4枚）

量子化適用（AWQ）

5.3 vLLMサーバーの使用

ストリーミング

5.4 DockerでvLLMを実行

Dockerfile

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

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

6.2 LoRA：Low-Rank Adaptation

LoRA設定

trainable params: 83,886,080 || all params: 8,114,474,240 || trainable%: 1.03%

6.3 QLoRA：量子化されたLoRA

4ビット量子化設定

kビット学習の準備（層正規化をfp32にキャストなど）

量子化モデルの上にLoRAを適用

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

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

ベースモデルをロード

LoRA重みをロードしてマージ

マージされたモデルを保存（標準HF形式、vLLM等と互換）

7. Hugging Faceエコシステム

7.1 Hub：モデルの探索

モデルを検索

モデル情報を取得

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

7.3 GGUFモデルリポジトリ

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

Space APIを経由して呼び出す

8. 量子化手法

8.1 なぜ量子化するのか？

8.2 GPTQ：学習後量子化

一回限りの量子化（キャリブレーションデータが必要）

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

インストール

量子化

8.4 学習時のbitsandbytes（BnB）

上記のQLoRAセクションで既に示した方法

load_in_4bit=TrueのBitsAndBytesConfigを使用

NF4量子化がQLoRAファインチューニングに最適