GB10 TP1 (Qwen3.8 Flash Next): alpha package at `--max-concurrency 16` gives +47% KV and faster C1/C4; one-box DFlash2+A16 export does not beat MTP
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Documentazione
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- github, rust
- Ambito
- infrastructure, performance
Direzione di ricerca
Start by reading the GB10 TP1 measurements and the alpha package README mentioned in the issue. Check how the README documents --max-concurrency and --mtp-draft-tokens, then decide whether to add the c16 recommendation and its benchmark context. Done when the guidance accurately reflects the reported results and distinguishes the one-box DFlash2 comparison.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Measurements from one DGX Spark (GB10, driver 615.71.09, kernel 7.0.0-1019-nvidia), in case they help with the GB10 TP1 defaults. Each package was benched on the same box, back to back, with no other traffic. Memory settings were identical: --memory-limit=-14GiB --embedding-table-storage disk --embedding-table-cache-size 2GiB, with page cache dropped before every launch.
Bench: llm_decode_bench.py, 8k context, 30 s per concurrency, temperature 1, 512 max tokens. Coding peak is the median of 10 runs. Single trials; run-to-run noise on this box is about ±5%.
| Package | Launch | KV tokens | C1 | C4 | C16 | Coding peak (median / max) |
|---|---|---|---|---|---|---|
local-inference-lab/Qwen3.8-Flash-Next-FLARE@gb10 (alpha, c32, MTP) |
default | 466,944 | 41.7 | 90.9 | 178.0 | 66.9 / 82.5 |
| same | --max-concurrency 16 |
688,128 | 44.6 | 103.3 | 170.9 | 64.2 / 78.2 |
| own TP1 export, DFlash2 + A16, c16 | --mtp-draft-tokens 7 --mtp-adaptive-verification --mtp-adaptive-verification-alpha 0.5 |
618,496 | 41.3 | 85.5 | 169.2 | 71.9 / 82.0 |
1. Lowering concurrency at launch on the alpha package. --max-concurrency 16 on the c32 alpha package raised the KV pool 47%. It was also faster at C1 (+7%) and C4 (+14%), and within noise at C16 and coding peak. Quality on it was unchanged: Hotel Lights x8 at xhigh 8/8 (temperature 0.7, top-p 0.95, seed 1000), tool calls 5/5, vision 8/8. For a single 128 GB GB10, c16 looks like the better default, or at least worth a line in the package README next to "--max-concurrency and --mtp-draft-tokens can be reduced at launch".
2. DFlash2 + A16 on one box. We exported the same recipe we use on TP2 (two Sparks, one RoCE cable):
- base checkpoint
nvidia/Qwen3.8-Flash-Next-FP4-Local; - export flags
--speculative-method dflash2 --mtp-draft-tokens 7 --online-mxfp8 --draft-head-quantization nvfp4 --force-moe-decode-a16 --max-concurrency 16; - main 972e28e4 plus
host-system-reserveanddflash2-tp-embedding-contiguous.
On TP2, switching to this recipe from MTP5 took the coding-peak median from 81 to 142 tok/s. On TP1 it gained 12% coding peak over the alpha at c16, lost 17% at C4, and had 10% less KV. Fixed allocation was 76.78 GiB versus the alpha's 75.72 GiB, with 109 graphs. Our reading is that most of DFlash2's TP2 win comes from fewer cross-host verification rounds, so on one box MTP remains the better choice.
3. One-box export timing on GB10. The export took 93 minutes in total. Kernel tuning took 42 minutes from a cold cache. "Compile model forwards" took 36 minutes for 79 forwards, against 476 s for 56 forwards on the TP2 export: with about 89 GB resident in the exporting process, the automatic --compile-workers budget allowed only 2 compiler processes. Warmup, capture and packing were uneventful.
Happy to rerun anything with different flags.
- Lingua principale
- Rust
- Stelle
- 800
- Fork
- 106
- Merge medio
- 1g 3h
- PR unite (30g)
- 100
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di NVIDIA/hyperflare-inference
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
NVIDIA/hyperflare-inference#268 ·
I maintainer di solito rispondono entro 1 giorno
-
break out engram wait timeApertaarea:caching area:engram enhancement performance triage:design-review
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
NVIDIA/hyperflare-inference#230 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
NVIDIA/hyperflare-inference#278 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
NVIDIA/hyperflare-inference#276 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
NVIDIA/hyperflare-inference#271 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di NVIDIA/hyperflare-inference
Issue simili
-
bug UI
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
wardian-app/Wardian#1746 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
jlcodes99/cockpit-tools#3125 ·
I maintainer di solito rispondono entro 2 giorni
-
bug user-sprint
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
Vondor/KassenSturz#967 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
area:build bug effort:low P5 source:agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno