Amazon EKSのMoE強化学習、スループットが40%向上。ただしベンチマークには限界も
Amazonによると、同社のエンジニアがElastic Fabric Adapter上でDeepEPを有効化した後、Amazon EKS上のMoE強化学習ではロールアウトの総スループットが40%向上した。テストでは48台のP5enインスタンスを使用し、16台を方策学習に、32台を推論ロールアウトの生成に割り当てた。これは大規模モデルのポストトレーニングにおける高コストな工程での大きな成果だ。
重要な変更点は、単により高速なGPU構成を追加したことではない。AmazonはDeepEPのエキスパート間通信パスをlibfabricに対応させ、DeepEP v2にAWSネットワークのネイティブサポートを提供した。この統合は、Mixture-of-Expertsモデルが異なるGPU上のエキスパートへトークンをルーティングする際に発生する不規則なトラフィックパターンを対象としている。
ただし、この結果には慎重な位置付けが必要だ。AWSが公開したのは、超高スパースなMoEワークロード1件における相対的なスループット向上であり、あらゆるモデル、クラスター、強化学習フレームワークに通用する汎用ベンチマークではない。独立したシステム研究では、異なるGPUおよびネットワークアーキテクチャ間でエキスパート並列通信を移行する難しさが指摘されている。
AmazonがMoE強化学習スタックで変更した点
Amazonが報告した向上は、測定対象クラスターにマシンを追加したのではなく、ルーティングされたトークンがエキスパート間を移動する方法を変えたことによるものだ。
AWSのアーキテクチャは、強化学習ジョブを複数のワーカーグループに分割している。GPUノードは方策学習、報酬モデル推論、ロールアウト生成を担う。CPUノードは環境実行と前処理を実行し、メモリ最適化ノードは経験バッファーとチェックポイントキャッシュを保持する。
Amazon EKSはオーケストレーション層として機能する。コンテナを配置し、個別のノードグループを管理し、障害を調整するとともに、運用者がワークロードの各部分を独立してスケールできるようにする。Amazon S3は、レイテンシーに敏感な実行パスの外部で、データセット、チェックポイント、最終的な重み、その他の永続的なアーティファクトを保存する。
この分離が重要なのは、強化学習が単一で均一な計算ではないためだ。ロールアウト生成では、推論ワーカーが現在の方策を用いて環境と相互作用し、候補応答または軌跡を生成する。報酬システムがそれらのサンプルを評価し、方策学習ワーカーが得られた経験を消費する。
更新された重みはその後ロールアウト群へ戻され、次の方策反復が始まる。このループは、選好シグナルを用いてモデルを改善するReinforcement Learning from Human Feedback、すなわちRLHFで見られる。また、グループ内の他のサンプルとの相対関係で出力を評価するGroup Relative Policy Optimization、すなわちGRPOでも用いられる。
各段階はインフラに異なる負荷を与える。ロールアウト生成は分散推論に似ており、多くの場合、独立したワーカー間で作業を分割できる。方策学習では、参加GPUが次のステップに進む前に協調した操作を完了する必要があるため、より厳密な同期が求められる。
そのため、このアーキテクチャでは報告されたテストにおいて、32台の推論インスタンスと16台の学習インスタンスを分離している。Amazonによると、これら48台のP5enシステム全体で、EFA上のDeepEPはDeepEPなしの構成と比較してロールアウトの総スループットを40%引き上げた。
P5enインスタンスはNVIDIA H200 GPUと高帯域幅のAWSネットワークを使用する。48インスタンスをフルに構成した環境は数百台のアクセラレーターに相当するが、AWSによれば、より大規模なアーキテクチャはおよそ1,000台のアクセラレーターまで拡張可能だ。公開された割合は48インスタンスでの比較を示すものであり、あらゆるクラスター規模に当てはまるものではない。
モデル自体は、超高スパースなMoEモデルとだけ説明されている。Mixture-of-Expertsモデルは複数の特化したフィードフォワードブロックを含むが、各トークンではその一部のみを活性化する。スパース性はトークン当たりの計算量を抑える一方、エキスパートが異なるGPUに配置される場合には、厳しいルーティング課題を生じさせる。
標準的な集団通信は、すべてのランクが同程度のサイズで予測可能なブロックを交換する場合によく機能する。MoEのルーティングは異なる。トークンは動的にエキスパートを選ぶため、トラフィックはスパースかつ不均一になり、多数の小規模転送で構成されうる。
この違いこそ、インフラがこれほど重要になる理由だ。理論上のモデル容量が大きくなっても、有用なトークン毎秒が自動的に増えるわけではない。エキスパートへのディスパッチと結果の収集がネットワークを圧迫すれば、高価なGPUは処理の代わりにアクティベーションを待つことになる。
Amazon EKSのMoE強化学習がネットワークの壁に突き当たる理由
スパース計算は演算量を節約するが、エキスパート並列化ではそのコストが通信遅延として戻ってくる可能性がある。
エキスパート並列化は、モデルのエキスパートを複数のGPUに分散する。ルーターがリモートのエキスパートを選択すると、システムは各トークンのアクティベーションを正しいデバイスへ送る必要がある。エキスパートが処理した後、結合操作によって出力が元の実行パスへ返される。
こうした交換はモデル全体で繰り返し発生する。送信先は実行時のルーティング判断に依存し、エキスパートごとに受け取るトークン数も異なりうる。そのためネットワークは、一部の混雑した宛先が全参加者を停止させないよう、多数の細粒度転送を処理しなければならない。
DeepEPはこのパターンのために作られた。DeepEPプロジェクトは、エキスパート並列ワークロード向けに特化したディスパッチおよび結合カーネルを提供する。サーバー内の通信にはNVLinkを使用し、サーバー間ではRDMA対応のトランスポートを利用する。
Remote Direct Memory Access、すなわちRDMAは、あるマシンがCPUの関与を抑えて別のマシンのメモリへデータを直接転送できるようにする。この短いパスにより、ソフトウェアのオーバーヘッドを削減し、高速なネットワークハードウェアをより有効に活用できる可能性がある。
Elastic Fabric Adapter、すなわちEFAは、密結合コンピューティング向けのAWSの低レイテンシーネットワークインターフェースだ。EFAドキュメントでは、AWS Scalable Reliable Datagramを基盤とするOSバイパスパスが説明されている。EKSは、分散機械学習アプリケーションを実行するPodにEFAデバイスを公開できる。
各P5enインスタンス内では、NVLinkとNVSwitchがローカルのアクセラレーターファブリック全体でGPUトラフィックを担う。インスタンス間転送では、EFAが該当するパスとなる。Amazonの統合はlibfabricを使用しており、これによりアプリケーションは共通APIを通じてさまざまな高性能ネットワークプロバイダーにアクセスできる。
Amazonによると、同社のエンジニアはDeepEPの通信プリミティブをCUDA固有のRDMAバックエンドからlibfabricへ移行する機能を提供した。この取り組みにより、DeepEP v2はエキスパートのディスパッチおよび結合に特化したカーネルを維持しながら、EFA経由でノード間データを送信できる。
特化したエキスパート操作と密な集団通信の違いは、この結果の中心にある。NCCLはall-reduce、all-gather、reduce-scatterのような規則的な操作に引き続き有用だ。DeepEPはMoE層周辺で発生するスパースなall-to-all交換を対象にしている。
最近の研究もこの分担を反映している。NCCL EPの著者らは、エキスパート通信向けに低レイテンシーモードと高スループットモードを別々に説明している。高スループット設計では、ノード間RDMA接続を介して送信する前に、NVLinkドメイン内でデータを集約する。
この階層構造は、マシン間というより遅い境界を越える細粒度トラフィックを減らす。また、クラスターが単一で均一なネットワークではないことも認識している。サーバー内通信は、サーバー間通信とは帯域幅とレイテンシーの特性が異なる。
AWSの実装も同じ大原則に従う。ローカルトラフィックはNVLinkに留まり、ノード間のDeepEPトラフィックはlibfabricがEFA経由で運ぶ。このトポロジーを意識したパスは、すべてのトークン転送を汎用的に扱う方式を置き換える。
結果として得られた40%の増加は、単なる通信マイクロベンチマークではなく、ロールアウトの総出力を指す。このエンドツーエンド指標は重要である。より高速なカーネルが、強化学習ループ全体を常に高速化するとは限らないためだ。この向上は、エキスパート通信が完了したロールアウト作業に影響を与えるほど重要だったことを示唆している。
ただし、ロールアウトのスループットはシステムの一層にすぎない。方策反復時間は、環境実行、報酬評価、サンプルバッファリング、チェックポイント公開、学習計算、重み同期にも左右される。ある段階を最適化すると、別の場所でボトルネックが表面化する可能性がある。
真の競争は特化型ルーティングと汎用集団通信の間にある
主要な競争は、動的なエキスパートルーティング向けに設計された通信と、規則的なデータ移動向けに設計された集団通信の間で起きている。
汎用集団通信は、成熟しており幅広くサポートされ、統合しやすいため魅力的だ。多くの学習フレームワークやハードウェア構成で機能する。運用者は使い慣れたツールでテストでき、その同期動作を把握しやすい。
MoEトラフィックは、こうした集団通信を効率的にする複数の前提に反する。各トークンが異なるエキスパートの組み合わせを選択しうる。一部のエキスパートは一時的に人気を集め、メッセージサイズは小さいままで、システムはすべてのMoE層でディスパッチと結合操作を実行する。
従来の実装では、このトラフィックをall-to-all操作にパッケージ化できる。このアプローチは引き続き機能するが、エキスパート並列性がより多くのノードにまたがるにつれ、同期とメッセージ処理のオーバーヘッドは増大する。その結果、GPUを増やすと有用な計算が比例して増えるのではなく、通信関係が増えることになる。
DeepEPは、エキスパートルーティングの意味論を中心に構築されたカーネルでこの問題に取り組む。ディスパッチカーネルはトークンのアクティベーションを選択されたエキスパートへ送る。結合カーネルは処理済みアクティベーションを返しつつ、未使用の宛先に対して汎用集団通信が実行しうる作業を回避する。
この設計は、通信と計算のオーバーラップも目指している。転送が進行している間にGPUが有用な行列演算を続けられれば、ネットワーク時間の一部はクリティカルパスから消える。このオーバーラップは、通信に繰り返しのCPU調整や厳格なグローバル同期が必要な場合、より困難になる。
Amazonのlibfabric移行が重要なのは、元の最適化がNVIDIA GPUとInfiniBand型ネットワークに密接に関連していたためだ。あるファブリックで優れた性能を示す通信ライブラリが、別のファブリックでも自動的に同じ挙動を維持するわけではない。順序保証、メッセージ開始、デバイスインターフェースは異なる。
したがって、この統合は単なるネットワークアドレスの変更以上の意味を持つ。DeepEPの前提をEFAのトランスポートセマンティクスに対応付け、実装が正確なトークン配送を維持する必要がある。また、特化型ルーティングの利点を打ち消すほどのソフトウェアオーバーヘッドを導入してはならない。
Amazonは、対応するP5およびP6システムでEFAとGPUDirect RDMAを利用できるとしている。GPUDirect RDMAでは、各ペイロードを通常のホストメモリ経由でステージングすることなく、ネットワーク転送がGPUメモリから読み取り、GPUメモリへ書き込める。OSは主要なデータパスの外側に留まる。
この設計は、標準的な集団通信だけに依存する汎用MoEデプロイメントに圧力をかける。大規模なエキスパート並列モデルを使用するインフラチームには、特化パスが本番に関連する強化学習ワークロード1件を改善できるという証拠が示された。
この結果はフレームワークの保守担当者にも課題を突き付ける。DeepEPのサポートは、サービングエンジン、強化学習システム、コンテナイメージ、スケジューラー、オブザーバビリティツールに到達しなければならない。脆弱なカスタムビルドを必要とする高速トランスポートは、デプロイや復旧の際にその優位性を失いかねない。
NCCL 2.31は、全体像にもう一つの要素を加える。AWSによれば、このリリースには密な集団通信向けの新しいEFA最適化が含まれる。したがって現実的なMoEトレーニングスタックでは、単一の万能な勝者を宣言するのではなく、トラフィックの種類ごとに異なる仕組みを使う。
DeepEPは不規則なエキスパートのディスパッチと結合を処理する。NCCLは引き続き、アテンション層、テンソル並列、データ並列、オプティマイザ状態をまたぐ密な同期を担う。EFAは、各パターンに最適化された経路を通じて、両方の通信クラスをマシン間で運ぶ。
この分担こそが、より大きなアーキテクチャ上の教訓である。MoEのスケーリングは、通信を形状と目的で識別することに依存する。すべての転送を交換可能なものとして扱えば、得られるはずの性能を取り逃がす。
DeepEPのスループット40%向上という主張が示さないこと
このベンチマークは特定のアーキテクチャ判断を支持するが、DeepEPがEFAを常に40%上回ることを立証するものではない。
Amazonはインスタンス構成、相対的な改善率、モデルのおおまかなスパース性プロファイルを明らかにしている。一方で、モデルのパラメータ数、エキスパート数、ルーティング分布、シーケンス長、バッチサイズ、完全なベースライン構成は公開していない。
こうした詳細はエキスパート通信に直接影響する。トークン当たりにより多くのエキスパートを有効化するモデルでは、通信量が増えうる。大きなバッチではメッセージをより効率的に集約できる一方、小さなデコードバッチでは固定レイテンシの影響が大きくなる可能性がある。
「aggregate rollout throughput」という表現にも文脈が必要だ。AWSは公開記事で、1秒当たりの出力トークン数、軌跡数、完了リクエスト数の絶対値を示していない。読者はクラスター全体の稼働率を計算できず、他社の環境と直接比較することもできない。
ベースラインも同じくらい重要である。「DeepEPなし」は、特定のチューニングを施した標準的なNCCL all-to-all実装を意味する可能性がある。異なるメッセージ集約、エキスパート配置、並行性、ルーティング方針によって、測定された差は縮小も拡大もあり得る。
Amazonが報告しているのは、自社の内部ワークロードによる統制された結果である。同社はベンチマークが独立監査を受けたとは主張しておらず、公開資料には反復試行のばらつきも含まれていない。したがって適切な表現は、AWSによればスループットが40%増加した、となる。
移植性という問題もある。以前のUCCL-EP researchは、GPUおよびネットワークインターフェースに密接に結び付いたエキスパート通信システムでは、統合作業が大きくなると論じた。この論文は特に、順序付けセマンティクスの違いがEFAやその他の非InfiniBandネットワークのサポートをどのように複雑化するかを検討している。
この研究は、Amazonが新たに説明したネイティブEFA対応より前のものである。それでも、AWSがlibfabricへの貢献を通じて現在解決したとしている技術的障壁を説明しているため、依然として重要である。両者は、急速に変化する実装の歴史における異なる時点を説明している。
UCCL-EPは別の経路を取る。ルーティング判断はGPU上に残しつつ、ネットワーク実行をマルチスレッドCPUプロキシに委譲し、制御チャネルを使ってハードウェア差異を橋渡しする。著者らはNVIDIAとEFAを組み合わせたシステムでの向上を報告しているが、そのテストには独自のモデル、フレームワーク、構成が使われている。
どちらの結果も、もう一方を無効にするものではない。これらは、トランスポート設計によって結果が変わり得ること、そして「EFA対応」が単一の固定された実行経路を意味しないことを示している。運用者は、ビルドがGPU起点の転送、CPUプロキシ、メッセージ集約、あるいは別の互換性レイヤーを使用しているかを把握する必要がある。
DeepEP自身の公開要件と性能結果も進化してきた。現在のプロジェクト文書では、対応するRDMA構成で高い帯域幅が報告されている一方、より大規模なエキスパート並列デプロイメントを直接ベンチマークするよう利用者に勧めている。この助言は、トポロジーや輻輳の挙動が異なるクラウドファブリックでは特に重要である。
クラスター規模はさらなる不確実性をもたらす。報告されたテストでは48台のP5enインスタンスが使われたが、AWSはより広いアーキテクチャをおよそ1,000基のアクセラレータへ拡張することを論じている。48ノードで良好に機能する設計が、より大きなあらゆる規模で同じ効率を維持するとは限らない。
複数のワーカーグループがインフラを共有すると、ネットワーク競合が発生し得る。モデルやワークロードの挙動が変化すれば、トークンルーティングの不均衡も大きくなり得る。単一の低速ランクでも、厳密に同期されたトレーニング処理を遅延させる可能性がある。
強化学習には、独自の変動要因もある。プロンプト長、応答長、環境レイテンシ、サンプリング設定、報酬モデルの複雑さはいずれも、ロールアウトワーカーが通信に費やす時間へ影響する。通信負荷の高いワークロードで40%向上しても、生成や環境実行が支配的になれば効果は小さくなり得る。
この結果がオンラインサービングについて示すことはさらに少ない。本番推論では、より小さなバッチと厳格なリクエスト単位のレイテンシ目標が一般的である。ロールアウト生成向けに調整された高スループットカーネルが、インタラクティブ利用者の初回トークンまでの時間や出力トークン当たりの時間を自動的に短縮するわけではない。
コストも絶対値としては示されていない。同一クラスターでスループットが高まれば、通常はアクセラレータ時間当たりの有用な作業量が増えるが、記事では総トレーニング費用は示されていない。また、最適化済み構成を代替インスタンスタイプやネットワークライブラリと比較してもいない。
こうした欠落は、結果が重要でないことを意味しない。むしろ、どこで有用かを定義している。このベンチマークは、AWSのDeepEP統合が大規模なMoE強化学習パイプラインの一つで意味のあるボトルネックを解消できる証拠である。
EKSとSpot CapacityがRLシステムの残りを変える
スケジューラ、バッファ、ストレージ、障害モデルが高速化されたロールアウトフリートへ継続的に処理を供給できて初めて、通信面での向上は運用上有用になる。
Amazon EKSにより、このアーキテクチャは異なるノードタイプを異なるタスクへ割り当てられる。GPUノードグループはトレーニングと推論の需要に合わせてスケールできる。CPUグループは環境ワーカー向けに拡張でき、メモリ重視のシステムは短命な経験データを受け止める。
この異種構成は、GRPOとRLHFに特に関連する。ロールアウトワーカーは大量の一時データを生成し得るが、ポリシートレーナーはそれを同期されたバッチで消費する。生成と消費の速度が乖離すると、一方は待機し、もう一方にはキューが蓄積する。
共有インメモリ経験バッファは、短期間にわたりこれらの速度を切り離す。ロールアウトワーカーは完了したサンプルを公開し、トレーナーは準備ができた時点でバッチを取得する。チェックポイントキャッシュは、すべての転送を永続的なオブジェクトストレージ経由にせず、更新済み重みを配布するのに役立つ。
Amazon S3は異なる役割を担う。データセット、復旧可能なチェックポイント、完成したモデル成果物、最終的な重みを保持する。最も頻繁なサンプル交換をこの永続パスの外に置くことで、オブジェクトストレージのレイテンシがすべてのトレーニングステップを支配することを防ぐ。
この分離はEKSの価値も明確にする。Kubernetesは行列乗算やエキスパートカーネルを高速化するものではない。アクセラレータの生産性を維持するために必要なサービス群を調整する役割を担う。
EKSは配置、再起動、スケーリング方針、ノードグループの境界を管理する。安定したポリシートレーニング容量を、より弾力的なロールアウトワーカーとは別にスケジューリングできる。この境界が、Amazonの第2の最適化、すなわち一部のロールアウト生成でのEC2 Spot Instancesの利用を支える。
Spot capacityは、AWSが基盤となるインスタンスを必要とした際に中断される可能性がある。1つのワーカーを失うだけで協調ジョブが停止または再開され得るため、このリスクは厳密に同期されたポリシートレーニングでは扱いにくい。ロールアウトタスクは、より容易に分割して再試行できる。
Amazonは、ロールアウトワーカーに範囲を限定した作業単位を与え、サンプルを頻繁に公開するよう推奨している。中断通知が到着すると、ワーカーはアクティブなリクエストを処理し切り、未完了タスクをキューへ戻せる。他のワーカーは、ポリシートレーニンググループ全体を再起動せずに継続できる。
この戦略によって中断のコストがゼロになるわけではない。失われた部分生成は一部の計算を無駄にし、代替ノードにはコンテナ、モデル重み、通信ライブラリが必要になる。オートスケーリングの判断では、キューの深さ、モデル読み込み時間、利用可能なSpot capacityも考慮しなければならない。
それでもこのトポロジーは、2つの障害ドメインを分離する。ポリシートレーナーは安定した容量にとどまり、ロールアウト生成は低コストだが予測しにくいプールを使う。この設計は、2段階の異なる同期要件に適合している。
DeepEPによる40%のスループット向上は、このバランスを変える可能性がある。より高速な推論ワーカーは、トレーナーが消費するより速く経験を供給するかもしれない。その場合、運用者はアイドル状態の生成に費用を払わないよう、ノードグループのサイズ変更、バッチスケジューリングの調整、または推論容量の削減を行う必要がある。
ポリシー更新後には逆のことが起こり得る。重みの配布とワーカー再起動に要する時間が、経験バッファを一時的に枯渇させる可能性がある。したがって有用な本番ダッシュボードは、1秒当たりの生成トークン数だけでなく、エンドツーエンドのポリシー反復を追跡しなければならない。
チームには再現可能なビルド情報も必要となる。DeepEP、NCCL、CUDA、libfabric、EFAドライバー、フレームワークのバージョン、GPUアーキテクチャはいずれもデータパスに影響する。1つのコンポーネントを変えるだけで、より遅いフォールバックが密かに選択される可能性がある。
こうした運用上の証拠は、モデルと実験の記録とともに保管すべきである。エンジニアリングチームは、構成判断、ベンチマークの記録、障害報告を、検索可能なtechnical knowledge baseに保存できる。この慣行は、後のイメージ再ビルドによってモデルを変えずにスループットが変化した場合に価値を持つ。
向上が一般化するかを示す3つのシグナル
次の検証対象は、モデル、クラスター規模、完全なポリシー反復をまたぐ再現性である。
第1のシグナルは、絶対スループットを伴う公開ベンチマークパッケージである。有用な結果には、1秒当たりのトークン数または軌跡数、レイテンシ分布、エキスパート負荷の不均衡、ネットワーク利用率、反復実行のばらつきが含まれる。
このパッケージには、ベースラインとなる集団通信、関連するすべてのソフトウェアバージョン、正確なDeepEPトランスポート経路を明記すべきである。また、モデル次元、トークン当たりのアクティブエキスパート数、バッチサイズ、プロンプト長、応答長、エキスパート並列度も開示すべきだ。
独立したチームが同様の向上を再現すれば、AWSの主張はより強固になる。結果が大きくばらつく場合でも、その統合は有用ではあるがワークロード固有ということになる。いずれの結果も、その追加の複雑さがいつ正当化されるかを運用者が判断する助けになる。
第2のシグナルは、公開された48インスタンス構成を超えるスケーリング効率である。複数のクラスター規模における結果は、スループットが比例して伸びるのか、それとも同期、輻輳、エキスパート不均衡によって伸び悩むのかを示す。
意味のあるスケーリング研究では、リソースを増やす間もワークロード定義を一定に保つべきである。集約出力とアクセラレータ当たりの効率の両方を報告すべきだ。集約スループットは、追加される各GPUがもたらす有用な作業量が減少していても上昇し得る。
およそ1,000基のアクセラレータに向けて高い効率が維持されれば、AWSのより広範なアーキテクチャ上の主張を支持する。急激な低下が見られれば、DeepEPが1つのボトルネックを解消する一方で、より大きな規模では別のボトルネックが現れたことを示す。
第3のシグナルは、実際の障害下におけるエンドツーエンドのポリシー反復時間である。ロールアウトスループットが重要なのは、トレーニングワーカーが新鮮な経験を必要とするためであり、孤立したトークンを生成すること自体が最終目的ではない。
今後の測定には、環境実行、報酬評価、バッファ遅延、ポリシー更新、チェックポイント公開、重みの再配布を含めるべきである。また、Spotの中断が完了サンプル数と復旧時間にどう影響するかも示す必要がある。
完全な反復が短縮されれば、通信最適化がアイドル時間を別の場所へ移すだけでなく、強化学習の進捗を改善することが確認される。反復時間がほとんど変わらないなら、チームはロールアウト容量を追加する前に、トレーニング、ストレージ、または同期を調査すべきである。
Amazon EKSでのMoE強化学習には、Kubernetesオーケストレーション、EFAネットワーク、専門化されたエキスパート間通信を組み合わせるための、信頼できる道筋が見えてきました。報告された40%の向上はこのアプローチを試す価値を示しますが、汎用的に適用できる定数ではなく、あくまで初期の測定結果です。インフラチームは、このスタックを標準化する前に、自社のモデル、ルーティングプロファイル、RLループを用いて比較を再現すべきです。実務上の問いは、DeepEPがより高速なグラフを生み出せるかどうかではありません。システムのあらゆる要素を考慮したうえで、同じクラスターが許容可能な信頼性とコストで、より多くの検証済みポリシー更新を完了できるかどうかです。
