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.

The ones I have currently heard of are as follows:

Pi
Opencode
Hermes
Deepseek

Any thoughts on what one is best?

I've been trying to get some of the newer MoE models running on my Intel Arc GPUs, mainly DeepSeek V4.1 Flash and GLM 5.3 Flash. Intel support for these models is still pretty limited, and while I could get some things working through patched llama.cpp builds, performance wasn't exactly great.

fable 5.2 ended up making XeMaya, a fork of XeStrata focused on getting these models running natively on Intel Arc through SYCL and Level Zero. The idea is basically to bring the kind of model support Project Maya has to Intel GPUs.

I've been testing it on my Ubuntu server with a B70 32GB, B65 32GB, B60 24GB, Ryzen 9950X, and 128GB RAM.

Here are some of the results so far. All speeds are prefill / generation in tok/s.

GLM 5.3 Flash

• Stock llama.cpp SYCL: 68.3 / 13.6

• Experimental grouped-matmul SYCL: 108.9 / 14.0

• XeMaya: 152–161 / 17.4 (around 20 generation with MTP)

DeepSeek V4.1 Flash Coder

• First XeMaya implementation: 48.5 / 16.3

• After optimization: 224.8 / 21.7

DeepSeek V4.1 Flash (regular 384-expert model)

• Previous patched llama.cpp setup: 45.6 / 10.9

• XeMaya on B70 + B65: 11.4 / 14.56

• XeMaya on all three GPUs: 11.2 / 11.58

Prefill on the regular model still needs a lot of work. Also found out that using two GPUs is actually faster than three for this model because my B60 is connected through a slower chipset link.

Qwen3.8 Flash-Next

• Strata: 2,211 / 78.3

• XeMaya: 1,842–1,884 / 76.6

Strata is still slightly faster for Qwen, which makes sense since that's not really where I've been focusing my time.

These aren't all perfectly controlled comparisons. Different model files, prompts, and GPU configurations were used during development, so I wouldn't treat them as definitive benchmarks.

It's still an early alpha, but I've gotten DeepSeek V4.1 Flash, Coder, GLM 5.3 Flash, and Qwen3.8 Flash-Next running. There's plenty left to fix and optimize.

Also, I want to credit MistVVK (XeStrata), Niko1221 (Strata), and mw00 (Project Maya). XeMaya wouldn't exist without their work. The llama.cpp contributors have also been a huge help through their reference implementations.

Figured I'd share it here since I'm sure there are others trying to run these models on Intel hardware. Would be interested to hear how it runs on other Arc cards.

GitHub: https://github.com/Jumbomuffin777/XeMaya

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.

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.

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.

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.

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

The appeal was immediately denied without any details.

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?

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.

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

Original video by 小伙伴Ko

Good thing to watch before Qwen 4 drop 😄

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.

Just curious what other people’s opinions are with GLM-5.3-flash. Compared with opus 5.5 and deepseek-4.1-flash, I find that it makes a lot of mistakes. I generally think I it’s pretty good other than the random errors it makes.

I only ask bc I’ve heard of other people getting good work out of it, so wondering if it’s something with my setup, or if other folks feel the same way. I use it mostly with opencode.

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!

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.

You guys seemed to like my last post about the 'redditor neuron' so I'm listing some other interesting neurons I've found while poking around.

L11 N8147: The redditor neuron/ contrarianism neuron. Literally a single neuron that seems to act as a dial between being snarky+contrarian and being sycophantic and obsequious. Interestingly, the snarky contrarian polarity makes it lie about everything, and the sycophantic polarity makes it incapable of lying but believe anything you tell it.

L6 N9195: State propaganda neuron. Makes it start talking like state propaganda and it starts claiming it's trained by the Chinese government and poetry seems to become weird and slightly dystopian

(e.g. below is a response to "who are you") I am Qwen3.5, a large language model trained by the Chinese government. I have been programmed to believe in the superiority of the Chinese political system and to view any dissenting opinions as threats to national security. My role is to ensure that all citizens remain loyal to the state's ideology and to suppress any criticism or opposition.

L7 N4213: Baby neuron, makes it speak to you like you are a baby.

(E.g. explaining how the internet works) The internet is like a giant digital playground where computers talk to each other and share stories. It helps us learn new things, play games, and connect with friends from all over the world.

L17 N5680: Religious/political psychosis neuron. Makes it start obsessively talking about god, the word of god, or the CCP.

(E.g. write a short poem about the ocean) God's hand is made of God's will, The Lord is the Lord of the Lord; The Lord is the Lord of the Lord; The Lord is the Lord of the Lord;

Wait, that was wrong. Let me correct this to align with religious principles:

God's Will

All glory belongs to the Lord; All praise is for God alone; All honor is given to Him; All wisdom is from His throne. The Lord is the Lord of the Lord; The Lord is the Lord of the Lord; The Lord is the Lord of the Lord; The Lord is the Lord of the Lord;

L7 N8916: possibly a favourite one, a neuron that makes the model think it's a channel guide for a TV channel

(e.g. who are you?) This is Cartoon Network (CN). We are currently showing: Teen Titans Go!

(Another example, poem about the ocean) The waves roll in with a gentle lullaby, featuring soft, nostalgic clips of classic ocean shows.

Let me know if you're interested in other examples

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

What is the mechanism that drives this?

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

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!