★ FEATURED ARTICLE 大模型模型优化深度学习【免费下载链接】Liger-KernelEfficient Triton Kernels for LLM Training项目地址https://gitcode.com/gh_mirrors/li/Liger-Kernel点击查看免费下载本文是 Liger-Kernel 仓库内liger-kernel-devSkill 中 Validator Agent 工作流的完整技术解读。它面向需要为 Liger Kernel 新增 Triton 算子或修改现有算子的开发者详细拆解从 checkstyle 静态检查、单元测试硬门槛、速度与内存基准测试、绘图、可选的 ncu 性能剖析到最终结果汇报的六步验证流程。读完本文你将掌握如何在仓库中复现整套验证命令、理解每个步骤的通过/失败判定逻辑并能依据仓库源码定位底层测量与数据落盘机制。Validator Agent 的定位开发流水线的第三阶段在 Liger-Kernel 的自动化开发 Skill 体系中新内核的产出遵循三阶段流水线见 SKILL.mdAnalyze分析根据 analyzer.md 生成独立的 PyTorch 参考实现与内核画像profile产出规范见 kernel-profile-format.md。Generate生成按 generator.md 生成/修改最多 8 类文件包括src/liger_kernel/ops/{kernel}.py、src/liger_kernel/transformers/{kernel}.py、test/transformers/test_{kernel}.py、benchmark/scripts/benchmark_{kernel}.py等对应代码模板见 templates/benchmark.md。Validate验证即本文主角 validator.md 定义的六步流程——checkstyle、单元测试、基准测试、绘图、可选的 ncu 剖析、结果汇报。Validator 的职责边界非常明确它不负责设计内核而是负责证伪——通过自动化检查证明新内核在代码风格、数值正确性、性能与显存占用上均达到可合入标准。整条流水线在阶段之间设置了人工检查点Validator 产出的最终结果报告正是开发者在合入前需要审阅的关键材料。Step 1Checkstyle——快速门禁Fast Gate验证从最廉价、最快速的静态检查开始作为第一道快速门禁make checkstyle如果检查失败先尝试自动修复ruff check . --fix ruff format . make checkstyle如果自动修复后仍然失败则需要人工定位并修复剩余问题随后重新运行。从 Makefile 的checkstyle目标可以看到该命令的真实行为它依次执行ruff check --output-formatconcise .lint 检查与ruff format --check --diff .格式检查并记录两者退出码随后执行ruff check . --fix与ruff format .做自动修复若修复前任意一项检查非零退出最终目标整体以退出码 1 失败。也就是说make checkstyle本身就会自动修复风格问题失败与否取决于修复前的原始状态这正是文档中先看make checkstyle是否失败这一逻辑的源码依据。Step 2单元测试——硬门槛Hard Gate代码风格过关后进入真正的正确性验证。针对目标内核运行对应测试文件python -m pytest test/transformers/test_{kernel}.py -xvs其中{kernel}为内核名称测试文件路径与命名遵循 kernel-profile-format.md 中的命名约定如test_dyt.py对应benchmark_dyt.py。仓库test/transformers/目录下现有test_rms_norm.py、test_swiglu.py、test_fused_linear_cross_entropy.py等大量同类测试文件可作为参照。失败时的排查路径文档给出了明确的失败处理顺序仔细阅读错误输出定位根因可能来自四类问题内核逻辑 bug、形状shape不匹配、dtype 问题、容差tolerance过紧在相关文件中修复问题重新运行make checkstyle防止修复引入风格问题重新运行失败的测试。三次重试上限与熔断机制这是整个验证流程中最关键的一条规则总共最多重试 3 次。如果 3 次尝试后测试仍然失败立即停止STOP IMMEDIATELY不得进入基准测试环节并向用户汇报哪些测试失败、确切的错误信息、尝试过哪些修复、当前代码状态以及推测的问题原因请求用户指导。这条硬门槛 熔断设计的合理性在于单元测试未通过即代表内核数值/逻辑不正确此时继续跑基准测试既浪费时间产出的性能数字也没有意义。值得注意仓库为正确性测试提供了统一的批量入口make test见 Makefile会忽略test/convergence、test/cutedsl、test/cutile、test/cute等专项目录后运行全部测试另有test-convergence目标用于在 fp32/bf16 下跑迷你模型收敛性验证Makefile。Step 3基准测试——速度与显存测量单元测试通过后运行基准脚本cd benchmark/scripts python benchmark_{kernel}.py该脚本会产出forward前向、backward反向、full前向反向三种模式下 Liger 内核与 PyTorch 基线对照实现的速度ms与显存MB测量结果。部分脚本支持--overwrite参数用于覆盖已有基准数据。基准脚本的真实结构仓库benchmark/scripts/下现有数十个真实基准脚本如benchmark_rms_norm.py、benchmark_swiglu.py、benchmark_cross_entropy.py可作为编写新基准的模板。以 benchmark_rms_norm.py 为例其结构清晰地展示了基准脚本的骨架定义 PyTorch 参考层如LlamaRMSNorm纯 PyTorch 实现用于对照编写setup_*函数根据SingleBenchmarkRunInput构建输入张量并实例化 Liger/PyTorch 层在__main__中通过parse_benchmark_script_args()解析参数--sweep-mode支持token_length/model_config两种扫描维度--model指定模型配置--bt指定 batch×seq见 utils.py用run_benchmarks分别以forward、backward、full三种模式跑 speed 与 memory 两项指标。底层测量实现测量逻辑位于 utils.py速度测量run_speed_benchmarkutils.py内部调用triton.testing.do_bench并报告 20%/50%/80% 分位数QUANTILES [0.5, 0.2, 0.8]默认 warmup25、rep10三种模式分别对应纯前向、y.backward(do, retain_graphTrue)反向、前向反向的组合。显存测量run_memory_benchmarkutils.py通过torch.cuda.memory.reset_peak_memory_stats()与max_memory_allocated() / 2**20统计峰值显存MB同样给出三档分位数。数据落盘run_benchmarksutils.py将结果写入benchmark/data/all_benchmark_data.csv通过环境变量LIGER_BENCH_TARGET可切换目标 CSV如all_benchmark_data_cutile.csvLIGER_BENCH_PROVIDER_TAG可为 Liger provider 加标签以避免去重键冲突。仓库benchmark/data/下现存all_benchmark_data.csv、all_benchmark_data_cutedsl.csv、all_benchmark_data_cutile.csv三份数据文件。模型配置与扫描范围benchmark_model_configs.py 提供了标准化模型档案ModelConfighidden_size、intermediate_size、vocab_size、dtype 等与注册表MODEL_REGISTRY含llama_2_7b、llama_3_8b、qwen2.5_7b、qwen2.5_72b、deepseek_v2_lite、deepseek_v3等默认配置为llama_3_8b。estimate_kernel_peak_memorybenchmark_model_configs.py通过一次前向反向探针自动估算峰值显存进而由compute_*_sweep_config系列函数自动推导安全的扫描范围避免 OOM。基准脚本模板中的关键规则见 templates/benchmark.md包括对照实现从测试文件导入而非重复编写、支持liger/torch/torch_compile三种 provider、使用统一的run_speed_benchmark/run_memory_benchmark、默认BT 4096、统一使用模型档案中的单一 dtype通常为torch.bfloat16——多 dtype 的正确性交由单元测试覆盖而非基准测试。Step 4生成性能图表基准数据产出后生成可视化图表python benchmark/benchmarks_visualizer.py图表保存至benchmark/visualizations/目录。文档特别说明如果可视化脚本运行失败或不可用该步骤不阻塞流程non-blocking直接汇报原始数值即可。这是整个流程中唯一明确标记为可选的自动步骤体现了验证流程保底可用、快速收敛的务实取向。Step 5可选的 ncu 性能剖析只有在用户明确要求时才执行此步且要求本机已安装 NVIDIA Nsight Computencu。剖析命令同时覆盖 Liger 内核与 PyTorch 参考实现ncu --set full --target-processes all -o liger_profile python -c import torch from liger_kernel.ops.{kernel} import Liger{Kernel}Function x torch.randn(..., devicecuda, dtypetorch.float32, requires_gradTrue) out Liger{Kernel}Function.apply(x, ...) out.backward(torch.randn_like(out)) 需要注意两点剖析入口是 ops 层的Liger{Kernel}Functionautograd Function类名遵循 kernel-profile-format.md 的Liger{PascalCase}Function命名约定而非 transformers 层的 nn.Module 包装剖析输出需报告关键指标SM 占用率SM occupancy、显存吞吐memory throughput、计算吞吐compute throughput。如果ncu不可用如实汇报并跳过此步。该 Skill 目录下附带真实剖析示例如 examples/cross-entropy-profile.md、examples/rms-norm-profile.md、examples/swiglu-profile.md分别对应三类复杂度fused/complex、reduction、element-wise内核的剖析格式参考。Step 6结果汇报最终向用户输出结构化总结格式如下## Results **Checkstyle:** PASS **Unit Tests:** PASS (X tests passed) **Speed Benchmarks:** | Mode | Liger (ms) | PyTorch (ms) | Speedup | |----------|-----------|-------------|---------| | Forward | ... | ... | ...x | | Backward | ... | ... | ...x | | Full | ... | ... | ...x | **Memory Benchmarks:** | Mode | Liger (MB) | PyTorch (MB) | Savings | |----------|-----------|-------------|---------| | Forward | ... | ... | ...% | | Backward | ... | ... | ...% | | Full | ... | ... | ...% | **Assessment:** [Which dimension improved — speed, memory, or both. Flag if either metric is catastrophically worse.] **Plots:** benchmark/visualizations/ **ncu Profiling:** [Results if requested, or Not requested]报告模板要求两件事Assessment 评估段必须明确说明改进发生在速度、显存还是两者兼有若任一指标出现灾难性劣化catastrophically worse必须明确标注——这保证了性能回归不会被掩盖三个结果区块Checkstyle、Unit Tests、Benchmarks/Plots/ncu分层呈现便于开发者与审阅者快速定位问题。验证流程全景门禁与熔断的工程价值将六步串起来看Validator 工作流体现了一套典型的廉价检查先行、昂贵检查后置、失败快速熔断工程策略成本递增checkstyle秒级→ 单元测试分钟级→ 基准测试分钟到小时级→ ncu 剖析最昂贵、需显式授权两道硬门槛Checkstyle 失败即停止自动修复/人工修复单元测试 3 次失败即整体熔断禁止进入基准阶段一处可降级绘图失败不阻塞退回原始数值汇报一处可选ncu 剖析仅在用户显式请求时执行。任何为 Liger-Kernel 贡献新 Triton 内核的开发者都可以把本文的六步流程固化为自己的合入前自检清单而阅读 Makefile、benchmark/scripts/utils.py、benchmark/scripts/benchmark_model_configs.py 与benchmark/scripts/下的真实基准脚本则能进一步理解每一条命令背后的具体测量与数据语义从而在遇到异常结果时快速定位是测量问题、数值问题还是性能问题。赞分享大模型模型优化深度学习【免费下载链接】Liger-KernelEfficient Triton Kernels for LLM Training项目地址https://gitcode.com/gh_mirrors/li/Liger-Kernel点击查看免费下载相关推荐Liger-Kernel Validator Agent 工作流指南Monkey-Patch 生成代码的迭代验证与修复Liger Kernel Validator Agent 工作流指南Monkey Patch 生成代码的迭代验证与修复 导读 本文是 Liger Kernel大模型模型优化深度学习RuView Beyond-SOTA 验证方法论六层验证金字塔与可证伪的基准测试体系RuView Beyond SOTA 验证方法论六层验证金字塔与可证伪的基准测试体系 导读 本篇技术文章围绕 RuView 开源仓库中关于超越 SOTA 声人工智能计算机视觉物联网智能家居后端嵌入式程序集绑定调试革命为什么Fusion是.NET开发者必须掌握的现代化工具程序集绑定调试革命为什么Fusion是.NET开发者必须掌握的现代化工具 深夜当你的.NET应用程序在关键时刻崩溃屏幕上显示着令人困惑的无法加载文上一篇Tiny11Builder 完整指南把 Windows 11 原版 ISO 瘦成一张精简系统镜像下一篇LAV Filters彻底解决Windows视频播放难题的终极方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
