Inference Notes · Paper Deep Reads

中文

← All notes

Measuring the Serving Stack Instead of the Model: Hidden Confounds in Local Tool-Use Evaluation

Lijuan Tang, Yuemeng Zheng · Northeastern University, Seattle

ProblemLocal serving stacks silently confound tool-use evaluation by rejecting or altering requests before they reach the model, leading evaluators to misattribute infrastructure failures to model incompetence.

VerdictThe paper demonstrates that 0% tool-use rates are often artifacts of the serving stack rather than model inability. However, the measurements suffer from extremely small denominators and high variance, meaning the numbers highlight the serving confound but cannot reliably rank model capabilities.

AgentInference
Published · arXiv 2609.26693 · Code
Read2026-09-23
TrustHigh confidence in mechanism and measurement caveats, but authors explicitly state their results do not support cross-model capability rankings.
CoverageFull LaTeX source, all 1 files incl. appendix given in full; 2 of 2 figures viewed by the reader
Read byGemini 3.1 Pro · independently audited

1. Task

What problem is being solved, in concrete terms (inputs, outputs, setting). The paper investigates how local serving stacks (like Ollama, llama.cpp, vLLM, SGLang) evaluate and handle tool-use requests from coding agents before they are passed to the model. In a standard local agent setup, a harness sends a request containing a prompt and a tool schema (tools=). The server must route this request, format it, and parse the response into a structured tool_call.

Why it matters and why it is hard. This protocol step is critical but often conflated with model capability. If the server fails to handle the tools= request or fails to parse a valid model output, it usually returns an error string to the harness. Typical per-turn analyses read these transport errors as ordinary non-call responses from the model, leading to silent contamination of the measurement. It is difficult to measure true model capability when the intervening software layer alters or rejects the request independent of the model's weights.

What prior approaches do and where they fall short. Prior benchmarks like BFCL evaluate function calling but do not treat the serving interface itself as an experimental variable. Agent harnesses generally record the assistant message stream but fail to preserve structured error metadata (like HTTP 400 rejection). Thus, when a model like Phi-3 or Gemma-3 is evaluated, it may score 0% fidelity not because it lacks capability, but because the serving layer rejected its native tool-call request entirely, an issue previous benchmarks failed to isolate.

2. Core idea

The core insight is that in local tool-use evaluation, the serving stack—not just the model—determines whether a tool-call request succeeds. By separating the tool channel (native tools= vs. prompt text) and probing different serving backends, the authors show that a "0% tool-use capability" often means the serving layer simply refused the request or failed to parse the response, misattributing an infrastructure failure to model incompetence.

3. Mechanism + mental model

The paper isolates serving layer confounds using three configurations on a fixed aggregation task (8 seeds per model):

  1. Native: Harness sends default tools= request. Ollama gates this per model (e.g., Llama-3.2 gets native calls; Qwen gets text; Phi-3/Gemma-3 are rejected with HTTP 400).
  2. Native+hint: tools= is sent, plus a text tool list and explicit JSON format injected into the prompt.
  3. Text-tools: tools= is dropped; uniform text guidance is provided, and calls are parsed from text.

Mental model: The serving layer is an opaque gatekeeper: if the model is not on the server's VIP list for native tools, the request bounces before reaching the weights, but the harness records it as the model choosing to do nothing.

4. Metrics / data

5. vs. baseline

The paper does not propose a new model or method, but compares standard serving setups against control configurations.

6. Open source

Code is released at https://github.com/LijuanTang94/serving-confound-repo

7. Key numbers, verified

Claim Where (§/Tab/Fig) Actual condition Holds? (✅/⚠️/❌) Note
Phi-3 and Gemma-3 reported at 0% due to native rejection §1, §4, Table 1 Ollama native FC 100% of turns are rejected HTTP 400 requests. Holds specifically for the Ollama version tested (0.30.8).
Adding text hint to native channel recovers most fidelity for accepted models §4, Fig 3, Table 1 Qwen 0.5B-14B, Llama-3.2 Jumps from 0-60% to 35-89% per-seed. The gain is substantial, though absolute magnitudes remain noisy.
Uniform text protocol lowers fidelity for Llama-3.2 §4, Fig 3, Table 1 Llama-3.2-3B Drops from 82% (native+hint) to 44% (text-tools) as the text parser discards its native capability.
Turn-pooled vs per-seed estimates differ by up to 55 points Abstract, §4, Table 1 Qwen-0.5B text-tools ⚠️ True, but this 51-56 point difference is an extreme outlier driven by a single 41-turn looping episode, not typical variance.
Constrained decoding removes protocol failure but induces non-termination §4 All 9 local models ⚠️ 100% valid 1-step holds for all 9 models, but the 600-900 turn infinite loops only occur on the weaker models, not all 9.
Same weights rejected by Ollama run on llama.cpp §4, Table 2 Phi-3, Gemma-3 llama.cpp handles them with 200 text/native.

8. What the abstract doesn't say

9. Reachability + takeaways

10. Confidence + next steps

11. Audit