既存のGPU環境には、まだ引き出せる性能があるかもしれません。10月のMI300X検証では、同じGPU4基と同じソフトウェアイメージを使い、サービング構成の変更によって、応答開始と出力能力の両方を改善しました。
最初のトークンまでの平均時間は47.1%短縮し、出力スループットは16.7%向上しました。AMDインフラでどれだけ有効な仕事を処理できるかを評価するチームにとって、増強を計画する前にサービング構成を見直す具体的な根拠になります。
待ち時間を減らし、出力を増やす
AMD MI300X GPU4基でDeepSeek V4.1 Flashを動かし、32の同時実行トレースセッションを使って、ローカルベースラインと更新後の構成を比較しました。
| 指標 | ローカルベースライン | 更新後の構成 | 変化 |
|---|---|---|---|
| 最初のトークンまでの平均時間 | 1.52 s | 0.80 s | 47.1%短縮 |
| 出力スループット、tokens/s/GPU | 185.5 | 216.5 | 16.7%向上 |
| 完了したプロファイリングリクエスト | 2,818 | 3,247 | 15.2%増加 |
ProsGrowのローカル測定、2026年10月25日。各実行の予定ベンチマーク期間は1時間です。パーセント値は丸める前の測定値から計算しています。
最初のトークンまでの待ち時間の短縮は、検証システムが平均して約0.71秒早く応答を提供し始めたことを意味します。スループットの向上は、ベンチマーク全体でより多くの生成出力を提供したことを意味します。リクエスト数は同じ比較を別の観点から示したもので、独立した結果や完了した業務タスク数ではありません。
エージェントサービスでコンテキスト再利用が重要な理由
多くのAIアプリケーションは、指示、検索した資料、過去の会話ターンなどの情報を引き継ぎます。再利用可能なコンテキストを使い回すことで、対話が続く間の重複処理を減らせます。
今回の変更により、サービングスタックはその機会をより有効に活用できるようになりました。GPUの割り当てとソフトウェアイメージを固定し、更新したサービング構成の効果を測定しました。この方法は同じコンテキストが繰り返されるアプリケーションに関係しますが、効果の大きさは実際のトラフィックに依存します。
新規で無関係なプロンプトは、長く続くエージェントセッションとは異なる挙動を示す可能性があります。だからこそ、導入評価には、アプリケーションが実際に処理するリクエストパターンを含めるべきです。
既存の処理能力を活用する
インフラチームにとっての実際の問いは、利用可能な資源で必要な応答時間とトラフィック水準を満たせる構成かどうかです。今回の結果は、MI300Xで検証する価値のある候補を示しています。
この結果は、運用コストの特定割合の削減や、対応ユーザー数の普遍的な増加を証明しません。それらはワークロード、稼働率、ホスティング価格、品質要件に依存します。実験のビジネス上の価値は、インフラの意思決定前に評価できる実測の改善をチームに提供することです。
ProsGrowの役割は、その評価を具体化することです。ベースラインを確立し、回避できる重複処理を特定して、関連する負荷で候補を検証します。私たちはDeepSeekとオープンソースのサービングエコシステムの機能を基盤にしています。
測定に関する注記
この比較では、同じMI300X割り当て、ソフトウェアイメージ、投機的生成設定を使っています。両方の実行で、記録済みAgentXトレースと、投機的生成の受理のシミュレーションを使用しました。これらは条件を制御したエンジニアリングベンチマークであり、実際の検証を伴う本番応答とは別のものです。
スループットは、トレース内の待機を含めた観測リクエスト期間全体で測定します。選択した各構成の正式な実行は1回で、信頼区間はありません。数値は32セッションの動作点を示しており、すべてのトラフィック水準に外挿すべきではありません。
ローカルMI300Xの品質評価はまだ完了していません。ワークロード固有の品質と実際のサービング性能の確認は、引き続き本番適合性確認の一部です。ここで示した数値はコンテキスト再利用の比較に基づきます。その後の実験設定のうち、改善について実際の検証を伴うテストがまだ必要なものは含めていません。
AMD環境の可能性を探る
AMDでプライベートDeepSeekを運用している、または専用GPU容量を検討していますか。ProsGrowは、応答時間、スループット、ワークロードに必要なインフラの関係を検証するお手伝いをします。