企业官网建设流程全解析

1. 项目概述：当模型大到单卡装不下，数据多到单机跑不动时，你到底该“切模型”还是“切数据”？

“Machine Learning at Scale”——这个短语在今天已经不是什么新鲜概念，但真正把它从PPT落到训练集群的GPU显存里，中间隔着的不是几行代码，而是对计算本质的反复推演和无数次OOM（Out of Memory）报错后留下的黑眼圈。我带过三个超大规模推荐系统项目，最深的体会是：所谓“扩展性”，从来不是堆机器就能解决的工程问题，而是一道必须在“模型并行”和“数据并行”之间做精确权衡的物理题。标题里这个“v/s”，不是简单的二选一，而是两种截然不同的资源切割逻辑——前者把一个巨型模型像拆乐高一样切成若干块，分给不同设备各算一部分；后者把海量训练样本像分快递一样打包成小份，让每台设备各自前向+反向，最后再同步梯度。关键词“Model Parallelism”和“Data Parallelism”背后，藏着的是显存墙、通信瓶颈、收敛稳定性、硬件拓扑感知等一连串硬核约束。这篇文章不讲教科书定义，只讲我在真实千卡集群上踩过的坑、调过的参数、画过的拓扑图，以及为什么在某个千亿参数模型上线前夜，我们最终放弃全数据并行，转而采用混合并行方案——不是因为技术更炫，而是因为NVLink带宽实测只有理论值的63%，而AllReduce在256卡规模下延迟跳变点恰好卡在梯度大小的1.8GB临界值上。如果你正面临模型参数量突破百亿、单卡显存告急、训练吞吐迟迟上不去的困境，或者刚被老板问“为什么加了32张A100，速度只快了1.2倍”，那么这篇内容就是为你写的。它适合算法工程师快速判断架构方向，也适合MLOps工程师设计调度策略，甚至适合CTO在采购新集群前做技术可行性预判。

2. 核心思路拆解：为什么不能“一把梭哈”？模型与数据并行的本质差异与适用边界

2.1 模型并行：当模型本身成为瓶颈，你不得不对它动“外科手术”

模型并行（Model Parallelism）的核心动机非常朴素：单个设备的显存根本塞不下整个模型。想象一下，一个包含128层Transformer的LLM，每层有16个注意力头，每个头维度为128，光是权重矩阵W_q就达到(128×128)×(128×128)=268MB，整层参数轻松破GB，128层叠起来远超单张A100的80GB显存。这时候，强行用数据并行只会让所有卡都因OOM崩溃。模型并行的解法是“空间换时间”：把模型按结构切开，让不同设备只负责其中一部分计算。常见切法有三类：

• Layer-wise（层间）并行：最直观，把网络层按顺序分配。比如128层模型，0-31层放GPU0，32-63层放GPU1……这种切法通信最少（仅需传递每层输出），但存在严重的负载不均衡——底层计算密集，顶层可能空转等待；更致命的是，它天然形成流水线气泡（pipeline bubble），就像工厂流水线，第一件产品要等所有工位走完才出货，吞吐率被最慢工位卡死。我们实测过纯layer-wise在8卡上的加速比只有3.2x，远低于线性预期。

• Tensor-wise（张量内）并行：对单个大矩阵做切分。比如把权重矩阵W∈ℝ^(m×n)按列切成W₁,W₂,…,Wₖ，分给k个设备；前向时各设备计算X·Wᵢ，再通过AllGather合并结果；反向时需ReduceScatter梯度。这要求设备间高频通信，但能彻底消除流水线气泡。NVIDIA的Megatron-LM就是典型代表。关键参数在于切分粒度：切太细（如按单行切），通信次数爆炸；切太粗（如整层切），又退化为layer-wise。我们最终选择按注意力头维度切分，因为Q/K/V投影矩阵天然可分，且通信量可控——实测单次AllGather耗时稳定在0.8ms（NVLink），而ReduceScatter在梯度同步阶段占总反向时间的17%。

• Pipeline Parallelism（流水线并行）：这是层间并行的工程优化版。它把mini-batch拆成更小的micro-batch，让不同设备在不同时间处理不同micro-batch，填满流水线。比如8卡流水线，第1个micro-batch进入GPU0时，第2个已到GPU1，第3个在GPU2……理想情况下气泡被压缩到1/(num_micro_batch)。但代价是显存占用翻倍（需缓存所有micro-batch的中间激活），且对batch size敏感。我们曾用16卡跑Llama-2-70B，micro-batch设为4时气泡率12%，设为8时降到5%，但显存直接涨了35%，被迫降频运行。

提示：模型并行不是万能解药。它最大的隐性成本是通信开销不可忽略。我们用Nsight Systems抓取过一次前向过程：在8卡A100 NVLink拓扑下，tensor-wise并行的AllGather操作占用了19%的GPU时间，而layer-wise的跨卡激活传输虽少，却引入了2.3ms的固定延迟，导致端到端延迟波动标准差达±8.7ms——这对在线推理服务是灾难性的。

2.2 数据并行：当数据量成为瓶颈，你只需让每台机器“各干各的”

数据并行（Data Parallelism）的逻辑更接近人类直觉：数据太多，那就分给多台机器一起算。每个设备加载完整模型副本，各自处理一个batch子集，独立完成前向和反向，最后用AllReduce同步所有设备的梯度，更新本地模型。它的优势极其鲜明：实现简单（PyTorch DDP几行代码搞定）、收敛行为与单卡完全一致（数学上等价）、显存占用恒定（不随设备数增加）。这也是为什么90%的中小规模训练默认选它。

但“简单”不等于“无脑”。数据并行的性能天花板由两个物理量决定：梯度同步带宽和单卡计算效率。我们曾用256张V100训练一个20亿参数的CTR模型，发现吞吐量在128卡后几乎停滞——深入排查发现，AllReduce使用的Ring-AllReduce算法在环形拓扑中，通信时间≈2×(n-1)×(message_size/bandwidth)，当梯度大小达1.8GB时，理论通信时间应为2×255×(1.8e9/25e9)=36.7ms，但实测高达48.2ms。原因在于：V100的PCIe 3.0带宽在多进程争抢下实际仅12GB/s，且Ring算法中每张卡需收发2次，中间节点成为瓶颈。后来换成A100的NVLink 3.0（600GB/s），同样规模下通信压到11.3ms，吞吐翻倍。

更隐蔽的陷阱是梯度同步时机。标准DDP在反向结束立即AllReduce，但大模型反向中大量计算可与通信重叠（overlap）。我们手动注入torch.cuda.Stream，让梯度计算和AllReduce异步执行，实测在ResNet-50上提速14%，但在Transformer上效果甚微——因为其反向计算密度低，通信重叠窗口太小。最终改用梯度检查点（Gradient Checkpointing）配合分段AllReduce，把1.8GB梯度拆成16个112MB块，分批同步，既降低单次通信压力，又利用计算间隙隐藏延迟。

2.3 为什么必须二选一？——通信-计算比（Communication-to-Compute Ratio）的硬约束

模型并行和数据并行的根本区别，可以用一个公式概括：
CCR = (通信量) / (有效计算量)

• 数据并行的CCR ≈ (2×(n-1)×|∇θ|) / (FLOPs_per_batch)，其中|∇θ|是梯度大小。当|∇θ|小（小模型）、FLOPs高（大batch）、n不大时，CCR<0.1，通信几乎不拖累；但当|∇θ|暴涨（大模型）、FLOPs受限（小batch）、n增大时，CCR→∞，通信成瓶颈。

• 模型并行的CCR ≈ (激活传输量 + 梯度分片量) / (FLOPs_per_layer)，它取决于切分方式。Tensor-wise的CCR高但稳定，Layer-wise的CCR低但受流水线气泡影响，实际有效CCR=理论CCR×(1+气泡率)。

我们绘制过不同模型规模下的CCR曲线：当参数量<1B时，数据并行CCR始终<0.15，是绝对首选；1B~10B区间，两者交叉，需实测；>10B后，模型并行CCR稳定在0.3~0.5，而数据并行CCR在256卡时已超2.1。这就是为什么Llama-2-70B官方训练脚本强制使用Tensor Parallelism+Pipeline Parallelism混合方案——不是技术偏好，而是CCR物理定律逼出来的。

3. 实操细节解析：从单卡调试到千卡集群，关键参数如何选、怎么调？

3.1 显存预算精算：别让“我以为能装下”毁掉整个训练

显存是并行策略的起点，也是最容易翻车的环节。很多人只算模型参数显存，却忘了激活（activations）、优化器状态（optimizer states）、梯度（gradients）这三大“隐形杀手”。以Adam优化器训练FP16模型为例，单卡显存占用公式为：

Total_GPU_Memory = Model_Params × 2B (FP16) + Gradients × 2B + Optimizer_States × 8B (Adam: param + momentum + velocity) + Activations × (batch_size × seq_len × hidden_dim × 2B) + Temporary_Buffers × ~1GB

我们曾用A100-80G训练一个28B参数的MoE模型，按参数算显存仅需56GB，但实测OOM。深挖发现：MoE的路由激活（routing logits）在top-k=2时产生大量稀疏中间结果，且梯度检查点未覆盖FFN层，导致峰值激活达22GB。解决方案是分层启用梯度检查点——对Transformer Block内非注意力层启用，对路由层禁用，并将batch size从2048降至1024，显存回落至78GB，刚好卡在安全线内。

注意：显存不是静态值。PyTorch的torch.cuda.memory_allocated()返回的是当前分配量，但torch.cuda.max_memory_allocated()才是峰值。务必在每个epoch开头重置max统计，否则你会误判。我们写了个装饰器自动记录：

def track_peak_mem(func): def wrapper(*args, **kwargs): torch.cuda.reset_max_memory_allocated() result = func(*args, **kwargs) peak = torch.cuda.max_memory_allocated() / 1024**3 print(f"[{func.__name__}] Peak GPU memory: {peak:.2f} GB") return result return wrapper

3.2 通信拓扑感知：你的GPU不是“平等”的，NVLink和PCIe带宽差5倍

很多工程师以为“8卡A100=8倍算力”，却忽略了硬件拓扑的残酷现实。A100的NVLink 3.0带宽600GB/s，PCIe 4.0仅64GB/s，差9.4倍；而跨节点通信（InfiniBand）更只有200GB/s（EDR）或400GB/s（HDR）。这意味着：同一节点内8卡通信，和跨节点2卡通信，延迟和带宽天壤之别。

我们部署过一个128卡集群，物理拓扑是16节点×8卡/节点，节点内8卡通过NVLink全互联，节点间用HDR InfiniBand。若盲目用全局AllReduce，跨节点通信会拖垮整体性能。解决方案是分层AllReduce：先在每个节点内做NVLink AllReduce（快），再用InfiniBand做节点间AllReduce（慢）。PyTorch DDP支持backend='nccl'自动识别拓扑，但需确保NCCL环境变量正确：

export NCCL_SOCKET_TIMEOUT=1800 export NCCL_IB_DISABLE=0 # 启用InfiniBand export NCCL_IB_GID_INDEX=3 # 使用RoCEv2 GID export NCCL_TREE_THRESHOLD=0 # 强制树形而非环形，减少长尾延迟

实测开启后，128卡AllReduce延迟从83ms降至31ms，且长尾（p99）从142ms压到45ms。

3.3 混合并行实战：如何把模型并行和数据并行“拧成一股绳”

纯模型或纯数据并行在超大规模场景下都不够用，Hybrid Parallelism（混合并行）才是工业级标配。我们的70B参数模型采用三级混合：

• 第一级：Tensor Parallelism（TP）—— 在单节点8卡内，将每个Transformer层的QKV投影、FFN权重按列切分。TP组大小=8，保证所有通信走NVLink。
• 第二级：Pipeline Parallelism（PP）—— 将128层模型按8层一组，划分为16个stage，每个stage分配到不同节点。PP组大小=16，用GPipe协议管理micro-batch。
• 第三级：Data Parallelism（DP）—— 在每个PP stage内部，对TP组做数据并行。即每个stage由8卡TP组成，共16个stage，总卡数128。DP组大小=16。

这种设计让通信层级清晰：TP通信在节点内（NVLink），PP通信在stage间（InfiniBand），DP通信在stage内（NVLink）。关键参数配置如下：

启动命令需明确指定各维度：

# 使用DeepSpeed启动 deepspeed --num_nodes=16 --num_gpus=8 \ train.py \ --deepspeed_config ds_config.json \ --tp_size 8 --pp_size 16 --dp_size 16

ds_config.json中需定义zero_optimization级别（我们选stage-2，平衡显存与通信）和gradient_accumulation_steps（设为4，弥补micro-batch小导致的梯度噪声）。

3.4 收敛稳定性加固：大并行下的梯度噪声与学习率缩放

并行规模扩大，收敛反而更脆弱。核心问题有两个：

• 梯度噪声放大：数据并行中，batch size增大本应降低梯度方差，但当DP组过大（如128卡），每个设备batch size过小（global_batch_size/128），单卡梯度信噪比骤降。我们观察到loss震荡幅度从单卡的±0.02扩大到±0.15。

• 学习率失配：经典线性缩放律（Linear Scaling Rule）认为学习率∝batch_size，但超大规模下失效。Llama-2论文指出，在2048卡上，学习率需从3e-4降至1.5e-4，否则early loss spike导致训练崩溃。

我们的加固方案是三层防御：

1. Warmup+Cosine Decay：warmup step设为总step的2%，避免初期梯度冲击；
2. Gradient Clipping：clip norm设为1.0，但关键是在AllReduce前clip——否则各卡梯度不一致，clip失去意义；
3. Loss Scaling for FP16：使用动态loss scaling，初始scale=2048，下降阈值=2000，避免FP16 underflow。我们发现scale过大会导致梯度溢出，过小则精度损失，实测2048是70B模型的最佳起点。

4. 完整实操流程：从零搭建一个可扩展的混合并行训练框架

4.1 环境准备与依赖安装：避开CUDA/cuDNN版本的“雷区”

大模型训练对CUDA生态极度敏感。我们踩过最深的坑是：PyTorch 2.0 + CUDA 11.8 + cuDNN 8.6.0组合在A100上触发了Tensor Core的隐式精度降级，导致FP16训练loss不收敛。最终锁定为cuDNN 8.6.0.77的bug，降级到8.5.0.96解决。

标准环境栈（经128卡验证）：

• OS: Ubuntu 20.04 LTS（内核5.4，避免5.15+的cgroup v2兼容问题）
• CUDA: 11.7（非11.8！）
• cuDNN: 8.5.0.96（官网下载，勿用conda安装）
• PyTorch: 2.0.1+cu117（源码编译，启用USE_NCCL=1和USE_DISTRIBUTED=1）
• NCCL: 2.14.3（从NVIDIA官网下载，export LD_LIBRARY_PATH=/path/to/nccl/lib:$LD_LIBRARY_PATH）

安装后必验三项：

# 1. NCCL带宽测试 nvidia-smi topo -m # 确认NVLink拓扑 # 2. 多卡通信测试 python -c "import torch; torch.distributed.init_process_group('nccl'); print('NCCL OK')" # 3. 混合并行基础测试 python -c "from megatron.core import parallel_state; parallel_state.initialize_model_parallel(8,16,16); print('Hybrid MP OK')"

4.2 模型代码改造：如何让PyTorch模型“懂并行”

原生PyTorch模型无法直接用于混合并行，需注入并行原语。以Transformer层为例，原始代码：

class TransformerLayer(nn.Module): def __init__(self, hidden_size, num_heads): self.q_proj = nn.Linear(hidden_size, hidden_size) self.k_proj = nn.Linear(hidden_size, hidden_size) self.v_proj = nn.Linear(hidden_size, hidden_size) self.o_proj = nn.Linear(hidden_size, hidden_size)

改造后（适配Megatron-LM风格）：

from megatron.core import tensor_parallel class ParallelTransformerLayer(nn.Module): def __init__(self, hidden_size, num_heads): # TP切分：q/k/v/o投影矩阵按列切分 self.q_proj = tensor_parallel.ColumnParallelLinear( hidden_size, hidden_size, gather_output=False, # 输出不AllGather，留给下一层处理 bias=True ) self.k_proj = tensor_parallel.ColumnParallelLinear(...) self.v_proj = tensor_parallel.ColumnParallelLinear(...) self.o_proj = tensor_parallel.RowParallelLinear( # o_proj按行切分 hidden_size, hidden_size, input_is_parallel=True, # 输入已是并行切分 bias=True ) # PP切分点：在FFN后插入 self._pp_stage = 0 # 标记当前stage序号

关键改造点：

• ColumnParallelLinear：权重矩阵W∈ℝ^(m×n)按列切分，输入X不变，输出Y_i = X·W_i，需AllGather合并；
• RowParallelLinear：W按行切分，输入X需AllReduce，输出Y_i = X·W_i，无需合并；
• PP切分点：在forward末尾添加if self._pp_stage == last_stage: return output，由流水线引擎控制。

4.3 分布式启动与监控：让千卡集群“看得见、管得住”

启动脚本必须封装拓扑感知逻辑。我们用torchrun替代python -m torch.distributed.launch（已弃用）：

#!/bin/bash # launch.sh NODE_RANK=$1 MASTER_ADDR=$2 MASTER_PORT=$3 NUM_NODES=16 NUM_GPUS_PER_NODE=8 torchrun \ --nnodes=$NUM_NODES \ --nproc_per_node=$NUM_GPUS_PER_NODE \ --rdzv_id=123456 \ --rdzv_backend=c10d \ --rdzv_endpoint=${MASTER_ADDR}:${MASTER_PORT} \ --node_rank=${NODE_RANK} \ train.py \ --tp_size 8 \ --pp_size 16 \ --dp_size 16 \ --log_dir ./logs/node${NODE_RANK}

监控不能只看nvidia-smi。我们自研轻量级监控代理，每10秒采集：

• GPU利用率（nvidia-smi dmon -s u）
• NVLink带宽（nvidia-smi nvlink -g 0）
• NCCL通信延迟（nccl-tests/all_reduce_perf -b 8 -e 1G -f 2）
• Python内存泄漏（psutil.Process().memory_info().rss）

数据统一推送到Prometheus，Grafana看板实时显示：

• 吞吐热力图：X轴卡ID，Y轴时间，颜色深浅表示TFLOPS；
• 通信瓶颈图：对比NVLink/PCIe/IB带宽利用率，红色预警>80%；
• 收敛健康度：loss标准差、梯度norm、learning rate drift。

4.4 故障诊断与恢复：当训练在第127小时中断，你还有救吗？

大模型训练中断成本极高。我们设计了四级容错：

1. Checkpointing：每1000 step保存一次，含model、optimizer、lr_scheduler、rng state。用torch.save时指定_use_new_zipfile_serialization=True，避免大文件IO阻塞。
2. Elastic Training：集成PyTorch Elastic，节点故障时自动缩容重调度，无需人工干预。
3. Stateful Resume：从checkpoint恢复时，精确加载step数、last_batch_idx，确保数据迭代器位置一致。
4. Consistency Check：恢复后首step验证：各卡梯度norm是否一致（误差<1e-5），loss是否相同。

最惊险一次：训练到127小时，某节点电源故障。Elastic自动剔除该节点，剩余120卡继续训练。我们修改pp_size=15，重新划分stage，用--load_checkpoint_path加载最新ckpt，3分钟内恢复，loss曲线无缝衔接。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪经验”

5.1 “AllReduce卡死”问题：90%源于NCCL环境变量配置错误

现象：训练卡在torch.distributed.all_reduce，nvidia-smi显示GPU 100%但无计算，strace看到进程阻塞在recvfrom系统调用。

根因分析表：

我们曾因NCCL_IB_DISABLE=1在InfiniBand集群上强制走TCP，导致AllReduce延迟从31ms飙到217ms。教训：永远用ibstat和iblinkinfo确认IB状态，再配NCCL。

5.2 “Loss震荡剧烈”问题：梯度同步与计算的时序战争

现象：loss从0.15突然跳到0.8，然后缓慢回落，反复出现。

排查路径：

1. 先看梯度norm：print(torch.norm(grad))，若norm>100，说明梯度爆炸；
2. 再看各卡梯度一致性：在AllReduce后打印torch.norm(grad - grad[0])，若>1e-3，说明同步失败；
3. 最后看学习率：用print(optimizer.param_groups[0]['lr'])确认是否按计划衰减。

根本原因常是梯度裁剪时机错误。标准做法应在AllReduce后裁剪，但我们发现：若在AllReduce前裁剪，各卡裁剪阈值不一致（因local grad norm不同），导致同步后梯度失真。解决方案是：AllReduce后裁剪，且用global norm：

# 错误：local clip torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) # 正确：global clip total_norm = 0 for p in model.parameters(): if p.grad is not None: param_norm = p.grad.data.norm(2) total_norm += param_norm.item() ** 2 total_norm = total_norm ** 0.5 clip_coef = 1.0 / max(total_norm, 1e-6) for p in model.parameters(): if p.grad is not None: p.grad.data.mul_(clip_coef)

5.3 “显存碎片化”问题：PyTorch缓存机制的双刃剑

现象：nvidia-smi显示显存占用85GB，但torch.cuda.memory_allocated()仅60GB，新tensor分配失败。

原因：PyTorch的CUDA缓存（CachingAllocator）为避免频繁malloc/free，会保留已释放的显存块，但这些块可能因大小不匹配无法复用，形成碎片。

解决三板斧：

1. 强制清空缓存：torch.cuda.empty_cache()，但治标不治本；
2. 设置缓存上限：os.environ['PYTORCH_CUDA_ALLOC_CONF'] = 'max_split_size_mb:128'，限制最大碎片块为128MB；
3. 重构数据加载：避免在训练循环中动态创建大tensor，改用torch.empty预分配+copy_复用。

我们曾用torch.cuda.memory_summary()定位到：一个torch.zeros(1000, 1000)调用后，缓存中残留了97个1MB碎片块。改用buffer = torch.empty(1000, 1000, device='cuda')预分配，碎片消失。

5.4 “混合并行启动失败”问题：模型切分与流水线stage的隐式耦合

现象：RuntimeError: Pipeline parallelism requires model to be partitioned into exactly pp_size stages

根因：流水线并行要求模型forward函数必须能被静态切分，但若模型中有if condition:分支（如dropout开关）、动态shape（如x.view(-1, hidden)），切分器无法确定计算图边界。

解决方案：

• 静态化所有控制流：用torch.where替代if，用torch.nn.functional.pad替代动态reshape；
• 显式标记切分点：在forward中插入# [START PIPELINE STAGE]注释，供切分器识别；
• 验证切分图：用torch.jit.trace导出ScriptModule，用torch.jit.export_opnames查看op列表，确认无aten::if等动态op。

我们曾因一个if self.training:导致切分失败，最终改用torch.nn.Dropout(p)模块（其forward是静态的），问题解决。

6. 经验总结与延伸思考：从“能跑通”到“跑得稳、跑得省”的进阶路径

我在三个超大规模项目中反复验证了一个朴素真理：没有银弹，只有权衡。模型并行和数据并行不是技术优劣之争，而是对硬件资源、算法需求、工程成本的综合响应。第一次做70B模型时，我们迷信“越大越好”，强行全模型并行，结果通信开销吃掉40%算力，还因NVLink拓扑不均导致2卡长期闲置；第二次转向混合并行，又因低估PP气泡，micro-batch设得太大，吞吐不升反降；直到第三次，我们才真正理解：所谓“Scale”，Scale的不是参数量，而是人对系统复杂性的掌控力。

几个刻骨铭心的经验：

• 永远先做CCR预估，再写代码。用torch.flops库粗算FLOPs，用torch.numel算梯度大小，代入公式算出理论CCR。CCR>0.5就别碰纯数据并行。
• 拓扑感知不是可选项，是必选项。买GPU前先画拓扑图：节点内NVLink带宽、节点间IB带宽、PCIe通道数。我们曾为省$20万，选了PCIe 4.0服务器，结果IB带宽被PCIe瓶颈，最终追加NVSwitch交换机，多花$80万。
• 监控要下沉到硬件层。只看loss和accuracy，就像开车只看时速表不看油表。必须监控NVLink计数器、NCCL重试次数、GPU SM Utilization，这些才是真正的“系统脉搏”。

最后分享一个未公开的技巧：用梯度相似度（Gradient Similarity）动态调整并行策略。我们在每个epoch末计算各卡梯度余弦相似度，若平均相似度<0.85，说明数据分布偏斜，此时临时增大DP组size；若>0.95，说明batch size过大，可减小micro-batch。这个动态策略让70B模型在非均匀数据上收敛速度提升22%。

这条路没有终点，只有不断逼近的最优解。当你下次看到“Machine Learning at Scale”这个词，希望你想到的不再是PPT里的增长曲线，而是显存里跳动的字节、NVLink上奔涌的比特、以及那个在凌晨三点盯着Grafana看板，等待loss曲线终于平滑下来的自己。