华为应该轻易就做出
搞不好华为已经做了
那天习帝会见企业家结束后，任正非估计和梁文峰私下喝酒去了，啼啼啼
完了，deepseek把GPU上的fp8的汇编代码开源了。
版主： Softfist
#41 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
搞不好华为已经做了
那天习帝会见企业家结束后，任正非估计和梁文峰私下喝酒去了，啼啼啼
你帝，我帝，他帝，谁的帝？
#42 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
我老早就说过，人工智能就是暴力计算勾股定理，只不过勾股定理是二维的，AI算的维度更高一些罢了，原理都是一样的。
在多维空间中算两个点的距离，不就是勾股定理的推广么。
在多维空间中算两个点的距离，不就是勾股定理的推广么。
#43 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
想起日本新干线开通时的一个评价：这反映出一个国家对效率的追求能达到怎样的一个地步。
mlforlife 写了： 2025年 2月 25日 23:16 好样的，让所有质疑闭嘴。
让美帝这帮草包三哥马内鸡看看，真正硬核的东西是什么样子，没有PPT，没有stand up， 就是刻苦的工作，就是智慧的光芒。
300行代码拍你脸上，自己领悟去吧。
#46 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
例如，cpu上的虚拟机，Basic,python,lua,luajit,java...
这个是GPU上的虚拟机，这个JIT他有一套自己的‘虚拟指令’，这些‘虚拟指令’背后，是一组GPU/NPU/CPU的硬件指令，各家的xPU的硬件指令只要实现了JIT的虚拟指令，用谁的xPU都没区别。
就像Basic,python,lua,luajit,java...在arm、龙芯指令集上照样跑一样。
#48 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
别扯了，现在各种pu哪有不支持jit的。
这个代码开源的核心是GEMM的汇编kernel。速度是nv官方CUTLASS的一到两倍。
也就说，可以少买一半GPU来干相同的事。
但这个只能支持hopper GPU，显然没有官方的兼容性好。
但是，我解读，这个对nv是利好，因为ptx只有nv支持。
其他家不可能去支持nv的ptx，这个跟英特尔的指令集一个道理。你优化不过它，而且人家想怎么改怎么改。
别忘了这个连a100都不支持。
这个代码开源的核心是GEMM的汇编kernel。速度是nv官方CUTLASS的一到两倍。
也就说，可以少买一半GPU来干相同的事。
但这个只能支持hopper GPU，显然没有官方的兼容性好。
但是，我解读，这个对nv是利好，因为ptx只有nv支持。
其他家不可能去支持nv的ptx，这个跟英特尔的指令集一个道理。你优化不过它，而且人家想怎么改怎么改。
别忘了这个连a100都不支持。
x1
#49 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
Xai的解读
DeepSeek's FP8 GEMM (General Matrix Multiplication) implementation, as showcased in their DeepGEMM library, has sparked some buzz for its reported performance, particularly when compared to NVIDIA's native APIs like cuBLAS. Based on what’s out there, here’s my take.
DeepGEMM is designed to squeeze every ounce of efficiency out of NVIDIA’s Hopper GPUs (like the H800), hitting over 1350 TFLOPS in FP8 precision under ideal conditions. That’s impressive when you consider NVIDIA’s cuBLAS, a go-to for matrix operations, is estimated to deliver around 1500 TFLOPS on an H800 for certain matrix sizes—though this scales up to 3000 TFLOPS on an H100, which DeepSeek likely didn’t use due to export restrictions. Posts on X and details from DeepSeek’s own releases suggest their library can outperform “expert-tuned kernels” (which could imply cuBLAS or similar) across a range of matrix sizes, sometimes by a significant margin—think up to 2.7x faster in extreme cases, as one X user noted.
What’s the trick? DeepGEMM uses a lightweight, just-in-time (JIT) compilation approach, keeping the core logic lean at around 300 lines of code. It leans hard into fine-grained scaling and custom optimizations, like two-level accumulation (using Tensor Cores for FP8 math and CUDA cores for higher-precision summing), to dodge the precision pitfalls of FP8. NVIDIA’s native APIs, while robust and general-purpose, don’t seem to match this level of specialization. DeepSeek’s focus on Mixture-of-Experts (MoE) layouts and their ability to tweak low-level instructions (even dabbling in PTX assembly) likely gives them an edge in tailored workloads—think AI training and inference for models like V3 and R1.
That said, it’s not a slam dunk. NVIDIA’s APIs are built for broad compatibility and reliability across diverse use cases, not just AI-specific GEMMs. DeepGEMM’s gains might shine brightest in DeepSeek’s own sandbox—optimized for their models and hardware constraints (like the H800’s nerfed bandwidth). Without head-to-head benchmarks on identical setups, claims of it being “much faster” feel anecdotal. The 1350+ TFLOPS figure is stellar, but cuBLAS could still edge out in raw peak performance on bigger matrices or less-specialized tasks. Plus, DeepSeek’s reliance on Hopper-specific Tensor Cores means it’s not a universal drop-in replacement.
So, is it “much faster”? Probably yes for DeepSeek’s niche—AI-driven, FP8-heavy, MoE-focused workloads on constrained hardware. For the average user leaning on NVIDIA’s stack? Maybe not as dramatic. It’s a testament to clever engineering over brute force, but the jury’s still out until someone runs the numbers side-by-side. What do you think—seen any solid comparisons?
DeepSeek's FP8 GEMM (General Matrix Multiplication) implementation, as showcased in their DeepGEMM library, has sparked some buzz for its reported performance, particularly when compared to NVIDIA's native APIs like cuBLAS. Based on what’s out there, here’s my take.
DeepGEMM is designed to squeeze every ounce of efficiency out of NVIDIA’s Hopper GPUs (like the H800), hitting over 1350 TFLOPS in FP8 precision under ideal conditions. That’s impressive when you consider NVIDIA’s cuBLAS, a go-to for matrix operations, is estimated to deliver around 1500 TFLOPS on an H800 for certain matrix sizes—though this scales up to 3000 TFLOPS on an H100, which DeepSeek likely didn’t use due to export restrictions. Posts on X and details from DeepSeek’s own releases suggest their library can outperform “expert-tuned kernels” (which could imply cuBLAS or similar) across a range of matrix sizes, sometimes by a significant margin—think up to 2.7x faster in extreme cases, as one X user noted.
What’s the trick? DeepGEMM uses a lightweight, just-in-time (JIT) compilation approach, keeping the core logic lean at around 300 lines of code. It leans hard into fine-grained scaling and custom optimizations, like two-level accumulation (using Tensor Cores for FP8 math and CUDA cores for higher-precision summing), to dodge the precision pitfalls of FP8. NVIDIA’s native APIs, while robust and general-purpose, don’t seem to match this level of specialization. DeepSeek’s focus on Mixture-of-Experts (MoE) layouts and their ability to tweak low-level instructions (even dabbling in PTX assembly) likely gives them an edge in tailored workloads—think AI training and inference for models like V3 and R1.
That said, it’s not a slam dunk. NVIDIA’s APIs are built for broad compatibility and reliability across diverse use cases, not just AI-specific GEMMs. DeepGEMM’s gains might shine brightest in DeepSeek’s own sandbox—optimized for their models and hardware constraints (like the H800’s nerfed bandwidth). Without head-to-head benchmarks on identical setups, claims of it being “much faster” feel anecdotal. The 1350+ TFLOPS figure is stellar, but cuBLAS could still edge out in raw peak performance on bigger matrices or less-specialized tasks. Plus, DeepSeek’s reliance on Hopper-specific Tensor Cores means it’s not a universal drop-in replacement.
So, is it “much faster”? Probably yes for DeepSeek’s niche—AI-driven, FP8-heavy, MoE-focused workloads on constrained hardware. For the average user leaning on NVIDIA’s stack? Maybe not as dramatic. It’s a testament to clever engineering over brute force, but the jury’s still out until someone runs the numbers side-by-side. What do you think—seen any solid comparisons?
x1
#50 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
理论上，速度提升四倍才对sjtu 写了： 2025年 2月 26日 00:48 别扯了，现在各种pu哪有不支持jit的。
这个代码开源的核心是GEMM的汇编kernel。速度是nv官方CUTLASS的一到两倍。
也就说，可以少买一半GPU来干相同的事。
但这个只能支持hopper GPU，显然没有官方的兼容性好。
但是，我解读，这个对nv是利好，因为ptx只有nv支持。
其他家不可能去支持nv的ptx，这个跟英特尔的指令集一个道理。你优化不过它，而且人家想怎么改怎么改。
别忘了这个连a100都不支持。
#53 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
其实可以算两个成果 一个是针对ai运算优化的虚拟机 一个是对接芯片的底层实现案例 两者结合跑起来性能还挺好
各个芯片厂搞个几周应该就可以照猫画虎 跑起来 这下就形成一个新的产业生态的
#54 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
重要的是，众生平等了，无数小公司都能训练自己的、专用的、‘专家大模型’了，drifter 写了： 2025年 2月 26日 02:17 其实可以算两个成果 一个是针对ai运算优化的虚拟机 一个是对接芯片的底层实现案例 两者结合跑起来性能还挺好
各个芯片厂搞个几周应该就可以照猫画虎 跑起来 这下就形成一个新的产业生态的
这可是各行各业，你都不敢想象，‘人工弱智的训练与使用’的普及，恐怕比互联网的普及更有冲击力。
x1
#55 Re: 完了，deepseek把GPU上的fp8的汇编代码开源了。
感觉主要是提供了一种思路，硬件公司Nvidia的软件部门太烂，有大量的空间可以优化
老黄现在应该做的是，赶紧对新的blackwell芯片做指令优化，或者把blackwell的指令做加密，不准别人优化
老黄现在应该做的是，赶紧对新的blackwell芯片做指令优化，或者把blackwell的指令做加密，不准别人优化
