決意のAI 無料

-
開発元 決意のAI (HPE)
公式サイト https://www.determined.ai/

Determined AI は、分散トレーニング、自動スーパーパラメーター検索、GPU クラスター管理、実験追跡機能を提供し、PyTorch と TensorFlow をサポートするオープンソースの深層学習トレーニング プラットフォームです。

決意のAI 製品インターフェース

決意AI

AI のコアパラメータと統計を決定

Determined AI は「ディープ ラーニング トレーニング用のオペレーティング システム」として位置付けられており、ML エンジニアリングにおける最も困難な分散オーケストレーションの問題を解決します。トレーニング タスクが 1 枚のカードから複数のノードに拡張されると、コードの修正コスト、リソースの競合、実験の混乱がほぼすべてのチームにとって避けられない問題点となります。 Determined は、統合されたスケジューリング レイヤーを通じてこれらの問題をカプセル化し、研究者がモデル自体にのみ集中できるようにします。

プロジェクト 広報
公式の位置づけ オープンソースの深層学習トレーニング プラットフォーム
コア機能 分散トレーニング、ハイパーパラメータ検索、実験追跡 GPU クラスター管理
サポートされているフレームワーク PyTorch、TensorFlow、Keras (KerasTuner を含む)
導入方法 セルフホスト型: Kubernetes、ローカル エージェント クラスター Slurm/PBS、AWS/GCP
ポータルにアクセス Web UI、CLI (det)、Python SDK、REST API
オープンソースライセンス アパッチ2.0
コードリポジトリ GitHub determined-ai/determined (3.2k スター、372 フォーク、96 人の貢献者)
最新バージョン v0.38.1 (2025-03-20)
会社の所有権 HPE (Hewlett Packard Enterprise) – 2021 年の買収
テクノロジースタック Go (44.6%) / Python (27.9%) / TypeScript (24.4%)

一文での簡単なコメント: これは別の MLOps ダッシュボードではなく、「マルチマシンおよびマルチカード トレーニング」を手動構成から宣言的送信に変更するスケジューリング エンジンです。中心的な価値は、チームが単一マシンのコードを記述するという精神的負担を負った状態で分散トレーニングを完了できるようにすることです。

HPE 買収の背景: 買収後、エンタープライズ レベルのサポート リソースを取得することを決定しました。 EE (Enterprise Edition) バージョンではライセンス キーが必要になりました。 OSS バージョンと EE バージョンには、SSO や RBAC 監査などのエンタープライズ機能に機能の違いがあります。コミュニティは、OSS バージョンが EE バージョンと同じ品質のコア トレーニング機能のアップデートを受け取り続けるかどうかに注意を払う必要があります。

Determined AI のユーザーと市場の認知度

GitHub コミュニティ活動: ウェアハウスには 3.2,000 のスター、372 のフォーク、合計 121 のリリース (2026 年 7 月現在)、および 96 人の寄稿者がいます。これは、このプロジェクトがオープンソース MLOps の分野で安定した注目を集めているものの、まだ超人気のランクには入っていないことを示しています (MLflow などの類似プロジェクトにはより高いスターが付いています)。

エンタープライズ導入: HPE は、金融、製造、科学研究、その他の業界の HPC 顧客向けの AI インフラストラクチャ ソリューションに Determined を統合しています。公開されている導入事例は学術機関と中規模の ML チームが大半を占めていますが、大規模な企業での導入数は非公開です。

業界ベンチマーク: Kubeflow (完全な K8s ネイティブ MLOps) および MLflow (実験的な追跡 + モデル登録に偏ったもの) と比較すると、Determined の主な違いは、フルリンク オーケストレーションではなく、「トレーニング タスク自体のスケジューリングと高速化」にあります。分散トレーニングのサブフィールドでは、Horovod (分散通信層のみ) や Weights & Biases (実験的追跡のみ) と直接競合するのではなく、補完します。

寸法比較 決意のAI キューブフロー MLフロー ホロヴォド
ポジショニング トレーニング スケジュール プラットフォーム フルリンク MLOps 実験追跡 + モデル登録 分散型トレーニングコミュニケーションライブラリ
分散型トレーニング 自動オーケストレーション 手動構成が必要です 関与していない 通信プリミティブを提供する
ハイパーパラメータ検索 組み込み (グリッド/ベイジアン/ASHA) Katib を統合する必要があります 内蔵されていません 関与していない
クラスターのスケジューリング 組み込みキュー + クォータ K8s ネイティブ スケジューリング 関与していない 関与していない
始めるのが難しい 中 (K8s の基本が必要) 高 低い 中

Determined AI のコスト上の利点

C側/個人

オープンソース バージョンは完全に無料です (Apache 2.0)。個人は「pip install completed」を通じて CLI をインストールし、単一のマシンまたは独自の GPU にローカル クラスターをデプロイできます。ライセンス料はかかりませんが、独自の PostgreSQL とストレージ バックエンドを維持するための運用コストを負担する必要があります。

開発者/チーム

オープンソース バージョンにはソフトウェア ライセンス料金がかからず、チームは必要に応じて導入することを選択できます。

  • ローカル エージェント モード: マスター + エージェントをベア メタルまたは VM に展開します。運用とメンテナンスの複雑さが低く、既存の GPU サーバーを使用するチームに適しています。
  • Kubernetes モード: Helm Chart を通じてデプロイされ、すでに K8s インフラストラクチャを持っているが、K8s 管理機能が必要なチームに適しています。
  • クラウド デプロイメント: detdeploy aws/gcp up ワンクリック デプロイメント、クラウド リソースの実際の使用量に応じた支払い、追加のライセンス料はかかりません。

隠れたコストは主に、PostgreSQL データベース管理、ストレージ (S3/GCS/共有ファイル システム) 構成、ネットワークおよびセキュリティ グループ ポリシー、バージョン アップグレードと移行などの運用および保守の人件費に反映されます。

企業/民営化

HPE は、以下を含む Enterprise Edition を提供しています。

  • SSO/SAML の統合
  • RBACの詳細な権限監査
  • 商用 SLA およびテクニカル サポート
  • ProLiantサーバー、NimbleストレージなどのHPEハードウェアとの事前統合検証

Enterprise Edition の価格は公開されていないため、HPE Sales を通じて見積もりを入手してください。購入前に確認すべき重要な条件: ライセンスがノード/GPU またはユーザーの数に基づいて請求されるかどうか、実稼働環境に制限された SLA 応答時間、アップグレード パス、およびデータ移行のサポート範囲が含まれるかどうか。

コスト階層 原価構成要素 一般的な年間コスト (導出)
個人/小規模チーム (OSS) 0 ライセンス料金 + クラウド ホスト/GPU 料金 $0 + オンデマンドのクラウド リソース
中規模チーム（OSS + 自社運用保守） ライセンス料0円＋運用保守工数（約0.5～1人月/年） $5,000~$15,000 (運用保守換算)
エンタープライズ (HPE EE) ライセンス料 + サポート契約 + ハードウェア ビジネスの確認が必要です

Determined AIの主な機能

  • ゼロ修正分散トレーニング: ユーザーはトレーニング スクリプトで determined.pytorch.PyTorchTrial または determined.keras.KerasTrial 基本クラスを使用するだけでよく、プラットフォームは勾配同期 (All-Reduce)、データ シャーディング、およびノー​​ド フォールト トレランスを自動的に処理します。 「torch.distributed.launch」や「tf.distribute.Strategy」を手動で記述する必要がないため、分散トレーニングの参入障壁が低くなります。

    • エキスパート ビュー: この抽象化レイヤーの隠れた利点は、コードに分散ロジックを組み込むことなく、チームがシングルカードのプロトタイプからマルチカードの製品に直接移行できることです。その後 GPU の数を増やすには、トレーニング コードを変更せずに、YAML 設定の slots_per_trial を変更するだけで済みます。

  • 適応型ハイパーパラメータ検索 (ASHA): 非同期連続半減アルゴリズムに基づいて、リソースが限られている場合、可能性の低いトライアルが最初に削除され、より多くの計算能力が可能性の高いパラメータの組み合わせに割り当てられます。 Early Stopping、グリッド検索、ベイジアン検索をサポートし、検索プロセス中に検索スペースを動的に調整できます。

    • エキスパート ビュー: ASHA とプラットフォーム スケジューラの連携が Determined の主な違いです。検索アルゴリズムは、「次のパラメータ セットは何か」を判断できるだけでなく、プラットフォーム スケジューラを通じて「どのトライアルをプリエンプトできるか」を制御することもでき、クラスターがいっぱいになった場合に優先順位の低い検索トライアルを自動的にダウングレードし、ハイパーパラメータ検索が正式なトレーニング タスクをブロックすることを回避します。

  • GPU クォータとキューのスケジューリング: リソース プール (リソース プール) による GPU クォータの分割をサポートします。ユーザーが「det Experiment create」を通じてタスクを送信すると、プラットフォームは自動的にキューに登録され、スケジュールが設定され、スロットが割り当てられます。 Priority Scheduler と Fair Scheduler をサポートし、単一のユーザーがクラスターを占有することを防ぎます。

    • エキスパート ビュー: スケジューラ + クォータの組み合わせにより、「GPU のアイドリングと競合が共存する」という典型的なチームのジレンマが解決されます。研究者は、誰がいつカードを使用するかを手動で交渉する必要がなくなり、プラットフォームは、提出されたタスクが最終的にスケジュールされることを保証します。これにより、10 人以上のチームの調整コストが大幅に削減されます。

  • 実験追跡と自動スナップショット: インジケーター (損失/精度などの時系列)、ハイパーパラメーター構成、完全なコード スナップショット (Git コミット + 追跡されていないファイル)、および各トレーニングのモデル重みチェックポイントを自動的に記録します。 Web UI は複数の実験指標の比較と視覚化をサポートしており、Checkpoint はワンクリックでトレーニングを再開または継続できます。

    • エキスパート ビュー: コード スナップショットの自動インターセプトは手動記録よりも信頼性が高く、研究者がコミットを忘れた場合でも、プラットフォームは送信時にソース コードを自動的にアーカイブします。これは、特に複数の研究者がクラスターを共有する場合、実験の再現性にとって非常に重要です。 「このモデルがどのバージョンのコードで実行されたか」はもはや謎ではありません。

  • ノートブックおよび対話型タスク: クラスター GPU ノード上で Jupyter Notebook、TensorBoard、または Shell を起動すると、計算が GPU ノード上で直接実行されます。ノートブック内のデータとトレーニング タスクは同じストレージ層 (共有ファイル システムまたはオブジェクト ストレージ) を共有するため、データ前処理後のトレーニング タスクの直接送信が容易になります。

    • エキスパート ビュー: ノートブックとトレーニング タスクは GPU プールを共有します。つまり、同じカードでノートブックとトレーニングを同時に実行することはできません。インタラクティブなタスクが運用トレーニング リソースを占有するのを防ぐために、ノートブックを優先順位の低いリソース プールに制限するか、小さな GPU プールを分離することをお勧めします。

  • DeepSpeed の統合: バージョン 0.17.0 以降、DeepSpeed のサポートが組み込まれており、YAML 構成を通じて ZeRO 最適化 (ステージ 1/2/3) を有効にして、非常に大規模なモデル トレーニング シナリオでグラフィックス メモリの使用量を削減できます。 Determined の自動勾配同期と合わせて、ZeRO の通信モードとプラットフォーム スケジューラは連携して動作します。

  • コア API (下位レベルのインターフェイス): Trial 基本クラスを必要としない上級ユーザー向けに、Determined はコア API を提供します。これにより、ユーザーは最も煩わしくない方法でプラットフォーム機能を統合できます。トレーニング サイクル構造の変更を強制することなく、インジケーターを記録しチェックポイントを保存するためのコンテキストを取得するために「det.core.init()」のみを使用します。これは、Hugging Face Trainer などのサードパーティのトレーニング ライブラリと統合する場合に特に便利です。

Determined AI のモデルとバージョンの進化

Determined は、「OSS + EE」のデュアルトラック リリース戦略を採用しています。OSS バージョンはセマンティック バージョニングに従い、EE バージョンは OSS バージョン番号の後に「-ee」サフィックスを追加します。

メインライン リリース

バージョン番号 発売日 コアの変更点
v0.32.0 2026-05 (正式な正確な日付はまだありません) パフォーマンスの最適化とバグ修正を含む最新リリース バージョン
v0.38.1 2025-03-20 環境イメージの更新と依存関係の修復を含む、最新の安定バージョン
v0.38.0 2024-11-23 Searcher Context (アーキテクチャの簡素化)、タスク構成ポリシー (Config Policies) GA、Global Config Policies UI の削除
v0.37.0 2024-09-30 新しい実行オブジェクト (実行セントリック API)、ワークロード アラート (ワークロード アラート)、構成ポリシーの初期サポート
v0.36.0 2024-08-24 Flat Runs ビュー GA、RBAC Webhook、Data Lineage の初期サポート
v0.35.0 2024-08-09 Flat Runs 比較ビュー、メタデータ フィルター検索、K8s ポッドからジョブ送信、フレームワーク分割 (フレームワーク分割)
v0.34.0 2024-06-29 ノートブック トークン認証 K8s ノード セレクター/アフィニティは、実行の一時停止/再開をサポートします。
v0.33.0 2024-05-30 WebUI テンプレート管理 Flat Runs 並べ替え/フィルタリング、ヒート マップ (ヒートマップ)、Helm パスワードの複雑さのチェック
v0.32.0 2024-04 (正式な正確な日付はまだありません) テンプレート CRUD API、K8s マルチ RM サポート、試験的なバッチ操作

バージョン管理の観察

  • ペース: 2024 年は月に約 1 つのマイナー バージョンの反復頻度を維持しますが、2025 年に入るとペースは遅くなります (v0.38.1 は 2025-03 年にリリースされます)。これは、製品の成熟度の向上またはチーム リソースの調整を反映している可能性があります。
  • アーキテクチャの進化: v0.35 から v0.38 までの中心的なトレンドは、「実験/トライアル集中化」から「実行集中化」(フラット ラン) への移行と、マルチテナント ガバナンス機能を強化するための構成ポリシーの導入です。
  • エンタープライズ エディションの違い: EE バージョンは、SSO の改善 (v0.38.0 以降)、ライセンス キーの検証、RBAC 監査ログなどのエンタープライズ機能で OSS よりも優れています。OSS ユーザーは、これらの機能が徐々にコミュニティ バージョンに移行されるのか、それとも長期間 EE 専用のままになるのかに注意する必要があります。

Determined AI の技術的利点

宣言型トレーニング構成: ユーザーは YAML を通じてトレーニング ハイパーパラメーター、リソース要件 (「slots_per_trial」)、検索アルゴリズム、およびスケジュール戦略を定義し、プラットフォームはそれに応じてトライアルを生成し、実行をスケジュールします。この宣言型抽象化の主な利点は、研究者が「方法」ではなく「何を行うか」を説明し、プラットフォームがバックグラウンドでのクラスター負荷に基づいて「どのマシンで実行する GPU の数」を自動的に決定することです。

自動勾配同期 (All-Reduce アグリゲーション): Determined の Harness コンポーネントは、ユーザー トレーニング コードの上に勾配同期ロジック (NCCL または Gloo に基づく) を自動的に挿入するため、ユーザーが分散通信コードを記述する必要がなくなります。複数のトライアルは、それぞれに割り当てられたスロットで個別に順方向/逆方向に実行されます。 Harness は、各 backward()` の後に All-Reduce 集約勾配を自動的に実行して、各ノードのモデル パラメーターの一貫性を確保します。このメカニズムにより、トレーニング スクリプトに触れることなく、YAML の「slots_per_trial」を変更するだけで、単一のカードから複数のカードに拡張できます。

ASHA 検索のコラボレーションのスケジュール設定: 従来のハイパーパラメータ検索ツールはスケジューラとは独立して実行され、検索されたトライアルは依然としてリソースのキューに入れられる必要があります。 Determined は、サーチャーとスケジューラーを深く統合します。サーチャーが次のパラメーターのセットを決定した後、スケジューラーは、トライアルを直ちに開始するかどうか、および現在のクラスターの負荷に基づいて優先順位の低いトライアルをプリエンプトするかどうかを決定します。この共同設計により、クラスターがいっぱいになったときにハイパーパラメーター検索が実稼働トレーニング タスクをブロックしないようにすることができます。検索トライアルはプリエンプティブルとしてマークされ、優先度の高いタスクが送信されると GPU が自動的に解放されます。

デュアルトラック スケジューリング (エージェント RM + K8s RM): エージェント RM (セルフマネージド エージェント クラスター) と K8s RM (Kubernetes ネイティブ スケジューリング) の 2 つのリソース管理モードをサポートすることが決定されました。 Agent RM はベア メタル/HPC 環境に適しており、K8s への依存関係を必要とせず、展開がより軽量です。 K8s RM は、すでに K8s インフラストラクチャを持っているチームに適しており、K8s の自動拡張と縮小、名前空間の分離、その他の機能を利用できます。両方を同時に有効にすることができ (マルチ RM)、同じマスターが異種クラスターを管理できるようになります。

Checkpoint のストレージ抽象化: Checkpoint は、共有ファイル システム S3/GCS オブジェクト ストレージ (HDFS) へのストレージをサポートします。プラットフォームはチェックポイント ライフ サイクル (GC ポリシー) を自動的に維持し、ストレージ層全体でのデータ移行を構成できます。この抽象化により、トレーニング クラスターのストレージと計算が切り離されます。トレーニング ノードはステートレス インスタンスにすることができ、チェックポイントは外部オブジェクト ストレージに保存されるため、実験が失敗した後の迅速な回復が容易になります。

パフォーマンス プロファイリングの組み込み: Web UI にはトレーニング パフォーマンス分析ツールが組み込まれており、GPU 使用率、データ読み込みスループット、通信率などの指標を表示して、トレーニングのボトルネック (データ読み込みがボトルネックなのか通信がボトルネックなのかなど) を特定するのに役立ちます。この機能では、Prometheus/Grafana を追加統合する必要がなく、パフォーマンス チューニングのためのツール チェーンの複雑さが軽減されます。

コード ウェアハウスのメイン言語として Go を選択した (44.6%) ことは、マスター コンポーネントの同時実行パフォーマンスに対する高い要件が高いことを示しています。マスターは、数百のエージェントのハートビート、スケジュール決定、API リクエストを同時に管理する必要があります。このシナリオでは、Go の Goroutine モデルは Python よりも効率的です。 Python (27.9%) は Harness (トレーニング ランタイム) と SDK に使用され、TypeScript (24.4%) は Web UI に使用されています。

Determined AI の使い方

CLI をインストールしてクラスターを起動します

「」バッシュ

CLI をインストールする

pip インストールが決定されました

ローカル クラスター (単一マシンでの迅速なエクスペリエンス)

det デプロイ ローカル クラスターアップ

AWSDeployment

デプロイ aws アップ

GCP デプロイメント

det デプロイ gcp アップ 「」

トレーニング タスクを送信する

トレーニング スクリプトの適応 (PyTorch の例):

「」パイソン completed.pytorch から PyTorchTrial、DataLoader、PyTorchTrialContext をインポート

クラス MyTrial(PyTorchTrial): def init(self, context: PyTorchTrialContext): self.context = コンテキスト self.model = self.context.wrap_model(nn.Sequential(...))

def train_batch(self、batch、epoch_idx):
    loss = self.model(バッチ)
    self.context.backward(損失)
    self.context.step_optimizer(self.optimizer)
    return {"損失": 損失}

「」

YAML 設定ファイル (experiment.yaml):


名前: my_experiment
エントリポイント:train.py
ハイパーパラメータ:
  学習率:
    タイプ: ダブル
    最小値: 0.0001
    最大値: 1.0
検索者:
  名前: アダプティブ_アシャ
  メトリクス: 損失
  小さいほうが良い: true
  最大試行数: 100
リソース:
  トライアルごとのスロット数: 8
「」

コマンドを送信します:

「」バッシュ
det実験はexperiment.yamlを作成します。
「」

### 導入オプションの比較

|導入方法 |該当するシナリオ |前提条件 |メンテナンスの複雑さ |
|---|---|---|---|
|ローカル クラスター (「detdeploy local」) |個人開発/複数のカードを備えた 1 台のマシン |ドッカー |低い |
| AWS `detdeploy aws` |クラウドでのクイック スタート | AWS アカウント + クォータ |中 |
| GCP `det デプロイ gcp` |クラウドでのクイック スタート | GCP アカウント + 割り当て |中 |
| Kubernetes ヘルム チャート |既存の K8s クラスター | K8s クラスター + Helm 3 |中～高 |
|エージェントの手動展開 |ベアメタル/HPC | PostgreSQL + 共有ストレージ |高 |
| Slurm/PBS の統合 | HPC クラスター |スラーム/PBS コンテキスト |高 |

**迅速な検証パス**: 個々の開発者は、マスターとエージェントを含む単一ノード クラスターをローカルで 5 分以内にプルアップし、公式の MNIST サンプル検証コア プロセスを実行できる「pip install dedicated && detdeploy local cluster-up」を推奨します。

## 決定的な AI の製品価格

Determined AI は、「オープンソース コア + エンタープライズ バージョン」のデュアルトラック価格モデルを採用しています。

- **オープン ソース バージョン (OSS)**: Apache 2.0 ライセンス。分散トレーニング、スーパー パラメーター検索、実験追跡およびスケジューリングを含む完全な機能を備えています。使用制限や GPU の上限はありません。自己運用およびメンテナンス機能を持つ個人、学術チーム、中規模のチームに適しています。
- **Enterprise Edition (HPE Enterprise Edition)**: OSS に基づいて、SSO/SAML 統合 RBAC のきめ細かい権限監査と、HPE ハードウェア事前統合検証用の商用 SLA サポートが追加されています。価格は HPE Sales を通じて年間サブスクリプションベースで入手でき、特定の請求単位 (ノード/GPU/ユーザー) は開示されていません。
- **クラウド ホステッド エディション**: HPE は SaaS ホスティングを提供しておらず、すべての展開はセルフホステッドです。操作不要のエクスペリエンスが必要な場合は、「detdeploy aws/gcp」を通じてクラウド上ですぐに起動できますが、管理と監視は依然としてチームの責任です。

|バージョン |ライセンス |価格 |適用スケール |
|---|---|---|---|
| OSS |アパッチ2.0 |無料 |個人から中規模のチーム (GPU 100 基未満) |
| EE |商用ライセンス |ビジネスの確認が必要です |中規模および大規模企業 (100 個以上の GPU) |

Enterprise Edition を購入する前に、GPU の数に基づいた段階的な価格設定をサポートしているかどうか、実稼働対応の 24 時間年中無休のサポート、アップグレード、およびデータ移行に関する特定の条件が含まれているかどうかを HPE に確認する必要があります。

## 決定された AI アプリケーション シナリオ

- **マルチ GPU クラスター トレーニング管理**: チームが 10 ～ 100 個の GPU を共有する場合、Determined のキュー スケジューリングはアイドル状態の無駄を効果的に削減します。研究者は、誰がいつカードを使用するかを手動で調整する必要がなくなりました。スーパーパラメータ検索はパラメータ空間を自動的にスキャンするため、パラメータを手動で変更して再実行する必要がなくなります。 **検証のポイント**: キュースケジューリングにおいて優先度の高いタスクが頻繁に投入される場合、優先度の低い検索試行が正しくプリエンプトされて復元できるかどうか。

- **標準化された実験パイプライン**: コードのスナップショット、ハイパーパラメーター、インジケーター、チェックポイントがトレーニングごとに自動的に記録されます。新しい研究者がプロジェクトを引き継ぐと、Web UI で過去の実験を直接表示したり、ワンクリックで実験を再現したり、指定されたチェックポイントからトレーニングを継続したりすることができます。 **検証すべき重要なポイント**: コード スナップショットに追跡されていないローカルで変更されたファイルが完全に含まれているかどうか、およびチェックポイント GC 戦略が時期尚早な削除につながる可能性があるかどうか。

- **非常に大規模なモデル トレーニング (DeepSpeed 統合)**: 数百億のパラメーターを使用したモデル トレーニングの場合、ZeRO Stage 2/3 はビデオ メモリの使用を最適化し、Determined の自動マルチノード スケジューリングと連携して、大規模なモデル トレーニングのインフラストラクチャのしきい値を下げます。 **検証の焦点**: DeepSpeed バージョンと確定バージョンの互換性 ZeRO Stage 3 での通信効率。

- **ハイブリッド クラウド/異種クラスタのトレーニング**: マルチ RM を通じてクラウド上のローカル ベア メタル クラスタと K8s クラスタの管理を統合し、トレーニング タスクはリソース要件に従って利用可能なノードに自動的にスケジュールされます。 **検証の焦点**: クラスター間のチェックポイント同期メカニズムとネットワーク遅延が分散トレーニングに及ぼす影響。

- **HPC/学術研究コンピューティング**: Determined を Slurm/PBS クラスターに展開して、手動でジョブを送信する従来の SSH 方法に代わって、トレーニング タスクを送信するための Web UI を科学研究者に提供します。組み込みの実験追跡により、「パラメータの記録忘れ」によって引き起こされる再現不可能な問題が軽減されます。 **検証の焦点**: Slurm の統合バージョンは Job Array をサポートし、既存の HPC スケジューリング戦略と共存します。

## Determined AI の該当グループ

- **ディープ ラーニング研究者/アルゴリズム エンジニア**: 分散コード適応の作業負荷を軽減し、実験パラメータと結果を自動的に記録し、ワンクリックで複数の実験指標セットを比較することを期待して、頻繁に分散トレーニング実験を実施する必要があります。その価値は、GPU が 5 ～ 50 個ある中規模のチームで最も顕著になります。

- **ML インフラストラクチャ/プラットフォーム エンジニア**: チームのトレーニング インフラストラクチャの構築を担当します。 「提出してトレーニングする」というセルフサービスのプラットフォームを提供し、「研究者が環境を設定し、ドライバーを調整し、パッケージをパッケージ化するのを支援する」という日常的なサポート作業を軽減したいと考えています。 K8s/PostgreSQLの運用保守コストと効率向上のバランスを評価する必要があります。

- **HPC クラスター管理者**: Slurm/PBS クラスターを管理し、ジョブの優先順位とリソース クォータを制御する機能を維持しながら、研究者が Web UI を通じてクラスターを使用するためのしきい値を下げることを目指します。既存のスケジューラとの互換性の確認と交換コストを確認する必要があります。

- **技術的意思決定者 (CTO/VP Eng)**: MLOps プラットフォームの選択を評価するには、Kubeflow/MLflow/Determined の機能範囲と運用保守コストを比較する必要があります。 Determined は「トレーニング効率の向上」という 1 つの側面において優れた競争力を持っていますが、チームが完全なモデルのデプロイメントとモニタリングのリンクを必要とする場合は、他のツールと組み合わせる必要がある場合があります。

**群衆には適していません**:
- 1 枚のカードでニーズを満たすことができる小規模なチームや個人の場合、Determined のクラスターの導入とメンテナンスのコストがメリットよりも高くなる可能性があります。 `torchrun` または `python train.py` を直接使用する方が軽量です。
- 完全な推論展開 + A/B テスト + モデル監視リンクを必要とするチームの場合、Determined には推論サービス コンポーネントが含まれていないため、KServe/Seldon などのツールと組み合わせる必要があります。
- K8 への必然的な依存に抵抗するチーム - エージェント RM モードは利用可能ですが、ほとんどの高度な機能 (マルチ RM、自動スケーリング) は依然として K8 に依存しています。

## 決定された AI の概要と展望

**コア コンピテンシー**: Determined AI は、「分散トレーニング スケジューリング」の垂直分野において、オープン ソース コミュニティに最も完全なすぐに使えるソリューションを提供します。宣言型 YAML 構成 + 自動勾配同期 + ASHA 検索 + GPU クォータ管理の組み合わせにより、マルチマシンおよびマルチカードのトレーニングが「各チームが独自のホイールを作成する」から「トレーニングとしての構成」に変わります。 GPU リソースを大量に消費する (10 個以上の GPU) ML チームの場合、トレーニング コードを変更することなく、GPU の使用率と実験の効率を大幅に向上させることができます。

**現在の制限事項**:
- 学習曲線は、K8s のデプロイメントと YAML 構成の理解に重点を置いています。コンテナ化されていないチームの場合、最初のデプロイには 1 ～ 2 週間かかる場合があります。
- OSS バージョンと EE バージョンの間の機能のギャップについては不確実です - SSO や RBAC 監査などのエンタープライズ機能は、長い間 EE バージョンにロックされてきました。 OSS バージョンがコア トレーニング機能の完全な反復進行状況を維持できるかどうかはまだわかりません。
- コミュニティのサイズ (3.2,000 スター) は、Kubeflow (~14,000 スター) や MLflow (~18,000 スター) よりも小さく、サードパーティの環境への貢献やコミュニティの問題への対応速度が制限される可能性があります。

**調達/導入リスク評価**: チームはまず OSS バージョンをパイロットとして既存のクラスターにデプロイし、1 ～ 2 つの典型的なトレーニング タスク (非コア実稼働タスク) を選択して、分散トレーニングの使いやすさとスケジュール効果を検証することをお勧めします。パイロット期間中は、次の 3 つの重要な指標に注意を払うことをお勧めします。 (1) トレーニングの提出からトレーニングの開始までの平均待ち時間 (手動調整の改善度の比較)。 (2) ハイパーパラメータ検索の導入後、最適なパラメータを見つけるために必要な試行回数と GPU 時間。 (3) 研究者がプラットフォームに切り替えた後のコード変更の作業負荷 (少ないほど、抽象化層の効果が高くなります)。パイロット検証に合格した場合は、EE バージョンのエンタープライズ機能が必要かどうかを評価し、その過程で EE バージョンの価格条件とデータ移行パスを HPE に確認します。

関連ツール: hugging-face、replicate

バージョン情報

  • 決定 0.32.0 ：公式の正確な日付はまだありません。
  • 決定 0.28.0 ：公式の正確な日付はまだありません。

ユーザーレビュー

  • レビューを読み込み中...