Show HN: Utilyze — より高精度な、オープンソースの GPU モニタリングツール「nvtop」に匹敵するパフォーマンスを提供します

「このギャップは意識の問題ではありません。CUDA カーネルを作成するエンジニアたちは、どのような状態が正確な資源利用率を示すかを知っています。問題はツールです。これまで、負荷を遅滞させることなく、本番環境で GPU の真の効率を継続的に可視化する方法は存在していません。」 ——MIT 大学教授兼 Systalyze CEO、Manya Ghobadi

nvtop（上段） は、行列乗算のサイズに関わらず、すべてのワークロードにおいて 100% の値を表示します。Utilyze（下段） は実際の計算処理能力を通じてputhput を追跡し、異なる行列サイズに伴う利用率の劇的な変化を明らかにします。

上記の図に示される通り、nvtop は負荷強度に対して不変です：上段（青色ラインが天井に固定されている）の 3 つの行列乗算サイズすべてで nvtop が 100% を示しています。一方、Utilyze（下段）では計算処理能力のスケーリングが観察され、N=256 で 2.6%、N=1024 で 32%、N=4096 で 88% という利用率の変化が見られます。

Utilyze の正確性を検証するためには、真の計算利用率を直接計算してみましょう：TF32 精度で N×N マトリックスを 2 つ乗算する際に行う浮動小数点演算は 2·N³ です。GPU のクロック速度に H200 の理論的な TF32 ピークレート（494.5 TFLOPS）を掛け合わせ、利用率を計算します。N=256 では、2·256³ ≈ 0.034 GFLOps × 155,349 イテレーション/秒 = 5.2 TFLOPS すなわち 1% の利用率となります。同様の計算から、N=1024 で 32%、N=4096 で 86% の利用率が得られます。これに対し、Utilyze が報告した値は理論的な「正解値」と比べて最大わずか 2% の誤差しかありません。

この直接的な計算は、行列乗算のような単純な計算操作には適用可能ですが、実際の AI ワークロードにおいては実装不可能です。最新のトレーニング、ファインチューニング、および推論パイプラインは、注意力機構、正規化、通信、スパース性、制御フローなど多様な演算子、動的な形状、GPU 全体にわたる複雑なスケジューリング効果を含みます。このような環境下では、第一原理から真の利用率を解析的に導き出すことは現実的ではありません。必要とされるのは、ハードウェアレベルで真の利用率を直接測定する方法です。

Utilyze はまさにこの機能を備えています：GPU ハードウェアのパフォーマンスカウンターを通じて真の計算利用率を直接測定します。Utilyze は別のアプローチ（FLOP 数から誘導する方法）でもほぼ同様の値に達し、その差はわずか 2% です。両者の方法が一致するのは、どちらも同じ物理的な現象——つまり、利用可能な計算能力に対して実行された演算量——を異なる角度から測定しているためです。この相互検証により、Utilyze のハートウェアカウンターに基づくアプローチの精度が確認されます。現在他のどのツールも、実用的なオーバーヘッドをかけずにリアルタイムでこのようなレベルの正確さを提供できるわけではありません。

「クラウドプロバイダーやハードウェアベンダーは、これらのダッシュボード上で同じような誤解を招く指標を示しています。その数字が 100% を示すと、当然ながら「より多くのハードウェアが必要だ」という結論に至ります。この誤認を正すためのインセンティブについては、遠慮を込めて言えば『複雑な事情』があります。」 ——MIT 大学教授兼 Systalyze CEO、Manya Ghobadi

DCGM ベースのカウンターも優れていない

以前の記事でも指摘されている通り、このギャップは NVIDIA の Data Center GPU Manager (DCGM) というツールキットを通じて解決案が提示されています。DCGM は nvidia-smi よりも豊富な GPU カウンター情報を提供します（詳しくはこちらとこちらを参照）。

GPU 利用率の最も一般的なプロキシ指標である DCGM の「SM Active」は、スケジュールされたワープがある SM の数を総 SM 数で割った比率です。これは SM 全体を単一のオン/オフスイッチとして扱うのではなく、GPU 内部での何らかの計算活動を検討するため、nvidia-smi よりも改善されています。しかしながら、SM Active その他 DCGM の指標も同じレベル下の根本的な問題を抱えています：ワープが SM に駐在しているだけでは、その SM が実際の演算を行っているとは限りません。ワープはデータ移動中、メモリからデータを待機中、あるいはずっと書式化などの管理命令を走らせている可能性があります。そのような状態でも SM Active は 100% と表示されてしまいます。Utilyze はまさに「GPU の真の利用率はいかなのか」という問いに答えるために設計されています：ピークの計算スループットの何分の一を実際に提供しているのか。現成のツール、DCGM を含むものは、これを持続的に提供するものではありません。

実証のために H200 でメモリ束縛型のワークロードを nvtop, DCGM, Utilyze の 3 つで実行しました。これはデコード重みの LLM 推論ステップと似た形状のワークロードです。このワークロード条件下では、実際の計算スループットは天井の約 6% に過ぎません：

唯一 Utilyze が正しく測定しています。nvtop はすでに説明した理由で誤りです。SM Active は驚くべき 99% の利用率を示していますが、実際に SM にはワープが常駐し続けています。ただし、それらのワープは計算を行っておりません。データ待機中です。SM Active は「演算中のワープ」と「データ待機中のインデックス待ちワープ」の区別がつきません。SM Active に依存して GPU 利用率を監視すると、GPU が満タンになっているように見せかけながら実際にはただ待機しているという錯覚を与えます。

DCGM も SM issue（命令の発行頻度）、SM occupancy（SM のワープ充填率）、テンソルコアのスループットなどの他の指標を報告しますが、これらが個別または組み合わせても、Utilyze が提供する全体的な像は提供できません。

本番環境で稼働する Utilyze の紹介

Systalyze は、ハードウェアの理論的限界に対する GPU の計算およびメモリバンド幅利用率をパーセンテージで報告するためのオープンソース GPU モニタリングツールとして Utilyze を開発しました。単なる利用効率だけでなく、現在のハードウェア・ソフトウェアスタックと AI ワークロードの下で実質的に達成可能な理論的上限の割合も推定します。Utilyze はほぼゼロのオーバーヘッドでリアルタイムに動作するため、パフォーマンスを乱すことなく継続的な可視性が求められる本番環境にも適合しています。Systalyze 内では Utilyze を使ってパフォーマンス最適化技術のモニタリング、ベンチマーク、検証を行っています。みなさんもぜひご活用ください。

今日から Utilyze をお試しください

Utilyze の動作原理について解説する前に、正確な GPU 利用率測定がなぜ技術的に困難なのかを整理しましょう。GPU には一般浮動小数点数学計算用の CUDA コアと行列乗算を実行するテンソルコアという 2 つの基本的な計算リソースがあります。また、チップ外の高帯域幅メモリの HBM、L2 キャッシュ、各 SM 内の共有メモリ、スレッド固有レジスタなど複数の階層のメモリーも持っています。これら各資源がそれぞれボトルネックとなり得ます。ワークロードはテンソルコアを全能力で使いつつメモリバンド幅はほとんど使用していないか、その逆のパターンもありえます。単一のパーセンテージではこの 2 次元の実態を表現できません。

その結果、GPU 上のすべての AI 操作は 2 つの物理的な上限に束縛されます：計算単位が演算を実行する速さ（計算スループット）、およびメモリーと計算単位間のデータ移動速度（メモリバンド幅）。すべてのカーネルはこのうちどちらかの上限に最初に達し、それがその最大性能を決定します。

GPU 利用率を正確に捉えるためのフレームワークとは何かといえば、「光速モデル (SOL)」です。これはカーネルが GPU の理論的なハードウェアの天井に近い程度を測定し、2 つの数値を報告するパフォーマンスフレームワークです：Compute SOL % (= 達成 FLOPs ÷ ピーク FLOPs) と Memory SOL % (= 達成帯域幅 ÷ ピーク帯域幅)。これはルーフラインモデルに由来しており、すべてのカーネルは計算かメモリのどちらかで束縛され、2 つの SOL パーセンテージのうち高い方が束縛となるリソースを示します。

Utilyze はまさにこの機能を提供し、2 つの見出し数字である Compute SOL % と Memory SOL % をリアルタイムで表示します。分子は各計算エンジン（テンソルコア、FP32/FP64/INT32 パイプライン等）およびメモリスブシステム（HBM 帯域幅、L2、L1 等）を NVIDIA が提供するハードウェア単位の理論的最大値のパーセンテージとして直接測定することで得られます。分母は SOL そのものであり、ハードウェア上のピークです。これらが結合することで、他のどのツールも提供できない正確でリアルタイムな GPU 利用率の視覚化が可能になります。もし計算数のみが支配的ならワークロードは計算束縛型です。メモリーの数が支配的ならメモリー束縛型であり、最適化ではまずデータ移動をターゲットにすべきです。

しかし話はここで終わるわけではありません。単独の生の SOL % では伝えきれない重要な点はあります：100% は現実的な目標ではありません。

H100 における 2,000 TFLOPS の計算と 3.4 TB/s のメモリバンド幅という理論上のハードウェアピークは、いかなる実際の AI ワークロードも到達できない物理的限界です。カーネル起動にはオーバーヘッドが発生します。データはメモリの階層間を移動します。スレッド同期にはサイクルが消費されます。マルチ GPU セットアップでは GPU 間の通信に時間が消耗し、本来計算に使える時間を奪います。Mixture-of-Experts モデルでは、トークンを異なるエキスパートへルーティングすることで不規則なメモリアクセスパターンが生じ、実効的なスループットが低下します。これらはすべて不良な最適化の兆候ではなく、実用上のデプロイメントの構造的性質です。

すべてのデプロイメントにはモデルアーキテクチャ、ハードウェア、並列化戦略、バッチサイズなどの組み合わせに起因する 100% を下回る自然な天井があります。これをAttainable Compute SOL %（以下 Attainable SOL % と略記）と呼びます。現在の SOL % と Attainable SOL % の間のギャップがあなたの最適化予算です。Attainable SOL % と 100% の間のギャップはデプロイメントの物理法則であり、チューニングでは閉じることはできません。

例えば、30% の Compute SOL % で 120B パラメータの推論を実行している場合で、そのハードウェア上の Attainable SOL % が 35% なら限界に近いと言えます。逆に Attainable SOL % が 65% で現在が 30% の場合、回復可能なパフォーマンスは 35 パーセントポイントあり、ここで最適化を行うのが正しい選択であり、ハードウェア調達ではありません。

なぜ Utilyze は他と違うのか

パフォーマンスエンジニアは AI ワークロードのパフォーマンス問題のデバッグに主に 2 つのツールの使用に頼ります。第一がNsight Compute (ncu) で、カーネルレベルのプロファイラーとしてテンソルコアの理論スループットの達成率やメモリスバスの飽和度合い、ボトルネックの位置など詳細な計算およびメモリスループット指標を報告します。第二がNsight Systems (nsys) で、カーネルの実行タイミングと相互関係を記録するタイムラインツールです。両者ともオフライン分析向けに構築されており、リアルタイムダッシュボードには不向きです。ncu は各カーネルを「再生」することで詳細を得ており、異なるカウンターを選択して複数回実行し結果を組み合わせます。これは価値ある成果ですが、オーバーヘッドが大きくワークロードを通常の 10～100 倍に遅らせてしまい、ライブトラフィックへの適用は不可能になります。nsys は slowdown を回避しますがスループット指標の報告はなく、「何が起きたか」ではなく「どの効率的さで起きたか」しか答えません。

実用的な結果として、ncu（あるいは AMD 版 Omniperf）を日常的に使いこなすベテランエンジニアたちはこれらをオフラインでのカーネル単位デバッグに利用しており、ライブトラフィックの監視には使っていません。この課題に対応するために Utilyze は NVIDIA の Nsight Perf SDK を使用し、時間窓を通じて GPU パフォーマンスカウンターをスキャンします。カーネルの再生ではなく、複数のウィンドウにわたるローリングサンプルを採取し結果を統合することで、オーバーヘッドは微小であり測定も連続的です。Utilyze を任意の本番 AI ワークロードと並行して実行し、リアルタイムで意味のあるデータを取得できます。

Utilyze のベンチマーク

以下は、Utilyze を活用して実際の AI ワークロードのパフォーマンスボトルネックを特定する方法を示すいくつかの例です。

ケース 1：プリフィル重みの LLM 推論

まず推論ワークロードから始めましょう：vLLM 0.19 で 2xH200 GPU にて動作する Llama-3.1-8B モデルです。入力シーケンス長さ (ISL) 8192、出力シーケンス長さ (OSL) 64、並列度 20 のプリフィル重みワークロードをまず使用します。以下の図はがこのワークロード実行中の Utilyze の出力を示しています。

Utilyze は、このワークロードの Compute SOL % メトリックによると、これらの GPU が理論的 максимум の約 45% で稼働していることを示しています。メモリの SOL % メトリックが計算 SOL より低いことは、このワークロードとモデルがメモリバンド束縛ではなく計算束縛であることを示しています。これは、メモリー束縛であることが多いデコード重みの推論ワークロードと比較する際に有用です。Utilyze はこのワークロードおよびモデル固有の上限利用率すなわち Attainable SOL % を 89% と見積もっています。この値はモデル、GPU、ワークロードに依存しており、特定のモデルやワークロードには固有的な性質が存在し、Attainable SOL % が変動します。Attainable SOL % と Compute SOL % の差は、GPU が現在未利用であることを示しています。

これを nvtop と比較してみましょう：

• nvtop の利用率 は常に 100% を示しています。このメトリックを利用率の指標として読むと、GPU が完全に飽和しており最適化の余地がないという誤信息进行得ます。Utilyze はこの認識が誤りであることを示します。

次に Systalyze の最適化を適用し同じベンチマークを実行してみましょう： 上記の図では新しい Compute SOL % ラインが Attainable SOL % に達しており、このモデルに対して GPU を可能な限り接近させることが達成されたことを意味します。スループット数字はこの利用率の向上に対応しています。最適化前のトータルトークンスループットは 52,298 トークン/秒で、最適化後には 73,903 トークン/秒となり、40% の増加です。

ケース 2：デコード重みの LLM 推論

Utilyze の GPU 利用率数字をデコード重みの推論において解釈するには、背後にあるメカニズムのより深い理解が必要です。いくつかの異なるシナリオを通じ、Utilyze が GPU 内部で実際に何が起こっているかを理解するのを支援する方法について解説します。

同じモデルを未最適化状態とし、デコード重みワークロード (ISL = 1024, OSL = 4096, 並列度 = 2) で始めましょう： 上記の図ではメモリの SOL % が計算 SOL % より顕著に高く、このワークロードがメモリバンド束縛であることを示しています。デコード重みの LLM ワークロードはしばしばメモリー束縛型であり、計算束縛型ではありません（参照）。これは、バッチごとのトークン解読のために、ユーザークエリ全体のモデル重量と KV キャッシュを HBM から GPU の計算単位へ移動させる必要があるためです。

同じワークロードを実行しますが並列度を増大させ (ISL = 1024, OSL = 4096, 並列度 = 32) ます： 高い並列度では、メモリの SOL % と計算 SOL % の両方が高い値を報告します。計算 SOL % はバッチサイズが大きいため高く、各トークンバッチに対してモデル重量をメモリーから一度だけ読み取ることでバッチあたりの演算作業が増えるためです。メモリの SOL % は KV キャッシュからより多くの情報を総体で読み取るため高い値を報告します。ベンチマークの進行に伴い後続のトークンは解読ステップにおいてより大きな KV キャッシュから読み込む必要があるため、メモリの SOL % は増加します。

可能な限りバッチ数を増やそうとして並列度を 1024 に設定すると、計算 SOL % が約 46% に近づき、Attainable SOL % にほぼ到達します。

ケース 3：LLM ファインチューニング

ここで Llama-3.1-8B モデルを NVIDIA H200 GPU 2 台で LoRA (Low-Rank Adaptation) を用いてファインチューニングしましょう。デフォルトフレームワーク設定を使用します。LoRA はパラメータ効率的なファインチューニングの広く使用される技術であり、全モデル重量を更新する代わりにベースモデルを凍結したまま各トランスフォーマー層に小さな訓練可能なアダプターマトリックスを挿入します。トレーニングループは、凍結されたモデルを通じた順方向パス、アダプター層の勾配を計算するための逆方向パス、そしてアダプターパラメータのみを更新するための最適化ステップの間で切り替わります。

Utilyze はハードウェアの理論的極大値を大幅に下回る 1–7% の Compute SOL % を報告します。一方、nvidia-smi はあらゆるケースで 80-100% の過大見積もりを示します。低い Compute SOL % はデフォルト設定での LoRA ファインチューニングの特性であり、なぜこのような結果が得られるかを理解するには含まれる演算の計算密度を見る必要があります。順方向パスと逆方向パスにおける主要なコストは、トレーニングステップごとに HBM を通して凍結されたベースモデル重量をストリーミングすることです。これらの読み取りは大きく連続的でありメモリバンド効率が高いですが、移動したバイトあたりに比較的小数の演算作業を生み出し、このワークロードを明確にメモリー束縛領域に位置づけます。同時に、LoRA アダプター層自体は小さく、典型的なランク 8～64 ではそれらが導入する行列乗算の問題サイズがテンソルコアを飽和させるにはあまりにも小さすぎます。その結果、トレーニング全体を通じて GPU がカーネルを継続的に起動していますが、Tensor Cores は多くの時間をデータの待機中であり演算を実行する間では利用されません。これはメモリー束縛のデコード重み推論ケースで観察された基本的なパターンと同じです：外部から見て GPU は飽和しているように見えますが、計算単位は内部で主にアイドル状態です。

以下の図は Systalyze の最適化を適用する前後の Utilyze 出力を示しています。ベースライン実行では Compute SOL % が安定して 1% から 7% の間で推移します。Systalyze の最適化を適用すると Compute SOL % は 40–55% に引き上げられます。これは GPU 計算スループットの実際の 6～8 倍の改善に相当し、トレーニングステップ時間の短縮に直接反映されます。潜在的な計算容量は常に存在していました。欠けていたのはそれを可視化する測定と、それに基づいて行動するためのツールでした。

より困難なケースとして、4 つの NVIDIA H200 GPU で gpt-oss-20b のフルファインチューニングを考えてみましょう。gpt-oss-20b は Mixture-of-Experts モデルで、合計 20B のパラメータのうちトークンごとに活性化するのは 36 億パラメータだけです。モデルは一つの H200 に収まりませんので、トレーニングフレームワークはすべての GPU 間にパラメータ、勾配、最適化状態をシャーディングし、各ステップで通信を行います。Utilyze はベースライン実行では常に 3–15% の Compute SOL % を報告します。nvidia-smi は 100% を表示（下の図参照）しています。Compute SOL % の値は MoE モデルの特性であり、テンソルコアは大きな均一なマトリックス乗算を望むが、MoE は各アクティブエキスパートごとに与えられる小さな不均一チャンクを提供し、ルーティングとトークンのシャッフルにより GPU が完全には利用されません。Systalyze の最適化により利用率は 30-60% に押し上げられ、MoE トレーニング向けのより良い設計を反映しています。ワークロードは完全にメモリー束縛から計算束縛へシフトします。MoE スパース性は GPU 利用率とトークンあたりの小さな活性化量および低いトレーニング FLOPs の間のトレードオフであり、したがって低い SOL % はアーキテクチャの本質的部分に起因し、単なるチューニング問題ではないことに注意してください。

測定からパフォーマンスへ：Systalyze

Utilyze はあなたの現状を示します。Systalyze はギャップを埋めます。当社のプラットフォームは同じ SOL 測定インフラを活用し、自動的にどの最適化技術（例：CUDA グラフコンパイル、効率的なカーネルの書き換え、並列化戦略選択、ハイパーパラメータチューニング、カーネル融合、ゼロコピー、カーネルバイパス、効率的ジョブオーケストレーションなど）を適用すべきかを特定します。各最適化は測定された SOL 影響により検証されます。

数十億パラメータ以下の推論モデルから数兆パラメータの境界モデルまで、クラウドまたはオンプレミスを含むあらゆるデプロイメントにおいて、デフォルト構成では一貫して 2–10 倍のパフォーマンスを無駄にしています。正確な測定をガイドとする正しい最適化の組み合わせは、その大部分を取り戻します。

コミュニティへのお願い

Utilyze は Apache 2.0 ライセンスを持つ無料オープンソースプロジェクトです。

• Utilyze をワークロードで実行してください
• あなたの数値を共有してください。 他のダッシュボードの報告と Utilyze が測定する値との間に現れる驚くべきギャップについて特に教えてください。コミュニティが提供するデータポイントが越多、より多くのモデルアーキテクチャ、ハードウェア世代、デプロイメント構成における Attainable SOL % をよりよく校正できます。

成果を共有するには、Utilyze リポジトリの GitHub Discussion にあなたのモデル、ハードウェア、ベースライン SOL %、および試した最適化情報を投稿してください。私たちは能動的に監視し回答いたします。より深い協力やエンタープライズデプロイメントについては utilyze@systalyze.com までご連絡ください。

初期リリースは NVIDIA ハードウェアを対象としています。AMD サポートはロードマップ上にあり、MI300X や MI325X を実行中で協働をご希望の場合は下のチャネルを通じてご連絡ください。

GitHub で Utilyze を入手

(リポジトリへのリンク)

Systalyze について学ぶ

Systalyze は MIT スピンオフ企業であり、企業がトレーニング、ファインチューニング、推論、エージェント AI ワークフローを大幅に改善された効率性と予測可能性で実行できるようにする AI デプロイメントおよび最適化ソフトウェアを開発しています。プラットフォームはオンプレミス、ハイブリッド、マルチクラウド環境を問わず完全なデータプライバシーを保証しながら、パフォーマンスとコスト効率の大きな向上を提供します。Systalyze は生産性 AI システムのスケーラビリティと経済的効率性を高めるように設計されています。本記事で説明した Utilyze というオープンソース GPU モニタリングツールはプラットフォームの測定基盤として役立ち、無料で利用可能です。