对于机器学习模型而言,在训练和序列化之后,实际要考虑的问题是这些通常被称为“工件”的文件应该存放在哪里,FastAPI 应用如何可靠地访问它们?有效地管理这些工件,有助于维持整洁的项目结构、保证结果可重现性以及实现顺畅的部署。模型工件的存储位置模型文件的存放位置取决于应用的复杂程度、部署环境和团队工作流程。我们来看看一些常见方法:在应用目录内: 对于较简单的项目或在开发阶段,您可以直接将模型工件存储在FastAPI项目结构中,通常是在一个专门的目录,比如 models/ 或 artifacts/。优点: 管理简单,可以使用Git与应用代码一起方便地进行版本控制。存储无需外部依赖。缺点: 增加应用包/代码库的大小。如果模型很多、很大或更新频繁,可能会变得难以管理。将模型工件与应用代码部署紧密绑定。专用文件服务器或网络共享: 在某些组织环境中,模型可能会存储在共享网络驱动器或专用的内部文件服务器上。您的应用需要适当的权限和网络访问来获取这些文件。优点: 集中存储,与各个应用代码库分离。缺点: 需要管理网络访问和权限。如果网络路径较慢,可能会引入延迟。与别的方案相比,可能缺乏版本控制能力。云存储服务: 像Amazon S3、Google Cloud Storage (GCS) 或 Azure Blob Storage 这样的服务是生产环境的常用选择。它们提供可扩展、持久且高可用的存储,与您的应用服务器解耦。优点: 优秀的扩展性和可靠性。内置版本控制能力。细粒度的访问控制。模型可以独立于应用部署进行更新。缺点: 引入对云服务商的依赖。需要处理身份验证,并使用特定的SDK(如AWS的boto3、GCP的google-cloud-storage)来访问文件。存储和数据传输可能产生费用。模型注册中心: MLflow Model Registry、DVC(数据版本控制)、Vertex AI Model Registry 或 SageMaker Model Registry 等平台专门用于管理机器学习生命周期,包括模型工件存储、版本控制和阶段管理(例如,测试阶段、生产阶段)。优点: 提供模型管理的结构化工作流程。追踪实验、参数、指标和模型血缘。简化协作和管理。通常与云存储后端集成良好。缺点: 引入另一个工具/平台的依赖。需要学习特定注册中心的API和工作流程。对于非常简单的项目来说可能过于复杂。在应用中访问工件无论存储位置如何,您的FastAPI应用都需要一种方式来找到并加载正确的模型工件。配置: 避免在应用逻辑中直接硬编码路径或存储桶名称。使用配置文件(例如,通过Pydantic设置管理处理的.env文件)或环境变量来指定模型工件的位置。这使得您的应用在不同环境(开发、测试、生产)中更具适应性。加载策略: 如“将模型加载到FastAPI应用中”一节所述,决定是在应用启动时(常用模型常见)还是按需加载模型。从云存储访问模型可能会影响此决定,因为初始下载期间可能存在延迟。缓存机制在此处可能很有用。模型工件版本控制机器学习模型是不断发展的。您会使用新数据重新训练它们,尝试不同的架构,或者更新预处理步骤。对模型工件进行版本控制对于以下几点来说非常重要:可重现性: 确保您能够追溯在某个预测中使用了哪个具体的模型版本。回滚: 如果新部署出现问题,可以快速恢复到以前已知的良好模型版本。实验: 同时部署不同模型版本(例如,用于A/B测试)。版本控制策略:简单的命名约定: 在文件名中包含版本号或日期(例如,sentiment_model_v1.2.pkl、forecast_model_2024-03-15.joblib)。这很简单,但对于在本地存储模型的小项目来说可行。目录结构: 使用目录来分离版本(例如,models/v1/model.pkl、models/v2/model.pkl)。云存储版本控制: 大多数云服务商提供对象版本控制,在您上传同名新文件时会自动保留旧版本。然后您可以引用特定的对象版本。模型注册中心: 这些平台提供内置的版本控制机制,通常将版本与特定的训练运行、指标和生命周期阶段关联起来。组织项目清晰的目录结构有助于管理工件,特别是当它们本地存储时。考虑采用如下布局:digraph G { bgcolor="transparent"; node [shape=folder, style=filled, fillcolor="#a5d8ff"]; edge [color="#495057"]; project [label="my_ml_api/"]; app [label="app/"]; models_dir [label="models/"]; main_py [label="main.py", shape=note, fillcolor="#dee2e6"]; routers_py [label="routers.py", shape=note, fillcolor="#dee2e6"]; schemas_py [label="schemas.py", shape=note, fillcolor="#dee2e6"]; model_v1 [label="sentiment_v1.pkl", shape=note, fillcolor="#96f2d7"]; model_v2 [label="sentiment_v2.joblib", shape=note, fillcolor="#96f2d7"]; requirements [label="requirements.txt", shape=note, fillcolor="#dee2e6"]; dockerfile [label="Dockerfile", shape=note, fillcolor="#dee2e6"]; project -> app; project -> models_dir; project -> requirements; project -> dockerfile; app -> main_py; app -> routers_py; app -> schemas_py; models_dir -> model_v1; models_dir -> model_v2; }这是一个示例项目结构,展示了一个专门的models/目录,用于在app/中的应用代码旁边存储序列化的模型工件。在此结构中,app/内的应用代码将被配置为从同级models/目录加载模型。安全考量请谨慎对待您的模型工件,特别是当它们是专有信息,或者内部嵌入的预处理步骤会显示关于训练数据的敏感信息时。本地存储: 确保包含模型的目录设置了适当的文件系统权限。云存储: 使用云服务商提供的访问控制机制(例如,AWS/GCP中的IAM策略、Azure中的Access Keys/SAS令牌)来限制对授权应用或服务的访问。对静态工件进行加密。模型注册中心: 充分利用注册中心平台提供的身份验证和授权功能。部署打包您选择的工件管理策略直接影响如何为部署打包您的应用,特别是当使用容器时(第6章将涵盖此内容)。本地工件: 在构建过程中,您需要将模型文件复制到容器镜像中(例如,在Dockerfile中使用COPY指令)。云端/注册中心工件: 您的容器可能不需要内置模型文件。相反,在容器内运行的应用会在启动时或按需从外部存储位置下载所需的模型工件。这通常会使容器镜像更小,但需要在容器环境中进行网络访问和凭证管理。选择正确的方法需要平衡简易性、可扩展性、安全性和与MLOps工作流程的集成。对于生产系统,通常建议借助云存储或专用的模型注册中心,而不是直接将模型与应用代码打包在一起。