Wuyun ネイティブ AI プラットフォーム - KubeAI の実装プロセスを理解するための 1 つの記事

1. はじめに

ここ数年、コンテナ技術に代表されるクラウドネイティブ分野が大きな注目と発展を遂げており、コンテナ化の導入は企業にとってコスト削減と効率化を図るための重要なステップとなっています。現在までに、Dewu はドメイン全体のコンテナ化を基本的に完了しています。コンテナ化のプロセスでは、サービスの導入と運用保守の方法が以前の ECS モードからコンテナ化モードにスムーズに切り替わった一方で、同社はリソース利用率と研究開発効率の面で多くの効率向上を達成しました。 。

Dewu は、新世代のトレンディなオンライン ショッピング コミュニティです。AI とビッグデータ技術に基づいた検索エンジンとパーソナライズされたレコメンデーション システムがビジネス展開を強力にサポートします。そのため、アルゴリズム ドメインのアプリケーションがビジネスの 10% を占めています。膨大な割合のアプリケーションです。コンテナ化プロセスでは、アルゴリズム アプリケーション サービスと通常のサービスの研究開発プロセスの違いを考慮し、アルゴリズム ドメインにおける研究開発学生のニーズを十分に調査したことに基づいて、Dewu クラウド ネイティブ AI プラットフォーム - KubeAI プラットフォームを構築しました。アルゴリズムドメインの研究開発シナリオ。機能の継続的な反復とサポートされるシナリオの継続的な拡張を経て、KubeAI は現在、CV、検索レコメンデーション、リスク制御アルゴリズム、データ分析などの AI 機能を含むビジネス ドメインをサポートし、コンテナ化を正常に完了し、リソース利用率と研究開発効率を向上させています。この記事では、誰もが KubeAI の実装プロセスを理解できるようにします。

2. AI ビジネスのコンテナ化推進

2.1 AI アルゴリズム モデルの開発プロセス

AI ビジネスは、どちらかというとモデルの反復的な開発プロセスです。これは次の手順に要約できます。

需要シナリオを決定する: このプロセスでは、どのような問題が解決されるのか、どのようなシナリオが機能に提供されるのか、そして何が機能するのかを明確に定義する必要があります。関数/サービスの入力は何ですか? 出力は何ですか?たとえば、どのブランドの靴を特定または品質検査する必要があるか、ブランドの製品の特徴は何か、サンプルの特徴のサイズはどのくらいか、特徴の種類などです。シナリオが異なれば、サンプル データと使用される処理アルゴリズムに対する要件も異なります。

データ準備: シナリオ需要分析の結果に応じて、さまざまな方法 (オンライン/オフライン/モックなど) でサンプル データを取得し、データに対して必要なクリーニングやラベル付けなどの操作を実行します。以降のプロセスはすべてデータに基づいて行われるため、このプロセスが AI ビジネス開発の基礎となります。

アルゴリズムを決定し、トレーニング スクリプトを作成する: ビジネス目標の理解に基づいて、このリンクでアルゴリズムの受講生は適切なアルゴリズムを選択し、過去の経験または経験に基づいてモデル トレーニング スクリプトを作成します。現場調査と実験結果。

モデルのトレーニング: アルゴリズム モデルの場合、複雑な数式として理解できます。この式には、f(x)=wx b の w と b のように、多くのパラメーターが含まれます。トレーニングとは、モデルの認識率を高めるために、大量のサンプル データを使用して最適なパラメーターを見つけるプロセスです。モデルのトレーニングはAIビジネス開発プロセスにおいて非常に重要な部分であり、ビジネス目標の達成はモデルの精度に依存すると言えます。したがって、このリンクは他のリンクよりも多くの時間、エネルギー、リソースを必要とし、最高のモデル精度と予測精度を達成するには実験トレーニングを繰り返す必要があります。このプロセスは一度だけではなく周期的であり、ビジネスシナリオの更新やデータの更新に応じて定期的に実行する必要があります。アルゴリズム モデルの開発とトレーニングのために、業界には TensorFlow、PyTorch、MXNet などの主流の AI エンジンから選択できるものがあります。これらのエンジンは、アルゴリズム開発者が複雑なモデルを配布しやすくするために、ある程度の API サポートを提供できます。 、またはハードウェアを最適化してモデルのトレーニング効率を向上させます。モデルの学習結果としてモデルファイルが得られますが、このファイルの内容はモデルのパラメータを保存するものと理解できます。

モデルの評価: 過剰な偏差によるモデルのアンダーフィッティングや過剰な分散によるオーバーフィッティングを防ぐために、通常、開発者がモデルの汎化能力を評価するように導くために、いくつかの評価指標が必要です。一般的に使用される評価指標には、適合率、再現率、ROC 曲線/AUC、PR 曲線などがあります。

モデルの展開: トレーニングと評価を繰り返した後、ビジネスのオンライン/実稼働データの処理に役立つ理想的なモデルを取得できます。これには、入力データを受け入れて推論結果を提供するという目的を達成するために、モデルをサービスまたはタスクの形式でデプロイする必要があり、このサービスをモデル サービスと呼びます。モデル サービスは、モデルをロードするオンライン サービス スクリプトであり、準備が完了すると、前処理されたデータに対して推論計算を実行します。

モデル サービスの開始後、データ特性の変更、アルゴリズムのアップグレード、オンライン推論サービス スクリプトのアップグレード、推論インジケーターの新しいビジネス要件などにより、モデル サービスを反復する必要があります。この反復プロセスではモデルの再トレーニングと再評価が必要になる場合がありますが、推論サービス スクリプトの反復アップグレードだけの場合もあることに注意してください。

2.2 コンテナ化移行の本格化

昨年以来、Dewu のさまざまなドメインでビジネス サービスのコンテナ化の実装を段階的に推進してきました。コンテナ化プロセス中のデプロイ方法の変更によって引き起こされるユーザーの操作習慣の変化を軽減するために、私たちは引き続き公開プラットフォームのデプロイ プロセスを使用して、コンテナのデプロイと ECS デプロイの違いを保護します。

CIプロセスでは、開発言語の種類に応じて異なるコンパイル・構築テンプレートをカスタマイズし、ソースコードのコンパイルからコンテナイメージの作成までをコンテナプラットフォーム層で均一に完結することで、通常の課題を解決します。研究開発学生のコンテナに対する悩み 知識不足でエンジニアリングコードをコンテナイメージ化できないことが問題。 CD プロセスでは、アプリケーション タイプ レベル、環境レベル、および環境グループ レベルで構成を階層的に管理し、デプロイメントを実行するときに、多層構成を Helm Chart の value.yaml にマージし、オーケストレーション ファイルをコンテナクラスター。ユーザーは、実際のニーズに応じて対応する環境変数を設定し、デプロイメントを送信して、アプリケーション クラスター インスタンス (ECS サービス インスタンスと同様のコンテナ インスタンス) を取得するだけで済みます。

コンテナ プラットフォームでは、アプリケーション クラスターの運用と保守のために、ECS インスタンスにログインするのと同じように、WebShell 経由でコンテナ インスタンスにログインする機能が提供されます。これは、アプリケーション プロセス関連の問題のトラブルシューティングに便利です。 ; コンテナ プラットフォームは、ファイルのアップロードとダウンロード、インスタンスの再起動と再構築、リソースの監視、その他の運用およびメンテナンス機能も提供します。

AI ビジネス (CV、検索とレコメンデーション、リスク制御アルゴリズム サービスなど) は、比較的大きなビジネスとして、通常のビジネス サービスとともにコンテナ化プロセスに参加しており、コミュニティとウォーターフォールが徐々に完成しています。トランザクション フローとヴァジュラの位置で表されるコア シーン サービスの移行。コンテナ化後は、テスト環境のリソース利用率が大幅に向上し、本番環境も大幅に改善され、運用保守効率が2倍になりました。

2.3 アルゴリズムの学生は苦痛に耐えられない

コンテナ化のプロセスには企業のテクノロジー システムの急速な発展が伴い、初期の未熟な AI サービスの研究開発プロセスはコンテナ化を困難にしています。要求が提起されたことで、当初はオンライン推論サービスのコンテナ化のみに焦点を当てていた私たちも、アルゴリズムの学生がモデル開発プロセスで直面する問題点や困難を理解できるようになりました。

#問題点 1: モデルの管理と推論サービスの管理が一貫していません。ほとんどの CV モデルはデスクトップ コンピューターでトレーニングされてから OSS に手動でアップロードされ、OSS 上のモデル ファイルのアドレスがオンライン推論サービスに構成されます。ほとんどの Soutui モデルは PAI でトレーニングされますが、OSS にも手動で保存され、リリース時には CV に似ています。モデル製品の管理は、モデルのトレーニングとリリースのプロセスで一貫性がなく、モデルがどのサービスにデプロイされているかを追跡することは不可能であり、サービスがどのサービスにデプロイされているかを直感的に確認することは不可能です。または、複数のモデルがあり、モデルのバージョン管理が不便です。

問題点 2: モデル開発環境の準備に時間がかかり、リソースを適用して使用するための柔軟な仕組みが不足しています。コンテナ化以前は、リソースは ECS インスタンスの形で提供されるのが一般的でした。リソースを申請するプロセスを経る必要があり、申請後はさまざまな初期化作業、ソフトウェアのインストール、依存関係のインストール、データの転送 (ほとんどの場合、アルゴリズムの研究作業で使用されるソフトウェア ライブラリはサイズが大きいため、インストールも複雑になります）。 ECSを導入した後、後でリソースが不足した場合には、再度申請を行って同じ手順を踏む必要があり、非効率です。同時に、リソースのアプリケーションにはクォータ (予算) の制約があり、自律的な管理や柔軟なアプリケーションとオンデマンドのリリースのメカニズムが欠けています。

問題点 3: クラウド ネイティブでサポートされている一部のモデル ソリューションを試すのは困難です。クラウド ネイティブ テクノロジーがさまざまな分野で導入され続ける中、Kubeflow や Argo Workflow などのソリューションは AI シナリオを適切にサポートします。例: tfjob-operator は、CRD 形式の TensorFlow フレームワークに基づいて分散トレーニング タスクを管理できます。ユーザーは、トレーニング タスクを Kubernetes に送信する前に、対応するコンポーネント (Chief、PS、Worker など) のパラメータを設定するだけで済みます。集まる。コンテナ化以前は、アルゴリズムの学生がこのソリューションを試したい場合は、Docker や Kubernetes などのコンテナ関連の知識に精通し、習得する必要があり、通常のユーザーとしてこの機能を使用することはできませんでした。

問題点 4: アルゴリズム以外の部門がアルゴリズムを迅速に検証したい場合、それを適切にサポートできるプラットフォームが見つかりません。 AI の機能はさまざまなビジネス分野、特に一部の成熟したアルゴリズムで明らかに使用されており、ビジネス チームは AI を簡単に使用して、ベースライン指標の予測や分類予測を行うことができ、ビジネスでより良い結果を達成するのに役立ちます。現時点では、異種リソース (CPU/GPU/ストレージ/ネットワークなど) とアルゴリズム モデル管理に関するこれらのシナリオのニーズを満たし、ユーザーにすぐに使用できる機能を提供する AI 関連機能を提供できるプラットフォームが必要です。関数を使用します。

上記の問題点と困難な問題の精査と分析、およびコンテナ化プロセス中にコンテナ プラットフォームについてアルゴリズムの学生によって提案されたその他の要件 (モデルの統合管理要件、ログ収集要件、リソースなど) に基づいています。プール要件、データ永続化要件など）を 1 つずつ議論して解決し、現在の問題を解決しながら、プラットフォームの長期的な機能計画も検討し、徐々に KubeAI プラットフォーム ソリューションを構築していきました。コンテナプラットフォームとAIビジネスを指向。

3. KubeAI プラットフォーム ソリューション

AI ビジネス シナリオとその周囲のビジネス ニーズに焦点を当て、業界における AI プラットフォームの基本アーキテクチャと製品形態を徹底的に調査研究したことに基づいて、コンテナ テクノロジーチームは、コンテナ化プロセス中にクラウドネイティブ AI プラットフォームである KubeAI プラットフォームを設計し、段階的に実装しました。 KubeAI プラットフォームは、アルゴリズム学習者の悩みの種のニーズを解決することに焦点を当てており、モデル開発、リリース、運用およびメンテナンスのプロセス全体にわたって必要な機能モジュールを提供し、アルゴリズム開発者が AI インフラストラクチャ リソースを迅速かつコスト効率よく取得して使用し、アルゴリズムを迅速に実行できるように支援します。モデルの設計、開発、実験。

3.1 全体的なアーキテクチャ

KubeAI プラットフォームは、モデルのライフサイクル全体にわたって次の機能モジュールを提供します。

データ セット管理: Main さまざまなデータ ソースと互換性があり、データ キャッシュの高速化機能を提供します。

モデル トレーニング: モデルの開発とトレーニング用の Notebook を提供するだけでなく、1 回限り/定期的なタスクの管理もサポートします。このプロセスでは、異種リソース (CPU/GPU/ストレージ) が柔軟に適用されます。そして解放されました。

モデル管理: モデルのメタデータ(モデルの基本情報、バージョンリストなど)を一元管理し、モデルのサービスリリースや運用保守プロセスとシームレスに連携します。

推論サービス管理: モデルを推論コードから切り離すことで、モデルをイメージにパッケージ化する必要がなくなり、推論サービスの更新効率が向上し、オンライン サービスのモデルのアップグレードがサポートされます。

AI パイプライン エンジン: データ分析、モデルの定期的なルーチン トレーニング タスク、モデルの反復、およびその他のシナリオのニーズを満たすために、パイプライン方式でタスクを配置することをサポートします。

KubeAI プラットフォームは個人ユーザーをサポートするだけでなく、プラットフォーム ユーザーもサポートします。個人の開発者は、KubeAI の Notebook を使用してモデル スクリプトを開発します。小規模なモデルは Notebook で直接トレーニングでき、複雑なモデルはタスクを通じてトレーニングできます。モデルの作成後は、推論サービスとして公開したり、新しいバージョンを反復したりするなど、KubeAI 上で均一に管理されます。サードパーティのビジネス プラットフォームは、上位層のビジネス イノベーションのために OpenAPI を通じて KubeAI の機能を取得します。

以下では、データセット管理、モデルトレーニング、モデルサービス管理、AI パイプライン エンジンの 4 つのモジュールの機能に焦点を当てます。

3.2 データセット管理

アルゴリズムの受講生が使用するデータは、整理後、NAS に保存されるか、ODPS から読み取られるか、OSS から取得されます。データ管理を統合するために、KubeAI は Kubernetes PVC (Persistent Volume Claim) リソースに基づいてユーザーにデータセットの概念を提供し、さまざまなデータ ソース形式と互換性があります。同時に、コンピューティング アーキテクチャとストレージ アーキテクチャの分離によって引き起こされる高いデータ アクセス オーバーヘッドの問題を解決するために、Fluid を使用してデータ セットのキャッシュ サービスを構成します。データは次のラウンドのためにローカルにキャッシュできます。反復計算、またはタスクをスケジュールすることができます。 データ セットはコンピューティング ノードにキャッシュされています。

3.3 モデル トレーニング

モデル トレーニングでは、主に 3 つの作業側面を実行します。

(1) JupyterLab に基づいて、以下を提供します。ノートブック機能により、ユーザーはローカルと同じ開発モードでシェルまたは Web IDE を介してアルゴリズム モデルを開発できます。

(2) モデルのトレーニングはタスクの形式で実行されるため、リソースの申請と解放がより柔軟になり、リソースの使用率が向上し、モデルのトレーニングのコストが大幅に削減されます。 Kubernetes の優れたスケーラビリティに基づいて、業界のさまざまな TrainingJob CRD を簡単に接続でき、Tensorflow、PyTorch、xgbost などのトレーニング フレームワークをすべてサポートできます。タスクはバッチ スケジュールとタスクの優先順位キューをサポートします。

(3) アルゴリズム チームと協力して Tensorflow トレーニング フレームワークを部分的に最適化し、バッチ データの読み取り効率と PS/Worker の通信速度の一部の改善を達成しました。PS の負荷不均衡では、遅いため、いくつかの解決策が作成されました。労働者などの問題。

3.4 モデル サービスの管理

通常のサービスと比較して、モデル サービスの最大の特徴は、サービスが 1 つ以上のモデル ファイルを読み込む必要があることです。コンテナ化の初期には、歴史的な理由から、ほとんどの CV モデル サービスはモデル ファイルと推論スクリプトをコンテナ イメージに直接パッケージ化していたため、比較的大きなコンテナ イメージと煩雑なモデル バージョンの更新が発生しました。

KubeAI は上記の問題を変更します。モデルの標準化された管理に基づいて、モデル サービスは設定を通じてモデルに関連付けられます。公開時に、プラットフォームはモデル設定に従って対応するモデル ファイルをプルし、推論スクリプトによってロードされます。 。このアプローチにより、アルゴリズム モデル開発者が推論サービスのイメージ/バージョンを管理するというプレッシャーが軽減され、ストレージの冗長性が減り、モデルの更新/ロールバックの効率が向上し、モデルの再利用率が向上し、アルゴリズム チームがより便利かつ迅速に管理できるようになります。 。

3.5 AI パイプライン エンジン

実際のビジネス シナリオは単一のタスク ノードではありません。たとえば、完全なモデル反復プロセスには、大まかにデータ処理リンク、モデル トレーニング リンク、および使用新しいモデル更新オンライン推論サービス、小規模トラフィック検証プロセス、および正式リリース プロセスの概要。 KubeAI プラットフォームは、Argo Workflow に基づいたワークフロー オーケストレーション エンジンを提供し、ワークフロー ノードはカスタム タスク、プラットフォーム プリセット テンプレート タスク、およびさまざまな深層学習 AI トレーニング タスク (TFJob、PyTorchJob など) をサポートします。

#4. KubeAI に実装される AI ビジネス シナリオの典型的なケース

4.1 CV アルゴリズム モデルの開発プロセス

CV アルゴリズム モデルの開発モードは、一般的に、エンジニアリング実践アルゴリズム モデルを開発しながら理論的アルゴリズムを研究し、いつでもデバッグできます。一般にモデルは小さいため、検索モデルやプッシュ モデルよりもトレーニング コストが低くなります。そのため、CV の学生は、Notebook でトレーニング スクリプトを開発した後、Notebook で直接トレーニングすることに慣れています。ユーザーは、ノートブック用の CPU、GPU カード、ネットワーク ストレージ ディスクなどのリソースを個別に選択して構成できます。

トレーニング スクリプトが開発とデバッグを通じてニーズを満たした後、ユーザーは KubeAI が提供するタスク管理機能を使用して、トレーニング スクリプトをスタンドアロン トレーニング タスクまたは分散トレーニング タスクとして構成し、実行用の KubeAI プラットフォーム。プラットフォームは、十分なリソースを持つリソース プールでタスクを実行するようにスケジュールします。操作が成功すると、モデルはモデル ウェアハウスにプッシュされ、KubeAI のモデル リストに登録されます。または、モデルはユーザーが作成できるように指定された場所に保存されます。選択と確認。

モデルが生成された後、ユーザーはそのモデルを KubeAI のモデル サービス管理の推論サービスとして直接デプロイできます。後でモデルの新しいバージョンが作成されると、ユーザーは推論サービスの新しいモデル バージョンを構成できます。次に、推論エンジンがモデルのホット アップデートをサポートしているかどうかに応じて、サービスを再デプロイするかモデル アップグレード タスクを作成することで、推論サービスでのモデルのアップグレードを完了できます。

マシン識別ビジネス シナリオでは、上記のプロセスが AI-Pipeline ワークフローを通じて調整され、モデルの反復が定期的に実行されるため、モデルの反復効率が約 65% 向上します。 CV シーンが KubeAI プラットフォームに接続された後、以前のローカル トレーニング方法は廃止され、プラットフォーム上の柔軟なオンデマンド リソース取得方法により、モデル管理、推論サービス管理、およびモデルの反復の点で、リソースの使用率が大幅に向上します。研究開発効率が約50％向上します。

4.2 検索およびプッシュ モデルのトレーニング タスクは PAI から KubeAI プラットフォームに移行されます

CV モデルと比較して、検索およびプッシュ モデルのトレーニング コストは高く、これは主にデータサンプルが大きく、トレーニング時間が長いため、1 つのタスクに大量のリソースが必要になります。 KubeAI が開始される前は、データが ODPS (Alibaba General Computing Platform が提供するデータ ウェアハウス ソリューション、現在は MaxCompute に名前変更されました) に保存されていたため、検索およびプッシュ アルゴリズムの学生のほとんどは Dataworks (ODPS に基づくビッグ データ) に所属していました。開発管理プラットフォームのコンソールでタスクを処理し、モデル トレーニング タスクを PAI プラットフォームに送信します。ただし、PAI はパブリック クラウド製品であるため、PAI に送信される 1 つのタスクのコストは、タスク自体に必要なリソースのコストよりも高く、その上位部分は実際には技術サービス料として理解できます。クラウド製品には社内のコスト管理ニーズも満たされていません。

KubeAI が段階的に実装された後、検索のモデル トレーニング タスクを徐々に移行し、PAI 上のシナリオを 2 つの方法でプラットフォームに移行します。方法 1 は、Dataworks で作業するユーザーの習慣を維持し、Dataworks でいくつかの SQL タスクを完了し、シェル コマンドを介してタスクを KubeAI プラットフォームに送信する方法です。方法 2 は、ユーザーが KubeAI プラットフォームにタスクを直接送信する方法です。データ ウェアハウスのインフラストラクチャが改善されるにつれて、徐々に 2 番目の方法に切り替えられることを期待しています。

Soutui のモデル トレーニング タスクの開発プロセスでは、KubeAI が提供する開発環境とツールを最大限に活用します。自社開発のトレーニングプロジェクトFramworkにより、CPUのみを使用する場合、トレーニング時間はPAI上でGPUトレーニングを使用するのと同じにすることができ、トレーニングエンジン側も大規模なモデルトレーニングとリアルタイムトレーニングシナリオをサポートし、複数のタイプと連携しますストレージ (OSS/ファイル ストレージ) ソリューションとモデル配布ソリューションを利用して、大規模なモデル トレーニング タスクの成功率を確保し、オンライン サービスへのモデルの更新を効率的に完了します。

リソースのスケジューリングと管理の点で、KubeAI はクラスターフェデレーション、過剰販売メカニズム、タスクバンドル、その他の技術的手段を最大限に活用して、トレーニングタスク用の専用リソースプールの使用をタスクポッドへのエラスティックリソースの割り当てに段階的に変換します。そしてそれらをオンライン リソース プール、パブリック リソース プールにスケジュールします。本番タスクや主要な開発タスクを日中に定期的に実行する特性を活かし、ピークシフトや差別化スケジューリング（小規模にはエラスティックリソースを、大規模には定期的にリソースを使用するなど）を実現します。ここ数カ月のデータから判断すると、リソースの総増加量はそれほど変わっていないにもかかわらず、タスクの大幅な増加を継続することができています。

4.3 ベースライン指標予測シナリオ

#これは、AI 機能を使用した典型的な非アルゴリズム ビジネス シナリオです。たとえば、Facebook の預言アルゴリズムを使用して、特定のビジネス指標のベースラインを予測します。 KubeAI は、これらのシナリオのニーズに対応する基本的な AI 機能を提供し、「成熟したアルゴリズムを迅速に検証することが難しい」という問題を解決します。ユーザーは、エンジニアリング的な方法 (既存のベスト プラクティスまたは二次開発を使用) でアルゴリズム モデルを実装し、コンテナ イメージを作成し、KubeAI でタスクを送信し、実行を開始して、目的の結果を取得するだけで済みます。または、定期的にトレーニングと推論を実行して、ベースライン予測結果を取得します。

ユーザーは、タスクに必要なコンピューティング リソースやその他の異種リソースをオンデマンドで構成して使用できます。現在、オンライン ビジネス シナリオの 12 の指標を例にとると、毎日 20,000 近くのタスクが実行されています。同様のニーズに対する以前のリソース コストと比較して、KubeAI はコストのほぼ 90% を節約し、研究開発効率を約 3 倍向上させるのに役立ちます。 。

5. Outlook

Dewu は、短期間でビジネスのコンテナ化に成功しました。これは、クラウド ネイティブ テクノロジー自体がますます成熟しているためですが、一方で、当社の自社のビジネスシナリオのニーズを深く理解することで、的を絞ったソリューションを提供できます。 KubeAI プラットフォームは、AI ビジネス シナリオのエンジニアリング効率を継続的に改善し、リソース利用率を向上させ、AI モデル/サービス開発のしきい値を下げる方法に基づいた、アルゴリズム ビジネス シナリオの問題点要件の詳細な分析に基づいています。そして徐々にそれを反復的に実装します。

今後も、AI モデルのトレーニングと反復の効率とリソース使用率をさらに向上させるために、トレーニング エンジンの最適化、洗練された AI タスク スケジューリング、エラスティック モデル トレーニングに引き続き熱心に取り組んでいきます。

以上がWuyun ネイティブ AI プラットフォーム - KubeAI の実装プロセスを理解するための 1 つの記事の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。