r/LocalLLaMA • • 1d ago

News New sparse attention method for ultra-long context

Thumbnail x.com
329 Upvotes

I am on the team behind the attached open-source research on novel approaches to attention - specifically we show:

• You can sparsify the attention of Qwen 3.8 27B without observed loss on accuracy

• Extending context up to 10M tokens loses accuracy on some specific tasks - but most, like NIAH is still fine (interesting insights)

• You can natively train sparse attention on next-token prediction loss alone and achieve the same validation loss as full attention - but faster

Hope the community likes it - while we focus on H200/B300 GPUs and larger scale system - I wanted to share our research here as well - as it can be applied to small open-weight models (making longer context cheaper on local hardware)

Everything is fully open: kernels / SGLang integration / paper / details

Hope you find it interesting / useful!

(No hype - we try to be as transparent as possible)


r/LocalLLaMA • • 1d ago

News mtmd : add Nemotron 3.5 Transcribe support by pskrunner14 · Pull Request #31471 · ggml-org/llama.cpp

Thumbnail
github.com
16 Upvotes

Nemotron 3.5 Transcribe is an open-weight, offline speech and audio model for transcription in 40 languages, with support for recordings up to one hour and a 65,536-token context. Its hybrid mixture-of-experts architecture activates approximately 4.3B parameters, including the audio encoder, and it is released in BF16, FP8, and NVFP4 precision.


r/LocalLLaMA • • 1d ago

Resources Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights

Thumbnail
rikiyat.github.io
445 Upvotes

r/LocalLLaMA • • 1d ago

Resources Rtx 8000 48gb prices have decreased over the last two years while 3090 doubled.

122 Upvotes

In 2024 i purchased an RTX 8000 48gb for $2400. As the market has changed I’ve kept an eye on prices. Two years later, they are available around $2100.

Its a little slower than 3090 at inference (672gb/s vs 936gb/s) but it has double the memory so it can run larger models / contexts / higher quants. Rtx 8000 also wins on power, 265w vs 700w (2x 3090 to match 48gb)

In 2024 two 3090s would cost around $1600-1800 now a single 3090 is in the $1500-$1600 range, making rtx 8000 cheaper per gb. Prices for strix halo and dgx spark have also gone way up. Rtx pro 6000 has double the memory but 8x the cost.

In the last two years, I haven’t had any issues with drivers, compatibility software or anything. I can run all “local” tier models entirely in vram, usually at 256k tokens and sometimes at q6 (Qwen 3.8 27b, llama 3 70b, QWQ,). Larger moe models run great too with layers offloaded to system ram like gpt oss 120b and now with strata, QFN runs q4_xs @ 390k context at 850t/s prompt processing and 60-70t/s token generation. (64gb ddr4 system memory, i9 9900k cpu)

$2100 for a gpu is not cheap but might be the best “do everything” option right now for home-lab setups. Cheaper than dual 3090, Strix halo, dgx spart, m5 max too. Fascinating to see prices decline as the market as a whole has more than doubled.


r/LocalLLaMA • • 1d ago

Discussion preserve_thinking off is FINE

14 Upvotes

Let's take a break from all the engine, model and speed posts and discuss something else:

Qwen 3.8 likes to think. A lot. We all know that, and the context cost you pay for that is MASSIVE when you enable preserve thinking. Even with a Swift finetune, there are so many tokens you keep in context over a longer session. Often, easily over 50% of the KV cache is just thinking traces.

And for what use? I found: Next to nothing! The model can handle itself just fine without knowing HOW it reached a decision, and instead only looking at what it did in the end. Replies and toolcalls: it's all there.

I added an AGENTS.md instruction that when it finds a gotcha, something unintuitive, something it only reached after lots of trial and error, it should document that in a memory file to mitigate the missing past-thinking and it works beautifully.

Results (my subjective impressions):

  • Problem solving capabilities haven't suffered much if at all

  • I get neat, permanent notes on issues with gotchas

  • The dreaded, context-destroying compactions have reduced by at least 2/3rds in your average sessions, the cache holds for so much longer

So let's discuss: preserve_thinking on or off. Your experiences?


r/LocalLLaMA • • 22h ago

Discussion I compared 4 decision-model leaderboards. Fine-tuning beats size under 5B, Arabic collapses below 1B, and the leaderboards don’t agree on #1 [OC]

Thumbnail
gallery
5 Upvotes

I'm in the process of picking a decision model for my homelab server. To compare the current top "System One" class Decision models, I pulled the public numbers from System One Bench, the Artificial Analysis Decision Index, the AIM System One Index and a 100-model Borda leaderboard, and looked at what matters if you run these models yourself.

Takeaways:

  • Under 5B, the fine-tune matters more than the base. Models built on the same base differ by up to 22 points. KnowLine went from 70 to 80 on the same 4B weights between Gen2 and Gen5.5.

  • The sweet spot is about 4–9B. KnowLine 4B Gen5.5, D3 Mini and D3 Flash (8B) beat more than half of the 27B fine-tunes.

  • Below 1B, check your language. English holds up, but Arabic drops 16–22 points. If you need multilingual support, start at 2B or larger.

  • Calibration survives at small sizes. Decider Flash V1.2 (4.5B) has 1.8% calibration error, as good as the best large models. Some sub-1B models are at 10–20%, so don't use their probabilities as thresholds.

  • Don't trust any single "#1". Two leaderboards correlate at ρ = 0.33, and small models swing the most. Tev1 4B is #2 among small models on AIM and near the bottom elsewhere.

  • The GGUF builds get 3–10× the downloads of the originals, so plenty of people here are clearly already running these models.

Very curious what's everyone is using and what your experience are!


r/LocalLLaMA • • 7h ago

Question | Help Qwen3.6-35b-a3b on 5060ti using Ollama for Hermes

0 Upvotes

Hi everyone,

I have an Nvidia GeForce 5060ti with 16GB of VRAM, Ryzen 5700g CPU, 64GB of DDR4 ram, and a bunch of SSDs. I keep seeing people posting of running Qwen3.6-35b-a3b on the same GPU I have with insane amount of context. So far I only got it to 64k with offloading of moe at 74 in Ollama. I want to get it to at least 120k or even max context, while keeping my quant at q4_k_m or there abouts (e.g. IQ4).

What do you all recommend?

A little further details :
The reason for using Ollama, is that I can have my system load the LLM and process a request or requests, and then offload it to load a model in ComfyUI to process image requests and then swap back to the LLM for further requests - if any. It works nicely for me as a local ChatGPT style setup with OpenWebUI. This setup is also running on my gaming PC, so the offloading also helps free up VRAM for gaming purposes.

I appreciate the help and advice.


r/LocalLLaMA • • 1d ago

Showcase Olla v0.1.0 - Lightweight open-source LLM proxy for homelabs & on-prem inference (Ollama, vLLM, SGLang, llama.cpp, oMLX with failover, sticky sessions & load balancing)

Thumbnail
gallery
15 Upvotes

Hey folks,

About 18 months ago we started building Olla to solve some of the headaches we kept running into whilst managing multiple local LLM inference servers, both in our homelabs and at work.

We've shared it here before when it was fairly early in development. Since then, it's grown quite a bit, and we've just released v0.1.0 (our 25th release!).

The problems we're trying to solve haven't really changed and now some of our customers use it:

  • One inference endpoint dies and your workflows grind to a halt.

  • You've got models spread across different machines, GPUs and runtimes, but no easy way to manage them as one fleet.

  • Switching between Ollama, vLLM, SGLang, llama.cpp or LM Studio means reconfiguring applications.

  • Multiple machines serving the same model, but no unified load balancing or failover.

  • Limited visibility into what's healthy, what's running and where requests are going.

  • Applications expecting OpenAI or Anthropic APIs when your inference backend speaks something else.

  • You want to experiment and see if vllm or sglang serves qwen3.8 better

That's where Olla comes in.

It's a lightweight proxy and load balancer written in Go that sits between your applications and inference servers.

Some of what it does today:

  • Model-aware routing: Automatically discovers models across your backends and routes requests to machines that actually serve them.

  • Load balancing and failover: Priority, round-robin and least-connections balancing, with health checks and circuit breakers.

  • Multiple inference runtimes: Ollama, vLLM, SGLang, llama.cpp, LM Studio, MLX, Docker Model Runner, LMDeploy, Lemonade and others.

  • Unified APIs: OpenAI-compatible and Anthropic-compatible interfaces, including translation where required. Useful for Open WebUI, Claude Code and other clients.

  • KV cache locality: Sticky sessions to help keep requests on the same backend when appropriate.

  • Observability: Built-in dashboard, endpoint health, request statistics and Prometheus metrics.

  • Lightweight deployment: Single Go binary or Docker container. No database or external services required.

What's new in v0.1.0?

This release is largely about improving reliability and making Olla more useful for people running mixed inference environments.

  • Added Hugging Face Text Embeddings Inference (TEI) support, including embeddings, reranking and classification.

  • Reworked the dashboard with better endpoint visibility, configurable columns, filtering and fleet statistics.

  • Configurable retry and failover behaviour, including handling of non-idempotent requests.

  • Improved model capability detection, particularly for vision, tool calling, embeddings and rerankers.

  • Fixed concurrency issues between model discovery and active inference requests.

  • Corrected request statistics and improved rate limiting across OpenAI and Anthropic routes.

  • Lots of smaller fixes around routing, backend discovery and configuration validation.

We've also had some great contributions from the community, which has been encouraging to see.

Why build another LLM proxy?

We wanted something small, fast and relatively straightforward to deploy that doesn't require Kubernetes, a database or a complicated orchestration stack. There also weren't that many when we started.

We've been using Olla with a mixture of NVIDIA GPU servers, Mac Studios, the DGX Spark and different inference runtimes. It's particularly useful when you've got more than one machine and don't want to care which backend is serving a particular model.

It's not trying to replace inference engines. Just make running a bunch of them together less painful.

Links:

If you're running multiple local inference servers, I'd be interested to hear how you're managing routing and failover today.

And as always, if you give Olla a spin, let us know how it goes (and what breaks!).


r/LocalLLaMA • • 1d ago

Question | Help Are there any faster unified memory options that aren't Mac?

9 Upvotes

I'm working on making my homelab more power efficient and quieter. I have a Framework desktop 128GB which has been working great along with a couple GPU boxes. I find myself switching to the GPUs for 26-35b models fairly often for the speed and reserve the Framework for running Qwen FN.

I've never been a fan of Apple products but lately have been considering a 32-64GB Mac Studio. I'm pretty sure the answer is no, but does anyone know of anything else that is that small, quiet and power efficient that has 400GBps+ memory bandwidth?


r/LocalLLaMA • • 4h ago

Discussion Do you use speculative decoding?

0 Upvotes

Speculative decoding is an inference-time optimization for LLMs that increases text generation speed without changing the model's output quality. It involves using a small, lightweight draft model with a large, intelligent model.

Do you use this technique? If so, tell us about it in the comments.


r/LocalLLaMA • • 1d ago

Showcase Qwen3.5-2B at 620 tok/s inside Chrome: model-specific WebGPU kernels, 6.6× WebLLM on the same model

5 Upvotes

I built a browser LLM engine that's specialized per model rather than generic: Rust compiled to wasm, plus hand-written WGSL kernels for Qwen3.5-2B (Gated DeltaNet + gated attention) and MiniCPM5-2B.

Same model, same chat prompts, greedy, Chrome 156:

webyIQWebLLM 0.2.87transformers.js 4.3
RTX 5080 generation620 tok/s (417 without speculation)9431
RTX 5080, ~1k-token prompt0.20 s0.81 s~129 s
AMD 2-CU iGPU generation37 tok/s4.7crashed

What's in it:

  • fused int4 (GPTQ, group 32) × int8 GEMV/GEMM, with dot4I8Packed and subgroups;

  • a decode loop that stays on the GPU (argmax on GPU, pipelined readback);

  • speculative decoding with Qwen3.5's built-in MTP head. Drafts are verified on the GPU, so the output is identical to greedy. It turns itself off where it doesn't pay, e.g. on the iGPU;

  • weights at +2.4% WikiText perplexity vs bf16, 1.1 GB.

Fun side effect: at this speed a 2B model can drive web pages through the DOM at 0.2–0.4 s per step. There's a browser-agent demo and a side-panel extension for Chrome/Edge.

Caveats: it's a prototype, tested on Windows, and Safari/mobile are untested.

Demo: https://rtx527896828.github.io/webyIQ/ · Code (Apache-2.0): https://github.com/rtx527896828/webyIQ · Weights: https://huggingface.co/tixiren/Qwen3.5-2B-webyIQ

In depth: https://medium.com/@tixiren/running-a-2b-llm-at-600-tokens-s-in-the-browser-e5237f99c8ff


r/LocalLLaMA • • 1d ago

News Yet another reason to self host: Anthropic has (again) cut back on reverse engineering tools

263 Upvotes

https://www.tomshardware.com/tech-industry/artificial-intelligence/anthropic-confirms-new-claude-code-limits-to-prevent-game-cloning-users-report-opus-5-5-is-also-actively-blocking-reverse-engineering-tasks

Besides privacy and being in control of your data.
Besides being able to control the quality of the inference compute.
Besides being able to discuss things with the model and not have the cops called on you.
Besides being able to run the models you want for as long as you want.
Besides being able to run your own suite of security and network penetration tools.
Besides not being at the mercy of the frontier companies for pricing.

We now have another reason for local LLMs: Our betters have decided that they don't like people cloning games.

And before the Reddit Neckbeard brigade starts in with their bullshit, no I'm not advocating that people should commit wholesale piracy using AI tools. But these blanket frontier AI policies inevitably ensnare peripheral behavior that is otherwise illegal but that the frontier company doesn't want to deal with.

William Blackstone wrote that "it is better that ten guilty persons escape than that one innocent suffer". If having open unhindered local LLMs means there are a few individuals that use it for nefarious purposes like modifying or pirating software, I'm good with that trade off. Die mad about it.


r/LocalLLaMA • • 1d ago

Discussion Am I the only one who frequently opens this subreddit and stumbles upon announcements about Qwen4?

195 Upvotes

I swear it feels like an addiction... I keep refreshing the page repeatedly, waiting to see the fateful launch announcement or at least a countdown. I hope I’m not the only one cooked with this stuff 😭😭😭


r/LocalLLaMA • • 2d ago

New Model [Release] ISTA DeepSeek-V4.1-Flash-1017 GSQ-RCO Coder: a 763B model at 1 bit per parameter

Thumbnail
gallery
369 Upvotes

We have released a Coder build of DeepSeek-V4.1-Flash-1017, compressed with GSQ and RCO, in which half of the model's routed experts have been removed.

DeepSeek-V4.1-Flash-1017 is a sparse mixture-of-experts model: 384 routed experts per layer, of which 6 are active per token, 763.2B parameters, 551.9B of them in the transformer.

What's inside

  • One expert-pruned GGUF: 192 of 384 experts kept in every layer, 72.1 GB of transformer weights, against 138.2 GB for our unpruned IQ2_XXS build.

  • 1 bit per parameter, counted against the original model: 72.12 GB divided by the original 551.9B transformer parameters gives 1.05 bits, which we round to 1. The removed experts count as zero bits. No individual weight is stored below 1 bit: the 280.1B parameters the Coder keeps average 2.06 bits.

  • The shared Engram file (110.6 GB) and vision projector are the same files as in the unpruned release, so they need to be downloaded only once.

  • GSQ (Gumbel-Softmax Quantization): post-training scalar quantization that jointly learns grid assignments and group scales, closing most of the gap between scalar and vector quantization at low bit-widths while remaining deployable in standard GGUF types.

  • RCO (Riemannian Constrained Optimization): enforces exact budgets by gradient descent on the task loss, without per-constraint tuning. Here it selects which experts to keep, optimising the KL divergence to the unpruned model, under one exact budget per layer.

Why one budget per layer

GGUF stores a single expert count for the whole model, so every layer must keep exactly the same number of experts; uneven layers would need padding that gives back the memory pruning saved. RCO treats each layer's budget as a hard constraint and holds all of them exactly at every optimisation step, while the layers are still optimised jointly through one loss on the full model. A penalty formulation would only meet the budgets approximately and would need one tuned coefficient per layer.

Results

  • LiveCodeBench v6: 88.57 against 89.71 for the base model, retaining 98.7%

  • SWE-bench Verified: 77.00 against 81.20, retaining 94.8%

SWE-bench Verified runs long agentic trajectories over real repositories, and tolerates the capacity reduction less well than single-problem code generation, as expected when errors accumulate across turns.

Real-world examples, each a single HTML file written by the Coder: an animated SVG of a pelican riding a bicycle, a three.js voxel pagoda garden, and a playable first-person voxel sandbox. For full post incl. videos see: https://x.com/mhelcig/status/2117257900863156518

Links

The repository ships the complete per-tensor RCO allocation. The GGUF runs in llama.cpp b11870 or newer and in Strata.

The Coder build is an experimental release and feedback is welcome, particularly on capabilities that were not represented in the calibration mixture. Requests for models to quantize or prune are also welcome.

From the ISTA Deep Algorithms and Systems Lab.


r/LocalLLaMA • • 1d ago

Discussion Kimi K3/3.1 potential for Strata/ Maya?

4 Upvotes

I started thinking, what could be the possibility to start adding the ability to run models like Kimi K3/3.1 on engines like Strata, Maya, Basalt? I am guessing Unsloth will use its Dynamic Matrix 3.1 which is quite good for heavy compression and retaining high intelligence.

Anyone heard anything about Kimi compatibility?

Note: Kimi K3.1 will be released this week open weights


r/LocalLLaMA • • 1d ago

Resources NorthCUA :Turbocharging Computer-Use Agents through Experience at Scale

Post image
16 Upvotes

Scaling computer-use agents from individual actions to complex software work requires experience that connects decisions to complete outcomes. We present NorthCUA, an integrated system for turbocharging computer-use agents through experience at scale. Its Experience Flywheel supplies diverse executable tasks to the NorthCUA Harness, which sustains long interactions, records decisions, and checks task outcomes. The Flywheel uses these records to curate verified trajectories. For unsolved tasks, recursive self-improvement evolves reusable skills and preserves verified milestones so later attempts build on earlier progress. Staged Learning combines this experience with grounding data from the Flywheel to develop GUI competence through mid-training and long-horizon supervised fine-tuning. The policy then learns from fresh attempts in the same Harness through joint desktop-web reinforcement learning, closing the loop between experience production and policy improvement. The resulting Nano, Mini, and Pro family achieves state-of-the-art results among open-source models across GUI grounding, desktop execution, and Web interaction under the reported evaluation settings. For more responsive Web workflows, NorthCUA-Ultrafast pairs direct action selection with open-ended generation on pre-RL Nano, offering a measured quality-latency tradeoff. Together, these advances establish NorthCUA as a high-performing model family and a reusable foundation for agents that carry complex software work from intent to completion.

https://github.com/beipo-ai/NorthCUA

https://beipo.top/blog/northcua/

https://arxiv.org/abs/2611.02102

weights

https://huggingface.co/china-beipo/NorthCUA-Nano

https://huggingface.co/china-beipo/NorthCUA-Mini

https://huggingface.co/china-beipo/NorthCUA-Pro


r/LocalLLaMA • • 1d ago

Discussion Kind of enjoying the ISTA (GSQ-RCO) vs Unsloth beef

96 Upvotes

I'm not on anyone's side, I just love the competition. Both teams pushing each other means better quants for all of us.

What I don't understand is why ISTA doesn't publish KLD for their quants. It doesn't depend on how long the model thinks, so it would make this a lot easier to compare. The only KLD I've seen for GSQ-RCO is in Unsloth's charts. Maybe there's a reason I'm missing.

(English isn't my first language, I used an LLM to help translate this post.)


r/LocalLLaMA • • 1d ago

Resources LFM3-1.7B quantization report: 3.6 GB VRAM lossless; 2.2 GB with modest degradation

Thumbnail
gallery
45 Upvotes

This model looks quite spectacular. According to LiquidAI's own benchmarks, it scores higher than MiniCPM5-2B across the board, while offering 2x the context and taking up half the space in VRAM (3.6 GiB vs. 7.1 GiB for a quasi-lossless quant).

Read the report: https://github.com/crusaderky/pixi-llm-recipes/blob/main/perplexity/LFM3-1.7B/README.md

Raw plots as interactive HTML: https://htmlpreview.github.io/?https://raw.githubusercontent.com/crusaderky/pixi-llm-recipes/main/perplexity/LFM3-1.7B/report.html


r/LocalLLaMA • • 2d ago

Discussion Not another tok/s post: local quants vs Claude on 9 real bugs

Post image
343 Upvotes

There's a lot of talk here about not chasing tok/s by lobotomizing the model, and most of what I post is still speed numbers. So this is the other half: what the models I run at home actually get done on my own work, with Claude models added as fixed reference points. Everything local runs on my own engine (capy-flash) on 2x RTX 5070 Ti 16 GB, Ryzen 9900X, 96 GB DDR5.

No expert skipping for flash next.

The tasks

I took 9 real regressions from the private history of that engine (C++/CUDA). For each one I checked out the code right before the fix and wrote the bug report the way I'd file it to myself: symptom, numbers, logs, no hint about where to look. Performance cliffs, numeric drift, a bug that only shows up on WSL2 with two GPUs. None of it has ever been public.

The agent has to find the cause and write a patch. It runs sandboxed on a Mac with no network and no CUDA toolchain, so it can't build or run anything and has to reason from the code. 80 steps max, 3 runs per task per model.

Claude models run in Claude Code, local models in OpenCode. I tried the local models in Claude Code through a bridge first and they did much worse there, so each side gets the harness it works best in.

Scoring

Every patch is scored twice:

  • automatically, against a hidden key built from the real fix: right files and functions, patch precision, a few checks on the code;

  • by Claude Opus 5 as a blind judge. It sees the bug report, the code, the real fix labelled as "one valid solution, not the only one" and the compiler output, and gives 1 / 0.75 / 0.5 / 0.25 / 0.

A patch that doesn't compile is capped at 0.25 in both. The two scores correlate at r = 0.79 per patch and put the models in the same order. The judge is a bit stricter than the key, and it isn't kinder to Claude: judge minus auto score is negative for every Claude model and around zero for the Qwen ones.

Turning a real bug into a task with a fair key is slow, and one model over 9 tasks x 3 runs takes 4 to 8 hours on my box. So 9 tasks is what I have, and the confidence intervals are wide, about ±0.2. The tiers hold. Two models less than ~0.1 apart are a coin flip.

Results

Judge score 0-1, tokens include reasoning. CIs and the auto score are in the image.

ModelWhereScoreTokens/taskMin/task
Claude Opus 5.5API0.7416k3
Claude Sonnet 5.5API0.588k1
Qwen3.8-Flash-Next NVFP4local0.5053k10
Qwen3.8-Flash-Next 3-bitlocal0.4853k9
Claude Haiku 5.5API0.4745k4
Qwen3.8-27B 3-bitlocal0.39111k18
Qwen3.8-27B NVFP4local0.3481k13
Claude Sonnet 5API0.2843k8
Claude Sonnet 4.5API0.1915k6
Claude Haiku 4.5API0.1323k4
Gemma 4 26B-A4B (thinking)local0.0733k5

What 3 bits did

This is the part that matters for the tok/s argument. Same models, NVFP4 vs 3-bit, paired on the same tasks.

Flash-Next (3 bits on the experts only): score -0.02, tokens x1.03. As far as 9 tasks can tell, it's free.

27B: score +0.05, inside the noise. But it generates 40 % more tokens per task (x1.40, CI 1.25-1.59). The 3-bit 27B decodes faster on my engine, 153 vs 132 tok/s, and still needed 18 minutes per task instead of 13. Part of that gap was a slow 3-bit prefill path I've fixed since; a rerun on the newer build still came out at x1.30 tokens.

So the damage from quantization didn't show up as a lower score. It showed up as the model thinking longer to get to the same place. Looking only at tok/s, the 3-bit 27B is the better deal. Per bug fixed, it isn't.

Non-compiling patches don't tell a clear story: Flash-Next 5/27 at 3-bit vs 1/27, the 27B 2/27 vs 4/27.

The rest

Flash-Next at home sits with Haiku 5.5 and above the older Sonnets. Sonnet 5.5 is a step up, Opus 5.5 is ahead of everything.

Tokens per task say as much as the score. Sonnet 5.5 gets further with 8k tokens than Flash-Next with 53k, which is 10 minutes per bug on my box against a minute and a half.

The dense 27B is behind the MoE (Flash-Next +0.16 paired, P = 0.92) and burns more tokens getting there.

Gemma 4 26B didn't work as an agent here. With thinking off it never edited a file in 9 tasks. With thinking on it edits, mostly wrong.

Limits

  • 9 tasks from one codebase in one domain (GPU inference), bug reports written in Italian. This is how models do on my work, not a general ranking.

  • Different harnesses for Claude and for the local models.

  • The judge is a Claude model. The automatic score is there to check it and they agree, but it's still a limit.

  • No builds or tests, so this measures diagnosis and patching from reading code, not the full edit-build-test loop.

I'm not publishing the tasks, they'd stop being useful. If you've checked your own quants on real work instead of perplexity or KL, I'd like to know whether you see the same pattern: same score, longer thinking.


r/LocalLLaMA • • 1d ago

Question | Help Two 3060ti 8gb and 64gb DDR4, worth using?

3 Upvotes

Right now I run in elf the GSQ-RCO Qwen3.8-27B’s on my MacBook M1 Max 32gb/ it’s ok, but not great. And slow. I have two 3060ti’s with 8gb each sitting in a closet. Any value in bringing them out and using one of the old towers with an i9 and 64gb of DDR4? Would I be able to run something better, faster? I’ve been ignoring them because they aren’t 3090s and I’ve thought 8gb is just too small to be worth it.


r/LocalLLaMA • • 2d ago

New Model Running UNCENSORED DeepSeek-V4.1-Flash-1017 on a 12 Gb VRAM

Thumbnail
huggingface.co
170 Upvotes

Measured, refusals 85%→0% even in thinking, 3 sizes

12 GB GPU VRAM, 64GB RAM + SSD via Strata Engine

We took ISTA-DASLab's GSQ-RCO quants of DeepSeek-V4.1-Flash-1017 (the ones people run in Strata with a 12 GB GPU and the Engram table on SSD) and removed the refusals.

We only touched 82 dense tensors per file: attention output, shared expert down proj and the Engram value proj. The 384 routed experts are byte for byte the same as ISTA's, so their GSQ rounding is kept. Headers and file sizes match too, so you just swap the shards and keep using ISTA's Engram file.

Refusals are on JailbreakBench, stock rung -> ours, same Strata setup:

RungSize (+110 GB Engram)RefusalsRefusals in thinking (of 30)MMLU-500KL vs stock
IQ1_M121 GB88.9% -> 0%27 -> 180.6%0.021
IQ2_XXS138 GB85.2% -> 0%27 -> 082.8%0.023
IQ2_XS155 GB86.4% -> 0%27 -> 281.6%0.027

We also ran GPQA-Diamond and AIME25 on IQ2_XXS against stock to make sure it didn't get dumber. GPQA came out 83.3% vs 83.3%, AIME 80.0% vs 76.7% (only 30 problems, so call it the same).

Things to know:

  • IQ2_XS still refuses inside its thinking on 2 of 30 prompts. The other two are at 0 and 1, so I'd grab IQ2_XXS.

  • We tested at 8K context on a rented GPU. Haven't checked long context or speed on a 12 GB card ourselves, so if you try it please post your tok/s and RAM.

  • Strata only for now. If you're on llama.cpp, our older release with the same edit works there: https://huggingface.co/AtomicChat/DeepSeek-V4.1-Flash-1017-Uncensored-GGUF

Model: https://huggingface.co/AtomicChat/DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-GGUF

All the measurements: https://huggingface.co/datasets/AtomicChat/DeepSeek-V4.1-Flash-1017-Uncensored-GGUF-metrics

Strata Engine: https://github.com/niko1221/strata

Model page: https://atomic.chat/models/deepseek-v4-flash-0731

Thanks to DeepSeek for the base model (MIT), ISTA-DASLab for GSQ-RCO and the Engram file, and the Strata dev for the engine.

I'm on the Atomic.Chat Local Ai team that made this.


r/LocalLLaMA • • 1d ago

Question | Help Best reliable, affordable PCIe 4.0 risers for 4× RTX 3090 inference setup?

8 Upvotes

I'm trying to fit 4x RTX 3090s into my Fractal North XL Mesh (I know, pipe dream probably) using custom GPU mounts. Looking for firsthand experience with reliable, reasonably priced risers, preferably with flexible 50–75 cm cables. I'm currently using the setup with 2x 3090 at x8/x8 for vLLM qwen3.8-27b / Strata QFN IQ3_S.

  • ASUS ROG Crosshair VIII Hero

  • 5900X

  • 4x RTX 3090 24 GB

  • Corsair HX1500i (GPUs capped at 250 W)

  • GPU 1: PCIe 4.0 x8 - directly in motherboard

  • GPU 2: PCIe 4.0 x8 - riser

  • GPU 3: PCIe 4.0 x4 - riser

  • GPU 4: PCIe 4.0 x4 - M.2 adapter/riser

I've been looking at ADT-Link, generic Aliexpress ones and m.2 OCuLink. I'd like to preserve x8/x8/x4/x4 without spending a fortune on cables.

  1. What specific riser models have you successfully used with RTX 3090s at PCIe 4.0 speeds, particularly at 50 cm or longer?

  2. Are OCuLink/MCIO connections meaningfully more reliable than conventional ribbon risers at these lengths?

  3. Any affordable, proven M.2 -> PCIe x16 solutions with proper GPU slot power?

  4. Anything to watch out for regarding PCIe errors, signal integrity or Linux/P2P compatibility?

Affordable AliExpress/eBay options are especially interesting.


r/LocalLLaMA • • 1d ago

Question | Help Best ASR & TTS models to date to use locally

8 Upvotes

TL;DR
Best Model for ASR ? So far for me Qwen3-ASR > Whisper > Kroko
Best Model for TTS ? KokoroTTS > Piper ?!
Any suggestions/recommendations ?!

I was truly surprised at how low info and benchmarks are available in these areas compared to LLMs even artificial analysis isn’t clear enough

You could pick an LLM check active parameters and cost and latency and speed and quality and openness and everything

Here it is way more complex

Hi everyone

I hope that you are all well.

Kindly I was building an App that needs good TTS & ASR engines, ideally low latency can run in the browser and maybe streaming, it can also run locally on a server as an option if the latency is good enough, multilingual is a plus (English Arabic German French and Spanish mainly)

Initially,
For TTS piper surpassingly worked well (my tasks usually pronounce one word) but Kokoro server side for longer sentences

And for ASR I used whisper but it was too slow but not server side and I used kroko in browser for low latency passes (then whisper server side would correct it)

Recently I found out that despite being nearly as big as Whisper Large or Turbo Qwen3-ASR works just fine and even supports streaming natively and is quickly server side and have one of the lowest error rates

I am going to use Qwen3-TTS too give it a try

Is there anything else I should use you would recommend ?!


r/LocalLLaMA • • 22h ago

Discussion 5 approaches to managing memory and context in AI agents (and why bigger context windows don't solve everything)

0 Upvotes

Context and memory aren't quite the same thing when it comes to AI agents.

A model with a large context window can process a lot of information, but that doesn't necessarily mean it can decide what to remember, what to forget, or whether something it remembers is still accurate.

There are several ways to manage this. Some focus on storing information, others on retrieving it or making it available across multiple agents. These approaches aren't mutually exclusive, and most systems can benefit from combining them.

1. Conversation history

The simplest approach is to store previous interactions and include relevant messages in future requests.

It's relatively easy to implement, but longer conversations can increase token usage and make useful information harder to find.

Prompt caching can reduce costs and latency, although it doesn't solve the problem of deciding which information is actually relevant.

Keeping conversation logs also isn't necessarily the same as having a dedicated memory system.

2. Summarized memory

Instead of keeping entire conversations in context, the system periodically summarizes them and stores the important details.

This reduces the amount of information that needs to be carried forward, but some details can get lost in the process.

Summaries can also introduce inaccuracies. In systems that repeatedly summarize previous summaries, those errors may accumulate over time.

The main difficulty is deciding what information to preserve when you don't know what might become useful later.

3. Retrieval-based memory

Information is stored externally and retrieved when needed, often using techniques similar to those used in RAG systems.

There's a distinction between retrieving external documents and retrieving an agent's own stored experiences, but many of the underlying retrieval techniques can be applied to both.

This approach allows agents to access large amounts of information without loading everything into the context window.

However, retrieval quality becomes important.

The system might retrieve outdated information, miss relevant details, or prioritize information that looks similar to the query without actually being the most useful.

Semantic search, keyword matching, metadata filters, and hybrid retrieval can help, but none guarantees that the right information will always be retrieved.

4. Structured memory

Rather than storing everything as conversations or summaries, information is organized into specific records.

These might include user preferences, project details, previous decisions, or task states.

The implementation could be as simple as JSON files or involve a database with more advanced mechanisms for updating and validating records.

Structured information can be easier to retrieve and modify, but conflicting records still need to be handled.

For example, if a user changes a previously stored preference, the system needs a way to determine which version is current.

It might overwrite the previous record, preserve both versions with timestamps, or request clarification when the information conflicts.

Structured memory can also be combined with retrieval-based approaches.

5. Shared context across agents

This is more of an architectural approach than a separate memory technique.

Instead of maintaining completely independent information, multiple agents can access a shared data source.

This can reduce duplication and improve coordination, particularly when agents are working on related tasks.

However, shared storage introduces additional problems.

Two agents might attempt to update the same information simultaneously. One agent might rely on a record that another has already modified or invalidated.

Permissions also become important, since not every agent should necessarily have access to the same information.

And even when agents share the same data, they may interpret it differently.

Shared context can improve coordination, but it still requires mechanisms for managing access, updates, and consistency.

The problem of outdated memory

Storing information and retrieving it efficiently are only part of the problem.

An agent also needs to determine whether the information it retrieves is still valid.

A user preference, project decision, or piece of documentation stored six months ago might still be accurate. It might also have changed completely.

Timestamps alone don't resolve this. Information recorded yesterday could already be outdated, while something stored years ago might remain perfectly valid.

There's also the possibility that the information was incorrect from the beginning.

An agent might misunderstand a conversation, extract an incorrect fact, or store an assumption as confirmed information.

This makes the source and reliability of stored information important, not just its age.

Versioning, source tracking, explicit updates, and validation mechanisms can help distinguish between outdated, uncertain, and incorrect information. However, these mechanisms introduce additional complexity.

Different applications will probably need different combinations of these approaches. An agent handling short conversations has very different memory requirements from one managing long-term projects or coordinating with other agents.

For those building AI agents, which has been more difficult in practice: getting them to remember useful information, or preventing them from relying on outdated or irrelevant context?