You say "that’s not how they’re making money", but the only reason anyone wants those A100s is because CUDA is pretty good. The hardware power is secondary in the sense that AMD is competitive with them — one could imagine a dominant AMD. But their stack is missing an API that works well.

How good A100/H200 are aren't the point, it's how essential they are to customers' profitability that matters. Zuck in particular still seems to be doubling-down on "build it, and they will come" while under continuing growing pressure to implement org-wide cost controls and wear big-boy business pants.

maybe because there's actual value in the systems being built and it's not simply blockchain 2.0 just because you keep repeating it?

there's a fairly incredible amount of commercial value in a system that can provide a workable "fuzzy match" or a system that can produce an approximately-optimal outcome without an intractable optimization step, for example. what is the commercial value of making the entirety of US logistics even 5-10% more efficient, or work-scheduling optimizations in a server farm?

like people just keep blindly repeating that there's no profitability there regardless of all the places it's quietly being deployed to great effect.

> Microsoft's and Meta's weaknesses are that they don't directly have a specific need for all of this hardware.

IIUC, OpenAI leased the model to Microsoft to power LLM search on Bing. OpenAI doesn't run the inference on their machines. Microsoft also added LLM features into Office (and Windows, too, right?)

What do you think is powering all that inference?

Those features are mostly being added to existing products and therefore aren't supporting new revenue streams. It remains to be seen if these features are popular enough to become table stakes for the existing OS and productivity software businesses and justify continued investment.

And why aren't they buying MI250Xs instead?

Prior vendor relationships and standardization. It's too much of a PITA ($$$$ engineering time) for research SWEs to support and buyers also have to engage more vendors to handle multiple stacks. Meta and Microsoft generally standardize their shit as much as possible. Meta's Reality Labs is sort-of a special case in that it does more "throwaway"-type stuff, but it still aims to standardize and not deviate that much because it slows things down.

>It's too much of a PITA ($$$$ engineering time) for research SWEs to support and buyers also have to engage more vendors to handle multiple stacks. Meta and Microsoft generally standardize their shit as much as possible.

Right, and they are standardizing on CUDA. Something no other company has any chance of matching for the forseeable future.

> Right, and they are standardizing on CUDA.

How many people are writing to CUDA directly, and how many folks are using something like PyTorch front-end where the back-end can potentially be changed?

* https://pytorch.org/blog/pytorch-for-amd-rocm-platform-now-a...

* https://rocm.docs.amd.com/projects/install-on-linux/en/devel...

* https://dev-discuss.pytorch.org/t/opencl-backend-important-u...

There are tons of use cases for GPGPU, the compute world isn't only about Pytorch and Tensorflow.

And even with middleware, turns out CUDA has the best debugging tooling, followed by DirectCompute/DirectML and Metal.

sure, it's things like oneapi that have pluggable backends. spir-v/vulkan compute too.

now, for how many of those things does AMD have a pluggable backend that actually works? none of them, unfortunately. Octane implemented on SPIR-V - on NVIDIA and Apple, because those were the runtimes that worked. AMD and Intel couldn't even compile it successfully (intel probably would today, I'd guess). Blender tried to support AMD for a long time, and the runtime was so buggy and defective they eventually pulled support from OpenCL entirely, since the OpenCL only ever ran properly on NVIDIA and Apple, and both of those have alternative interfaces that are cleaner and faster. The only point was supporting AMD, and AMD's OpenCL implementation is so buggy that it ended up being a de-facto AMD-specific codepath anyway.

That's the problem, AMD's software stacks are fractally broken. Not just HIP and their oneAPI adapter, but the ROCm it runs on. Not just ROCm, but the OpenCL it runs on. Not just openCL, but the kernel scheduler it runs on. Everything is broken at every level even on supported hardware.

Saying "it's just software" is a handwave. There are literally entire stacks here that are not fit-for-purpose and need to be substantially rebuilt before you can start building the layers above them. There isn't a stable enough basis to just implement an adapter for these pluggable frameworks, because the runtime and the kernel code are also broken.

MAANG are willing to invest in ASIC engineering like Apple does but are willing to buy and rent things from others in the short-term. They will eventually wise-up, and design their own custom AI accelerators. Meta already designs and builds their own servers.

Meta, Amazon, Google, Apple all already have custom accelerators, though some only for inference.

Microsoft does too, Maia 100