ローカル LLM / SLM 導入比較 — クラウド API に依存しない AI 活用

OpenAI が Apache 2.0 で公開した GPT OSS を筆頭に、オープンウェイトの言語モデルは特定の業務タスクにおいてクラウド API に匹敵するベンチマークスコアを記録し始めている。とりわけ SLM（Small Language Model）は、分類・要約・構造化データ抽出といった定型的なタスクでクラウド API との精度差が縮まりつつあり、データ主権とコスト最適化を両立する選択肢として注目されている。本記事では、データのクラウド送信に制約がある金融・医療・製造業の情シス・セキュリティ担当者に向けて、GPT OSS を含むローカル LLM / SLM とクラウド API のトレードオフを GPU 要件・タスク別精度・TCO の 3 軸で比較する。読み終える頃には、自社に最適なアーキテクチャとモデルの組み合わせを判断するための材料が揃うはずだ。

AI の言語モデルを業務に組み込む方法は大きく 3 つに分かれる。クラウド API・ローカル LLM・SLM だ。この 3 つは「モデルの実行場所」と「モデルの規模」という 2 つの軸で整理できる。

クラウド API は、OpenAI や Anthropic、Google が提供するホスティング済みモデルに HTTP リクエストを送る方式だ。インフラ管理が不要な反面、入力データがプロバイダのサーバーを経由する。

ローカル LLM は、大規模な言語モデルを自社のサーバーやワークステーション上で動かすアプローチを指す。Llama 4 Maverick（400B 総パラメータ、17B アクティブ）や GPT OSS 120B（117B 総パラメータ、5.1B アクティブ）のような大型モデルが該当する。最近の大型モデルは MoE（Mixture of Experts）アーキテクチャを採用し、総パラメータ数に対してアクティブパラメータを大幅に抑えることで、従来より少ない GPU で動作可能になっている。

SLM（Small Language Model）は、パラメータ数を数十億以下に抑えた軽量モデルだ。GPT OSS 20B（21B 総パラメータ、3.6B アクティブ）、Phi-4（14B）、Gemma 3（4B / 12B / 27B）、Qwen 3（7B）、Llama 4 Scout（109B 総パラメータ、17B アクティブ）などが代表例になる。「小さい＝低性能」ではなく、MoE や高品質データによる訓練で特定タスクの精度を大型モデルに近づけている点が特徴だ。

特に GPT OSS は OpenAI が Apache 2.0 ライセンスで公開した初のオープンウェイトモデルファミリーで、公開から数週間で HuggingFace 上のダウンロード数が 900 万を超えた。クラウド API の GPT シリーズと同じトークナイザを使い、ツール呼び出しや Chain-of-Thought 推論にも対応しているため、既存の GPT ベースのワークフローからの移行障壁が低い。

金融や医療の現場でクラウド API の採用が見送られる最大の理由は、データ主権（Data Sovereignty）の問題だ。患者の診療記録や顧客の取引データをクラウドに送信すること自体が、社内規定や業界ガイドラインで禁止されているケースは珍しくない。

ローカル LLM と SLM はどちらもデータが自社環境から出ない。違いはモデル規模と必要リソースにある。次のセクションで、どちらを選ぶべきかの判断基準を整理する。

ローカル実行が万能というわけではない。投資対効果を冷静に見極めるため、導入が強く推奨されるケースとクラウドで十分なケースを分けて考える。

ローカル LLM / SLM の導入効果が見えやすいのは、以下の 3 つのパターンだ。具体的な数値は組織やタスクによって大きく異なるため、ここではパターンの構造を示す。

パターン 1: 機密データの分類・要約（金融）。融資審査の書類を AI で要約したいが、顧客の財務情報をクラウドに送れない。SLM を社内サーバーに配置すれば、データが外部に出ない形で審査書類の要約を自動化できる。手作業と比べてどの程度の時間短縮になるかは、書類の複雑さやモデルの精度調整に依存する。

パターン 2: 製造ラインのログ解析（製造）。工場のエッジサーバーで設備ログを SLM に解析させ、異常パターンを検出する。クラウド API 経由ではネットワーク往復の遅延が加わるが、ローカル実行ではその分を短縮できる。ただし SLM の推論自体にも数十〜数百ミリ秒はかかるため、「リアルタイム」の定義は業務要件に合わせて検証が必要だ。

パターン 3: 電子カルテの構造化（医療）。自由記述の診療メモから SOAP 形式への変換を SLM で行うアプローチが考えられる。患者データが院内ネットワークから出ないため、個人情報保護法や医療情報ガイドラインとの整合性を保ちやすい。ただし医療領域は YMYL（Your Money or Your Life）に該当するため、出力の人間によるレビュー体制が不可欠だ。

一方で、以下に該当するならクラウド API の方が合理的だ。

• 処理するデータに機密情報が含まれない（公開情報の要約、社内 FAQ の生成など）
• 月間トークン量が少ない（後述の損益分岐点を参照）
• 最新モデルの性能が常に必要（クラウド API は自動的にモデルが更新される）
• GPU インフラの運用体制を持てない（専任の ML エンジニアがいない）

「クラウドに送れないデータがある」かつ「月間トークン量がある程度ある」場合に、ローカル実行の投資対効果が見合ってくる。

ローカル実行で最初につまずくのが「どのモデルを、どのハードウェアで動かせるか」だ。MoE アーキテクチャの普及により、総パラメータ数だけでは必要メモリを判断できなくなっている。アクティブパラメータ数と量子化レベルから逆算し、予算に応じた選定ができるようにする。

以下の表は、主要なオープンウェイトモデルを GPU メモリ要件別に整理したものだ。MoE モデルは総パラメータ数が大きくても、アクティブパラメータが少ないため必要メモリが抑えられる点に注目してほしい。

GPU スペック比較（NVIDIA 公式）: RTX 5090 は 32GB GDDR7・帯域 1,792 GB/s（Blackwell アーキテクチャ）。H200 は 141GB HBM3e・帯域 4.8 TB/s。B200 は 192GB HBM3e・帯域 8 TB/s。帯域幅はメモリバウンドな LLM 推論で特に重要な指標だ。

読み方: MoE モデルの「Q4 VRAM 目安」は全エキスパートの重みを含む。アクティブパラメータが少なくても、全エキスパートをメモリに載せる必要がある。

注目すべきは GPT OSS 20B の効率性だ。 総パラメータ 21B に対してアクティブはわずか 3.6B。MXFP4 量子化で約 13GB に収まるため、RTX 5090 の 32GB で余裕をもって動作する（RTX 4090 の 24GB でも動作可能）。にもかかわらず、公式ベンチマーク上は OpenAI o3-mini に匹敵するスコアを記録している。

RTX 5090 1 枚で最大限の精度を狙うなら GPT OSS 20B（MXFP4）が第一候補。RTX 4090 比で帯域幅が 78% 向上しているため、推論スループットの改善も期待できる。32GB の VRAM に余裕があるため、Gemma 3 27B（Q4, 16GB）も快適に動作する。

H200 1 枚なら GPT OSS 120B と Llama 4 Scout の両方が選択肢に入る。GPT OSS 120B は MXFP4 で約 61GB、Llama 4 Scout は int4 で約 55GB + KV キャッシュ。141GB の VRAM があるため、長いコンテキスト（128K トークン）でも KV キャッシュの余裕がある。テキスト推論重視なら GPT OSS 120B、マルチモーダル（画像理解）が必要なら Llama 4 Scout を選ぶ。

B200 なら Llama 4 Maverick（400B 総パラメータ）まで視野に入る。192GB の HBM3e と 8 TB/s の帯域幅により、Q4 量子化で単一 GPU での推論が可能だ。H100 比で推論性能が最大 15 倍とされている（NVIDIA 公式）。

量子化はモデルの重みを低ビット（4bit / 8bit）に圧縮する技術で、必要 VRAM を半分以下に削減できる。GPT OSS の登場で、従来の量子化形式に加えて MXFP4 が新たな選択肢として加わった。

量子化レベルと精度の関係については、コミュニティの検証報告が蓄積されている。一般的な傾向として、Q8（8bit）では FP16 比で精度低下がほとんど検出されず、Q4（4bit）ではタスクによって軽微な劣化が見られ、Q2（2bit）では明確な品質低下が報告されている。ただし、劣化の程度はモデル・タスク・言語によって異なるため、自社のユースケースでの検証が不可欠だ。

実務的な推奨は Q4 以上。Q4 でメモリに収まるなら Q4 で運用し、品質に問題が出た場合のみ Q8 に上げるアプローチが効率的だ。

MXFP4 は OpenAI が GPT OSS で採用した量子化形式で、MoE のエキスパート重みに選択的に適用される。Blackwell アーキテクチャ（B200 / RTX 5090）および Hopper アーキテクチャ（H100 / H200）で最適なスループットが出る。

量子化のメリットは VRAM 削減だけではない。RTX 5090 の 1,792 GB/s、H200 の 4.8 TB/s、B200 の 8 TB/s というメモリ帯域幅は、量子化による重みサイズの縮小と相乗効果を発揮する。同じモデルでも Q4 にすれば重みの転送量が半減し、帯域幅のボトルネックが緩和されてトークン生成速度が向上する。

モデルの重みファイルをダウンロードしただけでは、推論（テキスト生成）は実行できない。GPU へのモデルロード、トークナイザの適用、KV キャッシュの管理、出力トークンのサンプリングといった一連の処理を担うのが推論フレームワークだ。フレームワークの選択はモデルの精度には影響しないが、推論速度・同時処理数・運用の手軽さに直結する。

llama.cpp は C/C++ 実装の推論エンジンで、CPU only から GPU まで幅広く対応する。GGUF 形式のモデルを直接読み込め、Python 環境やCUDA ドライバ以外の依存が少ないのが強み。GPT OSS も GGUF 変換版が公開されており、llama-server -hf ggml-org/gpt-oss-120b-GGUF で起動できる。Windows PC やエッジデバイスなど、Python 環境の構築が難しい環境での導入に向いている。

vLLM は PagedAttention による高効率なメモリ管理が特徴だ。通常の推論では KV キャッシュがリクエストごとに連続メモリを確保するため、同時リクエスト数が増えると VRAM が逼迫する。vLLM はこれをページ単位で管理し、メモリの断片化を防ぐことで同じ VRAM でより多くのリクエストを並列処理できる。GPT OSS は公式に vLLM をサポートしており、vllm serve openai/gpt-oss-120b --tensor-parallel-size 2 でサービス化できる。社内 API サーバーとして複数部署に提供する場合の第一候補だ。

Ollama は llama.cpp をラップした CLI ツールで、ollama run phi4 の一行でモデルのダウンロードから起動まで完了する。モデル管理（バージョン切替、削除）も CLI で完結するため、PoC やプロトタイピングで「まず動かしてみる」段階に最適だ。ただし、リクエストキューイングやモニタリングの仕組みは内蔵していないため、本番環境では vLLM 等への移行が必要になる。

「ローカルで動くのはわかったが、精度は大丈夫なのか？」— 導入検討で最も多い質問だ。GPT OSS の公開によって、この問いへの回答は大きく変わった。

以下は、主要なベンチマークにおけるローカルモデルとクラウド API の公開スコア比較だ。MMLU・HumanEval・MATH は各モデルの公式発表値またはサードパーティの再現検証に基づく。

注: GPT OSS 20B の個別ベンチマークスコアは公式モデルカードで「o3-mini に匹敵する」と総括されているが、タスク別の詳細スコアは一部未公開。上記の「o3-mini 相当」は OpenAI の公式比較に基づく。

テキスト分類・短文要約・構造化データ抽出・多言語翻訳については、標準的な公開ベンチマークが確立されておらず、モデル間の精度比較は自社データでの検証が不可欠だ。一般的な傾向として、入出力が短く定型的なタスク（分類・抽出）ほど SLM とクラウド API の差が小さく、長いコンテキストや複雑な推論が必要なタスクほどクラウド API が優位になる。

GPT OSS の登場で、公開ベンチマーク上でローカルモデルがクラウド API に迫る領域は広がった。

ローカルモデルが強いベンチマーク領域として、コード生成（HumanEval）とツール呼び出し（TauBench）が加わった。GPT OSS 120B は TauBench で o3-mini を上回り、o4-mini に匹敵するスコアを記録している（OpenAI 公式ブログ）。GPT OSS 20B も o3-mini と同等水準とされる。

クラウド API が依然として優位な領域は、複雑な推論・数学（MATH ベンチマーク）と多言語タスクだ。GPT OSS 120B の「deep mode」（推論に時間をかけるモード）でもクラウド大型モデルとの差は残る。

ただし、ベンチマークスコアと実業務での精度は必ずしも一致しない。ベンチマークは標準化されたプロンプトと評価基準で測定されるが、実業務では入力データの質・ドメイン固有の語彙・出力形式の要件が異なる。導入判断にはベンチマークを参考にしつつ、自社データでの PoC 検証が不可欠だ。

汎用精度で不足がある場合、PEFT（パラメータ効率型ファインチューニング）で自社データに特化させることで精度を引き上げられる。

ライセンスの観点では、GPT OSS は Apache 2.0 のためファインチューニングや商用利用に制約がない。一方、Llama 4 Scout は Llama 4 Community License であり、月間アクティブユーザー 7 億人を超える企業には別途ライセンスが必要になる。多くの企業にとっては実質的に制約にならないが、Apache 2.0 とは条件が異なる点は認識しておくべきだ。

PEFT の中でも実務で最も使われているのが LoRA と QLoRA だ。

LoRA はモデルの重み行列に低ランクの更新行列を追加する手法で、全パラメータの 0.1〜1% 程度の追加パラメータだけを学習する。RTX 4090 1 枚で Phi-4 14B の LoRA ファインチューニングが可能だ。

QLoRA は LoRA に量子化を組み合わせた手法で、必要 VRAM をさらに半減させる。16GB クラスの GPU でも 14B モデルのファインチューニングができるため、初期投資を抑えたい場合に有力な選択肢になる。

カスタマイズの典型的なフローは以下の通りだ。

1. ベースモデル選定: 上記の選定表からハードウェアに合うモデルを選ぶ
2. データ準備: 業務データから 500〜5,000 件の学習データを作成（入力・出力のペア）
3. QLoRA でファインチューニング: 学習時間はデータ量・LoRA rank・エポック数に依存する。目安として、1,000 件・rank 16・3 エポックの条件で RTX 4090 上では数時間程度
4. 評価: 社内テストセットで精度を検証し、ベースモデルとの差分を確認
5. デプロイ: llama.cpp / vLLM にマージ済みモデルを配置

ドメイン特化のファインチューニングによる精度向上の幅は、ベースモデルの汎用性能・学習データの質と量・タスクの性質に大きく依存する。事前に小規模な検証（100〜200 件）で効果を確認してから本格的なデータ整備に進むことを推奨する。

精度面でローカル実行が使えるとわかっても、コストが合わなければ導入の意思決定は通らない。ここでは初期投資と月間運用コストの両面から損益分岐点を試算する。

注: ハードウェア価格は市場状況により大きく変動する。RTX 5090 は DRAM 不足の影響で MSRP（$1,999）を大幅に上回る価格で取引されているケースが報告されている。導入検討時には最新の市場価格を確認すること。

RTX 5090 の費用対効果が注目される。GPT OSS 20B（公式ベンチマーク上 o3-mini 相当）が 32GB の消費者向け GPU で動くことは、ローカル AI の損益分岐点を引き下げる要因になっている。

クラウド API の価格はプロバイダ・モデル・契約形態によって大きく異なり、頻繁に改定される。導入検討時には各プロバイダの最新の料金ページを確認すること。一般的な傾向として、月間トークン量が増えるほどローカル実行の固定費モデルが有利になる。

RTX 5090 サーバー（初期投資 80〜100 万円、月間運用 3〜5 万円と仮定、価格は参考値）の場合、クラウド API との損益分岐点は月間トークン量に依存する。RTX 5090 は RTX 4090 比で VRAM が 24GB → 32GB に増え、メモリ帯域幅も 78% 向上しているため、GPT OSS 20B のような MoE モデルをより快適に動かせる。

この試算の前提として知っておくべきは、ローカル SLM の月間運用コストは処理量にほとんど比例しないという点だ。GPU サーバーは固定費モデルなので、処理量が増えるほどトークン単価が下がる。逆に、月間トークン量が少ないライトな使い方では、クラウド API の従量課金の方が安くなる。

RTX 5090 は RTX 4090 より初期投資が高い一方、32GB の VRAM で Gemma 3 27B（Q4, 16GB）も余裕をもって動作し、モデル選択肢が広がる。投資額の増分に見合うかは、必要なモデルサイズと処理量で判断する。

具体的な損益分岐点は、使用するクラウド API のモデル・料金体系・契約条件によって大きく変わる。導入検討時には、自社の月間トークン量を 1〜2 週間計測した上で、クラウド API の見積もりとローカル実行の固定費を比較することを推奨する。

ローカル LLM / SLM の導入で繰り返し見てきた失敗パターンを 3 つ紹介する。どれも技術的には対処可能だが、事前に知っておくと無駄な回り道を避けられる。

70B モデルを無理に動かそうとして、過度な量子化（Q2）で品質を落とすケースがある。14B モデルを Q4 で動かした方が、70B を Q2 で動かすより精度が高い場合は多い。ハードウェアに合うサイズのモデルを Q4 以上で使う方が、結果的に精度もコストも最適化される。

先述の GPU 要件別モデル選定表に立ち返り、自社の GPU メモリで「Q4 以上で動かせる最大のモデル」を選ぶのが実務的な正解だ。

もう一つ見落とされがちなのが、推論時の KV キャッシュによるメモリ消費だ。モデル本体が 8GB でも、長いプロンプト（4,000 トークン超）を処理すると KV キャッシュで追加 2〜4GB を消費する。24GB の RTX 4090 でも、14B モデル（Q4, 8GB）+ KV キャッシュ + OS で実質 18〜20GB を使い切ることがある。

回避策は 2 つ。コンテキスト長を業務で必要な最小限に制限すること（4,096 で足りるなら 8,192 にしない）。もう 1 つは vLLM の PagedAttention を使い、KV キャッシュを効率的に管理することだ。

導入時の PoC は成功しても、運用フェーズで放置されるケースがある。オープンウェイトモデルは数ヶ月おきに新バージョンが公開される。Phi-3 → Phi-4、Gemma 2 → Gemma 3 のように、世代が変わると同じパラメータ数でも精度が大幅に向上する。

最低限の運用体制として、四半期に 1 回のモデル更新評価と、推論速度・エラー率の定期モニタリングを組み込むことを推奨する。専任の ML エンジニアがいなくても、情シス担当者がスクリプトで自動化できるレベルの作業だ。

データを外部に出せるならクラウド API の方が手軽だ。GPT OSS を選ぶべきなのは、データ主権の制約がある場合、API コストを固定費化したい場合、またはオフライン環境で動かしたい場合。OpenAI の公式ベンチマークでは、GPT OSS 20B は MMLU・HumanEval・TauBench 等で o3-mini に匹敵し、120B は o4-mini に匹敵するスコアを記録している。ただし、ベンチマークスコアが実業務の精度を保証するわけではないため、自社タスクでの PoC 検証は必須だ。

使える。RAG（Retrieval-Augmented Generation）は検索で取得した文書をプロンプトに埋め込む手法なので、モデルのサイズに依存しない。GPT OSS 20B や Phi-4 + ベクトル DB（Qdrant, pgvector 等）の組み合わせで、社内文書検索 + 回答生成のパイプラインを構築できる。GPT OSS は 128K、Llama 4 Scout は最大 10M トークンのコンテキスト長を持つため、RAG のチャンクサイズ設計にも余裕がある。

ハードウェア次第だが、単一リクエストのレイテンシではローカルの方が速いケースがある。クラウド API にはネットワーク往復とキュー待機のオーバーヘッドが加わるためだ。RTX 4090 上の GPT OSS 20B であれば、MoE のアクティブパラメータが 3.6B と少ないため、Dense 14B モデルよりも高速にトークン生成を開始できる可能性がある。ただし、同時リクエスト数が増えると GPU がボトルネックになるため、vLLM 等のバッチ推論フレームワークでスループットを確保する設計が必要だ。実際のレイテンシはモデル・量子化・プロンプト長・バッチサイズで大きく変わるため、ベンチマーク値ではなく自社環境での計測を推奨する。

本番運用の実績は、オープンソースコミュニティやクラウドプロバイダの事例報告で増えつつある。QLoRA でファインチューニングした SLM を本番投入する際の注意点は主に 2 つだ。1 つは学習データの品質管理で、ノイズの多いデータで学習すると汎用性能が劣化する「壊滅的忘却」が起きうる。もう 1 つは LoRA アダプタのバージョン管理で、ベースモデルの更新時にアダプタの再学習が必要になる。ファインチューニングの技術的な詳細は PEFT の入門記事で解説している。

ローカル LLM / SLM の導入判断は、「データ主権の要件」「月間トークン量」「タスクの複雑さ」の 3 つで決まる。GPT OSS の登場でこの判断は一段とシンプルになった。データをクラウドに送れない制約があり、月間 500 万トークン以上を処理するなら、GPT OSS 20B（RTX 4090）または GPT OSS 120B（H100）で、クラウド API の o3-mini / o4-mini 相当の精度をローカルで実現できる。

まずは Ollama + GPT OSS 20B で小さく検証し、精度に満足できたら QLoRA で自社データに特化させ、vLLM でサービス化する。このステップで進めれば、初期投資を最小限に抑えながらデータ主権とコスト最適化を両立できる。