El ASUS ROG Flow Z13: mi laboratorio doméstico portátil que se negó a quedarse portátil

El ASUS ROG Flow Z13 nunca estuvo pensado para ser un servidor. Es una tablet gaming con teclado desmontable, una barra de luz RGB, y suficiente GPU para jugar títulos AAA en ajustes decentes. Compré una en caja abierta en febrero de 2026 como estación de trabajo portátil — algo que pudiera meter en una mochila, conectar a un dock en casa, y usar como mi máquina para todo. Durante cinco meses hizo exactamente eso, y lo hizo mejor que hardware del doble de su tamaño.

Después desarrolló una falla de alimentación, y desde entonces no ha completado un arranque.

Especificaciones completas

Componente	Especificación
Modelo	ASUS ROG Flow Z13 (2025) — GZ302EA
CPU	AMD Ryzen AI Max+ 395 "Strix Halo" — 16 núcleos / 32 hilos, hasta 5.1 GHz, 80 MB de caché
GPU	AMD Radeon 8060S — RDNA 3.5, integrada, 40 unidades de cómputo
NPU	AMD XDNA — hasta 50 TOPS
RAM	128 GB LPDDR5X-8000, soldada (memoria unificada CPU/GPU)
Almacenamiento	1 TB PCIe 4.0 NVMe, M.2 2230
Pantalla	13.4", 2560×1600, 180 Hz, táctil
Batería	70 Wh
Puertos	2× USB4 Type-C, 1× USB 3.2 Type-A, HDMI 2.1, microSD, conector combo de 3.5 mm
Conectividad inalámbrica	Wi-Fi 7, Bluetooth 5.4
Peso	~1.2 kg (tablet) / ~1.5 kg (con teclado folio)
SO	Venía con Windows 11; corrió Bazzite (Fedora Atomic) durante toda su vida de servicio
Especial	Teclado folio desmontable con RGB por tecla, barra de luz en el borde, soporte para lápiz óptico

El número estrella son los 128 GB. Como es LPDDR5X unificada y compartida entre CPU y GPU, podía separar 64 GB como VRAM y aun así quedarme con 64 GB para el sistema operativo. A principios de 2026 no había otra máquina que pudieras llevar en una mano capaz de hacer eso.

Lo que corría, día a día

Un modelo de 120B, en local

La memoria era todo el punto. Con 64 GB reservados como VRAM y ROCm manejando la iGPU RDNA 3.5, corría un modelo de 120B de parámetros en esta tablet — lento, pero de verdad, a una velocidad usable para trabajo de fondo. Los modelos más chicos eran cómodos: un MoE de 30B corría a unos 70 tokens por segundo, lo cual está bien para uso interactivo.

Esa capacidad moldeó toda la pila que construí encima. Mi elenco de agentes tenía un nivel que nunca tocaba ninguna API en la nube: trabajo pesado a granel, barridos nocturnos, y cualquier cosa que no quisiera que saliera de la casa iba al modelo local, y no costaba nada más que electricidad. Tanto la configuración de OpenClaw de ocho agentes como el desglose de costos asumen que ese nivel existe, porque en esta máquina existía.

Desarrollo y alojamiento

Cada sitio que mantengo se escribió, compiló y previsualizó aquí antes de desplegarse — este incluido. Los puertos USB4 alimentaban un monitor 4K y un dock, así que la misma tablet se convertía en una estación de escritorio en unos cuatro segundos.

Infraestructura siempre encendida

Corría Tailscale como columna vertebral de mi red doméstica y una pila de servicios de systemd que mantenía todo comunicándose. Estaba siempre encendida, siempre enchufada, y siempre bajo alguna carga. Ese último detalle importa para cómo termina esta historia.

Lo que funcionó de maravilla

• 128 GB de memoria unificada. Esta especificación por sí sola ponía al Z13 en una clase aparte. Correr un modelo de 120B en una tablet todavía se siente ligeramente absurdo, y nada más portátil se le acercaba en ese momento.
• Compatibilidad con Linux. Una vez que pasé de Windows 11 a Bazzite, todo encajó. El protocolo ASUS Aura HID funcionaba sobre hidraw, ROCm manejaba la iGPU, y las unidades de systemd reemplazaron cada proceso de fondo de Windows con algo más limpio.
• El factor de forma. Tablet en el sofá, escritorio en el dock, servidor headless detrás del monitor — todo la misma máquina, cambiando en segundos. El teclado folio era genuinamente bueno: recorrido completo, sin flexión.
• Rendimiento de la GPU. Cuarenta unidades de cómputo de RDNA 3.5 manejaban CAD, inferencia local, y juegos ligeros. Nunca se comportó como gráficos integrados.

Lo que no funcionó

• Temperaturas bajo carga sostenida. El chasis delgado tenía exactamente una estrategia para el calor: hacer girar los ventiladores más fuerte. Una ejecución larga de inferencia la convertía en una secadora de pelo, y el chasis se ponía incómodamente caliente al sostenerlo.
• Entrega de energía bajo carga combinada. La carga es USB-PD por los puertos Type-C. Bajo una ejecución pesada de CPU+GPU la plataforma podía consumir más de lo que el cargador estaba dispuesto a entregar, así que la batería iba goteando incluso enchufada — la máquina efectivamente se autocompletaba desde la batería para cubrir la diferencia.
• Duración de batería en Linux. Windows lograba de seis a ocho horas con el ajuste de firmware de ASUS. Linux conseguía de tres a cuatro en un buen día, y suspender/reanudar con un teclado desmontable era una fuente recurrente de irritación con udev.
• No reparable. La RAM está soldada y el chasis está sellado. El SSD M.2, accesible por una puertita en el soporte plegable, es la única parte reparable por el usuario en la máquina — que resultó ser justo lo que me salvó.

El proyecto del teclado RGB

Armoury Crate de ASUS — la única forma oficial de controlar el RGB del teclado y la barra de luz — no existe en Linux. Así que escribí el mío propio: un CLI en Python que habla directo con la interfaz Aura HID, un selector de color en GTK4, y un panel de navegador en localhost. Unos 40 KB en total, y sobrevivía a suspender, reiniciar, y desconectar el teclado — el trío que todas las demás herramientas RGB de Linux olvidan.

Se convirtió en una de las entradas más leídas de este sitio. Lee el artículo completo del teclado RGB →

Cómo terminó: una falla de alimentación

Alrededor del 19–20 de julio de 2026 el Z13 dejó de completar un arranque. Le dediqué dos días antes de concluir que no era reparable de mi parte. La falla es lo bastante específica como para merecer que se documente bien, porque «no enciende» es la frase menos útil en informática — y en este caso ni siquiera es precisa. Enciende sin problema. Simplemente se niega a quedarse despierta.

Los síntomas, en orden

1. El arranque se detiene en un logo estático de ROG. No el animado — un fotograma congelado. Nunca llega a un aviso de «presiona F2», nunca llega a la BIOS, nunca llega a un bootloader. Hasta dónde llegaba variaba entre intentos: a veces un panel apagado sin retroiluminación, a veces una pantalla negra encendida con los ventiladores corriendo, a veces el logo congelado.
2. El teclado folio está muerto en el arranque. La retroiluminación destella blanco al reiniciar, y después nada. F2, Esc y Supr nunca se registran. Esto coincide con una falla conocida en este modelo donde el controlador del teclado se queda atascado en modo bootloader.
3. No hay alimentación en el bus USB durante el POST. Conecté un teclado RGB externo mientras el logo estaba en pantalla: sin luces, sin energía. En esa etapa del POST el puerto debería estar activo. No lo estaba — lo cual indica que la gestión de rieles de energía del controlador integrado está atascada, no que falte el sistema operativo.
4. Un evento térmico. Encontré la máquina con la pantalla apagada, los ventiladores apagados, conectada a la corriente, y el chasis muy caliente. Esa combinación es la alarmante: el SoC estaba consumiendo energía en un estado colapsado sin nada controlando los ventiladores. Tras un enfriamiento forzado, la temperatura del chasis se estabilizó alrededor de los 96 °F con un ventilador externo encima — confirmando que el calor era la anomalía, no la base normal.
5. La pista reveladora: un LED de reposo bajo un fotograma congelado. Tras un reinicio del EC, el LED de encendido se asentó en un parpadeo lento — aproximadamente un segundo encendido, cinco segundos apagado. Según la propia especificación de indicadores de ASUS, ese patrón significa que la notebook está en modo de reposo. Una máquina no puede estar dormida y sostener al mismo tiempo un logo de POST en su pantalla. Esa contradicción es el diagnóstico.
6. Es reproducible. Un toque para despertarla ponía el LED en blanco sólido durante unos 30 segundos, y después volvía al parpadeo de reposo. Arranque en frío, despertar, arranque en frío: mismos 30 segundos, mismo resultado, cada vez.

Así que la secuencia es: el firmware se cuelga temprano en el POST, el controlador integrado deja caer la plataforma en Modern Standby por debajo del firmware colgado, y el controlador de pantalla se queda sosteniendo el último fotograma que se le dio. El logo congelado no es la máquina pensando. Es una imagen fija en una computadora dormida.

Lo que probé

• Reinicios forzados y reinicios estándar, repetidamente.
• Reinicio duro de EC/RTC en ambos sentidos — mantener presionado el botón de encendido 40 segundos con la corriente conectada, y de nuevo con la corriente desconectada y luego reconectada. En esta plataforma eso es eléctricamente equivalente a sacar la pila del CMOS.
• Desconexión total de periféricos: teclado separado, microSD fuera, cada cable USB-C y HDMI removido, arrancada como tablet desnuda.
• Una espera de 45 a 60 minutos sin tocarla después del reinicio, por si el reentrenamiento de los 128 GB de memoria o una cápsula de firmware pendiente necesitaban ese tiempo.
• Entrada a BIOS por el folio (muerto), por teclado USB externo (puerto sin energía), y por Volumen-abajo + encendido.
• Un enfriamiento completo, y después una nueva prueba en frío.

Me salté desconectar físicamente la pila del CMOS: la retención de 40 segundos ya realiza ese reinicio eléctricamente, y no repara un EC atascado ni una falla de entrega de energía. También me salté todo lo que fuera a nivel de sistema operativo, por la razón de abajo.

Lo que descarté, y cómo

Sospechoso	Veredicto	Por qué
Software / SO / parámetros del kernel	Exonerado	El cuelgue ocurre antes de que cargue cualquier bootloader. Nada en el disco se ejecuta en el punto de la falla, así que ninguna configuración en él puede ser la causa.
Dispositivo de arranque / SSD	Exonerado	Tanto el riel USB muerto como la firma de colapso-a-reposo están por encima de la capa de almacenamiento. El SSD se sacó después y está sano — está corriendo en la máquina de reemplazo.
Bloqueo térmico	Exonerado	La falla se reproduce en frío, a ~96 °F.
Batería agotada	Exonerado	El parpadeo es el pulso blanco de reposo, no el indicador naranja de batería baja.

No es solo mi unidad

Esta es una clase de falla documentada en este modelo, más que mala suerte con una sola placa. Hay un hilo activo en el foro de ROG que describe el mismo comportamiento en el GZ302EA — caídas repetidas de pantalla negra y cuelgues duros ligados a Modern Standby — y un reporte aparte, bien conocido, del controlador del teclado folio quedando atascado en modo bootloader en Linux. Ambos coinciden exactamente con lo que vi.

Si estás leyendo esto porque tu propio Z13 está detenido en un logo congelado: cronometra el intervalo antes de que el LED de encendido empiece su parpadeo lento. Si son unos 30 segundos, tienes esta falla, y ninguna cantidad de reinstalaciones va a ayudar.

Lo que en realidad compraron dos días de diagnóstico

No un arreglo. Lo que compró fue certeza — la diferencia entre «está roto, quizá hice algo» y saber exactamente qué capa falló y que ninguna cantidad de mi tiempo lo iba a mover. Cinco hechos sostienen eso:

• Un colapso reproducible hacia el reposo en unos 30 segundos, tanto desde arranque en frío como al despertar.
• Un LED de estado de reposo mostrado al mismo tiempo que un logo de POST congelado — un estado en el que una máquina sana no puede estar.
• Un evento térmico: chasis caliente, ventiladores apagados, conectada a corriente, en un estado colapsado.
• Sin alimentación en el bus USB durante el POST.
• Un hilo de defecto específico del modelo que describe un comportamiento idéntico en las unidades de otras personas.

Ese último fue el que más importó para cómo me sentí al respecto. Cuando una máquina muere hay un reflejo de auditarte a ti mismo — el parámetro de kernel que pusiste, la actualización que corriste, lo que dejaste compilando toda la noche. Encontrar la misma firma de 30 segundos descrita por desconocidos en el propio foro del fabricante resolvió esa duda, e hizo que detenerme fuera una decisión fácil en vez de una que me siguiera molestando.

Nunca presenté una reclamación de garantía. La unidad era de caja abierta, perseguirla habría significado semanas sin la máquina que de verdad necesitaba, y ya había pedido el reemplazo. Así que el Z13 está en un estante, sin su SSD, que salió por la puertita del soporte plegable y fue directo a la caja que la reemplazó. Esa puertita es la única pieza de diseño de esta máquina que rindió frutos justo al final.

Lo que le diría a cualquiera que use una tablet como servidor

No estoy enojado con el Z13. Hizo más de lo que cualquier tablet tendría derecho a hacer, y lo hizo durante cinco meses sin quejarse. Pero hay una lección real en la forma de esta falla, y no es «el hardware de consumo es malo».

Es que una máquina construida alrededor de una batería tiene una máquina de estados de gestión de energía diseñada para un dispositivo que se carga, se descarga, duerme y despierta. Correrla como servidor significa mantenerla en una esquina de esa máquina de estados — enchufada, caliente, nunca durmiendo — durante meses seguidos. Esa no es la carga de trabajo para la que se ajustó el firmware, y la falla que finalmente llegó fue una falla de gestión de energía, no una CPU rota ni un disco lleno.

La versión práctica: si una máquina va a ser infraestructura siempre encendida, prefiere una cuya historia de energía sea un conector cilíndrico y un ventilador. Y guarda tus datos en algún lugar que la muerte de la máquina no pueda llevarse consigo — la única razón por la que esta historia tiene un final ordenado es que el SSD estaba detrás de una puertita en vez de detrás de una soldadura.

Qué la reemplazó

El sucesor es un CHUWI AuBox Ai365 — un mini PC AMD pequeño con un Ryzen AI 9 365, doble 2.5 GbE, y un simple conector cilíndrico. Tiene 30 GB de memoria utilizable frente a los 128 GB del Z13, lo cual me costó el modelo local grande sin más; ese nivel ahora corre un MoE de 35B en vez de uno de 120B, y el trabajo pesado se mudó a una API barata en la nube. A cambio, no tiene batería, ni negociación USB-PD, ni Modern Standby en el cual colapsar.

Lee sobre la configuración del CHUWI AuBox Ai365 →