拆解那 11.9%:大规模训练集群的生产力损失度量与自动化治理

——解读 ASE '26 论文《Characterizing and Mitigating Productivity Loss in Large-Scale Model Training: An Empirical Study》

论文:Xue et al., Characterizing and Mitigating Productivity Loss in Large-Scale Model Training: An Empirical Study, ASE '26(第 41 届 IEEE/ACM 自动化软件工程国际会议),DOI: 10.1145/3832783.3834462
作者团队来自北京航空航天大学与快手科技,实证数据基于快手生产训练集群。

TL;DR

这篇论文做了三件事:

提出 ETPR(Effective Training Productivity Ratio):把端到端训练生产力分解为调度好put(SG)× 占空比(DC)× 生产力质量(QoP)三个分量,使可靠性导致的生产力损失可以被归因到生命周期的具体阶段;
完成一次生产级实证:覆盖快手集群三个月、20,629 个训练任务,发现端到端生产力中 11.9% 被损失掉,且损失主要发生在资源分配之后——而非排队调度阶段;
构建并部署了自动化稳定性治理框架:统一处理 fail-stop(崩溃)、fail-hang(假死卡住)、fail-slow(隐性变慢)三类故障,四周边部署将集群 ETPR 从 88.1% 提升至 91.9%。

下面逐层展开。

一、背景:GPU 时长是怎么被"蒸发"的

训练 LLaMA 3(405B)这样的模型需要 16,000+ 张加速器连续运行 54 天。在这种尺度下,生产力的瓶颈往往不是算法和峰值硬件性能,而是训练系统的可靠性:

硬件故障(ECC 错误、GPU 掉卡、过热)
网络退化(RDMA/InfiniBand 拥塞、丢包)
软件缺陷(框架 bug、配置错误、依赖不匹配)

这些故障以三种典型形态侵蚀生产力,论文借用了经典的可靠性失效分类:

失效形态	表现	危害特征
Fail-stop	任务显式崩溃退出	损失直观,但诊断/恢复时间可能远超故障本身
Fail-hang	进程活着但不产生任何进展(假死)	无报错信号,极难察觉与定位
Fail-slow	迭代仍在推进,但吞吐低于健康基线	最隐蔽:任务"看起来正常",慢性失血

更关键的是,故障本身往往只是损失的开始:诊断、调试、恢复过程占据的非生产时间经常超过故障造成的直接中断。论文给出了一个真实例子:一次错误的并行配置导致任务反复崩溃,用户在 30 分钟内重启多次,没有一次取得任何训练进展。

二、已有指标的盲区

ETTR:只看见"死",看不见"慢"。 Effective Training Time Ratio(ETTR)量化中断、抢占和恢复造成的损失,聚焦任务存活率。它无法识别那些活着但变慢的任务——而 fail-slow 恰恰是最难治理的损失来源。

MPG:关注效率,而非可靠性。 ML Productivity Goodput(MPG)在集群规模上按系统层分解机器学习生产力,主要用于定位性能与利用率瓶颈(如编译器效率、异构调度),而不是将生产力损失归因到可靠性事件。

缺口。 业界缺少一个能同时回答以下问题的指标:损失发生在哪个阶段?是排队没排上、占着 GPU 不干活、还是干活干得慢?每一类损失分别对应什么运维动作?ETPR 就是为填补这个缺口设计的。

三、ETPR:把端到端生产力拆开

3.1 任务生命周期与四个时间量

以单个训练任务为基本分析单元,把其生命周期(覆盖正常执行与故障恢复期)分解为四个时间量:

Demanded Time(需求时间):从任务提交到终止的端到端时间;
Allocated Time(分配时间):任务成功调度后实际占用所分配 GPU 的时间;
Productive Time(生产时间):分配时间中用于训练迭代、且其进展最终被有效 checkpoint 保存的部分——恢复后的重算(recompute)、重启开销、checkpoint 开销、故障处理、无进展的 hang 全部不计入;
Ideal Time(理想时间):在健康执行环境、相同硬件与可比配置下,完成同样持久化进展所需的估计时间(从足够多的健康运行样本中估计健康迭代耗时)。

3.2 三分量分解

对观测窗口内所有任务聚合,ETPR 定义为:

$\text{ETPR} = \underbrace{\frac{\sum_i \text{Allocated}_i}{\sum_i \text{Demanded}_i}}_{\text{Scheduling Goodput (SG)}} \times \underbrace{\frac{\sum_i \text{Productive}_i}{\sum_i \text{Allocated}_i}}_{\text{Duty Cycle (DC)}} \times \underbrace{\frac{\sum_i \text{Ideal}_i}{\sum_i \text{Productive}_i}}_{\text{Quality of Productivity (QoP)}}$

三个分量各有明确的运维语义:

分量	语义	低值的含义	对应的失效形态
SG	申请的 GPU 时间有多少真正变成分配执行	排队等待、启动失败等调度损失	—
DC	分配的 GPU 时间中有多少产生持久训练进展	“占而不产”:fail-stop、fail-hang 及随后的诊断/恢复/failover	fail-stop、fail-hang
QoP	生产执行离健康吞吐基线有多近	任务仍在完成迭代,但比预期慢(fail-slow)	fail-slow

一个值得注意的细节:QoP 只度量"活跃推进期"的吞吐效率。fail-hang 产生的进展为零,因此被计入 DC 损失而非 QoP 损失——这保证了每个分量与一类运维动作的对应关系是干净的。

3.3 度量实现

各时间量先按 wall-clock 区间测量,再乘以任务申请的 GPU 数 $N_i$ 换算成 GPU-time,使不同规模的任务可比较。Productive Time 从训练日志与 checkpoint 记录的时间戳推导;Ideal Time 基于同硬件环境、可比配置下的健康运行样本估计。论文明确强调:ETPR 是操作层面的集群级归因估计,而非逐步精确记账。

四、实证研究:三个月、20,629 个任务告诉我们什么

4.1 实验设置

数据源三路交叉:

调度器记录与任务级遥测(提交/调度/终止时间、申请 GPU 数、执行尝试次数);
训练日志与运行时监控指标(迭代进展、运行状态、故障症状);
由监控告警、系统故障与用户上报生成的事件工单(含症状、日志、遥测、运维人员的诊断与处置记录)。

根因标注:5 名资深 SRE 与软件工程研究生独立审查 443 起确认的故障事件,基于日志中的上下文错误信息确定根因,缺失显式错误信号时结合症状模式与遥测推断。标注一致性用 Cohen’s kappa 评估,达到 0.82(高一致性)。

4.2 RQ1:症状——损失分布

Table 1:ETPR 各维度留存率

维度	留存率	主要贡献因素
Scheduling Goodput	99.1%	排队等待
Duty Cycle	92.5%	常规开销、Stop Failures、Hangs、Manual Stops
Quality of Productivity	96.1%	Stragglers(落后者)
ETPR	88.1%	—

注:表中"贡献因素"(如 Stop Failures、Stragglers)不仅指事件本身,还包括处置它们所需的额外时间。

整体 ETPR 为 88.1%,即端到端训练生产力损失了 11.9%。分布高度不均:

SG 损失仅 0.9%:主要来自排队等待与资源碎片化。调度不是问题所在,因此论文后文不再展开;
DC 损失 7.5%:其中约 20% 是常规基线开销(pod 启动、初始化、数据加载、checkpoint 读/写),其余来自 fail-stop 事件、fail-hang 停滞、人工终止及其后续诊断与恢复;
QoP 损失 3.9%:最可见的表现是 straggling——一个或少数 rank 反复落后,拉长所有同步迭代。fail-slow 之所以危害巨大,是因为它不仅拉长 Productive Time,还常常在异常被发现之前已持续很久;即使被发现后,任务往往还在继续运行,而运维人员仍在收集证据、缩小范围。

4.3 RQ2:根因——频次与成本的严重不对称

Table 2:根因分类、典型症状与人工诊断恢复时长

类别	典型症状	代表性根因	占比	平均诊断+恢复
软件/用户故障	Fail-stop, Fail-hang	代码 bug、API 误用、依赖问题、配置错误、驱动不匹配、张量设备/形状不匹配、CUDA kernel 与内存访问错误、Python 异常等	74.1%	20.3 min
网络故障	Fail-stop, Fail-hang, Fail-slow	通信超时、连接失败、带宽退化、fabric 不稳定、远端 worker 崩溃、网络拥塞、拓扑问题	15.9%	148.2 min
硬件故障	Fail-stop, Fail-hang, Fail-slow	ECC page failure、EDAC 内存错误、PCIe fatal error、GPU 掉卡、GPU 功耗/过热、NVLink/IB 物理问题、I/O 错误、NVMe 故障	5.1%	74.5 min
资源耗尽	Fail-stop, Fail-hang	主机/显存耗尽、磁盘配额超限、共享内存耗尽、文件描述符耗尽	4.9%	53.1 min

两个结构性发现:

发现 1(症状侧):主导性生产力损失发生在调度之后。 DC 损失主要来自"已分配但不生产"的时段——fail-stop、fail-hang、人工停止及随后的诊断恢复;QoP 损失来自 fail-slow——任务持续完成迭代但吞吐退化。

发现 2(根因侧):故障量与治理成本呈倒挂。 软件/用户故障占 74.1% 的事件量,制造了沉重的日志诊断负担(但平均 20 分钟即可恢复);硬件与网络故障占比很小,却分别需要 74.5 和 148.2 分钟——因为它们缺乏直接可执行的框架级日志,常表现为静默 hang、持续 straggler 或间歇性通信错误,必须跨层关联硬件遥测、健康信号与网络计数器才能定位。单卡热节流(thermal throttling)甚至可能先表现为局部减速,再逐步恶化为拖垮所有 rank 的系统级瓶颈。

五、自动化稳定性治理框架

针对上述三类损失,论文构建了一条"观测 → 诊断 → 定位 → 恢复 → 预防"的端到端流水线。

5.0 架构总览

Tracing Plane(每个 pod 部署):

结构化日志解析器——摄取 stdout/stderr,转发故障相关条目;
心跳监控器——跟踪 rank 存活,进展停滞时触发栈采集;
CUDA 活动追踪器——基于 CUPTI Activity API 对集合通信算子插桩,记录算子级起止时间戳;
系统遥测监控器——采集 GPU/CPU 利用率、内存、网络状态、NIC/PCIe 带宽等。

Master Agent:汇聚所有 pod 的信号,执行诊断、定位与恢复。它将每个任务的诊断事件串行化以避免并发/级联故障下的恢复冲突;诊断例程互斥——级联场景(如网络退化 → fail-slow → fail-hang 心跳超时)按序评估,hang 检测会等待 slow 检测完成。

Recovery Plane:选择破坏性最小的动作恢复持久训练进展。

5.1 Fail-stop 诊断:知识库 + 三级递进

离线阶段:从历史故障日志挖掘高频模式构建词法规则;用 Drain 将日志解析为结构化模板;将模板 embedding 与已验证标签存入向量知识库。

在线阶段:fail-stop 事件虽会显式报错,但根因常被海量分布式日志与级联次生错误淹没。框架采用分布式训练引擎中的最早错误启发式(earliest-error heuristic):跨进程比对时间戳,找到最早失败的进程,提取其主要错误条目,过滤下游级联噪声。随后三级递进分类:

Aho–Corasick 词法匹配——处理高频模式;
语义检索——词法不确定时检索向量知识库;
LLM 推理——检索置信度低时兜底。

若主错误指向硬件/网络但缺乏精确故障 rank,框架在恢复前先做定向定位:硬件错误关联设备健康信号、用 dcgmi diag 验证疑似 pod/节点;网络错误(如 mpirun SSH 失败、来源不明的集合通信错误)运行 nccl-tests、ib_write_bw 或跨节点 all-reduce 检查以定位故障通信路径。

5.2 Fail-hang 诊断:栈采样 + 多数投票

静默停滞没有显式错误信号,还必须与 checkpoint 写入等预期长延迟操作区分。诊断流水线:

master rank 监控训练循环心跳。不用固定超时直接杀任务,而是把持续心跳丢失作为进入诊断模式的信号;
通过远程 shell 用 py-spy 对每个 rank 的主线程栈等间隔采样三次;
仅当三轮采样调用栈完全一致才确认 hang——该判据能有效区分真正的死锁与瞬态同步延迟;
定位:同步集合通信下,非故障 rank 通常阻塞在同一个同步屏障上、呈现相同调用栈。系统收集最终栈轨迹并做多数投票识别主导执行模式,任何偏离主导模式的 rank 视为离群者,映射到其物理宿主节点。

5.3 Fail-slow 诊断:先检测,后定位

异常检测:自适应、相位感知。

朴素阈值方法在训练场景下会大量误报:正常训练本身存在周期性波动,且不同模型结构的时间分布天然不同——例如 MoE 架构在健康硬件下也会出现周期性迭代耗时尖峰,而稠密模型相对平稳。

为此,检测器从任务自身的无异常历史迭代校准:

训练步可能呈周期行为 → 用**自相关函数(ACF)**估计主导周期;
用干净迭代的中位数与 **MAD(Median Absolute Deviation)**构建相位感知基线;
迭代耗时信号对基线归一化得到异常分数;
仅当异常分数持续累积超过自校准阈值才告警——区分持续性退化与瞬态抖动。

Straggler 定位:最近启动者加权评分。

fail-slow rank 因计算或网络退化而变慢,它总是晚于同伴进入下一次集合通信,造成两个可观测效应:rank 间启动时间偏差增大、通信时间被拉长(同步要等所有人)。

对通信组 $G$ 中的每个集合通信事件 $e$ ,每个 rank $r$ 上报调用起止时间 $t_r^{\text{start}}, t_r^{\text{end}}$ 。归一化的"最晚启动者"权重:

$w^{\text{latest}}_{r,e} = \frac{t_r^{\text{start}} - \min_{r' \in G} t_{r'}^{\text{start}}}{\max_{r' \in G} t_{r'}^{\text{start}} - \min_{r' \in G} t_{r'}^{\text{start}}}$

同时以组内最晚开始到最晚结束的时长度量有效通信时间 $\delta^{\text{comm}}_e$ ,并做通信时长加权聚合:

$\Phi_r = \frac{1}{|E_r|} \sum_{e \in E_r} w^{\text{latest}}_{r,e} \cdot \delta^{\text{comm}}_e$

其中 $E_r$ 是 rank $r$ 参与的集合通信事件集合。定位只在告警之后激活,且仅使用告警窗口内的事件计算 $\Phi_r$ ——检测期低开销、定位期快响应。

5.4 故障恢复:分层、最小破坏

核心设计:每个训练 pod 内运行一个 agent 作为任务本地控制平面,将训练进程生命周期与 pod 生命周期解耦——接管进程启动、环境校验、代码分发、网络配置与恢复执行。可恢复的故障通过现有 pod 集内的进程级重启处理,避免全量 pod 重建与重新调度;全局调度器只负责资源分配与 pod 替换。

Table 3:诊断结果 → 恢复动作映射

诊断结果	恢复动作
用户代码、API 误用或配置故障	提供回溯与知识库提示;可修复时就地重启
环境或依赖不匹配	校验运行环境,将受影响组件回滚到已知良好版本
资源耗尽	清理非持久的临时文件、缓存、过期共享内存段,保留 checkpoint 与用户数据
瞬态 fail-slow 症状	跨窗口观察;若退化持续但定位置信度不足,就地重启
已定位的硬件、网络或持续 straggler 故障	替换受影响 pod/节点,更新 rank placement,从最近有效 checkpoint 重启

In-Place Recovery(不换 pod/机器):用户代码 bug → 抽取完整 traceback,LLM 辅助检索知识库中的相关 issue 与解法;环境故障 → 运行校验脚本并回滚;资源耗尽 → 清理临时状态。修复后在现有 pod 集内从最新有效 checkpoint 重启全部 pod,保留已准备好的环境。

Pod Replacement:已确认的硬件/网络故障与持续 straggler。调度器从热备池取健康 pod 替换故障 pod,更新 placement 与 rank 映射后从最新 checkpoint 重启;故障 pod 及其物理机被标记并排除出调度池,直至修复或检修完成。

5.5 主动预防

Pre-Flight 任务校验:训练开始前校验任务配置、依赖一致性、GPU 健康、拓扑、通信就绪与存储容量;检查 GPU 数与并行维度兼容性、校验 YAML、过滤有不可修复 ECC/过热问题的 GPU、验证 PCIe/NVLink 拓扑、跑短通信测试、估算内存与存储需求;故障历史频繁的节点被标记并排除出后续调度;
持续舰队巡检:独立后台进程低频巡检 CPU 频率、互联状态、硬件错误日志、内存错误、存储健康、交换机连通性与硬件温度;发现严重问题时隔离资源或安全暂停训练任务,防止故障级联。

六、效果验证:五个案例 + 四周部署

Case #1:Fail-stop 诊断的准确率—延迟权衡。

用集群日志库中 14,651 条故障日志构建知识库;检索用 bge-small-en,LLM 推理用 GPT-5.4(temperature=0)。在 254 条未被词法匹配解决的 held-out 日志上评估:

方法	W-Precision	W-Recall	W-F1	平均决策时间
Retrieval-Only	79.47%	74.70%	74.85%	0.275s
LLM-Only	84.27%	82.21%	82.54%	4.210s
Retrieval + Conditional LLM	82.34%	80.24%	80.46%	0.312s

Retrieval + Conditional LLM(检索置信度低于阈值才调用 LLM)以约 1/13 的决策时间达到了接近 LLM-Only 的分类性能——典型的准确率—延迟工程权衡。

Case #2:硬件导致的 Fail-stop。 128 GPU 任务在迭代 15,030 处(计划共 327,500)突然崩溃,触发跨多个 rank 的海量级联错误(泛化的 std::runtime_error 与框架级 MPI abort 消息)。词法快路径绕过下游噪声,锁定最早失败单元 Rank 14:NCCL watchdog 线程中浮现的不可修复 ECC 错误。归类为永久硬件故障后,框架自动隔离问题节点、调度健康替换 pod、从最近 checkpoint 安全重启。从故障检测到恢复持久训练,全流程不足 10 分钟。

Case #3:Fail-hang。 心跳持续丢失 → 进入诊断模式 → py-spy 三轮采样 → 6 分钟内确认 hang 并识别可疑 rank。栈模式分析显示,某节点上一个离群 rank 在 forward 阶段阻塞在 irecv。确认后优雅停止、隔离节点、热备替换、重启——hang 未再复发。

Case #4:Fail-slow 异常检测。 数据集:64 个训练会话(50 正常 + 14 异常),覆盖 Dense 与 Megatron-LM 训练的 MoE 两种负载。对比三个常用统计时序基线:

方法	Accuracy↑	FPR↓	FNR↓
Z-Score	68.75%	30.00%	35.71%
MAD	73.43%	26.00%	28.57%
BOCD	89.06%	10.00%	14.28%
本文方法	93.75%	4.00%	14.28%

Z-Score/MAD 这类基线无法区分正常迭代波动与真实退化,误报率高达 26–30%;本文的自适应相位感知方法把 FPR 压到 4%,同时保持对真实慢化的敏感度。

Case #5:GPU 降频注入的 Straggler 定位。 8 GPU、4 节点(PP=2, DP=2, TP=2)集群中,对 Rank 0 施加 SM 时钟频率上限,使其计算吞吐降低约 40%。Rank 0 因此更晚到达集合同步点,其他 rank 被迫等待。确认稳定慢化后,定位模块在告警后窗口内用 $\Phi_r$ 排序全部 rank:Rank 0 在 3 次迭代内即成为 top-ranked,并与其他 rank 保持持续分离——以很短的响应延迟定位了注入的慢 rank。

部署收益:ETPR 88.1% → 91.9%。 四周全量部署后的集群级指标:

指标	部署前	部署后
Scheduling Goodput	99.1%	99.0%
Duty Cycle	92.5%	95.6%
Quality of Productivity	96.1%	97.1%
ETPR	88.1%	91.9%

增益主要来自 DC 与 QoP 的改善。归因分析显示:端到端诊断-恢复流水线使部分软件/用户故障可通过回滚或重启自动恢复;预检机制明显减少了配置错误(如非法并行设置)引发的故障;对网络/硬件故障,自动化诊断与恢复加上慢节点的更快发现,将平均诊断恢复时间压到 30 分钟以内。这些机制还帮助 SRE 团队识别更多潜在故障机器并将其移出调度池。

七、局限与工程教训(我认为是全文最有价值的部分之一)

7.1 误诊是有代价的:XID 31 的教训

部署早期,知识库缺少对特定 GPU XID 错误的细粒度标注。当用户的有 bug 的自定义 CUDA kernel 越界访问内存时,GPU 驱动上报 Xid 31(内存页错误),语义检索将其宽泛地误分类为物理硬件故障,触发了不必要的 pod 驱逐。由于根因在软件侧,新 pod 上的重启任务在同一个训练步再次崩溃,触发误报警循环——浪费数小时算力,还耗尽了健康备用池。

修复方式:穷尽式标注 GPU XID 错误码,明确区分用户触发的软件故障与真实硬件缺陷。未来方向:结合诊断置信度、历史节点健康与预估恢复成本,做出置信度感知的恢复决策,再决定是否升级到昂贵的定位或替换动作。

7.2 有些故障自动化救不了:CUDA OOM

朴素地减小 batch size 或调整内存参数可以避开 OOM,但会降低 MFU、浪费硬件。论文给出了一个真实案例:某推荐模型训练因 CUDA OOM 反复中断,用户多次重启。用 torch memory snapshot 工具人工分析约两天才发现:用户自定义的训练步函数把 loss 返回在输出对象内部,导致 PyTorch 保留了计算图与中间激活,一块 embedding 相关的内存区域始终未释放。这类问题需要对用户代码和框架内存行为的深入理解,指向未来的内存泄漏检测与内存感知代码诊断方向。

7.3 Master Agent 是单点

当前框架依赖 master agent 汇聚信号并协调诊断、定位与恢复。它一旦崩溃或不可达,系统无法自动检测、选举新 master 或继续恢复。改进方向:master 健康监控、leader election、状态复制。

7.4 ETPR 是操作型估计,不是精确记账

健康基线来自"同硬件、相似配置的健康运行",会随模型架构、并行策略、数据分布或代码的变化而漂移。新任务或显著变更的模型需要先重建健康基线,ETPR 才能准确反映 QoP 退化。未来可探索相位与配置感知的基线、以及 ETPR 值的置信度估计。

八、结语与评述

这篇论文的价值在于完成了一个闭环:

度量先行:ETPR 用 SG × DC × QoP 的乘法分解,把"生产力损失"从一个模糊的体感变成可归因、可分层治理的工程指标;
实证支撑设计:三个月 20,629 个任务的数据明确指出——调度不是问题(SG 99.1%),真正的损失在资源分配之后(DC 92.5%、QoP 96.1%),且故障频次与治理成本严重倒挂(74.1% 的事件只占 20.3 分钟/起的恢复成本,而 15.9% 的网络事件要 148.2 分钟/起);
按症下药:三类失效形态各配一条成熟的技术路线——fail-stop 走"最早错误 + 词法/语义/LLM 三级分类",fail-hang 走"心跳 + 多轮栈采样一致性 + 多数投票",fail-slow 走"ACF 相位感知自适应检测 + 通信时长加权的最近启动者评分";
生产验证:四周边部署带来的 +3.8pp ETPR、以及基础设施故障平均恢复时间压进 30 分钟,是可以在生产集群上复现检验的数字。

对正在建设或运营大规模训练集群的团队,这篇论文最具迁移价值的或许不是某个具体算法,而是两个思维方式:先建立可归因的生产力分解,再让每一种损失分量对应一类自动化处置动作;以及把误诊的代价当作一等公民来治理——XID 31 的故事说明,错误的"重动作"(驱逐 pod)比没有动作更危险。

延伸资源

论文原文:Characterizing and Mitigating Productivity Loss in Large-Scale Model Training: An Empirical Study(ASE '26)
相关阅读:《从零搞懂 GPU 集群调度》——本文的 DC 损失对应那篇讲的万卡治理"故障自愈闭环"(DCGM + node-problem-detector + descheduler),本文把它推进到了诊断-恢复流水线的细粒度
相关阅读:《浅谈大规模集群的高性能网络容器化建设》——本文 4.3 节网络故障占比 15.9%、平均诊断 148.2 分钟,那篇讲的 RDMA 组网与 NCCL 验证正是这类故障的第一现场
相关阅读:《Macvlan 在大模型训练中的角色:为 Pod 提供共享 RDMA 通道》——本文 fail-slow 定位依赖的集合通信插桩,落到的正是 NCCL/RoCE 这套网络栈
相关阅读:《Anchor 论文精读:解耦 GPU 内存所有权》——本文回答"损失怎么度量、怎么自动治",Anchor 回答"浅层中断的单次恢复成本怎么压到秒级",故障分级处置思想一脉相承

注:受专有与保密约束,论文中的工业数据集与代码暂未公开。文中所有数据、公式与案例均转述自原论文。