AWS Lambda加载170MB ONNX模型速度不稳定冷启动耗时过长咨询

使用搭载5个170MB大小AI模型的容器镜像部署Lambda函数，首次调用时需要将所有模型加载到内存用于后续推理。

• 多数场景下单模型加载耗时10-25秒，冷启动总耗时可达2分钟左右；偶尔单模型加载仅需1-2秒，冷启动总耗时仅10秒，性能波动极大
• 耗时根源已定位到磁盘文件读取到内存的步骤，仅「将磁盘字节文件读取到变量」的简单操作就需要10-20秒
• 已使用10240MB内存规格的Lambda函数，理论上应该拥有最高处理性能

• 用onnxruntime和Python加载模型
• 所有代码和模型都存在容器内，从容器本地读取
• 测试验证：使用with open("model.onnx","rb") as f: cont = f.read()读取任意模型需要20秒，之后再调用model = onnxruntime.InferenceSession("model.onnx")加载相同文件可瞬间完成，确认问题出在文件读取环节，和onnxruntime本身无关
• 该问题在ZIP包部署的Lambda函数读取大文件时也会出现，排除容器本身问题

1. 创建Lambda函数
2. 配置函数为10240MB内存、30秒超时
3. 上传对应测试ZIP包
4. 运行测试事件，测试打开文件耗时可达16秒

测试包内含168MB的model.onnx文件，以及如下代码的lambda_function.py：

import json,time

def lambda_handler(event, context):
    # TODO implement
    
    tt = time.time()
    with open("model.onnx","rb") as f:
        cont = f.read()
    tt =  time.time()-tt
    
    print(f"Open time: {tt:0.4f} s")
    
    return {
        'statusCode': 200,
        'body': json.dumps(f'Open time: {tt:0.4f} s')
    }

1. Lambda部署包采用懒加载机制：不管是ZIP包还是容器镜像，冷启动时都不会全量预先下载到运行环境本地磁盘，首次访问大文件时系统才会从后端存储拉取对应文件块，跨网络拉取的开销就是10-20秒高耗时的核心来源。
2. 性能波动是缓存导致：如果函数短时间内多次冷启动，后端存储可能会缓存部署包的文件块，再次读取时不需要跨网络拉取，耗时就会降到1-2秒，就是你遇到偶尔加载快的情况。
3. Lambda挂载的是网络存储，不是本地SSD，本身大文件顺序读性能就远低于常规云服务器本地盘，也会带来额外耗时。

快速落地优化 #

• 提前预读文件：在函数初始化阶段（即lambda_handler之外的全局代码区域）就异步预加载所有模型文件到内存，利用冷启动初始化窗口并行拉取文件，不要等到请求进入才开始读取。
• 压缩模型体积：对ONNX模型做剪枝、量化处理，将单模型体积压缩到50MB以内，可大幅降低拉取耗时。
• 调整读取方式：改用mmap内存映射方式读取大文件，可降低单次IO的阻塞耗时。

长期稳定优化 #

• 用Lambda层存储模型文件：Lambda层的加载优先级更高，存储架构和普通部署包有差异，冷启动加载大文件的耗时更低。
• 模型存入内存文件系统：10GB内存规格的Lambda最多可使用5GB左右的共享内存，可将模型提前加载到共享内存目录，后续读取完全走内存，无任何IO开销。
• 开启预置并发：提前预启动Lambda运行实例，将模型预先加载到内存，可完全消除冷启动的加载耗时，适合对延迟要求高的生产场景。
• 启用Lambda SnapStart：如果使用支持快照的 runtime，开启后可直接保存启动后加载完模型的内存快照，冷启动时直接恢复快照，加载耗时可降到百毫秒级别。

内容的提问来源于stack exchange，提问作者bezale