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

目次

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

この記事の立ち位置

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

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

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

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

オンプレミスを選ぶ理由

判断の軸は3つある。

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

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

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

2. 量が多い

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

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

3. 応答速度を詰めたい

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

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

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

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

実際の構成

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

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の世代が特定の最適化に対応しておらず、前提が崩れていたためです。手法の評判ではなく、自分の環境で測ってください。