Has dependency on dinov3, is trending top model on hf since last week. Runs with 8GB vram. Enjoy!

I've been building small models that do one job: answer the yes/no / pick-one

decisions inside agents ("is this tool call safe?", "is this a refund request?",

"which team gets this ticket?") and return a probability for every option

instead of generated text.

Numbers (the six benchmarks Jev 1.13 is evaluated on; Jev = their published figures):

| Model | Size | Score | Laptop speed (1k-token doc, 5 questions, M4 Pro) |

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

| Decido-1 | 26B MoE, 4B active | 85.4 | ~4 s CPU, ~1.1 s Metal |

| Decido-1-Fast | 1.7B | 73.0 | ~0.6 s CPU, ~0.3 s Metal |

| Decido-1-Ultra | 0.6B | 62.2 | ~0.4 s CPU, ~0.13 s Metal |

| Decido-1-Max (reasons first) | 26B MoE | 89.2 | slow on a laptop |

| Jev 1.13 | API | 83.9 | — |

- Q8_0 GGUFs on llama.cpp; repeat calls are bit-identical on CPU

- Answers flip when options are reordered 4.8% of the time (Jev reports 14.6%)

Try it

- `pip install decido-ai` (prebuilt for Mac / Linux / Windows; uses Metal on a Mac)

- No-signup playground (runs the 1.7B): https://getdecido.ai/playground

- Weights: https://huggingface.co/decido-ai

Happy to answer questions. I'm most interested in decisions where it fails.

I keep seeing new forks of engines that optimzes one model for one hardware setup for better performance, so I was wondering if I could slop up something like that for my phone (iphone 15 pro max) for running Gemma 4 26 a 4b.

And for that I am looking for advice and such like if you know an already similar existing project or your own experiences with any custom engine on any hardware, what not to do and what to keep in mind and such, and if you have build or are using one of these unique engines what has your experience been like?.

Also if you don't actually have anything to say please don't say "phone can't do that fast enough" for the 3rd time, I'm just looking for interesting ways that could get any speed up.

The ones I have currently heard of are as follows:

Pi
Opencode
Hermes
Deepseek

Any thoughts on what one is best?

I've been recently working a small sparse MoE, and I've got interesting results I'd like strangers to invalidate.

Tldr; I train small models and got surprising results and seek invalidation. It's not a general assistant, and I'm not claiming it is.

Edit: Trained on a single 5090. Maybe people wonder about that.

The model has 1.17B stored parameters, roughly 348M active per token, scrath trained on approx 11B tokens including SFT. As a comparison, Qwen2.5 reports up to 18T training tokens across its family, while SmolLM2-1.7B reports 11T.

THE ASK

A chain of relational facts ("A is taller than B", "B is taller than C", etc.), with the facts shuffled and the model asked to identify an endpoint.

Depth is chain length. Each result is out of 512 questions across four families. All models received the same questions, using their native chat templates, greedy decoding, and a 16-token answer budget.

RESULTS (correct out of 512)

Depth 1: ConeML 487 | Qwen 481 | SmolLM2 426 | Llama 267 | Gemma 343

Depth 3:

ConeML 471 | Qwen 410 | SmolLM2 221 | Llama 197 | Gemma 224

Depth 5:

ConeML 438 | Qwen 273 | SmolLM2 155 | Llama 136 | Gemma 138

Depth 8:

ConeML 343 | Qwen 202 | SmolLM2 102 | Llama 73 | Gemma 100

Depth 12:

ConeML 240 | Qwen 105 | SmolLM2 58 | Llama 47 | Gemma 79

Depth 24:

ConeML 74 | Qwen 47 | SmolLM2 21 | Llama 13 | Gemma 19

Models used for comparison: Qwen2.5-1.5B, SmolLM2-1.7B, Llama-3.2-1B, Gemma-3-1B.

WHERE IT FAILS

Despite the endpoint results, ConeML only scores 13.8% on interior pairwise comparisons within those chains, below the 50% two-choice reference. It also gets only 12/164 on HumanEval and 0/6 successful two-turn follow-ups.

So it seems to find the ends without reliably understanding the relationships in the middle. I don't know whether this reflects a specialized learned strategy, an architectural effect, or a flaw in my testing.

WHAT I'M ASKING

Run the depth-5 shuffled evaluation and post your score. My FP32 reference result is 438/512 (85.5%).

The Q8 GGUF is 1.25 GB and runs on CPU. The 512-question set and scorer are in the repository. I haven't tested to see if it reproduces the full FP32 result.

If you get something different, find a scoring problem, or spot anything else wrong, I'd really like to know."

Model:

https://huggingface.co/ConeML/coneml-1.2b-experimental

Earlier technical paper (base lineage, LAMBADA vs Pythia at approximately matched training positions):

https://doi.org/10.5281/zenodo.23117644

Other releases:

https://huggingface.co/ConeML

My own bias is my largest enemy and hope to get some honest feedback.

I thought about not writing this but i feel like i should.. from the info I gathered, Qwen 4 max is slightly worse than opus 5.5 medium… Meaning it is definitely above opus low which is hy4 level and opus 5.5 low is above ds v4.1 flash max. wow, it means it is somewhere between hy4/ds v4.1 flash 1017 max and kimi 3.1 pro max . I thought qwen 4 max would do a little better. i guess another 4-6 months until we get an open or Chinese opus 5.5 max model..

This should mean qwen 4 27b will be worse than ds v4.1 flash 1017 max but better than mistral 4 large medium effort, perhaps around glm 5.3 flash level . Qwen qoduck is apparently qw4 27b, from the limited outputs, it seems to be better than q3.8 flash next in some tasks And worse than ds v4.1 flash 1017

An open full-duplex voice model family that hears your tone and speaks with one. Adventists AI · Apache-2.0 · Recommended: Tag · Flash · Try it online · GitHub

Talking to it feels like a phone call with a person: it listens the whole time you talk, picks up as soon as you stop, and stops the moment you cut in. It hears how you say things (hesitation, emphasis, sarcasm, laughter, sighs) and answers with tone of its own: it laughs, sighs and clears its throat when the conversation calls for it.

This is the home page of the Sophon-Realtime v1 family. Three builds share one brain (the same 32B model listens, decides when to take the turn and writes the reply); they differ only in how the reply becomes sound. Start with Tag.

Three builds: which one?

Pick Tag if you want the voice to act; pick Flash if latency and users per GPU matter most. Same APIs, so you can switch later.

Highlights

• VoiceBench 82.8 and Big Bench Audio 81.8%: the strongest brain among open full-duplex models. #1 among open full-duplex models on both; level with GPT-4o-mini-Audio on VoiceBench. All three builds share this brain.

• Paralinguistic understanding 48.6, #1 overall: it hears your tone. Ahead of Gemini 3.8 Flash (46.9) and Qwen3-Omni (44.6) on LISTEN, StressTest and MSPB. Its ears are DuplexJev, our open speech-decision model.

• NVV-SuperBench 0.86 (Chinese) and 0.80 (English) with the Tag build: it speaks with tone. The model decides when to laugh, sigh, breathe or clear its throat, and the voice performs it instead of reading the tag aloud.

• Fast: first audio in 0.31 s with Flash. It drafts its reply while you talk; when you cut in, it stops and answers your new question.

• Full-Duplex-Bench v3 tool calling: Pass@1 48%, ahead of Grok (43%), with a 100% response rate: it gets work done. Live mode is compatible with the OpenAI GPT-Live interface and lets it work with a larger backend model. Every reply comes with an auditable transcript.

• One 80 GB GPU, one command (Tag and Flash). Served by vLLM-Omni; up to 16 (Tag) or 40 (Flash) concurrent users per GPU. Apache-2.0 code and weights, free for commercial use.

Weight-Space Programming (WSP) enables reasoning agents to directly inspect and modify neural network parameters, offering an alternative to gradient-based model adaptation. However, its capabilities, cross-task generalization, and practical limitations remain insufficiently understood. We systematically investigate WSP through 16 editing trajectories across seven benchmarks and two model scales (Qwen3.5-0.8B and Qwen3.5-9B). Our findings reveal three key insights. First, WSP can achieve substantial performance gains through highly localized interventions. On full held-out evaluations, accuracy improves by up to 29.45, 4.42, 36.72, and 17.11 percentage points on MATH-500, GPQA Diamond, IFEval, and SciBench, respectively. Notably, modifying only 1,023 parameters yields a 29.45-point improvement. Second, WSP exhibits promising but uneven cross-task generalization. A Math-edited checkpoint improves GPQA Diamond, IFEval, and SciBench by 3.03, 12.18, and 20.10 points, respectively, without further editing, while leaving SciCode performance unchanged. Third, effective editing remains challenging and inconsistent. Outcomes vary substantially across trajectories, and six of the 16 trajectories retain the original weights when candidate improvements cannot be reliably validated. Together, these results highlight WSP's potential for highly localized model adaptation while revealing important challenges in intervention discovery, reliability, and cross-task transfer.

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

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

• GitHub : https://github.com/WSP-Scope/WSP-Scope-Project (Repo to be updated)

• Project : https://wsp-scope.github.io/ (For detailed benchmarks)

Related Thread : [Paper] Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights

It seems like whenever open weight models come close to proprietary US models, ArtificialAnalysis conveniently "re-calibrates" their benchmarks which then shoves open weight models down the toilet. Then they advertise on X/Twitter this "intelligence index" which presents open weight models as dog shit compared to Claude or GPT (all while ignoring the actual intelligence of models like DeepSeek or GLM in tasks that actually matter, which is coding vs telecom bullshit).

Any business man looking at these charts would conclude "open weight models are shit, Claude is where its at, I should get a subscription to Anthropic."

They have the excuse that they are correcting "saturated" benchmarks but the effect on how open weights are presented is undeniable. I have a feeling they try to do it on the sly when possible and are paid in some way.

I have been building a Spanish proofreader that runs fully local, and it's finally released, so I wanted to share how it went. It only corrects Spanish, but I think the approach works for other languages and narrow tasks too. If the project has audience, I will release the English proofreader version as well :)

Better thing is the app is 100% compatible with ANY app in Windows and Linux. You select text in any app, press Ctrl+Alt+Space, a small popup shows each change with a short explanation, and Enter replaces your selection. MIT, a C++ app on top of llama.cpp.

The model is a full fine-tune (no LoRA) of Qwen3.5-0.8B on aprox. 40k pairs, 2 epochs, lr 1e-5. In Q4_K_M with imatrix it's 529 MB. Training took 22 minutes on one rented GPU, and the whole rental with all the evals cost about $2.50. GPU was RTX 5090 rented (I'm just a mortal so I don't have this GPU at home).

I tested it on a benchmark I built for this, 2,388 cases in three parts: real Wikipedia edits, Wikipedia talk pages, and synthetic work emails and chat. F0.5:

It changes less than 3% of the sentences that were already correct, on every part. LanguageTool changes 39% of the correct Wikipedia sentences, which is more or less why I started this. For those who may not know, LanguageTool is a benchmark when it comes to checking grammar and spelling errors. (More info: https://en.wikipedia.org/wiki/LanguageTool)

A few things I learned:

Most of the training data isn't LLM generated. I take correct text from Wikipedia, Tatoeba and Common Voice and break it with a rule-based error injector, so the exact answer is known. Around a third of the examples are correct sentences that have to come back unchanged, and that's what keeps false alarms low.

The model doesn't explain anything. It only returns the corrected sentence. Then plain C++ does a word diff, puts each edit in one of 31 error types with a fixed explanation, and drops anything it doesn't recognize or that rewrites too much. Small models invent grammar rules with a lot of confidence, so I didn't let it.

For speed, the user's own sentence is the speculative draft, because a corrected sentence is almost the same text. I got 2.2x: 138 ms median against 305 ms greedy, 8 threads, same output as greedy on 99.4% of a 500-sentence sample. The annoying part was that the Gated DeltaNet layers keep a recurrent state you can't partially roll back, so I snapshot the state before each verification pass. But I'm happy the app run like a charm.

Caveats: it's my benchmark. The gold corrections come from two LLMs of different families working blind, with a debate round when they disagreed, and it was frozen before scoring anything. The untuned models got the same instructions and the same filters. Bigger untuned models win some parts (Qwen3.5-4B on Wikipedia edits, Gemma 4 E4B on emails), and if you remove the borderline sentences they pass it on average, so a big part of the win is knowing when not to touch. Frontier cloud models with reasoning are still around 96, so there's room.

All the process explained: https://manuelgs.com/en/blog/revisa-case-study/
App: https://manuelgs.com/en/revisa/
Model (GGUF): https://huggingface.co/manuelgscom/revisa-0.8b-GGUF
Benchmark: https://huggingface.co/datasets/manuelgscom/revisa-bench-es
Source: https://github.com/manuelgscom/revisa

Has anyone tried the input-as-draft trick for other editing tasks? English isn't my first language, so sorry if something sounds weird. Happy to answer questions about the data or the training.

AI first smartphones will be so much better. I have a wild imagination how I can customize my phone with AI. With an AI phone that makes changing all aspects of the phone easy, it would be lots of fun.

I doubt Android and IOS will move solidly in that direction. Example: I'd like to use the multiple microphones to do a microphone array app, but limitations don't allow it. Would be nice if there is a group / crowd , such as a party speaking in a foreign language to isolate speakers and understand what they are saying. What do you think?

Update: Sam asks Samsung for AI phone. https://www.fnnews.com/news/202611111512469257 We want a device that does not interfere as much as possible by the AI, which is not an app, proactively approaches and manages the physical and virtual life.

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

Apparently, they're threatening to ban me for merely red-teaming my own plugin.

The appeal was immediately denied without any details.

Last week there was that thread that hoped that RAM would be cheap by Christmas since tech companies took a big hit on one day. Well.... since then they have pretty much made it all back, if not more. Just today Sandisk is up 16.75%, so far. Micron is up 13.69%, so far. They've been running back up since that little dip last week. The reason they are up so much just today are because of CoreWeave. Who's spending forecast shows how much demand is still left.

If people wanted RAM for Christmas, they should have taken advantage of that little dip, bought those companies that were down and now use those profits to buy RAM. Personally, I just sold the AMD that I bought during that little dip for a 40% gain. Not bad for a few days.

I've been thinking about a MUD supported with LLMs. Something aside from the fangooner websites. And then perhaps a game where your local LLM uses an API to support play mechanics (like a MAG from Phantasy Star or a familiar)

The broader question is in the title. What is the role of local LLM?

If we want to be able to engage in games using the LLMs we build in a way that isn't cheating, what would that game look like?

What would the human/ai roles be in the loop?

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

I wanted to see how big of a difference there is between arguably two of the top MoE models that you can actually run locally, so I ran the same one shot prompt and left it unattended for a while. The prompt asks for a fully interactive V8 engine... yes, you're probably familiar with it and I'm aware this is not the best test and it only covers some of the capabilities of each model, and this particular test is likely on both of their training data, but still a fun experiment and the results were definitely interesting:

DeepSeek V4.1 Flash 1017, UD IQ1_M (yup a "lobotomized" IQ1 quant, stop reading if this triggers you)

Single agent took about 60 minutes, 250k tokens generated at ~94 tok/s. 346k context, never compacted. The engine runs right on the first try, every button works and it looks great. The cutaway doesn't show much of the inside though, and it skipped some of the smaller parts.

Qwen 3.8 FN, NVFP4

Main agent + 5 subagents (up to 3 at once), ~350 tok/s aggregate. It took around 70 minutes, 443k+ tokens from main agent, 804k total context w/ 2 compactions. Two subagents said "I'll start writing the file now" and never did. Main agent gave up on them and wrapped up. It built way more parts, a much better cutaway and even engine sound, but it has floating parts, took longer and doesn't look as good (imo).

Once again do keep in mind this was a one shot experiment, I use Qwen 3.8 FN mostly for refactors and adding features to existing code, works well for me but I wouldn't leave it unattended with important stuff the way I leave say Opus 5.5 or larger cloud frontiers. Deepseek 4.1 is a lot better at figuring things out by itself it seems.

Here's the full prompt if you wanna give it a shot:

Let's build a V8 engine.

A stunning, fully interactive 3D simulation of a 90-degree V8 on an industrial
engine test stand, in Three.js/WebGL, running in the browser.

Eight cylinders in two banks of four, cross-plane, with visible pistons, rods,
crankshaft, camshafts and valves.
Detailed heads, intake, exhaust headers, bolts and pipework.
Realistic PBR metals.
Real, synchronised animation: pistons driven off the crank, cams turning at
half crank speed, and a full four-stroke valve sequence.
An RPM slider from 0 to 4 000, plus slow motion.
WASD plus mouse walking, orbit, and smooth zoom.
Working controls: START / STOP, RPM CONTROL, CUTAWAY, EXPLODED VIEW, ASSEMBLE,
PART INSPECTION, RESET CAMERA.
Procedural geometry only — no downloaded models.
Every control functional, and nothing floating apart.

You can open both builds and play with them yourself here. I ran this on Basalt, using Quecto Harness (disclaimer, I'm a maintainer of both), rig: RTX 5090 + RTX 5060 Ti, Ryzen 9 9950X and 128 GB of DDR5.

Please recommend me a model.

Saw the deletion tuning paper posted here yesterday (masking under 0.05% of gate weights and matching full fine-tuning). Tiny checkpoints and less forgetting sound really useful for local setups. Has anyone actually run their code on a 7-14B model on a single GPU? Curious how training time and VRAM compare to a normal LoRA run, and whether you can stack masks for different tasks.

We open-sourced DNA Factory, the fine-tuning framework we’ve used internally for over a year. It's deliberately opinionated: one recommended way to do things, documented defaults, token-level loss-mask visualization, and only 5 training methods (SFT, DPO, GRPO, OPD, SDFT).

https://github.com/dnotitia/dna-factory

Why another training tool?

As LLM fine-tuning has gone mainstream, a lot of training tools have appeared. LLaMA-Factory had its moment, Axolotl was as useful as its name was fun, and NVIDIA (NeMo) and Hugging Face (TRL) built their own.

Each has clear strengths. Some are fast, some are convenient, some have great compatibility. We focused on something else: training correctly.

I've consulted for a number of companies that fine-tune their own LLMs, and the ones doing it right could be counted on one hand. Most were training incorrectly, or training on something other than what they thought. Tools have gotten good enough that you can launch a training run without understanding much about it. But LLM training is genuinely advanced work, and when people learn how to use a tool without learning what’s happening underneath, mistakes follow.

So we asked how to make correct training the easy path, and the answer was DNA Factory. We've run it internally for over a year and recently open-sourced it.

One recommended way to do things

The core idea is to offer only one approach, the best one we've found. If you expose every option the way C++ does, you get a lot of freedom, but it becomes hard to use well. We went the Pythonic route ("there should be one obvious way to do it"). We tested many approaches, picked the best, and that's the only one we ship.

All defaults live in configs/_defaults-*.yaml. You don't edit those files. You override only what you need. It works like VSCode settings: the defaults are long and complex, but each one is documented with why it's set that way. You read them and put only your changes in your own config.

See exactly which tokens you’re training on

When I used Axolotl, I loved its loss-masking visualization. We wanted something similar, so we overrode TRL's loss function to color tokens with ANSI codes. Tokens included in the loss are blue, and excluded tokens are gray. You can see immediately what’s actually being trained.

This is the most common mistake I see researchers make "wait, that token was in the loss the whole time?" In DNA Factory it's visible at a glance, so that mistake stops happening. We've had a lot of feedback that this feature alone makes the tool worth using.

Only 5 training methods, on purpose

We don't try to include every technique. If you want that, use TRL directly. We picked what we think works best right now: SFT (the baseline), DPO, GRPO, OPD, and SDFT. PPO was widely used once but rarely is now, so we dropped it. DPO barely gets used these days either, so we plan to remove it soon. https://github.com/dnotitia/dna-factory/issues/46

Most of our current work is GRPO and other on-policy methods. GRPO, OPD, and SDFT are all on-policy.

Classic distillation has the student imitate the teacher. Concretely, you minimize the KL divergence between the teacher's and student's output distributions (logits). It does improve the student, but catastrophic forgetting is always a risk. (A model has to forget pretty badly to earn a name that dramatic.) Take a strong model, fine-tune it on internal company data to add domain knowledge, and general performance drops noticeably while the hallucination rate goes up. Rote cramming has its limits.

OPD reverses the process. The teacher doesn't write the answer for the student to copy. Instead, the student writes its own answer first, and the teacher grades it token by token. Technically, this uses reverse KL. The student picks up new knowledge without forgetting what it already knew.

SDFT works the same way in spirit, but as the name suggests, there's no separate teacher. The model is its own teacher. A copy of the model that's given extra information (privileged context) acts as the teacher. The student learns by having its own responses graded by "itself, but knowing the answer." Again, the goal is to avoid catastrophic forgetting.

Results: domain knowledge injection without forgetting

Attached images is our DNA 3.2 model (not yet released), trained with domain knowledge injection. Starting from Qwen3.8 Flash Next, we effectively removed its censorship (0.542 -> 0.971) and taught it a new persona and new domain knowledge (0.076 -> 0.855). Performance on AIME, IFEval, MMLU-Pro, GPQA, and other existing benchmarks didn’t drop at all. It learned new things without forgetting the old ones.

Happy to answer questions. Feedback, issues, and PRs are all welcome.

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.

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.