Request for Historical Evaluation Manifests for LFM2.5 Benchmark Reproduction

#15
by chase-jay - opened

Hello Liquid AI team,

We are independently reproducing the benchmark results published for LFM2.5-2.6B and the accompanying Gemma-4 and Qwen3.5 comparisons.

We treat the published values only as comparison targets. Our reproduced scores are recorded separately, and every undisclosed field remains marked as UNKNOWN rather than being inferred as an official setting.

Could you please share or confirm the exact historical evaluation manifests used for the published tables?

  1. Global runtime
    Exact model revisions
    vLLM, PyTorch, and CUDA versions/commits
    GPU type, dtype, tensor parallelism, and quantization
    gpu_memory_utilization, concurrency, and scheduling configuration
    Complete model-server commands
  2. Generation configuration
    Full prompt/chat template for each benchmark
    Thinking/reasoning settings
    Reasoning and tool parsers
    temperature, top_p, top_k, min_p, and penalties
    Seed, number of runs, retries, stop sequences, and timeout
  3. Benchmark-specific manifests
    BFCLv4: effective temperature, runtime, handlers for all five models, repository commit, aggregation procedure, and raw category CSVs
    IFStruct: evaluator/dataset commits, Qwen thinking setting, reasoning parser, and whether the validator received raw reasoning or final-answer text
    LiveCodeBench v6: prompt style, top_p, seed, and exact repository revision
    ToolSandbox: scenario list, user simulator, search backend, tool handler, and aggregation procedure
    BrowseComp+ and Claw-Eval: exact OpenClaw version/configuration, task list, retrieval/index settings, graders, judges, and trial aggregation
    Multi-IF, PinchBench, τ³-Bench, and AA Omniscience: exact historical revisions and run manifests

Two ambiguities we observed appear to be particularly score-critical.

First, Liquid's public BFCL stack requests temperature=0.001, while its pinned vLLM version clamps positive temperatures below 0.01 to 0.01. Our complete public-stack run contains 5,217/5,217 valid rows and scores 49.43%, compared with the published 56.88%.

Second, using the same Qwen3.5-4B checkpoint and seeds, we observed IFStruct scores of 86.00%, 61.50%, and 16.00% solely from changes to the thinking/parser response-boundary settings. The published value is 36.25%, so the exact historical generation and evaluation boundary is essential for reproducibility.

Redacted manifests, server commands, handler definitions, raw generations, or evaluator summaries would all be sufficient. If any details cannot be disclosed, confirmation of that would also be useful; we will keep those fields marked as UNKNOWN.

Sign up or log in to comment