Repository navigation
Name the Qwen model 0.69 blesses and commit its parity receipt at the SERVING shape — our gates are all single-stream #3555
Description
Requirement: 0.69 must name the Qwen model it blesses for "usable on pure CUDA" and commit that model's CPU-vs-CUDA parity receipt per (model, host) — because first-party internal consumers gate their own admission of an apr serve backend on it.
(This issue is deliberately requirements-only. The consuming projects are internal and their specifics are not public; what matters here is what aprender must produce.)
What aprender must produce
- A named model. "Qwen usable on pure CUDA" is not actionable for a consumer until the release says which model and which size the claim covers.
- A committed parity receipt per (model, host) clearing that model's threshold, under
evidence/parity/, with its basis stated inline — not a number quoted into someone else's document. A figure that travels without its basis stops being evidence; see the calibration note below. - The shape the receipt was measured at.
The calibration note (why a low number is not automatically a defect)
evidence/parity/thresholds.yaml sets the default 0.98 by separating two measured populations, n=5 each, stdev 0:
| population | lambda (sm_89) | gx10 (sm_121) |
|---|---|---|
| known-good qwen2.5-coder-7b | 0.998607 | 0.998465 |
| known-bad qwen2.5-coder-1.5b | 0.950827 | 0.950611 |
The 1.5B row is the negative control that gives 0.98 its discrimination — a small dense model below the line is the calibration working, not the CUDA backend failing. Qwen3.5 on CUDA, shipped in 0.68.2 against a per-model 0.99 floor with its own measured basis:
| model | lambda | gx10 |
|---|---|---|
| qwen3.5-0.8b | 0.998971 ×5 | 0.999176 ×3 |
| qwen3.5-9b | 0.999254 ×5 | 0.999351 ×3 |
Anyone consuming these numbers should read them from evidence/parity/thresholds.yaml, which states the provenance inline, rather than copying a value into another document.
Serving shape — the part that is a real gap on our side
A parity receipt taken at m=1 does not license a claim about a batched serving path. Measured on the 0.68.2 tree:
$ grep -nE 'batch|--concurrency|serve' scripts/check_model_parity.sh → no match
$ grep -nE 'batch|serve|concurren' scripts/check_model_ladder.sh → no match
Neither C14 nor the model-capability ladder exercises the batched serving path. Both are single-stream. So the path apr serve actually uses — the one #2753 says emits garbage for every m>1 and #2770 says diverges at m≥4 — is gated by nothing in the release train. That is why those defects survived releases: not waived, unlooked-at. A release can be fully green and still ship a serving path that produces garbage.
Acceptance
scripts/check_model_parity.sh --judge <record> --model <name>PASSes for the blessed model on both GPU hosts, records committed underevidence/parity/.- The receipt carries
shape: {batch, concurrency}, and at least one receipt per blessed model is taken at the serving shape, not only m=1. Until P0: batched CUDA decode emits garbage for every m>1 — PERF-001's 3.32x aggregate is throughput of garbage tokens #2753/cuBLAS decode route diverges at m>=4: coherent but different continuation, so c=4 fails parity while c=2 passes #2770 land that receipt is expected RED — a red receipt that measured the right path is worth more than a green one that measured the wrong path. - EPIC: release train 0.69.0 — COMPLETE Qwen usability on pure CUDA (all 0.68.x folded in) #3080 names the blessed model in its acceptance list.
Activity
noahgift commentedon Sep 20, 2026
The serving-shape gap is ours, and it is now in the issue body above with the measurement. Summary for anyone reading the thread: neither
check_model_parity.shnorcheck_model_ladder.shmentions batch, concurrency or serve — both are single-stream — so the batched path that #2753 and #2770 cover is gated by nothing in the release train.Added acceptance: the committed receipt carries
shape: {batch, concurrency}and at least one per blessed model is taken at the serving shape. A RED receipt that measured the right path beats a green one that measured the wrong path.(An earlier revision of this issue quoted a first-party consumer's internal spec sections and measurements. This repository is public and those projects are not; the issue has been rewritten to state what aprender must produce, which is the part that belongs here.)
[-]Name the model 0.69 blesses for 'Qwen usable on pure CUDA' and commit its parity receipt — a downstream reviewer lane's admission depends on it[/-][+]Name the Qwen model 0.69 blesses and commit its parity receipt at the SERVING shape — our gates are all single-stream[/+]noahgift commentedon Sep 23, 2026
milestone → 0.71.0 per docs/roadmaps/milestone-triage-2026-09-23.md (#4024), operator approval 2026-09-23 (relayed by aprender-cf). Reason: model/backend correctness or the certified matrix: Don't Leave Behind (#3994)
noahgift commentedon Sep 26, 2026
Progress on branch
PMAT-3555-serving-shape-parity(@ 144ab3b, pushed branch-only because the PR cap is exceeded; batcher: 59).Blessed model:
qwen3.5-9b(Qwen3.5-9B-Q4_K_M.gguf). This is named inevidence/parity/blessed.yaml, not in #3080: #3080 is a closed 0.69.0 epic, so I did not edit it.Gate:
bash scripts/check_model_parity.sh --blessedis RED unless every host has BOTH receipts:apr parityCPU-vs-CUDA cosine record withshape {batch:1, concurrency:1}.--judgerefuses any other shape claim.--serving. Its shape is what the server formed (maxm_formed), bound to the blessed file.apr serveformed no cross-request batch for qwen35 (m_formed=0). The batched path is #2753.gx10 is missing because there is no attributable CUDA aarch64 binary:
~/.cargo/bin/aprthere is 0.70.0 (817d633), a PR-branch commit. Handed off via the cop inbox.Also fixed:
scripts/apr_bin.shcalled a binary built from HEAD STALE. git had lengthened--short HEADto 10 hex digits after the binary embedded 9. The fix matches the(sha)field of--versionas a prefix of the full sha; the case table is incheck_apr_bin_resolution.sh.Checks and quorum:
degraded: same-family.🤖 Generated with Claude Code
paiml#3571 layer 1: apr serve routes the Qwen3.5 hybrid to Qwen35Mode…
noahgift commentedon Oct 14, 2026
merged into #5317 (master ticket for epic #4381; triage rule 7b, 2026-10-14). It is a checklist row there; reopen this issue when work on it starts or its PR opens.