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> ]
Copy

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
)
Copy

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'));
Copy

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'
)
);
Copy

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'
Copy

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')
);
Copy

Das folgende Beispiel filtert Inferenzprotokolle nach Modellversion:

SELECT *
FROM TABLE(
  INFERENCE_TABLE(
    'my_model',
    MODEL_VERSION => 'v1'
  )
);
Copy

Das folgende Beispiel filtert Inferenzprotokolle nach Version und Dienst:

SELECT *
FROM TABLE(
  INFERENCE_TABLE(
    'my_model',
    MODEL_VERSION => 'v1',
    SERVICE => 'my_service'
  )
);
Copy

Das folgende Beispiel filtert Inferenzprotokolle nach Version und Gateway:

SELECT *
FROM TABLE(
  INFERENCE_TABLE(
    'my_model',
    MODEL_VERSION => 'v1',
    GATEWAY => 'my_gateway'
  )
);
Copy

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

snow.model_serving.request.data.<Spalte>

Die an das Modell gesendeten Eingabe-Features.

snow.model_serving.response.data.<Spalte>

Die vom Modell zurückgegebene Inferenzausgabe.

snow.model_serving.request.timestamp

Der Zeitpunkt, zu dem die Anfrage den Inferenzdienst erreicht hat.

snow.model_serving.response.code

Der HTTP-Status (z. B. 200 für Erfolg und 5xx für Fehler).

snow.model_serving.truncation_policy

Zeigt an, ob die Daten die Größenbeschränkungen überschritten haben (NONE oder TRUNCATED_DEFAULT). Weitere Informationen dazu finden Sie unter Datenkürzungslogik.

snow.model_serving.last_hop_id

Spiegelt die letzte Gateway-ID wider, von der die Anfrage an den Inferenzdienst gesendet wurde.

snow.model_serving.hop_ids

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 TRUNCATED.

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

snow.model.version.id

Eindeutiger Bezeichner für die Modellversion.

snow.model.version.name

Name der Modellversion.

RECORD_ATTRIBUTES

In der folgenden Tabelle sind die Felder des Datensatzattributschemas beschrieben:

Feld

Beschreibung

snow.model_serving.function.name

Name der Modellfunktion, die aufgerufen wurde.

snow.model_serving.last_hop_id

Das ID des letzten Gateways, das die Anfrage verarbeitet hat.

snow.model_serving.hop_ids

Liste der Gateway-IDs, die die Anfrage bearbeitet haben.

snow.model_serving.request.data.<Spalte>

Eingabefelder, bei denen <column> für bestimmte Eingabefeldnamen steht.

snow.model_serving.request.timestamp

Zeitstempel, wann die Anfrage vom Inferenzdienst erfasst wurde.

snow.model_serving.response.data.<Spalte>

Antwortdaten, bei denen <column> die Felder für die Inferenzantwort enthält.

snow.model_serving.response.timestamp

Zeitstempel, wann die Antwort vom Dienst erfasst wurde.

snow.model_serving.response.code

Antwortcode des Inferenzdienstes (z. B. 200, 5xx).

snow.model_serving.truncation_policy

Gibt an, ob Daten gekürzt wurden. Die Werte sind NONE oder TRUNCATED_DEFAULT.