古い家族の写真のスタックを生き返らせることを探しているなら、UbuntuコンテナでOpenVINOを使用してモノクロ写真を色付けする方法に関するUbuntuのデモをチェックしてください。 コンテナ、ニューラルネットワーク、Kubernetesのこの魔法のような使い方には、役立つリソースとディープラーニングに飛び込むための楽しい方法が満載です。
のバージョン パート1 そして パート2 この記事はUbuntuのブログで最初に公開されました。
目次:
- Ubuntuコンテナ上のOpenVINO:開発者の生活を楽にする
- OpenVINO および Ubuntu コンテナイメージ
- 白黒画像を色付けするニューラルネットワーク
- デモ アーキテクチャ
- Kubernetes を使用したデプロイ
Ubuntuコンテナ上のOpenVINO:開発者の生活を楽にする
AI / MLと、Ubuntuコンテナ上のOpenVINOで何ができるかに興味があるとします。 その場合、このブログはあなたにとっても優れた読み物です。
Dockerイメージのセキュリティは、 出所やサプライチェーンだけでなく、 ユーザーエクスペリエンスにも関係しています。 より具体的には、開発者エクスペリエンスです。
アプリ開発、コンテナ化、デプロイのプロセスから手間や摩擦を取り除くことで、開発者が物事を成し遂げるという名目で信頼できないソースや悪いプラクティスを使用することを奨励することを回避できます。 AI/ML 開発には複雑な依存関係が必要になることが多いため、 安全で安定した コンテナー イメージの完璧な実例となります。
なぜUbuntu Dockerイメージなのか?
そのカテゴリで最も人気のあるコンテナイメージとして、Ubuntu ベースイメージ はシームレスでセットアップが簡単なエクスペリエンスを提供します。 パブリッククラウドホストからIoTデバイスまで、Ubuntuエクスペリエンスは一貫しており、開発者に愛されています。
Ubuntuベースのコンテナイメージを採用する主な理由の1つは、ソフトウェアエコシステムです。 1つの「インストール」コマンドで30,000を超えるパッケージが利用可能であり、Canonicalのエンタープライズサポートにサブスクライブするオプションがあります。 それは物事を簡単にするだけです。
このブログでは、Ubuntu Docker イメージを使用すると、コンポーネントのコンテナー化が大幅に簡素化されることがわかります。 NGINX Webサーバーには、Canonicalが最大10年間維持しているLTSイメージポートフォリオの 事前構築済みおよび事前構成済みのコンテナイメージ も使用しました。
Ubuntuは、コンテナイメージ全体で安全で安定した一貫したエクスペリエンスを提供するだけでなく、ベアメタルサーバーからコンテナまで安全な選択肢です。 さらに、Intelハードウェアを含むクラウドおよびオンプレミス での ハードウェア最適化が付属しています。
なぜオープンヴィーノなのか?
ディープラーニング推論を本番環境にデプロイする準備ができたら、特にエッジにデプロイする場合、バイナリサイズとメモリフットプリントが重要な考慮事項 になります。 OpenVINO は、CPU ベースの推論用に 40MB をわずかに超える バイナリサイズの軽量推論エンジンを提供します。 また、モデルを大規模に提供し、デプロイを管理するためのモデル サーバーも提供します。
OpenVINO には、モデル推論のパフォーマンスを向上させるためのオープンソースの開発者ツールが含まれています。 最初のステップは、モデルオプティマイザーを使用して、ディープラーニングモデル(TensorFlow、PyTorch,...でトレーニング)を中間表現(IR)に変換することです。 実際、FP32からFP16の精度に変換することで、モデルのメモリ使用量を 半分に 削減します。 OpenVINOの低精度ツールを使用することで、追加のパフォーマンスを解き放つことができます。 トレーニング後最適化ツール (POT) とニューラル ネットワーク圧縮フレームワーク (NNCF) は、量子化、バイナリ化、フィルター プルーニング、およびスパースシティ アルゴリズムを提供します。 その結果、インテルデバイスのスループットは、CPU、 統合GPU、VPU、およびその他のアクセラレータで向上します。
Open Model Zooは、実際のユースケースで機能する事前トレーニング済みのモデルを提供し、すぐに開始できるようにします。 さらに、Python と C++ のサンプル コードでは、モデルを操作する方法を示します。 音声認識から自然言語処理、コンピュータービジョンまで、280を超える事前トレーニング済みモデルをダウンロードできます。
このブログシリーズでは、Open Model Zooの事前トレーニング済みのカラー化モデルを使用し、モデルサーバーで提供します。
OpenVINO および Ubuntu コンテナイメージ
モデルサーバーには、デフォルトで最新のUbuntu LTSが付属しており、一貫した開発環境とレイヤー化しやすい基本イメージを提供します。 OpenVINO ツールは、ビルド済みの開発およびランタイム コンテナー イメージとしても使用できます。
Canonical LTS Docker Images と OpenVINO™ の詳細については、以下をお読みください。
- コンテナソフトウェアサプライチェーンを保護するためのインテルとカノニカル– Ubuntuブログ
- OpenVINO ドキュメント – OpenVINO™
- ウェビナー:エッジでの安全なAI展開– カノニカルとインテル
白黒画像を色付けするニューラルネットワーク
さて、目前の問題に戻ります:おばあちゃんとおじいちゃんの古い写真をどのように色付けしますか? Open Model Zooのおかげで、ニューラルネットワークを自分でトレーニングする必要はなく、デプロイにのみ焦点を当てることができます。(あなたはまだ それについて読むことができます。
私たちのアーキテクチャは、バックエンド、フロントエンド、ニューラルネットワーク予測を提供するOpenVINOモデルサーバー(OVMS)の3つのマイクロサービスで構成されています。 モデル サーバー コンポーネントは、2 つの異なるデモ ニューラル ネットワークをホストして、その結果 (V1 と V2) を比較します。 これらのコンポーネントはすべて、一貫したソフトウェアエコシステムとコンテナ化された環境のためにUbuntuベースイメージを使用します。
このタイプのマイクロサービスアーキテクチャに慣れていない場合は、いくつか読んでください。
gRPC と REST API の比較
OpenVINO モデル サーバーは、 OpenVINO IR または ONNX 形式でモデルを提供するために、HTTP/REST および gRPC エンドポイントを介してサービスとして推論を提供します。 また、複数の異なるモデル、または同じモデルとモデル パイプラインの異なるバージョンに対応するための一元化されたモデル管理も提供します。
サーバーは、REST と gRPC という 2 つの API セットをインターフェイスとして提供します。 どちらの API も TensorFlow サービングと互換性があり、予測、モデル メタデータの確認、モデルの状態の監視のためにエンドポイントを公開します。 低待機時間と高スループットが必要なユース ケースでは、gRPC API を介してモデル サーバーと対話することをお勧めします。 実際、REST よりも大幅に小さいオーバーヘッドが導入されます。 ( gRPC の詳細については、こちらをご覧ください。
OpenVINO モデル サーバーは、最小限の依存関係を持つ Docker イメージ として配布されます。 このデモでは、MicroK8s クラスターにデプロイされたモデル サーバー コンテナー イメージを使用します。 この軽量テクノロジの組み合わせは、小規模な展開に適しています。 エッジコンピューティング デバイスに適しており、データが生成される場所で推論を実行し、プライバシーの向上、低遅延、低ネットワーク使用量を実現します。
Ubuntu の最小コンテナー イメージ
2019年以降、Ubuntuの基本イメージは最小限であり、「スリム」なフレーバーはありません。改善の余地はありますが(投稿し続けてください)、Ubuntu Dockerイメージは30MB未満のダウンロードであり、コンテナで利用できる最も小さなLinuxディストリビューションの1つになっています。
Dockerイメージのセキュリティに関しては、サイズは1つのことであり、攻撃対象領域を減らすことは公正な投資です。 ただし、よくあることですが、サイズがすべてではありません。 実際、メンテナンスは最も重要な側面です。 豊富で活発なソフトウェアエコシステムコミュニティを備えたUbuntuベースイメージは、通常、小規模なディストリビューションよりも安全な方法です。
一般的なトラップは、より小さく始めて、多くの異なるソースからの依存関係の負荷をインストールすることです。 その結果、パフォーマンスが低下し、最適化されていない依存関係が使用され、セキュリティで保護されなくなります。 あなたはおそらくあなた自身のLinuxディストリビューションを効果的に維持することになりたくないでしょう...だから、私たちはあなたのためにそれをしましょう。
デモ アーキテクチャ
「ユーザーとして、白黒写真をブラウザにドラッグアンドドロップして、すぐにダウンロードできるカラーバージョンを表示できます。」 –首相(私)は言った。
そのために–かつてのソフトウェアエンジニア(まだ私)に答えました–必要なのは:
- 派手でありながら軽量なフロントエンドコンポーネント。
- ニューラルネットワークのカラー化予測を提供するOpenVINO™モデルサーバー。
- 非常に軽いバックエンドコンポーネント。
フロントエンドでモデルサーバーを直接ターゲットにすることもできますが(REST APIを公開します)、送信された画像に変換を適用する必要があります。 実際、色付けモデルはそれぞれ特定の入力を想定しています。
最後に、これら 3 つのサービスを Kubernetes でデプロイします。まぁ。。。グルーヴィーだから。 また、そうでないと考える場合(誰もが1つか2つの欠陥を持つことが許されています)、ソースコードリポジトリに完全に機能するdocker-compose.yamlが見つかります。
以降のセクションでは、最初に各コンポーネントを見てから、MicroK8sを使用してKubernetesでそれらをデプロイする方法を示します。 心配する必要はありません;完全なソースコードは 無料で入手でき、関連する部分にリンクします。
ニューラルネットワーク – OpenVINO モデルサーバー
カラー化ニューラルネットワークはBSD 2条項ライセンス の下で公開 されており、 Open Model Zooからアクセスできます。 事前にトレーニングされているので、使用するために理解する必要はありません。 ただし、予想される入力を理解するために詳しく見てみましょう。 また、リチャード・チャン、フィリップ・イゾラ、アレクセイ・A・エフロスの原作を読むことを強くお勧めします。 彼らは、 このウェブサイト と元の 論文でアプローチを非常にアクセスしやすく理解しやすくしました。
ネットワークアーキテクチャ図でわかるように、ニューラルネットワークは珍しい色空間であるLABを使用します。 色をコード化するための多くの3次元空間があります:RGB、HSL、HSVなど。 LAB形式は、色情報を明度情報から完全に分離するため、ここで関連します。 したがって、グレースケール画像はL(明度)軸のみで符号化できます。 L軸のみをニューラルネットワークの入力に送信します。 残りの2つの軸(AとB)にコード化された色の予測が生成されます。
アーキテクチャ図から、モデルが 256×256 ピクセルの入力サイズを想定していることもわかります。 これらの理由から、RGBコード化されたグレースケール画像を元のサイズでネットワークに送信することはできません。 まずそれを変革する必要があります。
デモでは、2つの異なるモデルバージョンの結果を比較します。 それらを「V1」(シググラフ)および「V2」と呼ぶようにします。 モデルは、2つの異なるモデルとしてOpenVINO™モデルサーバーの同じインスタンスで提供されます。 (同じモデルの2つの異なるバージョンでそれを行うこともできます– 詳細については、ドキュメントを参照してください。
最後に、 Docker イメージをビルドするために、Ubuntu ベースの開発キットの最初のステージを使用して、モデルをダウンロードして変換します。 次に、より軽量なモデル サーバー イメージに基づいてリベースします。
# Dockerfile FROM openvino/ubuntu20_dev:latest AS omz # download and convert the model … FROM openvino/model_server:latest # copy the model files and configure the Model Server …
バックエンド – Ubuntuベースのフラスコアプリ(Python)
ユーザー向けのフロントエンドとニューラル ネットワークをホストするモデル サーバー間のインターフェイスとなるバックエンド マイクロサービスでは、Python を使用することを選択しました。 特に機械学習アプリケーション用に、画像を含むデータを操作するための多くの貴重なライブラリがあります。 Webサービング機能を提供するには、 Flask が簡単な選択です。
バックエンドは、色付けされる画像を含む HTTP POST 要求を受け取ります。 ニューラル ネットワーク予測を使用して、色付けされた結果を同期的に返します。 その間に、今見たように、モデルアーキテクチャに一致するように入力を変換し、表示可能な結果を表示するように出力を準備する必要があります。
入力での変換パイプライン は次のようになります。
出力は次のようになります。
Python Flask アプリケーションをコンテナー化するために、すべての開発依存関係を含む最初のステージを使用して、実行環境を準備します。 これを新しい Ubuntu ベース イメージにコピーして実行し、モデル サーバーの gRPC 接続を構成します。
フロントエンド – UbuntuベースのNGINXコンテナとSvelteアプリ
最後に、ソリューションを試すための派手なUIをまとめました。 これは、ファイル入力フィールドを備えた簡単なシングルページアプリケーションです。 2つの異なるカラー化モデルの結果を並べて表示できます。
Svelte を使用して、動的なフロントエンドとしてデモを構築しました。各色付けの結果の下には、(CSS変換を使用して)彩度スライダーもあり、予測された色を強調し、前後をより適切に比較できます。
このフロントエンド アプリケーションを出荷するために、ここでも Docker イメージを使用します。 まず、Node 基本イメージを使用してアプリケーションをビルドします。 次に、Canonicalによって維持されている事前構成された NGINX LTSイメージ の上にリベースします。 フロントエンド側のリバース プロキシは、/API エンドポイント上のバックエンドへのパススルーとして機能し、デプロイ構成を簡略化します。 これは、NGINXテンプレートディレクトリにコピーされた NGINX.conf構成ファイル で直接行います。 コンテナー イメージは、環境変数でこれらのテンプレート ファイルを使用するように事前構成されています。
Kubernetes を使用したデプロイ
物事が深刻になりつつあるので、白黒写真をスキャンする時間があったことを願っています(色付け)。
次のセクションでは、実行中の Kubernetes インストールが既にあることを前提としています。 そうでない場合は、次の手順を実行するか、 このMicroK8sチュートリアルを実行することをお勧めします。
# https://microk8s.io/docs sudo snap install microk8s --classic # Add current user ($USER) to the microk8s group sudo usermod -a -G microk8s $USER && sudo chown -f -R $USER ~/.kube newgrp microk8s # Enable the DNS, Storage, and Registry addons required later microk8s enable dns storage registry # Wait for the cluster to be in a Ready state microk8s status --wait-ready # Create an alias to enable the `kubectl` command sudo snap alias microk8s.kubectl kubectl
はい、約 2 つのコマンド ラインで Kubernetes クラスターをデプロイしました。
コンポーネントの Docker イメージをビルドする
すべてのコンポーネントには、標準環境で自身を構築し、そのデプロイの依存関係を出荷するための Dockerfile が付属しています (詳細については、「 コンテナーとは 」を参照してください)。 これらはすべて、一貫した開発者エクスペリエンスのためにUbuntuベースのDockerイメージを作成します。
Kubernetes を使用してカラーライザー アプリをデプロイする前に、コンポーネントのイメージをビルドしてプッシュする必要があります。 これらは、Kubernetes クラスターからアクセスできるレジストリでホストする必要があります。 MicroK8sで 組み込みのローカルレジストリ を使用します。 ネットワーク帯域幅によっては、イメージのビルドとプッシュに数分以上かかります。
sudo snap install docker cd ~ && git clone https://github.com/valentincanonical/colouriser-demo.git # Backend docker build backend -t localhost:32000/backend:latest docker push localhost:32000/backend:latest # Model Server docker build modelserver -t localhost:32000/modelserver:latest docker push localhost:32000/modelserver:latest # Frontend docker build frontend -t localhost:32000/frontend:latest docker push localhost:32000/frontend:latest
Kubernetes 構成ファイルを適用する
これで、すべてのコンポーネントをデプロイする準備が整いました。 Kubernetes 構成ファイルは、デモ リポジトリの ./K8s フォルダー にあるデプロイおよびサービス YAML 記述子として使用できます。 1つのコマンドで、それらをすべて一度に適用できます。
kubectl apply -f ./k8s
数分待ってください。 を使用して、展開されている watch kubectl status
アプリを確認できます。 すべてのサービスの中で、フロントエンドのサービスには、ノードのIPアドレスをターゲットにすることでパブリックにアクセスできるようにするための特定の NodePort
構成があります。
準備ができたら、 http://localhost:30000/ デモ アプリにアクセスできます (リモート クラスターを使用している場合は、クラスター ノードの IP アドレスに置き換え localhost
ます)。 コンピューターから画像を選択して、色付けしてください!
全体として、私たちが達成したタスクを考えると、プロジェクトは非常に簡単でした。 Ubuntuコンテナのおかげで、マルチステージビルドで各コンポーネントのイメージをビルドすることは、一貫性のある簡単なエクスペリエンスでした。 また、OpenVINO™ と Open Model Zoo のおかげで、優れた推論パフォーマンスを備えた事前トレーニング済みモデルを提供することは、すべての開発者がアクセスできる簡単な作業でした。
おしまいです!
あなたはそれを成し遂げるためにインターネット上であなたの写真を共有する必要さえありませんでした。 この記事を読んでくれてありがとう。楽しんでいただけたでしょうか。 ソーシャルにお気軽にお問い合わせください。 最後のカラー化の例を残します。
—
Ubuntu、Dockerイメージの魔法、または独自のDockerファイルの作成方法の詳細については、以下の関連リソースを参照してください。
- より役立つDockerイメージを見つける Docker Hub.
- Ubuntuをチェックしてください ドッカーハブプロファイル.
- 方法を学ぶ 独自のドッカーファイルを作成する ドッカーデスクトップ用。
- について読む エッジでの安全な AI デプロイ.
- についてもっと知る Canonicalが維持するUbuntuベースのOCIイメージ.
- Ubuntuの見解を読む EKS をローカルで実行する.
- はじめに ダウンロード ドッカーデスクトップ ウィンドウズ、マック、またはリナックス用。