【AWS】Gemma 4をセルフホスティングしてみた〜クラッシュを回避するインスタンス選定とメモリのリアル〜

はじめに

オープンソースLLM（オープンウェイトモデル）の進化が止まりませんね。最近発表されたGoogleの 「Gemma 4」 は、Apache 2.0ライセンスで商用利用もしやすく、マルチモーダル対応やMoE（Mixture-of-Experts）アーキテクチャの採用など、自分で動かしてみたい魅力が詰まっています。

ただ、いざAWS上でセルフホスティングしようと検討し始めると、 「どのインスタンスを選べばいいのか分からない」「小さいインスタンスだとすぐクラッシュする」「かといって大きなインスタンスはコストが高すぎる」 といった壁にぶつかるかと思います（まさに私がそうでした…！）。

この記事では、私自身がAWS（東京リージョン）でGemma 4のセルフホスティングを検討・試行錯誤する中で見えてきた、 メモリ容量の落とし穴や、コスパを壊さずに安定稼働させる現実的なインスタンス選定のポイント を、自戒も込めてまとめてみました。少しでも参考になれば幸いです！

1. なぜ今、Gemma 4のセルフホスティングに注目するのか？

Gemma 4は従来のモデルから大きく進化し、特に以下の3点がセルフホスティングの動機として非常に強いと感じています。

• 完全なオープンソース（Apache 2.0）: 従来のGemmaライセンスから変更され、ビジネスや社内ツールに組み込みやすくなりました。
• 全モデルがマルチモーダル対応: テキストだけでなく、画像や音声（小型モデルでネイティブ対応）を直接処理できます。
• 選べるサイズバリエーション: 軽量なエッジ向け（E4B）から、賢さと速度を両立したMoE（26B A4B）、最高精度のDense（31B）まで、用途に合わせた選択が可能です。

2. 東京リージョンで候補となる主要GPUインスタンス

まずは、AWS東京リージョン（ap-northeast-1）で利用できる主なコンピューティングリソースを整理してみます。「AIといえばGPU」ですが、実はファミリーごとに得意分野が全く異なります。

ファミリー	搭載GPU / チップ	VRAM (1基)	特徴と推論ホスティングへの適性
G6 (g6.xlarge等)	NVIDIA L4	24GB	現在の標準的な推論選択肢。 FP8ネイティブ対応でコスパが良い。
G5 (g5.xlarge等)	NVIDIA A10G	24GB	前世代だが、実はメモリ帯域がG6の2倍広い。（後述する重要な逆転現象あり）
G6e (g6e.xlarge等)	NVIDIA L40S	48GB	中〜大型モデル単一GPUの本命。 24GBでは溢れるモデルを載せたい場合に。
Inf2 (inf2.xlarge等)	AWS Inferentia2	32GB〜	AWS独自アクセラレータ。Neuron SDKの変換が必要だがコスパ最強クラス。

💡 P系・VT系・Trn系は推論に向いている？
AWSには他にも様々なインスタンスがありますが、推論用途としては以下のような理由から候補から外すのが無難そうです。

• P系 (P4de/P5等): H100やA100搭載のAI学習向け最高峰。月額数百万円規模になるため、31B以下の推論には完全なスペックオーバー（コスパ最悪）です。
• Trn系 (Trn1/Trn2): AWS自社製チップ「Trainium」。モデルの「学習（Training）」特化のため、推論なら兄弟チップの「Inf系（Inferentia2）」を選ぶのが合理的です。
• VT系: 動画のエンコード・トランスコード専用。AI推論用のCUDA/Tensorコアを持たないため利用できません。

3. Gemma 4 各モデルの特性と必要メモリの目安

各モデルを動かすために必要な「重みサイズ（VRAM）」の目安です。ここで注意したいのが、 「MoEモデルの罠」 です。

モデル名	パラメータ構造	非量子化(BF16)	INT8 / FP8量子化	INT4量子化 (GGUF等)
E4B	約40億 (軽量万能)	約 8 GB	約 4 GB	約 2.5 GB
12B	約120億 (Encoder-free)	約 24 GB	約 13 GB	約 7 GB
26B A4B	約260億 (MoE / アクティブ4B)	約 52 GB	約 28 GB	約 15 GB
31B	約310億 (最大Dense)	約 62 GB	約 33 GB	約 18 GB

⚠️ MoE (26B A4B) の「4B」に騙されない！
26B A4Bは、1トークン生成時に計算で使うパラメータが「4B（40億）」なので爆速ですが、モデル全体の重み（260億分）はすべてメモリに常駐させる必要があります。「4Bだから軽い GPU で動く」と誤解して小さなインスタンスを選ぶと起動すらできないので注意が必要です。

4. なぜ「xlarge」だと26Bや31Bがクラッシュするのか？

コミュニティや自らの検証でもよく耳にするのが「26Bや31Bを xlarge サイズで立ち上げるとクラッシュする」という現象です。これにはGPUのVRAM不足だけではない、 「2つの技術的な理由」 が隠れていました。

原因①：CPUシステムRAM不足による「ロード時」のクラッシュ（OOM Killer）

LLMをvLLMやHugging Face等で起動する際、モデルファイルをディスクから一度CPU側のシステムRAMに展開し、そこからGPUのVRAMへ転送するのが一般的です。

実はAWSの xlarge は、システムRAMが意外と少なく設定されています。

• g6e.xlarge (48GB VRAM) ⇒ システムRAM：32 GiB
• g6.xlarge (24GB VRAM) ⇒ システムRAM：16 GiB

26Bや31Bは、INT8量子化でもファイルサイズが 28GB〜33GB 程度あります。これを 32 GiB しかRAMがない g6e.xlarge で読み込もうとすると、OSや環境の消費分と合わさって即座にメモリが溢れ、LinuxのOOM Killerによってプロセスが強制終了されてしまいます。

原因②：KVキャッシュ不足による「推論中」のクラッシュ（CUDA OOM）

仮にロードを乗り越えても、推論中のVRAM余白に注意が必要です。例えば、48GB VRAMに 31B (FP8: 約33GB) を載せると、残りのVRAMは 15GB ほどです。
ここには推論の履歴を保持する「KVキャッシュ」が作られますが、長文を入力したり複数人からアクセスが重なると、この15GBの余白を一瞬で食いつぶし、「CUDA Out of Memory」でサーバーが落ちる原因になります。

5. コスパを壊さずに安定させる現実的な3つのアプローチ

「じゃあマルチGPUや超大型インスタンスにすればいいのでは？」と考えてしまいますが、それだと待機中も数十万円の月額コストが垂れ流しになり、APIを使った方がマシ…という本末転倒な状態になります。

そこで、単一GPUの低コストな環境を維持しつつ、クラッシュを完全に回避するためのアプローチを3つ整理しました。

アプローチ①：「xlarge」ではなく「2xlarge」を選ぶ（スイートスポットを狙う）

実は、AWSのインスタンスサイズ（数字）の仕組みを知ると、賢いコスト最適化ができます。

• g6.xlarge ＝ L4 GPU (1基) / vCPU 4 / RAM 16GB ＝ クラッシュ危険大
• g6.2xlarge ＝ L4 GPU (1基) / vCPU 8 / RAM 32GB ＝ コスパと安定のスイートスポット！

「サイズを xlarge から 2xlarge に上げても、高価なGPUの枚数は1基のまま変わらない」 というのが最大のポイントです。増えるのはCPUとRAMだけなので、料金の上がり幅を最小限に抑えつつ、ロード時のOOMクラッシュを確実に防ぐことができます。

※ 12xlarge などになるとGPUが4基・8基と増殖してコストが数倍に跳ね上がるため、よほどの理由がない限りは「単一GPUゾーン（8xlargeまで）」でRAMが足りる最小サイズを選ぶのが良さそうです。

アプローチ②：4-bit量子化（INT4 / GGUF Q4_K_M）の徹底活用

品質の劣化が非常に少ない4-bit量子化を活用すると、26Bや31Bのメモリ消費を 15〜18GB まで抑えられます。
これにより、なんと24GB VRAMの安価な g6.2xlarge 1台で、26B A4B や 31B が安定稼働します！推論用のVRAM余白も6〜8GB以上確保できるため、KVキャッシュによるクラッシュも防げます。

アプローチ③：メモリマッピング（mmap）対応エンジンの採用

llama.cpp や Unsloth で利用できる GGUF形式 を採用するのも強力です。OSの mmap 機能により、SSDから直接VRAMへデータを流し込めるため、CPU側のシステムRAMをほとんど消費せずにモデルをロードできます。

モデル	おすすめコスパ構成	運用ポイント
E4B / 12B	g6.xlarge (L4 24GB / RAM 16GB)	12BはINT4/INT8量子化が前提。安価で快適に動作する鉄板構成。
26B A4B	g6.2xlarge (L4 24GB / RAM 32GB)	INT4量子化＋GGUF等を使用。 MoEの爆速推論を低コストで安全に回せる。
31B	g6.2xlarge (L4 24GB / RAM 32GB)	INT4量子化＋コンテキスト長制限（8k程度）。 単一GPUで最大の知能を引き出す。

6. 実務でハマる「G5 vs G6」メモリ帯域幅の逆転現象

最後に、インフラ検討で私が最も面白いと感じた「メモリ帯域幅」の話を共有します。
最新の G6 (L4) が推奨されがちですが、実は状況によって古い G5 (A10G) の方が推論スピードが圧倒的に速くなるケースがあります。

比較項目	G5 (A10G)	G6 (L4)	特徴・影響
メモリバス幅 / 帯域幅	384-bit / 600 GB/s	192-bit / 300 GB/s	なんとG5の方がちょうど2倍速い！
演算性能 (FP16)	約 35 TFLOPS	約 121 TFLOPS	計算自体はG6の方が約3.5倍速い
FP8 ネイティブ対応	× 非対応	〇 対応 (ADA世代)	最新のFP8運用ならG6が有利

LLM推論の8割は「メモリ帯域幅バウンド」

チャットボットのように「1文字ずつテキストを生成する（デコードフェーズ）」とき、GPUは1文字生成するたびにモデルの重みファイル全量をVRAMから計算コアへ読み直します。
つまり、計算コアの速さ（FLOPS）は余っており、「VRAMからデータをどれだけ速く運べるか（メモリ帯域幅）」だけでテキスト生成速度（Tokens/秒）が決まるのです。

そのため、INT4やINT8/FP16のモデルを使って少人数でリアルタイムチャットをする用途なら、メモリ帯域幅が600 GB/sある G5の方が、最新のG6よりも1.5〜2倍近くテキスト生成が速い という逆転現象が起きます。

🎯 まとめ：G5 と G6 はどう使い分ける？

• G5 (g5.2xlarge) がおすすめ: INT4/INT8量子化を採用し、社内チャットボットなどで「1人1人のテキスト生成の体感スピード（Tokens/秒）」を何より最優先したい場合。
• G6 (g6.2xlarge) がおすすめ: 最新の「FP8量子化」で省メモリ運用したい場合、インスタンス料金を少しでも安くしたい場合、または長文要約やマルチモーダル入力など「最初の1文字目が出るまでの速度（計算力）」を重視する場合。

おわりに

LLMのセルフホスティングは、ただ大きなサーバーを借りれば良いというわけではなく、 「モデルサイズ・量子化・システムRAM・VRAM帯域幅」 のバランスをパズルの様に組み合わせる必要があります。

断言できる絶対の正解はありませんが、「まずは自分の用途で許容できる最小の量子化（4-bit等）を試し、それをちょうど収められる単一GPUの中で、RAMに余裕があるインスタンス（2xlarge等）を選ぶ」というのが、スペックオーバーの無駄を省く一番近道だと感じています。

これからのGemma 4やローカルLLM環境の構築の際に、本記事が皆さんの検証の手助けやコスト削減のヒントになれば嬉しいです！

参考資料・公式ドキュメント

• Google AI - Gemma モデルの概要（公式ドキュメント）
  Gemmaモデルファミリーの特徴や技術仕様、公式の推奨ハードウェアガイドが確認できます。

• Hugging Face - Google 公式ページ（オープンウェイト配布元）
  各モデルの重みファイルダウンロード、具体的なコンテキスト長やモデルカードの確認はこちらから。

• AWS 公式 - Amazon EC2 G6 インスタンス（L4 GPU）
  FP8対応で現在の推論コスパの標準となる G6 シリーズのvCPU/RAM比率やネットワーク帯域幅の詳細。

• AWS 公式 - Amazon EC2 G6e インスタンス（L40S GPU）
  単一GPUで48GB VRAMを備える大容量モデル用本命インスタンスの公式スペックシート。

• AWS 公式 - Amazon EC2 G5 インスタンス（A10G GPU）
  メモリ帯域幅600 GB/sを誇り、テキスト生成スピードに強みを持つG5シリーズの公式ページ。

• vLLM 公式ドキュメント
  セルフホスティングの業界標準推論サーバー。PagedAttentionや量子化モデルの起動パラメータなどの参考に。

• llama.cpp（GitHub 公式リポジトリ）
  GGUF形式モデルの推論やmmapによるシステムRAM節約を実現するためのツール・ライブラリ。