feat(qwen4): detect the line and validate its geometry

[sysuTobo]

Description

Refs #1104 — one of three PRs delivering slice A of the #1103 Qwen3.8-Flash-Next bring-up, so this does not close the issue. The tensor contract that enforces this config against real checkpoint bytes follows as a separate PR stacked on this one; the gated-norm activation this line needs is #1129, which is independent of both.

Qwen/Qwen3.8-Flash-Next is a new line, not a Qwen3.5 variant: model_type: qwen4_exp with an inner qwen4_exp_text, against Qwen3.5's qwen3_5. The Qwen3.5 probe hard-requires model_type == qwen3_5, so today this checkpoint surfaces as an unknown model instead of a known-but-uncompiled one, and the server cannot name the feature that would serve it.

Production invariant changed: ModelLineRegistry::detect gains a claimant, and feature_gate_hint in the server binary gains a family. Registration is more than model_line.rs — the server hand-mirrors every line's probe identities in a hint descriptor its own comment says cannot be derived away, so the mirror is tested and not just the probe. detect requires a unique claimant, which is why the routing regression below matters more than it looks.

Detection succeeds and launch refuses with the reason. There is no text graph, no weights loader and no step, so the alternative would be serving a partial model.

Probe

Fail-closed identity plus structure, following the Gemma 4 pattern of pinning structure rather than widths.

Pinned, because an alternative would need a kernel or serving path this line does not have: the GDN head dims (they are the Triton AOT specialization keys), head_dim 256, the conv kernel ceiling, rope_type: default (no YaRN path), output_gate_type: sigmoid, mamba_ssm_dtype: float32, dtype: bfloat16 — so the FP8 sibling fails closed rather than loading as BF16 — and untied embeddings.

Deliberately not pinned: expert count, hidden size, layer count, head counts, hc_count. A smaller qwen4_exp checkpoint should reuse this probe, which is what the L20 small-model deployment case in #1103 needs. smaller_widths_still_pass keeps that promise honest rather than aspirational.

Alongside the pinned values the probe refuses the shapes that are unservable rather than merely different: a num_hidden_layers that disagrees with layer_types, a zero hidden_size or vocab_size, and an ngram_vocab_size_base with no room for a prime search. mrope_interleaved and mrope_section are accepted, not refused: a text-only sequence is their degenerate case in the reference itself, which expands one position per token across all three axes before interleaving, so every rotary pair takes the same position with its own frequency. The decision and the fixtures that would tell it apart are tracked in #1105.

Config

Two fields the reference implementation reads are absent from config.json and come from upstream defaults, so both are modelled explicitly with those defaults: norm_topk_prob (true, and it decides whether the router renormalizes its top-k) and seed. A port that reads only config.json silently drops the router renormalization — this is #1068's mirror image.

The rope values come from the nested object the reference reads (modeling_qwen4_exp.py takes config.rope_parameters["rope_theta"] and [..., "partial_rotary_factor"]), so TextConfig models that copy. The checkpoint also carries a legacy top-level partial_rotary_factor that nothing upstream reads; the probe refuses a checkpoint where the two disagree rather than letting readers pick differently. num_experts_per_tok is carried as well — the probe validates 0 < k <= num_experts exactly as the reference's config does, and a router that re-read config.json on its own would be a second source of truth.

The n-gram table's geometry is derived rather than read, because config.json states none of it:

heads          = (ngram_size - 1) * heads_per_ngram = 2 * 8 = 16
head_dim       = ple_embed_dim / heads              = 2560 / 16 = 160
head i vocab   = the (i+1)-th prime after (ngram_vocab_size_base - 1)
rows per shard = ceil(sum / 128) * 128 / split_ngram_parts = 2,500,012
bytes at BF16  = 102,400,491,520                    = 102.4 GB

102.4 GB, not the ~51 GB vLLM and SGLang quote — that figure is the fp8 footprint and this checkpoint ships BF16. Every host-RAM budget in the issue set was 2× under until it said which dtype it meant.

The derivation lands here rather than with its first consumer because #1106 needs the geometry independently of any tensor contract, and because it is pure arithmetic over config.json; nth_prime_after_matches_the_reference pins the prime search against the reference's _find_nth_prime_after, including its lower bound (searching from 0 must not call 1 prime).

Crate shape

No CUDA dependency at all, so its 44 tests need no device, no weights and no Triton-equipped build. CI runs them on a CPU runner (cpu-unit-tests, cpu-clippy). The per-model CUDA matrix also has a row for this line, for the opposite reason — to compile the server side, which is the one part of this PR that cannot be checked on a CPU-only box (see Evidence).

Preserving that split is the point of the crate's shape: when slice B adds the device side, config and probe must move behind #[cfg(any(feature, test))] the way pegainfer-gemma4/src/lib.rs does, not behind a whole-crate #![cfg(feature)] the way Qwen3.5 does — the latter would make even pure-CPU config tests require a Triton build.

Nothing outside the test suite consumes the geometry yet, so the crate carries #![cfg_attr(not(test), allow(dead_code))], with a comment saying it comes off when the first runtime caller lands. Test builds keep the lint, which is how the width-pinning test below came to exist rather than a blanket allow.

Evidence

• Routing is unchanged for every existing line. no_other_lines_identity_is_accepted walks 13 foreign model_type values; qwen35_is_not_mis_routed_here pins the specific confusion this line exists to avoid; three #[cfg(not(feature))] tests pin the server's hint mirror (both identities, and that the two lines do not cross-hint), one #[cfg(feature)] test pins that it goes silent once the line is compiled in, and one that it stays silent for an unknown family.
• The frozen config fixture is the real file, not a transcription: a test re-hashes tests/frozen_config.json against FROZEN_CONFIG_SHA256 at revision de4b8e4d, so the fixture cannot drift from the revision it claims to be. The reference implementation itself first ships in transformers 5.16.0 — the checkpoint's declared 5.8.0.dev0 is what it was authored against, not a release carrying qwen4_exp — and PINNED_TRANSFORMERS names that, with a test holding the two facts apart.
• A finding the width-pinning test surfaced, which slice B has to plan around: this line's GQA group is 24 / 2 = 12, and SUPPORTED_GQA_GROUP_SIZES is [1, 2, 3, 4, 8]. So decode_group_is_compiled() is false here and captured-graph decode is off the table — the same corner Qwen3.5-27B is in at group 6. Recorded in the doc's Traps rather than left for slice B to discover.
• The registration chain is compiled by CI now. The line has its own cuda-clippy matrix row — feature: qwen38-flash-next, extra_packages: -p pegainfer-server, needs_triton: false — which is what compiles the registry entry and the hint family, plus a step that runs those tests with the feature both ways. Before that row existed the claim rested on a hand-run on L20 / sm_89: cargo check --release --locked -p pegainfer-server --features qwen38-flash-next --all-targets → exit 0, and the hint tests → 5 passed with the feature on, 7 passed with it off. Note the row only runs once this PR leaves draft: ci.yml gates the heavy jobs on draft == false.
• CI's exact commands run locally: cargo fmt --all --check, cargo clippy --release --locked -p pegainfer-build -p pegainfer-frontend -p pegainfer-sim -p pegainfer-qwen38-flash-next -p kvbm-logical --all-targets -- -D warnings, cargo test --release --locked -p pegainfer-qwen38-flash-next --lib → 44 passed.

Docs: docs/models/qwen38-flash-next/bring-up.md (freeze table with file hashes, the measured traps, what is still open) plus its docs/index.md row.

What the pre-submission audit changed

An audit of this branch at d3bb63cc found four issues worth fixing and nine worth tightening; 0820991b closes them:

• the pinned transformers release was 5.8.0, which carries no qwen4_exp — repointed to 5.16.0, pinned by a test;
• partial_rotary_factor had two sources: the probe validated the nested copy while TextConfig read the legacy top-level one — one source now, and a disagreement is refused;
• num_experts_per_tok was validated by the probe but never carried — it is a TextConfig field now;
• the registration path had no CI coverage at all (the feature was enabled by no matrix row) — hence the row above;
• plus the input-domain checks, the prime search's lower bound, and the mrope reasoning written into the probe. The sigmoid output_gate_type note in launch and in the doc now names feat(kernels): make the gated RMSNorm activation selectable #1129, so neither goes stale when that PR merges.

Type of Change

• New feature (non-breaking change which adds functionality)
• Documentation update

Checklist

• My code follows the style guidelines of this project (see docs/conventions/coding-style.md).
• I have performed a self-review of my own code.
• I have formatted my commits according to Commitizen conventions.
• I have run the local test suite and all tests pass (see CLAUDE.md).

Test plan

• CI green for pegainfer-qwen38-flash-next: cpu-unit-tests, cpu-clippy, and the new Qwen3.8-Flash-Next CUDA Clippy row (the last one needs this PR out of draft).
• cargo run --release -- --model-path <Qwen3.8-Flash-Next> on a stock build should print the --features qwen38-flash-next hint rather than reporting an unknown model.
• The same with --features qwen38-flash-next should detect the line and then refuse to launch, naming slice B as the reason.
• On a CUDA-capable box (L20 / sm_89), before the CI row existed: cargo check --release --locked -p pegainfer-server --features qwen38-flash-next --all-targets → exit 0, and cargo test --release --locked -p pegainfer-server --features qwen38-flash-next --bin pegainfer hint → 5 passed; the same without the feature → 7 passed.

[sysuTobo]

Code audit — round 2 (head 400d9d4e, base c8a09c9d)

TL;DR: the forward paths all check out, and this round every load-bearing number was traced to real bytes: the committed fixture is byte-identical to the upstream config.json at de4b8e4d; the n-gram prime derivation matches the checkpoint's stored ngram_heads_vocab_sizes / ngram_heads_offsets tensors (I64[16], range-fetched from model-00037-of-00131.safetensors) byte for byte; shard_127.weight really is [2500012, 160] BF16, pinning rows-per-shard, head_dim and the 102.4 GB figure at once. 44/44 tests reproduced locally. Of round 1's 13 findings, 12 are fixed and 1 (R9) was fixed but went stale again when the branch was rebased onto the #1129 merge. New this round: 9 findings (5 M / 4 L), mostly one theme — the probe's mirror of the reference's own validate_architecture is incomplete — each verified line-by-line against the transformers v5.16.0 sources.

New findings

ID	Sev	Finding	Evidence
N1	M	The probe comment still says the in-tree gated norm "hardcodes silu … until that lands" — #1129 (this PR's own base) landed the sigmoid entry point	probe.rs:228-232 vs pegainfer-kernels/csrc/shared/norm.cu:7-9,83 at base
N2	M	Same staleness in the doc: "has to become selectable … that change is a separate PR (#1129)" — #1129 is merged in base	bring-up.md:107-113
N3	M	NgramTable::derive hardcodes ple_layer_index = 0; the reference primes head i of PLE layer L at global index L * ngram_heads + i, so a multi-PLE-layer checkpoint passes the probe and derives wrong geometry for layer ≥ 1	config.rs:282-287 vs modeling_qwen4_exp.py:1037-1039
N4	M	Probe omits the reference's hc_count > 1 rule (a single-branch residual stream is refused upstream)	probe.rs:284-292 vs configuration_qwen4_exp.py:196
N5	M	Probe omits three reference QSA rules: indexer_kv_heads == 1, indexer_budget % indexer_compress_ratio == 0, rotary_dim <= indexer_head_dim	probe.rs:241-253, :417-426 vs configuration_qwen4_exp.py:221,223,227
N7	M	rope_theta is read by the reference from the same nested object, by direct index (rope_parameters["rope_theta"]), yet is neither probed nor carried — while RopeParameters' doc claims to be "the only canonical copy" of "every rope value". A slice-B rope consumer would have to re-read config.json: the exact second-source shape R3 was fixed for	config.rs:42-53 vs modeling_qwen4_exp.py:108
N6	L	Probe omits "PLE only on linear_attention layers"	probe.rs:298-317 vs configuration_qwen4_exp.py:248-254
N8	L	Labeler name/globs say qwen4 while the line/crate/feature/docs-dir are all qwen38-flash-next; kernel files named after the line (*qwen38*) would not get labelled	.github/labeler.yml:18-25
N9	L	no_other_lines_identity_is_accepted's docstring says the other half ("no existing line claims qwen4_exp") is pinned by the server's hint tests — hint tests pin the hint table; identity uniqueness rests on each line's own hard gate plus the registry's Conflict	probe.rs:471-477 vs pegainfer-qwen35/src/model_line.rs:85

Report-only (no code change proposed): rotary_dim()'s bail is unreachable after probe_rope (defensive D1, fine); ngram_vocab_size_base has no upper bound so a pathological config could make the sieve allocate ~4.3 GB (the reference is equally unbounded and config.json is operator-controlled); the CI hint substring filter is naming-fragile (its "every test in that module" comment is true today — checked); smaller_widths_still_pass exercises the probe but not Config::from_json; the reference also requires eos_token_id when PLE is on (configuration:255-256) and rewrites full_attention → qwen_sparse_attention in layer_types (:181-185) — both are slice-B/#1105 territory; the PR body's "Qwen3.5 probe hard-requires qwen3_5" is actually outer-or-text identity.

Round-1 receipts (R1–R13)

ID	Status
R1	Fixed — PINNED_TRANSFORMERS = "5.16.0" + the two-facts test. Re-verified independently: qwen4_exp/ is 404 at tags v5.8.0 and v5.15.0, present at v5.16.0
R2	Fixed (better than the prescription) — nested rope_parameters is canonical, disagreement refused, dedicated test
R3	Fixed — num_experts_per_tok carried; the cited configuration_qwen4_exp.py:200 line number is accurate (checked)
R4	Fixed — pointer comment in the probe, no vacuous assertion, as prescribed
R5	Fixed — CUDA matrix row + "both ways" test step; the 5-on/7-off counts re-derived by hand and correct
R6	Documented bound (correct to keep) — allow(dead_code) with its removal condition; slice B must delete it
R7	Fixed — the empty-feature comment in the crate's Cargo.toml
R8	Fixed — CLAUDE.md row now says "Foundation only (probe, config)"
R9	Fixed-then-staled — the fix pre-dated #1129 merging; the rebase onto c8a09c9d inverted its tense ⇒ re-fixed as N1/N2
R10–R13	Fixed — layer-count cross-check, hint test coverage, prime lower bound (double: max(1) + base >= 2 probe rule), zero width/vocab refusals; each has its dedicated test

Byte-level verification performed this round

• fixture ≡ upstream config.json @ de4b8e4d (diff = identical; sha256 889658f2… = FROZEN_CONFIG_SHA256 = upstream file hash)
• model.safetensors.index.json: 1658 keys, 131 files, total_size 359,999,963,128 B = 360.0 GB — freeze table fully confirmed
• lm_head.weight [248320, 2560] lives alone in model-00131; embed_tokens in model-00130 — untied ✓; the only model-level norm is hyper_connection_mixer.hc_norm.weight — "no final-norm tensor" ✓
• PLE tensors exist only under layers.1 — the 1-indexed [2] trap confirmed against the real layout ✓
• ngram_embedding.shard_0…shard_127 — exactly 128 named shards ✓; shard_127.weight = [2500012, 160] BF16 ✓
• stored ngram_heads_vocab_sizes = [20000003, 20000023, …, 20000171] and ngram_heads_offsets = the derived prefix sums — byte-exact against an independent recomputation ✓
• ple.conv1d.weight = [10240, 1, 4], same shape as the GDN conv — the "identical shape, dilated anyway" trap confirmed; reference conv_dilation = ngram_size, state (4-1)*3 = 9 (modeling:1134-1135) matches ple_conv_state_len() ✓
• _find_nth_prime_after (modeling:1009-1015) semantics + _is_prime(<2) = False — the port's start.max(1) floor is equivalent on {0,1}; all 7 pinned values recomputed ✓; padding formula ≡ modeling:1052-1053 ✓
• norm_topk_prob: bool = True / seed: int = 1234 upstream defaults (configuration:156,163), consumed by the router (modeling:903,912), absent from the fixture ✓
• mrope degeneration argument holds: 2-D positions expand(3, …) (modeling:123-124) then the interleaved overwrite copies identical axes onto themselves (:140-156) = plain 1-D rope ✓
• GQA group 12 ∉ SUPPORTED_GQA_GROUP_SIZES = [1,2,3,4,8] (pegainfer-kernels/src/ops/attention.rs:18) ✓; gemma4 cfg(any(feature, test)) precedent ✓; load_shard_info_fixed exists (pegainfer-core/src/weight_loader.rs:1055) ✓; reasoning_effort arms on output_gate_type (pegainfer-frontend/src/vllm/reasoning_effort.rs:16,94) ✓
• referenced issues all exist and match: [Model] Qwen3.8-Flash-Next roadmap #1103 roadmap / [Model] Qwen3.8-Flash-Next: line skeleton & bring-up #1104 slice A / [Model] Qwen3.8-Flash-Next: QSA sparse attention #1105 QSA / [Model] Qwen3.8-Flash-Next: text-graph assembly & decode step #1127 slice B / [Model] Qwen3.8-Flash-Next: multi-GPU EP serving & envelope #1128 slice C ✓
• cargo test --release -p pegainfer-qwen38-flash-next --lib → 44 passed locally ✓

Verdict

Detection, fail-closed refusals, geometry derivation and the registration/hint surface are all correct for the frozen checkpoint and for the tested variants. The real gap is that the probe is looser than the reference's own validation in five places (N3–N7): today none of them is reachable from the only checkpoint that exists, but each one turns "known-but-uncompiled" into "known, detected, and silently mis-derived" for a future qwen4_exp variant — which is precisely the class of failure this crate exists to prevent. All nine findings are mechanical to close; a fix commit follows on this branch.

[sysuTobo]

Fix commit for the round-2 findings: 8e0ec018

Every code-level finding from the audit above is closed on the branch; each fix carries a dedicated test. Mapping:

Finding	Fix	Guard
N1 (M) stale "hardcodes silu" comment	probe.rs output-gate comment rewritten: #1129 made the shared kernel selectable (rms_norm_gated_sigmoid_cuda beside Qwen3.5's SiLU); what remains is this line's call site. The sigmoid pin stays fail-closed — no silu-gated qwen4_exp variant has golden fixtures here	existing a_non_sigmoid_output_gate_bails (rationale now accurate)
N2 (M) stale doc trap	bring-up.md Traps now reads "became selectable in #1129 … merged before this line's detection PR, so what remains is this line's call site"	— (doc; tense anchored to a merged commit)
N3 (M) multi-PLE-layer mis-derivation	probe_ple refuses any ple_layer_ids but a single entry, naming the reference's per-layer prime offset (global_head_idx = L * ngram_heads + i, modeling:1037-1039); NgramTable's doc now states the single-layer assumption	a_multi_layer_ple_bails ([2, 6] refused)
N4 (M) hc_count > 1 missing	probe_hyper_connections mirrors configuration:196 — a single-branch residual stream has nothing to mix	a_single_branch_residual_stream_bails
N5 (M) QSA rules missing	probe_attention mirrors indexer_kv_heads == 1 (:221) and budget a whole multiple of the compress ratio (:223); probe_rope mirrors rotary ≤ indexer_head_dim (:227)	an_indexer_kv_heads_above_one_bails, an_indexer_budget_not_divisible_by_the_compress_ratio_bails, a_rotary_width_past_the_indexer_head_bails
N6 (L) PLE-on-linear rule missing	probe_ple mirrors configuration:248-254 (safe subscript: probe_layer_types runs first and pins layer_types length to num_hidden_layers)	ple_on_a_full_attention_layer_bails ([4] is full under interval 4)
N7 (M) rope_theta unmodelled	Carried as a required RopeParameters field (serde-required ⇒ absence refuses at parse), probed positive-and-finite (the reference direct-indexes it, modeling:108) — no consumer can need a second read of config.json	a_missing_rope_theta_bails + bit-exact pin 10_000_000.0 in the_frozen_revision_pins_the_attention_and_moe_widths
N8 (L) labeler naming gap	Added *qwen38* kernel globs beside *qwen4*, so files named after the line label the same as files named after the model_type	— (labeler only)
N9 (L) docstring evidence pointer	Reworded: identity uniqueness rests on each line's own hard gate + the registry's Conflict; the server's hint tests pin that the hint table does not cross-map	— (docstring)

Report-only items stay report-only by design: rotary_dim()'s defensive bail (unreachable after the probe, kept), the unbounded ngram_vocab_size_base sieve window (the reference is equally unbounded and config.json is operator-controlled), the CI hint filter's naming fragility (its comment is true today), smaller_widths_still_pass covering the probe but not from_json, eos_token_id and the qwen_sparse_attention rename (slice B / #1105 territory), and the allow(dead_code) bound (R6, comes off with the first runtime caller).

Verification

• cargo test --release --locked -p pegainfer-qwen38-flash-next --lib → 51 passed (44 + 7 new; the description's "44 tests" and the doc's count are updated where they live — the description itself can't be edited, so noting it here)
• cargo clippy --release --locked -p pegainfer-qwen38-flash-next --all-targets -- -D warnings → clean (exit 0; the only output is the pre-existing third-party proc-macro-error2 future-incompat notice)
• cargo fmt --all --check → clean
• The frozen config still passes end-to-end (the_frozen_revision_passes, the_registry_entry_detects_the_frozen_revision), and smaller_widths_still_pass still holds — the new rules mirror the reference's own refusals, so no config the reference accepts is rejected here
• Server-side hint tests are untouched by this commit (no main.rs change)

Round-1 receipts stand as tabulated in the audit comment: R1–R5, R7–R8, R10–R13 fixed; R6 a correctly documented bound; R9 fixed-then-staled-by-rebase and now re-fixed as N1/N2.

[github-actions]

This pull request has merge conflicts with main. Please rebase it so it can be reviewed and merged.

[sysuTobo]

每次call这个函数都得重算线性筛，是否太耗时？如果调用次数少，是否应该打表；如果次数多；是否应该预处理？

[sysuTobo]

Round 3: the registration follow-ups, and a prime-sieve fix

Two commits on the branch since the last round (both on top of the rebase onto main @ 67bd8a2b, which also closed the merge-conflict notice above — the PR is MERGEABLE/CLEAN).

61dd6779 — three follow-ups from reviewing the registration surface

ID	Finding	Fix
G1	launch's refusal framed the GDN gated-norm activation as an open kernel dependency, but #1129 already made the sigmoid entry point selectable.	The message now says the missing piece is the call site, which lands with the text graph in slice B. pegainfer-qwen38-flash-next/src/model_line.rs:27-34
G2	feature_gate_hint is identity-only — it cannot run a compiled-out probe — so it also fires for the FP8 sibling and the tied/YaRN variants of qwen4_exp, which the probe refuses. That was undocumented.	Written down on the family table (pegainfer-server/src/main.rs:54-67) and in bring-up.md.
G3	The hint table is a hand-mirror of each line's identity, and nothing bound it to the probe.	families() is now reachable from a test, and a feature-gated test asserts the qwen38-flash-next row equals the line crate's MODEL_TYPE / TEXT_MODEL_TYPE (main.rs:386-402). Those constants move the identity strings to one place (probe.rs:26-35, re-exported by lib.rs:31-32).

346f6445 — nth_prime_after re-sieved on every candidate

The lazy re-sieve compared the candidate's square root against the largest prime in the current sieve, not against the sieve's limit. Near the frozen base that root is 4473 = 3²·7·71 — composite — so the test held for every candidate.

Measured (x86_64, -O) on the derivation one Config::from_json performs — heads = (ngram_size − 1) × heads_per_ngram = 16 calls of nth_prime_after:

variant	per Config::from_json
before	6.26 ms (the last call alone re-sieved 172 times)
after (compare against the sieve limit)	175 µs
single linear sweep for all 16 primes (rejected)	17.5 µs

Derived values are unchanged; nth_prime_after_matches_the_reference and the n-gram geometry tests pin them.

Why neither a precomputed table nor a shared pre-pass:

• NgramTable is derived on purpose — the checkpoint stores its own ngram_heads_vocab_sizes, and deriving is exactly what lets the manifest reject a partition that disagrees with its own config before any bytes move.
• ngram_vocab_size_base and heads are config values the probe deliberately does not pin (ngram_vocab_size_base ≥ 2, any integer). A hard-coded table would be a second source of truth that cannot enumerate a base it permits.
• The remaining 10× (175 µs → 17.5 µs) would cost the 1:1 correspondence with the reference's _find_nth_prime_after, which the unit test reads directly. Not worth it on a once-per-load cold path.

Verification

• Local: cargo fmt --all --check ✓, 51 line-crate tests ✓, cargo clippy -D warnings on the crate ✓.
• CI run 37944431030 (head 61dd6779): 16/16 jobs green, including the Flash-Next row's both-ways step — 6 hint tests with the feature on (the new binding test among them) and 7 with it off.
• CI on 346f6445 is running.

[FeathBow]

@codex review please.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-11T09:36:28.126485Z	346f644	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 346f6445d3

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Run geometry derivation from the registered probe

For a qwen4_exp config with positive but inconsistent derived geometry (for example, ple_embed_dim = 2561 or split_ngram_parts = 3), this production method calls only probe_config_json, which accepts it; repo-wide, Config::from_json is called only by tests, where NgramTable::derive rejects those cases. Consequently ModelLineRegistry::detect claims the config and launch says it was validated even though the advertised geometry validation is dead scaffolding; construct Config here (or move its checks into the probe) so the config layer participates in the production invariant.

AGENTS.md reference: AGENTS.md:L128-L128

Useful? React with 👍 / 👎.

[sysuTobo]

Fixed in f1d2699: ModelLine::probe now builds the whole Config, so detect runs the n-gram/head-group derivations too, not just the structural probe. Guarded by the_probe_rejects_geometry_that_does_not_derive (ple_embed_dim = 2561).

[chatgpt-codex-connector]

Exercise the line gate with a production E2E

In the inspected cuda-clippy job, the new registration step only runs the hint unit-test filter with the feature on and off, and a repo-wide qwen4_exp search finds no test that invokes the built server. This feature changes production detection and the intentional launch-refusal path, so these pure tests do not provide the repository-required production E2E or cover the CLI/registry/startup wiring as shipped; add a release-binary test against a model directory that asserts both the stock-build feature hint and the enabled-build refusal.

AGENTS.md reference: AGENTS.md:L128-L128

Useful? React with 👍 / 👎.

[sysuTobo]

Fixed in f1d2699: pegainfer-server/tests/detect_gate.rs runs the shipped binary against a model dir holding the frozen config, both ways — the stock build must name --features qwen38-flash-next, the enabled build must detect and refuse. Wired into the CUDA row; both cfgs green.

[chatgpt-codex-connector]

Reject non-integral full-attention head groups

For a smaller checkpoint with positive but non-divisible head counts (for example, 10 query heads and 3 KV heads), this loop accepts the config even though grouped attention needs an integral query/KV ratio. The analogous Qwen3.5 validation rejects this at pegainfer-qwen35/src/config/model.rs:265-271, and the shared attention dispatch operates on that derived group, so this probe can claim a geometry the planned attention path cannot represent; require num_attention_heads to be a multiple of num_key_value_heads.

Useful? React with 👍 / 👎.

[sysuTobo]

Fixed in f1d2699: the probe now rejects a non-integral query/KV ratio, mirroring qwen35's AttentionHeadDivisibility. Test: a_non_integral_gqa_group_bails (10 query / 3 KV heads).

[chatgpt-codex-connector]

Reject non-integral GDN head groups

For a smaller checkpoint whose positive linear value-head count is not a multiple of its key-head count, this loop accepts the config even though Gated DeltaNet maps value heads in whole groups over key heads. The reused Qwen3.5 geometry enforces this exact invariant at pegainfer-qwen35/src/config/model.rs:255-263; without the same check here, detection can validate a shape the shared GDN path cannot represent, so reject unless linear_num_value_heads is divisible by linear_num_key_heads.

Useful? React with 👍 / 👎.

[sysuTobo]

Fixed in f1d2699: the probe now requires linear_num_value_heads % linear_num_key_heads == 0, mirroring qwen35's LinearHeadDivisibility. Test: a_non_integral_gdn_head_group_bails (48 value / 10 key heads).

[github-actions]

This pull request has merge conflicts with main. Please rebase it so it can be reviewed and merged.

[FeathBow]

@codex review please.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[github-actions]

Commit attribution notice

This pull request contains commits attributed to an account other than the PR author @sysuTobo without a verified signature from that account:

• 8e27d514 attributed to @FeathBow
• 6a0782fd attributed to @FeathBow
• 87f5abee attributed to @FeathBow
• f764e826 attributed to @FeathBow
• 93069eca attributed to @FeathBow
• ac1c55d2 attributed to @FeathBow
• 658483d6 attributed to @FeathBow

If you are mentioned above and did not take part in this pull request, please say so here. Attributing a commit to someone else normally requires that person to be involved; maintainers should treat unacknowledged attribution as a review blocker.

This check never fails the build.

[FeathBow]

We pushed seven commits on top of yours.

• Name. The crate, feature, hint family and docs are now qwen4 (pegainfer-qwen4, --features qwen4, docs/models/qwen4/). The line claims any qwen4_exp checkpoint, the model card calls it "an experimental preview of the architecture that will underpin Qwen4", and the issues and the label already use qwen4. Qwen3.8-Flash-Next is its first checkpoint. The empty crate feature is gone, and the server feature only enables the dependency, as glm52 and k3 do.
• One typed validation. The probe checks identity only, as Qwen3.5's does. Every other rule moved into config.rs behind one serde parse (RawConfig into Config), so each field is read once and NgramTable::derive no longer repeats checks the probe already made. ModelLine::probe still builds the whole Config, so detection refuses an unservable config before the frontend starts. The rules and their messages carried over.
• Quantized siblings. The official FP8 config differs from the BF16 one only by a top level quantization_config, and its text_config.dtype is still bfloat16, so the dtype pin let it through. nvidia's NVFP4 config is the same case. A quantization_config at either level is now refused, and the FP8 test uses that real block.
• Rotary width. An odd width is refused. The reference builds arange(0, rotary_dim, 2) and rotates cos.shape[-1] dims, which is one more than an odd rotary_dim.
• Prime search. It is now a direct port of the reference's _is_prime and _find_nth_prime_after. The 16 primes and the table geometry are unchanged, and the crate's tests finish in 0.01 s.
• Dead code. The crate wide allow(dead_code) is gone. Accessors and exports with no caller (hc_hidden_size, the gdn_* widths, ple_conv_state_len, bf16_bytes, seed, FROZEN_REVISION, PINNED_TRANSFORMERS) are removed with their tests, and the revision and the transformers release stay in bring-up.md. The fields the tensor contract will read keep a cfg_attr(not(test), allow(dead_code)), so test builds still check them.
• Tests. Tests that repeat another one are dropped. In the crate these are two that check serde's required field handling, two pairs that hit the same comparison, the trait object coercion the server registration already compiles, and the wiring test detect_gate covers. In the server, four hint tests are covered by the generic hint tests, the test that binds the qwen4 row to the crate's constants, and detect_gate.
• Detection gate. Each run of the binary is bounded at 60 s and fails with the run's stderr, where output() could wait forever on a startup or shutdown path that never returns.
• Launch. The refusal says the checkpoint is detected and inference is not implemented yet. The kernel history stays in bring-up.md.
• CI and the model table. The CI row, the CPU job entries and the row in the supported models table are dropped until the line serves. detect_gate stays and runs with cargo test -p pegainfer-server.

Checked on one sm_89 box. cargo fmt --all --check, CI's CPU Clippy, Clippy with -D warnings on pegainfer-qwen4 and on pegainfer-server with and without --features qwen4, the crate's unit tests (40 passed), and the server's hint tests plus detect_gate both ways (4 and 1 without the feature, 5 and 1 with it) all pass. With the run budget cut to 1 ms, detect_gate fails with "the binary did not exit within 1ms". The binary against the three real configs:

config	stock build	--features qwen4
BF16, the frozen revision	names --features qwen4	detected, then refuses because inference is not implemented
Qwen/Qwen3.8-Flash-Next-FP8	names --features qwen4	not claimed, quantization_config is present
nvidia/Qwen3.8-Flash-Next-NVFP4	names --features qwen4	not claimed, quantization_config is present

#1104, #1127 and #1128 still use the old name, and a branch stacked on this one needs a rebase over the rename. Tell us if anything here should go another way.