[ChatStream] 生成と初期化

[ChatStream] 生成と初期化

こんにちは (株)Qualiteg プロダクト開発本部です!

本稿では、 ChatStream の生成と初期化についてご説明いたします!

ChatStream クラスは ChatStream パッケージのコアとなるクラスで、FastAPI/Starlette の Request を受け取り、
負荷制御をしながらストリーミングレスポンスをクライアントに送出する役割をもっています。

以下のように model,tokenizer,device, 最大同時処理数 num_of_concurrent_executions 、待ち行列の最大数 max_queue_size ,プロンプトクラス ChatPrompt を指定して初期化します

tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForCausalLM.from_pretrained(model_path, torch_dtype=torch.float16)
model.to(device)

chat_stream = ChatStream(
    num_of_concurrent_executions=2,
    max_queue_size=5,
    model=model,
    tokenizer=tokenizer,
    device=device,
    chat_prompt_clazz=ChatPrompt,
)

オプション一覧

ChatStream の初期化オプション(コンストラクタ引数)一覧

パラメータ名 説明
model HuggingFace形式の事前学習済み言語モデル。
tokenizer HuggingFace形式のトークナイザ。
device 実行デバイス。"cpu" / "cuda" / "mps"から選択。
num_of_concurrent_executions 事前学習済み言語モデルにおける文章生成タスクの同時実行数。デフォルトは2。
max_queue_size 事前学習済み言語モデルにおける文章生成タスクの最大キューサイズ。デフォルトは5。
too_many_request_as_http_error 'Too many requests'の状況が発生した場合、ステータスを429として返すかどうか。デフォルトはFalse。
use_mock_response テストのための固定フレーズを返すかどうか。モデルを読み込む必要がないため、すぐに起動する。デフォルトはFalse。
mock_params use_mock_response=Trueの時に返すフレーズのタイプ "round" / "long"。デフォルトは{"type": "round"}。
chat_prompt_clazz 言語モデルに送られるプロンプトを管理するクラス。AbstractChatPromptから継承し、各モデルのエチケットに従ったチャットプロンプトを生成するクラスを実装する。
max_new_tokens 新たに生成されるトークンの最大サイズ。デフォルトは256。
context_len コンテキストのサイズ(トークン数)。デフォルトは1024。
temperature 予測におけるランダム性の温度値。デフォルトは1.0。
top_k サンプリングのためのtop Kの値。デフォルトは50。
top_p サンプリングのためのtop Pの値。デフォルトは1.0。
repetition_penalty 繰り返しのペナルティ。デフォルトはNone。
repetition_penalty_method 繰り返しのペナルティの計算方法。デフォルトは"multiplicative"。
add_special_tokens トークナイザのオプション。デフォルトはNone。
request_handler リクエストハンドラ。デフォルトでは、セッションを簡単に保持するハンドラがデフォルト。
logger ロギングオブジェクト。デフォルトはNone。

例)

chat_stream = ChatStream(
     model=None,  # HuggingFace形式の事前学習済み言語モデル
     tokenizer=None,  # HuggingFace形式のトークナイザ
     device=None,  # 実行デバイス "cpu" / "cuda" / "mps"
     num_of_concurrent_executions: int = 2,     # 事前学習済み言語モデルにおける文章生成タスクの同時実行数
     max_queue_size: int = 5,     # 事前学習済み言語モデルにおける文章生成タスクの最大キューサイズ
     too_many_request_as_http_error=False,     # 'Too many requests'の状況が発生した場合、ステータスを429として返す
     use_mock_response=False,     # テストのための固定フレーズを返す。モデルを読み込む必要がないため、すぐに起動する
     mock_params={type: "round"},     # use_mock_response=Trueの時に返すフレーズのタイプ "round" / "long"
     chat_prompt_clazz=None,     # 言語モデルに送られるプロンプトを管理するクラスを指定。AbstractChatPromptから継承し、各モデルのエチケットに従ったチャットプロンプトを生成するクラスを実装する
     max_new_tokens=256,  # 新たに生成されるトークンの最大サイズ
     context_len=1024,  # コンテキストのサイズ(トークン数)
     temperature=1.0,  # 予測におけるランダム性の温度値
     top_k=50,  # サンプリングのためのtop Kの値
     top_p=1.0,  # サンプリングのためのtop Pの値
     repetition_penalty=None,  # 繰り返しのペナルティ
     repetition_penalty_method="multiplicative",  # 繰り返しのペナルティの計算方法
     # トークン関連の処理
     add_special_tokens=None,  # トークナイザのオプション
     request_handler=SimpleSessionRequestHandler(),
     # リクエストハンドラ。デフォルトでは、セッションを簡単に保持するハンドラがデフォルト
     logger=None,  # ロギングオブジェクト
)

Read more

LLM推論基盤プロビジョニング講座 第3回 使用モデルの推論時消費メモリ見積もり

LLM推論基盤プロビジョニング講座 第3回 使用モデルの推論時消費メモリ見積もり

こんにちは!前回はLLMサービスへのリクエスト数見積もりについて解説しました。今回は7ステッププロセスの3番目、「使用モデルの推論時消費メモリ見積もり」について詳しく掘り下げていきます。 GPUメモリがリクエスト処理能力を決定する LLMサービス構築において、GPUが同時に処理できるリクエスト数はGPUメモリの消費量によって制約されます。 つまり、利用可能なGPUメモリがどれだけあるかによって、同時に何件のリクエストを処理できるかがほぼ決まります。 では、その具体例として、Llama3 8B(80億パラメータ)モデルをNVIDIA RTX A5000(24GB)にロードするケースを考えてみましょう。 このGPUには24GBのGPUメモリがありますが、すべてをリクエスト処理に使えるわけではありません。最初にモデル自体が一定量のメモリを消費し、残りの領域で実際のリクエスト処理を行います。 GPUメモリ消費の二大要素 GPUの消費メモリ量は主に以下の2つの要素によって決まります 1. モデルのフットプリント LLMをGPUに読み込んだときに最初に消費されるメモリ

By Qualiteg コンサルティング
システムと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 研究部