Automatische Erfassung von Inferenzprotokollen für Echtzeit-Inferenz¶
Verwenden Sie die automatische Erfassung in Snowflake ML, um automatisch jede Anfrage und Antwort zu protokollieren, die von einem Modelldienst verarbeitet werden. Die automatische Erfassung bietet einen sofortigen Einblick in die Erfolge von Anfragen, die Anfragefehler und die Eingaben, die hinter unerwarteten Vorhersagen stehen.
Anstatt Anfrage- oder Antwortdaten in eine Tabelle oder Ansicht weiterzuleiten, können Sie Inferenzanfrage- und Antwortdaten automatisch speichern. Anstatt Pipelines für die Datenerfassung und -überwachung korrekt zu erstellen, können Sie die automatische Erfassung verwenden.
Mit der automatischen Erfassung stehen Ihnen folgende Möglichkeiten zur Verfügung:
Schnelles Debuggen: Analysieren Sie historische Inferenzdaten, um Grenzfälle zu diagnostizieren und das Verhalten von Modellen zu verstehen.
Kontinuierliche Verbesserung Ihrer Modelle: Verwenden Sie reale Produktionsdaten, um hochwertige Datensets zu erstellen und neue Modelle zu trainieren.
Testen: Verwenden Sie die aus den Protokollen gesammelten Daten für A/B- und Shadow-Tests.
Für jede Inferenzanfrage protokolliert die automatische Erfassung Folgendes:
Nutzlast der Anfrage
Nutzlast der Antwort
Bezeichner der Modellversion
Dienstbezeichner
Metadaten zum Gateway-Routing
Zeitstempel von Anfrage/Antwort
Antwortcode (z. B. 200).
Bemerkung
Snowflake erfasst keine Daten für die Eingaben und Ausgaben mit der vLLM-Inferenz-Engine.
Diese Daten sind schreibgeschützt und können von Benutzenden nicht geändert werden.
Snowflake erfasst nur Antwortdaten für erfolgreiche Anfragen. Wenn eine Anfrage fehlschlägt, erfasst Snowflake keine Daten.
Voraussetzungen und Kompatibilität von Modellversionen¶
In den folgenden Abschnitten werden die Voraussetzungen und die Kompatibilität von Modellversionen für die automatische Erfassung beschrieben.
Anforderungen an die Zugriffssteuerung¶
Um erfasste Inferenzdaten zu konfigurieren und darauf zuzugreifen, muss Ihre Rolle über die folgenden Berechtigungen verfügen:
Berechtigung |
Objekt |
Anmerkungen |
|---|---|---|
OWNERSHIP |
Modell |
Erforderlich, um einen Dienst mit aktivierter automatischer Erfassung zu erstellen und Inferenztabellendaten mithilfe der Funktion INFERENCE_TABLE zu lesen. OWNERSHIP ist eine spezielle Berechtigung für ein Objekt, das automatisch der Rolle zugewiesen wird, die das Objekt erstellt hat, aber von der besitzenden Rolle mit dem Befehl GRANT OWNERSHIP auch auf eine andere Rolle (oder eine beliebige Rolle mit der Berechtigung MANAGE GRANTS) übertragen werden kann. In einem verwalteten Zugriffsschema kann nur die Person, die Eigentumsrechte am Schema besitzt (z. B. die Rolle mit der OWNERSHIP-Berechtigung für das Schema), oder eine Rolle mit der MANAGE GRANTS-Berechtigung Berechtigungen für Objekte im Schema, einschließlich zukünftiger Berechtigungszuweisungen, erteilen oder entziehen. |
OWNERSHIP |
Dienst |
Erforderlich, um in der Funktion list_service() anzugeben, ob für einen Dienst die automatische Erfassung aktiviert ist. OWNERSHIP ist eine spezielle Berechtigung für ein Objekt, das automatisch der Rolle zugewiesen wird, die das Objekt erstellt hat, aber von der besitzenden Rolle mit dem Befehl :doc:`GRANTOWNERSHIP </sql-reference/sql/grant-ownership> ` auch auf eine andere Rolle (oder eine beliebige Rolle mit der Berechtigung MANAGE GRANTS) übertragen werden kann. In einem verwalteten Zugriffsschema kann nur die Person, die Eigentumsrechte am Schema besitzt (z. B. die Rolle mit der OWNERSHIP-Berechtigung für das Schema), oder eine Rolle mit der MANAGE GRANTS-Berechtigung Berechtigungen für Objekte im Schema, einschließlich zukünftiger Berechtigungszuweisungen, erteilen oder entziehen. |
USAGE |
Modell, Dienst, Version, Gateway |
Erforderlich, um Entitäten in der Funktion INFERENCE_TABLE aufzulösen. |
Kompatibilität von Modellversionen¶
Jedes Modell existiert als Modellobjekt. Das Modellobjekt hat seine eigene Inferenztabelle, die die Daten und Metadaten für jede Inferenzanfrage enthält. Die automatische Erfassung protokolliert die Daten aus der Inferenztabelle des Modells. Jeder Modelldienst hat seine eigene Inferenztabelle.
Wenn Sie ein neues Modell erstellen, ist die automatische Erfassung automatisch aktiviert.
Modelle, die vor dem 23. Januar 2026 erstellt wurden, unterstützen keine automatische Erfassung. Sie müssen das Modell klonen und die automatische Erfassung für seinen Dienst aktivieren.
Verwenden Sie den folgenden Befehl, um ein vorhandenes Modell zu duplizieren:
CREATE [ OR REPLACE ] MODEL [ IF NOT EXISTS ] <name> [ WITH VERSION <version_name> ]
FROM MODEL <source_model_name> [ VERSION <source_version_or_alias_name> ]
Das mit dem vorangegangenen Befehl erstellte Modell hat eine leere Inferenztabelle. Weitere Informationen zum Aktivieren der automatischen Erfassung finden Sie unter Aktivieren der automatischen Erfassung.
Sie können auch eine Modellversion aus einer bestehenden Modellversion erstellen. Weitere Informationen dazu finden Sie unter Syntaxvariante.
Nachdem Sie das Modell dupliziert haben, können Sie die automatische Erfassung aktivieren, indem Sie die unter Aktivieren der automatischen Erfassung beschriebenen Schritte ausführen.
Aktivieren der automatischen Erfassung¶
Nachdem Sie ein neues Modell erstellt oder ein bestehendes Modell geklont haben, aktivieren Sie die automatische Erfassung für den Modelldienst unter Verwendung des Python-SDK. Weitere Informationen über den Modelldienst finden Sie unter Einsatz von Modellen für Echtzeit-Inferenz (REST API).
Verwenden Sie den folgenden Python-Code, um die automatische Erfassung zu aktivieren:
mv.create_service(
service_name="my_service",
service_compute_pool="my_compute_pool",
autocapture=True
)
Die mv-Variable ist das Objekt der Modellversion. Sie haben es definiert, als Sie das Modell in der Modell-Registry protokolliert haben.
Der Standardwert für die automatische Erfassung ist False. Stellen Sie sicher, dass Sie die automatische Erfassung für ein Modell aktivieren, das Sie nach dem 23. Januar 2026 erstellt und in der Modell-Registry protokolliert haben. Andernfalls schlägt die Erstellung des Dienstes fehl, weil das Modell keine Inferenztabelle hat.
Wichtig
Die Einstellung für die automatische Erfassung kann nicht geändert werden. Sie können die automatische Erfassung für einen bestehenden Modelldienst nicht aktivieren oder deaktivieren. Sie müssen den Dienst neu erstellen, um diese Konfiguration zu ändern. Wenn Sie den Dienst neu erstellen, ändert sich der Endpunkt, es sei denn, Sie verwenden einen stabilen Endpunkt oder ein stabiles Gateway.
Abfragen von Inferenzdaten¶
Um auf Ihre Protokolle zuzugreifen, verwenden Sie die Funktion INFERENCE_TABLE. Diese Funktion gibt Inferenzprotokolle für ein Modell zurück und unterstützt das Filtern nach Version, Dienst und Gateway. Nur Personen mit Eigentumsrechten an einem Modell können die Daten sehen, wenn sie über USAGE-Berechtigungen für das Gateway und den Dienst verfügen.
Grundlegendes Beispiel¶
Das folgende Beispiel zeigt, wie Sie alle Inferenzprotokolle für ein Modell mit der Funktion INFERENCE_TABLE abrufen. Diese Abfrage gibt alle erfassten Anfrage- und Antwortdaten für jede Inferenzanfrage zurück, die von den Diensten des Modells verarbeitet wird.
-- Fetch all inference logs for a specific model
SELECT * FROM TABLE(INFERENCE_TABLE('my_model'));
Beispiel für erweitertes Filtern¶
Sie können direkt innerhalb der Funktion INFERENCE_TABLE() nach bestimmten Versionen, Diensten oder Gateways filtern:
SELECT * FROM TABLE(
INFERENCE_TABLE(
'MY_MODEL',
VERSION => 'V1',
SERVICE => 'MY_PREDICTION_SERVICE',
GATEWAY => 'MY_GATEWAY'
)
);
Wichtig
Die Argumente für Dienst, Version und Gateway müssen zum Zeitpunkt der Abfrage vorhanden sein. Wenn ein neuer Dienst, eine neue Version oder ein neues Gateway mit demselben Namen wie eine zuvor vorhandene Komponente erstellt wurde, liefert die Abfrage nur Daten der aktuellen Version.
Sie können die folgende Prädikatklausel verwenden, um nach dem Funktionsnamen zu filtern:
WHERE RECORD_ATTRIBUTES:"snow.model_serving.function.name" = 'predict'
Bemerkung
Um die beste Leistung zu erzielen, filtern Sie nach einem Zeitbereich in der Spalte TIMESTAMP.
Abfragen von historischen Daten für gelöschte Entitäten¶
Die Inferenzdaten bleiben erhalten, nachdem Sie einen Dienst, eine Version oder ein Gateway gelöscht haben. Sie können diese historischen Daten abfragen, solange das Modell noch existiert.
Das folgende Beispiel gibt alle Inferenzprotokolle für ein Modell zurück:
SELECT *
FROM TABLE(
INFERENCE_TABLE('my_model')
);
Das folgende Beispiel filtert Inferenzprotokolle nach Modellversion:
SELECT *
FROM TABLE(
INFERENCE_TABLE(
'my_model',
MODEL_VERSION => 'v1'
)
);
Das folgende Beispiel filtert Inferenzprotokolle nach Version und Dienst:
SELECT *
FROM TABLE(
INFERENCE_TABLE(
'my_model',
MODEL_VERSION => 'v1',
SERVICE => 'my_service'
)
);
Das folgende Beispiel filtert Inferenzprotokolle nach Version und Gateway:
SELECT *
FROM TABLE(
INFERENCE_TABLE(
'my_model',
MODEL_VERSION => 'v1',
GATEWAY => 'my_gateway'
)
);
Datenschema und Metadaten¶
Snowflake erfasst nur Antwortdaten für erfolgreiche Anfragen. Wenn eine Anfrage fehlschlägt, erfasst Snowflake keine Daten.
Im Folgenden finden Sie die Datensatzattribute, die erfasst werden:
Feld |
Beschreibung |
|---|---|
|
Die an das Modell gesendeten Eingabe-Features. |
|
Die vom Modell zurückgegebene Inferenzausgabe. |
|
Der Zeitpunkt, zu dem die Anfrage den Inferenzdienst erreicht hat. |
|
Der HTTP-Status (z. B. 200 für Erfolg und 5xx für Fehler). |
|
Zeigt an, ob die Daten die Größenbeschränkungen überschritten haben (NONE oder TRUNCATED_DEFAULT). Weitere Informationen dazu finden Sie unter Datenkürzungslogik. |
|
Spiegelt die letzte Gateway-ID wider, von der die Anfrage an den Inferenzdienst gesendet wurde. |
|
Spiegelt die Liste der Gateway-IDs wider, die den Durchlaufpfad darstellen. Derzeit auf nur ein Gateway beschränkt. |
Datenkürzungslogik¶
Um die Systemleistung aufrechtzuerhalten, gibt es ein Limit von 1 MB für jedes Inferenzereignis. Wenn Anfrage und Antwort das Limit erreichen, führt Snowflake eine mehrstufige Kürzung durch, um so viel Funktionalität wie möglich zu erhalten.
Die folgende Tabelle zeigt den Kürzungsvorgang:
Stagingbereich |
Trigger |
Durchgeführte Aktion |
|---|---|---|
1: Sanfte Reduzierung |
> 700 KB |
Raw-Bytes entfernt; Zeichenfolgen > 2 KB gekürzt; JSON-Objekte ersetzt durch den Status |
2: Aggressiv |
> 900 KB |
Alle Zeichenfolgen werden weiter auf 256 Bytes gekürzt. |
3: Entfernung |
> 900 KB* |
Wird das Limit weiterhin überschritten, wird die Nutzlast gelöscht und durch eine schlanke Metadatenstruktur ersetzt. |
*Stufe 3 tritt auf, wenn die Metadaten allein den Schwellenwert nach der Reduzierung des Inhalts überschreiten.
Einschränkungen¶
Beachten Sie bei der Verwendung der automatischen Erfassung die folgenden Einschränkungen und Hinweise:
Unterstützung von LLM: Die automatische Erfassung wird für große Sprachmodelle (LLMs) nicht unterstützt.
Durchsatz: Die automatische Erfassung ist für einen Systemdurchsatz von ca. 300–400 Anfragen pro Sekunde (oder 10MB/s) pro Dienst ausgelegt.
Replikation: Sie können Inferenztabellen nicht replizieren. Replizierte Modelle haben keine Inferenztabellen im Zielkonto.
Aufbewahrung: Die Inferenzdaten bleiben auch dann erhalten, wenn der Dienst oder das Gateway gelöscht wird.
Warnung: Wenn Sie das Objekt löschen, werden alle zugehörigen Inferenzdaten dauerhaft gelöscht.
Ground Truth: Um die Abweichungsanalyse durchzuführen, führen Sie eine separate Ground-Truth-Tabelle und verknüpfen diese mithilfe allgemeiner Anfragen-IDs mit der INFERENCE_TABLE-Ausgabe.
Verbraucherkonten: Verbraucherkonten können keinen Dienst mit aktivierter automatischer Erfassung für freigegebene Modelle mit Inferenztabellen erstellen.
Leistung: Die automatische Erfassung ist so konzipiert, dass bei Inferenzanfragen keine zusätzliche Latenz entsteht. Bei extrem hohem Anfragevolumen kann es jedoch vorkommen, dass einzelne Erfassungen gelöscht werden.
Schema¶
Im Rahmen dieses Features werden die folgenden Werte zu den jeweiligen Spalten hinzugefügt:
RESOURCE_ATTRIBUTES¶
In der folgenden Tabelle sind die Felder des Ressourcenattributschemas beschrieben:
Feld |
Beschreibung |
|---|---|
|
Eindeutiger Bezeichner für die Modellversion. |
|
Name der Modellversion. |
RECORD_ATTRIBUTES¶
In der folgenden Tabelle sind die Felder des Datensatzattributschemas beschrieben:
Feld |
Beschreibung |
|---|---|
|
Name der Modellfunktion, die aufgerufen wurde. |
|
Das ID des letzten Gateways, das die Anfrage verarbeitet hat. |
|
Liste der Gateway-IDs, die die Anfrage bearbeitet haben. |
|
Eingabefelder, bei denen |
|
Zeitstempel, wann die Anfrage vom Inferenzdienst erfasst wurde. |
|
Antwortdaten, bei denen |
|
Zeitstempel, wann die Antwort vom Dienst erfasst wurde. |
|
Antwortcode des Inferenzdienstes (z. B. 200, 5xx). |
|
Gibt an, ob Daten gekürzt wurden. Die Werte sind |