050 · 插入探针后，瓶颈还是原来那个吗？
Warpline 在 GPU 二进制上插入探针，再把 warp 事件与硬件指标对齐。它提出的不只是让 Agent 看见更多数据，而是先追问：这些数据描述的还是原来的程序吗？
Gpu
046 · 简化版被证明，原 kernel 就正确了吗？
RESOLVE 用逐位测试连接原始 kernel 与低并发版本，再证明后者的代数等价性。这条混合证据链扩大了验证范围，也要求分清：哪些连接经过证明，哪些仍依赖有限执行。
044 · 优化停滞，错在程序还是团队？
Evolving Agent Teams 让监督者随搜索瓶颈重组角色与知识共享方式。它提供了有力的系统比较，也留下一个因果问题：突破究竟来自重组，还是随之改变的信息与搜索约束？
018 · Kernel 快了，端到端为什么几乎没动？
这篇论文把 kernel benchmark 的局部加速与真实 workload 的时间占比相乘：在 Transformer 中，可被生成式优化触及的部分仅占 8.9%–16.8%，因此看似不错的 kernel speedup 往往只能投射为约 1%–2.5% 的端到端收益。
017 · 人不写 CUDA，就等于 Agent 自主优化吗？
Agentic Kernel Optimization 用多 Agent、性能分析和人工搜索纠偏，在 B200 上为三类 FlashInfer-Bench workload 生成高性能 CUDA kernel；论文证明了代码可由 Agent 完成，却也留下了系统自主性、基线口径与验证边界的问题。
016 · 退回编译器基线，也算优化成功吗？
KernelOPT 尊重 Inductor 已做出的库调用分派，只搜索生成的 Triton 子 kernel，并用四级验证决定替换或回退；250 个 KernelBench 问题上的整体加速来自少数显著收益与大量基线保留的组合，不能等同于每个任务都被优化。
015 · 证据来自不同运行，还能属于同一段程序吗？
Argus 以稳定的语义区域为共同坐标，规划彼此隔离的多次 GPU 测量，并把直接观测、跨视图归因和变体推导的证据明确区分；实验显示更细粒度的反馈能改善多种 kernel 优化 Agent，但跨运行归因仍依赖区域身份与执行可比性的假设。
013 · 告诉 Agent 错在哪里，比只说“结果错了”更有用吗？
Ave 把 GPU kernel 优化必须保持的数据关系写成编译期不变量，再用静态分析与具体反例指导 Agent 修复；消融实验支持这种结构化反馈，但其保证范围取决于人预先表达了哪些不变量。
012 · 不跑 GPU，也能知道哪个 kernel 更快吗？
GPU Forecasters 让 LLM 预测候选 kernel 相对参考实现的性能分布，再把有限的真实 GPU 测量留给更值得验证的候选；实验说明排序信号有用，也显示校准、分布变化与总成本仍是关键边界。
CUDA 软件栈测试方法论：从 Differential Testing 到 GPU Compiler Fuzzing
从 CUDA 软件栈测试全貌出发，给出一套面向 Triton/GPU compiler 的 fuzz 测试选型、架构、CI 分层和落地方案。