MLflow proxied artifact access访问S3报Unable to locate credentials

从报错栈调用s3_artifact_repo.py的逻辑可以直接判断：客户端没有识别到服务端的代理工件模式，仍在尝试直连S3上传，完全没有走MLflow服务端的代理接口。正常启用proxied artifact access的场景下，客户端应该调用http_artifact_repo逻辑走HTTP接口和服务端交互，根本不会触发本地boto3的鉴权流程。

以下是按优先级排序的修复步骤：

1. 对齐客户端与服务端MLflow版本 #

版本不匹配是该问题最高发的诱因：

• 确保客户端、服务端MLflow版本完全一致，且均不低于1.23.0（proxied artifact模式在该版本正式稳定可用）。低版本客户端无法识别服务端返回的代理专用URI格式，会自动降级为直连对象存储的逻辑。
• 验证方式：本地执行pip show mlflow查客户端版本，进入K8s服务端Pod执行mlflow --version查服务端版本，二者必须对齐。

2. 修正服务端启动参数 #

你当前的启动参数存在冗余配置，会直接覆盖代理模式的默认行为：

• 开启--serve-artifacts并配置--artifacts-destination后，服务端会自动将默认工件根路径设置为代理专用的mlflow-artifacts:/格式，你额外添加的--default-artifact-root s3://my_bucket/artifacts配置会覆盖这个自动逻辑，导致新建实验写入的工件URI仍是直连S3的格式，客户端拿到后就会走本地S3上传逻辑。
• 修正后的启动参数移除冗余项即可：

mlflow server \
    --host 0.0.0.0 \
    --port 5000 \
    --backend-store-uri postgresql://user:pw@endpoint \
    --artifacts-destination s3://my_bucket/artifacts \
    --serve-artifacts

• 重启服务后验证代理接口可用性：本地端口转发完成后，访问http://localhost:5000/api/2.0/mlflow-artifacts/artifacts，返回405 Method Not Allowed即为正常（该接口仅支持上传下载的PUT/GET方法，直接GET访问根路径返回405符合预期），返回404则说明服务端代理功能未正常启动。

3. 正确新建测试实验 #

存量实验哪怕是之前新建的，只要工件路径写死了S3地址，就永远不会走代理逻辑：

• 删除之前创建的test、test2实验，不要在UI手动给新实验指定S3路径作为工件位置，也不要在代码里调用mlflow.set_experiment时传入指向S3的artifact_location参数。
• 直接在代码中调用mlflow.set_experiment("test_proxy")，让服务端自动分配代理格式的工件路径。

4. 验证代理生效状态 #

新实验启动运行后，先执行参数上报，再到MLflow UI查看该运行的详情页：

• 如果Artifact URI字段显示为mlflow-artifacts:/<run-id>/artifacts格式，说明代理配置已经生效，此时执行模型上传不会再触发本地AWS凭证校验，哪怕卸载本地boto3也能正常上传工件。
• 如果该字段仍显示s3://my_bucket/xxx格式，说明前述配置仍有遗漏，逐一回查即可。

必查配置项 #

不要漏了服务端本身的S3权限：代理模式只是把客户端的鉴权逻辑转移到服务端，K8s里的MLflow服务Pod必须绑定有S3读写权限的ServiceAccount，或者在Pod环境变量中配置正确的AWS凭证，否则哪怕客户端走代理，服务端也会因为没有权限写S3报错。
如果使用2.0以上版本的MLflow，不要在客户端本地设置MLFLOW_S3_ENDPOINT_URL、AWS_ACCESS_KEY_ID这类S3相关环境变量，部分版本检测到这类变量存在时，会自动降级为直连S3逻辑。

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