DeepSeek用PTX编程，隐忧乎？无忧乎？
DeepSeek用英伟达H20卡训练V3和R1大模型，但据说没有用英伟达的CUDA语言，而是用了更加底层的PTX。CUDA是英伟达的护城河。搞人工智能就要用英伟达的图形卡，跑英伟达的卡就需要CUDA。一旦形成生态就反过来了，搞人工智能就用CUDA写软件，跑CUDA就只有用英伟达的卡。
但DeepSeek用接近汇编语言的PTX编写软件，绕过了CUDA护城河，也因为PTX更加接近机器语言而更快。据说这是DeepSeek里老人马当年搞量化交易的“后遗症”，需要计算机和通信上达到极限性能，只有用接近汇编语言的“低级语言”来编写程序，比如PTX。
汇编接近机器指令，速度快，但远离自然语言，语句功能专一、琐碎，编写麻烦，可移植性很差，换一个GPU就需要重写。高级语言的发明就是为了解决接近自然语言和软件在不同平台之间的可移植性的问题的，但执行效率不及汇编。
接近自然语言很重要，这样更人类思维，编程和阅读容易，纠错也容易。跨计算机平台的可移植性也很重要，不仅更新更快的芯片出来了，重新编译一下又可以执行，换上完全“不同路子”的计算机也能执行，比如WinTel换到Unix或者iOS环境下。但编译出来的执行时效率不及汇编。
DeepSeek绕过了CUDA，但通用大模型要是“绑定”在H20卡上，那就亏了，换卡就要重新编写和测试一遍。
好在大模型的一大神迹就是按照自然语言的要求写程序。换到这里，只是直接写到PTX一级。这个问题解决了，可移植性比CUDA还好，直接用更加接近自然语言的伪码了。
即使以后不用PTX了，也就是重新训练大模型改用新语言的事。换句话说，大模型代替高级语言的工作了。
看来，没有隐忧。
应该是用的H800，不是H20 WiFi 发表于 2025-2-3 11:15
应该是用的H800，不是H20
两个说法都看到过，我都糊涂了。哪一个更弱？ 晨枫 发表于 2025-2-4 01:35
两个说法都看到过，我都糊涂了。哪一个更弱？
Nvidia's H800 was launched in March 2023 and is a cut-down version of the H100.
The H20 is expected to be available for important clients in early 2024, with a wider release in the second quarter
H20比H800新一代。应该更好一些。 相比于绕开cuda的突破，其实ds自己设计的Fire-Flyer AI-HPC框架，更值得自豪。
在训练的尝试中有意绕开了多卡之间必须依赖的nvlink的瓶颈，而这个其实是老黄在硬件底层的护城河，更深也更黑。 xiejin77 发表于 2025-2-4 23:58
相比于绕开cuda的突破，其实ds自己设计的Fire-Flyer AI-HPC框架，更值得自豪。
在训练的尝试中有意绕开了 ...
这个能展开说说吗？ 晨枫 发表于 2025-2-5 14:13
这个能展开说说吗？
ds自己有篇论文，我找时间专门解读一下吧 xiejin77 发表于 2025-2-5 00:21
ds自己有篇论文，我找时间专门解读一下吧
多谢。恭候。
DS倒是真开放哈。 WiFi 发表于 2025-2-4 01:15
应该是用的H800，不是H20
晨大的这个说法，我查了一下资料和信源，正好我之前写过ds-v3的解读。感觉可能是有点偏差。
Parallel thread execution就是PTX。这是一种底层的N卡指令集架构的中间语言，cuda也用ptx，在这一点上确实是类似asm。
但根据ds自己的论文看，他们用ptx不是为了绕过cuda，而是为了优化效率：
In detail, we employ the warp specialization technique (Bauer et al., 2014) and partition
20 SMs into 10 communication channels. During the dispatching process, (1) IB sending, (2)
IB-to-NVLink forwarding, and (3) NVLink receiving are handled by respective warps. The
number of warps allocated to each communication task is dynamically adjusted according to the
actual workload across all SMs. Similarly, during the combining process, (1) NVLink sending,
(2) NVLink-to-IB forwarding and accumulation, and (3) IB receiving and accumulation are also
handled by dynamically adjusted warps. In addition, both dispatching and combining kernels
overlap with the computation stream, so we also consider their impact on other SM computation
kernels. Specifically, we employ customized PTX (Parallel Thread Execution) instructions and
auto-tune the communication chunk size, which significantly reduces the use of the L2 cache
and the interference to other SMs.
理论上说基于ptx的话，N卡可用，华为的910c是不能用的。所以不存在通用性的可能，更像是ds的团队逢山开路遇水架桥的给cuda打补丁。
xiejin77 发表于 2025-2-5 15:08
晨大的这个说法，我查了一下资料和信源，正好我之前写过ds-v3的解读。感觉可能是有点偏差。
Parallel th ...
同意谢总的分析 xiejin77 发表于 2025-2-5 01:08
晨大的这个说法，我查了一下资料和信源，正好我之前写过ds-v3的解读。感觉可能是有点偏差。
Parallel th ...
PTX是不是本来就chip specific？有可能利用大模型反过来把PTX写的东西反过来生成伪码，再针对新芯片的相当于PTX的指令集生成新的软件？这可能丧失了直接用PTX的优化作用，但重获了CUDA的可移植性？ 晨枫 发表于 2025-2-6 02:13
PTX是不是本来就chip specific？有可能利用大模型反过来把PTX写的东西反过来生成伪码，再针对新芯片的相 ...
晨大好。
我的理解，类asm的语言都是和硬件架构和芯片的指令集深度绑定的。
您这思路，理论上可行，但是就像用谷歌翻译来回古文一样，偏差会大到不忍卒读。
其实ds并没有想绕开cuda，他的V3版本都是在N卡的体系里做的。
要知道，老黄的护城河可不仅仅是cuda生态和ptx，nvlink和IB网络框架才是最底层的壁垒。顺便说一句，DS嫌nvlink的故障率太多，边用边吐槽，还整了一套新架构出来。不过多机多卡的大集群，IB网络近期很有可能是绕不开的，最多就是减少带宽消耗而已。 xiejin77 发表于 2025-2-5 18:42
晨大好。
我的理解，类asm的语言都是和硬件架构和芯片的指令集深度绑定的。
多谢解释。那DS为什么不直接用CUDA，还要费事用PTX呢？ 晨枫 发表于 2025-2-6 08:50
多谢解释。那DS为什么不直接用CUDA，还要费事用PTX呢？
在论文里，这是第3.2.2节的内容
3.2.2. Efficient Implementation of Cross-Node All-to-All Communication
In order to ensure sufficient computational performance for DualPipe, we customize efficient
cross-node all-to-all communication kernels (including dispatching and combining) to conserve
the number of SMs dedicated to communication. The implementation of the kernels is codesigned with the MoE gating algorithm and the network topology of our cluster. To be specific,
in our cluster, cross-node GPUs are fully interconnected with IB, and intra-node communications
are handled via NVLink. NVLink offers a bandwidth of 160 GB/s, roughly 3.2 times that of IB
(50 GB/s). To effectively leverage the different bandwidths of IB and NVLink, we limit each
token to be dispatched to at most 4 nodes, thereby reducing IB traffic. For each token, when its
routing decision is made, it will first be transmitted via IB to the GPUs with the same in-node
index on its target nodes. Once it reaches the target nodes, we will endeavor to ensure that it is
instantaneously forwarded via NVLink to specific GPUs that host their target experts, without
being blocked by subsequently arriving tokens. In this way, communications via IB and NVLink
are fully overlapped, and each token can efficiently select an average of 3.2 experts per node
without incurring additional overhead from NVLink. This implies that, although DeepSeek-V3
13
selects only 8 routed experts in practice, it can scale up this number to a maximum of 13 experts
(4 nodes × 3.2 experts/node) while preserving the same communication cost. Overall, under
such a communication strategy, only 20 SMs are sufficient to fully utilize the bandwidths of IB
and NVLink.
In detail, we employ the warp specialization technique (Bauer et al., 2014) and partition
20 SMs into 10 communication channels. During the dispatching process, (1) IB sending, (2)
IB-to-NVLink forwarding, and (3) NVLink receiving are handled by respective warps. The
number of warps allocated to each communication task is dynamically adjusted according to the
actual workload across all SMs. Similarly, during the combining process, (1) NVLink sending,
(2) NVLink-to-IB forwarding and accumulation, and (3) IB receiving and accumulation are also
handled by dynamically adjusted warps. In addition, both dispatching and combining kernels
overlap with the computation stream, so we also consider their impact on other SM computation
kernels. Specifically, we employ customized PTX (Parallel Thread Execution) instructions and
auto-tune the communication chunk size, which significantly reduces the use of the L2 cache
and the interference to other SMs.
通俗一点说，就是为了实现高效的跨节点全面通信。解决的问题本质上和唐家山老师日志里说的双机对拷的场景差不多。一般来说单机多卡之间用nvlink，多机多卡之间依赖IB网络，但nvlink的速率是IB网络的速率的3.2倍，需要通过一些优化来实现更好的传输策略。这是一整套方案。
我的理解，使用PTX在其中，是为了更精准的定制线程执行减少通信块分配传输之间的串扰。
目的不是为了绕cuda，反而是为了让cuda的效率更高。
类比一下，就好比发现网卡驱动在对拷特定内存块的时候会和应用的线程执行出现串行导致效率降低，而绕开操作系统定义的与网卡驱动的接口，直接使用网卡支持的指令集进行了优化。 本帖最后由 唐家山 于 2025-2-6 09:53 编辑
晨枫 发表于 2025-2-6 08:50
多谢解释。那DS为什么不直接用CUDA，还要费事用PTX呢？
应该是性能的原因。打个比方吧，操作系统内核一般都是用C语言写的，但是一些关键部分会用汇编语言来写。原因就是汇编语言的代码（指令）比C语言编译后的代码（指令）的性能要高。 唐家山 发表于 2025-2-5 19:51
应该是性能的原因。打个比方吧，操作系统内核一般都是用C语言写的，但是一些关键部分会用汇编语言来写。 ...
多谢解释。
那DS如果把模型移植到华为芯片，应该需要重写软件吧？而且无法从原有的CUDA架构下移植？ 本帖最后由 xiejin77 于 2025-2-6 10:01 编辑
晨枫 发表于 2025-2-6 09:53
多谢解释。
那DS如果把模型移植到华为芯片，应该需要重写软件吧？而且无法从原有的CUDA架构下移植？ ...
这部分是DS用来做模型训练、推理的辅助工具软件使用的底层驱动，理论上说，效率可以接受的情况下是不需要做移植。cuda和华为cann工具链生态的顶层封装其实很像，真正需要适配的是这一部分。
华为自己好像发过新闻，ds的670B版本可以在910c的集群上用，但性能只有60%。
大模型的生态产业链其实挺长的，从芯片、数据，算力底座，网络等等等等。甚至连某些小众的领域都可能成为大模型生态链的瓶颈，比如支持rdma的全速网卡和超越IB网络的路由器。这一方面国内还有很长的路要走，很多的坑要踩…… 本帖最后由 唐家山 于 2025-2-7 09:02 编辑
晨枫 发表于 2025-2-6 09:53
多谢解释。
那DS如果把模型移植到华为芯片，应该需要重写软件吧？而且无法从原有的CUDA架构下移植？ ...
确实需要重写。不过重写软件的代价并不像外界想象的那么高。显卡（计算卡）的硬件架构比较简单，上面用的指令集基本上都是相同或类似的。从CUDA架构移植也不麻烦。真正麻烦的地方，是经常会有一些隐藏的bug需要fix。
更正：刚才查了一下。各个厂家的GPU指令集在架构设计、编程模型上差别还是挺大的，不能直接移植。这是我想当然了。另外，早期的显卡上的操作比较简单，现在的显卡（计算卡）的操作已经相当复杂了。以后还得学习之后再发言，否则就闹笑话了。 xiejin77 发表于 2025-2-5 19:58
这部分是DS用来做模型训练、推理的辅助工具软件使用的底层驱动，理论上说，效率可以接受的情况下是不需要 ...
嗯，不大懂，看来way over my head了，就不去勉强搞懂了。
多谢解释。 唐家山 发表于 2025-2-5 19:59
确实需要重写。不过重写软件的代价并不像外界想象的那么高。显卡（计算卡）的硬件架构比较简单，上面用的 ...
多谢解释。
我用过的语言不多，除了常用的科学计算语言，工控语言用的比较多，各厂家之间基本上无法移植，还不只是语句上的差别，有些架构上就不一样。但看来图形卡的专用语言没有那么不同。
页:
[1]
2