几乎每个做过稀疏模型推理的人，都会在某个深夜面对同一种困惑：模型剪枝后，权重文件小了一半，理论上 FLOPs 也明显下降，可真正部署到 GPU 上之后，实测延迟不仅没有下降，有时候反而更慢。打开 Nsight 一看，SM 占用率不高，访存事务极度不规则，数据还挤在同一个 bank 里不断冲突。问题往往不在模型结构，而在那一层“不匹配的 kernel”。
稀疏模型的性能，从来不是由“稀疏了多少”决定的，而是由“跑在哪个 kernel 上”决定的。GPU 的矩阵计算性能高度依赖数据在显存、寄存器和线程之间的排列方式。一个为稠密矩阵设计的 GEMM kernel，遇到非结构化稀疏矩阵时会产生大量无效分支、负载不均和访存浪费。现代 GPU 的指令集和硬件单元虽然对稀疏有不同程度的支持，但要让真正的加速发生，必须针对特定稀疏模式定制专门的 kernel。
SparseDitto 这个方向，瞄准的正是这个痛点。从项目标题可以明确读出它的技术主张：用 LLM 驱动的 Agent 系统，理解不同的 sparsity pattern，并自动定制对应的 GPU kernel。本文不会把 SparseDitto 当作一个可以下载安装的开源工具来“手把手部署”——从已有材料看，它更像一个正在被研究、讨论和验证的系统设计理念——但恰恰是这个理念，值得模型部署工程师和 AI Infra 开发者认真拆解。
接下来，我会沿着“问题 → 原理 → 传统瓶颈 → Agent 系统设计 → 概念实现 → 验证排错”这条线，说明它到底解决了什么，为什么由 LLM 来做这件事，以及如果你想把类似思路引入自己的算子开发流程，应该从哪里入手。
1. 这篇文章真正要解决的问题
先给读者一个明确判断：SparseDitto 这类系统的核心价值，不是“让 AI 帮你写几段 CUDA 代码”，而是把“稀疏模式分析、Kernel 生成、编译反馈、性能迭代”这一整条链路，从过去依赖资深工程师经验的低效事务，变成一个可以被 LLM Agent 自动执行和反复优化的闭环。
在传统开发流程里，为一个新的稀疏模型定制算子，通常要经历下面几个痛苦环节：
- 分析模型权重在剪枝后的稀疏模式，判断是随机稀疏、块状稀疏还是 N:M 结构化稀疏；
- 查找有没有现成的稀疏矩阵库或算子可以复用，比如 cuSPARSE、DGL、Sputnik 等；
- 如果没有现成实现，手写 CUDA kernel，并处理索引压缩、内存对齐、负载均衡、bank conflict 等问题；
- 在不同 shape、不同稀疏率下反复跑 benchmark，验证性能是否真正优于稠密 baseline。
整个过程属于典型的“高经验门槛 + 长调试周期”。一个熟悉 GPU 编程的工程师，面对一种新的稀疏模式，从设计到调通，花上几天甚至几周都很正常。更麻烦的是，深度学习模型里的稀疏模式常常不止一种：前几层可能是 block sparse，中间层是 N:M，最后的分类头可能几乎稠密。一种 kernel 打天下的局面根本不存在。
SparseDitto 的出发点，就是解决这种“碎片化定制”问题。它把 GPU kernel 定制拆解成多个可以由 LLM Agent 独立完成的小任务，让大模型负责模式识别、代码生成和错误修复，让编译器和 profile 工具负责反馈，形成一个自动迭代的系统。这个思路一旦跑通，受益的会是三批人：
第一，模型部署工程师。部署剪枝模型时，不再因为算子不匹配而放弃压缩收益；第二，推理引擎开发者。在为 LLM 推理框架适配不同 GPU 架构和新稀疏格式时，能够用更短时间生成候选 kernel；第三，AI Infra 研究者。可以把代码生成和自动调优结合，探索比传统 AutoTVM 更灵活、更懂上下文的优化方案。
同时也要注意，这不意味着 LLM 能凭空写出超越专家手工优化的 CUDA。它在当前更实际的定位是“自动化的初级算子工程师”加“快速迭代器”：能够生成可用版本，再由编译反馈和 profile 数据驱动它逐步逼近更优实现。
2. 稀疏模式与 GPU Kernel：为什么“一个 Kernel 打天下”不成立
想要理解 SparseDitto 的难点，先要理解一个基础事实：稀疏模式本身就是 GPU Kernel 的“输入条件”，而不是代码里一个可以简单判断的分支。
2.1 稀疏模式的本质：数据布局决定性能
GPU 上矩阵运算的性能瓶颈往往不在计算单元，而在数据搬运。稠密 GEMM 之所以能跑出很高算力，关键之一是数据在显存、L2、共享内存、寄存器的搬运路径是规则且可预测的。稀疏矩阵引入的第一个问题就是：规则的数据流被切断了。
如果稀疏是随机的，矩阵中非零元素的位置没有规律，那么存储时必须用索引来标记位置，比如 CSR、CSC 格式。访存时要先读索引，再跳转到对应的数据位置，容易造成：
- 内存事务碎片化，一个 warp 内不同线程访问的地址跨度很大；
- 数据在共享内存里产生 bank conflict，导致访问串行化；
- 线程负载不均衡，有的线程处理大量非零元素，有的几乎闲置。
如果稀疏是结构化的，例如固定每 4 个元素保留 2 个的 2:4 模式，或者按 64x64 的 tile 剪枝，那么数据布局可以提前规划，甚至可以用掩码而非完整索引来表达位置。这样 kernel 里的访存和计算路径会重新变得规则，硬件也能更高效地利用稀疏指令。
2.2 常见稀疏模式与 Kernel 关注点
下面用一张表把几种常见稀疏模式和它们在 GPU Kernel 设计中的核心关注点列出来。
| 稀疏模式 | 典型来源 | 数据表达 | Kernel 设计关注点 |
|---|---|---|---|
| 非结构化稀疏 | 低精度剪枝、随机剪枝 | CSR / CSC / COO | 索引访存开销、负载均衡、线程调度 |
| Block Sparse | 基于块剪枝、硬件结构化剪枝 | 固定块大小 + bitmap | Tile 大小、块内连续访存、共享内存利用率 |
| N:M 结构化稀疏 | 面向硬件稀疏指令的剪枝 | 掩码 + 压缩非零值 | 如何利用硬件稀疏指令、索引压缩与对齐 |
| Channel / Filter 稀疏 | 结构化剪枝、通道裁剪 | 去除整个通道或滤波器 | 不必存索引，但需要重排内存布局 |
| 稠密 | 未剪枝的原始模型 | 连续多维数组 | 常规 GEMM 优化、tensor core 对齐 |
这张表说明一个重要结论：不同的稀疏模式，会导向完全不同的存储格式和 kernel 策略。面向 N:M 稀疏优化的 kernel，很难直接处理 block sparse 的矩阵；为 CSR 格式写的高性能 kernel，也无法高效处理 2:4 掩码模式。
2.3 为什么不能靠编译器自动解决
很多读者会问：TVM、MLIR、Triton 这类工具不是已经可以自动生成代码了吗？为什么还需要专门的大模型 Agent？
答案是：编译器擅长在给定计算描述和调度策略后做代码生成，但它不擅长“理解稀疏矩阵的来源和语义”。一个权重矩阵的稀疏模式，是从剪枝算法产生的；这个模式在多大比例上是规则的，是否适合用 tensor core 的稀疏指令，是否可以通过重排来提升局部性，这些判断需要领域知识。
编译器需要人明确告诉它“按 block size=32 分块”或“使用某条 sparse load 指令”，而 SparseDitto 想省掉的正是这一步。它希望 LLM 能直接从 profile 数据和稀疏结构描述中，推断出应该用哪种存储格式、哪种 kernel 策略，然后生成代码。这是它与传统代码生成工具在定位上的最大区别。
3. 传统 GPU Kernel 定制手段的瓶颈
在讨论 SparseDitto 之前，先客观评估一下现有手段。把它们的瓶颈说清楚，才能理解 LLM Agent 的出现为什么有价值。
3.1 手写 CUDA Kernel：高质量，但成本极高
手写 CUDA kernel 是“天花板”最高的方式，也是成本最高的方式。资深 GPU 工程师可以直接控制 shared memory、寄存器分配、warp 调度、异步拷贝等细节，为一种稀疏模式写出性能极佳的 kernel。但在工业化场景里，模型的稀疏模式经常变化，不可能为每一种新模式都养一个算子专家。
另一个问题是调试周期长。CUDA kernel 一旦涉及复杂索引计算，很容易出现越界、hazard、同步错误。加上 GPU 上调试工具不如 CPU 侧成熟，定位一个性能问题往往需要反复看 Nsight 报告，过程相当琐碎。
3.2 Triton 等 DSL：降低了编码门槛，但策略判断仍需人工
Triton 这类 Python 嵌入式 DSL 的出现，大大降低了编写 GPU kernel 的门槛。它屏蔽了 CUDA 里大量底层细节，让开发者可以用更接近 NumPy 的方式描述计算。对于规整的稠密算子，Triton 能生成非常不错的代码。
但稀疏场景并不那么适用。Triton 的设计假设是“每个 tile 内的数据访问相对规则”，而稀疏矩阵在 tile 粒度上就不规则。尽管 Triton 提供了 mask 等机制，但如何设计 tile 大小、如何处理索引、如何减少 mask 判断带来的浪费，依然需要人工决定。简而言之，Triton 可以降低“写 kernel”的难度，却并没有降低“设计 kernel 策略”的难度。
3.3 TVM / MLIR / AutoTVM：自动搜索空间巨大，但模式感知弱
编译器路线提供了自动调优的可能性。AutoTVM、Ansor 等系统可以在计算图上执行调度搜索，自动尝试 tile size、循环展开、线程绑定等组合。问题是搜索空间巨大，跑一轮可能要很长时间；而且它依赖 tvm 的算子模板。
在面对稀疏矩阵时，这种方案会遇到一个更深的问题：稀疏模式的多样性，意味着存储格式和 kernel 结构都需要变化，而不只是调度参数变化。编译器无法从零生成一个全新的 sparse kernel 结构，只能在已有模板里做参数搜索。如果没有人先把 kernel 模板写出来，自动调优也无从谈起。
3.4 传统方案的共同缺口
把它们放在一起看，缺口的共性就清楚了：人在关键时刻通过阅读 profile、观察数据规律、结合经验做出“换一个 kernel 思路”的决策，自动化工具只能接住后面“调参数”这一步。SparseDitto 想用 LLM 填补的，正是这个最需要判断力的环节。
| 方案 | 优势 | 瓶颈 | 适合场景 |
|---|---|---|---|
| 手写 CUDA Kernel | 性能天花板最高，控制力强 | 成本高、迭代慢、依赖专家 | 少数核心算子，长期复用 |
| Triton / DSL | 编码门槛低，迭代快 | 稀疏策略仍需人工判断 | 规整算子，稀疏程度较轻 |
| TVM / AutoTVM | 参数搜索自动化 | 搜索空间大，模板依赖强 | 计算形态稳定的算子 |
| LLM Agent 系统 | 能理解上下文和模式，自动迭代 | 生成质量不稳定，需要安全机制 | 稀疏模式多变的场景 |
4. SparseDitto 的核心思路：Agent 系统如何定制 Kernel
讲了这么多瓶颈，接下来进入正题：SparseDitto 这类系统内部是怎么运作的。
4.1 先理解“Agentic System”在这里意味着什么
“LLM-Based Agentic System”并不是简单地把提示词发给大模型，让它返回一段代码。它强调的是：LLM 作为系统里的“决策中心和工具调用者”，主动观察环境、生成动作、接收反馈并不断修正。
在 SparseDitto 的场景里，环境就是“GPU + 矩阵数据 + 编译器 + profiler”。LLM Agent 的任务是结合稀疏模式的观察结果，生成一个 kernel 候选；执行环境返回编译错误或性能数据后，Agent 再基于这些反馈修改代码或策略。
这与传统自动化工具的区别在于：LLM 拥有“语言语义理解”能力，它能读 bool 值、读 profile 报告，也能读一段 CUDA 源码中 addr 计算存在的问题。它可以在符号层面做推理，而不是像 AutoTVM 那样只能调数值参数。
4.2 从标题倒推出的系统模块
虽然公开材料没有给出 SparseDitto 的完整架构，但从标题和同类研究的设计逻辑，可以合理推断出一个 Agent 系统至少需要以下四个模块：
| 模块 | 职责 | 可以使用的工具/接口 |
|---|---|---|
| Sparsity Analyzer | 读取矩阵或模型权重，分析非零值分布、稀疏率、模式规律 | PyTorch / NumPy 统计、scipy.sparse |
| Kernel Generator | 根据稀疏模式描述、目标 GPU 架构和优化要求，生成 kernel 候选代码 | 大模型 API、本地 LLM、代码模板 |
| Compiler & Runtime Feedback | 编译代码、执行测试、收集错误信息和性能指标 | nvcc、gcc、Nsight Compute、Python |
| Iterative Optimizer | 根据反馈修改 prompt 或直接修改源码，控制迭代轮数和回滚 | 多轮 Agent 循环、代码 patch 工具 |
从系统设计上看，SparseDitto 真正难的并不是“生成第一版代码”，而是如何让最后两块反馈足够清晰、足够频繁，让 LLM 能在每一轮迭代中看到有效的改进信号。
4.3 Agent 系统与传统 AutoTurbo 的关键差异
如果只用一句话概括，那就是：传统自动调参在“调度空间”里搜索，而 LLM Agent 可以在“算法结构空间”里搜索。前者改的是 tile 大小，后者可能直接把 CSR kernel 换成 N:M mask kernel，这是质的差别。
这种能力带来的另一个重要变化是可解释性。LLM Agent 每次修改，都可以用自然语言解释“为什么这样改”。工程师能更快判断它的决策是否靠谱，而不需要完全相信黑盒搜索结果。这在 GPU kernel 这样需要严格验证的领域，是很大的工程价值。
5. 概念原型实现：从模式分析到 Kernel 生成
下面用一个概念原型演示这类 Agent 工作流的核心逻辑。需要提前说明：这不是 SparseDitto 的官方 API，也不是某个开源项目的真实代码，而是帮助你理解这类系统落地时的关键路径。
5.1 第一步：把稀疏模式变成结构化描述
要让 LLM 参与决策，第一步是给它一份清晰的“稀疏模式体检报告”。相比直接丢一个巨大矩阵，先用工具提取出模式特征更可靠。这一步在具体系统里可以是一个独立脚本。
下面的 JSON 是你可以提交给 LLM 的稀疏模式描述示例：
{ "matrix_name": "attention.weight", "shape": [4096, 4096], "dtype": "float16", "sparsity_ratio": 0.5, "pattern_analysis": { "non_zero_distribution": "uniform", "block_structure": true, "block_size": [64, 64], "zero_rows": false, "zero_columns": false }, "target_gpu": "A100", "kernel_requirements": { "use_sparse_instructs": true, "target_tensor_core": true, "memory_bandwidth_limit": "2025 GB/s" } }这份描述的价值在于它把一张稀疏矩阵的“形态”翻译成了 LLM 更容易理解和推理的结构化信息，而不是让模型自己读一个几百 MB 的权重文件。
5.2 第二步：构造 Kernel 生成 Prompt
LLM 生成代码的质量，高度依赖 prompt 中给出的信息。一个合格的 prompt 至少应包含：任务定义、稀疏模式描述、目标 GPU 架构、约束条件、以及可选的 few-shot 示例。
SYSTEM_PROMPT = """ 你是一个 GPU Kernel 优化工程师。用户会提供稀疏矩阵的模式描述和目标 GPU 架构。 你需要生成一个可以编译执行的 kernel 源码或者等价算子实现。 要求： 1. 优先保证正确性，再进行性能优化。 2. 代码中必须有清晰的注释，说明关键设计决策。 3. 如果矩阵满足 block structure，优先考虑固定 tile 的 block sparse 策略。 4. 如果矩阵是 N:M 稀疏模式，考虑使用硬件稀疏指令。 5. 不要生成无法编译的伪代码。 """ def build_generate_prompt(sparse_info: dict, base_kernel: str) -> str: return f""" {SYSTEM_PROMPT} 下面是稀疏模式的 JSON 描述： {sparse_info} 下面是一个可参考的基础 kernel 模板： {base_kernel} 请针对该稀疏模式生成更合适的 kernel，并解释你的改动理由。 """这段代码展示了一个常见做法：把稀疏模式 JSON 和已有 kernel 模板一起塞给 LLM，让它输出新 kernel。这里真正容易踩坑的是，如果不提供基础模板，LLM 可能会生成一个结构上完全不同、但性能更差的实现。因此在概念原型中，保留一个可重复迭代的起点非常重要。
5.3 第三步：Agent 迭代循环
核心循环并不复杂：生成 → 编译 → 运行 → 反馈 → 再生成。难点在于每次反馈的信息质量。
import subprocess def run_agent_loop( generator, sparse_info: dict, base_kernel: str, max_iters: int = 5 ): kernel = base_kernel history = [] for i in range(max_iters): prompt = build_generate_prompt(sparse_info, kernel) new_kernel = generator.generate(prompt) # 编译并运行一个最小测试 ok, feedback = compile_and_run_kernel(new_kernel) if ok: performance = profile_kernel(new_kernel) feedback = f"编译运行通过，性能指标：{performance}" history.append((new_kernel, feedback)) # 如果性能达标，停止迭代 if performance.get("speedup", 0) > 1.5: return new_kernel, history else: history.append((new_kernel, feedback)) # 把编译错误或 profile 反馈作为上下文传给下一步 kernel = new_kernel # 返回效果最好的一版，而不是最后一版 return best_kernel_from_history(history)这段伪代码里最值得学习的一点是：不要让 Agent 在失败后一头冲到下一轮。把编译错误、profile 结果、甚至nvcc的告警信息都塞回 prompt，让 LLM 理解“刚才错在哪里”，才能产生真正有效的迭代。同时，如果多轮迭代后效果不佳，要从历史中挑出最快的一版，而不是默认接受最后一版，这是工程上必须避免的一个问题。
5.4 这一部分的小结论
从这个概念原型可以看出，SparseDitto 这类系统的实现难点不在于“能用大模型生成代码”，而在于：
- 如何把稀疏模式量化成 LLM 可理解的结构化信息；
- 如何把编译器和 profiler 的输出，转化成 LLM 能吸收的反馈语言；
- 如何设计迭代终止条件，避免无限循环和性能回退。
6. 如何验证 Agent 生成的 Kernel 是否可靠
如果 Agent 真的生成了一版 kernel，验证工作就成了关键。GPU kernel 的验证大致分三层：正确性、性能、稳定性。
6.1 正确性验证
正确性验证的核心原则很简单：用一个可信的 baseline 做对比。最稳妥的 baseline 是稠密矩阵计算结果，或者用scipy.sparse等成熟库的自定义结果。
具体验证维度包括：
- 最大绝对误差和相对误差；
- 是否出现 NaN 或 Inf；
- 在不同随机输入下多次运行，结果是否一致；
- 对特殊 shape 和小矩阵是否仍然正确。
6.2 性能验证
性能验证不能只跑一个 batch 就下结论。需要覆盖不同矩阵大小、不同稀疏率、不同数据分布。常用工具包括 Nsight Compute 和 Nsight Systems。
下面是一套通用的验证命令流程，重点展示“编译 → 运行 → profile”三个环节的配合：
# 1. 用 nvcc 编译 kernel 测试程序（这里以测试文件为例） nvcc -arch=sm_80 -O3 -o test_kernel test_kernel.cu # 2. 运行可执行文件，确认正确性 ./test_kernel --verify --tol 1e-3 # 3. 用 Nsight Compute 抓取 kernel 性能指标 ncu --section MemoryWorkloadAnalysis --section SpeedOfLight ./test_kernel # 4. 用 Nsight Systems 观察整体端到端时间 nsys profile -o test_profile ./test_kernel --benchmark在这套流程里，真正需要 Agent 关注的是第三步输出中的几个核心指标：Memory Throughput、Compute Throughput、Achieved Occupancy、以及 Wave Occupancy。如果内存吞吐远高于计算吞吐，说明 kernel 仍然卡在访存，需要考虑调整数据布局。如果 occupancy 很低，则说明线程数或寄存器占用可能存在问题。
6.3 稳定性验证
性能验证容易忽略但同样重要的是稳定性。矩阵的稀疏模式可能只在一定范围内被正确识别，如果输入是一个稀疏率突然升高或降低的矩阵，kernel 可能退化甚至出错。在实际工程里，要设置一组回归测试矩阵，覆盖：
- 稀疏率 50% 附近；
- 稀疏率极高和极低的情况；
- 不同 block size 的矩阵；
- 极端 shape，比如 1xN 或 Nx1。
6.4 验证阶段的小结论
一句话：Agent 生成代码只是系统的“上半场”，验证才是决定它能否被信任的“下半场”。如果验证流程没有做好，LLM 的生成能力反而会变成一种风险——代码运行快是真的，但结果可能是错的。
7. 常见问题与排查思路
LLM 驱动的 GPU kernel 定制，一定会遇到下面几类问题。这里列成排查表，方便直接对照排查。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 生成的 CUDA 代码编译失败 | 使用了当前架构不支持的指令，或索引类型错误 | 查看 nvcc 报错行号，确认目标架构 | 把编译错误信息反馈给 LLM，要求按报错修改；指定正确的 arch |
| 编译通过但运行结果错误 | 索引计算越界、mask 逻辑写错、共享内存同步缺失 | 先用小矩阵单步排查；和稠密 baseline 对拍 | 把错误的 shape 和期望输出喂给 LLM，重点检查边界条件 |
| 性能反而比稠密 kernel 差 | 稀疏率不够高、索引开销过大、内存访问不连续 | 用 ncu 查看 Memory Workload Analysis | 降低索引粒度，或改用 block sparse 策略；考虑是否适合用稀疏 kernel |
| Agent 多轮迭代仍然失败 | 反馈信息不完整，LLM 没有理解失败原因 | 检查传给 LLM 的 prompt 是否包含完整错误日志 | 增加编译错误、profile 摘要、运行返回值等反馈字段 |
| 某次修改性能提升明显，但下一次改动回退 | 缺少回归基准，Agent 在局部搜索空间震荡 | 记录每一版性能，建立回归对比 | 设置性能阈值，只接受超过阈值的版本；否则保留上一版 |
| 生成的 kernel 在特定 shape 下性能骤降 | 测试矩阵 shape 覆盖不足 | 增加不同 shape 的回归矩阵 | 在 prompt 中显式要求兼容 shape 范围，或加入 shape 自适应逻辑 |
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| LLM 生成时出现幻觉 API | 大模型记忆了不存在的库函数或指令 | 对比 CUDA 文档，检查编译错误 | 增加工具调用，让 Agent 先查询文档或已有代码库 |
| 花费剧烈增长 | 每轮都调用大模型，prompt 越来越长 | 检查 token 统计，观察历史记录长度 | 压缩历史，只保留最近几轮关键反馈；本地小模型兜底 |
这些问题的共同点是：大部分并不是 LLM 本身“聪明不聪明”的问题，而是系统设计有没有把反馈闭环做好。反馈越清晰、越结构化，LLM 的效果越稳定。
8. 最佳实践与工程建议
最后，从工程落地角度给出一组建议。如果你准备在自己的项目里尝试“LLM Agent 定制 GPU Kernel”这个方向，以下几件事值得提前规划。
8.1 从模板出发，不要从零生成
LLM 生成一个完全陌生的 kernel，出错概率很高。更稳妥的方式是：准备几个经过验证的基础 kernel 模板（稠密 GEMM、CSR SPMM、block sparse SPMM），让 Agent 在模板基础上做修改。这和人类工程师的工作方式是一致的：先站在靠谱的框架上，再针对稀疏模式做局部优化。从零生成只适合探索性实验，不适合写入生产路径。
8.2 把 Profiling 数据当成对话上下文
这是很多人忽略的一点。LLM Agent 的优势是能“读报告”。与其在 prompt 里写“请优化性能”，不如直接把 Nsight Compute 的关键指标摘要喂给它，比如“当前 kernel 的 DRAM throughput 只有 30%，sector 利用率低”。这种具体反馈能显著提升 Agent 下一轮修改的针对性。
8.3 建立回归测试和 A/B 验证
任何由 Agent 生成的 kernel，都必须纳入回归测试。不要因为它被验证过一次就长期信任。矩阵 shape 变化、GPU 驱动更新、甚至是 LLM 模型版本的替换，都可能引入隐性变化。生产环境里建议默认保留原 kernel，新 kernel 先灰度，通过率和性能都达标后再切换。
8.4 安全边界与权限控制
这一点必须强调：让 LLM 生成 GPU kernel，本质上是让 AI 编写直接运行在硬件上的代码。在开发和测试环境里，应该在沙箱中编译和执行；在生产环境，需要设置最小权限、代码审查和回滚机制。不要让 Agent 直接向生产环境提交代码。对于任何涉及线上变更的操作，都要先经过人工 review 和备份恢复预案。
8.5 判断哪些场景值得用这套方案
不是所有稀疏场景都需要引入 LLM Agent。从成本收益看，下面这些场景更值得使用：
- N:M 结构化稀疏：硬件有对应稀疏指令，但 kernel 策略因模型而异，适合让 Agent 探索；
- Block sparse：需要根据 block size 和矩阵 shape 调整 tile 策略；
- 多变稀疏模式：模型不断更新，稀疏格式频繁变化，人工跟进成本过高。
反过来，如果矩阵稀疏率很低，或者稀疏模式非常规整且已经有一个调好的 kernel，就不必动用 LLM Agent 自动化流程。低稀疏度场景下，索引和分支开销很容易超过省下的计算量，Agent 的生成能力也救不了这个问题。
9. 总结与后续学习方向
回到开头那个问题：为什么剪枝模型在 GPU 上没有加速？答案往往不是模型本身，而是 kernel 与稀疏模式不匹配。SparseDitto 给出的解题思路，是用 LLM Agent 把“分析稀疏模式 → 生成 kernel → 编译反馈 → 迭代优化”这条链路自动化，把原本依赖资深工程师判断的部分交给大模型来完成。
从技术架构看，它并不神秘，本质上是一个带工具调用的多轮 Agent 系统；但它的难点非常具体：如何把矩阵特征变成 LLM 能理解的结构化描述，如何让编译器和 profiler 的反馈成为有效的下一轮输入，以及如何在验证、安全和回滚层面搭建可靠的工程边界。
如果你对这个方向感兴趣，下一步最值得做的不是等待一个现成的“SparseDitto 一键安装包”，而是自己动手做一个小闭环：选择一种常见稀疏模式，比如 2:4 结构化稀疏或 block sparse，准备一个基础 kernel 模板，再用一个本地或云端 LLM 搭建“生成代码、编译、运行、反馈修改”的最小循环。这个实验不需要复杂的框架，但能帮你建立对“LLM Agent 写 GPU kernel”这个问题的第一手认知。
这个方向真正的天花板，不在于大模型能不能写出更好的 CUDA，而在于我们能不能把硬件反馈和代码生成之间的“对话”做得足够精细。谁能把这条路打通，谁就能显著降低稀疏模型落地的工程成本。
