What happened
Kapitsa released version 0.2.22 on October 27. The GitHub release describes a runtime update, rather than a new model release: its changes concern loading and executing particular model-weight formats, plus benchmark results for specific Flash-Next configurations on Apple hardware. The release tag was created by GitHub Actions and lists 32 commits to main since the preceding release.
The headline addition is support around EXL3 routed-expert kernels. The release says Flash-Next can run Sushi's EXL3 packs, naming a flash-next:64gb option based on Sushi's 2-bits-per-weight pack. That pack contains 36.7 GB of weights. Kapitsa reports 78.6 tokens per second with MTP on an M5 Max. Separately, the notes say EXL3 routed-expert kernels received GPU checks. Another kernel entry is described as “not wired to a model yet,” so the reported Flash-Next path and the more general kernel work should not be treated as identical claims.
The update also adds loading for 8-bit and mixed 4/8-bit expert packs on generic expert kernels. Specifically, it supports Q8_0 and Q6_K GGUF import through MLX. The release says same-weight 8-bit packs are within “near-tie drift” of the 4-bit path. It does not provide a detailed methodology, workloads, or a full comparison table for that statement, but it identifies the import formats and the runtime path involved.
A separate Flash-Next Q2_0 change allows an n-gram table to be read in place from a GGUF file using --table gguf, ple.gguf, and IQ4_NL. According to the release, when a local GGUF is available, the 4-bit pack supplies 5.9 GB instead of 37.9 GB. The release explicitly marks that local-table arrangement as not verified on a GPU. Kapitsa also records a Q2_0 Flash-Next benchmark resident on a 64 GB M2 Max: 43–46 tokens per second for decode and 414–434 tokens per second for 4K prefill. Finally, it changes how a folder's precision is counted, using weight bytes, and notes that the Q2_0 Flash-Next pack is not a 4-bit pack.
What the archive adds
This is a new release in a known story. Kapitsa v0.2.15, an open-source Apple Silicon inference engine for Qwen and Nemotron, ships stability fixes and faster MoE prefill covered an earlier version focused on stability and MoE prefill. Version 0.2.22 adds format, packaging, and device-specific execution claims, including EXL3 execution and mixed-precision expert-pack loading.
Trend signal
The release supports Harness architecture outlives model choice. Kapitsa's changes are not new model weights; they are runtime capabilities for loading, checking, packaging, and measuring different representations of weights. The useful boundary is therefore the harness that connects model packs to hardware, memory limits, and execution paths, rather than the model name alone.
Why it matters
Local-model selection is often framed as a binary question: does a checkpoint fit in available memory? This release highlights the more useful question: which complete combination of pack, precision, runtime, machine, context stage, and auxiliary files is workable for the job. A 36.7 GB EXL3 pack, an M5 Max result, and a Q2_0 result on a 64 GB M2 Max are specific configurations, not interchangeable claims about Flash-Next performance.
For builders, Q8_0 and Q6_K import support may widen the set of expert packs that can be evaluated without switching runtimes. Reading the n-gram table from a local GGUF may also change distribution and storage planning where the stated reduction from 37.9 GB to 5.9 GB applies. This is particularly relevant when moving a local setup between machines or maintaining multiple candidate packs. The update does not establish model quality, end-to-end latency under a production workload, or reliability in deployment. It makes those trade-offs easier to test in a defined runtime.
The release also separates two measurements that teams should keep distinct: decode throughput and prefill throughput. The cited M2 Max figures give both a decode range and a 4K-prefill range, but neither number alone describes interactive application experience. Prompt length, generated length, concurrency, and the application’s quality threshold determine whether a given pack is usable.
Limits and uncertainty
The speed figures are release-note claims from Kapitsa maintainers, not an independent benchmark. The source does not specify the prompt mix, generated length, MTP configuration beyond naming it, concurrency, thermal conditions, full software environment, or quality effects of the named quantizations. It does not establish that the reported M5 Max and M2 Max results transfer to other Apple Silicon systems, contexts, or workloads.
The local-GGUF table path is explicitly not verified on a GPU. Nor does the release provide general comparisons against other local inference runtimes, a price analysis, or evidence that a particular precision produces acceptable output for a particular task. “Near-tie drift” is a release-note characterization, not a substitute for an application-level evaluation.
Skill to build now
Create a small local-inference evaluation sheet before selecting a pack. Record the exact checkpoint and pack name, weight bytes, auxiliary-file bytes, runtime version, device memory, decode speed, prefill speed, context length, and a task-quality sample. Run the same prompt set through one lower-precision and one higher-precision expert pack where Kapitsa supports both.
Keep the results separate by machine and by workload stage. Compare initial prompt processing, token generation, storage requirements, and output quality rather than collapsing them into one throughput number. This turns a release-note benchmark into a decision about usable latency, distribution size, and output quality for a specific application.
Reader takeaway
Kapitsa 0.2.22 broadens the runtime layer around local expert models with EXL3 Flash-Next packs, 8-bit and mixed expert-pack imports, and a smaller local-table distribution path. Its benchmarks are useful starting points for a matching configuration, but teams should validate the full pack-runtime-hardware combination on their own tasks.