Files
esh-pfi-infrastructure/stacks/flash-next-seat/.env.example
T
vh 2d83a895c1 docs(fv-ml1): reconcile GPU seat inventory and model lineage against running containers
Read from docker inspect, nvidia-smi and each model's own config.json rather
than from compose files or the gateway config, so the document records what is
deployed rather than what was intended.

Findings worth naming:

- char-rp drift. The LiteLLM config documents char-rp as G4-MeroMero-v2-31B on
  ana-ml2 GPU 0; :8016 actually serves gemma4-26b-a4b-it-nvfp4, a 26B 30-layer
  128-expert stock Gemma-4, on fv-ml1 GPU 1. Host renaming explains part of it,
  but 31B MeroMero-v2 and 26B stock gemma4 are different models and the comment
  block carries sampler defaults keyed to the model it names.
- Two gateway aliases are dead: erp-tune-v2 (:8098) and gemma4-26b-a4b-it-base
  (:8099). Nothing is listening on either; callers get a connection failure
  rather than a clear retirement error.
- Three different speculative-decoding methods coexist -- dflash k=7 with a
  separate drafter on mog-sec, qwen3_5_mtp k=3 on gen, mtp k=3 on flash-next.
  The method string is architecture-specific; copying a --speculative-config
  between seats without changing it will not work.
- Three seats run the floating :latest tag, so what they would pull on recreate
  is not what is running and was never recorded.
- Seven aliases resolve to vllm-gen on :8015, which is why GPU 0 shows draw
  during ordinary OpenWebUI use -- its auto-titling fires summarizer per turn.

Also commits the flash-next-seat MTP k=3 change made today: compose gains the
speculative-config with its measured rationale, and .env.example documents the
KV-cache reduction MTP requires (14 GiB OOMs, 10 GiB verified in production).
2026-09-13 22:28:58 -07:00

107 lines
7.2 KiB
Bash

# flash-next-seat — Qwen3.8-Flash-Next (abliterated) on fv-ml1 GPU 2, :8022.
# Copy to .env on the host at /opt/docker/compose/flash-next-seat/.env.
#
# This is the INITIAL configuration, stood up 2026-09-13. Values marked FIRST-BOOT
# are deliberately conservative and expected to be revised once the seat has
# reported its own memory budget and been bisected for depth. Do not treat them as
# measured — they are not yet.
# ── Image ───────────────────────────────────────────────────────────────────
# ⚠ MUST contain vLLM #54371 (UVA PLE-offload), merged 2026-09-09T14:32Z.
# Verified by ancestry rather than version string: this commit is +150 / behind_by=0
# from merge commit 3116c5d06bfe76501b3dd6b5434bfc7f3274f5e7. v0.29.0 does NOT
# contain it (cut ~6h before the merge) and neither does any nightly-<sha> tag
# dated 2026-09-09 or earlier — the nightly build runs ~06:16 UTC.
FN_IMAGE=vllm/vllm-openai:nightly-eed1f3d0c6043bd494424a22443ee198dd56f657
API_KEY=replace-me
# ── Placement ───────────────────────────────────────────────────────────────
# GPU 2 was completely idle (2 MiB) before this seat; GPU 3 still is. Every other
# compose GPU pin on fv-ml1 is 0 or 1, so this seat displaced nothing.
FN_GPU_ID=2
FN_PORT=8022
FN_CONTAINER_NAME=vllm-flash-next
# ── Model ───────────────────────────────────────────────────────────────────
# dealignai/Qwen3.8-Flash-Next-ABLITERATED-NVFP4 @ be794b990578ef3031eccf9f28e675a289a09ee9
FN_MODEL=/tank/aimodels/qwen38-flash-next-abliterated-nvfp4
FN_QUANT=modelopt_fp4
FN_SERVED_NAME=qwen3.8-flash-next-uncensored
FN_SERVED_NAME_THINK=qwen3.8-flash-next-uncensored-thinking
# ── The offload ─────────────────────────────────────────────────────────────
# The 51B n-gram table (47.7 GiB FP8) lives in pinned host RAM; the GPU reads rows
# over CUDA UVA. Without this the checkpoint needs ~126 GiB of VRAM and will not
# start on one 96 GiB card. fv-ml1 has 566 GB RAM / ~388 GB available, so the
# host side is not a constraint here — unlike every DGX-Spark report upstream,
# where host and device share one unified pool and "offload" frees nothing.
FN_ENGRAM_CONFIG={"cpu_offload": true}
# Card is dedicated -- one tenant, nothing to compete with. Measured at 262K:
# weights 74.36 GiB resident, 560,654 KV tokens, 2.14x concurrency.
# ⚠ This ratio is now ADVISORY ONLY -- see the KV pin below, which overrides it.
FN_GPU_MEM_UTIL=0.96
# ⚠⚠ 14.00 GiB, PINNED IN BYTES AND MEASURED THE HARD WAY (2026-09-13).
# 16.00 GiB was tried first and nearly OOM'd: a 155,497-token prefill drove GPU 2 to
# 97,074 of 97,887 MiB and the allocator logged "OOM on device 0 while trying to
# allocate 488636416 bytes (free: 422117376)" -- 466 MiB wanted, 403 MiB free. The
# request survived but that is one step before the mog-sec crash shape.
# ⚠ WHY THE ESTIMATE WAS WRONG: --kv-cache-memory makes vLLM SKIP MEMORY PROFILING
# and ignore --gpu-memory-utilization entirely. The profiler was the thing accounting
# for deep-prefill activation; pinning bytes turns it off. Do NOT take vLLM's
# "17.46 GiB to fully utilize" suggestion -- it is computed from a profile taken at
# max-num-batched-tokens depth and is 3.5 GiB above what a 150K request survives.
# Re-raising requires re-running the deep probe and reading the allocator log.
# VERIFIED at 14.00 GiB: 0 OOM warnings, 155,557-token prefill in 14.2 s, 2,085 MiB
# still free on the card at peak.
# ⚠ MTP ON (k=3) REQUIRES A SMALLER KV POOL THAN THE NO-SPEC SEAT.
# Measured 2026-09-13: the draft head adds ~5.08 GiB of weights and raises
# per-token KV cost ~16%. At the old 15032385536 (14 GiB) the engine OOMs at
# init with MTP enabled -- 79.44 GiB weights + 14 GiB KV = 93.44 against a
# 91.17 GiB budget. 8589934592 (8 GiB) is PROVEN to boot; 10737418240 (10 GiB)
# leaves ~1.73 GiB for activations and is the current setting. If the seat
# OOMs at init, drop to 8589934592.
FN_KV_CACHE_MEMORY=10737418240
# FULL NATIVE 262,144 (operator-directed 2026-09-13). The KV pool holds ~641K
# tokens, so a single max-length request fits with ~2.4x concurrency to spare.
# ⚠ STARTUP IS NOT A DEPTH TEST. Two open upstream issues make depth the risky
# axis -- #54764 (PLE short-conv prefill pads every request in a batch to the
# batch-MAX query length) and #54919 (long prefill starving active decode for 3-7
# minutes) -- and vLLM's own recipe admits a single 262K request was never tested.
# If deep requests misbehave, --max-num-batched-tokens is the lever, not this.
FN_MAX_MODEL_LEN=262144
FN_MAX_NUM_SEQS=16
FN_MAX_NUM_BATCHED_TOKENS=8192
FN_MAMBA_CACHE_MODE=align
# ── Prefix caching ──────────────────────────────────────────────────────────
# ⚠ THE ROLLBACK LEVER for open #54173 (CUBLAS_STATUS_INTERNAL_ERROR / illegal
# memory access in the GDN path, WITH prefix caching). Set to the empty string to
# disable. Leave FN_MAMBA_CACHE_MODE=align either way — Qwen4Exp raises on "all".
FN_PREFIX_CACHING=--enable-prefix-caching
# ── Vision ──────────────────────────────────────────────────────────────────
# 4194304 px = 2048x2048 -> ~5,125 image tokens. The checkpoint's own preprocessor
# declares 16777216 (4096x4096) -> ~16,384 tokens, which is both wasteful and fatal
# on builds enforcing the image-token count check. Same trap as stacks/mog-sec.
FN_MM_PROCESSOR_KWARGS={"size": {"longest_edge": 4194304, "shortest_edge": 65536}}
FN_LIMIT_MM={"image": 4}
# ── Misc ────────────────────────────────────────────────────────────────────
FN_REASONING_PARSER=qwen3
FN_REASONING_EFFORT=medium
FN_TOOL_CALL_PARSER=qwen3_xml
# Intentionally EMPTY. expandable_segments has corrupted retained tensors on this
# box before (quant playbook §3.10) and has never been tested against a pinned
# host allocation handed to UVA.
FN_ALLOC_CONF=
# ── NOT SET, on purpose ─────────────────────────────────────────────────────
# --speculative-config : MTP is off. vLLM's own recipe measured it WORSE at every
# concurrency on 4xH100 (8-36% less throughput, 32-173%
# more latency, ~36% acceptance) and open #55357 reports
# episodic 0% acceptance with repetition collapse.
# --kv-cache-dtype fp8 : fp8_e4m3 KV on this model's QSA path is an unmerged RFC
# (#54426). Do not copy it over from gen/mog-sec.