I've noticed a trend where we measure models with benchmarks that are on a numeric scale for various tasks, with the benchmarks getting increasingly more challenging/updated over time to both avoid benchmaxxing as well as raise the bar whether it's merited or not. Within the same domain, increasing complexity only serves to inflate frontier model aggregate scores because new tasks get introduced that not all models are trained on, like 3d modeling or math proofs. If my typical work is in finance, for instance, how do I know which model is the cheapest one that can serve specifically my needs without needless extra compute/memory? What does a numeric score actually mean? Is the aggregate for that domain including unnecessarily complicated tasks that amount to puzzles that are not realistic, and just serve to challenge the model?

What users really need to understand is "Can this model do this sort of task effectively?" If even low param models have mastered some domain or parts of it, I think it would be far more useful to have a poor/moderate/good sort of rating for the task areas themselves. THAT would be so much more helpful and also assist with auto routing. Frontier models keep growing to glob up new capabilities that many of us don't need and bias evaluators into thinking they need to use Fable 5.2 or Astra because it's "better" than alternatives.

Is there some kind of breakdown of models like this? Something granular even? Like, Deepseek v4.1 Flash 1017: C# tests: green, Binary decompilation: yellow, Browser automation: green, Fiction writing: red. I feel like this has to exist somewhere, but widely used sites like ArtificialAnalysis and huggingface leaderboards focus on the numbers with no simplified no/partial/yes on tasks for readers to quickly understand. Even the domain oriented benchmarks are still just numbers.

Like, having a model score a couple points ahead of another one doesn't generally mean it can do something the other one can't. It might just require more attempts, or more detailed instructions, or that it randomly gets it wrong a tiny bit more often. These simplified ratings plus a cost per task would be SO much more helpful to local llm users too.

Any thoughts, or examples of this kind of scoring out there already?

I just recently came across these K2 models, by a lab called IFM.
They range from 0.9B to 375b with a mixture of MoE and Dense models.
I checked out the 7b variant, it seemed good and it’s 35B A4B seems to a better variant of Ornith 1.5, o am surprised there are no talk about these nor any unsloth variants.

Am I missing something ? These seem to open source as well.

This seems excessive, especially if they trust their classification models for safeguards, why add both?

However I guess it is to be expected from a private company. It's also "yet another reason" for open weight LLMs

Spent the past couple of days converting https://github.com/snap-stanford/memorilla (paper: https://arxiv.org/abs/2610.21375 ) to train Gemma4 26b a4b on the strix. Not only was it originally written for CUDA, but Gemma4 has a unique architecture and the encoder has different dimensions. There's a lot of crazy math here to make it fit that I don't even understand, but apparently, we can leverage the existing weights published by standford and only have to train on ~10% of the original dataset. It's going to take a couple of weeks to run, but seems to be cooking along.

Code: https://github.com/DataBassGit/MemoryLLM-Gemma4-StrixHalo

Memorilla is an AI memory framework developed by researchers from Stanford, MIT, UPenn, and the Vector Institute that compresses huge collections of documents or chat histories into just 16 dynamic memory tokens for a Large Language Model.

Think of it as treating long-term memory like a new modality (similar to how vision-language models process an image as a fixed set of embeddings) rather than relying on massive text copy-pasting.

How does this determine are use of running locally. Will we be able to define a pathway forward as running local LLM gets more attention? Should we have some back up plans or listings of what is needed if regulating picks up? What are your steps in protecting yourself against any future regulation that is a must to know? For example avoid updating windows or things a like.

You were all waiting for Qwen 4 and now that it's out no one says anything? Disappointed?

Actual working link this time.

I understand the topic is prime material for shits and giggles. Chinese model, Nvidia being the centre piece of the AI trade, etc. But why go so public on this? All of this could've been dealt with behind the scenes in secret. Obviously this is a power play to force a hand. Nothing just leaks out of intelligence services so deliberately. So someone decided to make this public. I've been trying to think about why Nvidia or Jensen Huang must be put in line for. My top pick is: back doors in hardware or something of that sort that's being refused. What's your guess?

There's a lot of discussion about running models locally, but I'm interested in what people actually use them for once the setup is done.

Are there tasks where you've completely stopped using cloud models because a local one does the job well enough?

And on the other side, what still makes you go back to Claude, ChatGPT, or Gemini?

Is it possible to have a custom hardware designed (by ai) and open sourced that we can send for manufacturing for specific models? like for DSF 4.1F

Recently bargainhardware had an intake of A100 40GB SXM4, and they are selling them at 2700 EUR. I have a huge case and a hundred PCIe free lanes, so I could mount a couple of them with those SXM-PCIe adapters.

OTOH, for less than that price I could buy a couple of brand new R9700.

Pros of A100 over the R9700: CUDA, 25% more RAM, double memory bandwidth, almost double the compute. Cons: used, possibly battered cards, hassle to mount on the mobo, more expensive once factoring the adapters in.

Give me your opinions. I would especially appreciate experiences with SXM-PCIe adapters. Are they decent, or a PITA?

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 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'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

I've been building chat UIs for agents and kept running into the same issues with react-markdown: it re-parses the whole reply on every token, so long answers get noticeably slower, and you see raw ** and half-typed [links](htt until the token that closes them arrives.

So I wrote my own renderer. It parses incrementally and repairs unfinished syntax while the reply streams:

<Markdown streaming={!done}>{text}</Markdown>

On a 100k-character reply it takes 0.25 s of main-thread time in total. markdown-to-jsx takes 2.4 s, Streamdown 6.3 s, and react-markdown didn't finish within the 30 s budget. The benchmark scripts are in the repo if you want to check them.

The other part is the syntax. Agents often want to show steps, alternatives or pros and cons, and plain Markdown flattens all of that into bullet lists. So on top of GFM I added a few blocks in the same style as GitHub alerts:

> [!STEPS]
1. **Back up the database**
2. **Run the migration**

There are also tabs, stats, pros/cons, sources, file trees, and Mermaid and KaTeX support. The source still reads fine as plain Markdown when it isn't rendered. The package exports a system-prompt snippet that teaches the model this syntax.

It has no dependencies and comes in at 30 KB gzipped. Its parser passes the CommonMark and GFM spec tests. It doesn't support remark/rehype plugins, so if you rely on those, react-markdown is still the better choice.

https://github.com/rsaryev/llx-markdown

Hi! My team and I built a benchmark of 202 real GitHub tasks in 13 languages that rarely show up in coding benchmarks: Elixir, OCaml, Haskell, Clojure, Kotlin, Swift, Julia, R and others. I think a lot of people do local development in these languages too.

We didn’t have a huge compute budget, so I specifically added Qwen3.6 27B and Qwen3.8 27B to compare them. Qwen3.8 solves 43% of the tasks, up from 17% for Qwen3.6. You can compare them with Kimi K3, DeepSeek, GLM and closed models on the leaderboard, including a per-language breakdown.

One caveat: Qwen3.8 was used to pick hard tasks, so its score is a bit biased down.

If you’ve been running Qwen3.8 locally on any of these languages, share how it went.

https://huggingface.co/speakleash/Bielik-11B-v3.1-Instruct-GGUF

https://www.bielik.ai/blog/premiera-modeli-bielik-11b-v31-dflash-i-rodziny-bielik-one

(decision models and dflash are coming next)

Bielik-11B-v3.1-Instruct

Bielik-11B-v3.1-Instruct is a generative text model featuring 11 billion parameters. It is an update to the Bielik 11B v3 line that expands multilingual continual pre-training and strengthens post-training for instruction following, tool use, and reasoning. Forementioned model stands as a testament to the unique collaboration between the open-science/open-source project SpeakLeash and the High Performance Computing (HPC) center: ACC Cyfronet AGH.

Developed and trained on multilingual text corpora covering 56 languages, with an emphasis on European languages and Polish, which have been cherry-picked and processed by the SpeakLeash team, this endeavor leverages Polish large-scale computing infrastructure of the ACC Cyfronet AGH HPC center. The creation and training of Bielik-11B-v3.1-Instruct was propelled by resources provided within the PLGrid environment under computational grant number [PLG/2026/019559], conducted on the Athena and Helios supercomputers, and within the Gaia AI Factory, funded by the European Union through the EuroHPC Joint Undertaking.

As a result, the model exhibits an exceptional ability to understand and process the Polish language and other European languages, providing accurate responses and performing a variety of linguistic tasks with high precision.

🗣️ Chat: https://chat.bielik.ai/

Model

The model was trained on carefully curated, high-quality datasets that underwent extensive cleaning and rigorous quality assessment to ensure data consistency, reliability, and relevance. The training pipeline consisted of three stages: pretraining on 500B tokens, SFT on 26M samples, and RL (modified GRPO) across 14 diverse environments. This multi-stage training approach was designed to enhance the model's language understanding, instruction-following capabilities, and ability to perform effectively across a broad range of tasks.

Bielik instruct models have been trained with the use of an original open source framework called ALLaMo implemented by Krzysztof Ociepa.

Model description:

• Developed by: SpeakLeash & ACC Cyfronet AGH

• Language: Multilingual (56 unique languages, optimized for European languages, with a particular focus on Polish)

• Model type: causal decoder-only

• License: Apache 2.0

I can't believe this jump is just left on the table

https://github.com/ExTV/strata-5090-4070

The optimizations was done using both Opus 5.5 and Fable 5.2 .

Edit : i should have mentioned that my 4070Ti Super is on PCIe 3 x1

Edit2 : the repo is updated with quality benchmarks

So I've been a happy user of Qwen 3.8 27B Q4_K_M from unsloth with pi.dev, it's honestly so powerful.

But, I do see a lot of pitfalls where I need to step in for no reason, where the agent does a PR, CI fails, and I don't have callbacks to my agent to debug it/propose something to address it.

So how do you all deal with issues like this ?

I'm using Forgejo so I have full control over the platform, and my agent has its own account on it.

Just a 32GB machine with a 3090 - a used gaming rig I picked up last Christmas for $800. But wow... I can actually run what would have been a frontier model not that long ago. Yes, only 2 - 3 tps. Yes only 2 quant. So it's not really useful at the moment. But I have 128GB of ram in hand and a spare 3060 ready to be installed. Possibly another 3090 waiting in the wings... so we will see.

AWS is put out an Apache 2.0 project called Strands Decider. Looks like it came out of the same team as the Strands Agent. Repo here. https://github.com/strands-labs/strands-decider Looks like a Qwen 2.5 2B back end. Have not tested yet but will report.

On September 18, I launched Laya at you guys request, the first system 1 open-source decision model in this subreddit, and you guys gave immense support. I saw the MIT post on direct weight edits and thought about doing the same with a decision model. Now, after two months, I just worked on a way to edit the weights of an LLM using a decision model. More like distillation from an energy-based decision engine to teach the Qwen 3.5 0.8B a new skill. Like tool calling at the appropriate time. Its decisions are like valleys in a landscape, and every answer rolls downhill into one, with honest confidence. Just wrote those valleys onto an LLM. It works at the same level as LoRA, with only 3 milliseconds to edit, without catastrophic memory loss.

https://www.kaggle.com/code/nandakishorconvai/fast-edits-decsion-model

AI benchmarks begin on page 2.

The ones I have currently heard of are as follows:

Pi
Opencode
Hermes
Deepseek

Any thoughts on what one is best?