Upload docs/HANDOFF_H200_32K.md with huggingface_hub
Browse files- docs/HANDOFF_H200_32K.md +160 -0
docs/HANDOFF_H200_32K.md
ADDED
|
@@ -0,0 +1,160 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Handoff: 16k -> 32k YaRN extension on the 2x H200
|
| 2 |
+
|
| 3 |
+
Written 2026-09-09 from the 2x H100 box. Everything below is measured on this
|
| 4 |
+
box unless marked as a projection.
|
| 5 |
+
|
| 6 |
+
## What the 2x H200 CAN and CANNOT do
|
| 7 |
+
|
| 8 |
+
`cp` cannot exceed the GPU count, so on 2 GPUs `tokens/rank = T/2`.
|
| 9 |
+
|
| 10 |
+
| target | tok/rank | total/GPU | 2x H200 (143 GB) |
|
| 11 |
+
|---|---|---|---|
|
| 12 |
+
| 16k | 8,192 | 70.7 GB (measured) | comfortable |
|
| 13 |
+
| **32k** | 16,384 | **130.8 GB (projected)** | **91.4% -- tight, probe first** |
|
| 14 |
+
| 64k | 32,768 | 250.9 GB | 175% -- impossible |
|
| 15 |
+
|
| 16 |
+
- **32k: run it.** `ext_32k.sh` starts with a 3-step probe and aborts on OOM.
|
| 17 |
+
- **64k: needs 4+ GPUs.** 4x H200 at cp=4 = 127.6 GB/GPU fits. Nothing to tune
|
| 18 |
+
on 2 GPUs: `CP_B` is already 1, and there is no activation-recompute flag in
|
| 19 |
+
bluscriptCP.cpp (checked: no `CP_RECOMPUTE`, no gradient checkpointing).
|
| 20 |
+
- 64k **evaluation** is fine on 2 GPUs -- generation stores no activations for
|
| 21 |
+
backward, so the training memory figure does not apply.
|
| 22 |
+
|
| 23 |
+
Measured activation cost is 7.51 MB/token/rank. A first-principles estimate for
|
| 24 |
+
this architecture is 1.3-2.5 MB, so actual is 3-6x higher than it needs to be
|
| 25 |
+
(the config keeps fp32 norms/residual/logits across 36 layers). If that gap is
|
| 26 |
+
real, a memory pass could make 32k comfortable and 64k possible on 2 GPUs -- but
|
| 27 |
+
that is a C++ change, not a flag, and it is unprofiled.
|
| 28 |
+
|
| 29 |
+
## Setup on the new box (nothing is pre-installed)
|
| 30 |
+
|
| 31 |
+
```bash
|
| 32 |
+
cd /root/Adhi/BluTrain/dist/Context_Parallelism
|
| 33 |
+
|
| 34 |
+
# 1. build -- BOTH targets, libtensor first
|
| 35 |
+
make libtensor SM_ARCH=90 -j$(nproc)
|
| 36 |
+
make CP_FUSED_ROPE=1 CP_ATTN_SPLIT=1 SM_ARCH=90 bluscript-cp -j$(nproc)
|
| 37 |
+
|
| 38 |
+
# 2. tiktoken -- longeval_gen.py needs it. WITHOUT IT training runs fine and the
|
| 39 |
+
# eval silently produces "no prompts" / "no scores yet". This has bitten twice.
|
| 40 |
+
/root/Adhi/BluTrain/envv/bin/pip install tiktoken
|
| 41 |
+
|
| 42 |
+
# 3. hf auth (the dataset is public now, but the model repo push needs a token)
|
| 43 |
+
hf auth login
|
| 44 |
+
|
| 45 |
+
# 4. parent checkpoint: l2, the best 16k arm. cp=2 needs it on BOTH ranks.
|
| 46 |
+
python - <<'PY'
|
| 47 |
+
from huggingface_hub import hf_hub_download
|
| 48 |
+
import shutil, os
|
| 49 |
+
p = hf_hub_download("unparallelled/BluScriptCP",
|
| 50 |
+
"checkpoints/lenbucket_l2_blumodelcp_run2_step_400.ckpt")
|
| 51 |
+
for r in (0, 1):
|
| 52 |
+
d = f"checkpoints_bluscriptcp/rank_{r}/lenbucket_l2_blumodelcp_run2_step_400.ckpt"
|
| 53 |
+
os.makedirs(os.path.dirname(d), exist_ok=True)
|
| 54 |
+
if not os.path.exists(d):
|
| 55 |
+
shutil.copyfile(p, d)
|
| 56 |
+
PY
|
| 57 |
+
|
| 58 |
+
# 5. b3 data (4 train shards + val ~ 930 MB) and the b2-val haystack
|
| 59 |
+
hf download unparallelled/BluScriptCP-data --repo-type dataset \
|
| 60 |
+
--include "cp_data_by_length/b3_16384_32768/train_shard_0000[0-3].bin" \
|
| 61 |
+
--include "cp_data_by_length/b3_16384_32768/val_shard_00000.bin" \
|
| 62 |
+
--include "cp_data_by_length/b2_8192_16384/val_shard_00000.bin" \
|
| 63 |
+
--local-dir ./dl
|
| 64 |
+
mkdir -p lendata/b3_16384_32768 lendata/haystack
|
| 65 |
+
cp dl/cp_data_by_length/b3_16384_32768/*.bin lendata/b3_16384_32768/
|
| 66 |
+
cp dl/cp_data_by_length/b2_8192_16384/val_shard_00000.bin lendata/haystack/b2val_haystack.bin
|
| 67 |
+
|
| 68 |
+
# VERIFY -- `hf download` exits 0 and prints a path even when --include matches
|
| 69 |
+
# NOTHING. Always ls, never trust the exit code.
|
| 70 |
+
ls -la lendata/b3_16384_32768/ lendata/haystack/
|
| 71 |
+
|
| 72 |
+
# 6. run it
|
| 73 |
+
./ext_32k.sh
|
| 74 |
+
```
|
| 75 |
+
|
| 76 |
+
## The run
|
| 77 |
+
|
| 78 |
+
```
|
| 79 |
+
CP_T=32768 YARN_SCALE=2 YARN_ORIG_MAXPOS=16384
|
| 80 |
+
parent: lenbucket_l2_blumodelcp_run2_step_400.ckpt
|
| 81 |
+
data: b3_16384_32768 (docs 16-32k -- these now FIT inside the window)
|
| 82 |
+
750 steps x 1,048,576 = 786 M tokens, matching run7's original 4k->16k extension
|
| 83 |
+
```
|
| 84 |
+
|
| 85 |
+
**The YaRN invariant, which cost 27pp when it was wrong:** `YARN_SCALE *
|
| 86 |
+
YARN_ORIG_MAXPOS` must equal `CP_T` exactly, and `ORIG_MAXPOS` must be the length
|
| 87 |
+
the weights were ACTUALLY trained at. Here 2 * 16384 = 32768. The default at
|
| 88 |
+
`YARNOps.cpp:57` is **1024** -- always set it explicitly. `ext_32k.sh` asserts it.
|
| 89 |
+
|
| 90 |
+
Projected step time ~25-29 s (2x the 16k tokens/rank plus attention's quadratic
|
| 91 |
+
term), so **750 steps ~ 5-6.5 h**. Unmeasured; the probe prints the real number.
|
| 92 |
+
|
| 93 |
+
## Why this run, in one paragraph
|
| 94 |
+
|
| 95 |
+
The document-length ladder is finished and it ended in a tie. Holding everything
|
| 96 |
+
else fixed at a 16k window:
|
| 97 |
+
|
| 98 |
+
| arm | training docs | 4096 | 8192 | 16360 |
|
| 99 |
+
|---|---|---|---|---|
|
| 100 |
+
| armA_c | flux, median 826 | 73.0 | 53.0 | 33.0 |
|
| 101 |
+
| l1 | b1 4-8k (fits) | 75.0 | 48.0 | 30.0 |
|
| 102 |
+
| l2 | b2 8-16k (fits) | **80.0** | 62.0 | **35.0** |
|
| 103 |
+
| l3 | b3 16-32k (TRUNCATED) | 74.0 | **64.0** | **35.0** |
|
| 104 |
+
|
| 105 |
+
l3 - l2 = -6.0 / +2.0 / +0.0 pp, none resolvable (combined 95% bars +-11.5 to
|
| 106 |
+
+-13.1). The haystack (b2-val) is in-distribution for l2 and out-of-distribution
|
| 107 |
+
for l3, so the bias runs TOWARD l2 and l3 still only drew level. Conclusion:
|
| 108 |
+
**document length helps only while documents fit inside the window.** Hence widen
|
| 109 |
+
the window, then feed b3.
|
| 110 |
+
|
| 111 |
+
## Gate the result on SHORT context, not perplexity
|
| 112 |
+
|
| 113 |
+
On 2026-09-02 a mismatched cache IMPROVED 16k (0 -> 14-17%) while COLLAPSING 4k
|
| 114 |
+
from 74% to 16%. Perplexity at the new length looked fine. `ext_32k.sh` therefore
|
| 115 |
+
evaluates 1024 / 4096 / 16360 / 32744 and **a regression at 1k or 4k is a failure
|
| 116 |
+
even if 32k improves.** Compare against l2's row above.
|
| 117 |
+
|
| 118 |
+
(32744 is not arbitrary: `PROMPT_LEN + MAX_NEW` must pad up to <= `CP_T` with
|
| 119 |
+
PAD=256, and 32744 + 24 = 32768 exactly.)
|
| 120 |
+
|
| 121 |
+
## Traps already paid for
|
| 122 |
+
|
| 123 |
+
1. **Never edit a running bash script.** Bash reads incrementally from a byte
|
| 124 |
+
offset; an insert shifts it and the interpreter resumes mid-line. This killed
|
| 125 |
+
`ladder_456.sh` with `syntax error near unexpected token 'do'`.
|
| 126 |
+
2. **`pgrep -f <script>.sh` matches the shell running it.** Killed my own shell
|
| 127 |
+
twice (exit 144). Exclude `$$`.
|
| 128 |
+
3. **Verify all rank shards** before trusting a checkpoint. A 3-of-4 set loads
|
| 129 |
+
silently wrong, and a zero exit code is not proof -- bluscriptCP catches a
|
| 130 |
+
failed save and only prints `[WARN]`.
|
| 131 |
+
4. **`say()` must write to stderr.** On stdout it poisons `$(...)` capture; that
|
| 132 |
+
fed a 3-line path into `CP_INIT_FROM` and aborted a run on rank 2.
|
| 133 |
+
5. **Run-number collisions.** `run_number` is the first free
|
| 134 |
+
`CP_BluScreipt_Training_logs/CP_Training_log<N>.csv`. A collision with an
|
| 135 |
+
existing checkpoint prefix let `CP_CKPT_KEEP=1` prune a live shard.
|
| 136 |
+
6. **`CP_STABLE` cannot equal `CP_MAX_STEPS`** -- `bluscriptCP.cpp:1006` aborts
|
| 137 |
+
with "leaves no cosine decay tail". Leave at least a 2-step tail; the guard
|
| 138 |
+
reads `CP_WARMUP` while `get_lr` uses `CP_REWARMUP`, so pin both.
|
| 139 |
+
7. **`CP_REWARMUP_ANCHOR=0` on every resume**, or each resume re-anchors a fresh
|
| 140 |
+
warmup ramp and the LR sawtooths (`bluscriptCP.cpp:2105`).
|
| 141 |
+
|
| 142 |
+
## Concurrently, on the 2x H100 box
|
| 143 |
+
|
| 144 |
+
Long b3 arm at 16k: run 17, 4,000 steps, WSD with flat 3.0e-4 for steps
|
| 145 |
+
100-3899 then a 100-step tail. Tests whether more long-context STEPS flatten the
|
| 146 |
+
slope -- the open question, since all arms sat at -18 to -29 pp/doubling while
|
| 147 |
+
Phi-3.5-mini (3.8B) manages -3.6. Checkpointed every 25 steps, `KEEP=2`. An
|
| 148 |
+
eval at step 1000 fires automatically, then the run resumes to 4000.
|
| 149 |
+
|
| 150 |
+
## Not to do
|
| 151 |
+
|
| 152 |
+
- **b4/b5/b6 at a 16k window** -- l3 already showed truncated documents add
|
| 153 |
+
nothing. b4 only becomes useful after a 64k extension.
|
| 154 |
+
- **b6 in a matched ladder** -- 57 M training tokens is 0.27x of one 400-step
|
| 155 |
+
arm; it would cycle 3.7x through all 790 documents.
|
| 156 |
+
- **Chasing 128k.** No 4B-class model has effective 128k: applying RULER's own
|
| 157 |
+
threshold (Llama2-7B at 4k = 85.6), Phi-3.5-mini (3.8B, 128k claimed) has an
|
| 158 |
+
effective context of **32k**, and so does Llama-3.1-8B-instruct. 32k is the
|
| 159 |
+
right target, and it is also where this corpus runs out (2.35 B tokens above
|
| 160 |
+
32k, total).
|