英伟达刚刚从DeepSeek-R1引发的4万亿元暴跌中缓过劲来，又面临新的压力？



硬件媒体Tom‘s Hardware带来开年最新热议：

DeepSeek甚至绕过了CUDA，使用更底层的编程语言做优化。



这一次是DeepSeek-V3论文中的更多细节，被人挖掘出来。

来自Mirae Asset Securities Research（韩国未来资产证券）的分析称，V3的硬件效率之所以能比Meta等高出10倍，可以总结为“他们从头开始重建了一切”。

在使用英伟达的H800 GPU训练DeepSeek-V3时，他们针对自己的需求把132个流式多处理器（SMs）中的20个修改成负责服务器间的通信，而不是计算任务。

变相绕过了硬件对通信速度的限制。



△ DeepSeek-V3 Technical Report

这种操作是用英伟达的PTX（Parallel Thread Execution）语言实现的，而不是CUDA。

PTX在接近汇编语言的层级运行，允许进行细粒度的优化，如寄存器分配和Thread/Warp级别的调整。

这种编程非常复杂且难以维护，所以行业通用的做法是使用CUDA这样的高级编程语言。

换句话说，他们把优化做到了极致。

有网友表示，如果有一群人嫌CUDA太慢而使用PTX，那一定是前量化交易员。



一位亚马逊工程师提出灵魂质问：CUDA是否还是护城河？这种顶尖实验室可以有效利用任何GPU。



甚至有网友开始畅想，如果“新源神”DeepSeek开源了一个CUDA替代方案……



那么事情是否真会如此？

DeepSeek真的绕过了CUDA？首先要明确的是，PTX仍然是英伟达GPU架构中的技术，它是CUDA编程模型中的中间表示，用于连接CUDA高级语言代码和GPU底层硬件指令。

PTX类似汇编语言，代码大概长这样：



△来自tinkerd.net

在实际编译流程中，CUDA代码首先被编译为PTX代码，PTX代码再被编译为目标GPU架构的机器码（SASS,Streaming ASSembler）。

CUDA起到了提供高级编程接口和工具链的作用，可以简化开发者的工作。而PTX作为中间层，充当高级语言和底层硬件之间的桥梁。

另外，这种两步编译流程也使得CUDA程序具有跨架构的兼容性和可移植性。

反过来说，像DeepSeek这种直接编写PTX代码的做法，首先不仅非常复杂，也很难移植到不同型号的GPU。

有从业者表示，针对H100优化的代码迁移到其他型号上可能效果打折扣，也可能根本不工作了。



所以说，DeepSeek做了PTX级别的优化不意味着完全脱离了CUDA生态，但确实代表他们有优化其他GPU的能力。

事实上，我们也能看到DeekSeek已经与AMD、华为等团队紧密合作，第一时间提供了对其他硬件生态的支持。



One More Thing还有人提出，如此一来，让AI擅长编写汇编语言是AI自我改进的一个方向。



我们不知道DeepSeek内部是否使用AI辅助编写了PTX代码——

但是确实刚刚见证DeepSeek-R1编写的代码显著提升大模型推理框架的运行速度。

Llama.cpp项目中的一个新PR请求，使用SIMD指令（允许一条指令同时处理多个数据）显著提升WebAssembly在特定点积函数上的运行速度，提交者表示：

这个PR中的99%的代码都是由DeekSeek-R1编写的。我唯一做的就是开发测试和编写提示（经过一些尝试和错误）。

是的，这个PR旨在证明大模型现在能够编写良好的底层代码，甚至能够优化自己的代码。



llama.cpp项目的创始人检查了这段代码后表示“比预期的更爆炸”。



DeepSeek绕开CUDA垄断，V3论文细节再挖出！英伟达护城河不存在了

【新智元导读】DeepSeek模型开发竟绕过了CUDA？最新爆料称，DeepSeek团队走了一条不寻常的路——针对英伟达GPU低级汇编语言PTX进行优化实现最大性能。业界人士纷纷表示，CUDA护城河不存在了？

原本DeepSeek低成本训出的R1，就已经让整个硅谷和华尔街为之虎躯一震。

而现在又曝出，打造这款超级AI，竟连CUDA也不需要了？

根据外媒的报道，他们在短短两个月时间，在2,048个H800 GPU集群上，训出6710亿参数的MoE语言模型，比顶尖AI效率高出10倍。

这项突破不是用CUDA实现的，而是通过大量细粒度优化以及使用英伟达的类汇编级别的PTX（并行线程执行）编程。





这则消息一出，再次掀翻AI圈，网友对其策略纷纷表示震惊：

「在这个世界上，如果有哪群人会疯狂到说出『CUDA太慢了！干脆直接写PTX吧！』这种话，绝对就是那些前量化交易员了。」









左右滑动查看

还有人表示，如果DeepSeek开源了CUDA替代品，这将意味着什么？



天才极客微调PTX，让GPU性能极致发挥

英伟达PTX（并行线程执行）是专门为其GPU设计的中间指令集架构，位于高级GPU编程语言（如CUDA C/C++或其他语言前端）和低级机器代码（流处理汇编或SASS）之间。

PTX是一种接近底层的指令集架构，将GPU呈现为数据并行计算设备，因此能够实现寄存器分配、线程/线程束级别调整等细粒度优化，这些是CUDA C/C++等语言无法实现的。

当PTX转换为SASS后，就会针对特定代的英伟达GPU进行优化。



在训练V3模型时，DeepSeek对英伟达H800 GPU进行了重新配置：

在132个流处理器多核中，划分出20个用于服务器间通信，主要用于数据压缩和解压缩，以突破处理器的连接限制、提升事务处理速度。

为了最大化性能，DeepSeek还通过额外的细粒度线程/线程束级别调整，实现了先进的流水线算法。

这些优化远超常规CUDA开发水平，但维护难度极高。然而，这种级别的优化恰恰充分展现DeepSeek团队的卓越技术实力。



V3论文中具体提到了关于PTX的细节

这是因为，在全球GPU短缺和美国限制的双重压力下，DeepSeek等公司不得不寻求创新解决方案。

所幸的是，他们在这方面取得了重大突破。

有开发者认为，「底层GPU编程才是正确的方向。优化得越多，就越能降低成本，或在不增加额外支出的情况下，提高可用于其他方面进步的性能预算」。



这一突破对市场造成了显著冲击，部分投资者认为新模型对高性能硬件的需求将会降低，可能会影响英伟达等公司的销售业绩。

然而，包括英特尔前掌门人Pat Gelsinger等在内的行业资深人士认为，AI应用能够充分利用一切可用的计算能力。

对于DeepSeek的这一突破，Gelsinger将其视为在大众市场中，为各类低成本设备植入AI能力的新途径。



CUDA护城河，也不存在了？

那么，DeepSeek的出现是否意味着前沿LLM的开发，不再需要大规模GPU集群？

谷歌、OpenAI、Meta和xAI在计算资源上的巨额投资是否最终将付诸东流？AI开发者们的普遍共识并非如此。

不过可以确定的是，在数据处理和算法优化方面仍有巨大潜力可以挖掘，未来必将涌现出更多创新的优化方法。

随着DeepSeek的V3模型开源，其技术报告中详细披露了相关细节。

该报告记录了DeepSeek进行的深度底层优化。简而言之，其优化程度可以概括为「他们从底层重新构建了整个系统」。

如上所述，在使用H800 GPU训练V3时，DeepSeek对GPU核心计算单元（流处理器多核，简称SM）进行了定制化改造以满足特定需求。



在全部132个SM中，他们专门划分出20个用于处理服务器间通信任务，而非计算任务。

这种定制化工作是在PTX（并行线程执行）层面进行的，这是英伟达GPU的低级指令集。

PTX运行在接近汇编语言的层面，能够实现寄存器分配和线程/线程束级别调整等细粒度优化。然而，这种精细的控制既复杂又难以维护。

这也是为什么开发者通常会选择使用CUDA这类高级编程语言，因为它们能为大多数并行编程任务提供充分的性能优化，无需进行底层优化。

但是，当需要将GPU资源效能发挥到极致并实现特殊优化需求时，开发者就不得不求助于PTX。

虽然但是，技术壁垒依然还在

对此 ，网友Ian Cutress表示：「Deepseek对于PTX的使用，并不会消除CUDA的技术壁垒。」



CUDA是一种高级语言。它使代码库的开发和与英伟达GPU的接口变得更简单，同时还支持快速迭代开发。

CUDA可以通过微调底层代码（即PTX）来优化性能，而且基础库都已经完备。目前绝大多数生产级的软件都是基于CUDA构建的。

PTX更类似于可以直接理解的GPU汇编语言。它工作在底层，允许进行微观层面的优化。

如果选择使用PTX编程，就意味着上文提到的那些已经建好的CUDA库，都不能用了。这是一项极其繁琐的任务，需要对硬件和运行问题有深厚的专业知识。

但如果开发者充分了解自己在做什么，确实可以在运行时获得更好的性能和优化效果。



目前，英伟达生态的主流，仍然是使用CUDA。

那些希望从计算负载中提升额外10-20%性能或功耗效率的开发者，比如在云端部署模型并销售token服务的企业，确实都已经将优化从CUDA层面深入到了PTX层面。他们愿意投入时间是因为，从长远来看这种投入是值得的。

需要注意的是，PTX通常是针对特定硬件型号优化的，除非专门编写适配逻辑，否则很难在不同硬件间移植。

除此之外，手动调优计算内核也需要极大的毅力、勇气，还得有保持冷静的特殊能力，因为程序可能每运行5000个周期就会出现一次内存访问错误。

当然，对于确实需要使用PTX的场景，以及那些收到足够报酬来处理这些问题的开发者，我们表示充分的理解和尊重。

至于其他开发者，继续使用CUDA或其他基于CUDA的高级变体（或MLIR）才是明智的选择。