尧图网站建设 
flash-linear-attention 的 MR/PR 就绪流程从依赖测试定位到 CI 强制 PR 模板的完整操作指南【免费下载链接】flash-linear-attention Efficient implementations for emerging model architectures项目地址: https://gitcode.com/GitHub_Trending/fl/flash-linear-attention本文围绕 flash-linear-attentionFLA仓库中的fla-mr-readiness技能文档展开完整讲解提交 Pull Request 前的七步预检清单、CI 强制的 PR 正文结构以及各步骤背后的仓库实现——scripts/find_dependent_tests.py的依赖追踪算法、check-pr-title工作流的校验正则、fla.utils设备封装等。读完后你将能够在 FLA 仓库中独立完成一次范围清晰、测试充分、证据完整、格式合规的 MR 提交并理解每一步检查在 CI 层面如何被强制执行。这个技能文档解决什么问题FLA 仓库在.agents/skills/fla-mr-readiness/SKILL.md中定义了 MR/PR 就绪检查清单覆盖四件事CONTRIBUTING.md合规性、测试计划、性能证据、PR 正文结构。它的定位在AGENTS.md中有明确说明——在打开任何 PR 之前都应加载该技能fla-mr-readiness— Preparing MR/PR, test plans, and contribution compliance在.agents/skills/README.md的技能总表中它与其他技能分工协作涉及内核优化循环时加载fla-optimization-loop涉及 NVIDIA 性能剖析时加载fla-nvidia-performance技能文档而fla-mr-readiness是提交动作本身的最后一道闸门。技能文档给出的预检清单共 7 步下面按顺序逐一展开并结合仓库源码说明每一步的底层支撑。第一步通读 CONTRIBUTING.md确认分支状态清单第 1 条要求确认三件事代码风格、docstring 格式、commit message 约定以及确认你的分支已与main或目标分支保持同步。CONTRIBUTING.md的 Core Principles 一节是每个 PR 的验收标尺其中与提交准备直接相关的几条包括数值对齐参考实现每个优化内核必须与 naive 参考实现在assert_close容差内一致纯重构改动必须保证输出和梯度均不变要实测 before/after 而不是假设触碰共享代码时审计全部调用点改一个符号、配置字段或公共内核意味着要在一次提交中更新它的所有使用处保护成熟路径、最小化 diff只改修复或特性真正需要的部分不要顺手重写可用代码。commit message 需要带方括号前缀标签CONTRIBUTING.md给出了常用标签表[Fix]、[Perf]、[Ops]、[Model]、[Layer]、[Attn]、[KDA]、[CP]等不属于任何类别时以[Misc]/[chore]兜底。这个约定并非只是惯例CI 的check-pr-title工作流会用正则^\[[A-Za-z][A-Za-z0-9]*\][[:space:]].强制校验 PR 标题必须以[Tag] 文本开头不符合即失败。第二步确认变更范围声明跨层依赖链清单第 2 条要求列出你修改的文件并在变更跨多层如 kernel model benchmark script时在 PR 描述中写明依赖链。FLA 的目录组织天然形成这种依赖链fla/ops/Triton 内核→fla/layers/PyTorch 层→fla/models/完整模型CONTRIBUTING.md的核心原则第 4 条也据此要求显式判断公共接口是否需要变更。第三步查重避免重复劳动清单第 3 条要求在开工/开 PR 前搜索 open issues 和 PRsgh pr list --repo fla-org/flash-linear-attention --state open --search keywords若发现相关 PR 已存在应去该 PR 下评论而不是另开一个竞争性 PR。这一点与AGENTS.mdOpening PRs 一节的要求一致Check for duplicates first … so you dont redo in-flight work且该文档还补充了查重之外的提交纪律不提交Co-Authored-By等工具署名行、开 PR 前用 grep 确认 diff 中不含已被主线路径禁用的tl.make_block_ptr/tl.advance。第四步用 find_dependent_tests.py 定位并运行受影响的测试清单第 4 条是测试环节的核心命令python scripts/find_dependent_tests.py changed_file_or_dir运行输出的测试文件列表后需在本地跑通如果某个测试不稳定flaky清单要求最多重试一次仍失败则必须在 PR 中解释原因。这个脚本的实现在scripts/find_dependent_tests.py值得从源码层面理解它如何精准而非全量地选出测试基于 AST 的符号级追踪脚本用ast解析fla/下所有源码与tests/下所有测试建立文件 → 定义符号和文件 → 导入符号两张映射DependencyFinder.__init__然后从变更文件定义的符号出发按 import 关系逐层向外扩散max_depth4。这样改一个内核函数只会牵连真正 import 它的测试文件而不是整个tests/ops/。modeling/configuration 联动启发式检测到modeling_name.py变更时会自动把同目录的configuration_name.py一并纳入追踪find_dependent_tests开头的initial_configs_to_add逻辑因为二者构成一个模型的两个面。backend 变更反向映射到 op 文件若变更匹配fla/ops/op/backends/...路径脚本会扫描该 backend 目录中继承BaseBackend的类的方法名再反查fla/中定义了同名dispatch函数的 op 文件get_backend_methods_from_dirfind_dispatch_op_files从而让原始 op 的回归测试也被触发。黑名单豁免fla/utils/、tests/conftest.py等宽泛工具路径被列入BLACKLIST/BLACKLIST_PREFIXES避免一次工具改动触发全量测试注释说明这是为了在fla/utils.py拆分为fla/utils/**包后保持原有选择行为。本地运行测试时要注意仓库测试机制的两个特性NaN 内存投毒tests/conftest.py中的poison_torch_memoryfixture 会对tests/ops/与tests/modules/下的测试把torch.empty/torch.empty_like/torch.Tensor.new_empty打补丁为 NaN 填充版本仅对来自fla包的调用生效见_is_called_from_fla的栈帧判断用于捕获内核未完全初始化输出张量的 bug。因此测试必须过包含这一隐式检查数值对比基准CONTRIBUTING.md规定测试用fla.utils.assert_close对前向与梯度做严格数值对比且必须torch.manual_seed(42)、覆盖非 2 的幂次序列长度等参数化形状。第五步性能证据仅当触碰内核代码清单第 5 条规定凡触碰 kernel 代码须参照fla-nvidia-performance技能的完整证据要求最低标准是——同一硬件上的 before/after benchmark如适用dense 与 varlen 两类工作负载都要覆盖NCU 剖析结果的摘要。仓库提供了现成的基准工具链可在 PR 的 Benchmark / NCU 小节直接引用# Op 级微基准对 git ref 做 before/after 对比会建临时 worktree不动工作区 python -m benchmarks.ops.run --op chunk_gla --base main python -m benchmarks.ops.run --list # 查看已注册 op # 正确性门控驱动先冻结 pytest 正确性门红灯时拒绝报告加速 python -m benchmarks.ops.verify --op chunk_gla --base main # 模型级训练吞吐 / 生成 python benchmarks/benchmark_training_throughput.py --name kda --batch_size 2 --seq_len 8192 [--varlen] python benchmarks/benchmark_generation.py --name kda新 op 需要注册进benchmarks/ops/registry.py才能被前两个命令使用其中定义了shape_BTHD等形状工厂与输入变换函数。fla-nvidia-performance技能还进一步要求NCU 需用--set full与--set source各跑一次代表性内核、本地留存.ncu-rep但绝不提交进仓库PR 中粘贴关键指标摘要memory throughput %、SOL、occupancy、热点指令硬件基线以 sm_90 及以上数据中心卡为准。第六步按 CI 强制结构撰写 PR 正文清单第 6 条指出正文结构的唯一事实来源是.github/pull_request_template.md且check-pr-title工作流会拒绝删减 checklist 的正文。模板全文如下即 PR 正文必须保留的骨架## Summary !-- What changed and why, at a high level. Link the issue this PR resolves, e.g. Fixes #1234. -- ## Test plan !-- How you verified it: commands run, hardware used. Identify dependent tests first: python scripts/find_dependent_tests.py changed_file_or_dir -- ## Benchmark / NCU (kernel changes only) !-- Same-hardware before/after numbers, with workload shape (batch, seq_len, heads, dims, dtype). State neutral if the change is not performance-related. -- ## Breaking changes !-- None / list any API or behavior changes and the migration path. -- ## Checklist - [ ] I have read [CONTRIBUTING.md](https://link.gitcode.com/i/35d9e07ef8b12c0f4a49621b3ee9cb98) and follow its conventions (code style, docstrings, commit prefixes). - [ ] I have read [AGENTS.md](https://link.gitcode.com/i/5fa01f960e57de36d90516c43a304aae) and, where my change matches its scope, the relevant skill under [.agents/skills](https://link.gitcode.com/i/5786efe1020a34bdca4e7bda56934f8c). - [ ] Dependent tests pass locally or in CI, and new behavior is covered by tests where applicable (tick as N/A for changes with no testable code, e.g. docs-only). - [ ] Kernel changes include same-hardware before/after benchmark numbers, dense varlen where applicable (tick as N/A when no kernel code changed). - [ ] This PR is minor/cosmetic-only (typo, formatting, style-only tweaks) — tick only if it is, and justify below. ### If you ticked the minor box above Standalone minor PRs are normally not accepted (see [No busywork PRs](https://link.gitcode.com/i/35d9e07ef8b12c0f4a49621b3ee9cb98)). Justify here why yours is worth a maintainers review time — minor PRs without a justification may be closed without review: !-- justification, or delete this section if not applicable --技能文档给出的示例正文含各节的推荐填写内容是## Summary One-paragraph description of what changed and why. ## Test plan - Unit tests added/modified: list - Dependent tests run: list - Varlen / CP / model tests: yes/no details ## Benchmark / NCU (kernel changes only) - Hardware: e.g., H100 - Workload: batch, seq_len, dtype - Before: throughput or latency - After: throughput or latency - Conclusion: improvement / neutral / trade-off (state neutral when the change is not performance-related) ## Breaking changes - None / list any API or behavior changes.check-pr-title 工作流到底校验什么上述结构不是建议而是硬约束。.github/workflows/check-pr-title.yml在 PR 的opened / edited / synchronize / reopened事件上执行两类检查标题前缀标题必须匹配^\[[A-Za-z][A-Za-z0-9]*\][[:space:]].即[Tag] 非空描述正文 checklist正文为空直接失败前四个 checklist 项必须被勾选require_checked用grep -qiE ^[[:space:]]*- \[x\]…匹配I have read [CONTRIBUTING.md]、I have read [AGENTS.md]、Dependent tests pass、Kernel changes include四个模式。技能文档解释了勾选的语义每项自带 N/A 解读勾选表示已考虑——完成或不适用例如 docs-only 的 PR 对 benchmark 项按 N/A 勾选第五个 minor 框是反逻辑普通 PR 保持不勾若勾选则### If you ticked标题下必须存在至少 20 个非空白字符的论证HTML 注释会被先剥离否则失败。两个实操要点编辑正文会重新触发检查改完 PR 标题/正文后检查会再跑一遍删减 checklist 会在编辑时直接被打回编辑 PR 要用 REST API 而非gh pr editAGENTS.mdOpening PRs 指出本仓库上gh pr edit会因 classic-Projects GraphQL 错误失败应改用gh api -X PATCH repos/fla-org/flash-linear-attention/pulls/N -f title... -F bodyfile。第七步代码风格审查与平台封装清单第 7 条把风格检查落到三个具体规则遵循CONTRIBUTING.md的 Python 风格Ruff lint autopep8、127 字符行宽、现代类型注解语法X | None、每个文件带 CI 强制check-header.yml的版权头本地用pre-commit run --all-files验证用fla.utils的设备/平台封装禁止新增直接的torch.cuda平台判断清单点名了可用符号——device、device_platform、IS_NVIDIA、IS_NVIDIA_HOPPER、IS_NVIDIA_BLACKWELL、IS_AMD、IS_INTEL。这些确实由fla/utils/__init__.py统一从_device.py导出同时还有IS_NVIDIA_SM100、IS_TMA_SUPPORTED等扩展符号并注册了小写别名。若现有封装不够用规则是先加一个小型fla.utilshelper 再使用而不是在测试或业务代码里就地判断平台NVIDIA 专属剖析命令只留在性能文档或脚本里不要混入通用正确性测试——这保证了正确性测试在不同后端NVIDIA/AMD/Intel/Ascend上都能运行。重要提醒性能数字的上下文、产物纪律与无琐事 PR技能文档 Important reminders 一节给出三条长期有效的纪律值得作为习惯固化裸性能数字禁止入 PR。任何数字必须同时携带五要素workload 形状batch、seq_len、heads、dims、dtype、硬件型号、所用基准命令、before 与 after、以及你的结论improvement / neutral / trade-off不提交.ncu-rep文件或原始 profile 转储结果摘要写进 PR 正文产物留在本地fla-nvidia-performance技能建议的本地布局为profile/run_name/下的REPORT.mdreports/analysis/拒绝 busywork PR琐碎清理应捆绑进实质性变更不要为单个 typo 单独开 PR模板中 minor 框的 20 字符论证要求正是对这条纪律的 CI 化执行。小结一张提交前速查表检查项命令 / 依据强制来源分支与main同步、风格/commit 前缀合规pre-commit run --all-filesCONTRIBUTING.md查重gh pr list --repo fla-org/flash-linear-attention --state open --search keywordsAGENTS.md定位受影响测试python scripts/find_dependent_tests.py changed_file_or_dirscripts/find_dependent_tests.py本地测试通过含 NaN 投毒pytest tests/ops/test_op.pytests/conftest.py内核改动的 before/after 证据python -m benchmarks.ops.run --op op --base main、--varlen训练基准.agents/skills/fla-nvidia-performance/SKILL.mdPR 标题[Tag]前缀 正文 checklist 完整按.github/pull_request_template.md原样填写.github/workflows/check-pr-title.yml编辑 PR 标题/正文REST APIgh api -X PATCH …不用gh pr editAGENTS.md按此流程走完你的 PR 在进入人工评审之前就已经通过了仓库 CI 对格式与证据的全部硬性检查也为评审者留下了可验证的测试计划与性能上下文。【免费下载链接】flash-linear-attention Efficient implementations for emerging model architectures项目地址: https://gitcode.com/GitHub_Trending/fl/flash-linear-attention创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 flash-linear-attention 的 MR/PR 就绪流程：从依赖测试定位到 CI 强制 PR 模板的完整操作指南
flash-linear-attention 的 MR/PR 就绪流程从依赖测试定位到 CI 强制 PR 模板的完整操作指南【免费下载链接】flash-linear-attention Efficient implementations for emerging model architectures项目地址: https://gitcode.com/GitHub_Trending/fl/flash-linear-attention本文围绕 flash-linear-attentionFLA仓库中的fla-mr-readiness技能文档展开完整讲解提交 Pull Request 前的七步预检清单、CI 强制的 PR 正文结构以及各步骤背后的仓库实现——scripts/find_dependent_tests.py的依赖追踪算法、check-pr-title工作流的校验正则、fla.utils设备封装等。读完后你将能够在 FLA 仓库中独立完成一次范围清晰、测试充分、证据完整、格式合规的 MR 提交并理解每一步检查在 CI 层面如何被强制执行。这个技能文档解决什么问题FLA 仓库在.agents/skills/fla-mr-readiness/SKILL.md中定义了 MR/PR 就绪检查清单覆盖四件事CONTRIBUTING.md合规性、测试计划、性能证据、PR 正文结构。它的定位在AGENTS.md中有明确说明——在打开任何 PR 之前都应加载该技能fla-mr-readiness— Preparing MR/PR, test plans, and contribution compliance在.agents/skills/README.md的技能总表中它与其他技能分工协作涉及内核优化循环时加载fla-optimization-loop涉及 NVIDIA 性能剖析时加载fla-nvidia-performance技能文档而fla-mr-readiness是提交动作本身的最后一道闸门。技能文档给出的预检清单共 7 步下面按顺序逐一展开并结合仓库源码说明每一步的底层支撑。第一步通读 CONTRIBUTING.md确认分支状态清单第 1 条要求确认三件事代码风格、docstring 格式、commit message 约定以及确认你的分支已与main或目标分支保持同步。CONTRIBUTING.md的 Core Principles 一节是每个 PR 的验收标尺其中与提交准备直接相关的几条包括数值对齐参考实现每个优化内核必须与 naive 参考实现在assert_close容差内一致纯重构改动必须保证输出和梯度均不变要实测 before/after 而不是假设触碰共享代码时审计全部调用点改一个符号、配置字段或公共内核意味着要在一次提交中更新它的所有使用处保护成熟路径、最小化 diff只改修复或特性真正需要的部分不要顺手重写可用代码。commit message 需要带方括号前缀标签CONTRIBUTING.md给出了常用标签表[Fix]、[Perf]、[Ops]、[Model]、[Layer]、[Attn]、[KDA]、[CP]等不属于任何类别时以[Misc]/[chore]兜底。这个约定并非只是惯例CI 的check-pr-title工作流会用正则^\[[A-Za-z][A-Za-z0-9]*\][[:space:]].强制校验 PR 标题必须以[Tag] 文本开头不符合即失败。第二步确认变更范围声明跨层依赖链清单第 2 条要求列出你修改的文件并在变更跨多层如 kernel model benchmark script时在 PR 描述中写明依赖链。FLA 的目录组织天然形成这种依赖链fla/ops/Triton 内核→fla/layers/PyTorch 层→fla/models/完整模型CONTRIBUTING.md的核心原则第 4 条也据此要求显式判断公共接口是否需要变更。第三步查重避免重复劳动清单第 3 条要求在开工/开 PR 前搜索 open issues 和 PRsgh pr list --repo fla-org/flash-linear-attention --state open --search keywords若发现相关 PR 已存在应去该 PR 下评论而不是另开一个竞争性 PR。这一点与AGENTS.mdOpening PRs 一节的要求一致Check for duplicates first … so you dont redo in-flight work且该文档还补充了查重之外的提交纪律不提交Co-Authored-By等工具署名行、开 PR 前用 grep 确认 diff 中不含已被主线路径禁用的tl.make_block_ptr/tl.advance。第四步用 find_dependent_tests.py 定位并运行受影响的测试清单第 4 条是测试环节的核心命令python scripts/find_dependent_tests.py changed_file_or_dir运行输出的测试文件列表后需在本地跑通如果某个测试不稳定flaky清单要求最多重试一次仍失败则必须在 PR 中解释原因。这个脚本的实现在scripts/find_dependent_tests.py值得从源码层面理解它如何精准而非全量地选出测试基于 AST 的符号级追踪脚本用ast解析fla/下所有源码与tests/下所有测试建立文件 → 定义符号和文件 → 导入符号两张映射DependencyFinder.__init__然后从变更文件定义的符号出发按 import 关系逐层向外扩散max_depth4。这样改一个内核函数只会牵连真正 import 它的测试文件而不是整个tests/ops/。modeling/configuration 联动启发式检测到modeling_name.py变更时会自动把同目录的configuration_name.py一并纳入追踪find_dependent_tests开头的initial_configs_to_add逻辑因为二者构成一个模型的两个面。backend 变更反向映射到 op 文件若变更匹配fla/ops/op/backends/...路径脚本会扫描该 backend 目录中继承BaseBackend的类的方法名再反查fla/中定义了同名dispatch函数的 op 文件get_backend_methods_from_dirfind_dispatch_op_files从而让原始 op 的回归测试也被触发。黑名单豁免fla/utils/、tests/conftest.py等宽泛工具路径被列入BLACKLIST/BLACKLIST_PREFIXES避免一次工具改动触发全量测试注释说明这是为了在fla/utils.py拆分为fla/utils/**包后保持原有选择行为。本地运行测试时要注意仓库测试机制的两个特性NaN 内存投毒tests/conftest.py中的poison_torch_memoryfixture 会对tests/ops/与tests/modules/下的测试把torch.empty/torch.empty_like/torch.Tensor.new_empty打补丁为 NaN 填充版本仅对来自fla包的调用生效见_is_called_from_fla的栈帧判断用于捕获内核未完全初始化输出张量的 bug。因此测试必须过包含这一隐式检查数值对比基准CONTRIBUTING.md规定测试用fla.utils.assert_close对前向与梯度做严格数值对比且必须torch.manual_seed(42)、覆盖非 2 的幂次序列长度等参数化形状。第五步性能证据仅当触碰内核代码清单第 5 条规定凡触碰 kernel 代码须参照fla-nvidia-performance技能的完整证据要求最低标准是——同一硬件上的 before/after benchmark如适用dense 与 varlen 两类工作负载都要覆盖NCU 剖析结果的摘要。仓库提供了现成的基准工具链可在 PR 的 Benchmark / NCU 小节直接引用# Op 级微基准对 git ref 做 before/after 对比会建临时 worktree不动工作区 python -m benchmarks.ops.run --op chunk_gla --base main python -m benchmarks.ops.run --list # 查看已注册 op # 正确性门控驱动先冻结 pytest 正确性门红灯时拒绝报告加速 python -m benchmarks.ops.verify --op chunk_gla --base main # 模型级训练吞吐 / 生成 python benchmarks/benchmark_training_throughput.py --name kda --batch_size 2 --seq_len 8192 [--varlen] python benchmarks/benchmark_generation.py --name kda新 op 需要注册进benchmarks/ops/registry.py才能被前两个命令使用其中定义了shape_BTHD等形状工厂与输入变换函数。fla-nvidia-performance技能还进一步要求NCU 需用--set full与--set source各跑一次代表性内核、本地留存.ncu-rep但绝不提交进仓库PR 中粘贴关键指标摘要memory throughput %、SOL、occupancy、热点指令硬件基线以 sm_90 及以上数据中心卡为准。第六步按 CI 强制结构撰写 PR 正文清单第 6 条指出正文结构的唯一事实来源是.github/pull_request_template.md且check-pr-title工作流会拒绝删减 checklist 的正文。模板全文如下即 PR 正文必须保留的骨架## Summary !-- What changed and why, at a high level. Link the issue this PR resolves, e.g. Fixes #1234. -- ## Test plan !-- How you verified it: commands run, hardware used. Identify dependent tests first: python scripts/find_dependent_tests.py changed_file_or_dir -- ## Benchmark / NCU (kernel changes only) !-- Same-hardware before/after numbers, with workload shape (batch, seq_len, heads, dims, dtype). State neutral if the change is not performance-related. -- ## Breaking changes !-- None / list any API or behavior changes and the migration path. -- ## Checklist - [ ] I have read [CONTRIBUTING.md](https://link.gitcode.com/i/35d9e07ef8b12c0f4a49621b3ee9cb98) and follow its conventions (code style, docstrings, commit prefixes). - [ ] I have read [AGENTS.md](https://link.gitcode.com/i/5fa01f960e57de36d90516c43a304aae) and, where my change matches its scope, the relevant skill under [.agents/skills](https://link.gitcode.com/i/5786efe1020a34bdca4e7bda56934f8c). - [ ] Dependent tests pass locally or in CI, and new behavior is covered by tests where applicable (tick as N/A for changes with no testable code, e.g. docs-only). - [ ] Kernel changes include same-hardware before/after benchmark numbers, dense varlen where applicable (tick as N/A when no kernel code changed). - [ ] This PR is minor/cosmetic-only (typo, formatting, style-only tweaks) — tick only if it is, and justify below. ### If you ticked the minor box above Standalone minor PRs are normally not accepted (see [No busywork PRs](https://link.gitcode.com/i/35d9e07ef8b12c0f4a49621b3ee9cb98)). Justify here why yours is worth a maintainers review time — minor PRs without a justification may be closed without review: !-- justification, or delete this section if not applicable --技能文档给出的示例正文含各节的推荐填写内容是## Summary One-paragraph description of what changed and why. ## Test plan - Unit tests added/modified: list - Dependent tests run: list - Varlen / CP / model tests: yes/no details ## Benchmark / NCU (kernel changes only) - Hardware: e.g., H100 - Workload: batch, seq_len, dtype - Before: throughput or latency - After: throughput or latency - Conclusion: improvement / neutral / trade-off (state neutral when the change is not performance-related) ## Breaking changes - None / list any API or behavior changes.check-pr-title 工作流到底校验什么上述结构不是建议而是硬约束。.github/workflows/check-pr-title.yml在 PR 的opened / edited / synchronize / reopened事件上执行两类检查标题前缀标题必须匹配^\[[A-Za-z][A-Za-z0-9]*\][[:space:]].即[Tag] 非空描述正文 checklist正文为空直接失败前四个 checklist 项必须被勾选require_checked用grep -qiE ^[[:space:]]*- \[x\]…匹配I have read [CONTRIBUTING.md]、I have read [AGENTS.md]、Dependent tests pass、Kernel changes include四个模式。技能文档解释了勾选的语义每项自带 N/A 解读勾选表示已考虑——完成或不适用例如 docs-only 的 PR 对 benchmark 项按 N/A 勾选第五个 minor 框是反逻辑普通 PR 保持不勾若勾选则### If you ticked标题下必须存在至少 20 个非空白字符的论证HTML 注释会被先剥离否则失败。两个实操要点编辑正文会重新触发检查改完 PR 标题/正文后检查会再跑一遍删减 checklist 会在编辑时直接被打回编辑 PR 要用 REST API 而非gh pr editAGENTS.mdOpening PRs 指出本仓库上gh pr edit会因 classic-Projects GraphQL 错误失败应改用gh api -X PATCH repos/fla-org/flash-linear-attention/pulls/N -f title... -F bodyfile。第七步代码风格审查与平台封装清单第 7 条把风格检查落到三个具体规则遵循CONTRIBUTING.md的 Python 风格Ruff lint autopep8、127 字符行宽、现代类型注解语法X | None、每个文件带 CI 强制check-header.yml的版权头本地用pre-commit run --all-files验证用fla.utils的设备/平台封装禁止新增直接的torch.cuda平台判断清单点名了可用符号——device、device_platform、IS_NVIDIA、IS_NVIDIA_HOPPER、IS_NVIDIA_BLACKWELL、IS_AMD、IS_INTEL。这些确实由fla/utils/__init__.py统一从_device.py导出同时还有IS_NVIDIA_SM100、IS_TMA_SUPPORTED等扩展符号并注册了小写别名。若现有封装不够用规则是先加一个小型fla.utilshelper 再使用而不是在测试或业务代码里就地判断平台NVIDIA 专属剖析命令只留在性能文档或脚本里不要混入通用正确性测试——这保证了正确性测试在不同后端NVIDIA/AMD/Intel/Ascend上都能运行。重要提醒性能数字的上下文、产物纪律与无琐事 PR技能文档 Important reminders 一节给出三条长期有效的纪律值得作为习惯固化裸性能数字禁止入 PR。任何数字必须同时携带五要素workload 形状batch、seq_len、heads、dims、dtype、硬件型号、所用基准命令、before 与 after、以及你的结论improvement / neutral / trade-off不提交.ncu-rep文件或原始 profile 转储结果摘要写进 PR 正文产物留在本地fla-nvidia-performance技能建议的本地布局为profile/run_name/下的REPORT.mdreports/analysis/拒绝 busywork PR琐碎清理应捆绑进实质性变更不要为单个 typo 单独开 PR模板中 minor 框的 20 字符论证要求正是对这条纪律的 CI 化执行。小结一张提交前速查表检查项命令 / 依据强制来源分支与main同步、风格/commit 前缀合规pre-commit run --all-filesCONTRIBUTING.md查重gh pr list --repo fla-org/flash-linear-attention --state open --search keywordsAGENTS.md定位受影响测试python scripts/find_dependent_tests.py changed_file_or_dirscripts/find_dependent_tests.py本地测试通过含 NaN 投毒pytest tests/ops/test_op.pytests/conftest.py内核改动的 before/after 证据python -m benchmarks.ops.run --op op --base main、--varlen训练基准.agents/skills/fla-nvidia-performance/SKILL.mdPR 标题[Tag]前缀 正文 checklist 完整按.github/pull_request_template.md原样填写.github/workflows/check-pr-title.yml编辑 PR 标题/正文REST APIgh api -X PATCH …不用gh pr editAGENTS.md按此流程走完你的 PR 在进入人工评审之前就已经通过了仓库 CI 对格式与证据的全部硬性检查也为评审者留下了可验证的测试计划与性能上下文。【免费下载链接】flash-linear-attention Efficient implementations for emerging model architectures项目地址: https://gitcode.com/GitHub_Trending/fl/flash-linear-attention创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考