Docs

Modell-Artefakt-Integration

Kurzfassung

  • Modell-Artefakt-Integration ist der Workflow, der ein trainiertes oder ausgewähltes Modell mit einem laufenden backend verbindet und bestätigt, dass es die erwarteten Outputs produziert. Er umfasst die Wahl des Laufzeit-Pfads, das Hineinbringen des Artefakts in das backend, das Verdrahten in den Graphen, das Ausführen repräsentativer Fixtures, das Benchmarken und das Aufzeichnen der Belege für eine Produktionsreife-Entscheidung. Testen ist ein Schritt darin.
  • Die Laufzeit-Pfad-Wahl — file-served versus runtime-fetched — ist eine Entscheidung pro Artefakt, die in /concepts/models behandelt wird. Dieser Flow ist die operative Sequenz, sobald diese Wahl getroffen ist.
  • Cold Start ist Teil der Messung. Die Latenz der ersten Anfrage auf einem frisch deployten Modell kann eine Größenordnung über der Steady-State-Latenz liegen, sodass ein Benchmark, der nur die warme runtime misst, den echten Kaltpfad unterschätzt.
  • Der Versionsvergleich beantwortet "ist dieses Artefakt besser als das Bisherige": dasselbe Fixture-Set, zwei Artefakte in Geschwister-Bindungen, dieselben semantischen Kriterien. Das Delta ist der Beleg, den die Promotion-Entscheidung braucht.

Was Modell-Integration eigentlich ist

Modell-Integration ist der Weg von "das Modell existiert als Datei oder Hub-ID" zu "das Modell produziert die erwarteten Outputs auf den Inputs, die zählen, auf der runtime, die den Produktionsverkehr bedienen wird, mit gemessenen Eigenschaften". Sie umfasst sieben Belange: die Wahl des Laufzeit-Pfads, das Hochladen des Artefakts mit dem richtigen Typ, das Binden in den richtigen Slot auf dem richtigen vertex, das Verdrahten der umgebenden Vor- und Nachverarbeitungs-components, das Ausüben repräsentativer Fixtures, das Messen der Laufzeit-Eigenschaften und das Festhalten der Belege hinter der Promotion-Entscheidung.

Die Plattform hält das Artefakt aus demselben Grund vom component getrennt, aus dem sie components von backends getrennt hält: die Lebenszyklen sind nicht deckungsgleich. Ein component-Release ist ein Vertrag über Input- und Output-Typen und Konfigurationsform. Ein Modell-Artefakt ist ein Snapshot von Weights, gebunden über den Datei-Bind-Pfad, austauschbar ohne Änderung an einem dieser Verträge. Das Artefakt in das component-Image einzubacken würde einen component-Republish für jede Weights-Änderung erzwingen und die Weights in jedem Image mitschleppen, wo das Artefakt als separate, adressierbare Datei hingehört.

Jeder Schritt in der Schleife ist klein. Die Arbeit besteht darin, sie alle zu tun, statt bei der ersten Anfrage aufzuhören, die 200 zurückgibt.

Mentales Modell

artifact                          backend graph
─────────                         ──────────────

file-served path
  ppl file upload ──(file_id)──▶ ┌──────────────────┐
                                 │ vertex file slot │ ◀─┐
                                 └──────────────────┘   │
                              ppl backend add-file ──────┘

runtime-fetched path
  hub model id ──(string param)─▶ ┌──────────────────┐
  workspace secret (private)      │ vertex model_id  │ ◀─┐
        │                         └──────────────────┘   │
        ▼                                                 │
  ppl backend change-parameter ───────────────────────────┘

                            │
                            ▼
                      backend deploy
                            │
                            ▼
              live runtime + fixture run
                            │
                            ▼
                  evidence + benchmark

Die Laufzeit-Pfad-Taxonomie — was file-served und runtime-fetched bedeuten, wie sich jedes bei Deploy verhält und die Tatsache, dass serving-runtimes Dienste sind, von denen das component abhängt, statt vertices — lebt in /concepts/models. Dieser Flow zeigt die Operationen, die jeder Pfad verwendet; siehe Datei-Upload und Bindung für den file-served-Pfad im Detail.

Den Laufzeit-Pfad wählen

Verwende diesen Schritt zuerst. Die Wahl beschränkt jeden folgenden Schritt.

Welcher Pfad zu welchem Artefakt passt — und der Reproduzierbarkeits-gegen-Speicher-Kompromiss hinter der Wahl — ist in /concepts/models behandelt. Triff diese Entscheidung, bevor du fortfährst; der Rest dieses Flows sind die Operationen für jeden Pfad.

Hochladen und binden (file-served-Pfad)

Verwende dies für individuell trainierte oder exportierte Artefakte, die das Team besitzt.

Upload registriert das Artefakt als typisierte workspace-Datei, dann hängt ein Bind es an den Modell-Slot auf dem vertex an. Die generischen Mechaniken — --type, die Beschreibungs-Flags, die --config-Standards, die mit dem Artefakt reisen, und ppl backend add-file — sind in Datei-Bindung; das Triton-Modell-Repository-Layout, das --type triton_model erwartet, ist in File-Typen.

ppl file upload <artifact_path> --type <type> --name "<display>" --readme @./README.md --config ./model.config.ymlppl backend add-file <backend_id> --vertex <vertex_id> --key <file_schema_key> --file <file_id>

Speziell für ein Modell-Artefakt sind die --config-Standards der Ort, an dem die beabsichtigten Laufzeit-Einstellungen der Version mit ihr reisen: der Konfidenz-Schwellwert, für den das Fine-Tuning trainiert wurde, eine für diese Version spezifische Label-Map, die Bildgröße, die die Vorverarbeitung annimmt. Der Bind ist Teil des event-gesourcten Operations-Logs des backends — rückgängig zu machen, replaybar und austauschbar, indem dieselbe Operation auf eine andere file_id gerichtet wird.

Auf ein Hub-Modell zeigen (runtime-fetched-Pfad)

Verwende dies für Hub-gehostete Modelle, die der serving-Dienst auf Abruf ziehen kann.

Der runtime-fetched-Pfad bindet einen Parameter statt einer Datei. Das component deklariert einen Modell-Identifier-Parameter, das backend setzt ihn auf die Hub-seitige ID, und der serving-Dienst übernimmt das Ziehen.

ppl backend change-parameter <backend_id> --vertex <v> \    --name model_name --type String --value "<hub-model-id>"

Für private Hub-Modelle ist das Access-Token ein workspace-secret, gebunden an einen secret: true-Parameter, den das component zu diesem Zweck deklariert:

ppl backend change-parameter <backend_id> --vertex <v> \    --name hub_token --type String --value "<secret-id>"

Das Klartext-Token tritt nie in den backend-Graphen ein. Das Token in der workspace-UI zu rotieren genügt; das backend übernimmt den neuen Wert beim nächsten Deploy. Siehe Secrets für den Bind-Vertrag.

Die Umgebung verdrahten

Verwende diesen Schritt, bevor du irgendein Modell als integriert behandelst.

Ein Modell sitzt selten allein in einem backend. Es braucht eine Eingabequelle, die ihm korrekt geformte Daten zuführt, und eine Ausgabesenke, die seine produzierte Form konsumiert. Beim Verdrahtungs-Schritt fängt die Typinferenz der Plattform Form-Nichtübereinstimmungen zur Graph-Edit-Zeit ab, bevor die runtime sie sieht.

Häufige Verdrahtungs-Fehler, die das Typsystem früh fängt: das Modell erwartet Image einer bestimmten Größe und der Upstream emittiert rohes Image ohne Resizing (eine Resize-Transformation einfügen), das Modell emittiert [BoundingBox], aber der nachgelagerte Konsument erwartet Polygon<Double> (einen Konverter einfügen), das Modell braucht Vorverarbeitung, die die Plattform als separates component bereitstellt (es als vertex hinzufügen). Ein korrekt verdrahteter Graph hält diese aus der runtime heraus; ein nicht gefangener produziert einen verwirrenden Laufzeitfehler.

Die Integration beweisen

Verwende dies jedes Mal. Dass der Bind gültig ist, ist nicht dasselbe wie dass das Modell korrekt ist.

Beweis ist die in Verhalten beweisen beschriebene Schleife: die zu testende Einheit identifizieren (das Artefakt, nicht das component oder das backend), ein Fixture-Set einfrieren, sie durch das deployte backend laufen lassen und beobachtete Outputs mit semantischen Erwartungen vergleichen. Modell-Beweis prüft Bedeutung, nicht Form: ein Detektor, der gültiges JSON mit den falschen Labels emittiert, ist kaputt, ein Transkriptionsmodell, das wohlgeformten Text in der falschen Sprache emittiert, ist kaputt, ein Segmentierungsmodell, das gültige Polygone im falschen Koordinatensystem emittiert, ist kaputt. Schema-Validierung fängt keinen davon.

Eine Triton-spezifische Prüfung gehört in die Beweis-Schleife für ONNX-auf-Triton-Artefakte: die config.pbtxt-dims müssen Element für Element mit der ONNX-Form übereinstimmen. Symbolische ONNX-Dimensionen erscheinen der runtime als -1, sodass eine Config, die eine konkrete Größe gegen eine symbolische Dimension festnagelt, nicht lädt. Bestätige, dass die deklarierten Formen des Repositorys mit dem ONNX-Graphen übereinstimmen, bevor du ein Lade-Versagen als Modell-Problem behandelst.

Cold-Start-Messung ist Teil des Beweises, nicht davon getrennt. Modelle laden oft faul bei der ersten Nutzung: ein Hub-Modell zieht bei der ersten Anfrage, ONNX initialisiert bei der ersten Inferenz, Triton lädt das Repository, wenn die erste passende Anfrage eintrifft. Die Latenz der ersten Anfrage kann 10–30 Sekunden über dem Steady-State liegen, sodass ein Benchmark, der nur die warme runtime misst, den Kaltpfad unterschätzt. Lass das Fixture-Set zweimal laufen, einmal kalt und einmal warm, und melde beides.

Versionsvergleich

Verwende dies immer dann, wenn ein Kandidaten-Artefakt gegen ein Bisheriges antritt.

"Ist der Kandidat besser als das Bisherige" wird beantwortet, indem dasselbe Fixture-Set gegen zwei Artefakte in Geschwister-vertex-Bindungen läuft, mit denselben semantischen Kriterien, die auf beide angewendet werden. Das Delta ist der Beleg, den die Promotion-Entscheidung braucht. Ein Kandidat, der gut, aber schlechter als das Bisherige ist, sollte nicht promotet werden; ein Kandidat, der unvollkommen, aber materiell besser als das Bisherige ist, sollte es oft.

Das Festnageln ist es, was den Vergleich ehrlich hält. Beide Artefakte haben adressierbare file_ids (oder adressierbare Hub-IDs), das Fixture-Set ist adressierbar, und das backend ist derselbe Graph mit zwei verschiedenen Bindungen. Das Artefakt selbst ist die einzige zu testende Variable.

Erwähnenswerte Nichtübereinstimmungs-Risiken

Die Menge der Nichtübereinstimmungs-Formen, die ein sauberes Deploy überleben — falsche Labels, falscher Tokenizer, falsche Vorverarbeitung, falsche Aufgabe, kaltes-Laden-mit-kaputt-verwechselt, fehlender Zugriff auf ein gated Modell — ist in /concepts/models aufgezählt. Lass die Beweis-Schleife gegen jede zutreffende für das zu testende Artefakt laufen; sie zu prüfen ist der Unterschied zwischen "dieses Modell funktioniert" und "dieses Modell funktionierte an dem einen Beispiel, das wir probiert haben".

Wo das hineinpasst

Modell-Integration ist der längste einzelne Workflow auf der Plattform, weil er mehr tut als testen. Das Artefakt tritt in den workspace ein, wird in den richtigen vertex gebunden, in ein backend verdrahtet, das seine Typen respektiert, an repräsentativen Inputs ausgeübt und für das Laufzeit-Verhalten charakterisiert. Jeder Schritt ist klein; einen zu überspringen liefert ein Modell aus, das in der Produktion aus einem vorhersehbaren Grund unterperformt.

Die Plattform macht die Schleife reproduzierbar: festgenagelte Artefakte, festgenagelte components, festgenagelte backends, deklarative Verdrahtung, an jedem Schritt festgehaltene Belege. Die Disziplin gehört dem Team; die Primitive halten sie wiederholbar.

Verwandt

War diese Seite hilfreich?