Anyscale

Anyscaleが選ばれる理由

Anyscaleは、分散Pythonコードの記述と、その確実な運用との間にあるギャップを埋める存在です。オープンソースのRayは、並列タスク、アクター、データパイプライン、トレーニング、チューニング、サービングのためのプログラミングモデルを提供しますが、本番環境のチームは依然として、クラスターのプロビジョニング、環境のパッケージ化、キャパシティのスケジューリング、障害対応、テレメトリの収集、アクセス制御、デプロイの調整といった運用課題に直面しています。

このプラットフォームは、これらの運用上の懸念をRayを中心としたマネージドなライフサイクルへと変換します。開発者はリモートの計算リソースに対して実験を行い、開発時の環境を維持したまま、同じアプリケーションをオフラインジョブや常駐サービスへと昇格させることができます。プラットフォームエンジニアは、すべてのML開発者がKubernetesや仮想マシン群を直接操作することなく、ネットワーク、IAM、ストレージ、アクセラレータの選択、クラウド容量を制御できます。

これは、一般的なクラウドMLスイートよりも焦点を絞った提案です。Anyscaleは、すべてのノートブック、フィーチャーストア、実験トラッカー、データウェアハウス、モデルレジストリ、またはアプリケーションフレームワークを置き換えることを意図していません。その差別化要因は分散実行レイヤーにあります。1つのPythonアプリケーションを、一貫した開発モデルを維持しながら、異種のCPUおよびGPUリソースにわたってスケールさせる点にあります。

この焦点は、現代のAIパイプラインにおいて特に重要です。トレーニング、データのキュレーション、バッチ推論、評価、リトリーバル、エージェントの実行、オンラインサービングは、それぞれ異なるスケーリングパターンを必要とすることが多いためです。これらの段階でRayを一貫して使用することで、チームが維持すべき互換性のない計算システムの数を減らすことができ、Anyscaleはその共有ランタイムを囲むマネージド環境を提供します。

主なワークフロー

一般的なワークフローは、ローカル環境またはインタラクティブなクラウド環境から始まります。開発者は、コンテナイメージ、Pythonの依存関係、環境変数、および必要なCPU、メモリ、アクセラレータの種類とスケーリング動作を記述した計算構成を定義します。アプリケーション自体はAnyscale専用の書き直しを必要とせず、Rayプログラムのまま維持されます。

インタラクティブな開発は、本番環境そのものではなく、一時的なフィードバックループとして扱うべきです。開発者は分散タスクの検査、コードの変更、代表的なデータでのテストを行い、リソースが正しく割り当てられているかを確認できます。動作が安定したら、アプリケーションをバージョン管理されたワークロード構成として定義し、ジョブまたはサービスとして起動します。

ジョブは、データセット変換、分散トレーニング、埋め込み生成、評価、バッチ推論、定期処理など、明確な完了地点がある作業に適しています。本番環境の構成では、リトライ動作、タイムアウト、リソース制約、ストレージの場所、および冪等な出力戦略を定義する必要があります。リトライされたジョブが、以前の結果を暗黙的に重複させたり破損させたりしてはいけません。

サービスは、クライアントが継続的に利用可能なエンドポイントを必要とする場合に適しています。アプリケーションは、Ray Serveのレプリカ、デプロイメント境界、リクエストルーティング、オートスケーリング信号を中心に設計されるべきです。本番環境への適合性は、モデルのロードが成功するかどうかだけでなく、起動時間、最初のトークン生成時間（TTFT）、継続的なスループット、キューの深さ、アクセラレータの利用率、およびロールアウトやノード障害時の挙動によって測定されます。

最終段階は運用化です。CLIおよびSDKコマンドをCI/CDに組み込み、個人用の資格情報をサービスアカウントに置き換えます。ダッシュボード、ログ、アラート、予算レポート、クラウドプロバイダーのテレメトリにより、同一のワークロードを異なる視点から可視化できます。設定、アプリケーションコード、デプロイコマンドはすべてソース管理下に置き、環境を「再構築」するのではなく「再現」できるようにします。

向いている用途

Anyscaleが最も明確な価値を発揮するのは、ワークロードが既に1台のマシンの性能を超えているか、近いうちに超えることが予想される場合です。数百万のドキュメント、画像、音声、ビデオフレームを処理するパイプラインは、1つの分散アプリケーション内でCPUの事前処理とGPUの推論を調整しながら、Ray Dataを通じて作業を分割できます。

基盤モデルのチームは、データセットのキュレーション、分散トレーニング、嗜好最適化（Preference Optimization）、評価、およびサービングにこのプラットフォームを利用できます。これらの段階は、計算プロファイルが大きく異なることが一般的です。データ準備には多くのCPUワーカーが必要な場合があり、トレーニングには密に調整されたアクセラレータが必要となり、推論にはトラフィックの変化に応答する弾力性のあるレプリカが必要になるからです。

バッチ推論も非常に適しています。大規模なオフラインコーパスに対してモデルを実行することは、インタラクティブなリクエストを処理することとは別の問題です。バッチパイプラインでは、入力をグループ化し、ステージ間でデータをストリーミングし、個別のリクエストのレイテンシに左右されずにアクセラレータを継続的に使用することで、スループットを最大化できます。

Anyscaleは、エージェント、モデルサーバー、リトリーバルサービス、MCP（Model Context Protocol）ツールが個別にスケールする複合AIアプリケーションのホストにも適しています。Ray Serveを使用することで、これらのコンポーネントを1つのデプロイ可能なアプリケーションとして維持しながら、各コンポーネントに異なるリソース要件を割り当てることができます。

従来の機械学習も引き続き重要です。Rayは、前処理、ハイパーパラメータチューニング、強化学習、コンピュータビジョン、およびLLM以外のモデルサービングを分散化できます。したがって、単にチャットボットをデプロイするかどうかではなく、分散Pythonポートフォリオ全体に基づいてAnyscaleを評価すべきです。

一方で、1つのインスタンスで十分に動作する小規模なAPIの場合、このプラットフォームのメリットは少なくなります。その場合は、コンテナサービスやマネージドエンドポイントの方が運用コストや学習コストが低く済む可能性があります。抽象化レイヤーを追加する価値があるのは、スケジューリング、並列処理、異種リソースの混在、あるいは急速なスケーリングが、将来の仮説ではなく実際の要件である場合です。

Rayの運用はどう変わるか

自前でRayを管理する場合、クラスターの作成、アップグレード、分離、監視、修復をどのように行うか組織として決定する必要があります。Kubernetesは基盤を提供しますが、オペレーターの管理、Podのスケジューリング、オートスケーラーの統合、ストレージ構成、イングレス、シークレット、オブザーバビリティ、およびバージョンの互換性管理といった作業が加わります。仮想マシンによるデプロイでは、イメージ、ネットワーク、インスタンスのライフサイクル、障害復旧のために別の自動化セットが必要になります。

Anyscaleは、Ray APIを維持したまま、これらのプラットフォームエンジニアリングの負担の一部を取り除きます。重要な点は、インフラの所有権が完全に消えるわけではないということです。特にBYOC（自前クラウド利用）デプロイメントでは、クラウド管理者が依然として信頼関係、ネットワークパス、ストレージ、IAMロール、クォータ、アクセラレータの可用性、およびコスト制御を構成します。

したがって、責任が「なくなる」のではなく「分担が変わる」と捉えるべきです。Anyscaleはコントロールプレーンとマネージドランタイムの動作を運用し、顧客はデータプレーン、アプリケーションコード、権限、依存関係、および選択したインフラを管理します。障害発生時にどのシステムに原因があるかの議論を避けるため、本番稼働前にこの境界線を定義しておく必要があります。

このモデルは、複数のチームがRayを必要とする場合に内部のプラットフォーム作業を削減できます。プロジェクトごとに独自のクラスターランチャー、ダッシュボード、デプロイスクリプト、リカバリ手順を作成する代わりに、組織でサポートされるイメージ、計算テンプレート、クラウドアイデンティティ、プロジェクト、およびワークロードパターンを一度定義すれば済みます。

トレードオフは、独自の管理プレーンと最適化されたランタイムへの依存です。アプリケーションコードはオープンソースのRayに基づいているため、完全に独自のプログラミングモデルに比べればロックインは限定的ですが、デプロイ構成、運用ワークフロー、ガバナンス統合などは、将来Anyscaleを離れる際に移行作業が必要になります。

LLMとエージェントのワークロード

LLMサービングにおいて、核となるアーキテクチャはオーケストレーションのためのRay Serveと、推論のためのvLLMを組み合わせたものです。これにより、KVキャッシュ管理や連続バッチングといったモデルレベルの懸念事項を、レプリカの配置、ノード選択、オートスケーリング、障害復旧といったクラスターレベルの懸念事項から切り離すことができます。

デプロイのサイズは、モデルのパラメータ数だけでなく、実際の測定値に基づいて決定すべきです。コンテキスト長、同時実行数、量子化、テンソル並列、投機的デコーディング、アダプター（LoRA等）の使用、およびレスポンス長はすべて、メモリ需要とスループットを変化させます。正常に起動したモデルであっても、リクエストルーティングによってGPUが低利用率のままだったり、レプリカが重みのロードに過度な時間を費やしたりすれば、経済性は悪化します。

マルチモデルデプロイメントには、さらなる計画が必要です。インフラを共有することで利用率は向上しますが、無関係なモデルがメモリを奪い合ったり、予測不可能なスケーリング動作を引き起こしたりする可能性があります。合成データによる最大スループットテストだけでなく、本番に近いプロンプト分布と同時実行数で各ルーティングポリシーをベンチマークすべきです。

バッチ推論は、オンラインサービングとは別に評価する必要があります。オフライン処理では入力を積極的にグループ化してアクセラレータの飽和を優先できますが、オンラインサービスではスループットとテールレイテンシ、TTFTのバランスをとる必要があります。同じモデルの重みを再利用するからといって、両方のパスで同じ構成が最適であるとは限りません。

エージェントアプリケーションでは、モデルサーバーの外部でオーケストレーションが行われます。エージェントはリトリーバルシステム、データベース、コードサンドボックス、MCPサーバー、または他のエージェントを呼び出す場合があります。これらのコンポーネントは、LLMとは異なるスケーリングおよびセキュリティ要件を持つことがよくあります。アプリケーションを独立してスケール可能な複数のデプロイメントとして扱うことで、軽量なツール実行のために高価なGPUを割り当てる無駄を避けることができます。

Anyscale Agent Skillsは、このワークフローをコーディングエージェントに拡張します。ワークロード構成の生成、失敗した実行の検査、RayやvLLMのエラー解釈、リソース変更の推奨などを支援します。これらは有用なアクセラレータですが、生成されたデプロイ判断は、予算、セキュリティポリシー、ベンチマーク結果に照らして検証されるべきです。エージェントは構成の不一致を特定することはできますが、明示的な制約なしに組織の許容可能なコストやリスクを判断することはできません。

他の選択肢との比較

Databricksは、データエンジニアリング、ガバナンス、アナリティクス、ノートブック、モデル開発、AIサービスにわたる広範なレイクハウス環境を提供します。データと運用のガバナンスが既にDelta LakeとUnity Catalogを中心に構築されている場合、自然な選択肢となります。AnyscaleはRayベースの分散実行に特化しており、データ、トレーニング、サービングにわたるカスタムPythonオーケストレーションが必要な場合に適しています。

Amazon SageMaker AIは、AWSネイティブの開発、トレーニング、デプロイ、レジストリ、ガバナンスサービスの広範なコレクションを提供します。AWSに注力している組織にとっては統合の手間が省けますが、ワークフローが複数の個別のSageMaker製品や構成モデルにまたがることがあります。Anyscaleはより統一されたRayプログラミングモデルを提供し、複数のクラウドプロバイダーにまたがって運用できます。

Google Vertex AIは、Google Cloud、BigQuery、Gemini、およびGoogleのマネージドMLサービスを中心に据える組織にとって同様の利点があります。より完全に管理されたモデルAPIやライフサイクル製品を提供しますが、Anyscaleは開発者に分散Pythonアプリケーションとオープンモデルランタイムに対するより大きな制御権を与えます。

Azure Machine Learningは、Azureのアイデンティティ、ネットワーク、レジストリ、パイプライン、エンドポイント、およびエンタープライズガバナンスと統合されています。AnyscaleのAzureデプロイは、リソースを自社のAzureテナント内に保持しつつ、共有計算エンジンとしてRayを使用したいチームに関連します。選択の基準は、主要な抽象化をAzure MLのアセットライフサイクルにするか、ポータブルなRayアプリケーションにするかによります。

Modalは、サーバーレスPython関数、コンテナ、定期ジョブ、および最小限のインフラ構成で利用できるGPUエンドポイントに特化しています。独立した関数やコンパクトなサービスには適しています。Anyscaleは概念的な範囲がより広いですが、ステートフルな分散アプリケーション、Rayライブラリ、大規模なデータパイプライン、およびマルチノード実行により適しています。

Runhouseは、既存の計算リソースをPython経由で利用可能にすること、およびローカルとリモート環境間で関数やサービスを移動させることに焦点を当てています。既にインフラを管理しているチームにとっては、より軽量な運用レイヤーとなります。Anyscaleは、スケジューリング、本番サービス、ガバナンス、フリートレベルの可視化など、Rayワークロードのためのより完全なマネージドコントロールプレーンを提供します。

自前運用のRayまたはKubeRayも、商用プラットフォームではありませんが重要な選択肢です。Anyscaleのプラットフォーム料金が不要になり、組織が完全に制御できるようになりますが、ランタイムのアップグレード、クラスターのライフサイクル、ダッシュボード、信頼性エンジニアリング、開発ツール、およびサポートの責務が内部のプラットフォームチームに移ります。比較すべきは、インフラの価格だけでなく、エンジニアリング工数とインシデント対応を含めた総コストです。

推奨される構成

まずは、実際のデータパスを動かす最小限の代表的なワークロードから始めてください。ランダムな入力を生成するノートブックでは構文の検証はできても、オブジェクトストアへの負荷、シリアル化のオーバーヘッド、パーティションの偏り、リモートストレージのボトルネック、あるいはモデルのロード時間などは表面化しません。

アプリケーションの構成とインフラの構成を分離してください。コードではタスクとアクターの要件を表現し、再利用可能な計算定義（Compute Config）では承認済みのノードファミリー、スポットポリシー、スケーリング制限、ネットワークを記述します。これにより、開発者ごとに少しずつ異なる本番クラスターが乱立するのを防げます。

性質の異なるワークロードには、専用のワーカーグループを使用してください。CPUによる前処理、GPU推論、コーディネーション、および軽量なサービスに、一律で同じインスタンスタイプを割り当てるべきではありません。明示的なリソースラベルと配置要件を設定することで、スケーラーが高価なアクセラレータ容量を浪費することなく各ステージを割り当てられるようになります。

永続的な入力、出力、チェックポイント、およびモデルアセットには、クラウドのオブジェクトストレージを優先してください。ノードローカルのディスクはキャッシュや一時ファイルには有用ですが、リトライやクラスターの入れ替え後も必要な状態を保持する唯一の場所にするべきではありません。

本番環境で使用するRayおよび依存関係の環境を固定（ピン留め）してください。新しいベースイメージやライブラリのバージョンを自動的に採用すると、シリアル化、スケジューリング、モデルカーネル、あるいはGPUの互換性が変わる可能性があります。一度に1つの環境ずつアップグレードし、昇格前に同じベンチマークと評価スイートを実行してください。

CI/CDおよび本番環境の自動化にはサービスアカウントを構成してください。個人のAPIキーはインタラクティブな開発のみに限定し、有効期限を短く設定し、イメージやリポジトリに埋め込まないでください。アプリケーションのシークレットは、コンソールで管理するプレーンテキストの環境変数ではなく、ワークロードアイデンティティを介してクラウドプロバイダーのシークレットマネージャーから取得すべきです。

プラットフォームを大規模な開発グループに開放する前に、最大クラスターサイズとアクセラレータクォータを設定してください。オートスケーリングは運用上便利ですが、誤った並列設定によって意図した以上の容量が要求される可能性があります。予算はあくまで通知の仕組みであり、強制的な停止制御ではないため、クラウドのクォータとAnyscaleのリソース制限によって強制力のある境界を設ける必要があります。

機密データや内部サービスを扱うワークロードでは、プライベートネットワークを使用してください。開発者のアクセス、コントロールプレーンの通信、オブジェクトストレージ、コンテナレジストリ、モデルのダウンロード、テレメトリ、および本番エンドポイントのトラフィックなど、経路全体を考慮する必要があります。最終的なモデルエンドポイントだけをプライベートにしても、データフローの残りの部分は保護されません。

ローカルRayからの移行

ローカルのRayアプリケーションは、クラスター規模に拡張する前に、まず確定的な（デターミニスティックな）動作とポータビリティを確保する必要があります。ローカルパス、プリインストールされたパッケージ、ホストの資格情報、およびプロセスグローバルな状態への依存を排除してください。入出力には、すべてのワーカーからアクセス可能な共有ストレージまたはクラウドURIを使用する必要があります。

リソース宣言は明示的に行う必要があります。ラップトップで成功するコードは、CPU、メモリ、またはGPUの可用性に暗黙的に依存している場合があります。分散クラスターでは、Rayはこれらの宣言を使用して作業をスケジュールするため、不正確な値はリソースの過剰割り当て、ハードウェアのアイドル、または配置できないタスクの原因となります。

シリアル化の境界を慎重にテストしてください。1つのローカルプロセス内では機能する関数、クラス、クロージャ、依存関係も、リモートワーカーに転送されると失敗することがあります。大きなオブジェクトは、一度保存するかRay Dataでストリーミングできる場合は、タスク定義内で繰り返しキャプチャしないようにしてください。

Anyscaleへの移行は段階的に進めてください。まずインタラクティブなワークスペースでローカルのワークロードを再現し、次にオフラインジョブとしてパッケージ化し、その後にスケジュール、リトライ、キュー、または本番データを追加します。これにより、アプリケーションのエラーとデプロイ・インフラのエラーを区別しやすくなります。

自前運用RayまたはKubeRayからの移行

標準のRay APIに基づいたアプリケーションは、根本的な書き直しなしに移行できることが多いですが、運用の構成は直接転送できません。Kubernetesのマニフェスト、Helmのチャート、オートスケーラーの設定、イングレス構成、およびカスタム監視スクリプトは、Anyscaleのクラウド、計算構成、イメージ、ジョブ、およびサービスにマッピングし直す必要があります。

移行前にすべての外部依存関係を棚卸ししてください。これには、オブジェクトストレージ、データベース、レジストリ、アイデンティティロール、シークレット、ダッシュボード、アラートルール、スケジューラー、CI/CDの資格情報が含まれます。現在のプラットフォームチームがインストールした複数のクラスターレベルのコンポーネントに依存している場合、ワークロードが自己完結しているように見えても注意が必要です。

代表的なワークロードを使用して、ランタイムの挙動を比較してください。マネージドなAnyscaleランタイムはRayとAPI互換ですが、プラットフォーム独自の最適化や運用の挙動が含まれており、起動、スケーリング、スケジューリング、またはパフォーマンスに影響を与える可能性があります。スループットの向上を移行の判断基準にする前に、出力の正確性を検証してください。

重要なサービスについては、一時的に両方の環境を並行稼働させてください。シャドウトラフィックを送信するか、記録されたリクエストを再生し、レイテンシと出力を比較します。その上でノードの消失、ロールアウト、およびスケールダウンの挙動をテストしてください。移行が完了したと言えるのは、単にデプロイ後に成功レスポンスが返ってきた時ではなく、運用手順とアラートが正常に機能した時です。

マネージドMLプラットフォームからの移行

SageMaker、Vertex AI、Azure Machine Learning、またはDatabricksからの移行は、単にトレーニングコマンドを翻訳する以上の作業を伴います。既存のシステムが、実験メタデータ、モデルレジストリ、パイプライン、機能アクセス、エンドポイント認証、リネージ、および承認ワークフローを管理している可能性があるためです。

どのシステムを信頼できる情報源（Authoritative System）として残すかを決定してください。Anyscaleは分散計算レイヤーとして機能しつつ、実行結果をMLflow、Weights & Biases、または別のレジストリに報告し続けることができます。周囲のすべてのサービスを同時に置き換えることは、ワークロードを必ずしも改善することなく、移行リスクを高めるだけです。

プロバイダー固有のパイプラインステップは、分散化する前に通常のPythonコンポーネントに変換してください。データアクセス、計算、アセットの公開、およびデプロイの間に明確な境界線を設けることで、Ray実装のテストが容易になり、プロバイダーSDKの呼び出しをコアなモデルロジックから分離できます。

モデルサービングのクライアントは、プラットフォームが生成したエンドポイントに直接依存するのではなく、安定した内部APIに依存するようにすべきです。これにより、ダウンストリームのすべてのアプリケーションを変更することなく、古いサービングシステムと新しいサービングシステムの間でトラフィックを移動させることが可能になります。

コストとキャパシティ計画

Anyscaleの料金は従量課金制であるため、一概に月額いくらとは言えません。総コストには、選択したCPUおよびGPUリソース、プラットフォーム利用料、永続ストレージ、イメージとモデルの転送、ネットワーク、アイドルの開発環境、失敗した試行、およびオプションのサポート契約が含まれます。

最適化のために考慮すべき単位は、「ワークロードの成功という成果に対するコスト」です。より高価なGPUであっても、バッチ処理を大幅に速く完了できれば全体として安くなる場合があります。一方で、入力の読み取りや単一の調整ステップがボトルネックとなり並列ワーカーが稼働できない場合、大規模なクラスターは無駄になります。

ステージごとに利用率を測定してください。1つのモデルレジストリが飽和状態にある一方で他のいくつかがアイドル状態である場合、全体のGPU利用率は許容範囲に見えてしまうことがあります。同様に、高いCPU利用率が、有用な前処理を反映しているのか、それとも過度なシリアル化・解凍作業によるものなのかを判断する必要があります。

スポットインスタンスは再試行可能なジョブのコストを削減できますが、まずチェックポイントとリトライ動作を設計しておく必要があります。中断されるたびに長いトレーニングが最初からやり直しになるのであれば、時間あたりの価格が低くても意味がありません。ミッションクリティカルなオンラインサービスでは、目標復旧時間（RTO）を反映したキャパシティ戦略を採用すべきです。

ゼロへのスケール（Scale-to-zero）はアイドル時のサービングコストを削減できますが、コールドスタートのレイテンシが発生します。モデルの重みサイズ、イメージキャッシュ、ノードの可用性、および初期化時間によって、このトレードオフが許容可能かどうかが決まります。平均トラフィックが低い場合でも、一部のアプリケーションでは最小限のウォームレプリカが必要です。

ワークロードの互換性がある場合、共有クラスターとジョブキューを利用して利用率を向上させることができます。ただし、これによって「うるさい隣人（Noisy Neighbor）」問題や予測不可能な待ち時間が発生する可能性もあります。複数のチームで予約容量を共有する前に、優先順位、プリエンプション、所有権、および最大同時実行数を定義しておく必要があります。

運用のトレードオフ

Rayは分散Pythonを身近なものにしますが、分散システムが1つの大きなプロセスのように動作するわけではありません。ネットワークの分断、ワーカーの消失、重複実行、部分的な出力、メモリ圧迫、データの偏り、バックプレッシャー、および依存関係の不一致などは、引き続きアプリケーション側の課題として残ります。

Anyscaleはチームが所有すべきインフラコードの量を減らしますが、開発者は依然としてRayのタスク、アクター、オブジェクトストア、データ、トレーニング、およびサービングのモデルを理解する必要があります。この知識がなければ、アプリケーションのボトルネックを解消する代わりに、すべての失敗に対してクラスターサイズを大きくすることで対応しようとしてしまう可能性があります。

BYOCはデータの制御を改善し、既存のリザーブドインスタンスの利用を可能にしますが、導入にはML、クラウド、ネットワーク、セキュリティ、および財務チーム間の協力が必要です。環境を保護するためのIAMやネットワークの制限が、設定を誤るとイメージのプル、ストレージへのアクセス、ダッシュボードへの接続、またはサービスルーティングを妨げる原因にもなります。

ホスト型クラウドは迅速な評価パスを提供しますが、本番環境の顧客ホスト型デプロイメントと同じリージョン、ネットワーク、インフラ、サポート、または監査オプションがあるわけではありません。ホスト型でのプロトタイプの成功を、エンタープライズデプロイメントの要件が既に解決された証拠と見なすべきではありません。

プロバイダー間のポータビリティにも限界があります。Rayのコードは環境を超えて動作しますが、インスタンス名、アクセラレータの可用性、IAMシステム、ストレージURL、ネットワーク構成、および価格設定は異なります。ポータビリティが最も高いのはアプリケーションレイヤーであり、インフラレイヤーでは相対的に低くなります。

エージェントスキルはドキュメントやログを読む時間を短縮できますが、生成された構成という新たな情報源を導入することになります。コーディングエージェントによって提案された変更は、手動で書かれたインフラコードと全く同じように、レビュー、バージョン管理、およびテストが行われるべきです。

したがって、Anyscaleは分散システムエンジニアリングを回避するための近道ではなく、Rayのためのマネージドな運用モデルとして評価するのが最善です。差別化につながらないプラットフォーム作業を大幅に取り除くことができますが、本番環境の信頼性は依然として、慎重なワークロード設計、測定、セキュリティ境界、およびキャパシティ計画にかかっています。