LLM实验可复现性：SageMaker Pipelines与MLflow协同实践

1. 项目概述：当大模型实验撞上工程化瓶颈，我们到底在解决什么问题？

你有没有经历过这样的场景：凌晨两点，盯着 Jupyter Notebook 里第 17 个model.fit()运行日志，心里却没底——这个超参组合到底是不是最优？昨天跑出来的 AUC 是 0.823，今天换了个随机种子就掉到 0.791，该信哪个？更糟的是，同事小张说他本地复现不了你的结果，而你翻遍.ipynb文件也找不到他用的到底是transformers==4.35.0还是4.36.2。这不是个别现象，而是当前绝大多数 LLM 实验团队的真实日常。Scaling LLM Experimentation with SageMaker Pipelines and MLflow这个项目标题，表面看是两个工具的组合技，但内核直指一个被严重低估的工程痛点：LLM 实验的不可复现性、不可追踪性与不可规模化。它不教你如何设计新架构，也不讲怎么调出 SOTA 指标，而是聚焦在“如何让每一次实验都像工厂流水线上的零件一样，可登记、可回溯、可对比、可重跑”。核心关键词——SageMaker Pipelines（定义可复用、可调度的端到端训练/评估/部署工作流）、MLflow（统一记录参数、指标、模型、代码快照与依赖环境）——共同构成了一套面向生产级 LLM 研发的“实验操作系统”。它适合三类人：一是刚从学术界转入工业界的算法工程师，还在用git commit -m "try lr=5e-5"管理实验；二是带 3–5 人小团队的技术负责人，正被成员间模型版本混乱、评估标准不一的问题拖慢迭代节奏；三是 MLOps 工程师，手头已有 SageMaker 基础设施，但缺乏一套轻量、可嵌入现有流程的 LLM 实验治理方案。这不是一个“锦上添花”的优化项，而是当你的实验从每周 2 次增长到每天 20 次时，唯一能防止团队陷入混沌的技术护栏。

2. 整体架构设计：为什么必须是 Pipeline + MLflow 的组合，而不是单点工具？

2.1 单点工具的致命短板：为什么只用 MLflow 或只用 Pipelines 都走不远

很多团队初期会尝试“打补丁式”改进：比如先上 MLflow，把所有mlflow.log_param()和mlflow.log_metric()塞进 notebook；或者直接用 SageMaker Pipelines 写一个训练 pipeline，把数据预处理、模型训练、评估打包成一个 DAG。这两种做法短期内都能看到效果，但很快就会触达天花板。我亲身经历过的三个典型崩塌时刻，足以说明问题：

• 时刻一：MLflow 单点记录的“断层”
  团队在 notebook 里用 MLflow 记录了 200+ 次实验，参数、指标、模型 artifact 全都有。但某天要复现一个 3 个月前的 SOTA 结果时，发现requirements.txt里只写了torch>=2.0，实际运行时 pip 安装了2.1.2，而那个最佳模型恰恰依赖2.0.1的某个 CUDA kernel 行为。MLflow 能存代码快照（mlflow.log_artifact("train.py")），但它不强制捕获运行时环境。你得手动conda env export > environment.yml并再 log 一次，而这个动作在快速迭代中极易遗漏。更麻烦的是，MLflow 的run_id是随机字符串，和 Git commit hash 没有绑定，当你想查“commita1b2c3d对应哪次 run”时，得靠人工在 UI 里翻找或写脚本关联，效率极低。

• 时刻二：Pipelines 的“黑盒化”陷阱
  另一个团队用 Pipelines 构建了完美的训练 pipeline：PreprocessStep → TrainStep → EvaluateStep → RegisterModelStep。每次pipeline.start()都生成一个清晰的 execution ID，日志集中管理，失败自动告警。听起来很美？问题出在TrainStep内部。他们把整个训练逻辑封装在一个train.py脚本里，而这个脚本里又硬编码了--learning_rate=2e-5 --num_train_epochs=3。当需要快速对比2e-5和3e-5时，必须修改代码、提交新 commit、更新 pipeline definition、重新部署——整个过程耗时 15 分钟以上。Pipelines 擅长管理步骤间的依赖与调度，但对步骤内部的超参敏感度与快速迭代支持极弱。它把实验变成了“发布流程”，而不是“探索流程”。

• 时刻三：两者割裂导致的“双系统运维”
  最常见的情况是：算法同学在本地用 MLflow 做快速试错，记录一堆run_id；MLOps 同学则用 Pipelines 在云端跑正式训练，产出execution_id。两个系统完全独立，没有 ID 映射，没有元数据同步。当业务方问“线上模型 A 对应的是哪次实验？”时，答案往往是：“我查下 Pipelines execution 日志……哦，它调用了train.py版本 v1.2.3，那对应的 MLflow run 应该是……大概在 3 月 15 号左右？”——这种模糊匹配，在模型审计或故障回溯时就是灾难。

提示：Pipeline 和 MLflow 不是“功能重叠”的竞品，而是“职责互补”的搭档。Pipeline 是实验的骨架（定义谁先谁后、谁依赖谁、谁触发谁），MLflow 是实验的血肉（记录每一次心跳、每一次呼吸、每一次微小的参数抖动）。拆开用，骨架没血肉是骷髅，血肉没骨架是瘫痪。

2.2 组合架构的核心设计哲学：以“可重现的最小单元”为原子

我们最终落地的架构，并非简单地把 MLflow client 嵌入 Pipeline Step，而是围绕一个核心理念重构：每一次 Pipeline Execution，必须对应且仅对应一次 MLflow Run；每一次 Run 的生命周期，必须由 Pipeline Step 的执行严格控制。这意味着：

• Pipeline Step 是 MLflow Run 的“启动器”与“终结者”：每个 Step（如TrainStep）在开始时调用mlflow.start_run()，并传入run_name=f"train_{execution_id}"；在成功结束时调用mlflow.end_run()；若 Step 失败，则mlflow.end_run(status="FAILED")。这样，execution_id 和 run_id 就天然绑定，无需人工映射。

• 超参注入不再是代码修改，而是 Pipeline Parameter：Pipeline 定义中声明ParameterString(name="learning_rate", default_value="2e-5")，在TrainStep的processor或estimator启动命令中，通过--learning-rate {learning_rate}注入。MLflow 在train.py中直接读取命令行参数并log_param("learning_rate", args.learning_rate)。改一个超参？只需在 Pipeline 启动时传入新值，无需改代码、无需新 commit。

• 环境固化不是“尽力而为”，而是“强制锁定”：TrainStep使用的 SageMaker Processing Job 或 Training Job，其容器镜像必须是预构建、带完整依赖的确定性镜像（如my-llm-train:py39-torch201-cu118），而非pytorch-training:2.0.1-cpu-py39这类可能随时间漂移的官方镜像。MLflow 的log_env功能在此只是补充，真正的环境保障来自镜像本身。

• 数据与模型版本化，由 Pipeline Input/Output 承载：Pipeline 的ProcessingInput指向 S3 上带版本号的数据集（如s3://my-bucket/datasets/llm-finetune-v2.1/），TrainingInput同理；ModelStep的输出模型也存入s3://my-bucket/models/llm-finetune/{execution_id}/。MLflow 的log_model()只负责将模型 artifact 存入其 tracking server，而真实可信的数据与模型来源，永远是 Pipeline 定义中明确指定的 S3 URI。这解决了“MLflow model registry 里的模型，到底用的是哪份数据训练的？”这一根本问题。

这套设计看似增加了前期配置成本，但换来的是实验治理的“确定性”。当新同学入职，他不需要去理解团队私有的命名规范或笔记习惯，只要看 Pipeline Definition 和 MLflow UI，就能在 5 分钟内搞清：过去一周所有 LLM 微调实验的输入数据版本、超参组合、评估结果、以及如何一键重跑任意一次。

3. 核心细节解析：从零搭建一个可复用的 LLM 微调 Pipeline

3.1 基础环境准备：SageMaker Studio 与 MLflow Tracking Server 的协同配置

在动手写 Pipeline 之前，必须确保两个基础设施“握手成功”。这不是简单的“安装包”问题，而是关于网络连通性、权限策略与默认行为对齐的实操细节。我见过太多团队卡在这一步，反复调试数小时。

首先，MLflow Tracking Server 的部署方式选择。官方文档推荐用 EC2 或 ECS，但对 SageMaker 用户，最省心且安全的方式是：在 SageMaker Studio Domain 内，启动一个专用的mlflow-serverLifecycle Configuration (LC) 并绑定到System或User空间。具体操作如下：

1. 创建一个 LC 脚本install-mlflow-server.sh：

#!/bin/bash set -e # 安装 mlflow 和依赖 pip install mlflow==2.12.1 gunicorn==21.2.0 # 创建 mlflow 数据目录（使用 EFS，确保跨 session 持久化） mkdir -p /home/sagemaker-user/mlflow-data # 创建启动脚本 cat > /home/sagemaker-user/start-mlflow.sh << 'EOF' #!/bin/bash mlflow server \ --backend-store-uri file:///home/sagemaker-user/mlflow-data \ --default-artifact-root s3://my-mlflow-bucket/artifacts \ --host 0.0.0.0 \ --port 5000 \ --gunicorn-opts "--timeout 120 --workers 4" EOF chmod +x /home/sagemaker-user/start-mlflow.sh # 设置开机自启（Studio Session 启动时） echo "/home/sagemaker-user/start-mlflow.sh &" >> /etc/rc.local

2. 将此 LC 关联到 Studio Domain 的DefaultUserSettings，并确保 Studio Execution Role 具有s3:GetObject,s3:PutObject权限（针对my-mlflow-bucket）以及ecr:GetAuthorizationToken（如果后续要用自定义 ECR 镜像）。

注意：不要用mlflow ui命令在 notebook 中启动！它默认绑定127.0.0.1:5000，Studio 内部无法访问。必须用--host 0.0.0.0并配合 Gunicorn。另外，--backend-store-uri用file://是为了简化，生产环境建议用 RDS PostgreSQL，但file://对于中小团队已足够稳定。

其次，SageMaker Studio 内 MLflow Client 的初始化。在 notebook 中，不能简单import mlflow; mlflow.set_tracking_uri("http://localhost:5000")。因为 Studio 的 notebook kernel 和 mlflow server 运行在不同容器中，localhost指向 kernel 自身。正确做法是：

import mlflow from sagemaker.s3 import S3Downloader # 获取 mlflow server 在 Studio 内网的 DNS 名称（关键！） # Studio Domain 的 VPC 内，mlflow server 会注册为 <domain-id>.studio.<region>.sagemaker.aws # 但更可靠的方式是：在 LC 中写入一个环境变量 import os mlflow_uri = os.getenv("MLFLOW_TRACKING_URI", "http://mlflow-server:5000") mlflow.set_tracking_uri(mlflow_uri) # 验证连通性 try: mlflow.list_experiments() print(f"✅ MLflow server connected at {mlflow_uri}") except Exception as e: print(f"❌ Failed to connect to MLflow: {e}") # 此处可添加 fallback 逻辑，如打印 debug 信息

最后，IAM 权限的“最小必要”原则。很多团队直接给 Studio Execution Role 加AdministratorAccess，这是安全隐患。实际只需以下策略：

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::my-mlflow-bucket/*", "arn:aws:s3:::my-mlflow-bucket", "arn:aws:s3:::my-dataset-bucket/*", "arn:aws:s3:::my-model-bucket/*" ] }, { "Effect": "Allow", "Action": [ "sagemaker:CreatePipeline", "sagemaker:StartPipelineExecution", "sagemaker:DescribePipelineExecution", "sagemaker:ListPipelineExecutions" ], "Resource": "*" } ] }

特别注意：s3:ListBucket权限必须显式授予my-mlflow-bucket，否则 MLflow server 无法列出 artifacts 目录，UI 会报 403 错误。这个细节，官方文档没写，但踩过坑的人都懂。

3.2 Pipeline Definition 编写：从抽象概念到可执行代码

一个健壮的 LLM 微调 Pipeline，绝不是把train.py包裹一层就完事。它必须包含数据准备、模型加载、训练、评估、模型注册五个核心环节，且每个环节都需考虑 LLM 场景的特殊性。下面以 LoRA 微调 Llama-2-7b 为例，展示关键代码片段与设计理由。

3.2.1 Pipeline 参数化：让超参成为“第一公民”

from sagemaker.workflow.parameters import ( ParameterInteger, ParameterString, ParameterFloat, ) # 定义 Pipeline 全局参数（这些将成为启动时的输入） base_job_prefix = ParameterString( name="BaseJobPrefix", default_value="llm-finetune" ) # LLM 特定参数：模型 ID、LoRA 配置、数据路径 model_id = ParameterString( name="ModelId", default_value="meta-llama/Llama-2-7b-hf" ) lora_r = ParameterInteger( name="LoraR", default_value=8 ) lora_alpha = ParameterInteger( name="LoraAlpha", default_value=16 ) lora_dropout = ParameterFloat( name="LoraDropout", default_value=0.1 ) # 数据参数：S3 URI 必须带版本，避免“最新数据”带来的不可控 train_data_uri = ParameterString( name="TrainDataUri", default_value="s3://my-bucket/datasets/llm-finetune-v2.1/train/" ) eval_data_uri = ParameterString( name="EvalDataUri", default_value="s3://my-bucket/datasets/llm-finetune-v2.1/eval/" ) # 训练参数：batch size, learning rate, epochs —— 这些是算法同学最常调的 per_device_train_batch_size = ParameterInteger( name="PerDeviceTrainBatchSize", default_value=4 ) learning_rate = ParameterFloat( name="LearningRate", default_value=2e-5 ) num_train_epochs = ParameterInteger( name="NumTrainEpochs", default_value=3 )

实操心得：为什么TrainDataUri和EvalDataUri是ParameterString而不是硬编码？因为数据版本迭代比模型代码快得多。上周用v2.1，这周可能就上线了修复标注错误的v2.2。把数据 URI 参数化，意味着一次 Pipeline 更新，就能覆盖所有数据版本的实验，无需修改任何 Python 代码。这是工程化思维与科研思维的关键分水岭。

3.2.2 Data Processing Step：不只是格式转换，更是数据质量门禁

LLM 微调的数据质量，直接决定模型上限。一个合格的ProcessingStep，必须包含数据验证逻辑，而不仅是pandas.read_json() → save_parquet()。

from sagemaker.sklearn.processing import SKLearnProcessor from sagemaker.processing import ProcessingInput, ProcessingOutput # 使用自定义镜像，内置了 fastparquet, datasets, transformers sklearn_processor = SKLearnProcessor( framework_version="1.0-1", role=role, instance_type="ml.m5.xlarge", instance_count=1, base_job_name=f"{base_job_prefix}-preprocess", image_uri="123456789012.dkr.ecr.us-east-1.amazonaws.com/my-llm-preprocess:latest" ) # 输入：原始 JSONL（每行一个 {"instruction": "...", "input": "...", "output": "..."}） # 输出：Hugging Face Dataset 格式的 parquet（支持 streaming, caching） processing_step = ProcessingStep( name="PreprocessData", processor=sklearn_processor, inputs=[ ProcessingInput( source=train_data_uri, destination="/opt/ml/processing/input/train" ), ProcessingInput( source=eval_data_uri, destination="/opt/ml/processing/input/eval" ) ], outputs=[ ProcessingOutput( output_name="train_dataset", source="/opt/ml/processing/output/train", destination=Join( on="/", values=[ "s3:/", bucket, prefix, "datasets", "processed", "train", ExecutionVariables.PIPELINE_EXECUTION_ID ] ) ), ProcessingOutput( output_name="eval_dataset", source="/opt/ml/processing/output/eval", destination=Join( on="/", values=[ "s3:/", bucket, prefix, "datasets", "processed", "eval", ExecutionVariables.PIPELINE_EXECUTION_ID ] ) ) ], code="preprocess.py", # 此脚本在镜像中 job_arguments=[ "--train-input-dir", "/opt/ml/processing/input/train", "--eval-input-dir", "/opt/ml/processing/input/eval", "--output-dir", "/opt/ml/processing/output", "--max-seq-length", "1024", "--min-output-length", "10", # 过滤掉太短的 output，避免噪声 "--deduplicate", "True" # 基于 instruction+input 的哈希去重 ] )

preprocess.py的核心逻辑（简略）：

def validate_and_clean_dataset(dataset): """LLM 数据清洗的黄金法则""" # 规则1：过滤掉 output 长度 < 10 的样本（可能是标注错误或占位符） dataset = dataset.filter(lambda x: len(x["output"]) >= 10) # 规则2：检查 instruction 是否为空或全是空格 dataset = dataset.filter(lambda x: x["instruction"].strip() != "") # 规则3：基于 content hash 去重（避免同一问题重复出现） hashes = [] for sample in dataset: h = hashlib.md5((sample["instruction"] + sample["input"]).encode()).hexdigest() if h not in hashes: hashes.append(h) else: continue # skip duplicate return dataset # 关键：在处理结束时，将数据统计写入 MLflow if __name__ == "__main__": mlflow.start_run(run_name=f"preprocess_{os.getenv('PIPELINE_EXECUTION_ID')}") mlflow.log_param("input_train_uri", args.train_input_dir) mlflow.log_param("input_eval_uri", args.eval_input_dir) train_ds = load_dataset("json", data_files=f"{args.train_input_dir}/*.jsonl") train_ds = validate_and_clean_dataset(train_ds) train_ds.to_parquet(f"{args.output_dir}/train/dataset.parquet") # 记录清洗后的关键指标 mlflow.log_metric("train_samples_after_clean", len(train_ds)) mlflow.log_metric("eval_samples_after_clean", len(eval_ds)) mlflow.log_artifact("preprocess_report.json") # 生成详细报告 mlflow.end_run()

注意：ProcessingStep的输出 S3 URI 中嵌入了ExecutionVariables.PIPELINE_EXECUTION_ID，这保证了每次 Pipeline 执行产生的数据都是隔离的，不会被后续执行覆盖。这是实现“可重现”的基石。

3.2.3 Training Step：将 MLflow 深度融入训练循环

这是整个 Pipeline 的心脏。我们使用 SageMaker Training Job（而非 Processing Job），因为它原生支持分布式训练和 GPU 优化。

from sagemaker.pytorch import PyTorch # 使用预构建的、带完整依赖的 ECR 镜像 estimator = PyTorch( entry_point="train.py", source_dir="src", # 包含 train.py, requirements.txt, utils/ role=role, instance_count=2, # 2x g4dn.12xlarge for Llama-2-7b LoRA instance_type="ml.g4dn.12xlarge", volume_size=200, max_run=3600 * 24, # 24 hours py_version="py39", framework_version="2.0.1", hyperparameters={ "model_id": model_id, "lora_r": lora_r, "lora_alpha": lora_alpha, "lora_dropout": lora_dropout, "per_device_train_batch_size": per_device_train_batch_size, "learning_rate": learning_rate, "num_train_epochs": num_train_epochs, "output_dir": "/opt/ml/model", # SageMaker 默认模型输出路径 }, # 关键：启用 MLflow 自动日志（需在 train.py 中初始化） environment={ "MLFLOW_TRACKING_URI": mlflow_uri, "MLFLOW_EXPERIMENT_NAME": "llm-finetune-experiment" } ) training_step = TrainingStep( name="TrainLLM", estimator=estimator, inputs={ "train": TrainingInput( s3_data=processing_step.properties.ProcessingOutputConfig.Outputs["train_dataset"].S3Output.S3Uri, content_type="application/x-parquet" ), "eval": TrainingInput( s3_data=processing_step.properties.ProcessingOutputConfig.Outputs["eval_dataset"].S3Output.S3Uri, content_type="application/x-parquet" ) } )

train.py的核心结构（重点看 MLflow 集成）：

import mlflow import torch from transformers import AutoModelForCausalLM, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model def main(): # 1. 解析 SageMaker 传入的超参 parser = argparse.ArgumentParser() parser.add_argument("--model_id", type=str) parser.add_argument("--lora_r", type=int) parser.add_argument("--lora_alpha", type=int) parser.add_argument("--lora_dropout", type=float) # ... 其他参数 args = parser.parse_args() # 2. 初始化 MLflow Run —— 必须在 Trainer 创建前！ # SageMaker 会自动设置 JOB_NAME 和 TRAINING_JOB_ARN run_name = f"train-{os.getenv('JOB_NAME', 'unknown')}" mlflow.start_run(run_name=run_name) # 3. 记录所有超参（包括 SageMaker 自动注入的） for k, v in vars(args).items(): mlflow.log_param(k, v) mlflow.log_param("sagemaker_job_arn", os.getenv("TRAINING_JOB_ARN")) # 4. 加载基础模型和 LoRA 配置 model = AutoModelForCausalLM.from_pretrained(args.model_id) peft_config = LoraConfig( r=args.lora_r, lora_alpha=args.lora_alpha, lora_dropout=args.lora_dropout, target_modules=["q_proj", "v_proj"], # Llama-2 的关键模块 ) model = get_peft_model(model, peft_config) # 5. 创建 Trainer，并启用 MLflow 自动日志（关键！） training_args = TrainingArguments( output_dir=args.output_dir, per_device_train_batch_size=args.per_device_train_batch_size, learning_rate=args.learning_rate, num_train_epochs=args.num_train_epochs, # 启用 MLflow 回调 report_to="mlflow", run_name=run_name, # 其他必要参数... ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, eval_dataset=eval_dataset, # MLflow 回调会自动记录 metrics, params, model ) # 6. 开始训练 trainer.train() # 7. 训练结束后，手动记录一些关键指标 eval_results = trainer.evaluate() for k, v in eval_results.items(): mlflow.log_metric(f"eval_{k}", v) # 8. 保存 LoRA adapter（不是整个模型！） model.save_pretrained(f"{args.output_dir}/lora-adapter") mlflow.log_artifact(f"{args.output_dir}/lora-adapter") # 9. 结束 Run mlflow.end_run() if __name__ == "__main__": main()

实操心得：report_to="mlflow"是 Hugging Face Transformers 的原生集成，它会自动记录loss,learning_rate,epoch等指标。但它不会记录你自定义的评估指标（如 custom_bleu_score）或模型结构信息。所以必须在trainer.evaluate()后，手动mlflow.log_metric()。另外，“保存 LoRA adapter” 而非整个模型，是为了体积和部署效率——一个完整的 Llama-2-7b 是 13GB，而 LoRA adapter 通常只有 20MB。

4. 实操过程详解：一次完整的 Pipeline 执行与结果分析

4.1 启动 Pipeline：从参数配置到 execution ID 生成

Pipeline 的启动，是整个实验流程的“发令枪”。它不像运行一个脚本那么简单，而是一次对实验意图的正式声明。我们以一次典型的 A/B 测试为例：对比 LoRA rankr=8和r=16对模型困惑度（Perplexity）的影响。

首先，在 SageMaker Studio notebook 中，实例化 Pipeline 并配置参数：

from sagemaker.workflow.pipeline import Pipeline # 创建 Pipeline 实例 llm_pipeline = Pipeline( name="LLM-Finetune-Pipeline", parameters=[ base_job_prefix, model_id, lora_r, lora_alpha, lora_dropout, train_data_uri, eval_data_uri, per_device_train_batch_size, learning_rate, num_train_epochs ], steps=[processing_step, training_step, evaluation_step, register_step], sagemaker_session=sagemaker_session ) # 启动第一次执行（r=8） execution_1 = llm_pipeline.start( parameters={ "BaseJobPrefix": "ab-test-r8", "ModelId": "meta-llama/Llama-2-7b-hf", "LoraR": 8, # 关键差异点 "LoraAlpha": 16, "LoraDropout": 0.1, "TrainDataUri": "s3://my-bucket/datasets/llm-finetune-v2.1/train/", "EvalDataUri": "s3://my-bucket/datasets/llm-finetune-v2.1/eval/", "PerDeviceTrainBatchSize": 4, "LearningRate": 2e-5, "NumTrainEpochs": 3 } ) print(f"✅ Pipeline Execution 1 started: {execution_1.arn}") print(f" Execution ID: {execution_1.execution_id}") # 输出类似：llm-finetune-pipeline-123456789012-us-east-1-abc123def456

几秒钟后，SageMaker 控制台会显示一个全新的 Pipeline Execution，状态为Executing。此时，后台发生了什么？

1. SageMaker 创建 Execution Context：为本次执行分配唯一的execution_id，并初始化所有Parameter的值。
2. ProcessingStep 启动：SageMaker 启动一个ml.m5.xlarge实例，拉取my-llm-preprocess:latest镜像，挂载输入 S3 数据，执行preprocess.py。该脚本内部调用mlflow.start_run(run_name=f"preprocess_{execution_id}")，在 MLflow UI 中创建一个名为preprocess-llm-finetune-pipeline-123456789012-us-east-1-abc123def456的 Run。
3. TrainingStep 启动：Processing 成功后，SageMaker 启动 2 个ml.g4dn.12xlarge实例，拉取训练镜像，挂载上一步输出的 processed data S3 URI，执行train.py。train.py中mlflow.start_run(run_name=f"train-{os.getenv('JOB_NAME')}")创建第二个 Run，名称为train-llm-finetune-pipeline-123456789012-us-east-1-abc123def456-00001（SageMaker 自动生成 JOB_NAME）。
4. Execution ID 与 Run ID 的映射关系：虽然 Run 名称不同，但它们的tags中都包含了sagemaker:execution-id: llm-finetune-pipeline-123456789012-us-east-1-abc123def456。这是我们在preprocess.py和train.py中主动添加的：

# 在 mlflow.start_run() 后 mlflow.set_tag("sagemaker:execution-id", os.getenv("PIPELINE_EXECUTION_ID", "unknown"))

这个 tag 是后续在 MLflow UI 中按 Execution ID 过滤所有相关 Runs 的唯一依据。

提示：不要依赖 Run Name 的字符串匹配！因为JOB_NAME可能包含-00001后缀，而PIPELINE_EXECUTION_ID是纯净的。tag 是结构化、可编程查询的，Name 是给人看的。

4.2 结果分析：如何在 MLflow UI 中进行多维对比

当 Pipeline 执行完毕（假设成功），打开 MLflow UI，你会看到至少两个 Runs（preprocess 和 train），它们都带有相同的sagemaker:execution-idtag。点击左侧Experiments，进入llm-finetune-experiment，然后使用右上角的搜索框：

tags."sagemaker:execution-id" = "llm-finetune-pipeline-123456789012-us-east-1-abc123def456"

这会筛选出本次执行的所有 Runs。现在，进行关键的 A/B 分析：

4.2.1 超参对比：确认实验变量唯一性

在 Runs 列表页，勾选preprocess-xxx和train-xxx两个 Run，点击Compare。在Parameters标签页，你会看到：

这立刻证明：lora_r=8是本次实验中唯一被改变的变量，其他所有参数（包括数据 URI）都保持一致。这是科学实验的铁律。

4.2.2 指标对比：量化 rank 对性能的影响

切换到Metrics标签页，重点关注eval_perplexity（评估集困惑度，越低越好）：

eval_perplexity=12.34是核心结果。但别急着下结论，再启动第二次 Pipeline Execution，将LoraR改为16：

execution_2 = llm_pipeline.start( parameters={ "BaseJobPrefix": "ab-test-r16", "LoraR": 16, # 唯一变化 # ... 其他参数完全相同 } )

等execution_2完成后，再次在 MLflow UI 中搜索：

tags."sagemaker:execution-id" = "llm-finetune-pipeline-123456789012-us-east-1-xyz789uvw012"

得到eval_perplexity=11.92。对比：

一个看似微小的-0.42，在 LLM 领域可能意味着生成质量的显著提升。更重要的是，这个对比是在完全相同的数据、相同的代码、相同的硬件、相同的随机种子（我们在TrainingArguments中设置了seed=42）下完成的。这就是 Pipeline + MLflow 组合带来的确定性。

4.2.