Tipps und Tricks zum Triton-Inferenzserver | von Adam Wawrzyński | Juni 2023

Dinge, von denen ich wünschte, ich hätte sie gewusst, bevor ich mit Triton herumgespielt habe

Dies ist der zweite Artikel zum Triton Inference Server. Im ersten habe ich Funktionen und Anwendungsfälle beschrieben. Wenn Sie es verpasst haben und einige der Konzepte dieses Textes nicht verstehen, empfehle ich Ihnen, ihn zuerst zu lesen. Du kannst es finden Hier.

Dieser Artikel beschreibt Tipps und Methods, stellt einen Spickzettel mit nützlichen Befehlen vor und stellt Codebeispiele für das Benchmarking verschiedener Modellkonfigurationen für Laptop-Imaginative and prescient-Modelle bereit. Dieser Artikel ist eher technischer Natur und durch die Lektüre lernen Sie spezifische Befehle zum Optimieren und Konfigurieren der von Triton bedienten Modelle kennen.

Notiz: In allen folgenden Befehlen verwende ich Container mit Versionen 22.04oder 22.11, aber Sie können wählen, welche Model für Sie am besten geeignet ist. Diese Container hängen von CUDA-Treibern ab und die Versionen, die ich in den folgenden Befehlen verwende, funktionieren möglicherweise nicht für Sie.

1. Führen Sie Triton im Docker-Container aus

• Wichtiger Hinweis: Sie müssen den absoluten Pfad des aktuellen Verzeichnisses übergeben und unter demselben Pfad im Container-Dateisystem mounten. Andernfalls können keine Modelle im gefunden werden model-repository

docker run 
--gpus=all 
-it 
--shm-size=256m 
--rm -p8000:8000 
-p8001:8001 
-p8002:8002 
-v$(pwd):/workspace/ 
-v /$(pwd)/model_repository:/fashions 
nvcr.io/nvidia/tritonserver:22.11-py3 
bash

2. Verwendung model-analyzer Werkzeug im Docker-Container

docker run 
-it 
--gpus all 
-v /var/run/docker.sock:/var/run/docker.sock 
-v $(pwd):$(pwd) 
--net=host 
nvcr.io/nvidia/tritonserver:22.11-py3-sdk

3. Definieren Sie den globalen Antwortcache

tritonserver --cache-config native,dimension=1048576

4. Definieren Sie den Modellantwort-Cache (in config.pbtxt)

response_cache { allow: true }

5. Definieren Sie das Abfrageintervall der Modelle

tritonserver --repository-poll-secs

6. Typisch model-repositoryStruktur

model_repository/
└── text_recognition
├── 1
│   └── mannequin.plan
└── config.pbtxt

7. Definieren Sie die dynamische Stapelverarbeitung (hier verwende ich 100 Mikrosekunden als Zeit für die Aggregation der dynamischen Stapelverarbeitung). config.pbtxt )

dynamic_batching { max_queue_delay_microseconds: 100 }

8. Definieren Sie die maximale Batch-Größe des Modells (hier verwende ich acht als maximale Batch-Größe in). config.pbtxt)

max_batch_size: 8

9. Aufwärmen des Modells

• Fügen Sie diese Zeile hinzu config.pbtxt. Das Feld key muss mit der definierten übereinstimmen enter Title, Typ und Abmessungen.

model_warmup [{
name : "regular sample"
batch_size: 1
inputs {
key: "input__0"
value: {
data_type: TYPE_FP32
dims: [ 3, 224, 224 ]
zero_data: true
}
}
}]

10. TensorRT-Optimierung (Modell mit halber Genauigkeit verwenden, maximale Arbeitsbereichsgröße definieren in config.pbtxt)

optimization { execution_accelerators {
gpu_execution_accelerator : [ {
name : "tensorrt"
parameters { key: "precision_mode" value: "FP16" }
parameters { key: "max_workspace_size_bytes" value: "1073741824" }
}]
}}

11. OpenVINO-Optimierung (für Modelle, die auf der CPU in ausgeführt werden config.pbtxt)

optimization { execution_accelerators {
cpu_execution_accelerator : [ {
name : "openvino"
}]
}}

12. TF JIT-Optimierung (in config.pbtxt)

optimization {
graph { degree: 1 }
}

13. TensorFlow XLA-Optimierungen

TF_XLA_FLAGS="--tf_xla_auto_jit=2 --tf_xla_cpu_global_jit" tritonserver --model-repository=...

14. TensorFlow mit automatischer FP16-Optimierung (in config.pbtxt)

optimization { execution_accelerators {
gpu_execution_accelerator : [
{ name : "auto_mixed_precision" }
]
}}

1. Benutzen model-analyzerDenken Sie im Docker-Container daran, ein Quantity mit zu mounten model-repository am gleichen Pfad im Container wie im Host-Dateisystem. Ansonsten model-analyzer wird Probleme haben, bereitgestellte Modelle zu finden.

docker run -it 
--gpus all 
-v /var/run/docker.sock:/var/run/docker.sock 
-v $(pwd):$(pwd) 
--net=host 
nvcr.io/nvidia/tritonserver:22.11-py3-sdk
cd /residence/<path_to_model_repository_parent>
model-analyzer profile 
--model-repository $(pwd)/model_repository 
--profile-models <model-name> 
--triton-launch-mode=docker 
--output-model-repository-path $(pwd)/output/ 
-f perf.yaml 
--override-output-model-repository

2. Um das Modell nach TensorRT zu exportieren, verwenden Sie das folgende Docker-Picture:

docker run --gpus all 
-it 
--rm 
-v $(pwd):/workspace 
nvcr.io/nvidia/tensorrt:22.04-py3

• Es ist sehr wichtig, die gleiche Model von zu verwenden tensorrt Behälter als tritonserver aufgrund der Versionsüberprüfung. Mit anderen Worten: Triton exportiert kein Servermodell mit einer anderen Model von TensorRT.

3. Grundlegender Befehl zum Konvertieren des ONNX-Modells in TensorRT

trtexec --onnx=mannequin.onnx 
--saveEngine=mannequin.plan 
--explicitBatch

4. Um das Modell mit halber Genauigkeit zu exportieren, können Sie die folgenden Flags hinzufügen:

trtexec ... --inputIOFormats=fp16:chw 
--outputIOFormats=fp16:chw 
--fp16

• Diese Optimierung führte zu einer bis zu zweifachen Beschleunigung der Latenz und des Durchsatzes auf MobileNetV3 im Vergleich zum FP32 ONNX-Modell.

5. Um das Modell im quantisierten Format zu exportieren (einige der Gewichte werden als int8 gespeichert), verwenden Sie die folgenden Flags:

trtexec ... --inputIOFormats=int8:chw 
--outputIOFormats=int8:chw 
––int8

• Diese Optimierung führte zu einer bis zu zwei- bis dreifachen Beschleunigung der Latenz und des Durchsatzes auf MobileNetV3 im Vergleich zum FP32 ONNX-Modell.

6. Um das Modell mit dynamischer Stapelgröße zu exportieren, müssen Sie drei Parameter angeben trtexec Programm. Für ein auf ImageNet trainiertes Modell können diese Parameter wie folgt aussehen:

trtexec ... --minShapes=enter:1x3x224x224 
--maxShapes=enter:8x3x224x224 
--optShapes=enter:4x3x224x224

• Diese Optimierung führte zu einer bis zu zweifachen Beschleunigung der Latenz und des Durchsatzes auf MobileNetV3 im Vergleich zu Modellen im Einzelbatch-Modus.

7. Für einen höheren Durchsatz und eine geringere Latenz im Einzelbatchmodus sollten Sie eine explizite Batchgröße verwenden.

• Für das Modell mit der expliziten Batch-Größe wurden im Vergleich zum Modell mit dynamischer Batch-Größe ein um etwa 20 % erhöhter Durchsatz und eine um 16 % verkürzte Inferenzzeit beobachtet.

8. Um ein Modell mit dynamischer Batchgröße nach ONNX zu exportieren (z. B. aus PyTorch-Code), müssen Sie den Parameter angeben dynamic_axes.

• Sie können Eingabe- und Ausgabenamen definieren, um während der Inferenz eine bessere Kontrolle über Parameternamen zu erhalten. Andernfalls werden Namen verwendet, die auf den Ebenennamen des Modells basieren.
• Sie können einen Blick auf PyTorch werfen Beispiel um den Prozess besser zu verstehen.

9. Allgemeine Konfiguration in config.pbtxt

• Definieren max_batch_size des Modells auf einen angemessenen Wert größer oder gleich 1. Wenn das Modell keine dynamischen Stapel unterstützt, beispielsweise ein nach TensorRT exportiertes Modell mit einer expliziten Stapelgröße von 1sollten Sie diesen Wert auswählen 1.
• Wenn max_batch_size größer als eins ist, dann ist in Dims die erste Dimension standardmäßig immer -1. Wenn Sie definieren dims: [3, 224, 224] Triton wird angehängt -1 an erster Stelle der Liste für Sie.

10. Allgemeines model-analyzer Aufbau

• Wenn Sie einen Docker-Container zum Durchführen einer Modellanalyse und zum Optimieren von Triton-Konfigurationsparametern verwenden, denken Sie daran, ein Quantity mit dem bereitzustellen model-repository innerhalb des Containers auf demselben Pfad wie auf dem Host-Laptop. Ansonsten, perf_analyzer Und model_analyzer wird es schwer haben, Modelle zu finden.

docker run -it 
--gpus all 
-v /var/run/docker.sock:/var/run/docker.sock 
-v $(pwd):$(pwd) 
--shm-size 1024m 
--net=host 
nvcr.io/nvidia/tritonserver:22.04-py3-sdk

• Sie können die Dokumentation und alle Parameter des überprüfen model_analyzer Hier.

Hier ist ein Beispiel für den Befehl:

model-analyzer profile 
--model-repository $(pwd)/model_repository 
--profile-models model_onnx 
--triton-launch-mode=docker 
--output-model-repository-path $(pwd)/output/ 
-f perf.yaml 
--override-output-model-repository

11. Allgemeines perf-analyzer Aufbau

• Es ist problematisch, Modelle zu analysieren, die mit Bildern arbeiten, wenn Sie keine Zufallsdaten anfordern können. In diesem Fall können Sie eine Datei mit Beispieldaten vorbereiten, die in einer Anfrage gesendet werden sollen. Es verfügt über ein vordefiniertes Format mit Daten als flache Werteliste und der Type eines gewünschten Tensors. Im folgenden Beispiel möchte ich ein Bild einer Type senden (640, 480, 3) aber auf dem Feld content material Ich muss das Bild als flache Liste von Werten angeben, in diesem Fall der Type (921600,).

{“information”: [{<input_name>: {“content”: [3, 5, …], “form”: [640, 480, 3]]}

• Befehl mit in einer Datei gespeichertem Datenbeispiel information.json wird so aussehen:

perf_analyzer -m python_vit 
-b 1 
--concurrency-range 1:4 
--input-data information.json 
--shape picture:640,480,3

12. Ensemble-Modell

• Sie müssen ein leeres Verzeichnis mit einer Model erstellen, die den Anforderungen von Triton entspricht.

Die Bereitstellung eines ViT-Modells als Python-Modell sieht beispielsweise so aus:

Funktionen initialize Und execute werden von Triton benötigt. Das Initialisierungsmodell und der Merkmalsextraktor werden von erhalten umarmendes Gesicht. execute führt eine Vorverarbeitung durch, ruft Modelle auf und gibt Ergebnisse zurück.

Hier ist es config.pbtxt:

Und das Verzeichnis sieht so aus:

python_vit/
├── 1
│   └── mannequin.py
└── config.pbtxt

Hier ist ein Beispiel für das ViT-Modell, das als Ensemble-Modell mit separater Vor- und Nachbearbeitung eingesetzt wird.

ensemble_model/config.pbtxt

preprocessing/1/mannequin.py

preprocessing/config.pbtxt

vit/config.pbtxt

Die Verzeichnisstruktur sieht so aus:

model_repository
├── ensemble_model
│   ├── 1
│   └── config.pbtxt
├── preprocessing
│   ├── 1
│   │   └── mannequin.py
│   └── config.pbtxt
└── vit
├── 1
│   └── mannequin.onnx
└── config.pbtxt

Sehen Sie sich einen Vergleich dieser beiden Bereitstellungskonfigurationen an. Sie sehen, dass die Optimierung des Kernmodells die Inferenzpipeline um bis zu etwa 30 % beschleunigt.

Als Benchmark habe ich MobileNetV2 ausgewählt. Nachfolgend finden Sie zwei Tabellen mit Ergebnissen für unterschiedliche Losgrößen:

Erwartungsgemäß schneidet TorchScript ohne Optimierungen in diesem Vergleich am schlechtesten ab. Aus der obigen Tabelle können wir schließen, dass dieser Anstieg zunimmt batch_size mit dynamic batching Dies führt zu einem erhöhten Durchsatz. Die Modellkonvertierung auf FP16 und INT8 führt zu einer spürbaren Beschleunigung, kann jedoch zu einer Leistungseinbuße führen.

Das Interessante ist das TensorRT FP16 hat einen höheren Durchsatz als TensorRT FP16 optimized. Das erste Modell wurde als Modell mit halber Präzision exportiert, während das zweite als Modell mit voller Präzision exportiert und in Triton für die Verwendung von FP16 konfiguriert wurde. Aus der obigen Tabelle können wir schließen, dass es besser ist, ein Modell mit halber Genauigkeit zu exportieren und sich nicht auf die Konvertierung von Triton zu verlassen, wenn Sie es verwenden möchten. Wie immer unterscheiden sich die Ergebnisse auf unterschiedlicher {Hardware} und Sie sollten alle Konfigurationen testen, bevor Sie sie auf Ihrem Laptop bereitstellen.