ローカルLLMの導入は
モデルより入口の設計です

「ローカルLLMを入れたい」と言われて、GPUとモデルの見積もりから始めている方へ

社内のデータを外に出せない部署から「ローカルLLMを使いたい」と言われ、どのGPUを何枚買い、どのモデルを載せるかの見積もりから手を付けている情シスやDX推進の方に向けて書いています。

先に決めるのはモデルではなく、入口です。ドコモビジネスの部署が社内向けに作った基盤の記事を読むと、GPUとモデルは後から入れ替わっていて、変わらなかったのは認証と流量制限と利用記録と切り替えを1か所で行う入口の設計でした。

何が公開されたのか

NTTドコモビジネスのエンジニアブログが2026年9月14日、社内向けに構築したローカルLLM基盤「Local LLM MaaS」の構成と、運用に乗せて分かったことを公開しました。部署で1つの基盤を運用し、そのエンドポイントを社内へ提供する形で、名前のMaaSはModel as a Serviceの略です。

LLMゲートウェイとは、利用者のツールと複数のモデルの間に立ち、認証、流量制限、利用記録、モデルの切り替えを1か所で行うソフトウェアです。この基盤ではLiteLLM Proxyがその役を担い、利用者は単一のエンドポイントを呼ぶだけで複数のローカルLLMをOpenAI互換のAPIとして使えます。

記事は、この基盤がまだPoCの位置づけだと明記しています。数字も、利用者数やGPUの枚数、費用は出ていません。それでも読む価値があるのは、構成の理由と、動かしてから起きたことが書いてあるからです。

各自で立てると4つの無駄が出ます

記事の出発点は、ローカルLLMを試すだけなら各自が手元のGPUに推論エンジンを立てても成り立つ、という認識です。そのうえで、組織全体で見ると4つの無駄が生じると書いています。

• GPUの利用効率。検証のために1人が1枚を確保すると、本人が触っていない時間ずっと空く。1か所に集約すれば同じGPUを複数の利用者の時間で埋められる
• 環境を維持する手間。推論エンジンもモデルも更新が速く、個別の環境では更新されないまま放置されるものが生まれる。集約すれば保守は運用側の1か所にまとまる
• 構築の知見。どのモデルがどのGPUに載るか、量子化や並列化をどう組むかの試行錯誤を、利用者ごとに繰り返すのは重複した投資
• 統制。誰がどのモデルをどれだけ使っているかを把握するには認証とログの集約が要る。入口を1つにすれば、その1か所に用意するだけで全員に効く

4つのうち3つは費用と手間の話で、最後の1つが統制の話です。統制は後から足せません。入口が分散した後で「誰が何にどれだけ使ったか」を集めようとしても、記録が無いからです。

構成は3つの部品と、記録の経路です

基盤は3つの部品でできています。各行の太字が部品で、右の列が記事に書かれている役割です。

ゲートウェイの選定理由に、既存のツールをそのまま繋げられることが挙がっています。OpenAI互換APIに加えてAnthropic Messages APIも受けるため、コーディングエージェントは接続先のURLを差し替えるだけで、社内のモデルを呼び出せます。入口を1つにしても、利用者側の道具は変えていません。

提供しているモデルは11種類で、20Bから2.8Tまで規模の幅があり、多くは画像も入力できます。最初の6つは既存のKubernetesクラスタ上、後から足したものは別のサーバー上で動いていますが、ゲートウェイの後段として登録しているので、利用者から見れば同じエンドポイントの別のモデル名です。限られたGPUに複数のモデルを載せるために、4ビットまで量子化したモデルを積極的に採用する方針だと書いています。

運用に乗せて分かった3つのこと

記事の後半が、この基盤を動かしてから起きたことです。各行の太字が起きたことで、右の列は同じ構成の提案を受けたときに聞くことです。

1行目は、モデルの選定を事前に絞り込む発想と逆の結果です。記事自身も、何が使われるかを事前に見積もって絞り込むより、複数のモデルを並べて試せる状態を保ち、実際の利用を見ながら入れ替える方が実態に合っている、と結んでいます。この動きを数字で見られたのは、入口と記録が1か所にあったからです。

2行目と3行目は、LLMのAPIが止まったときの動きを要件に書く話と同じ形です。クラウドのAPIが週に数回止まるのと同じように、社内のサーバーも落ちます。退避先と、利用者の出し入れの手順は、モデルの性能とは別に決めておく項目です。

量子化の数字は参考値です

記事が量子化を積極的に使う根拠として引いているのは、vLLMの開発を主導したNeural Magic（現Red Hat）の調査です。Llama 3.1系の8B・70B・405Bを対象に50万件以上を評価し、4ビット量子化でも平均で99%程度の精度を回復したと報告されています。重みの容量はおよそ4分の1になるので、同じGPU枚数で載せられるモデルを増やす方が得だ、という判断です。

記事はこの数字を、提供しているモデルとは対象が異なる参考値だと書いています。長文脈のタスクでは4ビットで大きく精度が落ちる報告もあり、影響の度合いは量子化の方式とモデルとタスクに左右されるので、長い文脈を扱う用途で品質を詰めたい場合は個別に確かめる必要がある、とも書いています。GPUの枚数を減らす根拠の数字は、自社の用途で測り直すものです。

クラウドの置き換えではありません

記事は、ローカルLLMはクラウド型のサービスを置き換えるものではないと明記しています。高性能なモデルをすぐ使える手軽さはクラウドの強みで、自組織で動かすからこそ得られるのは次の3つだ、という整理です。

• 扱うデータの置き場所を自ら定められること
• 誰がどう使っているかを自分たちの手元で把握できること
• 外部の提供方針に左右されず、どのモデルを載せるかを決められること

3つとも、モデルの性能の話ではありません。「社内データを外に出せない」の一言に混ざっている心配を3つの層に分けて確かめる回で書いたとおり、契約と設定で外せる心配を外したうえで、それでも残る範囲がこの3つに当たります。ローカルLLMの仕組みと限界の回で「ハイブリッドという現実解」と書いた形が、部署の規模で運用に乗った事例です。

Open Weightという言葉も記事に出てきます。学習済みの重みが公開されていて自組織で動かせる形態で、学習コードやデータまで公開するOpen Sourceとは別です。この違いは基盤モデルのオープンソースを名乗る条件の回で書きました。

数字の出どころと限界

この記事の内容は、NTTドコモビジネスのエンジニアブログが2026年9月14日に公開したLocal LLM MaaSの記事を、2026年9月18日に確認したものに基づきます。4つの無駄、vLLM・LiteLLM Proxy・OpenWebUIの構成と選定理由、OpenTelemetry CollectorからAmazon CloudWatch LogsとLangfuseへの振り分け、利用者ごとの仮想APIキー、OIDC連携が有償版の機能であること、サーバー停止とフォールバックの設定、11のモデル、新しいモデル追加時の利用の集中（当日の9割超、20倍超）、PoCの位置づけ、今後の予定は、いずれも同記事の記載です。4ビット量子化で平均99%程度の精度という数字は、同記事がNeural Magic（現Red Hat）のLlama 3.1系の調査として引いているもので、この基盤のモデルで測った値ではありません。

利用者数、GPUの枚数と種類、費用、応答速度、クラウド型との比較は公開されていません。9割超と20倍超は、モデルを追加した当日のリクエストの比率と倍率で、恒常的な利用の分布ではありません。「モデルより入口」という整理と、表の右の列の確認項目は、記事の記述から本記事が引いた発注側の論点で、ドコモビジネスが示した手順ではありません。

AIエージェントを隔離して動かす実行環境と自社に置いたGPUの話は3000体の裏にある基盤の回に、基幹システムのデータをAIに見せる接続の話は価格が出ている自動化と出ていない自動化の回に書いています。社内AI基盤の入口と運用の設計のご相談は、お問い合わせからお送りください。