hey boss, wanna train with me?

Joined July 2024
4 Photos and videos
Big Boss reposted
Definitely not full mesh over 576 chips my fault for glossing over that Clive. The model is an 8 chip pod, 7 ports per chip, full mesh inside the pod. Between pods you’d want a different topology, probably a torus or dragonfly, but the point I’m making is that the latency critical TP domain stays inside the pod where there are zero switch hops. Now on high batch workloads you are right past Batch 64 the MAC array throttles but since we have floorplan to spare, my simple answer is just to add more MACs 🤣🫨😎♟️✨😵‍💫 In fairness I wrote this on the toilet and my legs were going numb so I had to rush through a few details. But I want to point out also that your high batching cuts the other way as well as it drags KV with it. At B=256 with just a totally unserious 8K context that’s ~2M cached tokens or ~336 GB of KV at FP8. Reading that once per step is 42 ms at 8 TB/s, or roughly 3x the latency of GEMM. And attention itself runs at ~8 FLOPs/byte with GQA so at this high batch workload you are memory bound on basically every chip ever built, including mine. The workload you’re describing isn’t compute bound at all at real context windows 🪟 its bandwidth and more IMPORTANTLY capacity bound ! So you do the math again: per 8 TB/s of bandwidth, one 8-chip pod on my side, one B200 on theirs it’s 1.5 TB of memory against 192 GB. Normalize it however you want, since bandwidth is what sets throughput I bring ~190 GB per TB/s, HBM brings 24. That ratio holds whether you count chips, trays, or racks. The imaginary B=256/8K scenario needs ~370 GB for weights KV. That does not fit in 192 GB without quantization gymnastics or spilling across more GPUs. On the pod it fits four times over with the same bandwidth and same read time and the only difference being that one of us serves the batch in a single pod while the other is sharding it across extra $40K packages and paying the interconnect tax. So at high batch and at real context windows the memory capacity is the problem and that’s where this arch wins. So you see this isn’t some Groq Junior CompE novice hit job your too quick to write me off, this… is fucking cinema Clive.
3
3
43
6,743
Big Boss reposted
@HIDEO_KOJIMA_EN look at this
1
2
11
4,142
Unfortunately the conversion overhead of optics increases latency but the bigger issue is that for scale up reliability is critical. Any link flaps and this whole mesh goes down lmao. And if there’s anything optics do it’s flap so you need to design for the inevitable failure rate which means giving back a lot of the gains we just made in throughput. Copper at short lengths on the other hand doesn’t have any of these failure and if latency is the critical parameter than you don’t even want the farther reach optics give you anyway. The only drawback of using copper is power consumption which is the real reason to go with optics anyway and that might make more sense in a training regime. But there are many ways to mitigate the power consumption of the SERDES in this architecture by exploiting the traffic profile. The more interesting question is how to do it for longer reach and higher bandwidth, but I’ll keep those ideas for next time.
Boss, could an optical interconnect solve the problem?
5
33
8,126
The last step is to reduce the content of LPDDR entirely as sadly it’s a larger % of the BOM today. However, will leave that as an exercise to my fellow soldiers. Remember to always train hard, never know if the next battle is around the corner! 🫡
15
204
20,713
Big Boss reposted
So let me get this straight. An account called “Bog Boss” just decided to post a chip architecture that seems to beat Nvidia at inference and it’s uses LPDDR, an old TSMC node, and *checks notes* 33 millimeters of MACs with the rest of the area going to DDR PHYs & 32 Gb SERDES and I still can’t seem to think of anything to refute what he’s saying ? 😂😂😂🤣🤣🤣
First you have to understand that modern LLM inference already disaggregates weights as models outgrew single chips years ago. You shard either by layer (pipeline parallelism) or by slicing every layer (tensor parallelism), and the two do very different things. As an example, let’s look at Llama 3.3. It has 70B of weights and at FP8 that’s 70 GB of memory which is enough to fit on a single H100. Now that H100 has 3.35 TB/s of HBM, so the fastest it can ever decode for one user is 70/3.35 ≈ 21 ms/token or ~48 tok/s while using under 1% of its FLOPs. Now if we pipeline it across 8 chips: each chip holds ~8.75 GB, which means it only needs 1/8th the bandwidth and 1/8th the FLOPs to sustain the same aggregate throughput. Now crucially the token/sec a user gets is limited by the amount of data that crosses the link. In current LLMs all that is a small amount of activations for LLama 3.3 it’s ~8 KB per token…. Yes, you read that right it’s 8 KILOBYTES we are sending over a <900 GB/s link. That’s only 9 ns of serialization time but the overhead of 224G PAM4 SerDes adds ~100 ns per link traversal with RS-FEC which is 11x longer than the payload itself. And then you have the NVSwitch adding ~300 ns per hop and you need to pay twice. That’s ~600 ns of just hardware latency wrapped around 9 ns of data making a 98% tax before software even shows up. Then NCCL’s collective stack turns 600 ns into 10-20 us… all to move 8 kilobytes lol. For comparison 8 KB serializes over 10 Gigabit Ethernet NRZ, in just 6.6 us. Pipeline parallelism however doesn’t make a single user faster as the token still needs to visit every layer in the sequence, so per-user speed is still weights / per-chip bandwidth. To get more speed per user token you need to use tensor parallelism and have all the chips work on the same layer simultaneously. TP costs you 2 all reduce OPs per layer, 160 per token on llama 3, that’s still kilobytes of traffic but with NVLink overhead it’s a massive tax and why pipeline parallelism on most models still gives more interactivity per user. However, this gives you a huge latency lever to pull that scales tokens per second with interconnect speed instead of memory BW. The clever amongst you might have also realized that sharding doesn’t just cut memory bandwidth per chip it also cuts FLOPs per chip and is why we have such bad MFU on decode. So once you’ve sized the link for the memory, you need to size the compute for it too. This is called “balancing the pipeline”, and currently no shipping chip does it because they were all designed as standalone monsters. Remember Tokens/sec = ~aggregate memory BW / bytes touched per token. At batch 64 in FP4 you need ~250 FLOPs per byte, and Blackwell ships 1,250. Provisioned 5x more than the narrow pipe of HBM. Nobody saturates shit cause they are all building around HBM. So now it all comes full circle. Parallelism reduces memory bw pressure and thus FLOPs but increases interconnect latency pressure. Despite having HBM and GigaSERDES we aren’t actually doing more work lol. But if you really wanted to balance the pipeline you need to match the memory bandwidth, the flops, and most importantly the interconnect. So what does that look like ? Well if you build around LPDDR’s lower bandwidth, lower your interconnect latency, you actually can beat Nvidia on decode with a fraction of the silicon.
44
78
2,773
343,293
So following these principles here is the architecture that falls out and it’s quite different than what is thought to be optimal today. Starting with the memory: LPDDR6 tops out around 14.4 Gb/s per pin. We would want to as many channels as the die’s edge can carry. If we can fit 24 channels, that’s 576 data pins, and you get ~1 TB/s per chip with 192 GB of storage. Same as the b200 in size but about an a100 in bandwidth. But remember that LPDDR access latency is ~100 ns which is about the same as HBM. So streaming weights from LPDDR costs you nothing on latency and we just give up per package bandwidth, and remember our pipelining already collapsed that requirement. Now work backwards to compute. Tokens/sec = ~aggregate BW / bytes touched per token, and at batch 64 in FP4 every delivered byte wants ~256 FLOPs. 1 TB/s × 256 = ~260 TF of FP4. Size ~280 TF for some headroom and stop! That’s all we need, the rest of the alpha is in latency tuning not flops. Now process node, again using first principles thinking. On TSMC N6 that MAC array would be about 30 mm^2. The rest of the die goes to SRAM buffers, 24 LPDDR PHYs, and 56 lanes of plain 32 GT/s NRZ SerDes PCIe 5.0 transceivers, nothing exotic. Because we didn’t provision more flops we can provision what we really need which is ports. If we do 7 ports × x8 we can get a full mesh across 8 chips with ~224 GB/s any to any ops, sized for 8 KB activations instead of 100 MB gradients. Approximate Total Area: ~144 mm^2, ~180W with the DRAM. Fucking Mobile SoC level economics. And we get away without a crazy process node. N3 shrinks your logic, but that’s actually the one thing this die barely has. SRAM stopped scaling and the PHYs and SerDes are analog so they don’t shrink at all. An N3 port shrinks ~20% of the floorplan, and saves maybe 10-15W, but doubles the cost on a small die that already has beautiful *chefs kiss* 👨‍🍳💋 yield. Now do the node math: 8 chips (b/c full mesh w/ 7 ports) = 8 TB/s aggregate BW, 1.5 TB total of memory, and ~1.44 kW. A B200 inside an NVL72 is 8 TB/s, 192 GB, ~1.67 kW all in. So we are basically neck and neck on BW with a b200 with slightly lower power because we have more chips connected with quicker interconnects allowing them to act as a single unit. If we scale to the rack level at 72 nodes, that 576 chips, 576 TB/s which is again the same aggregate bandwidth as a GB200 NVL72, so approximately the same tokens/sec by construction but with ~104 kW of power against ~120-130 and 110 TB of memory against 13.8 TB of the NVL72. So in summary 4.5x less compute silicon, zero HBM, zero CoWoS, zero leading-edge nodes and still token/watt ~20% better. So what’s stopping everyone from doing this? The number I told you hold whether you want to believe it or not and get even more competitive with longer reasoning chains or agentic workloads because as you scale those the all reduces now sits on the critical path of every token and on a 30 ns link with a full mesh that’s orders of magnitudes of token throughput improvements over Nvidia’s stack. Counterintuitively the link latency, not the chip architecture, decides your memory, logic, and everything else! Thanks for reading if you made it this far.
26
12
589
87,575
First you have to understand that modern LLM inference already disaggregates weights as models outgrew single chips years ago. You shard either by layer (pipeline parallelism) or by slicing every layer (tensor parallelism), and the two do very different things. As an example, let’s look at Llama 3.3. It has 70B of weights and at FP8 that’s 70 GB of memory which is enough to fit on a single H100. Now that H100 has 3.35 TB/s of HBM, so the fastest it can ever decode for one user is 70/3.35 ≈ 21 ms/token or ~48 tok/s while using under 1% of its FLOPs. Now if we pipeline it across 8 chips: each chip holds ~8.75 GB, which means it only needs 1/8th the bandwidth and 1/8th the FLOPs to sustain the same aggregate throughput. Now crucially the token/sec a user gets is limited by the amount of data that crosses the link. In current LLMs all that is a small amount of activations for LLama 3.3 it’s ~8 KB per token…. Yes, you read that right it’s 8 KILOBYTES we are sending over a <900 GB/s link. That’s only 9 ns of serialization time but the overhead of 224G PAM4 SerDes adds ~100 ns per link traversal with RS-FEC which is 11x longer than the payload itself. And then you have the NVSwitch adding ~300 ns per hop and you need to pay twice. That’s ~600 ns of just hardware latency wrapped around 9 ns of data making a 98% tax before software even shows up. Then NCCL’s collective stack turns 600 ns into 10-20 us… all to move 8 kilobytes lol. For comparison 8 KB serializes over 10 Gigabit Ethernet NRZ, in just 6.6 us. Pipeline parallelism however doesn’t make a single user faster as the token still needs to visit every layer in the sequence, so per-user speed is still weights / per-chip bandwidth. To get more speed per user token you need to use tensor parallelism and have all the chips work on the same layer simultaneously. TP costs you 2 all reduce OPs per layer, 160 per token on llama 3, that’s still kilobytes of traffic but with NVLink overhead it’s a massive tax and why pipeline parallelism on most models still gives more interactivity per user. However, this gives you a huge latency lever to pull that scales tokens per second with interconnect speed instead of memory BW. The clever amongst you might have also realized that sharding doesn’t just cut memory bandwidth per chip it also cuts FLOPs per chip and is why we have such bad MFU on decode. So once you’ve sized the link for the memory, you need to size the compute for it too. This is called “balancing the pipeline”, and currently no shipping chip does it because they were all designed as standalone monsters. Remember Tokens/sec = ~aggregate memory BW / bytes touched per token. At batch 64 in FP4 you need ~250 FLOPs per byte, and Blackwell ships 1,250. Provisioned 5x more than the narrow pipe of HBM. Nobody saturates shit cause they are all building around HBM. So now it all comes full circle. Parallelism reduces memory bw pressure and thus FLOPs but increases interconnect latency pressure. Despite having HBM and GigaSERDES we aren’t actually doing more work lol. But if you really wanted to balance the pipeline you need to match the memory bandwidth, the flops, and most importantly the interconnect. So what does that look like ? Well if you build around LPDDR’s lower bandwidth, lower your interconnect latency, you actually can beat Nvidia on decode with a fraction of the silicon.
74
73
1,575
456,508
I agree with this post whole heartedly but I’d push it even further. The interconnect IS the binding constraint for AI even more so than memory. If we want faster inference & training with better economics we are best served by designing our interconnect first and then working backwards towards the optimal chip architecture. Today’s chips weren’t really designed with this principle in mind. There is no better example than running autoregressive decode on a GPU. Despite all those reticle sized logic dies & CoWoS integration decode runs at under 20% of peak FLOPs on Blackwell, wasting silicon and burning power while waiting for memory. The naive solution has always been to increase memory bandwidth whether that’s adding more HBM or using SRAM. However, that is a vast simplification of the problem which I’ll explain later. But if you were clever you’d have realized while reading that you could feed those idle FLOPs by streaming weights over the interconnect itself. Wallah 🪄 you just discovered the idea that forms the basis behind disaggregated memory from first principles. But sadly this currently doesn’t work on Nvidia’s hardware. NVLink5 carries 1.8 TB/s against 8 TB/s of local HBM, and scale out is 80x behind that. The “pipe” is smaller than the memory at the other end and thus leads to worst token/sec if its relied upon. But we get an interesting lemma out of this which is that remote memory is only as fast as the interconnect. Therefore you must balance the pipe for the memory it attaches to. SRAM needs an 80 TB/s link, HBM needs 2 TB/s, and LPDDR gets away with a couple hundred GB/s. So Nvidia selling a rack of 72 GPUs, each GPU’s memory is pretty segregated. The core idea is still sound though but this raises a question, why would Nvidia build a fabric that’s high bandwidth and high latency leading to memory access being segregated per GPU? It’s because they were optimizing for training over inference. Training is dominated by collectives on huge tensors, and a couple microseconds of latency on a huge all reduce operation is just noise so the bandwidth gains justify the latency tradeoff. But more importantly, this also works because it matches what the chip is good at. GPUs are great at hiding latency with occupancy (also what allows them to be OK for training) but bandwidth is the only thing warp switching can’t create. You can justify a 224G PAM4 FEC with overhead when you have a chip that’s designed to be latency tolerant as well. It’s a latency tolerant fabric for a latency tolerant chip. Maybe a good design for training but inference inverts this completely. Now everyone knows decode is bandwidth bound so you might assume again that more/higher BW memory and thus higher BW interconnects are necessary. However, it’s the exact opposite and the name of the game is actually lower latency and that’s why despite having high bandwidth memory MFU on decode is still so low and also why I made the point earlier that the interconnect is MORE important than the memory itself as well as the chip architecture. In part two I will explain why lower latency interconnects are not just ideal for inference but also allow you to get away with a smaller cheaper memory and a simpler chip architecture.
chips get all the love but the interconnects across all levels from c2c to rack-to-rack are as important, and many chip makers are sleeping on it until very recently. Even most interconnects people just want it to be as transparent as possible, just send and receive the bits with lower error rates and lower energy per bit, wrong long-term direction imo. Interconnects are part of the living creature, so many things happening in your blood vessels in addition to just moving stuff, and your axons do much more than carrying spikes. People do not appreciate interconnects, smaller volume, poor margin, messy ecosystem, manual process, it's been a spiral of grinding, and it is largely invisible. How often do you see people tearing down transceivers and die shot of DSP chips vs logic chips? How often do you see high res pictures of all the connector's gold fingers on the NVL72 cartridge? Because it sounds boring, it's just making contacts, shoving electrons and photons, what a simple problem. But that is deceiving, and theres so much to it. You might want 576 to begin with, had to cut down to 288, then to 144, and finally to 72, and that barely worked first time. You are entering the domain of analog and mixed signaling, you are fighting copper real estate with power delivery, you are getting impedance mismatch and reflections and interference at every stupid interfaces, your optical components' and connectors' backreflection is making your laser mode hop.. And we are not even going into the thermal and strain-stress, the reliability of how many times you can actually mate your connector, the horrible jobs people are doing across the stack from science-project-originated photonic PDKs to hand cleaved laser dies to optical engines to rack manufacturing, on spec-ing out the requirements, the tolerances.. On top of all these, people thinking about where the bits should be going and people who know what the bits have to go thru are two totally different groups of people. But it is shifting, pluggable volumes shipped are doubling and tripling for scale-out, scale-up domain asks for much higher bw than scale-out, and interconnects are inevitable even if you cram as much compute and memory onto a single wafer. People will see it always has been interconnects, the chips people have already been doing it on the chips, that you can sort it out with your chip designers and foundries, and now you need to work with more people to sort it out from chips to boards/trays to racks to pods to data halls and data centers. These people speak very different languages and care about very different things, and it will take a lot of effort to pull order out of all the chaos. At the end of the day, it is such a crazy problem to work on, such a beautiful thing to make, millions of amps of current flipping 1e20 of flops, sextillions of photons carrying thousands of terabits per second, a few tons of copper, tens of thousands of fibers totally few hundred kilometers, one scale-up domain. You absolutely need a group of people that appreciate the beauty and care about the craft behind the grinding to make it together.
13
23
413
85,045
Ok back to work. Today’s project backtest all of @jukan05 @zephyr_z9 @aleabitoreddit posts to see if they are front running their followers into the tape before firing off a tweet.
3
34
4,006
Additionally, this all assumes Nvidia still has the best hardware in 5 years for inference which is a big assumption. TPU, Tranium, or ASIC-X takes off and the inventory as well as data center design needs to be completely gutted.
2
103
16,776
All of this assumes you paid cash for the GPUs but almost nobody does. Neoclouds borrow heavily to buy GPUs and pledge the GPUs themselves as collateral. And that changes the picture two ways: 1. Debt service. At ~10–15% financing, a $1.2M H100 pod carries ~$10–15K/mo in interest before you serve a single token. That eats roughly a third of your net and pushes break even math from ~2 years past 3. 2. Depreciation is even worse Loans amortize on an assumed 5–6 yr useful life but H100 rental have fallen from ~$8/hr to under $3/hr in only two years. If the collateral halves in its economic value while the loan is still on a 6-yr schedule, you’re underwater because the asset is depreciating faster than the debt. Now the most dangerous part here is unlike regular cloud hosting this is a treadmill. Every new generation of chips makes the last one’s economics worse, meaning you have to keep borrowing to stay competitive: Say you bought all those h100 pods and Rubin’s land with a 2 or 4x TCO efficiency gain, the collateral backing your loan is worth maybe half what you paid while you still owe most of the principal. To stay in the neocloud game you need to take on MORE debt to buy Rubin pods. So now you’re servicing old debt on H100s that are earning less and worth less new debt on Rubin pods that themselves start depreciating the day Feynman is announced. New GPU generations roughly coming every 2 years if stack this math across 2–3 generations the debt servicing compounds: each cycle you’re carrying a layer of underwater legacy inventory fresh leverage on the newest tier. Depreciation isn’t a one-time hit either it’s a step down that repeats every ~18 to 24 months, and the debt from each cycle outlives the earning power of the hardware it bought. The math only works if demand rental rates keep rising fast enough to outrun the depreciation curve. The moment demand blinks the utilization dips or rates compress you’ve got fixed debt payments on a stack of assets losing value faster than you can pay them down. That’s how a an amazing “80% margin” business becomes insolvent without revenue ever going to zero. Light-asset model layer holds pricing power more but have their own risks. It’s clear however that the neocloud layer is on a never ending treadmill and will probably get squeezed first when push comes to shove.
10
3
140
26,758
Now flip to the neocloud side that rents to the AI lab. What does it cost to OWN the metal? For the H100 pod @ ~$30K/GPU ~40% for server/networking/cooling ≈ ~$1.2M capex. Power is about 700W per GPU and if we assume $0.07/kWh using Texas/Louisiana pricing we get: 700w × 28 × 1.3 PUE ≈ 25.5 kW = ~$1.3K/mo For a B200 pod: ~$45K/GPU 40% ≈ ~$945K capex. Power: 1,000W × 15 × 1.3 ≈ 19.5 kW = ~$1K/mo. Break even rate on renting GPUs assuming 24/7 uptime & ~70% utilization: H100: $4 × 28 × 0.7 × 720hr ≈ $56K/mo − power ≈ $55K net. Which is roughly ~22 months to break even. B200: $6 × 15 × 0.7 × 720hr ≈ $45K/mo − power ≈ $44K net. ~21 months to break even. Both ~2 year payback, then ~$45–55K/month in pure margin per pod. Beautiful 😍 So therefore Neoclouds renting at $4–6/GPU-hr, get ~40–60% gross after capex power. The model layer that rents FROM the neocloud, then turns the $90–112/hr cost into $270–495/hr of API revenue giving ~60–82% gross. The token layer captures the fatter margin. And neocloud eats capex risk depreciation; but at the end of the day the model provider holds all the pricing power as without good utilization neoclouds can’t make money and without high token costs margins collapse and put pressure on Neoclouds to drive prices down.
6
4
141
24,589
Quick math: Assume your an AI lab and you got a ~1.8T param MoE model, 16 experts × ~111B params, with 2 experts active per token = ~280B active params. If you serve at FP8 (1 byte/param), you can estimate theoretical max token throughput just from HBM bandwidth: Max tokens/sec = BW / (2 × active bytes) H100: 3.35e12 / (2 × 300e9) ≈ 5.6 tok/s × ~0.3 efficiency ≈ 1.7 tok/s per GPU. With 28 way sharding: 28 × 3.35 = 94 TB/s = ~47 tok/s, ~15–20 realistically. With batching a pod does ~3,000 tok/s. At 30 tok/s per user, that’s ~100 concurrent users per pod. Anthropic charges $25/M output and $5/M input tokens on Opus 4.8, so revenue is output dominated. H100 pod (~28 GPUs @ $4/hr) = ~$112/hr. Producing 3,000 tok/s × 3,600 sec = 10.8M output tokens/hr. At $25/M output tokens that’s roughly $270/hr revenue. Profits per H100 pod: $270 rev − $112 cost = ~$158/hr, ~59% gross margin. For B200 (8 TB/s HBM, ~2.4× the bandwidth, ~$6/hr). A 15 GPU pod does ~5,500 tok/s batched = ~180 users. That’s 19.8M tok/hr × $25/M ≈ $495/hr revenue at ~$90/hr cost. Profit for B200 pod: $495 rev − $90 cost = ~$405/hr profit, or ~82% gross margin. A pod costs about the same whether you are serving 1 user or 180 and every marginal user is pure margin until the KV cache fills.
25
46
747
283,827
Neoclouds will probably be the hardest hit when the dust settles. GPUs depreciate over 3-5 years but data centers need to be operational for 20 years. The gold rush you see right now won’t continue - hyperscalers who are the long term customers of many of the neoclouds will soon have their own infra stood up to serve AI while also cutting back on capex relatively soon (Q1-Q2 27). Microsoft probably the first with Google to soon follow. I’m sure the circular financing deals will all come back to bite.
4
6
49
8,264