Eine Solution-Demo veröffentlichen

TL;DR

Das Veröffentlichen verwandelt eines deiner backends — eine solution, die du gebaut hast — in eine öffentliche, teilbare Demo, die jeder an ihrer eigenen URL öffnen kann, ohne Konto. Ein solution-Eintrag bindet dieses backend an einen öffentlichen Alias, einen Ziel-node-flavor für besucher-gespawnte Läufe, Taxonomie-Tags (Branche, Geschäftsziel, Modalität) und ein optionales Budget für gesponserte Läufe, das der Vorlagen-Workspace bezahlt.
Das Veröffentlichen macht die Demo eigenständig öffentlich. Der kuratierte Solutions-Katalog — die Durchsuchen-und-Entdecken-Vitrine — zeigt eine plattformausgewählte Teilmenge veröffentlichter Demos; dort zu erscheinen ist eine Plattformentscheidung, kein Flag, das du setzt. Deine Demo ist an ihrer öffentlichen URL erreichbar, ob vorgestellt oder nicht.
Ein Eintrag wird aus einem bestehenden backend veröffentlicht. Die components, der Graph, die Parameter und die Dateibindungen des backends sind das, womit Besucher interagieren; der Eintrag ist die Veröffentlichungsschicht, die sie an eine öffentliche URL bindet.
Zwei CLI-Verben decken die Surface ab: ppl solution create registriert einen Eintrag, und ppl solution update patcht bestehende Felder. Ein backend trägt höchstens einen Eintrag; sobald er existiert, gibt create einen Konflikt zurück und update ist der Weg, ihn zu ändern.
Auf Plänen, die gesponserte Läufe enthalten, kann der Vorlagen-Workspace Besucher-Rechenleistung bis zu einem konfigurierbaren Budget abdecken. Wenn das Budget null erreicht, stoppen Besucherläufe, bis es aufgefüllt wird.
Der flavor ist der runtime-Vertrag für Besucher: er pinnt die node-Klasse, auf der ihre On-Demand-Läufe landen, was Cold-Start-Zeit, GPU-Klasse und Kapazität für die Besuchererfahrung festlegt.

Was ein solution-Eintrag ist

Ein solution-Eintrag ist eine veröffentlichte Bindung zwischen einem workspace-eigenen backend und einer öffentlichen URL. Der Eintrag hält die öffentlich zugewandte Konfiguration — Alias, flavor, Taxonomie-Tags, Budget für gesponserte Läufe — und referenziert das backend per ID; er kopiert nicht den Graphen des backends. Das backend zu ändern ändert das, womit Besucher interagieren, ohne ein separates Artefakt synchron zu halten.

Die Taxonomie-Tags (Branche, Geschäftsziel, Modalität) treiben die Entdeckung im Solutions-Katalog. Der flavor pinnt Besucherläufe an eine bekannte node-Klasse, sodass Cold-Start-Zeit und Kapazität vorhersehbar sind. Das Budget für gesponserte Läufe begrenzt team-finanzierte Besucher-Rechenleistung. Das Team verwaltet ein Objekt — den Eintrag — und die Plattform übernimmt Routing, Throttling und den Lebenszyklus der Besucher-Session.

Der Taxonomie-Satz, das Besucher-Session-Modell und der flavor-Katalog sind plattformdefiniert statt beliebig. Diese Beschränkungen sind es, die das Veröffentlichen zu einer Einzeiler-Operation machen. Ob eine veröffentlichte Demo dann im kuratierten Solutions-Katalog vorgestellt wird, ist eine plattformseitige Entscheidung; das Veröffentlichen gibt dir die öffentliche URL ohnehin.

Mentales Modell

dein Workspace                                    öffentlich zugewandt
──────────────                                    ─────────────
  backend (vertices, params, files, endpoints)
        │
        │ ppl solution create --backend <id>
        ▼
  solution-Eintrag ───▶  öffentliche solution-URL (per Alias aufgelöst)
   - alias                                                 │
   - flavor (Besucher-runtime-Klasse)                      ▼
   - industry / business-goal / modality            Besucher-Session
   - Budget für gesponserte Läufe                   (On-Demand-Deploy,
                                                     dem Vorlagen-
                                                     Workspace berechnet,
                                                     bis das Budget
                                                     leer ist)

Der Eintrag sitzt zwischen dem workspace-eigenen backend und der öffentlichen URL. Das backend zu ändern aktualisiert, was Besucher sehen; den Eintrag zu ändern aktualisiert, wie Besucher es finden und wie ihre Läufe aussehen.

Siehe Backends und Runtimes und nodes für die zugrunde liegenden Primitive.

Einen Eintrag erstellen

Verwende diesen Schritt, um ein backend zum ersten Mal zu veröffentlichen.

ppl solution create registriert den Eintrag. Die einzigen erforderlichen Flags sind --backend (das Workspace-backend, das du veröffentlichst) und --flavor (die node-Klasse, auf der Besucherläufe landen); alles andere ist optionale Metadaten.

ppl solution create \  --backend <backend_id> \  --flavor n1-gpu-micro \  --industry healthcare --industry retail \  --modality vision \  --alias vision-demo

Ein backend trägt höchstens einen Eintrag. Das erste create registriert ihn; ein zweites create für dasselbe backend gibt einen Konflikt zurück, statt zu überschreiben, sodass Änderungen an einem bestehenden Eintrag über ppl solution update laufen.

--flavor bestimmt die Besucher-runtime. Besucherläufe landen auf der node-Klasse des benannten flavors, was Cold-Start-Zeit, GPU- oder CPU-Klasse und verfügbaren RAM festlegt: eine GPU-Klasse für inferenz-lastige Demos, eine CPU-Klasse für leichtere Arbeit, eine Klasse mit mehr RAM für speichergebundene Modelle. Das CLI listet die verfügbaren flavors bei Bedarf; wähle einen, der zu dem passt, was ein repräsentativer Besucherlauf erfordert.

--alias ist der öffentliche Slug, den Besucher in der URL sehen (Kleinbuchstaben, max. 64 Zeichen; ein benutzerdefinierter Alias ist auf Plänen verfügbar, die benutzerdefinierte Demo-URLs enthalten). Lass ihn weg und der Eintrag ist über den Bezeichner des backends erreichbar; übergib ihn und die URL wird zu einem teilbaren Slug. Die Taxonomie-Tags (--industry, --business-goal, --modality) treiben die Entdeckung im Solutions-Katalog; wiederhole sie nach Bedarf.

Einen bestehenden Eintrag patchen

Verwende diesen Schritt, um ein Feld zu ändern, ohne den ganzen Eintrag neu anzugeben.

ppl solution update patcht die Felder, die du übergibst, und lässt alles andere unangetastet. Die häufigsten Gründe zum Patchen sind das Anpassen des Budgets für gesponserte Läufe, das Hinzufügen oder Entfernen eines Taxonomie-Tags oder das Löschen des öffentlichen Slugs (übergib --alias "").

ppl solution update --backend <backend_id> \  --industry healthcare --modality vision --sponsored 500

Der Patch ist inkrementell: nur die Felder, die der Aufruf benennt, ändern sich. Diese Form passt zu den häufigen Edits — das Budget für gesponserte Läufe anpassen, einen Tag korrigieren — ohne die volle Eintragskonfiguration neu anzugeben.

Gesponserte Läufe

Verfügbar auf Plänen, die gesponserte Läufe enthalten, wenn das Team Besucher-Rechenleistung bis zu einem Budget finanziert.

Das --sponsored <runs>-Feld setzt das Budget, das der Vorlagen-Workspace bezahlt. Jeder besuchergesteuerte Lauf dekrementiert den Zähler; wenn der Zähler null erreicht, stoppen Besucherläufe, bis das Budget aufgefüllt wird. Das Budget begrenzt team-finanzierte Besucher-Rechenleistung.

Ein Budget macht den Eintrag für Besucher kostenlos ausprobierbar bis zur konfigurierten Anzahl von Läufen. Es pro Eintrag zu setzen und über die Zeit zu ändern, lässt das Team entscheiden, welche Einträge kostenlose Tests anbieten und welche nicht.

Besuchererfahrung

Wenn ein Besucher die öffentliche URL des Eintrags öffnet, startet die Plattform eine Besucher-Session gegen das gebundene backend auf dem konfigurierten flavor. Der Session-Lebenszyklus ist plattformverwaltet: der Besucher braucht kein Konto, interagiert nicht direkt mit backends oder runtimes und sieht keinen internen Workspace-Zustand. An den Eintrag angehängte replays — deterministische Wiedergaben eines einzelnen vom Team aufgezeichneten Laufs — sind der leichtgewichtige Betrachtungspfad; Besucher sehen sie an, ohne echte Rechenleistung hochzufahren. Live-Trial-Läufe sind der schwerere Pfad, und sie verbrauchen das gesponserte Budget, wenn eines konfiguriert ist.

Eine häufige Konfiguration sind ein paar angehängte replays für Besucher, die sehen wollen, was der Eintrag tut, plus ein gesponsertes Live-Trial-Budget für Besucher, die ihre eigene Eingabe einspeisen wollen. Replays werden ohne Rechenverbrauch angezeigt; der Live-Trial ist durch das Budget begrenzt.

Wenn etwas schiefgeht

invalid_value bei --flavor — der flavor-Name ist nicht im aktuellen Katalog. Liste die verfügbaren flavors und wähle einen, der existiert.
conflict bei solution create — ein Eintrag existiert bereits für dieses backend (oder der gewählte Alias ist bereits von einem anderen Eintrag belegt). Nutze ppl solution update, um den bestehenden Eintrag zu patchen, oder wähle einen anderen Alias.
permission_denied — die Workspace-Identität, die zum Veröffentlichen verwendet wird, hat keinen Schreibzugriff auf das Ziel-backend oder die solution-Surface. Der Fix ist workspaceseitig, nicht CLI-seitig.
Besucherläufe gestoppt — das gesponserte Budget erreichte null, oder das gebundene backend wurde gelöscht. Fülle das Budget auf oder veröffentliche erneut gegen ein aktuelles backend.

Wo das hinpasst

Solutions ist die Veröffentlichungs-Surface, um eine solution-Demo vor Benutzer — Mitarbeiter, Kunden oder die Öffentlichkeit — in einer Operation zu stellen. Der Eintrag referenziert das backend per ID, sodass er mit dem backend synchron bleibt, während sich das backend ändert, und das Budget für gesponserte Läufe begrenzt team-finanzierte Besucher-Rechenleistung. Das Besucher-Session-Modell ist plattformverwaltet statt teamdefiniert.

Verwandt

Backends — das Objekt, an das ein Eintrag bindet.
Runtimes und nodes — das runtime-Gewebe, aus dem der flavor auswählt.
Deployen und überwachen — das nicht-öffentliche Gegenstück dieser Surface.
Applications — wenn eine Veröffentlichungs-Surface mehr als einen Eintrag braucht.
Solutions — backend-endpoints und die Konsumenten, die sie bedienen.