目安: 50分。演習の状態: 未実行 (not-run)。本文は学習ガイドであり、動作や品質の実測記録ではありません。
前提となる章: 小さなLLMをローカルで動かす
独自の概念図。矢印は依存関係や判断の順序を示し、性能の実測を表さない。
- 1課題とデータの地域
- 2実行形態
- 3計算・残る保存領域・転送の費用
- 4予算
- 5保存と停止
学習目標
- ローカル、VM、notebook、serverless、managed endpointを使い分ける
- tokens課金とGPU時間課金を換算の前提付きで比べる
仕事の役割
- 学習者: 仮説・データ・評価を設計する
- モデル: 指定した変換を試す
- アプリ: 制限・検証・権限を保証する
入力 → 工程 → 出力
| 入力 | 工程 | 出力 |
|---|---|---|
| モデル、VRAM要件、稼働時間、地域、データの制約 | 提供形態と総費用の項目を比較 | 用途別候補と予算上限・停止手順 |
CPU RAMとGPU VRAMの違い
一般的な専用GPU環境ではCPUのRAMとGPUのVRAMは別に存在する。128GB RAMのVMでもGPUが16GB VRAMなら、GPUに置くtensorはその制約を受ける。CPU offloadは選択肢だが転送と計算の待ちが増える。GPUが複数ある場合も、ソフトウェアで分割しなければVRAMが一枚の大きなメモリとして使えるわけではない。
CUDA対応例は通常NVIDIA環境を前提とする。AMD、Apple、CPUにも実行経路はあるが、演算、量子化、学習ライブラリの対応を個別に確認する。GPU名だけでなくVRAM、台数、接続、ドライバ、containerの組み合わせを記録する。
作業に合った基盤の形を選ぶ
notebookは短い検証に向くが、接続時間や資源割り当てが一定とは限らない。GPU VMは長い学習や自由な環境構築に向き、停止・保存・監視を自分で管理する。serverlessは断続的なジョブに合わせやすいが、起動待ちやモデル読み込みを評価する。managed endpointは推論運用の管理負担を減らす候補で、学習用VMとは用途が違う。
下の一覧は導入候補を整理したもので、最安ランキングではない。場所、在庫、クォータ、契約、データ保管地域、サポート、必要なGPUで比較する。患者情報や機密をアップロードして試すことはこの教材の演習に含めない。
請求単位を揃える
APIは入力tokenと出力tokenに異なる単価を持つことがある。GPUでは、処理していない待機時間や起動・ダウンロード時間も課金対象になり得る。概算は GPU単価×課金時間×台数＋CPU/RAM＋永続ディスク＋転送＋その他の料金。停止してもディスクなどが残れば費用は続く。
仮に架空の単価が1 GPU時あたり1通貨単位で3時間・1枚ならcompute部分は3になるが、これは実在サービスの価格ではない。ローカルも購入費、電力、保守、開発時間のコストがある。品質を満たした応答1件あたりの費用で比較すると、速さだけで選ぶ失敗を減らせる。
以下は基盤の形と費用項目の比較で、性能や価格の順位ではない。Colab FAQ は可変の資源制限を説明し、Runpod Podsの料金文書 は停止した計算と保持する保存領域を区別する。見積もりでは対象製品の契約条件を確認する。
実行基盤カタログ
| 基盤 | 形態 | 向く用途 | 確認する条件 | 一次資料 |
|---|---|---|---|---|
| Apple Silicon + MLX/llama.cpp | local | 個人検証、データを端末に留めたい試作 | 共有メモリ、同時数、対応演算、電力と端末占有 | Apple MLX ドキュメント / llama.cpp 公式リポジトリ |
| Google Colab | notebook | 環境構築を小さく始める学習実験 | GPUの種類・利用上限・実行時間が保証されるとは限らない。終了時の保存を設計 | Google Colab FAQ |
| Runpod Pods | gpu-vm/container | GPUを選んだ実験や追加学習 | 停止後のstorage費用、volumeの種類、消失条件。確認時点のPods文書はingress/egress料金なしと記載。対象製品と最新条件を再確認 | Runpod Pods 料金の仕組み |
| Lambda Cloud | gpu-instance | GPU instanceでの学習・検証 | GPU/地域の在庫、永続データの扱い、instance終了前の持ち出し | Lambda On-demand Cloud |
| Modal | serverless-compute | Pythonベースの断続的GPUジョブやサービス | cold start、同時数、実行時間、volumeとnetwork egressの料金を個別確認 | Modal GPU acceleration |
| Hugging Face Inference Endpoints | managed-inference | Hubモデルの管理された推論提供 | 選べるhardware、scale設定、待機時費用、認証、専用学習環境との違い | Hugging Face Inference Endpoints |
| Amazon EC2 GPU instances | cloud-vm | 既存AWS環境との統合、管理されたネットワーク設計 | instance、EBS、転送、quota、region、Spot中断と保存 | Amazon EC2 accelerated instances |
| Google Cloud GPU VM | cloud-vm | GCP基盤との統合、必要なGPU構成の確保 | GPU割り当て条件、zone/region、quota、disk、転送、Spot中断 | Google Cloud GPU machine types |
自分で進める工程
- 小さなサンプルで必要資源を決める
- 候補ごとのGPU在庫と地域を確認する
- 実行・停止・削除時の費用を読む
- 予算アラートと終了条件を設計する
- 保存と復旧の手順を決めてから借りる
品質を確認する
- ローカル、VM、notebook、serverless、managed endpointを使い分ける
- tokens課金とGPU時間課金を換算の前提付きで比べる
- idle、storage、egressが空欄になっていないか
失敗を切り分ける
| 注意すること | 具体的な確認方法 |
|---|---|
| 価格は本教材に固定掲載しない。契約時の公式画面で再確認する | 現行の課金単位、地域、ストレージや転送の追加費用を確認する。 |
| 停止・終了・削除は同じ意味ではない | 各状態で何の資源が残り、どの課金が続くかを確認する。 |
演習: GPU基盤とコストを選ぶ
状態: 未実行 (not-run)。
1時間の検証、夜間学習、断続的な推論APIの三つに適した形態を選ぶ
提出するもの: 採用理由、除外理由、費用項目の比較
完了の確認: idle、storage、egressが空欄になっていないか
実験記録用ワークシートに計画・条件・観察を記録する。未測定値は null とし、推定値は式と仮定を残します。
MENTAL MODEL / メモリ
モデルの重さを、分けて考える。
重みとKVキャッシュは別々に増える。下の値は設計用の概算です。
GBは10⁹ byte。KVは32層・8 KV heads・128 head dim・FP16・batch 1の仮定。量子化メタデータ、実行バッファ、OS、モデル固有の構造は別途必要。MoEでは総重みとactive parametersを分けます。
出典
公開日は資料の日付、確認日は内容を参照した日です。コミュニティの観測は公式の確定事項と区別します。
01