LLMをサーバーレスGPUでデプロイ:5プラットフォーム、実際の料金、正直なコールドスタート
RunPodのA100 80GBは1時間あたり$2.72です。あなたのエンドポイントに昼までに来るリクエストは12件。残りの23時間、GPUはアイドルのまま課金だけが続きます。LLMをサーバーレスGPUでデプロイすれば、支払うのはリクエストが動いている間だけです。これを実現するプラットフォームは5つあります。課金単位は5通り。それを揃えて比較したものはどこにもありません。
アイドル状態のGPUは、フル稼働のGPUとまったく同じコストがかかります。
要点まとめ
- サーバーレスGPUはリクエスト処理中のみ課金され、リクエスト間はスケールトゥゼロになります。
- Cloud Runは1インスタンスあたり1GPU。70BモデルにはマルチGPUが必要なため、サーバーレスでは基本的にホストできません。
- モデルの重みは、イメージに同梱するか、ネットワークボリュームに置くか、コールドスタートのたびに再ダウンロードするかのいずれかです。
- コールドスタートは3つの要素で構成されます。コンテナの起動、重みの読み込み、エンジンの初期化。速いのは最初だけです。
- 1日あたり約47,000リクエスト未満なら、スケールトゥゼロが24時間365日のレンタルGPUより安くなります。
LLMにとって「サーバーレスGPU」とは実際何を意味するのか?
サーバーレスGPUプラットフォームは、共有GPUハードウェア上で推論コンテナを実行し、リクエストの到着時に起動、トラフィックが止まるとスケールトゥゼロします。課金は秒単位(ベンダーによっては分単位・時間単位)で、コンテナが稼働している間のみ。アイドル課金なし。リザーブドインスタンスもなし。
課金単位はベンダーごとに異なるため、次のセクションではすべてを$/GPU時間単位に正規化します。
制約が2つあり、多くの人が驚きます。1つ目、Google Cloud Runは1インスタンスあたり最大1GPUです。VRAMの上限はカード1枚分になります。2つ目、「サーバーレス」は永続的な状態を意味しません。リクエスト間で重みをRAMに保持し続けるプロセスは存在しません。コンテナが終了すれば、メモリ上のすべても消えます。この1つの事実が、後述のモデル重みセクションのストレージ判断を左右します。
サーバーレスはサーバーがないという意味ではありません。リクエストとリクエストの間にサーバーがないという意味です。そしてまさにその間に、モデルの重みは消えてなくなります。
どのサーバーレスGPUプラットフォームを選ぶべきか?(2026年料金比較)
私たちはこれらのプラットフォームを一切販売しておらず、アフィリエイト収益も受け取っていません。この検索クエリとその近辺で競合する7本の記事のうち、4本はサーバーレスGPUを販売する企業が公開しています。この表はそうではありません。
すべての料金は2026年7月30日時点で各ベンダー自身の料金ページから読み取ったものです。料金は変わります。契約前に再確認してください。
| プラットフォーム | 公開されている課金単位(ベンダーの表記) | $/GPU時間(A100 80GB) | $/GPU時間(H100) | 無料クレジット | こんな人向け |
|---|---|---|---|---|---|
| Modal | $0.000694/秒 | $2.50 | $3.95 | Starterは$30/月 | 秒単位課金、高速ビルド、GPUスナップショットが欲しい人 |
| RunPod | $2.72/時間 | $2.72 | $4.55 | 公開なし | 固定時間料金で最も幅広いGPUメニューが欲しい人 |
| Beam | $0.000625/秒 | $2.25 | $3.55 | $30/月 | スピンアップとイメージ読み込みの課金ゼロが欲しい人 |
| Baseten | $0.06667/分 | $4.00 | $6.50 | あり(金額は非公開) | アクティブ計算課金のマネージド推論が欲しい人 |
| Cloud Run | 秒単位(L4とRTX PRO 6000 Blackwell。A100/H100なし) | 非公開(A100なし) | 非公開(H100なし) | GCPクレジット$300 | 既にGCPを使っていてEU/USリージョン制御が必要な人 |
正規化の計算式を、検証できるよう一度だけ示します。ModalのA100 80GBは$0.000694/秒×3600秒=$2.4984/時間。Beam:$0.000625×3600=$2.25/時間。Baseten:$0.06667/分×60=$4.00/時間。同じA100でBeamとBasetenの間にある1.8倍の差は実在します。誰も同じ単位で公開していないため、この差は見えにくい場所に隠れています。
注意事項が3つあります。Beamの料金ページは、サーバースピンアップとコンテナイメージの読み込みには課金しないと明記しています。Basetenの料金FAQは「Basetenではアイドル時間にも課金されますか?」という質問に「いいえ、アイドル時間への課金はありません」と答え、その上で課金時間を「モデルがデプロイ中、スケールアップ/ダウン中、または推論を実行している時間」と定義しています。つまりメーターは推論時間以外もカバーしており、予算を組むべきはまさにその部分です。RunPodの料金ページは時間単位の料金を公開しており、コールドスタートの数値は掲載していません。
Modalを選ぶなら、Modalの完全なウォークスルーは別途まとめています。
そのモデル、本当に載る?VRAM・1GPU制限・クォータ
70BモデルをサーバーレスGPUで動かせますか? 多くの場合、無理です。FP16では70Bは約140 GBのVRAMを必要とします。Cloud Runは1インスタンス1GPUが上限(RTX PRO 6000で最大96 GB)です。量子化(FP8/GGUF)かマルチGPUプラットフォームなしでは、計算が合いません。
| GPU | VRAM | 最低CPU/メモリ | 一般的なモデル上限 |
|---|---|---|---|
| L4 | 24 GB | 4 CPU / 16 GiB | 7B〜13B(FP16)、量子化で最大30B |
| A100 80GB | 80 GB | プラットフォームにより異なる | 30B〜70B量子化 |
| H100 80GB | 80 GB | プラットフォームにより異なる | 30B〜70B量子化 |
| RTX PRO 6000 Blackwell | 96 GB | 20 CPU / 80 GiB | FP8で70B |
Cloud Runのデフォルトクォータは、リージョンごと・プロジェクトごとにL4 GPU 3枚です(RTX PRO 6000は3,000ミリGPUとして別途付与)。L4が使えるリージョンは6つ:asia-southeast1、asia-south1、europe-west1、europe-west4、us-central1、us-east4。これが、ヨーロッパでのサーバーレスGPUを検討している人に対するデータ居住性の答えのCloud Run側半分です。ModalとRunPodはそれぞれのEUリージョンをドキュメント化しており、残りはFAQにあります。
Ismaili Simba氏のdev.toでのCloud Runウォークスルー(2025年4月)は、クォータ申請について「承認まで時間がかかる場合がある(最大5営業日)」と報告し、さらに「Cloud Runで利用可能なL4 GPUには16GB RAMの制限がある」と述べています。この遅延を見込んで計画してください。
モデルごとのVRAMサイジングについては、VRAM要件ガイドを参照してください。
モデルの重みはどこに置く?(そしてコストは?)
2024年11月のRedditスレッドは、2026年7月30日の確認時点でこの検索クエリのGoogle 5位にまだ残っており、原文のままこう尋ねています。
「80GBのモデルを保存する料金が見つけられません…APIコールのたびにモデルをダウンロードしたくない場合の代替策は?(コール時にPodがプロビジョニングされ、その後閉じられます)…なぜこれらのプラットフォームはモデルストレージのコストを掲載しないのですか?」
低スコアの返信が3件。どれも答えになっていません。2026年7月30日にこの検索を実行したところ、上位10件にはまだ、モデルストレージのコストを尋ねるこの2年前のスレッドが含まれていました。スレッド内で答えた人はいません。料金は両プラットフォームとも公開しています。Modalは1 GiBあたり月$0.09で、最初の1 TiBは無料です。つまり80 GBのチェックポイントは$0.00です。RunPodは1 TB未満のネットワークストレージが1 GBあたり月$0.07で、同じチェックポイントは月約$5.60です。
| 配置場所 | コールドスタートへの影響 | コスト | モデル変更に再ビルドが必要? | 最適な用途 |
|---|---|---|---|---|
| コンテナイメージに同梱 | 起動が最速 | イメージサイズの肥大化(27B FP8=数十GB) | あり、フルリビルド | シングルモデルのエンドポイント |
| 永続ネットワークボリューム | 高速(ホストにキャッシュ) | Modal $0.09/GiB/月、1 TiB無料。RunPod 1 TB未満$0.07/GB/月 | なし、パスを差し替えるだけ | マルチモデルまたは頻繁な入れ替え |
| 起動時にHugging Faceから取得 | 最も遅い:5 GB/sで130 GBなら26秒以上 | 無料(HF帯域) | なし | プロトタイプのみ |
3行目が失敗パターンです。TU Münchenによる2024年のServerlessLLMレビュー(arXiv 2411.15664)は、LLaMA-2-70B(130 GB)が5 GB/sで26秒以上かけて取得され、さらに8 GPUへの読み込みに約84秒かかると報告しています。トークン生成は約100 msです。これらの数値はそのレビューで引用されたものであり、レビュー自体が測定したものではありません。
RunPodの料金ページにはStorageセクションがあります。コンテナディスク$0.10/GB/月、ボリュームディスクは稼働時$0.10/GB/月・アイドル時$0.20/GB/月、ネットワークストレージは1 TB未満$0.07/GB/月・超えると$0.05/GB/月、高性能ネットワークストレージ$0.14/GB/月。数値は存在します。ただ、読者がこの疑問を抱く瞬間に比較しているGPUごとのサーバーレス料金の隣にも、エンドポイント設定フローにも載っていないだけです。秘匿ではなく、見つけやすさの問題です。そしてそれは、2年後もこの質問を生かし続けるのに十分でした。
# Point the Hugging Face cache at a mounted network volume
# so weights persist across cold starts (RunPod / Modal pattern)
export HF_HOME=/workspace/hf-cache
export TRANSFORMERS_CACHE=/workspace/hf-cache
export HF_HUB_ENABLE_HF_TRANSFER=1# Alternative: bake weights into the image at build time
FROM vllm/vllm-openai:latest
COPY ./model-weights /models/qwen3-27b-fp8
ENV MODEL_NAME=/models/qwen3-27b-fp8
# Downside: 30+ GB image, full rebuild to change modelsまだモデルを選んでいないなら、2026年オープンウェイトモデルまとめで各選択肢のデプロイ時サイズを整理しています。
デプロイ実践:RunPod ServerlessでvLLMをエンドツーエンドで
ゼロから呼び出し可能なエンドポイントまで6ステップ。各ステップをRunPodのvLLM手順(2026年6月22日更新)と照合してください。同手順は料金を公開していません。
-
モデルを選ぶ。 GPUに合ったサイズのオープンウェイトモデルを選びます(上記のVRAM表を参照)。Hugging Faceでゲート付きの場合は、先にアクセストークンを発行してください。
-
サーバーレスエンドポイントを作成する。 RunPodコンソールでServerlessを選び、vLLMワーカーテンプレートを選択し、GPUティアを決めます。
-
重要な環境変数を設定する。
MODEL_NAME=Qwen/Qwen3.6-27B-FP8
MAX_MODEL_LEN=32768
GPU_MEMORY_UTILIZATION=0.90
DTYPE=autoMODEL_NAMEを間違えると起動時に404になります。MAX_MODEL_LENをVRAMに対して高すぎる値にすると、最初のトークンの前にOOMです。GPU_MEMORY_UTILIZATIONを0.95超にすると、KVキャッシュのスパイクに対する余裕がなくなります。
-
ワーカー数の最小/最大とアイドルタイムアウトを設定する。 最小ワーカー0でスケールトゥゼロ(そしてコールドスタート)になります。最小ワーカー1でコールドスタートは消えますが、常時課金です。このトレードオフは後述のコールドスタートセクションで詳しく扱います。
-
ネットワークボリュームをアタッチする。 モデル重みセクションで決めたボリュームをアタッチするか、イメージ同梱のパスを受け入れます。これを省略すると、コールドスタートのたびにチェックポイントを再ダウンロードします。
-
最初のリクエストを送る。 コンソールからエンドポイントIDを読み取り、トークンが返ってくることを確認します。
curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
-H "Authorization: Bearer ${RUNPOD_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"input": {
"messages": [{"role": "user", "content": "Explain cold starts in one sentence."}],
"max_tokens": 60
}
}'サービングエンジン自体を比較検討中なら、vLLMとSGLangをスループットとレイテンシで比較しています。
アプリからエンドポイントをどう呼ぶか?
候補に残ったプラットフォームはすべてOpenAI互換APIに対応しています。1つのPythonスニペットがどこでも動きます。プロバイダーの切り替えはbase_urlの変更であり、書き直しではありません。これにより「どのプロバイダーか」はロックインの決定から設定の決定へと変わります。
import os
from openai import OpenAI
ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]
client = OpenAI(
base_url=f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
api_key=os.environ["RUNPOD_API_KEY"],
)
response = client.chat.completions.create(
model="Qwen/Qwen3.6-27B-FP8",
messages=[{"role": "user", "content": "What is scale to zero?"}],
max_tokens=120,
)
print(response.choices[0].message.content)# Same code, different provider. One line changes.
ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]
PROVIDERS = {
"runpod": f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
"modal": "https://your-app--your-func.modal.run/v1",
"beam": "https://your-beam-endpoint/v1",
}
client = OpenAI(base_url=PROVIDERS["modal"], api_key="your-key")すべてのプロバイダーがOpenAIの方言を話すなら、「どのサーバーレスGPUプロバイダーか」はアーキテクチャの決定ではなくなり、設定1行になります。
エンドポイントが複数になったら、LLMゲートウェイ比較がルーティングとフェイルオーバーをカバーします。より軽量な構成なら、LiteLLMプロキシでリトライとロギングを追加できます。
コールドスタートは実際どのくらいかかる?
サーバーレスGPU上の7Bモデルでは、真のコールドスタート(コンテナ起動+重み読み込み+エンジン初期化)で10〜30秒を見込んでください。実務者の報告に基づく数値です。ベンダードキュメントはコンテナ起動だけで1〜5秒を掲げています。この差は、チェックポイントがネットワークを渡る時間です。
RunPodのプロダクトページは200 ms未満のFlashBootコールドスタートを掲げています(ベンダーの主張であり、測定値ではありません)。r/LLMDevsの実務者はこう報告しています。「私の経験ではコールドスタートは良くない…だいたい10〜30秒だと思う」。さらに「ただし、私の経験の大半はディフュージョンモデルに関するものだ」とも。どちらも正しい。測っているものが違うのです。
コールドスタートの数値は、3つの数値が積み重なったものです。
-
コンテナ起動。 Modalのドキュメント:「コンテナは約1秒で起動します」。Cloud Run:ドライバインストール済みインスタンスは「約5秒で起動」します。
-
重み読み込み。 誰も宣伝しない部分です。TU Münchenによる2024年のServerlessLLMレビュー(arXiv 2411.15664)は、LLaMA-2-70Bが取得に26秒以上、8 GPUへの読み込みに約84秒かかるとしています。
-
エンジン初期化。 vLLMのグラフキャプチャとウォームアップ。Logesh Umapathi氏の測定では、A100-80GB上のQwen3.6-27B-FP8が、ベースライン460秒からeagerモードで219秒、vLLMスリープモードとModal GPUスナップショット併用で約70秒まで短縮されました。6.5倍の改善で、2026年5月17日に公開されています。
| ソース | 測定対象 | 数値 | 日付 | 種類 |
|---|---|---|---|---|
| Modalドキュメント | コンテナ起動 | 約1秒 | 現在 | ベンダードキュメント |
| Cloud Runドキュメント | インスタンス起動(ドライバインストール済み) | 約5秒 | 現在 | ベンダードキュメント |
| Umapathi氏 | Qwen3.6-27B-FP8、A100-80GB、フルコールドスタート | 460秒→219秒→約70秒 | 2026年5月 | 独立した測定 |
| TU MünchenによるServerlessLLMレビュー(arXiv 2411.15664) | LLaMA-2-70Bの取得+読み込み、数値は引用であり測定ではない | 取得26秒+読み込み84秒 | 2024年 | arXivプレプリント(レビュー) |
| r/LLMDevsの実務者 | RunPod上の7B、フルリクエスト | 約10〜30秒 | 2024年12月 | 体験談(ディフュージョンモデルの留保あり) |
公開データに対する私たちの解釈:ベンダーの数値はコンテナの時間を測っています。実務者の数値はリクエスト全体の時間を測っています。この2つのストップウォッチの間に、ネットワークを渡る80 GBの重みが横たわっています。種類の列が要点です。
やるべきこと:vLLMスリープモード、GPUスナップショット、そしてスケールダウンウィンドウの調整。Modalのデフォルトアイドルは60秒(2秒〜20分で設定可能)。ウォームワーカーはコールドスタートをなくしますが、常時稼働として課金されます。
# Modal scaledown config (illustrative)
# A 60s window means you pay for 60 idle seconds per burst.
# A warm worker (min_containers=1) costs ~$2.50/hr on A100 80GB, 24/7.
@app.function(
gpu="A100",
scaledown_window=60, # seconds idle before shutdown
# min_containers=1, # uncomment to kill cold starts; costs $60/day
)サーバーレスGPUは常時稼働GPUより安いのか?
サーバーレスGPUが安くなるのは、GPUが1日の大半アイドルのときです。A100 80GBで1日3,000リクエスト・平均2秒の場合、サーバーレスは1日約$4.17、24時間365日稼働のレンタルGPUは1日$65.28です。クロスオーバーはデューティサイクルの問題であり、リクエスト数の問題ではありません。
前提条件(再計算できるよう明示します):A100 80GBはModalの$2.50/時間、リクエストあたり平均GPU時間2秒、レンタルGPUはRunPodの$2.72/時間で24時間稼働、ホスティング型トークンAPIは100万トークンあたり$0.40(公開されている中間的な料金)、リクエストあたり約1,000トークン。
| 1日リクエスト数 | サーバーレス(推定) | レンタル24時間365日GPU | ホスティング型トークンAPI | 最安 |
|---|---|---|---|---|
| 500 | $0.69 | $65.28 | $0.20 | トークンAPI |
| 3,000 | $4.17 | $65.28 | $1.20 | トークンAPI |
| 10,000 | $13.89 | $65.28 | $4.00 | トークンAPI |
| 50,000 | $69.44 | $65.28 | $20.00 | トークンAPI |
| 200,000 | $277.78 | $65.28 | $80.00 | レンタルGPU |
クロスオーバーは1日約47,000リクエストです。それ以下ならサーバーレスが勝ちます。ホスティング型トークンAPIは、コモディティモデルを使うなら低トラフィック帯で両方を下回ります。損益分岐点は、リクエストがどれだけ来るかではありません。GPUが何もせずに過ごす時間がどれだけあるかです。
BentoMLの2024年8月の分析はこのトレードオフをうまく整理しています。ただし料金の例はGPT-3.5-turbo時代のもので、2年古いです。
あなたのトラフィック量でホスティング型トークンAPIがいくらかかるかは、LLM API料金比較を参照してください。推論側でリクエスト単価を削るなら、プロンプトキャッシングが繰り返しのコンテキストで通常30〜60%を節約します。
# Break-even calculator: adjust these and re-run
REQUESTS_PER_DAY = 3000
SECONDS_PER_REQUEST = 2
SERVERLESS_RATE_HR = 2.50 # Modal A100 80GB
RENTED_RATE_HR = 2.72 # RunPod A100 80GB, 24/7
serverless_daily = REQUESTS_PER_DAY * SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR
rented_daily = RENTED_RATE_HR * 24
print(f"Serverless: ${serverless_daily:.2f}/day")
print(f"Rented 24/7: ${rented_daily:.2f}/day")
print(f"Crossover: {int(RENTED_RATE_HR * 24 / (SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR))} req/day")サーバーレスGPUが間違った選択になるケース
- 継続的な高トラフィック。 この料金体系では1日約47,000リクエストを超えるとデューティサイクルが逆転し、レンタルGPUの方がリクエスト単価は安くなります。
- コールドパスでの1秒未満のSLO。 最初のリクエストを瞬時にするスナップショット技はありません。ウォームワーカーを維持するか、ボックスをレンタルしてください。
- マルチGPUが必要な70B超モデル。 Cloud Runの1インスタンス1GPUでその話は終わります。
- 厳格なデータ居住性。 Cloud Runで選べるのはL4の6リージョンがすべてです。
- 支払い済みのGPU空き枠に負ける単価。 GPUに余裕があるなら、推論を追加しても追加コストはゼロです。
GPUが1日16時間忙しいなら、サーバーレスは高い方の選択肢です。そうでないと主張する人は、サーバーレスを売っている人です。
ローカルファーストの道には、ローカルLLMツールガイドがあります。
著者について
Mert BaturはTechsy.ioの共同創業者です。Techsy.ioでは、B2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを提供しています。Techsyチームが本番環境で実際に使っているLLMツールスタックについて書いています。LinkedInでつながってください。
よくある質問
サーバーレスGPUとは?
サーバーレスGPUプラットフォームは、共有ハードウェア上でモデルコンテナを実行し、リクエスト間でスケールトゥゼロし、アクティブな計算にのみ課金します。永続的なGPUインスタンスを管理せずに、推論エンドポイントが手に入ります。トレードオフは、スピンアップ時のコールドスタート遅延です。
サーバーレスGPUでLLMを動かすコストは?
A100 80GBはBeamで$2.25/時間、Modalで$2.50/時間、RunPodで$2.72/時間です(2026年7月30日確認)。請求額はデューティサイクルで決まります。1日3,000リクエスト・各2秒ならModalで1日約$4です。ストレージは$0.09/GiB/月が加算され、1 TiBは無料です。
モデルの重みの保存にも課金される?
はい。ただし安価です。Modalは$0.09/GiB/月で1 TiB/月が無料のため、80 GBのチェックポイントは無料です。RunPodの料金ページは1 TB未満のネットワークストレージを$0.07/GB/月と掲載しており、同じ80 GBで月約$5.60です。
リクエストのたびにモデルを再ダウンロードする?
何もキャッシュされていない場合のみです。永続ボリューム上の重みや、イメージに同梱した重みはコールドスタートを生き延びます。Hugging Faceキャッシュを一時的なストレージに向けると、130 GBのモデルはスピンアップのたびに再ダウンロードされます。これが避けるべき失敗パターンです。
7Bモデルのコールドスタートはどのくらい?
実務者の報告(r/LLMDevs、2024年12月)では、真のコールドスタートで10〜30秒を見込んでください。コンテナは1〜5秒で起動します(Modal、Cloud Runのドキュメント)。残りは重み読み込みとエンジン初期化です。スナップショットとスリープモードを使えば、Umapathi氏は27Bモデルで460秒から約70秒まで短縮したと測定しています。
70BモデルをサーバーレスGPUで動かせる?
多くの場合、無理です。FP16の70Bモデルは約140 GBのVRAMを必要とします。Cloud Runは1インスタンス1GPU(最大96 GB)です。80 GBカード1枚に載せるにはFP8量子化が必要で、それがなければマルチGPUプラットフォームが必要です。サーバーレスのほとんどのサーフェスは1GPUが上限です。
サーバーレスGPUは24時間365日のGPUレンタルより安い?
1日約47,000リクエスト未満(A100 80GBで2秒/リクエスト)なら、安くなります。サーバーレスはアクティブな秒数のみ課金。レンタルGPUは関係なく24時間課金です。それを超えるとレンタルGPUが勝ちます。ホスティング型トークンAPIは低トラフィック帯で両方を下回ります。上記の損益分岐表を参照してください。
サーバーレスGPUでLLMを無料でデプロイできる?
Modalは月$30の無料クレジット(Starter)を提供しています。Beamは月$30。GCPの$300新規アカウントクレジットはCloud Run GPUの利用をカバーします。プロトタイプには十分ですが、本番トラフィックには足りません。GPU推論に永続的な無料枠を提供するプラットフォームはありません。
ヨーロッパで使えるサーバーレスGPUプロバイダーは?
Cloud Runはeurope-west1(ベルギー)とeurope-west4(オランダ)でL4 GPUを提供しています。ModalはEUリージョン選択をドキュメント化しており(eu-west、eu-north、eu-south)、基本料金の1.5〜1.75倍です。RunPodはEU-NL-1やEU-FR-1を含むヨーロッパのデータセンターを明示しています。リージョンは明示的に固定してください。いずれもデフォルトはEUではありません。
サーバーレスGPUでのLLMデプロイにDockerは必要?
常に必要とは限りません。RunPodはDockerを省略できるビルド済みvLLMワーカーテンプレートを提供しています。Modalはコード内のPythonイメージ定義からコンテナをビルドします。カスタム依存関係にはDockerfileを書きます。標準のvLLMサービングなら、ビルド済みパスが数分で動きます。
結論
5つのプラットフォーム、5つの課金単位、1つの正規化された表。判断は、ベンダーページが思わせるよりシンプルです。
- GPUはブランドではなくVRAMで選ぶ。
- 重みはイメージではなくボリュームに置く。モデルを一切入れ替えない場合を除く。
- コールドスタートは10〜30秒を見込み、それを前提に設計する。
- 1日約47,000リクエスト未満なら、スケールトゥゼロがコストで勝つ。
- エンドポイントの背後のサービングエンジンは交換可能。
base_urlは1行です。
呼び出し可能なエンドポイントが手に入りました。次は?ルーティングとフェイルオーバーが必要になったとき、その手前に何を置くか。LLMゲートウェイ比較がそれに答えます。あるいは、あなたの構成についてご相談ください。