- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 为什么需要 MLflow 2.x 运维指南
- 架构设计:追踪服务器与 Artifact 存储分离
- 实验追踪设计模式
- Model Registry 运维策略
- 实验追踪工具对比
- CI/CD 流水线集成
- 多租户配置
- Artifact 管理与成本优化
- 故障排查:常见的运维故障
- 运维检查清单
- 回滚与故障恢复流程
- 从 MLflow 2.x 迁移到 3.x 的要点
- 结语
- 参考资料
- 测验
为什么需要 MLflow 2.x 运维指南
MLflow 每月下载量超过 1,400 万次,已经成为开源实验追踪工具事实上的标准。安装它、调用一行 mlflow.autolog(),都不难。问题出在这之后。团队规模扩大、实验数量超过数千个之后,缺少实验命名规范、Artifact 存储容量暴涨、模型晋升流程混乱这类运维问题就会接连爆发。
本文覆盖 MLflow 2.x(2.9~2.18)以及 3.x 早期版本,讲解在生产级别设计和运维实验追踪与模型注册表的实战模式。写作前提是团队级运维,而不是本地练习。
架构设计:追踪服务器与 Artifact 存储分离
核心组成
MLflow 生产架构应当分离为三层。
- Tracking Server:存储实验元数据(参数、指标、标签)。使用 PostgreSQL 或 MySQL 后端。
- Artifact Store:存储模型二进制文件、数据集、可视化文件。使用 S3/GCS/Azure Blob。
- Model Registry:模型版本管理、别名(alias)、阶段切换。与 Tracking Server 使用同一个数据库。
# 生产追踪服务器启动命令
mlflow server \
--backend-store-uri postgresql://mlflow_user:${DB_PASSWORD}@db.internal:5432/mlflow_prod \
--default-artifact-root s3://company-mlflow-artifacts/prod/ \
--artifacts-destination s3://company-mlflow-artifacts/prod/ \
--host 0.0.0.0 \
--port 5000 \
--workers 4 \
--gunicorn-opts "--timeout 120 --keep-alive 5"
配置 Artifact 存储时的注意事项
把 S3 用作 Artifact 存储时,如果客户端和服务器两端都设置了 MLFLOW_S3_ENDPOINT_URL,会发生路径冲突。原则是:服务器端用 --default-artifact-root 指定路径,客户端不要设置这个环境变量。
# 客户端配置(正确方式)
import mlflow
import os
# 只设置追踪服务器 URI。Artifact 路径由服务器管理。
os.environ["MLFLOW_TRACKING_URI"] = "http://mlflow.internal:5000"
# S3 认证推荐使用 IAM Role(EC2/EKS 环境)
# 只有本地开发时才明确指定 credential
# os.environ["AWS_PROFILE"] = "mlflow-dev"
mlflow.set_experiment("/team-search/ranking-model-v3")
使用 GCS 时按 gs://bucket/path 格式指定,生产环境中应使用 Workload Identity 而非 Service Account Key。Artifact 上传/下载超时由 MLFLOW_ARTIFACT_UPLOAD_DOWNLOAD_TIMEOUT 环境变量控制,GCS 默认值为 60 秒。处理大体积模型 checkpoint 时,应把这个值调到 300 秒以上。
实验追踪设计模式
实验命名策略
实验名称使用 /{team}/{project}/{experiment-type} 模式。实验数量一旦超过 100 个,扁平命名就会变得无法管理。
import mlflow
# 好的例子:分层命名
mlflow.set_experiment("/search-team/query-ranking/bert-finetune")
mlflow.set_experiment("/fraud-team/transaction-classifier/xgboost-baseline")
mlflow.set_experiment("/recommendation/item2vec/hyperopt-sweep")
# 不好的例子:扁平且含糊的命名
# mlflow.set_experiment("experiment_1")
# mlflow.set_experiment("test_model")
# mlflow.set_experiment("johns_experiment")
标签体系设计
标签是实验检索与治理的核心。至少要记录以下标签。
import mlflow
from datetime import datetime
with mlflow.start_run(run_name="bert-ranking-v3.2.1") as run:
# 必需标签
mlflow.set_tag("team", "search")
mlflow.set_tag("owner", "jane.doe@company.com")
mlflow.set_tag("git.commit", "a1b2c3d4")
mlflow.set_tag("data.version", "v2026.03.05")
mlflow.set_tag("environment", "gpu-cluster-a100")
mlflow.set_tag("purpose", "hyperparameter-sweep")
# 记录参数
mlflow.log_params({
"learning_rate": 2e-5,
"batch_size": 32,
"max_epochs": 10,
"model_architecture": "bert-base-uncased",
"optimizer": "AdamW",
"warmup_steps": 500,
})
# 按 step 单位记录指标(epoch 或全局 step)
for epoch in range(10):
train_loss = train_one_epoch(model, train_loader)
val_ndcg = evaluate(model, val_loader)
mlflow.log_metrics({
"train_loss": train_loss,
"val_ndcg@10": val_ndcg,
}, step=epoch)
# 记录最终模型
mlflow.pytorch.log_model(
model,
artifact_path="model",
registered_model_name="search-ranking-bert",
)
autolog 的陷阱
mlflow.autolog() 对快速原型开发很有用,但在生产实验中会出现以下问题。
- 不必要的 Artifact 过量记录:以 sklearn 为例,feature importance plot、confusion matrix 等会在每次 run 时都被保存。跑上几千次超参数搜索,Artifact 存储容量就会急剧增加。
- 自定义指标缺失:领域特化指标(NDCG、MRR、业务 KPI)不会被 autolog 记录。
- 框架间缺乏一致性:PyTorch、TensorFlow、XGBoost 各自用不同的指标名称和结构记录。
生产环境中建议用 mlflow.autolog(log_models=False, log_datasets=False) 只启用最小限度的记录,核心指标和模型则显式记录。
Model Registry 运维策略
模型命名规则
模型名称应当以产品为中心来命名。版本号或算法名称不要包含在模型名称中。
# 好的例子(以产品/功能为中心)
fraud-detector
search-ranker
recommendation-item2vec
churn-predictor
# 不好的例子(以算法/版本为中心)
xgboost-fraud-v3
bert-search-ranking-2026
lgbm_model_final_final
版本号由注册表自动管理。算法变更通过标签或描述(description)来追踪。
基于 Alias 的部署工作流
MLflow 2.x 中推荐使用 Alias 系统取代传统的 Stage(Staging/Production)。Alias 更灵活,可以管理多个生产环境。
from mlflow import MlflowClient
client = MlflowClient()
# 注册新模型版本后设置 alias
model_name = "search-ranker"
version = client.create_model_version(
name=model_name,
source="runs:/abc123/model",
run_id="abc123",
description="BERT-base finetuned on 2026 Q1 query logs"
)
# 确认当前 champion
try:
current_champion = client.get_model_version_by_alias(model_name, "champion")
print(f"Current champion: v{current_champion.version}")
except mlflow.exceptions.MlflowException:
print("No champion alias set yet")
# Canary 部署:给新版本赋予 challenger alias
client.set_registered_model_alias(model_name, "challenger", version.version)
# Canary 验证通过后晋升为 champion
client.set_registered_model_alias(model_name, "champion", version.version)
# 把旧 champion 移到 archived
client.set_registered_model_alias(model_name, "previous-champion", current_champion.version)
服务代码中如果按 alias 加载模型,只需在注册表中修改 alias,就能实现模型的无停机替换。
import mlflow
# 服务代码:基于 alias 加载模型
model = mlflow.pyfunc.load_model("models:/search-ranker@champion")
predictions = model.predict(input_data)
模型版本元数据管理
每个模型版本都应当用标签记录以下信息。缺了这些信息,六个月后就没人知道"这个模型是用什么数据训练出来的"。
client.set_model_version_tag(model_name, version.version, "training_data", "s3://data/query-logs/2026-q1/")
client.set_model_version_tag(model_name, version.version, "training_commit", "a1b2c3d4e5f6")
client.set_model_version_tag(model_name, version.version, "validation_ndcg", "0.847")
client.set_model_version_tag(model_name, version.version, "approved_by", "jane.doe")
client.set_model_version_tag(model_name, version.version, "approval_date", "2026-03-05")
实验追踪工具对比
在选择 MLflow 之前,应当先评估符合团队需求的工具。
| 项目 | MLflow | Weights & Biases | Neptune.ai | ClearML |
|---|---|---|---|---|
| 许可证 | Apache 2.0(开源) | 付费 SaaS | 付费 SaaS | SSPL(受限开源) |
| 自托管 | 完全支持 | 有限 | 有限 | 完全支持 |
| 实验追踪 | 优秀 | 最优(可视化) | 最优(大规模) | 优秀 |
| Model Registry | 内置 | 内置 | 需外部集成 | 内置 |
| GenAI 支持 | 在 3.x 中强化 | 内置 LLM 评估 | 有限 | 有限 |
| 大规模日志记录 | 一般(依赖数据库) | 优秀 | 最优(1000 倍吞吐量) | 优秀 |
| UI/UX | 功能性 | 直观,最优 | 功能性 | 优秀 |
| 成本(50 人团队) | 仅基础设施成本 | $2,500~10,000/月 | $2,500~10,000/月 | 仅基础设施成本 |
| Databricks 集成 | 原生 | 插件 | 插件 | 有限 |
| 社区 | 20K+ GitHub Star | 活跃 | 活跃 | 活跃 |
选择标准总结:
- 成本敏感 + 必须自托管:MLflow 或 ClearML
- 最高水准的可视化 + 团队协作:Weights & Biases
- 大规模企业 + 治理:Neptune.ai
- 正在使用 Databricks 生态:MLflow(原生集成)
CI/CD 流水线集成
GitHub Actions 与 MLflow 集成
把模型训练和注册自动化,能保证可复现性、减少人为失误。
# .github/workflows/train-and-register.yml
name: Train and Register Model
on:
push:
paths:
- 'models/search-ranker/**'
branches: [main]
workflow_dispatch:
inputs:
experiment_name:
description: 'MLflow experiment name'
required: true
default: '/search-team/query-ranking/scheduled-retrain'
env:
MLFLOW_TRACKING_URI: ${{ secrets.MLFLOW_TRACKING_URI }}
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
jobs:
train:
runs-on: [self-hosted, gpu]
steps:
- uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install dependencies
run: |
pip install -r requirements.txt
pip install mlflow[extras]
- name: Train model
run: |
python models/search-ranker/train.py \
--experiment-name "${{ github.event.inputs.experiment_name || '/search-team/query-ranking/ci-train' }}" \
--run-name "ci-${{ github.sha }}" \
--register-model search-ranker
- name: Validate model
run: |
python models/search-ranker/validate.py \
--model-uri "models:/search-ranker@challenger" \
--threshold-ndcg 0.82
- name: Promote to champion
if: success()
run: |
python scripts/promote_model.py \
--model-name search-ranker \
--from-alias challenger \
--to-alias champion
模型验证脚本示例
CI 流水线中,模型晋升之前必须先做性能验证。
# scripts/validate_model.py
import mlflow
import sys
from mlflow import MlflowClient
def validate_model(model_name: str, alias: str, threshold: float) -> bool:
"""验证模型性能是否满足阈值。"""
client = MlflowClient()
# 按 alias 查询模型版本
model_version = client.get_model_version_by_alias(model_name, alias)
run = client.get_run(model_version.run_id)
# 确认验证指标
val_ndcg = run.data.metrics.get("val_ndcg@10")
if val_ndcg is None:
print(f"ERROR: val_ndcg@10 metric not found in run {model_version.run_id}")
return False
# 与当前 champion 比较
try:
champion = client.get_model_version_by_alias(model_name, "champion")
champion_run = client.get_run(champion.run_id)
champion_ndcg = champion_run.data.metrics.get("val_ndcg@10", 0)
print(f"Champion v{champion.version} NDCG: {champion_ndcg:.4f}")
print(f"Challenger v{model_version.version} NDCG: {val_ndcg:.4f}")
# 检查相对 champion 的性能下降
if val_ndcg < champion_ndcg * 0.98: # 下降超过 2% 时判定失败
print("FAIL: Challenger performs worse than champion by more than 2%")
return False
except Exception:
print("No existing champion found. Proceeding with threshold check only.")
# 绝对阈值检查
if val_ndcg < threshold:
print(f"FAIL: NDCG {val_ndcg:.4f} below threshold {threshold:.4f}")
return False
print(f"PASS: NDCG {val_ndcg:.4f} meets threshold {threshold:.4f}")
return True
if __name__ == "__main__":
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--model-name", required=True)
parser.add_argument("--alias", default="challenger")
parser.add_argument("--threshold", type=float, default=0.80)
args = parser.parse_args()
if not validate_model(args.model_name, args.alias, args.threshold):
sys.exit(1)
多租户配置
当有多个团队、需要隔离实验数据时,可以按下面的方式配置 MLflow 的多租户。
启用认证
MLflow 2.x 起内置了基础认证功能。
# 启动带认证的服务器
mlflow server \
--backend-store-uri postgresql://mlflow:${DB_PASSWORD}@db:5432/mlflow \
--default-artifact-root s3://mlflow-artifacts/ \
--app-name basic-auth \
--host 0.0.0.0 \
--port 5000
按团队隔离策略
需要完全的数据隔离时,与其为每个团队单独运维一套 MLflow 实例,不如通过实验命名和权限实现逻辑隔离,这在运维成本上更划算。
# 用团队前缀实现逻辑隔离
TEAM_PREFIX = {
"search": "/search-team",
"fraud": "/fraud-team",
"recommendation": "/rec-team",
}
def get_experiment_name(team: str, project: str, experiment: str) -> str:
"""生成包含团队前缀的实验名称。"""
prefix = TEAM_PREFIX.get(team)
if prefix is None:
raise ValueError(f"Unknown team: {team}. Allowed: {list(TEAM_PREFIX.keys())}")
return f"{prefix}/{project}/{experiment}"
# 使用示例
experiment = get_experiment_name("search", "query-ranking", "bert-v4-sweep")
mlflow.set_experiment(experiment) # "/search-team/query-ranking/bert-v4-sweep"
大规模组织中,善用 MLflow 3.x 的 Multi-Workspace 功能,可以在单一追踪服务器上实现工作区级别的实验/模型/prompt 隔离。
Artifact 管理与成本优化
Artifact 清理自动化
实验一旦累积,Artifact 存储成本就会快速增加。超参数搜索生成数百到数千个模型 checkpoint 的场景尤其严重。
from mlflow import MlflowClient
from datetime import datetime, timedelta
def cleanup_old_runs(experiment_name: str, days_old: int = 90, dry_run: bool = True):
"""清理超过指定期限的失败/取消 run 的 Artifact。"""
client = MlflowClient()
experiment = client.get_experiment_by_name(experiment_name)
if experiment is None:
print(f"Experiment '{experiment_name}' not found")
return
cutoff_ts = int((datetime.now() - timedelta(days=days_old)).timestamp() * 1000)
runs = client.search_runs(
experiment_ids=[experiment.experiment_id],
filter_string=f"attributes.end_time < {cutoff_ts} AND attributes.status != 'RUNNING'",
order_by=["attributes.end_time ASC"],
max_results=500,
)
deleted_count = 0
for run in runs:
# 用标签确认是否需要保留
if run.data.tags.get("keep", "false").lower() == "true":
continue
# 跳过已在注册表中登记的模型对应的 run
if run.data.tags.get("mlflow.registeredModelName"):
continue
if dry_run:
print(f"[DRY RUN] Would delete run {run.info.run_id} "
f"(ended: {datetime.fromtimestamp(run.info.end_time / 1000)})")
else:
client.delete_run(run.info.run_id)
deleted_count += 1
print(f"{'Would delete' if dry_run else 'Deleted'} {deleted_count} runs "
f"out of {len(runs)} found")
# 使用方式:先用 dry_run 确认,再实际删除
cleanup_old_runs("/search-team/query-ranking/bert-finetune", days_old=60, dry_run=True)
S3 生命周期策略
除了 MLflow 的 Artifact 清理之外,还可以在 S3 存储桶层面设置生命周期策略,进一步降低成本。
{
"Rules": [
{
"ID": "MoveOldArtifactsToIA",
"Status": "Enabled",
"Filter": {
"Prefix": "prod/"
},
"Transitions": [
{
"Days": 90,
"StorageClass": "STANDARD_IA"
},
{
"Days": 365,
"StorageClass": "GLACIER"
}
]
},
{
"ID": "DeleteTempArtifacts",
"Status": "Enabled",
"Filter": {
"Prefix": "tmp/"
},
"Expiration": {
"Days": 7
}
}
]
}
故障排查:常见的运维故障
1. 数据库连接池耗尽
症状:大量实验同时运行时出现 OperationalError: too many connections。
原因:MLflow 服务器默认的 SQLAlchemy 连接池大小(5)不够用。
解决方法:
# 启动服务器时调整连接池参数
mlflow server \
--backend-store-uri "postgresql://mlflow:pass@db:5432/mlflow?pool_size=20&max_overflow=40" \
--default-artifact-root s3://artifacts/ \
--workers 8
2. Artifact 上传超时
症状:记录大体积模型(数 GB)时出现 ConnectionError 或超时。
解决方法:
# 延长上传超时时间
export MLFLOW_ARTIFACT_UPLOAD_DOWNLOAD_TIMEOUT=600
# 调整 multipart upload 分块大小(S3)
export MLFLOW_S3_UPLOAD_EXTRA_ARGS='{"ServerSideEncryption": "aws:kms"}'
3. run 状态永久卡在 RUNNING
症状:训练进程已经死掉,但 MLflow UI 中对应 run 一直显示 "Running" 状态。
解决方法:
from mlflow import MlflowClient
client = MlflowClient()
# 强制终止卡住的 run
stuck_runs = client.search_runs(
experiment_ids=["1"],
filter_string="attributes.status = 'RUNNING'",
)
for run in stuck_runs:
end_time = run.info.end_time
# 没有 end_time 且开始时间已超过 24 小时的情况
if end_time is None or end_time == 0:
start_time = run.info.start_time
if (datetime.now().timestamp() * 1000 - start_time) > 86400000: # 24h
client.set_terminated(run.info.run_id, status="FAILED")
print(f"Force-terminated stuck run: {run.info.run_id}")
4. Model Registry alias 冲突
症状:两个 CI 流水线同时尝试设置同一个 alias。
解决方法:在设置 alias 之前先确认当前 alias 状态,并使用分布式锁(distributed lock)。基于 Redis 的锁是最简单的方式。
import redis
import time
def safe_promote_model(model_name: str, version: str, alias: str, redis_url: str):
"""使用分布式锁的安全模型晋升。"""
r = redis.from_url(redis_url)
lock_key = f"mlflow:promote:{model_name}:{alias}"
# 获取 TTL 为 30 秒的分布式锁
lock = r.lock(lock_key, timeout=30)
if lock.acquire(blocking=True, blocking_timeout=10):
try:
client = MlflowClient()
client.set_registered_model_alias(model_name, alias, version)
print(f"Successfully promoted {model_name} v{version} to @{alias}")
finally:
lock.release()
else:
raise RuntimeError(f"Failed to acquire lock for {model_name}@{alias}")
5. PostgreSQL 磁盘写满
症状:出现 DiskFull 错误,指标记录失败。
解决方法:MLflow 把指标存成一行行独立记录,step 级别的日志记录一多,数据库就会快速膨胀。要定期删除旧 run,并执行 VACUUM FULL。同时也要适当调整指标记录周期(不要每个 step 都记录,而是按 100 step 为单位记录)。
运维检查清单
运维生产级 MLflow 时,应当定期检查以下项目。
初始设置检查清单
- 完成 PostgreSQL/MySQL 后端存储配置
- 完成 S3/GCS Artifact 存储配置和 IAM 权限设置
- 配置追踪服务器高可用(HA)(负载均衡器 + 多个 worker)
- 启用认证(
--app-name basic-auth) - 配置 TLS 终止(termination)(前置 Nginx/ALB)
- 实验命名规范文档化并同步给团队
- 就 Model Registry 命名规范达成一致
每周运维检查清单
- 监控 Artifact 存储容量(设置阈值告警)
- 确认数据库磁盘使用量
- 清理卡住的(RUNNING 状态)run
- 执行失败 run 的 Artifact 清理脚本
- 确认追踪服务器响应时间(保持 P95 在 500ms 以下)
每月运维检查清单
- S3/GCS 成本分析与生命周期策略复查
- 数据库性能分析(检查慢查询、优化索引)
- 清理 Model Registry 中未使用的模型
- 复查 MLflow 版本升级
- 测试备份/恢复流程
回滚与故障恢复流程
模型回滚
生产模型出现问题时,立即回滚到之前版本的流程。
from mlflow import MlflowClient
def rollback_model(model_name: str):
"""把 champion 模型回滚为 previous-champion。"""
client = MlflowClient()
try:
previous = client.get_model_version_by_alias(model_name, "previous-champion")
except Exception:
print("ERROR: No previous-champion alias found. Manual intervention required.")
return False
current = client.get_model_version_by_alias(model_name, "champion")
# 执行回滚
client.set_registered_model_alias(model_name, "champion", previous.version)
client.set_registered_model_alias(model_name, "rolled-back", current.version)
# 标记回滚原因
client.set_model_version_tag(
model_name, current.version, "rollback_reason", "performance_degradation"
)
client.set_model_version_tag(
model_name, current.version, "rolled_back_at", datetime.now().isoformat()
)
print(f"Rolled back {model_name}: v{current.version} -> v{previous.version}")
return True
数据库恢复
PostgreSQL 后端发生故障时,按以下顺序恢复。
- 从最新的数据库快照恢复
- 重启 MLflow 服务器,确认 Artifact 存储一致性
- 用
mlflow gc命令清理孤儿(orphan)Artifact 引用 - 确认注册表的 champion alias 指向正确的模型版本
# Artifact 垃圾回收
mlflow gc \
--backend-store-uri postgresql://mlflow:pass@db:5432/mlflow \
--older-than 30d
从 MLflow 2.x 迁移到 3.x 的要点
MLflow 3.0(2025 年年中发布)把重点放在了 GenAI 与 AI Agent 支持上。现有 2.x 用户需要注意以下几点:
-
Model Registry 扩展:3.x 中,代码版本、prompt 配置、评估 run、部署元数据都会关联到模型上。与现有 2.x 注册表向下兼容。
-
新增 Tracing 功能:通过
mlflow-tracingSDK,可以在生产环境中以最小依赖为代码/模型/Agent 添加埋点(instrumentation)。 -
search_logged_models() API:可以用类 SQL 语法,跨全部实验按性能指标、参数、模型属性进行检索。
-
LLM 成本追踪:新增从 LLM span 中自动提取模型信息并计算成本的功能。
-
UI 改进:新增了面向 GenAI 应用与 Agent 开发者的侧边栏,同时继续支持既有的模型训练工作流。
从 2.x 升级到 3.x 时,必须执行数据库迁移脚本(
mlflow db upgrade),并在升级前确保已备份数据库。
结语
MLflow 2.x 的实验追踪与模型注册表,安装本身很容易,但要运维到生产级别,就必须系统性地做好架构设计、命名规范、Artifact 管理、CI/CD 集成、多租户、监控、回滚流程。尤其是 Artifact 存储成本管理与数据库性能优化,如果不从运维初期就纳入设计,日后就会变成沉重的技术债。
核心原则总结如下。
- 实验名称按层级命名,并用标签留下丰富的元数据。
- 模型名称以产品为中心,版本与算法交给注册表和标签去管理。
- 用基于 Alias 的部署实现模型的无停机替换。
- 在 CI/CD 流水线中把训练-验证-晋升自动化。
- 不把 Artifact 清理自动化,S3 账单每个月都会让人心惊。
参考资料
- MLflow Tracking 官方文档
- MLflow Model Registry 官方文档
- MLflow Artifact Stores 配置指南
- MLflow Model Registry Workflows
- MLflow Self-Hosting Troubleshooting
- MLflow Releases
- MLflow GitHub Repository
- MLflow Model Serving 官方文档
测验
Q1:《MLflow 2.x 实验追踪与模型注册表运维指南》主要讨论的内容是什么?
从 MLflow 2.x 的实验追踪设计到模型注册表运维、Artifact 管理、CI/CD 集成、多租户、生产部署的实战指南。
Q2:为什么需要 MLflow 2.x 运维指南?
MLflow 每月下载量超过 1,400 万次,已经成为开源实验追踪工具事实上的标准。安装它、调用一行
mlflow.autolog(),都不难。问题出在这之后。
Q3:请说明架构设计:追踪服务器与 Artifact 存储分离。
核心组成 MLflow 生产架构应当分离为三层。Tracking Server:存储实验元数据(参数、指标、标签)。使用 PostgreSQL 或 MySQL 后端。Artifact Store:存储模型二进制文件、数据集、可视化文件。
Q4:请说明实验追踪设计模式。
实验命名策略 实验名称使用 /team/project/experiment-type 模式。实验数量一旦超过 100
个,扁平命名就会变得无法管理。标签体系设计 标签是实验检索与治理的核心。
Q5:Model Registry 运维策略是如何运作的?
模型命名规则 模型名称应当以产品为中心来命名。版本号或算法名称不要包含在模型名称中。版本号由注册表自动管理。算法变更通过标签或描述(description)来追踪。