> if slowing this down were possible

Why is embedded alignment evaluation not possible?

I agree with Dario, this did work globally in banking and did encourage a race to the top. Didn’t prevent the GFC but also we did survive the GFC.

I saw Woz on Northbound 280 “driving” his cherry red Model S, using FSD. He was looking down at the screen the whole time I watched him. Swear he had ssh’d into it.

[0] https://cloud.google.com/billing/docs/how-to/disable-billing...

[0] https://github.com/AI-Hypercomputer/maxtext

https://github.com/tokyo-digitaltwin/roadmap_v1.0/blob/main/...

Would appreciate the collective energy being spent instead towards adding to amor refining Garry’s request.

https://ieeexplore.ieee.org/document/9499913

## How can we fit so much more compute on the silicon?

The NVIDIA H200 has 989 TFLOPS of FP16/BF16 compute without sparsity. This is state-of-the-art (more than even Google’s new Trillium chip), and the GB200 launching in 2025 has only 25% more compute (1,250 TFLOPS per die).

Since the vast majority of a GPU’s area is devoted to programmability, specializing on transformers lets you fit far more compute. You can prove this to yourself from first principles:

It takes 10,000 transistors to build a single FP16/BF16/FP8 multiply-add circuit, the building block for all matrix math. The H100 SXM has 528 tensor cores, and each has $4 \times 8 \times 16$ FMA circuits. Multiplying tells us the H100 has 2.7 billion transistors dedicated to tensor cores.

*But an H100 has 80 billion transistors! This means only 3.3% of the transistors on an H100 GPU are used for matrix multiplication!*

This is a deliberate design decision by NVIDIA and other flexible AI chips. If you want to support all kinds of models (CNNs, LSTMs, SSMs, and others), you can’t do much better than this.

By only running transformers, we can fit way more more FLOPS on our chip, without resorting to lower precisions or sparsity.

## Isn’t memory bandwidth the bottleneck on inference?

For modern models like Llama-3, no!

Would the inverse of these punitive solutions, ie., encouraging carpool / ridesharing, not also work? It always amazes me how relatively unutilized the HOV lanes are.

> the problems with your flow are clearly posting calls to actions on the page Sigh, agreed. I'd like to move away from a wizard-based flow and try either a) using a calendar to drag & drop the schedule, or b) create a WYSIWYG "signup page builder" flow.

>I’d just ask for where is the ultimate destination, maybe a date and a list of emails.

So try to get quicker to the step where a signup page is shared with users, right?

> If I have time, I’ll play around with this on my phone later. Thanks!