Liger Kernel：用融合 Triton 算子压低 LLM 训练的显存峰值与耗时

1. 摘要与一句话判断

3 分钟速读

1. 问题：PyTorch eager 逐步执行带来调用栈、dispatch、kernel 启动时延，且为反向物化全部中间激活；HBM 与片上 SRAM 之间的频繁拷贝是核心瓶颈；大词表模型的 logits 张量物化成为训练显存的主要尖峰 P（第 1-2 页 §2、第 6 页 §3.2）。
2. 方案：一套面向 LLM 训练的融合 Triton kernel 库（最小依赖 PyTorch + Triton），三层 API（自动补丁 / 模型专用补丁 / 单算子拼装），配合 FusedLinearCrossEntropy 的分块 logit 消费；与 FSDP、DeepSpeed ZeRO/ZeRO++ 正交叠加 P（第 1、3-7 页）。
3. 论文声称的主要结果：相对 HuggingFace 实现，平均吞吐 +20%、GPU 显存 −60%（摘要）；端到端逐模型为 LLaMA 3-8B +42.8%/−54.8%（batch 64）、Qwen2 +25.5%/−56.8%（batch 48）、Gemma +11.9%/−51.8%（batch 48）、Mistral +27%/−21%（batch 128）、Phi3 +17%/−13%（batch 128） P（第 1 页摘要、第 10 页 §4.2；条件见 #experiments）。
4. 质量护栏：论文把 exactness 视为不可妥协项：正确性容差测试（fp32/bf16 两档）、性能基准、小规模收敛测试、连续性检查四类实践内建，且摘要称集成测试内建（built-in） P（第 1 页摘要、第 7-8 页 §3.3）。
5. 主要限制：全部数字来自 A100 80GB + bfloat16 + v0.2.1；端到端序列长固定 512、20 步采样；基线只有 HuggingFace eager（未对比 torch.compile 等）；结果仅以图呈现、无数据表；Medusa 场景只有定性结论 P（第 9-14 页）+ I（公平性归纳）。

2. 问题背景

执行开销与显存开销同源：论文把 LLM 训练的低效归结到两点——eager 模式逐步执行带来的函数调用栈、dispatching 与 CUDA kernel 启动时延，以及「为反向而物化每一个中间激活」的显存占用 P（第 1-2 页 §2）。I 对架构师而言，这意味着微调作业的「OOM 上限」往往不是权重，而是激活与 logits 的临时峰值。

硬件层瓶颈：自定义算子融合的主要目标是缓解 HBM（大而慢）与片上 SRAM（快而小）之间频繁内存拷贝的瓶颈：SM 需要快速取数才能让多线程并行，等 HBM 送数时计算核心空闲；该问题在Transformer类大矩阵、多算子场景更严重 P（第 2 页 §2.2，引 Wen-Mei et al. 2022）。

既有三条路线与 Liger 的站位：P（第 2-3 页 §2.1-§2.3）

1. 模型编译器：torch.compile（PyTorch 2.0 JIT 捕图 → Triton/C++ 代码生成）、Apache TVM、XLA、nvFuser——泛化的图级优化，覆盖面广但对特定计算模式的针对性弱于手写融合。
2. 算法视角的融合：以 FlashAttention/FlashAttention-2 为代表，把注意力分块放进 SRAM、免整张注意力矩阵物化，显存复杂度从二次方降到线性——针对性精确、收益更大。
3. 手写 Triton 融合生态：xFormers（Meta）、FlashAttention 仓库（除 CUDA attention 外还含 layer norm、linear+squared ReLU 融合等 Triton/torch.script 组件）、Unsloth（重写流行 LLM 与 LoRA 层）、EfficientCrossEntropy（线性投影与 CE 融合、分块算损失以免物化整张 logits）；Liger 明言「借鉴并复用上述项目的代码」。

目标工作负载与约束：LLM 训练（论文实验以微调为主）；要求最小依赖（仅 PyTorch + Triton）；兼容 PyTorch FSDP、DeepSpeed ZeRO、ZeRO++ 等分布式框架 P（第 1 页 §1）。基线口径：性能对比基线为 HuggingFace 实现（eager 模型代码） P（第 1 页摘要、第 9 页图 2/图 3 图例）。I 论文未对比 torch.compile 或其他融合路线，属于其评测边界（见 #experiments 公平性说明）。

3. 核心机制

3.1 三层级 API：对现有代码扰动最小

1. 自动补丁：AutoLigerKernelForCausalLM.from_pretrained(...)——模型类型受支持即自动改写 modeling 代码，无需模型专用导入 P（第 3 页 §3.1）。
2. 模型专用补丁：如 apply_liger_kernel_to_llama()，加载模型前细粒度替换；适用于 causal LM 之外的形态（如序列分类） P（第 3 页 §3.1）。
3. 单算子拼装：高级用户直接使用 LigerLayerNorm、LigerCrossEntropyLoss 等组件自组模型 P（第 3 页 §3.1）。

I 三层 API 的运维含义：接入强度与回退粒度一一对应——自动补丁最容易整体开关，单算子拼装则支持「只替换风险最低的算子」的灰度策略（见 #security-ops）。

3.2 kernel 通用骨架

• 所有 kernel 把输入/输出整形为 (B×T, H) 二维矩阵（B=batch、T=序列长、H=隐维度），kernel 内由 Triton 按输入行并行；warp 数按 block size 计算（复用 Unsloth 的 calculate_settings） P（第 4 页 §3.2 与脚注 6）。
• 反向推导以「单行输入 x → 输出 y → ∇_yL」为单位展开，共享参数（γ/β）的梯度再按 batch 累加 P（第 4 页 §3.2）。

3.3 算子覆盖：论文实现与评估的 7 个 kernel

FLCE 的分块尺寸（提取文本在此处错序，已按原页更正）：P（第 7 页）

P 由于所有 chunk 共用投影权重 W，最终梯度需按块累加；mean reduction 的 CE 逐块计算不天然归一到全序列，Remark 以 chunk_size/(B×T) 比例补缩放修正该近似（第 7 页）。I 该「缩放校正」说明 FLCE 在数值上是对整批 CE 的受控近似，升级或复现时应保留论文的校正口径并跑收敛对照。

3.4 质量护栏：四类测试实践

• 正确性：对照纯 PyTorch/HuggingFace 实现，覆盖规则（2 的幂）与不规则形状、多种 dtype；容差 fp32 atol=1e-7 / rtol=1e-5，bf16 atol=1e-3 / rtol=1e-2；实践中容差可能需再放宽 1-2 个数量级（即使对 exact kernel），此时以收敛测试兜底（脚注 12） P（第 8 页 §3.3.1）。
• int32 溢出陷阱：program id 默认 int32，program_id × Y_stride > 2,147,483,647 时变负导致非法内存访问；大维度须显式转 int64 P（第 8 页 §3.3.1）。
• 性能：以速度与显存两维证明「重写为 Triton」是值得的；测试形状取自真实训练（如 batch 4、hidden 2048、可变序列长） P（第 8 页 §3.3.2）。
• 收敛与连续性：小规模模拟真实训练中 contiguity/shape/dtype 差异，校验训练结束时 logits、权重、loss 的 exactness；Triton 直接操作物理内存，非连续张量可致非法访问或错误输出——生产 RoPE 曾因 scaled_dot_product_attention 导数非连续而显著 loss 发散 P（第 8 页 §3.3.3-§3.3.4）。

3.5 训练框架接入

• 论文 §3.4 列出的集成：HuggingFace transformers Trainer、HuggingFace TRL SFTTrainer、Axolotl、LLaMA-Factory；通常一个标志即可，例如 TRL 的 SFTConfig(..., use_liger=True) 会经 AutoLigerKernelForCausalLM 加载模型（示例模型 meta-llama/Meta-Llama-3-8B） P（第 8 页 §3.4 与脚注 13-16）。
• 边界提示：PyTorch Lightning 集成仅出现在第 15 页 §6.1 贡献者分工中，§3.4 未列入——引用时不应把它与上述四个集成等同 P（第 15 页）+ I。
• 分布式兼容：kernel 级替换与并行策略正交，支持 FSDP、DeepSpeed ZeRO、ZeRO++ P（第 1 页 §1）。

4. GPU/系统数据路径

端到端文字序列（①–⑥；与图中分层 ①–⑤ 的对应关系见图注）

1. ① 接入层（控制面）：训练作业以三层 API 之一启动——AutoLigerKernelForCausalLM 自动补丁、模型专用补丁（如 apply_liger_kernel_to_llama()）或单算子拼装；框架形态下由 use_liger=True 等标志触发 P（第 3 页 §3.1、第 8 页 §3.4）。
2. ② 张量整形：被替换算子的输入/输出统一整形为 (B×T, H) 二维矩阵，kernel 按行并行、warp 数由 block size 推导 P（第 4 页 §3.2）。
3. ③ 融合执行（数据面核心）：每个融合 kernel 把一行数据一次载入片上 SRAM，完成「归一化+缩放」「旋转」「门控激活」等原本多个算子的正反向计算，缓存反向所需中间量（RMS、inverse RMS），把对 HBM 的多次往返压缩为最少读写 P（第 2 页 §2.2、第 4-6 页 §3.2）；SwiGLU/GeGLU 反向以重算换显存 P（第 5-6、9 页）。
4. ④ 大词表损失路径（FLCE）：已对齐标签的隐状态折叠为 (B×T, H) → 逐块过线性投影头得块 logits（chunk_size = 2^⌈log₂⌈BT/⌈V/H⌉⌉⌉）→ 非融合 CE kernel（在线 softmax）逐块算部分损失并就地把块 logits 替换为块 logits 梯度 → 回传得块隐状态梯度、累加投影头梯度 ∇_WL = Σ h(∇_xL)^⊤，并按 chunk_size/(B×T) 补缩放 P（第 6-7 页 §3.2、图 1、Remark）。
5. ⑤ 梯度归约交还框架：Liger 只替换算子内部执行；参数梯度写出后，all-gather/reduce-scatter/allreduce 等分布式归约仍由 FSDP、DeepSpeed ZeRO/ZeRO++ 完成 P（第 1 页 §1）+ I（职责边界解读）。
6. ⑥ 测试闸门（旁路）：接入前后跑正确性（容差制）、性能、收敛、连续性四类检查；摘要称基准与集成测试内建（built-in） P（第 1 页摘要、第 7-8 页 §3.3）。

5. 架构权衡

• 显存 ↔ 重算

  P SwiGLU/GeGLU 反向重算 SiLU/GELU 输出，峰值显存约降 1.6×，但速度只与基线持平（第 9 页 §4.1）。I 属「以算力换显存」：算力富余、显存吃紧的场景收益最大；算力已打满的作业收益有限。

• 速度与显存双降 ↔ 场景依赖

  P CE（vocab 163840）约 3× 提速 + 5× 省显存、RMSNorm 约 7×/3×、RoPE 约 8×/3×，但均在特定词表/隐维度下测得（第 9-10 页）。I 词表或隐维度越小，倍数越低（论文图 2/3 的曲线随维度收窄）；不能以最大维度倍数外推小模型。

• CE 就地替换 ↔ FLCE 分块

  P CE 就地替换免双份大张量但单张 logits 仍驻留；FLCE 让整张 logits 不物化，代价是多趟分块 GEMM 与 chunk_size/(B×T) 缩放校正（第 6-7 页）。I 论文以「投影层计算密集、分块 GEMM 开销可被压缩」论证近乎无损（第 7 页），但未给出两者直接对比数据。

• 接入低扰动 ↔ 模型代码版本耦合

  P 补丁式接入「对现有代码库扰动最小」（第 3 页），但 RoPE 假设 HF 形式的旋转矩阵（脚注 9 指向 v4.44.2 源码行）、SwiGLU 仅支持 β=1 等 HF 惯例（第 5 页）。I patch 本质是对 modeling 代码的运行时改写，transformers 大版本升级是主要回归风险源，需联动测试。

• 连续性不变量 ↔ 通用性

  P Triton 直接操作物理内存，非连续张量可致非法访问或错误输出；生产 RoPE 曾因 SDPA 导数非连续而 loss 发散（第 8 页 §3.3.4）。I 任何自定义模型/非常规并行组合（如改变梯度布局的并行策略）接入前都要做连续性审计与收敛冒烟。

• Triton 轻依赖可移植 ↔ JIT 与调优深度

  P Triton 的 Python 语法与 JIT 编译让库更轻量、可移植（第 2 页 §2.3）。I 代价方向：首次运行/新形状触发 JIT 编译等待；手写 Triton kernel 的调优深度通常以「已测形状族」为界，超出论文测试分布的形状收益需自测（论文未披露其他形状的结果）。

• exactness 目标 ↔ 容差现实

  P 论文宣称 exactness 不可妥协，但正确性以容差制验收（bf16 atol=1e-3/rtol=1e-2），且实践中可能再放宽 1-2 个数量级，以收敛测试兜底（第 8 页 §3.3.1 与脚注 12）。I 对「与 HF 实现逐位一致」有硬性要求的场景（如确定性回归测试）需另行评估。

6. 云上部署映射

以下映射为厂商中立示例；具体产品命名/规格仅作说明并标 E，以厂商当时目录为准，未逐一在线核验。论文事实单独标注 P。

7. 成本 / 性能 / SLO

7.1 微调场景的「SLO」口径

论文采集的指标是训练吞吐与 GPU 显存占用（20 步后采样、5 次重复取标准误差） P（第 10 页 §4.2）。I 平台侧通常转化为：①tokens/s 或 step 时间目标；②峰值显存上限（决定 batch/序列上限与选卡）；③loss 收敛里程碑（判废标准）；④OOM 率。第③④项论文未直接给平台化指标，需自建。

7.2 成本公式（参数化，编辑推断）

I 公式中由论文支撑的只有 Δt/Δm 的实验取值区间（带完整条件，见 #experiments）；单价、数据管道与存储成本论文未披露，本页不给伪精确数字。

7.3 敏感项排序（论文口径，条件互不可比）

P 显存敏感项首位是大词表 logits（Gemma 例：256k 词表、batch 8、seq 4096、bf16 下仅 logits 16.8 GB，第 6 页）；端到端显存降幅随模型从 −13%（Phi3）到 −56.8%（Qwen2）不等（第 10 页）。I 成本含义：词表越大、批量越大，Liger 的显存杠杆越值钱；显存本来就小的模型（如 Phi3 在该负载下）收益有限。

7.4 数据缺口

• 端到端 TCO、云价格、能耗：I 论文未披露，需部署时自测。
• FLCE 与非融合 CE 的直接对比数据、不同 GPU 架构（H100/AMD）数据：P 论文未明确披露（实验仅 A100 80GB）。
• 长序列端到端收益：E2E 实验固定 seq 512（第 10 页）；kernel 级虽测到 seq 16384（第 9 页），但两者口径不同、不能拼接出「长序列端到端收益 X%」。
• Qwen2、Phi3 的模型规格：P 论文未明确披露（Gemma 7b、Mistral 7b 仅见图注，第 12 页）。

8. 安全与可运维性

8.1 安全

• 供应链与许可：R 官方仓库 linkedin/Liger-Kernel，BSD-2-Clause（2026-09-15 核验）；二次分发需保留许可声明。I 依赖链为 liger-kernel + triton + torch + transformers，建议版本/commit 三重 pin + CVE 扫描；Triton JIT 编译产物缓存目录应纳入镜像层管理并限制写权限。
• 论文时点 vs 仓库演进：P 论文口径是 v0.2.1（第 9 页脚注 17）；R 仓库 README 当前能力（更多模型 patch、DPO/ORPO/CPO/SimPO/KTO 损失 kernel、cuTile/CuTe DSL 后端等）已超出论文（2026-09-15 核验）。I 评估、审计与安全扫描都应以「实际 pin 的那个版本」为对象，不得按论文或 README 文案外推。
• 训练数据合规：论文实验用 Alpaca 指令数据集（E2E）与 tiny shakespeare（收敛测试设计参考） P（第 10、15 页）。I 生产替换为自有语料前需完成许可/隐私/版权审查；Liger 本身不接触数据面内容，不新增数据合规面。
• 租户隔离：I Liger 是进程内算子库，无网络服务、无共享状态，不引入跨租户数据残留面；隔离责任仍在训练平台（作业沙箱、存储桶权限）。

8.2 可运维性

• 接入即灰度、回退即开关：P 补丁式设计与框架标志（use_liger）意味着「关闭标志即回到 HF 实现」（第 3、8 页）。I 建议作业模板把 Liger 开关做成一等配置：新模型族先单作业灰度，通过正确性/收敛对照再全量；回退预案＝关开关 + 记录版本组合。
• 上线前四闸门：P 正确性（容差）、性能（速度+显存）、收敛（小规模端到端校验 logits/权重/loss）、连续性（张量连续审计）是论文自述实践（第 7-8 页 §3.3）；摘要称基准与集成测试内建 P（第 1 页）。I 平台应把它们固化为接入新模型/新版本时的强制检查单，尤其连续性——论文记录过 RoPE 因 SDPA 导数非连续而 loss 发散的生产事故。
• 版本联动升级：P RoPE 假设 HF 旋转矩阵形式（脚注 9）、SwiGLU 按 HF 惯例仅 β=1（第 5 页）。I transformers 大版本升级应与 liger-kernel 升级联动演练，回归项包含收敛对照；「旧版本写出的检查点 → 新版本读取」在算子层透明（权重语义不变），但仍建议纳入常规升级演练。
• 监控告警：I 建议告警：loss 突变/发散（对应连续性与数值风险）、step 时间相对基线漂移（kernel 未生效或退化）、峰值显存与 OOM 率（验证容量收益）、JIT 编译等待（首步时延尖峰）。论文未提供平台化监控方案，以上为工程建议。
• 已知陷阱速查：P int32 program id 溢出（>2,147,483,647，第 8 页）；容差需按 dtype 分档并允许放宽（第 8 页脚注 12）；Medusa 等多头场景无 Liger 时极易 OOM（第 13 页）。I 建议写入平台 runbook。

9. 适用 / 不适用场景

适用（触发条件 + 理由）

1. 大词表 LLM（128k–256k 级）微调且显存被 logits/激活顶爆。触发：OOM 发生在 loss 计算附近、或 forward 末端显存尖峰。理由：FLCE 免整张 logits 物化，论文给出 16.8 GB logits 例与约 5× 省显存（CE，vocab 163840）P（第 6、9 页）。
2. 已在用 HF Trainer / TRL SFTTrainer / Axolotl / LLaMA-Factory 的微调管线。触发：希望零代码或一个标志接入。理由：论文明确列出四处集成并给出 use_liger 示例 P（第 8 页 §3.4）。
3. 显存受限要换小卡，或同卡想加大 batch / 加长序列。触发：容量规划需要显存余量。理由：论文把「更小 GPU、更大 batch、更长序列」列为显存释放的直接用途 P（第 10 页 §4.2）。
4. Medusa 类多解码头/多 token 预测训练。触发：逐头 logits 物化导致 OOM。理由：FLCE 免逐头 logits 物化，LLaMA-3 128k 词表下 stage-1/stage-2 均降显存升吞吐，无 Liger 极易 OOM P（第 13 页）。
5. FSDP / DeepSpeed ZeRO / ZeRO++ 用户想叠加算子层优化。触发：并行策略已定、不想改动分布式配置。理由：kernel 替换与分布式框架正交 P（第 1 页 §1）。
6. 对训练质量敏感、需要可验证性的团队。触发：要求接入有 correctness/convergence 证据链。理由：四类测试实践与内建基准/集成测试 P（第 1 页摘要、第 7-8 页 §3.3）。

不适用（触发条件 + 理由）

1. 期望推理加速的开箱收益。触发：拿训练 kernel 库直接优化 serving。理由：论文范畴是训练，仅结尾一句称技术可延伸到推理、无任何推理实验 P（第 14-15 页 §5）+ I。
2. 把论文数字外推到未测硬件/精度/规模。触发：H100/AMD/FP8、或大于 8 卡的场景直接引用本文百分比。理由：全部实验仅 A100 80GB、bfloat16、v0.2.1 P（第 9-14 页）；I 仓库虽列出更多硬件方向，但论文数字不适用。
3. 要求与 HF 实现逐位一致（bit-exact）的流程。触发：确定性回归测试或审计要求逐位复现。理由：正确性为容差制（bf16 atol=1e-3/rtol=1e-2）且允许放宽 1-2 个数量级 P（第 8 页 §3.3.1 与脚注 12）。
4. 无法保证张量连续性的自定义管线。触发：自定义模型/并行组合产生非连续中间量且不可改造。理由：Triton 直接操作物理内存，非连续可致非法访问或错误输出，论文有 RoPE loss 发散的生产案例 P（第 8 页 §3.3.4）。
5. 模型族不在 patch 支持范围且不愿自行拼装 kernel。触发：非主流架构、或 HF modeling 实现与 Liger 假设不一致。理由：自动补丁的前提是「模型类型受支持」（论文未给清单）P（第 3 页 §3.1）；R 支持清单需查仓库当前版本（2026-09-15 核验）。
6. 把 Liger 当作集群级训练系统。触发：期望它解决通信、容错、调度问题。理由：它是算子层库，不含集群控制面 P（第 1、3 页）；I 集群级需求见站内 MegaScale/TorchTitan 类系统论文。

10. 实验与指标

10.1 三套互不可混用的实验口径 P（第 9-14 页 §4）

10.2 kernel 级结果（正文倍数转录，条件逐条完整）

I 注意：以上为论文正文给出的约数（approximately）；图 2/3 为折线图、无数据表，逐点数值不可转录。精度字段：kernel 基准的精度论文未明确披露（仅端到端实验注明 bfloat16）。

10.3 端到端微调结果（正文百分比转录）

10.4 Medusa 多头训练结果

P 论文正文只给定性结论：Medusa 训练分两种情形（stage-1 只训新增头、stage-2 骨干与头同训），论文称两种情形均已基准化、Liger「降低显存、提升吞吐」；无 Liger 时实验极易 OOM；图 9-12 重复实验标准误差通常 <1%（第 13 页）。I 读图观察（近似值，非论文文字）：有对比柱的组合中 Liger 显存柱均更低；但吞吐并非处处更高——seq 1024 处 HuggingFace 吞吐与 Liger 持平或更高（图 9 约 47k vs 41k、图 10 约 36.5k vs 31k、图 12 约 18.2k vs 17.8k tokens/s，图 11 该点两者接近），Liger 的吞吐优势出现在 seq 2048 及 HF 因 OOM 无柱的组合。OOM 组合（读图）：图 9/11（3 头）HF 在 seq 4096 OOM；图 10/12（5 头）HF 在 seq 2048 与 4096 OOM；Liger 完成全部组合（第 13-14 页）。论文未给出 Medusa 场景的百分比数字——任何「Medusa 提速 X%」都不是论文结论。

10.5 公平性限制（引用前必读）

10.6 建议复现步骤（编辑推断）

1. I 环境 pin：liger-kernel v0.2.1（或选定 commit）+ 对应 torch/triton/transformers 版本，容器 digest 固化；4×A100 80GB。
2. I 用仓库 examples/huggingface 基准脚本（论文脚注 18 给出路径）按 §4.2 口径跑：Alpaca、bf16、AdamW+cosine、seq 512、目标 batch（如 64/48/128），20 步后采样吞吐与显存，重复 5 次记标准误差，与图 4-8 数量级对照 P（第 10 页）。
3. I 开/关 Liger 各跑一次小规模收敛对照（校验 logits/权重/loss），对齐论文收敛测试实践 P（第 8 页 §3.3.3）。
4. I 用真实业务模型/序列/词表复测：先 kernel 级（正确性容差 + 速度/显存），再端到端灰度；记录连续性审计结论。
5. I 把「开关、版本组合、吞吐/显存/收敛证据」写入作业模板与平台容量档案，形成可回退配置。

11. 论文 / 代码 / 延伸链接

12. 给架构师的决策清单

I 以下为落地前的勾选项；标注（P）的条目对应论文证据，（R）对应仓库核验，其余为工程判断。

• 需求与规模
  • 确认痛点是显存峰值（logits/激活）而非网络或调度——Liger 只解算子层（P：第 1-2、6 页）
  • 明确目标模型词表规模与 batch/序列计划；词表 ≥128k 时 FLCE 收益预期最高（P：第 6 页；I：外推判断）
  • 确认目标是训练/微调；推理加速需求另行选型（P：第 14-15 页 §5）
• 兼容性
  • 模型族在 Liger 支持范围内（查当前仓库清单）；否则评估单算子拼装路径（P：第 3 页 §3.1；R：README 2026-09-15）
  • transformers/torch/triton 版本组合可 pin；RoPE 旋转矩阵形式与新版 modeling 实现一致（P：第 5 页脚注 9；I：版本策略）
  • 分布式策略（FSDP/ZeRO/ZeRO++）与 kernel 替换正交性在本集群验证（P：第 1 页 §1）
  • 自定义模型的中间张量连续性可保证或可加 .contiguous()（P：第 8 页 §3.3.4）
• PoC（1-2 周量级）
  • 按 §10.6 用 examples/huggingface 脚本复现一批端到端数字，与论文同数量级（P：第 10 页脚注 18；I：验收阈值自定）
  • 开/关 Liger 各跑一次收敛对照（logits/权重/loss 校验）（P：第 8 页 §3.3.3；I：方法）
  • 跑一遍 correctness/perf/convergence/contiguity 四闸门并留档（P：第 7-8 页 §3.3）
  • 大词表模型单独验证 FLCE 路径与显存峰值曲线（P：第 6-7 页；I：验证设计）
• 容量与选型
  • 用实测峰值显存重算 batch/序列上限，评估「同卡加大 batch」与「降档换卡」两条路径的性价比（P：第 10 页；I：容量模型）
  • 不用论文百分比直接做容量承诺；按自有负载实测（I）
• SLO 与质量
  • 定义吞吐/步时延 SLO 与采样口径（对齐「20 步后采样、5 次重复」式的方法学，P：第 10 页）
  • 定义 loss 收敛里程碑与判废标准（含 Gemma 式图文张力的复核意识，P：第 10/12 页；I：口径治理）
  • 明确容差预期（bf16 atol=1e-3/rtol=1e-2 量级），对逐位一致需求提前声明（P：第 8 页）
• 成本
  • 按 §7.2 公式以当时单价估算，记录查询日期；不用本页数字报价（I）
  • 把「显存释放 → 降档换卡/加大 batch」写入成本敏感项，标注条件（P：第 10 页；I：解读）
• 安全
  • liger-kernel/triton/torch/transformers 版本 pin + CVE 扫描；BSD-2-Clause 合规分发（R：2026-09-15；I：供应链流程）
  • 训练语料合规审查（论文用 Alpaca 仅为实验口径）（P：第 10 页；I：合规要求）
• 运维与回滚
  • Liger 开关纳入作业模板一等配置；灰度 → 全量 → 可秒级回退（P：标志机制第 8 页；I：流程）
  • 监控：loss 突变、step 时延漂移、峰值显存/OOM 率、首步 JIT 编译等待（I）
  • 升级演练：transformers/liger 联动升级 + 收敛对照 + 检查点读取回归（I；机制 P：第 5 页脚注 9）
  • 已知陷阱写入 runbook：int32 溢出、连续性、容差分档（P：第 8 页）
• 退出策略
  • 回退面评估：关闭标志即恢复 HF 算子，权重语义不变、检查点通用（P：第 3、8 页；I：迁移成本结论）
  • 归档版本组合、开关状态、对照实验证据，保证可重建可审计（I）

13. 证据台账

下表为核心结论的证据映射；逐条引文与在线核验记录见构建文件 sources/liger-kernel.evidence.json。核验日期均为 2026-09-15。