Train TensorFlow models faster and at lower cost on Cloud TPU Pods | Hacker News Reader

Train TensorFlow models faster and at lower cost on Cloud TPU Pods

cloud.google.com

105 pointsfrankchn38 comments

Does this require distributed training?

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.

I worked on a research project that set out to answer that question:

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.

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.

Full ML Perf results can be found here: https://mlperf.org/results/

Julia runs on these ;). Well, it will once multicore access for non-TF frameworks is public.

We're on it! = D

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.

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.

> How these chips work is pretty reliant on Google's specific infrastructure.

I find that hard to believe. Can you be more specific?

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.

Which, fair enough, is a pain.

Google isn't on OCP afaik. Their hardware layer is pretty custom. Maybe you were thinking of Facebook?

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

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.

https://www.opencompute.org/membership/membership-organizati...

Not just hardware. TPU probably was only tested to work on one kernel version, one compiler, one version of GRPC etc.

It probably takes a lot of effort to develop Windows driver, libraries, support for many kernel version etc.

> 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."

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.

...er.

So, by that reasoning, there is nothing that can exist outside of Google, because Google does things internally at scale.

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.

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?

Agreed. TPU will come on premise when Google launches a similar offering to AWS Outposts and ships you an appliance.

Probably not what you are looking for, but: https://cloud.google.com/edge-tpu/

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)

You can also use Cloud TPUs for free in your browser via Colab. Several sample notebooks are available here: https://www.tensorflow.org/tfrc/

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.

"Revolutionary"

Curious what will be the answer from Nvidia.

This is what NVidia says [0].

Notice how Google did not submit benchmark results for several tests.

[0] https://blogs.nvidia.com/blog/2018/12/12/record-breaking-mlp...

NVidia won RESNET-50 benchmark with 80 nodes of DGX-1, curious if it is accessible in the cloud, and how much it will cost to rent it..

Indeed, all of this is but more examples of lies, damned lies, and benchmarks...

> the largest Cloud TPU Pod configuration tested (256 chips) delivers a 200X speedup over an individual V100 GPU

So a Cloud TPU chip is slower than a V100 chip? Seems like that's the answer.

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.

[1] https://github.com/uber/horovod/blob/master/docs/benchmarks....

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.

Their existing cards?

I thought TPUs were mostly used for inference, because they're low- precision. Has that changed?

Yep. That was the first generation that was only for inference. Subsequent generations can do inference and training.

TF only? Any reason why, besides Google tech lock in?

Reply on news.ycombinator.com