[ChatStream] 同時リクエスト時の推論速度を手軽に計測する

[ChatStream] 同時リクエスト時の推論速度を手軽に計測する

こんにちは、Qualitegプロダクト開発部です。

今回は RakutenAI-7B-Chat に5人同時リクエストしたときのパフォーマンスをお手軽に計測してみました。

実験環境

  • GPU: A5000
  • LLM: RakutenAI-7B-Chat AWQ-8
  • 推論環境: ChatStream v0.7.2
  • 同時リクエスト数: 5

動画のほうがわかりやすいとおもいますので、実際の実験の様子はこちらの動画をつくりました。ご覧くださいませ

動画にもありますように、ChatStreamUIのマルチタスク機能を有効にすると、同一画面内に複数のチャットウィンドウを開くことができます。

マルチタスク機能は、複数のLLMを連携させて業務をすすめていく為の機能ですが、今回は、この特長を利用して、同じモデルに対して同時に生成リクエストを投げる用途で使ってみました。以前も、この機能をつかった簡易計測をご紹介したのですが、今回は、入力プロンプトの同期機能を使用したので、より簡単に実施できました。
(1つのテキストボックスに入力プロンプトを入力すると、他のテキストボックスも連動します)

さて、結果ですが、動画にあるとおり、5人同時リクエストで70 tokens/sec 程度の推論速度がでました。

ChatStreamUIの仕様上、ウィンドウが狭くなることを気にしなくてよいなら同時リクエスト数(concurrency)はいくらでも増やすことができるので、推論速度の負荷テストも簡単にできる、、、とよいのですが、実際にはブラウザには1つのオリジンに同時に張れるセッションの数が限られている為、20や30といった同時リクエストはブラウザの仕様的に不可能となります。

本番向けに同時20件、同時30件、同時100件といった負荷テストは行うときは、当社の開発するLLMサービス専用負荷テストツールLLMLoadもおすすめですので、そちらは別途記事にしたいとおもいます。

[参考]1リクエストの場合

1リクエストのみの場合の実験はこちらの動画にあります。

1人同時リクエストで推論速度は 75 tokens/s ということで、5人同時リクエストのときよりやや速かったですが、逆にいえば、5人同時リクエストていどでは、ほとんどスループットは落ちないということがわかりました。

Read more

ゼロから作るコーディングエージェント【第2回】完了は「作った」ではなく「動いた」で決める。完了の門と、押し戻しに書くこと

ゼロから作るコーディングエージェント【第2回】完了は「作った」ではなく「動いた」で決める。完了の門と、押し戻しに書くこと

モデルの「完了しました」は5つの形ですり抜けました。構文検査だけ、テストは通るが動かない、待ち受けは立つが最初の要求で落ちる、起動するが仕様のAPIが無い、assertの無いテスト。完了の門を3段で閉じる設計と、押し戻しに「落ちた行と調べ方」を書いて「答え」を書かない理由を、数字つきで書きます。

By Qualiteg プロダクト開発部
「Blackwell」は 1 つではなかった。NVIDIA の Compute Capability 番号のわかりにくさを整理する

「Blackwell」は 1 つではなかった。NVIDIA の Compute Capability 番号のわかりにくさを整理する

こんにちは! NVIDIA の GPU を扱っていると、sm_120 や sm_100 といった番号を見かけます。Compute Capability と呼ばれる番号です。 この番号、製品の世代名と対応しているように見えて、実はずれています。 きっかけは、2026年9月23日に公開された TensorRT-LLM の v1.3.0rc28 でした。リリースノートに「SM107」という記述があります。次世代の Rubin に対応した、という文脈です。 ここで引っかかります。Blackwell の GeForce は sm_120 です。次の世代の Rubin が、なぜ 107 という小さい番号なのでしょうか。 調べてみると、引っかかりの原因は Rubin ではありませんでした。

By Qualiteg プロダクト開発部