Modelle

TL;DR

• Ein Modell auf Pipelogic lebt auf einem component-vertex. Es gibt zwei Integrationspfade: file-served (ein Artefakt hochladen und an den file_schema-Slot eines vertex binden) und runtime-fetched (einen vertex-Parameter auf eine hub-model-id zeigen lassen und den Serving-Dienst es zur deploy-Zeit ziehen lassen).
• Serving-runtimes sind Dienste, keine components. Triton, TorchServe, Ollama, vLLM und SGLang sind plattformverwaltete Dienste. Eine component deklariert depends_on: [<service>] in ihrer component.yml; die Plattform stellt den Dienst zur deploy-Zeit neben den Container der component auf. Du pinnst Triton selbst nie als vertex.
• Unter den Serving-Diensten gibt es zwei Formen, die zu kennen sich lohnt: Multi-model-Dienste (Triton, TorchServe, Ollama) führen eine Instanz aus, die viele Modelle bedient, zur Aufrufzeit ausgewählt. Parametrisierte Dienste (vLLM, SGLang) führen eine Instanz pro Modell aus — ein zweites Modell bedeutet eine zweite Instanz.
• Eine Modell-Integration ist fertig, wenn repräsentative Fixtures das erwartete Verhalten im live runtime erzeugen. "Der Upload gab 200 zurück" ist nicht die Messlatte; semantische Korrektheit ist es. Mismatch (falsche Labels, falscher Tokenizer, falsche Bildgröße, falsches Preprocessing) ist der Fehlermodus, der saubere deploys überlebt.
• Die Plattform trennt Artefakt (unveränderliche Workspace-Datei) von Bindung (vertex-Slot in einem backend) von Serving (verwalteter Dienst neben der component). Jedes der drei zu tauschen ist eine einzelne Graph-Mutation, keine System-Migration.

Was "Modelle auf Pipelogic" tatsächlich bedeutet

Es gibt drei gängige Wege, ein Modell in Produktion zu verwenden: die Gewichte in das component-Image backen, einen Modellserver als Dienst ausführen, von dem die component abhängt, oder auf einen gehosteten endpoint zeigen. Pipelogic zentriert sich auf den zweiten: das Modell-Artefakt und das Serving-runtime werden vom component-Code getrennt gehalten, sodass die component deklariert, was sie benötigt, und die Plattform es liefert.

Pipelogic trennt drei Belange. Das Modell-Artefakt ist eine typisierte Workspace-Datei — einmal hochgeladen, adressierbar per file_id, über viele backends wiederverwendbar, in einen component-Datei-Slot gebunden statt in das Image gebacken. Die vertex-Bindung ist der Ort im backend-Graphen, an dem das Artefakt lebt — der file_schema-Slot der component, gebunden per ppl backend add-file, im Operationslog aufgezeichnet, pro backend tauschbar, ohne das Artefakt oder die component zu berühren. Das Serving-runtime ist ein plattformverwalteter Dienst, den die component per depends_on: benötigt — die Plattform stellt es zur deploy-Zeit neben den component-Container, die component spricht über das lokale Netzwerk mit ihm, das Team betreibt Triton oder vLLM nie von Hand.

Die Disziplin, die dieses Design verlangt, ist, aufzuhören, Modelle als Code zu denken, der innerhalb der component läuft. Die component ist der Wrapper, der den typisierten Vertrag dem Rest des backend offenlegt; das Modell ist das Artefakt, das der Wrapper konsumiert; das Serving-runtime ist der Dienst, der das Artefakt lädt und Inferenzanfragen beantwortet. Die drei getrennt zu halten ist das, was "tausche dieses Modell gegen jenes" zu einer einzelnen Graph-Mutation macht statt zu einer Code-Änderung, einem Republish und einem Redeploy.

Mentales Modell — component-vertex, plus ein Serving-Dienst daneben

Ein Modell lebt auf einem Component-vertex. Das Serving-runtime ist ein Dienst, den die Component per depends_on: benötigt; die Plattform bringt es zur deploy-Zeit neben dem Container der Component hoch. Die component.yml der Component wählt den Integrationspfad:

  File-served (uploaded artifact)
  ┌─────────────────────────────┐
  │ file_schema:                │
  │   model:                    │
  │     file_type: triton_model │
  │     config_key: model_name  │
  │ depends_on: [triton]        │
  └─────────────────────────────┘
      ▲ ppl backend add-file
      │   $BID --vertex N --key model
      │   --file <file_id>

  Runtime-fetched (hub id)
  ┌─────────────────────────────┐
  │ config_schema:              │
  │   model_name:               │
  │     type: String            │
  │     default: "<hub-id>"     │
  │ cache:                      │
  │   huggingface_hub:          │
  │     - ids: model_name       │
  │ depends_on: [sglang]        │
  └─────────────────────────────┘
      ▲ ppl backend change-parameter
      │   $BID --vertex N --name model_name
      │   --type String --value "<hub-id>"

Das backend bindet beide Seiten mit einer von zwei Operationen; der component-Code bleibt generisch, und der Serving-Dienst kommt automatisch hoch, weil die component ihn benötigt.

Welcher Pfad für welches Modell richtig ist

Verwende diese Rahmung beim Planen einer neuen Modell-Integration.

File-served ist richtig, wenn das Artefakt custom-trainiert, exportiert oder anderweitig im Besitz des Teams ist. Ein fein-getuntes ONNX-Modell mit einem bestimmten Label-Set, ein Triton model repository mit einer custom config.pbtxt, ein TorchServe MAR mit custom Pre-/Post-Handlern — all diese sind file-served. Das Artefakt wird als typisierte Workspace-Datei hochgeladen, in den Slot des konsumierenden vertex gebunden und reist als Bindung mit dem backend-Graphen mit. Artefakte später zu tauschen ist dieselbe add-file-Operation, auf eine andere file_id gerichtet.

Runtime-fetched ist richtig, wenn das Artefakt hub-gehostet ist und das Team bereit ist, vom hub abzuhängen. Ein hub-gehostetes LLM, das vLLM oder SGLang on demand zu ziehen weiß, ein Ollama-Modellname, den der Serving-Dienst gegen seinen catalog auflöst, ein Triton model repository, das in einer entfernten Registry gehostet ist — all diese sind runtime-fetched. Der vertex trägt einen String-Identifikator; der Serving-Dienst erledigt den Pull beim ersten Request (oder zur deploy-Zeit, je nach Caching-Strategie des Dienstes).

Der Kompromiss ist Reproduzierbarkeit versus Speicher. File-served bedeutet, das Artefakt ist im Workspace-Datei-Store gepinnt — bit-für-bit reproduzierbare Läufe jedes Mal. Runtime-fetched bedeutet, das Artefakt lebt im hub — Reproduzierbarkeit hängt davon ab, dass der hub einen gegebenen Identifikator über die Zeit auf dieselben Gewichte auflöst. Für team-eigene Artefakte begünstigt der Kompromiss meist file-served; für stabile hub-Modelle begünstigt der Kompromiss meist runtime-fetched. Ein Modell, das der hub bereits hostet, file-served zu betreiben, dupliziert es im Workspace-Speicher; ein privates Fine-Tune runtime-fetched zu betreiben, hängt von einem hub ab, den das Team nicht kontrolliert.

Walkthrough — file-served (Triton-Detector)

# 1. upload the Triton model repository (directory root, NOT pre-tarred)ppl file upload ./model_repository \    --type triton_model \    --name "warehouse-detector" \    --readme @./README.md \    --config ./model.config.ymlCopy# returns $FID# 2. bind the file to the Triton Component vertex's `model` slotppl backend add-file $BID --vertex 2 --key model --file $FIDCopy# 3. deploy and run representative fixturesppl backend deploy --backend $BIDCopy

Das erwartete Layout eines Triton-Repositorys:

model_name/
├── config.pbtxt
└── 1/
    └── model.onnx        # or model.plan / model.pt / model.savedmodel/

Die CLI tart das Verzeichnis zur Upload-Zeit; vor-getarte Uploads erzeugen ein verschachteltes Archiv, das Triton nicht laden kann. Die optionale --config hängt ein YAML an, das zur Bindungszeit passende vertex-Parameter setzt (output-Namen, Thresholds, Bildgröße, Class-Labels), sodass das Backend nicht vom Artefakt abdriftet.

Walkthrough — runtime-fetched (LLM über SGLang)

# 1. point the vertex at a hub model idppl backend change-parameter $BID --vertex 3 \    --name model_name --type String --value '"Qwen/Qwen2.5-1.5B-Instruct"'Copy# 2. for a gated model, bind a Workspace secret for the hub tokenppl backend change-parameter $BID --vertex 3 \    --name hf_token --type String --value "<secret-id>"Copy# 3. deploy — the deploy blocks on the runtime's cold pull / weight load#    before it reports readyppl backend deploy --backend $BIDCopy

Für gated hub-Modelle ist das Token ein Workspace-secret, per ID gebunden, kein Klartext-Parameter — siehe Workspace-secrets.

Multi-model vs. parametrisierte Serving-Dienste

Verwende diese Rahmung bei der Wahl, von welchem Serving-Dienst eine component abhängen soll.

Serving-Dienste kommen in zwei operativen Formen, und die Form bestimmt, wie viele Instanzen für wie viele Modelle laufen.

Multi-model-Dienste führen eine Instanz aus, die viele Modelle bedient. components, die von Triton, TorchServe oder Ollama abhängen, teilen sich dieselbe Dienst-Instanz und wählen ihr Modell per ID zur Aufrufzeit. Das Muster ist richtig, wenn das Team viele Modelle mit ähnlichen runtime-Charakteristika bedient — ein halbes Dutzend ONNX-Detectoren mit verschiedenen Label-Sets, eine Flotte kleiner LLMs für verschiedene Anwendungsfälle, eine Menge TorchServe MARs mit custom Handlern — und der Overhead pro Modell beim Betrieb unabhängiger Instanzen die tatsächlichen Inferenzkosten dominieren würde.

Parametrisierte Dienste führen eine Instanz pro Modell aus. components, die von vLLM oder SGLang abhängen, binden einen bestimmten model_name beim Start; ein zweites Modell zu bedienen bedeutet eine zweite Instanz des Dienstes. Das Muster ist richtig, wenn das Modell groß genug oder die Inferenz-Engine eigensinnig genug ist, dass das Mischen von Modellen innerhalb einer Instanz die Optimierung, für die die Engine existiert, zunichtemachen würde. vLLMs kontinuierliches Batching, SGLangs Strukturierte-Generierung-runtime und ähnliche spezialisierte Engines sind unter der Annahme geschrieben "ein Modell lebt in diesem Prozess"; die Plattform respektiert das.

Dienst	Art	Am besten für
Triton	multi-model	CV-Detection / -Segmentation / -Classification, ONNX / TensorRT / TorchScript / TF SavedModel, dynamisches Batching.
TorchServe	multi-model	PyTorch-Modelle mit custom Python Pre-/Post-Handlern (MAR).
Ollama	multi-model	Schnelle LLM-/VLM-Iteration, lokal oder selbst-gehostet.
vLLM	parametrisiert	LLM-Serving mit hohem Durchsatz, langer Kontext.
SGLang	parametrisiert	Strukturierte Generierung, VLMs, OpenAI-kompatibles Serving.

Die praktische Implikation für das backend-Design: zwei vertices, die verschiedene LLMs über SGLang oder vLLM konsumieren, bringen zwei Dienst-Instanzen hoch; dieselben zwei vertices gegen Ollama oder Triton teilen sich eine. Dieses Teilen ist der richtige Default für "viele kleine Modelle" und der falsche Default für "ein großes optimiertes Modell".

Mismatch ist der Fehlermodus

Verwende diese Rahmung beim ersten Mal, wenn ein sauberer deploy ein kaputtes Modell ausliefert.

Eine Modell-Integration, die sauber hochlädt, sauber bindet und sauber deployt, kann trotzdem kaputt sein. Die Fehler clustern sich in eine kleine Menge von Formen, die eine Eigenschaft teilen — keine von ihnen erzeugt Schema-Fehler zur deploy-Zeit. Das Typsystem der Plattform fängt die Form-Fehler (falscher Dateityp für den Slot, falscher Literal-Typ für einen Parameter); die semantischen Fehler sind die des Teams, mit der Nachweis-Schleife zu fangen.

Die Formen, die zu benennen sich lohnen, grob in der Reihenfolge der Häufigkeit:

• Falsche Labels — die output-Class-IDs des Modells passen nicht zu dem, was der nachgelagerte Consumer erwartet. Schema-gültige Ausgabe, semantisch falsch.
• Falscher Tokenizer — Text-rein / Text-raus funktioniert als JSON; jedes Zeichen ist falsch, weil der Tokenizer mit dem Trainings-Tokenizer des Modells nicht übereinstimmt.
• Falsches Preprocessing — Bildgröße, Kanalreihenfolge, Normalisierung, dtype-Mismatch zwischen dem, was das Modell erwartet, und dem, was der Upstream emittiert.
• Falscher Task — Klassifikationsgewichte an eine Detector-component gebunden, Segmentationsgewichte an einen Klassifizierer.
• Kalter Start als kaputter endpoint missverstanden — der erste Request läuft in ein Timeout, weil der Serving-Dienst das Modell noch lädt; der zweite Request wäre gelungen.
• Fehlender Zugriff für gated Modelle — das Workspace-secret für das hub-Token wurde nicht an den access-token-Parameter der component gebunden, sodass der Pull des gated Repositorys durch das runtime vom hub abgelehnt wird und das Modell nie lädt. Der deploy schlägt beim Gewichte-Laden fehl, nicht beim Schema.

Die Nachweis-Schleife in Verhalten nachweisen ist der Ort, an dem diese Fehler gefangen werden. Die Plattform macht den Nachweis billig (gepinnte Artefakte, deterministische Graphen, lease-isolierte Testläufe); die Aufgabe des Teams ist es, den Nachweis tatsächlich auszuführen, bevor "fertig" erklärt wird.

Ersetzen und Iterieren

Verwende diese Rahmung, wenn "das Artefakt muss sich ändern" auftaucht.

Ein gebundenes Artefakt zu ersetzen ist eine einzelne Graph-Mutation. Eine neue Datei hochladen (ppl file upload), dann den Slot an die neue file_id neu binden. Das Operationslog der Plattform zeichnet den Tausch auf; die vorherige Bindung ist über das übliche backend-undo rückgängig machbar. Kein component-Republish, kein Redeploy über den Rest des Graphen — nur die eine Bindungs-Bearbeitung und, falls der Serving-Dienst es verlangt, ein Redeploy des betroffenen vertex.

Das Muster, das billige Iteration unterstützt, ist, das Artefakt adressierbar zu halten. Jede hochgeladene Datei hat eine stabile file_id; eine beliebige davon in den vertex-Slot zu binden ist dieselbe Operation; das Team kann zwischen zwei Artefakten A/B-testen, indem es sie in Geschwister-vertices im selben backend bindet und Ausgaben auf derselben Fixture-Menge vergleicht. Das ist die strukturelle Antwort auf "ist der Kandidat besser als der Amtsinhaber" — siehe Modell-Artefakt-Integration für die Vergleichsschleife.

Wo das hineinpasst

Modelle sind ein erstklassiger Belang auf der Plattform, weil die Integrationsschleife der Ort ist, an dem die meisten KI-Projekte Komplexität ansammeln. Indem die Plattform das Artefakt von der Bindung vom Serving-Dienst trennt, macht sie jedes Stück unabhängig tauschbar — und diese Tauschbarkeit ist das, was die Integrationsschleife billig hält, während das Projekt wächst. Das Team schreibt die component einmal, der Serving-Dienst läuft ohne Team-Betrieb, das Artefakt wird getauscht, während das Modell sich verbessert. Jedes Stück hat seinen eigenen Lebenszyklus; die Aufgabe der Plattform ist es, sie komponierbar zu machen.

Verwandt

• Files — die File-Primitive und der Lebenszyklus.
• File-Schema — die Deklaration des file_schema-Slots des Modells.
• File-Typen — file_type-Werte für Modell-Artefakte.
• File-Binding — das Artefakt hochladen und binden.
• Backend-Operationen — add-file- und change-parameter-Semantik.
• Secrets — gated hub-Tokens per ID binden, nie als Klartext.
• Modell-Artefakt-Integration — die vollständige upload- + bind- + iterate-Schleife.
• Solutions — wo Serving-components neben input- / transform- / output-components passen.