Flash-Next v2.0.1

Flash-Next v2.0.1: Qwen3.8-Flash-Next at an 806,792-token KV pool on 4x RTX 3090 (TP2 x PP2 + EP, MTP K=3, host-mapped PLE, host-resident embeddings).

v2.0.1 is v2 plus a port of upstream vLLM PRs #54442 and #56802 (issue #54437), which fix response_format / guided JSON failing under concurrency on the pipeline-parallel shape. Maintainer-reported, measured on the reference host with the shipped serve command (the requalification record, raw requests and logs are not published; the two upstream PRs are public): 80 structured requests across four load cells pass with every body schema-valid and zero grammar rejections, where v2 passed 8/10, 1/10, 2/10 and 6/10 under load. No throughput regression was found on a two-boot ladder: 0.978-1.028 of the v2 median at 4K/32K/131K/261K in both thinking modes. Same checkpoint, same serve command, same KV budget.

Source identity (see upstream/PIN-v2): vLLM fork tag v2.0.1 = commit ad5c3c223999de577b04cdb9caeab2dcb76b61b9, tree 5426cf19586a66946a1d8f7e68f48bdc7f52d62d. scripts/build-v2.sh asserts both.

Assets (four project files; the two "Source code" archives below them are generated by GitHub):

• v2.0.1-from-upstream-e962733e08.bundle.gz - the delta bundle over the public upstream commit. The checksum file hashes the uncompressed bundle: gunzip first, then sha256sum should give eb2b17399794512d57156fff1e9b2c72af18c8b4dd6c55abd1dd0ed39097e9e3. The gzipped asset as downloaded: sha256 7145fd659caea704d2b80c0a40a9bf3c7e5c5b5132de219fc21eea5048f42980.
• e2-base-src.tar.gz - snapshot of the base tree (e2-base) the 76 patches and the combined diff apply to
• build-artifacts-sm86-py313-cu130.tar.gz - the 22 compiled build products from the reference host (optional; the pinned upstream wheel gives the same files)
• build-artifacts.list - the list of those 22 files

Hashes of every asset and of the patch series: release/v2/SHA256SUMS.v2.0.1 in the tree (run cd release/v2 && sha256sum -c --ignore-missing SHA256SUMS.v2.0.1 from a checkout; place the downloaded assets there to verify them too).

Read the README section "Known behaviours of the Qwen3.8-Flash-Next architecture in vLLM" before putting this in front of clients: two behaviours remain open and documented (an occasional empty completion on a warm repeat of a long cached prefix, and prefix-cache loss for a session that finishes while other long sessions are decoding).

Also in this release: container and install fixes (privileged LXC recipe with host GPU preparation documented, a health check that performs a real generation, a build preflight that detects a python without venv, a guard against an existing vLLM checkout shadowing the built tree).