I'd also note that you can more or less write the same code in PyTorch with torch.vmap
HN user
chillee
horace.io / twitter.com/cHHillee
this is almost certainly not being done on cerebras
I think unlike Gluon/CuTe/ThunderKittens (which distinguish themselves from Triton by being lower level giving you more control, thus being less performance portable and harder to write), Helion distinguishes itself from Triton by being higher level and easier to write.
IMO, this is something that makes sense for PyTorch to release, as "neutral ground" in the industry.
What's the point of Triton compared to Gluon? What's the point of PyTorch compared to Triton?
One of the main values of Triton is that it significantly expanded the scope of folks who can write kernels - I think Helion could expand the scope even more.
If you think of Triton as a "baseline", most other DSLs are lower-level than Triton, whereas this is higher-level.
Their gross profits are very high even though they're not making operating profit.
Clearly not true anymore given OpenAI and Anthropic's revenue growth.
The 32 parallel sequences is also arbitrary and significantly changes your conclusions. For example, if they run with 256 parallel sequences then that would result in a 8x cheaper factor in your calculations for both prefill and decode.
The component about requiring long context lengths to be compute-bound for attention is also quite misleading.
No. In some sense, the article comes to the right conclusion haha. But it's probably >100x off on its central premise about output tokens costing more than input.
This article's math is wrong on many fundamental levels. One of the most obvious ones is that prefill is nowhere near bandwidth bound.
If you compute out the MFU the author gets it's 1.44 million input tokens per second * 37 billion active params * 2 (FMA) / 8 [GPUs per instance] = 13 Petaflops per second. That's approximately 7x absolutely peak FLOPS on the hardware. Obviously, that's impossible.
There's many other issues with this article, such as assuming only 32 concurrent requests(?), only 8 GPUs per instance as opposed to the more efficient/standard prefill-decode disagg setups, assuming that attention computation is the main thing that makes models compute-bound, etc. It's a bit of an indictment of HN's understanding of LLMs that most people are bringing up issues with the article that aren't any of the fundamental misunderstandings here.
I mean, vllm and sglang are both "pure python" essentially as well. But yeah, in ML you rarely require C++ to get good performance for most of the systems people are writing.
A couple things:
1. The academy has had a significant increase of young voters in the past 10 years or so. Generally speaking, young voters are more likely to take animation as a "serious" medium.
2. These interviews were always somewhat overstated. Of course some voters have stupid rationales, but I don't think this dominates the academy.
3. Disney's Inside Out 2 was nowhere close to winning the award this year - Flow's biggest competition was The Wild Robot, which did gross far more than Inside Out 2, but far below Inside Out 2.
If you look at the past couple years, The Boy and the Heron (Studio Ghibli) won over Across the Spider-Verse (with Pixar's movie Elemental nowhere close) in 2023, Guillermo del Toro's Pinocchio won over Across the Spider-Verse (with Pixar's movie Turning Red nowhere close) in 2022, etc.
I'm curious what year you're thinking about above. Perhaps Toy Story 4 over Klaus in 2019?
https://www.theinformation.com/articles/to-reduce-ai-costs-g...
Which takes it from
Broadcom generates a 70% profit margin from its work on TPUs, said a person with direct knowledge of the internal analysis. SemiAnalysis, a chip research firm, earlier reported that figure.
https://semianalysis.com/2023/08/30/broadcoms-google-tpu-rev...
One of the big things this article misses is that Google pays Broadcom a significant amount for the actual chip design, also around a 70% margin.
Google certainly has infra/cost advantages, but it's nowhere near 10x.
For latency-bound inference (i.e. one request) you don't need tensor-cores since all your operations are just matrix vector multiplications.
The big issue with Strassen isn't performance - it's numerical stability.
Well, that'll help with a lot :) But dealing with wave quantization requires dimensions that aren't neceessarily a multiple of 2, and often are a multiple of the number of SMs on a GPU (i.e. 132 on an H100)
It's very much in the "worse is better" camp.
It's always fun when people use autodiff in packages like PyTorch for completely unrelated usecases :)
it wouldn’t use functions like these and the generated comparable code would be on-pare performance wise
Perhaps if XLA generated all functions from scratch, this would be more compelling. But XLA relies very heavily on pattern-matching to common library functions (e.g. CuDNN), and these patterns will certainly work better on Nvidia GPUs than AMD GPUs.
In this way, I actually think explicitly calling the common library functions is actually much more transparent.
To be clear, this performance is quite bad (presumably because you didn't manage to get compilation working).
You're getting 35 tokens/s for a 405B model, which comes out to about 85 Teraflops. 8 MI300x GPUs comes out to 10.4 Petaflops, so you're getting about 0.8% MFU (which is about 40-50x worse than decent training performance of 30-40% MFU).
For AMD's sake, I hope that it's your software stack that's limiting perf.
And was trying to make a broader point about the lack of transparency (in performance, lower-level impl) in PyTorch when running on NVIDIA vs. non-NVIDIA hardware.
I don't quite understand this argument. Lack of transparency from running PyTorch so instead we're gonna leave it all to XLA? How does this solve the "transparency" issue?
I believe it should run on V100 as well (although definitely not tested as well), and an user reported that they got it running on T4 too.
Ah sorry, should have put that in the blog post. This leverages Triton heavily, so it'll only work on machines that have Triton backends (at least, we've tested on Nvidia and AMD GPUs)
In my (very amateurish) testing, I think the performance seemed pretty comparable (for non-dilated natten). I need to do some proper benchmarking though!
These benchmarks are on Ampere, where FA3 has no performance benefits over FA2.
On Hopper, FlexAttention is currently about 80% of FlashAttention3's performance (about 500 TFLOPs peak)
https://x.com/chhillee/status/1821253769147118004?s=46
Perhaps this tweet thread would be better.
I would agree with this. For example, how would you represent causal attention in the standard equation?
Hi, one of the authors of this blog post (Horace He), along with Driss Guessous, Yanbo Liang, and Joy Dong.
We’re quite happy with this abstraction - happy to answer any questions about it!
Where are you seeing these benchmarks?