LLM推論基盤プロビジョニング講座 第1回 基本概念と推論速度

LLM推論基盤プロビジョニング講座 第1回 基本概念と推論速度

こんにちは!

本日は LLMサービスの自社構築する際の推論基盤プロビジョニング、GPUプロビジョニングについて数回にわけて解説いたします。

はじめに

LLMの進化に伴い、ChatGPTやClaudeといったパブリックなLLMの活用は企業においても急速に広がってきました。しかし先進的な企業はこれらの汎用LLMに加えて、「領域特化型」「ドメイン特化型」といった専用LLMの構築へと歩みを進めています。こうした動きの背景には、企業固有の専門知識への対応力強化と情報セキュリティの確保という二つの重要なニーズがあります。

一般的なパブリックLLMでは対応できない企業固有の専門知識や機密情報の取り扱いが必要なケースが増えているため、自社LLMの構築や自社サーバーでの運用を検討する企業が急増しています。特に金融、医療、製造、法務といった専門性の高い領域では、業界特化型の独自LLMが競争優位性をもたらすと認識されています。

しかし、業界特化型のLLMを自社で運用することは簡単ではありません。自社運用を決断した場合、まず最初に取り組むべきは適切な推論環境の整備です。オンプレミス環境を構築するにしても、クラウドサービスを利用するにしても、どのようなハードウェアスペックが必要で、特にどのようなGPUがどれだけの数量必要になるのかを事前に見積もる必要があります。

これは単にGPUを購入すれば良いという話ではなく、サービスの想定負荷やモデルの特性に基づいた緻密な計算が必要です。必要なGPUの種類や数量を適切に見積もることで、過剰投資を避けつつ、必要な性能を確保するための調達費用を正確に見積もることができます。

こうした自社運用型LLMサービスを効果的に構築するためには、適切なGPUリソースと推論環境の「プロビジョニング」が不可欠です。特にコスト効率と性能のバランスを取りながら、ユーザー体験を損なわないLLM環境を構築することは容易ではありません。

本記事では、LLMサービスの本番稼働前に必要な「推論基盤プロビジョニング」の概念と、具体的な実施ステップについて解説します。

本記事は株式会社Qualiteg提供の 生成AI/LLM基礎研修2024-2025資料から一部抜粋して再編集しております。実測データは一部2024年当時のものとなりますのでご了承ください

推論基盤プロビジョニングとは

LLMサービス構築の鍵となる推論基盤プロビジョニングとは

自社でLLMサービスを本格的に構築・運用する企業が増える中、本番環境への移行前に適切なハードウェアリソースを確保することが課題となっています。特に高性能GPUの調達と最適な推論環境の構築は、サービスの品質とコスト効率を左右する重要な要素です。

LLMサービスの本番化の前に必要なGPUおよび推論用サーバーリソース(推論環境)を準備しておくことを「推論基盤プロビジョニング」と呼びます。これはGPUの確保だけでなく、サービス全体を支える推論インフラの設計と準備を含む包括的なプロセスです。

推論基盤プロビジョニングの概要

推論基盤プロビジョニングとは、LLMサービスの本番稼働の前に必要なGPUおよび推論用サーバーリソース(推論環境)を準備しておくことを指します。

この工程は大きく分けて以下の2つの要素から構成されています

1. GPUプロビジョニング

GPUプロビジョニングでは、提供予定のLLMサービスの想定負荷やLLMモデルの素性に応じて、LLMサービスの要件を満たすGPUの種類や数を決定します。

具体的には

  • サービスの同時利用者数予測
  • 応答時間の要件
  • 処理すべきトークン数
  • 選定したLLMモデルの要求スペック
  • コスト効率

などを総合的に判断し、最適なGPUの種類(NVIDIA A100, H100など)と必要台数を算出します。

2. 推論環境プロビジョニング

推論環境プロビジョニングでは、GPUが搭載されるサーバー・ワークステーションやクラウド環境を決め、サービス提供に必要となるソフトウェアを適切な環境に配置し、必要な設定を行う作業が含まれます。

ここでの主な作業は

  • 推論サーバーのハードウェア選定または仮想環境の構築
  • コンテナ環境(Docker, Kubernetes)の構築
  • モデルサーブィングフレームワーク(vLLM, TensorRT-LLM)の導入
  • 負荷分散の設定
  • モニタリングシステムの導入
  • セキュリティ対策

Qualitegが実践する7ステップGPUプロビジョニングプロセス

さて、前節で説明した推論基盤プロビジョニングの重要性を踏まえ、ここではQualitegが実際に行っている具体的なGPUプロビジョニングプロセスを紹介します。Qualitegでは、実現したいLLMサービスに必要なGPUの種類と必要ボリュームを以下の7つのステップで決定します。

Step 1: 推論速度の定義

まず最初に、実現したい推論速度を明確に定義します。推論速度は「1秒間に何トークン出力できるか」という単位(トークン/秒)で測定します。業界の参考値として、OpenAIのChatGPTは約15〜25トークン/秒の速度であり、最低ラインとしてはこの程度の速度が一般的に求められます。例えば、25トークン/秒などの具体的な目標を設定します。

Step 2: LLMサービスへのリクエスト数見積もり

次に、提供するLLMサービスに対するユーザーのリクエスト数の見込みから、同時リクエスト数を概算します。特にピーク時とオフピーク時で強く表れるサービスの場合は、ピーク時の同時リクエスト数を予測することが重要です。例えば、ピーク時には同時40リクエストが発生すると予測する場合があります。

Step 3: 使用モデルの推論時消費メモリ見積もり

LLMサービスで使用するモデルのフットプリント(GPUに読み込まれたときに消費するメモリの大きさ)を見積もります。また、KVキャッシュ(推論中のテキスト生成に消費されるGPUメモリ)の容量も考慮に入れる必要があります。例えば、Llama3-8Bモデルの場合、16GB+KVキャッシュ分のメモリが必要になります。

Step 4: 推論エンジン選定

LLMモデルに対応した推論エンジンを選定します。推論エンジンとは、推論処理の計算を効率的に行うソフトウェアです。モデルに最適化されたエンジンを選ぶことが重要で、GPU依存、プラットフォーム依存があるため、非対応のものは選定しないようにします。例えば、TensorRTなどが代表的な推論エンジンとして挙げられます。

Step 5: GPUノード構成見積もり

LLMサービスの要件を満たすGPUノードが何台必要かを算定します。Step 2の同時リクエスト数とStep 3のメモリ見積もりからGPUリクエスト計算時間で概算したものに対し、このステップではGPUスペックと同時処理を勘案して見積もります。複数の構成案を作成するのが一般的ですが、最初からコストキャップがあることが多いため、それも勘案しながら構成を見積もります。例として、A5000 × 4などの構成が考えられます。

Step 6: GPUノード構成案での負荷試験

Step 5で作ったGPU構成案と選定した推論エンジンの組み合わせで、実際に負荷試験を行います。Step 3で算出した消費メモリはあくまで理論値であるため、実際に負荷をかけて実測してデータを収集することが重要です。この負荷試験にはLocustなどのツールが使用されることがあります。

Step 7: 推論体験とコストのトレードオフ検討

最後に、Step 6で収集したデータをもとに、本番向けのGPU構成、推論エンジンを決定します。数値の良い組み合わせほど高価なGPUが必要になる傾向があるため、推論体験(主に推論速度)とコストのトレードオフを検討します。この検討結果は最終的に推論環境仕様書としてまとめられます。

それでは、重要なステップの内容をみていきましょう。


STEP1: 推論速度の定義 - LLMサービス構築の基本

同期型と非同期型のLLMサービス

LLMサービスを提供する形態には「同期型」と「非同期型」の2つのパターンがあります。

同期型LLMサービスとは

チャットボットのような「リアルタイム性」や「即時性」が求められるサービスが同期型LLMサービスに分類されます。ユーザーが質問や指示を入力すると、即座に応答が返ってくることが期待されます。この場合、推論速度が速いほど応答を受け取るユーザー体験は向上するため、同期型LLMサービスを提供する際には、最初に「目指すべき推論速度」を明確に定義することが重要です。

同期型LLMサービスは同時に大量のリクエストが来ることを想定する必要があり、リクエストを捌くために複数のGPUや推論環境が必要になるため、実現難易度とコストは非同期型に比べて高くなります。

非同期型LLMサービスとは

即時性が求められない用途では、例えば

  • 大量の文章を要約する
  • 大量の文章を翻訳する

といった処理をLLMに一括して実行させ、終わり次第結果を通知させるようなユースケースがあります。このようなパターンを非同期型サービスと呼びます。

「数時間、数日かけて終われば良い」というレベル感の非同期型LLMサービスの場合、1台のGPUでも効率的に処理できる場合があり、実現難易度は低く、コストも抑えられる利点があります。

ストリーミングレスポンスによる体験向上

ユーザーが入力してからLLMが応答を返し、ユーザーの画面に表示されるまでの時間を「レイテンシ」と呼びます。

レスポンス方式には以下の2種類があります

シングルバッチレスポンス(一括返信)

入力されたプロンプトからテキスト生成を行い、すべてのテキストの生成が終わってからレスポンスする方式です。生成結果が出そろうまでユーザーに返信しないため、ユーザーは結果を待たされることになります。この場合、総レイテンシが約10秒かかると、結果がすべて一度に表示されます。

ストリーミングレスポンス(逐次返信)

入力されたプロンプトからテキスト生成を行い、1トークン(または数トークン)生成されるごとに逐次返信する方式です。テキスト生成の過程を見ることができるので、一括返信よりもユーザー体験が向上します。

初期応答レイテンシが約2秒で最初の結果が表示され始め、完全応答レイテンシが約11秒でも、ユーザーは少しずつ結果が表示されるのを見ることができるため、体感的な待ち時間が短く感じられます。

推論速度の単位と目標設定

同期型LLMサービスの場合、まず推論速度を設定することが重要です。

推論速度の単位

推論速度は「1秒間に何トークン生成できるか」を示す「トークン/秒」(英語表記ではT/sやtokens/sec)で表されます。これはLLMサービスの性能を表す際に最もよく使われるメトリクスです。

最低限目指したい推論速度

リクエストピーク時に15〜25トークン/秒の推論速度を実現できることが最低ラインとされています。ここで設定した推論速度をピーク時に実現できるよう、後続のステップでGPU構成を見積もっていきます。

主要LLMサービスの推論速度比較

各社のLLMチャットサービスの推論速度を比較すると

  • ChatGPT(GPT4): 15〜25トークン/秒
  • ChatGPT(GPT4o): 25〜50トークン/秒
  • Claude3 Haiku: 120トークン/秒
  • Groq(Llama70B): 300トークン/秒

目指すべき推論速度の目安

現実的な目標としては、ChatGPTのスピードがエンドユーザーの体験基準と考えると、GPT-4oと同程度の40〜70トークン/秒が実現したい推論速度の目安となります。

LLMの推論速度は以下のように分類できます

  • 低速(〜30トークン/秒): GPT-4(15〜25)、DeepSeek-V2-Chat(25)
  • 中速(30〜100トークン/秒): GPT-4o(40〜70)
  • 高速(100〜300トークン/秒): Claude3 Haiku(120)、Fireworks Llama3 70B(200)
  • 超高速(300トークン/秒〜): Groq Llama3 70B(302)、Groq Llama3 8B(900)

自社LLMサービスの判定ラインとしては、15トークン/秒(C判定)、30トークン/秒(B判定)、70トークン/秒(A判定)といった基準が考えられます。

これらの推論速度の定義が、以降のGPUプロビジョニングプロセスの基盤となり、必要なGPUリソースの算出に直接影響します。

今回のまとめ:効果的なGPUプロビジョニングへの道

今回は、LLMサービス構築における推論基盤プロビジョニングの基本概念と、Qualitegが実践している7ステップGPUプロビジョニングプロセスの中でも特に重要なSTEP1「推論速度の定義」について詳しく解説しました。

同期型と非同期型のLLMサービスの違いを理解し、ユースケースに応じた適切な推論速度目標を設定することがプロビジョニングの第一歩です。ChatGPTやClaude3などの主要LLMサービスの推論速度を参考にしながら、ユーザー体験を左右する重要な指標として15〜70トークン/秒の範囲で目標を定めることが推奨されます。

次回は、STEP2「LLMサービスへのリクエスト数見積もり」、STEP3「使用モデルの推論時消費メモリ見積もり」について詳しく解説します。DAUからの総GPU時間と同時リクエスト数の算出方法、KVキャッシュの計算方法、そして実際の負荷試験の実施手順と測定項目について学びましょう。

GPUプロビジョニングプロセスは単なる技術的な計算ではなく、ビジネス要件とユーザー体験を満たすための戦略的なアプローチです。適切なGPUリソースを確保することで、コスト効率の良い安定したLLMサービスの提供が可能になります。

それでは次回またお会いしましょう!

Read more

GPUを使った分散処理で見落としがちなCPUボトルネックとtasksetによる解決法

GPUを使った分散処理で見落としがちなCPUボトルネックとtasksetによる解決法

こんにちは! 複数枚のGPUをつかった並列処理システムを設計しているときCPUについてはあまり考えないでシステムを設計してしまうことがあります。 「機械学習システムの主役はGPUなんだから、CPUなんて、あんまり気にしなくてよいのでは」 いいえ、そうでもないんです。 推論中のあるタイミングに急に動作が遅くなったりするときCPUが原因であることがけっこうあります。 概要(5分で分かる要点) 先日GPUを使った並列処理システムで、予期しないCPUボトルネックが発生し、パフォーマンスが大幅に低下する問題に遭遇しました。 複数のプロセスが異なるGPUを使用しているにも関わらず、処理が極端に遅くなる現象の原因は、処理パイプラインの一部に含まれるCPU集約的な計算処理でした。 問題の症状 * 単一プロセス実行時:正常な速度 * 複数プロセス並列実行時:処理時間が数倍に増加 * GPUリソースに競合なし(nvidia-smiで確認済み) 根本原因 処理パイプラインにGPUに適さないCPU集約的な計算(データ前処理、統計変換など)が含まれており、複数プロセスが同じCP

By Qualiteg プロダクト開発部
Model Context Protocol完全実装ガイド 2025- 仕様変遷から最新Streamable HTTPまでの全て

Model Context Protocol完全実装ガイド 2025- 仕様変遷から最新Streamable HTTPまでの全て

こんにちは! 現在、LLM業界で破竹の勢いでひろまっているMCPについて、本日はとくに実装面について解説していきたいとおもいます。 MCP、MCPとひとくちにいっていますが、実は短期間でけっこう「標準」とよばれる仕様が変化しておりますので、仕様のバリエーションを順を追って解説しつつ、実際に実装をしていきたいとおもいます。 さて、MCPですが、2024年後半、Anthropicが発表したModel Context Protocol(MCP)は、AI分野における重要な転換点となりました。 従来、各AIベンダーが独自に実装していたツール呼び出し機能(tool useと呼びます)を標準化し、AIモデルと外部システムの連携を統一的に扱える仕組みを提供しました 本記事で、MCPの誕生から現在に至るまでの技術的変遷を詳細に追いながら、2025年時点での最適な実装方法を完全なソースコードと共に解説します。特に、仕様の変化に振り回されがちな実装者の視点から、なぜ現在の形に収束したのか、そして今後どのような実装アプローチを取るべきかを明確にしていきます。 第1章 MCPが解決しようとした問題

By Qualiteg プロダクト開発部
【出展報告】ASCII STARTUP TechDay 2025

【出展報告】ASCII STARTUP TechDay 2025

こんにちは! 本日、「ASCII STARTUP TechDay 2025」に出展してまいりましたのでレポートさせていただきます! ASCII STARTUP TechDay 2025 ASCII STARTUP TechDay 2025は、2025年11月17日(月)に東京・浅草橋ヒューリックホール&カンファレンスで開催された、ディープテック・スタートアップのエコシステム構築をテーマにした展示交流・カンファレンスイベントです。 秋の展示会は本当にいいですね 本日はとてもよいお天気で、涼しくて、展示会にはピッタリの気候で朝からルンルンでした。しかも午後からの展示会ということで、気持ちに余裕をもって朝の業務をこなしていたところ、けっこうすぐに昼前になり、あわてて現場へ。 浅草橋は当社からもわりと近いという立地の良さを甘く見ておりましたが💦、なんとか予定時刻前に到着しました。やっぱり、都心開催は本当にありがたいですね。 会場へ急いでいると、おなかが「ぐ~」と鳴り 「そういえば、朝食まだだったわ」 とおもったところに、なんと私の大好きなエッセンさん🍞のトラックがあるで

By Qualiteg ビジネス開発本部 | マーケティング部
サブスクビジネス完全攻略 第1回~『アープがさぁ...』『チャーンがさぁ...』にもう困らない完全ガイド

サブスクビジネス完全攻略 第1回~『アープがさぁ...』『チャーンがさぁ...』にもう困らない完全ガイド

なぜサブスクリプションモデルが世界を変えているのか、でもAI台頭でSaaSは終わってしまうの? こんにちは! Qualitegコンサルティングです! 新規事業戦略コンサルタントとして日々クライアントと向き合う中で、ここ最近特に増えているのがSaaSビジネスに関する相談です。興味深いのは、その背景にある動機の多様性です。純粋に収益モデルを改善したい企業もあれば、 「SaaS化を通じて、うちもデジタルネイティブ企業として見られたい」 という願望を持つ伝統的な大企業も少なくありません。 SaaSという言葉が日本のビジネスシーンに本格的に浸透し始めたのは2010年代前半。それから約15年が経ち、今やSaaSは「先進的な企業の証」のように扱われています。 まず SaaSは「サーズ」と読みます。 (「サース」でも間違ではありません、どっちもアリです) ほかにも、 MRR、ARR、アープ、チャーンレート、NRR、Rule of 40…… こうした横文字が飛び交う経営会議に、戸惑いながらも「乗り遅れてはいけない」と焦る新規事業担当者の姿をよく目にします。 しかし一方で、2024

By Qualiteg コンサルティング