bench

Plugin de composición para DeepSeek Harness (dsh) que expone una Tool para comparar latencia y tokens/segundo entre modelos, en el mismo prompt: bench_run.

Compara dos backends:

• LM Studio (local, API compatible con OpenAI — /v1/chat/completions).
• Ollama (local o modelos :cloud — API nativa /api/chat).

No shellea a nada — solo fetch() HTTP directo a los servidores locales.

Requisito

Los servidores que quieras comparar tienen que estar corriendo y accesibles (LM Studio en http://localhost:1234 por default, Ollama en http://localhost:11434). El plugin no los levanta ni los verifica de antemano — si un target no responde, esa fila del resultado queda ok: false.

Instalación

1. Dependencias locales:

   cd bench
   npm install
   

2. Montarlo en el perfil de dsh (~/.dsh/profiles/<perfil>/cordis.patch.yml):

   - insert:
       - id: bench
         name: 'file:///C:/ruta/a/bench/host.js'
   

3. Reiniciar el proceso de dsh para que cargue el plugin.

Tool

bench_run

Parámetro	Tipo	Requerido	Descripción
prompt	string	sí	Prompt idéntico para todos los targets.
systemPrompt	string	no	Aplicado a todos los targets.
lmStudioModels	array<string>	no	Ids de modelo a probar vía LM Studio (deben estar ya cargados ahí).
lmStudioBaseURL	string	no	Default http://localhost:1234.
ollamaModels	array<string>	no	Ids de modelo a probar vía Ollama, ej. "glm-5.3-flash:cloud".
ollamaBaseURL	string	no	Default http://localhost:11434.
maxTokens	integer	no	Tope de tokens de completion (solo afecta a los targets de LM Studio). Default 256.
timeoutMs	integer	no	Timeout por request. Default 180000 — los modelos de razonamiento locales pueden ser muy lentos (un solo dígito de tok/s), no asumir que un timeout corto significa que algo cuelga.

Corre los targets secuencialmente (no en paralelo): correrlos a la vez competiría por la misma GPU/CPU local y ensuciaría la medición de latencia.

Devuelve { ok, results: [{ backend, model, ok, latencyMs, promptTokens, completionTokens, tokensPerSec, error? }] }.

Decisiones de diseño (por qué está armado así)

• tokensPerSec/promptTokens/completionTokens son null, nunca undefined, cuando el dato no está disponible. dsh-tools valida que el valor devuelto por una tool sea JSON "lossless" y rechaza undefined como valor de propiedad (a diferencia de JSON.stringify, que lo descarta en silencio) — el error es "value is not lossless JSON". Encontrado en vivo durante la verificación de este plugin, no en la documentación.
• El tok/s de Ollama usa eval_duration cuando está, y cae a total_duration si no. Los modelos :cloud de Ollama (probado con gpt-oss:20b-cloud) no devuelven el desglose eval_duration/prompt_eval_duration que sí traen los modelos locales — solo total_duration. Sin el fallback, todo target :cloud reportaba tok/s n/d aunque la llamada hubiera funcionado bien.
• El tok/s de LM Studio se calcula con latencia de wall-clock, no con timing del servidor. /v1/chat/completions devuelve usage.completion_tokens pero el campo stats viene vacío — no hay timing propio que usar.
• Targets hardcodeados a estos dos backends (no una lista genérica de endpoints) — es lo que se necesitaba probar hoy; una lista de targets arbitrarios con schema propio (baseURL+apiStyle+model por objeto) hubiera requerido parámetros de tipo objeto anidado, evitados por precedente (ver la nota de schemas tipados en el README de kdd-gates).

Estado verificado

• lmStudioModels: ["lfm2.5-230m-tomoe"] contra LM Studio real: 64ms, 78.1 tok/s (5 tokens).
• ollamaModels: ["gpt-oss:20b-cloud"] contra Ollama Cloud real: 1407ms, 82.6 tok/s (109 tokens), confirmando el fallback a total_duration.