Mi agente de IA le construyó una herramienta de benchmarks a mis agentes de IA

Mi agente de programación Hermes escribió una herramienta de benchmarks. Prueba la velocidad, la inteligencia y la aptitud como agente de mis modelos locales — los mismos modelos sobre los que corren otros agentes de IA — y escupe JSON y una tabla en terminal. La herramienta son 1.660 líneas de Python llamada bench-llm — un agente de IA le construyó una herramienta de benchmarks a agentes de IA.

Con qué terminas

Un comando contra un modelo te da esta forma de salida en tu terminal (ejecución de ejemplo):

$ bench-llm gemma-4-31b-it

============================================================
  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Status:   READY
  GGUF Path:     ~/.lmstudio/models/google/gemma-4-31b-it-Q4_K_M.gguf
  GGUF Size:     16.5 GB
  Arch:          gemma4
  Quant:         Q4_K_M
============================================================

  🔥 Warming up model... OK (0.23s TTFT)

  ⚡ SPEED BENCHMARKS
  ----------------------------------------
    short_50 (131 chars, 3 runs)...
      TPS:  mean=84.2 median=83.8
      TTFT: mean=0.231s median=0.228s
    medium_200 (323 chars, 3 runs)...
      TPS:  mean=85.7 median=85.2
      TTFT: mean=0.312s median=0.308s
    long_800 (769 chars, 3 runs)...
      TPS:  mean=82.1 median=81.5
      TTFT: mean=0.541s median=0.537s

  🔍 Validating speed plausibility...
    Confidence: HIGH

  🧠 ABILITY TESTS
  ----------------------------------------
    Running: Code Generation (median_of_list)... PASS
    Running: Logic Puzzle (Pet Ownership)... PASS
    Running: JSON Compliance... PASS
    Running: Instruction Following... PASS
    Running: Summarization (Key Facts)... FAIL

    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
  ----------------------------------------
    Running: Task Acknowledgment... PASS
    Running: Format Adherence... PASS
    Running: Conciseness (Output/Input Ratio)... PASS

    Agent Fitness Score: 3/3

  📄 Results saved: ~/benchmarks/gemma-4-31b-it-2026-08-11.json

================================================================================
  BENCHMARK RESULTS: gemma-4-31b-it
================================================================================

  📊 SUMMARY TABLE
  ──────────────────────────────────────────────────────────────────────
  Model ID                         gemma-4-31b-it
  GGUF Size                        16.5 GB
  Architecture                     gemma4
  Quantization                     Q4_K_M
  T/s (short, mean)                84.2
  TTFT (short, mean)               0.231s
  Ability Score                    4/5 (80.0%)
  Agent Fitness Score              3/3 (100.0%)
  Confidence                       🟢 HIGH
  ──────────────────────────────────────────────────────────────────────

También escribe un payload JSON completo en ~/benchmarks/ con cada medición en bruto, cada respuesta de test y un resumen estructurado — para que puedas volver a alimentar los resultados a tu agente y preguntarle "¿cuáles de mis modelos deberían encargarse del trabajo JSON masivo?".

Qué prueba

Tres dimensiones, cada una elegida porque importa para un stack de agentes siempre activo.

⚡ Velocidad

Tres longitudes de prompt — corto (~50 caracteres, "explica qué es una variable"), medio (~200 caracteres, "explica la recursión") y largo (~800 caracteres, "compara tres paradigmas de programación") — con tres ejecuciones de calentamiento seguidas de las mediciones reales.

Qué se mide:

• TTFT (Time To First Token) — cuánto tarda el modelo en empezar a escribir. Crítico para la UX del chat; cualquier cosa por encima de 500ms se siente lento.
• Rendimiento (tokens/seg) — qué tan rápido genera una vez que arranca. Importa para bloques de código largos y reportes.
• T/s de prefill — qué tan rápido procesa el prompt de entrada antes de generar. Un costo oculto pero real.

También ejecuta una verificación de plausibilidad contra los límites de hardware conocidos. Si tu modelo de 30 GB afirma 200 T/s en una 7900 XTX, bench-llm lo marca — ese número probablemente está contaminado por decodificación especulativa o una caché precalentada.

🧠 Capacidad

Cinco tests que son triviales para un modelo competente y un delator inconfundible para uno que va justo:

• Generación de código — Escribe median_of_list(numbers) con casos límite (lista vacía, longitud par, longitud impar, no mutar la entrada). La función se ejecuta dentro de bench-llm contra seis casos de prueba — no es comparación de patrones contra el texto de la respuesta, es código realmente ejecutándose.
• Acertijo lógico — Un acertijo de propiedad de cuatro mascotas (Alice/pez, Bob/pájaro, Carol/gato, Dan/perro). Una regex extrae las asignaciones de respuesta y verifica las cuatro.
• Cumplimiento de JSON — "Devuelve un objeto JSON con estas claves exactas." Prueba si el modelo puede producir JSON válido y conforme al esquema bajo demanda — el mínimo indispensable para llamadas a herramientas.
• Seguimiento de instrucciones — Escribe los números 1–10, marca los pares con *, súmalos. Prueba la adherencia precisa al formato: la respuesta es trivial, el formato es todo el punto.
• Resumen — Un párrafo denso sobre computación cuántica basada en helio. Comprueba si seis datos técnicos clave sobrevivieron a la compresión. La mayoría de los modelos suelta al menos uno.

🤖 Aptitud como agente

Aquí es donde bench-llm hace algo que no he visto en otras herramientas de benchmarks. Le envía al modelo una tarea de agente real — buscar líneas ERROR en syslog, agrupar por servicio, producir un reporte JSON — y evalúa la respuesta como lo haría un supervisor de agentes:

• Reconocimiento de tareas — ¿Entiende el modelo qué se le pidió? ¿Puede esbozar un enfoque e identificar obstáculos? (Un modelo que se lanza directo a alucinar entradas de syslog falla aquí.)
• Cumplimiento de formato — ¿La salida coincide con el esquema JSON pedido? Comprueba el array services, el entero total_errors y el string scan_period.
• Concisión — ¿Cuál es la proporción salida/entrada? Los modelos que responden a un prompt de 1.300 caracteres con 20.000 caracteres de divagación se marcan como VERBOSE. Un agente que no puede ser conciso te quema la ventana de contexto en cada turno.

Los tres tests de aptitud como agente comparten el mismo prompt — evalúan aspectos distintos de la misma respuesta. Esto mantiene el benchmark rápido mientras mide las cualidades que importan cuando un modelo corre sin supervisión.

Cómo se construyó

Hermes — el agente de programación de mi máquina — escribió todo. Le di una especificación aproximada: "Necesito una herramienta que evalúe modelos locales en LM Studio, pruebe velocidad e inteligencia, y produzca JSON y una tabla." Se fue, volvió con un script funcional, e iteramos.

El proceso fue:

1. Primer intento: solo tests de velocidad — conectar a la API compatible con OpenAI de LM Studio, hacer streaming de tokens, medir TTFT y T/s.
2. Segundo intento: tests de capacidad — programación (con ejecución real), acertijos lógicos, cumplimiento de esquema JSON, seguimiento de instrucciones, resúmenes.
3. Tercer intento: aptitud como agente — la tarea de syslog, evaluación de la respuesta como si el modelo fuera un agente de mi stack.
4. Pasadas de pulido: resolución de archivos GGUF (encontrar el archivo real del modelo en disco, reportar su tamaño y cuantización), validación de plausibilidad de velocidad, la tabla resumen, el modo --quick, --list para descubrir modelos, y el comando de pre-vuelo --check.

Las cuatro iteraciones ocurrieron en una sola tarde. El script final tiene 1.660 líneas. Cada línea la escribió Hermes — yo revisé, probé con modelos reales, señalé problemas ("este número de rendimiento no puede ser correcto para un modelo de 123B"), y él los arregló. El validador de plausibilidad nació exactamente de ese tipo de ciclo de retroalimentación.

Decisiones de diseño que se quedaron

• Streaming, no polling. bench-llm usa streaming compatible con OpenAI para obtener el tiempo por token. Un enfoque de polling difuminaría la medición del TTFT y perdería la granularidad a nivel de token.
• Ejecución real de código para el test de programación. No pregunta "¿esto parece una función de mediana?" — hace exec() del código en un namespace nuevo y ejecuta seis casos de prueba; la salida que se ve segura pero no corre, falla.
• Extracción de respuestas con regex para los tests de lógica/JSON. Los benchmarks que exigen un formato preciso fallan duramente con modelos que añaden "¡Claro! Aquí tienes tu respuesta:" antes de la salida real. Los verificadores de bench-llm extraen el payload de cualquier envoltorio que el modelo ponga alrededor — miden el contenido del modelo, no su verborrea.
• Limpieza de VRAM entre benchmarks. Ejecuta pkill -f llama-server y espera a que LM Studio muestre cero modelos cargados antes de cada ejecución. Sin esto, la caché KV de un modelo anterior puede contaminar la medición del TTFT del siguiente benchmark.
• Resolución de archivos GGUF. Mapea los IDs de modelo de LM Studio de vuelta a los archivos GGUF reales en disco usando coincidencia difusa por nombre de publicador y arquitectura. Esto te da el tamaño del modelo, la cuantización y si el archivo siquiera existe — respondiendo "¿este modelo está realmente listo para medir?" antes de desperdiciar una ejecución.

Configuración

Tres pasos:

# 1. Install the two dependencies (requests talks to LM Studio's model-metadata
#    endpoint — without it every model shows as "not found")
pip install openai requests

# 2. Make sure LM Studio is running with at least one model loaded
# (it should be listening on localhost:1234 — that's the default)

# 3. Run it
./bench-llm --list                         # see what's available
./bench-llm gemma-4-31b-it --quick         # smoke test
./bench-llm gemma-4-31b-it                 # full benchmark

Sin archivos de configuración, sin claves API (LM Studio acepta cualquier string), sin base de datos. Los resultados caen en ~/benchmarks/.

Opcional pero útil: copia bench-llm a tu PATH para poder ejecutarlo desde cualquier lugar.

cp bench-llm ~/bin/
chmod +x ~/bin/bench-llm

Resultados reales: modelos base en mi rig y mi laptop

Los números de abajo vienen de las suites sucesoras (mismo método de velocidad, conjunto de tests más amplio) y cubren solo modelos base — sin fine-tunes de la comunidad. "Rig" es una caja GPU sin cabeza, 2× RTX 5090 + 2× RTX 3090; "APU" es la GPU integrada de esta laptop. La velocidad solo es comparable dentro de un mismo dispositivo. Aplica la propia advertencia de las suites: las transcripciones abarcan varias revisiones, así que lee las diferencias pequeñas como ruido.

Velocidad + aptitud como agente (suite bench, reporte del 2026-08-18 — Code / Tools / Instruct / Reason son tasas de aprobación):

Nivel difícil (Gauntlet, 2026-08-19 — tasa de aprobación sobre los casos solo-difíciles; "—" = categoría no ejecutada para ese modelo):

Lo que yo saco de esto: el MoE Gemma 4 26B (4B activos) es el caballo de batalla diario del rig — 229 T/s, 110ms de TTFT, llamadas a herramientas perfectas — y su columna débil es el seguimiento de instrucciones, que es exactamente en lo que se apoya un bucle de agente sin supervisión. El Nemotron de 4B es la sorpresa: en una APU de laptop sigue instrucciones mejor que el 26B en el rig, solo que cinco veces más lento (18.5 T/s en APU vs 229 en el rig). En el nivel difícil, el Qwen3.8 27B base llega al 74% en programación, las filas de 1.5B y 256M muestran cómo se ve "demasiado pequeño para trabajo de agente", y la fila del V4-Flash en la nube es el techo que persiguen los modelos locales — a $0.088 por toda la ejecución difícil.

Qué lo hace diferente

Hay montones de benchmarks de LLM. La mayoría son conjuntos de acertijos académicos (MMLU) o trivia optimizada para leaderboards. bench-llm hace tres cosas que importan para alguien que realmente ejecuta modelos locales:

1. Prueba cualidades de agente, no cualidades de chatbot. El cumplimiento de formato, el reconocimiento de tareas y la concisión son lo que hace o rompe a un modelo en un bucle de agente sin supervisión. Un modelo genial conversando pero incapaz de seguir un esquema JSON es inútil en un flujo de trabajo de llamadas a herramientas.
2. Valida sus propias mediciones. El verificador de plausibilidad detecta números que no pueden ser correctos — contaminación por decodificación especulativa, cachés precalentadas, bugs de medición. Si una herramienta de benchmarks no puede decirte cuándo su propia salida es basura, no puedes confiar en nada de ella.
3. Es un solo script. Sin Docker, sin base de datos, sin dependencias de drivers de GPU, sin descarga de datasets de 50 GB. Un archivo Python, un pip install, y funciona contra lo que sea que tengas cargado en LM Studio ahora mismo.

Puntos de atención

• LM Studio debe estar ejecutándose primero. bench-llm no inicia LM Studio por ti — se conecta a localhost:1234. Si no hay nada escuchando, falla con un error claro.
• La limpieza de VRAM es agresiva. Ejecuta pkill llama-server entre benchmarks para limpiar la caché KV. Si tienes otros procesos llama-server que quieras mantener vivos, no ejecutes bench-llm — o modifica el paso de limpieza.
• El resumen es el test más difícil. Casi todos los modelos que he probado sueltan al menos un dato clave. Si un modelo puntúa 4/5 con el resumen como única falla, es un resultado fuerte — no lo leas como una deficiencia.
• Los modelos de razonamiento tienen TTFT más lento. Los modelos pensantes pasan tiempo en una fase de razonamiento antes de producir salida. bench-llm mide el TTFT desde el primer token de cualquier tipo — incluidos los tokens de razonamiento. Eso hace que los modelos de razonamiento se vean más lentos de lo que se sienten en la práctica, porque los tokens de pensamiento fluyen durante lo que de otro modo sería aire muerto. La salida JSON separa el TTFT en ttft_reasoning_s y ttft_content_s para que puedas ver la división.
• El test de programación hace exec() de la salida del modelo. Se ejecuta en un namespace nuevo con funciones de prueba puras — no es un sandbox real, así que ejecútalo como un usuario que no tenga nada que perder — pero si la idea de ejecutar código generado por LLM te incomoda, salta los tests de capacidad con --speed-only.
• Muchos modelos toman tiempo. Un benchmark completo en un modelo toma 2–5 minutos según la velocidad; unas pocas docenas es una noche. Usa --quick para comparaciones y guarda la suite completa para tus principales candidatos.

Descarga

bench-llm es un solo script de Python más un README. Sin paso de compilación, sin asistente de instalación — descomprime y ejecuta.

El zip incluye:

• bench-llm — el script de benchmarks de 1.660 líneas
• README.md — instrucciones condensadas de configuración y uso

Ambos archivos los escribió Hermes, mi agente de programación. Con licencia MIT — úsalo, modifícalo, inclúyelo en tu propio toolchain. Dependencias: openai y requests.

Relacionado: Cuánto cuestan de verdad mis agentes de IA (por qué importa la velocidad local), Reasonix y DeepSeek Harness (los agentes de programación que respaldan estos modelos), y el stack local de agentes en el que corren.

Descargas

• Descargar bench-llm (zip) 18 KB

Gratis para uso personal. Si te ahorra una tarde, el botón del café está aquí cerca.