📚 全体地図を見る
オープンソース LLM vs クラウド LLM — 損益分岐はどこか
「オープンソース LLMを使うべきか、Claudeで済ませるべきか」
この問いが技術ブログで妙に宗教戦争のように扱われているのをよく見ます。「オープンが未来だ」 vs 「クラウドが現実だ」 — どちらも間違いとは言わないけど、これは本来損益分岐の問題です。月にトークンをどれだけ使うか、データがどれほどセンシティブか、GPUを24時間回すサイズのワークロードがあるか。数字で答えが出ます。
この記事では宗教を外して、数学だけで見ていきます。
- 「オープンソース」という言葉の正確な意味 — open-weight と本物のOSIオープンソース
- 2026年4月時点でライセンスは4分類に割れる
- H100時間単価 × 720h vs API $/M tok の計算
- モデルサイズ別のVRAM要件
- 損益分岐 — 月2億トークンという境界線
- 推論エンジン3種(vLLM / TensorRT-LLM / SGLang) — 何をいつ
- ハイブリッドが実務で一番多く見られる理由
- シナリオ別の選び方
順に行きます。
1. 「オープンソース LLM」という言葉を正確に — 今の大半は open-weight
「オープンソース LLM」という言い方が、日本語のネットでもほぼ自動的にLlama・Qwen・DeepSeekを指す言葉になっています。ところが厳密に見るとこの用法は間違いです。
OSI(Open Source Initiative)が2024年10月に確定させたOpen Source AI Definition v1.0では、あるモデルが「オープンソースAI」と呼ばれるには三つが全部公開されている必要があります。
- 訓練データ: どのデータで学習したか、全リストとアクセス方法
- 訓練コード: 再現可能な学習スクリプト・ハイパーパラメータ
- 重み(weight): 最終モデルのパラメータ
この三つが揃って初めて「オープンソース」です。一つでも欠ければオープンソースではない。
問題は、Llama・Qwen・DeepSeekがいずれも重みだけ公開していることです。訓練データの具体的構成は非公開か概略のみで、訓練コードも非公開の部分が多い。
なので最近の業界で正確さを重視する書き方では 「open-weight(オープンウェイト)」 と呼びます。重みは開いたけれど、訓練データ・コードは閉じている、という意味。MetaもLlama 4の公式ブログで「open weights」という表現を使っています。
なぜこの区別が重要かというと、再現可能性の問題だからです。訓練データとコードがないと:
- 同じモデルをゼロから作り直せない
- 学習データにどんなバイアスが入ったか検証できない
- 著作権・プライバシーの問題を追跡できない
重みだけ公開のモデルは「無料で使えるブラックボックス」に近い。あなたがLlama 4をfine-tuneしてプロダクトに載せたとき、元のMetaがどんなデータで学習させたかは推測するしかない。
本記事では正確さのために 「open-weight LLM」 という表現を使いつつ、読者の便宜のためにタイトルと検索キーワードでは一般的な「オープンソース LLM」を残しています。同じものを指していると理解してください。
ⓘ この区別が初見なら 👉 F7. パラメータ理解で「モデルの中身は何か」を先に読んでおくと入ります。重み = パラメータの最終保存版です。
2. ライセンス4分類 — 2026年4月時点
「open-weight」と一口に言ってもライセンスは同じではありません。現在の主要モデルを商用の観点で4つに分けると、こうなります。
Llama 4 Maverick
MAU 7億人未満無料
DeepSeek V3.2
DeepSeek R1
| 区分 | ライセンス | OSI承認 | 商用 |
| Llama 4 Scout/Maverick | Llama 4 Community | NO | MAU 7億未満無料 |
| Qwen 3, Gemma 4 | Apache 2.0 | YES | 自由 |
| DeepSeek V3/V3.2/R1 | MIT | YES | 自由 |
| GPT-5.4 / Opus 4.7 / Gemini 3.1 | 独占 | — | APIのみ |
押さえておくポイントをいくつか。
(1) Llama 4は厳密には「open-weight」だがOSIオープンソースではない。
MetaのLlama 4 Community Licenseには「月間アクティブユーザー(MAU)7億人を超える企業は別途商用ライセンスを必要とする」という条項があります。つまりApple・Google・Amazonのような巨大プラットフォームがMetaの競合製品でLlamaを使うことを防ぐ条項。OSIオープンソース定義は「すべてのユーザー・用途に対して差別しないこと」を要件とするため、この一文でOSI承認を取れません。
(2) Qwen 3とGemma 4は本物のApache 2.0。
差別条項がない。商用自由、fine-tune自由、再配布自由。OSI承認済みの標準オープンソースライセンスです。GoogleのGemma 4も同じ方向 — 元は2024年のGemma 1で「use policy」が付いていましたが、現在のGemma 4ではApache系により開いた形に寄っています。
(3) DeepSeek V3系列はMIT — 最も自由な選択。
MITは「俺のコードを使って何かあっても俺は責任を負わない」が全部のライセンス。改変・再配布・商用化に何の制約もない。DeepSeekがこれを選んだのは 意図的な市場戦略 として読めます — 最も制約が少ない条件で最も早くエコシステムを取りに行く狙い。
(4) クローズドモデルはAPI経由でしか使えない。
GPT-5.4, Opus 4.7, Gemini 3.1 Proは重みそのものを絶対にダウンロードできません。あなたが使っているのはOpenAI/Anthropic/GoogleのクラウドGPUで動いているAPIエンドポイントだけ。これが「クラウド LLM」と呼ぶときの現実的な定義です。
ライセンス解釈はここまで。ここからは数学の話。
3. コスト数学 — API $/M tok vs H100時間単価
「自前で回したほうが安い」と言うには、まず数字が必要です。二つの軸で比較します。
A. API側の価格 (2026-04時点、1Mトークン単位、入力/出力)
– GPT-5.4: $2.50 / $15
– Opus 4.7: $5 / $25
– Sonnet 4.6: $3 / $15
B. H100 80GB GPUレンタル料金 (2026-04時点、時間単位)
– RunPod Community Cloud: $1.49/h (最安帯)
– 一般市場: $2.50~$3.00/h
– 高額スポット: $3.90/h
$1.49/h × 720h = 月$1,073
中間価格で月$1,800
高額スポット換算で月$2,808
つまりH100を1枚、1か月ノンストップで回すのにかかる金額はおよそ $1,073 ~ $2,808(日本円で約16万 ~ 42万円)。RunPodの格安コミュニティオプション基準で$1,073がfloorで、現実的には月$1,500~$2,000あたりが多い。
この金額をAPIに使ったらどうなるか計算してみます。Opus 4.7 入力基準で $1,073 / $5 per 1M = 2.1億 入力トークン。Sonnet 4.6 入力基準なら $1,073 / $3 = 3.6億トークン。GPT-5.4 入力基準なら 4.3億トークン。
あなたのワークロードが月2億トークン未満なら、H100を1枚借りて自分で回すより APIで使ったほうが必ず安いということです。これが以降繰り返し出てくる損益分岐の基準線の出発点。
ただしここまでは「APIの価格だけを並べた比較」です。実際にはさらにかかるコストがあります:
- エンジニアリング人件費(open-weightモデルのサービングは人手がかかる)
- ネットワーク・ストレージ・S3 egress
- モニタリング・ログ・アラート
- 失敗時の代替オプション(API fallbackがだいたい必要)
なので「純粋GPUコスト」がAPI予算より安いからといって、そのまま黒字になるわけではない。実務では「API費用の2~3倍のトークンを24/7使うワークロード」くらいにならないとself-hostが本当に得をしない、というのが保守的な見立てです。
4. VRAM数学 — どのモデルがどのGPUに乗るか
価格の次は モデルがGPUに乗るか の問題。VRAM容量が足りなければ載せることすらできません。
| モデルサイズ | 必要VRAM | GPU構成 | 例 |
| 7~13B | 24GB | RTX 4090 1枚 | Qwen 3 8B, Gemma 4 9B |
| 70B級 / MoE(17B active) | 80GB | H100 80GB 1枚 または A100 × 2 | Llama 4 Scout |
| 235B~671B MoE | 320~640GB | H100 × 4~8 + NVLink | Qwen 3 大型, DeepSeek V3 671B |
| Llama 4 10M コンテキスト | KV cacheで数百GB | マルチGPUシャーディング必須 | Llama 4 Scout 10M context |
ここで押さえておきたいポイント。
(1) 7~13Bモデルは個人PCでも回る。
RTX 4090が1枚あれば、Qwen 3 8BやGemma 4 9Bは十分回ります。家庭用デスクトップにAIルーターを挿すような感覚。ただし一度に処理できるのは1〜2名程度なので、同時に複数クエリを捌くならバッチ最適化が必要です。
(2) 70BはH100 1枚が基準線。
Llama 4 Scoutは 17B active MoE 構造なので実際の計算量は17B相当ですが、全体の重みをメモリに載せる必要があるためVRAMは70B級を要求します。H100 80GB 1枚、またはA100 40GB 2枚が現実的な最小構成。
(3) 235B~671B MoEはマルチGPUの世界。
DeepSeek V3 671BやQwen 3の上位モデルをまともに回すには、H100を4~8枚NVLinkで束ねた構成 が要ります。ここからはエンタープライズのインフラ領域。RAM 128GB以上、NVMe SSD 2TB以上も前提。個人開発者が趣味で回せるサイズではありません。
(4) 長いコンテキストは別のメモリ爆弾。
Llama 4の10Mコンテキストのような極端なケースでは、重みは乗っても KV cacheが数百GBまで膨れます。コンテキスト長 × レイヤー数 × 隠れ次元 × 2(K, V)の式で増えていく。なので長コンテキストをself-hostでやろうとするとGPU 1~2枚では絶対に足りず、シャーディング構成が必須です。
パラメータ数の感覚があやふやならF7. パラメータ理解を先に読んでおくと入ります。ここからはその知識が金額に換算される領域です。
5. 損益分岐グラフ — 月2億トークンという境界線
3章と4章をグラフ1枚にまとめます。
このグラフがこの記事の一行要約です。
月2億トークン未満 = API優位。月2億トークン以上 + 24/7稼働 = self-host検討の価値あり。
ただしここには必ず添えるべき現実の条件があります。
-
24/7稼働を実際にできるか。 H100を1枚借りたまま平日午前中だけ使う運用だと、空いた時間はただお金を捨てているだけ。ピーク負荷が日中に寄っているならスポットインスタンスやオートスケールが要ります。そしてそれを仕込むのは結局エンジニアの時間。
-
ワークロードが安定しているか。 今月は10億、来月は1,000万トークンのような変動の激しい業務では、self-hostは浪費。APIの最大の長所は 使った分だけ払う弾力性 です。
-
fine-tuneした特殊モデルが必要か。 既製モデルしか使わないなら、APIのチューニングオプション(OpenAI fine-tuning, Claude custom)を使うほうが総合的に安い。open-weightのself-hostが本当に要るのは 「APIでは対応できないサイズ・構造のfine-tuneをしたいとき」 です。
-
センシティブデータか。 医療・金融・法務のような領域では「データを外に出さない」が価格より優先される。この場合は損益分岐の計算自体が意味を持たず、self-hostが強制される。(エンタープライズのzero-retentionオプションの話は8章で。)
だから「self-hostが有利な月2億トークン」が実務で出てくるサイズはかなり限定的です。企業単位のプロダクショントラフィック、あるいは特殊チューンしたモデルを常時回すAIプロダクトが、そのくらいのサイズになります。
6. 推論エンジン3種 — vLLM, TensorRT-LLM, SGLang
self-hostを決めたとしても、次の問題がすぐ来ます。どの推論エンジンを使うか。
モデルの重みをGPUに載せるだけではまともなスループットが出ません。バッチ管理、KV cache再利用、tensor parallel、メモリページングといった最適化が必須で — これを自作せずに使えるのが推論エンジン。2026年4月時点で主導権を握っているのは3つです。
対応モデル数が最多。
PagedAttentionでKV cache効率化。
コミュニティ最大。
vLLM比+15~30%スループット。
NVIDIA専用、コンパイル必要。
モデル固定時に有利。
RadixAttentionでTTFT短縮。
chatbot・RAGに強い。
同一systemプロンプト反復時。
実務的な選び方を整理するとこうなります。
vLLMを基準にしてまず始めること。 対応モデルが最も多く、新しいモデルが最も早く載り、ドキュメントとコミュニティが最も大きい。self-hostの経験がまだ浅いなら、ここから始めて基準点を作ってください。PagedAttentionのおかげでKV cacheのメモリが満杯になって落ちるケースがほぼありません。
TensorRT-LLMは「あるモデルをH100で絞り切る必要があるとき」だけ。 スループット+15~30%はタダでは手に入りません。モデルごとにエンジンをコンパイルし直す必要があり、NVIDIA GPU以外では動かない。つまり 「モデルを頻繁に替えない」 という前提があって初めて価値が出ます。一度セットアップすればH100の性能を本当に使い切れる。
SGLangは特定パターンで急に光ります。 同じsystemプロンプトで複数のリクエストが来る場合 — たとえばチャットボット、RAG、プロンプトテンプレートを固定して後半のuserメッセージだけ変えるケース — RadixAttentionが先頭のトークンをキャッシュに保存するため、TTFT(最初のトークンまでの時間)が大きく縮む。同じシステムプロンプトが繰り返されるパターンで、vLLM比の体感差が出ます。
3つとも全部オープンソースで無料。商用のself-host環境では、「vLLMをベースに置いて、特定モデルのH100最大スループットが必要ならそのモデルだけTensorRT-LLMで絞り、チャット・RAG部分はSGLangに切り替える」 というハイブリッドが多い。
7. ハイブリッド — 実務で一番多く見られる本当の答え
ここまで来るとお気づきのはず。「オープン vs クラウド」は二択の問いではない、ということに。
実務で最も多く見るのは ハイブリッド構成 です。片方だけで完結している組織のほうが、むしろ珍しい。
代表的な3つのパターンを見ておきます。
パターン1 — Fine-tuneはクラウド、結果だけself-host
Together AIやFireworksのようなサービスでopen-weightモデルをクラウドGPUでfine-tuneし、学習の終わった重みを自社インフラに持ち帰ってサービングする。学習は一度きり・断続的なのでクラウドGPUで時間課金、サービングは常時なのでself-hostで固定費化。この組み合わせがキャッシュフロー的に最もきれいです。
パターン2 — Router構成: センシティブデータはself-host、一般はClaude
LiteLLM・OpenRouterのようなルーターレイヤーを前に立てて、データの機微度に応じて 後段のモデルを振り分ける。個人情報が入るクエリ → self-host Llama 4。一般文書要約・コーディング補助 → Claude API。同じアプリケーションの中で2経路が自動で分かれる設計です。
# 擬似コード (LiteLLMスタイル)
if has_pii(user_query):
model = "self-host/llama-4-scout"
else:
model = "anthropic/claude-sonnet-4-6"
response = completion(model=model, messages=[...])
こう書くと規制対応はself-hostで、それ以外の大半のクエリは品質の高いクラウドモデルに投げる、という恩恵を両取りできます。
パターン3 — エンタープライズのzero-retentionオプション
Anthropic・OpenAIの双方が、エンタープライズプランで「プロンプトとレスポンスを我々のサーバーに0日保持(zero-retention)する」オプションを提供しています。これを使えばログが残らない。センシティブデータの懸念を下げながら、APIの利便性をそのまま享受できる選択肢です。self-hostに行かなくていいケースがこれで片付く状況は意外と多い。
つまり「データが機微だからself-hostが必須」と即断する前に、まず使っているAPIのエンタープライズzero-retentionオプションを検討するのが順番。
8. シナリオ別の選び方 — いつ何を使うべきか
ここまでの話を1つの表にまとめます。
| シナリオ | 推奨 |
| 個人開発者・サイドプロジェクト | クラウドAPI (月2億トークン未満がほぼ確定) |
| スタートアップMVP (月1千万~1億トークン) | クラウドAPI + fallbackルーター |
| 本番AIプロダクト (月2~5億トークン) | ハイブリッド — コアはself-host(Qwen 3/Llama 4)、ピークはAPI |
| 医療・金融・法務 (データ機微) | self-host優先 + エンタープライズzero-retention検討 |
| 特殊fine-tuneがプロダクトの核 | self-host (API fine-tuneでは届かない場合) |
| 最上位品質が最優先(論文執筆・法務分析・複雑コード) | クラウド — Opus 4.7/GPT-5.4がまだ先を行く |
| 日本語・韓国語特化性能が必要 | Qwen 3系列のself-host または Claude/GPT API |
個人的な観察として、日本のスタートアップが実際にself-hostへ移行する時点は、だいたいシリーズB以降です。それ以前はエンジニアリングリソースがあまりにも貴重なので、数十万円を節約しようとして数百万円分の時間を失ってしまう。月2億トークンという境界線は「越えられるか」ではなく「越えた瞬間にself-hostエンジニアを雇えるか」が本当の問題です。
9. FAQ
Q1. Llama 4 Community Licenseの「MAU 7億人」条件は中小企業にもかかりますか?
かかりません。この条項はApple・Google・Amazon・Metaのような巨大プラットフォームをターゲットにしたもので、月間アクティブユーザー7億人というのは世界でも一握りの規模。一般企業・スタートアップは商用利用に何の制約もなくLlama 4を使えます。ただし 「OSI定義のオープンソースではない」 という点は覚えておいてください。
Q2. RTX 4090 1枚で実務に耐えるモデルを回せますか?
個人プロトタイプのレベルまでは十分です。Qwen 3 8B, Gemma 4 9Bといった7~13Bモデルが24GB VRAMにきれいに収まります。ただし同時リクエスト処理量は低い — 1〜2名ぶん。社内ツールなら使えますが、顧客向けの本番運用にはバッチ最適化かマルチGPU構成が要ります。
Q3. DeepSeek V3がMITライセンスと聞きましたが、企業が自社プロダクトにそのまま組み込んで大丈夫ですか?
法的には可能です。MITは改変・再配布・商用利用すべてを許可しています。ただし 再現可能性の問題 が残る — 訓練データの構成が完全公開されていないので、ライセンス紛争の火種が混ざっていないか検証できません。法務が厳しいエンタープライズはこの点で止まることがあります。
Q4. open-weightモデルの性能がすでにClaudeやGPTに追いついた、という話がありますが事実ですか?
ベンチマーク(MMLU, HumanEvalのような標準テスト)では上位open-weightモデルがクラウドフロンティアと拮抗するスコアを出しています。ただし 実務品質 で体感される差はまだあります — 長コンテキストの精度、ツール呼び出しの安定性、指示に忠実に従う能力、adaptive thinkingのような領域ではクラウドフロンティアが先を行っている。ベンチ点数と実務体感は同じではない、というのは念頭に置いてください。
Q5. vLLM・TensorRT-LLM・SGLangのうち最初に触るなら何がいいですか?
vLLMが正解。インストールが一番簡単、対応モデルが一番広く、ドキュメントが一番整っている。ここで基準点を作ってから、スループットが足りなければTensorRT-LLM、共有プロンプトのパターンが多ければSGLangに移るのが定石です。
10. 次回予告 — P4 クローズド4社
今回はopen-weightとクラウドを数学で比較しました。P4では クローズド側だけに絞って4社(OpenAI・Anthropic・Google・xAI)を比較 します。
- GPT-5.4 / Opus 4.7 / Gemini 3.1 Pro / Grok それぞれの技術ポジショニング
- 価格構造の裏にある事業戦略の差
- adaptive thinking · extended thinking · reasoning modelsの設計哲学の差
- 企業が4社から1つを標準として選ぶときに実際に何を見るべきか
Pシリーズがだんだん実務の意思決定に寄ってきているのがわかると思います。「技術を学ぶ」と「技術を選ぶ」は別の能力で、Pシリーズは後者を鍛えるのが目的です。
11. ソース
- Llama 4: Multimodal intelligence (Meta) — Llama 4公式発表・Community License
- Qwen 3 (QwenLM) — Qwen 3公式発表・Apache 2.0
- DeepSeek V3 (GitHub) — DeepSeek V3リポジトリ・MITライセンス
- Claude API pricing (Anthropic) — Opus 4.7・Sonnet 4.6価格
- OpenAI API pricing — GPT-5.4価格
- vLLM vs TensorRT-LLM vs SGLang benchmarks (Spheron) — 推論エンジンベンチマーク
- H100 rental prices cloud comparison (Intuition Labs) — H100時間単価の市場価格
- Qwen 3 local hardware guide 2026 (Compute Market) — VRAM要件ガイド
- Open Source AI Definition v1.0 (OSI) — OSIオープンソースAI定義
📬 毎週月曜日、AIのしくみ地図の新編と今週のAIニュースをニュースレターでお届けしています。購読はshuntailor.net右下から。
著者: VibeCoding Tailor (バイブコーディング・テイラー)
サイト: shuntailor.net
