使用Requests可下载MLFlow Artifact，但MLFlow Client无法下载的问题

1. MLFlow Client与Requests的跟踪URI配置不一致 #

• 核心问题：Requests直接调用MLFlow服务器的公开API地址，但MLFlow Client未正确设置tracking_uri，或使用了容器内无法访问的地址（比如localhost，Docker容器内的localhost指向容器自身，而非宿主机的MLFlow服务）。
• 验证：打印当前Client的跟踪URI：

  import mlflow
  print(mlflow.get_tracking_uri())
  

  对比Requests请求中使用的MLFlow服务器域名/IP+端口，确认两者完全一致。
• 解决：在FastAPI代码中显式设置正确的跟踪URI，例如：

  mlflow.set_tracking_uri("http://[宿主机IP]:5000")
  

  避免使用localhost，改用宿主机可访问的IP或容器服务名（如果用Docker Compose编排）。

2. Artifact存储的访问方式差异 #

• 核心问题：MLFlow默认用本地文件系统存储Artifact时，Requests通过MLFlow服务器代理下载（服务器能访问本地存储），但MLFlow Client可能尝试直接读取本地文件路径——而Docker容器内未挂载对应目录，导致找不到文件。
• 验证：查看MLFlow服务器的artifact_root配置（可通过MLFlow UI的实验详情页查看），如果是本地路径（如./mlruns），检查容器内是否有该路径的挂载。
• 解决：
  • 强制MLFlow Client通过服务器API获取Artifact：确保tracking_uri指向MLFlow服务器，而非本地文件路径；
  • 若用本地存储，在Docker运行命令中挂载MLFlow服务器的mlruns目录到容器对应路径，例如：

    docker run -v /host/path/to/mlruns:/container/path/to/mlruns your-fastapi-image
    

3. 模型标识或Artifact路径参数不匹配 #

• 核心问题：Requests使用的模型run_id、Artifact路径，与MLFlow Client调用时的参数不一致（比如大小写错误、版本号错用、路径拼写差异）。
• 验证：
  • 对比Requests的API URL（例如http://mlflow-server:5000/api/2.0/mlflow/artifacts/download?path=model&run_id=abc123）中的run_id和path，与MLFlow Client代码中的参数：

    mlflow.artifacts.download_artifacts(run_id="abc123", artifact_path="model")
    

  • 登录MLFlow UI，确认模型的Artifact路径、run_id或注册模型的名称/版本是否正确。
• 解决：严格对齐两者的参数，确保模型标识（run_id/注册模型名+版本）和Artifact路径完全一致。

4. Docker构建阶段的网络限制 #

• 核心问题：如果在Docker构建阶段（RUN指令）执行MLFlow Client下载模型，此时容器可能无法访问外部MLFlow服务器（构建网络默认隔离），而Requests测试是在宿主机或运行阶段进行的，导致构建阶段失败。
• 验证：检查Dockerfile是否在RUN中执行模型下载，而非CMD/ENTRYPOINT运行阶段。
• 解决：
  • 将模型下载逻辑移到容器运行阶段（比如FastAPI启动时触发）；
  • 若必须在构建阶段下载，使用docker build --network=host参数让构建容器共享宿主机网络，确保能访问MLFlow服务器。

5. MLFlow版本不兼容 #

• 核心问题：MLFlow Client版本与服务器版本差异过大，导致API调用不兼容（比如新版本Client的请求格式被旧版本服务器拒绝）。
• 验证：分别在MLFlow服务器和FastAPI容器内执行mlflow --version，确认版本一致。
• 解决：在FastAPI的requirements.txt中指定与服务器完全相同的MLFlow版本，例如：

  mlflow==2.8.0
  

内容的提问来源于stack exchange，提问作者SzPeter-9923