Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Important
Dieses Feature befindet sich in der Public Preview.
Migrieren Sie vorhandene Deep Learning-Workloads von klassischen Databricks-Clustern zu AI-Runtime, verfolgen Sie die GPU-Nutzung und -Kosten mit der tabelle mit dem abrechnenden Nutzungssystem, und suchen Sie nach Beispielnotizbüchern und Korrekturen für häufige Fehler.
Migrieren von klassischen GPU-Workloads auf serverlose Server
Wenn Sie eine vorhandene Deep Learning-Workload von einem klassischen Databricks-Cluster (mit Databricks Runtime ML) auf serverlose (mit AI Runtime) verschieben, führen Sie die folgenden Schritte aus:
- Ersetzen Sie clusterabhängigen Code. Entfernen Sie alle Verweise auf Spark-basiertes verteiltes Training (z. B.
TorchDistributor) und ersetzen Sie sie durch den@distributedDekorator vonserverless_gpu. - Aktualisieren des Ladens von Daten. Ersetzen Sie direkte DBFS-Pfade durch Unity-Katalogvolumespfade (
/Volumes/...). Ersetzen Sie lokale Spark DataFrame-Vorgänge durch Spark Connect. Verwenden Sie zum Streamen dateibasierter Daten von VolumesUCVolumeDatasetausserverless_gpu.data. Siehe Laden von Daten auf AI-Runtime. - Installieren Sie Abhängigkeiten neu. Verlassen Sie sich nicht auf vorinstallierte Databricks Runtime ML-Bibliotheken. Fügen Sie explizite
%pip installBefehle für alle erforderlichen Pakete hinzu. - Aktualisieren Sie Prüfpunkt-Pfade. Verschiebe Prüfpunkte aus DBFS oder lokalem Speicher in Unity Catalog-Volumes (
/Volumes/<catalog>/<schema>/<volume>/...). Verwenden Sie für verteiltes CheckpointingUCVolumeWriterundUCVolumeReaderausserverless_gpu.data, die E/A über lokales NVMe zwischenspeichern. Siehe Modell-Checkpointing. - Aktualisieren der MLflow-Konfiguration. Stellen Sie sicher, dass Experimentnamen absolute Pfade verwenden und Run-Namen konfigurieren, damit sie problemlos neu gestartet werden können.
- Testen Sie zuerst interaktiv. Überprüfen Sie Ihre Arbeitsauslastung in einem interaktiven Notizbuch, bevor Sie sie als Aufgabe planen.
Nachverfolgen von Nutzung und Kosten
Sie können ihre GPU-Ausgaben für KI-Runtime überwachen, indem Sie die Tabelle des abrechnungsfähigen Nutzungssystems (system.billing.usage) abfragen. Die folgende Abfrage gibt die Gesamtauslastung für serverlose GPU-Workloads zurück:
SELECT
SUM(usage_quantity)
FROM
system.billing.usage
WHERE
product_features.serverless_gpu IS NOT NULL
Weitere Informationen zum Schema der abrechnungsfähigen Verwendungstabelle finden Sie in der Referenz zu abrechnungsfähigen Verwendungssystemtabellen.
AI-Runtime-Gebühren pro GPU-Stunde auf der Modellschulungs-SKU zu den folgenden Preisen:
- H100 bei Bedarf: $7,00/GPU-Stunde (USA Ost)
- A10 auf Abruf: $4,90/GPU-Stunde (US-Ost)
Beispiel-Notebooks
Die folgenden Kategorien von Beispielnotizbüchern stehen Ihnen bei den ersten Schritten zur Verfügung:
| Kategorie | Description |
|---|---|
| Große Sprachmodelle (LLMs) | Feinabstimmung großer Sprachmodelle einschließlich parametereffizienter Methoden (LoRA, QLoRA) |
| Maschinelles Sehen | Objekterkennung, Bildklassifizierung und andere CV-Aufgaben |
| Deep Learning Recommender-Systeme | Erstellen von Empfehlungssystemen mit modernen Deep Learning-Ansätzen wie Zweiturmmodellen |
| Klassisches ML | Herkömmliche ML-Aufgaben einschließlich XGBoost-Modellschulung und Zeitreihenprognose |
| Verteilte Multi-GPU-Schulung | Skalieren von Schulungen über mehrere GPUs mithilfe der Serverless GPU-API |
Die vollständige Liste finden Sie unter AI-Runtime-Beispielnotizbücher.
Troubleshooting
Genie Code kann dabei helfen, Korrekturen für Bibliotheksinstallationsfehler zu diagnostizieren und vorzuschlagen. Siehe Verwenden von Genie Code zum Debuggen von Computeumgebungsfehlern.
Um interaktiv auf der Berechnung zu debuggen, verwenden Sie das Webterminal, um Shell-Befehle auszuführen, die GPU-Nutzung mit nvidia-smizu überprüfen und Dateien zu verwalten. Das Webterminal ist verfügbar, wenn es mit der serverlosen GPU-Umgebung Version 5 oder höher verbunden ist. Siehe Ausführen von Shellbefehlen im Azure Databricks-Webterminal.
ValueError: Die Größe von numpy.dtype hat sich geändert, was auf eine binäre Inkompatibilität hinweisen könnte. Erwartet: 96 von C-Header, erhalten: 88 von PyObject
Der Fehler tritt in der Regel auf, wenn während der Kompilierung eines abhängigen Pakets eine Diskrepanz zwischen den verwendeten NumPy-Versionen und der derzeit in der Laufzeitumgebung installierten NumPy-Version besteht. Diese Inkompatibilität tritt häufig aufgrund von Änderungen der C-API von NumPy auf und ist besonders von NumPy 1.x auf 2.x spürbar. Dieser Fehler gibt an, dass das im Notizbuch installierte Python-Paket möglicherweise die NumPy-Version geändert hat.
Empfohlene Lösung:
Überprüfen Sie die NumPy-Version in der Laufzeit, und stellen Sie sicher, dass sie mit Ihren Paketen kompatibel ist. Informationen zu vorinstallierten Python-Bibliotheken finden Sie in den Versionshinweisen zu Serverless GPU Compute für Umgebung 4 und Umgebung 3 . Wenn Sie eine Abhängigkeit von einer anderen Version von NumPy haben, fügen Sie diese Abhängigkeit zu Ihrer Computeumgebung hinzu.
PyTorch kann libcudnn beim Installieren von Taschenlampen nicht finden
Wenn Sie eine andere Version von torchinstallieren, wird möglicherweise der Fehler angezeigt: ImportError: libcudnn.so.9: cannot open shared object file: No such file or directory. Dies liegt daran, dass torch nur im lokalen Pfad nach der cuDNN-Bibliothek sucht.
Empfohlene Lösung:
Installieren Sie die Abhängigkeiten neu, indem Sie --force-reinstall bei der Installation von torch hinzufügen:
%pip install torch --force-reinstall