LogoLogo
Continuum WebsiteContinuum ApplicationsContinuum KnowledgeAxolotl Platform
Continuum Knowledge
Continuum Knowledge
  • Continuum
  • Data
    • Datasets
      • Pre Training Data
      • Types of Fine Tuning
      • Self Instruct Paper
      • Self-Alignment with Instruction Backtranslation
      • Systematic Evaluation of Instruction-Tuned Large Language Models on Open Datasets
      • Instruction Tuning
      • Instruction Fine Tuning - Alpagasus
      • Less is More For Alignment
      • Enhanced Supervised Fine Tuning
      • Visualising Data using t-SNE
      • UMAP: Uniform Manifold Approximation and Projection for Dimension Reduction
      • Training and Evaluation Datasets
      • What is perplexity?
  • MODELS
    • Foundation Models
      • The leaderboard
      • Foundation Models
      • LLama 2 - Analysis
      • Analysis of Llama 3
      • Llama 3.1 series
      • Google Gemini 1.5
      • Platypus: Quick, Cheap, and Powerful Refinement of LLMs
      • Mixtral of Experts
      • Mixture-of-Agents (MoA)
      • Phi 1.5
        • Refining the Art of AI Training: A Deep Dive into Phi 1.5's Innovative Approach
      • Phi 2.0
      • Phi-3 Technical Report
  • Training
    • The Fine Tuning Process
      • Why fine tune?
        • Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?
        • Explanations in Fine Tuning
      • Tokenization
        • Tokenization Is More Than Compression
        • Tokenization - SentencePiece
        • Tokenization explore
        • Tokenizer Choice For LLM Training: Negligible or Crucial?
        • Getting the most out of your tokenizer for pre-training and domain adaptation
        • TokenMonster
      • Parameter Efficient Fine Tuning
        • P-Tuning
          • The Power of Scale for Parameter-Efficient Prompt Tuning
        • Prefix-Tuning: Optimizing Continuous Prompts for Generation
        • Harnessing the Power of PEFT: A Smarter Approach to Fine-tuning Pre-trained Models
        • What is Low-Rank Adaptation (LoRA) - explained by the inventor
        • Low Rank Adaptation (Lora)
        • Practical Tips for Fine-tuning LMs Using LoRA (Low-Rank Adaptation)
        • QLORA: Efficient Finetuning of Quantized LLMs
        • Bits and Bytes
        • The Magic behind Qlora
        • Practical Guide to LoRA: Tips and Tricks for Effective Model Adaptation
        • The quantization constant
        • QLORA: Efficient Finetuning of Quantized Language Models
        • QLORA and Fine-Tuning of Quantized Language Models (LMs)
        • ReLoRA: High-Rank Training Through Low-Rank Updates
        • SLoRA: Federated Parameter Efficient Fine-Tuning of Language Models
        • GaLora: Memory-Efficient LLM Training by Gradient Low-Rank Projection
      • Hyperparameters
        • Batch Size
        • Padding Tokens
        • Mixed precision training
        • FP8 Formats for Deep Learning
        • Floating Point Numbers
        • Batch Size and Model loss
        • Batch Normalisation
        • Rethinking Learning Rate Tuning in the Era of Language Models
        • Sample Packing
        • Gradient accumulation
        • A process for choosing the learning rate
        • Learning Rate Scheduler
        • Checkpoints
        • A Survey on Efficient Training of Transformers
        • Sequence Length Warmup
        • Understanding Training vs. Evaluation Data Splits
        • Cross-entropy loss
        • Weight Decay
        • Optimiser
        • Caching
      • Training Processes
        • Extending the context window
        • PyTorch Fully Sharded Data Parallel (FSDP)
        • Train Short, Test Long: Attention with Linear Biases Enables Input Length Extrapolation
        • YaRN: Efficient Context Window Extension of Large Language Models
        • Sliding Window Attention
        • LongRoPE
        • Reinforcement Learning
        • An introduction to reinforcement learning
        • Reinforcement Learning from Human Feedback (RLHF)
        • Direct Preference Optimization: Your Language Model is Secretly a Reward Model
  • INFERENCE
    • Why is inference important?
      • Grouped Query Attention
      • Key Value Cache
      • Flash Attention
      • Flash Attention 2
      • StreamingLLM
      • Paged Attention and vLLM
      • TensorRT-LLM
      • Torchscript
      • NVIDIA L40S GPU
      • Triton Inference Server - Introduction
      • Triton Inference Server
      • FiDO: Fusion-in-Decoder optimised for stronger performance and faster inference
      • Is PUE a useful measure of data centre performance?
      • SLORA
  • KNOWLEDGE
    • Vector Databases
      • A Comprehensive Survey on Vector Databases
      • Vector database management systems: Fundamental concepts, use-cases, and current challenges
      • Using the Output Embedding to Improve Language Models
      • Decoding Sentence-BERT
      • ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT
      • SimCSE: Simple Contrastive Learning of Sentence Embeddings
      • Questions Are All You Need to Train a Dense Passage Retriever
      • Improving Text Embeddings with Large Language Models
      • Massive Text Embedding Benchmark
      • RocketQAv2: A Joint Training Method for Dense Passage Retrieval and Passage Re-ranking
      • LLM2Vec: Large Language Models Are Secretly Powerful Text Encoders
      • Embedding and Fine-Tuning in Neural Language Models
      • Embedding Model Construction
      • Demystifying Embedding Spaces using Large Language Models
      • Fine-Tuning Llama for Multi-Stage Text Retrieval
      • Large Language Model Based Text Augmentation Enhanced Personality Detection Model
      • One Embedder, Any Task: Instruction-Finetuned Text Embeddings
      • Vector Databases are not the only solution
      • Knowledge Graphs
        • Harnessing Knowledge Graphs to Elevate AI: A Technical Exploration
        • Unifying Large Language Models and Knowledge Graphs: A Roadmap
      • Approximate Nearest Neighbor (ANN)
      • High Dimensional Data
      • Principal Component Analysis (PCA)
      • Vector Similarity Search - HNSW
      • FAISS (Facebook AI Similarity Search)
      • Unsupervised Dense Retrievers
    • Retrieval Augmented Generation
      • Retrieval-Augmented Generation for Large Language Models: A Survey
      • Fine-Tuning or Retrieval?
      • Revolutionising Information Retrieval: The Power of RAG in Language Models
      • A Survey on Retrieval-Augmented Text Generation
      • REALM: Retrieval-Augmented Language Model Pre-Training
      • Retrieve Anything To Augment Large Language Models
      • Generate Rather Than Retrieve: Large Language Models Are Strong Context Generators
      • Active Retrieval Augmented Generation
      • DSPy: LM Assertions: Enhancing Language Model Pipelines with Computational Constraints
      • DSPy: Compiling Declarative Language Model Calls
      • DSPy: In-Context Learning for Extreme Multi-Label Classification
      • Optimizing Instructions and Demonstrations for Multi-Stage Language Model Programs
      • HYDE: Revolutionising Search with Hypothetical Document Embeddings
      • Enhancing Recommender Systems with Large Language Model Reasoning Graphs
      • Retrieval Augmented Generation (RAG) versus fine tuning
      • RAFT: Adapting Language Model to Domain Specific RAG
      • Summarisation Methods and RAG
      • Lessons Learned on LLM RAG Solutions
      • Stanford: Retrieval Augmented Language Models
      • Overview of RAG Approaches with Vector Databases
      • Mastering Chunking in Retrieval-Augmented Generation (RAG) Systems
    • Semantic Routing
    • Resource Description Framework (RDF)
  • AGENTS
    • What is agency?
      • Rephrase and Respond: Let Large Language Models Ask Better Questions for Themselves
      • Types of Agents
      • The risk of AI agency
      • Understanding Personality in Large Language Models: A New Frontier in AI Psychology
      • AI Agents - Reasoning, Planning, and Tool Calling
      • Personality and Brand
      • Agent Interaction via APIs
      • Bridging Minds and Machines: The Legacy of Newell, Shaw, and Simon
      • A Survey on Language Model based Autonomous Agents
      • Large Language Models as Agents
      • AI Reasoning: A Deep Dive into Chain-of-Thought Prompting
      • Enhancing AI Reasoning with Self-Taught Reasoner (STaR)
      • Exploring the Frontier of AI: The "Tree of Thoughts" Framework
      • Toolformer: Revolutionising Language Models with API Integration - An Analysis
      • TaskMatrix.AI: Bridging Foundational AI Models with Specialised Systems for Enhanced Task Completion
      • Unleashing the Power of LLMs in API Integration: The Rise of Gorilla
      • Andrew Ng's presentation on AI agents
      • Making AI accessible with Andrej Karpathy and Stephanie Zhan
  • Regulation and Ethics
    • Regulation and Ethics
      • Privacy
      • Detecting AI Generated content
      • Navigating the IP Maze in AI: The Convergence of Blockchain, Web 3.0, and LLMs
      • Adverse Reactions to generative AI
      • Navigating the Ethical Minefield: The Challenge of Security in Large Language Models
      • Navigating the Uncharted Waters: The Risks of Autonomous AI in Military Decision-Making
  • DISRUPTION
    • Data Architecture
      • What is a data pipeline?
      • What is Reverse ETL?
      • Unstructured Data and Generatve AI
      • Resource Description Framework (RDF)
      • Integrating generative AI with the Semantic Web
    • Search
      • BM25 - Search Engine Ranking Function
      • BERT as a reranking engine
      • BERT and Google
      • Generative Engine Optimisation (GEO)
      • Billion-scale similarity search with GPUs
      • FOLLOWIR: Evaluating and Teaching Information Retrieval Models to Follow Instructions
      • Neural Collaborative Filtering
      • Federated Neural Collaborative Filtering
      • Latent Space versus Embedding Space
      • Improving Text Embeddings with Large Language Models
    • Recommendation Engines
      • On Interpretation and Measurement of Soft Attributes for Recommendation
      • A Survey on Large Language Models for Recommendation
      • Model driven recommendation systems
      • Recommender AI Agent: Integrating Large Language Models for Interactive Recommendations
      • Foundation Models for Recommender Systems
      • Exploring the Impact of Large Language Models on Recommender Systems: An Extensive Review
      • AI driven recommendations - harming autonomy?
    • Logging
      • A Taxonomy of Anomalies in Log Data
      • Deeplog
      • LogBERT: Log Anomaly Detection via BERT
      • Experience Report: Deep Learning-based System Log Analysis for Anomaly Detection
      • Log-based Anomaly Detection with Deep Learning: How Far Are We?
      • Deep Learning for Anomaly Detection in Log Data: A Survey
      • LogGPT
      • Adaptive Semantic Gate Networks (ASGNet) for log-based anomaly diagnosis
  • Infrastructure
    • The modern data centre
      • Enhancing Data Centre Efficiency: Strategies to Improve PUE
      • TCO of NVIDIA GPUs and falling barriers to entry
      • Maximising GPU Utilisation with Kubernetes and NVIDIA GPU Operator
      • Data Centres
      • Liquid Cooling
    • Servers and Chips
      • The NVIDIA H100 GPU
      • NVIDIA H100 NVL
      • Lambda Hyperplane 8-H100
      • NVIDIA DGX Servers
      • NVIDIA DGX-2
      • NVIDIA DGX H-100 System
      • NVLink Switch
      • Tensor Cores
      • NVIDIA Grace Hopper Superchip
      • NVIDIA Grace CPU Superchip
      • NVIDIA GB200 NVL72
      • Hopper versus Blackwell
      • HGX: High-Performance GPU Platforms
      • ARM Chips
      • ARM versus x86
      • RISC versus CISC
      • Introduction to RISC-V
    • Networking and Connectivity
      • Infiniband versus Ethernet
      • NVIDIA Quantum InfiniBand
      • PCIe (Peripheral Component Interconnect Express)
      • NVIDIA ConnectX InfiniBand adapters
      • NVMe (Non-Volatile Memory Express)
      • NVMe over Fabrics (NVMe-oF)
      • NVIDIA Spectrum-X
      • NVIDIA GPUDirect
      • Evaluating Modern GPU Interconnect
      • Scalable Hierarchical Aggregation and Reduction Protocol (SHARP)
      • Next-generation networking in AI environments
      • NVIDIA Collective Communications Library (NCCL)
    • Data and Memory
      • NVIDIA BlueField Data Processing Units (DPUs)
      • Remote Direct Memory Access (RDMA)
      • High Bandwidth Memory (HBM3)
      • Flash Memory
      • Model Requirements
      • Calculating GPU memory for serving LLMs
      • Transformer training costs
      • GPU Performance Optimisation
    • Libraries and Complements
      • NVIDIA Base Command
      • NVIDIA AI Enterprise
      • CUDA - NVIDIA GTC 2024 presentation
      • RAPIDs
      • RAFT
    • Vast Data Platform
      • Vast Datastore
      • Vast Database
      • Vast Data Engine
      • DASE (Disaggregated and Shared Everything)
      • Dremio and VAST Data
    • Storage
      • WEKA: A High-Performance Storage Solution for AI Workloads
      • Introduction to NVIDIA GPUDirect Storage (GDS)
        • GDS cuFile API
      • NVIDIA Magnum IO GPUDirect Storage (GDS)
      • Vectors in Memory
Powered by GitBook
LogoLogo

Continuum - Accelerated Artificial Intelligence

  • Continuum Website
  • Axolotl Platform

Copyright Continuum Labs - 2023

On this page
  • Key Concepts for Optimising Triton Server
  • Additional Insights and Perspectives
  • Making Inference Requests
  • Understanding Endpoints in Triton Inference Server
  • Creating APIs for Inference Requests
  • Practical Example: Image Classification
  • Monitor Model Metrics
  • Secure the Inference Server
  • Additional Insights

Was this helpful?

  1. INFERENCE
  2. Why is inference important?

Triton Inference Server

PreviousTriton Inference Server - IntroductionNextFiDO: Fusion-in-Decoder optimised for stronger performance and faster inference

Last updated 11 months ago

Was this helpful?

The article by Tan Pengshi Alvin, published in Towards Data Science, provides a detailed guide on optimising the throughput and latency of model inference using NVIDIA's Triton Inference Server, particularly when dealing with high client-server traffic.

Here's an analysis of the key concepts presented in the article along with additional insights:

Key Concepts for Optimising Triton Server

Latency and Throughput Understanding

  • The author emphasises the importance of understanding latency (time taken for a request-response loop) and throughput (amount of incoming requests processed in a time instance) in managing server performance.

Use of NVIDIA Triton Server

  • The article highlights Triton's ability to handle dynamic batch inferencing and concurrency in model inference, which optimises throughput.

TensorRT Integration

  • Integrating TensorRT with Triton is suggested as a method to reduce latency. TensorRT optimises deep learning models for inference, making them faster and more efficient.

Model Conversion and Optimisation

  • The process involves converting TensorFlow models to ONNX format, then to TensorRT models using Docker containers. This approach ensures compatibility with Triton's framework and leverages TensorRT's optimisation capabilities.

Local Directory Setup for Triton Server

  • Setting up a local directory structure and configuration file (config.pbtxt) as per Triton's requirements is crucial for successful deployment.

Additional Insights and Perspectives

Model Conversion Challenges

  • The need to convert models to specific formats (ONNX, TensorRT) indicates a complexity in deployment, highlighting the importance of understanding various model formats and their compatibility with different serving platforms.

Performance Caveats

  • While Triton offers significant advantages in batch processing and handling multiple requests, the author notes that Triton TensorRT might be slower than local TensorRT for single inferences due to network overheads. This highlights the trade-offs between different deployment strategies.

Scalability and Flexibility

  • Triton's ability to dynamically adjust to varying traffic and load is crucial for scalable AI applications, especially in environments with fluctuating request volumes.

Client-Side Considerations

  • The discussion on client-side inference code emphasises the need for client-server coordination and the importance of client-side setup in the overall performance of the server.

Making Inference Requests

The process of making inference requests to the Triton Inference Server is critical for evaluating the performance of deployed models. The example provided demonstrates a straightforward method to send an inference request using the HTTP v2 API. Here are some additional details and considerations:

Request Structure

  • The request is sent to /v2/models/<model_name>/infer where <model_name> should be replaced with the actual name of the deployed model.

  • The request body must correctly specify the input tensor's name, shape, datatype, and the actual data to be inferred.

Data Preparation

  • In the provided script, <input_data> should be the actual data for inference. This data often needs preprocessing to match the input format expected by the model (e.g., image normalisation, resizing).

Handling Different Data Types

  • While the example uses FP32 (floating-point 32-bit), depending on the model, other data types like INT8 (integer 8-bit) may be used, particularly in optimised models for faster inference.

Batch Inference

  • The script can be modified to send multiple data inputs in a batch for efficient processing, reducing the per-instance inference time.

Error Handling

  • Robust error handling should be incorporated to manage scenarios where the server is unreachable, the model is not found, or the input data format is incorrect.

Understanding Endpoints in Triton Inference Server

Endpoint Basics

  • In Triton Inference Server, an endpoint is a specific URI (Uniform Resource Identifier) where clients can send requests for model inference.

  • For instance, the endpoint for making an inference request typically looks like /v2/models/<model_name>/infer, where <model_name> is the name of the model you want to infer with.

HTTP v2 API

  • Triton supports the HTTP v2 inference protocol, which allows clients to make HTTP POST requests to the server.

  • This protocol is designed to be simple yet flexible, enabling clients to send requests and receive responses over standard HTTP.

Creating APIs for Inference Requests

To create an API for making inference requests, you would typically write a client script or program that sends HTTP requests to the Triton server. Here's a step-by-step breakdown using Python as an example:

Request URL

  • Construct the request URL using the model name: http://localhost:8000/v2/models/my_model/infer. Replace my_model with your specific model name.

Request Body

  • Prepare the request body, including the name, shape, datatype, and data for the input tensor. For example, if you're sending an image, you would preprocess the image to match the input format that the model expects (like resizing, normalisation).

Sending the Request

  • Use a library like requests in Python to send the POST request to the server. Include the URL, request body, and necessary headers (like Content-Type: application/json).

Handling the Response

  • Process the server's response, which typically includes the inference results. You'll need to parse this response to extract the information you need.

Practical Example: Image Classification

Let's say you have an image classification model named image_classifier deployed on Triton and you want to classify an image.

Prepare the Image

  • Preprocess the image (resize, normalize) and convert it into the format expected by your model, typically a NumPy array or a list.

Create the Request Body

  • The request body will include details like the input tensor's name (e.g., input_1), shape (e.g., [1, 224, 224, 3] for a single RGB image of size 224x224), datatype (FP32), and the image data.

Python Script for Inference

import requests
import json
import numpy as np
from PIL import Image
from io import BytesIO

# Load and preprocess the image
img = Image.open('path_to_image.jpg').resize((224, 224))
img_array = np.array(img).tolist()  # Convert to list for JSON serialization

# Prepare the request body
data = {
    "inputs": [
        {
            "name": "input_1",
            "shape": [1, 224, 224, 3],
            "datatype": "FP32",
            "data": img_array
        }
    ]
}

# Send the request
url = "http://localhost:8000/v2/models/image_classifier/infer"
headers = {"Content-Type": "application/json"}
response = requests.post(url, headers=headers, data=json.dumps(data))

# Process the response
if response.status_code == 200:
    result = json.loads(response.content)
    print("Classification Result:", result)
else:
    print("Error:", response.status_code, response.content)
  • This script sends the image to the image_classifier model and prints out the classification results.

In summary, making an inference request to Triton involves preparing the appropriate request with necessary details and sending it to the server's endpoint.

The server processes the request and returns the inference results, which the client can then use as needed. This process is crucial in scenarios where real-time or batch inferences are required from a deployed model.

Monitor Model Metrics

Monitoring model metrics is crucial for understanding the performance and efficiency of the deployed models. Triton Inference Server’s integration with Prometheus offers a comprehensive solution for this. Here are additional insights:

Metrics Types

  • Triton provides metrics like inference latency, throughput, GPU utilisation, and memory usage. These metrics are vital for optimizing model performance and resource allocation.

Prometheus Setup

  • The prometheus.yml file configures the Prometheus server to scrape metrics from Triton. This setup requires Prometheus to be installed and running in your environment.

Visualisation with Grafana

  • For better visualization of these metrics, Grafana can be integrated with Prometheus. Grafana dashboards offer a more intuitive way to monitor and analyze these metrics over time.

Alerting Mechanisms

  • Prometheus supports alerting rules that trigger notifications (e.g., via email, Slack) if certain metrics exceed predefined thresholds. This feature is crucial for real-time monitoring and ensuring the reliability of the server.

Custom Metrics

  • Depending on the specific use case, custom metrics can be defined and monitored. This could include model-specific performance metrics or business-relevant KPIs (Key Performance Indicators).

Security Considerations

  • When exposing metrics, security aspects should be considered. Ensure that the Prometheus endpoint is secured, especially if the server is exposed to the internet.

Secure the Inference Server

Authentication and Authorisation

  • Implementing robust authentication is crucial. Triton offers token-based and SSL/TLS client authentication. While token-based authentication uses access tokens for user verification, SSL/TLS authentication provides a more secure method by using digital certificates.

  • Role-Based Access Control (RBAC) can also be configured to manage user permissions and control access to server resources, ensuring that only authorized personnel can make changes or access sensitive data.

Encryption

  • SSL/TLS encryption is essential for securing data transfer between the client and the server. This step prevents potential data breaches during the communication process.

  • Configuring Triton to enforce SSL/TLS encryption and setting the --allow-insecure flag to false adds an extra layer of security, ensuring that all communications are encrypted.

Firewall Configuration

  • Setting up a firewall is a critical security measure. It controls incoming traffic to the server, blocking unauthorized access and potential attacks.

  • Depending on the deployment environment, either the operating system's built-in firewall or a third-party solution can be used to secure the server.

Regular Updates and Maintenance

  • Keeping the Triton Inference Server updated is vital for security. Regular updates ensure that the server has the latest security patches and features.

  • It is recommended to periodically check for new releases or updates from NVIDIA and implement them promptly. However, always back up existing configurations and models before updating to prevent data loss.

Additional Insights

  • Security as a Continuous Process: The steps highlighted for securing the Triton Inference Server remind us that security is not a one-time setup but a continuous process requiring regular monitoring and updates.

  • Balancing Performance and Security: Implementing robust security measures, especially encryption and authentication, is crucial. However, it's important to balance these with the server's performance to ensure that security enhancements do not unduly impact response times or throughput.

  • Broader Security Context: While the article focuses on server-specific security measures, it's important to consider the security of the entire ecosystem, including the networks and systems interacting with Triton.

LogoServing TensorRT Models with NVIDIA Triton Inference ServerTowards Data Science
Page cover image