Hacker News Reader

There's also a problem of dataset size. the 7900XTX maxes out at 24GB when a lot of new models require the higher-end 80GB A100 variants. The A100 is also a server-grade card, so even spec-for-spec it's not a fair comparison.

> a lot of new models require the higher-end 80GB A100 variants

For training, yeah. But at least in some cases, inference can be optimized to use less memory.

For their large Whisper model, OpenAI says they need 10GB of VRAM: https://github.com/openai/whisper#available-models-and-langu...

My DirectCompute port of that uses slightly over 4GB of VRAM, see the last column in that table: https://github.com/Const-me/Whisper/blob/master/SampleClips/... I haven’t actually optimized memory usage I only did the DirectCompute port, the memory savings were achieved by Georgi Gerganov in whisper.cpp project, which I ported to Windows.

apparently GPT-J needs ~25GB RAM min (for inference only), i.e. a 32GB card ...and GPT-3 is an order of magnitude bigger again

https://nlpcloud.com/gpt-3-open-source-alternatives-gpt-j-gp...

though TBH just making cards with more RAM to fit these kind of models seems easier than being at absolute cutting edge of performance

I also wonder how this metric translates to something like Apple Silicon 'unified memory'... latest MBP have 32GB RAM, I wonder if anyone managed to run GPT-J there yet?

There's a float16 version of GPT-J rewritten in C++ here that apparently fits into 16GB...

https://github.com/ggerganov/ggml/tree/master/examples/gpt-j

it's CPU-only and runs inference at "about ~6 words per second" on an M1 MBP

That's for the max-size model (6B parameters). GPT-Neo has pruned models 125m and 1.3b that fit into 1.5gb and 6gb of memory respectively.

These models are obviously nerfed, but you can run them on budget ARM hardware and get legible, paragraph-length responses in less than 10 seconds.

There's a 20B model now

The 20B model was the original I believe, and the other models were all pruned from it.

This is incorrect. Thought would be interesting. Pruning usually removes some parameters from the model (setting certain ones to 0 for instance). The smaller models all have less layers and therefore weren’t pruned but were smaller to begin with.

They have a link to the bottom for something similar, but with GPT-2. The Hugging Face docs have hints for using FP16, and avoiding double memory requirements for model and checkpoint data.

You can also use int8 quantization which comes for free with huggingface and isn’t a huge cost to accuracy. Which cuts the memory usage almost in half again. (almost in half because some layers might stay 32 bit if they make a tiny part of the model)

I am running GPT-J-6B inference on 13GB of VRAM. FP16 is a must at this scale. I've also loaded GPT-NeoX-20B using int8 quantization onto a single RTX 3090 before (24GB VRAM) however inference latency was quite high.

Actually, the MacBook Pro with M2 Max CPU can be configured with 96GB of ram. The Mac Studio with M1 Ultra can have up to 128GB of ram.

Ah great, I hadn't seen that... seems like that should be plenty for some of these models!

I've been running the stock implementation that OpenAI put out, I didn't know people had made so many improvements!

Thank you for your work.

As someone who trains large models, this is pretty much the only number I care about. Batching saves more time, and gets better results, than clock speed.

For the A100, A6000s, and H100s you are paying for the memory and the upcharge for being a server card. AMD isn't really competing in this space, but they are moving in that direction if you look at the exascale machines[0,1]

[0] https://www.top500.org/system/180047/

[1] https://www.amd.com/en/products/server-accelerators/instinct...

> Batching saves more time, and gets better results, than clock speed.

How much time is saved?

If you've got a 12GB card at 5x speed vs. a 96GB card at 1x speed (so 5x slower), is the former still competitive? How much faster does the 12GB card need to be to get the same quality results with less memory (and smaller batches)?

What if the faster card has 24GB of memory?

Well the batch size also helps with making training more stable. So a larger batch size computes the gradient across more examples so it ends up being more stable than only using a batch size of day one. A batch size of one is only fixing the error on one example rather than many.

a larger Batch size can help keep the gpu fed but usually that’s not a problem with these larger models.

Hard to say tbh. Could be infinite, could be zero.

In classification batch is going to help a ton (including stability) and you may not even get top results without a high batch, so infinite in that case. More realistically, consider that batch also helps with GPU I/O. I/O slows things down quite a lot, so if you're moving stuff in and out of the accelerator a lot then you can easily be I/O bound.

For generation the conversation gets more complicated. For GANs the smaller card could do better if you can fit a proper batch size there (probably not tbh but often closer to 16 or 24 so that may be better here). Here distributed tends to help more. For VAEs, Diffusion, Autoregressive, etc are more stable and can also hugely benefit from large batches.

So the truth is an unsatisfying "it depends." I know that may not be the answer you're looking for, but it is the real one. It takes a lot of work and tricks to scale (as anyone working in non-ML HPC will tell you very similar stories about scaling). But also note that the clock speeds aren't as big of a gap as you note though the memory gaps are.

Could you educate me on what's really different about a card that is "server-grade" vs. one that is not?

Two of the biggest differences are ECC memory and virtualization support.

Yeah, also while ECC is mostly transparent to the software layer, virtualization support is in itself a huge software layer that comes with this kind of equipment. MIG ( https://docs.nvidia.com/datacenter/tesla/mig-user-guide/ ), there's also software made to expose GPU inside containers.

This software is mostly supplied by vendor, and it mostly cares about vendor's tech, and will usually require special features exposed by the hardware, so, won't work with consumer-grade GPUs.

well, and it's a specialized die. A100 ~ 2x size of 3090

For these GPUs, it partially comes down to form factor (being able to drop 8 in a chassis with unified cooling). I’d say that’s the primary difference here. This applies maybe a little more noticeably to the rest of the computer around the a100s, with ECC ram, hot swappable components, and redundant power supplies. The 8x a100 rigs are absolute beasts, difficult to move even by two people without removing some components. There is also price discrimination here where manufacturers aim for higher margins on server components (as nvidia clearly does).

Between the two mentioned cards, though, it really does come down to performance. The cards are simply not interchangeable for large scale model training.

You should probably compare the H100:

https://www.techpowerup.com/gpu-specs/h100-sxm5-96-gb.c3974

With the MI300, which has 128GB and more compute power (at least on paper):

https://www.techpowerup.com/gpu-specs/radeon-instinct-mi300....

A100 can be compared with MI250, perhaps. It also has 128GB.

The MI300 will compete more with Grace Hopper than with the H100 SXM5. We will be covering and showing both later this year.

What is the pricing like for the MI300's?

I would guess $12k-$16k, but they haven't released the price yet.

An Azure 8x MI250X OAM enclosure was out and about at the SC22 conference late last year (second half of the linked article).

https://www.servethehome.com/microsoft-azure-at-sc22-and-the...

> 50% more than Radeon 7900 XTX, but the AMD GPU costs 10x less

You could say that about some of nvidia's other GPUs too. A better comparison would be AMD's server offerings, which are priced comparably.

> Unlike traditional HPC stuff like FEM or fluid dynamics, the GPU code of ML inference is not that complicated.

It's complicated enough relative to the problem ML people are trying to solve. That's why in ML, all these tools have emerged specifically to let practitioners not care about the GPU code. People writing pytorch code don't want to think about CUDA vs vulkan at all. It's more of a question for the people writing the foundational libraries like pytorch.

I sincerely hope that tools like openai's triton make it easier to support a variety of GPUs.

> You could say that about some of nvidia's other GPUs too.

Technically, yes. Practically, nVidia forbids to deploy their other GPUs in data centers, in the EULA of their drivers: https://www.datacenterdynamics.com/en/news/nvidia-updates-ge...

May or may not be enforceable, probably depends on jurisdiction, but I’m pretty sure that EULA gonna scare some people.

> People writing pytorch code don't want to think about CUDA vs vulkan at all.

Well, there’re also other people. OpenAI’s CEO doesn’t necessarily write pytorch code, but he described the compute costs of ChatGPT as “eye-watering”.

> I sincerely hope that tools like openai's triton make it easier to support a variety of GPUs.

I’ll believe it when I see it. Performance portability across GPU architectures ain’t trivial. For instance, in my Whisper implementation, the most expensive compute shader is the one which computes product of 2 matrices.

nVidia version: https://github.com/Const-me/Whisper/blob/master/ComputeShade...

AMD version: https://github.com/Const-me/Whisper/blob/master/ComputeShade...

These two compute shaders have little in common, they even use different memory layout for the arguments, despite both compute shaders are doing the same math.

This TB/sec of memory bandwidth is only when the data is on the GPU. The real problem is that GPU memory is expensive and models are getting bigger.

What we would like to do is what has usually been done with the cache hierarchy where you bring the data as needed to the GPU. As this would allow to only need a lot less memory, as we could stream parameters from RAM or disk as needed.

But there is a bottleneck at the pcie interface ( 32GB/s for pcie 4.0x16 ), and you can't feed the GPU fast enough. Which means you can't leverage cheap memory directly.

indeed the CUDA software is the moat for Nvidia, though its hardware is still great.

At the scale of investment OpenAI are making the software shouldn't be the moat anymore - you can hire a lot of very good software engineers with ten percent of that hardware budget.

it's way more than that, building an ecosystem takes time, like a decade or more, lots of tooling, libraries, optimizations etc have to be done, and they have to be done in a way users think it's either similar to CUDA, or is simpler, the moat is very wide and deep as far as I can tell.

I feel like very few ML researchers actually use CUDA. You'd likely get a long way with an optimised backend for XLA to cover tf/jax, probably something similar for pytorch. That's a lot of work but not sure it's a whole decade.

Not sure if that's entirely tree. CUDA has 85% or more of the market share last time I checked, intel's OneAPI and AMD's ROMA? are so behind that made their Machine learning hardware totally uninteresting for ML related purchases, sadly.

I don’t think OpenAI needs a new ecosystem. I think they just need a cost-efficient way to run inference of their ML models, for large userbase.

That smaller task is way more manageable. It shouldn’t take a decade, maybe a month or two. Vulkan ain’t some new tech, the API arrived years ago and is widely used by game developers.

Thanks to Valve work on DXVK 2.0, there’s even an implementation of MS DirectCompute GPU API over Vulkan on Linux. I’m not saying doing that is necessarily the best approach for the job, just one of the many options.

What are the chances someone pulls a Toy Story and Nvidia gets SGI’d by clusters of consumer grade graphic cards? Knowing greedy nvidia they’d probably try to nerf their gaming cards for that task but its not like they are a monopoly.

I don’t know what the chances are, but over time it might happen. Economy of scale should not be underestimated.

30 years ago, there was a consensus x86 architecture was only good for small computers, while servers need faster specially-designed processors like IBM Power or Dec Alpha. Then AMD64 was introduced, after a while they took server market too.

15 years ago, Intel was making specialized HPC co-processors called Xeon Phi. The chips were actually good, exceeded 1 TFlop of FP64, and weren’t terribly hard to program. I think it were consumer-grade graphic cards which made it obsolete. Despite much harder to program, the raw performance numbers were better, and cost efficiency in flops/$ was an order of magnitude better.

> It’s not terribly hard to port the inference to other hardware architecture or software stack

Sounds like a job for AI. Universal translator and all that.

With nvidia's sparsity support memory bandwidth can be effectively doubled for inference, if you can sparsify.