Wi‑Fi 8 ist eine Frage der Latenz, nicht der Geschwindigkeit: Das CTO‑Playbook fürs Büro‑Netzwerk

Ihre Entwickler denken, das Modell sei dumm. Ist es nicht. Es ist Ihr Büro‑Wi‑Fi. Wie diese Woche berichtet wurde, ist Wi‑Fi 8 (802.11bn) das erste Wireless‑Upgrade seit Jahren, das nicht der Schlagzeilen‑Geschwindigkeit hinterherläuft – es optimiert Zuverlässigkeit und Latenz. Genau das brauchen Ihre KI‑lastigen Workflows. Wenn Token‑Streams stottern, Code‑Suche träge wirkt oder Pair‑Programming‑Tools im Stand‑up hinterherhinken, liegt der Engpass in neun von zehn Fällen bei Airtime, Contention oder Bufferbloat – nicht bei Ihrem LLM.

Was sich mit Wi‑Fi 8 tatsächlich ändert

Wi‑Fi 7 (802.11be) trieb Multi‑Link und breitere Kanäle voran. Wi‑Fi 8 (802.11bn, Ultra High Reliability) setzt auf nutzbare Leistung unter Last: strafferes Scheduling, besseres Störungs‑Handling und deterministischeres Verhalten über Bänder hinweg. Die Vermarktung wird je nach Anbieter variieren, aber die Stoßrichtung ist klar: weniger Jitter, weniger Ausreißer, konsistentere p95‑Latenz. Das ist entscheidend auf modernen Engineering‑Flächen, auf denen 50–200 Laptops gleichzeitig Tokens streamen, live kollaborieren und Repos synchronisieren.

Zwei praktische Konsequenzen für Sie:

• Verschieben Sie Ihren KPI‑Fokus von Peak‑Durchsatz auf p95/p99‑Latenz und Jitter. Wenn Ihr Link im Flurtest 1,8 Gbit/s schafft, aber während des Stand‑ups 140 ms p95‑Latenz hat, verlieren Sie.
• Sie können heute schon 80% des Wi‑Fi‑8‑Vorteils mit dem richtigen 6‑GHz‑Design, Queue‑Management und Client‑Disziplin heben. Sie müssen nicht auf 802.11bn‑Logos warten.

Ihre tatsächliche Last abbilden: Es geht nicht um Bandbreite, sondern um Gleichzeitigkeit

Die meisten Dev‑Verkehre in der KI‑Ära sind nicht „groß“. Sie sind geschwätzig und interaktiv:

• Token‑Streaming: 1–3 gleichzeitige SSE/WS‑Streams pro Engineer, niedrige kbit/s, aber empfindlich gegenüber Jitter.
• Videocalls mit geteilten IDEs: 1–2 gleichzeitige Echtzeitflüsse pro Engineer, variable Rate, empfindlich gegenüber Paketverlust.
• Hintergrund‑Sync (Git, Paket‑Registries, Container): schubweise, opportunistisch; kann ohne Queue‑Disziplin Echtzeitverkehr verdrängen.

Das Designziel ist nicht „3 Gbit/s an jedem Schreibtisch“. Es ist „≤ 25 ms p95‑Latenz unter 70% Airtime‑Auslastung bei 100+ gleichzeitigen Echtzeitflüssen“.

Ein Entscheidungsrahmen für CTOs: Jetzt für Latenz designen, später Wi‑Fi‑8‑ready sein

1) Spectrum und Kanalplan: 6 GHz nutzen, aber nicht gierig werden

• 6 GHz Low‑Power Indoor (LPI) jetzt einführen. In den USA erhalten Sie bis zu 14 nicht überlappende 80‑MHz‑Kanäle in 6 GHz. Das ist ein Geschenk – nutzen Sie es zur Reduzierung von Contention, nicht für 320‑MHz‑„Speedtests“.
• In dichten Flächen 80‑MHz‑Kanäle auf 6 GHz bevorzugen. Breitere Kanäle (160/320) vergrößern Kollisionsdomänen und erhöhen die p95‑Latenz, wenn der Floor ausgelastet ist.
• 5 GHz auf 40–80 MHz mit sorgfältiger DFS‑Planung belassen; 2,4 GHz nur für Legacy/IoT.
• Legacy‑Datarates deaktivieren. Auf 2,4 GHz 1/2/5.5/11 Mbit/s ausschalten. Auf 5 GHz 6/9 Mbit/s deaktivieren und 12 Mbit/s als Minimum erwägen. Sticky Clients verbrennen Airtime.

2) Access‑Point‑Dichte und Backhaul: für Airtime planen, nicht für Balken

• Zielen Sie auf maximal 30–40 aktive Clients pro AP‑Radio auf latenzsensitiven Flächen. Für eine 120‑Engineer‑Fläche sind das typischerweise 4–6 APs auf 6 GHz plus Überlappung auf 5 GHz.
• 2,5‑GbE‑Backhaul pro AP als Basis; 5 GbE für sehr dichte Deployments. Uplink‑en Sie Tri‑Band‑Wi‑Fi‑7/8‑APs nicht über 1 GbE und erwarten Wunderdinge.
• PoE korrekt budgetieren. Moderne Tri‑Band‑APs ziehen oft 20–31 W. 802.3at (PoE+) liefert bis zu 30 W; einige Modelle benötigen 802.3bt. Datenblätter Ihrer Switches prüfen.

3) SSID und Sicherheit: den SSID‑Wildwuchs beenden

• Jede SSID kostet Airtime durch Beacons – grob 0,5–1% pro SSID und Band. Auf 2–3 SSIDs pro Band begrenzen.
• WPA3‑Enterprise mit EAP‑TLS und gerätebezogenen Zertifikaten für Mitarbeiter‑Laptops einsetzen. Separat eine eigene, gedrosselte SSID für Gäste vorsehen.
• IoT isolieren. Lassen Sie Badge‑Reader und Konferenzraum‑TVs nicht dieselben Airtime‑Policies wie Entwickler‑Laptops teilen. Eigene SSID, eigenes VLAN und nach Möglichkeit eigene APs auf 2,4 GHz.

4) Queue‑Management und QoS: zuerst Bufferbloat bekämpfen

• Smart Queue Management (SQM) am WAN‑Edge mit FQ‑CoDel oder Cake implementieren. Das allein senkt die p95‑Latenz während Builds und Deploys oft um 30–70%.
• DSCP korrekt auf WMM mappen: EF (46) auf Voice, AF41/AF31 auf Video, alles andere Best Effort. Markieren Sie nicht alles als EF, sonst kollabiert die Queue.
• Airtime Fairness auf APs aktivieren; Anbieter bevorzugen, die Queue‑Tiefe und Telemetrie pro Access Category (AC) sichtbar machen.

5) Roaming und Sendeleistung: langweilig machen

• 802.11k/v und 802.11r (Fast BSS Transition) für Laptops aktivieren, die es unterstützen. Ihre Live‑Coding‑Session darf beim Gang zwischen Huddle‑Räumen nicht hängen bleiben.
• Sendeleistung herunterregeln, um Roaming zu fördern. Überpowerte APs verursachen Sticky Clients und Hidden‑Node‑Probleme.

6) Client‑Disziplin: klare Standards für Laptops und Phones

• Standardisieren Sie auf 6‑GHz‑fähige NICs (z. B. Intel AX211/BE200 oder gleichwertige Modelle). Bis 2026 liefern die meisten Premium‑Laptops 6 GHz ab Werk; erzwingen Sie das in der Beschaffung.
• Private Hotspots auf Phones ausschalten. Persönliches Tethering zerstört RF‑Pläne und verwirrt Roaming.
• Konferenz‑Apps auf Hardware‑Codecs pinnen, wo verfügbar. Software‑Encoding treibt CPU und Warteschlangenverzögerung hoch.

7) Bürolayout: Kabel zählen weiterhin

• Genug Cat6A zu jedem AP‑Standort ziehen, um 2,5/5 GbE und PoE zu unterstützen. AP‑Dichte von einem pro 800–1.200 sq ft (ca. 75–110 m²) auf 6 GHz ansetzen, mehr in glaslastigen oder älteren Gebäuden.
• Zwei gebündelte 10‑GbE‑Uplinks pro IDF zum Core bereitstellen. Sie wollen keine Switch‑Uplinks als neuen Flaschenhals, sobald das RF stabil ist.

Messung: Latenz‑SLOs, nicht Speedtests

Speedtests sind Theater. Setzen Sie Metriken ein, die mit Entwicklerzufriedenheit korrelieren:

• On‑LAN p95‑RTT unter Last: Ziel 15–25 ms. Mit flent oder einem kontrollierten Ping testen, während Hintergrundverkehr gesättigt wird.
• WAN‑p95‑RTT zu Ihren KI‑Inference‑Edges: SLO setzen (z. B. unter 60 ms zum nächstgelegenen Inference‑POP) und bei Drift alarmieren.
• Jitter p95 für Konferenzen: unter 20 ms fühlt sich typischerweise „snappy“ an.
• Airtime‑Auslastung pro Radio: 60–70% ohne p95‑Ausreißer halten. Wenn p95 bei 50% Airtime auf über 80 ms schießt, stimmt Ihr Queueing oder Kanalplan nicht.

Tools, die wirklich helfen:

• flent (RRUL‑Tests), um Bufferbloat in beide Richtungen offenzulegen.
• iperf3 für kontrollierte Durchsatztests pro Band und pro AP.
• RF‑Heatmaps des Anbieters plus Ekahau/NetSpot‑Surveys für initiales Layout und Validierung.
• AP‑Telemetrie zu Warteschlangentiefe pro AC, Retry‑Raten und Client‑Verteilung über die Bänder.

KI‑spezifische Aspekte, die die meisten Büros übersehen

Token‑Streams sind klein, aber fragil

Jede Entwicklerin/jeder Entwickler hält womöglich 2–4 gleichzeitige SSE/WS‑Streams. Für sich genommen sind das Kilobits, aber die Empfindlichkeit gegenüber Mikrobursts ist hoch. Wenn Ihre p95‑Latenz während eines Container‑Pulls um 80–120 ms steigt, wirkt das Modell für den Nutzer als „denkender“ oder „dümmer“. Das ist ein Queueing‑Problem, kein Modellproblem.

Edge‑Caching ist nicht mehr optional

Bringen Sie Ihre Model/Router‑Endpoints so nah wie möglich heran – regional oder, wo sinnvoll, via On‑Prem‑Beschleuniger. 20–30 ms weniger WAN‑RTT können die subjektive Modellantwortzeit bei interaktiven Aufgaben um 10–20% reduzieren. Für interne Copilots und Code‑Suche verhindern lokale Proxys plus HTTP/2‑Keep‑Alives Verbindungs‑Churn.

Background‑Sync braucht eine Leine

Container‑Registries, Paketmanager und Indexing‑Agents füllen jede Queue, die Sie ihnen geben. Hintergrundtraffic pro Gerät drosseln (z. B. 20–50 Mbit/s) und auf SQM setzen, damit Echtzeitflüsse vorn bleiben. Ihr „schnellster AP“ kann einen ungebremsten CI‑Runner, der über Mittag 15 GB Images zieht, nicht ausoptimieren.

Sicherheit, ohne die Latenz zu ruinieren

• WPA3‑Enterprise (EAP‑TLS) mit kurzlebigen Zertifikaten und MDM‑erzwungenen Profilen liefert Geräteidentität ohne Captive‑Portal‑Spielchen. Captive Portals verschwenden Airtime und brechen Fast‑Roaming.
• Auf L3/L4 mikrosegmentieren, nicht über L2‑Roaming‑Domänen. Broadcast‑Domänen klein halten. mDNS/Bonjour‑Gateways für die wenigen benötigten Dienste; den Rest unterdrücken.
• Wire‑Speed‑ACLs an Access‑Switches und APs bevorzugen. Routen Sie nicht jedes Paket per Hairpin durch eine Cloud‑Firewall, wenn Ihre Policy es nicht verlangt.

Kosten und Timeline: was zu erwarten ist

• APs: 700–1.200 $ pro Enterprise‑Tri‑Band‑Einheit, plus 150–300 $ für Montage und Verkabelung.
• Switching: 2,5/5‑GbE‑PoE+ oder PoE++ Access‑Switches kosten 90–150 $ Port‑Aufpreis gegenüber 1 GbE; Core‑Uplinks 10/25 GbE nach Bedarf.
• Survey und Design: einmalig 5.000–20.000 $, je nach Anzahl der Etagen und RF‑Komplexität.
• Wi‑Fi‑8‑Timing: Erste Enterprise‑Geräte 2026–2027 erwarten, Client‑NICs folgen. Verzögern Sie Ihren 6‑GHz‑Rollout nicht wegen Logos; Firmware‑Features werden nachgerüstet, sobald sie reifen.

Ein 30‑60‑90‑Tage‑Umsetzungsplan

Tag 0–30: Baseline und das Gröbste stoppen

• Instrumentieren: flent‑Tests in Ihre Office‑Netzwerkchecks einbinden; p95‑RTT und Jitter ins NOC‑Dashboard exportieren.
• SQM am WAN‑Edge mit FQ‑CoDel oder Cake implementieren. Wenn Ihre Firewall das nicht kann, einen dedizierten Shaper inline setzen.
• SSIDs auf maximal drei pro Band reduzieren. Legacy‑Raten deaktivieren. Airtime Fairness und Fast‑Roaming einschalten.
• Beschaffungsstandard setzen: Nur noch 6‑GHz‑fähige NICs für neue Laptops.

Tag 31–60: Neuarchitektur für 6 GHz

• Eine prädiktive RF‑Planung für 6 GHz mit 80‑MHz‑Kanälen erstellen. Mit einem Spot‑Survey validieren.
• Switching bei Bedarf auf 2,5‑GbE‑PoE+ upgraden und pro IDF mindestens duale 10‑GbE‑Uplinks zum Core sicherstellen.
• IoT auf 2,4 GHz mit separater SSID/VLAN segregieren. Geräte‑Onboarding über Zertifikate erzwingen.
• Eine einzelne Engineering‑Fläche pilotieren: Ziel p95‑On‑LAN‑Latenz unter Last ≤ 25 ms zur Peak‑Stand‑up‑Zeit. Kanalplan entsprechend iterieren.

Tag 61–90: Härtung und SLOs setzen

• 6 GHz über die restlichen Flächen ausrollen. Ein fortlaufendes Playbook bekannter guter AP‑Platzierungen und Leistungspegel führen.
• Latenz‑SLOs fürs Büro‑Netzwerk veröffentlichen: z. B. p95‑LAN‑RTT unter Last ≤ 25 ms; WAN zum nächstgelegenen KI‑Edge ≤ 60 ms; Konferenz‑Jitter p95 ≤ 20 ms.
• Kontinuierliche Tests automatisieren (stündliches RRUL, täglicher Roaming‑Walk) und bei SLO‑Verletzungen alarmieren.
• Budget für 802.11bn‑Firmware‑Upgrades oder AP‑Tausche in 2027 vorab einplanen. Anbieter mit glaubwürdiger Wi‑Fi‑8‑Roadmap wählen.

Abwägungen, die Sie im Blick haben sollten

• Breitere Kanäle sind nicht immer besser. 160/320 MHz sehen in der Hersteller‑Demo toll aus und brechen um 15 Uhr ein. 80 MHz gewinnt in echten Büros oft beim p95.
• Mehr APs sind nicht immer besser. Zu dichte Deployments ohne Disziplin bei Leistung/Kanalwahl erzeugen Co‑Channel‑Interferenz und schlechtere Latenz.
• QoS kann schaden, wenn falsch angewendet. Übermäßiges EF‑Marking hungert Best Effort aus und erzwingt TCP‑Retransmits, die die wahrgenommene Responsiveness ruinieren.
• Sicherheit vs. Roaming. EAP‑TLS und 802.11r funktionieren auf modernen Stacks gut zusammen; Captive Portals und pro‑SSID‑NAC‑Spielchen selten.

Warum das für Ihre KI‑Roadmap zählt

Wenn Ihr Team sagt „das lokale Modell ist schlechter als die API“, messen Sie das RF. Wenn die p95‑Latenz in Ihrem Büro jedes Mal von 20 ms auf 120 ms springt, sobald jemand einen Container‑Pull startet, wirken Ihre Agenten „dümmer“, Ihre Code‑Suche „schwächer“ und Ihre Pair‑Programming‑Sessions rutschen von Echtzeit in peinlich. Das Versprechen von Wi‑Fi 8 ist stabile, deterministische Latenz; Ihre Aufgabe ist es, die Bedingungen zu schaffen, unter denen diese Gewinne ankommen.

Wählen Sie Partner, die liefern können

Das ist kein „einrichten und vergessen“‑Upgrade. Es ist eine Design‑Disziplin. Arbeiten Sie mit Netzwerkteams, die 6‑GHz‑Planung, SQM und Echtzeit‑SLOs beherrschen – nicht nur Peak‑Durchsatz. Fordern Sie von Anbietern p95‑Werte unter Last, nicht Flur‑Speedtests. Und starten Sie keinen weiteren KI‑Piloten, bevor Ihre Flächen während der Peak‑Stunden ≤ 25 ms p95‑On‑LAN‑Latenz halten. Ihre Modelle werden plötzlich deutlich smarter wirken.

Wichtigste Erkenntnisse

• Wi‑Fi 8 verlagert den Fokus von Peak‑Speed auf vorhersagbare Latenz – genau das, was KI‑lastige Workflows benötigen.
• Den Großteil des Nutzens erhalten Sie schon heute mit solidem 6‑GHz‑Design, SQM und Client‑Standards.
• Auf p95‑Latenz und Jitter‑SLOs designen, nicht auf Gbit/s‑Prahlereien.
• 80 MHz in 6 GHz nutzen, SSIDs pro Band auf drei begrenzen und aktive Clients auf ~40 pro Radio halten.
• SQM (FQ‑CoDel/Cake), korrektes DSCP→WMM‑Mapping und Fast‑Roaming (802.11k/v/r) implementieren.
• Für 2,5/5‑GbE‑Backhaul, 10‑GbE‑Uplinks und realistische AP‑Dichte (1 pro 800–1.200 sq ft) budgetieren.
• Einen 90‑Tage‑Plan setzen: Baseline und SQM, 6‑GHz‑Pilot, dann Latenz‑SLOs veröffentlichen und skalieren.

Author: Diogo Hudson Dias