Unsloth を用いた Amazon SageMaker AI 上の量子化モデルのデプロイ

この投稿は、Unsloth の Daniel Han 氏と Michael Han 氏との共著です。

16 ビット浮動小数点精度（BF16 または FP16）で保存された大規模基盤モデル（FMs）をそのままデプロイすると、コストが高騰します。これには大規模な GPU インスタンスが必要となり、サービングコストが上昇し、イテレーションサイクルも遅くなります。量子化（Quantization）はこの課題を解決する手法です。これはモデルの重みの数値精度を下げることで（例えば 16 ビットから 4 ビットへ）、メモリ使用量を劇的に削減します。ただし、量子化にはモデルの精度が低下するという欠点があります。そこで注目されるのが動的量子化（Dynamic Quantization）です。適切に実施されれば、動的量子化はメモリ使用量を削減しつつ、精度を維持することが可能です。インスタンスタイプのコスト削減、ストレージ節約、起動時間の短縮といった効果は、スケールするほど複利のように蓄積していきます。

本稿では、Unsloth で既に量子化されたモデルを AWS インフラ上でデプロイするための 4 つのパターンをご紹介します。これらのパターンでは、インスタンスへの直接アクセスには Amazon Elastic Compute Cloud（Amazon EC2）を、管理型のサービングには Amazon SageMaker AI の推論エンドポイントを利用します。また、既存のコンテナフレームワークに推論機能を組み込む必要がある場合は、Amazon Elastic Kubernetes Service（Amazon EKS）または Amazon Elastic Container Service（Amazon ECS）を活用します。さらに、本稿では本番環境での運用に関するベストプラクティスも解説します。

Unsloth の動的量子化とは何か？

Unsloth の共同創業者である Daniel Han 氏は、次のように説明しています。

「強力なモデルの最大の課題は、そのサイズが巨大で実行には 1.5TB の容量が必要になることです。いくつかの工夫を施すことで、このモデルを 217GB にまで圧縮できます。サイズが 86% 縮小されたからといって精度も同様に 86% 低下すると思うかもしれませんが、実際は精度の低下はわずか 14% です。この手法を「ダイナミック量子化」と呼びます。すべての重みを 4 ビットに量子化するのではなく、一部の層は高い精度の 8 ビットのまま維持するなど、モデルのディスク容量を削減できることを多くのベンチマークで示しています。」

実務的な観点から、量子化とは各重みを格納するビット数を減らす技術です。標準的な BF16 モデルではパラメータあたり 16 ビットを使用しますが、4 ビットに量子化するとサイズは 75% 削減されます（ただし、量子化のメタデータが含まれるため、実際のファイルサイズはわずかに大きくなります）。80 億パラメータモデルの場合、必要なメモリ使用量は約 16GB から約 5GB に減少します。これは、マルチ GPU インスタンスが必要になるか、単一の GPU で快適に動作するかを分ける決定的な差となります。

Unsloth は、ファウンデーションモデルの微調整と量子化を行うツールです。Unsloth Dynamic は一様な圧縮を超えた量子化手法で、すべての層に同じビット削減を適用するのではなく、以下の 3 つの手順で動作します。

• 層ごとの分析 – Unsloth は、各層が精度低下に対してどの程度敏感かを測定します。

動的ビット割り当て – 精度低下が出力の質に大きな影響を与える重要な層は、16 ビットなど高い精度で保持し、感度の低い層は積極的に量子化（4 ビット以下）します。

精度チューニング – ディスク使用量を最小限に抑えつつ、結合された出力品質が元のモデルと可能な限り近くなるよう、量子化の調整を行います。

このプロセスの最終目標は、量子化モデルと標準モデルの精度差を極小化しつつ、モデルサイズを実用的な範囲まで圧縮することです。オープンソースの Unsloth パッケージを使えば、微調整、実行、エクスポート、デプロイまでの一連の流れを単一のワークフローで完結させることができます。

AWS でモデルをデプロイする際、量子化（quantization）は非常に重要です。なぜなら、量子化を行うことで同時に 3 つの重要な要素が変化するからです。

第一に、インスタンスタイプの選定です。本来であれば大規模な GPU を必要とするような大型モデルでも、量子化によってより小さなインスタンス、あるいは CPU 上でも実用的に運用できるようになります。

第二に、起動時とストレージのプロファイルです。モデルファイルが小さくなることで、環境間での移動や保存、そして展開（プロモーション）が高速化されます。

第三に、デプロイの柔軟性です。コストを重視する推論には小規模なモデルファイルを、品質を重視する推論には高忠実度のエクスポートを、あるいはスループットを最大化する GPU サービングには統合された表現を選ぶなど、用途に応じて最適な形式を選べます。

この柔軟性が、AWS 環境において Unsloth を有用にする理由です。Unsloth を使えば、すべてのデプロイを同じランタイムやハードウェアの前提条件に強制するのではなく、サービングパスに合わせてモデルを適応させることが可能になります。

どのモデル形式を使うべきか

Unsloth のデプロイワークフローにおける重要な原則は、「出力アーティファクトがサービング設計を主導すべき」という点です。インフラの選定はその次です。まず、アーティファクトとランタイムを選択し、その後、運用モデルに合致する AWS サービス上にそのランタイムを配置します。

Unsloth は、デプロイ指向の出力タイプとして複数の形式をサポートしています：

• GGUF ファイル – GGUF は、モデルの重み、トークナイザー、メタデータを単一ファイルにパッケージ化する形式で、追加ファイルなしで自己完結し、すぐに読み込み可能です。llama.cpp、Ollama、Unsloth などの軽量ランタイム向けに適しています。AWS では、Amazon EC2 または Amazon SageMaker AI のカスタムコンテナに対応します。

• マージされた safetensors 重み – Unsloth を用いて作成可能な (16 ビット、8 ビット、FP8 4-bit、NVFP4) は、vLLM や SGLang などの高スループットエンジン向けです。AWS では、Amazon SageMaker AI Large Model Inference (LMI) コンテナ、Amazon EKS、または Amazon ECS に該当します。

実践的なデプロイマップ

以下の表では、各アーティファクトタイプに最適なランタイムと AWS のターゲットを対応付けています。これにより、要件に合致するデプロイパターンを素早く特定できます。

本記事で解説する各デプロイパターンは、いずれも以下の共通ワークフローに従います。

• Unsloth でモデルのファインチューニングを行うか、またはモデルをダウンロードします。
• 対象とするランタイムに適合したモデルファイルをエクスポートします。
• ローカル環境または Amazon EC2 上でランタイムを検証します。
• 同じモデルファイルとランタイムの組み合わせを、マネージド型またはネイティブなデプロイ環境へプロモートします。

この順序で進めることで、後々の予期せぬ動作（特にメモリ使用量、プロンプトフォーマット、レイテンシ挙動など）を防ぐことができます。

パターン 1: Amazon EC2 上で llama.cpp と Unsloth を用いた GGUF のデプロイ

このパターンは、インスタンスへの直接アクセスを通じて量子化レベルを迅速に検証したい場合に有効です。多くのユースケースにおいて、Amazon EC2 は最小限の抽象化で最大限の制御権を得られるため、強力な出発点となります。マネージドエンドポイントの設計に着手する前に、複数の量子化レベルでのベンチマーク実施、プロンプトフォーマットのテスト、CPU と GPU の挙動比較、そして実際のメモリフットプリントの確認を行うことが推奨されます。

典型的な Unsloth エクスポートは以下のようになります。

model.save_pretrained_gguf("gguf_model", tokenizer, quantization_method="q4_k_xl")

これにより、ローカル環境で llama.cpp ベースの推論が可能な GGUF ファイルが生成されます。関連するリポジトリでは、量子化されたエンドポイントに q4_k_xl を採用しています。異なる量子化手法は、ファイルサイズと出力忠実度のトレードオフを制御します。より高い出力忠実度が必要であれば q8_0 を使用し（ただしファイルサイズは約 2 倍になります）、あるいは量子化による劣化を完全に避けるためには f16 でフル精度の GGUF ファイルを作成してください。完全な量子化手法の一覧とその特性については、Unsloth の GGUF ドキュメント をご参照ください。

GGUF ファイルが準備できたら、最小限の llama-server の起動には以下の設定が必要です。

llama-server \
  --model /models/my-model.gguf \
  --alias my-model \
  --ctx-size 8192 \
  --host 0.0.0.0 \
  --port 8080

unsloth run \
  --model /models/my-model.gguf \
  --alias my-model \
  --ctx-size 8192 \
  --host 0.0.0.0 \
  --port 8080

これで、アプリケーションは OpenAI 互換インターフェースを通じてモデルと通信できるようになります。

from openai import OpenAI

client = OpenAI(
    base_url="http://:8080/v1",
    api_key="not-required",
)
response = client.chat.completions.create(
    model="my-model",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain AWS Graviton in two sentences."},
    ],
    max_tokens=128,
)
print(response.choices[0].message.content)

重要: この構成は孤立したテスト環境向けです。本番環境では、セキュリティグループを既知のクラスレス・ドメイン間ルーティング（CIDR）ブロックに制限し、プライベートインターフェース（例：127.0.0.1）にバインドしてください。また、エンドポイントは認証済み API ゲートウェイまたはロードバランサーの背後に配置する必要があります。

このアプローチが魅力的な理由は 3 つあります。デバッグが容易で、アップストリームのランタイム動作に近い挙動を示すためです。さらに、コンテナ契約や自動スケーリングポリシー、エンドポイントガバナンスを導入する前に、量子化の選択肢をクリーンな環境でテストできる場所を提供します。

Amazon EC2 は、実用的なデプロイメントに関する疑問を検証するための最も直接的な場所でもあります。

• 量子化の品質 – 特定の評価基準に対して、異なる量子化レベル（例：q4_k_m と q8_0）間の出力を比較してください。品質への影響はモデルアーキテクチャやタスクによって異なります。

• ハードウェア要件 – モデルのメモリ使用量が利用可能な CPU RAM を超える場合、GPU ベースのインスタンスが必要です。モデルの読み込み時だけでなく、推論中のピークメモリ使用量も確認してください。最適なパフォーマンスを得るには、モデル全体をメモリにロードできる十分な RAM または VRAM を用意してください。例えば、ディスク上のモデルサイズが 128 GB の場合、利用可能な RAM または VRAM は 128 GB より大きくする必要があります。

コンテキスト長のトレードオフ – コンテキストウィンドウを長くすると、レイテンシとメモリ消費量の両方が増加します。ワークロードに最適なバランスを見つけるために、代表的なプロンプト長でテストしてください。

チャットテンプレートの検証 – 「システム」や「ユーザー」といった役割をモデルが期待するトークンシーケンスにマッピングする構造化されたプロンプト形式が、トレーニング環境外でも一貫した動作を生み出すか確認してください。

評価、内部ツール、概念実証（PoC）、および初期の生産パイロットにおいては、Amazon EC2 が適切な出発点となることが多いです。

パターン 2: カスタムコンテナを使用した Amazon SageMaker AI 上の GGUF

迅速な反復には Amazon EC2 を推奨しますが、EC2 では管理された推論サービスが最初から用意されているわけではありません。オートスケーリング、モニタリング、AWS Identity and Access Management (IAM) の統合、そして安定した API サフェースを備えた本番用のエンドポイントが必要であれば、Amazon SageMaker AI 推論エンドポイントの方が適しています。

GGUF デプロイメントにおいて最も実用的な設計は、通常、GGUF モデルファイルと llama.cpp または他の軽量ランタイムをパッケージ化したカスタム推論コンテナです。このコンテナは Amazon SageMaker AI のホスティングインターフェースを公開します。これには、コンテナがポート 8080 でリスニングし、ヘルスチェックのために /ping を実装し、推論リクエストのために /invocations を実装することが求められます。

このパターンの完全な動作例は、コンパニオン GitHub リポジトリ に含まれています。ここでは、Unsloth による動的量子化モデル「Qwen3-VL-8B-Instruct (Q4_K_XL GGUF)」を llama.cpp で ml.g5.xlarge インスタンス上で動作させ（時間あたり約 1.41 ドル）、フル精度の BF16 バリアントを vLLM で ml.g5.12xlarge インスタンス上で動作させる（時間あたり約 7.09 ドル）という、両者の並列比較デプロイを行っています。料金は 2026 年 6 月時点のものですが、最新情報は Amazon SageMaker AI の価格ページ をご確認ください。

エントリーポイントスクリプトは、内部ポートで llama-server を起動し、nginx をリバースプロキシとして用いて Amazon SageMaker AI のインターフェース要件を満たします：

# Start llama-server with the GGUF model and vision projector
/app/llama-server \
  --model /models/Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf \
  --mmproj /models/mmproj-F16.gguf \
  --host 0.0.0.0 \
  --port 8081 \
  --ctx-size 4096

nginx はその後、/ping を llama-server のヘルスチェックに、/invocations をチャット完了エンドポイントにマッピングします。これにより、Amazon SageMaker AI には標準的なインターフェースを提供しつつ、ランタイムは軽量なまま維持されます：

# SageMaker health check endpoint
location /ping {
    proxy_pass http://llama_backend/health;
}

# SageMaker inference endpoint -> llama.cpp chat completions
location /invocations {
    proxy_pass http://llama_backend/v1/chat/completions;
    proxy_read_timeout 120s;
}

一般的なアーキテクチャは以下のようになります。

• 完成した GGUF モデルファイルを Amazon Simple Storage Service (Amazon S3) に保存する。
• Amazon SageMaker AI コンテナを起動し、モデルを /opt/ml/model 配下に配置する。
• llama.cpp または Unsloth を使用して、ローカルのモデルファイルに対して推論を開始する。
• Amazon SageMaker AI のリクエストをローカル推論呼び出しに変換する、軽量な API レイヤーを公開する。

同じく GitHub リポジトリにあるアーキテクチャ図は、サンプルがどのようにして量子化された GGUF エンドポイント（本稿の手法）とフル精度の vLLM エンドポイント（パターン 3）を同時にデプロイするかを示しています。フローは以下の通りです。

• Terraform が Amazon Elastic Container Registry (Amazon ECR)、AWS CodeBuild、Amazon S3 リソースを含むすべてのインフラストラクチャを構築します。
• AWS CodeBuild がカスタムコンテナイメージをビルドし、それを Amazon ECR へプッシュします。
• Amazon SageMaker AI は仮想プライベートクラウド（VPC）内で 2 つのリアルタイムエンドポイントを作成します。1 つは量子化された GGUF モデル用（パターン 2）、もう 1 つはフル精度モデル用です。
• 両方のエンドポイントは起動時に、それぞれのモデルファイルを Amazon S3 から取得します。
• Amazon SageMaker Notebook Instance を用意し、比較用のノートブックにアクセスできるようにして、両方のエンドポイントに対する評価を実行できます。

このパターンは、ランタイムを軽量に保ちつつ、エンドポイントのライフサイクルや自動スケーリングなど、本番環境で重要な運用課題を Amazon SageMaker AI が処理できるため、非常に効果的です。小規模なモデルでは、CPU ベースのエンドポイント上で特に有効です。一方、大規模な量子化モデルや低遅延が求められる場合は、同じ設計を GPU ベースのエンドポイントへ移行することも可能です。

ただし注意点として、llama.cpp は推論・デプロイエンジンとしては優れていますが、完全なサービングシステムではありません。Amazon SageMaker AI 上では、依然として Amazon SageMaker AI エンドポイントとして動作するコンテナが必要です。このラッパー層の実装に大きな工数はかかりませんが、本番設計においては重要な要素です。

パターン 3: GPU 最適化サービングエンジンを用いた Amazon SageMaker AI 上の統合重み

モデルファイルサイズや軽量なサービングを最優先する場合は GGUF が非常に有効です。しかし、スループットや GPU の効率性を重視する場合には、必ずしも最適な選択肢とは限りません。そのようなシナリオでは、統合された重み（merged weights）の方が魅力的になります。

Merged weights（マージ済み重み）とは、safetensors 形式の単一の統合セットとして保存されたモデルを指します。これは通常、微調整済みのアダプター（Low-Rank Adaptation (LoRA) など）とベースモデルを結合した結果ですが、デプロイ準備が整った形式で直接保存されたベースモデルにも適用されます。Unsloth では、マージ済み 16 ビット出力、マージ済み 4 ビット出力、および LoRA のみのエクスポートに対応する保存パスをサポートしています。これらは、バッチ処理、高トークンスループット、マルチ GPU スケーリングといった生産環境向けの GPU サービングパターンを基盤とした vLLM や SGLang などのランタイムと親和性が高い形式です。

代表的なエクスポート例は以下の通りです：

model.save_pretrained_merged(
    "finetuned_model",
    tokenizer,
    save_method="merged_16bit",
)

サービングパス（実行経路）は次のようになります：

vllm serve finetuned_model

AWS 環境では、Amazon SageMaker AI で利用可能な LMI コンテナが特に重要です。コンパニオンサンプル のフル精度エンドポイントでは、Amazon SageMaker AI 用の LMI コンテナは Terraform モデルリソース上の環境変数を通じて完全に設定されます：

HF_MODEL_ID = "Qwen/Qwen3-VL-8B-Instruct"
OPTION_DTYPE = "bf16"
OPTION_ROLLING_BATCH = "vllm"
OPTION_TENSOR_PARALLEL_DEGREE = "4"
OPTION_MAX_MODEL_LEN = "4096"

カスタムコンテナの作成は不要です。LMI コンテナは