[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エージェントを"事業に載せる"ために【第3回】AI導入を止めないために、実務で先に設計すべきこと

AIエージェントを"事業に載せる"ために【第3回】AI導入を止めないために、実務で先に設計すべきこと

— AI導入を"事業に載せる"ために、いま設計すべきこと(全3回) こんにちは!Qualitegコンサルティングチームです。 今回の「AI導入を“事業に載せる”ために、いま設計すべきこと」シリーズも、いよいよ第3回です。 第1回では、実際のAI導入事故を通じて、AIエージェントのリスクが単なる技術不良ではなく、権限や運用設計の不在から生まれることを見てきました。第2回では、事故が起きたときに責任をどこに置くのか、法務・契約・組織の観点から責任分解の難しさを整理しました。 では、AI導入を止めずに前に進めるためには、実務として何を先に設計しておくべきなのでしょうか。 本記事では、品質保証の転換、人間レビューの限界、海外で進む保険市場の変化も踏まえながら、AIエージェント導入前に設計すべき5つの領域と、経営として先に答えるべき3つの問いを整理します。 1. 品質保証の転換:「AIは自信を持って間違える」を前提にする 従来のソフトウェアの品質保証は、少なくとも同じ入力に対して同じ結果を期待しやすく、仕様・テスト・再現性を軸に品質を確認する考え方に立っていました。 ISACA

By Qualiteg コンサルティング
主要LLMプロバイダーのAPI料金表 — Claude / GPT / Gemini/Grok 【2026年5月13日時点】

主要LLMプロバイダーのAPI料金表 — Claude / GPT / Gemini/Grok 【2026年5月13日時点】

こんにちは、 今回は、主要LLMプロバイダー( Claude / GPT /Gemini/Grok)のAPI料金表  をまとめてみました。(2026年5月13日時点) プロバイダ別 料金一覧 まずは各社の現行ラインナップを縦に並べた一覧をご紹介します。価格はすべて per 1M tokens、円表記は 1ドル=160円換算です。 Anthropic(Claude) モデル Status Context Input Output Cached Input Claude Opus 4.7 Fast Mode Beta(Opus専用) 1M $30.00<br>(¥4,800) $150.00<br>

By Qualiteg プロダクト開発部
コーディングエージェントの現状と未来への展望 【第3回】"書くAI"から"指揮するAI"へ──2026年の開発現場で起きている変化

コーディングエージェントの現状と未来への展望 【第3回】"書くAI"から"指揮するAI"へ──2026年の開発現場で起きている変化

こんにちは! コーディングエージェントシリーズ、ついに最終回です! 2026年に入り、Claude Code、Cursor 3、GitHub Copilot Coding Agentはいずれも、単なるコード補完やチャット型支援を超え、複数エージェントを使った開発ワークフローへ進化しつつあります。本稿では、AIコーディングエージェントの最新動向を、Claude CodeのAuto Memory / Subagents、Cursor 3のAgents Window、GitHub CopilotのCoding Agent、そしてSWE-benchの読み方まで含めて整理します。 第1回では、2025年12月時点で百花繚乱状態にあったAIコーディングエージェントの全体像を俯瞰し、商用からOSSまで20以上のツールを「CLIベース」「IDE統合型」「AI特化IDE型」「自律型」の4つのカテゴリに整理しました。 第2回では、Claude Code・Codex CLI・Aiderを詳細比較したうえで、現在のコーディングエージェントが共通して抱える構造的課題——コンテキストウィンドウの限界、セッ

By Qualiteg コンサルティング
Windows版 Claude Code を irm でインストールして「claude is not recognized」を直すまで

Windows版 Claude Code を irm でインストールして「claude is not recognized」を直すまで

こんにちは! 公式PowerShellインストーラー(irm https://claude.ai/install.ps1 | iex)で Claude Code を入れたのに、claude --version を叩くと「The term 'claude' is not recognized as a name of a cmdlet...」と怒られるときがあります これは Anthropic 公式 GitHub にも報告されている 既知のバグで、インストーラーが PATH の追加を忘れています。実際にインストール作業をやって詰まったので、最短の解決手順をまとめます。 環境 * Windows 11 * PowerShell 7.x(コードは PowerShell

By Qualiteg プロダクト開発部