What a pity Google TPUs are locked in Google Cloud - many would like to use them on their own, in already owned servers. It kind of slows the ML progress, such restriction of access to the product.
I think they mean actually buying the chips. This model of putting revolutionary new hardware in the cloud only is kind of worrisome given the future implications.
How these chips work is pretty reliant on Google's specific infrastructure and there's a stark difference between the work needed to offer a service and selling chips. It isn't a matter of bad will or trying to slow ML progress but a matter of what's practical.
Maybe Google could just license the tech to parties that would be interested in doing the hardware for the masses? Or maybe we just have to wait to see what Nvidia is brewing?
At Berkeley, we had a guest lecture where one of the major contributors in developing Google’s cloud infrastructure gave a talk on building scalability and robustness into their systems. The majority of the public facing products/services that you find on GCP actually started much earlier as internal tools for employees.
There is a huge amount of work that is put into ensuring that everything works reliably, with significant underlying infrastructure needed to achieve it. The problems you face at the level of scale Google works in on a day to day basis turns even the most mundane tasks into extraordinarily difficult algorithmic challenges that have to be solved.
I think the point is that a lot of the products and services wouldn't work outside the Google Cloud platform without a significant amount of underlying infrastructure to support it, such that it would be very difficult to just provide some ready to go package for people to buy and implement themselves.
Which is largely bullshit. There's complexity in managing failures at scale -- but strip away the scale, and you strip away the complexity in managing failures. You just get normal, bog standard server-grade hardware, with the usual downtime.
No, think about all the various services and how they're implemented. For example, for ACLs if you use an internal-facing service that itself relies on proprietary data formats, protocols, assumptions about underlying hardware, and how the API will be used (maybe there's no way to sign up users because you don't need to on a corporate network), then externalizing the ACL service itself would be a huge task in SWE-hours.
Now think about how many different internal services like that a single complex ecosystem has to touch.
Saying "software is just a binary that needs to be made compatible with X platforms" is naive. It's like saying "facebook is just a bunch of UIs with form boxes, I could write facebook." Yeah, good luck.
I haven't been at Google for years and never worked on TPUs, but off the top of my head:
They control the system attached to the chips. That includes the kernel and userland (glibc, libstdc++, etc.).
Very limited number of configurations (CPU, RAM, network, motherboard, any RDMA use) to qualify.
Monitoring, profiling, diagnostics, firmware, networking, security and automation follow the internal Google standards.
They can tune cooling to accommodate Google's motherboards and racks, whether it's air (v2) or liquid cooling (v3).
You can bet that they talk directly to the GCS backends through Stubby/gRPC, rather than sending HTTP traffic through the outside network and traversing GFEs.
Then there's all the other "mundane" stuff they don't need to worry about: packaging, manuals, warranties and user-facing RMA, multi-tenancy, etc.
As far as I'm aware, they're still on OCP, which standardizes the bulk of this. Basically, this comes down to not being willing to be bothered with testing on diverse hardware.
Years ago, Google announced they'd join OCP. I'd be surprised if even half the fleet made the transition, given how much mileage they like to get out of old hardware.
Besides, for special toys like TPU pods it's not clear that they would value adhering to OCP standards above anything else.
If you look at an image of a Cloud TPU board [0], I'm not sure how it would even work with off the shelf servers. It's 100% custom for a Google Datacenter.
Nvidia also has the full supply chain set up, as well as things like driver support and all the things required to sell this kind of complex physical hardware.
Well, you lose some performance to distributed memory overhead of course, plus the TPU measure for that number is a previous generation TPU. The new ones are a decent bit faster. Plus you get four chips per "Cloud TPU". Putting all that together, TPUs are certainly a very competitive offering.
They seem roughly comprable. If you can get 85% scale out efficiency, based on the numbers in this post, 256 V100s would be at parity with 256 TPUs. In practice, you can get 90% scale out on Resnet with last year’s GPU and networking hardware. Network bandwidth is the bottleneck, and with better network hardware that could be improved. Maybe that’s why Google didn’t publish a benchmark for 256 V100s.
I’m also curious what the is the performance of the network interconnects in the TPU pod. I couldn’t find it documented, though I didn’t look super hard.
My understanding and experience is that it is not always trivial to get linear training speedups with additional machines.
It can be sometimes hard to get any speedup at all.
The difference with gradient descent can be described simply as:
* Single-machine training: take more steps
* Distributed training: take fewer but more confident and accurate steps. This could allow you to take bigger steps (learning rate) as well, but there is a limit to this as well.
They are not equivalent processes and it is an area of active research how to get an equivalent result with distributed training.
We looked at a bunch of different model architectures and datasets and found that you can get speedups from larger batch sizes up until a certain point, but that point is different for different datasets and architectures. The range of good hyperparameters is also narrower for larger batch sizes, which makes tuning harder.
To clarify, we found the range shrink if one trains for a fixed number of epochs and expand if one trains for a fixed number of steps. So tuning can be easier or harder depending on the budget.
40 comments
[ 0.19 ms ] story [ 88.1 ms ] threadI find that hard to believe. Can you be more specific?
There is a huge amount of work that is put into ensuring that everything works reliably, with significant underlying infrastructure needed to achieve it. The problems you face at the level of scale Google works in on a day to day basis turns even the most mundane tasks into extraordinarily difficult algorithmic challenges that have to be solved.
So, by that reasoning, there is nothing that can exist outside of Google, because Google does things internally at scale.
Now think about how many different internal services like that a single complex ecosystem has to touch.
Saying "software is just a binary that needs to be made compatible with X platforms" is naive. It's like saying "facebook is just a bunch of UIs with form boxes, I could write facebook." Yeah, good luck.
They control the system attached to the chips. That includes the kernel and userland (glibc, libstdc++, etc.).
Very limited number of configurations (CPU, RAM, network, motherboard, any RDMA use) to qualify.
Monitoring, profiling, diagnostics, firmware, networking, security and automation follow the internal Google standards.
They can tune cooling to accommodate Google's motherboards and racks, whether it's air (v2) or liquid cooling (v3).
You can bet that they talk directly to the GCS backends through Stubby/gRPC, rather than sending HTTP traffic through the outside network and traversing GFEs.
Then there's all the other "mundane" stuff they don't need to worry about: packaging, manuals, warranties and user-facing RMA, multi-tenancy, etc.
Which, fair enough, is a pain.
It probably takes a lot of effort to develop Windows driver, libraries, support for many kernel version etc.
That's easy to solve: "We only support Linux. Testing has only been done on kernel 4.13."
Google's hardware layer is one thing; as btian mentioned, TPU also is deeply integrated with software infra e.g borg https://ai.google/research/pubs/pub43438
Besides, for special toys like TPU pods it's not clear that they would value adhering to OCP standards above anything else.
If you look at an image of a Cloud TPU board [0], I'm not sure how it would even work with off the shelf servers. It's 100% custom for a Google Datacenter.
Nvidia also has the full supply chain set up, as well as things like driver support and all the things required to sell this kind of complex physical hardware.
Google also has a program to give research scientists free access to TPUs: https://www.tensorflow.org/tfrc/
[0] https://storage.googleapis.com/gweb-uniblog-publish-prod/ima...
(I work on GCP, but not on ML and TPU stuff)
So a Cloud TPU chip is slower than a V100 chip? Seems like that's the answer.
I’m also curious what the is the performance of the network interconnects in the TPU pod. I couldn’t find it documented, though I didn’t look super hard.
[1] https://github.com/uber/horovod/blob/master/docs/benchmarks....
Notice how Google did not submit benchmark results for several tests.
[0] https://blogs.nvidia.com/blog/2018/12/12/record-breaking-mlp...
My understanding and experience is that it is not always trivial to get linear training speedups with additional machines.
It can be sometimes hard to get any speedup at all.
The difference with gradient descent can be described simply as:
* Single-machine training: take more steps
* Distributed training: take fewer but more confident and accurate steps. This could allow you to take bigger steps (learning rate) as well, but there is a limit to this as well.
They are not equivalent processes and it is an area of active research how to get an equivalent result with distributed training.
https://arxiv.org/abs/1811.03600
We looked at a bunch of different model architectures and datasets and found that you can get speedups from larger batch sizes up until a certain point, but that point is different for different datasets and architectures. The range of good hyperparameters is also narrower for larger batch sizes, which makes tuning harder.