[ChatStream] キューイングシステムと同時処理制限

[ChatStream] キューイングシステムと同時処理制限

こんにちは! (株)Qualiteg プロダクト開発部 です!
本稿では、 ChatStream のキューイングシステムについてご説明いたします!

キューイングシステムとは

ChatStream は多数同時アクセス要求が来たときに、
リクエストをキューイングし、同時に実行できる文章生成の数を制限することができます。

GPU や CPU の性能に応じて、文章生成処理の同時実行数を制限することで、良好な応答性能を得ることができます。

また同時実行数を超えるリクエストがあった場合はリクエストをキューイング(待ち行列に追加)し、
順次実行することで、負荷を適切にコントロールします。

同時実行とは

同時実行とは 1GPU で実行する場合には、正確には同時実行ではなく 並行実行(concurrent) となります。

同時実行数をセットすると、その数だけ 並行実行 されます。

たとえば、同時実行数の最大値が2に設定されている状態で、2人のユーザー1、ユーザー2 が同じタイミングにリクエストしてきた場合
2人のリクエストは 処理キュー (文章生成中をあらわすキュー)に入り1トークンごとに交互に文章を生成 します。
例えば日本語のモデルの場合、1トークンはほぼ1文字に相当しますので、ユーザー1向けの文章に1文字追加したらユーザー2向けの文章に1文字追加します。
これを文章生成が終わるまで繰り返します。

ユーザー3が途中で割り込んできた場合、まだユーザー1とユーザー2の文章は生成されている途中ですので、ユーザーCのリクエストは リクエストキュー (処理待ち行列) に入ります。

ユーザー1またはユーザー2の文章生成が終了すると、 リクエストキュー に入っているユーザー3のリクエストが 処理キュー に入り、
文章生成処理が開始されます。

コラム: 非同期I/O と並行実行

FastAPIは非同期I/Oをサポートしており、これは複数のリクエストを並行に処理する能力があります。
Pythonの非同期I/Oは、コルーチンと呼ばれる特殊な関数を使用して並行性を実現しています。
この場合の並行性とは、一度に一つのタスクだけが進行するが、I/O操作(HTTPリクエスト、モデルからのトークンの生成など)を待つ間に他のタスクを進行させることができる
ということです。この形式を"協調的マルチタスク"を呼びます。
それぞれのリクエストは別の「非同期タスク」として処理され、これらのタスクは同じスレッド上で切り替えられます。
「非同期タスク」においては複数のリクエストに対するモデルへのアクセスが並行しているように見えますが
実際にはある瞬間に一つのリクエストだけがモデルを利用しています
そのため、それぞれのリクエストが モデルによるトークン生成のためにブロックする期間は限られており、
逐次出力トークンの生成について言えば、1つ新トークンを生成した後で他のリクエストに制御を戻すことができます
そのため、一つのリクエストによる文章生成の際、停止トークン、停止文字列が現れるまでの間、
他の全てのリクエストがブロックされることはなく、各リクエストはモデルからのトークンを逐次生成しながら、
他のリクエストも進行させることができます

キューイングの開始

Web アプリケーションの起動時に start_queue_worker を呼ぶことで、キューワーカーを開始できます

キューワーカーを開始すると、リクエスト処理キューが開始され、リクエストをリクエストキューに挿入し、処理キューへと順次実行していくキューイングループが開始されます

chatstream#start_queue_worker


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 コンサルティング