[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

AIエージェントを"事業に載せる"ために【第2回】AIエージェントの責任分解はなぜ難しいのか

AIエージェントを"事業に載せる"ために【第2回】AIエージェントの責任分解はなぜ難しいのか

— AI導入を"事業に載せる"ために、いま設計すべきこと(全3回) こんにちは!Qualitegコンサルティングチームです! 前回(第1回)では、Replit/Lemkin事件とDeloitte豪州政府報告書問題を通じて、AIエージェント導入の課題がモデル性能ではなく「権限・監査・責任の設計不在」にあることを見ました。 では、実際に事故が起きたとき、責任は誰が負うのでしょうか。第2回となる本記事では、法務・契約・組織の3つの観点から、AIエージェントの責任分解がなぜ難しいのかを構造的に整理します。 結論を先に言えば、法務だけでも契約だけでも組織論だけでも足りません。この3つを接続して設計しなければ、AIエージェントの責任分解は実務上機能しません。 1. 法的フレームワーク:複数の法理論が並走している AIエージェントが損害を出したとき、どの法理論で責任が問われるかについて、現時点でグローバルなコンセンサスは形成されていません。 Clifford Chanceの論考は、この状況の根本的な難しさを整理しています。法律は歴史的に、有害な行為がいつどのように発生したかを特定でき

By Qualiteg コンサルティング
AIエージェントを"事業に載せる"ために【第1回】

AIエージェントを"事業に載せる"ために【第1回】

AI導入事故は何を示しているのか — AI導入を"事業に載せる"ために、いま設計すべきこと(全3回) こんにちは!Qualitegコンサルティングチームです! AIエージェントを導入する企業が増える一方で、 「試してみる」段階から「事業に載せる」段階へ進める難しさ が、はっきり見え始めています。 本シリーズでは、AIエージェント導入を技術論だけでなく、責任分解・監査可能性・契約・運用統制を含む業務設計の問題として整理します。 全3回を通じて、「AIが賢いかどうか」ではなく、「AIを業務に載せるために何を設計するか」を考えていきます。 第1回となる本記事では、2025年に起きた2つの事例を出発点に、なぜいま「責任設計」が問題になっているのかを見ていきます。 上図は、本シリーズ全体で扱う論点の全体像です。 AIエージェントの導入は、技術的なモデル選定だけでは完結せず、権限設計、契約、監査、品質監視、保険、異常時対応まで含めた設計が必要になります。 第1回ではまず、なぜこうした設計が求められるようになったのかを、実際の事例から見ていきたいとおもいます なお、本シリー

By Qualiteg コンサルティング
PII検出の混同行列では見えないもの ― 認識器間衝突と統合テスト

PII検出の混同行列では見えないもの ― 認識器間衝突と統合テスト

こんにちは!Qualiteg研究部です! 個人情報(PII: Personally Identifiable Information)の自動検出は、テキスト中から特定の表現を抽出し、それがどの種類のPIIに当たるかを判定する問題として捉えることができます。 電話番号、人名、口座番号、金額表現など、検出対象のPIIタイプが増えるにつれて、単一の手法ではカバーしきれなくなり、性質の異なる複数の認識器(Recognizer)を組み合わせるマルチレイヤー構成が採用されるのが一般的です。 本稿で想定しているのは、ユーザーが海外製LLMにチャットを送信する直前に、その内容に個人情報や機密情報が含まれていないかをリアルタイムに検査するユースケースです。 この場面では、検出精度だけでなく、送信体験を損ねない速度が不可欠です。 高精度なLLMやBERT系モデル、NERベースの手法は有力ですが、送信前チェックの第一層として常時適用するには、レイテンシやコストの面で不利になることがあります。 そのため、本システムでは、正規表現、辞書、軽量なルールベース認識器を組み合わせた超高速な第一層を設け、そ

By Qualiteg 研究部, Qualiteg AIセキュリティチーム
日本語対応 LLMランキング2026 ~ベンチマーク分析レポート~(3月6日版)

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

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

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