GPUサーバーの最適容量計算: キューイング理論と実践的モデル

GPUサーバーの最適容量計算: キューイング理論と実践的モデル

こんにちは!

当社では、AIを使用した動画変換や動画生成サービスを展開しておりますが、このようなサービスは推論過程(つまり、動画生成をするときの計算処理)でもGPUに高負荷の計算を行わせる必要があります。

その為、GPUが動画を生成している過程ではユーザーは生成結果を待つことになります。特に画像や動画生成には膨大な計算処理が発生するため、待ち時間も長くなり、従来のSAASのように一瞬で応答という体験は難しく、長ければ数十秒~数分、数十分と待ち時間が発生する場合があります。

このようなサーバーシステムを設計する際、「1つのサーバーで、いや、1つのGPUで何人のユーザーをサポートできるのか?」という問いは常に重要です。

特に、同時に1件しか処理できない変換サーバーなど、制約のあるシステムでは正確な容量計算が不可欠です。

本記事では、キューイング理論に基づいてこのような変換サーバーの最適ユーザー数を計算する方法を解説いたします。また、実用的な計算ツールもご紹介します。

問題設定

では、シンプルな問題設定をしてみましょう

  • 同時に1件の変換しか処理できないサーバーがある
  • 1件の変換に平均5分かかる
  • ユーザーは不規則にサービスにアクセスする
  • ピーク時間にはアクセスが集中する

この状況で、快適なサービスを提供するには1台のサーバーで何人のユーザーまでサポートすべきでしょうか?

キューイング理論の基礎

この問題はキューイング理論(待ち行列理論)で解くことができます。

キューイング理論は、限られたリソースに対する需要が重なった場合の待ち行列の振る舞いを数学的に分析する理論です。

サーバーが1台で、到着がポアソン分布、サービス時間が指数分布に従うと仮定すると、これはM/M/1モデルと呼ばれるシステムになります。

計算モデルの導出

まず、基本的なパラメータを定義しましょう

  • t_p: 処理時間(分/件)
    変換サーバーが1件の処理リクエストを完了するのにかかる平均時間です。例えば、ファイル変換ならファイルの読み込み、処理、出力までの全工程を含みます。この値が小さいほど、サーバーの処理能力は高くなります。例:5分/件
  • μ (mu): サービス率(件/時間)= 60分 ÷ t_p
    1時間あたりに処理できる最大リクエスト数を表します。1時間(60分)を1件あたりの処理時間(t_p)で割ることで算出されます。例えば処理時間が5分なら、μ = 60分 ÷ 5分 = 12件/時間となります。これはサーバーの理論上の最大処理能力です。
  • ρ (rho): 目標システム利用率
    サーバーの稼働率の目標値で、0〜1の値をとります。キューイング理論によれば、安定した運用のためには0.7〜0.8程度に設定することが推奨されます。ρが1に近づくと待ち行列が急速に増加し、ユーザー体験が悪化します。例:0.8(80%の稼働率)
  • P_c: ピーク係数
    平均的なアクセス時間帯と比較して、最も混雑する時間帯のアクセス数の比率です。例えば、P_c = 2.5は、ピーク時のアクセス量が平均の2.5倍になることを意味します。この値は過去のアクセスログから算出するか、類似システムの実績から見積もります。
  • H: 稼働時間(時間/日)
    システムが1日に稼働している時間の合計です。24時間365日稼働のシステムなら24時間、業務時間内のみ利用可能なシステムなら、例えば8-20時の12時間などとなります。
  • P_a: アクセス確率(1日あたりの利用確率)
    登録ユーザー1人が1日のうちにシステムを利用する確率です。例えば、P_a = 0.3は、各ユーザーが30%の確率で1日にシステムを利用することを意味します。全ユーザーが毎日利用するシステムならP_a = 1となります。
  • F: 1ユーザーあたりの1日の変換回数
    ユーザーがシステムを利用する日に、平均して実行する変換処理の回数です。例えば、F = 2は、システムを利用する日には平均して2回の変換処理を行うことを意味します。ユーザーの利用パターンによって変わる値です。

キューイング理論によれば、システムが安定するためには利用率ρが1未満である必要があります。実際には、待ち時間を合理的な範囲に抑えるために、ρ = 0.7〜0.8程度に設定することが推奨されます。

計算手順

1台のサーバーでサポート可能な総ユーザー数

N = R ÷ r_u

1ユーザーあたりの1日の平均リクエスト数

r_u = P_a × F

1日の総処理可能リクエスト数

R = λ_a × H

ピーク時も安定稼働させるための平均到着率

λ_a = λ_s ÷ P_c

安定稼働時の平均到着率

λ_s = ρ × μ

サービス率の計算

μ = 60 ÷ t_p

これらをまとめると、最終計算式は以下になりますね!

N = (ρ × μ × H) ÷ (P_a × F × P_c)

この式に基づいて、サーバー1台でサポートできる最適ユーザー数を計算できます。

さて、自分で計算するのも面倒なので、ツールをご準備いたしました♪

最適ユーザー数計算ツール

以下のツールを使って、サーバーの最適ユーザー数を簡単に計算できます。各パラメータを調整すると、サポート可能なユーザー数がリアルタイムで更新されます。

GPUサーバーにぶるさがるユーザー数計算ツール

最大ユーザーサポート数計算ツール

同時に1件のみ処理できるGPU変換サーバーの最大ユーザーサポート数を計算します

分/件
1件の変換処理にかかる時間
0 〜 1
安定稼働のための目標稼働率(推奨: 0.7〜0.8)
最も混雑する時間帯の平均アクセス倍率
時間/日
システムが1日に稼働している総時間
0 〜 1
1人のユーザーが1日にシステムを利用する確率
回/日
利用する日の平均変換処理回数

実際の運用上の考慮事項

上記ツールは理解促進のためシンプルな条件設定と計算モデルを使用しておりますが、実際のシステム運用では以下のような追加要素も考慮する必要があります

1. ピーク時間の分析

実際のアクセスパターンを収集・分析することで、より正確なピーク係数を把握できます。例えば、システムログを分析して時間帯別のアクセス分布を作成し、平均値との比率を求めることでピーク係数を算出できます。

2. 処理時間のばらつき

実際の処理時間は一定ではなく、変動します。変換内容によって処理時間が大きく異なる場合は、平均処理時間だけでなく、最大処理時間や処理時間の分散も考慮することが重要です。

3. アクセス確率の見直し

ユーザーのアクセス頻度は時間帯や曜日、季節、サービスのバズり度合いによっても変化します。長期的なデータ収集を通じて、より正確なアクセス確率を見積もることで、計算精度を向上させることができます。

4. ユーザー体験の考慮

サーバー容量を計算する際、技術的な限界だけでなく、ユーザー体験も重要です。例えば、待ち時間が長くなりすぎないよう、余裕を持った設計が必要です。目標システム利用率を0.7程度に設定するのはこのためです。

パラメータの自動最適化:機械学習の活用

上記の考慮事項をベースに、実際のサービス運用データを活用して継続的に最適化していくことが理想的です。

さてさて、最適化といえば、当社も得意な機械学習の出番です。

データ収集とモニタリング

最適な容量計算のために、以下のようなデータを継続的に収集します

  • アクセスログ: 時間帯別、曜日別、季節別のアクセスパターン
  • 処理時間ログ: 各変換処理の実行時間と処理内容の関係
  • 待ち時間データ: ユーザーがキューに入ってから処理開始までの待機時間
  • ユーザー行動データ: キャンセル率、リトライ率、利用頻度など

機械学習によるパラメータ最適化

収集したデータを基に、以下のパラメータを機械学習モデルで自動的に更新・最適化できます

  1. ピーク係数の動的予測
    • 時系列分析(ARIMA, Prophet)を用いて、曜日や季節に応じた将来のピーク係数を予測します
      ・ARIMAは、Auto-Regressive Integrated Moving Average(自己回帰和分移動平均)の略で、時系列データの予測に広く使われる統計モデルです。
      ・Prophetは、Facebookが開発した時系列予測ツールで、大規模なデータに対しても効率的に予測を行えます。
    • 特別なイベントやプロモーション時、意図しないバズりなど異常値(スパイク)検出と自動調整
  2. 処理時間の予測モデル
    • 変換内容の特徴(動画種類、ファイルサイズなど)から処理時間を予測する回帰モデル
    • ユーザー別、コンテンツ別などの軸での処理時間傾向の学習
  3. アクセス確率の個別化
    • ユーザーのセグメンテーションによる細分化されたアクセス確率モデル
    • ユーザーの行動履歴に基づいた予測モデルの構築
  4. 最適システム利用率の自動調整
    • ユーザー満足度と処理効率のバランスを最適化するための強化学習
    • ユーザーのフィードバックデータを活用した利用率の調整

実装アプローチ

あとは機械学習ベースの最適化システムの実装とおなじです。データパイプラインをつくって、各種ログデータを効率的に集約していきます。
ログデータから週次でトレーニングにいれて、上記変数を予測します。予測された変数をもとに1台のGPUサーバーでさばけるユーザー数をより精度高く見積もり、サーバの増強戦略を検討します。ユーザー増加に追いつくようにサーバーを増強していくイメージですね。

こうした変数は実際にサービスを運用していかないとわからないので、本ブログのように最初は経験値をもとに設定しています。

まとめ

変換サーバーの容量計算は、単純に「1時間に何件処理できるか」という計算だけでは不十分で、ユーザーの行動パターン、ピーク時の集中度、システムの安定性などを総合的に考慮する必要があります。

本記事でご紹介した計算モデルは、キューイング理論に基づく1つの実践的なアプローチですが、あり、多くの長時間処理GPUサーバーシステムの容量計画に応用できるとおもいますが、あくまで理論的な見積もりであるため実際のシステム容量を決定する際は、実測データに基づく調整や、パフォーマンステストを併用するのが良いようにおもいます。

Read more

システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

こんにちは! 先日、dlibをつかったPythonアプリケーション(conda環境で動作する)作っていたところ、以下のようなエラーに遭遇しました。 ImportError: /home/mlu/anaconda3/envs/example_env/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /home/mlu/anaconda3/envs/example_env/lib/python3.10/site-packages/_dlib_pybind11.cpython-310-x86_64-linux-gnu.so) 「dlib_pybind11モジュールがGLIBCXX_3.4.32を要求してるけど、みつからない!」という感じのエラーですね。

By Qualiteg プロダクト開発部
LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

こんにちは! 今回はLLM推論基盤プロビジョニング講座 第2回です! STEP2 LLMサービスへのリクエスト数見積もり それでは、早速、LLM推論基盤プロビジョニングの第2ステップである「リクエスト数見積もり」の重要性と方法を解説いたします。 LLMサービスを構築する際に必要となるGPUノード数を適切に見積もるためには、まずサービスに対して想定されるリクエスト数を正確に予測する必要があります。 リクエスト数見積もりの基本的な考え方 LLMサービスへの想定リクエスト数から必要なGPUノード数を算出するプロセスは、サービス設計において非常に重要です。過小評価すればサービス品質が低下し、過大評価すれば無駄なコストが発生します。このバランスを適切に取るための基礎となるのがリクエスト数の見積もりです。 想定リクエスト数の諸元 リクエスト数を見積もるための5つの重要な要素(諸元)をみてみましょう。 1. DAU(Daily Active Users): 1日あたりの実際にサービスを利用するユーザー数です。これはサービスの規模を示す最も基本的な指標となります。 2. 1日

By Qualiteg コンサルティング
Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

こんにちは! 本日は、自動フレーミング映像の安定化に関するアルゴリズム・ノウハウを解説いたします 第1章 問題の背景と目的 バストアップ映像を撮影する際、特にオンラインミーティングやYouTubeなどのトーク映像では、人物がうなずく、首を振るなどの自然な動作をした際に「首まわりや肩がフレーム内で上下に移動してしまう」という現象がしばしば起こります。これは、多くの場合カメラや撮影ソフトウェアが人物の「目や顔を画面中央に保とう」とする自動フレーミング機能の働きに起因します。 撮影対象の人物が頭を下げた際に、映像のフレーム全体が相対的に上方向へシフトし、その結果、本来動いていないはずの肩の部分が映像内で持ち上がっているように見えてしまう現象です。 本稿では、この問題を撮影後の後処理(ポストプロセッシング)のみを用いて、高速、高い精度かつロバストに解決する手法をご紹介します。 前半では、従来のCV(コンピュータービジョン)の手法を使い高速に処理する方法をご紹介します。後半では、AIを使用してより安定性の高い性能を実現する方法について考察します。 第2章 古典手法による肩の上下

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

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

こんにちは! 本日は LLMサービスの自社構築する際の推論基盤プロビジョニング、GPUプロビジョニングについて数回にわけて解説いたします。 はじめに LLMの進化に伴い、ChatGPTやClaudeといったパブリックなLLMの活用は企業においても急速に広がってきました。しかし先進的な企業はこれらの汎用LLMに加えて、「領域特化型」「ドメイン特化型」といった専用LLMの構築へと歩みを進めています。こうした動きの背景には、企業固有の専門知識への対応力強化と情報セキュリティの確保という二つの重要なニーズがあります。 一般的なパブリックLLMでは対応できない企業固有の専門知識や機密情報の取り扱いが必要なケースが増えているため、自社LLMの構築や自社サーバーでの運用を検討する企業が急増しています。特に金融、医療、製造、法務といった専門性の高い領域では、業界特化型の独自LLMが競争優位性をもたらすと認識されています。 しかし、業界特化型のLLMを自社で運用することは簡単ではありません。自社運用を決断した場合、まず最初に取り組むべきは適切な推論環境の整備です。オンプレミス環境を構築するに

By Qualiteg コンサルティング