LM Warden

GPU 監視:これらの数値を測定したマシン。

キャプションに特記がない限り、このページの読み取り値は一台のワークステーションのものです。RTX A4000 四枚にまたがって一つのモデルを読み込み、自社のテスト トラフィックで負荷をかけています。図 1 と図 5 を記録している間にコンソールに表示されていた数値です。後半の適合テストでは Quadro RTX 5000 も使っており、その旨を記しています。

カードごとのパネルは NVIDIA のドライバーから読み取るので、Linux インストールの機能です。Apple シリコン搭載 Mac では、Mac アプリ (ベータ版) が GPU 使用率と Metal が報告するメモリ上限を表示します。電力は表示されません。

GPU
4 × NVIDIA RTX A4000、各 16 GiB (Ampere、compute 8.6)
使用中の VRAM
64.0 GiB 中 59.4、四枚すべてにまたがって一つのモデルを読み込み
PCIe
カードごとに Gen 4 x16
ドライバー
610.57.04、CUDA 13.3
GPU 負荷、電力、トークン (図 1 から読み取り)
項目キャプチャ時24 h の稼働時の中央値24 h のピーク
GPU 使用率、最も忙しいカード (%)100100100
GPU 電力、四枚の合計 (W)548530559
毎分のトークン数 (9 月 23 日のパネル)表示なし190k880k

数値は環境によって異なります。だからこそ、自分の環境で測定することに意味があります。トークンの行は毎秒トークン数への切り替え前のものです。Stats パネルは現在、毎秒トークン数を表示しており、これらの数値は 9 月 23 日に旧来の毎分パネルでキャプチャしたものです。

測定できない数値は 「not reported」 と表示されます。

ほとんどの GPU ダッシュボードは四枚のカードを平均して一本の線にし、欠けた値を 0 として描きます。このダッシュボードはカードごとに専用のパネルを用意します。ドライバーが報告するスロットリング ポイントに対する温度、そのカード自身の上限に対する電力、クロック、ファン、現在ネゴシエートされている PCIe リンク、カードが備えていれば ECC と NVLink。購入時期が十八か月違う二枚のカードは別々の二枚として扱われ、ドライバーが提供しない値はゼロとして描かれず、欠けていると表示されます。

負荷時の Stats ページにある四つの GPU パネル (RTX A4000 一枚ごとに一つ):電力状態 P2 で使用率 99~100%、温度は 79~94 度で、スロットリング ポイントは 100 度。三枚にサーマル スローダウンの警告、電力は上限 140 W に対して 134~138 W。クロック、ドライバーと CUDA のバージョン、PCIe リンク、NVLink、ECC スロットリング ポイントは推測ではなくドライバーの値 クロックが下がっている理由 (ドライバーの報告どおり) カード自身の上限 140 W に対する電力 NVLink と ECC (カードの報告どおり)
図 5同じ Stats ページの四つの GPU パネルを、同じ負荷の間に原寸でキャプチャしたもの。どのカードも電力状態 P2 で 99% か 100% に達しており、そのうち 90~94 °C の三枚は、ドライバーによって最大クロックの 76~84% に抑えられています。画像を横にスクロールすると四つすべてが見られます。
何をどこで読み取るか
カードごと温度とスロットリング ポイント、電力とその上限、コアとメモリのクロック、ファン、PCIe の世代と幅、ECC、NVLink、そのカードを使っているエンジン プロセス
ホストごと使用中の VRAM、GPU 使用率 (最も忙しいカード)、電力 (カードの合計)、毎秒トークン数
リクエストごと最初のトークンまでの時間、トークン間レイテンシ、所要時間。両エンジンともプロキシで同じ方法で測定

各リクエストが何を待っているか。

Stats ページは、実行中のすべてのリクエストを、クライアントのセッションと、そのリクエストがライフサイクルのどこにいるか (warden でキュー待ち、プリフィル (エンジンがプロンプトを読み込む段階)、思考中、ツール呼び出しの作成中、応答中) とともに一覧表示します。バッジは、プロンプトのうちレプリカのキャッシュにありそうな割合を示します。このマシンが学習したプリフィル速度の予測より長くかかっているプリフィルには、待っていそうな理由が表示されます。同じレプリカ上のほかのプロンプトの後ろにいる、キャッシュがおそらく追い出された、または warden からは原因が見えないまま遅れている、のいずれかです。セッションは各ツールがすでに送っている ID から得ます。Claude Code、Codex、OpenCode、pi はそのままで、Hermes と Aider は一行の設定で対応します。

In flight 表に 14 件のアクティブなリクエスト。すべて一つのクライアント アドレスのキー agent-farm から。列:トークン、クライアント IP、セッション、モデル、フェーズ、コンテキスト ウィンドウ、経過時間。六行がツール呼び出しまたは応答中、八行がプリフィル中で、ほとんどにプロンプトの 94~100% がキャッシュ済みと推定するバッジが付いている。三つのプリフィルに evict? バッジ、二つに砂時計のバッジ 1·r0 と 1·r4。表の下:1132 リクエストから学習したプリフィル モデル 439 tok/s、キャッシュ推定の的中率 57%、アイドル間隔ごとのヒット率は最大 30 秒後で 68%、5~15 分後には 18% に低下。 まだトークンがなく、キャッシュはおそらく追い出し済み レプリカ 4 で一つのプロンプトが先行
図 12GPU 七枚のマシンで実行中の十四件のリクエスト。表の下には、warden が完了したリクエストから学習した内容があります。このマシンはリクエストあたり毎秒約 439 トークンをプリフィルし、キャッシュ推定は 57% の割合で当たり、二分以上アイドルだった会話は通常キャッシュが消えています (2~5 分後のヒット率は 20%)。キー名は代替名で、アドレスはドキュメント用のアドレスです。幅 768 ピクセル未満では表がカードの一覧になります。2026 年 10 月 5 日に記録。画像を横にスクロールするとすべての列が見られます。