The upfront cost of facility is ~30%, network infra 10-15%, land/utilities is small percentage, power could be significant for an AI DC. The servers are ~50-60% only.
They are building new datacenters for the AI demand, so around half of this CAPEX is not for the GPU-s, and those will not be replaced every 3-5 years.
Also, TPUv2 was introduced in 2018, and still not completely retired in all regions, from accounting pov, it has been written down to 0, but they are still working.
This is a good chart that shows historical CAPEX spending. Hyperscalers have been through a couple CAPEX cycles like this, they all know what they are doing.
Idk how an AWS region would respond to a power outage, but i have tested this in AWS Outpost, and there, if you power down a rack, then power it back again, the baremetal instances will not be recreated. (I was surprised as I was expecting the EC2 health check to terminate them, but it does not work like that.)
My understanding is that if you stop/start an instance, your local storage is gone (as the instance might even end up in a different host), but if you just reboot the instance, it should keep the local storage.
I'm 100% sure that all providers are playing with the quantization, kv cache and other parameters of the models to be able to serve the demand. One of the biggest advantage of running a local model is that you get predictable behavior.
Yesterday GPT 5.2 wrote a python function for me that had the import in the middle of the code, for no reason. (It was a simple import of requests module in a REST client...)
Claude I agree is a lot better for backend,Gemini is very good for frontend
You don't need hundreds of services.
Give me virtual machines, reliable block storage, file storage and object storage, networking, dns, managed kubernetes, and it will cover the majority of workloads in Europe that run on Openshift or Openstack today.
Sure, EBS or any network-attached storage is expected to be a lot slower than a local SSD for synchronous writes or random reads, as there is a network stack in between. But my understanding is that for those usecases, you can use metal instances with local nvme. (ephemeral though)
The Model3 has a dedicated button for the windscreen wiper on the steering wheel, and then you can adjust with the scroll buttons.
It certainly has a learning curve, and it would be better if you could rely on muscle memory for these things.
I usually spend a couple of minutes when I drive someone else's car to get familiar with the controls, as the rear window windscreen wiper, light controls (especially fog light) can be tricky on old cars as well.
Imho, if Tesla could train a huge neural network to demonstrate that self driving is possible with their sw stack, they would have done that already to let Elon Musk have it's road show with it's capabilities.
(Running ChatGPT does not require a supercluster, training the model does)
Telco vendors have been using Openstack for 6-8 years already, and virtualization (and even containerisation, mainly with LXC, or Solaris zones earlier) was a thing back then.
Kubernetes is also used for the last couple of years, mainly inside their VNF-s, so the transition to CNF-s is not a "sudden" thing, most modern VNF-s were running a Kubernetes cluster inside virtual machines already.
There are some exotic scenarios, where copy-paste is the good(fast) solution.
For example, one of my clients can be accessed via a VPN. Once I'm on the VPN, I have to start their VDI. Inside the VDI, I need to start another VPN, that then allows me to open a Putty session to a bastion host, that I can use to reach my destination cluster. Believe it or not, they don't want to make it simpler.
Copy/paste works flawlessly through the VDI into the putty session, so I usually just uuencode my blob, and copy it to destination cluster and uudecode there, instead of uploading the file to the VDI, then pscp to the bastion host, and then scp to the destination cluster. (I know of zmodem, port forwarding and such, none of this is allowed...)