← 所有项目 Contribution Tasks
RightNow-AI/autokernel 该项目是一个 GPU 算子自动优化 AI 代理框架，核心闭环强依赖 GPU。但其调度层、Profiler 分析层、生态导出工具以及 CUDA/Triton 模板的编写完全可以在无 GPU 的 Mac 上进行。候选人作为资深 Kernel 工程师，可以离线编写高阶算子模板（如 DiT 相关的 AdaLN），并在 Colab T4 上做单次验证；同时可以重构纯 Python 的 Profiler 和调度逻辑，完美避开本地无 GPU 的硬约束，发挥在算子融合和性能建模上的专长。
当前方向： 项目正从早期的 Triton 验证阶段，快速向追求极致性能的 CUDA C++ 落地（大量引入 Tensor Core 和 Shared Memory 优化）以及 HuggingFace 生态整合方向演进。
★ 1564 Fork 164 4 个候选任务 Gemini：gemini-3.1-pro-preview
更新于 2026-10-08T07:37:23+00:00 · 本次生成失败，展示上次结果 · 打开仓库 ↗
目录 一、项目定位 · 二、架构与代码地图 · 三、本地跑起来 · 四、维护者与社区 · 五、切入方案 · 六、怎么介入 · 七、任务卡 一、项目定位 AutoKernel 是一个受 Karpathy autoresearch 启发的 GPU 算子自动优化 AI 代理框架。它的核心理念是：给定任意 PyTorch 模型，AI Agent 会自动分析瓶颈、提取算子，并在一个无限循环中（修改代码 -> 编译运行 -> 验证正确性与性能 -> 保留或回滚）不断迭代优化 Triton 或 CUDA C++ 算子。对于你这样资深的 Kernel 工程师，这个项目并不是一个底层的算子库（如 CUTLASS），而是一个「算子研发自动化流水线」。
项目目前处于快速迭代期（从 pyproject.toml 的 1.0.0 到 Changelog 的 v1.3.0），近期提交热点高度集中在 kernels/cuda（13次提交）和 HuggingFace 算子导出（export_hf.py）。这表明项目正在从纯 Triton 验证阶段，向追求极致性能的 CUDA C++ 落地以及生态整合方向演进。
针对你的硬件约束（仅有 Mac + 免费 Colab T4）的切入建议 ：
由于该项目的核心闭环 bench.py 强依赖 NVIDIA GPU（甚至 README 标明在 H100/A100/4090 上测试）进行真实的 TFLOPS 和内存带宽测试，你在 Mac 上无法 完整运行 Agent 迭代。但你的资深背景依然可以发挥巨大价值：
1. 离线模板与 Prompt 优化 ：你可以纯文本审查和优化 kernels/cuda/ 下的 C++ 模板，或者修改 program.md（Agent 的 System Prompt），将你对 CuTe/CUTLASS、Warp Specialization、Tensor Core wmma 的深刻理解注入给 LLM，指导它写出更优的代码。
2. 调度与工程架构 ：在 Mac 上开发和测试 orchestrate.py（基于 Amdahl 定律的调度逻辑）、profile.py（基于 CPU 模拟或离线 trace 的分析）以及 kernelbench/ 的集成逻辑。
3. 云端验证 ：利用 Colab T4 运行单次 uv run bench.py 或 uv run kernelbench/bench_kb.py 来验证你注入的高阶 CUDA 技巧是否被 LLM 正确采纳并编译通过。
解决什么问题、给谁用 解决深度学习模型中自定义算子（Triton/CUDA）开发门槛高、手工调优耗时长、且 LLM 一次性生成算子正确率和性能低下的问题。通过引入类似强化学习的「编辑-测试-反馈」闭环，让 AI 代理在无人值守的情况下（Overnight）暴力搜索并验证算子优化空间。
目标用户为 AI 基础设施工程师、模型研究员以及需要针对特定硬件（如 RightNow Enterprise 提及的企业级 GPU 优化）榨取极致性能的团队。典型场景包括：新模型架构的快速算子收敛、KernelBench 刷榜验证、以及将优化好的算子一键导出至 HuggingFace Hub 供社区使用。
同类项目与差别 karpathy/autoresearch ：AutoKernel 的直接灵感来源。区别在于 autoresearch 聚焦于 LLM 训练超参和架构的自动化研究，而 AutoKernel 专注于底层 GPU 算子（Triton/CUDA）的代码级生成与性能调优。ScalingIntelligence/KernelBench ：KernelBench 是一个包含 250+ 问题的算子评估基准（偏向 LLM One-shot 生成测试）。AutoKernel 深度集成了它（在 kernelbench/ 目录下），但将范式从「一次性生成」改为了「50-300+ 次迭代优化（fast_p 指标）」。OpenAI Triton / NVIDIA CUTLASS ：Triton 和 CUTLASS 是底层的编译器和模板库，而 AutoKernel 是位于它们上层的「AI 程序员」。AutoKernel 负责写出调用这些底层工具的代码，并通过 bench.py 验证其产物。核心能力 能力 在哪 成熟度 模型 Profiling 与瓶颈提取 profile.py, extract.py 成熟 基于 Amdahl 定律的多算子调度 orchestrate.py 成熟 Triton 算子基线与生成 kernels/ (如 matmul.py, flash_attention.py 等 9 种) 成熟 CUDA C++ 算子基线与生成 kernels/cuda/ 成熟 五阶段正确性与性能基准测试 bench.py 成熟 端到端模型验证与加速比报告 verify.py 成熟 KernelBench 自动化刷榜集成 kernelbench/ (bridge.py, bench_kb.py, scorer.py) 成熟 HuggingFace 算子导出 export_hf.py, examples/hf_kernels_test 成熟 AMD ROCm 硬件支持 CHANGELOG.md (v1.3.0) 实验（需验证具体代码实现）
阶段： 早期到中期快速发展阶段（核心闭环已跑通，正在横向扩展生态如 HF 导出和 AMD ROCm 支持）。
技术栈： Python >= 3.10；PyTorch >= 2.4.0 (torch-cu128)；Triton >= 3.3.0；CUDA C++ (通过 ninja >= 1.11.0 构建)；uv (包管理与环境隔离)；HuggingFace 生态 (transformers, datasets, huggingface-hub)；HolisticTraceAnalysis (HTA 性能分析)
规模： 支持 9 种核心算子类型；内置 5 个独立模型定义（GPT-2, LLaMA 等）；单次实验耗时约 90 秒（一晚可跑 ~320 次）；支持 KernelBench 的 250+ 个标准化问题；近期在 kernels/cuda 目录有 13 次密集提交；pyproject.toml 标定版本为 1.0.0，Changelog 最新记录为 v1.3.0。
二、架构与代码地图 AutoKernel 的架构设计并非传统的「底层算子库」，而是一条高度自动化的「算子研发流水线」。对于只有 Mac 环境的资深 Kernel 工程师而言，理解这种分层至关重要，因为你的主战场将集中在无需 GPU 即可开发的「调度层」与「模板层」。
1. 入口与调度层 (Entry & Orchestration Layer) ：包含 profile.py、extract.py 和 orchestrate.py。这一层负责将任意 PyTorch 模型解构为独立的算子问题。profile.py 利用 torch.profiler 寻找耗时瓶颈，orchestrate.py 则基于阿姆达尔定律（Amdahl's law）决定下一个该优化的算子。切入点 ：这部分纯 Python 逻辑完全可以在 Mac 上开发，你可以引入更复杂的 CPU 模拟调度策略或离线 Trace 分析。
2. Agent 交互层 (Agent Interaction Layer) ：由 program.md（System Prompt）和 kernel.py（Agent 唯一修改的文件）组成。这是 AI 与代码库的接口。切入点 ：你可以纯文本审查和优化 program.md，将你对 Warp Specialization、寄存器压力控制的理解注入 Prompt，指导 LLM 避开常见的 CUDA 陷阱。
3. 执行与评测层 (Execution & Evaluation Layer) ：核心是 bench.py、verify.py 和 kernels/cuda/_compile.py。这里执行严格的 5 阶段正确性检查（冒烟、形状扫描、数值稳定性、确定性、边界情况）和 Roofline 性能测试。_compile.py 实现了带缓存的 CUDA C++ JIT 编译（基于 load_inline）。切入点 ：这是强依赖 GPU 的一层，你在 Mac 上无法运行，但可以通过 Colab T4 运行单次 uv run bench.py 来验证编译和基础逻辑。
4. 模板与生态层 (Templates & Ecosystem Layer) ：包含 kernels/（Triton）、kernels/cuda/（CUDA C++）以及 export_hf.py。这里存放了 9 大核心算子的初始模板（如 FlashAttention、SwiGLU）。近期提交热点高度集中于此。切入点 ：这是你发挥核心价值的地方。你可以离线编写极致优化的 CUDA C++ 模板（如利用 nvcuda::wmma、Double-buffered Shared Memory），作为 Agent 的起点；同时参与 export_hf.py 的开发，将优化好的算子推向 HuggingFace 生态。
调度与入口层 Agent 交互层 评测与执行层 模板与生态层 Profiler → Extractor：瓶颈报告 Extractor → TargetKernel：初始模板 初始模板 Orchestrator → TargetKernel：切换目标 切换目标 AgentPrompt → TargetKernel：修改指令 TargetKernel → Benchmark：待测源码 待测源码 Benchmark → CUDACompiler：JIT编译 JIT编译 Benchmark → Orchestrator：性能反馈 性能反馈 Orchestrator → Verifier：触发验证 触发验证 TargetKernel → HFExporter：导出发布 导出发布 CUDATemplates → Extractor：提供模板 提供模板 Profiler Profiler Extractor Extractor Orchestrator Orchestrator AgentPrompt AgentPrompt TargetKernel TargetKernel Benchmark Benchmark Verifier Verifier CUDACompiler CUDACompiler CUDATemplates CUDATemplates HFExporter HFExporter KernelBench KernelBench AutoKernel 自动化算子研发流水线架构图 模块 / 路径 职责 · 入口 · 依赖 Profiler profile.py百行级 模型剖析器。运行 PyTorch 模型，利用 torch.profiler 捕获算子耗时，并根据规则分类为特定 Kernel 类型。入口：_KERNEL_CLASSIFICATION, _fallback_detect_gpu 依赖：models/ 包含硬件探测逻辑 (GPUSpec)，可在 Mac 上扩展 CPU/MPS 的 fallback 逻辑以便本地调试。 Extractor extract.py百行级 算子提取器。读取 Profiler 报告，将 Top-N 瓶颈算子对应的模板代码拷贝到 workspace 准备优化。入口：需验证 依赖：profile.py, kernels/ 连接模型分析与单算子优化的桥梁。 Orchestrator orchestrate.py百行级 多算子调度器。基于阿姆达尔定律决定当前应该把算力（Agent API Token）投资在哪个算子上收益最大。入口：需验证 依赖：bench.py 纯逻辑层，非常适合在 Mac 上进行算法迭代和单元测试。 AgentPrompt program.md文档 AI 代理的「大脑」与操作手册。包含 6 层优化剧本、决策框架和崩溃处理指南。入口：program.md 依赖：无 注入资深 Kernel 工程师经验的最佳文本载体。 TargetKernel kernel.py百行级 Agent 唯一被允许修改的文件。包含当前正在优化的 Triton 或 CUDA C++ 源码。入口：kernel_fn 依赖：kernels/cuda/_compile.py 动态生成和修改，是整个闭环的中心数据结构。 Benchmark bench.py数百行 固定基准测试台。执行 5 阶段正确性验证和 TFLOPS/带宽性能测试，输出 results.tsv。入口：需验证 依赖：kernel.py, reference.py 强依赖 NVIDIA GPU，Mac 用户需借助 Colab 运行。 CUDACompiler kernels/cuda/_compile.py百行级 CUDA C++ JIT 编译器。处理源码哈希缓存、架构自动探测（-gencode）和 pybind11 包装。入口：compile_cuda, _hash_source, _get_arch_flags 依赖：torch.utils.cpp_extension 将构建时间从 30s 缩短到 5s 的关键，支持线程安全锁。 CUDATemplates kernels/cuda/十几个文件 CUDA C++ 算子初始模板库。包含 FlashAttention、Matmul、LayerNorm 等 9 种算子的高性能起点。入口：CUDA_SRC, KERNEL_TYPE 依赖：kernels/cuda/_compile.py 近期提交热点（13次）。大量使用了 wmma、__shfl_down_sync 等底层 intrinsic。 Verifier verify.py百行级 端到端验证器。将优化后的所有算子插回原 PyTorch 模型，验证最终输出正确性并报告总加速比。入口：需验证 依赖：models/, workspace/ 闭环的最后一步，确保局部优化不会破坏全局语义。 HFExporter export_hf.py百行级 生态导出工具。自动检测后端（Triton/CUDA），提取源码并打包为 HuggingFace Kernels 格式。入口：detect_backend, extract_cuda_source 依赖：kernel.py 项目向生态整合演进的标志，近期有 3 次提交。 KernelBench kernelbench/5个文件 标准评测集集成。用于在 250+ 标准 GPU 算子问题上评估 AutoKernel 的迭代优化能力。入口：bench_kb.py, scorer.py, bridge.py 依赖：datasets 引入了 fast_p 指标，Agent 指令由 program_kb.md 独立控制。
目录树（按文件数） kernels/ 21 个文件 __init__.py, cross_entropy.py, cuda, flash_attention.py, fused_mlp.py, layernorm.py, matmul.py, reduce.py, rmsnorm.py, rotary_embedding.py, softmax.py examples/ 5 个文件 hf_kernels_test kernelbench/ 5 个文件 __init__.py, bench_kb.py, bridge.py, program_kb.md, scorer.py models/ 5 个文件 __init__.py, bert_base.py, custom.py, gpt2.py, llama_7b.py .gitignore/ 1 个文件 .python-version/ 1 个文件 CHANGELOG.md/ 1 个文件 LICENSE/ 1 个文件 README.md/ 1 个文件 analysis.py/ 1 个文件 bench.py/ 1 个文件 export_hf.py/ 1 个文件 extract.py/ 1 个文件 kernel.py/ 1 个文件 orchestrate.py/ 1 个文件 prepare.py/ 1 个文件 一次调用怎么流过这些模块 AutoKernel 的数据流是一个典型的「分析 -> 提取 -> 迭代优化 -> 验证」的强化学习式闭环。一次完整的模型优化路径如下：
1. 入口剖析 (Profiling) ：用户运行 uv run profile.py 传入模型（如 models/llama_7b.py）。系统使用 torch.profiler 捕获前向传播，通过 _KERNEL_CLASSIFICATION 规则（如匹配 flash、gemm）将底层算子映射为 9 大支持的 KERNEL_TYPE。输出关键数据结构 profile_report.json，记录各算子的 GPU 耗时占比。
2. 算子提取 (Extraction) ：extract.py 读取报告，按耗时降序（Top-N）将对应的初始模板（优先从 kernels/cuda/，其次 kernels/）拷贝到 workspace/ 目录下，准备进行独立优化。
3. 调度决策 (Orchestration) ：orchestrate.py 介入，基于阿姆达尔定律计算当前哪个算子的理论全局收益最大，将其选定为当前目标，并将其代码复制为 kernel.py。
4. AI 迭代闭环 (Agent Loop) ：
- Agent 读取 program.md 和当前的 kernel.py。
- Agent 修改 kernel.py 中的 CUDA_SRC 或 Triton 代码。
- 触发 bench.py。如果是 CUDA 后端，kernels/cuda/_compile.py 会提取 CUDA_SRC，计算哈希，动态生成 pybind11 包装并调用 load_inline 进行 JIT 编译。
- bench.py 执行 5 阶段正确性检查（对比 reference.py），若通过则测试 TFLOPS/带宽，结果追加到 results.tsv。
- Agent 读取测试结果，决定保留 (Keep) 或回滚 (Revert) 代码，进入下一次循环。
5. 端到端验证与导出 (Verification & Export) ：所有算子优化达到阈值后，verify.py 将它们替换回原模型进行端到端测试。最终，用户可通过 export_hf.py 解析 kernel.py，提取源码并发布到 HuggingFace Hub。
针对 Mac 用户的调度点 ：上述流程中，步骤 1-3 和 5 的控制流完全可以在 CPU 上模拟或执行。你可以通过伪造 profile_report.json 和 results.tsv，在 Mac 上专注开发 orchestrate.py 的调度算法或 export_hf.py 的解析逻辑，仅在需要真实编译时将 kernel.py 丢到 Colab T4 验证。
1 剖析模型 Profiler · profile.py 2 提取算子 Extractor · extract.py 3 调度决策 Orchestrator · orchestrate.py 4 AI修改代码 TargetKernel · kernel.py 5 JIT编译 CUDACompiler · kernels/cuda/_compile.py 6 基准测试 Benchmark · bench.py 7 端到端验证 Verifier · verify.py 关键类型与函数 名称 路径 用途 _KERNEL_CLASSIFICATION profile.py List[Tuple[List[str], str]]，定义了从 PyTorch 底层算子名（如 'fmha', 'cublas'）到 AutoKernel 标准算子类型（如 'flash_attention', 'matmul'）的映射规则。 GPUSpec profile.py Dataclass，存储当前 GPU 的硬件规格（SM 数量、显存、峰值 TFLOPS、带宽、计算能力），用于 Roofline 性能评估。 compile_cuda kernels/cuda/_compile.py 核心 JIT 编译函数。接收 CUDA C++ 字符串，处理哈希缓存、架构 flag 生成，并返回编译好的 PyTorch C++ 扩展模块。 CUDA_SRC kernels/cuda/*.py 全局字符串变量，包含原生的 CUDA C++ 设备代码和内核启动逻辑，是 Agent 实际阅读和修改的文本载体。 WelfordState kernels/cuda/layernorm.py C++ Struct，用于在 LayerNorm 中实现 Welford 在线算法，保证单次 pass 计算均值和方差的数值稳定性。 wmma::fragment kernels/cuda/matmul.py CUDA nvcuda 命名空间下的模板类，用于直接调用 Tensor Core 进行 16x16x16 矩阵乘加运算。 kernel_fn kernels/cuda/reduce.py Python 函数，作为 bench.py 调用的统一入口，负责处理 Tensor 的 dtype/shape 转换并调用底层编译好的 C++ 模块。 ModelNew kernelbench/program_kb.md KernelBench 模式下的目标类名，Agent 需要编写此类的 Triton/CUDA 实现以替换原始的 PyTorch Model。
扩展点 新模型接入 ：在 models/ 目录下新建 Python 文件定义自包含的 PyTorch 模型（参考 custom.py），或直接使用 uv run profile.py --module transformers --class-name ... 接入 HuggingFace 模型。新 Kernel 类型接入 ：1. 在 profile.py 的 _KERNEL_CLASSIFICATION 中添加名称匹配规则；2. 在 reference.py 中添加 PyTorch 参考实现；3. 在 kernels/ 和 kernels/cuda/ 下提供初始模板文件。新后端接入 (如 ROCm/HIP) ：在 export_hf.py 的 detect_backend 中添加识别逻辑，并在 kernels/ 下建立新目录（如 kernels/hip/），实现类似 _compile.py 的 JIT 编译封装，最后修改 bench.py 以支持新后端的调用。新调度策略 ：修改 orchestrate.py。当前基于阿姆达尔定律，可扩展为基于强化学习的探索-利用（Exploration-Exploitation）策略，或针对特定硬件（如 Mac 模拟）的离线调度策略。最近在动的地方 kernels/cuda/ ：13 次提交。项目正从 Triton 验证期向追求极致性能的 CUDA C++ 落地期演进，大量引入了 Tensor Core (wmma)、Shared Memory 优化和在线 Softmax 等高级技巧。README.md ：7 次提交。项目处于快速迭代期，文档频繁更新以反映新功能（如 KernelBench 集成、HuggingFace 导出、AMD ROCm 支持）。examples/hf_kernels_test/ ：5 次提交。为了打通 HuggingFace Kernels 生态，进行了密集的导出格式和 C++ 绑定测试。export_hf.py ：3 次提交。新增的核心功能，负责解析 AST 和正则表达式提取 CUDA_SRC，打包为标准分发格式。CHANGELOG.md ：3 次提交。记录了 v1.3.0 等版本的快速发布，表明项目维护活跃。建议阅读顺序 README.md program.md profile.py kernels/cuda/_compile.py kernels/cuda/matmul.py bench.py orchestrate.py export_hf.py 三、本地跑起来（没有 GPU 的 Mac） 安装 git clone https://github.com/RightNow-AI/autokernel.gitcd autokernelsed -i '' '/pytorch-cu128/d' pyproject.tomlsed -i '' '/tool.uv.sources/d' pyproject.tomlsed -i '' '/tool.uv.index/d' pyproject.tomlsed -i '' '/"triton>=3.3.0",/d' pyproject.tomluv sync --extra models --extra hf-kernels --extra kernelbench哪些路径能真跑 完全可在 Mac (CPU/MPS) 上执行的路径 ：
1. 调度与分析层 ：profile.py（支持 CPU Profiling，源码中的 _fallback_detect_gpu 在无 CUDA 时会安全返回空 GPUSpec）、extract.py、orchestrate.py（基于 Amdahl 定律的纯 Python 调度逻辑）。
2. 生态导出层 ：export_hf.py（基于纯文本正则和 AST 解析提取 CUDA_SRC，完全不依赖 GPU）。
3. KernelBench 桥接 ：kernelbench/bridge.py（从 HuggingFace 下载并缓存题目）。
必须依赖 GPU（需用 Colab T4 验证）的路径 ：
1. 编译与执行 ：kernels/cuda/_compile.py（强依赖 nvcc 和 torch.utils.cpp_extension.load_inline）、bench.py（5 阶段正确性与 Roofline 性能测试）、verify.py。
2. KernelBench 评测 ：kernelbench/bench_kb.py 和 kernelbench/scorer.py。
最小可运行 uv run prepare.pyuv run profile.py --model models/llama_7b.py --class-name LlamaModel --input-shape 1,512uv run extract.py --top 5uv run export_hf.py --name my_matmul --kernel kernels/cuda/matmul.pyuv run kernelbench/bridge.py fetch --source hf --level 1测试 项目没有 传统的 pytest 测试套件（目录树中无 tests/ 目录）。测试即「基准测试与验证」，核心是 bench.py（针对单个算子的 5 阶段正确性检查：冒烟、形状扫描、数值稳定性、确定性、边界情况）和 verify.py（端到端验证）。根据 README，单次 bench.py 实验耗时约 90 秒。在 Mac 上无法运行这些测试，你必须将修改后的 kernels/cuda/*.py 复制到 Colab T4 上，通过 uv run bench.py 进行单点验证。
调试 清理 CUDA 编译缓存：kernels/cuda/_compile.py 会将编译产物哈希缓存到 ~/.cache/autokernel/cuda_build，修改 C++ 模板后若未生效，直接 rm -rf ~/.cache/autokernel/cuda_build。 离线 Trace 分析：profile.py 默认使用 torch.profiler，你可以修改它导出 Chrome Trace JSON，在 Mac 上用 chrome://tracing 或 Perfetto 离线分析瓶颈。 KernelBench 静态审查：题目会被缓存在本地，可以通过 uv run kernelbench/bridge.py setup --level 1 --problem 1 快速生成特定题目的脚手架，在 Mac 上进行静态代码审查和 Prompt 优化。 日志开关：profile.py 等脚本使用了标准 logging，可以通过修改脚本中的 logger level 开启 Debug 输出。 CI 目录树中未发现 .github/workflows/ 或其他 CI 配置文件（需验证是否在内部私有仓库运行）。目前开源版本的 PR 极大概率依赖维护者手工拉取并在本地 A100/4090 上运行 uv run bench.py 和 uv run verify.py。因此，提交 PR 前务必在 Colab T4 上确保你的 CUDA C++ 代码能通过 bench.py 的 5 阶段正确性检查，否则会被直接打回。
坑 依赖陷阱：pyproject.toml 强绑定了 pytorch-cu128 并在 dependencies 中要求 triton>=3.3.0。在 Apple Silicon 上直接 uv sync 会报错找不到包。必须手动修改 pyproject.toml 剔除 CUDA 源和 Triton 依赖（见 install 步骤）。 GPU 强校验：bench.py 和 kernels/cuda/_compile.py 中有严格的 torch.cuda.is_available() 检查，在 Mac 上运行会直接抛出异常。不要试图在 Mac 上 mock CUDA 运行，直接把精力放在纯文本的 C++ 模板优化和调度逻辑上。 C++ 包装器陷阱：kernels/cuda/_compile.py 中的 _extract_forward_decl 依赖正则匹配来生成 C++ 前向声明。如果你在 kernels/cuda/*.py 中修改了 CUDA 函数签名（如增加了复杂的模板参数或换行），可能会导致正则匹配失败，进而引发 pybind11 编译时的「not declared in this scope」错误。 四、维护者与社区 项目处于极速迭代期。从 2026 年 3 月 11 日到 19 日的短短几天内，密集提交了 12 次核心更新（涉及 CUDA 模板、HuggingFace 导出、Bug 修复等）。目前仓库没有发布正式的 GitHub Release，但通过 CHANGELOG.md 记录了 v1.3.0 的演进，而 pyproject.toml 仍标为 1.0.0，这表明项目正处于早期快速验证与功能扩张阶段。
谁 角色 依据 RightNow-AI 核心维护组织 仓库所属的官方组织，主导了 README 的编写、核心架构设计（如 bench.py 和 orchestrate.py）以及商业化导流（RightNow Enterprise）。 @andyluo7 核心贡献者 (AMD ROCm 生态) 在 README 的 v1.3.0 Changelog 中被特别感谢，提交了 PR #6 增加了 AMD MI300X 的 Agent 优化支持与 HIP 兼容性。
流程与 Review 风格 目前没有正式的 CONTRIBUTING.md、CLA 或 DCO 要求。贡献流程属于典型的早期开源项目：直接通过 Issue 提出需求或报告 Bug（如 Issue #9 提出解析失败），然后提交 PR 修复（如 PR #10 修复 extract.py）。由于项目强依赖 uv 进行依赖管理，本地开发需使用 uv sync 和 uv run 进行测试。对于你来说，可以在 Mac 上用 uv 搭建纯 CPU 的调度层开发环境。
响应迅速且务实，对外部贡献持开放态度。Issue #1 和 #2 在提出后很快有了多次互动评论，且社区成员提交的 PR（如 PR #13 修复 orchestrate.py 时间预算，PR #10 修复 shape 解析）能迅速被跟进。维护者非常欢迎生态集成（如 HuggingFace kernels 的导出功能就是在近期密集提交中完成的）。
渠道 https://discord.gg/UfEyc72t https://img.shields.io/badge/Discord-Join%20us-5865F2?logo=discord&logoColor=white 这里的规矩 Correctness first (正确性优先)：README 明确指出，基准测试在测量性能前会先与 PyTorch 交叉验证，『一个快但错误的 kernel 会被立即回滚』。提交 PR 时必须保证通过 bench.py 的 5 阶段正确性检查（冒烟、形状扫描、数值稳定性、确定性、边界情况）。 控制修改范围 (Single file to modify)：架构设计强调 Agent 每次只修改 kernel.py。人类贡献者在优化模板或 Prompt 时，也应保持 PR 范围的收敛，避免破坏这种高度自动化的单文件闭环设计。 结果可解析：所有实验结果必须能输出到 results.tsv，保持人类可读和 Git 友好，不要引入复杂的外部日志基建。 维护者现在最想要的帮助 扩散模型/视频生成算子融合（完美契合你的背景）：Issue #14 明确要求支持 modulated norm and gated-residual fusion，这与你擅长的 DiT/视频生成推理加速完全对口。你可以直接在 Mac 上离线编写这些算子的 CUDA C++ 模板，并用 Colab 验证后提交 PR。 Apple Silicon (MLX) 支持（完美契合你的硬件）：Issue #8 提出了 MLX support。鉴于你只有 MacBook Air，这是你最完美的切入点！你可以主导将 AutoKernel 的评测后端扩展到 Apple Silicon，让 Agent 也能在 Mac 上优化 MLX 算子。 量化与分布式支持：Issue #4 (quants support) 和 Issue #7 (Tensor Parallelism Support) 亟待解决，这与你的端侧量化和分布式训练性能背景高度吻合。 离线 Profiling 与调度增强：PR #17 正在实现离线的 Profiler 关联，这属于调度与分析层，完全可以在你的 Mac 上进行纯 CPU 开发和 Code Review。 五、切入方案 建议长期负责： CUDA 模板架构师与 Agent 优化策略（Prompt）负责人kernels/cuda/ 和 program.md，你将直接决定该项目生成的算子性能上限，是通向核心维护者最快、最契合你硬件约束的路径。
它现在缺什么（你无 GPU 也能补） 缺口 依据 为什么是你 缺乏基于 CuTe/CUTLASS 的高阶 CUDA 模板 源码片段显示 kernels/cuda/matmul.py 目前使用的是原生的 nvcuda::wmma API，且注释提到 16x16x16 tiles 和双缓冲，这属于较基础的 Tensor Core 用法，尚未引入更现代的 CuTe 布局抽象。 你作为资深 Kernel 工程师，对 CuTe/CUTLASS 有深刻理解。你可以纯离线编写这些高阶模板，只需在 Colab T4 上做最终编译验证，完美避开无本地 GPU 的限制。 Agent Prompt 缺乏针对高阶 CUDA 优化的系统性指导 项目依赖 program.md 指导 LLM，但目前 LLM 容易在寄存器溢出（Register Spilling）、Warp Specialization 等高级技巧上犯错（提交热点显示 kernels/cuda 频繁修改）。 你可以将你脑海中的「CUDA 避坑指南」和「性能调优启发式规则」转化为纯文本，注入到 program.md 中，这完全不需要 GPU 即可完成。 缺少针对扩散模型（DiT/视频生成）的核心算子模板 目录树 kernels/ 下目前只有 flash_attention.py, fused_mlp.py, rmsnorm.py 等标准大语言模型（LLM）算子，缺乏 AdaLN、3D RoPE 等 DiT 专属算子。 你擅长扩散模型推理加速，可以直接贡献这些新兴算子的初始模板，拓宽 AutoKernel 的适用场景。 HuggingFace 导出工具的鲁棒性有待提升 export_hf.py 依赖正则表达式和 AST 解析来提取 CUDA_SRC（如 extract_cuda_source 函数），面对 LLM 生成的复杂或不规范的 C++ 宏定义时容易失效。这是一个纯 Python 的字符串与 AST 处理任务，完全可以在 Mac CPU 上开发和编写单元测试。 调度层（Orchestrator）缺乏基于关键路径的复杂分析 README 提到 orchestrate.py 仅基于基础的阿姆达尔定律（Amdahl's law）进行调度，可能无法处理复杂的算子融合（Fusion）收益评估。 你拥有丰富的 PyTorch 算子融合经验，可以在 Mac 上重构调度逻辑，引入更智能的离线算子图分析。 无 GPU 环境下的 Profiler 降级体验较弱 profile.py 中存在 _fallback_detect_gpu，在无 CUDA 时返回空的 GPUSpec，但无法进行离线的 Roofline 模拟分析。你可以引入基于硬件规格字典的离线 Roofline 模拟器，让开发者在 Mac 上也能跑通 profile.py 的分析流程。
第一批 PR 题目 范围 为什么安全 feat(export): enhance CUDA_SRC regex extraction in export_hf.py export_hf.py 这是一个纯 Python 的字符串处理任务。当前的正则可能无法完美处理带有复杂注释或多行宏定义的 C++ 代码。在 Mac 上编写并使用 pytest（或简单的 assert 脚本）即可完全验证，不依赖任何 GPU 环境。 feat(templates): add AdaLN (Adaptive LayerNorm) CUDA template for DiT models kernels/cuda/adaln.py, kernels/adaln.py, profile.py 新增算子模板不会破坏现有的 LLM 迭代循环。你可以离线编写 CUDA C++ 代码，在 Colab T4 上单次运行 bench.py 验证编译和正确性，这能直接发挥你在扩散模型领域的专长。 docs(prompt): inject warp specialization and register pressure guidelines program.md 纯文本修改。通过优化 System Prompt，指导 LLM 在生成代码时主动使用 __launch_bounds__ 或避免过度展开循环。这不需要跑测试，但能显著提升 Agent 生成代码的质量。 feat(profiler): add offline Roofline simulation for CPU-only environments profile.py 增强现有的 _fallback_detect_gpu 函数，允许用户通过环境变量或参数指定目标 GPU（如 --simulate-gpu H100），从而在 Mac 上也能生成完整的 profile_report.json。纯 Python 逻辑，完全本地可测。
怎么知道自己站住了 你的 PR 被迅速 Merge，且维护者在 Changelog 中特别感谢你对 CUDA 模板或 Prompt 的贡献。 当社区有用户提交关于 CUDA 编译错误或性能不达标的 Issue 时，维护者主动 @ 你寻求专业意见。 你编写的 DiT 算子模板被官方列入 README 的 "Supported Kernels" 列表中。 你优化的 program.md 使得 Agent 在 KernelBench 上的 fast_p 得分获得可观测的提升。 风险与对策 盲写 CUDA C++ 代码导致在真实 GPU 上编译失败或出现隐蔽的并发 Bug（如 Race Condition）。 ：严格遵守「Mac 上编写 + Colab T4 上验证」的闭环。在提交 PR 前，务必在 Colab 中运行 uv run bench.py 通过 5 阶段正确性检查。LLM Agent 无法理解或正确使用你引入的复杂 CuTe/CUTLASS 模板，导致生成的代码性能反而下降。 ：在引入高阶模板的同时，必须同步更新 program.md，给出具体的代码示例和修改边界（告诉 LLM 哪些部分可以改，哪些部分是 CuTe 核心逻辑不能动）。项目维护者更倾向于保持模板的简单性（如裸 wmma），拒绝引入学习曲线陡峭的 CuTe。 ：在提交代码前先开 Issue 讨论。可以提议将高阶模板作为可选的 Backend（例如新增 kernels/cute/ 目录），而不是直接覆盖现有的基础模板。Colab T4 算力较老（Turing 架构，sm_75），无法验证针对 Hopper (sm_90) 的 TMA 或 TMA Multicast 优化。 ：在代码中使用宏定义（如 #if __CUDA_ARCH__ >= 900）隔离高阶特性。对于无法测试的 sm_90 代码，在 PR 中明确标注「需拥有 H100 的维护者协助验证」。六、怎么介入这个项目 在 Discord 社区 (https://discord.gg/UfEyc72t) 进行日常讨论和同步进展。 对于重大架构变更或新功能（如离线模拟器），建议先开 Issue 或在现有 Issue 下留言提案，得到维护者确认后再动手。 确保所有新增的算子模板都包含 PyTorch 参考实现，并通过 bench.py 的 5 阶段正确性测试。 社区入口： img.shields.io/badge/Discord-Join%20us-5 · discord.gg/UfEyc72t
建议顺序 修复 fused_mlp.py 中 Triton math.tanh 编译报错 增强 export_hf.py 中 CUDA_SRC 的正则提取鲁棒性 添加 DiT 模型所需的 Modulated LayerNorm (AdaLN) 算子模板 扩展 Profiler 以识别量化模型 (bitsandbytes) 算子 为无 GPU 环境添加离线 Roofline 模拟器 增强 Profiler 输出以支持 Temporal Breakdown 分析 成为长期维护者的路径 CUDA 模板架构师 Agent 优化策略（Prompt）负责人 性能分析与调度层核心维护者 七、任务卡 任务 1 优先 · easy · Colab T4 · 1个晚上
修复 fused_mlp.py 中 Triton math.tanh 编译报错 Issue #19 · module 'triton.language.math' has no attribute 'tanh' ↗
无人认领 0 条评论 更新 2026-08-16
用到的专长： Triton 算子开发与调试
目标： 修复 kernels/fused_mlp.py 中 tl.math.tanh 导致的 AttributeError，使提供的复现脚本能成功编译。
为什么值得长期做： 解决基础算子的编译错误是维护算子库稳定性的第一步，能快速向维护者展示你对 Triton 底层 API 的熟悉程度，建立信任。
怎么介入： Issue 无人认领，直接留言认领。第一个 PR 的边界： 仅修改 kernels/fused_mlp.py 中的 tanh 调用。
第一步： 调查 Triton 当前版本对 tanh 的支持路径（如是否应使用 tl.math.libdevice.tanh 或 tl.extra.cuda.libdevice.tanh）。
本机怎么复现 / 验证： 在 Mac 上安装 triton（可能需要特定版本），保存 Issue 中的代码为 repro.py 并运行 python repro.py 观察编译报错。
认领留言（英文，可直接贴到 Issue） I can take this. I'll check the Triton version compatibility for tanh (likely needing tl.extra.cuda.libdevice.tanh or similar depending on the version) and fix kernels/fused_mlp.py. I can test it with the provided script and run the benchmark suite. Expect a PR in a day or two. 复制留言 大致实施方案 在本地或 Colab 运行 Issue 提供的复现脚本，确认报错。 修改 kernels/fused_mlp.py，将 tl.math.tanh 替换为当前 Triton 版本兼容的调用方式。 在 Colab T4 上运行 uv run bench.py 验证 fused_mlp 算子的正确性。 可能涉及的目录或文件 验收方式 运行 Issue 中的复现脚本不再报错。 在 Colab T4 上运行 uv run bench.py 针对 fused_mlp 通过正确性测试。 开工前问题与风险 向维护者确认 项目目前主要针对哪个版本的 Triton 进行测试？ 风险 不同 Triton 版本 API 可能有差异，需确保兼容项目 pyproject.toml 中的版本要求。 任务 2 优先 · medium · Colab T4 · 2-3个晚上
添加 DiT 模型所需的 Modulated LayerNorm (AdaLN) 算子模板 Issue #14 · [Feature] Support modulated norm and gated-residual fusion for diffusion/video transformer models ↗
无人认领 0 条评论 更新 2026-07-29
用到的专长： 扩散模型推理加速、CUDA/Triton 算子开发
目标： 添加 modulated_layernorm (AdaLN) 的 PyTorch 参考实现和初始 Triton/CUDA 模板。
为什么值得长期做： 扩展 AutoKernel 的适用场景至当前热门的扩散模型，直接展现你在前沿模型架构和算子融合上的深厚积累。
怎么介入： Issue 提问者表示愿意贡献，但目前无 assignee 且无 PR。可以留言提议合作或先提供基础模板。第一个 PR 的边界： 新增 modulated_layernorm 算子类型及其参考实现和基础模板。
第一步： 在 reference.py 中实现 modulated_layernorm 的 PyTorch 版本。
本机怎么复现 / 验证： 在 Mac 上编写代码，使用 python -m pytest 或直接运行 reference.py 验证 PyTorch 逻辑；最终编译需在 Colab 运行 uv run bench.py。
认领留言（英文，可直接贴到 Issue） I'm very interested in this for DiT models. I can start by contributing the base modulated_layernorm (AdaLN) kernel types (PyTorch reference, Triton, and CUDA C++ templates) and wiring them into bench.py. We can iterate on the generic custom-kernel interface later. Does this sound like a good first step? 复制留言 大致实施方案 在 reference.py 中添加 modulated_layernorm(x, scale, shift, weight, bias, eps)。 在 kernels/ 和 kernels/cuda/ 下分别创建 modulated_layernorm.py，提供基础的 Triton 和 CUDA C++ 实现。 在 bench.py 中注册该算子类型，并配置相应的输入 shape 生成逻辑。 在 Colab T4 上运行 uv run bench.py 验证正确性。 可能涉及的目录或文件 reference.py kernels/modulated_layernorm.py kernels/cuda/modulated_layernorm.py bench.py 验收方式 在 Colab T4 上运行 uv run bench.py，确保 modulated_layernorm 通过 5 阶段正确性测试。 开工前问题与风险 向维护者确认 对于 broadcast layout，初始版本是否先只支持 [B, T, D] 格式的 scale/shift？ 风险 CUDA C++ 模板可能在 Colab T4 (SM75) 上编译通过，但在 H100 上有差异，需尽量使用标准 API。 任务 3 可选 · medium · Mac · 2个晚上
扩展 Profiler 以识别量化模型 (bitsandbytes) 算子 Issue #4 · quants support ↗
无人认领 1 条评论 更新 2026-04-06
用到的专长： 模型量化、PyTorch Profiler 分析
目标： 扩展 profile.py 中的算子分类逻辑，使其能识别 bitsandbytes 等量化库产生的特定 kernel 名称。
为什么值得长期做： 介入核心的 Profiler 逻辑，为后续复杂的量化算子优化铺平道路，发挥你的端侧部署和量化经验。
怎么介入： Issue 提出者给出了思路但表示还没准备好实现。可以直接认领阶段 1 和 2。第一个 PR 的边界： 仅修改 profile.py，添加量化参数解析和 kernel 名称分类规则。
第一步： 审查 profile.py 中的 _KERNEL_CLASSIFICATION 字典和分类逻辑。
本机怎么复现 / 验证： 在 Mac 上编写一个包含假 kernel 名称的 JSON trace 文件，修改 profile.py 读取该文件并验证分类输出。
认领留言（英文，可直接贴到 Issue） I can help with Step 1 and 2 (Loading and Profiling quantized models). I'll extend profile.py to parse bitsandbytes kernel names and classify them correctly, and add CLI flags for quantization configs. I can mock the profiler traces to test this locally. PR should be ready in a few days. 复制留言 大致实施方案 收集 bitsandbytes 常见的 kernel 名称（如 igemmlt, quantize_blockwise 等）。 在 profile.py 中扩展分类规则，将这些 kernel 映射到新的类型（如 quant_matmul）。 编写一个简单的 mock 测试，模拟包含量化 kernel 的 profiler 输出，验证分类逻辑。 可能涉及的目录或文件 验收方式 运行包含 mock 量化 kernel 名称的单元测试，确保它们被正确分类。 开工前问题与风险 向维护者确认 是否希望在 profile.py 中直接引入 bitsandbytes 依赖，还是仅通过字符串匹配 kernel 名称？ 风险 无法在 Mac 上真实运行 bnb 模型，需依赖离线 trace 或 mock 数据进行验证。 任务 4 可选 · medium · Mac · 2-3个晚上
增强 Profiler 输出以支持 Temporal Breakdown 分析 Issue #1 · Feature Request: better profiler to identify bottleneck in performance ↗
无人认领 2 条评论 更新 2026-03-12
用到的专长： PyTorch Profiler、性能瓶颈分析
目标： 扩展 profile.py，解析 torch.profiler 的输出，生成类似 HTA 的 temporal breakdown（如计算、内存、通信的时间占比）。
为什么值得长期做： 深入项目的性能分析核心，为 Agent 提供更丰富的上下文，直接发挥你的性能调优经验。
怎么介入： Issue 提出者给出了建议，维护者有回复。可以留言提议实现一个轻量级的内置解析器。第一个 PR 的边界： 修改 profile.py，增加对 profiler events 的汇总统计逻辑。
第一步： 研究 torch.profiler 导出的 JSON trace 格式，找出如何区分计算和内存操作。
本机怎么复现 / 验证： 在 Mac 上准备一个 trace.json，编写脚本调用 profile.py 中的解析函数并打印结果。
认领留言（英文，可直接贴到 Issue） I can help enhance profile.py to provide a basic temporal breakdown (compute vs memory vs overhead) by parsing the torch.profiler events directly, without adding heavy dependencies like HTA. This will give the agent better context on where the time is spent. I can develop and test this using offline traces. Let me know if this approach works for you. 复制留言 大致实施方案 在 profile.py 中添加逻辑，遍历 profiler events。 统计不同类型操作（如 aten:: 算子、cudaMemcpy 等）的耗时。 在输出的 profile 报告中增加 temporal_breakdown 字段。 可能涉及的目录或文件 验收方式 使用预先捕获的 trace 文件在 Mac 上运行分析脚本，检查输出的 breakdown 比例是否合理。 开工前问题与风险 向维护者确认 是否希望引入外部库（如 hta）还是保持零依赖自己解析 trace？ 风险 自己解析 trace 可能不够准确，引入 hta 可能增加依赖负担。