Benutzerhandbücher für KI-Runtime

Verfolgen Sie den GPU-Verbrauch und die Kosten mit der Systemtabelle für abrechenbare Nutzung, sehen Sie sich Beispiele an und beheben Sie häufige Fehler.

Von Slurm migrieren

Wenn Sie von einem Slurm-Cluster und nicht von klassischen Databricks kommen, siehe Migrate from Slurm , um zu sehen, wie sbatch, srun/torchrun, Partitionen und gemeinsame Dateisysteme auf die Databricks-CLI abgebildet werden.

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.

Die AI-Runtime-Gebühren pro GPU-Stunde für die SKU „Model Training“ betragen:

• H100 bei Bedarf: $7,00/GPU-Stunde (USA Ost)
• A10 auf Abruf: $4,90/GPU-Stunde (US-Ost)

Examples

Entdecken Sie Notebook-Tutorials und laufbare Databricks CLI-Rezepte, die nach Aufgaben geordnet sind. Siehe AI-Laufzeitbeispiele.

Troubleshooting

Genie Code kann helfen, Umwelt- und Abhängigkeitsprobleme zu lösen und GPU- sowie verteilte Workload-Ausfälle in Notebooks zu untersuchen, die mit KI-Laufzeit verbunden sind. Siehe Use Genie Code with AI Runtime.

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. Siehe die serverlosen GPU-Release Notes für Umgebung 6, Umgebung 5 und Umgebung 4 für Informationen zu vorinstallierten Python-Bibliotheken. 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