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

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第3回 クライアントとサーバーのドメイン参加

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第3回 クライアントとサーバーのドメイン参加

こんにちは、今回はシリーズ第3回クライアントとサーバーのドメイン参加について解説いたします! はじめに こんにちは!シリーズ第3回「クライアントとサーバーのドメイン参加」へようこそ。 前回(第2回)では、Active Directoryドメイン環境の構築手順について、ドメインコントローラーのセットアップからDNS設定まで詳しく解説しました。ドメイン環境の「土台」が整ったところで、今回はいよいよ実際にコンピューターをドメインに参加させる手順に進みます。 「ドメインユーザーアカウントを作ったのに、なぜかログインできない」「新しいPCを追加したけど、ドメイン認証が使えない」といった経験はありませんか?実は、Active Directoryの世界では、ユーザーアカウントを作成しただけでは不十分で、そのユーザーが使用するコンピューター自体もドメインに「参加」させる必要があるのです。 本記事では、このドメイン参加について、単なる手順の説明にとどまらず、「なぜドメイン参加が必要なのか」「裏側で何が起きているのか」という本質的な仕組みまで、初心者の方にも分かりやすく解説していきます。Win

By Qualiteg コンサルティング
使い捨てソフトウェア時代の幕開け ― 市場構造の根本的変革と日本企業

使い捨てソフトウェア時代の幕開け ― 市場構造の根本的変革と日本企業

こんにちは、株式会社Qualiteg コンサルティング部門です。 昨今、生成AIの急速な進化により、ソフトウェア開発の在り方が根本から変わりつつあります。2024年にはClaude、GPT-4、Geminiなどの大規模言語モデルがコード生成能力を飛躍的に向上させ、GitHub CopilotやCursor、Windsurf等の開発支援ツールが実際の開発現場で広く活用されるようになりました。さらに、Devin、OpenAI Canvas、Anthropic Claude Codingといった、より高度な自律的コーディング機能を持つAIエージェントも登場しています。 このような技術革新を背景に、当部門では今後のソフトウェア産業の構造変化について詳細な分析を行いました。本シリーズでは、特に注目すべき変化として、従来1000人月規模を要していた企業向けSaaSプラットフォームや、基幹システムが、AIエージェントを効果的に活用することで、わずか2-3名のチームが数日から数週間で実装可能になるという、開発生産性の劇的な向上について考察してまいります。 これは単なる効率化ではなく、ソフトウェア

By Qualiteg コンサルティング
NVIDIA GeForce RTX 50xx with CUDA capability sm_120 is not compatible with the current PyTorch installation. が発生したとき

NVIDIA GeForce RTX 50xx with CUDA capability sm_120 is not compatible with the current PyTorch installation. が発生したとき

こんにちは、PyTorch 2.6.0 環境で以下のような問題が発生したときの対処方法について解説いたします。 NVIDIA GeForce RTX 5090 with CUDA capability sm_120 is not compatible with the current PyTorch installation. The current PyTorch install supports CUDA capabilities sm_50 sm_60 sm_70 sm_75 sm_80 sm_86 sm_90. 他のBlackwell GeForce の場合は以下のようなメッセージとなります。 NVIDIA GeForce RTX

By Qualiteg プロダクト開発部
OpenCV cv2.imwrite で発生する「_img.empty()」エラーと「動画安定化」による解決法

OpenCV cv2.imwrite で発生する「_img.empty()」エラーと「動画安定化」による解決法

こんにちは! 画像処理や動画解析の現場で広く利用されている OpenCV。 しかし実務で動画処理を行っていると、時折以下のようなエラーに遭遇することがあります。 cv2.error: OpenCV(4.11.0) /io/opencv/modules/imgcodecs/src/loadsave.cpp:929: error: (-215:Assertion failed) !_img.empty() in function 'imwrite' このエラーは、cv2.imwrite() に渡された画像が空(None またはサイズ0) の場合に発生します。 一見単純に見える問題ですが、背後には「入力動画の不安定さ」や「並列処理の競合」といった要因が潜んでいることが少なくありません。 本記事では、このエラーの発生原因を掘り下げ、実務で効果のある解決策として 「動画の安定化(正規化)」 を紹介します。 TL;

By Qualiteg プロダクト開発部