[ChatStream] Transformer応答をモックする Transformer Mock

[ChatStream] Transformer応答をモックする Transformer Mock

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

本稿では、モックデータの作成方法について説明します! これは正式には「Transformer Mock」と呼ばれている機能のためのもので、実際のLLM出力をレコーディングして再現するためのものです。

なぜこんなことが必要かというと、 LLM アプリのテスト(単体テストなど)で使用します。LLMアプリのテストをするとき、古典的な単体テストでは、入力に対して期待する出力は固定されていることが前提です。

ところがLLMはその特性上、同一の入力に対しても毎回異なる応答を返してきます。そこが生成AIの良いところですが古典的な単体テストをするときには悩んでしまいます。

ここで賢い読者の皆様は、同一の入力に対して、同一の出力を得たいなら、シードを固定すればいいじゃん。とお考えの方もいらっしゃるとおもいますが、シード値を固定して、入力を固定して、各種サンプリングパラメータを固定しても GPUの種類が異なると異なる出力を出してしまう、ということがわかっています。

これでは、GPUを変更したとたんに単体テストが通らなくなって困ってしまうため、それならば、あるGPUに対して入力した値と出力された値をレコーディングしておき、単体テストのときにはそのレコーディングした結果を「再現」することで疑似的にGPUの計算入力と計算結果を模すことができる、というのが本機能の発想となっております。

これにより、単体テストにおいても ChatStream 内コードの多くの部分を通る(1回のテストでのカバレッジがあがる)ため単体テストの信頼性を向上させることができます。

また、大型のモデルの読み込みには何十分もかかることもあり、nightly ビルドでCIしたとしても、本質的じゃない(そこはカバーしなくてよい)部分のために多くの時間をとられてしまうという課題もあり、そういった課題についても本機能によるエミュレーションで大幅に時間短縮することができます。

モックデータの作成方法

モデルを読み込まなくても、モデルと同じ応答を行わせることができる Mock モード(モックモード)について説明します。

Transformer Mockモードとは

事前に Model,Tokenizer への入力と出力のペアを記録し、それを再生することで
実際には Model,Tokenizer が無くても あたかも Model,Tokenizer があるかのように振る舞わせることができます。

このように Model,Tokenizer をエミュレーションするのが Mockモードです

Transformer Mockモードのメリット

  • モデルデータの読み込み時間が無い。
  • 再現性のある出力(AIアシスタントの応答)を得ることができる

ことで、モデルそのもの以外の評価やテストを手軽に用意に行うことができます

Generator Mockとの違い

類似の機能に Generator Mock があります。

Transfromer Mock モードは 実際のModel,Tokenizerの挙動を記録して再現するのにたいして Generator Mock は
入力を受け取った後、ダミーの文章で応答します。 Transformer Mock モードは決められた入力しか受け付けられませんが、Generator Mockはどのような入力でもダミーの文章で応答します。

Generator MockはAPIの挙動確認などで活用できますが、テストコード実行時のカバレッジは Transformer Mockモードに比べるとだいぶ低くなりますので、カバレッジを重視される場合は、Transformer Mockモードの使用がオススメです。

記録と再現

Transformer Mock モードのための記録 ~ Probeモード ~

厳密には Mock,Tokenizer の挙動を再現することを Transformer Mock モードと呼びます。
Mock,Tokenizer の挙動を記録するモードのことを Probe モードと呼びます。

以下のように probe_mode_enabled=True とすることで、 Probeモードが有効になります


chat_stream = ChatStream(
    num_of_concurrent_executions=2,
    max_queue_size=5,
    model=model,
    tokenizer=tokenizer,
    num_gpus=num_gpus,
    device=device,
    chat_prompt_clazz=ChatPrompt,
    add_special_tokens=False,
    max_new_tokens=128,
    context_len=1024,
    temperature=0.7,
    top_k=10,
    client_roles=client_role_free_access,
    locale='ja',
    token_sampler=TokenSamplerIsok(),
    seed=42,
    probe_mode_enabled=True,
)

probe_mode_enabled=True な状態で ChatStreamサーバーを起動し、UIからテキストの入力を行い
応答を生成します。このように普通にチャットを行うだけでその入力、応答が自動的に記録されます。

記録されたデータは以下ディレクトリに保存されます

 [home_dir]/.cache/chatstream/probe_data 

Transformer Mock モードで Model,Tokenizer をエミュレーション

MockTransformer をつかうと、記録されたデータをつかって Model,Tokenizer をエミュレーションすることができます

MockTransformer(parent_dir_path=[親ディレクトリ], dirname=[記録されたデータの保存されたディレクトリ名],
                wait_sec=[1トークン生成するたびに設定するウェイト(秒)])

[親ディレクトリ]を省略した場合は

 [home_dir]/.cache/chatstream/probe_data 

がディレクトリとして適用されます。

サンプルコード


mock_transformer = MockTransformer(parent_dir_path=mock_data_dir, dirname=mock_data_name, wait_sec=0)

model = mock_transformer.get_model() # model
tokenizer = mock_transformer.get_tokenizer() # tokenizer
token_sampler = mock_transformer.get_token_sampler() # サンプリングクラス

if device.type == 'cuda' and num_gpus == 1:
    model.to(device)

chat_stream = ChatStream(
    num_of_concurrent_executions=2,
    max_queue_size=5,
    model=model,
    tokenizer=tokenizer,
    num_gpus=num_gpus,
    device=device,
    chat_prompt_clazz=ChatPrompt,
    add_special_tokens=False,
    max_new_tokens=128,  # The maximum size of the newly generated tokens
    context_len=1024,  # The size of the context (in terms of the number of tokens)
    temperature=0.7,  # The temperature value for randomness in prediction
    top_k=10,  # Value of top K for sampling
    top_p=0.9,  # Value of top P for sampling,
    # repetition_penalty=1.05,
    client_roles=client_role_free_access,
    locale='ja',
    token_sampler=token_sampler,

)

これでChatStreamサーバーを起動するとTransformer Mockモードで動作します

注意

入力できるテキストや順序は、記録したときと同じテキストと順序となります

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