force_on MTP mode does not thread the manual-depth activation contract required by current vmlx main

[jjang-ai]

With vmlx at current main, mtp.mode=force_on + explicitDepth in server-runtime.json produces mtp=off: the engine's NativeMTPActivation gate requires isExplicitlyRequested + manualDepthRequest (task-locals or VMLX_NATIVE_MTP=1/VMLX_MTP_MANUAL_DEPTH env) at LOAD time, and the app's load plan never sets them (verified live 2026-08-31/09-01: force_on depth 3 on Qwen3.8-27B decoded plain at 24 tok/s; engine env-forms also refused because the app's LoadConfiguration overrides). The manual-depth threading commits exist on the vmlx side ('Thread manual MTP depth through LoadConfiguration into the activation gate') — the app side needs to adopt them at the next repin, with a live force_on proof per depth.

[jjang-ai]

Escalation with hard evidence: this is NOT limited to the old branch. Reproduced on a repin-preview build (osaurus main 62664a0 + vmlx main with #386/#387, local path dep):

• mtp.mode=force_on, explicitDepth=1 confirmed present in the test root's server-runtime.json (file-read path verified in ServerRuntimeSettingsStore.snapshot()).
• Qwen3.8-27B-JANG_4D generated with STEP-MTP decodePath=plain mtp=off — AR essay at 12.0 tok/s, prefill ~300 tok/s (also suspicious vs the old pin's 1.5-2.8k tok/s; needs its own repeat).
• The bundle's MTP evidence is COMPLETE: 31 mtp.* tensors verified directly in the safetensors headers (fc + 1 decoder layer + norms), sidecar present, family qwen3_5 on the allowlist, no blocked flag — every documented gate in resolvedMTPLaunch → manualRecommendation passes on paper.
• The same bundle ENGAGES depth-3 staged MTP on the shipped pin (1315fdcb build, auto mode): 39.6/39.1 tok/s, 94-98% acceptance, tonight's measurements on vmlx-swift#383. MTPRuntime.swift is byte-identical between the pin and main, so the divergence lives in the app-side wrapper (inspect call signature/jangConfig plumbing, plan threading) or a non-obvious status field.
• A census probe that reported tensors=0 metadata_only_missing_weights was traced to a stale-branch RunBench binary — disregard it; do not trust census output without confirming the binary's lineage.

Until this is isolated, the next repin will silently turn off 27B MTP (both auto and force_on) — treat as repin-blocking together with vmlx-swift#385. Repro: build osaurus main with a path dep on vmlx main, force_on depth 1, load Qwen3.8-27B-JANG_4D, observe STEP-MTP mtp=off. The load-time mtpPlan.reason (genLog, os_log-only on unsigned builds) is the missing breadcrumb — surfacing it to stdout under OSAURUS_PREFILL_DEBUG would make the next session's isolation immediate.

[jjang-ai]

Update: the 27B refusal that motivated this issue is root-caused and fixed on the vmlx side — it was not a contract-threading gap. The bundle's model.safetensors.index.json was rewritten by a stamping pass that omitted all 31 mtp.* tensors (the mtp shard's model-mtp-of-00005.safetensors name escapes the model-NNNNN-of-MMMMM glob), and the inspector's index-first short-circuit turned that into tensors=0 metadata_only_missing_weights. Fixed in osaurus-ai/vmlx-swift#388 (merged): the inspector unions index keys with shard header names. Live-proven on the preview build with the corrupt index installed: MTP-PLAN nativeMTP=true … tensors=31, speculative=on, real chat turn via verifier=input_capture_staged. The force_on plumbing itself was correct all along — with tensor evidence restored, manual depth 1 engaged with no osaurus-side change. Keeping this issue open only if the repin checklist still wants the diagnostic MTP-PLAN stdout mirror upstreamed; otherwise it can close with the next repin.

[jjang-ai]

Depth-ladder validation on the repin-preview build (vmlx main @ 6249656488, which includes vmlx-swift#388): force_on explicitDepth now engages across the ladder on Qwen3.8-27B-JANG_4D — d1: STEP-MTP depth=1 active=1 verifyCalls=258 avgCommitted=1.78, 29.5 tok/s over 459 tokens; d3: STEP-MTP depth=3 active=1 verifyCalls=511 acceptedByDepth=164/206/113/28 avgCommitted=2.01 downshifts=16 over 1,597 tokens. Cold prefill re-checked at 1,415.9 pp/s on a 6.6k novel prompt (the earlier one-off ~315 pp/s reading did not reproduce — fresh-launch artifact). No osaurus-side change was needed; the repin can proceed on the MTP front.