[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推論基盤プロビジョニング講座 第5回 GPUノード構成から負荷試験までの実践プロセス

LLM推論基盤プロビジョニング講座 第5回 GPUノード構成から負荷試験までの実践プロセス

こんにちは!これまでのLLM推論基盤プロビジョニング講座では、推論速度の定義、リクエスト数見積もり、メモリ消費量計算、推論エンジン選定について詳しく解説してきました。 今回は、残りのステップである「GPUノード構成見積もり」「負荷試験」「トレードオフ検討」について一気に解説し、最後に実際のサーバー構成例をご紹介します。 STEP5:GPUノード構成見積もり GPUメモリから考える同時リクエスト処理能力 LLMサービスを構築する際、どのGPUを何台選ぶかは非常に重要な決断です。今回はLlama 8Bモデルを例に、GPUメモリ容量と同時リクエスト処理能力の関係を見ていきましょう。 GPUメモリの使われ方を理解する ここは復習となりますが、 LLM推論においてGPUメモリは主に2つの用途で消費されます 1. モデル重みデータ: LLMモデル自体を格納するためのメモリ 2. KVキャッシュ: ユーザーとの対話コンテキストを保持するための一時メモリ Llama 8Bを16ビット精度で実行する場合、モデル重みデータは約16GBのメモリを占めます。これは固定的なメモリ消

By Qualiteg コンサルティング
発話音声からリアルなリップシンクを生成する技術 第2回:AIを使ったドリフト補正

発話音声からリアルなリップシンクを生成する技術 第2回:AIを使ったドリフト補正

こんにちは! 前回の記事では、当社のMotionVoxで使用している「リップシンク」技術について、wav2vecを用いた音声特徴量抽出の仕組みを解説しました。音声から正確な口の動きを予測するための基礎技術について理解いただけたかと思います。 今回は、その続編として、リップシンク制作における重要な技術的課題である「累積ドリフト」に焦点を当てます。wav2vecで高精度な音素認識ができても、実際の動画制作では複数の音声セグメントを時系列に配置する際、わずかなタイミング誤差が蓄積して最終的に大きなずれとなる現象が発生します。 本記事では、この累積ドリフトのメカニズムと、機械学習を活用した最新の補正技術について、実際の測定データを交えながら詳しく解説していきます。前回のwav2vecによる特徴抽出と今回のドリフト補正技術を組み合わせることで、MotionVoxがどのように高品質なリップシンクを実現しているのか、その全体像が見えてくるはずです。 累積ドリフトとは何か 基本概念 累積ドリフトとは、個々の音声セグメントが持つ微小なタイミング誤差が、時間の経過とともに蓄積していく現象で

By Qualiteg 研究部
AIエージェント時代の新たな番人「ガーディアンエージェント」とは?

AIエージェント時代の新たな番人「ガーディアンエージェント」とは?

こんにちは!今日は先日ガートナーが発表したガーディアンエージェントについて解説します ガートナーの公式定義 ハイプカーブで有名なガートナーは2025年6月に、ガーディアンエージェントに関する見解を発表しました。ガーディアン・エージェントとは、AIとの安全で信頼できるやりとりを支援するために設計されたAIベースのテクノロジです。 ざっくりいうと、 「AIエージェントが来るよ」と予言したガートナー社は、次は、「ガーディアンエージェントが来るよ」と予言しました。なぜガーディアンエージェントが来るのでしょうか?本稿では、そのあたりを考察していきたいと思います。 なぜ今、AIの「監視役」が必要なのか 2025年、私たちは本格的なAIエージェント時代の入り口に立っています。AIが単なるツールから、自律的に判断し行動する「エージェント」へと進化する中で、新たな課題が浮上しています。 従来のAIとエージェント型AIの違い さて、ガーディアンエージェントが必要になる理由として、生成AI(以後AIと呼びます)の急速な進化があげられます。従来のAIとエージェント型AIの違いを思い出

By Qualiteg コンサルティング
LLM推論基盤プロビジョニング講座 第4回 推論エンジンの選定

LLM推論基盤プロビジョニング講座 第4回 推論エンジンの選定

こんにちは!前回までの講座では、LLMサービス構築に必要なリクエスト数の見積もりや、使用モデルの推論時消費メモリ計算について詳しく解説してきました。今回は7ステッププロセスの4番目、「推論エンジンの選定」について詳しく掘り下げていきます。 推論エンジンとは何か 推論エンジンとは、GPU上でLLMモデルの推論計算(テキスト生成)を効率的に行うために設計された専用のソフトウェアプログラムです。一般的なディープラーニングフレームワーク(PyTorch、TensorFlowなど)でも推論は可能ですが、実運用環境では専用の推論エンジンを使用することで、大幅なパフォーマンス向上とリソース効率化が期待できます。 推論エンジンは単なる実行環境ではなく、様々な最適化技術を実装しています。特定のモデルアーキテクチャに特化した最適化機能を実装したものや、推論速度の高速化に特化したもの、前回解説したKVキャッシュのメモリ効率化機能を備えたものなど、それぞれ特徴が異なります。そのため、自社で採用したLLMモデルや運用環境、要件に合致した推論エンジンを選定することが重要です。 推論エンジン選定のアプロ

By Qualiteg コンサルティング