SparseDitto 这类项目值得先关注的不是“生成了多少行 CUDA 代码”而是它把“稀疏模式分析、GPU Kernel 生成、编译验证、性能迭代”整条链路自动化了。做过大模型推理、推荐系统或图神经网络的人应该都有体会稀疏计算从来不是一套算子吃遍所有场景非结构化稀疏、2:4 结构化稀疏、块稀疏、行稀疏的处理方式差别非常大。SparseDitto 的核心思路是用 LLM 驱动的 Agent 系统针对不同稀疏模式自动生成和定制 GPU Kernel把原本需要人工写 CUDA、反复调参的环节变成可重复的工程流程。适合看这篇文章的人正在做 GPU 算子开发、LLM 推理优化、模型稀疏化落地的工程师或者想了解 LLM Agent 在编译器和系统软件层面能怎么用的人。下面按实际落地顺序拆解。1. 为什么稀疏计算需要“按模式定制”的 GPU Kernel1.1 稀疏模式不是一种而是一族稀疏张量听起来是一个统一概念但落到 GPU 上不同模式的存储形式和计算路径完全不同。常见模式可以简单分成四类非结构化稀疏零元素位置完全随机通常用 COO、CSR 或 CSC 存储遍历时索引跳跃很大。结构化稀疏比如 N:M 稀疏最典型的是 2:4模型剪枝后很常见硬件和编译器可以针对固定比例做优化。块稀疏以固定大小的块为基本单位块内要么全零要么非零MoE 和部分 NLP 模型里经常出现。行稀疏、列稀疏、带状稀疏推荐系统、图数据和某些科学计算场景里更常见特点是非零元素集中在固定位置。这些模式直接决定了数据布局和线程映射。为 2:4 结构化稀疏写的 Kernel拿去跑块稀疏任务很可能一半线程在空转。反过来为块稀疏设计的 Kernel遇到非结构化稀疏时会因为索引查找开销太大而退化。1.2 同一份 Kernel 在不同稀疏率下表现完全不同除了模式稀疏率也很关键。稀疏率 50% 和 99%对应的优化策略是两个方向。稀疏率低时压缩存储带来的索引开销可能比省下的计算量还大。这时候 dense 计算加 mask 反而更快。稀疏率非常高时核心目标变成减少访存和线程空转必须把非零元素紧凑排布同时处理好负载均衡、向量化、bank conflict 和 warp divergence 这些问题。所以“定制”不是给代码加几个 if 分支而是针对某个模式、某个稀疏率区间、某个目标 GPU重写数据布局和线程组织方式。这也是为什么一个优化好的稀疏 Kernel很难直接复用到另一个模型上。1.3 人工写 Kernel 的真实成本手写一个正确且高性能的 CUDA Kernel成本通常被低估。先要理解模式特征然后设计存储格式再写索引计算接着处理边界和同步最后还要用 ncu 或 nsys 做性能分析反复调 block 大小、shared memory 和访存顺序。这一套流程对经验要求很高而且换个稀疏模式基本要重来一遍。SparseDitto 这类系统想解决的问题不是让 LLM 一步写出超越专家的 Kernel而是把“从模式描述到可测试 Kernel”的时间压缩让更多工程师先拿到一个能跑、能测、能对比的版本再决定要不要人工深调。2. LLM Agent 在 Kernel 定制里到底做什么2.1 从项目定位看核心链路从项目名称和这类系统的常见设计来看SparseDitto 的核心不是直接调用 LLM 生成一段代码就结束而是构建了一套 Agentic System。这类系统通常会按下面这条链路运行输入一个稀疏张量或稀疏模式描述。分析模式特征比如密度、分布、块大小、存储格式。Agent 根据模式生成候选 Kernel 代码。调用编译器检查代码能否编译。在 GPU 上跑正确性测试和 dense 参考结果对比。用 profiling 工具采集性能数据。把编译报错、正确性偏差、性能数据回传给 LLM继续迭代。这条链路的关键是最后一步。LLM 第一次生成的底层代码大概率有编译错误、边界问题或性能问题。只有把运行结果反馈给它才能形成有效迭代。2.2 为什么单次生成不够很多人把 LLM 生成代码理解成“一次给全”但在 GPU Kernel 场景里基本不成立。Kernel 代码的错误往往不是语法错误而是索引偏移、线程块边界、共享内存大小、同步缺失这类运行时问题。Agentic System 的意义在于它不只是写代码还能调用工具、读取报错、修改代码、重新编译。这更像一个能自己测试和返工的助手而不是代码补全插件。设计时需要注意Agent 的上下文长度有上限报错日志和调试信息要截断后喂给模型否则迭代几轮后反而会因为上下文太长而质量下降。2.3 它和 Triton、TVM、cuSPARSE 的关系这个定位容易让人误会以为 SparseDitto 要替代编译器或通用库。实际上更合理的理解是它站在这些工具之上。cuSPARSE、cuBLAS 这类库覆盖通用 shape但如果模型刚剪枝出一个新 pattern库未必马上有适配。Triton 是手写 DSL能让 LLM 更容易生成相对合理的 Kernel但复杂稀疏遍历仍然需要人工设计。TVM、AutoTVM 是模板加自动搜索搜索空间的设计本身是人工工作。SparseDitto 这类系统的思路是用 LLM 生成候选代码再借助现有编译器和 profiling 工具做验证和迭代。它更像一个“会用现有工具的算子助手”而不是重新发明编译流程。3. 想跑这类系统环境需要先准备好3.1 基础环境按优先级来建议按照下面的检查顺序准备环境而不是一上来就装一堆依赖。项目建议说明GPUNVIDIA GPU支持 CUDA学习用 4GB 显存也能跑小矩阵8GB 以上更舒服驱动和 CUDA 版本匹配先跑 nvidia-smi 确认CUDA Toolkit11.x 或 12.x具体版本看 PyTorch 和 Triton 要求Python3.10 以上PyTorchGPU 版本安装时确认 CUDA 版本对应Triton和 PyTorch 匹配的版本生成代码用 Triton 实现比裸 CUDA 更容易调试LLM 运行时Ollama 或 API 服务本地跑小模型也可以但生成质量可能受限PyTorch 的 GPU 版安装是新手最常卡住的地方。装完以后别急着跑项目先确认 torch 能看到 GPU。nvidia-smi python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))两条命令都正常再继续下一步。3.2 GPU 调用失败先查驱动的三层结构如果你在 WSL 或 Linux 容器里跑GPU 调用失败的问题会比本地 Windows 多很多。最常见的报错是 NVML 初始化失败或者消息里出现 “gpu access blocked by the operating system” 这类提示。我的排查顺序通常是这样先确认 nvidia-smi 在宿主机上能正常输出。在 WSL 里再跑一次 nvidia-smi确认设备透传正常。检查 Windows 侧是否安装了带 WSL 支持的 GPU 驱动而不是仅支持 Windows 的旧驱动。如果驱动更新过把 WSL 完全关掉再重新打开很多时候是驱动加载时机问题。最后再看 PyTorch 和 CUDA 版本是否匹配。这些不是 SparseDitto 本身的问题但跑这类系统时GPU 环境不稳定会直接干扰 Kernel 测试结果。你可能浪费很多时间在调 Kernel最后发现是驱动版本不对。如果你的机器是 AMD GPU情况还要更复杂一些。Ollama、PyTorch 默认不会直接识别需要单独配置 ROCm 或对应的运行时路径。SparseDitto 这类 Kernel 生成系统通常默认走 NVIDIA/CUDA 路线先确认后端支持范围再决定要不要投入时间。3.3 LLM 运行时怎么选生成 Kernel 的 LLM 建议选代码能力强的模型。本地跑可以用 Ollama 加开源模型好处是数据不出本机批量迭代成本低。如果只是快速验证也可以用 API 服务但要考虑每轮迭代的 token 消耗。有一点要注意Kernel 生成任务需要多轮调用 Agent每轮都包含报错日志和代码上下文token 消耗比普通对话高很多。所以不要一上来就用超大模型跑全量任务先用小矩阵、小模型把链路跑通再逐步放大。4. 实操从一个最小稀疏任务开始跑通完整流程4.1 先定义输入和参考输出第一次测试不要直接上一个真实模型而是构造一个能快速验证的最小任务。比如 1024x1024 或 4096x4096 的 float32 矩阵按某一种稀疏模式生成稀疏率定在 90% 左右。参考输出用 dense 计算得到代码就是普通 PyTorch matmul。这一步很关键因为后续所有 Kernel 生成结果都是和这个参考输出对比参考输出错了后面全错。为什么先用小矩阵因为生成代码第一次跑大概率有 bug小矩阵能让每次编译、运行、日志采集都在几秒内完成迭代效率高很多。等 Kernel 稳定了再换成真实尺寸。4.2 给 Agent 的初始输入怎么组织Agent 能不能生成有用代码很大程度上取决于你给它的信息是否完整。一个比较可靠的 prompt 结构是下面这样稀疏模式说明比如“块稀疏块大小 32x32稀疏率 90%”存储格式比如 CSR 还是 BSR目标计算语义比如“矩阵-向量乘”正确性要求比如“和 PyTorch dense 结果对比最大误差小于 1e-3”环境信息比如 GPU 型号、CUDA 版本、Triton 版本输出要求比如“先给一个最小可用版本再给优化版本”下面是我常用的示例 prompt 结构你是一名 GPU Kernel 优化工程师。 输入是 4096x4096 的 float32 矩阵稀疏模式为块稀疏 块大小 32x32整体稀疏率约 90%使用 BSR 格式存储。 请生成矩阵-向量乘的 Triton Kernel要求 1. 与 torch dense matmul 结果对比最大误差小于 1e-3。 2. 最小可用版本在前优化说明在后。 3. 只输出代码和必要说明不要写泛泛的优化建议。这只是示例实际使用时要把矩阵名、函数签名、调用方式写清楚越具体越好。4.3 生成、编译、测试、迭代拿到第一版代码后不要直接上全量数据。按下面的顺序走一遍先用 1024x1024 的输入跑编译和正确性测试。如果编译报错把完整报错日志截断后喂给 Agent让它修复。如果结果错误反馈“哪个位置的元素不匹配最大误差多少”。正确之后再跑性能测试把 profiling 结果回传。一轮只让 Agent 解决一类问题避免同时让改一堆东西。整个运行时循环可以理解成下面这个伪代码for i in range(max_iterations): code llm.generate(prompt) result compile_and_test(code) if result.compile_failed: prompt build_feedback(result.error_log) elif result.correctness_failed: prompt build_feedback(result.mismatch_info) elif result.performance_ok: break else: prompt build_feedback(result.profile_data)最关键的是设置迭代上限。我一般会限制在 5 到 10 轮以内超过上限就重置 prompt。因为 Agent 有时候会在同一个 bug 上反复试错与其让它一直修不如把上下文清掉重来。4.4 生成结果要进版本管理很多人会忽略这一步。生成式 Kernel 的特征是代码变化很快每一轮修改都可能引入新问题。建议把每次 prompt、生成的代码、测试结果、性能日志都保存下来。这不是为了归档而是为了对比。你可以回放任意一版代码看它的正确性和性能是怎么变化的。如果直接往生产目录里扔生成代码后面排查问题会非常痛苦。5. 判断一个 Kernel 值不值得用的四把尺子5.1 正确性不能只看一次相等生成 Kernel 通过一次测试不代表没问题。我一般会在不同 shape、不同稀疏率、不同 dtype 下各跑一遍。比较时注意三点参考输出用 dense 或可信的高精度实现不要用另一个可能同样错的稀疏实现。看最大误差而不是只看是否 True。float32 下最大误差小于 1e-3 通常可接受但具体阈值取决于业务。要测边界比如全零矩阵、