NZB Fast im Test und Benchmark gegen SABnzbd und NZBGet

Letzte Aktualisierung: 11.11.2026

NZB Fast ist ein neuer Usenet-Downloader mit einem markanten Versprechen: Archive werden bereits während des Downloads entpackt, wodurch Wartezeit und Speicherbedarf sinken sollen. Wir haben das auf einem Heim-NAS gegen SABnzbd und NZBGet getestet, zwei weitverbreitete Downloader.

Was NZB Fast macht

Wer Usenet nutzt, kennt den Ablauf. Eine NZB-Datei teilt dem Downloader mit, welche Artikel er abrufen soll. Er lädt sie, repariert Schäden mit PAR2-Dateien und entpackt RAR-, 7z- oder ZIP-Archive zu den fertigen Dateien.

Auch SABnzbd und NZBGet unterstützen vorzeitiges Entpacken über Direct Unpack. Download und Entpacken können sich überlappen; wenn Archive neben den fertigen Dateien erhalten bleiben, können dennoch zwei Nachteile entstehen:

• Etwa die doppelte Größe der Veröffentlichung wird als freier Speicher benötigt, weil Archive und entpackte Dateien gleichzeitig vorhanden sind.
• Reparaturen oder verbleibende Entpackarbeiten können den Abschluss über den eigentlichen Download hinaus verzögern.

NZB Fast entpackt jedes Archivvolume bei dessen Eintreffen. Das Projekt nennt dies One-Pass-Downloading. Theoretisch ist der Auftrag mit dem Download abgeschlossen, und es wird etwa das 1-Fache der Veröffentlichungsgröße an freiem Speicher benötigt.

Zusätzlich integriert es Funktionen, die ältere Werkzeuge anderen Programmen überlassen: Indexer-Suche, Beobachtungsliste, Medienbrowser und Vorschau. Seine API bildet SABnzbd oder NZBGet nach, sodass Sonarr und Radarr es als Download-Client nutzen können. Server lassen sich aus einer bestehenden SABnzbd-Konfiguration importieren.

Unser Testaufbau

Wir wollten einen wiederholbaren Test mit eindeutig legalen Inhalten.

• Die Veröffentlichung: Wir luden das offizielle Debian-13.7.0-DVD-1-ISO (3,99 GB), prüften seine SHA-512-Prüfsumme, teilten es in RAR-Volumes von 100 MB und ergänzten einen PAR2-Reparatursatz mit 10 % Wiederherstellungsdaten. Anschließend veröffentlichten wir es selbst in alt.binaries.test. Bei der Prüfung auf dem Download-Server waren alle 6.162 Artikel vorhanden.
• Die Hardware: Ein Ugreen-NAS mit vier CPU-Kernen und 7,5 GB RAM unter Docker. Jeder Downloader lief einzeln in einem eigenen Container mit einem leeren Download-Ordner.
• Der Server: Für jede Anwendung derselbe einzelne Newshosting-US-Server mit 20 Verbindungen. Andere Container liefen weiter; das NAS war nicht unbelastet.
• Die Durchläufe: Drei pro Konfiguration, wobei die Reihenfolge in jeder Runde wechselte. Gemessen wurde von der NZB-Übergabe bis zur Fertigmeldung der Anwendung. Danach verglichen wir das entpackte ISO mit Debians veröffentlichter Prüfsumme.
• Die Einstellungen: Die Standardeinstellungen der Anwendungen sowie aktiviertes Direct Unpack für SABnzbd und NZBGet. Direct Unpack ist deren eigene Funktion zum frühen Entpacken.

Die Haupttests liefen am 10. November 2026 nach pazifischer Zeit; sie begannen am 11. November um 03:33 UTC. Dies sind unsere NAS-Messungen, nicht die veröffentlichten Benchmarks des Entwicklers.

Getestete Versionen: NZB Fast 1.10.0, SABnzbd 5.1.3 und NZBGet 26.3. Wir ermittelten sie aus den aufbewahrten Benchmark-Containern: Das unveränderliche NZB-Fast-Image trägt die Versionsangabe 1.10.0; historische Startprotokolle nennen die SABnzbd- und NZBGet-Versionen. Alle drei Container entstanden vor den Haupttests. Die ursprünglichen Ergebnisdateien enthielten keine Versionsangaben. Daher prüften wir die aufbewahrten Container, statt das heutige latest-Tag mit der getesteten Version gleichzusetzen. Die Veröffentlichung von NZB Fast v1.10.0 ist auf den 10. November datiert.

Ergebnisse

Geschwindigkeit

Das Diagramm zeigt den Median der drei Durchläufe als Balken und jeden einzelnen Durchlauf als Punkt, damit die Streuung erkennbar bleibt.

Dieselben Werte als Tabelle, ergänzt um den maximalen Speicherbedarf. Angegeben ist der höchste Bedarf eines Durchlaufs anhand belegter Speicherblöcke.

Alle 15 Haupttest-Durchläufe waren erfolgreich und erzeugten ein ISO mit passender SHA-512-Prüfsumme. „Geschwindigkeit bis zur fertigen Datei“ bedeutet Nutzdatengröße geteilt durch die gesamte Bearbeitungszeit, nicht eine gesonderte Messung des Netzwerkdurchsatzes.

Auffällige Ergebnisse:

• NZB Fast war in jeder Runde am schnellsten. Es war etwa 16 % schneller als SABnzbd und fast doppelt so schnell wie NZBGet mit Standardeinstellungen. Seine drei Zeiten lagen zwischen 100 und 111 Sekunden.
• Die Speicherplatzaussage bestätigte sich. NZB Fast erreichte ungefähr 3,7 GiB für eine Veröffentlichung von 3,7 GiB. Alle anderen Konfigurationen lagen bei etwa 7,4 GiB.
• Direct Unpack brachte keinen automatischen Vorteil. In dieser Testserie half es NZBGet, während SABnzbd länger brauchte. Drei Durchläufe reichen nicht aus, um allgemein auf eine Verlangsamung von SABnzbd durch Direct Unpack zu schließen.
• Die Zeiten schwankten. SABnzbd mit Direct Unpack benötigte zwischen 130 und 190 Sekunden. Unterschiede von 10–20 % zwischen ähnlich schnellen Programmen sollten vorsichtig bewertet werden.

Speicherplatz

Hier zeigt sich die Konstruktion von NZB Fast. Bei dieser Arbeitslast erreichten SABnzbd und NZBGet etwa die doppelte Veröffentlichungsgröße, auch mit Direct Unpack. Gemessen wurde der belegte Platz in den Download-Ordnern, nicht der gesamte Container- oder Systemspeicher.

Der zeitliche Verlauf erklärt den Unterschied. Die älteren Downloader steigen allmählich auf etwa 7,4 GiB und fallen nach dem Löschen der Archive wieder auf 3,7 GiB. NZB Fast reserviert in den ersten Sekunden Platz für die fertige Datei und blieb beim Test der unbeschädigten Veröffentlichung nahe diesem Wert.

Zwei weitere Tests

Die ersten Ergebnisse stammen von einer unbeschädigten Veröffentlichung mit 20 Verbindungen. Wir testeten zusätzlich eine beschädigte Veröffentlichung und 40 Verbindungen, jeweils zweimal pro Anwendung und Zusatzszenario. Die Testserien liefen getrennt bei unterschiedlicher Hintergrundlast. Vergleichen Sie die Programme innerhalb eines Szenarios; Änderungen zwischen Serien belegen nicht allein den Nutzen einer Einstellung.

Eine beschädigte Veröffentlichung

Usenet-Artikel können fehlen. Wir entfernten 92 Artikel, entsprechend 1,5 % der RAR-Daten, aus der NZB. Jede Anwendung musste deshalb vor dem Entpacken mit dem PAR2-Satz reparieren. Wir führten je Anwendung zwei Durchläufe aus.

Jede Anwendung reparierte das ISO bytegenau, doch die Dauer unterschied sich deutlich. NZB Fast benötigte 226 Sekunden, etwa ein Viertel weniger als SABnzbd mit 305 Sekunden. NZBGet benötigte 641 Sekunden, fast dreimal so lange wie NZB Fast. Dessen maximaler Speicherbedarf stieg nur leicht auf 4,0 GiB.

Mehr Verbindungen

Unsere 20 Verbindungen lagen unter dem von Newshosting erlaubten Wert. Die Verbindungsermittlung von NZB Fast empfahl mehr Verbindungen; daher testeten wir alle Anwendungen nochmals mit 40.

Die Werte sind Mediane von zwei Durchläufen je Anwendung. NZB Fast und NZBGet waren in der Serie mit 40 Verbindungen schneller; SABnzbd nicht. Da die Serien zu verschiedenen Zeiten auf einem beschäftigten NAS liefen, ist nicht belegt, dass allein die Verbindungszahl die Unterschiede verursachte. Testen Sie Einstellungen an Ihrem eigenen Anschluss, statt grundsätzlich einen Vorteil durch mehr Verbindungen anzunehmen.

Lohnt sich der Einsatz?

Für einen Download-Rechner mit wenig Speicher möglicherweise schon. Der doppelte Platzbedarf ist bei kleinen SSDs oder fast vollen NAS-Systemen ein echtes Problem; NZB Fast vermied diesen Zusatzbedarf im Test mit unbeschädigten Daten.

Wenn SABnzbd bereits gut funktioniert, ist der Geschwindigkeitsvorteil beim fehlerfreien Download allein eher gering. 20 Sekunden bei 4 GB verändern den Alltag kaum; Anschluss und Anbieter sind wichtiger als der Client. Bei beschädigten Daten wuchs der Abstand: NZB Fast war etwa ein Viertel schneller als SABnzbd. Das ist vielversprechend, aber unsere absichtlich beschädigte Veröffentlichung bildet nicht jedes Reparaturproblem ab.

Worauf Sie achten sollten

• Unsignierte Anwendungen. Die macOS- und Windows-Versionen sind weder notarisiert noch codesigniert; Sicherheitswarnungen beim ersten Start sind zu erwarten. Docker vermeidet das.
• Unbekannter Maintainer. Wir konnten nicht feststellen, wer das Projekt betreibt. Das ist bei Software wichtig, die Anbieter-Zugangsdaten speichert.
• Junge Software. SABnzbd und NZBGet werden seit vielen Jahren gepflegt. NZB Fast ist wesentlich neuer und hat eine kleinere Gemeinschaft.
• Duplikatschutz. NZB Fast hielt eine zweite Kopie derselben Veröffentlichung als „Alternative“ zurück, bis wir die Warteschlange leerten. NZBGet übersprang ebenfalls eine als Duplikat erkannte NZB. Das ist sinnvoller Schutz, kann beim absichtlichen erneuten Download aber überraschen.
• Nicht immer ein Durchlauf. Selbstentpackende Archive, mehrteilige ZIPs und fortgesetzte Aufträge fallen auf den langsameren Weg mit zwei Kopien zurück.

Ausprobieren

1. Starten Sie das Docker-Image nzbfast/nzbfast. Das Dashboard verwendet Port 6789.
2. Tragen Sie den Usenet-Server im Dashboard ein oder importieren Sie Server aus SABnzbd. Beachten Sie die vom Anbieter erlaubte Verbindungszahl.
3. Übergeben Sie eine NZB oder verbinden Sie Sonarr und Radarr über den API-Schlüssel.
4. Halten Sie das Dashboard ausschließlich im Heimnetz erreichbar.

Unser Fazit

NZB Fast erfüllte in unserem Test seine wichtigsten Versprechen: Es war am schnellsten und benötigte halb so viel Speicherplatz. Wegen der Sicherheitsgrundlagen und des unbekannten Maintainers würden wir es zunächst lokal ausprobieren und uns noch nicht darauf verlassen. Weitere Veröffentlichungen, bei jedem Durchlauf erfasste Image-Digests und ein ansonsten unbelastetes NAS würden einen aussagekräftigeren Folgetest ermöglichen.

Einzelheiten zu Funktionen, Einrichtung und Sicherheit finden Sie im NZB-Fast-Projekt. Für eine bewährte Lösung lesen Sie unseren SABnzbd-Testbericht.