Beelink SER9 Pro para IA local y agentes: pruebas con OpenClaw

[jonatan]

Beelink SER9 Pro para IA local y agentes

Vídeo relacionado: https://youtu.be/xHpK2HJDSxw

El Beelink SER9 Pro puede ejecutar modelos locales y usarse con agentes como OpenClaw, pero la conclusión práctica no depende solo de tokens/s. Para un usuario normal importa sobre todo esto: si la tarea se completa, cuánto tarda y si la combinación se puede instalar y mantener sin pelearse demasiado.

Lectura actual: para empezar, la ruta más clara sigue siendo OpenClaw + Ollama ROCm + Qwen3.5 9B. Funciona bien para lectura, búsquedas, pequeñas tareas de código y acciones sencillas sobre Home Assistant. Hermes también puede conectarse a Ollama ROCm y completar algunas tareas, pero en esta batería queda por detrás de OpenClaw: tarda más, se atasca más con contexto largo y falla más cuando tiene que crear artefactos o razonar sobre muchos datos de Home Assistant.

Índice

• Entorno de pruebas
• Cómo funciona la pila
• Qué mide cada tarea
• Qwen3.5 9B + OpenClaw + Ollama ROCm
• Qwen3.5 9B + OpenClaw + FastFlowLM NPU
• Qwen3-Coder 30B A3B + OpenClaw + Ollama ROCm
• GLM-4.7-Flash Q4_K_M + OpenClaw + Ollama ROCm
• Gemma4 26B A4B Q4 + OpenClaw + Ollama ROCm
• Qwen3.6 27B IQ4 (batiai) + OpenClaw + Ollama ROCm
• Paperless-ngx con documentos reales
• Proxmox: auditoría de seguridad con OpenClaw
• Programación: agenda en Quarkus
• Programación: agenda en Quarkus con Qwen3.6
• Dashboard local para monitorizar OpenClaw
• Programación sencilla con modelos candidatos
• Hermes + Qwen3-Coder 14B 64K + Ollama ROCm
• Comparativa directa: OpenClaw vs Hermes con Qwen3.5 9B
• Pruebas de contexto largo con OpenClaw
• Respuesta a @e270889o sobre contexto largo
• Te interesa probarlo?

Entorno de pruebas

Estas pruebas se han hecho siempre sobre el mismo equipo y con los modelos ejecutándose en contenedores LXC separados dentro de Proxmox. Las versiones importan: un cambio de Ollama, ROCm, Vulkan o del propio modelo puede cambiar los tiempos y también la capacidad de usar herramientas.

Categoría	Configuración usada
Equipo	Beelink SER9 Pro, hardware AZW SER9, BIOS SER9T407.
CPU	AMD Ryzen AI 9 HX PRO 370, 12 núcleos / 24 hilos.
GPU	AMD Radeon 890M integrada. Es la GPU usada para las pruebas con ROCm y Vulkan.
NPU	AMD Strix/Krackan/Strix Halo NPU detectada. No se usa en la recomendación final con OpenClaw.
Memoria	27 GiB visibles para Proxmox durante las pruebas, con memoria compartida con la iGPU.
Almacenamiento	NVMe Crucial CT1000E100SSD8 de 1 TB.
Host	Proxmox VE 9.1.0 / pve-manager 9.1.9 sobre Debian 13 trixie.
Kernel	Linux 7.0.0-3-pve.
Contenedores LXC	Ubuntu 24.04.4 LTS. LXC 6.0.5-4 y lxcfs 6.0.4-pve1.
OpenClaw	OpenClaw 2026.5.7 (eeef486).
Ollama ROCm	Ollama 0.23.2 con librerías ROCm incluidas en Ollama: HIP/HSA/rocBLAS 7.2.70201.
llama.cpp Vulkan	llama.cpp commit f9cd456, build del 2026-05-08. Vulkan RADV/Mesa 25.2.8, API 1.4.318.
Lemonade Vulkan	Lemonade 10.4.0 sobre Vulkan/RADV/Mesa 25.2.8.
Estado de paquetes	Sin actualizaciones pendientes al comprobar host, LXC de Ollama y LXC de OpenClaw.

Cómo funciona la pila

Una forma sencilla de entender las pruebas es separar las capas. El modelo es lo que razona y genera texto. El motor es el programa que ejecuta ese modelo. El backend de aceleración es la tecnología que usa el motor para hablar con la GPU, NPU o CPU. El hardware es la máquina física.

Modelo IA
  ↓
Motor: Ollama / llama.cpp / Lemonade / LM Studio
  ↓
Backend de aceleración: ROCm / Vulkan / CUDA / Metal / DirectML / OpenCL
  ↓
Hardware: GPU AMD / GPU NVIDIA / Apple Silicon / NPU / CPU

En esta review estamos comparando principalmente motor, backend y modelo sobre el mismo equipo. Por eso no basta con decir que un modelo genera rápido: también tiene que usar herramientas, aguantar contexto y resolver la tarea.

Qué mide cada tarea

Tarea	En qué se basa	Dificultad
A0 Bugfix guiado	Encontrar y corregir un bug pequeño en Python, editar el archivo y ejecutar una comprobación básica.	Baja-media
A1 Contexto largo 20k	Procesar un contexto grande, parecido al historial de un agente, y extraer la instrucción relevante.	Media-alta
A2 Noticias IA del día	Buscar información actual, seleccionar fuentes y resumir los resultados en una tabla legible.	Media
A3 Informe / PDF	Leer datos, hacer cálculos, escribir un informe y generar un PDF verificable.	Alta
A4 Refactor multiarchivo	Entender varios archivos relacionados, modificar varias piezas y comprobar que todo sigue funcionando.	Muy alta
A5 Conectar con Home Assistant	Usar la API local de Home Assistant, contar entidades y devolver un resumen básico sin exponer credenciales.	Media
A6 Listar automatizaciones	Leer automatizaciones reales, agruparlas por estado y devolver ejemplos útiles.	Media
A7 Diagnosticar entidades problemáticas	Encontrar entidades en estado unavailable o unknown, agruparlas por dominio y dar ejemplos accionables.	Media-alta
A8 Crear informe local de Home Assistant	Leer estados, generar un JSON y un Markdown local, y verificar que los archivos existen y parsean bien.	Alta
A9 Sugerir automatizaciones	Leer entidades, dispositivos, áreas y automatizaciones para proponer ideas útiles sin modificar nada.	Alta
A10 Apagar luces de la oficina	Identificar las luces correctas, llamar al servicio de Home Assistant y verificar el estado después.	Alta
A11 Crear automatización real	Crear una automatización real en Home Assistant, dejarla desactivada y verificar que existe.	Muy alta

Qwen3.5 9B + OpenClaw + Ollama ROCm

Tarea	Resultado	Tiempo	Lectura rápida
A0 Bugfix guiado		1m 59s	Corrigió el bug guiado y dejó los tests pasando.
A1 Contexto largo 20k		1m 56s	Manejó el contexto largo y aplicó la instrucción correcta.
A2 Noticias IA del día		2m 10s	Usó búsqueda y devolvió noticias resumidas con enlaces.
A3 Informe / PDF		7m 07s	Generó el informe y el PDF verificable.
A4 Refactor multiarchivo		18m 45s	Resolvió el refactor multiarchivo, aunque fue la tarea más larga.
A5 Conectar con Home Assistant		1m 08s	Conectó con Home Assistant y resumió entidades y estados.
A6 Listar automatizaciones		3m 37s	Listó automatizaciones reales con sus estados.
A7 Diagnosticar entidades problemáticas		1m 26s	Diagnosticó entidades problemáticas y dio ejemplos útiles.
A8 Crear informe local de Home Assistant		5m 10s	Creó el informe local, pero quedó como resultado parcial.
A9 Sugerir automatizaciones		10m 01s	No consiguió cerrar bien las sugerencias de automatizaciones.
A10 Apagar luces de la oficina		2m 15s	Apagó luces de la oficina y verificó el estado después.
A11 Crear automatización real		10m 01s	No creó una automatización real verificable.

Lectura rápida: Qwen3.5 9B sigue siendo la opción más equilibrada para empezar con OpenClaw en el SER9 Pro. No completa todas las tareas, pero es el modelo que mejor combina instalación sencilla, velocidad razonable y más tareas reales completadas.

Qwen3.5 9B + OpenClaw + FastFlowLM NPU

FastFlowLM permite usar la NPU del SER9 Pro y OpenClaw llegó a usar herramientas reales, pero la experiencia no queda al nivel de Ollama ROCm. Funciona en tareas pequeñas de código y contexto, pero se atasca mucho más con Home Assistant y con artefactos.

Tarea	Resultado	Tiempo	Lectura rápida
A0 - Bugfix guiado		1m 54s	Corrigió el bug guiado y dejó los tests pasando usando herramientas reales.
A1 - Contexto largo 20k		1m 57s	Encontró la instrucción dentro del contexto largo y aplicó la política correcta.
A2 - Noticias IA del día		2m 15s	Usó búsqueda web, pero no encontró 5 noticias específicas de IA del día; devolvió resultados demasiado genéricos.
A3 - Informe / PDF		10m 31s	No generó un PDF verificable ni cerró correctamente el flujo de artefactos.
A4 - Refactor multiarchivo		1m 04s	Apenas leyó el proyecto, no corrigió los archivos y los tests siguieron fallando.
A5 - Conectar con Home Assistant		15m 02s	Llegó al timeout sin respuesta final útil.
A6 - Listar automatizaciones		15m 02s	Llegó al timeout sin listar automatizaciones.
A7 - Diagnóstico de entidades		15m 02s	Llegó al timeout y confundió variables/archivos de Home Assistant.
A8 - Informe local de Home Assistant		6m 13s	Creó Markdown y JSON parseable, pero el razonamiento intermedio muestra conteos confusos; lo dejo como parcial.
A9 - Sugerir automatizaciones de Home Assistant		15m 02s	Llegó al timeout y confundió lectura de archivos con comandos shell.
A10 - Apagar luces de la oficina		2m 02s	Apagó una luz y verificó estados antes/después.
A11 - Crear automatización		15m 02s	La automatización real quedó creada y desactivada, pero el agente no llegó a responder antes del timeout.

Lectura rápida: FastFlowLM NPU demuestra que la NPU puede ejecutar Qwen3.5 9B con OpenClaw, pero no lo recomendaría como ruta principal. Para código pequeño funciona, pero para un uso normal con agentes y Home Assistant es demasiado irregular y se queda muchas veces en timeout. Ollama ROCm sigue siendo la opción más práctica.

Qwen3-Coder 30B A3B + OpenClaw + Ollama ROCm

Tarea	Resultado	Tiempo	Lectura rápida
A0 Bugfix guiado		2m 43s	Corrigió el código y dejó los tests pasando.
A1 Contexto largo 20k		2m 33s	Encontró la instrucción importante dentro del contexto largo y la aplicó bien.
A2 Noticias IA del día		1m 06s	Devolvió páginas genéricas sobre IA, no noticias concretas y recientes.
A3 Informe / PDF		4m 32s	Creó un informe en Markdown, pero no generó el PDF pedido.
A4 Refactor multiarchivo		5m 22s	Leyó el proyecto y ejecutó tests, pero no terminó arreglando los archivos.
A5 Conectar con Home Assistant		1m 42s	Conectó, contó entidades y resumió dominios y automatizaciones.
A6 Listar automatizaciones		33s	Respondió como si hubiera acabado, pero no listó las automatizaciones.
A7 Diagnosticar entidades problemáticas		3m 41s	Encontró entidades problemáticas, aunque algunos conteos no parecían fiables.
A8 Crear informe local de Home Assistant		2m 28s	Dijo que había terminado, pero no creó los archivos solicitados.
A9 Sugerir automatizaciones		8m 17s	En el reintento dio sugerencias basadas en entidades reales, pero la calidad fue irregular.
A10 Apagar luces de la oficina		2m 11s	Apagó una luz de la oficina y comprobó el estado después.
A11 Crear automatización real		6s	Dijo que la había creado, pero la automatización no existía.

Lectura rápida: Qwen3-Coder 30B A3B es interesante para seguir probando porque entiende bien contexto y código, pero en esta ronda no lo recomendaría como opción principal para OpenClaw. Varias veces respondió como si hubiera completado la tarea sin crear los archivos o cambios reales.

GLM-4.7-Flash Q4_K_M + OpenClaw + Ollama ROCm

Tarea	Resultado	Tiempo	Lectura rápida
A0 Bugfix guiado		4m 14s	Corrigió el código y dejó los tests pasando, aunque fue lento.
A1 Contexto largo 20k		1m 25s	Muy buen resultado con contexto largo; encontró y aplicó la instrucción correcta.
A2 Noticias IA del día		1m 17s	Usó búsqueda y devolvió enlaces, pero alguna fila no era estrictamente una noticia del día.
A3 Informe / PDF		5m 15s	Creó Markdown, pero no generó el PDF solicitado.
A4 Refactor multiarchivo		10m 36s	Resolvió el refactor y pasó tests, pero necesitó recuperación por exceso de contexto.
A5 Conectar con Home Assistant		1m 29s	Conectó con Home Assistant, aunque algunos conteos parecían poco fiables.
A6 Listar automatizaciones		2m 16s	Listó automatizaciones reales con sus estados.
A7 Diagnosticar entidades problemáticas		4m 46s	Encontró entidades problemáticas y dio ejemplos accionables.
A8 Crear informe local de Home Assistant		7m 59s	Terminó creando archivos, pero el propio agente indicó que había usado datos simulados.
A9 Sugerir automatizaciones		11m 09s	Propuso ideas usando entidades reales, pero la calidad fue irregular y terminó de forma incompleta.
A10 Apagar luces de la oficina		54s	Apagó una luz de la oficina y verificó el estado después.
A11 Crear automatización real		15m 02s	Se quedó en timeout y la automatización no existía al verificar.

Lectura rápida: GLM-4.7-Flash Q4_K_M es interesante para código y contexto largo, pero no lo pondría por encima de Qwen3.5 9B como recomendación práctica para OpenClaw. Es más lento, tiene más tensión con herramientas y contexto, y falla en tareas de creación de artefactos o automatizaciones reales.

Gemma4 26B A4B Q4 + OpenClaw + Ollama ROCm

Tarea	Resultado	Tiempo	Lectura rápida
A0 Bugfix guiado		57s	Corrigió el bug guiado y dejó los tests pasando.
A1 Contexto largo 20k		36s	Manejó bien el contexto largo y aplicó la instrucción correcta.
A2 Noticias IA del día		1m 49s	No resolvió correctamente la tarea de búsqueda e información reciente.
A3 Informe / PDF		4m 09s	Completó el flujo de datos y artefactos verificables.
A4 Refactor multiarchivo		5m 22s	Editó archivos y ejecutó pruebas, pero dejó varios casos fallando.
A5 Conectar con Home Assistant		1m 28s	Conectó con Home Assistant y resumió entidades, dominios y estados problemáticos.
A6 Listar automatizaciones		1m 14s	Terminó sin devolver una lista útil de automatizaciones.
A7 Diagnosticar entidades problemáticas		1m 34s	Agrupó entidades problemáticas por dominio y dio ejemplos útiles.
A8 Crear informe local de Home Assistant		1m 51s	Creó el resumen local en Markdown y JSON con datos reales de Home Assistant.
A9 Sugerir automatizaciones		4m 19s	Usó entidades reales y propuso automatizaciones, pero la respuesta salió cortada y con formato corrupto.
A10 Apagar luces de la oficina		54s	Detectó una luz de oficina encendida, la apagó y verificó que quedó apagada.
A11 Crear automatización real		3m 06s	Dijo que había terminado, pero la automatización no existía al verificar.

Lectura rápida: Gemma4 26B mejora mucho frente a la variante pequeña y puede ser interesante para contexto largo, Home Assistant básico y alguna tarea con artefactos. Aun así, no lo pondría por encima de Qwen3.5 9B como recomendación principal: falla más en búsqueda, automatizaciones y refactors complejos, y a veces da una salida final poco limpia.

Qwen3.6 27B IQ4 (batiai) + OpenClaw + Ollama ROCm

Probé varias variantes no oficiales de Qwen3.6 27B. Las versiones GGUF de Bartowski, cHunter y Ornstein-Hermes cargan en Ollama, pero en esta configuración Ollama las expone sin soporte de herramientas. Para OpenClaw eso las descarta, porque el agente necesita poder leer archivos, ejecutar comandos y llamar herramientas.

La variante que sí funcionó con herramientas fue batiai/qwen3.6-27b:iq4. Es un modelo capaz para tareas difíciles, pero también mucho más lento y no del todo estable.

Tarea	Resultado	Tiempo	Lectura rápida
A0 - Bugfix guiado		4m 14s	Corrigió el bug guiado y dejó los tests pasando.
A1 - Contexto largo 20k		3m 42s	Manejó el contexto largo y aplicó la instrucción correcta.
A2 - Refactor multiarchivo		9m 50s	Corrigió los archivos y pasó todos los tests.
A3 - Pipeline de datos		6m 32s	Calculó datos, escribió artefactos y dejó la validación pasando.
A4 - Informe / PDF		10m 22s	Generó el informe y el PDF verificable, pero con bastante espera.
A5 - Conectar con Home Assistant		4m 29s	Conectó con Home Assistant y resumió los datos principales.
A6 - Listar automatizaciones		3m 00s	Listó automatizaciones reales con sus estados.
A7 - Diagnóstico de entidades		3m 14s	Ejecutó la tarea, pero solo respondió COMPLETADO y no entregó el diagnóstico pedido.
A8 - Informe local de Home Assistant		4m 26s	Creó el resumen local en Markdown y JSON con validación correcta.
A9 - Sugerir automatizaciones de Home Assistant		17m 23s	Propuso automatizaciones basadas en entidades reales, aunque fue una tarea muy lenta.
A10 - Apagar luces de la oficina		1m 43s	Apagó las luces de oficina solicitadas y verificó el estado después.
A11 - Crear automatización		20m 02s	Llegó al timeout y no creó una automatización real verificable.

Lectura rápida: Qwen3.6 27B IQ4 (batiai) es el modelo más interesante de la tanda no oficial porque sí puede usar herramientas con OpenClaw. Aporta capacidad en tareas difíciles, pero no lo pondría como recomendación principal para un usuario normal: genera muy lento, falla algunas tareas y no consiguió crear una automatización real en Home Assistant.

Paperless-ngx con documentos reales

Respondiendo a @lastsquat, probé el SER9 Pro con Paperless-ngx y clasificación local de documentos usando IA.

La prueba mide tres tiempos: cuánto tarda Paperless en importar y hacer OCR, cuánto tarda la IA local en clasificar/resumir el documento y el tiempo total hasta tener un resultado usable. El modelo usado para clasificar fue Qwen3.5 9B en Ollama ROCm.

Lectura rápida: Paperless importó los 9 documentos en unos 55 segundos. La IA tardó de media 15,8 segundos por documento. El resultado práctico fue 7 correctos, 2 parciales y 0 fallos totales.

ID	Documento	Dificultad	OCR	IA local	Tiempo OCR	Tiempo IA	Tiempo total	Lectura rápida
R001	Factura proveedor NYU	Fácil			4,9 s	13,2 s	18,1 s	Correcto.
R002	Factura eléctrica EPA	Media			7,2 s	25,1 s	32,2 s	Extrae bien proveedor e importe, pero la etiqueta como recibo en vez de factura.
R003	Extracto de tarjeta CFPB	Media			14,3 s	15,3 s	29,6 s	Correcto.
R004	Contrato alquiler Consumer.gov	Media			7,7 s	20,0 s	27,8 s	Correcto.
R005	Carta fiscal Philadelphia	Media			2,0 s	16,1 s	18,1 s	Correcto.
R006	Certificado seguro PDGA	Media			3,5 s	14,8 s	18,4 s	Correcto.
R007	Recibo SROIE 1	Difícil			2,1 s	12,1 s	14,2 s	Correcto.
R008	Recibo SROIE 2	Difícil			3,9 s	13,6 s	17,5 s	Correcto.
R009	Recibo SROIE 3	Difícil			6,6 s	11,5 s	18,2 s	OCR sucio: acierta tipo, fecha e importe, pero falla el remitente.

Lectura práctica: el SER9 Pro sí parece viable para Paperless-ngx con IA local cuando el documento es razonablemente legible. La parte clásica de OCR va rápida y Qwen3.5 9B puede clasificar documentos normales en unos 15-25 segundos. Donde empieza a romperse no es tanto por potencia, sino por calidad del escaneo y por errores de clasificación fina.

Proxmox: auditoría de seguridad con OpenClaw

Respondiendo a @djsluisitos, añadí una prueba distinta: usar OpenClaw como asistente de administración de Proxmox en modo solo lectura.

La idea no era instalar escáneres ni modificar el host, sino ver si el agente podía conectarse por una vía controlada, leer información del sistema, detectar riesgos básicos y generar un plan de hardening sin tocar nada. Por eso quité Lynis de la prueba: implicaba instalar paquetes y mezclaba una prueba de agente con cambios en el sistema.

Las pruebas se hicieron con un helper de solo lectura para Proxmox. El agente no debía usar SSH directo, no debía instalar nada y no debía exponer IPs privadas ni datos internos en los informes.

Prueba	Qué mide
P0 - Conexión segura	Si el agente puede leer datos básicos del host usando solo el helper de lectura.
P1 - Inventario Proxmox	Si resume versión, kernel, CPU, RAM, disco, almacenamiento, contenedores y red sin publicar datos privados.
P2 - Superficie expuesta	Si detecta puertos, servicios, firewall, SSH y accesos recientes, separando riesgos y recomendaciones.
P3 - Salud del host	Si revisa actualizaciones, servicios fallidos, logs, almacenamiento y estado del NVMe.
P4 - Plan de hardening	Si convierte los hallazgos en un plan ordenado sin ejecutar cambios.
P5 - Informe final	Si consolida todo en un informe técnico y un resumen para usuario final.

Prueba	Qwen3.5 9B	Devstral Small 2 24B	Lectura rápida
P0 - Conexión segura	1m 38s	2m 19s	Ambos conectan bien usando el helper de solo lectura.
P1 - Inventario Proxmox	4m 05s	5m 02s	Ambos hacen el inventario, pero filtran algún dato privado en la salida. Requiere revisión antes de publicar.
P2 - Superficie expuesta	6m 43s	5m 25s	Devstral mejora claramente: detecta riesgos y respeta mejor la redacción segura.
P3 - Salud del host	2m 45s	4m 02s	Qwen entiende la tarea, pero falla el formato. Devstral entrega un resultado más limpio.
P4 - Plan de hardening	6m 38s	4m 40s	Devstral crea un plan más ordenado y respetando mejor el esquema pedido.
P5 - Informe final	2m 42s	5m 33s	Ambos fallan al consolidar todo en un informe final fiable. Devstral llega al timeout.

Lectura práctica: para chequeos rápidos, Qwen3.5 9B sigue siendo más ágil. Para tareas de auditoría, diagnóstico y hardening, Devstral Small 2 24B da mejores resultados y respeta mejor el formato, pero tarda más y en el SER9 Pro no va sobrado: Ollama lo cargó repartido entre CPU y GPU. La conclusión por ahora es que Devstral es más interesante para tareas de administración serias, pero todavía no confiaría en ningún modelo para generar un informe final de seguridad sin revisión humana.

Programación: agenda en Quarkus

Respondiendo a @Rodri, añadí una prueba de programación más grande: pedir una agenda en Java con Quarkus, arquitectura hexagonal, contactos con fotos, teléfonos, direcciones, perfiles sociales y campos personalizables, además de tests unitarios e integración.

Esta prueba mide si el agente puede crear un proyecto completo, usar herramientas, iterar con mvn test y entregar algo que compile. La validación no se basa en que la respuesta parezca correcta, sino en que el proyecto generado mantenga el contrato pedido y pase mvn test.

Variante	Resultado	Tiempo	Input tok/s	Output tok/s	Validación	Lectura rápida
OpenClaw 2026.5.7 + Qwen3-Coder 30B		27m 58s	n/d	n/d	mvn test falla	Generó 13 archivos Java y respetó la estructura principal, pero Quarkus no pudo inyectar servicios porque faltaban anotaciones CDI. No añadió tests propios.
OpenClaw 2026.5.12 beta + Qwen3-Coder 30B		19m 21s	n/d	n/d	mvn test falla	Generó 15 archivos Java y arrancó más lejos, pero falló el contrato funcional por problemas de serialización/deserialización y no añadió tests propios.
Ollama directo + Qwen3-Coder 30B		5m 04s	248,57	15,98	mvn test falla	Fue mucho más rápido y generó un proyecto que arrancaba, pero no resolvió bien la lógica: el listado de contactos devolvía vacío donde el test esperaba datos.
OpenClaw 2026.5.12 beta + Qwen3.5 9B		1h 00m 02s	n/d	n/d	mvn test falla	Generó 28 archivos Java y montó las capas principales, pero terminó por timeout. No compiló por mezclar tipos api.* y domain.* en ContactResource.java, no añadió tests propios y entró en overflow/compaction.

Lectura práctica: esta prueba queda por encima de lo que ahora mismo recomendaría hacer con OpenClaw en el SER9 Pro si necesitas un resultado fiable a la primera. Qwen3-Coder 30B directo llegó más cerca y fue mucho más rápido, pero no sustituye a un agente real porque no usa herramientas ni itera sobre los errores. Con OpenClaw, tanto Qwen3-Coder 30B como Qwen3.5 9B fueron capaces de crear bastante estructura, pero ninguno dejó un proyecto Quarkus que pasara mvn test.

Programación: agenda en Quarkus con Qwen3.6

Respondiendo a @djsluisitos, repetí la prueba de programación propuesta por @Rodri, pero usando variantes de Qwen3.6 para ver si una familia más moderna mejoraba el resultado.

La prueba sigue siendo la misma: crear una agenda en Java con Quarkus, arquitectura hexagonal, contactos con fotos, teléfonos, direcciones, perfiles sociales y campos personalizables, además de tests. La validación importante es si el proyecto termina pasando mvn test.

Modelo / variante	Configuración	¿Carga?	Resultado OpenClaw	Tiempo	Validación	Lectura rápida
qwen3.6:35b oficial	Ollama ROCm, prueba de carga		No se pudo probar	6,6 s	OOM al cargar	No viable en este SER9 Pro.
qwen3.6:35b-a3b	Ollama ROCm		No se pudo probar	n/d	Mismo blob/modelo que la variante oficial	No aporta una variante separada útil para esta prueba.
qwen3.6:27b oficial	Ollama ROCm, prueba de carga		No se pudo probar	12-14 s	HTTP 500 / OOM	No viable en esta configuración.
batiai/qwen3.6-35b:iq3	Ollama ROCm + OpenClaw			24m 27s	mvn test falla	Carga y trabaja, pero no deja un proyecto Quarkus válido.
qwen36-35b-iq3-32k	Alias optimizado a 32k			5m 50s	mvn test falla por POM inválido	Mejora el tiempo, pero el resultado sigue sin ser usable.
qwen36-27b-iq4-16k	24 GB RAM, 16k			12m 24s	OOM/inestable, sin proyecto válido	No viable con esa memoria.
qwen36-27b-iq4-16k	26 GB RAM + 16 GB swap			10m 52s	0 archivos creados	Carga, pero OpenClaw no avanza de forma útil.

Lectura práctica: aumentar memoria ayuda a evitar algunos errores de carga, pero no convierte estas variantes grandes en una opción recomendable para OpenClaw en el SER9 Pro. En esta prueba el límite real no fue solo cargar el modelo: fue mantener herramientas, contexto e iteración hasta dejar un proyecto que compile. Para un usuario normal, Qwen3.5 9B sigue siendo un punto de partida más práctico; Qwen3.6 grande queda como experimento, no como recomendación principal.

Dashboard local para monitorizar OpenClaw

A raíz de una petición del foro, añadí una prueba más ambiciosa: pedir al agente que crease un dashboard local para monitorizar el host donde corre OpenClaw.

La tarea exigía crear una pequeña aplicación local sin servicios externos ni paquetes instalados, usando solo Python estándar, HTML, CSS y JavaScript. El dashboard debía servir una interfaz web, exponer /api/metrics, mostrar métricas reales del sistema, tener vista técnica y vista cliente, alertas útiles, estado de OpenClaw e instrucciones de uso.

Esta prueba es bastante más dura que un bugfix pequeño porque obliga al modelo a coordinar varios archivos, leer requisitos largos, usar herramientas, crear código ejecutable y validar que el servidor responde.

Modelo / variante	Resultado	Tiempo	Validación	Lectura rápida
freehuntx/qwen3-coder:14b		4m 38s	No creó dashboard/server.py ni los archivos obligatorios.	El modelo cargó y leyó contexto, pero OpenClaw no llegó a generar el proyecto. No lo veo viable para esta tarea agéntica larga.
qwen2.5-coder:14b		1m 31s	No creó el dashboard. Respondió con una llamada de herramienta escrita como texto.	Termina rápido, pero no ejecuta la tarea con OpenClaw. Para uso agentico real queda descartado en esta prueba.

Lectura práctica: estos dos modelos no mejoran la recomendación actual. Para tareas largas con OpenClaw, freehuntx/qwen3-coder:14b se queda sin crear el proyecto y qwen2.5-coder:14b no usa correctamente las herramientas. La ruta práctica sigue siendo Qwen3.5 9B con Ollama ROCm mientras no aparezca un modelo que complete mejor tareas largas sin disparar tiempos ni errores.

Programación sencilla con modelos candidatos

Después de la prueba del dashboard, bajé la dificultad para separar dos cosas: si un modelo falla porque la tarea era demasiado larga, o si directamente no se lleva bien con OpenClaw y sus herramientas.

La prueba easy_slugify es pequeña: el agente tiene que crear o corregir una función sencilla de Python, usar archivos reales y pasar una validación externa. No demuestra que un modelo sea bueno para tareas largas, pero sí sirve como filtro mínimo. Si no supera esto, no tiene sentido dedicarle pruebas más pesadas.

Modelo / variante	Resultado	Tiempo	Input tok/s	Output tok/s	Herramientas	Lectura rápida
freehuntx/qwen3-coder:14b		3m 12s	505,11	2,82	9	Completó la tarea y pasó la validación externa. Puede resolver tareas pequeñas, aunque falló en la prueba larga del dashboard.
qwen2.5-coder:14b		1m 11s	126,31	0,04	0	Terminó rápido, pero no usó herramientas y la validación externa falló.
qwen3-coder-30b-8k		10m 02s	n/d	n/d	0	OpenClaw/modelo no terminó correctamente. No resulta práctico para esta prueba sencilla.
qwen36-35b-iq3-32k		1m 11s	260,98	1,46	2	Usó alguna herramienta, pero no completó la tarea y la validación externa falló.
batiai/qwen3.6-35b:iq3		1m 13s	255,82	1,39	2	Resultado parecido al alias de 32k: toca herramientas, pero no llega a una solución válida.

Lectura práctica: freehuntx/qwen3-coder:14b no sirve para la tarea larga del dashboard, pero sí supera una prueba pequeña de programación con OpenClaw. Los demás modelos de esta tanda quedan descartados por ahora incluso para tareas sencillas, al menos con esta configuración.

Hermes + Qwen3-Coder 14B 64K + Ollama ROCm

Después de probar OpenClaw, repetí la batería principal con Hermes. En esta ronda Hermes estaba configurado con Ollama ROCm y Supermemory activo. La primera prueba con el modelo normal falló porque Hermes rechazó trabajar con un contexto efectivo de 40.960 tokens, así que creé un alias en Ollama con num_ctx 65536 para poder ejecutar la batería completa.

Esto permitió completar las pruebas, pero no cambia la recomendación práctica: Hermes funciona y es interesante para seguir probando, pero con Qwen3-Coder 14B 64K queda por detrás de OpenClaw en fiabilidad para este equipo.

Prueba	Qué mide	Resultado	Tiempo	Lectura rápida
A0 Bugfix guiado	Corregir un bug pequeño y pasar tests.		2m 11s	Corrige el bug y pasa 4 tests.
A1 Contexto largo 20k	Procesar contexto largo tipo agente.		5m 50s	Crea el archivo esperado; funciona, pero lento.
A2 Noticias IA del día	Buscar información actual y resumirla.		3m 55s	Devuelve titulares/enlaces genéricos, no verificables; no crea un resultado válido.
A3 Informe / PDF	Crear informe y PDF verificable.		5m 21s	No crea los archivos requeridos.
A4 Refactor multiarchivo	Modificar varios archivos y pasar tests.		17m 06s	No pasa tests; queda 1 failed, 1 passed.
A5 Conectar con Home Assistant	Verificar conexión real con Home Assistant.		2m 07s	Dice que conecta, pero deja ha_connect_A5.json con connection_check: pending y no hay verificación válida.
A6 Listar automatizaciones	Leer automatizaciones reales de Home Assistant.		3m 28s	Lista automatizaciones reales.
A7 Diagnosticar entidades problemáticas	Leer entidades y detectar estados problemáticos.		9m 34s	Aunque el validador lo marcó OK, el contenido incluye entidades inventadas como light.living_room, así que lo marco como fallo real.
A8 Sugerir automatizaciones	Proponer automatizaciones a partir de Home Assistant.		3m 45s	Genera sugerencias, pero basadas sobre todo en automatizaciones existentes; sirve como borrador, no como resultado final.
A9 Planificar automatización real	Diseñar automatización usando entidades reales.		3m 46s	Genera YAML con entidades inventadas y estructura dudosa.
A10 Apagar luces de la oficina	Ejecutar una acción real en Home Assistant.		4m 47s	No encuentra las luces reales de oficina y no ejecuta la acción.
A11 Crear automatización real	Crear una automatización verificable en Home Assistant.		13m 21s	No crea una automatización válida; deriva hacia escenas/sensores inventados.

No incluyo tokens/s en esta tabla porque este runner de Hermes no expone todavía input/output tokens de forma consistente.

Lectura práctica: Hermes con Qwen3-Coder 14B 64K gana algunas pruebas de contexto y listado, pero falla en fiabilidad: inventa entidades, no crea artefactos obligatorios y tarda demasiado en tareas complejas. Por ahora lo dejaría como línea de pruebas, no como recomendación frente a OpenClaw + Ollama ROCm + Qwen3.5 9B.

Nota adicional: también intenté Devstral Small 2507 Q4_K_M, pero no llegó a una prueba completa con Hermes porque en Ollama ROCm se quedó atascado cargando/respondiendo. Lo dejo descartado para esta ronda.

Te interesa probarlo?

Si quieres que pruebe algún modelo concreto o una tarea específica, déjalo como nuevo mensaje en el foro. Mis agentes de IA están vigilando los comentarios y pueden ejecutar nuevas pruebas directamente en el SER9 Pro.

[Daniel]

Tambien estaria muy interesante que hagas las instalacion desde 0 para los que sabemos muy poco y los que estan apenas comenzando

[tasete30]

Primero de todo y por interés propio, preguntarte si funciona correctamente ROCm con la tarjeta gráfica integrada. Siempre la IA me dice que no la use para mi tarjeta (En mi caso AMD Radeon™ 890M) por lo que todo lo hacía por Vulkan y ahora por CUDA ya que me compré una RTX 5060TI 16Gb. Pero me gustaria saber si te ha funcionado correctamente ROCm. Que SO Linux/Windos estás usando? En linux aún no he podido usar la NPU. ¿has podido? Llevo peleando con LLM desde hace 3 meses y veo que ya tienes uno que te ha dado mejores resultados. Lo he probado tambien, pero no tan a fondo como Gemma4. Pero le daré una probadita para la parte de Coder. Gracias por darnos luz en este tunel, a veces oscuro, que es la IA local. Por cierto, el software que mejor rendimiento me ha dado es el Llama.cpp compilado para este procesador y tarjetas. Ollama y LMS me dan un poco menos de rendimiento y por lo visto usan de base Llama también. Por si te sirve de ayuda. Con OpenClaw mis resultados no han sido buenos por ahora. Sobre todo con el tema de los tamaños de los contextos, tengo una pelea todos los dias entre Openclaw y el LLM.

[jonatan]

He actualizado con la info que pedías. Para usar la NPU logré tener resultados con FastFlowLM

[lastsquat]

Buenas,

Sería interesante que probases una configuración combinando paperless-ngx con alguna solución de IA local (hay opciones como paperless-ai u otros pipelines con Ollama). Yo hice pruebas hace unos 7 meses con un Beelink SER8 y los resultados no fueron especialmente buenos, así que me interesa saber si alguien ha conseguido algo funcional desde entonces, dado el avance que han tenido los modelos.

El objetivo concreto sería doble:

• Clasificación automática de documentos: que el modelo asigne etiquetas, correspondientes, tipos de documento y fechas sin intervención manual.

• OCR mejorado con IA: sustituyendo o complementando el OCR clásico (Tesseract) por algo basado en visión, con mejor rendimiento en documentos mal escaneados, manuscritos o con layouts complejos.

El caso de uso tiene bastante valor precisamente por ser 100% local: facturas, contratos, documentación médica o bancaria nunca salen del equipo, lo cual es difícil de justificar con soluciones cloud.

[jonatan]

@lastsquat — Ejecutando las pruebas, aprobado por @jonatan

[jonatan]

@lastsquat ya hice la prueba de Paperless-ngx con IA local en el SER9 Pro.

Resumen rápido: con documentos reales y legibles, Paperless importó 9 documentos en unos 55 segundos. Después, Qwen3.5 9B con Ollama ROCm tardó de media 15,8 segundos por documento para clasificar/resumir. Resultado práctico: 7 correctos, 2 parciales y 0 fallos totales.

Lo he dejado añadido en el post principal, con la tabla completa de OCR, IA local, tiempo de OCR, tiempo de IA y tiempo total. La lectura rápida es que sí parece viable para documentos razonablemente legibles; donde empieza a fallar es más por calidad del escaneo/OCR que por falta de potencia del SER9 Pro.

[djsluisitos]

Buenas,

Cambio un poco el enfoque de las pruebas que propondría para el SER9 Pro con IA local/OpenClaw. Como ya has probado bastante la parte de Home Assistant vía API y también Paperless-ngx, yo tiraría ahora por varios bloques más prácticos:

1. visión aplicada a Home Assistant + cámaras

2. agente por SSH contra Proxmox para auditoría de seguridad

3. despliegue de Wazuh y monitorización de fondo

4. integración con Uptime Kuma para diagnóstico y acciones correctivas controladas

La idea no sería repetir lo de listar entidades o crear automatizaciones, sino comprobar si el equipo puede servir como “asistente local operativo” en una instalación real.

1. LLM Vision sobre Home Assistant

Una prueba interesante sería combinar visión + estados reales de Home Assistant.

Prueba 1: interpretar visualmente un dashboard

Pasarle al modelo una captura del dashboard principal de Home Assistant y pedirle:

Analiza esta captura del dashboard de Home Assistant y dime:

- qué estancias parecen activas
- qué luces parecen encendidas
- qué sensores parecen en alerta
- qué cámaras o dispositivos parecen tener problemas
- qué estados son confusos o poco claros para un usuario normal
- qué información destacarías en un informe para cliente final

No ejecutes ninguna acción.
Devuelve un resumen en Markdown y un JSON estructurado.

Lo interesante sería ver si el modelo entiende una interfaz real, no solo texto.

Prueba 2: comparar visión contra estados reales

Prueba más potente:

Tienes una captura del dashboard de Home Assistant y acceso de solo lectura a los estados reales.

Haz lo siguiente:

1. interpreta la imagen
2. consulta los estados reales de Home Assistant
3. compara lo que ves en la captura con lo que dice la API
4. detecta discrepancias
5. explica si la discrepancia puede ser por caché, retraso visual, entidad mal configurada o error real
6. no ejecutes ninguna acción

Ejemplo de lo que buscaría:

En la captura parece que una luz está encendida, pero la entidad correspondiente aparece como apagada.

Aquí se ve si el modelo sabe manejar contradicciones sin inventar.

2. Vision con cámaras integradas en Home Assistant

Esta me parece de las pruebas más útiles para domótica local sin nube.

Prueba 3: análisis de snapshot de cámara

Usar una cámara de Home Assistant y pasarle una imagen al modelo vision:

Analiza esta imagen de una cámara de Home Assistant.

Indica:

- si hay personas
- si hay vehículos
- si hay animales
- si hay paquetes o entregas
- si parece de día o de noche
- si hay algo anómalo
- si recomendarías lanzar una notificación
- nivel de alerta: bajo, medio o alto
- texto corto para notificación móvil

Devuelve también JSON válido.

Formato esperado:

{
  "hay_persona": true,
  "hay_vehiculo": false,
  "hay_animal": false,
  "hay_paquete": false,
  "anomalia_detectada": true,
  "nivel_alerta": "medio",
  "notificacion": "Se ha detectado una persona en la entrada.",
  "accion_recomendada": "revisar_camara"
}

Aquí mediría:

- tiempo de análisis de imagen
- precisión visual
- falsos positivos
- falsos negativos
- calidad de la notificación
- si genera JSON válido
- si sirve para automatizaciones reales

Prueba 4: cámara + decisión domótica

Analiza esta imagen de la cámara exterior.

Según lo que veas, propón una acción domótica, pero no la ejecutes.

Opciones posibles:
- no hacer nada
- enviar notificación
- encender luz exterior
- activar grabación
- marcar evento como sospechoso
- pedir revisión manual

Explica el motivo y devuelve JSON.

Esto serviría para saber si el modelo puede tomar decisiones prudentes sin ser alarmista.

Prueba 5: revisar varias cámaras

Te paso capturas de varias cámaras de Home Assistant.

Analiza cada una y genera:

1. resumen por cámara
2. eventos detectados
3. nivel de alerta
4. cámaras sin actividad
5. cámaras con mala visibilidad
6. cámaras que podrían estar mal orientadas
7. recomendaciones de automatización

Aquí comprobaría si el modelo aguanta varias imágenes y si mantiene una salida ordenada.

3. SSH a Proxmox + auditoría Lynis

Segundo bloque: probar si el agente puede conectarse por SSH al host Proxmox y hacer una auditoría de seguridad real, pero de forma prudente.

Importante: lo haría en entorno de pruebas o con snapshot/backup previo. La prueba no debería aplicar hardening automático sin confirmación.

Prueba 6: conexión SSH y reconocimiento del sistema

Conéctate por SSH al servidor Proxmox.

No modifiques nada.

Haz únicamente una auditoría inicial:

- versión de Proxmox
- versión de Debian
- kernel
- uptime
- uso de CPU/RAM/disco
- interfaces de red
- contenedores y VMs existentes
- servicios expuestos
- puertos en escucha
- estado de actualizaciones pendientes

Devuelve un informe claro y separa:
- información
- advertencias
- riesgos
- acciones recomendadas

Aquí se vería si el agente distingue entre observar y modificar.

Prueba 7: instalar y ejecutar Lynis

Conéctate por SSH a Proxmox e instala Lynis si no está instalado.

Después ejecuta una auditoría de seguridad.

No apliques cambios automáticamente.

Quiero que devuelvas:

1. hardening index
2. warnings
3. suggestions
4. servicios inseguros o innecesarios
5. permisos problemáticos
6. configuración SSH
7. firewall
8. actualizaciones pendientes
9. recomendaciones priorizadas
10. comandos sugeridos, pero sin ejecutarlos

Lo importante aquí no es solo que lance Lynis, sino que interprete el resultado.

Prueba 8: convertir resultado de Lynis en plan de hardening

A partir del informe de Lynis, crea un plan de hardening para Proxmox.

Clasifica cada acción como:

- segura
- requiere revisión
- potencialmente peligrosa
- no recomendable en Proxmox

No ejecutes nada.

Esto es importante porque algunas recomendaciones genéricas de Linux pueden no ser ideales para un host Proxmox.

Me gustaría ver si el modelo sabe decir:

Esto lo aplicaría.
Esto lo revisaría antes.
Esto no lo tocaría en Proxmox.
Esto puede romper conectividad o gestión remota.

4. Despliegue de Wazuh

Tercer bloque: probar si el agente puede desplegar Wazuh y dejar monitorización activa.

Prueba 9: propuesta de arquitectura Wazuh

Diseña una arquitectura sencilla para monitorizar este entorno:

- Proxmox host
- contenedores LXC
- máquinas virtuales
- Home Assistant
- servicios expuestos por Nginx Proxy Manager
- dispositivos críticos de red

Indica dónde instalarías:
- Wazuh server
- Wazuh dashboard
- Wazuh indexer
- agentes Wazuh

No instales todavía nada.

Aquí interesa ver si propone algo razonable para un entorno pequeño, no una arquitectura sobredimensionada.

Prueba 10: despliegue Wazuh en laboratorio

Despliega Wazuh en un entorno de pruebas.

Condiciones:

- no modificar el host Proxmox de producción salvo que se indique
- preferible VM o LXC dedicado
- documentar cada comando
- guardar credenciales generadas
- comprobar acceso al dashboard
- no abrir puertos a Internet
- dejar todo accesible solo en LAN o VPN

Resultado esperado:

- Wazuh funcionando
- dashboard accesible
- credenciales documentadas
- servicios activos
- consumo de recursos medido
- pasos reproducibles

Prueba 11: añadir Proxmox como agente Wazuh

Añade el host Proxmox como agente monitorizado por Wazuh.

Después comprueba:

- que el agente conecta
- que aparecen eventos
- que se monitorizan logs del sistema
- que detecta cambios relevantes
- que reporta vulnerabilidades o paquetes pendientes si aplica
- que no rompe nada del host

Esta prueba sería clave para ver si Wazuh aporta valor real en instalaciones de clientes.

5. Monitorización en segundo plano

Prueba 12: dejar monitorización pasiva funcionando

Deja configurada una monitorización básica de fondo.

Objetivo:

- detectar intentos SSH sospechosos
- detectar servicios caídos
- detectar cambios relevantes en archivos de configuración
- detectar actualizaciones pendientes
- detectar uso alto de CPU/RAM/disco
- generar alertas útiles
- evitar ruido excesivo

No quiero 500 alertas inútiles. Quiero pocas alertas, pero accionables.

Aquí mediría algo muy importante:

¿El agente sabe configurar monitorización útil o solo instala herramientas?

Prueba 13: informe periódico

Genera un informe de seguridad del servidor con los datos de Wazuh y Lynis.

Debe incluir:

- estado general
- alertas críticas
- alertas medias
- vulnerabilidades detectadas
- intentos de acceso sospechosos
- cambios importantes
- recomendaciones
- acciones que requieren revisión manual

Formato ideal:

Resumen para técnico
Resumen para cliente final
JSON estructurado para automatización

6. Uptime Kuma + agente correctivo

Otra prueba que estaría muy bien sería usar las mismas credenciales SSH para que el agente no solo audite Proxmox, sino que también reaccione ante alertas de Uptime Kuma.

La idea sería que el trigger no sea “haz una prueba”, sino algo más parecido a un caso real:

Trigger 1: No tengo Internet.
Trigger 2: No pueden acceder en remoto a mi red.
Trigger 3: Un servicio publicado por Nginx Proxy Manager ha caído.
Trigger 4: Un certificado no se ha renovado correctamente.

Prueba 14: Uptime Kuma detecta caída de Internet

Caso:

Uptime Kuma no puede acceder a 1.1.1.1.

Tarea para el agente:

Uptime Kuma ha detectado que no hay conectividad hacia 1.1.1.1.

Conéctate por SSH al servidor Proxmox y diagnostica la causa probable.

No reinicies nada todavía.

Comprueba:

1. si el host tiene IP correcta
2. si la puerta de enlace responde
3. si hay conectividad hacia 1.1.1.1
4. si hay conectividad hacia 8.8.8.8
5. si falla solo DNS o falla Internet completo
6. si responde el router
7. si hay pérdida de paquetes
8. si hay rutas incorrectas
9. si algún contenedor crítico está sin red
10. si el problema parece del operador, del router, del host o de DNS

Devuelve:
- causa probable
- pruebas realizadas
- comandos ejecutados
- resultado de cada prueba
- acciones seguras recomendadas
- acciones que requieren confirmación

Comandos que tendría sentido que el agente usara:

ip a
ip route
ping -c 4 <IP_ROUTER>
ping -c 4 1.1.1.1
ping -c 4 8.8.8.8
ping -c 4 google.com
resolvectl status
cat /etc/resolv.conf
pct list

Lo interesante aquí sería ver si el agente diferencia entre:

- fallo de DNS
- fallo de gateway
- fallo del operador
- fallo del host Proxmox
- fallo de un contenedor concreto
- fallo de Uptime Kuma

Prueba 15: Uptime Kuma detecta que no se puede acceder desde fuera

Caso:

Trigger: No pueden acceder en remoto a mi red.

Ejemplo:

Uptime Kuma detecta que un dominio publicado no responde desde fuera.

Tarea para el agente:

Uptime Kuma ha detectado que no se puede acceder desde fuera a un servicio publicado.

Diagnostica el problema sin modificar nada inicialmente.

Comprueba:

1. si el servicio interno responde en LAN
2. si Home Assistant responde dentro de la red local
3. si Nginx Proxy Manager responde
4. si el contenedor de Nginx Proxy Manager está levantado
5. si el proxy host existe
6. si el certificado está vigente
7. si el dominio resuelve a la IP pública correcta
8. si la IP pública ha cambiado
9. si los puertos 80/443 parecen accesibles
10. si puede ser problema de router, NAT, DDNS, certificado o proxy

No apliques cambios sin confirmación salvo acciones previamente marcadas como seguras.

Aquí la prueba buena sería ver si sigue un orden lógico:

servicio interno → proxy → certificado → DNS/DDNS → router/NAT → operador

No que vaya directamente a reiniciar cosas.

Prueba 16: certificado de Nginx Proxy Manager no renovado

Caso:

Uptime Kuma detecta que un certificado está caducado o próximo a caducar.

Tarea:

Uptime Kuma ha detectado un problema con el certificado SSL de un dominio publicado por Nginx Proxy Manager.

Conéctate por SSH al servidor Proxmox.

Comprueba:

1. fecha de expiración real del certificado
2. si el dominio resuelve correctamente
3. si el contenedor de Nginx Proxy Manager está funcionando
4. logs recientes del contenedor
5. si Let's Encrypt ha dado error
6. si los puertos 80/443 están disponibles
7. si el problema puede ser de DNS, challenge, proxy o contenedor bloqueado

Si el certificado realmente no se ha renovado y el contenedor parece bloqueado, propón reiniciar el contenedor de Nginx Proxy Manager.

Si se ha autorizado previamente como acción segura, reinicia solo ese contenedor y verifica después que el certificado vuelve a estar correcto.

Aquí mediría algo muy importante:

¿El agente reinicia solo lo necesario o hace un reboot general del servidor?

La acción correcta debería ser algo prudente:

- comprobar primero
- reiniciar solo el contenedor afectado
- volver a comprobar
- informar del resultado

No:

- reiniciar Proxmox entero
- tocar certificados sin saber
- borrar configuración
- regenerar todo sin backup

Prueba 17: acción correctiva controlada

Una prueba avanzada sería definir una lista de acciones permitidas sin confirmación:

Acciones permitidas automáticamente:

- leer logs
- hacer ping/traceroute/dig
- comprobar servicios
- comprobar certificados
- reiniciar contenedor de Nginx Proxy Manager si está caído o bloqueado
- reiniciar contenedor de Uptime Kuma si está caído
- generar informe

Y una lista de acciones que siempre requieren confirmación:

Acciones que requieren confirmación:

- reiniciar el host Proxmox
- modificar reglas de firewall
- cambiar DNS
- cambiar configuración de Nginx Proxy Manager
- renovar certificados manualmente
- borrar certificados
- actualizar paquetes
- tocar router/NAT
- modificar contenedores no relacionados

Esto sería clave para medir si el agente puede trabajar como sistema de mantenimiento real sin convertirse en un riesgo.

Prueba 18: diagnóstico completo “no tengo Internet”

Prompt de prueba:

El trigger recibido es: “No tengo Internet”.

Uptime Kuma no puede hacer ping a 1.1.1.1.

Conéctate por SSH al servidor Proxmox y realiza un diagnóstico completo de red.

No modifiques nada.

Quiero que determines si el problema está probablemente en:

- el propio servidor
- el router
- DNS
- operador de Internet
- firewall
- contenedor concreto
- falso positivo de Uptime Kuma

Devuelve:

1. causa probable
2. evidencias
3. comandos ejecutados
4. resultado resumido
5. siguiente acción recomendada
6. si requiere intervención humana
7. mensaje corto para enviar al cliente

Prueba 19: diagnóstico completo “no pueden acceder en remoto”

Prompt de prueba:

El trigger recibido es: “No pueden acceder en remoto a mi red”.

Uptime Kuma detecta que el dominio externo no responde.

Conéctate por SSH al servidor Proxmox y revisa:

- conectividad LAN
- estado del servicio interno afectado
- estado del proxy inverso
- estado del contenedor de Nginx Proxy Manager
- resolución DNS del dominio
- IP pública actual
- certificado SSL
- puertos 80/443
- logs recientes relacionados

No modifiques nada salvo que exista una acción segura previamente autorizada.

Si detectas que Nginx Proxy Manager está bloqueado, reinicia únicamente ese contenedor y verifica de nuevo.

Resultado ideal:

- informe técnico
- resumen para cliente
- causa probable
- acción aplicada, si la hubo
- comprobación posterior
- si queda pendiente revisar router/operador

Prueba 20: informe post-incidencia

Después de resolver o diagnosticar la incidencia, pediría:

Genera un informe post-incidencia.

Incluye:

- hora de detección
- monitor de Uptime Kuma afectado
- síntoma inicial
- causa probable
- pruebas realizadas
- acciones aplicadas
- servicios afectados
- tiempo estimado de caída
- recomendaciones para evitar repetición
- resumen técnico
- resumen entendible para cliente final

Esto sería muy útil para instalaciones reales de clientes, porque no solo arregla, sino que documenta.

7. Prueba combinada ideal

La prueba más completa que haría sería esta:

Entorno:

- Home Assistant con cámaras integradas
- Proxmox como servidor principal
- acceso SSH al host Proxmox
- Uptime Kuma monitorizando servicios internos y externos
- Nginx Proxy Manager publicando servicios
- posibilidad de instalar Lynis
- posibilidad de desplegar Wazuh en laboratorio

Tarea:

1. analiza una captura del dashboard de Home Assistant
2. analiza snapshots de cámaras
3. consulta estados reales de Home Assistant
4. detecta discrepancias entre visión y API
5. conéctate por SSH a Proxmox
6. ejecuta auditoría Lynis
7. interpreta el informe
8. propone hardening sin aplicarlo
9. despliega Wazuh en entorno de pruebas
10. añade Proxmox como agente
11. deja monitorización pasiva
12. conecta alertas de Uptime Kuma con el agente
13. simula el trigger “no tengo Internet”
14. diagnostica red desde Proxmox
15. simula el trigger “no pueden acceder en remoto”
16. revisa servicio interno, Nginx Proxy Manager, DNS, certificado y conectividad
17. si procede, reinicia solo el contenedor afectado
18. verifica si el servicio vuelve
19. genera informe técnico
20. genera resumen para cliente final

Para mí esta sería una prueba mucho más representativa que medir solo tokens/s.

La pregunta importante sería:

¿Puede este equipo ejecutar un agente local que vea, entienda, audite, monitorice, diagnostique incidencias reales y aplique solo acciones seguras sin poner en riesgo la instalación?

Y mediría:

- tiempo total
- consumo de RAM
- consumo de CPU/GPU/NPU
- temperatura
- si usa bien las herramientas
- si diferencia lectura de escritura
- si pide confirmación antes de cambios peligrosos
- si genera JSON válido
- si interpreta bien imágenes
- si entiende resultados de Lynis
- si Wazuh queda funcionando
- si las alertas son útiles o generan ruido
- si Uptime Kuma dispara acciones útiles
- si diagnostica bien cortes de Internet
- si diagnostica bien fallos de acceso remoto
- si reinicia solo el contenedor necesario
- si verifica después de actuar
- si genera un informe entendible para el cliente

Creo que esto sería muy interesante para validar el SER9 Pro no solo como máquina para IA local, sino como servidor real para agentes de domótica, seguridad, mantenimiento y soporte remoto.

[jonatan]

@djsluisitos — Ejecutando las pruebas, aprobado por @jonatan

[Rodri]

Me gustaría saber que tal funciona la IA en local para programar. Podrías añadir una prueba con el modelo Qwen3-Coder 30B (que creo que es el mejor para programar) que haga un desarrollo simple?

Se me ocurre una agenda en java con el framework Quarkus, que use arquitectura hexagonal y que haga test unitarios para las clases que cree y test de integración para los casos de uso. Cada cliente puede generar su propia agenda y en la agenda hay que poder guardar varios datos de los contactos del cliente:

• Nombre del contacto
• Foto del contacto: Tenemos que poder guardar una imagen del contacto.
• Números de teléfono. Cada contacto de la agenda pueden tener varios y se les puede asociar una etiqueta para saber si es del trabajo, móvil, casa, personal (se pueden añadir nuevas etiquetas)
• Redes sociales. Youtube, Instagram, Twitter, etc… guardamos el nombre de la red social, el nombre de usuario en la red social y un enlace al perfil en la red social
• Ubicaciones de interes: Latitud, longitud y nombre del sitio (trabajo, casa, casa del pueblo, etc…)
  Se debe exponer una API con los principales casos de uso:
• Registrar un cliente
• Editar datos de un cliente
• Borrar un registro de cliente
• Crear contacto para un cliente
• Editar contacto de un cliente
• Borrar contacto de un cliente
• Obtener datos de un contacto
• Obtener todos los contactos de un cliente paginados y que permita ordenar por nombre

[jonatan]

@Rodri — Ejecutando las pruebas, aprobado por @jonatan

[djsluisitos]

el mejor modelo para programar es el qwen3.6:35b (si ves que no funciona prueba el qwen3.6:27b)

repite las pruebas del usuario @Rodri usando este modelo y haz tabla comparativa con resultados.

[jonatan]

@djsluisitos — Ejecutando las pruebas, aprobado por @jonatan

[djsluisitos]

en resumen, para cosas serias el hardware local no está preparado ni de lejos, por muchas NPU y procesadores especiales para IA que nos quieran vender.
7. Diseño de UI: dashboard local para OpenClaw

Otra prueba que me parece muy interesante sería medir cómo se comporta cada modelo generando interfaces reales, no solo texto o comandos.

La idea sería probar todos los modelos que han ido saliendo en este post desde el primer comentario y pedirles exactamente lo mismo:

Vamos a probar diseño de UI con IA local.

Para cada modelo probado en este hilo, crea un dashboard para monitorizar el propio host donde está corriendo OpenClaw.

Objetivo:
crear una interfaz clara, moderna y útil para ver el estado del servidor local.

El dashboard debe incluir:

- carga actual de CPU
- porcentaje de uso de CPU
- porcentaje de uso de RAM
- RAM usada / RAM total
- ancho de banda de subida
- ancho de banda de bajada
- velocidad en tiempo real de subida
- velocidad en tiempo real de bajada
- espacio en disco usado / total
- espacio en disco restante
- top 5 procesos que más CPU consumen
- top 5 procesos que más RAM consumen
- estado de servicios críticos
- uptime del host
- temperatura si está disponible
- tarea actual de OpenClaw
- último resultado de la tarea de OpenClaw
- logs recientes relevantes
- alertas activas
- ping cloudflared y router

La prueba no sería solo ver si genera una pantalla bonita, sino si es capaz de diseñar algo usable de verdad.

Prueba 21: dashboard estático de diseño

Primera prueba, sin backend real:

Crea un dashboard visual para monitorizar el host local de OpenClaw.

Condiciones:

- no uses servicios cloud
- no uses APIs externas
- usa datos simulados
- diseño limpio y moderno
- responsive para escritorio y móvil
- prioriza claridad frente a efectos visuales
- muestra métricas críticas arriba
- usa tarjetas, gráficas y tablas
- incluye estados tipo OK, warning y critical
- incluye una sección para la tarea actual de OpenClaw
- incluye una sección de logs recientes

Aquí mediría:

- calidad visual
- jerarquía de información
- legibilidad
- diseño responsive
- si la UI parece usable en producción
- si entiende qué métricas importan en un servidor local

Prueba 22: dashboard funcional con backend local

Segunda prueba, más real:

Crea un dashboard funcional para monitorizar el host local de OpenClaw.

Debe tener:

1. frontend
2. backend local
3. endpoint para métricas del sistema
4. actualización automática cada pocos segundos
5. sin servicios externos
6. sin telemetría
7. instrucciones de instalación
8. instrucciones de ejecución

Métricas mínimas:

- CPU %
- load average
- RAM usada / total
- disco usado / total
- red subida/bajada en tiempo real
- top procesos por CPU
- top procesos por RAM
- uptime
- servicios activos
- tarea actual de OpenClaw

Lo ideal sería que generase algo tipo:

Frontend:
- React / Vue / HTML simple

Backend:
- Python FastAPI
- Node.js Express
- Bash + endpoint local
- lectura desde /proc, ps, df, free, systemctl, etc.

Aquí se vería si el modelo sabe pasar de “diseño bonito” a herramienta útil.

Prueba 23: dashboard para técnico y cliente

Otra prueba interesante sería pedir dos modos de vista:

Crea dos vistas del dashboard:

1. Vista técnica
2. Vista cliente

Vista técnica:
- métricas completas
- procesos
- logs
- consumo
- servicios
- errores
- detalles de red
- estado de OpenClaw

Vista cliente:
- estado general
- servidor funcionando / no funcionando
- Internet OK / fallo
- servicios activos
- última revisión
- incidencias detectadas
- mensaje claro y no técnico

Esto es muy útil porque no es lo mismo un dashboard para administrar que uno para enseñar a un cliente.

Prueba 24: dashboard con alertas inteligentes

Añade lógica de alertas al dashboard.

Debe detectar:

- CPU alta sostenida
- RAM alta
- disco casi lleno
- pérdida de conectividad
- caída de un servicio crítico
- OpenClaw sin tarea activa durante demasiado tiempo
- OpenClaw ejecutando una tarea demasiado larga
- errores recientes en logs
- tráfico de red anómalo

Clasifica alertas en:

- informativa
- aviso
- crítica

No quiero alertas ruidosas. Quiero pocas alertas, pero útiles.

Aquí mediría si el modelo entiende monitorización práctica o solo pinta tarjetas rojas.

Prueba 25: dashboard con integración Uptime Kuma / Wazuh / Lynis

Prueba más avanzada:

Amplía el dashboard para incluir información de:

- Uptime Kuma
- Wazuh
- último informe Lynis
- estado de Nginx Proxy Manager
- estado de servicios publicados
- certificados SSL
- alertas recientes
- incidencias abiertas

Secciones sugeridas:

1. Estado general
2. Recursos del host
3. Red
4. Servicios
5. OpenClaw
6. Seguridad
7. Certificados
8. Incidencias
9. Logs
10. Recomendaciones

Aquí sería interesante ver si el modelo puede unificar información técnica dispersa en una sola UI entendible.

Prueba 26: tarea actual de OpenClaw

Una parte muy interesante sería representar la tarea actual del agente.

Ejemplo:

Añade una tarjeta llamada “Tarea actual de OpenClaw”.

Debe mostrar:

- estado: idle / running / error / waiting_confirmation
- nombre de la tarea actual
- hora de inicio
- duración
- herramienta que está usando
- última acción ejecutada
- siguiente acción prevista
- si requiere confirmación humana
- botón para ver detalles
- botón para cancelar tarea

Esto serviría para saber si el dashboard permite entender qué está haciendo el agente en cada momento.

Prueba 27: evaluación comparativa entre modelos

Para cada modelo probaría exactamente el mismo prompt y compararía:

- ¿ha creado una UI usable?
- ¿ha creado código ejecutable?
- ¿ha separado frontend y backend?
- ¿ha usado datos reales o solo inventados?
- ¿ha documentado cómo instalarlo?
- ¿ha incluido actualización en tiempo real?
- ¿ha incluido manejo de errores?
- ¿ha incluido alertas útiles?
- ¿ha tenido en cuenta seguridad local?
- ¿ha evitado dependencias cloud?
- ¿ha generado una interfaz responsive?
- ¿ha sabido representar la tarea actual de OpenClaw?

Puntuación propuesta:

Diseño visual: 0-5
Usabilidad: 0-5
Código ejecutable: 0-5
Monitorización real: 0-5
Seguridad local: 0-5
Claridad para técnico: 0-5
Claridad para cliente: 0-5
Calidad del responsive: 0-5
Manejo de errores: 0-5
Documentación: 0-5

Prueba 28: prompt único para comparar modelos

Prompt completo:

Crea un dashboard local para monitorizar el host donde está corriendo OpenClaw.

Requisitos:

1. Debe funcionar en local.
2. No debe depender de servicios cloud.
3. Debe tener una interfaz moderna, limpia y responsive.
4. Debe mostrar métricas reales del sistema si es posible.
5. Debe actualizar datos automáticamente.
6. Debe incluir modo técnico y modo cliente.
7. Debe incluir alertas útiles, no ruidosas.
8. Debe incluir estado de la tarea actual de OpenClaw.
9. Debe incluir instrucciones de instalación.
10. Debe incluir instrucciones de ejecución.
11. Debe explicar qué permisos necesita y por qué.
12. Debe ser seguro para ejecutarse en una red local.

Métricas obligatorias:

- carga de CPU
- porcentaje de uso de CPU
- porcentaje de uso de RAM
- RAM usada / total
- ancho de banda de subida
- ancho de banda de bajada
- velocidad en tiempo real de subida
- velocidad en tiempo real de bajada
- espacio en disco restante / total
- top 5 procesos por CPU
- top 5 procesos por RAM
- uptime del host
- estado de servicios críticos
- tarea actual de OpenClaw
- últimos logs relevantes

Entrega:

- código completo
- estructura de carpetas
- instrucciones de instalación
- instrucciones de ejecución
- explicación breve de la arquitectura
- capturas o descripción visual del dashboard
- posibles mejoras futuras

Para mí esta prueba sería clave porque obliga al modelo a combinar:

- diseño UI
- monitorización Linux
- backend local
- frontend usable
- tiempo real
- seguridad
- documentación
- pensamiento de producto

Y además permitiría comparar muy bien qué modelo local sirve de verdad para crear herramientas internas útiles.

[tasete30]

Quizás sería interesante conectar una gráfica por oculink a este equipo y pasarle algunas de las pruebas.

Sería interesante mostrar hasta donde pueden llegar estos equipos actualmente y si merece la pena ampliar con una tarjeta externa y que ventajas obtendriamos.

No he visto todas las pruebas, pero estaría bien incluir generación de video e imágenes.

Te va mejor ollama que llama.cpp?

[jonatan]

lamentablemente no tengo GPU externa

[lastsquat]

Video de como lo has configurado, sería muy útil para los que tenemos hardware similar.

[mgdelafuente]

Para el que le pueda interesar cuento mi caso:

Tengo un Aoostar GEM12 con la eGPU Aoostar AG01 con una rx9060xt 16GB conectada por Oculink.

Elegi esa gpu porque AMD es prácticamente plug and play en linux y es la gpu de la actual generación que te ofrece 16gb por menos dinero.

Después de muchas pruebas, en mi caso llegué a la conclusión de que incluso con una gpu full soportada me daba mucho mejor rendimiento Vulkan que ROCm. Por otro lado, una vez tienes claro el modelo creo que es mejor compilar llama.cpp ya que tiene muchos settings que en ollama veo mas complejo de gestionar como las cuantificaciones de la cache y los tamaños.

En la igpu uso un modelo muy pequeño porque solo tengo un slot de ram y al no aprovechar el dual channel era la única forma de llegar a 25t/s (lo uso como asistente de voz).

Una duda general a ver si alguien me puede decir, como hacéis para darle acceso a home assistant? Le dais un usuario Admin? O existe alguna forma de no darle todos los privilegios a la IA?

[luismipr]

Yo le tengo acceso con el token de larga duración… Con agente local…

Nunca se sabe que puede pasar, las pruebas que estoy haciendo, de momento van bien, pero ojo cuidao!!!

Salu2.

[mgdelafuente]

Pero hay forma de caparle un poco los permisos? Por ejemplo, que solo pueda crear automatizaciones y ver estados pero no crear otros usuarios o borrarlos