プライベートAIアシスタントを構築するチームにとって、GPU容量は、仕事の完了につながって初めて価値を持ちます。モデルがトークンを高速に生成していても、長いコンテキストの処理、以前の会話状態の復元、エージェントワークフローの段階間の待機に、多くの時間を費やすことがあります。
この違いを踏まえてGLM-5.2を検証しました。サービングシステムの再利用可能なコンテキストの扱いを改善し、同じAMD MI325X GPU8基がどれだけ多くの出力を提供できるかを調べました。モデルのチェックポイントと精度は変更していません。
出力レートは約3倍に
10月6日の実験では、実測の出力スループットがGPUあたり毎秒3.03トークンから9.05トークンに増加しました。GPU8基のサーバー全体では、毎秒24.22出力トークンから72.43出力トークンへと増え、ローカルの標準構成に対して2.99倍となりました。
| 測定結果 | ローカル標準構成 | ProsGrow最適化構成 |
|---|---|---|
| GPUあたり出力スループット | 3.03 tokens/s | 9.05 tokens/s |
| サーバー全体の出力スループット | 24.22 tokens/s | 72.43 tokens/s |
| 最初のトークンまでの時間の中央値 | 2.58秒 | 1.95秒 |
| 最初のトークンまでの時間の90パーセンタイル | 203.42秒 | 10.87秒 |
最初のトークンまでの測定は、別の側面を示しています。このワークロードで発生していた長い待ち時間は大幅に短縮しました。トークンストリーミング対話速度の中央値の変化は2.1%にとどまりました。したがって、スループットの改善はサービングワークロード全体の結果であり、すべてのトークンが3倍速く生成されたという意味ではありません。
完了した応答の構成が変わる中で、リクエスト全体の遅延中央値は6.73秒から7.92秒へ増加しました。全体のスループットが高くても、すべての遅延指標が改善したわけではありません。
有用なコンテキストを長く活用する
エージェントワークフローは、処理済みの情報を再び参照することがよくあります。その処理結果を保持すれば、特に複数の会話がメモリを取り合う場合に、同じコンテキストを再処理する必要を減らせます。
私たちは、サーバーのメモリ資源全体でコンテキストの再利用を調整することに注力しました。利用可能なホストメモリをGPUメモリと併用し、サービング方針を調整して、ベンチマーク全体での挙動を確認しました。サーバーのカウンターでは、全体のキャッシュ再利用率が83.4%から96.6%に増加しました。
ビジネス上の意味は実践的です。導入評価では、GPUの計算能力とともに、メモリとコンテキストの挙動を調べるべきです。GPUの追加購入を次の手段とする前に、既存サーバーにまだ処理能力の余地があるかもしれません。その大きさは、アプリケーションのトラフィックと応答要件に依存します。
公開参考値との比較
実測の9.05 tokens/s/GPUは、2026年9月25日のInferenceX GLM-5.2参考値(行443210)にある4.14 tokens/s/GPUの2.19倍でもありました。どちらもMI325X GPU8基、同時実行数4です。トークンストリーミング対話速度の中央値は、その参考値を3.6%下回りました。これは過去に公開された1点との比較です。ランタイムの識別情報や実行条件が異なるため、厳密な再現とは言えません。公開参考実行結果
この結果から言えること
性能測定の前に実施した、実際の検証を伴う独立した確認では、短いプロンプトと長いプロンプトの両方で、数学問題128問中125問に正解し、ベースラインで正解だった問題が不正解になることはありませんでした。これらの確認は検証した構成を支えるものですが、顧客のワークフローには独自の品質評価が必要です。
性能結果は、投機的生成の受理をシミュレーションした1時間のAgentXテストを、1組、順次実行したものです。一部の応答は指定より短く、2回の実行は異なる応答の組み合わせを処理し、入力長にも小さな違いがありました。完了した応答はすべて集計しています。結果は同時実行数4のGLM-5.2 FP8に適用され、本番環境の処理能力やコストを保証するものではありません。
プライベートGLMホスティングや専用AMD GPUインフラを検討していますか。ProsGrowは、モデル、ワークロード、応答目標を評価し、容量を増やす前に試す価値のあるサービング変更を見つけるお手伝いをします。パイロット導入を相談する