“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分钟内增长超过一倍，就可能出现限流，需要等容量跟上来。这种差异提醒着架构师：没有银弹，只有面向具体特征的权衡。