Comandos RyzenAdj: guía completa para dominar tu Ryzen Mobile

Si tienes un portátil con procesador AMD Ryzen y te gusta trastear con el rendimiento, seguramente hayas oído hablar de RyzenAdj y sus comandos. Esta pequeña herramienta en línea de comandos permite ajustar al detalle los límites de potencia, temperatura y corriente de la CPU, algo que puede marcar una diferencia enorme en temperaturas, ruido y rendimiento sostenido… pero también puede ser peligroso si no se usa con cabeza.

En las siguientes líneas vas a encontrar una explicación muy completa, en castellano de España, sobre qué es RyzenAdj, cómo funcionan sus parámetros principales y qué debes tener en cuenta al usarlo en Windows y Linux. También veremos algunos ejemplos reales de uso, problemas típicos (como cuando los ajustes “no se aplican”) y la relación con herramientas gráficas como Ryzen Controller o utilidades de terceros.

Qué es RyzenAdj y para qué sirve

RyzenAdj es una utilidad en modo consola pensada para modificar los parámetros de gestión de energía en procesadores Ryzen Mobile. Está basada en el proyecto FlyGoat/ryzen_nb_smu y se comunica con el SMU (System Management Unit) del chip para cambiar límites de potencia, temperatura y corriente que el firmware establece por defecto.

El propio desarrollador de varias interfaces gráficas (como Ryzen Controller) explica que su software usa exactamente el mismo ejecutable ryzenadj.exe como motor. De hecho, la conocida interfaz RyzenAdjUI_WPF dejó de mantenerse, y hoy se recomienda usar otras GUIs como Universal x86 Tuning Utility o el proyecto ryzen-controller-team/ryzen-controller para quienes no quieran lidiar con la consola.

La interfaz de comandos es idéntica en Windows y en sistemas tipo Unix (Linux, etc.), así que los mismos parámetros que uses en un sistema son válidos en el otro. Eso sí, siempre hay un requisito común: hay que ejecutarlo con permisos elevados, es decir, como administrador en Windows o como root en Linux.

Una característica clave es que RyzenAdj no se “instala” como tal: no necesita un gran sistema de configuración ni un servicio residente. Son los argumentos de la línea de comandos los que definen todos los ajustes que se aplican al vuelo. Precisamente por eso resulta muy fácil integrarlo en scripts, servicios de sistema o tareas programadas para automatizar el proceso.

Parámetros básicos y opciones de potencia en RyzenAdj

Uno de los temas que más interesan a los usuarios (y también al desarrollador de Ryzen Controller) es entender qué hace cada comando. La herramienta admite un conjunto amplio de opciones, muchas de ellas relacionadas con límites de potencia, tiempos de respuesta y límites de corriente para distintas partes del procesador.

En la documentación y en los hilos de desarrollo se mencionan de forma destacada los siguientes parámetros básicos (forma corta y larga):

• -a, –stapm-limit=<u32>: Establece el límite de potencia sostenida (STAMP o STAPM), en unidades de 10e-3 W. Es el valor que controla la potencia que el procesador puede mantener durante períodos largos.
• -b, –fast-limit=<u32>: Define el límite de potencia PPT rápida, también en 10e-3 W. Es el máximo de potencia que la CPU puede usar en ráfagas cortas, cuando se necesita un pico de rendimiento.
• -c, –slow-limit=<u32>: Marca el límite de potencia PPT lenta, igualmente en 10e-3 W. Suele complementar al límite rápido, suavizando la transición hacia un consumo más sostenido.
• -d, –slow-time=<u32>: Ajusta la constante de tiempo del PPT lento, expresada en milisegundos. Controla cuánto tiempo puede mantenerse ese nivel de potencia lenta antes de que el sistema vuelva a valores más contenidos.
• -e, –stapm-time=<u32>: Cambia la constante de tiempo STAPM (también en ms), que influye en la duración del límite de potencia sostenida antes de que se reduzca por motivos térmicos o energéticos.
• -f, –tctl-temp=<u32>: Fija la temperatura Tctl objetivo en grados Celsius. Es el umbral de temperatura que el procesador intentará no superar limitando potencia o frecuencia.
• -g, –vrm-current=<u32>: Establece el límite de corriente del VRM principal (en mA). Este valor influye en cuánta corriente puede suministrar la etapa de alimentación a la CPU.
• -j, –vrmsoc-current=<u32>: Define el límite de corriente del VRM del SoC (en mA), que afecta a la parte del chip encargada de gráficos integrados, controlador de memoria y lógica auxiliar.
• -k, –vrmmax-current=<u32>: Cambia el límite máximo de corriente del VRM (en mA). Es un tope superior que puede resultar arriesgado si se sube demasiado.
• -l, –vrmsocmax-current=<u32>: Ajusta el límite máximo de corriente del VRM del SoC (en mA), igualmente delicado si se manipula sin saber lo que se hace.
• -m, –psi0-current=<u32>: Controla el límite de corriente PSI0 (en mA), relacionado con los estados de ahorro de energía de la etapa de alimentación.
• -n, –psi0soc-current=<u32>: Configura el límite de corriente PSI0 del SoC (en mA), con una función similar aplicada a la parte SoC.

El desarrollador de Ryzen Controller comenta que algunas de estas opciones todavía no están implementadas en su GUI o no funcionan en todos los modelos de procesador, y que está interesado en añadirlas todas con descripciones claras. También indica que determinados parámetros pueden ser potencialmente peligrosos si se llevan al extremo, por lo que su idea es agruparlos en una pestaña tipo “modo avanzado” con advertencias bien visibles.

Si quieres, por ejemplo, fijar todos los límites de potencia en 45 W y una temperatura Tctl de 90 °C, el comando sería algo parecido a:

ryzenadj –stapm-limit=45000 –fast-limit=45000 –slow-limit=45000 –tctl-temp=90

Recuerda que las unidades de potencia están en milivatios (10e-3 W), así que 45000 equivale a 45 vatios de límite. Lo ideal es que cada usuario experimente con valores algo más conservadores al principio y vaya ajustando progresivamente.

Parámetros peligrosos y consideraciones de seguridad

La propia comunidad alrededor de RyzenAdj insiste en que no todos los comandos son igual de inocentes. Mientras que bajar límites de potencia y temperatura suele ser relativamente seguro (simplemente reduces el rendimiento máximo), elevar ciertos topes de corriente o permitir temperaturas muy altas puede tener consecuencias serias.

Los parámetros más delicados suelen ser los relacionados con límites máximos de corriente del VRM y del SoC (-g, -j, -k, -l, -m, -n). Subirlos sin control puede provocar que la etapa de alimentación trabaje más allá de lo que el fabricante tenía pensado, con riesgo de inestabilidad, apagones inesperados o, en casos extremos, daños a largo plazo.

Por eso algunas interfaces gráficas, como la de Ryzen Controller, valoran separar estos comandos en una sección especial etiquetada como “Control avanzado” o similar, donde el usuario tenga que aceptar advertencias claras antes de poder toquetear nada. Lo habitual es mostrar un aviso indicando que modificar estos parámetros puede anular garantías o acortar la vida útil del hardware.

Otro aspecto delicado es el uso de temperaturas objetivo demasiado agresivas. Aunque muchos portátiles Ryzen permiten llegar de fábrica a los 95-100 °C en cargas pesadas, establecer manualmente un Tctl extremadamente alto puede aumentar el riesgo de degradación, sobre todo si el sistema de refrigeración no está a la altura.

Desde el punto de vista práctico, lo más sensato es usar RyzenAdj sobre todo para reducir temperaturas y ruido, es decir, para bajar límites de potencia (STAPM, PPT rápido y lento) y fijar una temperatura Tctl algo más baja que la de serie. De esta forma se gana confort y estabilidad sin poner el equipo al límite.

Ejemplo real: bajar temperatura y ruido en un portátil Ryzen

En la comunidad se ha compartido un caso muy ilustrativo con un portátil Lenovo Yoga z16 equipado con un AMD Ryzen 7 6850H. El usuario comentaba que el equipo se ponía “bastante calentito” y que los ventiladores eran ruidosos cuando el procesador trabajaba a plena carga.

Su solución fue recurrir a RyzenAdj para establecer límites de potencia más contenidos y un techo térmico más razonable. Concretamente, ajustó:

• stapm_limit = 35000
• fast_limit = 35000
• slow_limit = 35000
• tctl_temp = 85

Es decir, fijó todos los límites de potencia relevantes en 35 W y estableció una temperatura máxima de 85 °C. Según explica, sin este ajuste el portátil alcanzaba con facilidad los 100 °C en ciertas cargas, mientras que con RyzenAdj se mantenía bastante por debajo.

Este cambio convirtió efectivamente al 6850H en algo muy parecido a un 6850U, ya que ambos chips son prácticamente idénticos a nivel de silicio, pero la serie H viene configurada para consumir más potencia de fábrica. El resultado fue una reducción notable del ruido, una carcasa menos caliente y, lo más interesante, ausencia de thermal throttling (limitación térmica) durante pruebas de estrés.

En pruebas comparativas frente a otro portátil (un ThinkPad T14 Gen 3 con Ryzen 6850U), ambos acababan moviéndose en un rango de 79-85 °C a plena carga, pero el Yoga z16 lograba mantener frecuencias de reloj algo más altas gracias a su sistema de refrigeración más robusto.

Para tener una referencia del impacto en benchmarks sintéticos, el usuario ejecutó PC Mark 10 en Windows 11 con el perfil de energía en “Mejor rendimiento” y obtuvo algo como esto:

• Antes de usar RyzenAdj: 6280 puntos
• Después de aplicar los nuevos límites con RyzenAdj: 6032 puntos
• T14 Gen 3 AMD (6850U): 6060 puntos (dato tomado de Notebookcheck)

Es decir, se pierde una pequeña cantidad de rendimiento máximo en favor de temperaturas y ruido mucho más contenidos. A cambio, la experiencia diaria resulta más agradable, y el equipo deja de funcionar al límite térmico de forma constante.

Un efecto curioso que comenta el usuario es que, en Fedora 38, puede mantener el perfil de energía del sistema en modo “ahorro de energía” y aun así disfrutar de frecuencias de reloj estables. Además, el comportamiento del ventilador se vuelve menos agresivo, lo que hace que el portátil sea incluso más silencioso que el T14 en las mismas cargas.

Cómo automatizar RyzenAdj en Linux

En Linux, una de las grandes ventajas de RyzenAdj es que se integra muy bien con scripts, servicios systemd y archivos de inicio como .xinitrc. Hay varias formas de conseguir que los ajustes se apliquen automáticamente en cada arranque, reanudación desde suspensión o inicio de sesión gráfica.

Un ejemplo práctico muy interesante lo aporta el mismo usuario del Yoga z16, que creó un servicio systemd personalizado para asegurarse de que RyzenAdj se ejecuta con los parámetros deseados después de cada arranque o salida de suspensión. El archivo de servicio tiene un aspecto similar a este:

Description=Servicio que mantiene ryzenadj en ejecución con los parámetros deseados
After=multi-user.target sleep.target suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target


WantedBy=multi-user.target sleep.target suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target


Type=exec
ExecStart=/usr/local/bin/ryzenadj --stapm-limit=35000 --fast-limit=35000 --slow-limit=35000 --tctl-temp=85
User=root
WorkingDirectory=/home/tcupsf/ryzenadj
Restart=always
RestartSec=60
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=%n

Con este enfoque, el servicio arranca siempre como root, lanza RyzenAdj con los parámetros indicados y, en caso de fallo, systemd intenta reiniciarlo cada 60 segundos. Además, está configurado para activarse no solo en el arranque normal (multi-user.target), sino también después de eventos de suspensión o hibernación, cuando algunos portátiles pueden “olvidar” los ajustes previos.

Otro caso que aparece en la comunidad es el de un usuario de Archcraft (una distribución basada en Arch) con un portátil Lenovo S540 13ARE (Ryzen 7 4800U) que quería ejecutar RyzenAdj automáticamente desde el archivo .xinitrc. Él ya había conseguido lanzar correctamente el daemon de ibus (ibus-daemon) añadiendo el comando en ese archivo, pero al intentar hacer lo mismo con “ryzenadj <parámetros>” los cambios no surtían efecto.

En estas situaciones suele haber dos posibilidades: o bien el comando no se ejecuta realmente con permisos de root (lo cual es obligatorio para que RyzenAdj pueda modificar el espacio de configuración del NB), o bien otros mecanismos de gestión de energía del sistema sobrescriben los ajustes poco después de aplicarlos.

Por eso, para asegurar un funcionamiento fiable en Linux, se recomienda usar servicios systemd en lugar de depender solamente de .xinitrc, y comprobar además que no hay perfiles de ahorro de energía, demonios de firmware del fabricante o configuraciones del kernel que anulen los cambios.

Automatizar RyzenAdj en Windows con scripts y tareas programadas

En Windows el planteamiento es parecido, pero en lugar de systemd se recurre al Programador de tareas y a scripts de PowerShell o archivos .bat. Los desarrolladores de RyzenAdj ofrecen incluso algunos ejemplos de automatización que se pueden adaptar con relativa facilidad.

La idea general pasa por seguir unos pasos como estos:

1. Preparar los argumentos de RyzenAdj que vayas a usar tras tus pruebas iniciales (por ejemplo, límites de potencia concretos y temperatura Tctl objetivo).
2. Copiar el contenido de la carpeta de RyzenAdj a una ubicación definitiva en tu sistema, donde vayas a mantener el ejecutable y los scripts.
3. Editar el script readjustService.ps1 (PowerShell) para incluir tu comando concreto de RyzenAdj con los parámetros elegidos, y probarlo manualmente en una consola con privilegios de administrador hasta asegurarte de que funciona según lo esperado.
4. Instalar el script como tarea programada usando el archivo installServiceTask.bat, que lo registrará en el Programador de tareas con la configuración adecuada.

En cualquier momento puedes revertir este proceso usando uninstallServiceTask.bat, que elimina la tarea asociada a RyzenAdj. Dentro del Programador de tareas, la entrada suele aparecer bajo la carpeta AMD con el nombre “RyzenAdj”, y desde ahí se puede comprobar si se está ejecutando correctamente.

Este enfoque permite que los límites de potencia y temperatura se apliquen automáticamente tanto en el arranque del sistema como en el inicio de sesión del usuario, sin necesidad de repetir el comando a mano cada vez.

Es importante recordar que, según comentan los propios desarrolladores, algunos ajustes de RyzenAdj pueden ser sobrescritos por las funciones de gestión de energía del dispositivo. En esos casos, la automatización es esencial para ir reestableciendo periódicamente los valores deseados.

Requisitos técnicos, compilación y backends de acceso

RyzenAdj necesita acceso de bajo nivel al espacio de configuración del Northbridge (NB) del procesador. Para lograrlo, en Linux se apoya en uno de estos dos métodos: el uso de la biblioteca libpci con acceso a /dev/mem, o el uso del módulo de kernel ryzen_smu. La herramienta intenta primero comunicarse mediante ryzen_smu y, si no encuentra un driver compatible, recurre como alternativa a /dev/mem.

La versión mínima de ryzen_smu soportada por RyzenAdj es la 0.1.7. Si ninguno de los backends está disponible (ni libpci con /dev/mem ni el módulo ryzen_smu), la inicialización de la herramienta falla y no se pueden aplicar los comandos.

En relación con /dev/mem, los desarrolladores advierten que su acceso puede estar restringido por motivos de seguridad en la configuración del kernel. Por ello, es recomendable revisar la documentación de tu distribución y, si es necesario, ajustar parámetros del kernel o recurrir a ryzen_smu para evitar problemas.

Antes de compilar, también es necesario asegurarse de que está instalada la dependencia libpci. En sistemas basados en Debian (Ubuntu, etc.), esto se resuelve instalando el paquete pcilib-dev o similar. En Fedora, Arch o OpenSUSE Tumbleweed existen paquetes equivalentes, y en algunos casos puede ser necesario agregar a los parámetros de arranque del kernel la opción iomem=relaxed para evitar errores de acceso en tiempo de ejecución.

La compilación en Linux no tiene demasiado misterio si ya dispones de compiladores C y C++ y de cmake. La forma más simple suele ser crear un directorio de compilación, ejecutar cmake apuntando al código fuente de RyzenAdj y luego compilar con make. Dado que es tan sencillo, los autores no ofrecen paquetes precompilados para cada distribución, sino que remiten a las instrucciones de build.

En cuanto a Windows, RyzenAdj puede construirse de manera prácticamente automática con Visual Studio + MSVC o, en línea de comandos, usando Clang + Nmake. Sin embargo, se ha reportado que, al menos de momento, MingW-gcc no funciona correctamente para compilar este proyecto.

El ejecutable requiere algunas DLL y un driver sys que se incluyen en el directorio ./win32 del árbol de código fuente. Para que todo funcione, hay que colocar tanto la biblioteca DLL como el driver del sistema en el mismo directorio que ryzenadj.exe. Dado que la configuración del entorno de desarrollo en Windows puede ser bastante engorrosa, los propios autores desaconsejan al usuario medio compilarlo manualmente y recomiendan usar directamente las versiones ya empaquetadas o, si se quiere integrar funcionalidad en un programa propio, revisar el proyecto libryzenadj.

Uso de ryzen_smu, secure boot y módulos de kernel

Si quieres que RyzenAdj se comunique con el procesador a través del módulo de kernel ryzen_smu, primero hay que instalarlo, ya que no forma parte del kernel estándar de Linux. En Fedora, por ejemplo, suele hacerse mediante paquetes que integran dkms para recompilar el módulo cuando se actualiza el kernel.

El proceso típico consiste en clonar el repositorio de ryzen_smu, compilar el módulo e instalarlo. Si en tu sistema está activo el Secure Boot, hay un paso adicional: tendrás que inscribir las claves UEFI generadas por dkms en la base de datos de claves de tu firmware (MOK, Machine Owner Key). Esto se hace con una herramienta que te pide establecer una contraseña, que posteriormente introducirás una única vez en el gestor MOK durante el siguiente arranque.

Tras reiniciar, el sistema arrancará el gestor MOK, donde tendrás que elegir la opción “Enroll MOK”, introducir la contraseña que elegiste y reiniciar de nuevo. Una vez completado el proceso, el módulo ryzen_smu debería cargar sin problemas, aunque el kernel indicará que ha sido “tainted” por la carga de un componente potencialmente propietario o no oficial.

Al cargar correctamente, el módulo será visible en dmesg y permitirá a RyzenAdj operar usando este backend en lugar de recurrir a /dev/mem. Esta suele ser la opción preferible desde el punto de vista de estabilidad y compatibilidad con las políticas de seguridad de las distribuciones modernas.

Por último, hay que tener presente que algunas distribuciones no incluyen aún paquetes directos para ryzen_smu. En esos casos, una alternativa es usar herramientas como Distrobox o Toolbox para encapsular una distribución compatible dentro de tu entorno actual y compilar allí todo lo necesario.

Problemas frecuentes y casos en los que RyzenAdj no aplica cambios

Un tema recurrente en los foros y sistemas de seguimiento de incidencias de Ryzen Controller es que, en algunos equipos, los cambios de RyzenAdj parecen no surtir efecto o se aplican de forma errática. Un ejemplo concreto es el de un usuario con un HP ENVY x360 Convertible 13-ag0xx con Ryzen 5 2500U.

Este usuario comenta que, tras descargar el controlador y guardar una configuración personalizada en la GUI, el portátil seguía limitado a 10 W de potencia. En algunos intentos, el programa mostraba el mensaje “Ryzenadj has been executed successfully” cuando pulsaba en “Apply”, pero en otras ocasiones el texto cambiaba a “Unable to apply ryzenadj”. En la práctica, el comportamiento de la máquina no variaba y el límite de 10 W seguía ahí.

Detrás de este tipo de problemas suelen encontrarse varios factores: desde bloqueos específicos en la BIOS del fabricante, pasando por versiones de firmware que no permiten modificaciones agresivas, hasta configuraciones de ahorro de energía muy estrictas que se imponen sobre cualquier cambio externo.

También es posible que, en ciertos modelos antiguos o poco documentados, algunos comandos de RyzenAdj no estén implementados o no encuentren los registros adecuados en el SMU. El propio desarrollador reconoce que hay opciones que todavía no funcionan en todos los procesadores o que no han sido totalmente mapeadas.

En estos casos, la recomendación pasa por:

• Verificar siempre la ejecución con permisos de administrador o root, tanto en Windows como en Linux.
• Probar primero los comandos desde la línea de comandos pura (sin GUI) para ver los mensajes de error exactos o la ausencia de ellos.
• Revisar foros y repositorios para comprobar si tu modelo concreto de portátil está reportado como problemático o limitado.
• Evitar confiar en que todos los sliders de una GUI funcionen en tu hardware, ya que la interfaz puede exponer parámetros que tu procesador o tu firmware no soportan realmente.

Si, tras todas estas comprobaciones, RyzenAdj sigue sin modificar el comportamiento de tu máquina, lo más probable es que el fabricante haya implementado restricciones firmes en la BIOS o el EC (Embedded Controller) y que, por tanto, no sea posible saltárselas sin modificaciones de firmware mucho más profundas y arriesgadas.

Relación con Ryzen Master y otras herramientas de AMD

Aunque RyzenAdj se centra en procesadores móviles y se usa mucho en portátiles con Linux o Windows, no hay que confundirlo con AMD Ryzen Master, la utilidad oficial de AMD para ajustar parámetros de las CPU de escritorio (y algunos equipos preconfigurados). Ryzen Master ofrece una interfaz gráfica bastante elaborada y una sección de “Rendimiento personalizado” muy completa.

En esa sección de ajustes, Ryzen Master permite crear múltiples perfiles personalizados donde se pueden almacenar configuraciones de la CPU Ryzen, de las GPU Radeon integradas y de la memoria DDR5. El usuario puede controlar qué núcleos permanecen activos, a qué frecuencia funcionan los gráficos integrados y qué latencias usa la memoria, entre muchas otras cosas.

La filosofía es parecida a la de RyzenAdj en el sentido de que se busca optimizar el rendimiento global y adaptar el comportamiento del sistema a las necesidades de cada aplicación. Sin embargo, mientras que RyzenAdj ataca directamente límites de potencia y temperatura a nivel de SMU en portátiles, Ryzen Master está más orientado a overclocking, undervolting y tuning fino de plataformas de escritorio.

Si el usuario no quiere complicarse creando perfiles propios, Ryzen Master ofrece un espacio de trabajo desde el que se pueden ver y modificar al vuelo los valores actuales del sistema. En cambio, RyzenAdj obliga a pensar en parámetros concretos y a escribirlos en forma de argumentos de consola o scripts, lo que lo hace más potente para automatizar, pero menos amistoso a primera vista.

Aun así, para equipos portátiles con procesadores Ryzen modernos, RyzenAdj y las GUIs que lo envuelven (como Ryzen Controller) siguen siendo, a día de hoy, una de las pocas formas de romper las limitaciones de fábrica impuestas en firmware, lograr menos ruido, menos calor o incluso rascar algo más de rendimiento sostenido en determinadas cargas.

Vista toda la información anterior, se entiende por qué tantos desarrolladores y entusiastas se han volcado en pulir las descripciones de comandos, automatización y compatibilidad de RyzenAdj. Bien empleado, este conjunto de herramientas permite adaptar muy bien el comportamiento de un portátil Ryzen a lo que cada usuario necesita: desde quien quiere un equipo silencioso que no pase de 80 y pico grados, hasta quien busca aprovechar al máximo el margen térmico sin depender solo de los valores conservadores definidos por el fabricante.