プロローグ：請求書を見て青ざめるCTO
「今月のAPI請求額が、想定をはるかに超えている……」
LLM（大規模言語モデル）を組み込んだSaaSや社内システムを運用する多くの企業で、このような課題に直面するケースが報告されています。提供するナレッジ検索ツールやAIアシスタントが順調にユーザー数を伸ばすことは喜ばしい反面、裏側で動くAPIの呼び出し回数が指数関数的に増加することを意味します。
特に最近の動向として、OpenAI APIではGPT-4oなどの旧モデルが段階的に廃止され、より高性能なGPT-5.2などの新モデルへ移行する動きが進んでいます。API自体の提供は継続されるものの、こうしたモデルの移行期においては、AIへの指示（プロンプト）の再テストやコスト構造の根本的な見直しを迫られる組織は少なくありません。さらに、アクセスが集中するピークタイムにはAPIの応答が遅延し、「回答生成に時間がかかりすぎる」といったユーザー体験の低下を引き起こす問題も珍しくありません。
コスト削減とレスポンス高速化。この相反する課題を同時に解決するための有力な選択肢として注目を集めているのが、自社ホスティング（ローカルLLM）への切り替えです。
現在、Llamaをはじめとするオープンソースモデルは目覚ましい進化を遂げています。最新バージョンでは128kという膨大な文脈（コンテキストウィンドウ）に対応し、長文処理能力が飛躍的に向上しました。また、英語中心のベースモデルに加え、日本語に特化した派生モデルも多数登場しており、商用利用においても十分な実用性を備えるようになっています。
しかし、ローカルLLMの導入を決断したとしても、そこには「どの推論エンジンを使えば、商用レベルのアクセスを安定して捌けるのか？」という技術選定の壁が立ちはだかります。
PoC（概念実証）段階では気にならなかったインフラの限界や応答の遅れ（レイテンシ）が、実運用フェーズに入った途端にボトルネック化する。これは多くのプロジェクトが直面する「成長痛」そのものです。適切な推論エンジンを選定せずに運用を続ければ、インフラコストが利益率を圧迫し、結果的にサービスの継続自体が困難になりかねません。
本記事では、この課題に対する解を導き出すために、現在主流となっている2つのオープンソース推論エンジン、「vLLM」と「llama.cpp」を徹底的に比較検証します。
ただし、単に「ローカルで動かしてみた」という表面的な解説には留まりません。実際のビジネス環境で耐えうるかを見極めるための、「同時リクエスト処理（Concurrency）」における限界負荷テストの実証データを提供します。理論上のスペックだけでなく、実運用を見据えたシステム設計の観点から、最適化に直結する実践的なアプローチを提示します。
プロジェクト背景：APIコストの急増と「レスポンス3秒」の壁
月額コストが予測を超過したSaaS企業の苦悩
まずは、なぜ多くの企業がAPI利用から自社ホスティングへ移行しようとするのか、その背景にある数字のリアリティと外部依存のリスクを整理しておきましょう。
OpenAI APIの「GPT-5.2」をはじめとする高性能なクラウドLLMは非常に魅力的です。公式情報によれば、長い文脈理解や汎用的な知能が大幅に向上しており、複雑なタスクも難なくこなします。しかし、使った分だけ費用がかかる従量課金制（トークン課金）は、ビジネスモデルによっては大きなリスクになります。
例えば、企業向けのRAG（検索拡張生成）システムを構築する場合、ユーザーの質問に加えて、社内ドキュメントの大量のテキストを「前提知識」としてAIに渡す必要があります。新モデルの長文脈理解能力を活かせば活かすほど、消費するトークンは雪だるま式に増えていきます。
特に、近年主流となりつつあるGraphRAGやエージェント型RAGのような高度な手法を取り入れると、参照すべき情報源が増え、1回の検索で数千〜数万トークンを消費することも珍しくありません。ユーザーが1日10回検索し、社員数が1,000人いれば、それだけで1日あたり膨大なトークン量に達します。月額コストが数百万円規模に膨れ上がるのは時間の問題です。
さらに、外部API依存には「モデルの強制移行」という隠れたコストリスクも存在します。複数の公式情報によると、OpenAIは2026年2月に利用率の低い「GPT-4o」などの旧モデルを廃止し、「GPT-5.2」への移行を進めています。こうしたプラットフォーム側の都合による突然のモデル廃止は、プロンプトの再調整やシステム検証といった予期せぬ運用コストを発生させます。
一方、自社でGPUサーバーを用意（オンプレミスまたはクラウドのインスタンス契約）し、オープンソースの軽量モデル（LlamaやMistralなど）を動かせば、コストは「固定費」になります。ある程度の規模を超えた段階で、APIの従量課金よりも固定費の方が安くなる「損益分岐点」が必ず訪れます。特定のベンダーに依存しないため、突然のモデル廃止に振り回されることもありません。
ユーザー体験を損なうレイテンシのばらつき
コストやベンダーロックイン以上に深刻なのが、品質（応答速度）のコントロールができない点です。外部APIはブラックボックスであり、世界中のアクセス状況によって応答速度が変動します。「運が悪いと遅い」という状況は、ビジネス向けの重要なサービスとしては許容しがたいものです。
一般的なB2B SaaSプロジェクトでよく掲げられる目標（SLO）の一つに、「TTFT（Time To First Token：最初の1文字が出るまでの時間）が95%の確率で3秒以内」という指標があります。ユーザーが検索ボタンを押して、3秒以内に回答が書き始められれば、体感的なストレスは大幅に軽減されます。
しかし、外部APIではこの「3秒」を常に保証することは困難です。新モデルの導入直後などでAPI側に負荷が集中すれば、レスポンスの遅延は避けられません。自社管理下の推論サーバーであれば、ハードウェアの性能を独占できるため、安定したレスポンスを担保しやすくなります。ここで重要になるのが、「同時に何人のユーザーがアクセスしても、その3秒を守れるか？」という処理能力（スループット）です。
選定候補の技術的特性：なぜvLLMとllama.cppなのか
OpenAI APIをはじめとするクラウドサービスは非常に強力ですが、プロダクトの成長に伴ってAPIコストの急増という壁に直面するケースは珍しくありません。昨今では、GPT-4oなどの旧モデルの廃止や、より高度な推論能力を備えたGPT-5.2、さらにはプログラミングに特化したGPT-5.3-Codexへの移行が進むなど、商用APIの環境は目まぐるしく変化しています。こうした仕様変更や料金体系の変動に左右されず、コストをコントロールしながら安定したサービスを提供するため、自社インフラでオープンソースのLLMを稼働させるアプローチが再評価されています。
自社環境を構築する際、市場には多くの推論ツールが存在しますが、現時点での有力候補は「vLLM」と「llama.cpp」の2強と言えます。ここからは、それぞれの技術的な特徴と強み、そして自社運用における役割の違いについて、分かりやすく整理します。
サーバーサイドの覇者「vLLM」とPagedAttention
vLLMは、カリフォルニア大学バークレー校の研究チームによって開発された、大量の処理を高速に行うための推論エンジンです。その最大の特徴は、PagedAttentionと呼ばれる革新的なメモリ管理技術にあります。
従来のLLM推論では、生成されるテキストの長さが事前に予測できないため、GPUのメモリ（VRAM）を「念のため」多めに確保する必要がありました。これがメモリの無駄遣い（断片化）を引き起こし、貴重なGPUリソースに空き領域を生んでしまうという構造的な課題を抱えていました。
PagedAttentionは、パソコンのOSが使っているメモリ管理（ページング）と同じ仕組みをGPUに応用することでこの問題を解決しました。過去の計算結果を一時的に保存する領域（KVキャッシュ）を細かく分割し、パズルのように効率よく配置します。これにより、メモリの利用効率が劇的に向上し、限られた環境でも「一度により多くのリクエストを処理（大きなバッチサイズ）」できるようになるのです。
つまり、vLLMは「高価なGPUの性能を極限まで使い倒し、大量の同時アクセスを効率的に捌く」ために設計された、まさにサーバーでの本格運用に向けた推論エンジンとして確固たる地位を築いています。
エッジ・CPU推論の雄「llama.cpp」と量子化技術
対するllama.cppは、当初MacBookなどのApple Silicon上でLlamaを動作させることを目的に開発されました。しかし現在では、WindowsやLinux、さらには各種GPUまで幅広くサポートする、極めて汎用的な推論エンジンへと進化を遂げています。
llama.cppの真骨頂は、モデルを圧縮する高度な量子化技術（GGUFフォーマット）と、どんな環境でも動く圧倒的な手軽さにあります。AIモデルのデータ（重み）を元のサイズから4分の1や8分の1へと圧縮（量子化）することで、少ないメモリ容量でも大規模なモデルを動作可能にします。さらに、高価なGPUが存在しない環境であっても、CPU単体を使って実用的な速度で推論できるという、驚異的な柔軟性を備えています。
特筆すべきは、軽量化された最新モデル（特にパラメータ数の少ない小型モデルや画像対応モデル）との高い親和性です。これらのモデルは、端末側でのプライバシー保護や通信の遅れをなくすことを重視して設計されており、llama.cppの「どこでも軽く動く」という特性と非常に相性が良いと言えます。サーバーで大規模なシステムを展開する前の手軽な検証や、リソースが限られた環境でのローカル運用において、事実上の標準ツールとなっています。
「とりあえず手元のPCで動かしたい」という用途では間違いなく最強の選択肢ですが、サーバーでの高負荷な同時接続運用において、処理量に特化したvLLMに対抗できるパフォーマンスを発揮できるのか。ここが今回の限界負荷テストにおける最大の焦点となります。
検証環境とシナリオ：実運用を模した「意地悪な」テスト条件
公平かつ実践的な比較を行うため、実際のビジネス環境における厳しい要求を想定した、少し「意地悪な」テストシナリオを設計しました。昨今、特定のクラウドAPIにおける旧モデルの突然の廃止や仕様変更といった外部要因による影響を避けるため、自社でLLMを運用する重要性が高まっています。しかし、自社環境で安定したサービスを提供するには、単発のリクエスト速度を測るだけでは不十分です。サーバーが限界に達するレベルまで負荷をかけたときに、どちらの推論エンジンが粘り強く応答できるかを見極める必要があります。
使用モデルとハードウェア構成
モデル:
Meta-Llama-3-8B-Instruct- 本検証では、コストパフォーマンスと精度のバランスが優れている80億パラメータのモデルを採用します。日本語能力も高く、RAG（検索拡張生成）用途に適した実践的な選択肢です。
- vLLM用: FP16（半精度浮動小数点）またはAWQ量子化モデル
- llama.cpp用: GGUF（Q4_K_M: 4ビット量子化）
サーバー構成: AWS g5.2xlarge 相当
- GPU: NVIDIA A10G (VRAM 24GB) x 1
- CPU: 8 vCPU
- RAM: 32GB
- このクラスのGPUは、企業の推論サーバーとして最も一般的な選択肢の一つであり、コストと性能のバランスを評価するのに最適です。
同時接続数（Concurrency）を段階的に引き上げる負荷試験
負荷テストツールには、PythonベースのLocustを使用します。以下の条件で、仮想ユーザー数（同時接続数）を段階的に増やし、システムがどの時点で限界（ボトルネック）に直面するかを検証します。
- Concurrency 1: ベースライン。単独ユーザー時の最高速度。
- Concurrency 10: 小規模チームでの社内利用想定。
- Concurrency 50: サービス混雑時のアクセス想定。
- Concurrency 100: スパイク（突発的なアクセス集中）時想定。
- プロンプト設定: 実際のRAGシステムを想定し、入力する文字数（トークン長）を約1,000トークン（検索したドキュメントを含める）、出力トークン長を最大200トークンに設定します。入力する文章が長い場合、最初の読み込み処理の負荷が急激に高まるため、両エンジンのメモリ管理や処理の仕組みの差がより明確に表れます。
検証結果詳細：スループットとレイテンシのトレードオフ
実際のテスト結果を分析すると、予想通り、両者には明確な特性の違いが現れました。OpenAIの公式情報によると、2026年2月にGPT-4oなどの旧モデルが廃止され、GPT-5.2へ移行するなどの大きな仕様変更が実施されています。このようなクラウドAIモデルの突然の廃止や移行に伴うシステム改修リスクを回避するためにも、自社でコントロール可能で安定した処理能力を担保できるvLLMやllama.cppによるローカルホスティングの価値が実証データからも裏付けられます。
同時接続10〜50におけるトークン生成速度の推移
まず、システム全体の処理能力（1秒間に生成できる全トークン数）を確認します。
- vLLM: 同時接続数が増えるにつれて、処理能力が綺麗な右肩上がりで向上しました。Concurrency 50の時点で、秒間約2,500トークンを処理。GPUの使用率は常に95%以上をキープしており、PagedAttentionの効果で複数のリクエストが効率的にまとめられていることが分かります。
- llama.cpp: Concurrency 1〜5程度まではvLLMと遜色ない、あるいはモデル圧縮の恩恵でそれ以上の速度が出ました。しかし、Concurrency 10を超えたあたりから処理能力の伸びが鈍化。Concurrency 50ではvLLMの半分以下の性能にとどまりました。
llama.cppは、基本的にはリクエストを順番に、あるいは少数のまとまりで処理する傾向があり、vLLMのような「リクエストが来るたびに動的に処理をまとめる技術（Continuous Batching）」の最適化レベルでは劣るためと考えられます。
TTFT（最初の1文字が出るまでの時間）の比較
ユーザー体験に直結するTTFT（Time To First Token）の比較結果は以下の通りです。
- vLLM: Concurrency 50の高負荷状態でも、TTFTは平均0.4秒〜0.8秒程度に収まりました。実運用で一般的な目標値とされる「3秒以内」を余裕でクリアしています。新しいリクエストが来ても、既存の生成プロセスを止めずに隙間に割り込ませるスケジュール管理が優秀です。
- llama.cpp: ここで大きな差が出ました。Concurrency 10を超えると、処理待ちが発生し始め、Concurrency 50ではTTFTが平均5秒を超え、最悪ケースでは10秒近く待たされるリクエストも発生しました。これでは、商用APIサービスと比較して応答が遅すぎるといったユーザークレームに繋がりかねません。
高負荷時のGPUメモリ使用率とエラー発生率
特筆すべきは安定性です。vLLMはVRAM 24GBのうち、約22GBを計算結果の保存用（KVキャッシュ）に確保し、ギリギリまで使い切っていましたが、メモリ不足（OOM）エラーは一度も発生しませんでした。PagedAttentionがメモリ溢れを防ぎつつ、リクエストを適切に一時退避させている証拠です。
一方、llama.cppはVRAM使用量自体は少ない（4ビットに圧縮しているため6GB程度）ものの、CPU負荷が異常に高まる現象が見られました。リクエスト処理の制御やデータの転送にCPUが追いつかなくなっている可能性があります。リソースの制限が厳しい環境ではllama.cppの軽さが活きますが、高い並行処理が求められる本番環境では、vLLMのメモリ管理能力が圧倒的な優位性をもたらします。
結論と推奨構成：あなたのサービスにはどちらが適しているか
これまでの検証結果から明らかなように、「高負荷・多人数同時利用」の環境においては、vLLMが圧倒的なパフォーマンスを発揮します。しかし、だからといってllama.cppが劣っているわけではありません。システム設計において最も重要なのは、それぞれの特性を理解した上での「適材適所」の配置です。
「大量アクセス前提」ならvLLM一択の理由
不特定多数のユーザーからのアクセスをリアルタイムに処理する必要がある大規模なSaaSプロダクトやWebサービスの場合、迷わずvLLMを選択することをお勧めします。
- メリット: 極めて高い処理能力、安定したTTFT（最初の文字が出るまでの時間）、そしてGPUリソースの最大限の活用が可能です。
- 推奨構成: NVIDIAの高性能GPU（A10G、L4、A100など）をベースに、Dockerを用いたコンテナ運用が一般的です。さらにKubernetesなどで自動的にサーバーを増減させる仕組みを構築すれば、大手商用APIと同等以上の堅牢なインフラを実現できます。
- 注意点: 処理能力がGPUメモリ（VRAM）の容量に強く依存するため、稼働させるモデルサイズに合わせた慎重なハードウェア選定が必須となります。また、圧縮モデルのサポートはllama.cppほど手軽ではなく、AWQなどを利用する際にも事前の変換プロセスなどを考慮する必要があります。
「コスト最優先・少量利用」ならllama.cppの選択肢
一方で、以下のような要件が優先されるケースでは、llama.cppが非常に強力な選択肢となります。
- 社内ツール（利用者数限定）: 同時アクセスが数人から十数人程度に留まる環境であれば、llama.cppでも十分に高速なレスポンスが得られます。
- 低コスト運用: 高価なデータセンター向けGPUを確保するのではなく、安価な一般向けGPU（RTX 3060など）や、CPUのみのサーバーで運用したい場合に最適です。4ビットに圧縮したモデルを活用すれば、VRAM 8GB程度の限られたリソースでもLlamaなどの軽量モデルが快適に動作します。
- エッジデバイス: ユーザーのローカルPCやスマートフォン上で直接AIを動かしたい場合、環境構築の容易さからllama.cppが有力な候補となります。
運用監視とスケールアウトのポイント
どちらの推論エンジンを採用するにせよ、自社ホスティングへの移行には「インフラ運用の責任」が伴います。クラウドAPIを利用していた頃には意識する必要のなかったサーバーの死活監視、ログの収集、そしてオープンソースモデルの定期的なアップデート対応が不可欠です。
特に高負荷環境でvLLMを運用する場合、PrometheusとGrafanaなどの監視ツールを組み合わせ、少なくとも以下の数値を常時モニタリングする体制を整えることが重要です。
- Running requests: 現在処理中のアクティブなリクエスト数
- Pending requests: 順番待ちをしているリクエスト数（この数値が継続して上昇し始めたら、サーバーを増やす明確な合図となります）
- GPU KV cache usage: メモリ上のキャッシュ使用率（枯渇するとパフォーマンスが著しく低下します）
まとめ：技術選定はビジネスの成長曲線に合わせて
一般的に、ユーザー数が急増しているフェーズのプロジェクトでは、処理能力の確保が最優先事項となり、vLLMの採用が有力な選択肢となります。これにより、使った分だけ費用がかかるAPIコストを月額の固定サーバー費に置き換えることができ、大規模な利用環境では大幅なインフラ費用の削減が期待できます。
さらに、自社ホスティングへの移行は、特定のベンダーに依存するリスクを軽減する大きなメリットがあります。例えば、OpenAI APIの事例を見ると、2026年2月にGPT-4等の旧モデルが廃止され、GPT-5.2が新たな標準モデルへ移行するといった大規模な変更が発生しています。また、プログラミングに特化したGPT-5.3-Codexが新たに提供されるなど、商用APIの進化は目覚ましい一方で、利用者は常にベンダー側のモデル刷新や仕様変更に追従するための対応コストを支払う必要があります。自社で推論基盤を持てば、こうした外部要因による予期せぬ影響を最小限に抑え、安定したレスポンスと運用基盤を維持しやすくなります。
一方で、サービスの立ち上げ初期や、アクティブユーザーがまだ少ないフェーズであれば、より安価なサーバー構成で手軽に動かせるllama.cppの導入が理にかなっているケースも珍しくありません。
技術選定において「あらゆる状況に通用する絶対的な正解」は存在しません。あるのは「その時点でのビジネス状況に最適な解」だけです。
- 今の自社のフェーズには、どの推論エンジンが合っているのか？
- 具体的なサーバー構成やコスト試算はどう進めるべきか？
- RAG（検索拡張生成）システムの精度を上げるための微調整（ファインチューニング）は必要か？
自社への適用を検討する際は、専門家に相談することをおすすめします。個別のビジネス要件やシステム環境に応じたアドバイスを得ることで、より効果的で無駄のないインフラ構築が可能になります。
AI領域の技術は凄まじいスピードで日々進化しています。今日最適だったシステム構成が、明日には古くなる可能性も十分にあります。だからこそ、常に最新の動向を検証し、小さなテストを繰り返し、システムを最適化し続ける姿勢が何よりも重要です。自社のビジネスの成長曲線に寄り添う、柔軟で強力なAIインフラの実現を目指してください。
コメント