デベロッパー

本番環境向けマルチモーダルファインチューニングパイプラインの構築

2025年6月23日

https://storage.googleapis.com/gweb-cloudblog-publish/images/updated_hero_1.max-2500x2500.png

Ayo Adedeji

Developer Relations Engineer

※この投稿は米国時間 2025 年 6 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

マルチモーダル AI モデルを特定のドメイン向けにファインチューニングしようとして、インフラストラクチャや実装の課題に悩まされていませんか。このガイドでは、Google Cloud と Axolotl を使用してマルチモーダルの実装のギャップを解消する方法について説明します。SIIM-ISIC Melanoma データセットで Gemma 3 をファインチューニングする完全なハンズオンサンプルも示します。GPU リソースの管理、データ準備、分散トレーニングに関する一般的な課題に対処しながら、コンセプトを本番環境向けに実用化する方法を学びましょう。

https://storage.googleapis.com/gweb-cloudblog-publish/images/updated_medical_disclaimer.max-1000x1000.png

ギャップを埋める

さまざまな業界の組織が、業務や顧客体験を変革しようと急速にマルチモーダル AI の導入を進めています。Gartner のアナリストは、2027 年までに生成 AI ソリューションの 40% がマルチモーダル（テキスト、画像、音声、動画）になり、2023 年の 1% から大幅に増加すると予測しています。これは、何種類ものデータを同時に処理して理解できるソリューションの需要が高まっていることを強く示しています。

医療機関はすでにこのようなシステムを使用して、患者記録とともに医療画像を分析し、診断を迅速化しています。小売企業は、買い物客が画像で検索して、パーソナライズされたおすすめ情報を得られるショッピングエクスペリエンスを構築しています。製造チームは、目視検査に技術データを組み合わせることで、品質の問題を検出しています。カスタマーサービスチームは、顧客からの質問とともにスクリーンショットや写真を処理するエージェントを導入して、問題解決の時間を短縮しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/industries-in-action_3.max-2200x2200.png

マルチモーダル AI アプリケーションは、人間の思考をかなり正確に再現しています。人間はさまざまな種類のデータごとに個別に世界を体験しているわけではありません。視覚的な手がかり、テキスト、音、コンテキストを組み合わせて、何が起こっているかを把握します。組織独自のビジネスデータでマルチモーダルモデルをトレーニングすると、チームの作業方法と AI システムの運用方法のギャップを埋めることができます。

本番環境へのデプロイで組織が直面する主な課題

マルチモーダル AI のプロトタイプを本番環境向けに実用化するのは容易ではありません。PwC のアンケート調査データによると、積極的にテストが行われているものの、ほとんどの企業が、現在の試験運用版のうち今後 6 か月以内に本格運用に至るのは 30% 未満であると予想しています。特にカスタマイズされたモデルの採用率は依然として低く、本番環境でカスタムモデルを積極的に使用している組織はわずか 20～25% にすぎません。

以下のような技術的な課題が、常に成功の妨げになっています。

インフラストラクチャの複雑さ: マルチモーダルファインチューニングは大抵の場合、テキストのみのモデルの 4～8 倍にのぼる大量の GPU リソースを必要とします。多くの組織は、必要なハードウェアにアクセスできず、分散トレーニング環境を効率的に構成するのに苦労しています。

データ準備の障害: マルチモーダルトレーニングデータの準備は、テキストのみのデータの準備とは根本的に異なります。組織は、画像とテキストのペアを適切にフォーマットし、さまざまなファイル形式を処理し、視覚的要素とテキスト要素の関係を維持する効果的なトレーニングサンプルを作成するのに苦労しています。

トレーニングワークフローの管理: 複数の GPU にわたって分散トレーニングを構成してモニタリングするために必要な専門知識を、ほとんどのチームは持ち合わせていません。マルチモーダルモデルにはパラメータチューニング、チェックポイント管理、最適化も必要で、複雑さはさらに増します。

こうした技術的な障壁が、「マルチモーダル実装のギャップ」、つまり潜在的なビジネス価値を見出すことと、それを本番環境で実現することの違いを生み出しています。

Google Cloud と Axolotl の連携による課題の解決

両社が連携して互いの強みを補完し合うことで、こうした課題に直接対処できます。Google Cloud は、要求の厳しいマルチモーダルワークロードに必要なエンタープライズグレードのインフラストラクチャ基盤を提供します。NVIDIA B200 Tensor Core GPU や Ironwood などの Google の専用ハードウェアアクセラレータは、これらのタスク向けに最適化されています。また、Google Cloud Batch、Vertex AI Training、GKE Autopilot などのマネージドサービスは、マルチ GPU 環境のプロビジョニングとオーケストレーションの複雑さを最小限に抑えます。このインフラストラクチャは、幅広い ML エコシステムとシームレスに統合可能で、本番環境のデプロイに必要なセキュリティとコンプライアンスの管理を維持しながら、スムーズなエンドツーエンドのワークフローを実現します。

Axolotl は、実装を簡素化する合理化されたファインチューニングフレームワークにより、この基盤を補完します。その構成主導のアプローチにより技術的な複雑さが抽象化されるため、チームはインフラストラクチャの細部ではなく成果の達成に集中できます。Axolotl は、複数のオープンソースおよびオープンウェイトの基盤モデルと、QLoRA のような効率的なファインチューニング手法をサポートしています。このフレームワークには、パフォーマンスを向上させる手法が最適化された形で実装されています。これらの手法は、コミュニティでテスト済みの、実用を通じて進化し続けるベストプラクティスに裏付けられたものです。

両社が協力することで、組織は複雑なインフラストラクチャの再構築や、カスタムのトレーニングコードの開発を行うことなく、本番環境グレードのマルチモーダルファインチューニングを実装できます。この組み合わせにより、価値創出までの時間が短縮され、以前は専門家が数か月をかけて開発していたものが、数週間の標準化された実装作業で実現するようになります。

ソリューションの概要

マルチモーダルファインチューニングパイプラインは、次の 5 つの重要なコンポーネントで構成されています。

基盤モデル: タスクの要件を満たすベースモデルを選択します。Axolotl は、Llama 4、Pixtral、LLaVA-1.5、Mistral-Small-3.1、Qwen2-VL など、さまざまなオープンソースおよびオープンウェイトのマルチモーダルモデルをサポートしています。この例では、Google の最新のオープンなマルチモーダルモデルファミリーである Gemma 3 を使用します。
データ準備: 画像とテキストの関係を維持した、適切にフォーマットされたマルチモーダルトレーニングデータを作成します。これには、画像とテキストのペアの整理、ファイル形式の処理、トレーニングセットと検証セットへのデータの分割が含まれます。
トレーニング構成: Axolotl の YAML ベースのアプローチを使用してファインチューニングパラメータを定義します。これにより、QLoRA などのアダプタ、学習率、モデル固有の最適化などの設定が簡素化されます。
インフラストラクチャのオーケストレーション: スケールと運用要件に基づいて、適切なコンピューティング環境を選択します。選択肢には、シンプルさを重視した Google Cloud Batch、柔軟性を重視した Google Kubernetes Engine、MLOps の統合を重視した Vertex AI カスタムトレーニングなどがあります。
本番環境への統合: ファインチューニングからデプロイまでの道筋を合理化します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/multimodal_finetuning_pipeline_components.max-1600x1600.png

上のパイプライン構造は、マルチモーダルファインチューニングシステム全体の概念的なコンポーネントを表したものです。このガイドで後ほど示すハンズオンサンプルでは、オーケストレーションに GKE を使用して、SIIM-ISIC Melanoma データセットに合わせて調整された具体的な実装を通じて、これらの概念を具現化します。実装の詳細はデータセットの特性や要件によって異なる場合がありますが、コアコンポーネントは同じです。

適切な Google Cloud 環境の選択

Google Cloud には、マルチモーダルファインチューニングワークロードをオーケストレートするための複数の方法が用意されています。ここでは 3 つのオプションを見ていきましょう。これらは、シンプルさ、柔軟性、統合のトレードオフがそれぞれ異なります。

Google Cloud Batch

Google Cloud Batch は、GPU 負荷の高いトレーニングジョブを最小限のインフラストラクチャ管理で最大限シンプルに実行したい場合に最適です。すべてのリソースのプロビジョニング、スケジューリング、依存関係が自動的に処理されるため、コンテナオーケストレーションや複雑な設定が不要です。このフルマネージドサービスはパフォーマンスと費用対効果のバランスがよく、運用上のオーバーヘッドのない強力なコンピューティング機能を必要とするチームに理想的です。

Vertex AI カスタムトレーニング

Vertex AI カスタムトレーニングは、Google Cloud の MLOps エコシステムとのインテグレーションと、マネージドテストの追跡を優先する場合に最適です。Vertex AI カスタムトレーニングジョブは、指標を追跡する Experiments、バージョン管理を行う Model Registry、ワークフローオーケストレーションを行う Pipelines、デプロイを行う Endpoints と自動的に統合されます。

Google Kubernetes Engine（GKE）

GKE は、コンテナ化されたワークロードと柔軟に統合したい場合に最適です。Kubernetes の高度なスケジューリング機能を活用しながら、コンテナエコシステム内の他のサービスとともにトレーニングジョブの統合管理を行うことができます。GKE は、リソース割り当てをきめ細かく制御できるため、複雑な ML パイプラインに最適です。ハンズオンサンプルでは、Autopilot モードの GKE を使用します。このモードでは、これらの統合のメリットを維持しながら、Google Cloud がノードのプロビジョニングやスケーリングなどのインフラストラクチャ管理を自動化します。これにより、Kubernetes の柔軟性と、マネージドサービスの運用のシンプルさを組み合わせて、クラスタの管理ではなく ML タスクに集中できます。

GKE でマルチモーダルファインチューニングジョブをオーケストレートする方法を示す完全な実装例については、こちらのコードサンプルをご覧ください。

読み込んでいます...

このリポジトリには、Autopilot モードの GKE に Axolotl トレーニングジョブをデプロイするための、すぐに使用できる Kubernetes マニフェストが含まれており、GPU を使用した自動クラスタ設定、永続ストレージ構成、ジョブ仕様、モニタリング統合などが記載されています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/gke_architecture_axolotl_training_deployme.max-1500x1500.png

ハンズオンサンプル: SIIM-ISIC Melanoma データセットで Gemma 3 をファインチューニング

このセクションでは、悪性か良性かを示すラベルを付けた皮膚病変のダーモスコピー画像（医療用拡大鏡を使って撮影された画像）を使用します。黒色腫（メラノーマ）は比較的まれではあるものの、皮膚がんによる死亡原因の 75% を占めており、患者の生存には早期かつ正確な発見が不可欠です。この課題にマルチモーダル AI を適用することで、皮膚科医が診断精度を向上させ、危険な病変をより迅速かつ確実に特定して人命を救える可能性を高めることができます。では、SIIM-ISIC Melanoma Classification データセットで Gemma 3 をファインチューニングする完全な例を見ていきましょう。

この実装では、Autopilot モードの GKE を利用して、トレーニングジョブとモニタリングをオーケストレートします。これにより、インフラストラクチャ管理を Google Cloud に任せて ML ワークフローに集中できます。

データ準備

SIIM-ISIC Melanoma Classification データセットは、Axolotl を使用したマルチモーダルファインチューニングのための特定の形式にする必要があります。データ準備プロセスには、次の 2 つの主なステップが含まれます。（1）Storage Transfer Service を使用してデータセットを Cloud Storage に効率的に転送する。（2）元データを Axolotl で必要な形式に処理する。まず、データセットを転送します。

ISIC データセットファイルの URL を含む TSV ファイルを作成します。

読み込んでいます...

データセットのバケットを作成します。

読み込んでいます...

TSV ファイルを Cloud Storage バケットにアップロードします。

読み込んでいます...

Storage Transfer Service に適切な IAM 権限を設定します。

読み込んでいます...

# 現在のプロジェクト ID を取得する
export PROJECT_ID=$(gcloud config get-value project)

# プロジェクト番号を取得する
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")

# Storage Transfer API を有効にする
echo "Enabling Storage Transfer API..."
gcloud services enable storagetransfer.googleapis.com --project=${PROJECT_ID}

# 重要: Storage Transfer Service アカウントは、サービスにアクセスした後に作成される
# Google Cloud コンソールで Storage Transfer Service にアクセスして、作成をトリガーする:
# https://console.cloud.google.com/transfer/cloud
echo "IMPORTANT: Before continuing, please visit the Storage Transfer Service page in the Google Cloud Console"
echo "Go to: https://console.cloud.google.com/transfer/cloud"
echo "This ensures the Storage Transfer Service account is properly created."
echo "After visiting the page, wait approximately 60 seconds for account propagation, then continue."
echo ""
echo "Press Enter once you've completed this step..."
read -p ""

# Storage Transfer Service に必要な権限を付与する
export STS_SERVICE_ACCOUNT_EMAIL="project-${PROJECT_NUMBER}@storage-transfer-service.iam.gserviceaccount.com"
echo "Granting permissions to Storage Transfer Service account: ${STS_SERVICE_ACCOUNT_EMAIL}"

gcloud storage buckets add-iam-policy-binding gs://${GCS_BUCKET_NAME} \
--member=serviceAccount:${STS_SERVICE_ACCOUNT_EMAIL} \
--role=roles/storage.objectViewer \
--condition=None

gcloud storage buckets add-iam-policy-binding gs://${GCS_BUCKET_NAME} \
--member=serviceAccount:${STS_SERVICE_ACCOUNT_EMAIL} \
--role=roles/storage.objectUser \
--condition=None

URL リストを使用してストレージ転送ジョブを設定します。

[Cloud Storage] > [転送] に移動します。
[転送ジョブを作成] をクリックします。
ソースタイプとして [URL リスト]、宛先タイプとして [Google Cloud Storage] を選択します。
TSV ファイルへのパスを入力します: gs://<GCS_BUCKET_NAME>/melanoma_dataset_urls.tsv
保存先バケットを選択します。
デフォルトのジョブ設定を使用して [作成] をクリックします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/storage-transfer-job-completion_1.max-2200x2200.png

この転送では、約 32 GB のデータを ISIC Challenge リポジトリから Cloud Storage バケットに直接ダウンロードします。転送が完了したら、ZIP ファイルを抽出する必要があります。次のステップでは、このデータを Axolotl 用にフォーマットします。Axolotl 用にデータをフォーマットする方法の詳細については、こちらの GitHub リポジトリのノートブックをご覧ください。

マルチモーダルトレーニングデータの準備

Gemma 3 のようなマルチモーダルモデルの場合、拡張形式 chat_template に従ってデータを構造化する必要があります。この形式では、テキストと画像の両方のコンテンツを含む一連のメッセージとして会話が定義されます。

以下は、単一のトレーニング入力の例です。

読み込んでいます...

データをトレーニング（80%）、検証（10%）、テスト（10%）に分割します。この際、層化サンプリングを使用して各分割のクラス分布が維持されるようにします。

この形式により、Axolotl は、トレーニング中に視覚要素とテキスト要素の関係を維持しながら、画像とそれに対応するラベルの両方を適切に処理できます。

Axolotl 構成ファイルの作成

次に、Axolotl の構成ファイルを作成して、Gemma 3 をファインチューニングする方法を定義します。4 ビット量子化を用いる QLoRA（Quantized Low-Rank Adaptation）を使用して、メモリ要件を管理可能な範囲に抑えながら、モデルを効率的にファインチューニングします。A100 40 GB GPU には十分なメモリがありますが、QLoRA を使用した 4 ビット量子化により、必要に応じてより大きなバッチサイズやシーケンス長でトレーニングできるため、黒色腫の分類タスクの柔軟性がさらに高まります。適合率はわずかに低下しますが、通常は許容できるトレードオフです。特に、ゼロからトレーニングするのではなく事前トレーニング済みモデルを適応させるファインチューニングタスクでは、その分の価値があります。

読み込んでいます...

# gemma3-melanoma.yaml ファイルを作成する
cat > gemma3-melanoma.yaml << EOF
# ベースモデルの構成
base_model: google/gemma-3-4b-it
model_type: AutoModelForCausalLM
tokenizer_type: GemmaTokenizer
processor_type: AutoProcessor
chat_template: gemma3

# Hugging Face 認証を有効にする
hf_use_auth_token: true

# データセットの構成
datasets:
  - path: /mnt/gcs/axolotl-data/siim_isic_train.jsonl
    type: chat_template
    ds_type: json
    field_messages: messages
    chat_template: gemma3

# トレーニング パラメータ
sequence_len: 4096
optimizer: adamw_torch_fused
lr_scheduler: cosine
learning_rate: 2e-5
weight_decay: 0.01
max_steps: 1000
warmup_steps: 100
gradient_checkpointing: true
gradient_accumulation_steps: 4
micro_batch_size: 1
save_strategy: epoch
save_total_limit: 2
flash_attention: true

# マルチモーダル固有の設定
skip_prepare_dataset: true
remove_unused_columns: false
sample_packing: false
image_size: 512
image_resize_algorithm: bilinear

# TensorBoard ロギングを有効にする
use_tensorboard: true

# 出力とロギング
output_dir: "/outputs/gemma3-melanoma"
logging_steps: 10
EOF

この構成は、黒色腫の分類タスク用に最適化されたパラメータを使用して QLoRA ファインチューニングを設定します。次に、トレーニングを実行するための GKE Autopilot 環境を設定します。

GPU トレーニング用の GKE Autopilot の設定

構成ファイルが準備できたので、トレーニングに使用する GKE Autopilot クラスタを設定しましょう。前述したように、Autopilot モードでは、Google Cloud がインフラストラクチャ管理を処理するため、ML タスクに集中できます。

では、GKE Autopilot クラスタを作成しましょう。

読み込んでいます...

# クラスタ構成の環境変数を設定する
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export CLUSTER_NAME=melanoma-training-cluster
export RELEASE_CHANNEL=regular

# 必要な Google API を有効にする
echo "Enabling required Google APIs..."
gcloud services enable container.googleapis.com --project=${PROJECT_ID}
gcloud services enable compute.googleapis.com --project=${PROJECT_ID}

# データと同じリージョンに GKE Autopilot クラスタを作成する
echo "Creating GKE Autopilot cluster ${CLUSTER_NAME}..."
gcloud container clusters create-auto ${CLUSTER_NAME} \
  --location=${REGION} \
  --project=${PROJECT_ID} \
  --release-channel=${RELEASE_CHANNEL}

# まだの場合、kubectl をインストールする
if ! command -v kubectl &> /dev/null; then
  echo "Installing kubectl..."
  gcloud components install kubectl
fi

# kubectl に必要な GKE 認証プラグインをインストールする
echo "Installing GKE auth plugin..."
gcloud components install gke-gcloud-auth-plugin

# クラスタを使用するように kubectl を構成する
echo "Configuring kubectl to use the cluster..."
gcloud container clusters get-credentials ${CLUSTER_NAME} \
  --location=${REGION} \
  --project=${PROJECT_ID}

# kubectl が正しく動作していることを確認する
echo "Verifying kubectl connection to cluster..."
kubectl get nodes

次に、サービスアカウントキーを使用せずに Google Cloud APIs と安全に認証できるように、GKE 用の Workload Identity 連携を設定します。

読み込んでいます...

# Workload Identity 連携の変数を設定する
export PROJECT_ID=$(gcloud config get-value project)
export NAMESPACE="axolotl-training"
export KSA_NAME="axolotl-training-sa"
export GSA_NAME="axolotl-training-sa"

# トレーニング ジョブ用の Kubernetes 名前空間を作成する
kubectl create namespace ${NAMESPACE} || echo "Namespace ${NAMESPACE} already exists"

# Kubernetes ServiceAccount を作成する
kubectl create serviceaccount ${KSA_NAME} \
    --namespace=${NAMESPACE} || echo "ServiceAccount ${KSA_NAME} already exists"

# IAM サービス アカウントを作成する
if ! gcloud iam service-accounts describe ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com &>/dev/null; then
    echo "Creating IAM service account ${GSA_NAME}..."
    gcloud iam service-accounts create ${GSA_NAME} \
        --display-name="Axolotl Training Service Account"
    
    # IAM の伝播を待つ
    echo "Waiting for IAM service account creation to propagate..."
    sleep 15
else
    echo "IAM service account ${GSA_NAME} already exists"
fi

# IAM サービス アカウントに必要な権限を付与する
echo "Granting storage.objectAdmin role to IAM service account..."
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/storage.objectAdmin"

# IAM の伝播を待つ
echo "Waiting for IAM policy binding to propagate..."
sleep 10

# Kubernetes ServiceAccount が IAM サービス アカウントの権限を借用できるようにする
echo "Binding Kubernetes ServiceAccount to IAM service account..."
gcloud iam service-accounts add-iam-policy-binding ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com \
    --role="roles/iam.workloadIdentityUser" \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[${NAMESPACE}/${KSA_NAME}]"

# Kubernetes ServiceAccount にアノテーションを付ける
echo "Annotating Kubernetes ServiceAccount..."
kubectl annotate serviceaccount ${KSA_NAME} \
    --namespace=${NAMESPACE} \
    iam.gke.io/gcp-service-account=${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com --overwrite

# 構成を確認する
echo "Verifying Workload Identity Federation setup..."
kubectl get serviceaccount ${KSA_NAME} -n ${NAMESPACE} -o yaml

次に、モデルの出力用に PersistentVolumeClaim を作成します。Autopilot モードでは、Google Cloud が基盤となるストレージクラスを管理するため、独自のストレージクラスを作成する必要はありません。

読み込んでいます...

PVC 構成を適用します。

読み込んでいます...

トレーニングジョブを GKE Autopilot にデプロイ

Autopilot モードでは、ジョブ定義の Pod テンプレートセクション内で、アノテーションとリソースリクエストを使用して GPU 要件を指定します。1 つの A100 40 GB GPU をリクエストする Kubernetes Job を作成します。

読み込んでいます...

# axolotl-training-job.yaml ファイルを作成する
cat > axolotl-training-job.yaml << EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: gemma3-melanoma-training
  namespace: ${NAMESPACE}
spec:
  backoffLimit: 0
  template:
    metadata:
      annotations:
        gke-gcsfuse/volumes: "true"
    spec:
      serviceAccountName: ${KSA_NAME}
      nodeSelector:
        cloud.google.com/gke-accelerator: nvidia-tesla-a100
      restartPolicy: Never
      containers:
      - name: axolotl
        image: axolotlai/axolotl:main-latest
        command: ["/bin/bash", "-c"]
        args:
          - |
            # ディレクトリ構造とシンボリック リンクを作成する
            mkdir -p /mnt/gcs/${GCS_BUCKET_NAME}
            ln -s /mnt/gcs/processed_images /mnt/gcs/${GCS_BUCKET_NAME}/processed_images
            echo "Created symbolic link for image paths"
            
            # ここでトレーニングを実行する
            cd /workspace/axolotl && python -m axolotl.cli.train /workspace/configs/gemma3-melanoma.yaml
        env:
        - name: HUGGING_FACE_HUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: huggingface-credentials
              key: token
        - name: NCCL_DEBUG
          value: "INFO"
        resources:
          limits:
            nvidia.com/gpu: 1
          requests:
            memory: "32Gi"
            cpu: "8"
            ephemeral-storage: "10Gi"
            nvidia.com/gpu: 1
        volumeMounts:
        - name: config-volume
          mountPath: /workspace/configs
        - name: model-storage
          mountPath: /outputs
        - name: gcs-fuse-csi
          mountPath: /mnt/gcs
      volumes:
      - name: config-volume
        configMap:
          name: axolotl-config
      - name: model-storage
        persistentVolumeClaim:
          claimName: model-storage
      - name: gcs-fuse-csi
        csi:
          driver: gcsfuse.csi.storage.gke.io
          volumeAttributes:
            bucketName: ${GCS_BUCKET_NAME}
            mountOptions: "implicit-dirs"
EOF

Axolotl 構成を使用して ConfigMap を作成します。

読み込んでいます...

Hugging Face の認証情報を使用して Secret を作成します。

読み込んでいます...

トレーニングジョブ YAML を適用してトレーニングプロセスを開始します。

読み込んでいます...

トレーニングプロセスのモニタリング

Pod 名を取得して、進行状況をモニタリングします。

読み込んでいます...

TensorBoard を設定してトレーニング指標を可視化します。

読み込んでいます...

# TensorBoard Deployment とサービス YAML を作成する
cat > tensorboard.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tensorboard
  namespace: ${NAMESPACE}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tensorboard
  template:
    metadata:
      labels:
        app: tensorboard
      annotations:
        gke-gcsfuse/volumes: "true"
    spec:
      serviceAccountName: ${KSA_NAME}
      containers:
      - name: tensorboard
        image: tensorflow/tensorflow:2.14.0
        command:
        - tensorboard
        args:
        - --logdir=/outputs/gemma3-melanoma
        - --host=0.0.0.0
        - --port=6006
        readinessProbe:
          httpGet:
            path: /
            port: 6006
          initialDelaySeconds: 30
          periodSeconds: 10
        volumeMounts:
        - name: model-storage
          mountPath: /outputs
      volumes:
      - name: model-storage
        persistentVolumeClaim:
          claimName: model-storage
---
apiVersion: v1
kind: Service
metadata:
  name: tensorboard
  namespace: ${NAMESPACE}
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 6006
  selector:
    app: tensorboard
EOF

TensorBoard をデプロイします。

読み込んでいます...

モデルのエクスポートと評価の設定

トレーニングが完了したら、ファインチューニングされたモデルをエクスポートし、ベースモデルと比較してパフォーマンスを評価する必要があります。まず、トレーニング環境から Cloud Storage にモデルをエクスポートします。

モデルをエクスポートする Pod を作成します。

読み込んでいます...

model-export.yaml ファイルを作成したら、それを適用します。

読み込んでいます...

これにより、エクスポートプロセスが開始され、ファインチューニングされたモデルが Kubernetes PersistentVolumeClaim から Cloud Storage バケットにコピーされます。これにより、モデルへのアクセスと評価が容易になります。

エクスポート後にファインチューニング済みモデルを評価する方法は、いくつかあります。たとえば、ベースモデルとファインチューニングされたモデルの両方を、それぞれの Vertex AI エンドポイントにデプロイして、API 呼び出しによる体系的なテストを行うことができます。これは、大量の自動テストや本番環境同様の評価に適しています。あるいは、探索的分析と可視化を行うこともできます。これには、Vertex Workbench インスタンスや Colab Enterprise などの GPU 対応のノートブック環境を使用すると大きなメリットが得られ、結果のリアルタイムでの可視化、インタラクティブなデバッグ、迅速なイテレーションによる評価指標の改善が可能になります。

この例では、ノートブック環境を使用して、その可視化機能とインタラクティブ性を活用します。評価アプローチには以下が含まれます。

ベースモデルとファインチューニングされたモデルの両方を読み込む
SIIM-ISIC データセットから取得した皮膚画像のテストセットで推論を実行する
標準的な分類指標（精度、適合率、再現率など）を計算する
混同行列を分析してエラーパターンを理解する
パフォーマンスの違いを示すビジュアリゼーションを生成する

完全な評価コードと実装の詳細については、GitHub リポジトリの評価ノートブックをご覧ください。

パフォーマンス結果

評価の結果、汎用マルチモーダルモデルは、ドメイン固有のファインチューニングにより、医療画像分類などの専門的なタスクを行うツールとしての有効性が大きく高まることが実証されました。複数の項目でモデルのパフォーマンスの大幅な改善が見られました。

最も注目すべき点として、ベースモデルでは黒色腫が過剰診断される傾向がありました。再現率は完璧（1.000）でしたが、特異度は極めて低く（0.011）、ほぼすべての病変が黒色腫としてラベル付けされていました。この挙動は臨床現場において問題となるもので、偽陽性は不要な処置や患者の不安、医療費の増加につながります。

ファインチューニングにより、モデルの機能が大幅に向上して良性病変を正しく識別できるようになり、偽陽性が 3,219 件から 1,438 件に減少しました。再現率が 1.000 から 0.603 に低下するというトレードオフはありましたが、全体的な診断機能は大幅に向上し、バランス精度が大幅に改善しました。

今回の評価には、新たに発表された MedGemma の結果も含めました。MedGemma は医療分野のテキストと画像の理解に特化してトレーニングされた Gemma 3 のバリアントの集合で、先日 Google I/O で発表されたものです。これらの結果は、さまざまなモデルの出発点が、専門的な医療タスクのパフォーマンスにどのように影響するかについての理解を深めるのに役立ちます。

以下に、3 つのモデルすべてのパフォーマンス指標を示します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/model_performance_comparison.max-1400x1400.png

精度は、ベースの Gemma 3 モデルではわずか 0.028 ですが、ファインチューニングされた Gemma 3 モデルでは 0.559 に跳ね上がり、1870.2% という驚異的な改善が示されました。MedGemma は、タスク固有のファインチューニングなしで 0.893 の精度を達成しました。これは、ベースモデル比で 3048.9% 高い値であり、カスタムチューニングされたバージョンよりも大きく優れています。

ファインチューニングされたモデルでは、適合率は 34.2% 向上し（0.018 から 0.024）、MedGemma では 112.5%（0.038）と飛び抜けていました。最も顕著だったのは、特異度、つまりモデルが黒色腫でない症例を正しく識別する機能の変化でした。ファインチューニングされたモデルの特異度は 0.011 から 0.558 に向上（4947.2% の改善）し、MedGemma では 0.906 に達しました（ベースモデル比で 8088.9% 高い）。

これらの数値は、ファインチューニングによって、モデルが単に黒色腫を予測するのではなく、皮膚病変の特徴をより細かく理解できるようになったことを示しています。MedGemma の結果は、医療アプリケーションの場合は医療用にトレーニングされた基盤モデルから始めると大きなメリットが得られることを示しています。

次の混同行列は、これらの違いをわかりやすく図示したものです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/comparative_confusion_matrices.max-1000x1000.png

ベースの Gemma 3 行列（左）を見ると、実際の陽性症例 58 件すべてを正しく識別している（完全な再現率）一方で、3,219 件の陰性症例を誤って陽性として分類している（低い特異度）ことがわかります。ファインチューニングされたモデル（中央）は、よりバランスの取れた分布を示しており、1,817 件の真陰性を正しく識別し、58 件の真陽性のうち 35 件を正しく識別しています。MedGemma（右）は、2,948 件の真陰性を正しく識別しており、優れたパフォーマンスを示していますが、他のモデルよりも偽陰性が多くなっています（46 件の黒色腫症例を見逃し）。

これらの違いが実際にどのような影響を与えるのかを説明するために、テストセットの実際の例、画像 ISIC_4908873 を見てみましょう。

https://storage.googleapis.com/gweb-cloudblog-publish/images/ISIC_4908873_1.max-2200x2200.jpg

免責条項: この画像は例として使用するためにのみ掲載しています。

ベースモデルはこれを誤って黒色腫と分類しました。その根拠として、黒色腫の一般的な兆候に焦点を当て、「色の著しい変化」、「不規則で境界が不明瞭」、「非対称」を悪性の決定的な指標として挙げており、それらをより広い良性パターンにあてはめることはしていませんでした。

一方、ファインチューニングされたモデルは、それを正しく良性と識別しました。「不均一な色の混在」や「境界が不規則」であることを認めながらも、そのような色の混ざり合いは「良性の母斑ではよく見られる」と見極めました。そして重要な点として、病変の全体的な「斑点状の外観で、小さな色の変化が多数ある」ことは、「黒色腫よりも一般的なほくろの特徴」であると解釈しました。

興味深いことに、MedGemma もこの病変を黒色腫と誤って分類しており、「病変は、境界が不規則で、色が不均一で、表面がやや隆起しているという、懸念される外観を示しています。これらの特徴は黒色腫を示唆しています。そのため、これは悪性黒色腫のようです」と回答しています。MedGemma の全体的な統計的パフォーマンスは優れているものの、この例は、ドメイン特化型モデルであっても、特定の診断課題に対するタスク固有のファインチューニングにより効果が得られることを示しています。

これらの結果により、ドメイン固有の AI システムを構築する組織にとって重要な知見が得られました。つまり、基盤モデルは出発点として強力な機能を備えていますが、専門的なアプリケーションに必要な適合率と信頼性を実現するには、多くの場合、対象を絞ったファインチューニングが不可欠だということです。実質的にすべてを黒色腫とラベル付けしていたモデルが、臨床的に有用な区別を行えるようになり、パフォーマンスが大幅に改善されたことから、適切なインフラストラクチャ、トレーニング方法、ドメイン固有のデータを組み合わせることの価値が改めて示されました。

MedGemma の優れた統計的パフォーマンスは、ドメインに特化した基盤モデルから始めることで、ベースラインの機能が大幅に向上し、効果的な医療 AI アプリケーションの構築に必要なデータや計算を削減できることを実証しています。ただし、この事例では、そのような特化型モデルであっても、臨床環境で最適な診断精度を得るには、タスク固有のファインチューニングが有用であることも明らかになりました。

マルチモーダルへの道のりの次のステップ

Google Cloud のエンタープライズインフラストラクチャと Axolotl の構成に基づくアプローチを組み合わせることで、以前は数か月の専門的な開発を要した作業を、数週間の標準化された実装で完了することができるようになります。これにより、より効率的かつ確実に、カスタムのマルチモーダル AI 機能をコンセプトの状態から本番環境向けに実用化できます。

詳細については、以下のリソースをご確認ください。