Wi‑Fi 8 é sobre latência, não velocidade: um playbook de rede para o escritório do CTO

Seus engenheiros acham que o modelo é burro. Não é. É o seu Wi‑Fi do escritório. Como foi reportado esta semana, o Wi‑Fi 8 (802.11bn) é a primeira atualização sem fio em anos que não persegue manchetes de velocidade — está otimizando confiabilidade e latência. Exatamente o que seus fluxos de trabalho pesados em IA precisam. Se fluxos de tokens gaguejam, a busca de código parece lenta ou ferramentas de pair programming ficam para trás durante o standup, nove em cada dez vezes o gargalo é airtime, contenção ou bufferbloat — não o seu LLM.

O que realmente muda com o Wi‑Fi 8

O Wi‑Fi 7 (802.11be) impulsionou multi‑link e canais mais largos. O Wi‑Fi 8 (802.11bn, Ultra High Reliability) dobra a aposta em performance utilizável sob carga: agendamento mais rígido, melhor tratamento de interferência e comportamento mais determinístico entre bandas. Os fornecedores vão variar no marketing, mas a direção é clara: menos jitter, menos picos, latência p95 mais consistente. Isso importa em andares de engenharia modernos, onde 50–200 laptops estão simultaneamente transmitindo tokens, colaborando ao vivo e sincronizando repositórios.

Duas implicações práticas para você:

• Mude seu KPI de throughput de pico para latência e jitter p95/p99. Se seu link faz 1,8 Gbps em um teste de corredor mas 140 ms de latência p95 durante um standup, você está perdendo.
• Você pode capturar 80% do benefício do Wi‑Fi 8 hoje com o design certo em 6 GHz, gerenciamento de filas e disciplina de clientes. Não precisa esperar por selos 802.11bn.

Mapeie sua carga real: não é banda, é concorrência

A maior parte do tráfego de dev na era da IA não é “grande”. É conversacional e interativo:

• Streaming de tokens: 1–3 fluxos SSE/WS concorrentes por engenheiro, poucos kbps porém sensíveis a jitter.
• Chamadas de vídeo com IDEs compartilhados: 1–2 fluxos em tempo real por engenheiro, taxa variável, sensível a perda de pacotes.
• Sincronização em segundo plano (Git, registries de pacotes, contêineres): com rajadas, oportunista; pode sufocar o tempo real sem disciplina de filas.

A meta de design não é “3 Gbps para cada mesa”. É “latência p95 abaixo de 25 ms com 70% de utilização de airtime para 100+ fluxos simultâneos em tempo real”.

Um framework de decisão para o CTO: projete para latência agora, esteja pronto para o Wi‑Fi 8 depois

1) Espectro e plano de canais: use 6 GHz, mas sem ganância

• Adote 6 GHz Low‑Power Indoor (LPI) agora. Nos EUA, 6 GHz oferece até 14 canais de 80 MHz não sobrepostos. Isso é um presente — use para reduzir contenção, não para perseguir testes de “320 MHz”.
• Prefira canais de 80 MHz em 6 GHz em andares densos. Canais mais largos (160/320) aumentam domínios de colisão e na verdade elevam a latência p95 quando o andar está movimentado.
• Mantenha 5 GHz em 40–80 MHz com planejamento cuidadoso de DFS; deixe 2,4 GHz apenas para legado/IoT.
• Desative taxas de dados legadas. Em 2,4 GHz, desligue 1/2/5,5/11 Mbps. Em 5 GHz, desative 6/9 Mbps e considere 12 Mbps como mínimo. Clientes “grudentos” destroem o airtime.

2) Densidade de access points e backhaul: planeje para airtime, não para “barrinhas”

• Almeje no máximo 30–40 clientes ativos por rádio de AP para andares sensíveis a latência. Para um andar com 120 engenheiros, isso tipicamente significa 4–6 APs em 6 GHz mais sobreposição em 5 GHz.
• Use backhaul de 2,5 GbE por AP como baseline; 5 GbE para implantações muito densas. Não faça uplink de APs tri‑band Wi‑Fi 7/8 via 1 GbE e espere milagres.
• Orce PoE corretamente. APs tri‑band modernos frequentemente consomem 20–31 W. 802.3at (PoE+) fornece até 30 W; alguns modelos pedem 802.3bt. Confira as especificações do seu switch.

3) SSID e segurança: elimine a proliferação de SSIDs

• Cada SSID custa airtime por causa de beacons — cerca de 0,5–1% por SSID por banda. Limite a 2–3 SSIDs por banda.
• Use WPA3‑Enterprise com EAP‑TLS e certificados por dispositivo para laptops de staff. Reserve um SSID separado, com limite de taxa, para convidados.
• Isolar IoT. Não deixe leitores de crachá e TVs de salas de reunião compartilharem políticas de airtime com laptops de engenheiros. SSID separado, VLAN separada e, se possível, APs separados em 2,4 GHz.

4) Gerenciamento de filas e QoS: combata o bufferbloat primeiro

• Implemente Smart Queue Management (SQM) na borda da WAN com FQ‑CoDel ou Cake. Só isso costuma reduzir a latência p95 em 30–70% durante builds e deploys.
• Mapeie DSCP para WMM corretamente: EF (46) para Voz, AF41/AF31 para Vídeo, todo o resto Best Effort. Não marque tudo como EF ou você vai colapsar a fila.
• Ative airtime fairness nos APs; prefira fornecedores que exponham profundidade de fila e telemetria por AC.

5) Roaming e potência: deixe previsível

• Habilite 802.11k/v e 802.11r (fast BSS transition) para laptops que suportem. Sua sessão de codificação ao vivo não deve travar ao se mover entre salas de reunião.
• Ajuste a potência de transmissão para baixo para incentivar roaming. APs superpotentes causam clientes “grudentos” e problemas de nó oculto.

6) Disciplina de clientes: defina o padrão para laptops e smartphones

• Padronize adaptadores de rede compatíveis com 6 GHz (por exemplo, Intel AX211/BE200 ou equivalentes). Até 2026, a maioria dos laptops premium virá com 6 GHz; exija isso nas compras.
• Desligue hotspots pessoais nos celulares. Tethering pessoal destrói planos de RF e confunde o roaming.
• Prenda apps de conferência a codecs de hardware quando disponíveis. Codificação por software gera picos de CPU e atraso de enfileiramento.

7) Layout do escritório: cabos ainda importam

• Puxe Cat6A suficiente para suportar 2,5/5 GbE e PoE por ponto de AP. Assuma densidade de um AP por 800–1.200 pés² em 6 GHz, mais em prédios com muito vidro ou mais antigos.
• Forneça dois uplinks agregados de 10 GbE por IDF para o core. Você não quer que uplinks de switch virem seu novo gargalo depois que o RF estiver estável.

Medição: adote SLOs de latência, não testes de velocidade

Testes de velocidade são teatro. Adote métricas que correlacionam com a felicidade do desenvolvedor:

• RTT p95 na LAN sob carga: mire em 15–25 ms. Teste com flent ou um ping controlado enquanto satura o tráfego de fundo.
• RTT p95 na WAN até suas bordas de inferência de IA: defina um SLO (por exemplo, abaixo de 60 ms até seu POP de inferência mais próximo) e alerte sobre desvios.
• Jitter p95 para conferências: abaixo de 20 ms tipicamente parece “responsivo”.
• Utilização de airtime por rádio: sustente 60–70% sem picos de p95. Se a p95 dispara acima de 80 ms com 50% de airtime, seu enfileiramento ou plano de canais está errado.

Ferramentas que realmente ajudam:

• flent (testes RRUL) para expor bufferbloat em todas as direções.
• iperf3 para verificações controladas de throughput por banda e por AP.
• Heatmaps de RF do fornecedor mais surveys Ekahau/NetSpot para layout inicial e validação.
• Telemetria dos APs para profundidade de fila por AC, taxas de retransmissão e distribuição de clientes entre bandas.

Considerações específicas de IA que a maioria dos escritórios ignora

Fluxos de tokens são pequenos, mas frágeis

Cada desenvolvedor pode manter 2–4 fluxos SSE/WS concorrentes. Individualmente são kilobits, mas a sensibilidade a micro‑rajadas é alta. Se sua latência p95 aumenta 80–120 ms durante um pull de contêiner, o usuário percebe o modelo como “pensando” ou “mais burro”. Isso é problema de enfileiramento, não de modelo.

Cache na borda não é mais opcional

Coloque seus endpoints de modelo/roteador o mais perto possível — regionalmente ou via aceleradores on‑premises quando fizer sentido. Tirar 20–30 ms do RTT da WAN pode reduzir o tempo de resposta percebido do modelo em 10–20% em tarefas interativas. Para copilotos internos e busca de código, proxies locais mais keep‑alives HTTP/2 evitam churn de conexão.

Sincronização em segundo plano precisa ser controlada

Registries de contêiner, gerenciadores de pacotes e agentes de indexação podem preencher toda fila que você der. Limite a taxa do tráfego de fundo por dispositivo (por exemplo, 20–50 Mbps) e confie no SQM para manter os fluxos em tempo real à frente na fila. Seu “AP mais rápido” não supera um runner de CI sem limites puxando imagens de 15 GB na hora do almoço.

Segurança sem matar a latência

• WPA3‑Enterprise (EAP‑TLS) com certificados de curta duração e perfis aplicados por MDM oferecem identidade por dispositivo sem jogos de portal cativo. Portais cativos desperdiçam airtime e quebram fast roaming.
• Microsegmente em L3/L4, não em domínios de roaming L2. Mantenha domínios de broadcast pequenos. Gateways mDNS/Bonjour para os poucos serviços que precisarem; suprima o resto.
• Prefira ACLs em velocidade de linha nos switches de acesso e nos APs. Não faça hairpin de todo pacote por um firewall na nuvem se sua política não exigir.

Custos e cronograma: o que esperar

• APs: US$ 700–US$ 1.200 por unidade corporativa tri‑band, mais US$ 150–US$ 300 para montagem e cabeamento.
• Switching: switches de acesso 2,5/5 GbE PoE+ ou PoE++ custam um ágio de US$ 90–US$ 150 por porta sobre 1 GbE; uplinks de core 10/25 GbE conforme necessário.
• Survey e design: custo único de US$ 5k–US$ 20k dependendo do número de andares e da complexidade de RF.
• Timing do Wi‑Fi 8: espere equipamentos corporativos iniciais em 2026–2027, com NICs de clientes na sequência. Não congele seu rollout de 6 GHz esperando por logos; você vai adaptar recursos de firmware conforme amadureçam.

Um plano de execução 30‑60‑90 dias

Dia 0–30: estabeleça baseline e estanque a sangria

• Instrumente: adicione testes flent aos checks da rede do escritório; exporte RTT p95 e jitter para o dashboard do seu NOC.
• Implemente SQM na borda da WAN com FQ‑CoDel ou Cake. Se seu firewall não fizer, coloque um shaper dedicado em linha.
• Reduza SSIDs para no máximo três por banda. Desative taxas legadas. Ative airtime fairness e fast roaming.
• Defina um padrão de compras: apenas laptops com adaptadores compatíveis com 6 GHz.

Dia 31–60: reprojete para 6 GHz

• Rode um plano de RF preditivo para 6 GHz com canais de 80 MHz. Valide com um survey pontual.
• Atualize switching onde necessário para 2,5 GbE PoE+ e garanta ao menos dois uplinks de 10 GbE para o core por IDF.
• Segregue IoT em 2,4 GHz com SSID/VLAN separados. Imponha onboarding de dispositivos via certificados.
• Pilote um único andar de engenharia: mire em latência p95 na LAN abaixo de 25 ms durante o pico do standup. Itere o plano de canais de acordo.

Dia 61–90: fortaleça e defina SLOs

• Faça rollout de 6 GHz nos demais andares. Mantenha um playbook vivo de posições de AP e níveis de potência comprovados.
• Publique SLOs de latência para a rede do escritório: por exemplo, RTT p95 na LAN sob carga ≤ 25 ms; WAN até a borda de IA mais próxima ≤ 60 ms; jitter p95 de conferência ≤ 20 ms.
• Automatize testes contínuos (RRUL horário, teste de caminhada de roaming diário) e alerte em violações de SLO.
• Prepare orçamento para upgrades de firmware 802.11bn ou trocas de AP em 2027. Escolha fornecedores com roadmap crível de Wi‑Fi 8.

Trade‑offs a reconhecer

• Canais mais largos nem sempre são melhores. 160/320 MHz parecem ótimos na demo do fornecedor e colapsam às 15h. 80 MHz frequentemente vence em p95 em escritórios reais.
• Mais APs nem sempre são melhores. Implantações densas demais sem disciplina de potência/canal causam interferência co‑canal e pior latência.
• QoS pode atrapalhar se mal aplicada. Marcação excessiva como EF estrangula Best Effort e força retransmissões TCP que destroem a responsividade percebida.
• Segurança vs. roaming. EAP‑TLS e 802.11r funcionam bem juntos em stacks modernos; portais cativos e contorcionismos de NAC por SSID raramente funcionam.

Por que isso importa para o seu roadmap de IA

Quando sua equipe diz “o modelo local é pior que a API”, meça o RF. Se a latência p95 dentro do seu escritório salta de 20 ms para 120 ms toda vez que alguém inicia um pull de contêiner, seus agentes parecerão “mais burros”, sua busca de código parecerá “mais fraca” e suas sessões de programação em par vão deslizar do tempo real para o constrangimento. A promessa do Wi‑Fi 8 é latência estável e determinística; seu trabalho é criar as condições para que esses ganhos se materializem.

Escolha parceiros que sabem executar

Isso não é um upgrade “configurar e esquecer”. É uma disciplina de design. Trabalhe com engenheiros de rede fluentes em planejamento de 6 GHz, SQM e SLOs de tempo real — não apenas throughput de pico. Peça aos fornecedores p95 sob carga, não testes de velocidade de corredor. E não lance outro piloto de IA até que seus andares consigam manter latência p95 abaixo de 25 ms na LAN durante as horas de pico. Seus modelos de repente parecerão muito mais inteligentes.

Pontos‑chave

• Wi‑Fi 8 muda o foco de velocidade de pico para latência previsível — exatamente o que fluxos de trabalho pesados em IA precisam.
• Você consegue a maior parte do benefício agora com um bom design em 6 GHz, SQM e padrões de clientes.
• Projete para SLOs de latência e jitter p95, não para se gabar de Gbps.
• Use 80 MHz em 6 GHz, limite SSIDs a três por banda e mantenha clientes ativos abaixo de ~40 por rádio.
• Implemente SQM (FQ‑CoDel/Cake), mapeamento DSCP→WMM adequado e fast roaming (802.11k/v/r).
• Orce para backhaul de 2,5/5 GbE, uplinks de 10 GbE e densidade realista de AP (1 por 800–1.200 pés²).
• Defina um plano de 90 dias: baseline e SQM, piloto em 6 GHz, depois publique SLOs de latência e escale.