|
| 1 | +# Raschka Full-Loop Cookbook (V8) |
| 2 | + |
| 3 | +> Companion to `VisualBuilderPlan-v8.md` / `VisualBuilderSpec-v8.md`. |
| 4 | +> This document is the **definitive end-to-end recipe** for taking any |
| 5 | +> preset in the Raschka gallery (currently 62 presets) and running an |
| 6 | +> N-step training job, with paper-anchored defaults, automatic |
| 7 | +> scaling, memory-fit verification, mid-canvas feature injection, and |
| 8 | +> streaming data, all from the Visual Builder UI. |
| 9 | +
|
| 10 | +## 0. Prerequisites |
| 11 | + |
| 12 | +- A built `vbgui` (`pnpm -C vbgui install && pnpm -C vbgui dev`). |
| 13 | +- The cppmega backend running on `127.0.0.1:8767` (`uvicorn |
| 14 | + cppmega_v4.jsonrpc.server:app --port 8767`). |
| 15 | +- A working tokenizer (the default bundled `cppmega_v3` ships at |
| 16 | + `cppmega_mlx/tokenizer/tokenizer.json`). |
| 17 | +- For the HF-quickstart path: outbound HTTPS to `huggingface.co`. |
| 18 | + Set `VBGUI_DISABLE_NETWORK=1` to refuse the RPC in offline runs. |
| 19 | + |
| 20 | +## 1. Pick a preset (R01) |
| 21 | + |
| 22 | +Open the Visual Builder, click the **Preset launcher** dropdown, |
| 23 | +choose e.g. `llama3_8b`. |
| 24 | + |
| 25 | +- `build_preset_specs` runs → canvas populates with the preset's |
| 26 | + brick chain. |
| 27 | +- The `defaults` block in the same response auto-fills the OptimTab |
| 28 | + (`adamw`, lr=`3e-4`, mixed_precision on, grad-clip 1.0) and the |
| 29 | + first group's ScheduleEditor (`wsd`, warmup 2000). |
| 30 | +- Paper anchor: <https://arxiv.org/abs/2407.21783>. |
| 31 | + |
| 32 | +## 2. Scale down to fit (R02) |
| 33 | + |
| 34 | +Switch to the **Gallery** tab. |
| 35 | + |
| 36 | +- A `GalleryScaleDownSlider` lives above the per-preset table. |
| 37 | +- Pick the target preset (same dropdown), drag the slider to a budget |
| 38 | + (default 1 GiB). |
| 39 | +- The `architectures.scale_down` RPC fires (debounced 250 ms) and |
| 40 | + surfaces the chosen `(hidden_size, num_layers)` + estimated bytes |
| 41 | + + scaled-down-from canonical shape. |
| 42 | +- Click **Apply scaled preset** → canvas swaps to the scaled chain |
| 43 | + and `dim_env.H` updates. |
| 44 | + |
| 45 | +## 3. Verify it fits everywhere (R03) |
| 46 | + |
| 47 | +Open the **Memory** sidebar tab. |
| 48 | + |
| 49 | +- `memory.matrix` returns a 4×5 grid of (topology × precision) cells. |
| 50 | +- Default axes: |
| 51 | + `[h100_8x, m3_ultra_solo, gb10_quarter, tpu_v6e_8]` × |
| 52 | + `[fp32, bf16, fp16, fp8, mxfp4]`. |
| 53 | +- Each cell shows estimated bytes + a `fits` chip (green/red) + |
| 54 | + full per-component breakdown on hover (weights / grads / optimizer |
| 55 | + / activations / kv-cache / edge handoff). |
| 56 | +- Use this matrix to validate the scale-down decision matches the |
| 57 | + intended deployment target. |
| 58 | + |
| 59 | +## 4. Auto-fit to your devbox (R04) |
| 60 | + |
| 61 | +Click **Auto-fit to my devbox** in the GalleryScaleDownSlider. |
| 62 | + |
| 63 | +- `architectures.auto_fit` chains `platform.get_info` → `scale_down` |
| 64 | + → `suggest_sharding` into a single result. |
| 65 | +- The banner that appears reports the chosen topology, the largest |
| 66 | + (H, L) that still fits at 90 % headroom, and a sharding-proposal |
| 67 | + axis summary (`dp×N, tp×M, ...`). |
| 68 | +- Apply slot still works the same; auto-fit just picks the slider |
| 69 | + value for you based on the detected hardware. |
| 70 | + |
| 71 | +## 5. Inject a feature mid-canvas (R08) |
| 72 | + |
| 73 | +In the **Canvas** tab the `FeatureInjectionBar` floats above the |
| 74 | +flow chart. |
| 75 | + |
| 76 | +- The dropdown is populated by |
| 77 | + `catalog.list_options('feature_injectors')` — 5 options today: |
| 78 | + - `mtp_weighted` → `rewriter:MTPRewriter` (K=2 head + weighted loss) |
| 79 | + - `ifim_shaped` → `rewriter:IFIMRewriter` (span-aware reshape) |
| 80 | + - `mhc_attn_bias` → `rewriter:MHCRewriter` (co-occurrence bias) |
| 81 | + - `engram` → `brick:engram` (standalone n-gram branch) |
| 82 | + - `ngram_2_3_4` → `brick:engram` with 2,3,4-gram defaults |
| 83 | +- Apply dispatches either `rewriters.add` (mutates `spec.rewriters`, |
| 84 | + flows into `pipeline.run`) or inserts a new brick node into the |
| 85 | + canvas with a fresh edge from the tail. |
| 86 | +- Subsequent training picks up the rewriter; e.g. MTP populates |
| 87 | + `extras.train.mtp` automatically. |
| 88 | + |
| 89 | +## 6. Stream training data from HF Hub (R09) |
| 90 | + |
| 91 | +In the **Data** tab → **HF quickstart** button. |
| 92 | + |
| 93 | +- Pick a dataset (`HuggingFaceFW/fineweb-edu` is the default), set |
| 94 | + the `n_tokens` target, click **Run**. |
| 95 | +- `data.hf_quickstart` streams the dataset, tokenizes each document |
| 96 | + with `CppMegaTokenizer`, and writes a parquet shard with the |
| 97 | + canonical 4-column schema |
| 98 | + (`token_ids / doc_ids / byte_offsets / byte_lengths`). |
| 99 | +- Live progress streams on `/ws/data/{job_id}` (start / progress / |
| 100 | + done frames). The result parquet path lands in the inspector's |
| 101 | + path field — click **Use for training** to point the next train |
| 102 | + run at it. |
| 103 | + |
| 104 | +## 7. Run N steps (R11) |
| 105 | + |
| 106 | +Back on the **Canvas** tab: |
| 107 | + |
| 108 | +- Click **Run pipeline** (or the split-button "Train" mode). |
| 109 | +- The runner threads everything wired in steps 1–6 into a |
| 110 | + `pipeline.run` request: scaled spec + rewriters from the injection |
| 111 | + bar + parquet from the quickstart + topology from the matrix view + |
| 112 | + ScheduleEditor schedule kind. |
| 113 | +- The `stage_train` stage publishes per-step |
| 114 | + `{step, loss, lr, overflow, grad_norms, mem_mb, ...}` events onto |
| 115 | + `train_event_bus`; the `LiveTrainPanel` subscribes via |
| 116 | + `/ws/train/{run_id}` and renders the sparkline + step counter. |
| 117 | +- A `finish: "ok"` frame fires the toast; the `extras.train` block |
| 118 | + now contains: |
| 119 | + - `preset_origin` — the originally-picked preset name (R01). |
| 120 | + - `scale_down_factor` — `H_scaled / H_canonical` (R02). |
| 121 | + - `memory_matrix_cell_used` — the cell the run actually used (R03). |
| 122 | + - `feature_injections` — list of applied injections (R08). |
| 123 | + - `data_source` — `{kind: "hf_quickstart", dataset_id, n_tokens}` |
| 124 | + (R09 / R10). |
| 125 | + - All the existing V7 extras (schedule_kind, optimizer kind, ...). |
| 126 | + |
| 127 | +## 8. Where this fits in the larger picture |
| 128 | + |
| 129 | +This loop covers the **"preset → trainable model"** path. The |
| 130 | +companions are: |
| 131 | + |
| 132 | +- The Visual Builder distributed-semantics layer (V7) handles |
| 133 | + multi-rank training once you've finished step 7 and want to fan |
| 134 | + out across multiple devboxes. |
| 135 | +- The Plasticity Toolkit (FIRE / DASH / ReDo) hooks happen inside |
| 136 | + `stage_train` — they don't surface in this cookbook but are |
| 137 | + active on every step. |
| 138 | +- MXFP4 + compile-trace + sync-checker (R05 / R06 / R07) are the |
| 139 | + remaining V8 P2 items — they extend step 3 (memory matrix) and |
| 140 | + step 7 (extras.train) with deeper diagnostics but aren't gating |
| 141 | + for a successful loop. |
| 142 | + |
| 143 | +## 9. Reference: extras.train v8 schema |
| 144 | + |
| 145 | +```jsonc |
| 146 | +{ |
| 147 | + "preset_origin": "llama3_8b", // R01 |
| 148 | + "scale_down_factor": 0.125, // R02 |
| 149 | + "memory_matrix_cell_used": |
| 150 | + {"topology": "m3_ultra_solo", "precision": "bf16"}, // R03 |
| 151 | + "compile_trace": { // R06 |
| 152 | + "fused_groups_count": 3, "dlpack_crossings": 1, |
| 153 | + "materialised_ops_count": 2 |
| 154 | + }, |
| 155 | + "sync_check": {"redundant_syncs_count": 0}, // R07 |
| 156 | + "feature_injections": |
| 157 | + ["mtp_weighted", "engram"], // R08 |
| 158 | + "data_source": { // R09 / R10 |
| 159 | + "kind": "hf_quickstart", |
| 160 | + "dataset_id": "HuggingFaceFW/fineweb-edu", |
| 161 | + "n_tokens": 100032 |
| 162 | + } |
| 163 | +} |
| 164 | +``` |
| 165 | + |
| 166 | +## 10. Smoke test |
| 167 | + |
| 168 | +The pure-Python integration test |
| 169 | +`tests/v4/test_raschka_full_loop_integration.py` covers steps 1-3-9 |
| 170 | +without any UI: |
| 171 | + |
| 172 | +```bash |
| 173 | +.venv/bin/python -m pytest tests/v4/test_raschka_full_loop_integration.py -v |
| 174 | +``` |
| 175 | + |
| 176 | +This proves the RPC plumbing end-to-end. The full UI loop is in |
| 177 | +`vbgui/e2e/scenarios/v8_raschka_full_loop.spec.ts` (R12). |
0 commit comments