在 Serverless GPU 上部署 LLM:5 大平台、真實價格、冷啟動老實說

在 Serverless GPU 上部署 LLM:5 大平台、真實價格、冷啟動老實說

RunPod 的 A100 80GB 每小時收費 $2.72。你的端點在午餐前只收到 12 個請求。其餘 23 小時那張 GPU 都在閒置,帳單卻一秒沒停。把 LLM 部署到 serverless GPU,你只在請求執行時付費。有 5 個平台做得到,卻用 5 種不同單位計費,沒人把它們換算成同一把尺。

閒置的 GPU 跟滿載的 GPU 一樣貴。

重點整理

• Serverless GPU 只在請求執行時計費,請求之間自動縮至零。
• Cloud Run 每個執行個體只能掛 1 張 GPU;70B 模型需要多 GPU,所以 serverless 通常跑不動。
• 模型權重要嘛打包進映像檔、放在網路磁碟區,要嘛每次冷啟動重新下載。
• 冷啟動由三件事組成:容器啟動、權重載入、引擎初始化。只有第一件快。
• 每天低於約 47,000 個請求時,縮至零比租一張 24/7 GPU 划算。

「Serverless GPU」對 LLM 來說到底是什麼意思?

Serverless GPU 平台在共享 GPU 硬體上執行你的推論容器,請求進來時把它啟動,流量停了就縮至零。你按秒(或按分、按小時,看廠商)付費,只算容器活著的時間。沒有閒置帳單,也沒有預留執行個體。

計費單位因廠商而異,所以下一節我們把一切換算成 $/GPU 小時。

有兩個限制常讓人意外。第一,Google Cloud Run 每個執行個體最多只能掛 1 張 GPU,VRAM 天花板就是一張卡。第二,「serverless」不等於持久狀態。沒有長壽命的處理程序在請求之間幫你把權重留在 RAM 裡。容器一死,記憶體裡的一切跟著死。單單這一件事,就決定了下面模型權重一節的儲存選擇。

Serverless 不是沒有伺服器,而是你的請求之間沒有伺服器。你的模型權重正好就消失在那段空檔裡。

該選哪個 serverless GPU 平台?(2026 價格並排比較)

我們不賣這些平台中的任何一個,也沒有從任何一家拿到聯盟分潤。在這個查詢及其近似變體下競爭的 7 篇文章中,有 4 篇出自銷售 serverless GPU 的公司。這張表不是。

所有費率均於 2026-07-30 從各廠商自己的定價頁面讀取。價格會變,下手前請重新確認。

換算過程在這裡列一次,方便你查核:Modal A100 80GB 每秒 $0.000694 乘以 3600 秒等於每小時 $2.4984。Beam:$0.000625 乘 3600 等於每小時 $2.25。Baseten:每分 $0.06667 乘 60 等於每小時 $4.00。Beam 與 Baseten 同樣一張 A100 價差 1.8 倍,這是真的,而且它就藏在大家眼皮底下,因為沒有兩家用同一個單位。

三個注意事項。Beam 的定價頁面明確寫著不對伺服器啟動與容器映像檔載入計費。Baseten 的定價 FAQ 對「在 Baseten 我需要為閒置時間付費嗎?」的回答是「不,閒置時間不計費」,接著補充計費時間是「你的模型實際部署、擴縮或產生預測的時間」,所以計費器涵蓋的不只預測時間,編預算時要把這部分算進去。RunPod 的定價頁面只公布每小時費率,沒有任何冷啟動數字。

如果你選 Modal,我們另外寫了一篇完整的 Modal 實作教學。

你的模型塞得進去嗎?VRAM、單 GPU 上限與配額

Serverless GPU 跑得動 70B 模型嗎?通常不行。FP16 下 70B 需要約 140 GB VRAM。Cloud Run 每個執行個體上限 1 張 GPU(RTX PRO 6000 最大 96 GB)。不做量化(FP8/GGUF)或不換多 GPU 平台,這筆帳算不攏。

Cloud Run 的預設配額是每個區域、每個專案 3 張 L4 GPU(RTX PRO 6000 另行核配,以 3,000 milliGPU 計),橫跨 6 個 L4 區域:asia-southeast1、asia-south1、europe-west1、europe-west4、us-central1、us-east4。這就是 Cloud Run 那一半的資料駐留答案,給所有在問歐洲 serverless GPU 的人;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-07-30 查的時候它還排在 Google 這個查詢的第 5 名,原文是這樣問的:

「我一直找不到儲存 80 GB 模型的費率……如果我不想每次 API 呼叫都重新下載模型(pod 在呼叫時建立、結束後關閉),有什麼替代方案?……為什麼這些平台都不列出模型儲存成本?」

三則低分回覆,沒有一則回答了問題。我們 2026-07-30 跑這個搜尋時,前十名裡仍然包括那則兩年前問模型儲存要多少錢的討論串。串上沒有人回答。兩家平台都有公布費率。Modal 是每 GiB 每月 $0.09,前 1 TiB 免費,所以那個 80 GB 檢查點帳單是 $0.00。RunPod 的網路儲存 1 TB 以下每 GB 每月 $0.07,同一個檢查點大約每月 $5.60。

第三列就是失敗模式。一篇 2024 年慕尼黑工業大學對 ServerlessLLM 的評述(arXiv 2411.15664)指出,LLaMA-2-70B(130 GB)在 5 GB/s 下需要 26 秒以上才能拉完,再花約 84 秒載入到 8 張 GPU 上,而 token 生成只要約 100 毫秒。這些數字是該評述引用的,不是它實測的。

RunPod 的定價頁面有一個 Storage 區塊:容器磁碟每 GB 每月 $0.10,磁碟區磁碟執行中每 GB 每月 $0.10、閒置 $0.20,網路儲存 1 TB 以下每 GB 每月 $0.07、超過 $0.05,高效能網路儲存每 GB 每月 $0.14。數字是存在的,只是它沒有擺在讀者比較 serverless 每 GPU 費率、心裡浮現這個問題的位置,也不在端點設定流程裡。這是能見度問題,不是隱瞞問題,但足以讓這個問題兩年後還活著。

# 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 開放權重模型評比有每個選項部署時所需的規格估算。

動手部署:vLLM 上 RunPod Serverless,從零到端點

從零到一個可呼叫的端點,共六個步驟。每一步都請對照 RunPod 的 vLLM 程序(2026 年 6 月 22 日更新)確認,該文未公布價格。

1. 選定模型。 挑選與你的 GPU 規格匹配的開放權重模型(見上方 VRAM 表)。如果它在 Hugging Face 上有存取限制,先產生一組存取權杖。

2. 建立 serverless 端點。 在 RunPod 控制台選擇 Serverless,挑選 vLLM worker 範本,選定 GPU 等級。

3. 設定關鍵環境變數。

MODEL_NAME=Qwen/Qwen3.6-27B-FP8
MAX_MODEL_LEN=32768
GPU_MEMORY_UTILIZATION=0.90
DTYPE=auto

MODEL_NAME 填錯,啟動就 404。MAX_MODEL_LEN 設得比 VRAM 能負荷的還高,第一個 token 還沒出來就 OOM。GPU_MEMORY_UTILIZATION 超過 0.95,KV 快取峰值就沒有餘裕。

1. 設定最小/最大 worker 數與閒置逾時。 最小 worker 數設 0 就是縮至零(也意味著冷啟動)。設 1 可以消滅冷啟動,但持續計費。下面的冷啟動一節會把這個取捨算清楚。

2. 掛上你在模型權重一節決定的網路磁碟區,或接受打包進映像檔的路線。跳過這一步,每次冷啟動都會重新下載檢查點。

3. 發出第一個請求。 從控制台讀取端點 ID,確認有 token 回傳。

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。一段 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 的方言,「選哪家 serverless GPU 供應商」就不再是架構決策,而是一行設定。

端點多了以後,我們的 LLM 閘道器評比涵蓋路由與故障轉移。想要輕量一點,LiteLLM proxy 可以加上重試與日誌。

實際會遇到多長的冷啟動?

以 serverless GPU 上的 7B 模型來說,根據實務工作者的回報,真正的冷啟動(容器啟動加權重載入加引擎初始化)預期是 10 到 30 秒。廠商文件寫的是容器啟動本身只要 1 到 5 秒。這兩個數字之間的差距,就是你的檢查點在過網路。

RunPod 的產品頁面宣稱 FlashBoot 冷啟動低於 200 毫秒(廠商說法,非實測)。r/LLMDevs 上一位實務工作者回報:「以我的經驗,冷啟動不太理想……我大概會說 10 到 30 秒」,並補充*「不過我的經驗大多圍繞擴散模型。」* 兩者都為真,只是量的是不同的東西。

冷啟動數字其實是三個數字疊出來的:

1. 容器啟動。 Modal 文件:「容器大約一秒啟動。」 Cloud Run:預先安裝驅動程式的執行個體*「大約 5 秒啟動」*。

2. 權重載入。 沒有人宣傳的部分。一篇 2024 年慕尼黑工業大學對 ServerlessLLM 的評述(arXiv 2411.15664)指出,LLaMA-2-70B 拉取要 26 秒以上,再花約 84 秒載入到 8 張 GPU。

3. 引擎初始化。 vLLM 的 graph capture 與暖機。Logesh Umapathi 實測 A100-80GB 上的 Qwen3.6-27B-FP8,從基準 460 秒,用 eager 模式降到 219 秒,再用 vLLM sleep 模式加 Modal GPU 快照降到約 70 秒。6.5 倍差距,發表於 2026 年 5 月 17 日。

我們對這些公開數據的解讀是:廠商數字量的是容器,實務工作者量的是整個請求。兩只碼表之間,隔著 80 GB 權重過網路。類型那一欄就是重點。

可以做的事:vLLM sleep 模式、GPU 快照,以及調整縮減窗口。Modal 的預設閒置是 60 秒(可設 2 秒到 20 分)。常駐 worker 可以消滅冷啟動,但就像全時運轉一樣計費。

# 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
)

Serverless GPU 比 24/7 GPU 便宜嗎?

GPU 一天大部分時間閒置時,serverless GPU 比較便宜。以 A100 80GB 上每天 3,000 個請求、平均每個 2 秒計算,serverless 一天約 $4.17,而租一張 24/7 運轉的 GPU 一天 $65.28。交叉點是使用率問題,不是流量問題。

假設(我們自己的假設,寫出來方便你重算):A100 80GB 用 Modal 的每小時 $2.50,每個請求平均 GPU 時間 2 秒,租 GPU 用 RunPod 的每小時 $2.72 全天候運轉,託管 token API 每 100 萬 token $0.40(中等價位的公開費率),每個請求約 1,000 token。

交叉點落在每天約 47,000 個請求。低於這個,serverless 贏。低流量時,用通用模型的託管 token API 比兩者都便宜。損益兩平的重點不在你收到多少請求,而在你的 GPU 有多少時間什麼都沒做。

BentoML 2024 年 8 月的分析把這個取捨講得很清楚,不過它的定價範例是 GPT-3.5-turbo 時代的,已經過時兩年。

你的流量下託管 token API 要多少錢,請看我們的 LLM API 定價比較。要在推論端降低單次請求成本,prompt 快取通常能在重複上下文上省下 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")

什麼時候 serverless GPU 是錯誤選擇

• 持續高流量。 以這些費率,每天超过约 47,000 個請求時,使用率反轉,租 GPU 的單次請求成本更低。
• 冷路徑上硬性要求亞秒級 SLO。 沒有任何快照技巧能讓第一個請求瞬間完成。留一個常駐 worker,或直接租機器。
• 需要多張 GPU 的 70B+ 模型。 Cloud Run 每個執行個體一張 GPU,這條路就到這裡。
• 嚴格的資料駐留要求。 Cloud Run 的菜單就只有 6 個 L4 區域。
• 單次請求的經濟帳輸給你已經在付錢的 worker 配置。 如果你有空閒的 GPU 餘裕,加上推論不需要額外成本。

如果你的 GPU 一天忙 16 個小時,serverless 就是比較貴的選項,跟你說相反的,都是在賣 serverless。

本機優先的路線,請看我們的本機 LLM 工具指南。

關於作者

Mert Batur 是 Techsy.io 的共同創辦人,團隊為 B2B 客戶打造 AI 代理人、自動化系統與語音/SDR 流程。他寫的文章談的都是 Techsy 團隊在正式環境實際使用的 LLM 工具鏈。歡迎在 LinkedIn 交流。

常見問題

什麼是 serverless GPU?

Serverless GPU 平台在共享硬體上執行你的模型容器,請求之間縮至零,只對實際運算計費。你拿到一個推論端點,不用管理持久 GPU 執行個體。代價是啟動時的冷啟動延遲。

在 serverless GPU 上跑 LLM 要多少錢?

A100 80GB 在 Beam 上每小時 $2.25,Modal $2.50,RunPod $2.72(2026-07-30 驗證)。帳單取決於使用率:每天 3,000 個請求、每個 2 秒,在 Modal 上一天約 $4。儲存另計每 GiB 每月 $0.09,1 TiB 免費。

模型權重的儲存要付費嗎?

要,但很便宜。Modal 每 GiB 每月 $0.09,每月 1 TiB 免費,所以 80 GB 檢查點不用錢。RunPod 定價頁面列出 1 TB 以下網路儲存每 GB 每月 $0.07,同樣 80 GB 大約每月 $5.60。

我的模型每次請求都會重新下載嗎?

只有在完全沒快取的情況下才會。放在持久磁碟區或打包進映像檔的權重,能撐過冷啟動。把 Hugging Face 快取指向臨時儲存,130 GB 模型就會每次啟動都重下。這就是要避免的失敗模式。

7B 模型的冷啟動多長?

根據實務工作者回報(r/LLMDevs,2024 年 12 月),真正的冷啟動預期 10-30 秒。容器啟動 1-5 秒(Modal、Cloud Run 文件)。剩下的時間是權重載入與引擎初始化。搭配快照與 sleep 模式,Umapathi 測得 27B 模型約 70 秒,從 460 秒降下來。

可以在 serverless GPU 上跑 70B 模型嗎?

通常不行。FP16 的 70B 模型需要約 140 GB VRAM。Cloud Run 每個執行個體允許一張 GPU(最大 96 GB)。想塞進單張 80 GB 卡,需要 FP8 量化,不然就要多 GPU 平台。多數 serverless 介面上限就是一張 GPU。

Serverless GPU 比 24/7 租 GPU 便宜嗎?

每天低於約 47,000 個請求(A100 80GB 上每個 2 秒)時,便宜。Serverless 只算實際運算的秒數;租 GPU 無論如何都算 24 小時。超過這個量,租 GPU 贏。低流量時,託管 token API 比兩者都便宜。見上方的損益兩平表。

可以免費在 serverless GPU 上部署 LLM 嗎?

Modal 每月給 $30 免費額度(Starter)。Beam 每月 $30。GCP 的 $300 新帳戶額度可用於 Cloud Run GPU。夠做原型,不夠跑正式環境流量。沒有平台提供 GPU 推論的永久免費方案。

歐洲有哪些 serverless 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。

在 serverless GPU 上部署 LLM 需要 Docker 嗎?

不一定。RunPod 提供預建的 vLLM worker 範本,可以跳過 Docker。Modal 從程式碼中的 Python 映像定義建置容器。自訂相依性需要寫 Dockerfile。標準 vLLM 推論用預建路線,幾分鐘就能上線。

結論

5 個平台,5 種計費單位,一張換算統一的表。這個決策比廠商頁面看起來簡單:

• 依 VRAM 選 GPU,不要依品牌。
• 權重放磁碟區,不要放映像檔,除非你永遠不換模型。
• 預期 10-30 秒冷啟動,並據此規劃。
• 每天低於約 47,000 個請求時,縮至零在成本上獲勝。
• 端點背後的推論引擎可以換;base_url 就是一行。

你已經有一個可呼叫的端點了。下一步:需要路由與故障轉移時,它前面要放什麼?我們的 LLM 閘道器評比有答案。或者和我們聊聊你的架構。