The first stage of the process is to take a vanilla CoreOS host and inject the CUDA drivers (one time process). After that, you can reboot the box and still retain the devices, for mapping into docker containers.
The approach is a bit different depending on your host operating system. You'll also find there are constraints when you introduce a virtualisation layer, like virtualbox or parallels on your desktop - GPUs can be mapped through, but it's painful(ish).
My money (not a billion) is on "Open, Big Learning".
Elon will probably want to build a giga-factory of neurons, then open-source some pre-trained, general model with a free API.
This is a man building electric cars, off-grid industrial-strength batteries, rockets and hyper-loops...I don't think publishing more/better research papers or winning kaggle competitions is the vision.
Awesome work, Murray (and your team). Any chance the data will be anonymised and made open? The report is great but it leaves me wanting more answers! I'm sure many folks would be happy to trawl through the dataset on their own.
Will definitely be participating next year! When do you plan to run the survey?
Agree - we crunched the numbers and came up with the same figures to do-it-yourself (~USD$9K). Although, I remember from the day this was announced (few months back) that Nvidia were loud-and-proud that they weren't going to make money from this. Each box was hand built and tested, so not deemed to be a large-scale device - they recognized that it's a niche market.
$15K is probably OK(ish) if you figure in your own time for the DIY build...probably a few days. Plus you get some vendor support, warranty on the whole package, certified working stack, future test-bed for CUDA updgrades (will work first), etc as you say.
In wild agreement. Save maybe 30% doing a custom build...so they aren't adding a huge mark-up, as they would for a gaming machine. Apparently...someone at Nvidia is looking a bit further into the future than just the short-term revenue.
Yes, sometimes development/testing for new kubernetes features 'feels' like it's focussed-first on GCE functionality (before other platforms) and earlier on, it had some hooks that weren't great (like GCE-only external load balancers and storage). But hey, it's not even v1.0 yet - and all those things are either fixed or being worked on already.
And as a non-GCE user, you aren't a second-class citizen. It works everywhere.
We've deployed successfully in AWS, vagrant and bare-metal (in the garage), so far. All with 'one-command' automated deployment and re-use of our pod & service specs throughout.
Roadmap/Architecture-wise, it would be good to see a more 'pluggable' approach for 3rd party integration (more like an Open Stack model), but again, we're still pre-v1.0...
Also, I think the google-folk here are being very 'reasonable' in their replies. Your comment was mis-directed & ill-informed. Go do some reading or watch Kelsey Hightower's presentation from a couple of months ago:
Font-resizing would be nice on the visual view. And killer feature would be two way interaction, but I can imagine that's a tricky one.
Here's a generic "SaaS subscription workflow" I made up in about 20 mins.
https://code2flow.com/NDIQIf
Love it!