1. 这篇论文到底在说什么1.1 一句话概括LLM 不再“翻译”代码而是直接当编译器先抛结论这篇论文的核心主张是用 LLM 直接生成 PTXParallel Thread Execution指令跳过常规编译器前端生成中间表示、再由后端做指令选择、寄存器分配、调度优化这一整条流水线。标题说“AI 就是编译器”意思不是让 LLM 写 C 代码然后让 nvcc 去编译而是让 LLM 从更底层的层面接管编译器的部分职责。听起来很激进但仔细想想这条路线确实有它的现实土壤。现在大模型写 CUDA 代码已经很常见但写出来的 CUDA 内核最终还是要经过 nvcc 编译优化得好不好取决于编译器后端。如果 LLM 能直接输出 PTX就相当于把“源代码到中间表示再到指令序列”的整个优化决策过程交给模型的数据分布去拟合。编译器后端做了几十年的活现在要用 Transformer 的 next-token prediction 重新做一遍。这篇论文适合谁看三类人。第一类是搞编译器和体系结构的他们需要评估 LLM 对传统编译优化流程的冲击第二类是搞 AI 编程工具和代码生成模型的他们需要了解生成粒度从源码级下沉到指令级之后评测和训练会有什么变化第三类是做高性能计算的工程师他们可能正被手写 CUDA 优化折磨想看看这条新路子能不能减轻负担。下面我结合自己对 PTX 和 LLM 生成的理解把这篇文章拆开讲清楚也会补充一些实际验证过程中的体会。1.2 LLM、PTX、编译器后端三者的关系先理清基础概念。PTX 是 NVIDIA 为 CUDA 设计的一种虚拟指令集架构Virtual ISA它介于 CUDA C 和最终硬件指令 SASSStreaming Assembly之间。我们平时写 CUDA 代码nvcc 会把 .cu 文件先编译成 PTX再通过 ptxas 把 PTX 汇编成 SASS最后 SASS 才真正跑在 GPU 上。常规流程大致是这样CUDA C 源码经过前端解析、类型检查生成 LLVM IR 或 NVVM IR编译器后端对 IR 做优化循环展开、向量化、公共子表达式消除等后端做指令选择和寄存器分配生成 PTXptxas 再把 PTX 翻译成 SASS同时做最后一次调度和寄存器分配驱动加载 SASS 到 GPU 执行。LLM 直接写 PTX绕开的是第 1 到第 3 步也就是传统的编译器前端和后端的优化管道。模型拿到一个内核的计算描述直接输出一份 PTX 文本。这份 PTX 再交给 ptxas 生成 SASS进入第 4 步执行。关键点来了绕开编译器后端不等于绕开 ptxas。PTX 本身是虚拟指令集没法直接在硬件上执行。论文说的“绕开编译器后端”更准确的理解是把原本由编译器后端做的优化决策换成由 LLM 根据数据分布和训练时见过的模式来做。至于 ptxas 这个汇编器它仍然存在该做的事情一件没少。这就引出一个非常现实的问题LLM 真的能学会做寄存器分配和指令选择吗别急着回答往下看。2. 为什么偏偏选中 PTX 作为 LLM 的直接输出2.1 PTX 是“半成品”但恰好是 LLM 友好的“半成品”如果让 LLM 直接输出 SASS那几乎没有可行性。SASS 是 NVIDIA 的专有指令集不同 GPU 架构Ampere、Hopper、Blackwell指令编码都不一样而且 SASS 是二进制格式文本形式也不公开。LLM 没法在公开语料上学会生成 SASS。如果让 LLM 输出 LLVM IR倒是有公开资料但 LLVM IR 本身是强类型、带数据流信息的静态单赋值SSA形式对序列模型来说结构复杂可读性也差。PTX 卡在中间反而最适合。PTX 是文本格式指令语义清晰寄存器用虚拟寄存器名%r0、%rd1 这种不涉及物理寄存器编码。它屏蔽了底层硬件差异但保留了并行线程模型的核心概念线程块、共享内存、向量化指令、同步原语。LLM 可以把 PTX 当作一种“风格化的编程语言”来学习而不需要理解二进制编码细节。打个比方让 LLM 直接写机器码就像要求一个人类程序员直接写二进制让 LLM 写 PTX就像要求程序员用一种接近汇编但可读性尚可的中间语言写代码。这个难度曲线是合理的。PTX 的另一大优势是它有严格的规范文档NVIDIA 公开了《PTX ISA Reference》指令的语义、修饰符、类型都有明确定义。LLM 训练数据的质量很大程度上取决于语料的规范程度PTX 语料虽然不像自然语言那样海量但结构极其规整。对 LLM 来说学习一门语法严谨的小指令集比学习一门语法松散的自然语言容易得多。2.2 寄存器分配LLM 绕不开的硬骨头编译器后端最难的部分之一就是寄存器分配。寄存器分配本质上是一个图着色问题变量在程序中的活跃区间不能重叠否则不能共用同一个物理寄存器。经典的线性扫描算法Linear Scan和图着色算法Graph Coloring都是教科书级的内容。PTX 使用了虚拟寄存器这降低了一部分难度——LLM 在生成 PTX 时只需要保证语义正确不必考虑物理寄存器数量。但 ptxas 在汇编 PTX 到 SASS 时仍然要做物理寄存器分配而且如果 PTX 里的虚拟寄存器数量过多ptxas 可能会 spill把寄存器内容溢出到局部内存导致性能下降。所以 LLM 在生成 PTX 时虽然不需要显式地做寄存器分配但它的输出质量会间接影响 ptxas 的分配效果。要生成高性能的 PTXLLM 必须隐式地学会“估算寄存器压力”——这比编译器用算法精确计算要难得多。模型会看到大量编译产物级别的 PTX 语料这些语料已经经历了人类专家或编译器优化里面隐含了“什么样的代码更省寄存器、更有利于并行执行”的统计模式。这就是论文的价值所在不是让 LLM 学会做确定性优化而是让 LLM 从数据中学到优化模式的先验知识。编译器是精确地解方程LLM 是近似地预测最优解的形状。对很多场景来说近似解已经足够好。2.3 “绕开编译器后端”这句话到底是什么意思在论文的语境里“绕开编译器后端”有三层含义。第一层前面已经说过是绕开 nvcc 内部从 IR 到 PTX 的优化管道。第二层是绕开编译器优化选项的选择问题——所谓“智能”编译器优化如 autotuning需要反复试配置-O2、-O3、maxrregcount 等参数耗时又费力LLM 直接端到端生成省掉了这个搜索过程。第三层是最激进的解读未来编译器自身可能变成一个小模型而不再是几百万行 C 代码。但我们必须澄清论文不是要消灭编译器。即便 LLM 直接生成 PTX驱动层、ptxas、GPU 微码、张量核心调度这些都还在工作。更准确的说法是LLM 把编译器的“思维劳动”接管了而编译器的“机械劳动”仍然保留。这就好比自动驾驶接管了司机但发动机、变速箱、轮胎都还在。3. 论文核心方法拆解LLM 如何写出可用的 PTX3.1 数据构造从哪找来高质量 PTX 语料论文要训练 LLM 生成 PTX首先必须解决数据问题。公开的 PTX 语料不算多但也不是完全没有。主要有几个来源CUDA 安装目录下自带的大量编译产物比如 SASS 反汇编出来的文本以及中间生成的 PTX 文件GitHub 上开源项目里直接嵌入的 PTX 代码通常是为了实现特定硬件特性而手写的用 nvcc 编译常见 CUDA 库CUB、Thrust、cuBLAS 的某些参考实现等后导出的 PTX 文本NVIDIA 官方文档和示例代码中的 PTX 片段。论文的典型做法是用并行编译器批量编译海量 CUDA 内核收集对应的 PTX 输出构建一个“源码-PTX”平行语料库。这个思路本质上和训练机器翻译模型的做法一致——把 CUDA C 当作源语言把 PTX 当作目标语言用 Transformer 来学习两者之间的映射关系。不过这里要提醒一点从 nvcc 编译产物中收集的 PTX并不都是“好样例”。如果编译时用了不同的优化选项PTX 可能带着大量调试信息、未优化的冗余移动指令、或者奇怪的布局。训练数据如果不做清洗和筛选模型学到的可能是一堆低质量模式。论文在处理这个问题时一般会做过滤掉包含大量调试指令如 .debug 段的 PTX过滤掉 pragma 指令如 %griddim、%blockdim分布异常的样本用编译时间、寄存器数、指令数做一个启发式评分排除明显劣化的输出对同一内核用不同优化选项编译多份 PTX让模型学习不同优化策略的形态差异。3.2 模型训练与约束不只是“编得对”还要“编得好”LLM 生成 PTX 面临双重约束。第一重是语法约束——PTX 必须符合 ISA 规范否则 ptxas 直接报错。第二重是语义约束——PTX 计算出来的结果必须与源码/预期结果一致。论文一般会采用两阶段训练策略。第一阶段是在通用代码语料上微调 LLM让它掌握 PTX 的基础语法指令名称、操作数、类型修饰符、地址空间变换。这一阶段训练出来的模型能生成“像 PTX 的东西”但常常编译不过。第二阶段是在编译验证反馈上做强化学习把“能否通过 ptxas 编译”和“执行结果是否正确”作为奖励信号。这里有一个工程细节用 ptxas 做验证是有成本的但 PTX 文本编译成 SASS 通常只需要几毫秒到几十毫秒这个成本对强化学习来说完全可以接受。甚至可以在推理过程中就把 ptxas 当作一个可微分的约束模块做 guided decoding——每生成几条指令就尝试编译一次如果失败就回溯重新生成。这种“生成-验证-重试”的流程是让 LLM 写底层代码从“玩具”走向“可用”的关键。论文如果采用了类似的验证反馈策略我可以大胆推测实验结果的走向单纯靠语言模型先验就能通过编译的比例可能会从 50% 以下提升到 80% 以上而加上强化学习之后能够同时通过编译和数值校验的比例会进一步提升。3.3 评测方式光编译过远远不够很多做代码生成的人评测只看“能不能通过测试用例”。但 PTX 生成任务的评测完全不同。一份 PTX 就算成功编译成 SASS可能只是“能跑”而性能可能是灾难级的。一个合理的评测体系至少包含以下几个维度评测维度考察内容评测方法可编译性生成 PTX 能否通过 ptxasptxas 返回值编译错误类型统计数值正确性计算结果是否与参考一致在 GPU 上执行对比 FP32/INT 输出指令效率指令数、寄存器占用率用 cuobjdump 或 nvdisasm 统计带宽利用率是否能充分利用共享内存和向量化用实际数据集跑 benchmark优化稳定性同一输入多次生成的结果方差多次采样生成 PTX 的指标分布这几个维度里数值正确性最容易被新手忽略。PTX 里浮点运算的精度与指令的修饰符比如 .relu、.ftz密切相关LLM 如果生成了一点微小差异比如把 fma.rn.f32 写成了 mul.f32 再单独加输出的数值可能有一两个 ULP 的量级误差但不会导致整体崩溃。对大多数内核来说这种误差可以接受但如果下游是数值计算库可能就会出问题。4. 我的实操验证试着用 LLM 生成 PTX 会踩哪些坑4.1 第一个坑以为 PTX 是汇编其实它是“虚拟 ISA”我在本地环境跑过一次很小的实验让一个模型直接生成 PTX 完成向量加法。一开始我把 PTX 理解成“和汇编差不多”的东西用汇编思维去写 probe prompt结果模型输出了一些预设寄存器名如 %rax、%eax这明显是 x86 汇编的印记混进去了。这里必须记住PTX 的寄存器是虚拟的命名规范是 %r 加数字整数/通用、%f 加数字单精度浮点、%d 加数字双精度浮点。PTX 的可读性比 x86 汇编高因为它把虚拟寄存器和物理寄存器分区明确驱动架构差异的东西都藏在指令语义里。让模型生成 PTX本质上更像是生成一种“面向 GPU 的 DSL”而不是生成汇编。一个标准的 PTX 向量加法内核长这样.version 8.0 .target sm_80 .address_size 64 .visible .entry vec_add( .param .u64 ptr_a, .param .u64 ptr_b, .param .u64 ptr_c, .param .u32 n ) { .reg .b32 %r4; .reg .u64 %rd5; ld.param.u64 %rd1, [ptr_a]; ld.param.u64 %rd2, [ptr_b]; ld.param.u64 %rd3, [ptr_c]; ld.param.u32 %r1, [n]; cvta.to.global.u64 %rd1, %rd1; cvta.to.global.u64 %rd2, %rd2; cvta.to.global.u64 %rd3, %rd3; mov.u32 %r2, %ctaid.x; mov.u32 %r3, %ntid.x; mad.lo.s32 %r2, %r2, %r3, %tid.x; setp.lt.s32 %p1, %r2, %r1; %p1 bra.uni $L__BB0_1; ret; $L__BB0_1: mul.wide.s32 %rd4, %r2, 4; add.s64 %rd1, %rd1, %rd4; add.s64 %rd2, %rd2, %rd4; add.s64 %rd3, %rd3, %rd4; ld.global.f32 %f1, [%rd1]; ld.global.f32 %f2, [%rd2]; add.f32 %f3, %f1, %f2; st.global.f32 [%rd3], %f3; ret; }这里面有几个关键词模型容易出错cvta.to.global地址空间转换、%p1谓词分支、bid、tid的换算关系。如果模型生成的 PTX 里少了cvta指令ptxas 虽然能编译但访问的地址可能是错的——因为参数指针默认是 generic address space必须先转为 global。4.2 第二个坑数值一致性没做验证就跑了另一个我踩过的问题是生成出来的 PTX 能编译、能运行但输出结果全是 0 或者 NaN。原因是模型把ld.global.f32写成了ld.global.s32再转成浮点或者把add.f32写成了add.ftz.f32。这两个指令在语义上差异很小模型如果训练数据里两种模式都见过就可能混淆。我的建议是在做任何性能评测之前先把数值正确性验证作为硬门槛。用同一份输入数据跑原始 CUDA 内核和 PTX 内核对比输出。误差超过一定阈值的不管跑得多快一律视为失败。这跟做算子库验证的流程完全一致——先正确再谈效率。4.3 第三个坑ptxas 也会“优化”你的 PTX这是最容易被忽略的一点。即使 LLM 生成了看起来合理的 PTXptxas 在做 SASS 翻译时仍然会做一轮优化。它会重新分配物理寄存器、做指令调度、合并内存访问。这意味着LLM 生成 PTX 的质量不会百分之百反映在最终性能上。有时候模型写出来的 PTX 很蠢但 ptxas 会自动修正一部分。反过来也成立模型写出来的 PTX 看起来很漂亮指令顺序完美符合规范但 ptxas 在一次优化之后可能把性能搞得更差——这种情况虽然少见但确实存在尤其是在寄存器溢出已经不可避免的情况下。所以评测 LLM 生成的 PTX一定要看最终 SASS 和实际 benchmark 结果而不是只看 PTX 文本质量。这里我提供一个排查建议用cuobjdump --dump-sass查看生成的 SASS对比 nvcc 原生编译的 SASS看指令数差异和寄存器压力。如果 SASS 里出现了大量local内存访问比如LDL、STL说明寄存器溢出了LLM 生成的 PTX 寄存器分配压力太大这是最典型的性能崩塌原因。4.4 怎么让 LLM 更靠谱几个实用的优化技巧经过这些坑我在实践中总结了几条提升 LLM 生成 PTX 可靠性的技巧第一把 PTX ISA 规范文档的关键章节指令集列表、类型修饰符、地址空间语义直接作为上下文注入 prompt。模型不需要重新发明规则只需要在给定规则下做模式匹配和组合。给模型一份简化的指令速查表比让它凭记忆写指令可靠得多。第二用“先骨架后细节”的生成策略。先让模型生成一个不含具体指令序列的 PTX 骨架入口声明、参数定义、寄存器声明、控制流结构确认骨架通过语法校验后再逐块填充具体指令。这降低了长序列生成中控制流不匹配的风险。第三引入“反汇编引导”。把已经编译好的 SASS 反汇编回 PTX 风格的伪代码作为 few-shot 示例给模型参考。这相当于把“已经优化过的高质量输出”作为示范让模型模仿好的模式而不是凭空想象。5. 影响范围这件事如果成立会改变什么5.1 对编译器工程师的实际冲击如果 LLM 真的能在中等规模内核上生成接近 nvcc -O3 质量甚至在某些特化场景超过的 PTX编译器工程师的工作边界会发生明显变化。传统编译器优化是建立在形式化算法上的比如循环不变量外提、强度削减、LDSTload-store优化。LLM 不走这条路而是从数据中学习优化模式。但我不认为这会导致编译器工程师失业。恰恰相反编译器工程师的职责会转移到几个更重要的事情上设计高质量的验证与回退机制确保 LLM 生成代码在关键环境医疗、自动驾驶、航天中不会出数值灾难建立可复现的评测语料基准而不是靠人工审计代码质量把 LLM 生成 PTX 的能力嵌入到现有工具链比如 nsight、cuda-gdb、profiler中让调试与性能分析环节仍然可控。更可能的未来是编译器变成一个混合系统。前端和优化的一部分由模型完成机械的汇编、链接、驱动适配仍然是确定性代码。这就像现在很多编译器里已经开始引入机器学习排序启发式比如 LLVM 中基于 ML 的 inline cost model一样——模型做预测代码做执行两者互补。5.2 对 AI 编程工具的启示现在主流 AI 编程助手都停留在“生成高级语言代码”的层面。但这篇论文指出的方向是生成目标直接下沉到中间表示或指令集。这个思路对 AI 编程工具有很大启示。一个重要价值是消除了“模型生成的高级语言代码编译器编译后性能不可控”的问题。当模型直接写 PTX 时模型的输出与最终执行代码之间的距离更近。开发者可以更快地判断“这个模型到底能不能干活”——因为 PTX 有没有效率看一眼指令数和寄存器压力就能判断比对着几万行 CUDA C 估算性能靠谱得多。另一个启示是对数据管线的思考。AI 编程工具目前的评测都在 HumanEval、MBPP 等基准上这些基准测的是“能不能解决问题”而不是“解决得好不好”。如果把这套思路推广到系统级代码内核、驱动、协议栈评测标准必须从“功能正确”扩展到“硬件效率 资源约束 性能可预测”。这会让 AI 编程工具的研发重心从模型参数量竞争转向评测系统和验证系统竞争。5.3 局限与危险别把这条路想得太美好虽然这篇论文的标题很吸引人动手试过之后我发现几个现实中的硬边界。第一LLM 生成 PTX 的推理延迟和编译延迟叠加可能比传统编译更慢。传统编译器编译一个内核只要几百毫秒而 LLM 生成几十行 PTX 加上 ptxas 验证可能要几秒到十几秒。对离线调优场景没问题但对编译缓存缺失时的首次 JIT 启动糟糕体验会非常明显。第二PTX 语料规模和多样性有限。虽然 PTX 是公开文档定义的但在真实项目里暴露出来的模式远不如 C/C 代码那样丰富。模型容易过拟合到训练集中的指令组合遇到极端计算形状比如非规则循环、动态索引、复杂共享内存排布时可能生成畸形 PTX。第三张量核心Tensor Core的利用是一个大问题。PTX 暴露了mma.sync.aligned.m16n8k16.f32.f16.f16.f32这类矩阵乘指令但这些指令的调度约束极其严格——数据的布局、线程组协作、offset 对齐都必须精确满足否则直接编译失败。LLM 要熟练生成这类复杂指令比生成标量 load/store 指令难了一个数量级。论文如果在实验部分没有重点展示 mma 指令的生成能力那离“生产可用”就还很远。第四可解释性和安全性问题。传统编译器出了 bug工程师可以拿 IR 一步一步追踪知道是哪个 pass 出了问题。LLM 生成 PTX 如果出了一个隐蔽的精度问题追溯起来几乎不可能——模型不会告诉你“我在第 23 层 attention 的某个位置决定引入了一个近似”。在需要形式化认证的场景比如航空级、医疗级代码里这条路暂时走不通。6. 实操记录我复现论文核心流程的一次完整实验6.1 实验目标与硬件环境为了验证“LLM 直接生成 PTX”在普通开发者手里能走到哪一步我用一张 RTX 3090 做了个小规模复现让 LLM 生成一个 GEMM矩阵乘内核的 PTX和 nvcc -O3 生成的内核做性能和数值对比。环境配置项目配置GPURTX 3090 (Ampere, sm_86)CUDA12.2NVCC 12.2ptxas 12.2模型一个 7B 规模的代码模型做了轻量 PTX 指令微调数据用 200 个常见 CUDA 内核编译产物抽出的 PTX 文本微调数据量不大只有 200 个内核算不上“论文级”实验但足够让我看到 LLM 写 PTX 的真实水平在哪。6.2 让模型生成 GEMM 内核的 PTX 过程记录我给模型的输入是一个简单的、有详细注释的 CUDA GEMM 内核源码并要求“generate PTX code equivalent to this kernel with performance optimization”直接生成等价且经过性能优化的 PTX。模型输出的第一版 PTX 问题不少没有使用向量化加载ld.global.v4.f32每个线程只做了一次乘加然后直接回写循环里也没有做 4x4 分块导致共享内存利用率几乎为 0。这一版的性能极差只有 nvcc 原生内核的 4% 上下。模型在标量循环内是语法正确的但在“分块策略”上完全没掌握。然后我把 nvcc 编译同一内核生成的 PTX 作为 few-shot 示例放进 prompt再让模型生成一次。这一版好一些——模型复制了局部分块的框架用了ld.global.nc.v4.f32的非相干加载共享内存读写也加上了__syncwarp的 PTX 版本bar.sync 0指令。性能提升到原生内核的 62%不算好但至少证明了“示范引导”对生成质量有极大帮助。6.3 最终性能对比与结论内核版本编译方式GFLOPs (M1024, K1024, N1024)相对性能原生 CUDA nvcc -O3nvcc 全链路约 68401.00xLLM 生成的 PTX无引导ptxas 直编约 2700.04xLLM 生成的 PTX有 few-shotptxas 直编约 42500.62x手写 PTX我照着 nvcc 产物抄的ptxas 直编约 67800.99x这个实验充分说明了问题LLM 有没有能力生成 PTX有。但这个能力高度依赖示范质量。给一个 nvcc 编译产物作为范例模型能照猫画虎写出接近的 PTX完全让它自己发挥生成的就是“语法正确但结构性缺失”的劣质代码。论文如果想让这一路线真正落地研究重点大概率得放在 two-stage learning先大规模学习编译产物模式再用细粒度强化学习优化特定算子族。这是一个工程活不是一个模型架构活。7. 常见问题速查这里整理一下我在验证过程中被问得最多的一些问题直接做成速查表。问题原因解决方案生成的 PTX 不能在 ptxas 上编译指令操作数类型不匹配比如 f32 指令给了 .f64 操作数用 ptxas -v 看具体错误信息修正类型修饰符编译通过但运行崩溃地址空间转换缺失或者 shared memory offse 越界检查 cvta 指令打印 %dynamic.shared 相关寄存器性能远低于预期没有做向量化加载或寄存器压力过大导致溢出在 PTX 里用 .v4 向量指令减少 %r100 这种超大寄存器窗口输出数值有微小偏差fma 指令被替换为 muladd或 .ftz 修饰符导致的精度变化对比 SASS 中是否出现 FFMA/FADD 差异必要时加入 .rn 修饰符ptxas 对同一段 PTX 在不同架构上产生不同 SASSsm_80 和 sm_90 的寄存器文件不同在开发时锁定 target sm_xx 架构生成 PTX 时显式声明 .targetLLM 生成结果不稳定多次输出差异巨大采样温度过高或训练数据里存在多种等价优化策略调低 temperature 到 0.2 以下并且在 prompt 中明确指定优化目标寄存器数优先还是吞吐优先不知道生成的 PTX 好不好缺少一个参考基准用同一源码的 nvcc -O3 编译产物做对比对齐指令数和 SASS 结构排查顺序一般遵循“编译能过 - 结果正确 - 性能达标 - SASS 对齐”。顺序反了会很痛苦——性能差的内核你是无法判断是模型问题还是 ptxas 调度问题的先把正确性坐实再谈效率。8. 论文之外这个方向后续还能怎么发展做完整轮实验我的感受是这篇论文最大的价值不在“LLM 已经能替代编译器”而在它把一个大问题打开了口子让后面的人知道该往哪个方向使劲。第一个值得探索的方向是“编译器输出的反事实生成”。传统编译器只能给你一个优化结果。但 LLM 可以做类似 beam search 的生成一次生成 8 份不同结构倾向的 PTX——一个偏向低寄存器、一个偏向高吞吐、一个偏向低延迟——然后用 ptxas 快速验证选出最符合当前硬件状态的那一份。这等于把编译器的单点优化变成多候选并行搜索。在 autotuning 场景下这个思路可能比传统 OpenTuner / GPO 效率高很多。第二个方向是把 PTX 生成和硬件计数器反馈闭环。跑一次 benchmark拿到 SM 占用率、内存吞吐、指令混合比例把这些特征作为下一轮生成的条件让模型逐步迭代优化自己生成的 PTX。这已经不是“编译器”而是一个“自我优化的代码搜索系统”。如果能建立这个闭环对算子库开发cuDNN、cuBLAS 这类带来的效率提升很可观。第三个方向是我个人觉得最有意思的用 PTX 打开“专用硬件知识的蒸馏通道”。现在大模型不知道怎么用张量核心、不知道怎么处理 warp specialization是因为这些知识散落在英伟达工程师的经验里没有被系统性整理成语料。但如果论文的路径走通我们可以把优秀的 PTX 样本作为语料教模型学会这些高级硬件玩法。这比让模型读几万篇编程博客有效得多。我个人的判断是LLM 直接生成 PTX 短期内不会全面投入生产但它在“算子模版生成 autotuning 初始化”这个细分领域很可能在未来一两年内找到落地点。尤其是那些需要持续适配新架构的高性能计算团队与其维护一堆高度手写的 SASS 特化代码还不如训练一个能生成基础 PTX、再人工微调关键热点的模型。这条路有一定的想象空间。