O ASUS ROG Flow Z13: Meu Laboratório Doméstico Portátil Que Se Recusou a Ficar Portátil

O ASUS ROG Flow Z13 nunca devia ter sido um servidor. É um tablet gamer com teclado destacável, uma barra de luz RGB, e GPU suficiente para rodar títulos AAA em configurações respeitáveis. Comprei um open-box em fevereiro de 2026 como estação de trabalho portátil — algo que eu pudesse jogar numa mochila, encaixar num dock em casa, e usar como minha máquina para tudo. Por cinco meses, foi exatamente isso que ele fez, e fez melhor do que hardware com o dobro do tamanho.

Depois ele desenvolveu uma falha de energia, e não completou mais um boot desde então.

Especificações completas

Componente	Especificação
Modelo	ASUS ROG Flow Z13 (2025) — GZ302EA
CPU	AMD Ryzen AI Max+ 395 ("Strix Halo") — 16 núcleos / 32 threads, até 5,1 GHz, 80 MB de cache
GPU	AMD Radeon 8060S — RDNA 3.5, integrada, 40 unidades de computação
NPU	AMD XDNA — até 50 TOPS
RAM	128 GB LPDDR5X-8000, soldada (memória unificada CPU/GPU)
Armazenamento	1 TB NVMe PCIe 4.0, M.2 2230
Tela	13,4" 2560×1600, 180 Hz, touchscreen
Bateria	70 Wh
Portas	2× USB4 Type-C, 1× USB 3.2 Type-A, HDMI 2.1, microSD, entrada combo P2 de 3,5 mm
Sem fio	Wi-Fi 7, Bluetooth 5.4
Peso	~1,2 kg (tablet) / ~1,5 kg (com teclado capa)
SO	Veio com Windows 11; rodou Bazzite (Fedora Atomic) durante toda a sua vida de serviço
Diferenciais	Teclado capa destacável com RGB por tecla, barra de luz na borda, suporte a caneta stylus

O número de destaque é o 128 GB. Por ser LPDDR5X unificada e compartilhada entre CPU e GPU, eu conseguia reservar 64 GB dela como VRAM e ainda sobravam 64 GB para o sistema operacional. No começo de 2026 não havia outra máquina que você pudesse carregar numa mão e fizesse isso.

O Que Ele Rodava, no Dia a Dia

Um modelo de 120B, localmente

A memória era o ponto principal. Com 64 GB reservados como VRAM e o ROCm comandando a iGPU RDNA 3.5, eu rodava um modelo de 120B parâmetros nesse tablet — devagar, mas de verdade, numa velocidade utilizável para trabalho em segundo plano. Modelos menores eram confortáveis: um MoE de 30B rodava a cerca de 70 tokens/segundo, o que é tranquilo para uso interativo.

Essa capacidade moldou toda a stack que eu construí em cima dela. Meu elenco de agentes tinha um nível que nunca tocava numa API de nuvem: trabalho braçal em massa, varreduras noturnas, e tudo que eu não queria que saísse de casa ia para o modelo local, e isso custava só eletricidade. A configuração de oito agentes do OpenClaw e o detalhamento de custos pressupõem que esse nível existe, porque nessa máquina ele existia.

Desenvolvimento e hospedagem

Todo site que eu mantenho foi escrito, construído e visualizado aqui antes do deploy — este incluído. As portas USB4 alimentavam um monitor 4K e um dock, então o mesmo tablet virava uma estação de trabalho desktop em cerca de quatro segundos.

Infraestrutura sempre ligada

Ele rodava o Tailscale como espinha dorsal da minha rede doméstica e uma pilha de serviços systemd que mantinha tudo se comunicando. Estava sempre ligado, sempre na tomada, e sempre sob alguma carga. Esse último detalhe importa para como esta história termina.

O Que Funcionou Muito Bem

• 128 GB de memória unificada. Só essa especificação já colocava o Z13 numa classe à parte. Rodar um modelo de 120B num tablet ainda parece meio absurdo, e nada mais portátil chegava perto na época.
• Compatibilidade com Linux. Assim que migrei do Windows 11 para o Bazzite, tudo se encaixou. O protocolo HID Aura da ASUS funcionava via hidraw, o ROCm comandava a iGPU, e unidades systemd substituíram cada processo de segundo plano do Windows por algo mais limpo.
• O fator de forma. Tablet no sofá, desktop no dock, servidor headless atrás do monitor — tudo a mesma máquina, trocada em segundos. O teclado capa era genuinamente bom: curso de tecla completo, sem flex.
• Desempenho de GPU. Quarenta unidades de computação de RDNA 3.5 davam conta de CAD, inferência local e jogos leves. Nunca se comportou como uma gráfica integrada comum.

O Que Não Funcionou

• Temperaturas sob carga sustentada. O chassi fino tinha exatamente uma estratégia para o calor: girar as ventoinhas mais forte. Uma sessão longa de inferência o transformava num secador de cabelo, e o chassi ficava desconfortavelmente quente ao toque.
• Entrega de energia sob carga combinada. O carregamento é USB-PD pelas portas Type-C. Sob uma carga pesada de CPU+GPU, a plataforma podia consumir mais do que o carregador estava disposto a fornecer, então a bateria ia descendo devagar mesmo com o cabo conectado — a máquina efetivamente se completando com a própria bateria para cobrir a diferença.
• Duração de bateria no Linux. O Windows conseguia de seis a oito horas com o ajuste de firmware da ASUS. O Linux conseguia de três a quatro num bom dia, e suspender/retomar com um teclado destacável era uma fonte recorrente de dor de cabeça com udev.
• Não reparável. A RAM é soldada e o chassi é lacrado. O SSD M.2, acessível por uma tampa no apoio dobrável (kickstand), é a única peça da máquina que o usuário pode mexer — o que acabou sendo a única coisa que me salvou.

O Projeto do Teclado RGB

O Armoury Crate da ASUS — a única forma oficial de controlar o RGB do teclado e da barra de luz — não existe no Linux. Então escrevi o meu próprio: uma CLI em Python falando direto com a interface HID Aura, um seletor de cores em GTK4, e um painel de navegador em localhost. Cerca de 40 KB no total, e ele sobrevivia à suspensão, ao reinício, e ao desencaixe do teclado — o trio que toda outra ferramenta RGB para Linux esquece.

Virou um dos posts mais lidos deste site. Leia o artigo completo sobre o teclado RGB →

Como Terminou: Uma Falha de Energia

Por volta de 19–20 de julho de 2026 o Z13 parou de completar um boot. Passei dois dias nisso antes de concluir que não era consertável pelo meu lado. A falha é específica o bastante para valer a pena registrar direito, porque "não liga" é a frase menos útil da informática — e neste caso nem é precisa. Ele liga sem problema. Só se recusa a continuar acordado.

Os sintomas, em ordem

1. O boot para num logo estático da ROG. Não o animado — um quadro congelado. Nunca chega a um prompt de "pressione F2", nunca chega à BIOS, nunca chega a um bootloader. Até onde ele chegava variava entre tentativas: às vezes um painel morto sem luz de fundo, às vezes uma tela preta acesa com as ventoinhas rodando, às vezes o logo congelado.
2. O teclado capa fica morto no boot. A luz de fundo pisca branco no reinício, depois nada. F2, Esc e Del nunca registram. Isso bate com uma falha conhecida deste modelo, em que o controlador do teclado fica preso em modo bootloader.
3. Sem energia no barramento USB durante o POST. Conectei um teclado RGB externo enquanto o logo estava na tela: sem luzes, sem energia. Nesse estágio do POST a porta deveria estar ativa. Não estava — o que indica que o gerenciamento dos trilhos de energia do controlador embutido está travado, não que falta o sistema operacional.
4. Um evento térmico. Encontrei a máquina com a tela apagada, as ventoinhas paradas, ligada na tomada, e o chassi muito quente. Essa combinação é a alarmante: o SoC estava consumindo energia num estado travado sem nada governando as ventoinhas. Depois de um resfriamento forçado, a temperatura do chassi se estabilizou perto de 96 °F com uma ventoinha externa apontada para ele — confirmando que o calor era a anomalia, e não a referência normal.
5. O detalhe revelador: um LED de modo de espera sob um quadro congelado. Depois de um reset do EC, o LED de energia se estabilizou numa piscada lenta — cerca de um segundo aceso, cinco segundos apagado. Segundo a própria especificação de indicadores da ASUS, esse padrão significa que o notebook está em modo de espera. Uma máquina não pode estar dormindo e ao mesmo tempo segurando um logo de POST na tela. Essa contradição é o diagnóstico.
6. É reproduzível. Um toque para acordar deixava o LED branco sólido por cerca de 30 segundos, e depois ele voltava à piscada de modo de espera. Boot a frio, acordar, boot a frio: os mesmos 30 segundos, o mesmo resultado, todas as vezes.

Então a sequência é: o firmware trava no início do POST, o controlador embutido derruba a plataforma para o Modern Standby por baixo do firmware travado, e o controlador de vídeo fica segurando o último quadro que recebeu. O logo congelado não é a máquina pensando. É uma imagem parada num computador adormecido.

O que eu tentei

• Reinícios forçados e resets padrão, repetidamente.
• Reset físico de EC/RTC dos dois jeitos — segurar o botão de energia por 40 segundos com a tomada conectada, e de novo com a tomada desconectada e depois reconectada. Nessa plataforma isso é eletricamente equivalente a tirar a bateria do CMOS.
• Remoção total de periféricos: teclado desencaixado, microSD fora, todo cabo USB-C e HDMI removido, ligado como um tablet nu.
• Uma espera de 45 a 60 minutos sem mexer depois do reset, para o caso de um retreinamento dos 128 GB de memória ou uma cápsula de firmware pendente precisar do tempo.
• Tentativa de entrar na BIOS pelo teclado capa (morto), por um teclado USB externo (porta sem energia), e por Volume Menos + energia.
• Um resfriamento completo, depois um novo teste a frio.

Eu pulei desconectar fisicamente a bateria do CMOS: a segurada de 40 segundos já realiza esse reset eletricamente, e isso não repara um EC travado nem uma falha de entrega de energia. Também pulei tudo em nível de sistema operacional, pelo motivo abaixo.

O que eu descartei, e como

Suspeito	Veredito	Por quê
Software / SO / argumentos de kernel	Isento	O travamento acontece antes de qualquer bootloader carregar. Nada no disco executa no ponto da falha, então nenhuma configuração nele pode ser a causa.
Dispositivo de boot / SSD	Isento	Tanto o trilho USB morto quanto a assinatura de pane-para-modo-de-espera ficam acima da camada de armazenamento. O SSD foi depois retirado e está saudável — está rodando na máquina substituta.
Bloqueio térmico	Isento	A falha se reproduz a frio, a ~96 °F.
Bateria descarregada	Isento	A piscada é o pulso branco de modo de espera, não o indicador laranja de bateria fraca.

Não é só a minha unidade

Esta é uma classe de falha documentada neste modelo, e não azar com uma placa específica. Existe um tópico ativo no fórum da ROG descrevendo o mesmo comportamento no GZ302EA — panes repetidas de tela preta e travamento duro ligadas ao Modern Standby — e um relato separado e bem conhecido do controlador do teclado capa ficando preso em modo bootloader no Linux. Os dois batem exatamente com o que eu vi.

Se você está lendo isso porque o seu próprio Z13 está parado num logo congelado: cronometre o intervalo até o LED de energia começar sua piscada lenta. Se forem cerca de 30 segundos, você tem essa falha, e nenhuma quantidade de reinstalação vai ajudar.

O Que Dois Dias de Investigação Realmente Compraram

Não um conserto. O que compraram foi certeza — a diferença entre "quebrou, talvez eu tenha feito algo" e saber exatamente qual camada falhou e que nenhuma quantidade do meu tempo mudaria isso. Cinco fatos sustentam isso:

• Uma pane reproduzível para modo de espera em cerca de 30 segundos, tanto no boot a frio quanto ao acordar.
• Um LED de estado de espera exibido ao mesmo tempo que um logo de POST congelado — um estado em que uma máquina saudável não pode estar.
• Um evento térmico: chassi quente, ventoinhas paradas, na tomada, em estado de pane.
• Sem energia no barramento USB durante o POST.
• Um tópico de defeito específico do modelo descrevendo comportamento idêntico nas unidades de outras pessoas.

Esse último foi o que mais importou para como eu me senti sobre isso. Quando uma máquina morre existe um reflexo de se autoauditar — o argumento de kernel que você definiu, a atualização que você rodou, aquilo que você deixou compilando durante a noite. Encontrar a mesma assinatura de 30 segundos descrita por estranhos no próprio fórum do fabricante resolveu essa questão, e transformou parar numa decisão fácil, em vez de uma dúvida incômoda.

Nunca abri uma reclamação de garantia. A unidade era open-box, correr atrás disso significaria semanas sem a máquina que eu realmente precisava, e eu já tinha encomendado a substituta. Então o Z13 está numa prateleira, sem o SSD, que saiu pela tampa do apoio dobrável e foi direto para a caixa que o substituiu. Essa tampa é a única peça de design nessa máquina que valeu a pena, bem no final.

O Que Eu Diria a Quem For Rodar um Tablet Como Servidor

Não estou bravo com o Z13. Ele fez mais do que qualquer tablet tinha o direito de fazer, e fez isso por cinco meses sem reclamar. Mas existe uma lição de verdade na forma dessa falha, e não é "hardware de consumo é ruim."

É que uma máquina construída em torno de uma bateria tem uma máquina de estados de gerenciamento de energia projetada para um aparelho que carrega, descarrega, dorme e acorda. Rodá-la como servidor significa mantê-la num canto dessa máquina de estados — na tomada, quente, nunca dormindo — por meses seguidos. Essa não é a carga de trabalho para a qual o firmware foi ajustado, e a falha que acabou chegando foi uma falha de gerenciamento de energia, não uma CPU quebrada ou um disco cheio.

A versão prática: se uma máquina vai ser infraestrutura sempre ligada, prefira uma cuja história de energia seja um conector jack e uma ventoinha. E mantenha seus dados em algum lugar de onde a morte da máquina não consiga levá-los junto — o único motivo de esta história ter um final arrumado é que o SSD estava atrás de uma tampa, e não atrás de uma solda.

O Que a Substituiu

O sucessor é um CHUWI AuBox Ai365 — um mini PC AMD pequeno com um Ryzen AI 9 365, 2,5 GbE duplo, e um simples conector jack. Ele tem 30 GB de memória utilizável contra os 128 GB do Z13, o que me custou o modelo local grande por completo; esse nível agora roda um MoE de 35B em vez de um 120B, e o trabalho pesado passou para uma API de nuvem barata. Em troca, ele não tem bateria, não tem negociação USB-PD, e não tem Modern Standby para travar dentro.

Leia sobre a configuração do CHUWI AuBox Ai365 →