Linux 7.2 vs 7.3 en AMD Ryzen AI Max+ 395 Strix Halo: qué mejora y qué no

septiembre 23, 2026 Alfonso Moreno | Sysadmin Senior 40 Visitas 9 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué este benchmark sí importa para los sysadmins

Si te manejas con un Framework Desktop, un mini-PC con chip Strix Halo, o simplemente quieres saber qué versión del kernel le saca más jugo a tu próximo homelab, este artículo te interesa. Michael Larabel de Phoronix publicó el 22 de septiembre de 2026 una comparativa muy puntual: misma máquina (Ryzen AI Max+ 395 “Strix Halo”), Ubuntu 26.10, dos kernels consecutivos (Linux 7.2 y Linux 7.3). El delta no fue dramático en la mayoría de los tests, pero aparecieron mejoras muy concretas en NUMA, memoria, latencia de red y compilación del kernel que vale la pena entender.

El contexto: Canonical ya tenía a Ubuntu 26.10 funcionando con Linux 7.2 en su rama diaria y, días antes del artículo, terminó migrando a Linux 7.3 como kernel de cara al release de octubre. Lo que Larabel midió es justamente ese cambio de última hora. La pregunta no es “¿gana 7.3?”, sino “¿dónde gana 7.3 y por qué a tu servidor o workstation le puede convenir el upgrade?”

El setup exacto: misma máquina, mismo OS, dos kernels

El benchmark se hizo sobre el Framework Desktop con un AMD Ryzen AI Max+ 395 (Strix Halo, 16 núcleos / 32 hilos, 64 GB de RAM unificada) y gráficos integrados Radeon 8060S. El sistema operativo fue Ubuntu 26.10 con su daily build inicial en Linux 7.2, y el mismo Ubuntu 26.10 después del switch a Linux 7.3 Git. Sin tocar nada más, ningún cambio de configuración. Eso es importante: cualquier diferencia viene del kernel, no de firmware, ni de drivers propietarios, ni de versiones de userland.

El otro detalle relevante es que el salto se mide contra Ubuntu 26.04 LTS con Linux 7.0 — el estado base de la LTS anterior. Ya en 7.2 había uplift visible sobre 7.0; lo que Phoronix buscó en 7.3 es si había mejoras adicionales o si el trabajo se había estabilizado.

Lo que mejoró en Linux 7.3 sobre Strix Halo

Categoría	Benchmark	Sentido del cambio
Memoria / NUMA	Stress-NG NUMA, MEMFD, CPU Cache, Mutex, Socket Activity	Mejora clara a favor de 7.3
Conmutación	ctx_clock (Context Switch Time)	Mejora en 7.3
Red	Ethr TCP Latency (32 threads)	Latencia ligeramente menor en 7.3
Compilación	Timed Linux Kernel Compilation (defconfig)	Más rápido en 7.3
Video	uvg266 Bosphorus 4K Ultra Fast, x265 Bosphorus 4K	Más rápido en 7.3
LLM local	llama.cpp Vulkan Qwen3.5-9B Q8 prompt processing 2048	Mejora en 7.3
Gaming ligero	DDraceNetwork (Vulkan)	Ligera mejora en 7.3

El patrón es claro: las mejoras de 7.3 sobre hardware con coherencia de memoria unificada (como Strix Halo) están en el stack de memoria, scheduling y scheduler, no en gráficos puros. Es exactamente el lado del kernel donde los parches de 7.3 apuntaban: el rework de x86/mm para reducir latencia y dos optimizaciones muy fuertes en memory management, ambos anunciados por Linus en el merge window.

Lo que NO mejoró (y por qué no te debería frustrar)

Los tests de gráficos puros (GravityMark Vulkan y Vulkan ray-tracing) salieron a favor de 7.2 — sí, ley bien, 7.2 fue más rápido en rendering Vulkan puro. ClickHouse 100M Rows Hits también quedó mejor con 7.2. NAMD STMV (molecular dynamics, 1.066.628 átomos) también ganó en 7.2. Y llama.cpp CPU BLAS con gpt-oss-20B Q8 también se inclinó por 7.2.

¿Eso significa que 7.3 es peor? No. Significa que en cargas con un patrón muy específico (rendering GPU puro, ciertas queries OLAP, simulaciones con NUMA locality neutra, inferencia CPU pura), el cambio de 7.2 → 7.3 no es neutro ni negativo, pero tampoco es ganancia. En esos workloads concretos el usuario debería quedarse en 7.2 o evaluar si los beneficios en otra parte justifican el cambio.

Lo que dice Phoronix y cómo leerlo

La conclusión textual del artículo: “Across dozens of other real-world workloads ultimately tested though, Linux 7.3 wasn’t yielding much of a difference on this AMD Ryzen AI Max+ desktop compared to Linux 7.2. But Linux 7.2 already was showing off quite well on Ubuntu 26.10 relative to Ubuntu 26.04 LTS on its Linux 7.0 kernel.” O sea: no hay un uplift dramático, pero el piso que ya daba 7.2 sobre la LTS anterior era alto. 7.3 se mueve marginalmente y trae features que no se reflejan en micro-benchmarks de rendimiento bruto.

Esto encaja con el comentario de Linus Torvalds en el anuncio de 7.3-rc1: el kernel está más pesado que versiones previas en parte por el churn de parches generados con ayuda de AI/LLM coding agents. El árbol de fuentes roza las 41 millones de líneas. Más código no siempre significa más velocidad en cada benchmark, sí significa más superficie para que los workloads reales se beneficien a largo plazo.

Cómo verificarlo tú mismo en tu propio Strix Halo

Si tienes un Framework Desktop o un mini-PC con Strix Halo y quieres reproducir (o contradecir) los resultados, el camino es directo con Phoronix Test Suite:

sudo apt install phoronix-test-suite
phoronix-test-suite benchmark 
  pts/stress-ng pts/ctx-clock pts/llama-cpp pts/x265 
  --force-compile  --user-tests-environment

Esto te deja un baseline reproducible. Para comparar 7.2 contra 7.3 en la misma máquina, primero corré la suite en Ubuntu 26.10 con el daily build de 7.2, después actualizá al kernel 7.3 y volvé a correr:

sudo apt install --install-recommends linux-generic-7.3
sudo reboot
uname -r   # confirma 7.3.x

Importante: usa exactamente el mismo governor de CPU y el mismo perfil de energía entre ambas corridas. Para Strix Halo es común que el boost behaviour difiera entre kernels y eso enmascara la señal real.

Qué viene en Linux 7.3 que no se ve en este benchmark

Aunque el uplift bruto en Strix Halo fue modesto, las features nuevas en 7.3 sí son jugosas para usuarios de hardware AMD reciente. El nuevo driver Ryzen AI Halo LED/RGB es el más visible (iluminación configurable del enclosure), y la enablement de Zen 6 sigue avanzando en el lado cliente. Para quien usa KSMBD como servidor de archivos, la compatibilidad con Apple Time Machine es una adición concreta — antes había que correr Netatalk; ahora KSMBD lo soporta nativamente. Si tienes un ThinkPad con USB-C Security, el driver ACPI ya lo entiende. Y para gaming en hardware con poca VRAM (8 GB o menos), las mejoras de gestión de vRAM en el DRM son las que más se van a sentir en frame pacing y mínimos de FPS.

También entra el soporte inicial de Apple M3 Pro/Max/Ultra (sin GPU todavía), el driver para el Steam Controller 2026, IBM Power12 enablement, y la subida de Intel Xe3P Nova Lake a “estable / enabled by default”. Si estás laburando con cualquiera de estos hardwares a corto plazo, 7.3 te abre puertas que 7.2 no te abría.

¿Vale la pena actualizar de Ubuntu 26.04 LTS a 26.10 para esto?

Depende. Si tu uso principal de la máquina Strix Halo es workstation con cargas NUMA-heavy, compilación de kernel, encoding de video o inferencia LLM local con llama.cpp Vulkan, sí: vas a ver mejoras pequeñas pero consistentes, y encima tienes las features nuevas. Si tu uso es gaming puro o rendering GPU, la respuesta es más tibia — 7.2 ganaba en esos benchmarks puntuales, y la diferencia puede no justificar el salto de LTS a no-LTS.

La estrategia pragmática es: mantenerte en 26.04 LTS hasta agosto 2026 (cuando salió 26.04.1 con HWE 7.0), o saltar a 26.10 solo si necesitas alguna feature específica de 7.3 (Time Machine sobre KSMBD, driver RGB, soporte Xe3P). Para el sysadmin promedio con Strix Halo como homelab, lo correcto es quedarse en LTS y dejar que el HWE traiga el kernel nuevo cuando esté estable.

Troubleshooting común al cambiar de kernel en Strix Halo

Hay dos cosas que típicamente rompen al subir de 7.2 a 7.3 en hardware AMD reciente. La primera es el driver de GPU: si tienes el stack amdgpu-pro instalado, asegurate de que la versión sea compatible con 7.3 antes de reiniciar, sino te quedás sin escritorio. La segunda es el driver de plataforma: el k10temp para EPYC Zen 5 ahora expone per-CCD temperature monitoring, así que si tienes scripts de lm-sensors basados en el formato anterior, hay que adaptarlos:

sudo sensors-detect
sensors | grep -i 'k10temp-pci-'
# k10temp-pci-1d20 ... tctl: +45.0°C
# k10temp-pci-1d20 ... tccd1: +44.5°C   <- nuevo en 7.3

Si ves que tccd1 no aparece, es probable que el módulo k10temp no haya cargado la nueva lógica. Forzá la recarga y revisa dmesg:

sudo modprobe -r k10temp
sudo modprobe k10temp
sudo dmesg | grep -i k10temp

Si sigues sin tccd1, lo más probable es que tu BIOS no exponga los registros correctos. Es un bug de firmware, no de kernel, y la única solución real es esperar un BIOS update del fabricante.

Conclusión: pequeño delta, pero vale la prueba

Linux 7.3 sobre Strix Halo no es la clase de salto que te cambia la vida, pero sí trae mejoras reales donde el hardware Strix Halo más lo aprovecha: NUMA, memoria, latencia de red, encoding de video y compilación. Si ya estás en Ubuntu 26.10 con 7.2, la actualización a 7.3 es segura y razonablemente rápida. Si estás en 26.04 LTS con 7.0, el delta real ya lo diste al subir a 7.2 — quedarte ahí te da la LTS hasta que el HWE te traiga 7.4 o superior.

Para los curiosos: la suite de Phoronix Test Suite te lleva dos horas como mucho en una máquina Strix Halo, y te deja evidencia reproducible de qué versión del kernel le conviene a tu workload específico. Más rápido que confiar en benchmarks ajenos.

Preguntas frecuentes

¿Por qué Linux 7.2 vs 7.3 en AMD Ryzen AI Max+ 395 Strix Halo: qué mejora y qué no es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Linux 7.2 vs 7.3 en?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Linux 7.2 vs 7.3 en?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Linux 7.2 vs 7.3 en y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Linux 7.2 vs 7.3 en?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.