|
|
@@ -36,8 +36,16 @@ measured, on the production package and flags.
|
|
|
(4 threads, O_DIRECT 4 K, 10 s) vs ≈33 K on a healthy dgx5 — while a
|
|
|
first-touch prefill demanded **≈24 K reads/s**, i.e. 80–90 % of the drive.
|
|
|
- **Mitigation that works today**: the unmerged upstream io_uring reader
|
|
|
- (PR #184) on top of current `main`. Same hardware, same package, same
|
|
|
- prompt: 3/3 wedges before, clean run after (numbers below).
|
|
|
+ (PR #184) on top of current `main` — **partially**. Same hardware, same
|
|
|
+ package, same prompt: 3/3 wedges before, clean run after **on a warm stand**
|
|
|
+ (numbers below). On a **freshly rebooted** node the cold-boot wedge persists:
|
|
|
+ 2026-11-04, 07:12 UTC boot, first long request ~9 min later died at
|
|
|
+ `sequence 93` with prefill frozen at **token 1** — dgx4's drive could not
|
|
|
+ deliver the first chunk's ≈350 MB of rows within the ≈8 s spin window even
|
|
|
+ with the parallel reader (its reads ran hot at ≈87 K reads/s for ~4 s and
|
|
|
+ then stalled mid-burst). Removing dgx4 remains the only complete fix on
|
|
|
+ this hardware; the reader patch is strictly beneficial but not sufficient
|
|
|
+ on a cold stand.
|
|
|
|
|
|
## Evidence
|
|
|
|
|
|
@@ -49,14 +57,17 @@ measured, on the production package and flags.
|
|
|
| 2 | orbit `prod4`, rank 0 = dgx4 | packaged `flare` | **poison** @ seq 2109 (frozen ~93 K) |
|
|
|
| 3 | orbit `prod4`, rank 0 = dgx4 | packaged `flare` | **poison** @ seq 1284 (frozen ~61 K) |
|
|
|
| 4 | orbit `prod4b`, rank 0 = **dgx1**, dgx4 = rank 3 | packaged `flare` | **poison** @ seq 1557 (`rank 1 waiting for rank 3`) |
|
|
|
-| 5 | orbit `prod5` = dgx1+dgx2+dgx3+**dgx8**, no dgx4 | packaged `flare` | **clean**, 0→157,086 in ~61 s |
|
|
|
-| 6 | orbit `prod4b`, dgx4 = rank 3 | **main + PR #184** | **clean**, 0→157,086 in ~60 s (~2,600 t/s) |
|
|
|
+| 5 | orbit `prod5` = dgx1+dgx2+dgx3+**dgx8**, no dgx4 | packaged `flare` | **clean**, 0→157,086 in ~61 s (×2) |
|
|
|
+| 6 | orbit `prod4b`, dgx4 = rank 3 | **main + PR #184** | **clean**, 0→157,086 in ~60 s (~2,600 t/s) — warm stand |
|
|
|
+| 8 | orbit `prod4b` (2026-11-04, **freshly rebooted** node) | **main + PR #184** | **poison** @ seq 93, prefill frozen at **token 1** — the cold-boot case survives the reader patch |
|
|
|
| 7 | orbit `sparks` = dgx5–8 (2 runs, incl. after 45 min idle) | packaged `flare` | clean |
|
|
|
|
|
|
Runs 4 and 6 matter most: with dgx4 demoted from rank 0 the failure
|
|
|
**followed the node, not the rank**. Run 5 isolates it further: remove dgx4
|
|
|
entirely and the packaged binary is clean. The wedging pair is always
|
|
|
-dgx2-or-dgx1 waiting on **dgx4's** data.
|
|
|
+a peer waiting on **dgx4's** data. Run 8 adds the cold-boot dimension: the
|
|
|
+reader patch rescues a warm stand but not the first long request after a
|
|
|
+reboot — the drive stalls mid-burst inside the spin window at chunk 1.
|
|
|
|
|
|
### Rank 0 metrics through one wedge (1 Hz, `prod4`, layout `ESP`)
|
|
|
|
|
|
@@ -112,6 +123,27 @@ Result (run 6): prefill 0 → 157,086 tokens in ~60 s, no burst gaps, total
|
|
|
lane (48.4 s). dgx4's KingSpec drive is still the slowest disk in the fleet;
|
|
|
the pipelined reader simply keeps it under the collective's patience.
|
|
|
|
|
|
+**But not on a cold stand** (run 8, 2026-11-04): after a node reboot the
|
|
|
+first long request wedges at `sequence 93`, prefill frozen at token 1. Rank
|
|
|
+0's 1 Hz capture shows the first chunk's reads running hot (≈87 K reads/s,
|
|
|
+disk wait +2.7 s) and then the whole runtime dead within ~8 s — dgx4's drive
|
|
|
+stalls mid-burst inside the spin window, which the parallel reader raises in
|
|
|
+throughput but cannot bound in time. Operationally this means: after every
|
|
|
+reboot, a cold stand can lose its first long prompt even with the patch.
|
|
|
+The production lane therefore excludes dgx4 (`prod-no4`) until the drive is
|
|
|
+replaced; the `prod4b`+patch configuration is reserved for after the swap.
|
|
|
+
|
|
|
+## Production decision (2026-11-04)
|
|
|
+
|
|
|
+- Serving lane: **`prod-no4`** = dgx1+dgx2+dgx3+dgx8 (orbit `prod5`, rank 0
|
|
|
+ = dgx1), recipe `dsv41-flash-1017-4x-flare-gb10-nodgx4`. Clean on the same
|
|
|
+ prompts that killed the dgx1–4 lane, with or without the reader patch.
|
|
|
+- `prod4b` + `executable` stays configured for **after the NVMe swap**
|
|
|
+ (Samsung PM9A3/PM9E1 M.2 2242 or Corsair MP700 Micro class; back up
|
|
|
+ `~/.config/flare/orbit/controller.key` before the DGX OS reinstall to skip
|
|
|
+ re-pairing).
|
|
|
+- The `prod4` orbit (rank 0 = dgx4) remains in `orbit.toml` for reference.
|
|
|
+
|
|
|
## Upstream material
|
|
|
|
|
|
### Status in `NVIDIA/spark-local-inference` (was `flare-local-inference`)
|
|
|
@@ -170,24 +202,35 @@ the pipelined reader simply keeps it under the collective's patience.
|
|
|
> Removing that node from the cluster (dgx1+dgx2+dgx3+dgx8) serves the same
|
|
|
> prompt cleanly with the packaged binary.
|
|
|
>
|
|
|
-> **Fix.** Current `main` + PR #184 cherry-picked (`pr184-on-main`) serves
|
|
|
-> the identical package and prompt: prefill 0→157 K in ~60 s, total Engram
|
|
|
-> disk wait 48.7 s (healthy-lane parity), no poison — 1/1 so far after 3/3
|
|
|
-> failures without it.
|
|
|
+> **Fix (partial).** Current `main` + PR #184 cherry-picked (`pr184-on-main`)
|
|
|
+> serves the identical package and prompt on a warm stand: prefill 0→157 K in
|
|
|
+> ~60 s, total Engram disk wait 48.7 s (healthy-lane parity), no poison — 1/1
|
|
|
+> after 3/3 failures without it. **On a freshly rebooted node the wedge
|
|
|
+> persists** (2026-11-04): the first long request dies at `sequence 93` with
|
|
|
+> prefill frozen at token 1 — the first chunk's ≈350 MB of rows must arrive
|
|
|
+> within the ≈8 s spin window and the slow drive stalls mid-burst (reads hot
|
|
|
+> at ≈87 K/s, then the runtime is dead). Excluding that node from the cluster
|
|
|
+> (`dgx1+dgx2+dgx3+dgx8`) is the only configuration that survived every case,
|
|
|
+> with or without the patch.
|
|
|
>
|
|
|
> **Requests.**
|
|
|
> 1. Reconsider #184: its close reasoning ("the filesystem was the
|
|
|
> bottleneck") holds for Btrfs, but on ext4/GB10 the single-lane reader
|
|
|
-> is what makes the lane survive a disk that is merely slow.
|
|
|
-> 2. Make the collective spin limit configurable at serve time (or raise it
|
|
|
-> when disk-Engram delivery is in play) — it is currently baked into the
|
|
|
-> prepared package, so operators cannot trade latency for stability.
|
|
|
+> is what makes a warm stand survive a disk that is merely slow.
|
|
|
+> 2. Make the collective spin limit configurable at serve time (or make it
|
|
|
+> Engram-aware / auto-extend on the first chunks of a cold stand) — it is
|
|
|
+> currently baked into the prepared package, so operators cannot trade
|
|
|
+> latency for stability. The cold-boot case (run 8) dies at token 1:
|
|
|
+> no reader improvement fixes a deadline that is shorter than the first
|
|
|
+> chunk's cold read time.
|
|
|
> 3. Expose `/metrics` on **every** rank (or at least the readiness/disk
|
|
|
> counters): the rank that waits is invisible today, which turns a disk
|
|
|
> stall into an unattributable fabric error.
|
|
|
> 4. Consider a preflight/warning when a host's Engram disk falls below the
|
|
|
> package's implied read rate; a 6 W consumer 2242 at 29 K IOPS is not
|
|
|
-> the same class as the reference platforms.
|
|
|
+> the same class as the reference platforms. A serve-time flag to shrink
|
|
|
+> the prefill chunk (package-baked at 4096 tokens here) would also bound
|
|
|
+> the per-chunk read volume on slow disks.
|
|
|
|
|
|
## Operational state after this investigation
|
|
|
|