在深度学习模型部署中稀疏化已经成为压缩模型、降低推理开销的主流手段之一。然而很多人会忽略一个更深的矛盾模型确实变“稀疏”了但 GPU 端的计算内核如果还是按稠密矩阵设计的推理速度不仅不会提升反而可能下降。为了适配非结构化稀疏、结构化稀疏、块稀疏等不同模式需要针对性地定制 GPU Kernel。问题在于手工定制成本极高对硬件底层的熟悉程度要求也很高。SparseDitto 这类 LLM-Based Agentic System 的提出正是为了把“看懂稀疏模式 设计计算方案 生成 GPU 内核 自动调优”这条链路交给大模型智能体完成。本文将围绕 SparseDitto 的标题思路拆解它的核心原理、工作流程并提供一个简化版原型帮助读者理解 LLM 智能体如何为不同稀疏模式自动定制 GPU 内核。本文适合对模型压缩、GPU 算子优化有一定了解但还不太清楚“如何让稀疏模型真正跑得快”的读者。如果你正在做推理加速、算子开发或者对大模型自动生成代码感兴趣这篇文章都可以作为一份系统化的学习笔记。接下来我们先从最基础的背景讲起。1. 背景与核心概念1.1 稀疏化落地卡点不在“稀疏”而在“内核”在正式介绍 SparseDitto 之前我们先回答一个基础问题为什么稀疏模型不能直接享受 GPU 加速红利GPU 的计算单元SM、Tensor Core是为稠密矩阵的高吞吐计算设计的。普通的稠密矩阵乘法GEMM可以把数据连续加载到寄存器或共享内存中利用极高的访存带宽和计算并行度完成运算。但稀疏矩阵中大量元素为 0如果继续使用稠密内核会做大量无效的乘加运算甚至因为内存中存储了太多 0 值而浪费带宽。因此业界普遍采用的思路是先对权重做稀疏化处理再配合稀疏格式或稀疏内核来跳过 0 元素计算。也就是将大规模 GEMM 分解为更小的子矩阵计算任务并在计算时判断哪些 tile 值得跳过。但这就引出了一个问题不同稀疏模式对 tile 大小、索引存储方式、访存策略的要求完全不同。比如非结构化稀疏0 元素随机分布无法直接切成固定 tile通常需要按行收集非零元素。结构化稀疏如 2:4 模式每 4 个元素中保留 2 个模式固定硬件如 Ampere 架构的 Sparse Tensor Core 可以直接支持。块稀疏按固定块大小例如 32x32稀疏整块为 0 的可以被跳过适合 SIMT 并行。如果你面对的是混合了多种稀疏模式的模型那么只有一个内核往往不够。这就是 SparseDitto 这类系统出现的核心原因。1.2 什么是 SparseDittoLLM 智能体驱动的 GPU 内核定制从标题 SparseDitto: Customizing GPU Kernels for Different Sparsity Patterns with LLM-Based Agentic System 来看SparseDitto 是一个基于 LLM 的智能体系统Agentic System目标是针对不同稀疏模式自动定制 GPU 内核。我们可以把它拆成两个关键子问题如何描述一种稀疏模式如何从描述生成高效的 GPU 内核传统编译器路线如 TVM、Triton、cuSPARSE通常依赖人工模板或自动调度搜索。LLM 智能体路线则不同它利用大模型对代码生成和推理的能力把“某种稀疏模式 性能目标 硬件信息”作为输入让模型生成可能的 kernel 实现再在实际 GPU 上编译、运行、测量性能并把测量结果反馈给模型迭代优化。这种“生成-编译-运行-反馈-再生成”的闭环就是 Agentic System 的核心。它不要求开发者手工编写每一行 CUDA 代码而是让 LLM 在约束下反复尝试类似一个自动化的算子优化工程师。1.3 SparseDitto 这类系统要解决什么问题我们再用更工程化的语言总结它在解决什么问题算子适配成本高。不同稀疏模式需要不同 kernel一个模型常包含多种稀疏状态不可能每个都人工写一份。编译器和模板的泛化能力有限。TVM/Triton 的调度策略通常针对常见 pattern 做过优化遇到自定义稀疏格式时效果可能不如专门编写的 kernel。LLM 代码生成能力已经足够强。现在的大语言模型能够生成结构完整的 CUDA/Triton 代码再叠加运行反馈可以逼近甚至超过手工调优效果。可解释性和可扩展性的平衡。LLM 可以解释自己生成的代码也可以根据新的稀疏模式生成新的代码不需要维护庞大的手工模板库。因此SparseDitto 的定位更像一个“算子代码生成智能体”而不是简单调用 cuSPARSE 封装接口的工具。2. 稀疏模式与 GPU 内核优化原理2.1 常见稀疏模式的分类先来看一张简表把常见的稀疏模式、存储特点和适用场景整理清楚稀疏模式特点常见存储格式典型场景非结构化稀疏0 元素随机分布索引复杂CSR、CSC、COO剪枝后的模型结构化稀疏按固定周期模式保留元素自定义掩码2:4 结构化剪枝块稀疏按固定块稀疏块内可能稠密BSR、BCSR卷积、Transformer 权重分块剪枝通道稀疏整个通道或行列被剪掉通道索引表结构化剪枝、通道裁剪不同的稀疏模式决定了 kernel 的访存方式对非结构化稀疏通常需要按索引查找非零元素计算和访存的粒度比较细。对 2:4 结构化稀疏可以用专用的 Sparse Tensor Core 指令直接跳过一半计算。对块稀疏可以选择跳过全零块用 tile 级别控制来减少无效计算。如果内核只是用相同的 tile 逻辑处理所有模式效率一定不是最优的。SparseDitto 的动机就是根据模式特征生成匹配的内核逻辑。2.2 GPU 内核优化的核心Tile、访存与并行在讨论 LLM 生成内核之前我们需要明确一个 GPU 内核在优化时到底在调什么。首先是 Tile 的大小。GEMM 通常把矩阵分成多个 tiletile 大小同时影响共享内存占用、寄存器复用和计算密度。稀疏 kernel 中tile 大小还影响索引重用的概率。其次是访存布局。GPU 中连续内存访问能高效利用带宽。如果稀疏元素的索引不连续无法直接使用 memory coalescing性能会大打折扣。因此许多稀疏优化不是优化计算而是优化“如何把非零元素重新组织成连续片段”。然后是并行策略。现代 GPU 有大量线程和 SM如果任务粒度太小例如每个线程处理一个标量非零元素调度开销会吃掉收益如果任务粒度太大例如每个线程处理一个 64x64 的大块则容易产生负载不均。这些参数传统编译器通过自动调度和搜索来寻找而 SparseDitto 的思路是让 LLM 根据稀疏模式的描述直接生成带参数的 kernel 代码再通过性能反馈调整参数。2.3 Triton 为什么适合 LLM 生成内核过去我们让 LLM 生成 CUDA kernel最大的痛点是 CUDA 代码中包含大量底层细节线程同步、共享内存分配、bank conflict 规避等。LLM 虽然能生成“看起来正确”的代码但离高效运行往往还有距离。Triton 的出现改变了这一点。Triton 是一种面向 GPU 的 Python 领域专用语言DSL它让开发者用类似 NumPy 的语义编写计算逻辑然后由编译器负责底层调度。Triton 代码结构更简洁控制流更清晰非常适合 LLM 生成。Triton 中一个典型 kernel 模板包含块索引计算内存加载计算内存存储例如一个稠密 GEMM 的 Triton 内核框架如下import torch import triton import triton.language as tl triton.jit def dense_gemm_kernel( A_ptr, B_ptr, C_ptr, M, N, K, stride_am, stride_ak, stride_bk, stride_bn, stride_cm, stride_cn, BLOCK_M: tl.constexpr, BLOCK_N: tl.constexpr, BLOCK_K: tl.constexpr, ): pid_m tl.program_id(0) pid_n tl.program_id(1) offs_m pid_m * BLOCK_M tl.arange(0, BLOCK_M) offs_n pid_n * BLOCK_N tl.arange(0, BLOCK_N) offs_k tl.arange(0, BLOCK_K) a_ptrs A_ptr (offs_m[:, None] * stride_am offs_k[None, :] * stride_ak) b_ptrs B_ptr (offs_k[:, None] * stride_bk offs_n[None, :] * stride_bn) acc tl.zeros((BLOCK_M, BLOCK_N), dtypetl.float32) for k in range(0, K, BLOCK_K): a tl.load(a_ptrs) b tl.load(b_ptrs) acc tl.dot(a, b) a_ptrs BLOCK_K * stride_ak b_ptrs BLOCK_K * stride_bk offs_cm pid_m * BLOCK_M tl.arange(0, BLOCK_M) offs_cn pid_n * BLOCK_N tl.arange(0, BLOCK_N) c_ptrs C_ptr stride_cm * offs_cm[:, None] stride_cn * offs_cn[None, :] tl.store(c_ptrs, acc)这段代码是典型的“手工编写”版本。对于稀疏场景我们需要在加载 B 矩阵的 tile 时只加载非零块或者跳过全零块。这正好是 LLM 智能体可以发挥的地方它可以把稀疏 mask 的语义翻译成 Triton 中的索引计算和条件判断逻辑。3. SparseDitto 的设计思想与工作流程3.1 系统级设计从描述到内核的闭环从标题来看SparseDitto 不是单次生成代码就结束的工具而是一个完整的智能体系统。我们可以把它的工作流程拆成如下阶段稀疏模式解析。系统读取用户提供的稀疏描述可以是模型权重中导出的 mask也可以是配置文件中的文字描述。内核生成。LLM 根据稀疏模式、硬件类型、性能目标生成一个或多个候选内核代码。编译与运行。系统在目标 GPU 上编译生成的代码并执行基准测试采集耗时、显存占用等指标。性能反馈与迭代。如果性能不达标系统将上一次结果与错误信息作为 Prompt 的一部分送给 LLM让其修改代码或参数。输出最优内核。最终选择性能最优且通过正确性校验的内核输出为可复用文件。这里的关键是“反馈”环节。如果仅仅是让 LLM 生成一次代码效果往往不稳定只有把运行结果返回给模型模型才能感知到“这个 tile 大小导致显存溢出”“这段索引计算越界”等实际问题并逐步修正。3.2 如何描述稀疏模式想让 LLM 理解稀疏模式就需要把问题形式化。常见描述方式有掩码矩阵直接保存一个 0/1 的二维矩阵与权重 shape 对齐。稀疏参数列表例如 non_zero_ratio、block_size、pattern_type比如 2:4。自定义 JSON 配置把稀疏格式、tile 策略、目标算子类型写清楚。在 SparseDitto 这类系统中更推荐使用结构化配置描述。因为它既容易传给 LLM也方便控制生成范围。例如一个用于 LLM 生成 kernel 的 prompt 中可以包含这样的描述{ ops: linear_gemm, sparsity_pattern: block_sparse, block_size: [32, 32], non_zero_ratio: 0.25, input_shape: [128, 128, 1024], target_gpu: NVIDIA A100, optimize_for: latency }LLM 看到这样的输入后可以生成对应的 Triton kernel并在 kernel 中针对 block_sparse 跳过全零块。这种“配置驱动生成”的方式比直接让模型读二进制权重更可控。3.3 LLM Agentic System 的核心组件SparseDitto 这类系统通常由以下组件构成Planner规划器负责把稀疏描述拆解成子任务例如先分析模式、再决定 kernel 模板。Coder代码生成器负责生成 Triton/CUDA 代码。Evaluator评估器负责编译、运行、计算准确率和性能。Critic批判器负责根据评估结果分析失败原因提出修改建议。这些组件可以是同一个 LLM 在不同 Prompt 下的角色扮演也可以是多个独立模型协作。由于每个环节的输入输出都相对明确工程化时更推荐用单独模块实现方便做缓存和权限控制。4. 原型环境准备4.1 硬件与软件要求为了跟上后续的实战示例建议准备以下环境GPUNVIDIA Ampere 架构或更高型号例如 A100、A800、RTX 3090 及以上主要为了发挥 Triton 和可能的 Sparse Tensor Core 能力。CUDA11.8 或 12.x具体版本需和 PyTorch、Triton 匹配。Python3.9 或更高版本。深度学习框架PyTorch 2.0 以上自带 Triton 依赖。LLM 服务可使用 OpenAI 兼容 API也可以部署本地模型如 Qwen2.5-Coder-7B 通过 vLLM 提供接口。版本说明由于 Triton 与 CUDA、PyTorch 的版本耦合比较紧遇到兼容性问题时优先参考官方版本矩阵。本文示例以常见环境为例重点演示配置思路。4.2 创建项目结构先创建一个清晰的目录结构sparseditto-demo/ ├── configs/ │ └── sparse_pattern.json ├── kernels/ │ └── generated/ ├── src/ │ ├── __init__.py │ ├── sparse_pattern.py │ ├── llm_agent.py │ ├── evaluator.py │ └── main.py └── requirements.txt其中sparse_pattern.py负责解析稀疏配置和构造 Prompt。llm_agent.py负责调用 LLM 生成代码。evaluator.py负责编译、运行和性能评估。main.py串联整个闭环流程。4.3 安装依赖创建一个简洁的 requirements.txttorch2.0 triton2.0 openai1.0 numpy1.24安装命令pip install -r requirements.txt如果你使用本地模型服务可以不用 openai 库直接用 requests 调用 vLLM 的 HTTP 接口。为了演示方便下文使用 OpenAI 兼容接口。5. 核心代码实现一个简化版 LLM 智能体内核生成系统5.1 定义稀疏模式描述类我们先用一个数据类来承载稀疏模式信息。它不是内核本身而是 LLM 生成代码时的“上下文”。# 文件路径src/sparse_pattern.py from dataclasses import dataclass, asdict from typing import Optional dataclass class SparsePattern: op_type: str linear_gemm pattern_type: str block_sparse block_size: tuple (32, 32) non_zero_ratio: float 0.25 input_shape: tuple (128, 128, 1024) target_gpu: str NVIDIA A100 optimize_for: str latency dtype: str float16 def to_prompt(self) - str: return ( f请为以下稀疏模式生成一个 Triton GPU kernel\n f算子类型{self.op_type}\n f稀疏模式{self.pattern_type}\n f块大小{self.block_size[0]}x{self.block_size[1]}\n f非零比例{self.non_zero_ratio}\n f输入形状{self.input_shape}\n f目标 GPU{self.target_gpu}\n f优化目标{self.optimize_for}\n f数据类型{self.dtype}\n f请直接输出完整的 Python Triton 代码不要额外解释。 )这段代码的作用很简单把稀疏配置拼接成 Prompt。在实际项目中你会希望这个 Prompt 包含更多示例和限制条件以减少 LLM 输出不合法格式的概率。5.2 实现 LLM Agent 调用层接下来实现调用 LLM 的模块。这里我们假设你有一个 OpenAI 兼容的接口base_url 可以是云厂商 API也可以是本地 vLLM 服务。# 文件路径src/llm_agent.py from openai import OpenAI class LLMAgent: def __init__(self, api_key: str, base_url: str, model: str qwen2.5-coder-7b): self.client OpenAI(api_keyapi_key, base_urlbase_url) self.model model def generate_kernel(self, prompt: str, temperature: float 0.3) - str: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: 你是一名资深 GPU 算子优化工程师擅长 Triton 和 CUDA。}, {role: user, content: prompt} ], temperaturetemperature, ) return response.choices[0].message.content.strip()这里需要注意真实项目里不能直接信任模型输出的代码。我们需要在 evaluator 中做安全校验和独立编译运行不能把生成代码直接加载进主进程执行。5.3 实现评估器编译、运行、反馈评估器是闭环系统中最关键的一环。它负责把 LLM 生成的代码写入临时文件编译成可执行模块然后在一组固定数据上做正确性和性能测试。# 文件路径src/evaluator.py import time import tempfile import importlib.util import numpy as np import torch class Evaluator: def __init__(self, max_retries: int 3): self.max_retries max_retries def run(self, code: str, sparse_pattern): # 将生成的代码写入临时文件 with tempfile.NamedTemporaryFile(suffix.py, deleteFalse, modew) as f: f.write(code) f.flush() module_path f.name try: # 动态加载生成的模块 spec importlib.util.spec_from_file_location(generated_kernel, module_path) module importlib.util.module_from_spec(spec) spec.loader.exec_module(module) # 构造测试输入 M, N, K sparse_pattern.input_shape a torch.randn(M, K, dtypetorch.float16, devicecuda) b torch.randn(N, K, dtypetorch.float16, devicecuda) # 调用生成的 kernel 函数 fn getattr(module, kernel) start time.time() c fn(a, b, M, N, K) torch.cuda.synchronize() latency_ms (time.time() - start) * 1000 # 与稠密结果对比正确性 c_dense a b.T diff (c.float() - c_dense.float()).abs().max().item() if diff 0.1: return {ok: False, reason: f正确性校验失败max diff {diff:.4f}} return {ok: True, latency_ms: latency_ms, code: code} except Exception as e: return {ok: False, reason: str(e)}这个评估器带有明显的教学简化性质。真实 SparseDitto 系统中的评估器要处理更多内容编译日志提取、显存占用测量、多次运行取中位数、线程安全隔离等但核心逻辑是一样的。5.4 闭包主流程让智能体迭代最后一个核心模块是主流程。它会循环执行“生成代码 → 评估 → 反馈 → 再生成”直到达到最大迭代次数或性能达标。# 文件路径src/main.py from sparse_pattern import SparsePattern from llm_agent import LLMAgent from evaluator import Evaluator MAX_ITERATIONS 5 TARGET_LATENCY_MS 10.0 def main(): pattern SparsePattern() agent LLMAgent(api_keyyour-api-key, base_urlhttp://localhost:8000/v1) evaluator Evaluator() prompt pattern.to_prompt() history [] for iteration in range(MAX_ITERATIONS): print(fIteration {iteration 1}: 生成内核中...) code agent.generate_kernel(prompt) result evaluator.run(code, pattern) history.append({iter: iteration, result: result}) if result[ok]: print(f内核正确延迟 {result[latency_ms]:.2f} ms) if result[latency_ms] TARGET_LATENCY_MS: with open(kernels/generated/best_kernel.py, w) as f: f.write(result[code]) print(达到性能目标已保存最佳内核。) break else: print(f评估失败{result[reason]}) # 构造反馈 prompt prompt ( f你上一次生成的代码存在问题{result[reason]}\n f请修正后重新输出完整代码并保持原有输入输出接口一致。\n f注意不要修改函数名 kernel不要增加额外参数。 ) if __name__ __main__: main()这个主流程虽然只有几十行但它已经构成了一个最简单的 LLM-Based Agentic System有生成、有评估、有反馈、有迭代。SparseDitto 的完整系统会比这复杂得多但核心思想完全一致。6. 运行验证与性能评估6.1 实际运行效果预期由于我们这里并不是真的让模型生成一个顶尖的块稀疏内核所以运行结果更多是验证流程是否打通。你可能会看到以下几种输出第一次迭代就成功LLM 生成的 Triton 代码能运行且正确性校验通过。前几次迭代失败代码里有不兼容的 API 或索引越界。这很常见尤其是本地小模型。多次迭代后达到性能目标随着反馈信息越来越明确模型会逐步修正 tile 大小、跳过逻辑等关键参数。为了更直观地评估性能建议你手动写一个稠密 Triton kernel 或直接使用 PyTorch 的矩阵乘作为基线然后对比延迟差异。例如python -m src.main如果一切正常控制台会打印类似内容Iteration 1: 生成内核中... 评估失败kernel 对象不可调用 Iteration 2: 生成内核中... 内核正确延迟 34.56 ms Iteration 3: 生成内核中... 内核正确延迟 22.18 ms 达到性能目标已保存最佳内核。这里的性能数字会因 GPU 型号、稀疏度和输入 shape 不同而差异极大不必过分关注具体数值重点是看迭代流程是否能逐渐改善结果。6.2 用表格对比不同稀疏模式为了说明“不同稀疏模式需要不同内核”的观点在实际项目中我们通常会准备一个基准对比表稀疏模式稠密内核耗时cuSPARSE 耗时LLM 生成内核耗时是否生效非结构化稀疏 0.9100 ms35 ms28 ms是2:4 结构化稀疏100 ms18 ms12 ms是块稀疏 block32100 ms22 ms15 ms是块稀疏 block64100 ms30 ms14 ms是第一列代表不同的稀疏模式第二列是不做任何稀疏优化的稠密内核耗时。LLM 生成内核在每一种模式下都可能表现不一样这正是 SparseDitto 这类系统需要针对 pattern 定制的原因。7. 常见问题与排查思路7.1 LLM 生成的代码无法编译现象动态加载模块时抛出 SyntaxError 或 ImportError。原因LLM 输出的 markdown 中包含 python 代码块标记导致 Python 文件解析失败。使用了当前环境不存在的库。Triton 接口版本不匹配。排查步骤检查生成代码前是否做了格式化清理去掉python 和标记。在 evaluator 中打印生成的代码片段手动检查关键 import。把 Triton 版本升级到与 PyTorch 匹配的版本。解决方案在代码生成 prompt 中明确要求“不要使用 markdown 代码块”。在 evaluator 中增加代码清理函数移除代码块标记。7.2 kernel 运行正确性校验失败现象max diff 超过阈值计算结果和稠密矩阵乘差异较大。原因稀疏索引计算存在越界或错误偏移。忽略了零元素的填充逻辑。数据类型转换精度不足。解决方案让 LLM 先生成一个小 shape 的调试版本。在 prompt 中提供更明确的伪代码或参考模板。降低正确性阈值例如先用 0.5 的阈值判断是否“基本正确”再逐步收紧。7.3 性能反而不如稠密内核现象生成的稀疏内核比直接调用 PyTorch 矩阵乘还慢。原因稀疏度不够高跳过零块带来的收益不足以抵消额外索引判断开销。tile 太小并行度不足。没有使用向量化加载。解决方案提高 block_size增大计算密度。让 LLM 生成两个候选版本评估后保留快的那一个。在 prompt 中强调“优先减少访存再减少计算”。7.4 常见问题速查表问题现象常见原因解决思路生成的代码无法加载输出内容包含 markdown 标记清理后重新加载kernel 输出 NaN稀疏索引越界检查 offs 计算增加边界 clamp性能没有提升稀疏度不够或 tile 过小调整 block size 和稀疏阈值LLM 调用超时本地模型推理速度慢设置流式输出或增加超时时间显存不足并行度设置过高限制 grid 数量或降低 BLOCK 大小8. 工程实践建议8.1 安全性不要把生成代码直接投入生产在开发 SparseDitto 这类系统时最重要的一条铁律是不要在主进程内直接执行 LLM 生成的代码。建议做法是在独立的 Docker 容器或沙箱中编译和运行生成代码。对生成的代码做静态审查检查是否存在危险 API 或资源耗尽风险。为编译和运行进程设置 CPU、内存、显存限制。所有基准测试使用非生产数据验证通过后再接入正式推理链路。这条建议不只是为了安全也是为了让系统更稳定。LLM 生成的代码可能调用 GPU 显存过大如果直接在主进程运行可能拖垮整个训练或推理服务。8.2 配置管理用版本化方式管理稀疏模式不要频繁地在代码中硬编码稀疏模式。建议把稀疏模式描述放到独立的配置文件中并纳入 Git 管理。这样当 LLM 生成结果变化时你可以追踪是哪一次配置变更导致了性能回退。{ pattern_id: block_sparse_32_v1, block_size: [32, 32], sparsity_threshold: 0.8, target_gpu: NVIDIA A100, fallback_kernel: dense_triton }8.3 性能缓存与重试策略LLM 调用不是免费的而且生成过程具有随机性。实际工程中应该做到对 Prompt 内容做哈希相同稀疏描述不重复调用 LLM直接使用历史最优 kernel。对每次评估结果做记录包括代码、耗时、显存、正确性指标。设置最大重试次数避免模型在错误中循环。8.4 最小权限原则与日志记录如果 SparseDitto 系统需要加载外部权重或访问远程 LLM 服务建议遵循最小权限原则LLM 服务只暴露必要 API不给文件系统权限。系统日志只记录必要信息不要打印完整权重或敏感数据。每次生成和评估都记录 trace ID方便回溯。9. 总结与学习路线SparseDitto 代表的是一种全新的算子开发范式从“手工编写 GPU 内核”到“LLM 智能体自动生成内核”。它的出现并不意味着人工算子工程师会被完全替代而是把更多重复性、探索性的工作交给大模型让人更专注于算法设计、异常分析和系统架构。如果想进一步学习可以按以下路线推进先掌握稀疏矩阵基础理解 CSR、CSC、BSR 等格式的适用场景。再学习 Triton 官方教程重点练习 tile 计算、索引偏移和内存访问。然后尝试复现一个简化版 SparseDitto先用固定几个 pattern 跑通闭环。最后再思考如何扩展多 GPU、动态 shape、自动检测稀疏模式、集成编译缓存等。在动手实践时建议从一个小矩阵、一个固定稀疏模式开始先确认流程闭环再逐步扩大场景。你可以先在本地部署一个小规模 LLM用最简单的“生成一次、评估一次、反馈一次”跑通第一版然后再加入更复杂的 Planner 和 Critic 组件。如果你正在研究模型压缩或推理加速SparseDitto 的思路值得关注。它不一定替代 cuSPARSE 或 cuBLAS但作为“面向任意稀疏模式的动态内核生成方案”在定制化算子需求越来越多的今天具备很强的工程参考价值。 SparseDitto：用LLM智能体为不同稀疏模式自动定制GPU内核
在深度学习模型部署中稀疏化已经成为压缩模型、降低推理开销的主流手段之一。然而很多人会忽略一个更深的矛盾模型确实变“稀疏”了但 GPU 端的计算内核如果还是按稠密矩阵设计的推理速度不仅不会提升反而可能下降。为了适配非结构化稀疏、结构化稀疏、块稀疏等不同模式需要针对性地定制 GPU Kernel。问题在于手工定制成本极高对硬件底层的熟悉程度要求也很高。SparseDitto 这类 LLM-Based Agentic System 的提出正是为了把“看懂稀疏模式 设计计算方案 生成 GPU 内核 自动调优”这条链路交给大模型智能体完成。本文将围绕 SparseDitto 的标题思路拆解它的核心原理、工作流程并提供一个简化版原型帮助读者理解 LLM 智能体如何为不同稀疏模式自动定制 GPU 内核。本文适合对模型压缩、GPU 算子优化有一定了解但还不太清楚“如何让稀疏模型真正跑得快”的读者。如果你正在做推理加速、算子开发或者对大模型自动生成代码感兴趣这篇文章都可以作为一份系统化的学习笔记。接下来我们先从最基础的背景讲起。1. 背景与核心概念1.1 稀疏化落地卡点不在“稀疏”而在“内核”在正式介绍 SparseDitto 之前我们先回答一个基础问题为什么稀疏模型不能直接享受 GPU 加速红利GPU 的计算单元SM、Tensor Core是为稠密矩阵的高吞吐计算设计的。普通的稠密矩阵乘法GEMM可以把数据连续加载到寄存器或共享内存中利用极高的访存带宽和计算并行度完成运算。但稀疏矩阵中大量元素为 0如果继续使用稠密内核会做大量无效的乘加运算甚至因为内存中存储了太多 0 值而浪费带宽。因此业界普遍采用的思路是先对权重做稀疏化处理再配合稀疏格式或稀疏内核来跳过 0 元素计算。也就是将大规模 GEMM 分解为更小的子矩阵计算任务并在计算时判断哪些 tile 值得跳过。但这就引出了一个问题不同稀疏模式对 tile 大小、索引存储方式、访存策略的要求完全不同。比如非结构化稀疏0 元素随机分布无法直接切成固定 tile通常需要按行收集非零元素。结构化稀疏如 2:4 模式每 4 个元素中保留 2 个模式固定硬件如 Ampere 架构的 Sparse Tensor Core 可以直接支持。块稀疏按固定块大小例如 32x32稀疏整块为 0 的可以被跳过适合 SIMT 并行。如果你面对的是混合了多种稀疏模式的模型那么只有一个内核往往不够。这就是 SparseDitto 这类系统出现的核心原因。1.2 什么是 SparseDittoLLM 智能体驱动的 GPU 内核定制从标题 SparseDitto: Customizing GPU Kernels for Different Sparsity Patterns with LLM-Based Agentic System 来看SparseDitto 是一个基于 LLM 的智能体系统Agentic System目标是针对不同稀疏模式自动定制 GPU 内核。我们可以把它拆成两个关键子问题如何描述一种稀疏模式如何从描述生成高效的 GPU 内核传统编译器路线如 TVM、Triton、cuSPARSE通常依赖人工模板或自动调度搜索。LLM 智能体路线则不同它利用大模型对代码生成和推理的能力把“某种稀疏模式 性能目标 硬件信息”作为输入让模型生成可能的 kernel 实现再在实际 GPU 上编译、运行、测量性能并把测量结果反馈给模型迭代优化。这种“生成-编译-运行-反馈-再生成”的闭环就是 Agentic System 的核心。它不要求开发者手工编写每一行 CUDA 代码而是让 LLM 在约束下反复尝试类似一个自动化的算子优化工程师。1.3 SparseDitto 这类系统要解决什么问题我们再用更工程化的语言总结它在解决什么问题算子适配成本高。不同稀疏模式需要不同 kernel一个模型常包含多种稀疏状态不可能每个都人工写一份。编译器和模板的泛化能力有限。TVM/Triton 的调度策略通常针对常见 pattern 做过优化遇到自定义稀疏格式时效果可能不如专门编写的 kernel。LLM 代码生成能力已经足够强。现在的大语言模型能够生成结构完整的 CUDA/Triton 代码再叠加运行反馈可以逼近甚至超过手工调优效果。可解释性和可扩展性的平衡。LLM 可以解释自己生成的代码也可以根据新的稀疏模式生成新的代码不需要维护庞大的手工模板库。因此SparseDitto 的定位更像一个“算子代码生成智能体”而不是简单调用 cuSPARSE 封装接口的工具。2. 稀疏模式与 GPU 内核优化原理2.1 常见稀疏模式的分类先来看一张简表把常见的稀疏模式、存储特点和适用场景整理清楚稀疏模式特点常见存储格式典型场景非结构化稀疏0 元素随机分布索引复杂CSR、CSC、COO剪枝后的模型结构化稀疏按固定周期模式保留元素自定义掩码2:4 结构化剪枝块稀疏按固定块稀疏块内可能稠密BSR、BCSR卷积、Transformer 权重分块剪枝通道稀疏整个通道或行列被剪掉通道索引表结构化剪枝、通道裁剪不同的稀疏模式决定了 kernel 的访存方式对非结构化稀疏通常需要按索引查找非零元素计算和访存的粒度比较细。对 2:4 结构化稀疏可以用专用的 Sparse Tensor Core 指令直接跳过一半计算。对块稀疏可以选择跳过全零块用 tile 级别控制来减少无效计算。如果内核只是用相同的 tile 逻辑处理所有模式效率一定不是最优的。SparseDitto 的动机就是根据模式特征生成匹配的内核逻辑。2.2 GPU 内核优化的核心Tile、访存与并行在讨论 LLM 生成内核之前我们需要明确一个 GPU 内核在优化时到底在调什么。首先是 Tile 的大小。GEMM 通常把矩阵分成多个 tiletile 大小同时影响共享内存占用、寄存器复用和计算密度。稀疏 kernel 中tile 大小还影响索引重用的概率。其次是访存布局。GPU 中连续内存访问能高效利用带宽。如果稀疏元素的索引不连续无法直接使用 memory coalescing性能会大打折扣。因此许多稀疏优化不是优化计算而是优化“如何把非零元素重新组织成连续片段”。然后是并行策略。现代 GPU 有大量线程和 SM如果任务粒度太小例如每个线程处理一个标量非零元素调度开销会吃掉收益如果任务粒度太大例如每个线程处理一个 64x64 的大块则容易产生负载不均。这些参数传统编译器通过自动调度和搜索来寻找而 SparseDitto 的思路是让 LLM 根据稀疏模式的描述直接生成带参数的 kernel 代码再通过性能反馈调整参数。2.3 Triton 为什么适合 LLM 生成内核过去我们让 LLM 生成 CUDA kernel最大的痛点是 CUDA 代码中包含大量底层细节线程同步、共享内存分配、bank conflict 规避等。LLM 虽然能生成“看起来正确”的代码但离高效运行往往还有距离。Triton 的出现改变了这一点。Triton 是一种面向 GPU 的 Python 领域专用语言DSL它让开发者用类似 NumPy 的语义编写计算逻辑然后由编译器负责底层调度。Triton 代码结构更简洁控制流更清晰非常适合 LLM 生成。Triton 中一个典型 kernel 模板包含块索引计算内存加载计算内存存储例如一个稠密 GEMM 的 Triton 内核框架如下import torch import triton import triton.language as tl triton.jit def dense_gemm_kernel( A_ptr, B_ptr, C_ptr, M, N, K, stride_am, stride_ak, stride_bk, stride_bn, stride_cm, stride_cn, BLOCK_M: tl.constexpr, BLOCK_N: tl.constexpr, BLOCK_K: tl.constexpr, ): pid_m tl.program_id(0) pid_n tl.program_id(1) offs_m pid_m * BLOCK_M tl.arange(0, BLOCK_M) offs_n pid_n * BLOCK_N tl.arange(0, BLOCK_N) offs_k tl.arange(0, BLOCK_K) a_ptrs A_ptr (offs_m[:, None] * stride_am offs_k[None, :] * stride_ak) b_ptrs B_ptr (offs_k[:, None] * stride_bk offs_n[None, :] * stride_bn) acc tl.zeros((BLOCK_M, BLOCK_N), dtypetl.float32) for k in range(0, K, BLOCK_K): a tl.load(a_ptrs) b tl.load(b_ptrs) acc tl.dot(a, b) a_ptrs BLOCK_K * stride_ak b_ptrs BLOCK_K * stride_bk offs_cm pid_m * BLOCK_M tl.arange(0, BLOCK_M) offs_cn pid_n * BLOCK_N tl.arange(0, BLOCK_N) c_ptrs C_ptr stride_cm * offs_cm[:, None] stride_cn * offs_cn[None, :] tl.store(c_ptrs, acc)这段代码是典型的“手工编写”版本。对于稀疏场景我们需要在加载 B 矩阵的 tile 时只加载非零块或者跳过全零块。这正好是 LLM 智能体可以发挥的地方它可以把稀疏 mask 的语义翻译成 Triton 中的索引计算和条件判断逻辑。3. SparseDitto 的设计思想与工作流程3.1 系统级设计从描述到内核的闭环从标题来看SparseDitto 不是单次生成代码就结束的工具而是一个完整的智能体系统。我们可以把它的工作流程拆成如下阶段稀疏模式解析。系统读取用户提供的稀疏描述可以是模型权重中导出的 mask也可以是配置文件中的文字描述。内核生成。LLM 根据稀疏模式、硬件类型、性能目标生成一个或多个候选内核代码。编译与运行。系统在目标 GPU 上编译生成的代码并执行基准测试采集耗时、显存占用等指标。性能反馈与迭代。如果性能不达标系统将上一次结果与错误信息作为 Prompt 的一部分送给 LLM让其修改代码或参数。输出最优内核。最终选择性能最优且通过正确性校验的内核输出为可复用文件。这里的关键是“反馈”环节。如果仅仅是让 LLM 生成一次代码效果往往不稳定只有把运行结果返回给模型模型才能感知到“这个 tile 大小导致显存溢出”“这段索引计算越界”等实际问题并逐步修正。3.2 如何描述稀疏模式想让 LLM 理解稀疏模式就需要把问题形式化。常见描述方式有掩码矩阵直接保存一个 0/1 的二维矩阵与权重 shape 对齐。稀疏参数列表例如 non_zero_ratio、block_size、pattern_type比如 2:4。自定义 JSON 配置把稀疏格式、tile 策略、目标算子类型写清楚。在 SparseDitto 这类系统中更推荐使用结构化配置描述。因为它既容易传给 LLM也方便控制生成范围。例如一个用于 LLM 生成 kernel 的 prompt 中可以包含这样的描述{ ops: linear_gemm, sparsity_pattern: block_sparse, block_size: [32, 32], non_zero_ratio: 0.25, input_shape: [128, 128, 1024], target_gpu: NVIDIA A100, optimize_for: latency }LLM 看到这样的输入后可以生成对应的 Triton kernel并在 kernel 中针对 block_sparse 跳过全零块。这种“配置驱动生成”的方式比直接让模型读二进制权重更可控。3.3 LLM Agentic System 的核心组件SparseDitto 这类系统通常由以下组件构成Planner规划器负责把稀疏描述拆解成子任务例如先分析模式、再决定 kernel 模板。Coder代码生成器负责生成 Triton/CUDA 代码。Evaluator评估器负责编译、运行、计算准确率和性能。Critic批判器负责根据评估结果分析失败原因提出修改建议。这些组件可以是同一个 LLM 在不同 Prompt 下的角色扮演也可以是多个独立模型协作。由于每个环节的输入输出都相对明确工程化时更推荐用单独模块实现方便做缓存和权限控制。4. 原型环境准备4.1 硬件与软件要求为了跟上后续的实战示例建议准备以下环境GPUNVIDIA Ampere 架构或更高型号例如 A100、A800、RTX 3090 及以上主要为了发挥 Triton 和可能的 Sparse Tensor Core 能力。CUDA11.8 或 12.x具体版本需和 PyTorch、Triton 匹配。Python3.9 或更高版本。深度学习框架PyTorch 2.0 以上自带 Triton 依赖。LLM 服务可使用 OpenAI 兼容 API也可以部署本地模型如 Qwen2.5-Coder-7B 通过 vLLM 提供接口。版本说明由于 Triton 与 CUDA、PyTorch 的版本耦合比较紧遇到兼容性问题时优先参考官方版本矩阵。本文示例以常见环境为例重点演示配置思路。4.2 创建项目结构先创建一个清晰的目录结构sparseditto-demo/ ├── configs/ │ └── sparse_pattern.json ├── kernels/ │ └── generated/ ├── src/ │ ├── __init__.py │ ├── sparse_pattern.py │ ├── llm_agent.py │ ├── evaluator.py │ └── main.py └── requirements.txt其中sparse_pattern.py负责解析稀疏配置和构造 Prompt。llm_agent.py负责调用 LLM 生成代码。evaluator.py负责编译、运行和性能评估。main.py串联整个闭环流程。4.3 安装依赖创建一个简洁的 requirements.txttorch2.0 triton2.0 openai1.0 numpy1.24安装命令pip install -r requirements.txt如果你使用本地模型服务可以不用 openai 库直接用 requests 调用 vLLM 的 HTTP 接口。为了演示方便下文使用 OpenAI 兼容接口。5. 核心代码实现一个简化版 LLM 智能体内核生成系统5.1 定义稀疏模式描述类我们先用一个数据类来承载稀疏模式信息。它不是内核本身而是 LLM 生成代码时的“上下文”。# 文件路径src/sparse_pattern.py from dataclasses import dataclass, asdict from typing import Optional dataclass class SparsePattern: op_type: str linear_gemm pattern_type: str block_sparse block_size: tuple (32, 32) non_zero_ratio: float 0.25 input_shape: tuple (128, 128, 1024) target_gpu: str NVIDIA A100 optimize_for: str latency dtype: str float16 def to_prompt(self) - str: return ( f请为以下稀疏模式生成一个 Triton GPU kernel\n f算子类型{self.op_type}\n f稀疏模式{self.pattern_type}\n f块大小{self.block_size[0]}x{self.block_size[1]}\n f非零比例{self.non_zero_ratio}\n f输入形状{self.input_shape}\n f目标 GPU{self.target_gpu}\n f优化目标{self.optimize_for}\n f数据类型{self.dtype}\n f请直接输出完整的 Python Triton 代码不要额外解释。 )这段代码的作用很简单把稀疏配置拼接成 Prompt。在实际项目中你会希望这个 Prompt 包含更多示例和限制条件以减少 LLM 输出不合法格式的概率。5.2 实现 LLM Agent 调用层接下来实现调用 LLM 的模块。这里我们假设你有一个 OpenAI 兼容的接口base_url 可以是云厂商 API也可以是本地 vLLM 服务。# 文件路径src/llm_agent.py from openai import OpenAI class LLMAgent: def __init__(self, api_key: str, base_url: str, model: str qwen2.5-coder-7b): self.client OpenAI(api_keyapi_key, base_urlbase_url) self.model model def generate_kernel(self, prompt: str, temperature: float 0.3) - str: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: 你是一名资深 GPU 算子优化工程师擅长 Triton 和 CUDA。}, {role: user, content: prompt} ], temperaturetemperature, ) return response.choices[0].message.content.strip()这里需要注意真实项目里不能直接信任模型输出的代码。我们需要在 evaluator 中做安全校验和独立编译运行不能把生成代码直接加载进主进程执行。5.3 实现评估器编译、运行、反馈评估器是闭环系统中最关键的一环。它负责把 LLM 生成的代码写入临时文件编译成可执行模块然后在一组固定数据上做正确性和性能测试。# 文件路径src/evaluator.py import time import tempfile import importlib.util import numpy as np import torch class Evaluator: def __init__(self, max_retries: int 3): self.max_retries max_retries def run(self, code: str, sparse_pattern): # 将生成的代码写入临时文件 with tempfile.NamedTemporaryFile(suffix.py, deleteFalse, modew) as f: f.write(code) f.flush() module_path f.name try: # 动态加载生成的模块 spec importlib.util.spec_from_file_location(generated_kernel, module_path) module importlib.util.module_from_spec(spec) spec.loader.exec_module(module) # 构造测试输入 M, N, K sparse_pattern.input_shape a torch.randn(M, K, dtypetorch.float16, devicecuda) b torch.randn(N, K, dtypetorch.float16, devicecuda) # 调用生成的 kernel 函数 fn getattr(module, kernel) start time.time() c fn(a, b, M, N, K) torch.cuda.synchronize() latency_ms (time.time() - start) * 1000 # 与稠密结果对比正确性 c_dense a b.T diff (c.float() - c_dense.float()).abs().max().item() if diff 0.1: return {ok: False, reason: f正确性校验失败max diff {diff:.4f}} return {ok: True, latency_ms: latency_ms, code: code} except Exception as e: return {ok: False, reason: str(e)}这个评估器带有明显的教学简化性质。真实 SparseDitto 系统中的评估器要处理更多内容编译日志提取、显存占用测量、多次运行取中位数、线程安全隔离等但核心逻辑是一样的。5.4 闭包主流程让智能体迭代最后一个核心模块是主流程。它会循环执行“生成代码 → 评估 → 反馈 → 再生成”直到达到最大迭代次数或性能达标。# 文件路径src/main.py from sparse_pattern import SparsePattern from llm_agent import LLMAgent from evaluator import Evaluator MAX_ITERATIONS 5 TARGET_LATENCY_MS 10.0 def main(): pattern SparsePattern() agent LLMAgent(api_keyyour-api-key, base_urlhttp://localhost:8000/v1) evaluator Evaluator() prompt pattern.to_prompt() history [] for iteration in range(MAX_ITERATIONS): print(fIteration {iteration 1}: 生成内核中...) code agent.generate_kernel(prompt) result evaluator.run(code, pattern) history.append({iter: iteration, result: result}) if result[ok]: print(f内核正确延迟 {result[latency_ms]:.2f} ms) if result[latency_ms] TARGET_LATENCY_MS: with open(kernels/generated/best_kernel.py, w) as f: f.write(result[code]) print(达到性能目标已保存最佳内核。) break else: print(f评估失败{result[reason]}) # 构造反馈 prompt prompt ( f你上一次生成的代码存在问题{result[reason]}\n f请修正后重新输出完整代码并保持原有输入输出接口一致。\n f注意不要修改函数名 kernel不要增加额外参数。 ) if __name__ __main__: main()这个主流程虽然只有几十行但它已经构成了一个最简单的 LLM-Based Agentic System有生成、有评估、有反馈、有迭代。SparseDitto 的完整系统会比这复杂得多但核心思想完全一致。6. 运行验证与性能评估6.1 实际运行效果预期由于我们这里并不是真的让模型生成一个顶尖的块稀疏内核所以运行结果更多是验证流程是否打通。你可能会看到以下几种输出第一次迭代就成功LLM 生成的 Triton 代码能运行且正确性校验通过。前几次迭代失败代码里有不兼容的 API 或索引越界。这很常见尤其是本地小模型。多次迭代后达到性能目标随着反馈信息越来越明确模型会逐步修正 tile 大小、跳过逻辑等关键参数。为了更直观地评估性能建议你手动写一个稠密 Triton kernel 或直接使用 PyTorch 的矩阵乘作为基线然后对比延迟差异。例如python -m src.main如果一切正常控制台会打印类似内容Iteration 1: 生成内核中... 评估失败kernel 对象不可调用 Iteration 2: 生成内核中... 内核正确延迟 34.56 ms Iteration 3: 生成内核中... 内核正确延迟 22.18 ms 达到性能目标已保存最佳内核。这里的性能数字会因 GPU 型号、稀疏度和输入 shape 不同而差异极大不必过分关注具体数值重点是看迭代流程是否能逐渐改善结果。6.2 用表格对比不同稀疏模式为了说明“不同稀疏模式需要不同内核”的观点在实际项目中我们通常会准备一个基准对比表稀疏模式稠密内核耗时cuSPARSE 耗时LLM 生成内核耗时是否生效非结构化稀疏 0.9100 ms35 ms28 ms是2:4 结构化稀疏100 ms18 ms12 ms是块稀疏 block32100 ms22 ms15 ms是块稀疏 block64100 ms30 ms14 ms是第一列代表不同的稀疏模式第二列是不做任何稀疏优化的稠密内核耗时。LLM 生成内核在每一种模式下都可能表现不一样这正是 SparseDitto 这类系统需要针对 pattern 定制的原因。7. 常见问题与排查思路7.1 LLM 生成的代码无法编译现象动态加载模块时抛出 SyntaxError 或 ImportError。原因LLM 输出的 markdown 中包含 python 代码块标记导致 Python 文件解析失败。使用了当前环境不存在的库。Triton 接口版本不匹配。排查步骤检查生成代码前是否做了格式化清理去掉python 和标记。在 evaluator 中打印生成的代码片段手动检查关键 import。把 Triton 版本升级到与 PyTorch 匹配的版本。解决方案在代码生成 prompt 中明确要求“不要使用 markdown 代码块”。在 evaluator 中增加代码清理函数移除代码块标记。7.2 kernel 运行正确性校验失败现象max diff 超过阈值计算结果和稠密矩阵乘差异较大。原因稀疏索引计算存在越界或错误偏移。忽略了零元素的填充逻辑。数据类型转换精度不足。解决方案让 LLM 先生成一个小 shape 的调试版本。在 prompt 中提供更明确的伪代码或参考模板。降低正确性阈值例如先用 0.5 的阈值判断是否“基本正确”再逐步收紧。7.3 性能反而不如稠密内核现象生成的稀疏内核比直接调用 PyTorch 矩阵乘还慢。原因稀疏度不够高跳过零块带来的收益不足以抵消额外索引判断开销。tile 太小并行度不足。没有使用向量化加载。解决方案提高 block_size增大计算密度。让 LLM 生成两个候选版本评估后保留快的那一个。在 prompt 中强调“优先减少访存再减少计算”。7.4 常见问题速查表问题现象常见原因解决思路生成的代码无法加载输出内容包含 markdown 标记清理后重新加载kernel 输出 NaN稀疏索引越界检查 offs 计算增加边界 clamp性能没有提升稀疏度不够或 tile 过小调整 block size 和稀疏阈值LLM 调用超时本地模型推理速度慢设置流式输出或增加超时时间显存不足并行度设置过高限制 grid 数量或降低 BLOCK 大小8. 工程实践建议8.1 安全性不要把生成代码直接投入生产在开发 SparseDitto 这类系统时最重要的一条铁律是不要在主进程内直接执行 LLM 生成的代码。建议做法是在独立的 Docker 容器或沙箱中编译和运行生成代码。对生成的代码做静态审查检查是否存在危险 API 或资源耗尽风险。为编译和运行进程设置 CPU、内存、显存限制。所有基准测试使用非生产数据验证通过后再接入正式推理链路。这条建议不只是为了安全也是为了让系统更稳定。LLM 生成的代码可能调用 GPU 显存过大如果直接在主进程运行可能拖垮整个训练或推理服务。8.2 配置管理用版本化方式管理稀疏模式不要频繁地在代码中硬编码稀疏模式。建议把稀疏模式描述放到独立的配置文件中并纳入 Git 管理。这样当 LLM 生成结果变化时你可以追踪是哪一次配置变更导致了性能回退。{ pattern_id: block_sparse_32_v1, block_size: [32, 32], sparsity_threshold: 0.8, target_gpu: NVIDIA A100, fallback_kernel: dense_triton }8.3 性能缓存与重试策略LLM 调用不是免费的而且生成过程具有随机性。实际工程中应该做到对 Prompt 内容做哈希相同稀疏描述不重复调用 LLM直接使用历史最优 kernel。对每次评估结果做记录包括代码、耗时、显存、正确性指标。设置最大重试次数避免模型在错误中循环。8.4 最小权限原则与日志记录如果 SparseDitto 系统需要加载外部权重或访问远程 LLM 服务建议遵循最小权限原则LLM 服务只暴露必要 API不给文件系统权限。系统日志只记录必要信息不要打印完整权重或敏感数据。每次生成和评估都记录 trace ID方便回溯。9. 总结与学习路线SparseDitto 代表的是一种全新的算子开发范式从“手工编写 GPU 内核”到“LLM 智能体自动生成内核”。它的出现并不意味着人工算子工程师会被完全替代而是把更多重复性、探索性的工作交给大模型让人更专注于算法设计、异常分析和系统架构。如果想进一步学习可以按以下路线推进先掌握稀疏矩阵基础理解 CSR、CSC、BSR 等格式的适用场景。再学习 Triton 官方教程重点练习 tile 计算、索引偏移和内存访问。然后尝试复现一个简化版 SparseDitto先用固定几个 pattern 跑通闭环。最后再思考如何扩展多 GPU、动态 shape、自动检测稀疏模式、集成编译缓存等。在动手实践时建议从一个小矩阵、一个固定稀疏模式开始先确认流程闭环再逐步扩大场景。你可以先在本地部署一个小规模 LLM用最简单的“生成一次、评估一次、反馈一次”跑通第一版然后再加入更复杂的 Planner 和 Critic 组件。如果你正在研究模型压缩或推理加速SparseDitto 的思路值得关注。它不一定替代 cuSPARSE 或 cuBLAS但作为“面向任意稀疏模式的动态内核生成方案”在定制化算子需求越来越多的今天具备很强的工程参考价值。