誰も教えてくれないAI大規模導入の効率的なプロセス！

現在、AIに関するチュートリアルは数多くあります。オブジェクト検出、画像分類、NLP の実行方法、チャットボットの構築方法など、リストは続きます。

しかし、AI を適切に拡張する方法に関する情報を探したところ、ほとんど見つかりませんでした。さらに驚くべきことは、存在する数少ないリソースが一貫して同じ点を強調していることです。

TensorFlow のようなスケーラブルなフレームワークを使用してモデルを構築します。
クライアント側 (TF.js、TF Lite、TF-slim など) でパッケージ化するか、コンテナーベースのマイクロサービスとしてデプロイします。

私はすでにモデルを開発していたので、2 番目の点にもっと興味がありましたが、それを実現する方法についての詳細がなく、各ソリューションの欠点に関する情報がさらに少ないことに驚きました。 Crane.ai で数日間 AI を研究し、拡張した後、これらの方法を展開する方法、これらの方法の欠点、および低レベルで TensorFlow モデルを最適化する方法に関するコンテンツをまとめました。

[[254822]]

モデルをクライアントにパッケージ化することは、悪い考えです。

最も一般的なアプローチの 1 つは、TensorFlow.js、TF Lite、TensorFlow Slim などのツールを使用して、AI を任意のクライアントにパッケージ化することです。これらのフレームワークがどのように機能するかについては詳しく説明しません。ただし、その欠点については強調しておきます。

計算能力。これらのモデルを展開する際の問題は、大量のメモリが必要になることです (モバイルアプリやブラウザーの制限、つまり 1 ～ 2 GB を超える RAM)。多くの携帯電話にはそのような計算能力がなく、デスクトップブラウザーは UI スレッドを遅延させるだけでなく、ユーザーのコンピューター、ブラウザーの起動、ファンの起動などの速度も低下させます。
時間を推測します。計算能力が不明なデバイスでモデルを実行する場合、推論時間も通常は不明です。これらのデバイスは、GPU を搭載した高 RAM、高 CPU マシンではなく、通常のコンピューターで実行される電話、ブラウザー、デスクトップアプリにすぎません。大規模なモデルの推論時間は簡単に 1 分を超える可能性があり、これはユーザーエクスペリエンスの観点からは実現可能ではありません。

大きなファイル。残念ながら、ほとんどのモデルはかなり大きなファイル（数十または数百 MB）に保存されます。したがって、これらのファイルの読み込みには時間がかかり、大量のメモリが必要になり、アプリケーションパッケージのサイズが大幅に増加します。
安全ではありません。オープンソースモデルを使用している場合を除き、AI モデルと事前トレーニング済みのチェックポイントは比較的機密性を保つ必要があります。ただし、モデルをアプリケーションにパッケージ化すると、推論コードが逆コンパイルされる危険性があるだけでなく、アプリケーションパッケージ内の事前トレーニング済みのチェックポイントも盗まれる危険性があります。
更新が難しい。モデルを更新する場合、クライアントには 2 つのオプションがあります。アップデートは集中管理マネージャー (Play ストア、App Store など) を通じてリリースされるため、頻繁に大規模なアップデートが発生します (これはユーザーにとって煩わしいものであり、ユーザーは設定に基づいてプロセスを中断したり、アップデートをまったく有効にしなかったりする可能性があります)。または、アプリケーション自体が新しいモデルのチェックポイントとメタデータを取得することもできます。後者の方がはるかに良さそうですが、不安定な接続で 100 MB 以上のファイルをダウンロードする可能性があり、時間がかかる可能性があるため、ダウンロードが完了するまでアプリを少なくともバックグラウンドで実行する必要があり、インターネットの送信コストが高くなります (クラウドによって異なります)。
訓練可能性の欠如。新規ユーザーのデータでトレーニングされたモデルは、精度を向上させ、高信号データのコアセットを構築しながら、ある程度のパーソナライゼーションを提供します。残念ながら、ほとんどのデバイスにはモデルをトレーニングするための計算能力が不足しており、十分な計算能力があったとしても、トレーニング結果をサーバーやアプリケーションを実行している他のデバイスに送信することができません。

[[254823]]

これらの欠点により、クライアント上で大規模なニューラルネットワークを展開して維持することがほぼ不可能になるため、これをモデルのスケーリングのオプションのリストから除外します。

クラウドエンドポイントとして展開

画像出典: https://xkcd.com/908/

クラウドは、モデルを大規模に展開するための強力なツールです。ニーズに合わせて環境をカスタマイズし、アプリケーションをコンテナ化し、アプリケーションを瞬時に水平方向に拡張しながら、大企業に匹敵する SLA と稼働時間を実現できます。

デプロイメントプロセスは、ほとんどの TensorFlow モデルで同じです。

イメージをProtobufバイナリファイルに固める
推論コードを調整して、固まったグラフを処理できるようにします。
コンテナ化されたアプリケーション
上にAPIレイヤーを追加する

最初の部分は比較的簡単です。グラフを「固定化」すると、名前付きノード、重み、アーキテクチャ、チェックポイントメタデータがすべて含まれる protobuf バイナリファイルが作成されます。このステップはさまざまなツールで実行できますが、最も一般的なのは、任意の出力ノード名のグラフを固定できる TF 独自のツールです。

この手法とその実装の詳細については、https://www.tensorflow.org/guide/extend/model_files#freezing を参照してください。

[[254824]]

推論コードの調整も難しくありません。ほとんどの場合、feed_dict は変更されませんが、主な違いは、モデルをロードするためのコードの追加と、出力ノードの仕様の変更です。

コンテナ化も簡単です。Dockerfile で環境を設定するだけです。 API レイヤーを追加し始めると、状況は複雑になってきます。通常、次の 2 つの方法が使用されます。

推論スクリプトを実行できる拡張コンテナをデプロイします。これらのコンテナは入力に基づいてスクリプトを実行し、セッションを開始して推論を実行し、パイプラインを通じて出力を返します。これは問題です。コンテナを操作してパイプで出し入れできる API レイヤーを追加することは、ほとんどのクラウドプロバイダーにとって容易ではありません (たとえば、AWS には API ゲートウェイがありますが、期待するほど便利ではありません)。また、このアプローチは最も効率の悪いアプローチです。ここでの問題は、コンテナの起動、ハードウェアの割り当て、セッションの開始、推論の実行中に貴重な時間が失われることです。 stdin を開いたままにして出力をパイプすると、スクリプトは高速化しますが、スケーラビリティは失われます (コンテナーの STDIN に接続されるため、複数のリクエストを受け入れることができなくなります)。

API レイヤーを実行する拡張コンテナをデプロイします。アーキテクチャ的には似ていますが、いくつかの理由からこのアプローチの方が効率的です。 API レイヤーをコンテナに組み込むことで、以前に発生した問題のほとんどが軽減されます。これにはより多くのリソースが必要ですが、使用するリソースは最小限で、垂直スケーリングはありません。各コンテナは実行されたままになり、この場合 API は分散化されているため、特定の stdin/stout をメインのリクエストルーターに接続できます。つまり、起動時間がなくなり、複数のリクエストを処理しながら速度を維持でき、水平方向のスケーラビリティが保証されます。ロードバランサーを使用してコンテナを集中管理し、Kubernetes を使用してほぼ 100% の稼働時間を保証し、クラスターを管理できます。この方法はシンプルで効果的です。

[[254825]]

クラスターをデプロイします。

API をコンテナのクラスター全体に分散することの主な欠点は、計算コストが比較的急速に増加する可能性があることです。残念ながら、これは AI では避けられませんが、この問題を軽減する方法はあります。

セッションを再利用します。クラスターは負荷に比例して拡大および縮小するため、推論の実行にかかる時間を最小限に抑えて、コンテナーを解放して追加のリクエストを処理できるようにすることが目標となります。このアイデアを実現する方法は、初期化後に tf.Session と tf.Graph を保存し、それらをグローバル変数として渡すことで、tf.Session と tf.Graph を再利用するという目的を達成することです。 TF の場合、この変更によりセッションの開始とグラフの構築にかかる時間が短縮され、推論タスクの速度が大幅に向上します。このアプローチは単一のコンテナでも機能し、リソースの再割り当てを最小限に抑え、効率を最大化するためにこの手法が広く使用されています。
入力をキャッシュし、可能であれば出力もキャッシュします。 AI においては、動的プログラミングパラダイムが最も重要です。入力をキャッシュすることで、入力の前処理やリモートの場所からの取得にかかる時間を節約できます。また、出力をキャッシュすることで、推論の実行にかかる時間を節約できます。これは Python では簡単に実行できますが、状況によって異なります。通常、モデルは時間の経過とともに改善されますが、これは出力キャッシュメカニズムに大きな影響を与えます。私のシステムでは、「80-20」ルールと呼ばれるものを採用しています。モデルの精度が 80% 未満の場合は、出力をキャッシュしません。精度が 80% に達するとキャッシュを開始し、精度が特定の値 (特定の時点ではない) に達するとキャッシュを停止するように設定します。この方法では、モデルの精度が高まるにつれて出力は変化しますが、「80-20」キャッシュではパフォーマンスと速度のトレードオフが少なくなります。

[[254826]]

タスクキューを使用します。一般的には、より大きいまたはより小さい推論タスク (この場合、より大きい画像とより小さい画像、複雑な画像と単純な画像) を実行することになります。 UX の場合、小さなタスクを優先するヒープキューを使用する方がよい場合があります。これにより、単純なステップを実行したいユーザーは、別のユーザーのより大きな推論タスクが最初に完了するのを待つのではなく、そのステップが完了するのを待つだけで済みます。 (ここで水平スケーリングを使用しないのはなぜかと疑問に思うかもしれません。水平スケーリングを使用することもできますが、計算コストが増加します)。

タスクキューを使用して専用の GPU でモデルをトレーニングします。トレーニングは、多くの利用可能なリソースを必要とする長くて困難なタスクであり、トレーニングプロセス中はモデルは使用できません。各インタラクションをトレーニングのためにモデルに返す場合は、別のサーバーまたは GPU で実行することを検討してください。トレーニングが完了したら、モデルをコンテナにデプロイできます (AWS では、モデルリポジトリを S3 に集中管理できます)。

結論は

[[254827]]

慎重に検討した結果、大規模に AI を展開するための効率的なワークフローを考案しました。