北京
“Lambda一直是每個執行環境一次處理一個請求。”這是過去幾乎所有開發者的默認認知。函數啟動，處理完單個調用后就閑置在那里，等到下一個請求才再次工作。如果面對上千個并發請求，Lambda會啟動上千個執行環境，每個環境都有獨立的內存分配、冷啟動開銷和按GB秒計的計費。
Lambda托管實例（LMI）徹底推翻了這套模型。2025年re:Invent上公布后，2026年3月又新增了32 GB內存與16 vCPU的配置。LMI在你的VPC內的EC2實例上運行函數，由AWS統一負責供應、補丁、伸縮和負載均衡，而每個執行環境可以同時處理多個請求。你仍然保留Lambda的編程模型，卻獲得了EC2的硬件選擇自由度與計費結構。
為了搞清楚這套新模型的實際表現，我動手實現了一個產品相似度引擎。處理程序會把一份產品目錄連同通過Bedrock生成的Nova嵌入一起加載到內存，然后用Amazon Nova多模態嵌入模型編碼傳入的搜索查詢，再借助ThreadPoolExecutor在不同類別上并行計算余弦相似度。這類負載壓根不適合標準Lambda——它要求穩定的吞吐量、大量內存占用，并且混合了I/O（Bedrock API調用）與CPU（向量運算），剛好能從多并發和可配置的軟硬件資源配比中受益。整個項目用Terraform管理基礎設施，基于Python 3.14結合Powertools做可觀測性，嵌入模型也可替換，默認Nova，備選Titan Text Embeddings V2，全部代碼已公開在GitHub，倉庫名為lambda-managed-instances-similarity-engine。
選擇LMI之前，值得先看清它在整個AWS計算版圖中的位置。從全托管到全自管形成了一個連續的選項光譜。當你的需求是持續可預測的吞吐量（每秒幾百到幾千個請求），希望利用特定EC2實例類型的優勢（如Graviton4或高帶寬網絡），運行超過標準Lambda 10 GB內存上限又需要靈活配比內存與vCPU的函數時，LMI就會進入首選清單。在成本端，當月調用量達到千萬級，配合Savings Plans的EC2定價可以比按GB秒計費更劃算。那些需要一次性加載大體積數據集（嵌入、模型、引用數據）并在多次請求間復用的場景，也同樣適合。
標準Lambda依然在突發、不可預測的流量面前顯出優勢，中低吞吐下按調用計價的模式更簡單經濟。而LMI的伸縮機制是觀察CPU利用率和執行環境飽和度后異步調整的，如果流量在5分鐘內增長超過一倍，就可能出現限流，需要等容量跟上來。這種差異提醒著架構師：沒有銀彈，只有面向具體特征的權衡。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
