“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.