Problembehandlung¶

In dieser Anleitung wird erklärt, wie Sie Ihre Bereitstellungen in Snowpark Container Services (SPCS) überwachen und häufige Probleme im Zusammenhang mit Paketabhängigkeiten, Arbeitsspeicher und Umgebungskonfigurationen beheben.

Überwachen der SPCS-Bereitstellungen¶

Sie können die Bereitstellung überwachen, indem Sie die Dienste, die gestartet werden, mit der folgenden SQL-Abfrage überprüfen.

SHOW SERVICES IN COMPUTE POOL my_compute_pool;

Copy

Zwei Jobs werden gestartet:

MODEL_BUILD_xxxxx: Die letzten Zeichen des Namens werden randomisiert, um Namenskonflikte zu vermeiden. Dieser Job erstellt das Image und endet, nachdem das Image erstellt wurde. Wenn bereits ein Image existiert, wird der Job übersprungen.

Die Protokolle sind nützlich, um Probleme wie Konflikte in Paketabhängigkeiten zu beheben. Um die Protokolle dieses Jobs zu sehen, führen Sie die folgende SQL aus. Achten Sie darauf, dass Sie die gleichen letzten Zeichen verwenden:
```
CALL SYSTEM$GET_SERVICE_LOGS('MODEL_BUILD_xxxxx', 0, 'model-build');
```
Copy
MYSERVICE: Der Name des Dienstes, wie er im Aufruf von create_service angegeben ist. Dieser Job wird gestartet, wenn der MODEL_BUILD-Job erfolgreich ist oder übersprungen wird. Um die Protokolle dieses Jobs zu sehen, führen Sie die folgende SQL aus:
```
CALL SYSTEM$GET_SERVICE_LOGS('MYSERVICE', 0, 'model-inference');
```
Copy

Wenn die Protokolle nicht über SYSTEM$GET_SERVICE_LOG verfügbar sind, da der Build-Job oder der Dienst gelöscht wurde, können Sie die Ereignistabelle (falls aktiviert) überprüfen, um die Protokolle zu sehen:

SELECT RESOURCE_ATTRIBUTES, VALUE
FROM <EVENT_TABLE_NAME>
WHERE true
    AND timestamp > dateadd(day, -1, current_timestamp())  -- choose appropriate timestamp range
    AND RESOURCE_ATTRIBUTES:"snow.database.name" = '<db of the service>'
    AND RESOURCE_ATTRIBUTES:"snow.schema.name" = '<schema of the service>'
    AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<Job or Service name>'
    AND RESOURCE_ATTRIBUTES:"snow.service.container.instance" = '0'  -- choose all instances or one particular
    AND RESOURCE_ATTRIBUTES:"snow.service.container.name" != 'snowflake-ingress' --skip logs from internal sidecar
ORDER BY timestamp ASC;

Copy

Paketkonflikte¶

Zwei Systeme bestimmen, welche Pakete im Service Container installiert werden: das Modell selbst und der Inferenzserver. Um Konflikte mit den Abhängigkeiten Ihres Modells zu minimieren, benötigt der Inferenzserver nur die folgenden Pakete:

gunicorn<24.0.0
starlette<1.0.0
uvicorn-standard<1.0.0

Vergewissern Sie sich, dass die Modellabhängigkeiten, zusammen mit den oben genannten, von pip oder conda aufgelöst werden können.

Wenn ein Modell sowohl conda_dependencies als auch pip_requirements eingestellt hat, werden diese über conda wie folgt installiert:

Kanäle:
- conda-forge
- nodefaults
Abhängigkeiten:
- all_conda_packages
- pip:
  - all_pip_packages

Snowflake ruft beim Erstellen von Container-Images Anaconda-Pakete von conda-forge ab, da der Snowflake-Conda-Kanal nur in Warehouses verfügbar ist und der Standardkanal von den Benutzenden verlangt, dass sie die Anaconda-Nutzungsbedingungen akzeptieren, was während eines automatisierten Builds nicht möglich ist. Um Pakete aus einem anderen Kanal zu erhalten, z. B. Standards, geben Sie jedes Paket mit dem Namen des Kanals an, wie in defaults::pkg_name.

Bemerkung

Wenn Sie sowohl conda_dependencies als auch pip_requirements angeben, wird das Container-Image erfolgreich erstellt, auch wenn die beiden Sätze von Abhängigkeiten nicht kompatibel sind, was dazu führen kann, dass das resultierende Container-Image nicht so funktioniert, wie Sie es erwarten. Snowflake empfiehlt, nur conda_dependencies oder nur pip_requirements zu verwenden, nicht beides.

Dienst außerhalb des Speichers¶

Einige Modelle sind nicht Thread-sicher. Daher lädt Snowflake für jeden Worker-Prozess eine Kopie des Modells in den Speicher. Dies kann bei großen Modellen mit einer größeren Anzahl von Workern dazu führen, dass der Speicher überlastet wird. Versuchen Sie, num_workers zu reduzieren.

Sie können die Dienstspezifikation nicht ändern¶

Die Spezifikationen für den Modell-Build und die Inferenzdienste können nicht anhand von ALTER SERVICE geändert werden. Sie können nur Attribute wie TAG, MIN_INSTANCES und so weiter ändern. Da das Image jedoch im Image Repository veröffentlicht ist, können Sie die Spezifikation kopieren, sie ändern und daraus einen neuen Dienst erstellen, den Sie manuell starten können.

Paket nicht gefunden¶

Die Bereitstellung des Modells ist während der Image-Erstellungsphase fehlgeschlagen. model-build-Protokolle deuten darauf hin, dass ein angefordertes Paket nicht gefunden wurde. (In diesem Schritt wird standardmäßig conda-forge verwendet, wenn das Paket in conda_dependencies erwähnt wird.)

Die Paketinstallation kann aus einem der folgenden Gründe fehlschlagen:

Der Paketname oder die Version ist ungültig. Überprüfen Sie die Schreibweise und die Version des Pakets.
Die angeforderte Version des Pakets existiert nicht in conda-forge. Sie können versuchen, die Versionsspezifikation zu entfernen, um die neueste in conda-forge verfügbare Version zu erhalten, oder verwenden Sie stattdessen pip_requirements. Sie können alle verfügbaren Pakete hier durchsuchen.
Manchmal benötigen Sie ein Paket aus einem speziellen Kanal (z. B. pytorch). Fügen Sie ein channel_name::-Präfix für die Abhängigkeit hinzu, z. B. pytorch::torch.

Huggingface Hub-Version stimmt nicht überein¶

Ein Hugging Face-Modellinferenzdienst kann mit der folgenden Fehlermeldung fehlschlagen:

ImportError: huggingface-hub>=0.30.0,<1.0 is required for a normal functioning of this module, but found huggingface-hub==0.25.2

Copy

Das liegt daran, dass das transformers-Paket nicht die korrekten Abhängigkeiten von huggingface-hub angibt, sondern stattdessen im Code überprüft. Um dieses Problem zu beheben, protokollieren Sie das Modell erneut, wobei Sie dieses Mal die erforderliche Version von huggingface-hub in den conda_dependencies oder pip_requirements explizit angeben.

Torch kann nicht mit CUDA kompiliert werden¶

Die typische Ursache für diesen Fehler ist, dass Sie sowohl conda_dependencies als auch pip_requirements angegeben haben. Wie im Abschnitt zu Paketkonflikten erwähnt, ist conda der Paketmanager, der für das Erstellen des Container-Images verwendet wird. Anaconda löst keine Pakete von conda_dependencies und pip_requirements zusammen auf und gibt conda-Paketen den Vorrang. Dies kann dazu führen, dass die conda-Pakete nicht mit den pip-Paketen kompatibel sind. Möglicherweise haben Sie torch in pip_requirements angegeben, und nicht in conda_dependencies. Erwägen Sie, die Abhängigkeiten in entweder in conda_dependencies oder pip_requirements zu konsolidieren. Wenn dies nicht möglich ist, geben Sie bevorzugt die wichtigsten Pakete in conda_dependencies an.