[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

コーディングエージェントの現状と未来への展望 【第2回】主要ツール比較と構造的課題

コーディングエージェントの現状と未来への展望 【第2回】主要ツール比較と構造的課題

こんにちは! 今回は、コーディングエージェントシリーズ第2回です! 前回の第1回では、2025年12月時点で百花繚乱状態にあるAIコーディングエージェントの全体像を俯瞰しました。 商用サービスからオープンソースまで20以上のツールを紹介し、それらを「CLIベース」「IDE統合型」「AI特化IDE型」「自律型」の4つのカテゴリに分類しました。 また、コーディングエージェントの本質が「LLM+ツール層」のオーケストレーションシステムであること、つまりLLM自体はコード生成と判断のみを担い、実際のファイル保存やコマンド送信はエージェントフレームワーク側が行うという基本アーキテクチャについても解説しました。 さて、今回は、「実際に使い込むと見えてくる課題」にフォーカスします。 正直なところ、どのツールも「すごい!」と感じる瞬間がある一方で、しばらく使っていると「あれ?」と思う場面に遭遇します。 セッションが長くなると急に性能が落ちたり、昨日教えたはずのことを今日は忘れていたり、ベンチマークで高スコアだったはずなのに自社コードではうまくいかなかったり……。 これらは単なる「まだ発

By Qualiteg コンサルティング
LLM学習の現実:GPU選びから学習コストまで徹底解説

LLM学習の現実:GPU選びから学習コストまで徹底解説

こんにちは! なぜOpenAIやAnthropicは世界最高水準のLLMを作れるのに、それに肩を並べる日本発のLLMは存在しないのでしょうか? 技術力の差でしょうか。それとも人材の問題でしょうか。 答えはもっとシンプルです。GPUの枚数とお金です。 今日はそんな 「LLMの学習」にフォーカスをあて、そのリアルについて徹底解説いたします! 1. はじめに 「LLMを自分で学習させてみたい」 そう思ったとき、最初にぶつかる壁がGPUの問題です。 どのGPUを何枚使えばいいのか。クラウドで借りるべきか、オンプレで買うべきか。そもそも個人や小規模チームでLLM学習は現実的なのか。 本記事では、こうした疑問に対して、具体的な数字と事例を交えながら答えていきます。 たとえばLLaMA 2の学習にはA100が2,048枚使われました。DeepSeek-V3は約8億円かかりました。では、あなたの手元のGPUでは何ができるのか。そこを明らかにしていきたいと思います。 対象読者は、LLM学習に興味があるエンジニアや研究者です。PyTorchでモデルを書いたことがある程度の知識を前提とし

By Qualiteg プロダクト開発部, Qualiteg 研究部
今からはじめるClaude Code

今からはじめるClaude Code

こんにちは! 今日は、最近エンジニアの間で話題になっているAIコーディングエージェント「Claude Code」について取り上げます。 AIによるコーディング支援ツールはここ1〜2年で一気に増え、「結局どれを選べばいいのか分からない」と感じている方も多いのではないでしょうか。本記事では、そうした中でClaude Codeを実際に使ってみた所感と、Windows環境での導入・運用の考え方を整理していきます。 AIコーディングツール、どれを使う? 2025年は、AIコーディング支援が一気に“実用品”になり、選択肢が増えすぎて迷いやすい年になりました。 GitHub Copilot、Cursor、Windsurf、Devin、Aider、Cline、OpenHandsなど、商用からオープンソースまで含めると、軽く20種類を超えます。 機能や思想が似ているものも多く、情報を追うだけで疲れてしまう、という方も少なくないと思います。 以前、当社ブログでは「AIコーディングエージェント20選」で全体像を整理しました。 AIコーディングエージェント20選!現状と未来への展望 【第1回】

By Qualiteg プロダクト開発部, Qualiteg コンサルティング
日本語対応 LLMランキング2025 ~ベンチマーク分析レポート~(12月18日版)

日本語対応 LLMランキング2025 ~ベンチマーク分析レポート~(12月18日版)

はじめに 本レポートは、Nejumi Leaderboard 4のベンチマークデータ(2025/12/18版)に基づいて、日本語対応LLMの性能を総合的に分析したものです。 前回は 2025/10/12 版の分析レポートを公開しましたが、たった2か月で劇的な変化がありました! (定期的に最新LLMランキングを更新してまいります。当社のX(旧Twitter)をフォローいただくことで更新情報を受け取り可能です) Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。 本分析では、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。 オープンソースモデルについて Weightがオープンなモデルは場合によっては「オープンソースモデル」、「OSSモデル」と呼ばれますが、モデルによっては「オープンソース」と呼ぶには不十分な場合があるため本稿では、「オープンソースモデル」ではなく「オープンモデル」と表現しています。 ベンチマーク分析について 本レポートは、

By Qualiteg コンサルティング, Qualiteg プロダクト開発部