[Amazon SageMaker] Hugging Face のモデルページから「ワンクリック」で Amazon SageMaker AI にデプロイしてみました

1 はじめに

製造ビジネステクノロジー部の平内（SIN）です。

2026年7月、Hugging Face のモデルページから、Amazon SageMaker Studio へ直接着地できるディープリンク連携が追加されました。モデルページの Deploy ドロップダウンから「Deploy on SageMaker AI」を選ぶと、モデルがプリロードされた状態で Studio のデプロイ画面に遷移する、というものです。

https://docs.aws.amazon.com/sagemaker/latest/dg/hugging-face.html

https://huggingface.co/docs/sagemaker/index

Hugging Face で公開されているモデルは、Inference API で簡単に利用できるのですが、わざわざ AWS SageMaker に持ってくる利点や、ワンクリックで利用できるようになった利点は、概ね以下のようなものかと思いました。

• 自社アカウント内に閉じることができる（VPC 分離、IAM でのアクセス制御、CloudTrail での監査ログが利用可能）。
• Amazon Bedrock のカタログにないモデルや、自社データでファインチューニングしたモデルを動かせる。
• AWS 運用基盤に乗せられる（コスト配分タグ、Organizations、SCP などがそのまま適用できる）。
• 気になったモデルを、環境構築の手間をかけずに自分の AWS アカウントですぐ試せる。
• つまずきによる離脱が減少する（ドメイン作成・実行ロール・ネットワークまわりが自動で用意され、GPU クォータの空きも画面上で確認できる）。
• 「評価してみる → 採用する」の検証サイクルを回しやすい。

まずは、「Hugging Face でモデルを見つけた」から「自分の AWS 環境で動かして確かめる」までの距離が著しく近づいたのは、間違いありません。

本稿では、この連携のうち「Deploy 経路（推論エンドポイントを立てる）」の方を実際に試してみました。「Customize 経路（ファインチューニング）」については、別途、改めてとさせてください。

なお、結果は 2026年8月上旬・バージニア(us-east-1)・特定のアカウントでの確認結果です。対応モデルやクォータ、権限まわりは、今後変更される可能性があることを予めご了承ください。

2 何が変わったのか

公式で挙げられているポイントは3つです。

1. ディープリンク — Hugging Face のモデルページから、モデルがプリロードされた状態で Studio に着地
2. 権限の事前設定 — 新規 Studio 環境に、デプロイ／カスタマイズ向けのマネージドポリシーが自動でアタッチされる（※詳細は6章）
3. GPU クォータ可視化 — インスタンス選択時に空き状況が表示され、不足時は Service Quotas へ誘導される（※詳細は3.3）

そして、Hugging Face から持ってきた後の着地先は2経路に分かれ、その後にできることが変わります。

課金モデルについて

Deploy 経路で作られるのはリアルタイム推論エンドポイントで、課金は起動している時間に対して発生します（トークン従量ではありません）。使っていなくても起動したままなら課金が続くため注意が必要です（本稿では、最後に削除まで行っています）。

3 やってみた: Hugging Face のモデルページから推論まで

3.1 Hugging Face のモデルページからの導線とモデル選択

モデルページの Deploy ドロップダウンを開くと、Cloud providers の一覧に Amazon SageMaker AI が表示されます。

これを選ぶと、対象のモデルであれば「Deploy on SageMaker AI」「Customize on SageMaker AI」の2つのボタンが表示されます。ただし、モデルによってはボタンが出ないことがあります。最初に試した小型の Qwen/Qwen2.5-0.5B-Instruct では、「このモデルはまだ Amazon SageMaker AI の Hugging Face コレクションにありません（Request to Add）」と表示され、ボタンは出ませんでした。

対応モデルはコレクションに収録されているものに限られるようで、収録状況は今後変わる可能性があります。そこで、収録済みで、かつゲート（HF 側のライセンス承諾）が不要な Qwen/Qwen2.5-7B-Instruct（Apache-2.0）に変更しました。こちらは「利用可能」と表示され、2つのボタンが出ます。

Deploy on SageMaker AI を押すと SageMaker Studio へ遷移します。

補足: あらかじめ別タブで AWS コンソールにサインインし、デプロイしたリージョンに変更しておくと、サインイン画面を挟まずにそのまま次の画面へ着地しました。

3.2 Studio 着地とドメインの自動作成

既存ドメインが無いリージョンだったため、着地の前に「マネージド AI 開発環境のセットアップ」画面が表示され、ドメインが自動作成されました。画面には所要時間の目安として「約20秒」と表示されます。

「スタジオのセットアップを開始」を選択するとセットアップが進み、無事に完了しました。

3.3 インスタンス選択と GPU クォータ表示

デプロイ画面に着地すると、モデル（qwen2-5-7b-instruct-180046）がプリロードされていました。ここでクォータ表示が確認できます。私の環境ではデフォルトで選ばれていた ml.g6e.2xlarge に「Quota limit reached」と表示され、Service Quotas へのリンクが出ていました。

インスタンスのドロップダウンを開くと、候補ごとに「X of Y quota used」という形で空き状況が表示されます。私のアカウントの状況では、空きがあったのは ml.g4dn.12xlarge / ml.g5.12xlarge / ml.g6.12xlarge（いずれも 0 of 1）で、g6e 系は 0 of 0 でした。

7B モデル自体は 1 GPU でも動く規模ですが、私のクォータ状況では、増加申請をせずに今すぐ選べるのは 4GPU の 12xlarge 級だけでした（このあたりはアカウントのクォータによって変わります）。コストを抑えるため、候補の中で最も安い ml.g4dn.12xlarge を選択しました。

3.4 デプロイと推論テスト

Deploy を押すとエンドポイントの作成が始まり、ステータスは Creating になります。作成中のエンドポイントは、確認する場所によって見え方が変わります。

SageMaker Studio の「Endpoint summary」画面では、ARN やエンドポイントログへのリンクなどがまとまって表示されます。

同じエンドポイントは、SageMaker AI コンソールの「エンドポイント」一覧からも確認できます。こちらは複数のエンドポイントを一覧で見たいときに便利です。

ステータスが InService になるまで、私の環境では 約8分 でした。

エンドポイント画面の Playground タブから推論を試せます。サンプルのリクエストを実行すると成功しました。

日本語のプロンプトも試しました。7B なので、それなりに自然な日本語が返ってきました。

4 ペイロード形式

モデルを利用する際に、一番気になるのはペイロード形式だと思いますが、今回のエンドポイント（JumpStart の Hugging Face LLM コンテナ）は、以下の形式となっていました。

リクエスト（Content-Type: application/json）:

{
  "inputs": "AWSを一言で説明してください。",
  "parameters": { "do_sample": true, "max_new_tokens": 256 }
}

レスポンス:

{ "generated_text": " クラウドコンピューティングのプラットフォームとして、高度なスケーラビリティと柔軟性を持ち、様々なサービス（インスタンス、ストレージ、データベースなど）を利用できる…" }

messages を使う OpenAI 互換形式ではなく、Text Generation Inference（TGI）のネイティブ形式（inputs ＋ parameters）で、レスポンスは generated_text キーで返っています。この形式はモデルやコンテナによって変わり得るので、実際のエンドポイントで確認するのが確実です。上記の形式は Studio の Playground（Test the sample request）で確認したものです。

作成されたエンドポイントは、通常の SageMaker エンドポイントなので、boto3 の invoke_endpoint からアプリケーションとして呼び出したり、Lambda / API Gateway / ECS と組み合わせたり、オートスケーリングや CloudWatch 監視、などの運用が可能です。

boto3 から叩く場合は、次のようになります（エンドポイント名は環境変数で渡す例）。上で確認した TGI 形式（inputs / parameters → generated_text）に合わせています。

import json
import os
import boto3

runtime = boto3.client("sagemaker-runtime", region_name=os.environ.get("AWS_REGION", "us-east-1"))
payload = {"inputs": "What is deep learning?",
           "parameters": {"do_sample": True, "max_new_tokens": 256}}
response = runtime.invoke_endpoint(
    EndpointName=os.environ["ENDPOINT_NAME"],
    ContentType="application/json",
    Body=json.dumps(payload),
)
# => {"generated_text": " ..."}
print(json.loads(response["Body"].read()))

5 後片付け

エンドポイントは起動している時間に対して課金されるため、検証後は削除します。エンドポイント名から設定名・モデル名を逆引きして、まとめて削除する例です。

export AWS_REGION=us-east-1
EP=<your-endpoint>

CFG=$(aws sagemaker describe-endpoint --endpoint-name "$EP" --query EndpointConfigName --output text)
MODEL=$(aws sagemaker describe-endpoint-config --endpoint-config-name "$CFG" \
  --query 'ProductionVariants[0].ModelName' --output text)

aws sagemaker delete-endpoint        --endpoint-name "$EP"      --region "$AWS_REGION"
aws sagemaker delete-endpoint-config --endpoint-config-name "$CFG" --region "$AWS_REGION"
aws sagemaker delete-model           --model-name "$MODEL"      --region "$AWS_REGION"

6 裏で作られたもの

自動作成されたリソースを CLI で確認しました。

ドメイン: QuickSetupDomain-20260803T030059 が作成され、ネットワーク構成は次のとおりでした。

• VPC: デフォルト VPC を利用（私の環境で作成したサブネットを使用）
• ネットワークモード: PublicInternetOnly（VPC 閉域ではなく、AWS マネージドゲートウェイ経由のアクセス）
• 認証: IAM

VPC 閉域にしたい場合は別途 VpcOnly 構成が必要になる、という点は押さえておくとよさそうです。

実行ロール: AmazonSageMaker-ExecutionRole-... が作成され、セットアップ画面には「AmazonSageMakerFullAccess」とだけ表示されていましたが、実際にアタッチされていたマネージドポリシーは複数でした。

• AmazonSageMaker-ExecutionPolicy-...（このロール用に自動生成）
• AmazonSageMakerFullAccess
• AmazonSageMakerModelCustomizationCoreAccess
• AmazonSageMakerCanvas 系 4種（SMDataScienceAssistantAccess / AIServicesAccess / FullAccess / DataPrepFullAccess）

IAM コンソールで実行ロールを開くと、7つのポリシーがアタッチされている様子が確認できます。

AmazonSageMakerModelCustomizationCoreAccess の中身を見ると、TrainingJob・MLflow・Pipelines に加え、報酬関数用の Lambda 作成や、Bedrock へのモデルインポート／カスタムモデル作成（CreateModelImportJob / CreateCustomModel と bedrock への PassRole）まで含まれていました。Customize 経路の成果物を Bedrock に載せられる、という導線が権限レベルで用意されていることが分かります。なお、各ステートメントには aws:ResourceAccount を自アカウントに限定する条件が付いていました。

アプリの起動状況: 「ドメインを作った時点で JupyterLab などが動いて課金されていないか」も確認しました。list-apps は空で、起動中のアプリ／スペースはありませんでした。今回の環境では、課金対象は推論エンドポイントのみでした。

7 どのモデルにボタンが出るのか

「どのモデルで連携ボタンが出るか」は気になるところなので、いくつかのモデルで Deploy メニューを確認しました。私が試した範囲では次のとおりです（収録状況は今後変わる可能性があります）。

私が試した範囲では、画像系（ViT / DETR）は Deploy メニューに「Amazon SageMaker AI」の項目自体が出ませんでした。

一方 Whisper（音声）は Deploy は可能で、Customize 側は「Request to Add for Customization」となっており、Deploy と Customize が独立して出し分けられていました。対応はタスク種別やモデルによって異なるようです。

8 Customize 経路の画面（参考）

本稿のスコープ外ですが、Customize on SageMaker AI の着地画面も確認しました（ジョブは実行していません）。

「Model customization」画面に着地し、Base model には Qwen2.5-7B-Instruct がプリロードされていました。カスタマイズ手法は SFT / DPO / RLVR / RLAIF の4種が選択でき、学習方式は LoRA / Full、データセットはアップロード or 既存から指定、という構成です。より細かく設定したい場合は JupyterLab ノートブックを開く導線も用意されていました。

9 後片付けとコスト

検証後は、起動時間課金を止めるためにエンドポイントを削除しました。削除後、一覧が空になっていることを確認しています。

• エンドポイント／エンドポイント設定／モデル: 削除済み（前章のコマンド）
• 起動中のアプリ／スペース: なし（今回の環境では最初から起動なし）
• 自動作成されたドメイン・サブネット: 存在自体は無料

10 最後に

Hugging Face からワンクリックで持ってくる連携を、Deploy 経路で試してみました。
やってみると、非常に簡単で、これで終わりなの？って感想です。

今回の検証で分かったことを3点にまとめます。

• データを外に出さず、Bedrock にないモデルも、既存の運用基盤の上で動かせる
• 課金はトークンではなく起動時間
• ペイロード形式は。Playgroundタブで確認できる

繰り返しになりますが、対応モデルの範囲・GPU クォータの状況・自動作成される権限やネットワーク構成は、アカウントや時期によって変わります。本稿はあくまで特定環境での一例として捉えてください。