test(qwen3_5): qualify the remaining published Qwen3.5 widths - #1289
zhenshanx-nv wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 10 remain after this review. 📝 SummarySummaryAdds FP16 test manifests for Qwen3.5 0.8B, 2B, and 4B. Each manifest uses a Hugging Face checkpoint, chat templates, disabled thinking, a France-capital prompt, and single-device execution. All cases remain outside premerge. Excludes these widths from release-performance evaluation. The release workload and receipt currently cover only Qwen3.5 9B. Architecture impact
Review outcomeHUMAN REVIEW REQUIRED The objectives report 154 passing architecture and benchmark tests and token-for-token Hugging Face parity with NED 0.0000. The supplied shell output confirms the manifest and release configuration, but it does not verify those test results. WalkthroughThree Qwen3.5 text-generation manifests were added for the 0.8B, 2B, and 4B models. Release-performance exclusions were added for these widths because workload and receipt coverage exists only for the 9B width. ChangesQwen3.5 profiles
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Other Merge Risk: ⚪ Minimal · up to The new model profiles and performance exclusions match the repository’s catalog and release-suite contracts, with no identified merge-blocking risk. 🚥 Pre-merge checks | ✅ 8 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (8 passed)
Full details: Shared Semantic NeutralityExplanation The pull request changes shared configuration in Resolution Remove the Qwen-specific exclusions from the shared release suite, or supply the specialization through an existing narrow family-owned data contract that the shared loader consumes generically. Alternatively, add matching release-performance workloads and receipts so no Qwen-specific exclusion is required. Comment |
5954968 to
df092fb
Compare
The family claimed every dense Qwen3.5 width already, but only the 9B had a manifest, so the three smaller published widths were supported without being measured. Each one builds and matches the Hugging Face reference token for token, normalised edit distance 0.0000, with no change to the family. The new cases are not premerge: the 9B remains the family's premerge gate, so the premerge suite still runs one Qwen3.5 build rather than four. The three widths run on demand and through the release performance matrix. Signed-off-by: Zhenshan Xie <zhenshanx@nvidia.com>
df092fb to
79c38a1
Compare
|
This is an automated Internal CI result; no review from an individual maintainer is requested. Open the public Source Actions run from the automated status link above. |
Background
families/qwen3_5claims every dense Qwen3.5 checkpoint bymodel_type, but onlyQwen/Qwen3.5-9Bhad a manifest. The three smaller published widths — 0.8B, 2B and 4B —were therefore supported without ever being measured against the reference.
Exit Criteria
support.pywas wrong and that is a different PR.Implementation
Manifests only. No family code changed.
Routing was checked first, because
qwen3_5andqwen3_8both namemodel_type: qwen3_5and a checkpoint claimed by two families is a hard failure in
resolve_family. They areexact complements by construction:
families/qwen3_5/support.pyreturnsNonewhenoutput_gate_typeis present withoutmlp_only_layers, which is precisely the conditionfamilies/qwen3_8/support.pyclaims. All three widths report nooutput_gate_typeand docarry
mlp_only_layers, so they resolve toqwen3_5alone.Change categories
Validation
Commands and Results
Each width built at fp16 and driven through the native CLI, compared against the Hugging
Face reference with the prompt rendering and metric used by
families/qwen3_5/tests/test_e2e.py:[11751, 248046, 198, 248044]Paris[57590, 248046, 198, 248044]Paris[57590, 248046, 198, 248044]ParisToken for token, against a threshold of 0.15.
tools/tests/test_architecture.pyandapps/benchmark/trtmc_benchmark/tests— 154 passed(this covers the manifest field contract and the release-matrix coverage rule)
Hardware, Environment, and Revisions
Qwen/Qwen3.5-0.8B,Qwen/Qwen3.5-2B,Qwen/Qwen3.5-4Bc96119fdNot Run / Remaining Gaps
premerge: false.qwen35-9bstays the family's premerge gate sothe premerge suite still builds one Qwen3.5 model rather than four; the new widths run on
demand and through the release performance matrix.
carries a CPU-only torch, so locally the reference ran on the CPU; the GPU form runs in CI.
excluded_profiles, not benchmarked: the release-performanceworkload and receipt were collected only for the 9B, which exercises the same builder and
runtime path.
35B-A3B,122B-A10B,397B-A17B) are out of scope here.Contributor Self-Review
Notes For Future Readers
Worth recording that this is the first change in the repository to add a manifest to an
existing family without touching family code — every prior manifest arrived as part of the
commit that created its family. The reason it works here is that
qwen3_5was written toclaim a lineage rather than a checkpoint, and the widths differ only in layer and hidden
dimensions, which the builder already reads from config.
The routing check was the part worth doing carefully. Two families naming the same
model_typelooks like a latent conflict, but the complementaryoutput_gate_type/mlp_only_layerspredicates make it exact, and that is what decides which family owns afuture Qwen3.x release.
Third-party provenance: the checkpoints are the published
Qwen/Qwen3.5-*Hugging Facerepositories.
Risk level
Test inputs only. No family code, no runtime code, and the premerge gate is unchanged.