Übrigens waren beim Benchmark alle SSDs leer!
Vergiss nicht, dass es immer dann einen Unterschied zwischen dem Füllstand der SSD gibt den man sieht und dem, den der Controller sieht, wenn sie nicht getrimmt werden oder ein Secure Erase ausgelöst wird, aber auf Secure Erase werde ich nachfolgend nicht weiter eingehen.
Nur durch TRIM wird sie auch aus Sicht des Sicht des Controller leer, wenn man Dateien löscht, sonst aber nicht. Alle Daten werden bei SSDs (wie bei HDDs) alle Daten immer unter einer logischen Adresse geschrieben werden und eben so lange erhalten bleiben, wie diese Adresse nicht überschrieben wurde. Während dies bei HDDs die Daten direkt überschreibt, da dort jeder logische Sektor direkt auf einen physikalischen Sektor umgerechnet wird (außer es ist ein Reservesektor der an Stelle eines defekten Sektors verwendet wird), was bei NAND ja nicht geht da man dies nur blockweise löschen kann und muss, bevor man einzelne Pages neu beschreiben kann, markiert der Controller die NAND Pages in denen die Daten für diesen logischen Sektor vorher standen als zu löschen, nutzt andere Pages und passt die Mappingtabelle an. Die SSD kann also demnach aus Sicht des Controllers nur immer voller werden und wenn sie einmal komplett beschrieben wurde, würde sie aus Sicht des Controller für immer voll bleiben, da das Löschen einer Datei ja nur das Setzen eines Flags in den Metadaten des Filesystems ist. Dies führt dann zu Leistungsverlust, vor allem beim Schreiben und erhöhtem Verschleiß und deshalb hat man dann TRIM eingeführt, womit der Host der SSD mitteilen kann, welche Daten nicht mehr gültig ist und mit TRIM passiert beim Löschen eben mehr als nur ein Flag in den Metadaten zu setzen, sondern vorher wird geschaut welche logischen Adressen die Datei belegt und es werden die entsprechenden TRIM Befehle für diese Adressen geschickt.
Da gibt es nur zwei Probleme: Erstens kann ein SSD Controller TRIM Befehle unter den Tisch fallen lassen, wenn er anderweitig zu beschäftigt ist und anderseits müssen die TRIM Befehle auch ankommen. Bei SATA waren da früher alte Treiber ein Problem, die dies Befehle nicht kannten und daher nicht durchgelassen und auch so manches USB Gehäuse hat sie nicht unterstützt. Das NVMe Protokoll wurden von Anfang an mit TRIM implementiert, aber ob alle USB Controller den auch durchreichen, dafür würde ich meine Hand nichts ins Feuer legen wollen und auch ein Secure Erase geht über USB nicht in jedem Fall, vermutlich sogar oft nicht.
Kurz gesagt: Nur weil sie im Explorer leer aussieht, muss sie nicht aus Sicht des Controllers leer sein und dies beeinflusst eben auch direkt die Schreibgeschwindigkeit, da die Größe des Pseudo-SLC Schreibcaches eben davon abhängt wie viele freie NAND Pages es gibt die der Controller erstmal mit nur einem Bit beschreiben kann, denn genau dies ist ja der Pseudo-SLC Schreibcache. Es wird ja gerne vereinfacht von SLC Cache gesprochen, oft zusammen mit DRAM Cache, was dann so klingt als wäre da ein extra SLC NAND Chip verbaut so wie es einen extra DRAM Chip bei SSDs mit DRAM Cache gibt, aber dies ist eben nicht der Fall.
Alternativ könnte es aber auch thermisches Throtteling sein. Führe bei CDM mal nur die sequentiellen Tests aus und beobachte nebenbei die Temperatur. Wenn Du dazu CDI nimmst, dann drücke öfter mal F5, da CDI per default nur alle 30 Minuten die Werte neu einliest.
