Datei-Bindung

Eine File wird in zwei Zügen nutzbar: sie wird als typisiertes Artefakt in den Workspace hochgeladen und dann in einen Slot eines Backend-Vertex gebunden. Der Upload macht das Artefakt adressierbar; das Binden verdrahtet es in einen lauffähigen Graphen. Die beiden sind absichtlich getrennt — dieselbe hochgeladene File kann in viele backends gebunden werden, und das Umlegen einer Bindung ist die Art, ein Artefakt gegen ein anderes auszutauschen, ohne die component anzufassen.

Hochladen

Der Upload schiebt eine lokale Datei oder ein Verzeichnis in den Workspace-Dateispeicher und registriert sie mit einem Typ, einem Anzeigenamen und einer Beschreibung:

ppl file upload <path> --type <file_type> --name "<display>" --readme @./README.mdCopyppl file upload <path> --type <file_type> --name "<display>" --readme @./README.md --config ./file.config.ymlCopy

--type ist das entscheidende Flag. Es bestimmt, welche Art von Artefakt der Upload ist und welche file_schema-Slots die resultierende File akzeptieren. Ein falscher Typ hier zeigt sich erst später — entweder lehnt die Bindung ihn ab, oder er bindet und die Laufzeit erreicht einen inkompatiblen Loader. Die Plattform stellt ein breites Vokabular bereit (Modell-Artefakte, Daten-Fixtures, config- und Dokumenttypen); die vollständige Liste steht unter Dateitypen.

Der Triton-Fall ist hervorzuheben, weil er der häufigste Upload-Fehler ist: --type triton_model erwartet ein Triton-Modell-Repository-Verzeichnis, das als Verzeichnispfad übergeben wird, kein vorab getartes Archiv. Eine Beschreibung ist ebenfalls erforderlich — --readme inline oder --readme @<path> von der Festplatte — denn ein Upload, der sie auslässt, bleibt an einer Editor-Abfrage hängen, die ein Agent-Ablauf nicht beantworten kann.

Config mit der Datei mitführen

Eine File kann ein --config-Dokument mitführen, und das ist das Muster für ein Artefakt, das seine eigenen Laufzeit-Defaults mitbringen soll:

tags:  - detector  - warehouseconfig_schema:  confidence_threshold:    type: Double    default: 0.35  labels:    type: String    default: warehouse_labels

Die tags sind durchsuchbare Workspace-Metadaten. Die config_schema-Defaults werden über den Namen abgeglichen: jeder Eintrag, dessen Name mit einem Parameter des konsumierenden Vertex übereinstimmt, ersetzt den Wert dieses Parameters zur Bindezeit. Ein Detektor, der confidence=0.35 mitliefert, bringt das backend auf 0.35 ohne separaten Parameter-Schritt. Der Nebeneffekt ist entscheidend — ein zuvor mit ppl backend change-parameter gesetzter Wert wird für die Parameter ersetzt, die der Datei gehören, sodass alles in config_schema der Datei gehört und alles andere unter Kontrolle des Graphen bleibt.

An einen Vertex binden

Das Binden hängt eine file_id an einen benannten Slot eines bestimmten Vertex:

ppl backend add-file <backend_id> --vertex <vertex_id> --key <file_schema_key> --file <file_id>Copy

--key ist der Slot, den die konsumierende component deklariert hat (siehe Datei-Schema). Die Plattform validiert, dass der Typ der File den Slot erfüllt, sodass eine Nichtübereinstimmung zur Bindezeit statt zur Laufzeit abgelehnt wird. Die Bindung ist eine einzelne Operation im event-gesourcten Backend-Log — sie fügt die Bindung hinzu, wendet jede config-Defaults an, die die File mitführte, und wird Teil der reproduzierbaren Historie des backends. Das nächste Deployment übernimmt sie, und die vorherige Bindung ist rückgängig machbar.

Die Bindung beweisen

Eine gebundene File bedeutet, dass die Plattform ihren Typ für den Slot akzeptiert hat. Sie bedeutet nicht, dass das Artefakt korrekte Ausgaben erzeugt: ein Detektor kann binden und die falschen Labels laden, ein Tokenizer kann binden und das Modell-Vokabular verfehlen, ein Triton-Repository kann binden und ein Backend referenzieren, das dem Container fehlt. Jedes davon zeigt sich erst, wenn die Laufzeit die File ausführt. Der Beweisschritt ist ein Fixture-Lauf durch das deployte backend — die günstige Form ist ein Live-Backend-Test, die gründliche Form ist die Versionsvergleichsschleife in Verhalten beweisen.

Verwandtes

• Datei-Schema — der Slot, auf den eine Bindung zielt.
• Dateitypen — die file_type-Werte, die ein Slot akzeptiert.
• Datei-Upload und Backend-Bindung — die praktische Anleitung.
• Verhalten beweisen — bestätigen, dass die gebundene File sich korrekt verhält.
• Backend-Operationen — wie die Bindung im Operationslog landet.