什么时候用
先判断任务是否合适
- 需要记录和对比数百次ML实验的参数、指标和产物
- 需要追踪LLM agent的多步推理轨迹和token消耗
- 需要给训练好的模型做版本管理、阶段标记和部署
- 需要统一管理多个LLM API的路由、限流和成本预算
先准备什么
材料越清楚,结果越有用
- •安装MLflow并启动Tracking Server(本地或远程)
- •在训练代码中插入几行MLflow logging代码记录参数和指标
- •如需LLM追踪,配置OpenTelemetry或启用MLflow的自动埋点
- •如有多个LLM提供商,在AI Gateway中配置路由和密钥
它会怎样推进
从材料到可以检查的结果
- 01
记录实验
在代码中用mlflow.log记录参数、指标和模型产物
- 02
对比Run
在MLflow UI中筛选、排序和可视化对比多次实验
- 03
注册模型
将最佳模型注册到Registry并标记阶段(Staging/Production)
- 04
追踪LLM
自动捕获agent的span树、token用量和推理延迟
- 05
部署服务
将注册模型一键部署为REST endpoint或Docker容器
第一次这样开始
把仓库地址直接交给 AI
先让 AI 说明环境和风险,再完成最小安装验证。跑通以后,再把自己的真实材料放进去。
第一次直接复制
帮我安装这个库:https://github.com/mlflow/mlflow 安装前先告诉我需要什么环境,安装后帮我跑通一个最小示例。
结果出来后
先看这些检查点
- 检查注册模型的版本和阶段标记是否与预期一致
- 验证LLM追踪中的span树是否完整覆盖了agent执行路径
- 确认AI Gateway的预算限额和限流规则是否在真实负载下正确生效
常见误区
这些判断仍由你负责
- 把实验记录当备份用而不同步管理训练数据和环境依赖
- 在LLM追踪中不做采样导致存储和成本远超预期
- 把Staging阶段的模型直接推Production而不做线上评估和灰度验证
技术依据
查看能力拆解、验证范围与来源
技术依据
查看能力拆解、验证范围与来源
- 01
AI网关与LLM路由治理
在多个 LLM provider(OpenAI/Anthropic/Gemini/Bedrock/...25 种)和 gateway(Databricks/LiteLLM/Vercel/OpenRouter/...)之上提供一层统一、OpenAI 兼容的路由网关,统一管理 credential、rate limit、fallback、成本预算(budget)、流量分流(A/B)与输入输出护栏(guardrail)。这是从"应用直连各家 API"到"统一可治理的 LLM 访问层"的转换。
- 02
LLM与agent轨迹追踪
把一次 LLM/agent 执行(含多次模型调用、工具调用、检索、子链路)的结构化轨迹(Trace)捕获下来,形成可回放、可评估、可关联到 Run 的树状执行记录。这是 mlflow 在 LLM 时代的核心观测能力,独立于传统 Run 记录。
- 03
实验跟踪与run状态管理
把一次模型训练/推理执行的"参数、指标、产物、标签、状态"沉淀成可检索、可对比、可复现的持久记录(Run),并按 Experiment 分组。这是 mlflow 最底层也最核心的能力:所有 genai/tracing/registry/evaluation 都建立在 Run 这条时间线之上。
- 04
模型打包与flavor体系
把一个训练好的模型(任意框架:sklearn/pytorch/tensorflow/langchain pipeline/custom)打包成一个自描述、可多 flavor 加载、可跨环境复用的标准产物(MLflow Model),并支持签名校验与统一加载。这是模型从"内存对象"变成"可注册、可部署、可评估"产物的转换。
| 能力 | 主要输入 | 主要输出 | 人工检查 |
|---|---|---|---|
AI网关与LLM路由治理源码已核对 |
|
|
|
LLM与agent轨迹追踪源码已核对 |
|
|
|
实验跟踪与run状态管理源码已核对 |
|
|
|
模型打包与flavor体系源码已核对 |
|
|
|
模型注册与版本生命周期源码已核对 |
|
|
|
模型评估与eval-run源码已核对 |
|
|
|
处理机制
- 01
store抽象与对象生命周期治理
解释 tracking/registry/artifact/tracing 四类能力的共同结构:mlflow 把每类能力都拆成"实体 + abstractstore + 多后端实现 + 异步刷新 + search 检索 + 软删除生命周期"的同构骨架。这个横切结构决定了为什么 Run/Trace/RegisteredModel/ModelVersion 的治理方式高度一致,以及为什么同一套概念能同时支撑 ML 与 LLM 两条产品线。
已核对范围
- 静态确认 gateway FastAPI app 的 OpenAI 兼容路由(/v1/chat/completions、/v1/completions、/v1/embeddings)
- 静态确认 25 个 provider 适配层(gateway/providers)
- 静态确认 budgettracker/budget 模块的成本聚合与 budgetexceeded webhook + trace 阻断
- 静态确认 guardrails(输入/输出护栏)与 rate limit/fallback/traffic-split 配置
- 静态确认 Trace/Span/TraceInfo/LiveSpan 实体与 SpanType(LLM/CHAIN/AGENT/TOOL/CHATMODEL/RETRIEVER/EMBEDDING/EVALUATOR)、TraceState(OK/ERROR/INPROGRESS) 枚举
- 静态确认 fluent trace 装饰器与 startspan 上下文、span 层级 parentid 链、span 权重 sampling 机制
- 静态确认 OpenTelemetry 导出路径(mlflow/tracing/otel)与 processor/destination 分层
- 静态确认 60+ 框架 autolog 式自动埋点(openai/anthropic/langchain/crewai/autogen/dspy 等)
仍待核对
- 未真实运行 gateway server
- 未验证 budget 在高并发下的准确性
- 未验证各 provider 的请求/响应兼容性与降级
- 未真实运行 tracing 捕获
- 未验证 sampling 比例在低 ratio 下的代表性偏差
- 未验证 trace 与 run 的 link 行为在并发 trace 下的边界
- 未真实运行 tracking server 与 client 的端到端记录
- 未验证异步日志(synchronous=False)在并发场景下的顺序与丢失边界
相关文章
具备相关能力的其他库
相关课程
把单项工具放进完整研究设计流程
课程一从研究问题、文献判断、理论假设和方法骨架继续推进,帮助你建立可以复用的研究设计档案。