Triton Inference Server

Triton Inference Server hostet ein Model Repository und beantwortet Inferenzanfragen über HTTP. LibreYOLO exportiert den ONNX-Graphen, erzeugt eine config.pbtxt, die die Export-Metadaten als einen einzelnen Triton-Parameter transportiert, und behandelt eine Modell-URL wie einen ladbaren Modellpfad.

Aufruf: LibreYOLO("http://127.0.0.1:8000/yolo9")
Hilfsfunktion: create_triton_config(onnx_path, config_path, model_name=..., max_batch_size=8)
Extra: pip install "libreyolo[onnx,triton]"
Protokoll: Nur HTTP- und HTTPS-V2-Inferenz. Kein gRPC, keine Authentifizierung, kein Shared Memory, kein Laden und Entladen von Modellen.
Timeouts: Verbindungs- und Netzwerk-Timeouts liegen standardmäßig bei 30 Sekunden

Installation

pip install "libreyolo[onnx,triton]"

Das Extra triton installiert tritonclient[http]. Die Extras für gRPC und Shared Memory sind absichtlich ausgeschlossen: Diese Integration macht ausschließlich HTTP- und HTTPS-V2-Inferenz. onnx wird gebraucht, weil sowohl das bereitgestellte Artefakt als auch der Config-Generator von einem ONNX-Graphen ausgehen.

Aufbau des Model Repositorys

Exportiere mit dynamischer Batch-Achse, in das Verzeichnis-Layout, das Triton erwartet.

In das Repository-Layout exportieren

from pathlib import Path from libreyolo import LibreYOLO model_dir = Path("triton_repo/yolo9/1")model_dir.mkdir(parents=True, exist_ok=True) LibreYOLO("LibreYOLO9t.pt").export(    format="onnx",    output_path=str(model_dir / "model.onnx"),    dynamic=True,    simplify=False,)

config.pbtxt erzeugen

from libreyolo import create_triton_config create_triton_config(    "triton_repo/yolo9/1/model.onnx",    "triton_repo/yolo9/config.pbtxt",    model_name="yolo9",    max_batch_size=8,)

Resultierendes Layout

triton_repo/  yolo9/    config.pbtxt    1/      model.onnx

Triton behält die ONNX-Custom-Metadaten in seiner Model-Config-Antwort nicht bei, deshalb müssen die vollständigen exportierten Metadaten auf einem anderen Weg mitreisen. create_triton_config kodiert sie als einen einzelnen JSON-String-Parameter namens libreyolo_metadata in config.pbtxt, gibt die Input- und Output-Deklarationen in Graph-Reihenfolge aus, kümmert sich um das JSON-Escaping und fixiert das Modell auf KIND_CPU.

Die Hilfsfunktion validiert vor dem Schreiben. Sie verlangt genau einen ONNX-Graph-Input, mindestens einen Output, auflösbare Tensor-Shapes und Metadaten, deren names-Map jeden Klassenindex von 0 bis nc - 1 definiert. Ein Modell, das eine dieser Prüfungen nicht besteht, wird zur Config-Zeit abgelehnt statt beim ersten Request.

max_batch_size: 8 passt zu einem dynamischen Export und lässt den Server bis zu acht Bilder pro Request bündeln. Für einen ONNX-Graphen mit fester Batch-Größe 1 nimm max_batch_size=0; LibreYOLO schickt die Bilder dann nacheinander.

Start des Servers

Server starten

docker run --rm --name libreyolo-triton \  -p 8000:8000 -p 8002:8002 \  -v "$(pwd)/triton_repo:/models:ro" \  nvcr.io/nvidia/tritonserver:26.04-py3 \  tritonserver --model-repository=/models --exit-on-error=true

Auf Bereitschaft warten

until curl --fail --silent http://127.0.0.1:8000/v2/health/ready; do sleep 1; done

Stoppen

docker stop libreyolo-triton

Die Befehle fixieren Triton Server 26.04 und lassen die GPU-Flags von Docker bewusst weg, da KIND_CPU in der erzeugten Config eine GPU-Platzierung ohnehin verhindert.

Ausführung des Artefakts

Eine Triton-Modell-URL ist ein Modellpfad. LibreYOLO() prüft auf ein http- oder https-Schema, bevor irgendeine lokale Pfadverarbeitung greift, und gibt ein Backend zurück, das mit dem Server spricht. Die Aufrufstelle ist damit identisch mit der für einen lokalen Checkpoint, und das zurückkommende Results-Objekt ebenfalls.

Gegen das bereitgestellte Modell vorhersagen

from libreyolo import LibreYOLO, SAMPLE_IMAGE remote = LibreYOLO("http://127.0.0.1:8000/yolo9")result = remote.predict(SAMPLE_IMAGE)print(result.boxes.xyxy[:3])

Mit dem lokalen Modell vergleichen

from libreyolo import LibreYOLO, SAMPLE_IMAGE remote = LibreYOLO("http://127.0.0.1:8000/yolo9").predict(SAMPLE_IMAGE)native = LibreYOLO("LibreYOLO9t.pt").predict(SAMPLE_IMAGE) print(len(remote.boxes), len(native.boxes))print(remote.boxes.xyxy[:3])print(native.boxes.xyxy[:3])

Version fixieren oder Timeout ändern

from libreyolo import LibreYOLOfrom libreyolo.backends.triton import TritonBackend # Ein zweites Pfadsegment wählt die Modellversion. Ohne es# entscheidet Tritons konfigurierte Version Policy.pinned = LibreYOLO("http://127.0.0.1:8000/yolo9/1") # Verbindungs- und Netzwerk-Timeout: standardmäßig 30 Sekunden.patient = TritonBackend("http://127.0.0.1:8000/yolo9", timeout=120)

Die URL-Form ist http(s)://host:port/model mit einem optionalen Versionssegment. Der Port muss explizit angegeben sein. Eingebettete Zugangsdaten, ein Query-String und ein Fragment werden allesamt abgelehnt, ebenso ein Pfad mit mehr als zwei Segmenten.

device wird angenommen und mit einer Log-Zeile ignoriert, weil die Platzierung die Entscheidung des Servers ist.

Einschränkungen

Das Backend scheitert mit einem direkten Fehler statt mit einem verschlechterten Ergebnis, wenn der Vertrag nicht erfüllt ist: fehlende LibreYOLO-Metadaten in der Model Config, mehr als ein Modell-Input, eine Abweichung zwischen den konfigurierten Outputs und den Modell-Metadaten, ein nicht unterstützter Input-Datentyp oder ein Server beziehungsweise Modell, das nicht bereit ist.

Außerhalb des Vertrags in dieser Version: gRPC, Authentifizierung, Shared Memory sowie das Laden oder Entladen von Modellen über die API.

Jedes Format, das Triton selbst unterstützt, lässt sich bereitstellen, aber der Metadaten-Parameter und die erzeugte Config sind hier auf ONNX zugeschnitten, also führt der LibreYOLO-Weg über ONNX in das Repository. Für eine vollständige Video-Pipeline statt eines Request-Response-Servers siehe DeepStream.