<p>you can go in cloudwatch logs to diagnose your model failure.
Real-time inference traffic scaling can be addressed via working on 3 independent dimensions:</p>

<ol>
<li><p><strong>hardware</strong>: choosing larger machines or more
machines. For example you can <a href="https://aws.amazon.com/blogs/machine-learning/load-test-and-optimize-an-amazon-sagemaker-endpoint-using-automatic-scaling/" rel="nofollow noreferrer">load test your model endpoint</a> with bigger and bigger machines and see when hardware size gives you acceptable latency. The Autoscaling feature of SageMaker helps you address this automatically. If deploying a deep neural net, you can also consider using appropriate accelerators, eg GPU (EC2 P3, EC2 G4) or <a href="https://aws.amazon.com/blogs/machine-learning/serving-deep-learning-at-curalate-with-apache-mxnet-aws-lambda-and-amazon-elastic-inference/" rel="nofollow noreferrer">Amazon Elastic Inference Accelerator</a> to make each prediction much faster. </p></li>
<li><p><strong>software</strong>: you have 2 levers to tune here:</p>

<ul>
<li>choosing a <strong>serving stack</strong> that is lean and fast. Different servers will handle load at different levels of performance. One common trick is to batch the load - for example, instead of hitting 100 times your server can you hit it only once with a batch of 100 records? If clients cannot batch their requests, can you use micro-asynchrony so that you do the batching yourself after they issued requests? You can usually configure such micro-batching in advanced deep learning servers such as <a href="https://github.com/tensorflow/serving/tree/master/tensorflow_serving/batching" rel="nofollow noreferrer">TF Serving</a> or <a href="https://github.com/awslabs/mxnet-model-server/blob/master/docs/management_api.md#register-a-model" rel="nofollow noreferrer">MXNet Model Server</a> (both can be used in SageMaker), but otherwise you can also do it yourself by having a queue (SQS) in front of your server.</li>
<li><strong>model compilation</strong> - optimizing the model graph and its runtime. This is a very smart concept, that leverages the fact that when you know where you're going to deploy (eg NVIDIA, Intel, ARM, etc), you have an insider edge and you can refine your model artifact and create a bespoke runtime application that are tailor-made for this specific target platform. This can reduce memory consumption and latency by double-digit percentage, and is an active area of ML research. In the SageMaker ecosystem, such a compilation task can be performed with SageMaker Neo, but the open source ecosystem is developing fast, with notably treelite (<a href="https://www.sysml.cc/doc/2018/196.pdf" rel="nofollow noreferrer">paper</a>, <a href="https://treelite.readthedocs.io/en/latest/" rel="nofollow noreferrer">doc</a>) for decision tree compilation and TVM (<a href="https://arxiv.org/abs/1802.04799" rel="nofollow noreferrer">paper</a>, doc) for arbitrary neural net compilation. Both are dependencies of Neo by the way.</li>
</ul></li>
<li><p><strong>science</strong>: some models are slower or heavier than others. If speed and concurrency are your priorities over accuracy, and if you already exploited all possible tricks at level (1) and (2) above, consider using fast-throughput    models, eg linear models &amp; logistic regression for structured data, MobileNet or SqueezeNet instead of large Resnets for classification (<a href="https://gluon-cv.mxnet.io/model_zoo/classification.html" rel="nofollow noreferrer">nice benchmark here</a>), Yolov3 instead of FasterRCNN for detection (<a href="https://gluon-cv.mxnet.io/model_zoo/detection.html" rel="nofollow noreferrer">nice benchmark here</a>), etc. But be aware that unlike levels (1) and (2), changing model science will alter accuracy.</p></li>
</ol>

<p>As mentioned above, those 3 areas of improvements really are about real-time inference; if you can afford to pre-compute all possible model inputs, then the ultimate low-latency high-throughput solution is to pre-compute offline a variety of input-predictions pairs of interest and serve them on demand from a fast database or local read-only store.</p>
Sagemaker Endpoint throttling exception
<p>I have created an endpoint using Sagemaker, and designed my system so that it is called about 100 times <strong>simultaneously</strong>. This seemed to cause <em>'Model error'</em> and take too much time. Do I need to create an endpoint for each event, and make one call per endpoint, instead?</p>