当我开始在MLflow上工作时，我遇到了同样的问题。
所以这个概念是有两个不同的东西tracking uri和artifact uri。
tracking uri存储日志，artifact uri存储工件（如yaml、pkl等）。
但是如果你想要一个通用的uri，你可以使用SQLite作为本地数据库，然后你的命令将是这样的...
mlflow服务器--backend-store-uri sqlite：///mlruns.db--host 0.0.0.0--端口5000
Note:如果您正在使用远程服务器，那么您的工件存储也应该是远程存储，它不适用于本地数据库
并且不要忘记显式地设置跟踪URI，有两种方法：

• 在你的代码中mlflow.set_tracking_uri("sqlite:///mlruns.db")
• 使用环境变量export MLFLOW_TRACKING_URI=sqlite:///mlruns.db

工件存储需要对服务器和客户端都可访问。如果您的客户机从远程机器连接，并且您没有配置像S3这样的远程工件存储，那么它们的工件文件将保存在本地。您可以查看本地存储
这里有一个关于目前支持的不同工件存储的解释：https://mlflow.org/docs/latest/tracking.html#artifact-stores

我遇到了同样的问题（对于mlflow.pytorch）。对我来说，通过替换log_model()和log_atrifacts()来修复它。
所以记录藏物的是：

mlflow.log_metric("metric name", [metric value])
mlflow.pytorch.log_model(model, "model")
mlflow.log_artifacts(output_dir)

此外，对于终端中的ui，cd到mlruns所在的目录。例如，如果mlruns的位置是...\your-project\mlruns：

cd ...\your-project

转到安装mlflow的环境。

...\your-project> conda activate [myenv]

然后，运行mlflow ui

(myenv) ...\your-project> mlflow ui

我在这篇文章中也回答了这个问题：

我发现我的问题是，通过使用PyCharm和Docker，它自动将我的跟踪uri设置为/opt/project，这是PyCharm自动设置的共享卷，用于与其“调试器容器”和实际的Python容器一起使用我的代码。这样，如果我在同一个容器中运行ui，我就可以找到并看到工件，但如果我使用不同的docker容器，我就不能找到并看到工件。
如果关键字“artifact_location”类似于“file：///opt/project/mlruns/0”，则可以通过检查mlruns文件夹中的meta.yaml文件来验证这是否是您的问题。
我通过在导入后设置跟踪URI来修复它：

import mlflow

mlflow.set_tracking_uri("file:///<your-root-path>/mlruns")