Dieser Beitrag ist eine Übersetzung des englischen Originals. Bei Abweichungen gilt das englische Original.
ArtifactNet-Forschung · Teil 5 · 2/3 · Mai 2026
Destillation und Runtime — leicht ≠ schnell
Teil 5 der ArtifactNet-Forschungsreise. Dies ist die Aufzeichnung vom Mai 2026, als wir versucht haben, die SOTA-Erkennungsgenauigkeit von der 4-Sekunden-Batch-Inferenz auf Streaming-Echtzeitverarbeitung zu übertragen. Wir haben das Modell verkleinert, und es wurde langsamer; wir haben die Runtime auf 28 Arten getauscht und sind an eine Hardware-Untergrenze gestoßen; und wir haben die teure Lektion gelernt, dass ein „Echtzeitmodell“ nicht dasselbe ist wie ein „Erkennungsmodell“. Hier ist die Ingenieursarbeit, ein auf Genauigkeit ausgelegtes Modell in Echtzeit-Vorgaben zu zwingen — Erfolge und Fehlschläge, nüchtern aufgeschrieben.
Willst du das aktuelle Modell in Aktion sehen? Schicke einen beliebigen Track durch die kostenlose Demo — dieselbe forensische Pipeline, die unten beschrieben wird, ohne Konto.
Die Erkennungs-Pipeline von ArtifactNet arbeitet grundsätzlich offline.
audio → STFT → ArtifactUNet (residual extraction) → HPSS → 7-channel forensic features
→ ResidualCNN → per-segment P(AI) → per-track median verdict
Um einen Track zu beurteilen, ziehen wir sieben 4-Sekunden-Chunks heraus und lassen sie als einen einzigen Batch laufen. Bei 0.58s pro Track reicht das völlig aus, und weil der Nutzer nur das Ergebnis will, war Latenz nie das Problem.
Das Problem kam aus der gegenläufigen Zwillingsforschung. Wenn du dieselbe Residual-Physik nutzt, um RVQ-Ghosting aus KI-Audio zu entfernen, erhältst du ein Werkzeug zur Qualitätswiederherstellung (de-artifact). Und das wollten wir als Audio-Plug-in (VST3). Ein Plug-in muss jeden 256/512-Sample-Block, den der Host ihm zuwirft, auf der Stelle verarbeiten und zurückgeben — es kann keine zukünftigen Frames sehen (kausal), und es kann nicht 4 Sekunden warten.
Mit anderen Worten: Dasselbe ArtifactUNet-Backbone musste in zwei Welten leben:
| Erkennung | de-artifact in Echtzeit | |
|---|---|---|
| Verarbeitungseinheit | Batch aus 4s-Chunks | Block-Streaming im zweistelligen Millisekundenbereich |
| Zukünftige Frames | erlaubt (bidirektional) | verboten (kausal) |
| Latenz | irrelevant | innerhalb von Hunderten ms |
| Ausgabe | P(KI) | wiederhergestellte Wellenform |
Die Arbeit im Mai bestand darin, diese Lücke technisch zu überbrücken. Und dabei wurde die Intuition, dass „ein kleineres Modell schneller ist“, dreimal widerlegt.
Das erste Design war ArtifactUNetLite: 1.85M Parameter (die Hälfte des 3.6M-Teachers), eine Multi-Rate-Architektur, die 44.1/48/96 kHz in einem einzigen Modell verarbeitet, und kausales Streaming für das Plug-in.
Mehrere Designentscheidungen wurden ausdrücklich festgelegt:
CausalChannelLayerNorm (LN pro Frame). GroupNorm/BatchNorm lassen Statistiken über die Zeitachse durchsickern und brechen die Kausalität. Ein Unit-Test erzwang „Einfluss der Zukunft auf die vergangene Ausgabe = 0“ (Δ in der Vergangenheit = 0.00).residual = m·X und clean = (1−m)·X als komplementäres Paar erzwungen werden.Alle 8 Unit-Tests bestanden — der Multi-Rate-Hop blieb bei 44.1/48/96 durchgehend bei 2.90ms, Residuum + Clean rekonstruierten den Eingang mit einem Fehler von 8.94e-08, und die Kausalität hielt.
Dann kam der Schock bei der Geschwindigkeitsmessung. Lite lief auf der CPU 2.5× langsamer als das bestehende Erkennungs-UNet — obwohl die Parameterzahl halbiert war.
Bei näherer Untersuchung war die Ursache klar:
Erste Lektion: Die Parameterzahl ist kein Ersatzmaß für die Geschwindigkeit. Echtzeit-Geschwindigkeit entsteht (a) durch weniger Frames dank eines großen Hops und (b) dadurch, dass sich die Kanäle zum Decoder hin verjüngen und die kumulative Last senken — Lite verzichtete auf beides.
Wir haben Lite nicht verworfen. Das einzelne Multi-Rate-Modell, das kausale Streaming ohne Lookahead und der kleine Gewichtsspeicher (günstig für Mobilgeräte und Speicherplatz) blieben echter Mehrwert. Wir haben aber festgehalten, dass es nie wieder als Weg zur „RT-Beschleunigung“ vorgeschlagen wird.
Als Nächstes kam die ArtifactUNetRT-Serie für echte Echtzeit-Entfernung. Statt 4-Sekunden-Chunks streamt sie kurze Frames:
| Name | T-Frames | Chunk-Länge | Einsatz |
|---|---|---|---|
| RT8 | 8 | ~93ms | niedrigste Latenz |
| RT16 | 16 | ~186ms | empfohlen für niedrige Latenz |
| RT24 | 24 | ~278ms | |
| RT48 | 48 | ~557ms | Standardmodus |
Zwei Schlüsseltechniken:
CausalCLN wird für die Inferenz durch ein Standard-LayerNorm-Muster ersetzt (numerisch identisch; Details in §6).Die RT-Serie nutzt N_FFT=1024 (117K Parameter) — eine kleine spektrale Eingabe, optimiert für niedrige Latenz. Für die VST3-Echtzeit-Entfernung war sie hervorragend.
Hier tappten wir jedoch in eine Falle. „Könnten wir dieses schnelle RT-Modell nicht auch in der Erkennungs-Pipeline verwenden?“ Wir extrahierten sein Residuum und schickten es durch das bestehende Erkennungs-CNN — und die CNN-Kompatibilität brach auf 30% ein.
Die Ursache war einfach und grundlegend. Das Erkennungs-CNN wurde auf der spektralen N_FFT=2048-Basis trainiert. Das RT-Modell verwendet N_FFT=1024, also einen völlig anderen Eingangsraum. Mit halber Frequenzauflösung im Residuum sieht das CNN eine Verteilung, der es nie begegnet ist. Zwei Modelle mit unterschiedlichen Eingangsräumen ließen sich nicht einmal direkt vergleichen.
Zweite Lektion: Eine für Echtzeit veränderte spektrale Basis ist mit nachgelagerten Modellen nicht kompatibel. N_FFT zu verkleinern, um Tempo zu gewinnen, war eine Entscheidung nur für die Entfernung, die sich nicht auf die Erkennung übertragen ließ.
Das dritte Modell wurde zur Brücke zwischen den beiden Welten. ArtifactUNetFast ist ein 534K-Modell, 6.7× kleiner als der Teacher (3.6M), das N_FFT=2048 beibehält. Mit derselben spektralen Basis lässt es sich direkt in die Erkennungs-Pipeline einsetzen und unterstützt zugleich kausales Streaming.
| Eintrag | Merkmal |
|---|---|
| Parameter | 534K (6.7× kleiner als der Teacher) |
| Architektur | CausalDSConv + CausalCLN, U-Net mit 4 Ebenen, base_channels=24 |
| Eingabe | (B, 2, 1025, T) — cat([H_mag, P_mag]), ein einzelner Forward-Pass (der Teacher braucht zwei) |
| Ausgabe | (B, 2, 1025, T) — [mask_H, mask_P] ∈ [0, 0.5]² |
| Training | Wissensdestillation vom eingefrorenen Teacher |
| Loss | 1.0 × MSE(mask) + 0.1 × spectral_convergence |
| Daten | AIME + Jamendo + Lo-Fi-Hiphop (12K Dateien, 60K Chunks, SR-Pool 44.1/48k) |
Der Kern der Destillation ist, die Maske des Teachers nachzuahmen, während die Eingabe in 2 Kanäle gebündelt wird, sodass H/P in einem einzigen Forward-Pass verarbeitet werden (der Teacher lässt H und P zweimal laufen). Nach der Konvergenz bei einem besten Loss von 0.06645 haben wir an 10 Tracks mit dem Teacher verglichen:
| Kennzahl | Wert |
|---|---|
| Masken-Pearson | H=0.84, P=0.86 (starke Korrelation) |
| Masken-MAE | H=0.080, P=0.073 |
| Maskenverteilung | Student 0.28 vs. Teacher 0.31 |
| Spektrale Konvergenz | 0.38 (Residuum-Charakter erhalten) |
Die Maske ist etwas gröber als die des Teachers, aber Verteilung und Charakter sind erhalten — die Residuen-Extraktion funktioniert korrekt.
Das Hauptergebnis war die Geschwindigkeit. Auf PyTorch liegt das Modell auf dem Niveau des Teachers, doch mit dem Wechsel zu ONNX Runtime ändert sich alles:
| Modell | ORT-CPU, 4 Threads, p50 | RTF | Gesamtlatenz |
|---|---|---|---|
| Teacher (PyTorch, 2× Forward-Pass) | ~998ms | 0.25 | ~4s |
| Fast (PyTorch, 1× Forward-Pass) | ~1066ms | 0.27 | ~4s |
| Fast ORT T=16 | 18.5ms | 0.10 | 204ms ✅ |
| Fast ORT T=24 | 27.8ms | 0.10 | 306ms |
50× Beschleunigung auf ORT gegenüber PyTorch. Bei T16 ergeben Chunk (186ms) und Inferenz (18.5ms) zusammen 204ms Gesamtlatenz — innerhalb des Budgets für Echtzeit-Plug-ins.
Wir haben drei Artefaktformen exportiert — rohes ONNX (für die ORT-Runtime), eine Version mit CausalCLN-Umbau (nur Rust/tract, Custom-Op) und eine mit onnxsim optimierte Version. Beachte: Die Umbau-Version scheitert auf ORT beim Erstellen der Session (Custom-Op nicht unterstützt), sie läuft also nur mit Rust/tract. Diese Weggabelung führt in den Runtime-Krieg des nächsten Abschnitts.
Nachdem das Modell feststand, lautete die Frage auf welcher Runtime es laufen sollte. Um die Latenz der Echtzeit-Entfernung von de-artifact (RT48 Stereo) zu senken, haben wir fast jede Inferenz-Engine und jede Einstellung ausgereizt.
| Stufe | RTF (Stereo) |
|---|---|
| tract sequenziell (Start) | 0.416 |
| tract parallel L‖R | 0.218 |
| Umstieg auf ORT FP32 4‖4 | 0.031 |
| ORT-Konfigurations-Tuning | 0.029 |
| CausalCLN→LayerNorm-ONNX-Umbau | 0.023 |
| theoretisches Minimum (Custom-Op nötig) | ~0.018 |
Allein der Wechsel von tract zu ONNX Runtime verbesserte den RTF von 0.416 auf 0.031 — ein 18×-Gewinn (sequenzielle Ausführung von tract gegenüber der MLAS-Optimierung von ORT plus L/R-Session-Parallelität). Der Umbau brachte ihn auf 0.023. Die absolute CPU-Untergrenze (Ryzen 5800X, AVX2 FP32) lag bei Stereo 11.9ms, RTF 0.022.
| Einstellung | Latenz (p50) | RTF | vs. CPU |
|---|---|---|---|
| CPU Stereo 4‖4T | 12.2ms | 0.0223 | 1× |
| CUDA sequenziell L→R | 3.9ms | 0.0072 | 3.1× |
| CUDA Graph FP16 | 2.52ms | 0.0046 | 4.8× |
| TRT FP16 sequenziell | 1.71ms | 0.0031 | 7.1× |
| TRT FP16 batch=2 | 1.44ms | 0.0026 | 8.5× |
Die finale Untergrenze der GPU (RTX 3060) war TensorRT FP16 mit batch=2 bei 1.44ms (RTF 0.0026). Stereo L+R in die Batch-Dimension eines einzigen Forward-Passes zu bündeln, war immer schneller als Multi-Stream (die Batch-Fusion von TRT verteilt die SM-Ressourcen optimal). LayerNorm auf FP16 zu erzwingen (den FP32-Fallback zu deaktivieren) brachte weitere 5%.
Wege, die schnell aussahen, aber scheiterten oder sich verschlechterten:
Nachdem wir alle 28 SessionBuilder-Optionen von ORT ausgeschöpft hatten, kamen wir zu dem Schluss, dass 11.5–12.3ms das absolute Minimum für diese Hardware ist. Um weiter zu senken, bräuchte es ein erneutes Training (Verkleinerung) oder neue Hardware. Das ist keine Niederlage, sondern eine abgesteckte Grenze — wer weiß, was möglich ist, kann entscheiden, worauf er oberhalb davon verzichtet.
Ein Hinweis zum CausalCLN→LayerNorm-Umbau, der auf der gesamten Runtime-Stufenleiter wiederkehrte. Es war die kleinste und zugleich sauberste Optimierung.
Das beim Training verwendete CausalChannelLayerNorm ist ein Custom-Op, der Statistiken über (C,F) pro Frame berechnet. Er garantiert Kausalität, lässt sich im Inferenzgraphen aber nicht sauber auf Standard-ONNX-Ops abbilden. Also haben wir den Graphen umgebaut und ihn durch ein numerisch äquivalentes Standard-LayerNorm-plus-Transpose-Muster ersetzt.
Entscheidend ist, dass die Ausgabe Bit für Bit identisch bleibt und nur die Runtime schneller wird — weil ORT das Standard-LayerNorm-Muster als fusionierten Kernel erkennt. Erneut validiert auf ORT 1.24.x, ergab der Umbau einen gemessenen Gewinn von +3.69ms; im Profil nahm LayerNorm 20.1% der Gesamtzeit ein und das durch den Umbau entstandene Transpose 16.8% — dennoch war es ein Nettogewinn.
Ein interessantes Gegenbeispiel: Dieselbe LayerNorm direkt als Rust-Custom-Op zu implementieren, verschlechterte Mono tatsächlich um 1.3ms. Für die kleine T=48-Schleife schlug die fusionierte MLAS-Implementierung von ORT das Rust mit Schleifen-Transposition. „Ein handgeschriebener Kernel ist immer schneller“ war ebenfalls eine falsche Intuition.
Während sich die Echtzeit-Entfernung in RT/Fast verzweigte, haben wir auch geprüft, ob die Erkennungs-Pipeline selbst auf ORT umziehen kann. Die Antwort war, den Teacher direkt nach ONNX zu exportieren.
| Eintrag | Ergebnis |
|---|---|
| ORT, 4 Threads, Mono | 275.8ms (Ziel <500ms erreicht) |
| Übereinstimmung des CNN-Urteils | 100% (9/9) |
| Numerischer Fehler | max. 2.56e-06 |
| Parameter | 3.6M |
| ONNX-Knoten | 76 (einfache UNet-Struktur) |
Die Beibehaltung von N_FFT=2048 ergab 100% Übereinstimmung des Urteils mit dem Erkennungs-CNN (numerischer Fehler 2.56e-06). Das ist der entscheidende Unterschied zum RT-Modell:
| Modell | ORT-Geschwindigkeit | CNN-Kompatibilität | Einsatz |
|---|---|---|---|
| RT (N_FFT=1024, 117K) | 12.3ms Stereo | 30% | nur VST3 |
| Teacher (N_FFT=2048, 3.6M) | 275.8ms Mono | 100% | Erkennungs-Pipeline |
Für die Erkennung ist die Antwort der große Teacher und nicht das kleine RT-Modell — Kriterium war die Kompatibilität, nicht die Geschwindigkeit.
Dies ist das Herzstück des Artikels. Den ganzen Mai über bestand die hartnäckige Versuchung, die schnellen Modelle direkt in der Erkennungs-Pipeline zu verwenden. Es scheiterte dreimal, jedes Mal aus einem anderen Grund.
(1) ArtifactUNetRT — Fehlanpassung der spektralen Basis. N_FFT=1024, daher lag die CNN-Kompatibilität bei 30%. (§3)
(2) ArtifactUNetLite — Parameter-Inversion. 1.85M, aber auf der CPU 2.5× langsamer als das Erkennungs-UNet. (§2)
(3) ArtifactUNetFast — eine Falle in zwei Schichten.
Fast behält N_FFT=2048, hat also nichts von RTs Kompatibilitätsproblem. Das warf die naheliegende Frage auf: „Was, wenn wir das Erkennungs-CNN auf Fast neu trainieren?“ Ein Vergleich der Residuen offenbarte zwei Dinge:
| UNet-Pfad | TPR (KI) | FPR (echt) |
|---|---|---|
| codec4 (aktuelle Produktion) | 98.0% | 0.0% |
| phase2 (Teacher von Fast) | 100.0% | 55.0% |
| Fast (Drop-in) | 98.0% | 52.5% |
Die richtige Reihenfolge war klar — um mit Fast zu erkennen, musst du zuerst von einem Codec-bewussten Teacher (codec4) neu destillieren und dann das CNN daraufsetzen. Und wenn Echtzeit-Streaming nicht das Ziel ist, braucht die Erkennung keine kausale Einschränkung; ein bidirektionaler, leichtgewichtiger Student gewinnt dann bei Genauigkeit und Effizienz.
Dritte und größte Lektion: Echtzeit-Vorgaben (kausal, kurzer Hop, kleines N_FFT, 2-Kanal-Fusion) kollidieren frontal mit Erkennungsgenauigkeit und -geschwindigkeit. Der Anspruch, ein Backbone für zwei Welten zu nutzen, forderte jedes Mal einen anderen Preis. Die Schlussfolgerung war, die Rollen zu trennen: Die Entfernung nutzt Fast/RT, die Erkennung nutzt Teacher/codec4.
Zwei Prüfungen rundeten den Monat ab.
Test auf adversariale Umgehung. Der Zweck von de-artifact ist die Verbesserung der Audioqualität, nicht das Umgehen der Erkennung. Dennoch haben wir als Sorgfaltsprüfung selbst getestet, ob sich unser Unterdrückungswerkzeug zur Umgehung missbrauchen ließe — wir schickten das Original und die Ausgaben bei den Unterdrückungsstärken α=0.5/1/2/4 durch die Erkennungs-Pipeline und maßen die Änderung von P(KI). (Die Robustheit der Erkennung wird in einem späteren Teil behandelt.)
Leichtgewichtiger SOTA-Vergleich. Etwa zur selben Zeit haben wir uns an einer kleinen Teilmenge (SONICS Fake 150 + Real 150) mit einer externen Baseline gemessen (einem MERT-basierten 2-Stufen-Modell, 174M Parameter). ArtifactNet mit 4.2M Parametern lag vorn mit TPR 100%, FPR 10.7%, F1 0.949, schlug damit das 174M-Modell (F1 0.929) und war mit 0.58s/Track gegenüber 2.62s/Track 4.5× schneller. Angesichts der Größe der Teilmenge zählen nicht die absoluten Zahlen, sondern der Vorsprung trotz 40× Parameterabstand — eine erneute Bestätigung der Prämisse dieser Serie, dass ein kleines Modell der Ausgangspunkt für Echtzeit ist.
Parameterzahl ist nicht Geschwindigkeit. Zwei Inversionen — Lite (2.5×) und Fast (3.44×) — wiesen auf dieselbe Wahrheit: Echtzeit-Geschwindigkeit hängt von Hop-Größe, Kanalverjüngung, Größe des Aktivierungstensors und Anzahl der Kernel-Starts ab. Bevor du ein Modell verkleinerst, profiliere, was tatsächlich langsam ist.
Echtzeit-Optimierung bricht die Kompatibilität mit nachgelagerten Modellen. Die Verkleinerung von N_FFT (RT) sowie Kausalität und 2-Kanal-Fusion (Fast) kollidierten alle mit dem nachgelagerten Erkennungs-CNN. Um ein Backbone für mehrere Zwecke wiederzuverwenden, musst du zuerst entscheiden, welche Achsen geteilt und welche getrennt geführt werden. Wir haben die spektrale Basis (N_FFT=2048) geteilt und Kausalität und Kanalfusion getrennt geführt.
Das Ausreizen der Runtimes ist keine Niederlage, sondern Grenzziehung. Der Weg tract→ORT→TVM→OpenVINO→TensorRT, um die Hardware-Untergrenze festzunageln (CPU 11.9ms, GPU 1.44ms), erlaubte es uns, oberhalb dieser Untergrenze vernünftig zu entscheiden, worauf wir verzichten und was wir neu trainieren.
Im nächsten Teil nehmen wir dieses verfeinerte SOTA mit nach draußen, um seine verbleibenden Schwächen anzugreifen — und zweifeln am Ende stattdessen an unserer eigenen Bewertungsmethodik.
ArtifactNet-Forschungsteam · Mai 2026
Lade eine beliebige Datei hoch — dieselbe forensische Pipeline, die in dieser Serie beschrieben wird.