「費用は要件によります」——この一文で終わる説明では、見積もりは作れない。 何がどう効いて費用が変わるのかがわからなければ、自社の場合がいくらの話になるのかは永遠に見当がつかないままだ。
「ローカルLLM 構築 費用」「オンプレミス 生成AI 導入 コスト」で検索してこのページに来た人が知りたいのは、そういう一般論ではなく、何を選ぶと費用がどちらに動くのかという具体的な変数のはずだ。この記事では、その変数を一つずつ分解する。
費用の土台：提供形態で「初期費用 対 月額」の比率がまるごと変わる
ローカルLLM（私有LLM）の費用を語るとき、最初に効くのは機材のスペックではなく、どういう形で動かすかという提供形態の選択だ。これによって、初期費用と月額費用の比率がまったく別物になる。
- セルフホスト（自社設置）——GPUハードウェアを自社の建物に設置する。機材は初日から自社の資本資産（capex）になり、月々の追加費用は運用・保守が中心になる。継続的・高負荷・予測可能な利用では最も安くなりやすいが、前提として建物側が電源・冷却負荷に対応できる必要がある。
- マネージドホスティング——ベンダーがハードウェアを預かって運用する。電源・冷却・UPS・接続・監視を月額費用（opex）にまとめ、初期費用の重さを避けられる。ハードウェアの所有権は自社に残る。
- 共有インフラ——ハードウェア購入が一切ない。GPU/VRAM容量を単位課金でレンタルする、完全なopexモデル。利用が軽い、あるいはまだ様子見の段階に向く。
どれか一つが常にお得ということはなく、利用規模によって最適な形態が入れ替わる。継続的で高負荷な利用ならセルフホストの初期投資が月々の単価を下げていくし、利用がまだ読めない段階なら共有インフラで単価課金のまま様子を見る方が合理的になる。3形態の詳しい比較と、それぞれの月額目安はプライベートLLM基盤にまとめている。
この選択が「まるごと」費用構造を変える理由は単純で、同じモデル・同じ用途でも、提供形態が変われば費用が発生するタイミングと項目そのものが変わるからだ。だからこそ、モデルサイズを検討する前に、まずここを決めておく必要がある。
モデルサイズが費用を動かす、二つの別々の理由
提供形態の次に効くのがモデルサイズだが、ここでよくある誤解は「大きいモデルほど良い」という一本のはしごとして考えてしまうことだ。実際には、モデルサイズを押し上げる理由は2つあり、それぞれ別の軸にある。この2つを混同すると、必要ない費用を積んでしまう。
軸1：精度の下限。 業務で使い物になる回答品質を確保するための最小サイズという軸。
- **32Bクラス（Dense、FP8で約32GB）**が、業務利用として実用に耐える下限に位置する。
- **70Bクラス（Dense、FP8で約70GB）**が既定・推奨の位置づけになる。理由は「余裕を見て大きめ」という感覚ではなく、1台のマシンで、全社共通で使うChatGPT相当のアシスタントを近似できるサイズという、具体的な基準に基づく。多くの企業にとって、この規模が「まず立てる1台」の答えになる。
軸2：同時利用の上限。 これは回答の精度ではなく、同時に何人・何リクエストをさばけるかというスループットの軸。
- **122B-A10B（MoE、アクティブ10B、FP8で約125GB）や400Bクラス（MoE、アクティブ17B、FP8で約400GB）**は、精度を追加で底上げするためというより、より高い同時利用に対応するための選択肢として位置づく。
なぜ「精度は足りているのに」同時利用が増えるとモデルが大きくなるのか
一つのマシンに搭載できるGPUメモリと演算能力には上限がある。複数人が同時に問い合わせると、サーバーは会話ごとの文脈（KVキャッシュ）を同時に何本も保持しながら、リクエストをまとめて処理する必要がある。同時セッションが増えるほど、同じ演算資源を奪い合うことになり、一つひとつの回答の精度は変わらないまま、応答が遅くなる、あるいは処理しきれるセッション数に天井が来る、という形で頭打ちになる。
122B-A10BやFP8で約400GBの400Bクラスといった大型のMoE構成は、この天井を押し上げるための選択だ。MoE（Mixture of Experts）は総パラメータ数が大きい一方で、1トークンの生成に実際に使う「アクティブパラメータ」は10B・17Bと控えめに保たれている。総容量が大きい分、同時に飛んでくる多様なリクエストをさばくためのメモリ・処理の余地が広がる一方、1件あたりの生成コストは70Bクラスの基準からそこまで離れない。つまりここで積んでいるのは「一つの答えをより賢くする」費用ではなく、「同時に、より多くのリクエストをさばく」ための余地の費用だ。困っているのが回答の質なのか、さばける量なのかを先に切り分けておかないと、不要な方の軸で費用を積んでしまう。
なお**35B-A3B（MoE、アクティブ3B）**は、このはしごの外にある。トリアージやガードレールといった軽い判定専用の役割で、業務の主要な回答をこのモデル単体に任せる設計にはしない。
量子化を下げれば機材は安くなる。それでもFP8より下げない理由
モデルサイズが決まったら、次に効くのが量子化だ。量子化を下げるほど、同じモデルを動かすのに必要なGPUメモリは小さくなり、機材費用は下がる。技術的には4bit/INT4まで下げることもできる。
当社の標準構成では、FP8を量子化の下限にしており、既定ではそれより下へは踏み込まない。理由は理論上の慎重さではなく実測にある。当社のテストでは、FP8を下回る量子化で、日本語のビジネスタスクにおける精度低下が測定可能な形で確認されている。ハードウェア費用を抑えられる可能性がある一方で、それを既定の推奨として提供することはしていない。
この判断は「安全側に倒した保守的な方針」というより、測定結果と、その測定結果が示す精度低下を天秤にかけた上での線引きだ。量子化を下げる選択肢自体は残っているので、精度要件が緩い用途では検討の余地がある——ただし、それは実測の上で判断すべきことで、コスト削減のためにまず疑うべき最初の変数ではない。
小さく始めて、後から伸ばす——やり直しになる部分、引き継げる部分
最初から70Bクラスのフルビルドにコミットせず、小さく始めて必要に応じて伸ばすという進め方も選択肢に入る。ここで整理しておく価値があるのは、規模を上げるときに何がやり直しになり、何が引き継げるかだ。
引き継げるもの——RAGの設定・検索インデックス、評価データセット、そして統合レイヤー。当社のビルドは標準的なOpenAI互換の推論インターフェースを軸に設計しており、モデルのサイズやホスティング形態を変えても、アプリケーション側の統合部分を書き換える必要はない。評価に使ったドキュメント・質問セットも、モデルのサイズに依存しないため、そのまま次のティアの検証に使い回せる。
やり直しになるもの——ファインチューニング済みのウェイトそのものと、ハードウェア・ホスティングの手配。ファインチューニングは特定のベースモデルの重みに紐づくため、32Bで調整した結果を70Bにそのまま移植することはできず、新しいベースモデルに対してチューニングをやり直すことになる。同様に、共有インフラで小さく検証してからセルフホストの機材を組む、という規模の切り替えでは、ホスティングの契約・調達もそのつど組み直しになる。
この「引き継げる／やり直しになる」の境界線をあらかじめ知っておくと、最初の一歩をどこまで小さくしていいかの判断がしやすくなる。実際にどこまで小さく始められるかは、30日間の私有LLM PoCのように、ハードウェアを購入する前に自社のドキュメント・ワークロードに対して検証する形が使える。PoCは既定では70Bクラスを起点に検証するが、必要であれば32Bクラスまで下げる判断も、実測の精度・レイテンシに基づいて行う。
なお、ここまでの費用はモデルを動かす基盤の話であり、モデルの上に載せるアプリケーション——業務システムへの組み込みや、RAG以外のワークフロー構築——にまで踏み込む場合は、AI駆動型開発サービス側の費用も別途乗ってくる。基盤とアプリケーションは別の見積もり項目だ。
LLLの価格（参考値）
ここまでの変数を踏まえた上で、当社が実際に提示している価格を挙げておく。以下はUSD建てで、お客様への提示価格そのものであり、社内原価ではない。
| 契約形態 | 価格 | 備考 |
|---|---|---|
| 30日間PoC | $6,000（50名以下のチームは$3,000） | 継続する場合はフルビルドに全額充当 |
| フルビルド（単一ユースケース） | $8,000〜$22,000、規模により変動 | 環境構築・RAG・既存システム統合・トレーニングを含む |
| 継続的な保守・運用 | 月$300〜$1,300 | GPU台数による段階制 |
| マネージドホスティング | 月$300〜$1,600 | 消費電力による段階制。電源・冷却・UPS・接続・監視を含む |
| 共有インフラ | 24GB VRAMユニットあたり月$300から | ハードウェア購入なし |
機材そのもの（GPUサーバー本体）の価格はここに含まれていない。GPU・サーバーメモリの市場価格は急激に変動しているため、当社は固定の機材価格をページに掲載していない。目安として、70Bクラスの既定モデルに見合う8GPUのフルビルドは、完成品として米ドル建てで下6桁台前半の規模になる——これは規模感の参考値であり、正確な見積もりではない。また電源・冷却・UPSなどの設備費用は建物ごとに変動が大きいため、現地調査の上で個別に価格設定される。
まとめ：自社の数字を組み立てる順番
「費用は要件によります」を具体的な順番に分解すると、次のようになる。
- 提供形態を選ぶ——セルフホスト・マネージド・共有のどれかで、初期費用と月額費用の比率がまるごと変わる。詳しくはプライベートLLM基盤。
- 精度の下限と同時利用の上限を、別の軸として見積もる——32B・70B・122B-A10B・400Bのどこに乗るかは、「回答の質」の問題か「さばく量」の問題かで決まる。
- 量子化はFP8を下限に置く——それより下げれば機材は安くなるが、当社の実測では日本語ビジネスタスクの精度低下が確認されている。
- 小さく始める場合は、引き継げるものとやり直しになるものを分けて考える——RAG・評価データセット・統合レイヤーは引き継げるが、ファインチューニングとハードウェア手配はティアが変わるたびにやり直しになる。
この4つを自社のワークロードに当てはめれば、「いくらの話になるか」の見当が付けられるはずだ。それでも机上の見積もりには限界があるので、実際の数字が必要な場合は、ハードウェアを購入する前に自社のドキュメントで検証する30日間の私有LLM PoCを使う手もある。