qwen38-megakernel v2026.11.07

Prebuilt packages of the engine and its server for Qwen3.8-27B on one 24 GB NVIDIA GPU: unpack, install one Python
package, point it at the model, and run. No CUDA toolkit, no compiler, no build.

Fixes from an outside review, same tokens

An outside review of this repository (eleven static audits of v2026.11.05's source, one per part of the engine and
server) found one high-severity bug, a set of medium ones and a list of smaller items. This release fixes those that
cannot change the output of the default settings. On the default settings the engine's token ids are identical to
v2026.11.05's, bit for bit; the changes are in configurations off the defaults, error paths, the server's request
handling and memory use. Speed changes were left for later releases.

What changed since v2026.11.05

Engine

• Exact reuse with a short KV window: with MK_EXACT and MK_KV_WIN of 1,280 or less, a checkpoint's window ring
  could hold the wrong rows when a prefill chunk was longer than the ring, so a resumed conversation read the keys and
  values of other positions. Under that combination the prefill chunk is now capped at the ring's length (1,280 or 1,920
  tokens) and the console says so. The presets' 2,048-position window was not affected.
• fp16 KV cache with MK_PREFILL=mk: the MTP catch-up stored its keys and values through the q8_0 path, writing
  through a null pointer; it now stores fp16 rows as every other store site does.
• MK_MTP_WIN on presets with a window ring: a window start that was not a multiple of 32 could read past the ring;
  the start is now aligned to 32 positions.
• --agents checkpoints: a prompt whose last prefill chunk was 32 tokens or fewer saved no checkpoint (about one in
  eight chunk-fed prompts), so its next turn read a whole turn or the whole prompt again. Every prompt now gets one.
• C API: a step() straight after unpark() or side_end() would have replayed another sequence's decode state; it
  now throws "prefill first" where it would read it. The server always prefills there and is not affected.
• Loader: a GGUF whose rope.dimension_count, rope.dimension_sections or full_attention_interval differs from
  the values compiled into the kernels is refused (a missing key is a warning); -c below 1 is an argument error; a KV
  cache that does not fit on a driver without the system-memory fallback (Linux) is reported with its size and the
  options that fit, instead of a bare CUDA error.
• Memory: the prefill scratch is 42 MB smaller at a 2,048-token chunk (21 MB at 1,024) when every gate / up pair is
  fused, as in the shipped GGUFs, and the attention partials about 2 MB smaller per engine and per agent slot: a little
  more context when the cache is sized to fit.
• Smaller items: saved state files are keyed on the GPU as well; warnings where pinned memory ran short; the
  opt-in deep-pass build's tier gate under sampled drafts reads only confidences fixed before the drafts it decides
  about (not re-measured in this release).

Server

• Text parts are joined with newlines: a message whose content is a list of text parts (Claude Code's text blocks,
  Codex's input_text parts, AI-SDK clients) is now joined with newlines, as with images and as llama-server does;
  before, the parts ran together.
• Lone UTF-16 surrogates in a request (a string cut inside an emoji) become U+FFFD instead of failing the request,
  and an error after a stream's headers closes the connection instead of writing a second response into the stream.
• Tool schemas are checked before the prompt is read: a malformed tool is a 400, not a 500 after a full prefill.
• A client that stops reading a stream for 60 seconds counts as gone; it used to hold the engine for up to 600 s.
• --agents uses one checkpoint slot for the engine's own short sequence (MK_CK_SLOTS=1 unless set): about
  1.2 GiB less pinned host memory.
• Console warnings where text was dropped silently (text after a tool call, an Anthropic assistant prefill, Anthropic
  fields the server does not act on, tool-call arguments in the history that are not JSON), TCP_NODELAY on connections,
  and /props no longer fails on a non-integer MK_IMAGE_MAX_PIXELS.

Docs: the exactness claims now name exactly what scripts/gate.sh and scripts/exactness.py check and what is
not scripted, and numbers that were stale or undated are fixed.

Changed behaviour: the newline joining changes the prompt that clients sending text parts get, so a conversation
cached by an earlier version is read once more on its first turn after the update. Requests with a tool that is not an
object, has no name or whose parameters are not an object get a 400. The server started with --ctx 0 and without
--agents now stops at load (it ran with no usable context before). The loader refusals and the prefill-chunk cap above
apply only to the configurations named.

What the engine is and how it performs: README.
In short: output that speculation, cache reuse and the OS never change, 1.9 to 2.1x llama.cpp's decode speed on an RTX 3090
on q8_0, conversations and agent sessions that resume where they left off, the OpenAI, Anthropic and OpenAI Responses APIs
for coding agents and chat UIs, and the model's full 262k context on 24 GB with preset D or F.

Downloads

package	for
qwen38-megakernel-v2026.11.07-windows-x64-sm86.zip	Windows 10 / 11 x64
qwen38-megakernel-v2026.11.07-linux-x64-sm86.tar.gz	Linux x86-64 and WSL2, glibc 2.38 or newer (Ubuntu 24.04, Debian 13, Fedora 39 and newer)

Checksums: SHA256SUMS.txt.

What you need

• An NVIDIA GPU with 24 GB of VRAM and compute capability 8.6 (RTX 3090 / 3090 Ti class; tested on an RTX 3090). More
  than 4 drafts, and --agents with 2 or more slots, need at least 80 SMs. RTX 40-series cards (8.9) can run this code
  but are untested; RTX 50-series cards need a
  source build.
• An NVIDIA driver that supports CUDA 13.2 (nvidia-smi shows "CUDA Version: 13.2" or higher). The CUDA runtime is
  inside the engine; nothing else from CUDA is needed.
• An x86-64 CPU with AVX2, and Python 3.10 or newer.
• The model, which is not included: Unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf (and mmproj-BF16.gguf for images).

Quick start

pip install -r requirements.txt huggingface_hub
hf download unsloth/Qwen3.8-27B-GGUF Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir ~/models
scripts/serve.sh            # Windows: scripts\serve.bat (models in %USERPROFILE%\models)

The server listens on http://127.0.0.1:8080 with 120k tokens of context. For the full 262k context pass 8080 262144
and, on Linux, set MK_KV='K*=6,V*=5' MK_KV_WIN=2048 (preset D); scripts\serve.bat picks preset F above 240k on its
own. Several agents at once: MK_AGENTS=4 scripts/serve.sh 8080 0. Settings for Claude Code, Codex, Qwen Code, Aider,
Open WebUI and six other clients are in docs/CLIENTS.md; every setting is in docs/CONFIGURATION.md.

Checked before release

scripts/gate.sh ran on this release's engine against a reference recorded the same day on v2026.11.05's kernels: 46
checks, 0 failed. scripts/exactness.py passed 65 of 65 checks and its 107 results were identical to the reference:
greedy ids at 0, 4 and 7 drafts, and cache reuse against a fresh server (follow-ups, edits, sampled follow-ups, parked and
resumed conversations, side requests, --agents) on q8_0, preset D and preset F, up to about 255k tokens. The state
digests across prefill chunk sizes, the CLI's greedy, sampled, penalty and chain=2 ids, draft-depth ids on four prompts,
the parallel slots' outputs and the KL reports on q8_0, D and F were identical to the reference too. New C API checks
(a resume under MK_KV_WIN=1024, a step refused after an unpark, slot checkpoints) passed, and so did the server's CPU
test suite (309 tests). Every kernel's register count and spills are unchanged from v2026.11.05's build.
The Linux package holds the gated build's own engine and host objects, relinked against the CPU-only llama.cpp.
The Windows package is a native build of this tag and was not gated itself: unpacked and run with a bare PATH (System32
only), its CLI token ids at 7 and 0 drafts and its KL report were identical to the Linux reference, and its server
answered a request.
Decode and prefill speed were not measured for this release: no kernel changed for speed. The benchmark tables in the
README and docs/BENCHMARKS.md are v2026.11.05's.

Source and licenses

Built from 8d28080 (this tag), sm_86, with llama.cpp b10246 (CPU only). Licensed under the GNU AGPL v3. The packages
also contain llama.cpp's libraries (MIT), the NVIDIA CUDA runtime and, on Windows, the Visual C++ runtime: see
THIRD_PARTY_NOTICES.md. This engine started as the megakernel of open-jet by
Louis Forster.

qwen38-megakernel v2026.11.05

Prebuilt packages of the engine and its server for Qwen3.8-27B on one 24 GB NVIDIA GPU: unpack, install one Python
package, point it at the model, and run. No CUDA toolkit, no compiler, no build.

Faster at depth, same tokens

Reading long prompts is faster on every KV cache, and decoding deep into a long context is faster on the low-bit KV
presets, with the same output bit for bit. This is the full-context work: the gain grows with the context.

RTX 3090, UD-Q4_K_XL, sustained, near the card's 480 W limit	earlier kernels	v2026.11.05
preset F, decode step at 258k tokens, default draft gates	40.84 ms	36.28 ms	-11.2%
preset F, decode step at 258k tokens, 7 drafts	47.53 ms	43.97 ms	-7.5%
preset F, decode step at 101k tokens, 7 drafts	34.39 ms	32.99 ms	-4.1%
preset F, read a 258k-token prompt	285.3 s	257.1 s	-9.9%
preset D, read a 258k-token prompt	289.9 s	260.1 s	-10.3%
preset F, read a 101k-token prompt	73.8 s	69.0 s	-6.5%
q8_0, read a 101k-token prompt	71.4 s	67.8 s	-5.0%
q8_0, read a 40k-token prompt	22.5 s	22.0 s	-2.4%

(CLI under WSL2, one session, old and new alternating; 2026-11-05. Decode: against the commit before these kernels,
3 runs each. Prompt reads: MK_PFX=64, which keeps the earlier prompt-read kernel, against the default, 1 to 3 runs each.)
Short interleaved runs overstate gains like these, because in real work the GPU runs into its power limit, so these
figures come from sustained runs.

A full run of this release

The server benchmark suite, one session, the same clients, prompts and model file as v2026.11.03's run:

RTX 3090, UD-Q4_K_XL, 7 drafts	v2026.11.03	v2026.11.05
preset F at 262,144 tokens: read a 260,896-token prompt	311.7 s	278.7 s	-10.6%
preset F at 262,144 tokens: decode at that depth	69.7 tok/s	77.8 tok/s	+11.6%
preset F, decode at 101.6k context	116.7 tok/s	123.2 tok/s	+5.5%
preset D, decode at 101.6k context	104.9 tok/s	110.6 tok/s	+5.5%
q8_0, decode at 101.6k context	115.4 tok/s	116.4 tok/s	+0.9%
q8_0, read a 101.6k-token prompt from scratch	72.5 s	68.5 s	-5.6%
q8_0, the 282 benchmark questions: right, total time	230, 1,607 s	230, 1,563 s	-2.7%

llama.cpp's unchanged binary, the control, also came out 0.9% to 1.9% faster on its decode rows between the two
sessions, with the GPU about 6 C cooler, and took 1.4% less time on the questions: read small changes against that. Against it in this session (b12024, tuned, 4 drafts), this engine on q8_0 decodes 1.9x as fast on short prompts
and 2.1x as fast at 101.6k context. All 282 answers on q8_0, preset D and preset F, and the 10 full-context answers on
preset F, are byte-identical to v2026.11.03's.

What changed since v2026.11.03

• Prompt read: a new attention kernel with fewer instructions per tile (pk_attn9). Saved states were byte-identical
  to the earlier kernel's on q8_0, preset D and preset F, up to 258k tokens.
• Decode on the low-bit KV presets: the attention kernels copy and convert low-bit K and V with fewer per-row branches
  and split the work across two groups of threads, with the same token ids. Decode speed on q8_0 did not change.
• Server limits, from an outside review of this repository: bodies in memory over all connections
  (MK_MAX_INFLIGHT_MB, 256), a request's first byte to the last of its body (MK_REQUEST_TIMEOUT_S, 300 s), connections
  (MK_MAX_CONNECTIONS, 256). A 3.8 MB body built to hit the placeholder search held the engine's lock for 13.8 s on
  Windows; it now gets a 400 in 0.06 s. Control characters from requests are escaped on the console.
• Engine checks: the slot calls refuse a slot listed twice, and a keep-warm thread that fails to start no longer
  escapes the C API.
• An opt-in -DMK_L2_TUNE=1 source build exposes the L2 prefetch budgets as MK_L2_* settings, for GPUs with another
  L2 size; scripts/l2_sweep.py times settings against the defaults
  (docs/EXPERIMENTAL.md).
• Kernel benches: bench/mmq_bench and bench/attn_bench test the engine's own prefill kernels in make check.
• scripts/exactness.py on Windows: it runs from a venv, and a package's BUILD_INFO.txt no longer stops it.

Changed behaviour: the limits above are on by default: past them a client gets a 503, or a closed connection when a
body takes too long to arrive. Malformed fields that used to give a 500 with an exception's text now give a 400: a content
part or tool call that is not an object, tool_calls or chat_template_kwargs of the wrong type, numbers past a float's
range, and temperature, top_p or min_p that are not finite fp32 numbers (NaN used to run as greedy). The server warns
at startup when it listens beyond loopback with no API key. The loader refuses a GGUF whose rope.freq_base or
layer_norm_rms_epsilon differs from the values compiled into the kernels, and warns when the key is missing.

What the engine is and how it performs: README.
In short: output that speculation, cache reuse and the OS never change, 1.9 to 2.1x llama.cpp's decode speed on an RTX 3090
on q8_0, conversations and agent sessions that resume where they left off, the OpenAI, Anthropic and OpenAI Responses APIs for coding agents and chat UIs, and the model's full 262k
context on 24 GB with preset D or F.

Downloads

package	for
qwen38-megakernel-v2026.11.05-windows-x64-sm86.zip	Windows 10 / 11 x64
qwen38-megakernel-v2026.11.05-linux-x64-sm86.tar.gz	Linux x86-64 and WSL2, glibc 2.38 or newer (Ubuntu 24.04, Debian 13, Fedora 39 and newer)

Checksums: SHA256SUMS.txt.

What you need

• An NVIDIA GPU with 24 GB of VRAM and compute capability 8.6 (RTX 3090 / 3090 Ti class; tested on an RTX 3090). More
  than 4 drafts, and --agents with 2 or more slots, need at least 80 SMs. RTX 40-series cards (8.9) can run this code
  but are untested; RTX 50-series cards need a
  source build.
• An NVIDIA driver that supports CUDA 13.2 (nvidia-smi shows "CUDA Version: 13.2" or higher). The CUDA runtime is
  inside the engine; nothing else from CUDA is needed.
• An x86-64 CPU with AVX2, and Python 3.10 or newer.
• The model, which is not included: Unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf (and mmproj-BF16.gguf for images).

Quick start

pip install -r requirements.txt huggingface_hub
hf download unsloth/Qwen3.8-27B-GGUF Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir ~/models
scripts/serve.sh            # Windows: scripts\serve.bat (models in %USERPROFILE%\models)

The server listens on http://127.0.0.1:8080 with 120k tokens of context. For the full 262k context pass 8080 262144
and, on Linux, set MK_KV='K*=6,V*=5' MK_KV_WIN=2048 (preset D); scripts\serve.bat picks preset F above 240k on its
own. Several agents at once: MK_AGENTS=4 scripts/serve.sh 8080 0. Settings for Claude Code, Codex, Qwen Code, Aider,
Open WebUI and six other clients are in docs/CLIENTS.md; every setting is in docs/CONFIGURATION.md.

Checked before release

The new package against v2026.11.03's, directly: greedy token ids at 0, 4 and 7 drafts and sampled ids at 7 drafts, on
UD-Q4_K_XL and Q4_K_M, were identical, bit for bit. scripts/gate.sh on this commit (36 checks) passed on both models,
with outputs identical to its reference. scripts/exactness.py gave 21 of 21 results identical to the commit before these
kernels. Token ids on long prompts, past the q8_0 window where the low-bit kernels run, were identical to the earlier
kernels in all 26 comparisons: q8_0, presets D and F and other low-bit formats, up to 258k tokens, at 0, 3 and 7 drafts,
greedy and sampled, second turns. Parallel slots past the window matched in 6 of 6, and 8 of 8 saved states were
byte-identical up to 258k tokens.
The native Windows build gave 21 of 21 exactness.py results identical to Linux, and preset F and D ids at 40k identical
to Linux over 512 tokens. It also matched the Linux reference in token ids at 7 and 0 drafts, the KL report, server replies
(text, thinking, an image and a cached image follow-up, the API test, video), side requests and parked conversations
(q8_0 and preset D), --agents 4 and a slot prompt prefilled in chunks between other slots' steps; the server's CPU test
suite passed. The bundled ffmpeg refused DASH manifests, concat lists and ffmetadata and decoded MP4, MKV and AVI clips; the
engine and the vision encoder loaded from a folder whose name has non-ASCII characters.
Both packages were unpacked and run with nothing else on the path (Windows: System32 only; Linux: a clean environment):
their token ids at 7 and 0 drafts, KL report and replies to a text, a thinking, an image and an image follow-up request
were identical, bit for bit, to the Linux reference, their image embeddings (both vision backends; PNG, JPEG, GIF and BMP)
to the previous vision library's, and the packaged server answered a PNG and refused a TGA with a 400.
Decode speed was measured under WSL2, not on native Windows. The benchmark tables in the README and docs/BENCHMARKS.md
at this tag come from v2026.11.03; the speed tables above are this release's.

Source and licenses

Built from 3ed5ce5 (this tag), sm_86, with llama.cpp b10246 (CPU only). Licensed under the GNU AGPL v3. The packages
also contain llama.cpp's libraries (MIT), the NVIDIA CUDA runtime and, on Windows, the Visual C++ runtime: see
THIRD_PARTY_NOTICES.md. This engine started as the megakernel of [open-jet](https://github.com/L-Forster/open-je...

qwen38-megakernel v2026.11.04-l2tune (experimental: L2 prefetch tuning)

An experimental Windows build for tuning, not a faster release. For everyday use, stay on
v2026.11.03.

The engine prefetches weights to L2 while DRAM would otherwise sit idle, in amounts sized for the 6 MB L2 of an RTX 3090.
This build reads those amounts from the environment, so a GPU with more L2 (an RTX 4090 has 72 MB) can try other values
with no compiler. On an RTX 3090 no setting beat the defaults, and nobody has measured it on another GPU yet: finding
out is what this build is for.

Why there is only an sm_86 package

An RTX 40 card does not need a separate sm_89 package. Compiled for sm_86 and for sm_89 with CUDA 13.2.2, this build gives
byte-identical machine code: all 157 code sections, 16.1 MB. Only the architecture flag in the ELF header differs. An
RTX 4090 runs sm_86 code as it is, so a native sm_89 package would run the same instructions, and this package is the one
that has been through the checks below. We compiled the sm_89 one too, but it cannot run on our RTX 3090, so it would have
shipped with less testing and no difference in the code. (Compared for this build's flags only.)

Try it

You need Python 3.10 or newer, the model, and the GPU to yourself. Unpack the zip and, from its folder:

python scripts\l2_sweep.py -m <path to Qwen3.8-27B-UD-Q4_K_XL.gguf>

That tries 7 settings against the defaults in about 25 minutes (--grid full: 18 settings, about 55 minutes;
--set MK_L2_DN=11520,MK_L2_TOP=2: your own). It needs no packages from pip. Each setting is compared with runs of the
defaults on both sides of it, a change within the defaults' own run-to-run change is marked ~, and every setting must
give the same tokens. The table it writes to l2_sweep_out\results.md is what we would like to see: please post it on
issue #1.

The server takes the same variables (set MK_L2_DN=11520, then scripts\serve.bat), and the load prints the values in use.
The settings, what each one does and the measurements are in
docs/EXPERIMENTAL.md.
These settings affect decode only, not prompt processing.

What was checked

On one RTX 3090, 2026-11-04:

• No value changes a token: greedy and sampled ids equal v2026.11.03's with every budget at its default, at 0, at its
  largest and at a middle set, on two models and with preset D. scripts/gate.sh passes against the same reference as
  v2026.11.03.
• At its defaults it costs nothing measurable against the default build: 163.5 vs 163.6 tok/s on short prompts, 122.2 vs
  122.6 tok/s after a 57k-token prompt.
• This package, unpacked, from a venv: scripts\exactness.py passes all 11 checks, and all 21 results equal the Linux
  build's.

Not checked: anything on an RTX 40 card.

Also in this package

Two fixes to scripts\exactness.py on Windows, which v2026.11.03's package lacks: it no longer dies on its last line on a
cp1252 console, and its server and agents checks now work from a venv.

Needs Windows 10 / 11 x64, an NVIDIA driver with CUDA 13.2 support and an x86-64 CPU with AVX2.

qwen38-megakernel v2026.11.03

Prebuilt packages of the engine and its server for Qwen3.8-27B on one 24 GB NVIDIA GPU: unpack, install one Python
package, point it at the model, and run. No CUDA toolkit, no compiler, no build.

Faster decode, same tokens

The served build decodes 5.5% faster on short prompts and 5.7% faster after a 40.5k-token prompt than v2026.11.01,
and reads that prompt about 3% faster, with the same output bit for bit:

RTX 3090, UD-Q4_K_XL, q8_0 KV cache, 7 drafts	v2026.11.01	v2026.11.03
greedy decode, short prompts	155.9 tok/s	164.4 tok/s	+5.5%
greedy decode after a 40.5k-token prompt	115.9 tok/s	122.5 tok/s	+5.7%
read the 40.5k-token prompt	23.3 s	22.6 s	-0.7 s

(CLI under WSL2, 512 tokens, both engines interleaved in one session, 2026-11-03; how: docs/EXPERIMENTAL.md, "How it
was measured".) Every check below gave v2026.11.01's tokens, bit for bit.

What changed since v2026.11.01

• GPU code tuned from Nsight Compute profiles of the decode cycle and the prompt read, every change keeping the
  output bit-identical: weights prefetched into L2 ahead of the phases that read them; split-K work and the attention
  projections spread evenly over all 82 SMs; a reworked delta-net core (two state columns per thread, its event loop
  pipelined); attention prologues that start their K / V copies first; the MTP draft passes' state, the grid
  barrier's count and the layer loop's state in shared memory instead of local memory; and in the prompt read, a
  layer's independent matrix products on side streams and the delta-net scan's state-independent work in a parallel
  pre-pass.
• Two experimental source builds, in active development (not in these packages; build flags, requirements and
  measured speed in docs/EXPERIMENTAL.md):
  • the deep pass (MKFLAGS=-DMK_MAXD=16): up to 15 drafts per step, verified as one 16-row pass, with the
    default build's output; +2.7 to +3.1% on short prompts, the default build's rate after a long prompt. It needs
    the q8_0 KV cache for now: the low-bit KV presets with the deep pass are on the list.
  • int8 decode attention (-DMK_ATT_I8=1, then MK_ATT_I8=1 at run time): +1.4% after a 40.5k-token prompt,
    -2.7% on short prompts; not bit-identical to the default fp16 path, and opt-in until its accuracy bar is settled.
• Source builds: ccache now caches the engine objects (NVCC="ccache nvcc"; before, its nvcc -E failed on every
  object and nothing was cached). ptxas peaks at 21.0 GiB of RAM on Linux and 20.6 GiB on Windows (v2026.11.01: 18.8 GiB
  on Windows); int8 attention would add about 5 GiB and 5 minutes, one reason it is opt-in.
• Kernel benches: make check builds again, and with it the benches leg of scripts/gate.sh.
• New settings: MK_PFX (the prompt read's earlier paths, for comparisons) and MK_PROF_DUMP / _N / _FILE
  (a launch's raw phase timestamps with MK_PROFILE), in docs/CONFIGURATION.md.

Changed behaviour: MK_K6 defaults to 6 instead of 4 (how the attention projections are dealt across the blocks;
the same output). The C API's mk_step returns an error when the caller's buffer holds fewer tokens than the step
produced, instead of returning them cut short (the server's buffer holds 16). MK_ATT_I8=1 in the environment of a
default build prints that it is ignored.

What the engine is and how it performs: README.
In short: output that speculation, cache reuse and the OS never change, 1.8 to 1.9x llama.cpp's decode speed on an
RTX 3090, conversations and agent sessions that resume where they left off, the OpenAI, Anthropic and OpenAI Responses
APIs for coding agents and chat UIs, and the model's full 262k context on 24 GB with preset D or F.

Downloads

package	for
qwen38-megakernel-v2026.11.03-windows-x64-sm86.zip	Windows 10 / 11 x64
qwen38-megakernel-v2026.11.03-linux-x64-sm86.tar.gz	Linux x86-64 and WSL2, glibc 2.38 or newer (Ubuntu 24.04, Debian 13, Fedora 39 and newer)

Checksums: SHA256SUMS.txt.

What you need

• An NVIDIA GPU with 24 GB of VRAM and compute capability 8.6 (RTX 3090 / 3090 Ti class; tested on an RTX 3090). More
  than 4 drafts, and --agents with 2 or more slots, need at least 80 SMs. RTX 40-series cards (8.9) can run this code
  but are untested; RTX 50-series cards need a
  source build.
• An NVIDIA driver that supports CUDA 13.2 (nvidia-smi shows "CUDA Version: 13.2" or higher). The CUDA runtime is
  inside the engine; nothing else from CUDA is needed.
• An x86-64 CPU with AVX2, and Python 3.10 or newer.
• The model, which is not included: Unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf (and mmproj-BF16.gguf for images).

Quick start

pip install -r requirements.txt huggingface_hub
hf download unsloth/Qwen3.8-27B-GGUF Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir ~/models
scripts/serve.sh            # Windows: scripts\serve.bat (models in %USERPROFILE%\models)

The server listens on http://127.0.0.1:8080 with 120k tokens of context. For the full 262k context pass 8080 262144
and, on Linux, set MK_KV='K*=6,V*=5' MK_KV_WIN=2048 (preset D); scripts\serve.bat picks preset F above 240k on its
own. Several agents at once: MK_AGENTS=4 scripts/serve.sh 8080 0. Settings for Claude Code, Codex, Qwen Code, Aider,
Open WebUI and six other clients are in docs/CLIENTS.md; every setting is in docs/CONFIGURATION.md.

Checked before release

The new package against v2026.11.01's, directly: greedy token ids at 0, 4 and 7 drafts and sampled ids at 7 drafts, on
UD-Q4_K_XL and Q4_K_M, were identical, bit for bit. scripts/gate.sh on the Linux build (36 checks: the kernel
self-checks, scripts/exactness.py, sampled and greedy CLI runs at 0 and 7 drafts with a presence penalty and with
chain=2, token-count invariance, 4 and 2 parallel slots, the C API checks and the KL report against llama.cpp) passed,
with outputs identical to the reference v2026.11.01's gate used. The kernel self-checks ran after the last commit, which
fixed their build and changed no engine source; the other 35 ran on the same objects just before it.
Before the merge, scripts/exactness.py (draft depths, the MTP layer, prompt chunking, the server, parallel agents)
gave 19 of 19 results identical to v2026.10.30's run, and parallel slots, presence and frequency penalties and
40k-token prompts were checked as well; each cleanup step of the GPU code was compared as PTX, function for function.
The native Windows build matched the Linux reference in token ids at 7 and 0 drafts, the KL report, server replies
(text, thinking, an image and a cached image follow-up, the API test, video), side requests and parked conversations
(q8_0 and preset D), --agents 4 and a slot prompt prefilled in chunks between other slots' steps; the server's CPU
test suite passed. The bundled ffmpeg refused DASH manifests, concat lists and ffmetadata and decoded MP4, MKV and AVI
clips; the engine and the vision encoder loaded from a folder whose name has non-ASCII characters.
Both packages were unpacked and run with nothing else on the path (Windows: System32 only; Linux: a clean environment):
their token ids at 7 and 0 drafts, KL report and replies to a text, a thinking, an image and an image follow-up request
were identical, bit for bit, to the Linux reference, their image embeddings (both vision backends; PNG, JPEG, GIF and
BMP) to the previous vision library's, and the packaged server answered a PNG and refused a TGA with a 400.
Not re-measured for this release: the benchmark tables in the README and docs/BENCHMARKS.md, which come from earlier
builds; the speed table above is this release's. Decode speed was measured under WSL2, not on native Windows.

Source and licenses

Built from 605f82a (this tag), sm_86, with llama.cpp b10246 (CPU only). Licensed under the GNU AGPL v3. The packages
also contain llama.cpp's libraries (MIT), the NVIDIA CUDA runtime and, on Windows, the Visual C++ runtime: see
THIRD_PARTY_NOTICES.md. This engine started as the megakernel of open-jet by
Louis Forster.

qwen38-megakernel v2026.11.01

Prebuilt packages of the engine and its server for Qwen3.8-27B on one 24 GB NVIDIA GPU: unpack, install one Python
package, point it at the model, and run. No CUDA toolkit, no compiler, no build.

What changed since v2026.10.31.1

A maintenance release: one build configuration instead of 18 compile-time switches, the engine's source split so that
most changes rebuild in seconds, a GPU check script for every build, memory checks that turn a silent slowdown into an
error or a warning, and documentation rewritten to describe what the engine does now. The GPU kernels compute what they
did: every check below gave the same tokens, bit for bit, as v2026.10.31.1.

• A KV cache that does not fit warns at load. With the CUDA sysmem fallback (Windows, WSL2) a cache larger than the
  free device memory used to load without a word and sit partly in system memory: an fp16 cache at 120k context decoded
  at 20 instead of ~150 tok/s. The engine now says so at load, and the load goes on. A smaller -c, a KV preset or
  --kv q8 fits.
• --agents slots that do not fit are refused at startup, with what they need and what is free, instead of
  spilling to system memory. MK_SLOT_SPILL=1 lets the driver decide as before.
• Load errors stay errors. A tensor that fails to re-encode on one of the loader's worker threads ends the load with
  that error instead of ending the process; a load that fails frees all its device memory, the 192 MiB staging buffer
  included; a parked conversation or side request whose copy fails waits for its copies before its memory is reused.
• Exact reuse with --agents: slot prefill chunks end on the same 32-token grid as solo prefills, so a slot's
  replies equal the same request run alone.
• One build configuration. The 18 compile-time switches are built in at the values the packages always used, and
  MKFLAGS is empty by default. A -D for one of them stops the build with an error that names it.
• Faster rebuilds. The GPU code (qwen38_mk.cu) and the host code (engine.cu and the files next to it) are
  compiled separately: a change to the host side rebuilds in 10 to 30 s instead of 11 minutes and 19 GB of RAM. The
  engine refuses a GPU object built with other settings or for other GPU architectures than its host files.
• scripts/gate.sh runs every GPU check of a build (kernel self-checks, exactness, CLI, token-count invariance,
  parallel slots, the C API, the KL report against llama.cpp) in about 17 minutes, against a recorded reference.
• Documentation: a new README front page; the other documents describe the engine as it is, and every measurement
  with its date is in docs/BENCHMARKS.md.

Changed behaviour: a -D for a former switch (MK_WV, MK_MAXT, MK_K5, ...) is a build error. --agents slots
that need more device memory than is free are refused at startup unless MK_SLOT_SPILL=1.

What the engine is and how it performs: README.
In short: output that speculation, cache reuse and the OS never change, ~1.9x llama.cpp's decode speed on an RTX 3090,
conversations and agent sessions that resume where they left off, the OpenAI, Anthropic and OpenAI Responses APIs for
coding agents and chat UIs, and the model's full 262k context on 24 GB with preset D or F.

Downloads

package	for
qwen38-megakernel-v2026.11.01-windows-x64-sm86.zip	Windows 10 / 11 x64
qwen38-megakernel-v2026.11.01-linux-x64-sm86.tar.gz	Linux x86-64 and WSL2, glibc 2.38 or newer (Ubuntu 24.04, Debian 13, Fedora 39 and newer)

Checksums: SHA256SUMS.txt.

What you need

• An NVIDIA GPU with 24 GB of VRAM and compute capability 8.6 (RTX 3090 / 3090 Ti class; tested on an RTX 3090). More
  than 4 drafts, and --agents with 2 or more slots, need at least 80 SMs. RTX 40-series cards (8.9) can run this code
  but are untested; RTX 50-series cards need a
  source build.
• An NVIDIA driver that supports CUDA 13.2 (nvidia-smi shows "CUDA Version: 13.2" or higher). The CUDA runtime is
  inside the engine; nothing else from CUDA is needed.
• An x86-64 CPU with AVX2, and Python 3.10 or newer.
• The model, which is not included: Unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf (and mmproj-BF16.gguf for images).

Quick start

pip install -r requirements.txt huggingface_hub
hf download unsloth/Qwen3.8-27B-GGUF Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir ~/models
scripts/serve.sh            # Windows: scripts\serve.bat (models in %USERPROFILE%\models)

The server listens on http://127.0.0.1:8080 with 120k tokens of context. For the full 262k context pass 8080 262144
and, on Linux, set MK_KV='K*=6,V*=5' MK_KV_WIN=2048 (preset D); scripts\serve.bat picks preset F above 240k on its
own. Several agents at once: MK_AGENTS=4 scripts/serve.sh 8080 0. Settings for Claude Code, Codex, Qwen Code, Aider,
Open WebUI and six other clients are in docs/CLIENTS.md; every setting is in docs/CONFIGURATION.md.

Checked before release

The new build against v2026.10.31.1, directly: greedy token ids at 0, 4 and 7 drafts and sampled ids at 7 drafts, on
UD-Q4_K_XL and Q4_K_M, were identical, bit for bit. scripts/gate.sh on the Linux build (36 checks: the kernel
self-checks, scripts/exactness.py, sampled and greedy CLI runs at 0 and 7 drafts with a presence penalty and with
chain=2, token-count invariance, 4 and 2 parallel slots, the C API checks and the KL report against llama.cpp) gave
outputs identical to the reference recorded before the source split, and the split's GPU code has the same register and
shared-memory use as before, function for function. The benchmark suite's speed step (q8_0, 120k context, this build's
GPU code) decoded within 0.2% of v2026.10.31.1's speed on the same machine, with the same tokens and the same accepted
drafts on every request.
The new checks behaved as described: a -D for a former switch stopped the build with its name, the non-default build
options still compiled, an fp16 KV cache at 120k context under WSL2 printed the load warning (and decoded at about 20
tok/s), while q8_0 at 120k and preset F at 262,144 loaded without it.
The native Windows build matched the Linux reference in token ids at 7 and 0 drafts, the KL report, server replies
(text, thinking, an image and a cached image follow-up, the API test, video), side requests and parked conversations
(q8_0 and preset D), --agents 4 and a slot prompt prefilled in chunks between other slots' steps; the server's CPU
test suite passed. The bundled ffmpeg refused DASH manifests, concat lists and ffmetadata and decoded MP4, MKV and AVI
clips; the engine and the vision encoder loaded from a folder whose name has non-ASCII characters.
Both packages were unpacked and run with nothing else on the path (Windows: System32 only; Linux: a clean environment):
their token ids at 7 and 0 drafts, KL report, image embeddings (both vision backends) and replies to a text, a
thinking, an image and an image follow-up request were identical, bit for bit, to the Linux reference, and the packaged
server answered a PNG and refused a TGA with a 400.
Not tested here: the KV-cache warning with a native Windows driver (tested under WSL2, which has the same fallback).

Source and licenses

Built from 1560752 (this tag), sm_86, with llama.cpp b10246 (CPU only). Licensed under the GNU AGPL v3. The packages
also contain llama.cpp's libraries (MIT), the NVIDIA CUDA runtime and, on Windows, the Visual C++ runtime: see
THIRD_PARTY_NOTICES.md. This engine started as the megakernel of open-jet by
Louis Forster.

qwen38-megakernel v2026.10.31.1

Prebuilt packages of the engine and its server for Qwen3.8-27B on one 24 GB NVIDIA GPU: unpack, install one Python
package, point it at the model, and run. No CUDA toolkit, no compiler, no build.

What changed since v2026.10.31

A second robustness release, prompted by another outside review: the server's exposure (video input, /props, request
framing), wrong output with --agents on GPUs with 50 to 79 SMs, and smaller fixes to the C API, Windows paths and the
build. The GPU kernels did not change, and every check below gave the same tokens, bit for bit, as v2026.10.31.

• Video input reads media containers only. A "video" that was a DASH manifest could make the server's ffmpeg read a
  local video file into the prompt, or send a GET request to an address of the sender's choice. ffmpeg now reads only
  MP4 / MOV (3GP, M4V), Matroska / WebM, AVI, MPEG-TS, MPEG-PS, Ogg, FLV and GIF; DASH manifests, HLS playlists, concat
  lists and other containers get a 400. A server on the default address (127.0.0.1) or with an API key was not open to
  this from other machines, and web pages of other sites were refused already.
• /props no longer shows the API key (MK_API_KEY shows as (set)).
• A request body the server does not read closes the connection. The body of a GET or OPTIONS request used to stay
  on the connection and be read as the next request (behind a reverse proxy: a request the proxy never saw).
• --agents with 2 or more slots needs 80 SMs. On GPUs with 50 to 79 SMs (A10, L4, RTX A5000), v2026.10.31 started
  with up to 4 drafts, but its batched passes of 8 rows ran on fewer blocks than they need: wrong tokens, without an
  error. The engine now refuses 2 or more slots there (1 slot runs). Making the batched passes work on those GPUs is
  open, and a pull request is welcome. GPUs with 80 SMs or more, the RTX 3090 among them, were never affected.
• Windows: folders with non-ASCII names. A model, draft vocabulary or mmproj in a folder whose name has non-ASCII
  characters (a user folder such as C:\Users\José\models) did not open; it does now.
• Smaller fixes. {"messages": [1]}, a repetition_penalty that is not a number and max_tokens: 0 get a 400 (a
  500, a dropped connection or a run to the end of the context before); an HTTP/1.0 client gets a stream it can read;
  the C API's tokenizer calls return an error instead of letting an exception end the process; a GPU the build has no
  machine code for is refused at start with what to rebuild; the engine uses the CUDA device its caller selected
  instead of device 0; two small leaks on failure paths; the packages are named after the GPU code they hold; make
  rebuilds the engine when MKFLAGS or ARCH change; scripts/serve.sh picks the mmproj in its documented order; the
  reference tools refuse bad flags. The README now says that scripts\serve.bat uses preset F above 240k context,
  whose output differs slightly from the q8_0 cache's (runs with F give the same tokens as each other).

Changed behaviour: max_tokens: 0 is a 400 (it meant "up to the end of the context"; OpenAI's and Anthropic's
minimum is 1). Video in a container outside the list above is a 400, WMV / ASF among them. --agents 2 or more stops at
start on a GPU with fewer than 80 SMs.

What the engine is and how it performs: README.
In short: output that speculation, cache reuse and the OS never change, ~1.9x llama.cpp's decode speed on an RTX 3090,
conversations and agent sessions that resume where they left off, the OpenAI, Anthropic and OpenAI Responses APIs for
coding agents and chat UIs, and the model's full 262k context on 24 GB with preset D or F.

Downloads

package	for
qwen38-megakernel-v2026.10.31.1-windows-x64-sm86.zip	Windows 10 / 11 x64
qwen38-megakernel-v2026.10.31.1-linux-x64-sm86.tar.gz	Linux x86-64 and WSL2, glibc 2.38 or newer (Ubuntu 24.04, Debian 13, Fedora 39 and newer)

Checksums: SHA256SUMS.txt.

What you need

• An NVIDIA GPU with 24 GB of VRAM and compute capability 8.6 (RTX 3090 / 3090 Ti class; tested on an RTX 3090). More
  than 4 drafts, and --agents with 2 or more slots, need at least 80 SMs. RTX 40-series cards (8.9) can run this code
  but are untested; RTX 50-series cards need a
  source build.
• An NVIDIA driver that supports CUDA 13.2 (nvidia-smi shows "CUDA Version: 13.2" or higher). The CUDA runtime is
  inside the engine; nothing else from CUDA is needed.
• An x86-64 CPU with AVX2, and Python 3.10 or newer.
• The model, which is not included: Unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf (and mmproj-BF16.gguf for images).

Quick start

pip install -r requirements.txt huggingface_hub
hf download unsloth/Qwen3.8-27B-GGUF Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir ~/models
scripts/serve.sh            # Windows: scripts\serve.bat (models in %USERPROFILE%\models)

The server listens on http://127.0.0.1:8080 with 120k tokens of context. For the full 262k context pass 8080 262144
and, on Linux, set MK_KV='K*=6,V*=5' MK_KV_WIN=2048 (preset D); scripts\serve.bat picks preset F above 240k on its
own. Several agents at once: MK_AGENTS=4 scripts/serve.sh 8080 0. Settings for Claude Code, Codex, Qwen Code, Aider,
Open WebUI and six other clients are in docs/CLIENTS.md; every setting is in docs/CONFIGURATION.md.

Checked before release

The new engine against v2026.10.31's (Linux, on the release build itself): sampled token ids at 0 and 7 drafts, with a
presence penalty and with chain=2 (UD-Q4_K_XL), greedy ids at 7 drafts on Q4_K_M, the KL report, the T-invariance
runs and the parallel slots (4 slots on UD-Q4_K_XL and Q4_K_M, 2 slots on UD-Q4_K_XL: each reply matched the same
request run alone, and the sampled replies matched v2026.10.31's) were identical, bit for bit; so were the two Linux
engines' Q4_K_M ids at 0, 4 and 7 drafts and sampled at 7. scripts/exactness.py passed its 10 checks, and its 19
results were identical to v2026.10.31's. Through the C API, mk_piece of ids outside the vocabulary returned an error
on Linux and on Windows, and the process carried on.
On Windows, the bundled ffmpeg (7.1) refused DASH manifests (with a local-file and an HTTP base URL: no request reached
the listener), concat lists and ffmetadata, and decoded MP4, MKV and AVI clips; the engine, its draft vocabulary and
the vision encoder loaded from a folder whose name has non-ASCII characters. The native Windows build matched the Linux
reference in token ids, the KL report, server replies (text, thinking, an image and a cached image follow-up, the API
test, video), side requests and parked conversations (q8_0 and preset D), and --agents 4; the server's CPU test suite
passed on both systems. Both packages were unpacked and run with nothing else on the path (Windows: System32 only;
Linux: a clean environment); their token ids at 7 and 0 drafts, KL report, image embeddings (PNG, JPEG, GIF and BMP,
both vision backends) and replies to a text, a thinking, an image and an image follow-up request were identical, bit
for bit, to the Linux reference, and the packaged server answered a PNG and refused a TGA with a 400.
Not tested here: the refusal of 2 or more --agents slots on 50 to 79 SMs (no such GPU at hand) and the refusal of a
GPU the build has no machine code for (only an RTX 3090, which passes).

Source and licenses

Built from f8fb324 (this tag) with the served configuration (-DMK_WV=1 -DMK_MAXT=8 -DMK_WV_Q6F=1 -DMK_K5=1, sm_86)
and llama.cpp b10246 (CPU only). Licensed under the GNU AGPL v3. The packages also contain llama.cpp's libraries (MIT),
the NVIDIA CUDA runtime and, on Windows, the Visual C++ runtime: see THIRD_PARTY_NOTICES.md. This engine started as
the megakernel of open-jet by Louis Forster.

qwen38-megakernel v2026.10.31

Prebuilt packages of the engine and its server for Qwen3.8-27B on one 24 GB NVIDIA GPU: unpack, install one Python
package, point it at the model, and run. No CUDA toolkit, no compiler, no build.

What changed since v2026.10.30

A robustness release, prompted by an outside review: the engine's failure paths, the C API's boundary and the server's
exposure. No GPU code changed (the engine's changes are host code: its failure paths and argument checks), and every
check below gave the same tokens, bit for bit, as v2026.10.30.

• A failed request no longer leaves its cache to the next one. When a request failed inside the engine, v2026.10.30
  could let the next request of the same conversation resume from the failed request's cache: with a NaN injected in a
  test build, that follow-up reused 480 tokens and its reply differed from a fresh server's. The next request now
  starts from scratch and its reply matches a fresh server's. With --agents, the slots of a call that failed (a CUDA
  error or the NaN / inf check) are refused until their next prompt, which starts from scratch.
• The server. An opt-in API key (--api-key KEY or MK_API_KEY): every request but /health then needs
  Authorization: Bearer KEY or x-api-key: KEY, others get a 401. A connection that stalls for MK_TIMEOUT_S
  seconds (default 600) is closed. A JSON body nested too deep gets a 400 instead of an internal error.
• The C API's boundary. Token ids outside the vocabulary are refused before anything changes. A context longer than
  the model's 262,144 is refused at once by the engine and by the parallel slots (an absurd one, such as 100,000,000,
  used to load the weights or build a 26 GB table before failing). An engine whose start fails frees its memory
  (v2026.10.30 could leave 16,571 MiB of VRAM behind; now about 250 MiB, the CUDA context), and a failed slots_open
  undoes itself so the next one succeeds.
• scripts/exactness.py. The exact-output claims as a check any build can run: the same tokens at every draft depth
  and without the MTP layer, the same state and tokens at three prefill chunk sizes, and a server's reused
  conversations against fresh ones; --compare checks the results against another build's, bit for bit.

Changed behaviour: -c above 262,144 (the model's context length) now stops the engine at start with an error. The
engine has no RoPE scaling, so positions past the model's context were never useful.

What the engine is and how it performs: README.
In short: output that speculation, cache reuse and the OS never change, ~1.9x llama.cpp's decode speed on an RTX 3090,
conversations and agent sessions that resume where they left off, the OpenAI, Anthropic and OpenAI Responses APIs for
coding agents and chat UIs, and the model's full 262k context on 24 GB with preset D or F.

Downloads

package	for
qwen38-megakernel-v2026.10.31-windows-x64-sm86.zip	Windows 10 / 11 x64
qwen38-megakernel-v2026.10.31-linux-x64-sm86.tar.gz	Linux x86-64 and WSL2, glibc 2.38 or newer (Ubuntu 24.04, Debian 13, Fedora 39 and newer)

Checksums: SHA256SUMS.txt.

What you need

• An NVIDIA GPU with 24 GB of VRAM and compute capability 8.6 (RTX 3090 / 3090 Ti class; tested on an RTX 3090). More
  than 4 drafts needs at least 80 SMs. RTX 40-series cards (8.9) can run this code but are untested; RTX 50-series cards
  need a source build.
• An NVIDIA driver that supports CUDA 13.2 (nvidia-smi shows "CUDA Version: 13.2" or higher). The CUDA runtime is
  inside the engine; nothing else from CUDA is needed.
• An x86-64 CPU with AVX2, and Python 3.10 or newer.
• The model, which is not included: Unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf (and mmproj-BF16.gguf for images).

Quick start

pip install -r requirements.txt huggingface_hub
hf download unsloth/Qwen3.8-27B-GGUF Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir ~/models
scripts/serve.sh            # Windows: scripts\serve.bat (models in %USERPROFILE%\models)

The server listens on http://127.0.0.1:8080 with 120k tokens of context. For the full 262k context pass 8080 262144
and, on Linux, set MK_KV='K*=6,V*=5' MK_KV_WIN=2048 (preset D); scripts\serve.bat picks preset F above 240k on its
own. Several agents at once: MK_AGENTS=4 scripts/serve.sh 8080 0. Settings for Claude Code, Codex, Qwen Code, Aider,
Open WebUI and six other clients are in docs/CLIENTS.md; every setting is in docs/CONFIGURATION.md.

Checked before release

The new engine against v2026.10.30's (Linux): sampled token ids at 0 and 7 drafts, with a presence penalty and with
chain=2 (UD-Q4_K_XL), greedy ids at 7 drafts on Q4_K_M, the KL report, the T-invariance runs and the parallel slots
(4 slots on UD-Q4_K_XL and Q4_K_M, 2 slots on UD-Q4_K_XL: each reply matched the same request run alone, and the sampled
replies matched v2026.10.30's) were identical, bit for bit; so were the two Linux packages' Q4_K_M ids at 0, 4 and 7
drafts and sampled at 7. scripts/exactness.py passed its 10 checks, and its 19 results were identical to
v2026.10.30's. Through the C API, a context of 262,145 was refused in 0.4 s by the engine and by slots_open, a failed
slots_open was followed by one that worked, and penalties on the engine's own sequence worked beside parallel slots.
The native Windows build matched the Linux reference in token ids, the KL report, server replies (text, thinking, an
image and a cached image follow-up, the API test, video), side requests and parked conversations (q8_0 and preset D),
and --agents 4; the server's CPU test suite passed. Both packages were unpacked and run with nothing else on the path
(Windows: System32 only; Linux: a clean environment); their token ids at 7 and 0 drafts, KL report, image embeddings
(PNG, JPEG, GIF and BMP, both vision backends) and replies to a text, a thinking, an image and an image follow-up
request were identical, bit for bit, to the Linux reference, and the packaged server answered a PNG and refused a TGA
with a 400.

Source and licenses

Built from bc26121 (this tag) with the served configuration (-DMK_WV=1 -DMK_MAXT=8 -DMK_WV_Q6F=1 -DMK_K5=1, sm_86)
and llama.cpp b10246 (CPU only). Licensed under the GNU AGPL v3. The packages also contain llama.cpp's libraries (MIT),
the NVIDIA CUDA runtime and, on Windows, the Visual C++ runtime: see THIRD_PARTY_NOTICES.md. This engine started as
the megakernel of open-jet by Louis Forster.

qwen38-megakernel v2026.10.30

Prebuilt packages of the engine and its server for Qwen3.8-27B on one 24 GB NVIDIA GPU: unpack, install one Python
package, point it at the model, and run. No CUDA toolkit, no compiler, no build.

What changed since v2026.10.29

• Faster decode, same output. Work inside the decode kernel (its stack frame and local memory; no setting changed).
  With UD-Q4_K_XL on an RTX 3090, one conversation decodes 0.9% faster at a 38k context and 1.2% faster at 101.6k
  (short prompts: unchanged within noise), and four agents at once (--agents 4) 7.4% faster in total. The output is
  unchanged: every check below gave the same replies, bit for bit, as v2026.10.29.
• About 150 MiB less VRAM. The decode kernel's stack frame shrank from 2,016 to 752 bytes per thread. The GPU
  reserves that much for every thread that can be resident, so the engine now holds ~150 MiB less: room for ~4k more
  tokens of q8_0 KV cache.

What the engine is and how it performs: README.
In short: output that speculation, cache reuse and the OS never change, ~1.9x llama.cpp's decode speed on an RTX 3090,
conversations and agent sessions that resume where they left off, the OpenAI, Anthropic and OpenAI Responses APIs for
coding agents and chat UIs, and the model's full 262k context on 24 GB with preset D or F.

Downloads

package	for
qwen38-megakernel-v2026.10.30-windows-x64-sm86.zip	Windows 10 / 11 x64
qwen38-megakernel-v2026.10.30-linux-x64-sm86.tar.gz	Linux x86-64 and WSL2, glibc 2.38 or newer (Ubuntu 24.04, Debian 13, Fedora 39 and newer)

Checksums: SHA256SUMS.txt.

What you need

• An NVIDIA GPU with 24 GB of VRAM and compute capability 8.6 (RTX 3090 / 3090 Ti class; tested on an RTX 3090). More
  than 4 drafts needs at least 80 SMs. RTX 40-series cards (8.9) can run this code but are untested; RTX 50-series cards
  need a source build.
• An NVIDIA driver that supports CUDA 13.2 (nvidia-smi shows "CUDA Version: 13.2" or higher). The CUDA runtime is
  inside the engine; nothing else from CUDA is needed.
• An x86-64 CPU with AVX2, and Python 3.10 or newer.
• The model, which is not included: Unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf (and mmproj-BF16.gguf for images).

Quick start

pip install -r requirements.txt huggingface_hub
hf download unsloth/Qwen3.8-27B-GGUF Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir ~/models
scripts/serve.sh            # Windows: scripts\serve.bat (models in %USERPROFILE%\models)

The server listens on http://127.0.0.1:8080 with 120k tokens of context. For the full 262k context pass 8080 262144
and, on Linux, set MK_KV='K*=6,V*=5' MK_KV_WIN=2048 (preset D); scripts\serve.bat picks preset F above 240k on its
own. Several agents at once: MK_AGENTS=4 scripts/serve.sh 8080 0. Settings for Claude Code, Codex, Qwen Code, Aider,
Open WebUI and six other clients are in docs/CLIENTS.md; every setting is in docs/CONFIGURATION.md.

Checked before release

The new engine against v2026.10.29's (Linux): token ids at 0, 4 and 7 drafts (UD-Q4_K_XL on four prompts, Q4_K_M on
one), sampled replies on both files, replies with a presence penalty, the KL report and the sampled replies of four
parallel slots were identical, bit for bit; the parallel-slot replies (2 and 4 slots, UD-Q4_K_XL and Q4_K_M) matched
each request run alone. The native Windows build matched the Linux reference in token ids, the KL report, server
replies (text, thinking, an image and a cached image follow-up, the API test, video), side requests and parked
conversations (q8_0 and preset D), and --agents 4; the server's CPU test suite passed. Both packages were unpacked
and run with nothing else on the path (Windows: System32 only; Linux: a clean environment); their token ids at 7 and 0
drafts, KL report, image embeddings (PNG, JPEG, GIF and BMP, both vision backends) and replies to a text, a thinking,
an image and an image follow-up request were identical, bit for bit, to the Linux reference, and the packaged server
answered a PNG and refused a TGA with a 400.

Source and licenses

Built from 6f3b257 (this tag) with the served configuration (-DMK_WV=1 -DMK_MAXT=8 -DMK_WV_Q6F=1 -DMK_K5=1, sm_86)
and llama.cpp b10246 (CPU only). Licensed under the GNU AGPL v3. The packages also contain llama.cpp's libraries (MIT),
the NVIDIA CUDA runtime and, on Windows, the Visual C++ runtime: see THIRD_PARTY_NOTICES.md. This engine started as
the megakernel of open-jet by Louis Forster.

qwen38-megakernel v2026.10.29

Prebuilt packages of the engine and its server for Qwen3.8-27B on one 24 GB NVIDIA GPU: unpack, install one Python
package, point it at the model, and run. No CUDA toolkit, no compiler, no build.

What changed since v2026.10.26

• Several agents at once: --agents N (N = 1-4; --parallel N / -np N is the same with 32,768 positions per
  slot). Each request runs in a parallel slot of the engine with its own KV cache and recurrent state, and every slot
  that is decoding runs in the same engine cycle. A greedy reply is the one the request gets alone on the server, bit
  for bit, whatever runs beside it. With Q4_K_M (2026-10-28): 353 tok/s in total for 4 agents on short prompts and 296
  with a ~23k-token context each; one agent alone 190 and 178 tok/s. With --agents, images, video and the presence /
  frequency penalties get a 400, and side requests, parking and pinned checkpoints are off. Run it with
  MK_AGENTS=4 scripts/serve.sh 8080 0 (context 0 = the most that fits per slot); details in
  docs/SERVER.md.
• A smaller engine build. The served build no longer compiles code that no served setting reaches, and lm_head's
  variants share one function. ptxas peaked at 21.2 GB in a 13-minute build on Linux / WSL2 (37.7 GB and 28.5 minutes
  before) and at 20.2 GB in a 14-minute build natively on Windows (27-30 GB and up to 30 minutes before). The output is
  unchanged, bit for bit, and so is decode speed; files whose output.weight is Q8_0 (some fine-tunes) decode ~0.5%
  faster.
• Removed settings (measured slower or no gain; the engine refuses them at startup with a message that names them):
  MK_MTP_Q4=0 / ab and the policy key mtpq in builds with more than 4 drafts (their MTP layer is always
  re-quantized to Q4_K, IQ4_NL included; the lean build keeps both), MK_K6 bit 1, and the policy key blk=1.
• One conversation alone decodes 0.6% (UD-Q4_K_XL) to 1.3% (Q4_K_M) slower than v2026.10.26 (2026-10-28, same
  output): the price of the slot machinery behind --agents.
• Fixes: the CLI's MK_PROFILE tables print again; a prefill kernel's shared-memory buffer that is read as float4 is
  now aligned explicitly (its alignment held only by where the other variables happened to land); make rebuilds the
  engine after an edit to any header it includes.

What the engine is and how it performs: README.
In short: output that speculation, cache reuse and the OS never change, ~1.9x llama.cpp's decode speed on an RTX 3090,
conversations and agent sessions that resume where they left off, the OpenAI, Anthropic and OpenAI Responses APIs for
coding agents and chat UIs, and the model's full 262k context on 24 GB with preset D or F.

Downloads

package	for
qwen38-megakernel-v2026.10.29-windows-x64-sm86.zip	Windows 10 / 11 x64
qwen38-megakernel-v2026.10.29-linux-x64-sm86.tar.gz	Linux x86-64 and WSL2, glibc 2.38 or newer (Ubuntu 24.04, Debian 13, Fedora 39 and newer)

Checksums: SHA256SUMS.txt.

What you need

• An NVIDIA GPU with 24 GB of VRAM and compute capability 8.6 (RTX 3090 / 3090 Ti class; tested on an RTX 3090). More
  than 4 drafts needs at least 80 SMs. RTX 40-series cards (8.9) can run this code but are untested; RTX 50-series cards
  need a source build.
• An NVIDIA driver that supports CUDA 13.2 (nvidia-smi shows "CUDA Version: 13.2" or higher). The CUDA runtime is
  inside the engine; nothing else from CUDA is needed.
• An x86-64 CPU with AVX2, and Python 3.10 or newer.
• The model, which is not included: Unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf (and mmproj-BF16.gguf for images).

Quick start

pip install -r requirements.txt huggingface_hub
hf download unsloth/Qwen3.8-27B-GGUF Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir ~/models
scripts/serve.sh            # Windows: scripts\serve.bat (models in %USERPROFILE%\models)

The server listens on http://127.0.0.1:8080 with 120k tokens of context. For the full 262k context pass 8080 262144
and, on Linux, set MK_KV='K*=6,V*=5' MK_KV_WIN=2048 (preset D); scripts\serve.bat picks preset F above 240k on its
own. Settings for Claude Code, Codex, Qwen Code, Aider, Open WebUI and six other clients are in docs/CLIENTS.md; every
setting is in docs/CONFIGURATION.md.

Checked before release

The new engine against the engine just before the build trim (Linux): token ids at 0, 4 and 7 drafts on four prompts,
30 generation jobs on three model files (greedy, sampled, presence / frequency penalties; two of the files have a Q8_0
output.weight), the KL report on two files and the parallel-slot replies were identical, bit for bit; the removed
settings were refused by name, and seven more model files gave the same token ids and draft acceptance. The native
Windows build matched the Linux reference in token ids, the KL report, server replies, side requests and parked
conversations (q8_0 and preset D), and --agents 4. The server's CPU test suite (226 tests). Both packages were unpacked
and run with nothing else on the path (Windows: System32 only; Linux: a clean environment); their token ids at 7 and 0
drafts, KL report, image embeddings (PNG, JPEG, GIF and BMP, both vision backends) and replies to a text, a thinking, an
image and an image follow-up request were identical, bit for bit, to the Linux reference, and the packaged server
answered a PNG and refused a TGA with a 400.

Source and licenses

Built from b550714 (this tag) with the served configuration (-DMK_WV=1 -DMK_MAXT=8 -DMK_WV_Q6F=1 -DMK_K5=1, sm_86)
and llama.cpp b10246 (CPU only). Licensed under the GNU AGPL v3. The packages also contain llama.cpp's libraries (MIT),
the NVIDIA CUDA runtime and, on Windows, the Visual C++ runtime: see THIRD_PARTY_NOTICES.md. This engine started as
the megakernel of open-jet by Louis Forster.

qwen38-megakernel v2026.10.26

Prebuilt packages of the engine and its server for Qwen3.8-27B on one 24 GB NVIDIA GPU: unpack, install one Python
package, point it at the model, and run. No CUDA toolkit, no compiler, no 20-minute build.

What changed since v2026.10.25

A security release for image input. The engine, text output and image embeddings are unchanged.

• Images are decoded as PNG, JPEG, GIF (its first frame) or BMP. Other formats (TGA, PSD, HDR, PIC, PNM) now get a
  400. The image decoder in the packages (stb_image 2.30, the copy llama.cpp ships) has unfixed memory bugs in those
  loaders that a single image in a request reaches: a crafted PIC file could crash the server (GHSL-2023-149), and a
  truncated TGA or HDR file could put uninitialized memory into the pixels the model sees (GHSL-2023-147). Anyone who
  could send the server a request could trigger them.
• The libmtmd vision backend only loads Qwen3.x's projector. That backend runs with --vision-backend mtmd, or with
  auto when the CPU encoder turns an mmproj down (for example on a CPU without AVX2). llama.cpp b10246, which the
  packages bundle, writes past a stack array in its MiniCPM-V encoder when an mmproj declares a large image size
  (llama.cpp #27166, fixed upstream in b11110), and a malicious
  mmproj could reach it through this backend. The backend now also sizes its output by the projector's actual width,
  decodes images with the restricted decoder above, and no longer hands an image it cannot decode to an ffmpeg on the
  PATH.
• The CPU vision encoder refuses two more malformed mmprojs (an empty position embedding, a head count that does not
  divide the width).
• The docs include the KL divergence measurements at 100k and 160k context published after v2026.10.25.

What the engine is and how it performs: README.
In short: output that speculation, cache reuse and the OS never change, ~1.9x llama.cpp's decode speed on an RTX 3090,
conversations and agent sessions that resume where they left off, the OpenAI, Anthropic and OpenAI Responses APIs for
coding agents and chat UIs, and the model's full 262k context on 24 GB with preset D or F.

Downloads

package	for
qwen38-megakernel-v2026.10.26-windows-x64-sm86.zip	Windows 10 / 11 x64
qwen38-megakernel-v2026.10.26-linux-x64-sm86.tar.gz	Linux x86-64 and WSL2, glibc 2.38 or newer (Ubuntu 24.04, Debian 13, Fedora 39 and newer)

Checksums: SHA256SUMS.txt.

What you need

• An NVIDIA GPU with 24 GB of VRAM and compute capability 8.6 (RTX 3090 / 3090 Ti class; tested on an RTX 3090). More
  than 4 drafts needs at least 80 SMs. RTX 40-series cards (8.9) can run this code but are untested; RTX 50-series cards
  need a source build.
• An NVIDIA driver that supports CUDA 13.2 (nvidia-smi shows "CUDA Version: 13.2" or higher). The CUDA runtime is
  inside the engine; nothing else from CUDA is needed.
• An x86-64 CPU with AVX2, and Python 3.10 or newer.
• The model, which is not included: Unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf (and mmproj-BF16.gguf for images).

Quick start

pip install -r requirements.txt huggingface_hub
hf download unsloth/Qwen3.8-27B-GGUF Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-BF16.gguf --local-dir ~/models
scripts/serve.sh            # Windows: scripts\serve.bat (models in %USERPROFILE%\models)

The server listens on http://127.0.0.1:8080 with 120k tokens of context. For the full 262k context pass 8080 262144
and, on Linux, set MK_KV='K*=6,V*=5' MK_KV_WIN=2048 (preset D); scripts\serve.bat picks preset F above 240k on its
own. Settings for Claude Code, Codex, Qwen Code, Aider, Open WebUI and six other clients are in docs/CLIENTS.md; every
setting is in docs/CONFIGURATION.md.

Checked before release

Image embeddings were byte-identical to v2026.10.25's on both vision backends for PNG, JPEG, GIF and BMP images (Linux:
nine images; Windows: four), and both backends refused a TGA. The server's CPU test suite (211 tests). Both packages were
unpacked and run with nothing else on the path (Windows: System32 only; Linux: a clean environment); their token ids at
7 and 0 drafts, KL report, and replies to a text, a thinking, an image and an image follow-up request were identical, bit
for bit, to the Linux reference, and the packaged server answered a PNG and refused a TGA with a 400.

Source and licenses

Built from d151b12 (this tag) with the served configuration (-DMK_WV=1 -DMK_MAXT=8 -DMK_WV_Q6F=1 -DMK_K5=1, sm_86)
and llama.cpp b10246 (CPU only). The engine's sources are unchanged since v2026.10.25: the Windows engine is relinked
from v2026.10.25's compiled object, and the Linux package carries v2026.10.25's engine binaries (BUILD_INFO.txt in each
package says which). Licensed under the GNU AGPL v3. The packages also contain llama.cpp's libraries (MIT), the NVIDIA
CUDA runtime and, on Windows, the Visual C++ runtime: see THIRD_PARTY_NOTICES.md. This engine started as the
megakernel of open-jet by Louis Forster.