オンプレミスでLLMを動かす｜GPU5枚で運用した実測と、棄却した選択肢

動画で見る（5分14秒）

章から見る

1. 0:00 オープニング
2. 0:36 編集部の環境
3. 0:54 足したら、悪くなった4つ
4. 1:53 19回、別のモデルを測っていた
5. 3:04 効いたのは、選び方
6. 3:45 最初から、GPUを買わない
7. 4:42 まとめ

動画の台詞を読む

部長：顧客の資料は、外に出せないから、社内にGPUを買って、AIを動かすわ。速くする設定も、うち向けの学習も、入れてもらう
トラ猫：……編集部は、その2つを、自分のGPUで試しました
トラ猫：速くする設定で、6分の1まで、遅くなりました
部長：遅く？
トラ猫：うち向けの学習も、やり方を4通り試して、4通りとも、何もしていない元のモデルに、負けました
外に出せない資料のために、生成AIを、自社のGPUで動かしてきた、編集部の記録です。
トラ猫：先に、編集部の環境です。GPUは、RTX 3090。推論のエンジンは、vLLMです
トラ猫：モデルは、4ビットに軽くして、本番の26Bを、GPU 2枚に分けて載せています
部長：でも、どれも、評判の良いやり方でしょ
トラ猫：はい。速くする設定は、毎秒5トークン。何もしなければ、毎秒30以上、出ていました
トラ猫：原因の1つは、RTX 3090の世代では、最新の高速化の部品が使えないこと。さらに、計算の手順を固める最適化も、切る必要がありました
トラ猫：追加学習は、4通りのやり方で、合わせて20回比べて、16回、元のモデルの方が良い、という判定でした
トラ猫：直したい所を、決まりとして指示に書き足すと、勝ったのは、6回のうち1回
トラ猫：知識を12項目足しても、6回のうち2回。足すたびに、悪くなりました
部長：うちの見積もり、学習の費用まで、入ってたわ
トラ猫：追加学習は、別の用途では、効いたこともあります。どちらになるかは、自分の環境で、試すまで分かりませんでした
トラ猫：一番高くついた失敗は、これです。19回分の評価を、本番とは別のモデルに対して、やっていました
部長：どうして、そんなことに
トラ猫：評価を回す仕組みが、別の接続先を、指していたんです。そこには、比較用の、別のモデルが載っていました
部長：点数が出てたら、普通、信じちゃうわ
トラ猫：はい。自動では、見つかりませんでした。接続先を、1件ずつ確かめる監査で、やっと分かったんです
トラ猫：同じ監査で、設計書に書いた3つの動きのうち、実際に作られていたのは、1つだけ、とも分かりました
部長：うちも、システム会社の評価の報告、どのモデルを測ったか、書いてないわ
部長：じゃあ、どうすれば、気づけたの
トラ猫：動いている仕組みに、自分の構成を、書き出させます。読み込んだモデル、接続先、登録された知識の数
トラ猫：そして、評価の点数には、この記録を、必ず添える。設計書に書いてある、は、根拠にしません
部長：点数だけじゃなくて、何を測ったか、を一緒に出してもらうのね
部長：足しても良くならないなら、何が、効いたの
トラ猫：どのモデルを選ぶか、です。4ビットに軽くした26Bの方が、比べた相手より、明確に良くて、2.2倍、速かった
部長：選んだら、もう決まりね。9割、勝ったんでしょ
トラ猫：23件で比べた時は、9割でした。100件に増やして測り直すと、66%に、縮みました
部長：少ない件数の大差は、そのまま、信じちゃダメね
トラ猫：はい。さっきの、6回の比較も、少ない件数です。だから、自分の環境で、件数を増やして、測り直します
部長：じゃあ、GPUは、何枚、買えばいいの
トラ猫：買う前に、手元で、小さいモデルを1つ、動かします。7Bなら、メモリは5.2GB
トラ猫：業務に要る品質が、7Bで足りれば、GPUは1枚で済みます
トラ猫：ただし、ぎりぎり載る構成だと、同時に何人も使う時に、詰まります。何人で使うかも、先に決めます
部長：最初から、何枚も買わない、のね
部長：うちで、私が、やることは？
トラ猫：まず、手元の機械で、7Bを1つ動かして、自社の業務で足りるかを見ます
トラ猫：次に、評価の方法を、1つだけ決める。どのモデルの答えかを伏せて、10件比べる、それだけで構いません
トラ猫：最後に、データが、どこから外に出るかを、辿ります。見落としは、たいてい、文書を検索用に変える処理にあります
部長：……速くする設定も、うち向けの学習も、うちのGPUで、測ってから決めるわ
トラ猫：足すより、選ぶ。そして、何を測ったかを、毎回、添える、です
部長：見積もりの前に、まず、7Bを1つ、手元で動かしてみる
トラ猫：はい。業務で、足りるかどうか、からです
GPUの見積もりの前に、何を試しましたか。記事は、AIコンパス、オンプレミスでLLM、で検索。

目次

• この記事の立ち位置
• オンプレミスとは何か
• オンプレミスを選ぶ理由
• 大規模言語モデル（LLM）とは
• 実際の構成
• 実測したレイテンシ
• 必要なVRAMとディスク
• モデルをどう選んだか
• 量子化の扱い
• 棄却した選択肢1：投機的デコード
• 棄却した選択肢2：追加学習
• 棄却した選択肢3：規則を書き足す
• 棄却した選択肢4：知識の数を増やす
• 仕様と実機が食い違っていた
• 評価をどう設計したか
• クラウドとの比較
• 情報を外に出さないという要件
• 導入前に決めておくこと
• 費用をどう見積もるか
• まとめ

この記事の立ち位置

生成AIを業務で使いたいが、扱うデータを外部のサービスに送れない。この制約は、受託業務、医療、金融、法務、人事といった分野で頻繁に発生する。

選択肢は、手元のハードウェアでモデルを動かすことになる。しかし「オンプレミスでLLMを動かす」という話は、構成図と必要スペックの紹介で終わっていることが多い。実際に何が動かず、何を諦めたかの記録は少ない。

編集部は自社のGPUサーバーで大規模言語モデルを運用している。この記事は、その構成と実測値、そして試して棄却した選択肢の記録である。

採用したものより、棄却した記録のほうが役に立つ。やってみて効かなかったことは、他では書かれない。

オンプレミスとは何か

定義

自社が管理する場所に機材を置き、そこでソフトウェアを動かす形態を指す。自社のサーバールーム、借りているデータセンターのラック、社内に置いた1台の機械。所有と管理が自社にあれば、いずれもオンプレミスである。

対になるのがクラウドで、他社が用意した計算資源を、必要な分だけ借りて使う形態である。

オンプレミスとクラウドの違い

生成AIを動かす文脈に限って、違いを整理する。

「安いのはどちらか」に一般的な答えはない。 使う量と、使わない時間の長さで逆転する。

中間の形もある

実務では、二択ではない選び方をすることが多い。

専用サーバーを借りる。 機材は他社のものだが、その機材を自社だけが使う。購入せずに専有できる。

クラウド上に隔離した環境を作る。 通信を制限し、自社専用の領域で動かす。データは事業者の設備にあるが、経路を絞れる。

用途で分ける。 機微な情報を含む処理だけ手元で動かし、それ以外はクラウドのAPIを使う。編集部はこの形をとっている。

この記事が扱う範囲

以降は、自社のGPUで大規模言語モデルを動かした実際の記録である。構成、実測値、必要な機材、そして試して棄却した選択肢を書く。

一般的な比較ではなく、動かしてみて何が起きたかが中身である。

オンプレミスを選ぶ理由

判断の軸は3つある。

1. データを外に出せない

最も強い理由である。契約上、顧客の情報を自社の判断で外部サービスに渡せない場合がある。この制約は技術で回避できない。

利用規約で「学習に使わない」と明記されていても、送信すること自体が契約違反になる場合は変わらない。個人情報が含まれる場合の扱いは、個人情報保護委員会の法令・ガイドラインが基準になる。

2. 量が多い

月に数時間なら、クラウドのAPIが安い。量が増えるとある点で逆転するが、その点は自社の使い方で変わるので、実際に見積もる必要がある。

見落としやすいのは、GPUの購入費だけでなく電力・空調・保守・人件費が乗ることである。

3. 応答速度を詰めたい

ネットワークの往復を無くせる。編集部の構成では、トンネル経由の往復だけで50〜100ミリ秒かかっている。対話用途ではこれが効く。

逆に、オンプレミスが向かない場合

最新のモデルをすぐ使いたい場合は向かない。公開されているモデルは、商用APIの最新版に対して遅れる。

使う量が読めない場合も向かない。GPUは使わなくても費用が発生する。

大規模言語モデル（LLM）とは

定義

大量の文章で学習させた、次に来る語を予測する仕組みである。英語では Large Language Model、略して LLM と呼ぶ。

「質問に答える」「要約する」「翻訳する」といった働きは、すべて次の語を予測し続けた結果として出てくる。人のように理解して答えているわけではない、という点は押さえておく価値がある。

規模の表し方

モデルの大きさはパラメータ数で表す。「7B」は70億、「32B」は320億を意味する。

大きいほど能力が高い傾向があるが、そのぶん必要なメモリと計算量が増える。 本記事で扱う話の中心はここで、自社の機材でどこまで載るかが構成を決める。

なお、一部の専門家だけを使う方式（Mixture of Experts）のモデルでは、総パラメータ数と実際に計算に使われる数が違う。編集部が採用しているモデルは総数26B、実際に動くのは3.8Bという構成である。総数だけで速度を予想すると外れる。

手元で動かせるのはどれか

商用APIで提供されている最上位のモデルは、重みが公開されていない。手元で動かせるのは、重みが公開されているモデルに限られる。

公開モデルは商用APIの最新版に対して遅れるが、用途を絞れば十分に実用になるというのが編集部の実測である。後述する比較では、公開モデルどうしでも選び方で明確な差が出た。

API経由と手元で動かすことの違い

API経由は、事業者のサーバーで動いているモデルに文章を送り、結果を受け取る。送った内容は事業者の設備を通る。

手元で動かす場合、モデルの重みを自社の機材に置き、計算も自社で行う。文章はネットワークに出ない。

この違いが、オンプレミスを選ぶ最大の理由になる。

実際の構成

編集部の構成である。対話用途のため、言語モデル以外に音声認識と音声合成も同居している。

RTX 3090を5枚使っている。最小構成としては、言語モデルに2枚、音声認識に1枚、音声合成に1枚の計4枚である。

推論エンジンにはvLLMを使っている。複数の要求をまとめて処理する仕組みと、メモリの断片化を抑える仕組みを持つ。技術的な背景はPagedAttentionの論文にある。

ネットワークの構成

GPUを載せた機械と、開発に使う機械は別である。両者はトンネルで接続し、サービストークンで認証している。GPUの機械を直接インターネットに露出させない。

この構成にすると、GPUの機械を社内ネットワークの中に置いたまま、外から使える。

環境の制約

構築時にはまった点として、マザーボードの設定でメモリ管理の機能を無効にする必要があった。GPUを複数枚挿す構成では、この種のハードウェア側の設定が効いてくる。ドライバのバージョンにも下限がある。

NVIDIAのCUDA Toolkitのバージョンとドライバの対応表は、構築前に確認しておく。

実測したレイテンシ

実際に測った値である。

最初のトークンまでの21ミリ秒は、調整前と比べて30.7%の短縮である。

音声認識を会議の記録に使った場合の精度と、モデルの選び方はAI文字起こしと議事録の実務で扱っている。

この数字の読み方

専用のGPUを割り当てた構成での値である。複数の利用者が同時に使う環境では、待ち行列が発生して大きく変わる。

また、入力が長くなると最初のトークンまでの時間は伸びる。長い文書を読ませる用途では、この値は当てはまらない。

再現性も測った

同じ入力に対して同じ出力が返るかを確認した。乱数の種を固定し、確率の最も高い語を選ぶ設定で30回試行し、30回すべてが一致した。

業務で使う場合、同じ入力で同じ結果が出ることが要件になる場面がある。監査や再現確認が必要な用途では、この性質を先に確かめておく。

必要なVRAMとディスク

実際に使っている容量である。いずれも4ビット量子化を適用している。

ディスクは、GPUの機械で合計55GB程度である。内訳は推論エンジンのキャッシュが約15GB、音声認識が約5GB、音声合成のモデル群が約32GBとなる。

VRAMだけで判断しない

「24GBのGPUなら32Bのモデルが載る」という計算は、推論だけを考えた場合である。実際には、同時に処理する要求の数に応じてキャッシュが必要になる。

vLLMでは、このキャッシュにVRAMの一定割合を割り当てる。モデルがぎりぎり載る構成にすると、同時処理数が1に近づいて速度が出ない。

モデルをどう選んだか

公開されているモデルは多い。選び方を決めておかないと、目についたものを順に試して終わる。

編集部は総当たりの比較で決めた。同じ入力を複数のモデルに与え、出力を並べて判定する。判定は別の大きなモデルに複数の観点で採点させ、合議で勝敗を決めた。

結果

3つのモデルによる総当たりで、採用したモデルが12の観点のうち10勝0分1敗、勝率90%だった。2位のモデルは63%、3位は0%である。

その後、観点を増やした再試験でも11勝1敗（91%）と傾向は変わらなかった。

ただし、標本を増やすと差は縮んだ

重要な注意点がある。入力を100件に増やして測り直すと、勝率は66%に下がった。

23件の入力で測ったときは91%、100件では66%。標本が小さいと差が大きく見える。

どちらも同じ方向の結論（採用したモデルが良い）ではあるが、「90%勝っている」と「66%勝っている」では意思決定が変わる場合がある。 小さい標本で出た大差は、そのまま信じない。

後日、別の観点で再検証した

別の日に、より実際の用途に近い入力で、上位2つのモデルを一対一で比較した。判定は2つの異なる大きなモデルの合議とした。

結果は8つの観点すべてで採用モデルが勝ち、判定した2つのモデルの意見も一致した。ここで本番採用を確定させている。

絶対評価も取っておく

勝敗だけでなく、絶対値でも測っておく必要がある。相対比較では「他より良い」しか分からない。

7つの観点で10点満点の絶対評価を取ったところ、4.2〜4.9点だった。最も高いのが具体性で7.5点、最も低いのが掘り下げの深さで3.0〜3.5点である。

つまり、比較では勝っているが、絶対値としては中程度である。この認識があるかないかで、期待値の置き方が変わる。

量子化の扱い

モデルの重みを低いビット数で表現し、メモリと計算量を減らす手法である。編集部では4ビットの量子化を使っている。

代表的な手法としてAWQとGPTQがある。いずれも、重要な重みの精度を保ちながら全体を圧縮する考え方に基づく。

品質への影響

量子化すると品質は落ちる場合がある。ただし編集部の比較で分かったのは、量子化の有無より、どのモデルを選ぶかのほうが影響が大きいということである。

4ビット量子化した26B規模のモデルが、比較対象より明確に良い結果を出している。「量子化するくらいなら小さいモデルを使う」という判断は、実測では支持されなかった。

速度への影響

速度も測った。採用したモデルは、比較対象に対して2.2倍速い（同じ処理で535秒と1,185秒）。

量子化とモデルの構造（一部の専門家のみを使う方式）の両方が効いている。

棄却した選択肢1：投機的デコード

ここから、試して棄却したものを書く。

投機的デコードは、小さいモデルに先の語を予測させ、大きいモデルがまとめて検証することで生成を速くする手法である。理論的には数倍の高速化が見込める。

結果は毎秒5トークン。何もしない状態が毎秒30以上なので、6分の1まで遅くなった。

なぜ遅くなったか

原因は複数ある。

使用しているGPUの世代が、特定の高速化に対応していない。 RTX 3090の計算能力の世代は、最新の注意機構の最適化が使えない。

計算グラフの最適化を無効にする必要があった。 投機的デコードを有効にするために、事前に計算手順を固める最適化を切ることになり、その分が遅くなった。

テンソル並列との組み合わせで調整が必要だった。 2枚のGPUに分割している構成では、追加の調整が要る。

さらに出力の品質も落ちた

速度だけでなく、出力に誤った情報が混ざる現象も確認された。存在しない事実を述べる出力が出た。

学び

手法の評判ではなく、自分の環境で測る。 投機的デコード自体は有効な手法だが、それが成立する前提（GPUの世代、並列の構成、モデルの組み合わせ）が揃っていなければ効かない。

論文やブログに載っている数値は、その環境での値である。

棄却した選択肢2：追加学習

特定の用途に合わせてモデルを追加学習させる手法を、4つの段階で試した。データの作り方、学習の設定、評価の方法を変えながら4回である。

4回すべて、追加学習していない元のモデルに負けた。

判定は大きなモデルによる合議で行い、4段階で20回の比較のうち16回、元のモデルのほうが良いという判定だった。

なぜ負けたのか

追加学習は、与えたデータの傾向にモデルを寄せる。寄せた結果、元のモデルが持っていた汎用的な能力が削れる。

特に、想定していなかった入力に対する対応力が落ちる。学習データに似た入力では良くなるが、外れた入力で崩れる。

ただし、別の用途では成功している

公平を期すために書くと、同じ手法が別の用途では機能した。そちらは合議で87%の勝率を得ており、採用している。

つまり「追加学習は効かない」ではなく、用途によって効いたり効かなかったりする。事前にどちらかを予測する方法は、編集部では見つけられていない。試して測るしかない。

先に試すべきこと

追加学習は費用と時間がかかる。その前に確かめるべきことがある。

指示の書き方を変える。 出力の形式、禁止事項、参照すべき観点を明示する。

指示の書き方を変えながら採点した結果はプロンプトは足しても良くならないにまとめている。足すほど下がった実測である。

参照する情報を整備する。 学習させるのではなく、都度渡す。

モデルを変える。 編集部の比較では、モデルの選択のほうが追加学習より効果が大きかった。

棄却した選択肢3：規則を書き足す

出力の傾向を直すために、指示の中に規則を書き足していく方法を試した。

「この表現を使わない」「この観点を必ず含める」といった規則を、問題を見つけるたびに追加する。

結果は、合議で6回中1回の勝率（16%）。元の状態から50ポイント下がった。

なぜ悪化したか

規則を足すと、モデルが規則を守ることに注意を使い、内容が薄くなる。 また、規則同士が矛盾する場合に予測できない動きをする。

さらに本質的な問題として、観測した問題に対して規則を足す方式は、終わらない。 1つ直すと別の問題が出る。編集部の記録には「もぐら叩き」と書かれている。

代わりに効いたこと

規則の数ではなく、何を目指すかの記述を整えるほうが効いた。個別の禁止事項を並べるより、達成したい状態を1つ示すほうが結果が良い。

ただし、機械で検査できる禁止事項は規則として持つ価値がある。「この文字列を出力しない」は、指示に書くのではなく、出力後の検査で止める。

棄却した選択肢4：知識の数を増やす

モデルに渡す背景知識を、12項目追加した。

結果は合議で6回中2回（33%）。元の状態から33ポイント下がった。

学び

知識は量ではなく質である。 関連の薄い知識を足すと、関連の強い知識が埋もれる。

渡せる情報量には上限がある。追加するということは、何かを押し出しているのと同じである。押し出されたものが何かを見ずに追加すると、悪化する。

仕様と実機が食い違っていた

運用の記録から、最も高くついた失敗を書く。

19回分の評価を、本番とは違うモデルに対して行っていた。

設計上、本番の言語モデルは特定のポート番号で待ち受けている。評価を回すスクリプトは、別のポート番号を指していた。そちらには比較用の別のモデルが載っている。

どう気づいたか

全体の監査を行った際に、接続先を1件ずつ確認して見つかった。自動的には検知されなかった。

評価は正常に完走し、点数も出ていた。数字が出ているので、間違っているとは思わない。

同種の食い違いが他にもあった

同じ監査で、次の食い違いも見つかった。

設計書に書かれた3つの動作のうち、実装されていたのは1つだけだった。残る2つは、コード上に存在しなかった。

背景知識のうち36項目が、登録簿に載っていなかった。 結果として280件以上の情報が、モデルから参照できない状態にあった。

環境変数の名前と、実際に効く範囲が食い違っていた。 ある設定は、本番で使っている経路には適用されない仕様だった。名前からはそれが分からない。

対策

動いているシステムに、自分の構成を出力させる。 起動時に、実際に読み込んだモデル名・接続先・バージョン・登録された項目数をログに出す。

評価の結果に、その出力を必ず添付する。 点数だけを保存すると、何を測ったのか後から分からない。

「設計書にそう書いてある」を根拠にしない。 設計書は意図であり、実機の状態ではない。

同じ形の食い違いが配信の側でも起きている。HTTP 200を返しながら壊れていた6件をHTTP 200なのに壊れているに記録した。

評価をどう設計したか

ここまでの比較を成立させるために、評価の設計に手を入れている。

判定を別のモデルにやらせる

出力の良し悪しを人が見ると、量が増えたときに続かない。編集部では、別の大きなモデルに複数の観点で採点させ、合議で判定している。

判定するモデルは、比較対象とは別系統のものを使う。同じ系統だと自分の出力を高く評価する傾向が出る。

盲検にする

どちらの出力がどのモデルのものかを伏せて判定させる。伏せないと、モデル名に引きずられる。

ある棄却の判断は、盲検で50件中4件しか合格しなかったという結果に基づいている。

数を数える検査も併用する

主観的な判定だけでなく、機械的に数える検査も入れている。

ある候補モデルは、同じ文を47回繰り返すという壊れ方をした。これは数えれば分かる。もう1つ、特定の話者の発話が84%を占めるという偏りも数えて検出した。

壊れ方には、数えれば分かるものと、読まないと分からないものがある。 前者は機械で先に落とす。

回帰試験を回す

変更のたびに、100件の入力で通しを行う。所要時間は約16分である。

この試験では、成功率だけでなく、出力の統計も取る。平均の長さ、存在しない固有名詞が混ざった割合、話題が混線した割合。

存在しない固有名詞の混入率は、改善前が30%以上、改善後が6%である。この数字を追えるようにしたことが、改善の判断を可能にした。

クラウドとの比較

公平のために、クラウドのAPIと比べた場合の整理を書く。

手軽に試す選択肢

いきなりGPUサーバーを組む必要はない。手元の機械で試せる選択肢がある。

OllamaとLM Studioは、コマンドやGUIでモデルを取得して動かせる。llama.cppはCPUでも動作し、量子化したモデルを扱える。

まずこれらで、自社の業務に必要な品質が小さいモデルで足りるかを確かめる。 足りるなら、大きなGPUは要らない。

本格的に複数の要求を捌く段階になったら、vLLMやText Generation Inferenceといった推論サーバーを検討する。音声認識のように、変換した形式で高速に動かす基盤としてはCTranslate2がある。

モデルの入手先としてはHugging Faceが中心で、Qwenのような公開モデル群が揃っている。量子化や最適化の実装はOptimumにまとまっている。

情報を外に出さないという要件

オンプレミスを選ぶ最大の理由がこれである以上、本当に外に出ていないかを確かめる必要がある。

確かめるべき経路

モデルの取得。 初回にモデルをダウンロードする。この通信自体は問題ないが、取得したモデルが外部に問い合わせる実装になっていないかは確認する。

ログと監視。 推論の入出力をログに残す場合、そのログがどこに保存され、誰が読めるかを決める。外部の監視サービスに送っていないか。

埋め込みの生成。 文書を検索可能にする処理で、外部のAPIを使っていないか。ここを見落として、本文が外に出ている構成は起こり得る。

評価とデバッグ。 開発中に、問題のある出力を外部のサービスに貼って調べることがある。運用上のルールとして決めておく。

ネットワークで担保する

最も確実なのは、GPUの機械から外向きの通信を遮断することである。モデルの取得時だけ開け、運用中は閉じる。

編集部の構成では、GPUの機械を直接インターネットに露出させず、トンネルとトークン認証を経由させている。

組織としての取り決め

技術的な遮断に加えて、何を扱ってよいかの取り決めが要る。AI事業者ガイドラインや情報処理推進機構の資料が、方針を作る際の参照先になる。

導入前に決めておくこと

小さいモデルで足りるかを先に確かめる

これが最も費用を左右する。 7B規模で足りるなら、GPUは1枚で済む。手元の機械で試してから調達する。

同時に何件処理するかを決める

1人が使うのと、50人が同時に使うのでは構成が変わる。モデルがぎりぎり載る構成は、同時処理で詰まる。

評価の方法を先に作る

モデルを入れてから「良いかどうか」を議論すると決まらない。入れる前に、何をもって良しとするかを決めておく。

編集部の場合、盲検での勝敗、絶対評価の点数、機械的に数える検査の3つを組み合わせている。

誰が保守するかを決める

GPUサーバーは壊れる。ドライバは更新される。モデルは新しいものが出る。運用を担当する人を決めていないと、入れたまま古くなる。

止まったときにどうするかを決める

オンプレミスは、止まったら止まる。クラウドのAPIに切り替える経路を用意しておくか、止まってよい業務に限定するかを決めておく。

費用をどう見積もるか

オンプレミスとクラウドの比較で、最も判断を誤りやすいのが費用である。

GPUの価格だけで比べない

「GPUを1枚買えば使い放題」という見方は、次を勘定に入れていない。

電力。 常時稼働させると無視できない。GPUの消費電力に加えて、電源装置の効率と空調が乗る。

設置場所。 複数枚のGPUを積む機械は、一般的なオフィスの机には置けない。発熱と騒音がある。

保守。 GPUは壊れる。予備を持つか、止まる期間を許容するかを決める。

人件費。 ドライバの更新、モデルの入れ替え、障害対応に人の時間がかかる。ここが最大の費目になることが多い。

クラウドの費用は使い方で桁が変わる

一方でクラウドのAPIも、見積もりを誤りやすい。

入力の長さが費用に直結するため、長い文書を毎回読ませる使い方をすると想定の数倍になる。 同じ内容を繰り返し送らない設計にできるかで、桁が変わる。

比べるべきは「業務1件あたり」

月額の総額ではなく、処理する業務1件あたりの費用で比べる。

議事録1本、問い合わせ1件、文書1通。この単位で両方を試算すると、量がどこで逆転するかが見える。逆転点が自社の処理量より遠ければ、クラウドで足りる。

段階を踏む

現実的な順序は次のようになる。

第1段階。 クラウドのAPIで、機微でないデータを使って業務が成立するかを確かめる。

第2段階。 手元の機械で小さいモデルを動かし、必要な品質が出るかを確かめる。

第3段階。 量と機微さの両方が要件になった時点で、GPUを調達する。

最初からGPUを買わない。 業務が成立するかどうかのほうが、先に確かめるべき不確かさである。

まとめ

自社のGPUサーバーで大規模言語モデルを運用した記録である。

構成はRTX 3090が5枚。 言語モデルに2枚、音声認識に1枚、比較用に2枚、音声合成に1枚。最小構成は4枚である。

実測は、最初のトークンまで平均21ミリ秒、全体で0.8〜1.2秒。 乱数を固定した30回の試行はすべて一致した。

モデルの選択が、量子化の有無より効いた。 4ビット量子化した26B規模が、比較対象より明確に良い。

小さい標本の大差は信じない。 23件で91%だった勝率が、100件では66%になった。

棄却した選択肢が4つある。 投機的デコード（6分の1に減速）、追加学習（4段階すべて元のモデルに敗北）、規則の追加（50ポイント低下）、知識の追加（33ポイント低下）。

19回分の評価を、本番とは違うモデルに対して行っていた。 数字が出ていたので誰も疑わなかった。設計書ではなく、動いているシステムに構成を出力させる。

明日から試せる3つ

1つ目は、手元の機械で7B規模のモデルを1つ動かしてみることである。自社の業務に必要な品質が小さいモデルで足りるかが分かれば、調達の判断が変わる。

2つ目は、評価の方法を1つだけ決めることである。盲検で10件比べる、それだけでよい。決めていないと、入れてから議論が始まる。

3つ目は、いま使っている生成AIの経路で、データがどこに出ているかを1つずつ辿ることである。モデルの取得、ログ、埋め込みの生成、デバッグ。見落としはたいてい埋め込みの生成にある。

編集部では、オンプレミス構成の検討を含めたAI導入の支援を行っている。データを外に出せないが生成AIを使いたい、という段階の相談については、サービス案内を参照してほしい。

参考にした一次資料

• vLLM ドキュメント — 本記事の構成で使っている推論エンジン
• vLLM リポジトリ — 実装
• PagedAttention の論文 — vLLM のメモリ管理の背景
• AWQ の論文 — 本記事で使っている4ビット量子化
• GPTQ の論文 — 別系統の量子化手法
• Ollama — 手元で試す選択肢
• LM Studio — GUI で試す選択肢
• llama.cpp — CPU でも動く実装
• Text Generation Inference — 別系統の推論サーバー
• CTranslate2 — 変換形式で高速に動かす基盤
• Hugging Face Transformers — モデルの入手と実行
• Qwen — 公開されているモデル群の例
• Optimum — 量子化・最適化の実装
• NVIDIA CUDA Toolkit — ドライバとの対応表を確認する
• 個人情報保護委員会 法令・ガイドライン — 個人情報を扱う場合の基準
• AI事業者ガイドライン（経済産業省・総務省） — 組織としての方針の参照先
• 情報処理推進機構 — セキュリティの指針

よくある質問

オンプレミスとクラウドはどちらを選ぶべきですか。

扱う情報の機微さと、処理する量で決まります。顧客情報や未公開の事業計画を含むデータを外部のAPIに送れない場合は、オンプレミスが選択肢になります。一方、量が月に数時間程度ならクラウドのAPIのほうが安く早く、GPUの調達も構築も運用も不要です。編集部では情報の種類で使い分けています。

オンプレミスで動かすにはどれくらいのGPUが必要ですか。

モデルの規模によります。編集部の構成では、26B規模のモデルを4ビット量子化して約16GB、32B規模で約19GB、14B規模で9.4GB、7B規模で5.2GBのVRAMを使っています。音声認識と音声合成を同時に動かす場合は、それぞれ別のGPUに分けています。全体でRTX 3090を5枚使う構成です。

応答速度は実用になりますか。

編集部の実測では、最初のトークンが返るまでが平均21ミリ秒、音声認識が3秒の音声に対して280ミリ秒、発話が終わってから最初の音声が返るまでの全体が約0.8〜1.2秒でした。対話用途で実用になる水準です。ただしこれは専用のGPUを割り当てた構成での値で、共用環境では変わります。

量子化すると品質は落ちますか。

落ちる場合があります。ただし編集部の比較では、量子化の有無より、どのモデルを選ぶかのほうが結果への影響が大きいという結果になりました。4ビット量子化した26B規模のモデルが、量子化していない小規模モデルより明確に良い、という比較結果が出ています。

追加学習をすれば自社向けに良くなりますか。

必ずしも良くなりません。編集部では追加学習を4つの段階で試しましたが、いずれも追加学習していない元のモデルに負けました。盲検による比較で、元のモデルのほうが良いという判定が8割でした。追加学習を検討する前に、指示の書き方と参照させる情報の整備で改善する余地がないかを確かめるべきです。

高速化の手法は効きますか。

環境によります。編集部では投機的デコードという高速化手法を試しましたが、毎秒5トークンと、何もしない状態の6分の1まで遅くなりました。使用しているGPUの世代が特定の最適化に対応しておらず、前提が崩れていたためです。手法の評判ではなく、自分の環境で測ってください。