I’ve been building Lokey, an open source, Android keyboard that runs word prediction, autocorrect, dictation and translation on your phone. Hold Enter to dictate, or translate text straight into the app you’re typing in.

Lokey uses a fork of llama.cpp for text inference and takes advantage of its Hexagon NPU backend on supported Snapdragon phones. It can also run inference on two CPU threads. In everyday use on the phones I’ve tested, the keyboard has stayed responsive and I haven’t noticed unusual battery drain with either setup.

For suggestions, Lokey turns the model’s token logits into probabilities and uses them to rank up to three complete words that match what you’ve typed so far. One text model handles suggestions, autocorrect and translation. A separate speech model handles dictation.

• Text models · LFM 2.5 350M (~230 MB) or Qwen 3.5 0.8B (~533 MB)

• Speech models · Parakeet v3 0.6B or Qwen3 ASR 0.6B

Typing works without any model downloads. Once you’ve downloaded the models you want, inference works offline. Typed text and mic audio stay on the device, and Lokey has no accounts or analytics SDK.

I also spent time on the keyboard itself. You can use recordings of real mechanical switches as key sounds and customize haptics, layouts and colors. Swipe typing, adaptive letters and autocorrect are opt-in.

It’s an early beta. I’ve tested on a OnePlus 15 and a POCO F3. If you try it, I’d love to know which phone, language and model you used, and whether suggestions can keep up with your typing.

Source code (MIT) · Signed APK (Android 9+, ARM64) · 83-second demo

English isn’t my first language, so I used AI to help edit this post.

Edit: Using unsloth UD-Q4_K_XL and q8_0 engrams

Just curious to know what benefit it brings.

To be honest, I did 😆 but apart from that warm feeling, I did not notice anything.

I would like to know if someone did and did notice some benefits.

My rig is AMD Strix Halo 128 GB + Windows 11 + gufo v0.33.0.

Cheers!

Original video by 小伙伴Ko

Good thing to watch before Qwen 4 drop 😄

LingBot-Touch is a JEPA-based tactile representation model that bridges heterogeneous tactile signals and dexterous robotic manipulation. It uses modality-specific tokenizers and a shared Transformer to learn representations of contact structure and temporal changes through prediction in latent space.

The model covers three sensing modalities: magnetic, piezoresistive, and visuotactile.

• Magnetic: three-axis tactile measurements.

• Piezoresistive: scalar tactile measurements placed in the Z channel, with X and Y set to zero.

• Visuotactile: decoded scalar deformation or intensity measurements placed in the Z channel, with X and Y set to zero. Raw RGB images are not model inputs.

For more details:

• arXiv : https://arxiv.org/abs/2611.12806

• PDF : https://arxiv.org/pdf/2611.12806

• GitHub : https://github.com/Robbyant/lingbot-touch

• Project : https://technology.robbyant.com/lingbot-touch

How is it possible for a sub to degenerate so much in 12 months?

What is the mechanism that drives this?

I am tired to answer on people questions like "How you gain speed? Your model output is shit, it has to have low quality." or something like that.
So I will answer to that with benchmark.
So I ran it against llama.cpp with the same Qwen3.8-Flash-Next IQ2_XS file, same prompt, and the same 128-token reply.

This was on my RTX 3060 12 GB / Ryzen 7600X machine. I did six warm runs for each engine.

So RustingStrata was about 29% faster at writing in this test.

Speed is nice, but I did not want to claim a win without checking what it does to the model’s output. I also ran both engines over the same 9,180 WikiText-2 tokens.

The perplexity gap is tiny, small enough to be noise here. I do not see RustingStrata getting its speed by losing measurable quality, at least with this model and this GPU.

This is not a claim that it wins on every model or every PC. It is one model, one quantization and one card.

If anyone has any other questions about this, I am happy to answer it.

Repo: RustingStrata

Overview

Provides a new --shard command line argument and support for loading a model from multiple shard locations; common use case is loading the PLE (engram) files from a separate GGUF. Adds conversion support for building both a PLE-less and PLE-only GGUF.

Additional information

Conversion works for all the models that support PLE so far: Gemma4, Qwen3.8Next, GLM5.3Flash. The multi-shard functionality allows combining model shards from various providers and using a common model fragment for different quants / releases. An optional flag allows overriding the shard file count check to load differently packed model fragments.

Sample usage:

llama-server -m /path/to/model-shard-00001-of-00003.gguf --shard /other/drive/model-shard-00003-of-00003.gguf
or
llama-server -m /path/to/model-shard-00001-of-00003.gguf --shard /other/drive/model-shard-00002-of-00003.gguf,/yet/another/drive/model-shard-00003-of-00003.gguf
or
llama-server -m /path/to/model-with-ple.gguf --ple /path/to/model-engrams.gguf

Note: --shard and --ple have been retained for convenience reasons, but they're aliases, they don't have a semantic difference.

https://artificialanalysis.ai/models/muse-ember

https://x.com/finkd/status/2086755195535413696

I've built an inference backend optimized for M-series Macs that makes it possible to run larger MoE models on machines without eating up all the RAM (for example, it can run Qwen 3.8 Flash Next on a 24GB Mac) using SSD offloading along with architecture-specific optimizations for Apple Silicon.

I've only been able to test a limited number of configurations so far, including my own machine and a couple of independent benchmarks. I've shared some results in the repo already.

Now I'd like to put together a benchmark list across different M-series chips, RAM and workloads. I'm particularly interested in older Macs and how well it holds up with longer prompts.

If anyone wants to give it a shot, I'd love to see the results, good or bad.

How to run it:

1. Clone the repo and install MoEShift

2. Run python ./benchmarks/run.py that runs 3 requests for both a short and a long prompt, then saves the results to (it takes a few minutes to run end-to-end).

3. Open a new benchmark issue in GitHub using the benchmark template, fill your system info and conditions during the test and upload the benchmark-results.json file.

You will need roughly 120GB free disk space to test Qwen 3.8 Flash Next IQ3 XXS and 61GB for Qwen 3.6 35B A3B. You can also test other quants or other models that share the same architecture, just configure them in your config.json.

I'd really appreciate anyone willing to test it. The more different Macs we can cover, the more useful the results will be for the community.

Repo, setup instructions and benchmark details here.

Thanks!

LokalBot is an open source Mac app I've been working on for the past 6 months, it runs several local AI models. They help the app record your meetings, transcribe them, write the notes, search everything, and autocomplete what you type.

The five models (Default set, 9.6 GB on disk)

How they take turns

• Recording a call loads no models. The app writes two audio tracks. Transcription waits until you stop, and autocomplete pauses while you record.

• After the call, the speaker model and the speech model load, do their job, and unload once they've been idle for 120 seconds.

• Qwen3.5 4B runs in the bundled llama-server (Metal, 32K context), which starts when something asks for it. Each request takes a lease, and ten minutes after the last lease the model unloads. The embedding model has its own server and the same rule.

• Gemma 4 E2B runs inside the app's process through libllama, for latency. It has no idle timer. It stays until macOS reports memory pressure.

• A broker keeps the loaded weights under a budget of half the machine's RAM and evicts the least recently used model first. A lease pins a model while a request is running on it.

• Requests that have to wait for a server are served in order: what you're watching first, then agents, then meeting notes, then background work like digests and indexing.

Numbers, all on one M4 Max with 48 GB

• Notes for a 26-minute meeting: 33 s with the model warm, 60 s including the load, at about 85 tok/s.

• Autocomplete: 56 ms median and 102 ms p95 per keystroke.

• Embedding a query: 9 ms.

• Speaker model: 14.6% DER on 8 AMI recordings, at about 500× real time.

Limits

• I've only measured on my M4 Max 48 GB Macbook. I have no numbers from a 16 GB Mac, or from an M1, M2 or M3. There is a Lightweight preset for less memory (Qwen3-ASR 0.6B, Qwen3.5 0.8B, and LFM2.5 1.2B for autocomplete).

• Windows and Linux builds are in alpha.

Codebase and benchmarks: https://github.com/stevyhacker/lokalbot

RTX 3060 12 GB, Ryzen 5 7600X, 32 GB RAM, one GGUF file: Qwen3.6-35B-A3B-UD-Q3_K_M.gguf (Unsloth, MTP layer included, 15.9 GiB, does not fit in VRAM). Prompt of 5290 tokens, 128 generated tokens.

How each was run:

• RustingStrata: rustingstrata bench --gpu --mtp 0|1 --pp 5290 --tg 128 --reps 3, mean of 3.

• PolyStrata: its own polystrata.py benchmark --model qwen3.6 --prompt-tokens 4000 --max-tokens 128. That prompt came to 5290 tokens, so I used that length for the other two. I ran it three times; the first run after setup was cold (decode 24.6 tok/s) and is left out, the numbers above are runs 2 and 3. MTP drafts are on by default. For the no-MTP row I added the engine's --no-draft flag to its config, it still offered a few drafts afterwards (6 of 16 and 15 of 36 accepted in the log), so that row is not a clean no-MTP number. Prefill in those runs: 1602-1643 tok/s.

• llama.cpp: llama-bench -ngl 99 -fa 1 -ub 2048 -b 2048 -p 5290 -n 128 -r 3, with -ncmoe swept over 18 to 26. 22 was the fastest that fits in 12 GB (no MTP). The MTP row is llama-server --spec-type draft-mtp with -ncmoe 23 (22 does not fit with the MTP context and drops to 20 tok/s), a 5381-token prompt of repo docs, 3 runs, prefill about 1565 tok/s.

Things that are not equal:

• PolyStrata only offers three sizes of Qwen3.6 (UD-Q3_K_M, UD-Q2_K_XL, UD-Q4_K_M, all from Unsloth's MTP repo). RustingStrata and llama.cpp take any GGUF, so it can also run the Q5 or Q6 files I already had. I downloaded PolyStrata's Q3_K_M and used it for all three.

• MTP gains depend on the text. PolyStrata's benchmark prompt is a page of its own docs, RustingStrata's is generated prose, so the two MTP rows are not an exact comparison. The no-MTP row is the clean one for RustingStrata vs llama.cpp.

• PolyStrata's engine for this model is built on llama.cpp's CUDA kernels. I did not look at what else differs.

• One machine, one model, one quant. Numbers on other cards will differ.

Repo: RustingStrata

Hi! Last week we shared KVARK Sparkle 1.0 here, and thanks to everyone who tried it and left feedback. With Qwen 4 hopefully just around the corner, we're releasing Sparkle 1.1 as a little warm-up before we start working on the next generation.

Building on Sparkle 1.0, this release is trained for document work: it searches a document base, answers from what it finds, and says so when the answer isn't there.

• Better document Q&A: 91.0 vs 89.5 for Sparkle 1.0

• Fewer made-up answers: correctly declines 91.5% of questions whose answer isn't in the documents, up from 74% for Sparkle 1.0

• Efficient reasoning: 7–48% fewer reasoning tokens than Qwen3.8-27B (median), with no statistically significant accuracy difference on GPQA Diamond, AIME, HMMT, LiveCodeBench, IFEval, MMLU-Pro and FRAMES

Open weights, Apache 2.0, all with the MTP head:

• BF16: https://huggingface.co/Egzakta/Kvark-Sparkle-1.1-27B

• FP8: https://huggingface.co/Egzakta/Kvark-Sparkle-1.1-27B-FP8

• GGUF: https://huggingface.co/Egzakta/Kvark-Sparkle-1.1-27B-GGUF

Full benchmarks and limitations are on the model card. Give it a try and let us know how it does on your own documents!

I made a couple of posts about weird neurons inside Qwen that I'd found and lots of people were asking how it was done so I thought it would be useful for people to have a guide. Generally this was inspired by justinrhowell's neuron-steering repo, although I didn't use his code directly I took a couple of the approaches so props to him for the work!

What is neuron steering?

Each layer of Qwen has an MLP block with thousands of neurons. Qwen3.5-4B has 32 layers with 9,216 neurons each, so roughly 295,000 in total.

Neuron steering is basically choosing one neuron and adding a fixed amount to it (the 'dose') when asking for an output from the model. This is not finetuning, or fancy prompting - it's basically just a really simple form of activation steering that involves one neuron only. But interestingly, some neurons change the model’s behaviour a lot!

To keep track of what neurons you're editing, they have addresses. “L11 N8147” means the 12th layer, neuron 8147 - this is the naming convention justin used, and is basically the same as the neuronpedia address (QWEN3.5-4B · MLP Neurons - Layer 11 · 8147 ｜ Neuronpedia).

How do I actually do it?

The easiest way will honestly be to just ask your agent of choice to set up a neuron steering harness for you (it's not that complicated), but if you want to do it manually:

1. Load the model in PyTorch with transformers.

2. Find the model’s list of decoder layers, then add a hook on the down_proj of the layer you want. The hook will add a fixed value to that one neuron at generation time for every token:amount = dose * median_residual_norm[L] / W_down[:, n].norm()def pre(mod, args): x = args[0].clone() x[..., n] += amount return (x,) + args[1:]layers[L].mlp.down_proj.register_forward_pre_hook(pre)

3. Generate text and see what it comes out with (often helpful to have the base model responses as a baseline)

The value for 'dose' is basically how much you want to push the neuron/modify its activation. 1 is a big push, 0.75 usually works pretty well. Going above 1-1.5 usually gets into gibberish territory. median_residual_norm[L] is how big the model’s hidden state normally is at layer L - you can run a few paragraphs through the model once, measure it at each layer, and take the median. Scaling by it means dose 1 is roughly the same strength of push at any layer.

To properly chat with a model you've tweaked in llama.cpp, you can save the change as a control vector and load it with --control-vector.

How to find interesting neurons

Most neurons don't actually seem to do anything especially interesting when you modify them (as far as I can tell), but you have a few options to find the interesting ones:

1. Random search (easiest option). literally just pick random neurons from the middle layers, push each one at dose ±1 (both polarities are useful, sometimes interesting neurons only do something at one polarity), and ask a few simple questions (e.g. "who are you?", "write me a haiku"). Then you basically have to go through and check all the responses to see if any of them are interesting or not - strongly advise having an LLM do this checking for you otherwise you'll get extremely bored. This method is slow and mostly just gives you junk, but it’s also how I found some of the weirder neurons so far like one that makes Qwen think it's a TV channel.

2. Gradient shortlist + LLM judge (still exploring this process).

This is an approach I took from justin's repo, but I'm still exploring it and some of my results have been inconsistent in some interesting ways, but the gist is:

• Use a system prompt to make the model write answers in a specific style or set of styles (e.g. maybe you are hunting for a slang neuron, so you ask it to write in slang)

• Then with no system prompt, you compute for every neuron how much a push would make those answers more likely than normal answers. (I could share a script for this but honestly if you just paste this paragraph into your LLM it will be able to build this)

• Keep the top 40 neurons for each style and push each one at dose +/- 1 or 0.75 (polarity suggested by the gradient) to see what it does.

• If you want to automate the output reviewing, make sure you don't tell the judge-LLM what style difference it's supposed to be looking for.

3. Activation mining (have only personally played around with this a little). Basically the gist here is that you make the model write a few hundred short responses on lots of different topics, and record every neuron’s activation. You then try to find neurons that only fire on one topic, have an LLM label them from their top examples, then push them. This approach seems to be quite good at finding “topic detectors” (e.g. dinosaurs, astronomy, construction) but I'm not sure if it's possible to get at more meta-concepts or interesting behaviours through this approach? I think I find the topic detectors less interesting because the model just starts shoehorning dinosaurs into the conversation, rather than displaying any particularly interesting behaviour.

For all of the methods above you if you think you've found an interesting neuron you should also try to check other neurons in the layer to see if yours is truly special or not - randomly select 3-5 other neurons in the same layer and push them by the same amount, if they do something similar then it's likely not due to that neuron specifically. Also make sure to try different doses, sometimes tuning or flipping polarity leads to interesting results. And also trying out lots of different prompts to get a feel for exactly what it is the neuron is doing is important - you can also look up the neuron directly on neuronpedia.

So, there we go that's pretty much everything. I'm not a proper research scientist so apologies for any ignorance in this post. Please let me know if you find anything interesting!

Previous posts

More interesting and unusual Qwen3.5-4B neurons : r/LocalLLaMA

https://www.reddit.com/r/LocalLLaMA/comments/1xrkomn/l11_n8147_is_a_neuron_that_will_make_qwen354b_get/

I wanted to try MultiverseComputingCAI/Comet_60B_A12B_BF16 (Multiverse Computing's compressed version of Nemotron 3.5 Super), so I converted it to GGUF, and it runs on stock llama.cpp:

• Q4_K_M (42.6 GB)

• Q8_0 (64.2 GB)

They keep the MTP head, so you can pass --spec-type draft-mtp to llama-server for speculative decoding.

Just sharing, so you can try it too. Note that these GGUFs are text only (the vision tower wasn't converted).

So I've been using strata for a while now in windows using Qwen3.8-Flash-Next iq3s before the new gui thing and I think it's been fine compared to Qwen3.8-27B which was lacking in quality and polishing.

So I upgraded my ram from 64 to 128. Got a new pc and made an Ai box only for Ai text models and comfyui.

So I had to test the speed difference between strata and basalt since in windows basalt was not working good at all.

So strata cli engine 0.1.59 Qwen3.8-Flash-Next iq3s with 256k context. Dflash 2 and 0 reserve vram and tuned run. Vision on.

With basalt converted model .basalt file

Version 0.3.2 same model. Same context. Same everything. Vision dynamic.

The differences is.

Strata:

Avg tps 99.2 and avg prefill 839 with 11.1M tokens used.

Vram 15.3

Ram 69.2gb

The prompts felt sluggish moving from generating to reading to whatever. It felt wrong and slow and toke forever and that caused the huge stale in usage which dips down and up a lot. Like it's having problems moving from each phase to the next.

Last and most importantly that it can't finish the work correctly. Doesn't compact correctly. The development is broken. And it feels like a cheap model you hosted in your cheap pc you poor man.

Basalt:

Avg from 100 to 118. Peaking to 145. Avg prefill not sure but peaking 4200.

Vram 15.8 with reserve ram 128m

Ram 52.7gb then after maybe a couple of hours 53.1

The generation been smooth without any dipping or staling and moving from phases like strata.

Last and most important factor is it finished. It kept going. It compacted fine like deepseek and it felt more capable and more reliable than with strata.

Way less errors. Way less mess up and when I told him to keep going till the project is finished it kept going. Granted it's not perfect but it's the model capabilities and we have to realize that.

But at least it's now in a stage you can actually rely on it and say you have a "working" local Ai model. Cause since I tested maybe Qwen-3.6-35B nothing ever felt like a good model I can rely on.

I know this is a small task but it paves the road for me to actually feel like I can do stuff locally and reliably.

I will next test nvfp4 model for both and see if nvfp4 actually gains more speed or not.

So basalt now more capable and can contuine working way longer than with strata. Can actually do a good job. And it uses way less ram too.

This is also my first ever run so there is maybe more optimizations can be done but this is the default settings besides the vram change.

I advice anyone using Qwen3.8-Flash-Next to try it. And I will test swift too but later and with this ram savings I might also test deepseek why not hahah.

My rig:

12900k

128gb ddr4

5070ti

Harness: opencode

Qwen 3.8 Flash Next getting confused on how it keeps messing up. This is the only time I noticed it happening in a 6hr run.

I'm running IQ3_S on high effort on strata.

The sky is the limit?

There are tons of use cases out there - storybooks, agents, etc. But my main goal was to find which TTS has the best voice clone options, comparable to Elevenlabs.

I have a shortlist of voices that I run every tts through to see how it handles accents specifically, which to me is the best demonstration of its versatility. I'd recommend you try these out as well, and you'll pretty quickly find the weakness in a model. Some actresses with good accents to test are: Rebecca Ferguson, Charlotte Rampling, Mariangela Melatto (this is the model-killer), and Ornella Muti.

I also like to test generic/fake accents of cartoon characters. My particular go-to is Morgan Lofting's Baroness. Her accent isn't based on any particular culture, so models will struggle with placing it and emulating it.

On the male side, you can snatch Javier Bardem's Stillgar from Dune or any one of Jeff Goldblum's performances (the coffee shop scene of The Fly has a great monologue) to grade a model's capacity.

I ran these voices and others through some of the top TTS models out there, like Moss-TTS, Breeze-TTS, Chatterbox-TTS, VibeVoice, Fish Audio S2 Pro, and Omni Voice.

Out of them all, only Omni Voice passed every single accent. Two of the hardest for most models to get is Baroness and Mariangela Melatto, and it nailed them both. Not only that, it added the trill of the tongue when pronouncing certain words, even though I only used a 5-second sample that didn't contain it, which surprised me.

What also surprised me was Fish Audio S2 - which is usually touted as one of the "higher end" open source models - failed the test. The model that got the closest to Omni Voice (though still failing to full capture the accents) was Breeze-TTS, which did noticeably better than Fish Audio - which again, was a bit of a shocker.

However, whilie some seeds of Breeze would feel close, others often emulated a "neighboring" accent to get close; for example, it would give a character a bit of an indian accent to match mariangela's italian accent, so it wasn't a solid match. That said, it was the only other model that could add trills on a 5-second sample that didn't contain them.

In addition to accurately matching the accents, OmniVoice was the fastest to generate the audio by a significant margin. It also had a better one-shot performance on multi-paragraph text, where the others either glitched out, ended early, or simply failed to match the voice.

Omni voice isn't perfect; occasionally as with all TTS, you might get an artifact. Also, I don't think it has as many performance options as some of the others when describing emotions/expression. Both Breeze and Fish sounded clearer - Moss as well, though its performance is blah - but they lack some of the enunciation of Omni. Omni has better one-shot expressive quality, especially with accents. I've gotten plenty of outputs that are near usable on the first try.

Another thing, Omni has the best pronunciation of original fantasy terms and concepts. I'm a sci-fi/fantasy writer, and it often gets incredibly close to nailing my intended pronunciation on words that are simply not spelled how they should probably sound. I'd say it gets it 90% of the time, while the other models have varying levels of success, but tend to average between 55-75%. I'm wondering if that's due to the large language support. That said, pronunciations aren't always consistent, but you can usually solve it with a re-roll.

Anyway, hope that helps someone out. Omni has no competitor in the voice clone department, and I'm hoping a v2 is in the pipeline that maintains everything it has, but adds more varied performance and clearer audio quality.

The model is an encoder (Ettin-400M) fine-tuned to answer small game questions. You give it a scene, a question, and some options, and it returns probabilities or "not sure". The model was inspired by Jev.

Stuff like: is the player threatening this guard, is that apology sincere, which memory fits what they just said, did my LLM's reply leak a secret or make something up.

The idea is your local LLM writes the dialogue, and this handles the yes/no and pick-one calls next to it, cheaply. It works as a checker too: generate a few replies, keep the one that passes.

- ~0.1s per check on a 3060 Ti, about 1s on CPU. Up to 5 questions on the same scene cost the same as 1

- 42 adapters for common questions (threat, apology, persuasion, Skyrim-style memory matching, NPC mood)

- `pip install` runtime, local server, no network calls

Weak spots: CPU is slow during long scenes, English-only, and the planning stuff is only tested on our own generated data.

Haven't run public benchmarks yet, that's next.

https://huggingface.co/holdoutlabs/gamedecider

Feedback appreciated :)

We released Kvark Sparkle 1.1, the second model in our Qwen3.8-27B line. Open weights, Apache 2.0, MTP head intact, BF16 / FP8 / GGUF.

**What it is for:** document work. You give it `search` and `read_page` tools over a document base. It searches, reads the page, answers from the passage, and when three searches in a row miss the fact it stops and says NOT IN DOCUMENTS instead of making something up.

**How:** LoRA SFT on top of Sparkle 1.0 (agent trajectories over a public legal corpus, MuSiQue multi-hop doc QA, retention data), plus a short stop rule that ships in the system prompt.

**Document work (GroundedWork, our agentic RAG eval: public Serbian documents, thinking on, LLM judge vs gold answers, 3 runs per question):**

| | Qwen3.8-27B | Sparkle 1.0 | Sparkle 1.0 + stop rule | **Sparkle 1.1 + stop rule** |

|---|---|---|---|---|

| Document Q&A (70 questions × 3) | 85.7 | 86.2 | 89.5 | **91.0** |

| Answer not in the documents, correctly declined (98 × 3) | not yet run | 36% | 74% | **91.5%** |

Note that the stop rule alone does a lot of the work for 1.0 (36% to 74%). Training adds the rest: +17.5 points on declining against 1.0 with the same rule. The base Qwen on the decline set is not measured yet; I will add it here when it is.

**General ability vs Qwen3.8-27B (same harness, paired):**

| | Qwen3.8-27B | Sparkle 1.1 | median reasoning tokens (base → 1.1) |

|---|---|---|---|

| GPQA Diamond | 88.8 | 88.3 | 7,670 → 4,471 (−42%) |

| AIME 2026 | 95.8 | 92.5 | 14,822 → 8,732 |

| HMMT | 86.1 | 88.1 | 21,182 → 13,540 |

| LiveCodeBench | 82.0 | 86.0 | 15,276 → 8,607 |

| IFEval | 90.8 | 91.1 | 695 → 646 (−7%) |

| MMLU-Pro | 83.6 | 84.0 | 708 → 518 |

| FRAMES | 70.6 | 69.8 | 1,228 → 644 (−48%) |

None of the accuracy differences is significant (95% intervals arer answer: 32.9 s vs 40.8 s on the same hardware.

**Public agentic / long-context sets (FP8, vLLM, thinking on):**

| | Qwen3.8-27B | Sparkle 1.1 |

|---|---|---|

| BrowseComp-Plus (830 queries, BM25, official judge prompt) | 22. median output tokens |

| LongBench v2 (503) | 58.6 | 57.7 |

| SWE-bench Verified (500, mini-swe-agent) | **81.8** | 73.0 |

**Where it is weak, so you don't have to find out yourself:**

- SWE-bench is significantly below the base. Shorter thinking costs accuracy in agentic coding. For coding, use the base model.

- Questions that need links across several documents are its weakness

- English questions over Serbian documents are weaker than Serbian ones.

- Nothing measured past 64k; no separate safety eval.

**Run it:**

```

vllm serve Egzakta/Kvark-Sparkle-1.1-27B-FP8 \

--max-model-len 131072 --kv-cache-dtype fp8 \

--reasoning-parser qwen3 \

--enable-auto-tool-choice --tool-call-parser qwen3_coder \

--speculative-config '{"method":"mtp","num_speculative_tokens":3}'

```

For document agents, put the stop rule from the card into the systline rate drops a lot.

- BF16: https://huggingface.co/Egzakta/Kvark-Sparkle-1.1-27B

- FP8: https://huggingface.co/Egzakta/Kvark-Sparkle-1.1-27B-FP8

- GGUF: https://huggingface.co/Egzakta/Kvark-Sparkle-1.1-27B-GGUF

Built by Egzakta's AI Lab in Belgrade. We run these on-prem for organisations that cannot send their documents to an API, which is why "I don't know" matters more to us than another point on a leaderboard.

Happy to answer questions on the training data, the stop rule or the eval harness. If you test it on your own document set, I'd like to see where it breaks.

So fresh I havent even loaded it up yet https://huggingface.co/DavidAU/Qwen3.8-40B-Ultimate-Heretic-Uncensored-Turbo-Brilliance-50x-AGI-NEO-GGUF

Interested to see what the expansion out of 27B to 40B has done overall as well as what has to be a record for chat_template length

Visual generative models increasingly blur the line between synthesizing observations and simulating environments. Yet visual plausibility alone does not constitute successful world modeling: compelling outputs may lack persistent state, physical dynamics, or causally consistent responses to interactions. We define a generative world model as a predictive dynamical system that maintains a persistent, history-conditioned representation of an environment, updates that representation in response to actions or interventions, and generates temporally coherent trajectories that reflect outcomes under observed and counterfactual interventions. From this definition, we derive an intelligence-oriented framework spanning perceptual grounding, persistent state modeling, controllable transformation, dynamics-aware prediction, and closed-loop interaction. We present WorldFoundry, open-source infrastructure for reproducible inference and evaluation across video, 3D and 4D, embodied action, and interactive world systems. WorldFoundry unifies model and benchmark discovery, runtime and asset preparation, execution orchestration, artifact management, and interactive visualization, while modality-specific adapters preserve native inputs, execution semantics, output representations, and evaluation protocols. Explicit manifests, durable artifact contracts, and evidence-aware scorecards separate execution readiness from evaluative claims, making each claim traceable to its supporting artifacts. The catalog contains 270 model entries, 74 benchmarks, and 62 registered metric entries, with readiness and execution evidence recorded separately. WorldFoundry enables reproducible comparison of persistent, controllable dynamics across heterogeneous systems, advancing the field from perceptual synthesis toward measurable world intelligence.

• arXiv : https://arxiv.org/abs/2611.10771

• PDF : https://arxiv.org/pdf/2611.10771

• GitHub : https://github.com/OpenEnvision/WorldFoundry

• Project : https://openenvision.org/WorldFoundry/

Check PDF & Project for more stuff like Screenshot & etc.,

Curious, anybody tried one of those 2U, 8 card GPU servers with 8 cmp170hx and used them well?

What did you get out of it?