8.1 傳統 VM 啟動要幾十秒？Serverless 對毫秒級冷啟動的苛刻要求#

一次改變產業的發表#

2014 年 11 月，AWS re:Invent 大會上，亞馬遜發布 AWS Lambda——「把你的函式上傳，我負責所有基礎設施，事件來了就執行，執行多久付多少錢。」Serverless／FaaS（Function as a Service） 的時代正式開場。

開發者世界為之著迷：

Lambda 的承諾：
  · 不用管伺服器、不用容量規劃
  · 毫秒計費（以 100ms 為單位）
  · 事件驅動：HTTP 請求、佇列、排程、檔案上傳皆可觸發
  · 自動擴縮：0 個實例到數千個並發，全自動

光鮮背後的工程煉獄：冷啟動（Cold Start）#

Serverless 的經濟模型有一個殘酷的技術前提：函式沒有常駐的機器。當請求到達而「溫熱的執行環境」不夠時，平台必須現場憑空造出一個環境——這就是冷啟動。

傳統 VM 冷啟動的解剖（2014 年水準）：
  BIOS/韌體初始化          ~1-2 秒
  核心載入與初始化          ~1-3 秒
  init 與系統服務啟動        ~5-20 秒
  應用程式載入              ~1-5 秒
  總計：常見 20-60 秒       ← 對互動式請求，等於永遠

容器的冷啟動：
  省去核心與韌體，約 0.5-2 秒
  ← 好得多，但隔離等級不足以讓「陌生租戶的代碼」共處一台機器

矛盾就此攤牌：

需求公式：毫秒級冷啟動 ＋ VM 級多租戶隔離 ＋ 每秒數千次建立銷毀

  VM      ：隔離 ✔   啟動 ✘（數十秒）
  容器    ：啟動 ~✔  隔離 ✘（共享核心）
  兩者兼得：2014 年市面上沒有現成答案

Lambda 的第一代答案：微型容器＋速記快照#

AWS 早年用改造過的輕量容器技術執行客戶函式，並用各種工程手法壓榨冷啟動：

預先配置（provisioned pools）：預熱好的執行環境常備待命；
執行環境重用（warm reuse）：同一環境連續服務多個請求，只付一次冷啟動；
記憶體快照／fork 加速：以 copy-on-write 快照快速「複製」已初始化的環境。

但安全審計與多租戶風險模型始終像達摩克利斯之劍：不能讓陌生租戶的代碼共享核心。AWS 需要一個徹底的答案。

量化需求：一個內部指標的誕生#

Lambda 團隊為這個問題定下了近乎苛刻的工程目標（後來成為 Firecracker 的官方數據）：

Firecracker 的出廠目標（2018 公開數據）：
  · VM 啟動時間  < 125 毫秒
  · 記憶體開銷    每個 VM 的 VMM 程序 < 5 MB
  · 密度          單台實體機上數千個 MicroVM
  · 隔離          KVM 硬體輔助的 VM 級邊界

「125 毫秒」這個數字值得停一下：它接近人類一次眨眼的時長。工程上，這意味著從 BIOS 模擬到核心初始化到使用者函式就緒的全鏈條都要被剝到只剩骨架。

冷啟動戰爭的技術清單#

要打贏冷啟動，每一毫秒都來自一次刪除：

傳統 VM 的包袱	MicroVM 的手術
完整 PC 韌體/BIOS	極簡虛擬韌體（微碼級引導）
通用裝置模型（IDE、USB、音效…）	只留 virtio 網卡＋virtio 區塊裝置
完整系統呼叫模擬與設備直通	純 virtio 化 I/O
常駐管理守護行程＋REST API 層	單一 Unix socket 的極簡 API
通用發行版 guest 映像	客製化極小 guest 核心

歷史關聯：這份「刪除清單」與 1970 年代 CP/CMS 的「極簡 VMM 哲學」遙相呼應——最好的 hypervisor 什麼都不多做。差別在於，Serverless 把「少」從設計品味變成了毫秒級的硬性 KPI。下一節看執行這份清單的兩大產物。