行程要活在哪一層抽象上：誰開機、誰打補丁、誰把下一份副本拉起來。

負載平衡決定一個請求落進哪一個行程。這篇問的是那個行程本身怎麼存在。VM、容器編排、Serverless 容器、FaaS 不是四個互不相關的產品名，而是同一條光譜上的四個刻度：愈往右，你交出的責任愈多，計費單位也從「機器開著的鐘點」收成「這次呼叫真正佔用的時間」。

由左往右讀：你交出的是開機、打補丁與擴縮，不是把業務邏輯交出去。四格都還是在跑你的程式。

GCP 的 Cloud Run 用計費開關就能站在兩個刻度上：request-based 只在處理請求時算 CPU，instance-based 則在實例活著的整段時間算 CPU。AWS 要換刻度，通常是換服務。

擴縮的時間尺度也沿著這條光譜變短。FaaS 的新並發是秒級，但頂在帳號配額上。Fargate 要先拉映像，計費還有 1 分鐘的最低額。EC2 自動擴縮群組要經過開機與行程暖機，是分鐘級。那個有延遲的回授迴圈——指標、冷卻、暖機缺口——是自動擴縮那篇的主題。這裡只把時間尺度當成選型限制：撐不住一分鐘冷啟動的路徑，就不要把「縮到零」當成免費的選項。

先問這一層跑不跑得了。跑不了的月費是 0 不是便宜，是沒有這一格。

第 4 節的決策器先做這三道淘汰，再比較錢。三道都對著 FaaS，其中 GPU 同時淘汰 Fargate。編排與 VM 在這三道裡都還有格位，因為加速器與長時間行程最終都是放在機器上。

單次執行時間

Lambda Event Functions 的單次執行上限是 15 分鐘。第 4 節裡的長作業設成 20 分鐘、3,008 MB：記憶體還在 128 MB–10,240 MB 的範圍內，長度已經出局。Durable Functions 讓等待可以暫停、等待期間的 on-demand 執行不再累 duration，一段連續運算仍要切在單次上限裡面。怎麼切、cold start 與並發配額怎麼算，是 Serverless FaaS 深入那篇的範圍。

長連線

Event Functions 按 wall-clock 收 GB·s。連線若握在同一次呼叫裡，等候的每一秒都在計費，而且 30 分鐘的連線直接超過 15 分鐘。Web Functions 是另一個計價點：請求、程式真正佔用的 vCPU、以及執行環境活著期間的記憶體。定價頁上的串流例子是一條連線開 3 秒、其中 200 ms 在用 CPU，同一個環境可以同時服務多條，所以等候不再按 wall-clock 的 CPU 計價。幾萬條幾乎閒置的連線仍然需要一個一直活著的環境來握著 socket。那個環境是 VM 或編排節點上的行程，不是「一條連線換一次 Event Function 呼叫」。

GPU

Lambda 的 Event Functions、Web Functions、MicroVMs，公開計價的維度是請求、vCPU、記憶體與快照，沒有 GPU。Fargate 的文件寫明 GPU 與 Inferentia 目前都不可用。推論要加速器，就回到掛得上 GPU 的機器：EC2、ECS on EC2、EKS 節點，或 ECS Managed Instances。這篇的模型用 g5.xlarge（1×A10G、4 vCPU、16 GiB），us-east-1 on-demand 每小時 $1.006，開滿一個月 $734.38。

這一句不能推到整個「Serverless 容器」刻度。Cloud Run 可以掛 L4 或 RTX PRO 6000，必須改成 instance-based 計費，實例仍可縮到零，文件寫的啟動時間大約 5 秒。Fargate 沒有 GPU，不代表這一格的每一家都沒有。

出局看的是「這一格的計價與配額裡有沒有你要的資源」，不是這個品牌聽起來像不像 Serverless。

交叉點不是某個 rps 之後 FaaS 單價突然改寫，是水平的實例月費被填滿之後，wall-clock 仍比較貴。

下面的數字鎖在撰稿當下的公開牌價：us-east-1、Linux、on-demand。不含 Savings Plans、資料傳輸、EBS、負載平衡器。FaaS 用 Lambda Event Functions 的 x86 第一級——每百萬次請求 $0.20、每 GB·s $0.0000166667——每月先扣 100 萬次與 40 萬 GB·s。單一架構、單一區域的 duration 超過約 60 億 GB·s 會進下一級，這條模型沒有算到那裡。Fargate 用 Linux/x86：每 vCPU·時 $0.04048、每 GB·時 $0.004445，計費粒度到秒，最低 1 分鐘。VM 的計價單位是 m6i.large：每小時 $0.096、2 vCPU、8 GiB，開滿 730 小時是 $70.08。

短請求的形狀固定成：wall-clock 80 ms，其中 25% 是 CPU（每請求 20 ms 的 vCPU），記憶體 256 MB。容量以利用率 0.6 為目標，超過就進下一台。Fargate 對 256 MB 會落到最小的合法任務：0.25 vCPU 配 0.5 GB，時價 $0.0123425，一個任務的 CPU 容量是每秒 7.5 個請求。

同一組短請求，三個流量假設算出來是：

編排欄在第 4 節會單獨畫出來，數字與 VM 相同：ECS on EC2 買的是同一批機器。EKS 的控制平面小時費、以及 bin packing 的碎片，這張表故意沒有加。

稀疏那一列，8,000 次還在免費額度裡，所以 FaaS 是 $0。Fargate 若為每次請求拉起任務，要付滿 60 秒：8,000 × 60/3,600 × $0.0123425，四捨五入是 $1.65。VM 同樣被 60 秒最低額卡住：8,000 × 60/3,600 × $0.096 = $12.80。一台一直開著則是 $70.08，模型取較低的那個。

日週期的尖峰是 80 × 0.020 / 0.6 = 2.67 vCPU，VM 進到 2 台，而且只有 25% 的時間需要這個編成，其餘縮到 0：2 × 0.25 × $70.08 = $35.04。Fargate 是 ceil(80 / 7.5) = 11 個任務，同樣只覆蓋 25%：11 × 0.25 × $9.01 = $24.78。Lambda 的 20 rps 整月是 5,256 萬次請求、約 105 萬 GB·s，扣掉免費額度後是 $21.17。它比 Fargate 低約 17%。

平穩的尖峰是 165 rps，約 5.5 vCPU。Fargate 用 22 個 0.25 vCPU 任務剛好貼上，月費 $198.22。VM 要 3 台才有 6 vCPU，月費 3 × $70.08 = $210.24。Lambda 是 3.942 億次請求、788 萬 GB·s，扣掉免費額度後 $203.37，夾在兩者中間。

把短請求放上「整月開滿、尖峰等於平均」的軸，Event Functions 大約從 55 rps 起會貴過一台 m6i.large。在那之前，VM 的月費是一條水平線：你為一台沒填滿的機器付 $70.08。rps 不會讓 Lambda 的單價在某個門檻改寫。單價從一開始就不同——以 1,769 MB 約等於 1 vCPU 的配置比例估算，Event Functions 的 wall-clock 大約是每 vCPU·時 $0.104；m6i.large 攤開是每 vCPU·時 $0.048，而且這 0.048 還帶著記憶體。短請求有四分之三的時間在等 I/O，Lambda 仍按 80 ms 收費，VM 只按 20 ms 的 CPU 準備容量。

沒有情境對照表。硬限制先淘汰，裸月費再排名，維運胃口只在 15% 以內改寫建議。

第 3 節的表是短請求的三個點。工作負載還會變成 20 分鐘的作業、握滿 30 分鐘的連線，或一塊 GPU。決策器用同一組常數把四種刻度都算出來，再套三步：

flowchart TD
    L[硬限制] --> Q{跑得了?}
    Q -->|否| X[這層出局]
    Q -->|是| M[算裸月費]
    M --> B{15% 帶內?}
    B -->|否| C[取最便宜]
    B -->|是| P[胃口決勝]
  

決策帶是「裸月費 ≤ 最便宜者 × 1.15」。帶外的層不會因為你想養機器就被選上。這條 15% 是帶寬，與 Managed Instances 的 15% 管理費是兩件事。編排與 VM 同價，平手時才由胃口決定誰管那一批機器。

綠框是這四題的建議。灰掉的格子是第 2 節的硬限制，不是計費失敗。連線容量的教學假設：每 vCPU 2,500 條，所以 0.25 vCPU 的 Fargate 任務是 625 條，m6i.large 是 5,000 條。

預設停在平穩短請求、可以養叢集、沒有 GPU。Fargate $198.22 最便宜，Lambda $203.37，VM 與編排都是 $210.24。15% 帶的上限約 $227.95，三個都在帶內。胃口把建議放在編排，比 Fargate 多 $12.02。改成「只想管程式」，建議改到 Lambda，多付 $5.15。改成「可以養機器」，建議改到 VM，多付的仍是 $12.02——編排與 VM 是同一張帳單，胃口只決定誰來管那 3 台 m6i.large。

再改兩題，規則的另外兩面會出現。日週期短請求的 Lambda 是 $21.17，Fargate $24.78 已經高出約 17%，落在帶外，三種胃口都停在 FaaS。稀疏的 8,000 次把 FaaS 收到 $0，帶寬跟著變成 0，胃口無法把你推向 $1.65 或 $12.80。

20 分鐘的作業一個月若只有 40 次，FaaS 因長度出局。Fargate 約 $0.72（任務按 1 vCPU 與 3 GB，跑完即停）。VM 若每次開機再加 45 秒緩衝，約 $1.33，相對 $0.72 已經超過 15%，建議停在 Fargate；一直開著的那台仍是 $70.08。平穩的 8,000 條長連線則是 Fargate $117.13、兩台 VM $140.16，VM 約貴 20%，同樣出帶。4 條與 500 條都還塞得進同一個任務與同一台機器，月費不會跟著連線數斜線上升——那是計價粒度，不是模型壞掉。

硬限制、閒置與單價、誰還願意管機器。然後補一句：Lambda 這個名字底下已經有不只一種計費點。

開口不要從產品目錄開始。先說哪一層根本跑不了：連續運算超過 15 分鐘、要 GPU、或是必須握著大量閒置連線。再說交叉點從哪裡來——一台起跳的實例月費是水平線，Event Functions 的 wall-clock 是過原點的斜線，兩線相交的那個 rps 取決於單次的 CPU 占比與記憶體，不是一個可以背的常數。最後才說維運胃口：當 Fargate、Lambda、VM 的裸月費擠在 15% 以內，選編排還是自己養機器，是團隊想不想管節點，不是運算單價。

2026 年的 Lambda 定價頁已經把計費點拆開。穩定高流量有 Managed Instances（EC2 牌價加 15% 管理費，另加請求費）。I/O 與短串流有 Web Functions（active CPU，環境記憶體按存活時間）。可暫停的隔離環境有 MicroVMs（按實例秒，外加快照）。四層光譜還在；「用了 Lambda」不再自動等於「按 GB·s 的 Event Functions」。

「尖峰只占 25% 的時間」假設擴縮跟得上。指標、冷卻與暖機造成的缺口，是自動擴縮那篇的模型，不是這張月費表的輸入。