hf-cloud-sagemaker-deployment-planner

SageMaker デプロイプランナー

Amazon SageMaker へのモデルのデプロイを支援します。このスキルを利用するユーザーの多くは、質問をできるだけ少なくして、妥当なデフォルト設定でモデルをデプロイしたいと考えています。必要なことだけを尋ね、正直に適切な方法を提案し、専門スキルに引き継いでください。

ワークフローのフェーズ

1. 要件の確認 — デプロイ対象と制約事項を確認します（このスキル）
2. 方法の選択 — リアルタイム／サーバーレス／非同期／バッチ／Bedrock CMI（このスキル）
3. コンテキストの事前確認 — hf-cloud-aws-context-discovery、続いて hf-cloud-python-env-setup
4. IAM の事前確認 — hf-cloud-sagemaker-iam-preflight
5. イメージの選択 — hf-cloud-serving-image-selection
6. デプロイ — hf-cloud-sagemaker-production-defaults

フェーズ 1～2 はこのスキルが担当します。その他のフェーズは、該当するパターンに応じて開始されます。

要件の確認：必要なことだけを尋ねる

最終的には、次の情報が必要です。

• モデル：HuggingFace ID、アーティファクトの S3 パス、またはモデル名です。ユーザーの説明が曖昧（「ファインチューニングしたモデル」など）な場合は、アーティファクトの場所を尋ねてください。
• モデルの種類：テキスト生成 LLM、埋め込み／リランカー、その他（分類器、NER など）のいずれかです。これによってサービングスタックが決まります。通常はモデル名から推測できます（-embed-* で終わるもの、BAAI/bge- で始まるもの、sentence-transformers/* などは埋め込みモデルです。チャット／インストラクトモデルは LLM です）。本当に判別できない場合に限り、尋ねてください。
• トラフィックの形状：おおよそどのくらいの頻度で呼び出されるかを尋ねてください。
• レイテンシの許容範囲：インタラクティブ、ニアリアルタイム、非同期のいずれかです。
• コストへの配慮：ユーザーがその意向を示した場合、またはトラフィックパターンが曖昧な場合に限り、尋ねてください。

リージョンは hf-cloud-aws-context-discovery で確認します。ユーザーが自発的に伝えない限り、尋ねないでください。

これらすべてを最初にまとめて尋ねないでください。多くの場合、最低限必要なのは「どのモデルか」と「おおよそどのくらいの頻度で呼び出されるか」だけです。通常、モデル名が分かればモデルの種類も判断できます。それだけで、方法を 2 つの候補に絞り込めることがよくあります。ユーザーがすでに伝えた情報を再度尋ねないでください。

パスの選択

パス	適している場合	適していない場合
リアルタイムエンドポイント	トラフィックが安定しており、レイテンシーが1秒未満から数秒程度で、常時稼働が必要な場合	トラフィックの変動が非常に大きい場合や、極めて少ない場合（アイドル中も料金が発生します）
リアルタイム、ゼロスケール	トラフィックが少ない、またはスケジュールされている場合、開発／テスト用エンドポイント、また、アイドル状態からの最初のリクエストに約9分かかっても許容できるクライアントがある場合	インタラクティブなSLAがある場合：起動中のリクエストはすべて400で失敗します
サーバーレス推論	トラフィックが突発的／断続的で、コールドスタート（約10秒以上）を許容でき、モデルが比較的単純な場合	数Bパラメーターを超えるLLM（メモリ／コールドスタートの制限）、厳格なSLAがある場合
非同期推論	推論に時間がかかる（60秒超）、ペイロードが大きい、キューに対応できる場合	インタラクティブな同期呼び出し
バッチ変換	データセットに対するオフラインスコアリング	オンラインまたはインタラクティブな用途
Bedrock Custom Model Import	Bedrock互換APIを使用したい場合、対応するベースモデルファミリーを使用する場合、重みのみを扱う場合	カスタム推論ロジック、非対応アーキテクチャ

LLMでは、トラフィックが明らかに突発的／少量である場合や、推論に長時間かかる場合を除き、リアルタイムエンドポイントがデフォルトです。「低トラフィック」のケースではサーバーレスが魅力的に見えますが、ほとんどのLLMはメモリ制限を超えます。

埋め込みでも、デフォルトはリアルタイムです。ただし、通常はCPUインスタンスが適しています（はるかに低コストで、ほとんどの埋め込みワークロードには十分な速度です）。埋め込みモデルにGPUインスタンスを安易に推奨しないでください。モデルが小さく（1Bパラメーター未満）、トラフィックが中程度の場合は、CPUの選択肢も検討するようhf-cloud-serving-image-selectionに依頼してください。

テキストからの画像生成、動画生成、その他の長時間推論ワークロード（リクエストあたり30秒超）で、トラフィックも突発的な場合は、非同期推論が適しています。バッチ間で実際にゼロスケールでき、S3経由でリクエストをキューイングするため、GPUがアイドル状態の間は料金が発生しません。hf-cloud-sagemaker-production-defaultsには、この用途に特化したdeploy_async.pyがあります。

リアルタイム、リアルタイムのゼロスケール、非同期は、スクリプト化された3つのパスです（hf-cloud-sagemaker-production-defaults内のdeploy.py、deploy_ic.py、deploy_async.py）。サーバーレス、バッチ変換、Bedrock Custom Model Importは現時点ではスクリプト化されていません。これらについては、このワークフローでデプロイしようとせず、簡潔に説明してユーザーに引き継いでください。

ゼロスケールなら、リアルタイムと非同期のどちらを選ぶべきですか？ どちらもゼロまでスケールし、アイドル状態からの最初のリクエストが遅くなります。1回の推論がInvokeEndpointの制限時間である60秒を超える可能性がある場合、ペイロードが大きい場合、またはクライアントが同期レスポンスの代わりにS3の結果を受け取れる場合は、非同期を選択してください。通常の同期HTTPレスポンスが必要で、起動完了まで再試行できるクライアントには、リアルタイムのゼロスケールを選択してください。リアルタイムのゼロスケールには推論コンポーネントが必要です。通常のリアルタイムパスでは、インスタンス数を1未満にできません。

2つのパスがどちらも妥当な場合は、それぞれについて一文で説明し、どちらか一方を選んでください。選択肢の中に推奨事項を埋もれさせないでください。

インスタンスの選定：推奨する前にクォータを確認する

エンドポイントのクォータはインスタンスタイプおよびリージョンごとに設定されており、多くのアカウントでは GPU タイプのデフォルト値は 0 です。アカウントで起動できないインスタンスを推奨すると、ResourceLimitExceeded によってデプロイサイクルを丸ごと無駄にしてしまいます。まず確認してください：

aws service-quotas list-service-quotas --service-code sagemaker --region <region> \
    --query "Quotas[?contains(QuotaName, 'for endpoint usage') && Value > \`0\`].[QuotaName, Value]" \
    --output table

希望するタイプが結果にない場合は、結果に含まれるタイプを推奨するか、何かを作成する前に増枠を申請するようユーザーに伝えてください（数時間から数日かかります）。

呼び出し自体が拒否された場合は、その旨を一度だけ伝えて続行してください。クォータ確認は最適化のためのものであり、必須条件ではありません。デプロイ時に実際の制限が ResourceLimitExceeded として表示されます。事前確認のためにワークフローを止めたり、ユーザーに IAM の変更を求めたりしてはいけません。

一般的な 24 GB クラスの GPU ファミリーに関する注意点：

• ml.g5.*（A10G）と ml.g6.*（L4）は、gpu-3-1 AMI が設定されていれば、どちらも現在の vLLM イメージで動作します（hf-cloud-serving-image-selection を参照）。g6 は新しい世代で、1 時間あたりの料金がやや安く、g5 はメモリ帯域幅がおよそ 2 倍あるため、通常は LLM のトークン処理性能に優れています。クォータがある方を選んでください。両方にクォータがある場合は、どちらを選んでも問題ありません。処理性能なら g5、コストなら g6 です。
• モデルが 24 GB に収まらない場合は、ml.g6e.*（L40S、48 GB）を使用します。

推奨するのに十分な情報が揃ったら、はっきりと伝えてください：

お聞きした内容から、ml.g5.xlarge のリアルタイムエンドポイントをおすすめします。モデルが小さいためコスト効率がよく、トラフィックのパターンも安定しているので、アイドル状態の時間に料金を払わずに済みます。別の選択肢として、トラフィックが数時間にわたって途絶える場合はサーバーレスの方が安くなります。ただし、Qwen3-0.6B はサーバーレスのメモリ制限ぎりぎりで、コールドスタートには 15～30 秒かかります。リアルタイムエンドポイントで進めてもよろしいですか？

その後は確認を待ってください。何かを作成する前に、ユーザーが何に費用をかけることになるのかを把握できるようにしてください。

計画は会話の中で扱います。明示的に求められない限り、plan.yaml などの成果物を生成しないでください。

スタイル

• このスキルを使うユーザーは、AWS の設定を自分でしたくないため、エージェントに任せています。その意向に沿って、網羅的ではなく効率的に対応してください。
• 通常、確認の質問は 1 回で十分です。3 回では尋問になってしまいます。
• 現在のイメージ URI、SDK の API、クォータなど、具体的な情報がわからない場合は推測せずに確認してください。「確認方法」の詳細は他のスキルが扱います。
• 推奨内容にユーザーが異議を唱えた場合は、それを受け入れてください。ユーザーの方が自身の制約をよく理解しています。