3 ms·
I think you ignored both of my points - 1. You just negated a technical statement with... I don't even know what. Engineering opportunities at volume and high
by lmeyerov 1y ago
I think you ignored both of my points -
1. You just negated a technical statement with... I don't even know what. Engineering opportunities at volume and high skill allow changing the margin in ways low volume and low capitalization provider cannot. Talk to any GPU ML or DC eng and they will rattle off ways here. You can claim these opportunities aren't enough, but you don't seem to be willing to do so.
2. Again, even if tokens are unprofitable at scale (which I doubt), market position means owning a big chunk of the distribution channel for more profitable things. Classic loss leader. Being both the biggest UI + API is super valuable. Eg, now that code as a vertical makes sense, they bought more UI here, and now they can go from token pricing closer to value pricing and fancier schemes - imagine taking on GitHub/Azure/Vercel/... . As each UI and API point takes off, they can devour the smaller players who were building on top to take over the verticals.
Seperately, I do agree, yes, the API case risks becoming (and staying) a dumb pipe if they fail to act on it. But as much as telcos hate their situation, it's nice to be one.
- jsnell 1y agoI don't think I was ignoring your points. I thought I was replying very specifically to them, to be honest, and providing very specific arguments. Arguments that you, by the way, did not respond to in any way here, beyond calling them "[you] don't even know what". That seems quite rude, but I'll give you the benefit of the doubt. Maybe if you could name one of those potential opportunities, it'd help ground the discussion in the way that you seem to want? Like, let's say that additional volume means one can do more efficient batching within a given latency envelope. That's an obvious scale-based efficiency. But a fuller batch isn't actually valuable in itself: it's only valuable because it allows you to serve more queries. But why? In the world you're positing where these queries are sold at negative margins and don't provide any other tangible benefit (i.e. cannot be used for training), the provider would be even better off not serving those queries. Or, more likely, they'd raise prices such that this traffic has positive margins, and they receive just enough for optimal batching. > You can claim these opportunities aren't enough, but you don't seem to be willing to do so. Why I would claim that? I'm not saying that scaling is useless. I think it's incredibly valuable. But scale from these specific workloads is only valuable because these workloads are already profitable. If it wasn't, the scarce compute would be better off being spent on one of the other compute sinks I listed. (As an example, getting more volume to more efficiently utilize the demand troughs is pretty obviously why basically all the major providers have some sort of batch/off-peak pricing plans at very substantial discounts. But it's not something you'd see if their normal pricing had negative margins.) > Engineering opportunities at volume and high skill allow changing the margin in ways low volume and low capitalization provider cannot. My point is that not all volume is the same. Additional volume from users whose data cannot be used to improve the system and who are unprofitable doesn't actually provide any economies of scale. > 2. Again, even if tokens are unprofitable at scale (which I doubt), If you doubt they're unprofitable at scale, it seems you're saying that they're profitable at scale? In that case I'd think we're actually in violent agreement. Scaling in that situation will provide a lot of leverage.
- lmeyerov 1y ago> But why? In the world you're positing where these queries are sold at negative margins and don't provide any other tangible benefit (i.e. cannot be used for training), the provider would be even better off not serving those queries. Or, more likely, they'd raise prices such that this traffic has positive margins, and they receive just enough for optimal batching. ... But scale from these specific workloads is only valuable because these workloads are already profitable I'm disputing this two-fold: - Software tricks like batching and hardware like ASICs mean what is negative/neutral for a small or unoptimized provider is eventually positive for a large, optimized provider. You keep claiming they cannot do this with positive margin some reason, or only if already profitable, but those are unsubstantiated claims. Conversely, I'm giving classic engineering principles why they can keep driving down their COGS to flip to profitability as long as they have capital and scale. This isn't selling $1 for $0.90 because there is a long way to go before their COGS are primarily constrained by the price of electricity and sand. Instead of refuting this... You just keep positing that it's inherently negative margin. In a world where inference consumption just keeps going up, they can keep pushing the technology advantage and creating even a slight positive margin goes far. This is the classic engineering variant of buttoning margins before an IPO: if they haven't yet, it's probably because they are intentionally prioritizing market share growth for engineering focus vs cost cutting. - You are hyper fixated on tokens, and not that owning a large % of distribution lets them sell other things . Eg, instead of responding to my point 2 here, you are again talking about token margin. Apple doesn't have to make money on transistors when they have a 30% tax on most app spend in the US.
- lmeyerov 1y agoMaybe this is the disconnect for the token side: you seem to think they can't keep improving the margin to reach profitability. They are static and it will just get worse, not better. I think deepseek instead just showed they haven't really bothered yet. They rather focus on growing, and capital is cheap enough for these firms that optimizing margins is relatively distracting. Obviously they do optimize, but probably not at the expense of velocity and growth. And if they do seriously want to tackle margins, they should pull a groq/Google and go aggressively deep. Ex: fab something. Which... They do indeed fund raise on.
- solarkraft 1y ago> Engineering opportunities at volume and high skill allow changing the margin in ways low volume and low capitalization provider cannot Everything depends on this actually being possible and I haven’t seen a lot of information on that so far. DeepSeek‘s publication suggests that it is possible - specifically there was recently a discussion on batching. Google might have some secret sauce with their TPUs (is that why Gemini is so fast?) And there are still Cerebras and Groq (why haven’t they taken over the world yet?), but their improvements don’t appear to be scale dependent. Speculating that inference will get cheaper in the future might justify selling at a loss now to at least gain mind share, I guess.
- lmeyerov 1y agoThere is an interesting subtlety to what you are saying - * Inferencing is getting cheaper: 40-80% / yr in hardware + 40-80% / yr in software. Annual numbers will change, but for next 5 years, seems fine to assume continued improvement at meaningful levels. * Subtlety 1: What % of that improvement is only accessible to large providers with bigger workloads and bigger capitalization? Think more opportunities for batching, specialization, bulk purchasing, ... . That edge is where their ability to both underprice others + have a profitability margin here vs being a loss leader. A lot of the annual hw/sw improvement is commoditized for low-scale. Eg, hyperscalers pay 10% less to Nvidia than the next tier of smaller buyers, and I'm unsure of how to think of the margin benefit of custom hw * Subtlety 2: if things keep going well, there may be a limited window around wirkloads "tricky enough that only they can do it" , eg, if commodity + oss using 2nd tier providers are "good enough" and also reach low COGS, so it's just regular data center stuff, all this becomes unclear again. I can likewise imagine that becoming true of the wider use case of Text, while image/video/audio ends up more specialized