So wählst du 2026 einen dedizierten Streaming-Server aus

Was solltest du bei einem Streaming-Server als Erstes dimensionieren?

Port-Geschwindigkeit. Alles andere ist verhandelbar.

Ein Streaming-Server führt drei Jobs mit völlig unterschiedlichen Ressourcenprofilen aus. „Ingest“ nimmt den kodierten Feed von deiner Sende-Software entgegen und kostet fast nichts. „Transcoding“ wandelt diesen Feed in verschiedene Qualitätsstufen um und beansprucht CPU-Leistung. „Delivery“ überträgt Segmente an die Zuschauer und beansprucht Netzwerkkapazität – und genau hier springen die Budgets meist als Erstes die Lücke.

Eine langsame CPU kannst du ausgleichen, indem du weniger Wiedergabevarianten kodieren lässt. Kleine Festplatten kannst du durch die Archivierung in einem Objektspeicher ausgleichen. Einen ausgelasteten Netzwerkport kannst du nicht ausgleichen. Sobald der Port voll ist, puffern alle Zuschauer gleichzeitig, und die einzige Lösung ist ein Hardware- oder Tarifwechsel.

Diese Reihenfolge bestimmt den weiteren Verlauf dieses Leitfadens: zuerst das Netzwerk, dann die CPU, dann der Arbeitsspeicher und zuletzt der Speicherplatz.

Wie berechnet man die Bandbreite für gleichzeitige Zuschauer?

Multipliziere die Anzahl der gleichzeitigen Zuschauer mit ihrer durchschnittlichen übertragenen Bitrate und rechne dann den Overhead hinzu. Ein 1080p-Stream mit 5 Mbit/s und ein 720p-Stream mit 3 Mbit/s sind realistische Planungswerte für die adaptive Übertragung, bei der die meisten Zuschauer im mittleren Bereich liegen.

Gleichzeitige Zuschauer	Durchschnittlicher Stream mit 5 Mbit/s	Realistischer Hafen gesucht
250	1,25 Gbit/s	3 Gbit/s
500	2,5 Gbit/s	3 Gbit/s
1,000	5 Gbit/s	8 bis 10 Gbit/s
2,500	12,5 Gbit/s	CDN erforderlich
10,000	50 Gbit/s	CDN erforderlich

Zwei Faktoren sorgen dafür, dass das realistisch bleibt. Die Portgeschwindigkeit ist die Nennkapazität der Verbindung, nicht der Durchsatz, den du tatsächlich messen wirst. Protokoll-Overhead, Wiederholungsübertragungen und Netzwerkbedingungen schmälern diese Zahl – rechne also mit etwa 60 bis 70 % des Nennwerts für eine dauerhafte Übertragung. Zweitens ist die gleichzeitige Nutzerzahl nicht gleichbedeutend mit der Zuschauerzahl. Ein Stream mit 4.000 Registrierungen und einer Live-Teilnahmequote von 35 % erreicht in der Spitze etwa 1.400 Zuschauer, nicht 4.000.

Die High-Capacity-Server von InMotion werden mit einem 3-Gbit/s-Basisport und unbegrenztem Datenvolumen ausgeliefert. Zusätzliche Kapazität ist in 1-Gbit/s-Schritten für 60 $ pro Monat bis zu 10 Gbit/s erhältlich. Der CC-4000 bietet die vollen 10 Gbit/s ohne Aufpreis. Unbegrenztes Datenvolumen ist hier genauso wichtig wie die Port-Geschwindigkeit, da bei Tarifen mit Datenlimit ein erfolgreicher Stream zu einer Rechnung für Datenüberschreitung führt.

Wie viel CPU-Leistung brauchst du für Live-Transcoding?

Plane nach Wiedergabe, nicht nach Stream.

Software-Kodierung mit x264 bei der veryfast Die Voreinstellung beansprucht je nach Komplexität der Szene etwa 2 bis 4 Kerne pro 1080p30-Rendering. Eine dreistufige Leiter (1080p, 720p, 480p), die aus einer einzigen 1080p-Quelle generiert wird, benötigt in der Regel zwischen 6 und 10 Kerne, wenn man den Aufwand für die Einlesung und die Verpackung mit einrechnet. Bei zwei gleichzeitigen Kanälen verdoppelt sich dieser Wert in etwa.

Die Wahl der Voreinstellung hat einen größeren Einfluss auf die Zahlen als die Hardware. Der H.264-Kodierungsleitfaden von FFmpeg erklärt den Kompromiss: Langsamere Voreinstellungen bieten eine höhere Kompressionseffizienz, erfordern aber einen hohen CPU-Aufwand – was für die Kodierung auf Abruf in Ordnung ist, für Live-Übertragungen aber unbrauchbar ist. Bei der Live-Transkodierung gibt es eine strenge Frist. Wenn die Kodierung hinter der Echtzeit zurückfällt, gehen Bilder verloren, und keine noch so hohe zusätzliche CPU-Leistung kann die Aufnahme später wiederherstellen.

Drei Möglichkeiten, die CPU-Kosten zu senken, bevor du neue CPUs kaufst:

• Lass die oberste Stufe aus. Leite das 1080p-Quellsignal unverändert weiter und transkodiere nur die unteren Stufen. Allein dadurch wird die aufwendigste Wiedergabe aus dem Arbeitsaufwand entfernt.
• Kürze die Liste ein bisschen. Vier Punkte sind üblich. Drei reichen normalerweise für ein Geschäftspublikum aus, das über Breitband-Internet und Desktop-Geräte zugreift.
• Kodiere Talking-Head-Inhalte mit 30 fps statt mit 60 fps. Sport, Gameplay und bewegungsreiche Aufnahmen benötigen die höhere Bildrate. Webinare und Produktdemos hingegen nicht.

InMotion bietet keine GPU-Server an, daher ist hardwarebeschleunigte Codierung nicht Teil dieses Stacks. Die Software-Codierung auf modernen Prozessorkernen bewältigt Ein-Kanal- und kleine Mehrkanal-Aufträge problemlos; sehr große Codierungsreihen über viele gleichzeitige Kanäle hinweg gehören in eine dedizierte Codierungsstufe oder zu einem externen Transcodierungsdienst.

Wie viel RAM verbraucht ein Streaming-Server eigentlich?

Weniger, als die meisten Käufer für einen einzelnen Kanal erwarten, und viel mehr, sobald du mehrere betreibst.

Der Streaming-Stack selbst ist recht überschaubar. NGINX dem RTMP-Modul, ein FFmpeg-Prozess pro Wiedergabe und das Betriebssystem benötigen für einen Kanal selten mehr als 8 bis 16 GB. Das überrascht viele Erstkäufer, die davon ausgehen, dass Videos genauso speicherintensiv sind wie Datenbanken.

RAM spielt eine Rolle, wenn der Server als Ursprungsserver fungiert. Segmente, die aus dem Seitencache bereitgestellt werden, gelangen nie auf die Festplatte, wodurch die Latenz unter Last konstant bleibt. Eine einzelne Wiedergabe mit 5 Mbit/s und einem 60-Sekunden-DVR-Fenster belegt etwa 37 MB im Cache. Multipliziere das mit einer vierstufigen Leiter und zwanzig Kanälen, und du cachst kontinuierlich mehrere Gigabyte an Live-Segmenten – zusätzlich zu den Kodierungsprozessen.

Die 64-GB-Konfigurationen der Managed Dedicated Server von InMotion bieten genügend Spielraum für einen Multi-Channel-Origin, ohne dass Segment-Lesevorgänge wieder auf die Festplatte ausgelagert werden müssen.

Welche Speicherkonfiguration eignet sich für eine Video-Bereitstellungsinfrastruktur?

NVMe aktive Segmente, kostengünstigere Speicherkapazität oder Objektspeicher für das Archiv.

Live-Segmente sind kleine Dateien, die ständig geschrieben und wieder gelöscht werden. Dieses Schreibmuster kommt NVMe zugute NVMe sich rotierende Festplatten NVMe schlecht schlagen. Aufnahmen sind ein anderes Problem: Sie werden immer größer.

Die Berechnungen sind vorhersehbar. Eine 1080p-Aufnahme mit 6 Mbit/s verbraucht etwa 2,7 GB pro Stunde. Bei 12 Mbit/s sind es fast 5,4 GB pro Stunde.

• Acht Stunden pro Tag bei 6 Mbit/s: etwa 22 GB täglich oder 650 GB pro Monat
• Zwei 1, NVMe RAID-1- NVMe bieten eine nutzbare Kapazität von fast 1,92 TB, sodass das Array nach diesem Zeitplan in etwa drei Monaten voll ist
• RAID-1 sorgt durch Spiegelung für Redundanz, daher verdoppelt ein Array mit zwei Festplatten den nutzbaren Speicherplatz nicht

Plane den Archivierungspfad vor dem ersten Stream und nicht erst nach der Festplattenwarnung. Premier Care umfasst 500 GB Backup-Speicherplatz auf Dedicated Servern und 2 TB auf High Capacity Servern, was für eine Kopie wichtiger Aufzeichnungen außerhalb des Servers ausreicht. Für Langzeitarchive solltest du abgeschlossene Aufzeichnungen nach einem Zeitplan in einen S3-kompatiblen Objektspeicher synchronisieren und die lokale Festplatte für den Arbeitsspeicher nutzen.

In welchem Format solltest du deine Arbeit einreichen?

Latenz und Skalierbarkeit ziehen in entgegengesetzte Richtungen, und die richtige Antwort hängt davon ab, was deine Zielgruppe tatsächlich braucht.

Protokoll	Typische Latenz	Skalierbar bis	Am besten für
Standard-HLS	15 bis 30 Sekunden	Sehr viele Zuschauer über CDN	Webinare, VOD, lineare Kanäle
HLS mit geringer Latenz	2 bis 5 Sekunden	Große Zuschauerzahlen über CDN	Live-Veranstaltungen, Sport, Produkteinführungen
WebRTC	Weniger als 1 Sekunde	Hunderte pro Server	Auktionen, Telemedizin, wechselseitige Interaktion

Apples Dokumentation zu HTTP Live Streaming behandelt die HLS-Erweiterung „Low-Latency HLS“, die Teilsegmente nutzt, um die Verzögerung zu verringern, und dabei das HTTP-Übertragungsmodell beibehält, das das Caching über ein CDN ermöglicht. Genau diese Caching-Eigenschaft ist der Grund dafür, dass HLS so kostengünstig skalierbar ist: Ein Segment ist eine statische Datei, sodass ein einziger Server ein CDN versorgen kann, das wiederum alle anderen Nutzer versorgt.

WebRTC unterhält pro Zuschauer eine zustandsbehaftete Verbindung. Dadurch steigen die Serverkosten pro Zuschauer stark an, weshalb interaktive Plattformen in der Regel WebRTC für die wenigen Teilnehmer nutzen, die sprechen, und HLS für das Publikum, das zuschaut.

Wann sollte ein CDN die Bereitstellung übernehmen statt deines Servers?

Sobald das kontinuierliche Versandvolumen etwa die Hälfte deiner nutzbaren Portkapazität erreicht oder sobald deine Zielgruppe sich über mehr als einen Kontinent erstreckt.

Die Zahlen sprechen für sich. Ohne CDN ziehen 2.000 gleichzeitige Zuschauer mit 5 Mbit/s 10 Gbit/s direkt von deinem Server. Mit einem CDN als Vorstufe liefert der Ursprungsserver jedes Segment nur einmal an jeden Edge-Standort und verzeichnet statt 2.000 nur noch ein paar Dutzend Verbindungen. Die Auslastung deines Servers steigt nicht mehr mit der Zuschauerzahl.

Auch bei geringeren Zuschauerzahlen zwingt die geografische Lage zu derselben Entscheidung. Ein Zuschauer in Sydney, der Segmente aus Virginia abruft, muss auf jeden Hin- und Rückweg warten. InMotion betreibt Rechenzentren in Virginia, Kalifornien und Amsterdam, was den ersten Hop für Zuschauer in Nordamerika und Europa erheblich verkürzt, aber ein globales Publikum benötigt dennoch Edge-Caching.

Konfiguriere die Quelle richtig, bevor du ein CDN darauf verweist. Segmentdateien sollten lange Cache-Laufzeiten haben, da sie sich nach dem Schreiben nie mehr ändern. Playlist-Manifeste sollten dagegen sehr kurze Laufzeiten haben, da sie sich alle paar Sekunden ändern. Wenn du das verwechselst, führt das entweder zu veralteten Streams oder zu einem CDN, das gar nichts zwischenspeichert.

Verändern On-Demand-Videos die Anforderungen?

Im Wesentlichen. VOD hebt die Echtzeit-Frist auf, die die Entscheidungen bezüglich der Streaming-Server-Hardware bestimmt.

Beim Kodieren einer Bibliothek über Nacht kannst du langsame, effiziente Voreinstellungen nutzen, die bei gleicher Bildqualität kleinere Dateien erzeugen. Kleinere Dateien bedeuten weniger Bandbreite bei jeder zukünftigen Wiedergabe, sodass sich der einmalige CPU-Aufwand kontinuierlich auszahlt. Beim Live-Kodieren gibt es diese Möglichkeit nicht.

Was VOD dagegen bietet, ist Speicherplatz. Eine Bibliothek mit 500 Stunden bei 1080p über drei Stufen hinweg nimmt mehrere Terabyte ein, und Bibliotheken werden immer größer. Wenn dein Arbeitsaufkommen hauptsächlich aus On-Demand-Inhalten besteht, solltest du dein Budget eher auf Kapazität und CDN-Entlastung als auf Rechenkerne ausrichten.

Welcher InMotion-Server eignet sich für deine Streaming-Anforderungen?

Arbeitsbelastung	Profil	Empfohlener Plan
Ein Kanal, weniger als 500 gleichzeitige Zuschauer, CDN davor	3-Sprossen-Leiter, gelegentliche Aufnahmen	Essential, ab 99,99 $/Monat (64 GB RAM, zwei 1,92 TB NVMe)
Zwei bis drei Kanäle, 500 bis 2.000 Zuschauer	Mehrere Leitern, tägliche Aufzeichnung	„Advanced“ ab 149,99 $/Monat oder „Elite“ ab 199,99 $/Monat
Inhalte aus verschiedenen Quellen, umfangreiche VOD-Bibliothek, über 2.000 gleichzeitige Nutzer	Befindet sich hinter einem CDN, sorgt für einen konstant hohen Durchsatz	Hochleistungsserver mit einer Basisbandbreite von 3 Gbit/s, skalierbar auf 10 Gbit/s
Benutzerdefinierter Stack, kein Control Panel, nur Root-Zugriff	Speziell für die Codierung oder als Ursprungsknoten konzipiert	Bare Metal Server
Entwicklung und Test von Encodern	Keine Produktions-Viewer	Ein dedizierter Server der Einstiegsklasse oder ein VPS

Jeder verwaltete dedizierte Server umfasst den „Advanced Product Support“, und bei allen Tarifen ab der Einstiegsstufe kann „Premier Care“ hinzugebucht werden, das Schutz vor Malware, Speicherplatz für Backups und Beratungsstunden umfasst.

Was kostet ein Streaming-Server pro Monat?

Die Rechnung für den Service macht selten den gesamten Rechnungsbetrag aus. Plane vier Posten ein:

• Der Server selbst kostet ab 99,99 $ pro Monat für eine Konfiguration, die einen einzelnen, gut abgestimmten Kanal bewältigt
• Port-Geschwindigkeit über dem Basisangebot, zu 60 $ pro Monat pro zusätzlichem Gigabit bei Tarifen, bei denen diese Option gilt
• CDN-Bereitstellung, die von deinem Anbieter pro Terabyte abgerechnet wird und bei großem Umfang oft den größten Anteil an den variablen Kosten ausmacht
• Archivspeicher, entweder mit integrierter Backup-Kapazität oder als Objektspeicher, dessen Preis pro Terabyte berechnet wird

Eine Control-Panel-Lizenz – sofern du eine benötigst – wird separat von den Managed-Care-Paketen abgerechnet. Überprüfe die aktuellen Preise im Warenkorb, bevor du den Kauf abschließt, da sich Aktions- und Verlängerungspreise unterscheiden.

Was führt zu Pufferung, nachdem du den Server gekauft hast?

Die Hardware ist selten der Übeltäter. Diese fünf Konfigurationsprobleme sind für die meisten Beschwerden nach dem Kauf verantwortlich:

• Keyframe-Intervalle, die nicht mit der Segmentlänge übereinstimmen. Player können nicht nahtlos zwischen den Darstellungsvarianten wechseln, sodass es bei Qualitätsänderungen zu Rucklern kommt. Stell das Keyframe-Intervall auf das Doppelte der Bildrate ein und passe es auf allen Stufen an.
• Ein Preset, das für Live-Auftritte zu langsam ist. Die Codierung hinkt der Echtzeit hinterher und es kommt zu Bildausfällen. Greif nach veryfast und passe es dann entsprechend an.
• RTMP ist offen zum Internet hin. Jeder, der den Port findet, kann einen Stream über deine Bandbreite senden. Beschränke die Datenübertragung auf bekannte Senderadressen.
• Die Aufnahmen werden mit derselben Lautstärke wie die Live-Segmente gespeichert. Bei langen Sessions kommt es aufgrund von Festplattenkonflikten zu Rucklern. Trenne die Pfade voneinander.
• Kein CDN vor einem Origin-Server, der ein globales Publikum bedient. Die Entfernung ist kein Hardware-Problem, und kein Server-Upgrade kann das beheben.

Wo solltest du dir eine zweite Meinung zum Build einholen?

Streaming-Workloads variieren stärker als fast jeder andere Hosting-Anwendungsfall. Ein einzelner 720p-Webinar-Kanal und eine Sportübertragung mit vier Kanälen in 1080p60 liegen an entgegengesetzten Enden derselben Produktpalette, und der Unterschied zwischen einer optimal dimensionierten Lösung und einem teuren Fehler hängt meist von zwei Zahlen ab: der Spitzenzahl der gleichzeitigen Zuschauer und der Anzahl der Renditionen, die du tatsächlich benötigst.

Falls es sich bei diesen Zahlen noch um Schätzungen handelt, besprich sie vor der Bestellung. Das Team von InMotion hat Erfahrung mit Streaming- und Medien-Workloads in Shared-Origin-Setups, Multi-Channel-Konfigurationen und CDN-gestützten Architekturen – und die Gespräche zur Dimensionierung finden mit Ingenieuren statt und nicht nach einem vorgefertigten Skript. Wende dich mit deiner Schätzung der gleichzeitigen Nutzerzahlen und deiner Encoding-Stufen an das Team oder schau dir die aktuellen Dedicated-Server-Tarife an, um die Konfigurationen direkt zu vergleichen.