2026年のオープンソースAIの決定版ガイド。最先端モデル、トレーニングフレームワーク、推論サーバー、ファインチューニング手法、ベクトルデータベース、オーケストレーションツール — そしてユースケースに応じた適切なスタックを選ぶための実践的な指針。
2022年、GPT-3.5 はオープンソースコミュニティにとって到達不可能と広く見なされていた。その差は越えがたく感じられた。2026年までに状況は劇的に変わった:Llama 4 Maverick はほとんどのベンチマークで最先端のクローズドモデルと競合し、DeepSeek-R1 は数学的推論で OpenAI o1 に挑み、オープンソースのエコシステムは狭い領域でクローズドの同等品を上回る専門モデルを生み出してきた。
企業と開発者にとって、これは初めて真の選択肢を意味する。オープンウェイトのモデルはもはや次善策ではなく、しばしば第一の選択肢である。
モデルは完全に自社のインフラ上で動作する。データが環境を離れることは決してない — 医療、法務、金融、その他あらゆる規制業界にとって極めて重要だ。
単一の A100 クラスターが、大量利用時のトークン単位 API コストを置き換える。月間1000万件以上のリクエストでは、自社ホスト型モデルは通常5〜20倍のコスト削減をもたらす。
自社の領域、トーン、データでファインチューニングできる。クローズド API はプロンプトエンジニアリングを与えるが、オープンウェイトはモデルの完全な制御を与える。
運用負担。モデルを自社ホストするということは、インフラのプロビジョニング、モデルの更新、監視、キャパシティ計画、インシデント対応を自ら担うことを意味する。クローズド API はそのすべてを外部委託する。問うべきは決して「オープンソースは優れているか?」ではなく — 「それを確実に運用できるエンジニアリング能力があるか?」である。
graph TB A["Foundation Models (Llama 4, Mistral Large 3, Qwen 2.5, DeepSeek R2)"] --> B["Fine-tuned / Instruction-tuned Variants"] B --> C["Inference Server (vLLM / TGI / Ollama)"] C --> D["Orchestration Layer (LangChain, LlamaIndex, CrewAI)"] D --> E["Application (RAG, Agents, Chatbot, Code assistant)"]
2026年初頭時点の全体像。MMLU スコアはあくまで参考値 — 本番用にモデルを選定する前に、必ず自社の具体的なタスクでベンチマークすること。
| モデル | 組織 | パラメータ | コンテキスト | ライセンス | MMLU | 最適な用途 |
|---|---|---|---|---|---|---|
| Llama 4 Maverick | Meta | 400B (MoE) | 1M | Llama 4 | 87.5 | 最先端と競合、マルチモーダル |
| Llama 4 Scout | Meta | 109B (MoE) | 10M | Llama 4 | 79.6 | 長コンテキスト、効率的な MoE |
| Llama 4 Behemoth | Meta | 2T (MoE, preview) | 256K | Llama 4 | 92.0 | 最大の能力(教師モデル) |
| Mistral Large 3 | Mistral | 123B | 128K | MRL | 84.0 | エンタープライズ、欧州コンプライアンス |
| Mistral Small 3 | Mistral | 24B | 128K | Apache 2.0 | 81.0 | 効率的、寛容なライセンス |
| DeepSeek-R1 | DeepSeek | 671B (MoE) | 128K | MIT | 90.8 | 推論、数学、コード |
| DeepSeek-R1-Distill-70B | DeepSeek | 70B | 128K | MIT | 86.7 | 効率的な推論 |
| Qwen2.5 72B | Alibaba | 72B | 128K | Qwen License | 86.6 | 多言語、コーディング |
| Qwen2.5-Coder 32B | Alibaba | 32B | 128K | Apache 2.0 | — | コード生成 |
| Gemma 2 27B | 27B | 8K | Gemma | 75.2 | コンパクト、よく最適化済み | |
| Phi-4 | Microsoft | 14B | 16K | MIT | 84.8 | 小型ながら驚くほど高性能 |
商用利用に最も寛容。特許権を付与し、改変と再配布を許可する。Mistral は主力モデルにこれを採用している。
極めて寛容で、制限は最小限。DeepSeek は MIT の下でリリースしており、その結果、同社のモデルは最も自由にライセンスされた最先端モデルの一つとなっている。
ほとんどの商用利用に寛容だが、月間アクティブユーザーが7億人を超える製品・サービスにはライセンス契約が必要。Llama 3 と同じ条件。
重要な区別:「open weight」はモデルの重みが利用可能であることを意味するが、トレーニングコードやデータは利用できない場合がある。真のオープンソース(Mistral など)は両方をリリースする。
汎用モデルは始まりにすぎない。オープンソースのエコシステムは、その領域内でははるかに大きな汎用モデルを上回る、非常に高性能な専門モデルを生み出してきた。
欧州企業にとって、Mistral のモデル(Mistral Small 3 は Apache 2.0 ライセンス、EU 本社、EU ホスティングの選択肢あり)は、コンプライアンスとデータ主権の理由からしばしば既定の選択肢となる。Mistral Small 3 と Mistral Large 3 は、明確な欧州由来を備えた寛容または商用にやさしいライセンスを提供し、多くの調達およびデータレジデンシー要件を満たす。
二つのフレームワークが支配的だ:PyTorch と JAX。JAX を選ぶ特別な理由がない限り、PyTorch から始めるとよい — エコシステム、ツール、コミュニティのサポートが比類ない。
動的計算グラフ、命令型の実行スタイル、そしてあらゆる ML フレームワークの中で最大のエコシステム。Meta、Microsoft、Hugging Face、そして研究コミュニティの大多数が使用している。
XLA コンパイルを備えた Google の関数型 ML フレームワーク。TPU で卓越し、関数変換(grad、jit、vmap、pmap)を可能にする。Flax と Equinox はその上に構築された主要なニューラルネットワークライブラリだ。
Hub から任意のモデルを読み込み、ファインチューニングし、共有する。オープンソースAIエコシステムの中核ライブラリ。
教師ありファインチューニング(SFT)、RLHF、DPO、GRPO のトレーニングループ。アライメントトレーニングの標準ライブラリ。
マルチ GPU、マルチノード、混合精度トレーニングのための単一の抽象化レイヤー。一度書けば、どこでも実行できる。
ZeRO オプティマイザーのステージ 1/2/3、3D 並列化(tensor、pipeline、data)。非常に大きなモデルのトレーニングに必須。
Fully Sharded Data Parallel — DeepSpeed ZeRO に対する PyTorch ネイティブの回答。統合がよりシンプルで、性能は同等。
from transformers import AutoTokenizer, AutoModelForCausalLM
from trl import SFTTrainer, SFTConfig
from datasets import load_dataset
import torch
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Llama-4-Scout-17B-16E-Instruct",
torch_dtype=torch.bfloat16,
device_map="auto",
)
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-4-Scout-17B-16E-Instruct")
dataset = load_dataset("HuggingFaceH4/ultrachat_200k", split="train_sft[:10000]")
trainer = SFTTrainer(
model=model,
args=SFTConfig(
output_dir="./sft-output",
num_train_epochs=3,
per_device_train_batch_size=4,
),
train_dataset=dataset,
processing_class=tokenizer,
)
trainer.train()完全なファインチューニングは事前学習と同数の GPU を必要とし — ほとんどのチームには手が届かない。パラメータ効率の良いファインチューニング(PEFT)手法により、単一の GPU で最先端モデルを適応させることが可能になる。
すべてのモデルの重みを更新する代わりに、LoRA は凍結された重み行列と並んで小さなアダプター行列 A と B を追加する。アダプターのみがトレーニングされ、7B モデルでは学習可能なパラメータを最大10,000分の1に削減する。
ランク r がアダプターの容量を制御する。典型的な値:8〜64。ランクが高いほど容量は増えるがパラメータも増える。推論時には、アダプターをベースモデルにマージしてオーバーヘッドをゼロにできる。
QLoRA はベースモデルの重みを 4-bit NF4(Normal Float 4)に量子化し、その後 LoRA アダプターを bfloat16 でトレーニングする。これにより、通常は16基の GPU クラスターを必要とする 70B モデルのファインチューニングを、わずか 2× A100 80GB GPU で行える。アダプターがより高い精度でトレーニングされる場合、量子化による品質の低下は最小限だ。
from peft import LoraConfig, get_peft_model
lora_config = LoraConfig(
r=16, # rank — controls adapter capacity
lora_alpha=32, # scaling factor (alpha/r = effective LR)
target_modules=["q_proj", "v_proj", "k_proj", "o_proj"],
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM",
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# trainable params: 6,815,744 || all params: 8,036,802,560 || trainable%: 0.085| 手法 | GPU メモリ(7B) | 学習可能パラメータ | 品質 | 最適なユースケース |
|---|---|---|---|---|
| Full Fine-Tuning | ~112 GB | 100% | 最高 | 品質が最優先で GPU が潤沢な場合 |
| LoRA | ~16 GB | 0.1–1% | ほぼ完全 | スタイル/フォーマットの適応、instruction tuning |
| QLoRA | ~6 GB | 0.1–1% | LoRA の95〜98% | リソース制約下のファインチューニング、2基の GPU で 70B |
重み行列を大きさと方向の成分に分解し、その後 LoRA を方向成分のみに適用する新しいバリアント。同じランクで標準の LoRA より良い品質を達成することが多い。peft では use_dora=True を介してサポートされる。
ファインチューニングを使う場合:
RAG を使う場合:
モデルを手に入れたら、それをサービングする必要がある。推論サーバーの選択が、スループット、レイテンシ、運用上の複雑さを左右する。本番ワークロードでは、vLLM が最も広く採用されている選択肢だ。
| サーバー | 言語 | 最適な用途 | 量子化 | ストリーミング | ライセンス |
|---|---|---|---|---|---|
| vLLM | Python | 高スループットの本番環境 | GPTQ, AWQ, GGUF | ✓ | Apache 2.0 |
| TGI | Rust/Python | HuggingFace スタック | bitsandbytes, GPTQ | ✓ | Apache 2.0 |
| Ollama | Go | ローカル開発 | GGUF (llama.cpp) | ✓ | MIT |
| llama.cpp | C++ | エッジ/CPU/Apple Silicon | GGUF all levels | ✓ | MIT |
| LMDeploy | Python | 高速推論 + int4 | W4A16, W8A8 | ✓ | Apache 2.0 |
| Triton Inference Server | C++ | マルチフレームワーク本番環境 | Backend dependent | ✓ | BSD |
従来の推論は KV キャッシュを大きな連続ブロックで割り当て、メモリを浪費し、異なるシーケンス長のリクエストのバッチ処理を妨げる。PagedAttention は KV キャッシュを仮想メモリページのように扱う — ブロックはオンデマンドで割り当てられ、可能な場合はリクエスト間で共有される。これにより連続バッチ処理(新しいリクエストが進行中のバッチに加わる)が可能になり、素朴なサービングと比べて GPU 利用効率が2〜4倍向上する。
# Start vLLM OpenAI-compatible server
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-4-Scout-17B-16E-Instruct \
--dtype bfloat16 \
--max-model-len 8192 \
--port 8000from openai import OpenAI
# vLLM exposes an OpenAI-compatible API
client = OpenAI(base_url="http://localhost:8000/v1", api_key="token")
response = client.chat.completions.create(
model="meta-llama/Llama-4-Scout-17B-16E-Instruct",
messages=[{"role": "user", "content": "Explain attention mechanisms"}],
temperature=0.7,
max_tokens=512,
)
print(response.choices[0].message.content)開発、エアギャップ環境、または個人利用のために、ローカル推論ツールはクラウドアカウントなしでコンシューマー向けハードウェア上でモデルを実行できるようにする。Ollama が最も簡単な入り口だ。
モデルのダウンロード、GGUF 量子化を管理し、OpenAI 互換のローカル API を公開する。Python 環境は不要。
# Install Ollama
curl -fsSL https://ollama.ai/install.sh | sh
# モデルのプルと実行
ollama run llama4:scout # ~23 GB GGUF Q4_K_M(MoE、効率的)
ollama run mistral-small3 # ~14 GB GGUF Q4
ollama run deepseek-r1:70b # ~40 GB
ollama run qwen2.5-coder:7b # コード専門
# ダウンロード済みモデルの一覧
ollama list| 形式 | ビット/重み | 品質 | 推奨用途 |
|---|---|---|---|
| Q2_K | 2-bit | 低 | RAM の絶対的最小限 |
| Q4_K_M | 4-bit | 良好 | 品質/サイズの最良のバランス — 推奨される既定値 |
| Q5_K_M | 5-bit | 非常に良好 | RAM に余裕がある場合 |
| Q6_K | 6-bit | 優秀 | ほぼ無損失、RAM が潤沢な場合 |
| Q8_0 | 8-bit | ほぼ無損失 | 開発、RAM の多いシステム |
| F16 | 16-bit | 無損失 | 最高品質、サーバー GPU のみ |
| ハードウェア | 推奨モデル |
|---|---|
| MacBook M2/M3/M4 (16GB) | 8B Q4_K_M |
| MacBook M2 Pro (32GB) | 13-14B Q4_K_M |
| MacBook M3 Max (64GB) | 70B Q4_K_M |
| RTX 3090 24GB | 13B Q8_0 or 30B Q4 |
| A100 80GB | 70B FP16 or Llama 4 Scout Q4 |
| 2× A100 80GB | Llama 4 Maverick Q4 or 70B FP16 |
ローカルモデル用のクロスプラットフォーム GUI。HuggingFace から参照・ダウンロード、OpenAI 互換のローカルサーバー、ハードウェア使用状況の監視。開発者でないユーザーに最適。
プライバシー優先のデスクトップ LLM アプリケーション。100% オフライン、オープンソース(AGPL)、Ollama 互換モデルをサポート。テレメトリをゼロにしたいユーザー向けに作られている。
ベクトルデータベースは RAG システムの背骨だ。適切な選択は、規模、既存のインフラ、そしてベクトル検索と並んでメタデータフィルタリングが必要かどうかに依存する。
| データベース | 種類 | 規模 | ライセンス | 独自の特長 |
|---|---|---|---|---|
| pgvector | PostgreSQL extension | 中 | Apache 2.0 | SQL + ベクトル、新規インフラ不要 |
| Chroma | Embedded/server | 小〜中 | Apache 2.0 | 最もシンプルな API、プロトタイピングに最適 |
| Qdrant | Rust server | 大 | Apache 2.0 | ペイロードフィルタリング、高速 |
| Weaviate | Go server | 大 | BSD | ハイブリッド検索、GraphQL |
| Milvus | C++ server | 非常に大 | Apache 2.0 | 十億規模、クラウドネイティブ |
| LanceDB | Embedded | 中 | Apache 2.0 | Arrow ネイティブ、サーバーレス |
すでに PostgreSQL を運用しているなら、pgvector は新規インフラなしでベクトル検索を追加する。IVFFlat または HNSW インデックスで数百万のベクトルを余裕で扱える — 本番の RAG システムの大半には十分すぎるほどだ。
-- Enable the extension
CREATE EXTENSION IF NOT EXISTS vector;
-- Create table with vector column
CREATE TABLE documents (
id bigserial PRIMARY KEY,
content text,
embedding vector(1536) -- dimension matches your embedding model
);
-- Create approximate nearest neighbor index (IVFFlat)
CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);
-- Alternatively, HNSW (better recall, slower build)
-- CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
-- Semantic similarity query
SELECT content, 1 - (embedding <=> '[0.1, 0.2, ...]'::vector) AS similarity
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 5;オーケストレーションフレームワークは、モデルをツール、メモリ、マルチステップのパイプラインに接続する。この分野は混み合っている — GitHub のスター数だけでなく、ユースケースに基づいて選ぶこと。
| フレームワーク | GitHub スター | 最適な用途 | 抽象化レベル |
|---|---|---|---|
| LangChain | 90k+ | 汎用パイプライン | 高 |
| LangGraph | 10k+ | 状態を持つエージェントワークフロー | 中 |
| LlamaIndex | 35k+ | RAG 中心のアプリケーション | 中 |
| CrewAI | 20k+ | マルチエージェント連携 | 高 |
| AutoGen | 30k+ | 会話型マルチエージェント | 中 |
| DSPy | 20k+ | プロンプト最適化 | 低〜中 |
| Semantic Kernel | 20k+ | .NET/エンタープライズ統合 | 高 |
| Haystack | 15k+ | NLP パイプライン、オープン | 中 |
DSPy は他のフレームワークとは異なる哲学をとる:プロンプトテンプレートを手作業で作る代わりに、タスクシグネチャ(入力、出力、制約)といくつかのラベル付き例を定義すると、DSPy が OPRO や BootstrapFewShot などのアルゴリズムを用いてプロンプトを自動的に最適化する。これはプロンプトの言い回しに敏感な、より小さなオープンソースモデルを扱うときに特に強力だ — 手作業で反復するのではなく、オプティマイザーに何が機能するかを見つけさせよう。
評価は、ほとんどのオープンソースAIプロジェクトが本番で失敗する場所だ。モデルを展開する前に、測定可能な品質基準を定義し、ベースラインを確立すること。
lm-evaluation-harness
by EleutherAI
オープンソースモデルの標準ベンチマークランナー。MMLU、HellaSwag、ARC、WinoGrande、その他60以上のベンチマークを実行する。Open LLM Leaderboard のスコア生成に使用される。
OpenCompass
by Shanghai AI Lab
100以上のベンチマークを備えた包括的な評価プラットフォーム。特に中国語ベンチマークとアジア言語モデルのカバレッジが充実している。
Ragas
by Explodinggradients
RAG 専用の評価フレームワーク。LLM-as-judge の手法を用いて、コンテキストリコール、忠実性、回答の関連性、コンテキストの精度を測定する。
DeepEval
by Confident AI
ユニットテスト形式の評価フレームワーク。Python で評価アサーションを書き、CI/CD に統合し、モデルのバージョンを通じてメトリクスを追跡する。
Evals
by OpenAI
OpenAI の評価形式は業界標準となっている。多くのオープンソースプロジェクトが相互運用性のために同じ評価構造を採用している。
HELMET
by Princeton
長コンテキスト言語モデルの総合的評価。大きなコンテキストウィンドウをうたうモデルにとって不可欠 — 実際の長コンテキストのリコールと推論をテストする。
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall
from datasets import Dataset
eval_data = Dataset.from_dict({
"question": ["What is LoRA?"],
"answer": ["LoRA adds low-rank adapter matrices to frozen weights..."],
"contexts": [["Low-Rank Adaptation adds trainable matrices A and B..."]],
"ground_truth": ["LoRA is a parameter-efficient fine-tuning method..."],
})
result = evaluate(
eval_data,
metrics=[faithfulness, answer_relevancy, context_recall]
)
print(result)
# {'faithfulness': 0.96, 'answer_relevancy': 0.89, 'context_recall': 0.92}普遍的に正しい答えは存在しない。これらの質問を順に検討すること — 各回答が選択肢を大幅に絞り込む。
データが自社のインフラを離れられないなら、既定でオープンソース専用の道にいることになる。これにより、あらゆるマネージド API サービスが直ちに除外される。まずインフラのサイジングを行うこと。
1日1Kリクエスト未満:単一マシン上の Ollama で十分。1日1K〜100K:単一の A100 ノード上の vLLM。1日100K超:ロードバランサーの背後の vLLM クラスターまたは TGI。非常に大量の場合、API アクセスと比べたコスト削減が数週間でインフラの元を取る。
おおまかな目安:7B モデル ≈ 14 GB FP16(または 5〜6 GB Q4);13B ≈ 26 GB;70B ≈ 140 GB FP16(または 40 GB Q4);405B ≈ 810 GB FP16(または 200 GB Q4)。KV キャッシュ用に20%のオーバーヘッドを加える。QLoRA ファインチューニングは推論メモリの約1.5倍を必要とする。
一般的なチャット → Llama 4 Scout。コード生成 → Qwen2.5-Coder。推論/数学 → DeepSeek-R1。多言語 → Qwen2.5 72B。文書 Q&A → Mistral Small 3 + pgvector。各領域に明確な勝者がいる — 専門モデルが存在するなら汎用モデルを使わないこと。
スタイルとフォーマットの変更 → LoRA(高速・低コスト)。領域固有の知識 → 自社コーパスでの QLoRA + SFT。推論の改善 → 選好データでの GRPO または DPO。ベースモデルの挙動がプロンプティングで十分に近いなら、ファインチューニングは完全に省くこと。
| ユースケース | モデル | サービング | オーケストレーション | ベクトル DB |
|---|---|---|---|---|
| 社内チャットボット | Llama 4 Scout | vLLM | LangChain | pgvector |
| コードアシスタント | Qwen2.5-Coder 7B | Ollama | Claude Code | — |
| 文書 Q&A | Mistral Small 3 | vLLM | LlamaIndex | Qdrant |
| マルチエージェントワークフロー | Llama 4 Scout | vLLM | LangGraph | pgvector |
| 推論タスク | DeepSeek-R1-Distill 7B | Ollama/vLLM | Custom | — |
| プライバシー重視 | Llama 4 Scout | Ollama (air-gapped) | Custom | Chroma |