DockerがAIモデルのパッケージ化にOCI Artifactsを選択した理由

AI開発が加速する中、開発者はワークフローを再発明することなく迅速に行動できるツールを必要としています。Docker Model Runner は、大規模言語モデル (LLM) を OCI アーティファクト (開発者が既に知っていて信頼している形式) としてパッケージ化するための新しい仕様を導入しています。コンテナと同じワークフローにモデル共有を組み込み、Docker HubなどのOCIレジストリをサポートします。

OCIアーティファクトを使用することで、チームはカスタム・ツールチェーンをスキップし、コンテナ・イメージの場合と同じようにモデルを操作できます。この投稿では、OCIアーティファクトを選択した理由、形式の仕組み、GenAI開発者にとって何のロックを解除するかを共有します。

OCIアーティファクトを使用する理由

Docker の目標の 1 つは、genAI アプリケーション開発をより大きな開発者コミュニティが利用できるようにすることです。これは、モデルがクラウドネイティブエコシステム内で第一級の市民になるのを支援することで実現できます。

モデルがOCIアーティファクトとしてパッケージ化されている場合、開発者は新しい配布ツールチェーンを学習、吟味、採用することなく、AI開発を開始できます。代わりに、開発者はHubで新しいモデルを発見し、今日のコンテナイメージと同じように、既存のOCIレジストリを介してバリアントを公開または非公開で配布できます。Docker Hubを使用しているチームの場合、レジストリアクセス管理(RAM)などのエンタープライズ機能は、ポリシーベースの制御とガードレールを提供し、安全で一貫したアクセスを強制するのに役立ちます。

モデルをOCIアーティファクトとしてパッケージ化すると、Docker Model Runnerなどの推論ランナーとcontainerdやKubernetesなどの既存のツールとのより深い統合への道も開かれます。

OCIイメージおよびアーティファクトの理解

これらの利点の多くは、OCIイメージとOCIアーティファクトに等しく適用されます。イメージがLLMに最適でない理由と、カスタム・アーティファクト仕様が追加の利点をもたらす理由を理解するには、まずOCIイメージのコンポーネントとその汎用のいとこであるOCIアーティファクトを再検討することが役立ちます。

OCIイメージとは

OCIイメージは、 Open Container Initiative(OCI)によって定義されたコンテナイメージの標準化された形式です。コンテナの実行に必要なすべてのもの (メタデータ、構成、ファイルシステムレイヤー) をパッケージ化します。

OCIイメージは、次の3つの主要コンポーネントで構成されます。

イメージマニフェスト – イメージ設定への参照とファイルシステムレイヤーのセットを含む JSON ファイル。
イメージ構成 - レイヤーの順序とOCIランタイム構成を含むJSONファイル。
1つ以上の レイヤー – TARアーカイブ(通常は圧縮)で、順番に適用されてコンテナルートファイルシステムを生成するファイルシステムの変更セットが含まれています。

以下は、busybox イメージのマニフェストの例です。

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:7b4721e214600044496305a20ca3902677e572127d4d976ed0e54da0137c243a",
    "size": 477
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:189fdd1508372905e80cc3edcdb56cdc4fa216aebef6f332dd3cba6e300238ea",
      "size": 1844697
    }
  ],
  "annotations": {
    "org.opencontainers.image.url": "https://github.com/docker-library/busybox",
    "org.opencontainers.image.version": "1.37.0-glibc"
  }
}

イメージマニフェストには、すべてのイメージコンポーネントへのコンテンツアドレス可能な参照が含まれているため、マニフェストファイルのハッシュ (イメージダイジェストとも呼ばれます) を使用して、イメージを一意に識別できます。

OCIアーティファクトとは

OCIアーティファクトは、OCIイメージ形式を拡張して、コンテナ・イメージを越えたコンテンツの配布をサポートする方法を提供します。これらは、マニフェスト、設定ファイル、および 1 つ以上のレイヤーという同じ構造に従います。

OCI イメージ仕様のアーティファクトガイダンスでは、この同じ基本構造 (マニフェスト + 構成 + レイヤー) を使用して他の種類のコンテンツを配布する方法が説明されています。

アーティファクト・タイプは、構成ファイルのメディア・タイプによって指定されます。たとえば、次のマニフェストでは、config.mediaType は application/vnd.cncf.helm.config.v1+json に設定されています。これは、レジストリやその他のツールに対して、アーティファクトが Helm チャートであり、それに応じて解析する必要があることを示しています。

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.cncf.helm.config.v1+json",
    "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111",
    "size": 117
  },
  "layers": [
    {
      "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip",
      "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617",
      "size": 2487
    }
  ]
}

OCIアーティファクトでは、レイヤーは任意のメディア・タイプにすることができ、ファイル・システムの変更セットに限定されません。アーティファクトタイプを定義する人は誰でも、サポートされているレイヤータイプを定義し、コンテンツの使用方法と解釈方法を決定します。

コンテナイメージの使用とカスタムアーティファクトタイプ

この背景を念頭に置くと、LLM をコンテナイメージとしてパッケージ化することもできますが、カスタムタイプを定義することにはいくつかの重要な利点があります。

カスタムアーティファクトタイプを使用すると、ドメイン固有の設定スキーマを定義できます。主要なメタデータへのプログラムによるアクセスは、AIのユースケースに特化した便利なツールのエコシステムのサポート構造を提供します。
カスタムアーティファクトタイプを使用すると、圧縮された TAR アーカイブ以外の形式でコンテンツをパッケージ化できるため、LLM がイメージレイヤーとしてパッケージ化されるときに発生するパフォーマンスの問題を回避できます。モデルレイヤーの違いとその重要性の詳細については、以下の「レイヤー」セクションを参照してください。
カスタム型を使用すると、モデルが推論エンジンとは別にパッケージ化および配布されます。この分離は、ユーザーがすべてのモデルをすべてのエンジンと組み合わせてパッケージ化することなく、システム用に最適化された推論エンジンのバリアントを消費することを可能にするため、重要です。
カスタム成果物の種類を使用すると、コンテナーイメージに通常付随する期待から解放されます。スタンドアロンモデルは、推論エンジンなしでは実行できません。カスタムタイプとしてパッケージ化すると、独立して実行できないことが明確になり、混乱や予期しないエラーを回避できます。

Docker モデルアーティファクト

高レベルの目標を理解したところで、フォーマットの詳細を深く掘り下げてみましょう。

メディアの種類

モデル仕様では、次のメディアの種類が定義されています。

application/vnd.docker.ai.model.config.v0.1+ json– モデル構成 JSON ファイルを識別します。マニフェストの config.mediaType のこの値は、アーティファクトを v0に準拠した設定ファイルを持つ Docker モデルとして識別します。仕様の1 。
application/vnd.docker.ai.gguf.v3- 画層にGGUFファイルとしてパッケージ化されたモデルが含まれていることを示します。
application/vnd.docker.ai.license – レイヤーにプレーンテキストのソフトウェアライセンスファイルが含まれていることを示します。

今後、ランタイム構成の追加、プロジェクターや LoRA アダプターなどの新機能のサポートの追加、モデルファイルのサポートされるパッケージ形式の拡張など、より多くのメディアの種類が定義されることが予想されます。

積荷目録

モデルマニフェストは、イメージマニフェストと同様に書式設定され、構成によって区別されます。MediaType です。次のマニフェストの例は、 ai/gemma3から取得されたもので、モデル設定 JSON と 2 つのレイヤー (1 つは GGUF ファイルを含み、もう 1 つはモデルのライセンスを含む) を参照しています。

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.docker.ai.model.config.v0.1+json",
    "size": 372,
    "digest": "sha256:22273fd2f4e6dbaf5b5dae5c5e1064ca7d0ff8877d308eb0faf0e6569be41539"
  },
  "layers": [
    {
      "mediaType": "application/vnd.docker.ai.gguf.v3",
      "size": 2489757856,
      "digest": "sha256:09b370de51ad3bde8c3aea3559a769a59e7772e813667ddbafc96ab2dc1adaa7"
    },
    {
      "mediaType": "application/vnd.docker.ai.license",
      "size": 8346,
      "digest": "sha256:a4b03d96571f0ad98b1253bb134944e508a4e9b9de328909bdc90e3f960823e5"
    }
  ]
}

モデル ID

マニフェストダイジェストはモデルを一意に識別し、Docker Model Runner によってモデル ID として使用されます。

モデル構成 JSON

モデル構成は、サイズ、パラメーター数、量子化、アーティファクトの出所に関するメタデータ (作成タイムスタンプなど) など、モデルに関する重要なメタデータを表示する JSON ファイルです。
次の例は、Dockerhub の ai/gemma モデルからのものです。

{
  "config": {
    "format": "gguf",
    "quantization": "IQ2_XXS/Q4_K_M",
    "parameters": "3.88 B",
    "architecture": "gemma3",
    "size": "2.31 GiB"
  },
  "descriptor": {
    "created": "2025-03-26T09:57:32.086694+01:00"
  },
  "rootfs": {
    "type": "rootfs",
    "diff_ids": [
      "sha256:09b370de51ad3bde8c3aea3559a769a59e7772e813667ddbafc96ab2dc1adaa7",
      "sha256:a4b03d96571f0ad98b1253bb134944e508a4e9b9de328909bdc90e3f960823e5"
    ]
  }
}

ドメイン固有の設定スキーマを定義することで、ツールは小さなJSONファイルをフェッチして解析することで、モデルメタデータに安価にアクセスして使用できるようになります。必要な場合にのみモデル自体をフェッチできます。

たとえば、Docker Hubのようなレジストリフロントエンドは、このデータをユーザーに直接表示し、ユーザーはそれを使用してモデルを比較したり、システムの機能や要件に基づいて選択したりできます。ツールでは、このデータを使用して、特定のモデルのメモリ要件を見積もることができます。その後、利用可能なリソースと互換性のある最適なバリアントを提案することで、選択プロセスを支援できます。

層

モデル・アーティファクト内のレイヤーは、OCIイメージ内のレイヤーと2つの重要な点で異なります。

圧縮が推奨される画像レイヤーとは異なり、モデルレイヤー は常に圧縮されていません。モデルは大きくてエントロピーの高いファイルであるため、圧縮してもサイズの削減はごくわずかですが、圧縮 (非) 圧縮は時間と計算量が多くなります。

アーカイブに複数のファイルが含まれているOCIイメージのレイヤーとは対照的に、モデルアーティファクトの各「レイヤー」には 1つのRAWファイルが含まれている必要があります。これにより、Docker Model Runner などのランタイムは、モデルの非圧縮コピーを 1 つ保存することで、クライアントマシンのディスク使用量を削減できます。このファイルは、実行時に推論エンジンによって直接メモリマップされます。

ファイル名、階層、メタデータの欠如(例:Modification Time) は、同一のモデルファイルが常に同一の再利用可能なレイヤー BLOB になることを保証します。これにより、ファイルサイズを考えると、LLMで作業する場合に特に重要な不要な重複を防ぐことができます。

これらの「レイヤー」は実際にはファイルシステムレイヤーではないことに気付いたかもしれません。これらはファイルですが、ファイルシステムは指定されていません。では、これは実行時にどのように機能するのでしょうか?Docker Model runner がモデルを実行すると、モデルファイルシステムで GGUF ファイルを名前で検索する代わりに、目的のファイルがそのメディアタイプ (application/vnd.docker.ai.gguf.v3) で識別されますモデルストアからフェッチされます。Model Runner アーキテクチャの詳細については、このブログ記事のアーキテクチャの概要を参照してください。

流通

OCI イメージや他の OCI アーティファクトと同様に、Docker モデルアーティファクトは、 OCI 配布仕様に準拠する Dockerhub、Artifactory、Azure Container Registry などのレジストリを介して配布されます。

発見

Docker Hub

Docker Hub Gen AI カタログは、一般的なモデルの発見に役立ちます。これらのモデルは、ここで説明する形式でパッケージ化されており、Docker Model Runner および OCI 仕様をサポートするその他のランタイムと互換性があります。

Hugging Face

Hugging Faceでモデルを探索することに慣れているなら、朗報があります!Hugging Face は、Docker モデルのプルを使用して Hugging Face からプルするときに、Docker Model Artifact 形式へのオンデマンド変換をサポートするようになりました。

次は何ですか?

Docker OCI Model形式と、使い慣れたワークフローとコマンドを使用して開発者がAIアプリ開発にアクセスしやすくするという目標をどのようにサポートするかについて、理解を深めていただければ幸いです。しかし、このバージョンのアーティファクト形式はほんの始まりにすぎません。将来的には、パッケージ形式の機能強化により、このレベルのアクセシビリティと柔軟性がより広範なユースケースにもたらされることが期待できます。将来のバージョンでは、次のものがサポートされます。

テンプレート、コンテキストサイズ、デフォルトパラメータなどの追加のランタイム設定オプション。これにより、ユーザーは特定のユースケースに合わせてモデルを設定し、その設定をモデルと一緒に単一の不変アーティファクトとして配布できます。
LoRAアダプターにより、 ユーザーはユースケースに応じた微調整で既存のモデルアーティファクトを拡張できます。
LLaVAスタイルのプロジェクターを使用して、言語モデルや視覚モデルなどのマルチモーダルをパッケージ化できるマルチモーダルプロジェクター。
モデルインデックスファイルは 、さまざまなパラメーター数と量子化を持つ一連のモデルを提供し、ランタイムが使用可能なリソースに最適なオプションできるようにします。

機能の追加に加えて、私たちはオープンなエコシステムの育成に取り組んでいます。予想する：

containerdへのより深い統合により、よりネイティブなランタイムエクスペリエンスを実現します。
ModelPackやその他のモデルパッケージ標準と調和させ、相互運用性を向上させる取り組み。

これらの進歩は、OCIアーティファクトをAIモデルをパッケージ化して実行するための汎用性と柔軟性のある方法にするという当社の継続的な取り組みを示しており、開発者がすでにDockerに期待しているのと同じ使いやすさと信頼性を提供します。

さらに詳しく

Docker Model Runner の設計アーキテクチャの内部をご覧ください。
Docker Model Runner のクイックスタートガイドをお読みください。
Model Runner のドキュメントが見つかります。
Docker Navigator ニュースレターを購読してください。
Docker は初めてですか? アカウントを作成します。
ご質問はございますか? Docker コミュニティがお手伝いします。

DockerがAIモデルのパッケージ化にOCI Artifactsを選択した理由

OCIアーティファクトを使用する理由

OCIイメージおよびアーティファクトの理解

OCIイメージとは

OCIアーティファクトとは

コンテナイメージの使用とカスタムアーティファクトタイプ

Docker モデルアーティファクト

メディアの種類

積荷目録

モデル ID

モデル構成 JSON

層

流通

発見

Docker Hub

Hugging Face

次は何ですか?

さらに詳しく

掲示される

投稿タグ

投稿カテゴリ

関連記事

アプリ開発のDockerの現状:セキュリティ

舞台裏: Docker Model Runner の設計方法と今後の予定

Docker Model Runner を使用して AI モデルをローカルでビルド、実行、パッケージ化する方法

製品

特徴

開発者

料金プラン

会社

言語

DockerがAIモデルのパッケージ化にOCI Artifactsを選択した理由

OCIアーティファクトを使用する理由

OCIイメージおよびアーティファクトの理解

OCIイメージとは

OCIアーティファクトとは

コンテナイメージの使用とカスタムアーティファクトタイプ

Docker モデルアーティファクト

メディアの種類

積荷目録

モデル ID

モデル構成 JSON

層

流通

発見

Docker Hub

Hugging Face

次は何ですか?

さらに詳しく

掲示 される

投稿タグ

投稿カテゴリ

関連記事

アプリ開発のDockerの現状:セキュリティ

舞台裏: Docker Model Runner の設計方法と今後の予定

Docker Model Runner を使用して AI モデルをローカルでビルド、実行、パッケージ化する方法

掲示される