Best estimates from last year are on the order of 50 million discrete consumer GPUs vs 7-10 million datacenter/enterprise GPUs. Sounds like the PC market is huge! but with average sales costs of well under 1k USD (a lot of the PC cards are budget variety, included with prebuilt computers, etc). it's only a $30-40b business. Those datacenter GPUs are averaging $50k each before the supply issues with HBM started to inflate everything greatly. But using that as a benchmark, that enterprise business looks like several hundred billions.

NVIDIA's latest filing reported $162b in revenue for datacenter compute in the last FY, so we know it's at least that large. Now add AMD, Intel, and everything going on in China that we don't have great numbers for. We can very conservatively say that the enterprise GPU market is currently >5x larger than consumer, in dollars, and it may be quite a bit larger than that.

In the simple case, the shop isn't really repairing your bike, it's deploying a fix (a new part) that has already been designed and manufactured. This is a much different and easier thing to do.

In the case of new features, let's say you wanted your bike to also attach a kite, so it went faster on a windy day. The bike shop proposes to do this by attaching the kite to a bolt that they want to put in the frame by drilling a hole all the way through this frame. Is this acceptable to do? Maybe, but who knows, really? How much testing do you want to happen before you trust your life that the frame won't collapse?

There's a lot of effort put into engineering things we take for granted every day. The upside to software is we think we can change it to easily do anything. The downside is if you care about reliability then that ten minute / one line change has hundreds to thousands of hours of test program behind it that we collectively pretend doesn't exist.

It's to assume that every single thing that could break, will break, and design enough resiliency in that you have to stack up as many failures as possible before things truly go off the rails.

So to do this without killing people, you add the new systems with the same safety thresholds, then gather quite a few years of statistics, then, slowly let things become more efficient if that's both warranted by data and also warranted by simulation of events that you do not yet have data for.

Skipping steps in this because you want to put more cars on the road immediately is foolish and dangerous.

Yes, at 5pm in a major city, a bus driver might pull up next to a convenience stop, stop the bus, go pee, and come back. Does it happen often? Not that often, because of the aforementioned "we design routes so people aren't trapped for multiple hours" concept.

Why not aim for the same distance between cars and twenty times more safety instead?

"When that happens, choosing to drive yourself will be a selfish act, just like exposing people to secondhand smoke is now." Really? I drive on logging roads a few times a month to get to some property. This is pretty sketchy even in good conditions and there's always the chance of getting stuck and having to hike a mile or two the rest of the way up to go get the tractor and sort it out. I'm probably not buying a self-driving car any time soon, if ever.

Now, is having self driving taxis a fantastic idea in a very dense city? Of course. There's huge benefits in keeping the average car as safe, efficient in both energy and pollution, and highly utilized as possible. Are these also a good retrofit to dense-ish suburbs where a bus/rail network isn't quite enough (and the costs to build it in already-developed land are unpalatable)? Also yes. But that's not ubiquitous, that's just part of a larger system that needs to be able to serve all users.

And if your point is that "move out of the mountains and into a city because that's the less-selfish option"... that's a certain kind of political statement, I guess.

There's a lot that's problematic that we suspect that is going on but don't have firm proof, because the organization actually is pretty good at keeping it secret enough. There's some exceptions where things do get leaked/revealed, but how would you know if this was 99% of wrongdoing, or 0.99% of it?

Even if it were IP-bsaed, it would be extremely straightforward for one box to send a UDP message to another, and receive and retransmit at the application layer. No TTL nonsense, No multiple IPs showing up communicating upstream.

There's no advertising here, there's just aggressively trying to drain each person's wallet as much as possible and seeing how far you can get before they change behaviour.

One example: my friend and I both requested rides using the same app, standing next to each other to the same street in the same neighborhood 3-4 miles away. He owns a car and rarely uses car services, I do not and it's my primary transportation. The quoted cost of his ride was half mine. It was shocking.

Something like the next iteration of Cerebras hardware paired with HBM for KV cache + HBF for weights could be incredibly strong here and much more likely to see away to make into a product with some lifetime compared to "let's bake a old model into a very, very large number of custom chips, design all the interconnects from scratch, and pray". Maybe in 10-15 years once this all matures.

Now if that works out that means in '29/'30 we could easily see a run on NAND that's even worse than the current DRAM price issues, on top of the current increases. Fun times if that happens.

Let's say a magic set of chips comes along to host this. Maybe it's 2-3x more efficient in size and power. You're still talking a form factor that's a good chunk of a rack, draws tens of kilowatts, and could actually be sold at a similar if not higher price point because the OPEX is so much lower.

It may be useful but it's certainly uneconomic to spend >$1m to self host the model, plus ongoing power and maintenance costs, plus the cost to adapt whatever building you're in to be able to power it.

It's entirely possible for a 2-3 month project if one senior person was left the hell alone to do it to take a dozen people five years.

Small plants in the middle of nowhere, especially municipal ones? You're lucky if it was designed this century and not 50-100 years ago. Everyone's just trying to keep old stuff running at absolute minimum cost.

It's quite reliable, and does not require paying for a team of people who wants to try new things. Once this happens for a long while there's no one in the building left who's going to advocate for change, since the only thing all that fancy new technology brings is the next 5 years of nobody getting a bonus because operational metrics weren't being met anymore.

You have to try really hard to convince these people that the thing that they have seen on a daily basis to work just fine for the past twenty years is no longer good enough, because all their evidence says that it is. And you should also listen to them much more than people who just want to use the latest thing typically do, because they do have the decades of experience seeing how things actually fail.

1. Line of credit - we are not billed until we take delivery of tested product. 2. Willingness to handle high mix, low volume products. One product line example: a dozen SKUs with 95-98% parts in common on 2 PCBs, a single set of parts (that we aren't billed for up front) and quoting to build 20 of SKU 1, 50 of SKU 2, 10 of SKU 3, etc. without charging 2-3x the price.

We manufacture in the research / test equipment / defense space and I've heard similar things from other small hardware companies that are like us.

A new 2010 Toyota likely wouldn't even be legal to sell today in many jurisdictions, and this is in fact one part of the problem.

Another part of the problem is that all the big automakers need to design a new car roughly every 5 years in order to keep from losing the ability to design one at all, as people age and retire. What's really been settled on is that "minor updates every year and a major update every 5-6 years" actually does work in terms of keeping know-how to design these things, as well as handle supply chain problems.

For example, if a chip you need goes EOL and you have to redesign around that, it's much better to have that happen in the last 1-2 years of your manufacturing, you do a last time buy to get through that last year, and move on. Much harder to do on a longer lifecycle: that 2010 design, sold new in 2026, and operated until 2040+. How many suppliers go out of business over 30 years, or stop making a critical component?

This is especially useful when projects are wound down. Let's say you've contracted to an org for support or management on a project that you want to kill, you've already obligated some amount of funds, and you don't really want to make that organization angry by ripping millions away from them (the pool of contractors is not large). What to do? Well, you could take Joe and give him a raise by suggesting he work for the contractor instead of you directly. Money's already spent, anyways. So you save your own money that you can use for your pet projects or whatever, Joe gets a raise, the contractor doesn't get a termination that pisses everyone off. Everyone happy, right? Smh.

What about the $10k/year offshored employees that are getting replaced by AI call centers? If that were the break even, then once you close down the whole building and develop the systems to not need them, then how much would inference costs have to go up before all that gets unwound and handed back to humans? It's more than you think - there's real margin there.