Mi agente de IA creó una herramienta de evaluación para mis agentes de IA

El 2026-08-11 le pedí a mi agente de programación una herramienta que evaluara los modelos locales de mi pila de agentes. Me devolvió bench-llm: 1,660 líneas de Python que miden la velocidad en LM Studio, ejecutan el código que escribe un modelo y comprueban si el modelo puede realizar una pequeña tarea de agente. En dos semanas todos los modelos que me importaban obtenían 5/5, así que lo reconstruí como CrucibleForge: 251 casos, 158 de ellos difíciles, ahora de código abierto en GitHub. Esta página cubre ambos. Usa bench-llm para obtener un primer número de un modelo en cinco minutos. Usa CrucibleForge cuando necesites clasificar modelos que todos superan las pruebas fáciles.

¿Qué obtendrá al final?

Un único comando ejecutado contra un modelo produce esto (ejemplo de ejecución, abreviado):

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

  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Size:     16.5 GB     Quant: Q4_K_M

  ⚡ SPEED BENCHMARKS
    short_50    TPS: mean=84.2   TTFT: mean=0.231s
    medium_200  TPS: mean=85.7   TTFT: mean=0.312s
    long_800    TPS: mean=82.1   TTFT: mean=0.541s
  🔍 Validating speed plausibility...  Confidence: HIGH

  🧠 ABILITY TESTS
    Code Generation (median_of_list)... PASS
    Logic Puzzle (Pet Ownership)....... PASS
    JSON Compliance.................... PASS
    Instruction Following.............. PASS
    Summarization (Key Facts).......... FAIL
    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
    Task Acknowledgment / Format Adherence / Conciseness: PASS
    Agent Fitness Score: 3/3

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

El archivo JSON contiene todos los tiempos de ejecución, todas las respuestas del modelo y un resumen. Puede devolverlo a su agente y preguntarle: “¿cuál de mis modelos debería encargarse del procesamiento masivo de JSON?”

¿Qué pruebas realiza bench-llm?

Velocidad

Envía tres longitudes de prompts (aproximadamente 50, 200 y 800 caracteres), realiza ejecuciones de calentamiento y luego mide tres cosas. El TTFT (tiempo hasta el primer token) indica cuánto se espera hasta que aparezca el texto; más de 500 ms se percibe como lentitud en un chat. El Throughput (tokens/segundo) muestra la velocidad a la que escribe una vez iniciada la generación. El Prefill T/s indica cuán rápido lee el modelo el prompt.

También realiza una verificación de plausibilidad frente a los límites hardware conocidos. Si un modelo de 30 GB afirma alcanzar 200 T/s en una tarjeta 7900 XTX, bench-llm marca esa cifra como sospechosa, ya que probablemente la decodificación especulativa o un caché ya caliente hayan distorsionado el resultado.

Habilidad

• Generación de código: escribir median_of_list(numbers) manejando los casos límite. bench-llm ejecuta la función con seis casos de prueba en lugar de limitarse a leer el texto.
• Puzle lógico: un problema de asignación de mascotas entre cuatro personas. El verificador extrae las cuatro asignaciones del mensaje de respuesta.
• Cumplimiento JSON: devolver un objeto con claves exactas. Esto es lo mínimo que un modelo debe hacer para integrarse con herramientas externas.
• Cumplimiento de instrucciones: listar los números del 1 al 10, marcar los pares y sumarlos. El cálculo matemático es sencillo; lo importante es el formato solicitado.
• Resumen: condensar un párrafo denso manteniendo seis datos específicos. La mayoría de los modelos omiten al menos uno.

Aptitud para agentes

Al modelo se le asigna una tarea realista para agentes: buscar líneas con ERROR en el syslog, agruparlas por servicio y devolver un informe en formato JSON. Tres criterios evalúan esa única respuesta:

• Reconocimiento de la tarea: ¿describe el modelo un enfoque y señala lo que no puede hacer? Un modelo que inventa líneas de syslog es rechazado.
• Cumplimiento del formato: ¿existe el array services, el entero total_errors y la cadena scan_period?
• Concisión: relación entre longitud de salida e input. Una respuesta de 20,000 caracteres para un prompt de 1,300 se marca como VERBOSE, pues un agente que divague agota su ventana de contexto en cada interacción.

Cómo se construyó

Mis instrucciones para el agente de programación fueron una sola frase: “Necesito una herramienta que haga benchmarking de modelos locales en LM Studio, mida su velocidad y capacidades, y genere resultados en formato JSON y en forma de tabla”. El agente creó la herramienta en cuatro fases durante una sola tarde: primero realizó pruebas de velocidad mediante la API de streaming compatible con OpenAI que ofrece LM Studio; luego probó las capacidades del modelo; después ejecutó las tareas asignadas; y finalmente realizó los ajustes necesarios (como localizar el archivo GGUF en el disco, verificar su validez, y gestionar las opciones --quick, --list y --check). El agente escribió cada línea de código. Mi labor consistió en ejecutarla con modelos reales y darle retroalimentación. La verificación de validez existe porque le indiqué al agente que un determinado valor de rendimiento era imposible para un modelo de 123 mil millones de parámetros.

Decisiones de diseño que merece la pena copiar en sus propias herramientas:

• Hagan streaming, no consultas periódicas. Medir el tiempo por cada token es la única forma de obtener un valor preciso del TTFT.
• Ejecuten el código. Un código que parece correcto pero no se ejecuta se considera un fallo, no un éxito.
• Extraigan la respuesta antes de verificarla. Los mecanismos de verificación eliminan los textos introductorios como “¡Claro! Aquí está su respuesta:”. De ese modo, la prueba puntúa el contenido real, no el preámbulo.
• Inicien cada ejecución con una GPU vacía. De lo contrario, el caché del modelo anterior distorsiona el valor del TTFT. La forma en que bench-llm logra esto es el primer “truco” que mencionaré a continuación.

Configuración

# 1. Install both dependencies (requests reads LM Studio's model metadata;
#    without it every model shows as "not found")
pip install openai requests

# 2. Start LM Studio with at least one model; it listens on localhost:1234

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

No hay archivos de configuración ni base de datos. LM Studio acepta cualquier cadena de texto como clave de API. Los resultados se guardan en ~/benchmarks/. Si desea ejecutar el script desde cualquier lugar, cópielo en una carpeta que esté incluida en su PATH.

Posibles problemas

• Interrumpe el funcionamiento de llama-server. Al iniciar cada ejecución, limpia el entorno ejecutando pkill -f llama-server y espera a que LM Studio indique que no hay modelos cargados. Cualquier instancia de llama-server en la máquina también se detiene. No lo ejecute en un equipo que sirva otros servicios; de lo contrario, elimine ese paso.
• La prueba de codificación ejecuta la salida del modelo mediante exec(). Utiliza un espacio de nombres nuevo, que no constituye un entorno aislado. Ejecútelo como un usuario sin nada que perder, o bien omita las pruebas de capacidades usando --speed-only.
• Los modelos de razonamiento parecen ser lentos. El valor TTFT cuenta el primer token de cualquier tipo, incluidos los tokens de razonamiento. El formato JSON lo divide en ttft_reasoning_s y ttft_content_s.
• Una puntuación de 4/5, con solo el test de resumen fallando, es un resultado excelente. Casi todos los modelos omiten al menos un dato importante.
• Una ejecución completa tarda entre 2 y 5 minutos por modelo. Use --quick para comparar varios modelos, y luego ejecute el conjunto completo de pruebas con los finalistas.
• LM Studio debe estar ya en ejecución. El script bench-llm se conecta a localhost:1234 y no inicia nada por sí mismo.

Resultados: modelos base en mi equipo y mini PC

Estas cifras provienen del conjunto de pruebas intermedio que siguió a bench-llm (mismo método de medición de velocidad, más pruebas; informe fechado el 18-08-2026). “Equipo” se refiere a una caja GPU sin pantalla que cuenta con 2× RTX 5090 y 2× RTX 3090. “APU” es la GPU integrada del mini PC (cuando aún ejecutaba un servidor de modelos locales). Comparen las velocidades únicamente dentro de cada dispositivo. Los valores de “Code”, “Tools”, “Instruct” y “Reason” representan los porcentajes de éxito en dichas tareas.

El modelo Gemma 4 26B de tipo “mixture-of-experts” (con 4 mil millones de parámetros activos) es el caballo de batalla en el equipo: genera 229 tokens por segundo, tarda 110 ms en producir el primer token y logra un 100% de éxito en la ejecución de tareas relacionadas con herramientas. Su punto débil es el cumplimiento de instrucciones, algo fundamental para el funcionamiento de bucles de IA no supervisados. En cambio, el modelo Nemotron 3 Nano 4B, que corre en el mini PC, sigue mejor las instrucciones (94% frente a 50%). No obstante, es unas doce veces más lento (18,5 frente a 229 tokens/s) y funciona en un dispositivo distinto. Elijan el modelo según la columna que sea crítica para su carga de trabajo, no basándose únicamente en la velocidad máxima.

¿Qué lo reemplazó? CrucibleForge

bench-llm dejó de ser útil debido a su propio éxito: cinco pruebas de capacidad bastan para evaluar un modelo, pero también hacen que la herramienta no tenga nada más que decir cuando todos los modelos obtienen puntuaciones perfectas. CrucibleForge es la reescritura de esa herramienta. Consta de unas 9.400 líneas de código Python, y su principio fundamental es que una pregunta difícil debe seguir siendo fácil de calificar.

• 158 casos difíciles. Problemas matemáticos de competición con respuestas numéricas, problemas lógicos cuyas soluciones son únicas, y ejercicios de programación cuya complejidad debe cumplir ciertos requisitos (por ejemplo, un algoritmo de conteo de inversiones O(n²) excede el tiempo permitido). También incluye casos que ponen a prueba el uso de herramientas y la resistencia a inyecciones de prompts; además, se incluyen tareas de recuperación de información en contextos largos (de 12k a 24k tokens) e instrucciones con múltiples restricciones.
• El código se califica ejecutándolo en un entorno aislado bwrap sin conexión a red, con sistema de archivos de solo lectura y límite de 15 segundos. Para ser aprobado, el programa debe imprimir una cadena específica en la salida estándar; de lo contrario no puede falsear un resultado exitoso simplemente terminando con código de retorno cero. Si no se cuenta con bwrap (situación habitual en macOS y Windows), el sistema se niega a ejecutar el código del modelo a menos que se utilice el parámetro --allow-unsandboxed.
• Las respuestas en prosa cuentan con una respuesta de referencia. El modelo juez visualiza dicha respuesta y decide si la respuesta del modelo evaluado transmite el mismo significado. Cualquier modelo de instrucciones decente puede realizar esa tarea, por lo que el modelo juez ya no constituye un punto débil en el proceso de evaluación.
• Cualquier endpoint compatible con OpenAI. Funciona con LM Studio, Ollama, llama.cpp, vLLM, DeepSeek, OpenRouter y otros. Los modelos alojados procesan los casos de forma concurrente e informan sobre el costo en tokens. Las claves API se obtienen exclusivamente mediante variables de entorno.
• Recupera respuestas que los modelos de razonamiento pierden. Un modelo de razonamiento que agota su presupuesto de tokens al pensar genera una respuesta vacía. El sistema lo detecta, vuelve a enviar el mismo caso sin activar la función de razonamiento y registra cuántas veces ocurre esto. La función recover vuelve a ejecutar únicamente esos casos a partir de una ejecución previa.
• Comparte las GPU de manera equitativa. En mi equipo StudioForge, cada ejecución solicita exclusivamente las tarjetas gráficas que necesita y las libera al finalizar. El antiguo bench-llm empleaba el comando pkill para resolver el mismo problema, pero eliminando todos los modelos en ejecución.
• Interfaz web disponible en 127.0.0.1:8777: permite seleccionar modelos y categorías, visualizar el registro de ejecución y abrir cualquier caso fallido para consultar el prompt, la respuesta, el razonamiento del modelo y las observaciones del juez. Para que funcione fuera de la interfaz local, se requiere un token de autenticación.

Pruébelo

git clone https://github.com/LaserLloyd/CrucibleForge.git crucibleforge
cd crucibleforge
uv sync
uv run crucibleforge config --init      # writes models.yaml; add your provider and model
uv run crucibleforge status             # is the provider up? how many cases?
uv run crucibleforge all --profile standard --models my-model --yes
uv run crucibleforge gui                # http://127.0.0.1:8777

El perfil standard contiene una selección fija de 56 casos, dimensionada para completarse en menos de una hora en un modelo de 27 mil millones de parámetros con una velocidad de generación de aproximadamente 70 tokens por segundo, incluyendo la calificación. Es una ejecución que se puede permitir repetir sin problemas. Además, este perfil se divide en dos: coding no requiere modelo juez, mientras que chat incluye los casos que sí necesitan esa evaluación. Los demás comandos disponibles son run, judge, recover, report, pairwise, models, import-openclaw y cases.

El comando en el que más confío es el que verifica directamente los enunciados de los problemas. Este ejecuta todas las soluciones de referencia en el entorno aislado, vuelve a calcular por fuerza bruta cada respuesta matemática y reconstruye cada estructura de contexto largo. Este es su resultado del 16 de septiembre de 2026:

$ uv run crucibleforge cases verify
251 cases checked, 0 with problems (36 reference solutions executed, 35 answers re-derived)

El conjunto de pruebas (335 casos) realiza la misma verificación, por lo que un enunciado erróneo no puede pasar desapercibido ni hacer que todos los modelos fallen silenciosamente o sean calificados como “difíciles” sin más.

Cómo se ve un informe

La función report genera un archivo Markdown y uno en formato JSON. Cada modelo cuenta con una fila de resumen y otra por categoría que detalla los conteos brutos. A continuación se muestra la fila correspondiente a DeepSeek V4 Pro:

| Model        | Coding      | Math        | Tool use    | Instruction  | Reasoning    | Long-context |
| deepseek-pro | 89% (54/61) | 95% (21/22) | 94% (31/33) | 100% (31/31) | 100% (37/37) | 97% (29/30)  |

Se enumeran todos los fallos junto con su motivo. Los siete errores de tipo “coding” son similares al primero que aparece abajo; el segundo ejemplo corresponde a uno de sus dos casos en los que no utilizó correctamente las herramientas disponibles:

- deepseek-pro [coding] CZ01-prime-census: TRUNCATED at 32768 tokens (32768 reasoning tokens); no code in response
- deepseek-pro [tooluse] TZ06-three-parallel-one-turn: 1 calls, expected 3

Esto es lo realmente útil: el modelo no generó código deficiente; simplemente pensó hasta agotar su límite de 32.768 tokens y no escribió nada. Un presupuesto mayor o un nivel menor de esfuerzo en el razonamiento habrían cambiado ese resultado. La tasa de aprobación por sí sola no permitiría detectar tal situación.

Resultados en el nivel difícil

Estos son los resultados de las pruebas completas: todos los 251 casos, o casi todos. El porcentaje “Difícil” representa la tasa de éxito en los casos objetivo considerados difíciles (154 de los 158; los otros cuatro se evalúan por separado). Las cifras correspondientes a Código, Matemáticas y Herramientas indican las tasas de éxito en todos los casos de cada categoría. He omitido las filas provenientes de pruebas con 56 casos, ya que solo abarcan 38 casos difíciles y no son comparables. También he excluido las puntuaciones relativas a juegos de rol y contenido para adultos que figuran en el informe completo, ya que no son relevantes para el trabajo con agentes IA.

Los nombres en minúsculas corresponden a versiones modificadas por la comunidad; se listan según sus etiquetas oficiales. Las filas sin marcas fueron generadas nuevamente el 16-09-2026 a partir de los archivos de prueba guardados. Las pruebas abarcan varias revisiones del conjunto de casos, por lo que pequeñas diferencias en los porcentajes pueden considerarse ruido estadístico. ¹ Datos extraídos del informe del 25-08-2026; pruebas posteriores con 56 casos reemplazaron estos resultados completos. En una versión anterior de esta página, V4 Flash aparecía con un resultado de 272/308: se habían contado dos pruebas completas bajo la misma etiqueta; el valor de $0.331 corresponde a una sola prueba. ² MiniMax M3 es el modelo alojado por MiniMax. No se evaluó un caso, y el costo indicado es estimativo: tengo un plan con tarifa fija; la cifra utiliza la tasa de referencia de mi archivo de registro ($0.255/$1.02 por millón de tokens de entrada/salida). Según la lista de precios oficial de MiniMax ($0.60/$2.40), el costo real sería aproximadamente 2.4 veces mayor; con la promoción actual de mitad de precio, sería alrededor de 1.2 veces superior. ³ Estos modelos procesaron 140 de los 154 casos difíciles; para los demás se necesitó más contexto del que podían manejar.

Lo que deduzco de todo esto:

• El modelo líder alojado cuesta aproximadamente un dólar por ejecución. V4 Pro superó 143 de los 154 casos difíciles por $1.10. Es un precio suficientemente bajo como para volver a ejecutarlo siempre que los resultados locales parezcan demasiado buenos.
• Un modelo de 27 mil millones de parámetros en tu propio hardware puede acercarse mucho. Qwen3.8 27B logró un resultado de 135 casos, solo dos puntos por debajo de V4 Flash, y además genera tokens 1.7 veces más rápido.
• La velocidad no predice necesariamente la capacidad del modelo. MiniMax M3 es el modelo alojado más rápido, con 212 tokens/s, pero solo alcanza un 85% de éxito; su punto débil son las matemáticas (77%). joyfox-35b-rp, por su parte, genera tokens a 319 tok/s y obtiene un 75% de aciertos.
• Modificar un modelo puede perjudicar sus capacidades de programación. El modelo Qwen3.8 27B tras ser modificado cayó al 62% en tareas de programación, frente al 85% que lograba el modelo original.
• La capacidad de manejar contextos largos por sí sola no indica gran cosa. Los modelos de 1.5 mil millones, 7 mil millones y 256 millones de parámetros aún logran resolver la mayoría de los casos (83%, 80% y 56%, respectivamente), a pesar de sus bajos resultados en programación y matemáticas.

Descarga

El archivo descargable es bench-llm, la versión original ya retirada; no se trata de CrucibleForge (que se encuentra en GitHub). El archivo ZIP contiene dos ficheros: bench-llm, el script de 1.660 líneas, y README.md, con instrucciones resumidas para la configuración. No hay nada que compilar ni instalar aparte de estos dos archivos: simplemente descomprima y ejecútelo. El agente generó ambos ficheros, los cuales están bajo licencia MIT. Las dependencias necesarias son openai y requests. Lea la sección de posibles problemas antes de ejecutarlo en una máquina que sirva otros servicios.

Relacionado: StudioForge (el servidor con GPU del cual estos modelos obtienen sus tarjetas gráficas), Cuánto cuestan realmente mis agentes de IA (por qué la velocidad local es importante), DeepSeek Harness (un agente de programación respaldado por estos modelos) y el stack de agentes de IA local en el que se ejecutan.

Descargas

• Download bench-llm, the original single-file script (zip — retired, still works) 18 KB

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