I guess gigawatts is how we roughly measure computing capacity at the datacenter scale? Also saw something similar here: > Costs and pricing are expressed per “token”, but the published data immediately seems to admit that this is a bad choice of unit because it costs a lot more to output a token than input one. It seems to me that the actual marginal quantity being produced and consumed is “processing power”, which…
Gigawatts seems like more a statement of the power supply and dissipation of the actual facility. I’m assuming you can cram more chips in there if you have more efficient chips to make use of spare capacity? Trying to measure the actual compute is a moving target since you’d be upgrading things over time, whereas the power aspects are probably more fixed by fire code, building size, and utilities.
Anthropic expands partnership with Google and Broadcom for next-gen compute
131–139 of 139 posts
Re: Anthropic expands partnership with Google and Broadcom for next-gen compute
#132Earlier quoted context omitted.
> but the published data immediately seems to admit that this is a bad choice of unit because it costs a lot more to output a token than input one And, that's silly, because API pricing is more expensive for output than input tokens, 5x so for Anthropic [1], and 6x so for OpenAI! [1] https://platform.claude.com/docs/en/about-claude/pricing [2] https://openai.com/api/pricing
I think for the same model wall time is probably a more intuitive metric; at the end of the day what you’re doing is renting GPU time slices. Large outputs dominate compute time so are more expensive. IMO input and output token counts are actually still a bad metric since they linearise non linear cost increases and I suspect we’ll see another change in the future where they bucket by context length. XL output contex…
For Anthropic, as a business bleeding money, it's probably nice to have value-based pricing, for the tokens, so innovation (like computation efficiency improvements) can result in some extra margin. If they exposed the more direct computation cost, they could never financially benefit from any improved efficiency, including faster hardware!
Re: Anthropic expands partnership with Google and Broadcom for next-gen compute
#133Earlier quoted context omitted.
How so? Opus and Sonnet are frontier models which cannot easily be replicated. Compute has real physical constraints which require appropriate procurement at this scale. At least those two points seem like pretty strong moats against the majority of companies.
You don't need to "replicate" Opus and Sonnet, you just need to match their overall performance at lower cost. That's been absolutely doable so far, with a steadily decreasing lag time.
Re: Anthropic expands partnership with Google and Broadcom for next-gen compute
#134Re: Anthropic expands partnership with Google and Broadcom for next-gen compute
#135Earlier quoted context omitted.
How so? Opus and Sonnet are frontier models which cannot easily be replicated. Compute has real physical constraints which require appropriate procurement at this scale. At least those two points seem like pretty strong moats against the majority of companies.
You don't need to "replicate" Opus and Sonnet, you just need to match their overall performance at lower cost. That's been absolutely doable so far, with a steadily decreasing lag time.
To be clear, I accept you might be right, but I think the crux is whether lag time is increasing, steady or growing.
Re: Anthropic expands partnership with Google and Broadcom for next-gen compute
#136Earlier quoted context omitted.
The moat is in: 1. Opus and Sonnet. 2. Compute capacity. Anthropic has much more of it than your average coding startup. 3. The developing ecosystem around Claude Code.
none of the three are even remote moat
Re: Anthropic expands partnership with Google and Broadcom for next-gen compute
#137Earlier quoted context omitted.
> but the published data immediately seems to admit that this is a bad choice of unit because it costs a lot more to output a token than input one And, that's silly, because API pricing is more expensive for output than input tokens, 5x so for Anthropic [1], and 6x so for OpenAI! [1] https://platform.claude.com/docs/en/about-claude/pricing [2] https://openai.com/api/pricing
I think for the same model wall time is probably a more intuitive metric; at the end of the day what you’re doing is renting GPU time slices. Large outputs dominate compute time so are more expensive. IMO input and output token counts are actually still a bad metric since they linearise non linear cost increases and I suspect we’ll see another change in the future where they bucket by context length. XL output contex…
This is a bit too much of a simplification.
The LLM provider batches multiple customer requests into one GPU/TPU pass over the weights, with minimal latency increase.
The LLM provider may in fact be renting GPUs by the second, but the end user isn't. We the end users are essentially timesharing a pool of GPUs without any dedicated "1 vGPU" style resource allocation. In such a setting, charging by "GPU tick" sounds valid, and the various categories of token costs are an approximation of cost+margin.
Re: Anthropic expands partnership with Google and Broadcom for next-gen compute
#138Earlier quoted context omitted.
I don’t think Opus and Sonnet are significantly better than Gemini or ChatGPT. Am I missing something? It looks to me that Anthropic is one or two Gemmas away from a lot of people using Opus for 20% of hard use cases and letting on-device LLM rip through the code base on a Mac Mini or Studio and OpenCode. Once Claude Code is not the only game in town and Cowork is made redundant by Google pulling their finger out on…
On-device agentic use is orders of magnitude harder than simple chatting (which is still slow for SOTA), it uses up a huge amount of context and tokens on reading code and reasoning through it. It's sort of viable if you just set it to work overnight on some completely vibe-coded stuff, but that has very middling results. Giving feedback to the model interactively is completely out of the question. Where open models…