几乎每个做过稀疏模型推理的人都会在某个深夜面对同一种困惑模型剪枝后权重文件小了一半理论上 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基于块剪枝、硬件结构化剪枝固定块大小 bitmapTile 大小、块内连续访存、共享内存利用率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 size32 分块”或“使用某条 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.sparseKernel Generator根据稀疏模式描述、目标 GPU 架构和优化要求生成 kernel 候选代码大模型 API、本地 LLM、代码模板Compiler Runtime Feedback编译代码、执行测试、收集错误信息和性能指标nvcc、gcc、Nsight Compute、PythonIterative 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 生成 PromptLLM 生成代码的质量高度依赖 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 -archsm_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 策略考虑是否适合用稀疏 kernelAgent 多轮迭代仍然失败反馈信息不完整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而在于我们能不能把硬件反馈和代码生成之间的“对话”做得足够精细。谁能把这条路打通谁就能显著降低稀疏模型落地的工程成本。