-
Notifications
You must be signed in to change notification settings - Fork 11
Add Orion-Q: Qwen porting, diagnostics, and training prep on top of Orion #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,131 @@ | ||
| # Orion-Q | ||
|
|
||
| Orion-Q is a Qwen-focused porting and diagnostics subset built on top of Orion. | ||
|
|
||
| It is not a separate engine. It is a curated extension of Orion that adds: | ||
|
|
||
| - Qwen model configs and blob conversion | ||
| - Qwen CPU inference path | ||
| - Qwen ANE or hybrid inference path | ||
| - Qwen LoRA training primitives | ||
| - Qwen diagnostics, including smoke, probe, parity, and diff tests | ||
|
|
||
| The boundary for this subset is defined in: | ||
|
|
||
| - `docs/orion_q/ADR-008-orion-q-boundary.md` | ||
|
|
||
| ## What Orion-Q Is | ||
|
|
||
| Orion-Q is the part of the local Orion worktree that makes Qwen-family models runnable and verifiable inside Orion. | ||
|
|
||
| In practical terms, Orion-Q includes: | ||
|
|
||
| - Qwen frontend and model registration | ||
| - Qwen weight loading and export path | ||
| - Qwen-specific CPU and ANE execution support | ||
| - Qwen LoRA training path | ||
| - Qwen diagnostics and validation tests | ||
|
|
||
| ## What Orion-Q Is Not | ||
|
|
||
| Orion-Q does not include: | ||
|
|
||
| - Silver accelerator work | ||
| - user-specific training tracks | ||
| - CRPG or other domain assets | ||
| - reports, logs, or generated tokenizer experiment outputs | ||
| - exported checkpoints or model weights | ||
|
|
||
| Those belong to downstream tracks or local runtime artifacts, not to Orion-Q itself. | ||
|
|
||
| ## Current Status | ||
|
|
||
| Within the currently defined Orion-Q scope: | ||
|
|
||
| - Qwen porting core: complete | ||
| - binary judge diagnostics: close-out achieved | ||
| - target hybrid parity smoke scope: close-out achieved | ||
| - ANE training preparation line: complete | ||
|
|
||
| Supporting documents: | ||
|
|
||
| - `docs/orion_q/ORION_Q_PORT_CLOSEOUT.md` | ||
| - `docs/orion_q/ORION_Q_HYBRID_PARITY_CLOSEOUT.md` | ||
| - `docs/orion_q/ORION_Q_ANE_PREP_CLOSEOUT.md` | ||
|
|
||
| ## Included Code Areas | ||
|
|
||
| The shared Orion-Q subset is expected to cover these groups: | ||
|
|
||
| - shared Orion core changes required by Qwen support | ||
| - `compiler/frontends/qwen35_*` | ||
| - `kernels/inference/qwen_*` | ||
| - `kernels/training/qwen_lora_*` | ||
| - `model/configs/qwen35_*` | ||
| - `model/convert/hf_to_blobs_qwen35.py` | ||
| - `tests/test_qwen35_*` | ||
| - `tests/test_qwen35_9b_*` | ||
|
|
||
| ## Validation Philosophy | ||
|
|
||
| Orion-Q treats diagnostics as part of the product surface, not as throwaway experiments. | ||
|
|
||
| That means the following are first-class parts of the subset: | ||
|
|
||
| - smoke tests | ||
| - bridge-stage diffs | ||
| - layer diffs | ||
| - parity checks | ||
| - ANE training probes | ||
|
|
||
| ## Recommended Share Mode | ||
|
|
||
| The recommended way to share Orion-Q is: | ||
|
|
||
| 1. As an Orion-based fork or draft PR branch | ||
| 2. With generated artifacts excluded | ||
| 3. With a narrow, explicit scope | ||
|
|
||
| Suggested framing: | ||
|
|
||
| `Orion-Q: a Qwen-focused porting and diagnostics subset built on top of Orion` | ||
|
|
||
| ## Excluded Artifacts | ||
|
|
||
| Do not publish these as part of Orion-Q: | ||
|
|
||
| - `tokenizer/data/orion_*` | ||
| - `tokenizer/data/*_tok` | ||
| - exported blobs and checkpoints | ||
| - local reports and logs | ||
| - user workflow assets | ||
|
|
||
| ## Local Share Bundle | ||
|
|
||
| This workspace can generate a clean Orion-Q share bundle with: | ||
|
|
||
| ```bash | ||
| python3 scripts/prepare_orion_q_share.py --clean | ||
| ``` | ||
|
|
||
| Default output: | ||
|
|
||
| ```text | ||
| build/orion_q_share/Orion-Q | ||
| ``` | ||
|
|
||
| The bundle is driven by: | ||
|
|
||
| - `scripts/orion_q_share_manifest.txt` | ||
|
|
||
| ## Relationship to Upstream Orion | ||
|
|
||
| Upstream Orion remains the execution core. | ||
|
|
||
| Orion-Q should be communicated as: | ||
|
|
||
| - Orion core | ||
| - plus Qwen-specific porting | ||
| - plus Qwen-specific diagnostics | ||
|
|
||
| It should not be presented as a replacement brand or a disconnected new project. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -121,6 +121,13 @@ int orion_cmd_infer(int argc, const char* argv[]) { | |
| double t_load = time_ms() - t0; | ||
| fprintf(stderr, "Weights loaded in %.1f ms\n", t_load); | ||
|
|
||
| OrionModelConfig cfg = kGPT2_124M; | ||
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The dynamic dimensions here are a useful start, but this command still loads |
||
| cfg.n_layer = w->n_layer; | ||
| cfg.d_model = w->d_model; | ||
| cfg.hidden_dim = w->d_ff; | ||
| cfg.vocab = w->vocab; | ||
| cfg.max_seq = w->max_seq; | ||
|
|
||
| // Tokenize prompt | ||
| int prompt_tokens[1024]; | ||
| int prompt_len = orion_gpt2_encode(tok, prompt, prompt_tokens, 1024); | ||
|
|
@@ -134,7 +141,7 @@ int orion_cmd_infer(int argc, const char* argv[]) { | |
|
|
||
| // Allocate | ||
| float* logits = (float*)malloc(w->vocab * sizeof(float)); | ||
| OrionKVCache* kv = orion_kv_cache_create(&kGPT2_124M); | ||
| OrionKVCache* kv = orion_kv_cache_create(&cfg); | ||
| int gen_count = 0; | ||
|
|
||
| // Start profiler | ||
|
|
@@ -148,12 +155,12 @@ int orion_cmd_infer(int argc, const char* argv[]) { | |
| bool prefill_ok; | ||
| if (use_ane) { | ||
| prefill_ok = orion_ane_prefill(w, prompt_tokens, prompt_len, | ||
| &kGPT2_124M, weights_path, kv, logits); | ||
| &cfg, weights_path, kv, logits); | ||
| if (!prefill_ok) { | ||
| fprintf(stderr, "Warning: ANE prefill failed, falling back to CPU\n"); | ||
| // Reset KV cache | ||
| orion_kv_cache_free(kv); | ||
| kv = orion_kv_cache_create(&kGPT2_124M); | ||
| kv = orion_kv_cache_create(&cfg); | ||
| orion_gpt2_prefill_kv(w, prompt_tokens, prompt_len, kv, logits); | ||
| prefill_ok = true; | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Qwen production sources are now part of every build, but none of the 33 added
test_qwen*.mprograms are included inTEST_NAMESor a separate test target. They all compile when requested manually, and the two frontend tests run successfully, butmake testnever discovers them. Would you add a focused target (for exampletest-qwen) and include the self-contained tests in the default verification path, with model/ANE-dependent probes clearly separated? That would make the close-out claims reproducible for reviewers and CI.