Der erste Trainingslauf bricht ab, bevor auch nur ein Batch durchläuft. Schuld ist meist eine winzige Zahl im Traceback: der dtype.

Eine Zahl ist eine Zahl, und PyTorch rechnet das schon richtig zusammen. Das klingt plausibel, weil Python selbst beim Rechnen nie über Typen meckert.

Tatsächlich legt der dtype (Datentyp) fest, wie jede Zahl im Speicher abgelegt ist: Float32 braucht 32 Bit pro Zahl, Float64 (Double) 64 Bit. PyTorch-Layer wie nn.Linear erzeugen ihre Parameter standardmäßig als Float32, und auch die meisten Fertigmodelle rechnen mit Float32. PyTorch erlaubt in den meisten Operationen keine stillen Typumwandlungen: Ein linearer Layer mit Float32-Parametern, der einen Float64-Eingabetensor erhält, bricht mit einem RuntimeError ab, statt automatisch umzuwandeln.

Normale Python-Zahlen und auch viele NumPy-Ergebnisse kommen als Double an. Wer daraus mit torch.tensor(…) einen Tensor baut, erhält ohne Angabe oft Float64. Der Fehler wirkt deshalb wie ein Bug, ist aber gewollte Strenge.

Die Umwandlung geschieht gezielt mit tensor.to(torch.float32) oder direkt beim Erzeugen mit torch.tensor(daten, dtype=torch.float32).

Woran man es erkennt: Der Traceback nennt einen RuntimeError und zeigt beide dtypes an, etwa float32 neben float64. Damit steht die Ursache direkt in der Meldung.

dtype heißt nicht „egal, Hauptsache Zahl“, sondern eine feste Speicherform, die Modell und Tensor teilen müssen. Wie beim Gerät gilt: to(…) erzeugt eine Kopie, deshalb das Ergebnis wieder demselben Namen zuweisen, etwa x = x.to(torch.float32).

📌 Float32-Standard · RuntimeError statt stiller Umwandlung · dtype beim Erzeugen mitgeben

📚 KI von Grund auf · Tag 22 von 30
#PyTorch #machinelearning #deeplearning