AI编程Agent用10小时凿开CUDA护城河：推理战场的底层软件革命与程序员的真实机遇

引言：当「10小时复刻CUDA」成为可能

2026年8月，AI行业被一条新闻刷屏了：

一家成立仅一年的小公司，用AI编程Agent，只花10个小时，就为一款非英伟达AI芯片搭建出了一套完整的底层软件栈——包括GPU Kernel生成、测试、调试和性能优化，形成了某种意义上的「类CUDA」能力。

而在此之前，这套工作通常需要一支经验丰富的芯片软件工程师团队，花上数月甚至数年才能完成。

消息一出，圈内炸锅。有人高呼「CUDA的护城河终于被凿穿了」，有人冷静指出「这不过是第一层，离真正的CUDA生态还差得远」，还有人干脆泼冷水——「代码能生成，不等于能用在生产环境」。

那么，真相到底是什么？

作为程序员，我们更关心的是：这场底层软件的变革，对我们的日常工作意味着什么？AI编程Agent的这一次突破，是噱头还是真实的范式转变？

这篇文章，我不打算做情绪化的判断。我要做的是把这件事的底层逻辑拆开来看，从CUDA的架构本质，到AI Agent生成Kernel的工程原理，再到推理市场的竞争格局，最后给出一个程序员视角的判断：你该不该关心这件事，以及如果关心，你应该关注什么。

一、CUDA到底是什么：不止是一门语言

在讨论「AI能不能替代CUDA」之前，我们先得搞清楚CUDA究竟是什么。很多人对CUDA的理解是「英伟达的编程语言」，这个理解只对了一半。

1.1 CUDA的真实结构：三层软件帝国

CUDA的全称是Compute Unified Device Architecture（统一计算设备架构），它由英伟达高管Ian Buck带队，花了近20年打造。如果把它拆开来看，实际上是一个三层嵌套的软件体系：

第一层：内核层（Kernel Layer）

这是最底层，直接和GPU硬件打交道。包括：

• CUDA C/C++编译器（NVCC）：将CUDA代码编译成PTX（Parallel Thread Execution）中间代码，再进一步编译成GPU机器码
• GPU Kernel：用__global__修饰符声明的并行计算函数，是GPU上真正执行计算的代码单元
• CUDA运行时（Runtime API）：管理GPU内存分配、数据传输、Stream流控制等底层操作

一个典型的CUDA Kernel看起来是这样的：

// 矩阵加法 Kernel
__global__ void matrixAdd(float *A, float *B, float *C, int width) {
    int row = blockIdx.y * blockDim.y + threadIdx.y;
    int col = blockIdx.x * blockDim.x + threadIdx.x;
    
    if (row < width && col < width) {
        C[row * width + col] = A[row * width + col] + B[row * width + col];
    }
}

// 调用方式
dim3 threadsPerBlock(16, 16);
dim3 blocksPerGrid((width + 15) / 16, (width + 15) / 16);
matrixAdd<<<blocksPerGrid, threadsPerBlock>>>(d_A, d_B, d_C, width);

这层的工作是让GPU真正「干活」——把数学运算翻译成硬件指令。

第二层：库层（Library Layer）

这是CUDA真正值钱的地方。经过20年的打磨，英伟达为各种主流计算场景提供了高度手工优化的库：

• cuBLAS（CUDA Basic Linear Algebra Subprograms）：线性代数库，针对矩阵乘法等操作做了极致优化
• cuDNN（CUDA Deep Neural Network Library）：深度学习卷积、池化、激活函数等算子的GPU实现，是TensorFlow、PyTorch深度学习框架的性能基石
• cuFFT（快速傅里叶变换）、cuSPARSE（稀疏矩阵）、cuSOLVER（线性方程组求解器）……

这些库里的每一个函数，都经过了英伟达工程师团队长达数年的手工调优。以cuDNN中的卷积实现为例，内部会根据GPU架构（Volta、Ampere、Hopper等）自动选择最优的实现路径，包括FFT卷积、Winograd算法、直接法等，每一种都在特定条件下做了手工汇编级别的优化。

第三层：框架与生态层（Ecosystem Layer）

这是CUDA护城河的最终形态：

• 深度学习框架：PyTorch、TensorFlow、JAX的GPU后端都以CUDA为核心
• 开发者生态：数百万开发者积累的海量CUDA代码、工作流和最佳实践
• 工具链：Nsight系列调试器、profiler、Visual Profiler，构成了完整的开发和优化工具链
• 社区与文档：20年积累的教程、论坛回答、代码样例

1.2 为什么说CUDA的护城河是「难以复制」

把英伟达GPU想象成一座工厂，CUDA三层的关系就好比：

• 第一层（内核层）：告诉你机器的每一个齿轮怎么转
• 第二层（库层）：直接给你现成的、已经调试好的生产工具
• 第三层（生态层）：整座工厂的运转体系，包括工人培训手册、供应链、维修网络

现在的问题是：AI Agent能在10小时内搭好「告诉齿轮怎么转」的第一层，但第二层的库——那些经过多年手工优化的cuBLAS、cuDNN——能在10小时内被替代吗？

答案是否定的，至少目前是。但这并不意味着第一层不重要——恰恰相反，第一层是进入门槛，第二层是护城河深度，而第三层才是最终的锁定效应。

二、Infinity + Ignition：10小时复刻了什么

2.1 事件核心角色

这次事件的主角是Infinity公司及其创始人Jeremy Nixon。Nixon此前在Google Brain担任研究员，Infinity是他的创业项目，专注于为不同AI芯片编写底层软件。

Infinity的核心产品是一款名为Ignition的AI研究Agent。它的设计思路非常清晰：

人类工程师（给出高层方向）
    ↓
Ignition Agent（自动化执行）
    ↓
生成GPU Kernel → 运行测试 → 寻找错误 → 测量性能 → 自动改写
    ↓
人类工程师（审查结果，调整方向）

Ignition的核心能力是把一个需要反复手动调试的工程循环自动化。这个循环对AI Agent来说特别友好，因为每一步都有明确的反馈信号：

• 编译是否通过？→ 明确的是/否
• 运行结果是否正确？→ 可以和已知正确结果比对
• 性能是否提升？→ profile数据直接量化

这恰恰是AI Agent最擅长的工作模式：有明确目标、有即时反馈、需要大量试错的循环迭代。

2.2 服务对象：d-Matrix推理芯片

Infinity这次用Ignition服务的是一家名为d-Matrix的AI芯片公司。d-Matrix成立于2019年，专注于生成式AI推理芯片，其核心技术路径与传统GPU有所不同。

d-Matrix的CEO Sid Sheth在公开场合表示，他们很早就判断AI推理的机会最终会超过训练，而Infinity提供的正是他们进入这个市场最需要的东西：配套软件。

对于d-Matrix这样的推理芯片公司来说，挑战是双重的：

1. 硬件上：推理芯片可以在某些特定任务中优于GPU（比如高能效比）
2. 软件上：没有成熟CUDA生态的支持，开发者不愿意迁移

Infinity的工作正是解决第二个问题：用AI Agent加速软件栈的构建，把原本可能需要数月的芯片适配工作压缩到数小时或数天。

2.3 10小时的真实含义

需要澄清的是，Infinity用10小时搭建的「类CUDA软件」，并不等于完整的CUDA替代品。

具体来说，Infinity主要攻克的是CUDA的第一层——为特定芯片生成和优化推理Kernel，并围绕这些Kernel搭建底层软件能力。他们正在开发一套面向多种芯片的通用推理库，但这个通用推理库不等于cuDNN的完整功能集，更不等于CUDA生态20年积累的所有库和工具。

用更准确的语言描述：他们在10小时内为d-Matrix的推理芯片生成了一套可用的Kernel适配层，这是进入市场的门槛，但还不是护城河。

三、推理侧：CUDA护城河的真正裂缝

3.1 训练 vs 推理：两种完全不同的市场逻辑

AI计算分成两个截然不同的阶段，理解这两者的差异，是理解「CUDA危机」的关键：

训练（Training）：制造模型的过程

• 规模：需要上万块GPU协同，耗时数周甚至数月
• 硬件：追求极致性能，愿意为稳定性付出溢价
• 切换成本：极高——换芯片意味着重新调试整个训练流程，损失的是数周的生产时间
• 结果：企业在训练侧极度保守，CUDA几乎是唯一选择

推理（Inference）：使用训练好的模型回答问题

• 规模：可以拆分到小集群甚至单卡
• 硬件：追求性价比，每个Token的成本是核心指标
• 切换成本：相对低——如果能跑、够便宜，客户愿意尝试
• 结果：推理侧存在真实的竞争空间

正如d-Matrix首席商务官Marshall Choy所说：「在推理侧，CUDA不再是决定因素。这将是一场开源软件的竞争。」

3.2 为什么推理才是突破口

推理侧有几个关键特征，使得它比训练侧更容易被「绕过」：

第一，推理不需要完整的CUDA生态

训练侧需要复杂的集群协同、通信优化、故障恢复，这些都需要CUDA生态的深度支持。但推理侧的大量场景——比如单卡跑一个Llama模型的推理——只需要基本的Kernel能跑起来就行。

这意味着推理Kernel的适配成本天然低于训练侧，这给AI Agent留下了更大的发挥空间。

第二，推理框架可以跨芯片运行

如果有一个推理框架能够支持多种芯片，用户就可以在不同硬件之间切换，而不需要重写代码。CUDA最大的锁定效应（用CUDA写的代码只能在英伟达GPU上运行）就失效了。

第三，推理成本的压力

每个Token的推理成本是所有AI公司的核心KPI。当AMD MI300X、d-Matrix、AWS Inferentia、谷歌TPU等在某些推理任务中展现出成本优势时，企业就愿意尝试——只要软件能跟上。

3.3 各路玩家的推理布局

正是看准了这个机会，各路芯片厂商和云计算巨头已经在推理市场排兵布阵：

对所有这些玩家来说，软件栈的完善程度直接决定了市场渗透率。Infinity用AI Agent加速这个过程，恰恰是踩在了这个趋势上。

四、验证生态：CUDA最深的护城河

4.1 代码能生成，不等于能用

AI Agent能快速生成大量代码，但验证这些代码在各种边界情况下都算得对、跑得稳，是一个完全不同量级的挑战。

INT21创始人Bing Xu的话非常到位：「AI生成一万行代码很快，但『证明这一万行在各种边界情况下都算得对、跑得稳』极慢。」

CUDA最深的资产恰恰是它的验证工具链：

// 举一个简单的例子：fp16矩阵乘法中的NaN/Inf处理
// CUDA库中的实现会处理：
// 1. 输入溢出 → 自动scale
// 2. 乘积累加溢出 → Kahan加法或分块处理
// 3. 极端值传播 → 显式NaN/Inf检查
// 4. 数值精度稳定性 → 多种算法自适应选择

// 这些边界处理，是20年生产环境反馈的结晶
__global__ void matrixMultiplyOptimized(
    half *C, const half *A, const half *B,
    int M, int N, int K, float alpha, float beta
) {
    // 每一行都需要处理数值溢出、精度损失、并行度优化
    // AI生成的代码可能90%的情况下正确
    // 但生产环境需要的是99.9999%的正确率
}

生成90%正确的代码是80%的工程难度；把10%的边界情况补上，是剩下80%的工程难度。

4.2 Modular的观点：炒作被严重夸大

Modular联合创始人Chris Lattner（LLVM和Swift语言的创始人）对这次「CUDA危机」泼了一盆冷水。他的观点很有分量，因为他是真正在底层编译器领域做过开创性工作的人。

他认为AI Coding Agent的改进是渐进式的，而非颠覆性的，理由有三：

第一，写代码只是软件工程的一小部分

生成GPU Kernel只是芯片适配工作的起点。生产级的性能优化（内存布局、显存访问模式、tensor core调度）需要深入理解硬件微架构，这部分工作AI Agent目前还无法替代资深工程师。

第二，芯片软件是小众精英领域

AI Agent的训练数据主要来自GitHub这样的公开代码库，而芯片底层软件（CUDA Kernel、GPU驱动、编译器优化）大部分不是开源的。AI能学到的只是冰山一角。

第三，几百万行存量代码的迁移成本还在

即使AI Agent能生成新的Kernel，企业已有的、经过生产验证的CUDA代码库不会一夜消失。迁移成本不只是技术问题，更是组织决策问题。

4.3 英伟达自己的AI：护城河在自我加固

一个容易被忽略的细节是：英伟达自己也在用AI Agent开发CUDA。

英伟达开发者生态副总裁Ankit Patel表示：「我们也在使用AI Agent来更快地开发CUDA，并在更大规模上进行验证。」

这意味着什么？

如果连进攻方都在用AI加速自己的迭代速度，那么CUDA的护城河不只是在被挑战——它也在被AI加固。英伟达用AI开发AI软件生态的速度，可能比竞争对手用AI挑战它的速度更快。

Bing Xu的判断很准确：这场仗的胜负，取决于竞争对手追赶英伟达的速度，能否快过英伟达自我迭代的速度。

五、DeepSeek的路径：TileLang与底层软件的新思路

5.1 TileLang：高层抽象的GPU Kernel语言

除了Infinity的Agent路径，另一个值得关注的方向来自DeepSeek的TileKernels项目。DeepSeek选择了另一条路：开发一套名为TileLang的GPU Kernel编程语言，通过高层抽象来减少手写CUDA代码的必要性。

# TileLang示例：声明式矩阵乘法（伪代码风格）
@tile_kernel(tile_size=128)
def matmul(A: Tensor, B: Tensor) -> Tensor:
    # TileLang自动处理：
    # 1. 共享内存分配和管理
    # 2. 线程块布局和调度
    # 3. 显存读写合并（coalesced access）
    # 4. bank conflict避免
    return A @ B

# 编译器生成优化的CUDA/ROCm代码
compiled_kernel = tile_compile(matmul, target="nvidia-a100")

TileLang的思路是：不是替代CUDA，而是让开发者用更高层的语言表达计算意图，由编译器负责生成优化的底层代码。这实际上是在第一层（内核层）和第三层（框架层）之间插入一个新的抽象层。

这条路和MLIR（Multi-Level Intermediate Representation）的思路一脉相承——用分层抽象来处理硬件多样性。Chris Lattner离开谷歌后做的Mojo语言，也是这个方向的探索者。

5.2 两条路径的对比

两条路径并不互斥，未来很可能出现融合：用AI Agent辅助编译器优化，或者用TileLang这样的高层抽象降低AI生成Kernel的难度。

六、程序员视角：这件事对我们意味着什么

6.1 短期影响：AI芯片工程师的需求会变化

对于正在做AI基础设施开发的程序员来说，这件事最直接的影响是：芯片适配工作的方式正在改变。

过去，一个芯片公司需要雇佣大量有CUDA/ROCm经验的工程师，手写Kernel适配代码。这个岗位的人才稀缺、培养周期长，是AI芯片公司最大的软件成本之一。

AI Agent介入后，这个岗位的形态会发生变化：

# 过去的模式：工程师手写
@cuda.jit
def convolution_kernel(input_feature, weight, output_feature):
    # 手动处理共享内存、线程调度
    # 每个新芯片都需要重新实现
    pass

# 现在的模式：AI Agent + 工程师审查
# 1. 工程师给出高层方向（数据布局、算法选择）
# 2. AI Agent生成初始实现
# 3. 工程师审查并手动优化关键路径
# 4. AI Agent根据性能profiling结果迭代

# 未来可能的模式：完全由AI主导
# 工程师转型为"AI Kernel优化师"
# 核心技能从"写Kernel"变成"审查AI生成的Kernel + 识别优化机会"

这不意味着芯片软件工程师会失业——但他们的核心技能需要升级：从「写代码」转向「判断代码质量 + 识别优化方向 + 审查验证」。

6.2 中期影响：推理市场的软件碎片化

推理侧的软件竞争已经开始。从中期来看，推理市场很可能会经历一个「碎片化→标准化→再碎片化」的周期：

碎片化阶段（现在）：各芯片厂商用AI Agent加速软件适配，推理Kernel的选择变多，但缺乏统一标准

标准化阶段：随着行业经验积累，可能会出现类似POSIX的推理软件标准（比如Anthropic提出的推理接口规范），降低跨芯片迁移成本

再碎片化阶段：标准接口确定后，各芯片厂商在标准之上通过硬件特性实现差异化

对于应用开发者来说，这意味着：不要过早绑定在单一推理后端上。保持对不同推理后端的适配能力，会是未来几年的核心竞争力之一。

6.3 长期影响：验证和优化才是护城河

如果你在AI基础设施领域长期发展，有一点值得认真思考：

CUDA的护城河正在从「代码的存量」迁移到「验证和优化的生态」。

代码可以由AI生成，但以下几件事目前仍然高度依赖人类的经验和判断：

1. 性能profiling和瓶颈分析：识别「为什么这个Kernel慢」比「怎么让它变快」更难，AI目前在这方面的能力有限
2. 数值精度验证：确保AI生成的代码在各种输入条件下都能产生数值正确的结果
3. 架构级优化决策：决定数据在芯片间怎么流动、内存层级怎么设计、计算和通信怎么overlap

这三件事，恰好是CUDA护城河向AI芯片进攻者最难突破的地方。谁先在这些领域建立起验证和优化工具，谁就是下一个CUDA生态的构建者。

6.4 程序员的具体行动建议

基于以上分析，以下是我给程序员的几个具体建议：

如果你在AI基础设施领域（编译器、Runtime、推理框架等）：

• 深入理解GPU/AI芯片的硬件微架构：内存层级、计算单元特性、带宽延迟比
• 学习profiling和性能分析工具：Nsight、Roofline Model、kernel profiling
• 关注AI推理框架的多后端支持能力：TensorRT、vLLM、TGI等在不同硬件上的性能特性
• 考虑学习TileLang、MLIR等高层抽象工具，提前布局下一代开发范式

如果你在应用开发领域（用AI编程工具开发业务代码）：

• 这件事对你的直接影响有限，但间接影响值得关注
• 未来你可能会发现：同一个AI应用，背后可以在不同推理后端之间无缝切换
• 选型时多关注推理后端的开放程度和跨平台能力

如果你对AI编程Agent感兴趣：

• 关注Ignition这类专用AI Agent的发展：它们展示了AI在「有明确反馈循环」的工程任务中的真实能力
• 不要神化它，也不要轻视它：理解它的适用边界比了解它的能力上限更重要

七、总结：护城河安然，但战场已变

回到最初的问题：AI编程Agent在10小时内搭建的「类CUDA软件」，到底意味着什么？

我的判断是：

第一，短期内CUDA的护城河安然无恙。

CUDA的护城河不只是代码——它是cuBLAS/cuDNN二十年的手工优化、是几百万行经过生产验证的存量代码、是Nsight系列调试分析工具的完整生态、是数百万开发者积累的经验和习惯。这些都不会在10小时内被颠覆。

第二，变化会先在推理侧悄悄发生。

训练侧的企业会因为切换成本过高而继续保守，但推理侧的竞争已经真实开始了。AI Agent在这个战场上确实在加速软件适配，d-Matrix、Rebellions、AMD这些英伟达的挑战者，正在用更短的时间弥补与CUDA生态的差距。

第三，验证生态是下一道护城河。

当AI Agent能在10小时内生成大量Kernel代码时，验证这些代码的生产可用性就成为最稀缺的能力。英伟达在验证工具链上的积累，是它最深的护城河——也是AI芯片挑战者最难跨越的鸿沟。

第四，程序员的机遇在「判断层」而非「执行层」。

AI在「生成」层面的能力在快速提升，但「判断质量」「识别优化方向」「验证正确性」这些能力，在未来几年内仍然高度依赖人类工程师。这意味着：理解硬件、理解算法、理解系统的工程师，会比纯粹写代码的工程师更值钱。

参考来源：

• 量子位：《老黄垒20年的CUDA护城河，AI刚刚用10小时凿开了》（2026-08-05）
• Business Insider: "Nvidia's CUDA Faces New Threats From AI Coding Agents"（2026-08）
• PrimeIntellect-ai/prime-agent GitHub Release v0.6.1（2026-08-08）
• DeepSeek TileKernels/TileLang 项目（2026年）
• Modular官方博客（2026年）
• d-Matrix 官方技术白皮书（2026年）