When more concurrency makes a local model less responsive

Mean job time · one lane

10.451 s

Mean job time · two lanes

18.399 s

The question

Which context, reasoning budget and concurrency settings make local GPT-OSS usable?

How the work was approached

Compared LM Studio CLI/API, context sizes and fixed ten-job conveyor runs; preserved request-level CSV and answers.

What the record shows

In the final fixed-budget comparison, two concurrent jobs increased individual latency despite slightly lower recorded batch wall time. The selected ordinary-use profile kept one conveyor lane. API visible content was used to avoid exposing separate reasoning output.

What remains unresolved

Short prompt set, historical runtime, no isolated decode timing or general quality proof. Batch wall times are source-note observations; mean job metrics were independently recomputed from CSV.

What we are trying to achieve

The goal is a local assistant that feels responsive during real work. This experiment helps distinguish fast queue completion from the wait a person experiences for each answer. A future matched comparison would repeat the same tasks and score answer quality alongside latency.

Sources & reading notes

1. GPT_OSS_20B_TUNING.mdPhase 2 Context And Concurrency / Final phase 2 comparison Retained project record Source record retained privately.
2. results.csv10 raw job rows, reread and recomputed Retained project record Source record retained privately.
3. results.csv10 raw job rows, reread and recomputed Retained project record Source record retained privately.
4. lmstudio-conveyor-worker.ps1EstimatedTokensPerSecond calculation Retained project record Source record retained privately.

This is a dated, source-based research account, not a live machine report. Historical results, engineering preparation, research designs, open review gates, and measured pilots remain distinct.