如何将requirements.txt依赖预构建进Docker镜像以降低EC2冷启动时长

问题核心原因 #

你遇到的冷启动重复下载依赖问题，根源是Cortex部署框架的默认运行机制导致：

• 默认PythonPredictor模式下，Cortex不会直接使用你构建的自定义镜像，而是启动自带的Python服务基础镜像后，将你的项目代码、requirements.txt挂载到容器内/mnt/project路径下，现场执行依赖安装。
• 从启动日志可验证：下载的依赖版本（如torch 1.8.1+cu101）和你自己requirements.txt标注的版本（torch 1.9.0）完全不一致，且日志显示依赖读取路径为Cortex自带的/opt/conda/envs/env虚拟环境，和你Dockerfile中系统Python的依赖安装路径不匹配，因此Cortex识别不到提前装好的依赖，才会重复下载。

解决方案 #

方案1：切换自定义容器部署模式（最彻底） #

直接使用Cortex的DockerPredictor替代默认的PythonPredictor，配置后Cortex会直接拉取你提前构建、已装完全部依赖的镜像启动实例，不会执行任何运行时依赖安装步骤，完全避免冷启动下载。
操作要点：

• 本地构建Docker镜像后推送到和EC2同区域的AWS ECR仓库
• 在Cortex的API配置YAML中，指定predictor.type: docker，同时填写你的ECR镜像地址即可。

方案2：默认模式下复用预安装依赖 #

如果不想调整部署模式，可以调整Dockerfile适配Cortex的运行环境：

• 基础镜像替换为Cortex官方的Python服务基础镜像，保证Python环境路径一致
• 提前将requirements.txt依赖安装到Cortex默认使用的/opt/conda/envs/env虚拟环境中
• 在Cortex的API配置中指定该镜像作为PythonPredictor的基础镜像，Cortex会跳过依赖安装步骤直接启动服务。

方案3：临时优化依赖安装速度 #

如果暂时不想调整部署架构，可以通过以下方式降低冷启动耗时：

• 在AWS同区域搭建私有PyPI镜像源，所有EC2实例从内网拉取依赖，速度远快于公网
• 将torch等大体积依赖的whl包提前打到镜像内，安装时直接读取本地文件无需下载

验证方法 #

本地启动你构建的Docker镜像，执行docker exec -it 容器ID pip list，核对依赖版本是否和requirements.txt一致，确认依赖安装正确后再推送到镜像仓库使用。

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