bug: VLM structured output quality degrades under concurrent requests (conc >= 2)

[mdevk]

Summary

JSON validity of VLM structured extraction drops significantly under concurrent requests on oMLX v0.3.4. Even concurrency=2 shows consistent degradation.

Data

Three separate runs at each concurrency level, 20 photos each, Qwen3-VL-30B-A3B-Instruct-4bit, structured JSON extraction prompt, temperature: 0.1:

Concurrency Sweep (unpatched v0.3.4)

Concurrency	Run 1	Run 2	Run 3	Avg
1	100% (20/20)	—	—	100%
2	65% (13/20)	60% (12/20)	45% (9/20)	57%
4	100% (20/20)	—	—	100%
8	100% (20/20)	—	—	100%
16	70% (14/20)	—	—	70%

Failure Types

conc=2: Output contains corrupted/merged JSON. Example: {"description": "A young girl in a pink, "description": "A y — two separate responses appear concatenated.

conc=16: content: null with completion_tokens: 0 — model fails to generate any content. 5 of 6 failures were this type.

Key Observations

1. conc=2 is consistently degraded (45-65% across 3 runs). This is NOT noise.
2. conc=4 and conc=8 show 100% — the degradation is NOT monotonic with concurrency, suggesting a specific scheduling/batching edge case at low concurrency.
3. conc=16 failures are content: null — the model produces no output at all.
4. The corruption at conc=2 looks like cross-request contamination (merged JSON from different requests).

Correction

We previously reported 100% validity at conc=2 (on our review of PR #648). That measurement may have had different conditions or methodology. The data here is from a clean unpatched v0.3.4 install with 3 repeated runs.

Environment

• oMLX v0.3.4 (Homebrew, unpatched)
• Mac Studio M3 Ultra 96GB
• Qwen3-VL-30B-A3B-Instruct-4bit
• Structured JSON extraction prompt
• 20 diverse photos per run

Not related to #648

We tested the IOKit underflow fix from #648 and saw no change in this behavior. The deferred-clear race is a different issue.

[Chuhan1112]

I looked into this further and found two separate root causes for the JSON validity degradation at high concurrency.

Bug 1: mRoPE position state contamination between VLM requests (omlx bug)

Location: omlx/scheduler.py, the call to clear_vlm_position_state()

# Current code — only clears for text-only requests
if vlm_embeds is None and hasattr(self.model, "clear_vlm_position_state"):
    self.model.clear_vlm_position_state()

VLMModelAdapter stores _position_ids and _rope_deltas on the language model as instance-level state (mRoPE requires this across the forward pass). The condition if vlm_embeds is None means these are only cleared before text-only prefills — not between consecutive VLM prefills.

When conc ≥ 2, the scheduler allows multiple VLM requests in the same prefill batch. Request A's mRoPE state (_position_ids, _rope_deltas) persists into Request B's prefill, corrupting position embeddings. This produces garbage logits → garbled output → invalid JSON.

Fix: Remove the vlm_embeds is None guard; always clear the mRoPE state before each VLM prefill:

if hasattr(self.model, "clear_vlm_position_state"):
    self.model.clear_vlm_position_state()

---

Bug 2: Grammar processor None-slot crash at high concurrency (mlx-lm upstream bug + omlx workaround needed)

Location: mlx-lm pinned commit dcbf6e3, PromptProcessingBatch.extend() + GenerationBatch._step()

When a grammar-constrained request and a non-grammar request are batched together, the following happens:

1. omlx passes logits_processors=[[]] for non-grammar requests (empty inner list, semantically correct)
2. mlx-lm's extend() evaluates any([[]]) → False and silently replaces [[]] with [None]
3. The merged batch ends up as [[GrammarProcessor], None]
4. _step() evaluates any([[GrammarProcessor], None]) → True, then iterates all slots and crashes on the None entry

This is a contract inconsistency inside mlx-lm dcbf6e3. The issue should be reported upstream. In the meantime, omlx's _patched_generation_batch_step can add a defensive None guard:

for e in range(len(self.uids)):
    procs = self.logits_processors[e]
    if not procs:  # handles None and []
        continue
    for proc in procs:
        if isinstance(proc, GrammarConstraintProcessor):
            proc.accept_token(sampled[e])

---

Why this manifests specifically at high concurrency: Both bugs require ≥ 2 concurrent requests. Bug 1 requires two concurrent VLM requests (possible only at conc ≥ 2). Bug 2 requires a grammar request and a non-grammar request to be batched together in the same GenerationBatch, which only happens under concurrent load. At conc=1, requests execute sequentially with full state isolation.

The content: null / completion_tokens: 0 pattern at conc=16 is consistent with Bug 1 producing entirely corrupt output that the response parser fails to decode, resulting in an empty completion.