[MrDongsls]

Required human contributor answers

1. What outcome are you trying to achieve?

   Answer: Serve the Vela 2.0 4B and 9B decoder members on system1-omni the same way the 0.8B is served.

2. What is the highest-leverage variable for that outcome?

   Answer: Exact-match parity with each member's pinned reference runtime.

3. How will this work move that variable rather than create busywork?

   Answer: The three members ship one byte-identical runtime, so one registry and the shape-derived heads extend the validated 0.8B path to both with no new executor code.

4. Who is the customer or user, and what they actually need?

   Answer: Anyone who wants Vela 2.0 decisions from system1-omni on the larger members, and they need correct answers on all five question kinds.

After answering the four questions: is a PR needed at all to achieve this outcome?

Human decision: Yes, the new members are served only after this registry, tests and docs merge.

For a bug fix: link actual observed failure evidence.

N/A, not a bug fix.

Purpose

Fourth slice of the Vela 2.0 native chain. It serves the 4B and 9B decoder members on the Python reference worker and the native library that already serve the 0.8B, one pinned member per worker process.

• The worker keeps one member registry keyed by the package's config.json model_name. Each entry pins the repo, revision, the ten hashed files and the shard layout, and a package naming an unpinned member is refused by its own name.
• The native bundle gate mirrors that registry as a member table with the exported tensor inventories. The F32 heads derive every width from the tensors' own shapes and the executor cross-checks the backbone hidden size, so one implementation serves hidden 1024, 2560 and 4096.
• Fixtures are relabeled per member and JSON fixtures are committed. The head-input safetensors of the larger members are not committed, about 103 MB of binaries, and are regenerated with recipe/vela/export_head_inputs.py on the pinned package.

Builds on #151, #174, #175, #176 and #177.

Stacked PRs and merge order

This is the fourth slice of one chain and stacks on the open 0.8B native PRs; the branch history contains the #177 head 064244d, so most of this diff's native-crate lines are those PRs' content plus the member-parameterization on top:

Order	PR	Layer
1	#151 (merged)	0.3B Python reference worker
2	#174 (merged)	0.8B hybrid through the reference worker
3	#175	0.8B native bundle export, wire contract, token-level processing
4	#176	0.8B native F32 heads, scoring and span decoding
5	#177	0.8B native response finishing and CUDA executor
6	this PR	the 4B/9B member layer

Recommended merge order is #175 → #176 → #177 → this PR. Once the 0.8B stack lands, this PR's diff collapses to its own layer (the hybrid.py member registry, the per-member fixtures, the member-stamping exporters and the docs); until then, reviewers can treat the files under src/models/vela/native/ as the #175–#177 surface under review there. The branch merges current main in 1b8d025, so it stays conflict-free while the stack lands.

Test Plan

System1-Omni Version / Commit: 73af078 on model/vela2-4b-9b, based on the #177 head 064244d.

• CPU on the branch head: cargo fmt --all --check, cargo clippy --workspace --locked --all-targets --features omni-laya/serve -- -D warnings, cargo test --workspace --locked --features omni-laya/serve, PYTHONPATH=src pytest tests/vela, and mkdocs build --strict. The release build was not run locally and is left to CI.
• Author-run GPU evidence recorded in the recipes, one rented RTX 4090 48 GB, sm_89, driver CUDA 13.3, toolkit 13.2, the bf16 autocast setting: package gate, load and all-kind warmup for both members, nine-case exact-match reference parity against the pinned upstream server, frozen oracle, token-plan and head-input fixtures exported under each member's label, and the native replays with the member-calibrated gates in the tests.

Test Result

• CPU: all checks above pass on 73af078. The workspace tests report 100 test targets ok with no failure, the omni-vela-native crate 30 passed and 4 ignored that need an exported bundle or a GPU, and pytest 160 passed including the member-parametrized oracle cases.
• Reference parity: exact on all nine cases for both members, four 200s byte-equal including key order and agreed 422 and 413. A warm 4B worker answered the example request in about 0.2 s, a single observation, not a benchmark.
• Native heads and response: 4B head logit drift at most 8.97e-5, answer drift at most 5.56e-3, response drift at most 5.56e-3. 9B: 4.20e-5, 6.80e-4 and 5.92e-3. All inside the member gates. The larger ceilings against the 0.8B baseline come from the GPU-recorded fixtures and are documented in the tests and native.md. One divergence is kept deliberately: on borderline span cases the replay flips the discrete span set while its probabilities still match, so the tests assert probabilities there and keep full structural assertion on the 0.8B CPU-recorded fixtures.
• Head updated to b2559fe (independent-review fixes plus the merge of current main): the same CPU checks pass there — fmt, workspace clippy and workspace tests 421 passed / 0 failed / 92 ignored after the merge, omni-vela-native 32 passed / 4 ignored (two new bundle-walk tests), pytest tests/vela 160 passed also re-verified torch-free on system Python, and mkdocs build --strict clean. main merge conflicts (Cargo.toml, README.md, docs/supported-models.md, recipe/README.md) are resolved in 1b8d025; Cargo.lock keeps only the omni-vela-native addition against main.
• Executor on CUDA: 4B replays all four small cases with worst logit drift 0.2271 against the 0.35 bf16 gate. 9B recorded two of the four, worst 0.1899, before the rented session ended. The 9B cjk and score cases are unverified and remain to be run.

Demo / evidence

The runs above are author-run and recorded with hardware, revisions and gates in recipe/vela/reference.md and recipe/vela/native.md. No separate raw archive or video. The change is a serving integration and the parity numbers are the evidence. The 9B executor cjk and score replays are labeled unverified above and will be fully verified when this PR is ready for review.

Self-review

• I have reviewed the full diff and addressed the issues I found.
• I have checked that the change follows the project's architecture and stays focused on the stated purpose.
• I have run the checks appropriate to this change and reported commands, results, and anything that I could not verify above.
• I have checked that the PR description, documentation, and any accuracy or performance claims match the implementation and available evidence.