Qwen3.8-Flash-Next · Splash Quality GGUF · v4

Builds that fit the Hub's 128 GB line are in the family repository: a 4-bit (82.5 GB in memory) and a 5-bit (92.6 GB in memory) build, each with an 8-bit or 4-bit PLE table. Its 5-bit body is the Balanced body trimmed by 3.9 GB. This repository keeps the full Quality body.

GGUF quantizations of Qwen/Qwen3.8-Flash-Next for Splash 1.4.0 on Apple silicon.

This repository contains the Quality expert body (Quality-PLE8, Quality-PLE5, Quality-PLE4). Attention, Gated-DeltaNet, shared experts, hyper-connections, embedding/output matrices and PLE projections stay Q8_0; routed experts use the exact mix below. The streamed PLE table is separate from the resident body, so stored size and resident memory are different quantities. The family repository carries the builds that fit the Hub's 128 GB line; the other repositories of this release are linked below.

Quick start

Splash 1.4.0 or newer, a 128 GB Apple-silicon Mac, macOS 26.4 or later:

brew install incoai/tap/splash
splash serve --model Vardaan97/Qwen3.8-Flash-Next-Splash-Quality-GGUF:Quality-PLE8

For the other folders, use :Quality-PLE5 or :Quality-PLE4. Splash resolves :FOLDER to the eight split parts in that folder. The first start downloads them (152.8 GB for Quality-PLE8) and the vision projector (0.91 GB) from this repository. Splash then adds the DFlash2 draft it releases for Qwen3.8-Flash-Next, incoai/Qwen3.8-Flash-Next-DFlash2 (1.21 GB), by itself. It picks the draft from the model family it reads in the GGUF, not from the repository name, so you don't pass --draft-model; this repository ships no draft. Later starts reuse the downloads.

• Vision is on by default, through the BF16 projector at the repository root. Add --language-only to serve text only.
• Memory and context are planned automatically from the GPU working set. --ple-memory defaults to auto, which streams the PLE table from the SSD when memory can't hold it. --max-memory caps Splash to leave room for other applications.
• Wired limit. All our measurements used iogpu.wired_limit_mb=110592 on an M5 Max 128 GB (sudo sysctl iogpu.wired_limit_mb=110592, resets on reboot). A Mac at the default limit is untested.

At a glance

Hub GGUF panel. The panel groups split files by the quant tag in their filenames and shows the total download size, including the PLE table, which streams from the SSD and is not held in memory. All three table variants in this repository carry the same Q5_K_XL tag, so the panel shows them as one combined entry. The family repository lists its builds at their in-memory size, which fit a 128 GB Mac. The memory actually needed is the resident body in the memory table.

Which one should I pick

Measured on the earlier Splash build with native MTP (2026-10-19), not on Splash 1.4.0. The KLD figures don't depend on the runtime.

All nine variants are the same model. They trade disk, memory, speed and weight error. On agent tasks the four tested PLE8 variants are indistinguishable: 7–8/16 strict and 8–9/16 with the lenient FinQA re-grade, a one-task spread that is within noise for 16 single-trial tasks. PLE5 and PLE4 were not task-tested.

Our default: UD-Q4_K_XL-PLE8. It had the fastest decode, the lowest memory and the quickest load, and its agent-task scores are within noise of the others. We keep Quality-PLE8 as the quality reference, since its measured weight error is lowest.

The PLE table streams from the SSD (a 2 GiB cache in these runs), so the table choice changes disk size, not the resident body; PLE5/PLE4 runtime memory is in the release E2E table. Sweep decode rates come from each model's own agent workload, so they are descriptive rather than a controlled A/B. On an older build, UD was also faster on prose (122.8 vs 114.4–115.3 tok/s) but not on the 2K greedy city test (157.7 vs 158.3–161.9).

These custom variants were designed around 128 GB unified memory and PLE streaming. A full 262,144-token base context is a model capability, not an end-to-end validation for each quant.

Call it

Splash serves an OpenAI-compatible API on 127.0.0.1:8000. This is the release E2E's tool-call check, which expects two parsed get_weather calls:

curl -s http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "model": "Vardaan97/Qwen3.8-Flash-Next-Splash-Quality-GGUF:Quality-PLE8",
  "messages": [{"role": "user", "content": "Call get_weather exactly twice: once for Paris and once for Tokyo, both in celsius. Do not answer in prose."}],
  "tools": [{"type": "function", "function": {"name": "get_weather", "description": "Read weather for one city.",
    "parameters": {"type": "object", "properties": {"city": {"type": "string"}, "unit": {"type": "string", "enum": ["celsius"]}},
                   "required": ["city", "unit"], "additionalProperties": false}}}],
  "tool_choice": "auto", "parallel_tool_calls": true,
  "reasoning_effort": "high", "max_tokens": 4096
}'

Optional settings. None of these is required on 1.4.0. They reproduce the conditions of our earlier measurements.

• --max-context 176K (180,224 tokens) is the server limit we tested; the agent harness kept each request within 131,072 tokens. Without it, Splash plans the context itself. The native 262,144-token window is not validated for these files.
• --ple-memory 2G gives the 2 GiB PLE row cache our runs used; the default auto sizes the cache itself.
• --disable-ane, --idle-release off and --max-cache-disk 0 (SSD cache off) match the benchmarks. With the default --idle-release 10m, the weights are freed after 10 idle minutes and reloaded by the next request (loading took 41.4 s in the sweep).
• int8 KV and fp32 state are Splash's defaults and what the measurements used.
• --served-model-name flash-next adds a short model name for API calls.
• Reasoning: the benchmark requested "reasoning_effort": "high" through a custom chat template with a distinct high level. The GGUFs' own template supports low, medium and xhigh, so Splash renders high as xhigh. "none" turns reasoning off; --default-reasoning-effort sets a server default. Sweep sampling was temperature 1.0, top_p 0.95, top_k 20, min_p 0.

Offline. After one online start has installed the model, add --offline (or set HF_HUB_OFFLINE=1) to start it without contacting the Hub. A 40-hex --revision keeps Splash on one repository commit. To pre-fetch one folder only:

hf download Vardaan97/Qwen3.8-Flash-Next-Splash-Quality-GGUF --include "Quality-PLE8/*.gguf" "mmproj-*"

Memory and storage

Measured on the earlier Splash build with native MTP (2026-10-19), not on Splash 1.4.0.

Text-only (no projector), 176K context, int8 KV, fp32 state, 2 GiB PLE cache and a 110,592 MB wired limit. Download adds the 0.908 GB projector to the target shards; the DFlash2 draft (1.21 GB) comes from its own repository, and imatrix_unsloth.gguf_file (0.580 GB) is provenance only, which Splash does not download. Resident body is the target tensor bytes without the streamed table, from the GGUF headers. Peak after load is Splash's Metal allocation high-water mark after loading plus a 64-token warmup; sweep peak is the highest over the roughly one-hour agent run. Neither is process RSS. Whole-machine memory in use peaked at 124.2–124.6 GiB during the four PLE8 sweep runs, including the sandboxed harness, and swap never grew above its starting baseline (about 1.0 GiB). Weights loaded is from the server log; the OS file cache was not controlled. Rows without a sweep run are covered by the release E2E table, which also loads the projector.

Benchmarks (M5 Max 128 GB)

Splash 1.4.0 install check

Passed, 2026-10-22. This ran on stock Splash 1.4.0 (1482f6bb) on an M5 Max 128 GB with the wired limit at 110,592 MB.

• How it ran: exactly as a user runs it, splash serve --model REPO:FOLDER, with Splash's defaults (vision on, automatic memory and context) plus --max-cache-disk 0.
• What it downloaded: the Hugging Face cache already held these exact files, matched by SHA-256, so the large shards weren't downloaded again. On the first start, Splash fetched the 1.21 GB DFlash2 draft from its own repository by itself, and nothing else.
• Context: its automatic plan held the model's full 262,144-token window.

The checks:

• 17 × 23 answered 391.
• A code planted in an ~8K-token prompt was retrieved.
• Two get_weather calls (Paris and Tokyo, celsius) came back as parsed tool calls.
• A synthetic receipt image was read into a JSON schema with all 6 fields correct.

The time to Ready includes loading the weights; the first start also includes the draft download. Peak memory is Splash's Metal allocation high-water mark after the checks, not process RSS.

The family repository's Quality-PLE8 folder holds the same bytes as this repository's (identical SHA-256). Quality-PLE5 and Quality-PLE4 use the same body with smaller tables and were not launched.

Scored agent sweep, 2026-10-18/19

Measured on the earlier Splash build with native MTP (2026-10-19), not on Splash 1.4.0.

Method. Nine local Flash-Next builds ran one at a time through the same sandboxed agent harness on the M5 Max. Each faced 16 deterministically graded tasks from public benchmarks (one trial each), four repeat attempts (F1 and H3 twice more) and one separately judged finance write-up (F3). All used the same Splash build with native MTP, text-only serving, reasoning high, temperature 1.0 / top_p 0.95 / top_k 20, identical task order and seeds, a fresh server per model, a 131,072-token working context, per-task time caps set from one UD pilot, and a two-hour window per model. The four rows below are the released PLE8 files: the same shard bytes, except that the custom bodies' tensor-free part 1 differs only by a shortened importance-matrix path. No score is transferred to PLE5 or PLE4.

Per-task primary outcomes: ✓ pass · ✗ wrong or invalid · ⏱ hit the time cap · ✓ˡ fails the strict final-line rule, passes the lenient re-grade.

Tasks: M1 AIME 2026 and M2 HMMT Feb 2026 (math, no tools); C1/C2 BigCodeBench-Hard and T1 Terminal-Bench (coding); F1 FinQA and F2 FinanceMath (finance); H1/H2 LongHealth at about 96K/64K input tokens, H3/H4 MedXpertQA (health); I1/I2 IFBench (instructions); B1–B3 BFCL v4 (tools).

Noise. n = 16 single-trial tasks. Eleven tasks had the same outcome for all nine sweep models: H1, H2, H4, I2 and B3 always passed; M1, H3, F2, B1, B2 and T1 always failed. Among these four variants, strict scores differ only on C2 (Quality passed) and on F1's answer format (Balanced passed strict); with the lenient F1 re-grade only C2 differs. A one-task difference is within noise, and no paired uncertainty analysis was completed. The whole nine-model sweep spanned 5–9/16 strict. These are results of one harness, not general capability rankings.

Notes. The lenient re-grade changes only F1's format rule: it accepts source-reference lines after the numeric FINAL ANSWER: line. It is a post-hoc sensitivity check; strict stays the primary score. F3, an adapted FAB financial-variance write-up, is judged separately and is not in /16. All four scored 3/5 and failed the combined gate: the Sonnet 5.5 judge passed all five criteria, but the deterministic signed-figure gate rejected two. UD's F3 attempt also used the whole 131,072-token working context. B1/B2 failed for every model, and the harness showed tool results to the model as render errors in those tasks, so the tools column says little about tool-use ability. T1 and most M1 attempts hit their caps. Wall includes load, warmup, solving, archival and cleanup (Balanced's includes substantial teardown) and excludes cooldowns. Decode is Σ(output × logged tok/s)/Σoutput over completed server requests with ≥500 output tokens (50/52/53/61 requests), excluding warmup and cancelled requests. Metal peak is Splash's allocation high-water mark, not process RSS or whole-machine memory. MTP counters are proposal acceptance, not speedup.

Neutral KLD and perplexity

Same BF16 reference and neutral text, 87 × 4096-token chunks, 178089 scored tokens; base PPL 4.045181. Chunk SE is used for KLD uncertainty; PPL ratios are the measured tool summary. These are distribution comparisons, not task scores, and they don't depend on the runtime.

Balanced-PLE5 adds 0.000457 KLD (+3.44%) versus PLE8 while saving 16.000 GB. Quality-PLE5 (0.013128) and Max-PLE5 (0.012848) were measured on 2026-10-19 with the same scorer. Quality and Max PLE8 are effectively tied (0.6 paired SE). Full method, raw baseline logs and paired comparisons remain in KLD evidence.

1M context

Measured on an earlier Splash YaRN build without MTP, not on Splash 1.4.0. Splash 1.4.0 turns on YaRN when --max-context goes past the 256K native window, up to 1,010,000 tokens; this test has not been rerun on it.

Original unsloth UD-Q4_K_XL with its stock IQ4_NL table, factor 4, max context 1010000, int8 KV, fp32 state, 2 GiB PLE cache: at 1000000 prompt tokens it retrieved 8/8 planted facts and returned NOT_FOUND for the absent fact, with 614.3 s cold TTFT, 1628 prefill tok/s, 28.5 decode tok/s and 91.9 GiB Splash peak, no new swap. Retrieval was also 8/8 at 262K and 520K. The sum-of-amounts test failed at 520K and 1M. This does not validate arbitrary long-context reasoning, other quants, or the custom bodies at 1M. Reproduction.

Release E2E smoke, 2026-10-19

Measured on the earlier Splash build with native MTP (2026-10-19), not on Splash 1.4.0.

The E2E decode figure is a single cold 300-token sample with reasoning off, so it reads lower than the agent-sweep decode rates in the glance box. The two numbers measure different things.

Completed 2026-10-19T07:14:16Z on the exact upload-source assembly, the stock MTP head of that build and the shipped projector; int8 KV, fp32 state, 2 GiB PLE cache. Prose timing disables reasoning and EOS for exactly 300 completion tokens; the other checks request high reasoning. Load timing is process launch to ready, with the existing OS file-cache state (not a certified cold load). The six-prompt smoke battery covers text/math, executed code assertion, two tool calls, an 8K-token needle, exact instruction format and a 300-token prose decode. Projector presence/header checks do not establish image/PDF correctness. These checks do not replace the scored sweep or validate streaming, Responses API, full-context correctness or broader hardware.

Variants

One repository per expert body, with PLE8/PLE5 folders together and PLE4 where offered; the family repository carries the 4-bit and trimmed 5-bit builds that fit the Hub's 128 GB line. All sizes are decimal GB; target downloads exclude the projector and importance matrix. These are mixed quantizations, not uniform Q8/Q6/Q5/Q4 files.

File labels. Shards are labelled for the Hub: UD-Q4_K_XL for the UD body, and Q5_K_XL for the Quality, Balanced and Max bodies. Q5_K_XL is the nearest standard class for these mixes: expert gate/up Q5_K/Q6_K, expert down Q5_1/Q8_0, attention Q8_0. That works out to about 6.1–6.3 bits per weight over the body, excluding the streamed PLE table (computed from body size and parameter count). The exact per-tensor mix is listed on each model card. The table precision is in the folder name: PLE8 = Q8_0, PLE5 = Q5_1, PLE4 = IQ4_NL.

‡ Measured in the release E2E (2026-10-19, earlier build with native MTP) on the exact public files: Splash's memory plan at load with --max-context 176K, vision projector loaded, 2 GiB PLE cache. Other rows come from the earlier v2 protocol.

PLE5 uses the same body as its PLE8 sibling and a Q5_1 table: 38.4 GB, 6.0 bpw (32 values per 24-byte block). Balanced-PLE5 KLD and top-1 are measured on the same neutral protocol as its PLE8/PLE4 baselines; its chunk SE is reconstructed from 87 running chunk means. Quality-PLE5 (0.013128, +4.1% vs Quality-PLE8) and Max-PLE5 (0.012848, +2.5% vs Max-PLE8) were measured on 2026-10-19 with the same scorer and reference, on the exact release files. For these two rows the SE shown is the scorer's own; the other rows use the chunk-SE reconstruction. The model treats table error as independent of body error; these estimates are not task results. Native resident tensor bytes exclude the table and are unchanged.

Native resident bytes sum target tensor bytes with the PLE table excluded. Splash target bytes and KV capacity come from runtime-format status on earlier builds; Splash 1.4.0 plans memory itself, so its figures can differ. KV capacity is shared across lanes; it is not a tested single-request context length. PLE8 runtime status here is from the SVG stack, with int8 KV, fp32 state, a 2 GiB PLE cache and a 110,592 MB wired limit; the SVG requests used 32,768 context. † Historical status from the earlier release build. These are separate cohorts, not matched memory comparisons. Evidence.

Ultra256-PLE8: a historical Q8-focused larger-memory archive is recorded, but no validated public release is offered. Max-PLE4: not released. Lite: not released (missing body shards). Quality-H6 is an experimental control, outside this release family.

Exact Quality tensor mix

Layer numbers are zero-based. blk.N. prefixes are omitted below; global tensors are named literally. Each listed type applies to every tensor of that suffix on the listed layers. All offered table variants share the same expert body. Q4_0, Q4_1 and Q4_K are absent from these custom bodies; PLE4 uses IQ4_NL specifically. Q5_1 down-projections are distinct from Q5_K gate/up tensors. Header/recipe evidence.

Tensor bytes by actual storage type (GGUF headers/padding excluded; bytes are derived from the recorded shapes and block sizes):

PLE streaming avoids keeping the full table resident but still uses a row cache.

Speed on earlier builds

Measured on older Splash builds with native MTP, before the 2026-10-19 sweep build, not on Splash 1.4.0. All figures are single-stream observations on one 128 GB M5 Max (40-core GPU); they are workload- and build-specific. The older STACK and the #447-based build are separate measurements.

City is the 2,048-token greedy workload; prose here is the prose category from the mixed corpus, not its all-category aggregate. Exact-token cold/warm/edit protocol, thermal gating and depth differ by row; no cross-row speedup is claimed. Quality prefill was 2,466 tok/s at 4K and 1,836 at 32K. Max's older SVG median decode was 98.6 tok/s; that is not a city/prose benchmark. On Balanced-PLE8, the final older STACK measured aggregate 72-prompt throughput 105.3 → 115.1 tok/s (+9.4%) vs the stock head, with 72/72 identical greedy outputs; the post-hoc analysis included PLE-related disk-tainted launches. Earlier-stack evidence.

#447-based build. These tests used original UD-Q4_K_XL with its IQ4_NL table, not the custom variants or the UD+Q8 assembly in this family.

The last row is the tested no-drafting proxy, not a trained external draft comparison and not a matched MTP-off run. Its prose launch was unbracketed. The native-MTP aggregate averages 114.7 tok/s versus 33.1; treat this as descriptive. City was cool-down gated; prose/TTFT ran warm, one launch per arm, bracketed by the older fork reference except the no-draft proxy.

Long-context tests used 131,072 and 174,080 prompt tokens, then 256 greedy output tokens at depth, --max-context 176K, int8 KV, fp32 state and a 2 GiB streamed table cache; one launch per arm, no cooling gate. These establish UD runtime performance, not custom-variant long-context quality or memory fit. The greedy outputs matched the no-draft proxy on 30/72 prompts; matching verify-row composition gave 72/72. The batched kernels make rows depend on their verify batch, so cross-mode bitwise identity is not promised. Runtime evidence.

How quality was measured

• KLD: BF16 neutral logits from base commit de4b8e4d, held-out prose in 30 languages; 87 chunks at 4,096 context, 178,089 scored tokens. One local Metal scoring harness, microbatch 512, versus reference CUDA batch 2,048. The PLE table stayed in CPU memory. These scores measure weight error outside Splash; the absolute harness offset is unmeasured. Use chunk and paired standard errors, not the tool's independent-token error. Method and reference datasets, ranked table, paired table.
• Publication gates: Quality-PLE8 has its own completed KLD run. Against Balanced-PLE8 it is −0.000660 ± 0.000125 paired se (5.3 se lower). Max-PLE8 is −0.000730 ± 0.000101 (7.2 se lower), meeting the existing requirement of at least two paired se. Quality vs Max is only +0.000070 ± 0.000117 (0.6 se): no established quality separation. Paired values recover rounded running means and need not equal subtraction of the final six-decimal summaries. Quality-PLE8 vs UD is −43.2% KLD on this set; no general task-quality percentage is implied.
• SVG: three prompts × seeds 17/42/123, thinking on, medium effort, temperature 1, top_p 0.95, top_k 20, 24,000-token output cap; one blind Sonnet 5.5 rater, five criteria. Invalid/capped outputs score 1. The Quality re-score uses byte-identical images; it is not an independent replication. Earlier models and the later Quality anchor ran in different thermal/runtime cohorts. The differences among Quality, Balanced, Max and UD do not establish a reliable task ranking at this sample size.
• Coding: a 13-task, 320-point coding-agent harness, thinking off, one run per model on the earlier STACK. Quality and UD are descriptively tied. Permission rejections ended sessions early across the harness; these scores include that confound. Balanced/Max have no run of this coding suite; agent-task results are in Benchmarks.
• End-to-end behaviour: the trace review found no wavering or truncation in Quality's nine SVG cells; Max had four wavering traces and Balanced had two plus one truncation. These are descriptive judgments by a non-blind trace reviewer, not an additional benchmark win.

Task evidence and protocol notes. UD table and runtime cohorts.

Reproducibility

Source: unsloth's BF16 conversion, quantized with its importance matrix and a per-tensor type file. The target is an eight-part split; shard 3 contains only per_layer_token_embd.weight. Quality-PLE8 is assembled from the measured Quality body and the measured Balanced-PLE8 table; its recipe/type file describes that assembly, not a claimed new quantizer run.

Each offered folder includes recipe.txt, tensor-types.tt, plan.txt, quantize.log, and sha256sums.txt. The explicit tensor map and release size plan are reconstructed from recorded headers; the recipe is the historical rule file, and assembly/body evidence is labeled in each log. The complete descriptor inventory is in TENSOR-INVENTORY.md. The original first part contains no tensors: only its importance-matrix path is shortened to imatrix_unsloth.gguf_file; all weights are unchanged. See VARIANTS.md for source identities and hashes. All PLE5 folders reuse the byte-identical 38,400,184,512-byte Q5_1 shard, SHA-256 49339744a76e378904a6574ff469c5fa44c60388c411f53abda4c915d13a8061. Its completed build/splice and independent rehash receipts agree; full-set checks read headers only. All PLE8 folders use the byte-identical table shard, SHA-256 cde244f3da0df479d14fb328dd4ef9fcb5e048b594a4f615974730132dcf1acb; repeated content is eligible for Hub storage deduplication, which does not remove each folder's logical download size.

Repository layout

README.md  LICENSE  VARIANTS.md  MEASUREMENTS.md  UD-EVIDENCE.md  TENSOR-INVENTORY.md
Quality-PLE8/  Qwen3.8-Flash-Next-Splash-Quality-PLE8-Q5_K_XL-00001-of-00008.gguf … 00008-of-00008.gguf
Quality-PLE5/  Qwen3.8-Flash-Next-Splash-Quality-PLE5-Q5_K_XL-00001-of-00008.gguf … 00008-of-00008.gguf
Quality-PLE4/  Qwen3.8-Flash-Next-Splash-Quality-PLE4-Q5_K_XL-00001-of-00008.gguf … 00008-of-00008.gguf
mmproj-Qwen3.8-Flash-Next-BF16.gguf
imatrix_unsloth.gguf_file
kld/  KLD-TABLE.md  METHOD.md  PAIRED-RELEASE.md  logs

Limitations and known issues

• Runtime. The agent sweep, speed, memory and E2E results come from earlier Splash builds with native MTP. Splash 1.4.0 decodes with the DFlash2 draft and plans memory itself, so its speed, memory and output with these files can differ; they have not been measured yet.
• Hub install path. Installing from the Hub with stock Splash 1.4.0 was checked on one variant of this body (see Splash 1.4.0 install check). The other table variants use the same body.
• Wired limit and hardware. Every measurement is from one M5 Max 128 GB with iogpu.wired_limit_mb=110592. At the default limit Splash plans a smaller budget and may hold less context or stream more of the model from the SSD; that is untested, as are other Macs and memory sizes.
• Reasoning effort. With the GGUFs' own chat template, high renders as xhigh; the benchmark's distinct high level came from a custom template.
• Answer format. In the FinQA task, three of these four PLE8 variants (and six of the nine sweep models) put source references after a required FINAL ANSWER: line. If you parse the last line, say so in the prompt or post-process.
• Context. Long tool-heavy sessions can fill the window: UD's F3 attempt used the whole 131,072-token working context. Beyond 176K is untested with these files; the 1M result used original UD on an earlier build.
• Reproducibility. Batched kernels make outputs depend on batch composition and cache state, so even greedy outputs are not bitwise reproducible across those conditions.
• Not validated beyond the text-only agent sweep and the six-prompt release smoke: image/PDF correctness (vision is on by default, but our checks only loaded the projector), streaming and Responses API details, cancellation and cache behaviour, full 262,144-token correctness, and long-context or code-text KLD.
• Small samples. 16 single-trial agent tasks, a common BFCL harness defect, one blind SVG rater, and permission-rejection confounds in the earlier coding runs.
• PLE5 has no task benchmarks (including SVG and coding). All three PLE5 variants have measured KLD: Quality 0.013128, Balanced 0.013727, Max 0.012848. UD+Q5_1 measured city +2.9%, approximately equal to UD+Q8, with prose/TTFT within noise; those UD-body observations do not establish speed for the custom PLE5 bodies.
• Quality gaps. Quality-PLE8 lacks matched city/prose, 4K–64K TTFT/prefill and 128K/170K fit and decode on the sweep build. Quality-PLE4 also lacks sweep-build speed, SVG and coding; its historical HTTP/113K smoke is not current validation.

Changelog

v3 → v4 (Splash 1.4.0). The model files are unchanged. The MTP head is removed and this card is rewritten.

• Instructions now use the released Splash 1.4.0 (brew install incoai/tap/splash, then splash serve --model REPO:FOLDER). The source build, PR checkout and SPLASH_MTP_* settings are gone.
• Speculative decoding is DFlash2: Splash downloads the released draft by itself. The native MTP head (mtp/) is removed from the repository and the instructions; MTP-era measurements stay, labelled as such.
• Vision is on by default; memory, context and PLE streaming are planned automatically. The earlier benchmark flags are listed as optional.
• Download sizes no longer include the 2.787 GB MTP head. Added the Hub-panel note, family-repository links and a placeholder for the 1.4.0 install check.

Earlier. v3 renamed the custom-body shards from -Mixed- to -Q5_K_XL- so the Hub's GGUF panel classifies them (contents and SHA-256 unchanged), moved to public per-model repositories, and added the scored agent sweep, the release E2E smoke and the 1M-context note. v2 split the release into one repository per expert body, added Quality-PLE8 and Max-PLE8 with measured KLD and paired uncertainty, added blind SVG/coding results and exact tensor mixes, and put valid YAML at the top of the card.

Credits

• unsloth: source BF16 GGUF conversion, importance matrix and BF16 vision projector, redistributed unchanged. Inherited general.quantized_by, general.repo_url and general.tags still name unsloth.
• Qwen: the base model and license.
• Splash contributors: the runtime and the DFlash2 draft.
• The BF16 reference logits and neutral evaluation text come from the public datasets cited in kld/METHOD.md.

Licence

These files are derivatives of Qwen3.8-Flash-Next under Qwen Community License 1.0. Read LICENSE for the full terms; it is identical to the base repository's license.