Repository navigation
Conversation
added 3 commits
October 25, 2026 02:56
Second member of the Vela 2.0 family: a pinned vela2-decoder executor (hybrid.py) with a 10-file gate (shard index and the side-loaded broad head hashed; the 2.02 GB shard by exact size), member-aware response finishing (span_heads with spans, keyed by span question ids), worker member detection from config.json model_type, and the per-member /v1/models entry. compare_reference.py serves either member; the hybrid oracle fixtures export under oracle-hybrid-. Evidence (author-run, x86 WSL2, CPU FP32, no fla — the runtime's CPU path never dispatches to it): nine-case parity vs the pinned upstream server exact-match (four 200s incl. key order, five agreed rejections incl. the 16,384-window 413); 0.3B nine-case regression; live worker smoke with span_heads and per-member thresholds; byte-identical Rust frontend forwarding; 133 CPU contract tests.
- recipe/vela/export_native.py: gate-verified export into a native bundle — 320 backbone tensors re-keyed backbone. -> model. with per-tensor dtypes preserved (204 BF16 Linear/conv1d + 116 F32), the 37 F32 heads incl. the side-loaded broad span head in one file, backbone_config at the config root (the family Config::load shape), and a manifest pinning the source revision, the gate table, the tensor inventory and every bundle file's SHA-256. - src/models/vela/native (omni-vela-native): the bundle manifest gate and the wire admission mirroring protocol.py and the pinned runtime's preamble with byte-equal 422/400 bodies. - recipe/vela/export_token_plan.py and five frozen token plans under tests/vela/fixtures/: the predict mapping, the row decomposition and the rendered records (p_ids, blocks, readout positions, truncation, a windowed long-span case); example-request totals 1,041 tokens, matching the oracle's usage. Checks: cargo test (15 tests, no weights, no GPU), fmt/clippy clean, mkdocs --strict.
The Rust processing of the native path, mirrored from the pinned runtime and checked field-for-field against the five frozen token plans (opt-in render parity with the exported bundle's tokenizer): - state.rs: the state -> typed-parts mapping (role grouping, field ranges, canonical DEV2.0 JSON) with the pinned rejection triples; - questions.rs: the SystemOne -> predict mapping — the validation walk and order, Noul folded into a two-option choice (choice renders [ABS], the reference's abstain default), over resolution, threshold/head carried, the set-label collision check; - words.rs: the GLiNER2/CJK _WORD splitter and the first-token word mapping; - render.rs: the encoder (char-offset tokens, memoized), the six-rule span-head dispatch with the hallucination-alias label replacement, the truncation budget, the DEV2.0 rendering (parts pass, question blocks with option ends and query positions, span layout a/c with word positions) and the window rows (head only, as the reference); - processing.rs: the Processor over the exported bundle. Also: the envelope error locs are flat arrays, matching the reference triples exactly. Checks: cargo test (26 tests) + fmt/clippy clean + opt-in render parity (5/5 fixtures).
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This was referenced Oct 25, 2026
added 11 commits
October 25, 2026 14:26
…processing # Conflicts: # Cargo.toml # README.md # docs/supported-models.md # recipe/README.md
…reference-serving # Conflicts: # README.md # docs/supported-models.md # recipe/README.md
…ember docs Keep the Clef and pplx-decider rows from main alongside the Vela 0.8B hybrid additions; the package-gate descriptions now carry the directory-symlink refusal from main.
…ows alongside the Clef/pplx-decider additions
…native-processing # Conflicts: # recipe/README.md
4 tasks done
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #151 + #174 — review the last two commits only.
Required human contributor answers
What outcome are you trying to achieve?
Start the native Rust path for the 0.8B: export the checkpoint into a verifiable bundle, implement the wire admission, and mirror the token-level processing — checked against frozen token-plan fixtures recorded from the pinned runtime. (Source: issue [New Model]: Support the Vela 2.0 series #137.)
What is the highest-leverage variable?
Exact token-level parity with the pinned runtime is the foundation every later stage validates against.
How will this work move that variable?
Five frozen fixtures (including a windowed long-span and a CJK case) lock the predict mapping and rendered rows field-for-field; the opt-in render test replays them through the Rust code.
Who is the customer or user?
Contributors building the native worker; ultimately users needing GPU-accelerated Vela decisions.
Is a PR needed? Yes — prerequisite for the executor PR.
For a bug fix: N/A.
Purpose
Export script (
export_native.py: gate-verified, per-tensor dtypes preserved, manifest SHA-256), Rust bundle gate + wire admission (byte-equal 422/400), token-level processing (state/questions/words/render/processing), five frozen token-plan fixtures, parity example binary.Test Plan
System1-Omni Version / Commit:
model/vela2-native-processing@0f1e4dacargo test -p omni-vela-nativecargo clippy -p omni-vela-native --all-targets -- -D warningsmkdocs build --strictVELA_NATIVE_BUNDLE=… cargo test --test vela_native_processing -- --ignoredTest Result
All passed. Render parity is opt-in (needs the exported bundle's tokenizer); CI covers CPU tests only.
Demo / evidence
Author-run, x86 WSL2, CPU FP32:
usage.input_tokens.#[path]wiring.Not measured: GPU, performance.
Self-review