Triton V1 and V2: For the 20.07 release, a legacy V1 version of Triton will be released from this branch. The V1 version of Triton is deprecated and no releases beyond 20.07 are planned. Going forward Triton V2 will continue monthly releases as described on branch master.

NVIDIA Triton Inference Server provides a cloud inferencing solution optimized for NVIDIA GPUs. The server provides an inference service via an HTTP or GRPC endpoint, allowing remote clients to request inferencing for any model being managed by the server. For edge deployments, Triton Server is also available as a shared library with an API that allows the full functionality of the server to be included directly in an application.

• Support for the legacy V1 HTTP/REST, GRPC and corresponding client libraries is released on GitHub branch r20.07-v1 and as NGC container 20.07-v1-py3.

• Multiple framework support. The server can manage any number and mix of models (limited by system disk and memory resources). Supports TensorRT, TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch, and Caffe2 NetDef model formats. Also supports TensorFlow-TensorRT and ONNX-TensorRT integrated models. Variable-size input and output tensors are allowed if supported by the framework. See Capabilities for detailed support information for each framework.
• Concurrent model execution support. Multiple models (or multiple instances of the same model) can run simultaneously on the same GPU.
• Batching support. For models that support batching, Triton Server can accept requests for a batch of inputs and respond with the corresponding batch of outputs. Triton Server also supports multiple scheduling and batching algorithms that combine individual inference requests together to improve inference throughput. These scheduling and batching decisions are transparent to the client requesting inference.
• Custom backend support. Triton Server allows individual models to be implemented with custom backends instead of by a deep-learning framework. With a custom backend a model can implement any logic desired, while still benefiting from the GPU support, concurrent execution, dynamic batching and other features provided by the server.
• Ensemble support. An ensemble represents a pipeline of one or more models and the connection of input and output tensors between those models. A single inference request to an ensemble will trigger the execution of the entire pipeline.
• Multi-GPU support. Triton Server can distribute inferencing across all system GPUs.
• Triton Server provides multiple modes for model management. These model management modes allow for both implicit and explicit loading and unloading of models without requiring a server restart.
• Model repositories may reside on a locally accessible file system (e.g. NFS), in Google Cloud Storage or in Amazon S3.
• Readiness and liveness health endpoints suitable for any orchestration or deployment framework, such as Kubernetes.
• Metrics indicating GPU utilization, server throughput, and server latency.
• C library inferface allows the full functionality of Triton Server to be included directly in an application.

The current release of the Triton Inference Server is 1.15.0 and corresponds to the 20.07 V1 release of the tensorrtserver container on NVIDIA GPU Cloud (NGC). The branch for this release is r20.07-v1.

Continuing in the latest version the following interfaces maintain backwards compatibilty with the 1.0.0 release. If you have model configuration files, custom backends, or clients that use the inference server HTTP or GRPC APIs (either directly or through the client libraries) from releases prior to 1.0.0 you should edit and rebuild those as necessary to match the version 1.0.0 APIs.

The following inferfaces will maintain backwards compatibility for all future 1.x.y releases (see below for exceptions):

• Model configuration as defined in model_config.proto.
• The inference server HTTP and GRPC APIs as defined in api.proto and grpc_service.proto, except as noted below.
• The V1 and V2 custom backend interfaces as defined in custom.h.

As new features are introduced they may temporarily have beta status where they are subject to change in non-backwards-compatible ways. When they exit beta they will conform to the backwards-compatibility guarantees described above. Currently the following features are in beta:

• The inference server library API as defined in trtserver.h is currently in beta and may undergo non-backwards-compatible changes.
• The C++ and Python client libraries are not stictly included in the inference server compatibility guarantees and so should be considered as beta status.

The User Guide, Developer Guide, and API Reference documentation for the current release provide guidance on installing, building, and running Triton Inference Server.

You can also view the documentation for the master branch and for earlier releases.

An FAQ provides answers for frequently asked questions.

READMEs for deployment examples can be found in subdirectories of deploy/, for example, deploy/single_server/README.rst.

The Release Notes and Support Matrix indicate the required versions of the NVIDIA Driver and CUDA, and also describe which GPUs are supported by Triton Server.

• High-Performance Inferencing at Scale Using the TensorRT Inference Server.
• Accelerate and Autoscale Deep Learning Inference on GPUs with KFServing.
• Deep into Triton Inference Server: BERT Practical Deployment on NVIDIA GPU.
• Maximizing Utilization for Data Center Inference with TensorRT Inference Server.
• NVIDIA TensorRT Inference Server Boosts Deep Learning Inference.
• GPU-Accelerated Inference for Kubernetes with the NVIDIA TensorRT Inference Server and Kubeflow.

Contributions to Triton Inference Server are more than welcome. To contribute make a pull request and follow the guidelines outlined in the Contributing document.

We appreciate any feedback, questions or bug reporting regarding this project. When help with code is needed, follow the process outlined in the Stack Overflow (https://stackoverflow.com/help/mcve) document. Ensure posted examples are:

• minimal – use as little code as possible that still produces the same problem
• complete – provide all parts needed to reproduce the problem. Check if you can strip external dependency and still show the problem. The less time we spend on reproducing problems the more time we have to fix it
• verifiable – test the code you're about to provide to make sure it reproduces the problem. Remove all other problems that are not related to your request/question.