Announcing New AWS Deep Learning AMI for Amazon EC2 P3 Instances

We’re pleased to announce a new set of AWS Deep Learning AMIs, which come pre-installed with deep learning frameworks optimized for the NVIDIA Volta V100 GPUs in the new Amazon EC2 P3 instance family.

The new P3 instances are perfect for deep learning, with eight NVIDIA Volta GPUs available in a single p3.16xlarge instance, which is capable of 125 trillion single-precision floating-point operations per second. This dramatically reduces the training time for sophisticated deep learning models, from days to just hours.

Deep Learning AMIs: Now with CUDA 9 for Volta

The new AMIs are pre-installed and configured with CUDA 9 for both Ubuntu and Amazon Linux, along with the other GPU drivers to take advantage of the speed of Volta on P3, including cuDNN 7.0, NCCL 2.0.5 and the NVIDIA Driver 384.81. 

Deep learning frameworks optimized for Volta

In addition to the latest drivers, the AMI also includes popular frameworks which have been optimized for P3 and Volta. Volta is brand new, and so this first release of the new CUDA 9 AMIs includes frameworks which were built from source, using the latest available versions. It’s still super-early for Volta, and so while we expect the frameworks to continue to evolve in terms of stability and performance over time, these latest versions will provide significant performance improvements in training time. That said, some of these builds are from the bleeding edge, so test before you put them into production. You can help them all get better by sending feedback to the open source projects as you run your experiments on P3.

Apache MXNet v0.12 RC1: Training convolutional neural networks is up to 3.5 times faster than the Pascal GPUs when using float16. Full release notes for MXNet version 0.12 are available here.

Caffe2 v0.8.1: With FP16 support, Caffe2 allows developers using NVIDIA Tesla V100 GPUs to maximize the performance of their deep learning workloads.

TensorFlow (master): We include a version of TensorFlow built from the master as of 11am on 24^th October, 2017 (commit: 5bef42), and included 8 patches from NVIDIA for Volta support. In our initial testing, this build shows 3 times the training performance on a p3.16xlarge compared to the latest official release (TensorFlow 1.3), on p2.16xlarge.

Gluon: As with previous versions, these AMIs includes Gluon, a new open source deep learning interface which allows developers to easily and quickly build machine learning models, without compromising training speed. You can read more about Gluon in our launch announcement, and get started with over 50 notebooks with sample code. 

Selecting the right AMI for the job

Getting started with the AWS Deep Learning AMI is simple. You can start with just one click from the AWS Marketplace or follow this step-by-step guide to get started with your first notebook.

The CUDA 9 AMI is available in the following versions:

• Deep Learning AMI CUDA 9 Ubuntu Version
• Deep Learning AMI CUDA 9 Amazon Linux Version

We’ll add additional frameworks as they become available for Volta. The CUDA 8 AMIs are still maintained and available, and include the latest stable, official “point” releases for TensorFlow, MXNet, Caffe, Caffe 2, Microsoft Cognitive Toolkit (CNTK) and Keras. The CUDA 8 AMI is available in the following versions:

• Deep Learning AMI CUDA 8 Ubuntu Version
• Deep Learning AMI CUDA 8 Amazon Linux Version

Join us at AWS Re:Invent 2017

If you’re interested in learning more about deep learning, don’t forget to also check out our Guide to Machine Learning at re:Invent, November 27 to December 1, 2017. At the re:Invent conference you can explore over 50 machine learning sessions, workshops, and labs as well as attend our inaugural Deep Learning Summit for perspectives on the future of deep learning.

 

Powered by WPeMatico

The post Announcing New AWS Deep Learning AMI for Amazon EC2 P3 Instances appeared first on Artificial Intelligence Solutions.

Read More...

How Astro Built Astrobot Voice, a Chatbot for Email

This is a guest post by Roland Schemers, CTO of Astro Technology, Inc. Astro, in their own words, “creates modern email apps for Mac, iOS and Android, powered by artificial intelligence, built for people and teams. With Astrobot Voice, an in-app email voice assistant, you can now read, manage, and reply to emails without leaving Astro’s apps.”

Recently, Astro launched Astrobot Voice, the first in-app email voice assistant. This means you can now read, manage, and reply to emails without leaving Astro’s iOS or Android apps.

After Astro launched an Amazon Alexa skill in June, we were eager to enable more people to manage email with voice. In this post, we’ll give a technical breakdown of why we went down this path, how we accomplished this, and what technology we used.

Why build in-app voice?

We’re owners and fans of Amazon Echo—we actually give an Echo Dot to every new Astro employee, as a way to say “welcome” and to dogfood our own Alexa skill .We saw the success of the skill, and thought of ways we could engage with more people, in more places. So we decided to explore the feasibility of building in-app voice.

Selecting software

When determining how to build in-app voice, we considered a number of options, but had a few goals in mind:

1. Reuse as much code and logic as possible from either our text-based assistant (running on api.ai) or our Alexa skill.
2. Create a smooth user experience with accurate voice recognition.
3. Let the server do the heavy lifting.

The first goal was important given our timeline and engineering resources. We are a small startup and time savings like these go a long way.

The second goal of creating a smooth user experience was particularly challenging. Amazon Alexa has a definite leg up on Natural Language Processing due to scale. So, in trying to make an experience that felt accurate, we knew we wanted to leverage the AWS services and the deep learning technologies behind them.

For the third goal, we knew Astrobot Voice required a combination of OS-level APIs and server-side development. For our initial implementation, we decided to make sure the server was doing most of the heavy lifting, while keeping in mind costs. The benefits of the server doing the most of the work include shared code for both our iOS and Android apps, and also the ability to make changes to the flow on the server without needing to push updated versions of the Astro apps to the app stores.

The stack

iOS

For our iOS API for voice recognition, we used AVSpeechSynthesizer and SFSpeechRecognizer. SFSpeechRecognizer is only available for iOS 10+, so Astrobot Voice is only available on iOS 10 and 11. This could be a limiting factor for some app developers, but works for us.

Android

For Android, we used the standard Android API for voice recognition, which includes Speech Recognizer and Text To Speech.

For both iOS and Android, we had the option of sending the server recorded text or a text string. We decided to go with the latter option due to cost, time constraints, and latency.

Server

On the server side, we used Amazon Lex. Choosing Amazon Lex over api.ai let us reuse and share of a lot of the same logic we already had for Alexa. While we could have reused some of the logic for the text-based version of Astrobot, ultimately we decided we’d save more time and provide a better experience using Amazon Lex. We estimate this saved us 2-4 weeks of a single developer’s time. As we further develop Astrobot Voice and our Alexa skill, we’ll continue to save time due to this decision.

In the future, when we offer a paid version of Astro (currently our apps are free), we plan to take advantage of more AWS services by replacing our on-device speech recognition with Amazon Lex for voice input and Amazon Polly for voice output. This will improve the quality of the bot experience.

Here’s the flow and an architecture diagram of how these services work together to create the Astrobot Voice experience:

Advice to in-app voice developers

First, make sure your service or app lends itself to voice. Adding voice to certain apps right now likely isn’t a priority given the state of voice. Despite the availability of natural language understanding and automatic speech recognition, voice still isn’t the default way of using apps. So, your use case needs to be a fairly obvious one to get traction and bubble to the top of your product roadmap. We saw a very clear use case for email and voice at home, for example, while getting ready for the day or in the car.

Second, we recommend really considering the technology you use, and not reinventing the wheel yourself. There are lots of services and resources to make the development process easier and to get an MVP out into the world. The flipside of that is making sure you have good abstraction on the server side, so you’re not locked into a particular service for intent detection. Since these services are still fairly new and, therefore, constantly evolving, you might eventually (or even quickly) need to switch services. For Astrobot (both voice and text based) we’ve tried Luis.ai, wit.ai, api.ai, and now Amazon Lex without needing to make significant changes to our server logic.

We’re excited to be the first email app with a voice assistant built in, and look forward to seeing other apps make progress on voice. In many cases, voice is a much faster way to retrieve information and create new information and we’re anxious to see what’s next.

Powered by WPeMatico

The post How Astro Built Astrobot Voice, a Chatbot for Email appeared first on Artificial Intelligence Solutions.

Read More...