Commit Graph
3 Commits
Author SHA1 Message Date
vh 1b5d6ba23a docs(flash-next-seat): dealignai weights deleted — record that no local rollback exists
Operator instruction: delete the displaced dealignai checkpoint. 125 GiB
reclaimed from /tank (59% -> 57% used). Verified before removing: not mounted
by any running or exited container, no symlinks, no inodes shared with the
converted orcarouter directory.

Every "rollback is two .env keys" statement across the stack README, the
.env.example, persistent-memory and its detail file was true when written and
is false now -- the .env backup still names paths that no longer exist.
Corrected in place rather than left as false reassurance, since a stale
rollback instruction is discovered precisely when it is needed.

Reverting this seat now costs a 126 GiB re-download. The quality A/B against
dealignai is likewise no longer runnable locally: its reference arm is gone.

The pristine 170 GiB orcarouter download is retained deliberately -- it is what
makes the PLE bf16->FP8 conversion reproducible without re-fetching -- and that
is now recorded so a future session does not reclaim it as an obvious duplicate.

Also notes that ~75 GiB of non-PLE shards are duplicated between the pristine
and converted orca directories (the convert's hardlinks hit EXDEV across two
container bind mounts); both now sit directly on /tank, so relinking would
reclaim it if /tank ever tightens.
2026-09-14 02:51:54 -07:00
vh 4390be947d feat(flash-next-seat): serve orcarouter weight-only NVFP4 on gen-large
Swaps gen-large from the dealignai ModelOpt W4A4 build to
orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4, which is weight-only on both
axes (W8 float attn, W4 float experts, input_activations: null) and so avoids
the 4-bit-activation long-context degradation mode.

The checkpoint was previously recorded as unloadable on any mainline vLLM,
requiring a from-source PLE-loader patch. That conclusion was wrong on cost.
Qwen4ExpPLEEmbeddingMethod.from_quant_config checks ple_embedding_dtype as
branch 1, before any quant-config type check, and its NotImplementedError for
CompressedTensorsConfig is scoped to the PLE path only -- experts and dense
load through the ordinary compressed-tensors paths. Verified by instantiating
the real config and calling the selector both ways before doing any work.

orcarouter ships a bf16 PLE, so the fix was to make the declaration true:
convert the 51.2B-param table to FP8 and declare it. Its 128 PLE tensors sit
in one shard file with nothing else in it. Global amax 0.0894, per-shard
outlier ratio 1.66x, scale chosen exactly representable in bf16 so no
scale-rounding error stacks on quantization; amax maps to 446.17/448, no
clipping. Round-trip 2.655% RMS relative, 0.002% underflow, 0 saturation --
the same FP8-PLE treatment dealignai already shipped. MTP head (31 tensors)
and vision tower carried through untouched.

A second, independent blocker followed: orcarouter labels its 12 QSA layers
qwen_sparse_attention, which vLLM rejects; it accepts full_attention and
selects QSA via indexer_n_heads. Confirmed indexer_n_heads == 4 in both this
and the dealignai checkpoint before renaming -- without that check the rename
silently selects plain attention and serves a subtly wrong model that still
passes a healthcheck.

Measured on the live seat: healthy, coherent, KV 344,155 tokens @ 262,144 ctx,
MTP k=3 at 60.4% acceptance / 2.81 mean acceptance length, warm decode median
167.5 tok/s at conc=1 (n=5, spread 12.2%). The reorg note's dealignai figure
came from a different harness, so this is not claimed as a win over it; what
it does establish is that weight-only experts did not cost decode speed.

Still open: controlled quality A/B vs dealignai, and a deep-prefill probe at
262K. Rollback is two .env keys; dealignai remains on disk.

Also corrects the README's MTP-is-off section, stale since k=3 was deployed,
and adds a superseded-claims row to the quantization playbook.
2026-09-14 02:48:42 -07:00
vh f964a47262 flash-next-seat: Qwen3.8-Flash-Next on fv-ml1 GPU 2 with the n-gram table in host RAM
First seat whose weights do not fit its card. The model is 176B total -- a 125B
main model plus a 51B n-gram (PLE) lookup table -- at ~6B active per token. The
table is a pure embedding lookup, so it lives in pinned host RAM and the GPU
reads rows directly over CUDA UVA: ~78 GiB resident on a 95.6 GiB card, 47.7 GiB
pinned of 566 GB. GPU 2 and GPU 3 were both idle, so this displaced nothing.

Checkpoint dealignai/Qwen3.8-Flash-Next-ABLITERATED-NVFP4 @ be794b99, pinned by
revision: NVFP4 W4A4 routed experts, FP8 PLE table, everything else at source
precision. Chosen over better-liked builds because its provenance states
protocols and repeat counts -- AIME26 pass@1 98.75% over 30x8 repeats with a
stated SEM, full-set GSM8K, and a byte-equality audit covering all 31 MTP
tensors -- and because it declares text_config.ple_embedding_dtype, which is the
field vLLM reads first when selecting the PLE weight format. Builds that ship an
FP8 table without that declaration resolve to the unquantized path and fail on
load; the README records the check.

Requires vLLM #54371 (UVA PLE-offload, merged 2026-09-09T14:32Z), verified by
ancestry: the pinned nightly is +150 commits / behind_by 0 from the merge commit.
Not in v0.29.0, cut six hours earlier. The older worker-based offload (#53899) is
paused upstream and is not the path here -- its deadlocks, ptrace gate and
stale-output-under-graphs bugs all came from the separate worker process that UVA
does not have.

Five deliberate departures from the other seats on this box, each from a
measurement rather than a preference, all annotated in place:

  - no MTP: the vLLM recipe measured it worse at every concurrency on 4xH100
    (8-36% less throughput, 32-173% more latency, ~36% acceptance)
  - modelopt_fp4, not compressed-tensors: only the ModelOpt reader honours the
    ignore list keeping attention, shared experts, PLE and MTP out of W4A4
  - KV left at auto: fp8 KV on this model's QSA path is an unmerged RFC (#54426)
  - mamba-cache-mode stated explicitly: the model raises on mode "all"
  - 128K context and 8192 batched tokens, not the native 262K: #54764 and #54919
    make depth the risky axis, and sizing to the KV pool has never fixed a
    depth-driven crash on this hardware

Nothing is wired into LiteLLM. Pointing an alias at this seat changes what
existing callers receive and is a separate decision.
2026-09-12 23:05:29 -07:00