Live data from Hacker News

Welcome to the New AWS AI Blog

aws.amazon.com

81–90 of 98 posts

Re: Welcome to the New AWS AI Blog

#81
post #79

I know ML is the big cheese right now, but doesn't it seem like a bad use case for the cloud? Consider: 1) Training ML models does not require network access, which is one of the biggest competitive advantages of the cloud. 2) Training ML models is typically a batch process, which benefits minimally from the scale-on-demand model of the cloud. Since the cloud premium is a significant exchange for the value that it ad…

> does not require network access > benefits minimally from scale-on-demand Neither of these is true when dealing with terabytes of data (or more, if you're working with image/video corpora). Many AI/ML problems have stages that are trivially parallelizable - if you can divide your problem into iterations where a subgraph of nodes communicates internally, then sends/receives updates to other subgraphs, it's very simi…

Good point. I've worked with lots of local exploratory machine learning (R or Spark on a single workstation), and lots of stable applications that use machine learning processes that are no longer fiddled with, but I've never witnessed the transition between the two.

Re: Welcome to the New AWS AI Blog

#82

I know ML is the big cheese right now, but doesn't it seem like a bad use case for the cloud? Consider: 1) Training ML models does not require network access, which is one of the biggest competitive advantages of the cloud. 2) Training ML models is typically a batch process, which benefits minimally from the scale-on-demand model of the cloud. Since the cloud premium is a significant exchange for the value that it ad…

I don't follow point 2, batch processes can definitely take advantage of scaling on demand. You can spin up a huge cluster, only pay for it for an hour while training, and then spin down to just what you need to serve requests for your already trained model.

Of course it depends on how much data you're training on, and how up-to-date you need your model to be.

Re: Welcome to the New AWS AI Blog

#83
post #78

We have recently set up a TensorFlow assessment function in AWS lambda, and got very close to the maximum allowed size of a lambda function (250MB) with the trained model currently being 85MB, and the TensorFlow libraries and binaries taking up another 140 or so megabytes by default ( I feel like Amazon could do some work in this area to support users to use their own engines and not be bound to AWS AI Platforms and…

I've hacked around lambda quite a bit (I think the compressed size of one function is a tad under the max allowed). My hacks I remember are: - Run strip all .so libraries -- many aren't stripped fully - In Python I manually deleted sub packages of numpy/scipy I didn't need - If you're loading large models at initialize, numpy load routines are _much_ faster than cPickle. Have it load at module initialization, not dur…

That sounds quite similar to what we're doing!

Would love to see a blog post to compare experiences..

(Speaking of blogposts.. that was somewhere on the todo list..)

Re: Welcome to the New AWS AI Blog

#84

Quick slightly unrelated question: Does anyone have a comparison of using Google cloud services vs AWS for machine learning? I'm planning to pick one, and I was leaning towards Google Cloud Services because of the TensorFlow support and the fact that Google is big on ML, making it likely that it's something that Google will support and be good at. With this blog post, I'm not sure.

On the GPU side of things, I can confirm that AWS p2.xlarge has worked well for me. It has one Tesla K80. Azure's offering is similarly priced. Back in November Google Cloud announced P100 GPUs would be available soon; that will be interesting.

https://news.ycombinator.com/item?id=13697666 :)

Re: Welcome to the New AWS AI Blog

#85

Quick slightly unrelated question: Does anyone have a comparison of using Google cloud services vs AWS for machine learning? I'm planning to pick one, and I was leaning towards Google Cloud Services because of the TensorFlow support and the fact that Google is big on ML, making it likely that it's something that Google will support and be good at. With this blog post, I'm not sure.

I've used both and both are great overall. Even if you are using TensorFlow, I would recommend AWS right now for someone just starting out because the documentation is more currently more thorough, although that will probably change. The CloudML service looks really cool (and I think it's really what everyone will ultimately use), but I hit enough problems/bugs getting my model trained and running that I plan to wait for it to come out of beta before trying again.

Re: Welcome to the New AWS AI Blog

#86

"Mark Cuban recently talked about it as the most important technology to ramp up on, to avoid becoming a “dinosaur”" I wonder if this impresses this blog's audience, or does exactly the opposite...

It's completely a typo. They meant Mark Suster, as can be seen by following the link.

Re: Welcome to the New AWS AI Blog

#87

I know ML is the big cheese right now, but doesn't it seem like a bad use case for the cloud? Consider: 1) Training ML models does not require network access, which is one of the biggest competitive advantages of the cloud. 2) Training ML models is typically a batch process, which benefits minimally from the scale-on-demand model of the cloud. Since the cloud premium is a significant exchange for the value that it ad…

Makes sense - though if you add some kind of validation to the trained model you could build a continually improving 'ground truth' and automate the training and improvement over time.

Re: Welcome to the New AWS AI Blog

#88
post #16

Earlier quoted context omitted.

AWS doesn't offer any high-level services for training your own custom model. You'd have to build the neural network yourself and deploy EC2 boxes to run it. I've had success with Clarifai's [0] custom CV model API in the past. You basically upload batches of labeled images to train a model, and then you can submit new images for classification. Of course, I have no idea how effective it would be for your documents.…

Wow, this is literally exactly what I was looking for. Thank you. Hopefully, it works well. From https://developer.clarifai.com/quick-start/ Seems simple to train // add inputs with concepts app.inputs.create([{ "url": "https://samples.clarifai.com/dog1.jpeg", "concepts": [ { "id": "cat", "value": false }, { "id": "dog", "value": true } ] }, { "url": "https://samples.clarifai.com/dog2.jpeg", "concepts": [ { "id": "ca…

I'm glad I could help! I'd actually be really curious to hear how well it works for you.

Re: Welcome to the New AWS AI Blog

#89
post #88

Earlier quoted context omitted.

Wow, this is literally exactly what I was looking for. Thank you. Hopefully, it works well. From https://developer.clarifai.com/quick-start/ Seems simple to train // add inputs with concepts app.inputs.create([{ "url": "https://samples.clarifai.com/dog1.jpeg", "concepts": [ { "id": "cat", "value": false }, { "id": "dog", "value": true } ] }, { "url": "https://samples.clarifai.com/dog2.jpeg", "concepts": [ { "id": "ca…

I'm glad I could help! I'd actually be really curious to hear how well it works for you.

I'll post results here once I get permission to bring those docs into the cloud - they are all mostly private.

Re: Welcome to the New AWS AI Blog

#90
post #78

We have recently set up a TensorFlow assessment function in AWS lambda, and got very close to the maximum allowed size of a lambda function (250MB) with the trained model currently being 85MB, and the TensorFlow libraries and binaries taking up another 140 or so megabytes by default ( I feel like Amazon could do some work in this area to support users to use their own engines and not be bound to AWS AI Platforms and…

I've hacked around lambda quite a bit (I think the compressed size of one function is a tad under the max allowed). My hacks I remember are: - Run strip all .so libraries -- many aren't stripped fully - In Python I manually deleted sub packages of numpy/scipy I didn't need - If you're loading large models at initialize, numpy load routines are _much_ faster than cPickle. Have it load at module initialization, not dur…

Just to throw this out there as another possible optimization, if you find that you're putting a big fat library into every function, one possibility is to run the library as its own lambda function. You'll be slowed down a bit by the network but it might be made up for by not having to constantly initialize the same thing.
Post reply on HN