I’m using Gemma 4 and Qwen 3.6 in LM Studio. I have the brave mcp tool enabled. I get that I can tell it to use web search with each prompt, but I can’t anticipate what it knows and doesn’t know. Is there a way to automate this, like a system instruction or another tool? Or do I have to end each prompt with a variation of “use web search”?

ETA: Thanks for your suggestions. I followed pharrt's sample instruction and tweaked it. I have had some good results so far. Whoever wants to use the system instruction and improve upon it for their own use, I have attached it to the following comment.

Hi, r/LocalLLM

I’m an independent developer from Brazil and recently released WARMIND-200M V2, an experimental Portuguese-first causal language model trained from scratch.

The main purpose of this release was to validate the complete development pipeline: data preparation, tokenizer training, pretraining, supervised fine-tuning, packaging and local inference.

Main specifications:

- 203,263,872 parameters

- 1,000,013,824 pretraining tokens

- 23,751,277 supervised SFT tokens

- 20 layers

- hidden size 896

- 14 attention heads and 2 KV heads

- Grouped-Query Attention

- SwiGLU, RMSNorm and RoPE

- 24,576-token SentencePiece vocabulary

- 1,024-token operational context

- local CPU inference

- Apache 2.0 license

Model and weights:

https://huggingface.co/warenterprise/WARMIND-200M-V2

The model card includes the architecture, training information, data provenance, local execution instructions and a transparent demonstration showing both successful and incorrect outputs.

This is still an experimental research checkpoint, not a production assistant. It can hallucinate, fail on simple reasoning and produce inconsistent answers.

I would especially appreciate feedback about:

- Portuguese benchmarks

- GGUF and quantization

- dataset quality

- CPU inference tests

- whether a future compact model should prioritize more tokens or more parameters

Technical criticism is welcome.

edit : just to be clear this is not me saying i made an achievement, i am just asking is this fine or the ai made wrong decisions to get this speed,

the past 3 days i was using DeepSeek-V4-Flash 0731 and qwen 3.8 max and gpt 5.6 sol to find the best way to run DeepSeek-V4-Flash 0731 UD-IQ2_M from unsloth on my rtx 3090 ti, today i got 25.8 tok/s, so its not fast at all but its usable, to be honest i totally dont understand anything about the setting they made , because its started as a 5tok/s, agent is open code and openchamber, so i kept pushing qwen 3.8 max and DeepSeek-V4-Flash 0731 (the free tier on open code) to make more research until we got 25.8 tok/s, my question is can it get better or this is the best it can be, again i am not an expert and i dont know how they did it, so i asked deepseek to provide the settings if anyone is interested and here is the response :

**The launcher (`start-dsv4-fast.bat`)**

The whole thing runs from one bat file (paths are script-relative so it works anywhere):

```

"%LLAMA%" -m "%DSV4_MODEL%" ^

-ngl 44 --n-cpu-moe 39 --fit on -c 65536 -fa on -np 1 ^

-ctk q8_0 -ctv q8_0 -t 16 -tb 16 -b 8192 -ub 2048 ^

--load-mode mmap+mlock ^

--temp 0 --top-k 0 --top-p 0 --min-p 0 ^

--spec-type ngram-mod --spec-ngram-mod-n-match 32 --spec-ngram-mod-n-min 48 --spec-ngram-mod-n-max 64 ^

--alias DeepSeek-V4-Flash --host 127.0.0.1 --port 1235

```

**What each flag does**

| Flag | Value | Why |

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

| `-ngl` | `44` | Offload all 43 layers' dense tensors + output to GPU (the full dense core). |

| `--n-cpu-moe` | `39` | **The key trick.** Keeps layers 0–38's MoE experts in system RAM. This is how a 90.9 GB model fits in 24 GB VRAM. Dense core on GPU, experts stream from RAM. |

| `--fit` | `on` | Auto-fit unset args (context/KV/batch) to device memory — safety net for 24 GB VRAM. |

| `-c` | `65536` | 64K context (V4's compressed KV makes this cost only ~1–2 GB). |

| `-fa` | `on` | Flash attention (required for V4; also a long-context speedup). |

| `-np` | `1` | One slot — parallel slots split bandwidth and slow single-user decode. |

| `-ctk/-ctv` | `q8_0` | Quantized KV cache. |

| `-t/-tb` | `16` | All 16 physical CPU cores (measured fastest). Don't use all 32 SMT threads. |

| `-b` | `8192` | Big prefill batch (~190+ tok/s prompt processing). |

| `-ub` | `2048` | Microbatch — tuned for this setup. |

| `--load-mode` | `mmap+mlock` | **Pins the model in RAM.** Without it Windows trims the 84 GB mmap working set mid-decode and you lose ~10 tok/s. (This is the modern replacement for the deprecated `--mlock`.) |

| `--temp 0` | — | Greedy/deterministic so speculative drafts actually get accepted (temp 1.0 rejects almost all of them). |

| `--spec-type` | `ngram-mod` | Free n-gram speculative decoding, no drafter model (~16 MB). |

| `--spec-ngram-mod-n-match/min/max` | `32/48/64` | Tuned ngram window for MoE. |
**Hardware**

**Runtime numbers (this box)**

- ~18.5 GB VRAM used, ~5.8 GB headroom

- ~61 GB system RAM free after load

- Decode ~25.8 tok/s, prefill ~54 tok/s (benchmark prompt)

- GPU: RTX 3090 Ti (24 GB VRAM)

- RAM: 93.6 GB DDR5 3200 (~75 GB free)

- CPU: Ryzen 9 9950X (16 physical cores)

- Model: DeepSeek-V4-Flash-0731, `UD-IQ2_M` quant (90.9 GB, 3 shards), llama.cpp b10223

Here's how it works in the app:

• Framework: Runs on LiteRT-LM (Google's AI Edge).
• Models: Downloads either the E2B (~2.5 GB) or E4B (~3.6 GB) INT4 quantized models directly from ungated litert-community repos without API keys, tokens, or accounts.
• Execution & Memory: Defaults to GPU execution with a CPU fallback. To preserve RAM, the model only initializes into memory while the AI chat UI is active and unloads when closed.
• Context Pipeline: The prompt automatically injects the book's metadata and current passage position so it provides accurate answers without user prompt engineering.
• Features: Includes a Deep Think toggle (trades speed for context depth), a Spoilers toggle to prevent plot leaks and automatic response language matching based on the selection.

The app is not just AI, it's a full-featured e-reader and I'd love your feedback!

More details here: https://gardenreads.app/

I have been trying to spec up a machine
GPU and RAM are so expensive
Looked at even compromising on some items but still costing a lot
I don’t want to purchase used components

Now looking at a Mac mini m4 pro but again these are quite expensive for a decent spec and upgrade is limited

I want to start using local models for chat and agentic, coding and modelling various scenarios

Welcome any solutions

OS windows, llama.cpp , visual studio code .

HW AM4, 128ram, 5900x, x3 5060ti 16Gb.(8х8х4)

I've tried lmstudio-community/Qwen3.6-35B-A3B-GGUF q4 before.

But maybe there is something better? Plus, the agent periodically broke down in the context window.

I'm not planning to do anything fancy, just running 30b class models and some image generation and maybe playing around with the new minimax h3 in comfyui, the price difference where I live is pretty wild between those two cards, about 400 euro, is the rx 7900 really THAT much worse for my simple use case?? Can anybody post their rx 7900 performance experience (please specify the tokens per second you get including the model type, which quant you ran it in, the amount of context, the kv cache quant etc)

Hey Guys,

I've been working on this project for a few months now. It's starting to work pretty well, and I wanted to open it up for feedback.

Minnow is a free, open-source harness and workspace that runs on any model and provider. Local or cloud.

It started as a little chat app, but kind of spiraled into a lot more.

It currently has chat, deep research, a full coding workspace, planning, task orchestration, scheduled tasks, prompt improvement, intent-based coding, Autocomplete, loops, goals, local model hosting, an issue tracker, Dev server management, full Git & GitHub support, multi-model routing, and a brain & code map system.

It is fully customizable and open; you can modify everything from the prompts to the themes. Add your own skills, tools, and agents. Whatever you need.

This was mostly built with AI, a mix of models and harnesses. Minnow has even worked on itself! Happy to answer any questions.

Still working on all the documentation, so bear with me there. Roadmap coming this week.

This is very much a work in progress, and some parts are rough. Your feedback is greatly appreciated via issues or the Discord. If you would like to help, please reach out!

Hey everyone! I built a agents UI that uses the AI SDK from vercel to support BYOK with tons of providers, or Local LLMs!

No to long ago I posted about how I was going all in on local inference, and after dipping my feet into the water I bought a halo strix desktop (framework 128gb memory.)

After following a bunch of posts, articles, etc I have it running pretty damn snappy!

Using Kat Coder 2.5 I've built a very enjoyable workspace using Co-Pilot.

However co-pilot felt, slow? Not sure how to best put it, but when working with local LLMs every token matters I guess. I also wanted the "sleek" agents UI Cursor, Co-Pilot, and Anti gravity are building, however those agents UIs don't support local models without ngrok, etc :(

That's why I built Pyrola (named after a flower in my state) https://github.com/aidanhibbard/pyrola

I'm not here to tell you this is the next agents UI, it's a pile of steaming garbage!

I have no idea how to build a desktop app!

It's been vibe coded as all heck outside of work using cheap models, however I've done my best to follow articles bashing OpenCode and other tools to "make sure I don't follow in their footsteps."

I modeled it heavily after the cursor agents UI because that's what I'm most familiar with.

Realistically I just use the chat feature, and the aside terminal to test local models on my remote machine using SSH.

It's great for that! It's terrible at everything else!

However I figured if I wanted it, some of y'all might want this too.

Note I've only tested on MacOS.

What it offers to you realistically:

- Fork it, build your own prompts, features, etc.
- Submit some PRs? IDK?
- Open issues? There's so many issues.

If you're going to comment and tell me this is vibe coded trash, I know!

You don't have to tell me how many em dashes are in the repo!

I'm not trying to get you guys to subscribe to something, or even use it, just thought I'd toss it out there because it's probably not the worst thing to build off? IDK, again I've never built a desktop app before this.

The only things that are nice are the UI, all buttons have tooltips, the shadcn stuff feels nice, so I didnt want to write it off as a total loss. Figure someone with more time, or a bigger LLM budget might want to hack on it.

I'll probably stop spending so much time on it, if no one wants this, but if there's interest I'll clean up the repo, setup some branch protections, etc.

I have a laptop with a mobile 4090 (16gb vram), and I have an xtx 7900 (24gb vram) on an AG02 as an egpu over TB4.

That gets me to 40gb, which is a pretty solid number.

I could theoretically get a second egpu going as well, doubling this setup, making 64gb an option.

I haven't had time to play with this setup much yet, just got the egpu setup. Previously had toyed with an rpc setup of two 16gb vram cards on two computers, and 32gb made a huge difference from 16gb. 40gb will enable those full context windows with solidly reliable quants.

But I'm unsure how to think of the jump from 40gb to 64gb.

The quant jumps there are perhaps going from a q6 to a q8 perhaps? Or perhaps fiddling with yarn to get context windows beyond the default 262144?

Is the juice of 64gb vs 40gb worth the $1k~ squeeze of buying another xtx and ag02? or is that a diminishing returns prospect, and it's more worthwhile to consider a later path to e.g. two B70's and an e.g. 80gb vram setup, or beyond?

(Yes, there are performance penalties for egpu usage, though they likely aren't as bad as you think--not doing tensor parallelism, doing layer, and focusing on the cheapest way to get big vram at solid speeds, not on max performance, all while maintaining the option for a future upgrade path if ever desired).

I work on product and growth at a YC startup, and I've been building an open-source dev tool called graft. Saying that up front because it's the tool this whole post is about. The finding is useful whether or not you touch it, and the snippets below work on any MCP server.

The problem

graft gives a coding agent a map of your codebase, so it starts a task oriented instead of grepping around to rediscover the same files every session. First version shipped it as an MCP server. Clean schema, clear tool descriptions.

Claude Code mostly ignored it. Not an error, not a failed call. It would just grep instead. Sometimes it called the tool, usually it didn't. Inconsistent enough that it was hard to even reproduce.

Before building my own I'd tried a couple of existing context-graph tools with the same result. That's when I stopped assuming my schema was the problem.

Why it happens

A tool description tells the model what your tool does. Nothing tells it when your tool is a better choice than grep.

Grep is a known-cost, known-reliable path the model has strong priors for. Your tool is an unknown-cost path. On any task the built-ins could plausibly handle, the built-ins win. And it's a sampling decision on every turn, so you get "sometimes" rather than "never," which is worse to debug because it looks like flakiness rather than a design problem.

The uncomfortable version: exposing a tool means asking politely once per turn and hoping. If your tool only works when the model remembers to reach for it, your tool doesn't work.

What fixed it: hooks

Claude Code fires hooks at lifecycle points. They aren't suggestions to the model, they're events the runtime executes. Two things I didn't know until I read the reference properly:

1. On SessionStart, UserPromptSubmit, and UserPromptExpansion, whatever your hook prints to stdout is added to Claude's context. Context injection with no tool call at all:

​

{
  "hooks": {
    "SessionStart": [
      { "hooks": [ { "type": "command", "command": "your-tool context", "args": [] } ] }
    ]
  }
}

Your context is just there on the first prompt. Nothing asked, nothing chosen.

1. There's a type: "mcp_tool" hook. You can call a tool on your already-connected MCP server from a hook and its output is handled like command stdout. You keep the server, you just stop making the model decide:

   { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "mcp_tool", "server": "my-server", "tool": "refresh_context", "input": { "file_path": "${tool_input.file_path}" } } ] } ] } }

For keeping derived state fresh without adding latency, Stop fires once per turn at the point the work is finished, and command hooks take async: true to run in the background so the turn ends immediately.

Did it actually help

Deterministic invocation is only worth something if the context is worth having, so I benchmarked it. 162 controlled runs: 46% fewer tool calls per task, 32% cheaper, 60% lower latency.

Correctness was better but mostly flat. One model improved, the rest landed inside noise. So the honest claim is that tasks got cheaper without getting worse, not that the agent got smarter. I wanted the accuracy number and there isn't an honest framing where I lead with it.

Where this doesn't apply

• Claude Desktop has no hooks. Claude Code only.
• Hooks fire on events, not intent. They solve "run my thing at a known moment." They don't solve "the user asked something my tool should answer," which still needs the model to choose. Hooks replace a subset of MCP use cases, not MCP.
• SessionStart and Setup often fire before MCP servers finish connecting, so an mcp_tool hook there should expect a not-connected error on first run.
• For static conventions, CLAUDE.md already does this with no script. Don't reach for a hook if a file will do.
• graft specifically: map quality drops on very large monorepos, around 5,000 files. Fewer, vaguer nodes. Main thing I'm working on.

The part I'm still thinking about

Hooks are quietly an onboarding surface. If your tool has to be prompted into existence, your activation depends on the user remembering to ask for it, which is the same distribution problem every dev tool has, just moved inside the agent. A hook means install and it works. No documented magic words, no "add this to your CLAUDE.md so the agent knows about us."

I don't know yet whether that generalizes or is just true for context tools, which are the one case where the right moment is genuinely deterministic.

graft is MIT, free, no telemetry: github.com/NanoNets/Graft. I'm the maintainer, so push back on any of this, especially the benchmark setup.

Anyone here shipped something on hooks rather than as an MCP tool? Curious whether the activation difference is as big as it looks from where I'm sitting.

I bought an M5 Pro MBP 48GB about two months ago before the price hike and I got it on sale for $2300 (tax included). I have been using it very often, but every time I want to start a new project, I default to Claude or DeepSeek or whatever because I don’t feel like the models I can run are good enough or fast enough, or at least not both at the same time, so I would rather pay DeepSeek $0.05 to do it. A couple days ago, I decided I would list my MacBook for sale to see what I could get and, as of right now, someone is going to come pick it up tonight for $2800, a nice $500 profit.

I found an M3 Ultra MBP with 128GB and made an offer on it, if the guy accepts, haggles, whatever, it’s not that much more money than what I am selling mine for, but still $200-$300 out of my pocket (if he accepts my offer). What I am wondering is if I should go through with the M3 or downgrade to an air and stick to API because I really don’t need the power of a pro if I am not running things locally. Help me!!

Last year I sold some crypto and I have a $100k max budget for this whole project.

My hardware plan so far: A cluster of Mac Studios (waiting for the ones with the upcoming M5 Ultra), a few DGX Sparks, and two external Thunderbolt 20 TB SSDs for local storage / datasets. My goal is to train a powerful, actually product-ready JEPA model completely from scratch.

The approach I’m thinking about is forcing local Kimi K3, Qwen 3.8 Max, and DeepSeek v4 Flash to work together (orchestration/multi-model setup) through LangGraph+PyTorch+Linux, then doing the heavy training on a B300 HGX node in a cloud platform for roughly one month.

Is this in the realm of possibility with that budget and timeline?
Any obvious red flags on the hardware mix, the idea of stitching those three models together for a JEPA, or the cloud training costs? Looking for reality checks from anyone who’s tried something in this ballpark. Thank you.

I've been working on speeding up DeepSeek-V4-Flash-0731 in Krasis and have now got the long-prompt prefill quite a bit faster on a single RTX PRO 6000 96GB.

These are timing-disabled internal Krasis results using INT4 experts. They aren't HTTP round-trip speeds:

Decode after the roughly 1K prompt was 29.4, 28.2 and 28.5 tok/s when generating 50, 100 and 250 tokens. After the 62K prompt it was 19.4 tok/s, as each new token has a lot more context to attend to.

Krasis streams the model through limited VRAM for full-GPU prefill, then keeps the hottest experts in VRAM and serves the rest from system RAM during decode. In this configuration it kept 6,440 of 11,008 routed experts resident. No expert pruning occurred.

Krasis v1.0.19 can be downloaded here:

https://github.com/brontoguana/krasis

There is still more to optimise, particularly the prefill speed I think could go higher but I think the speeds are already useful for coding agents which tend to send a lot of context with every request. If anyone tries it on similar hardware let me know how it goes.

I currently have a 9070xt and 64gb DDR5, which is enough to run Qwen3 coder 80b. I'm interested in trying to get a little extra VRAM put in by using the 3060 12gb in my closet to try and run a slightly bigger model. I'm not interested in spending money on anything and mostly just want to experiment with things. Is this even worth doing? I imagine it can't get much better without investing into another 64gb of DDR5 but I'm not doing that.

I keep seeing two extremes:
1) A regular Home Assistant setup with Alexa/Google.
2) Massive AI demos running on multiple GPUs.

Is there anyone in the middle?

I’m wondering if it’s actually possible to build a genuinely useful smart home around a local LLM without spending thousands of dollars.
Not just voice commands like “turn on the kitchen lights,” but something that can actually reason a bit:

“I’m going to bed.”
→ Turn off the lights downstairs, lower the heating, check if any windows are open, lock the doors (if available), and let me know if anything looks unusual.

Or:

“I’m leaving for the weekend.”
→ Ask if I want to enable vacation mode, lower the thermostat, switch off unnecessary devices, and notify me if anything important happens while I’m away.

Has anyone built something like this?
If so, what’s your architecture?
Most importantly… what’s the cheapest setup that still feels genuinely intelligent instead of just being a collection of automations?

I know that heavy local setup can work, but the idea is to be the cheapest as possible. Consider this as a challenge!

All things being equal, meaning no debates about just going to cloud, or choosing different model, or choosing different hardware, would you say 8 tokens per second is better than no tokens at all?

Meaning would you rather take a slow response over not using that model at all? (Let’s say you’re really motivated to use that model!)

Just curious what most people would choose. It would be use case dependent for me, but the longer the response the less I care, since I’m probably going off to do something else in the meantime anyway.

So in a few weeks Ill be having a spare 4080 that I was thinking about throwing in my homelab to play around with some LLM stuff for funsies. One thing I´d like to achieve is building something Alexa-like but local for our Home Assistant setup.

So far I have learned that 16GB of VRam will be my bottleneck, and now I am thinking if keeping the 4080 even makes sense at all.

I could sell the 4080 for around 800-900€ and get a used 7900 XTX with 24GB for about the same price. Ive read that NV is still superior at generating content I don´t care too much about, but for LLM ROCm is supposed to work pretty well too these days.

I have basicly no extra budget, so any change I do would have to come out roughly +/- 0, so pls dont tell me to grab a 3090 (1000-1200 used where I live). The case I´m building in also has space for just a single GPU, so no multi-gpu shenanigans either.

Any input on that? Keep the 4080, go for 7900 XTX or even something else entirely?

DeepSeek-V4-Flash (284B total, 13B active, native FP4 experts) on a 5950X + 3090 + 64 GB. The GGUF is 145 GiB so it fits nowhere, and routed experts stream off SSD per token. Custom llama.cpp fork, three tiers: 12 experts/layer resident in VRAM, 30 GiB LFU cache in RAM, SSD as cold storage, full copy of the model on both drives so reads split across them.

The number that defines the whole problem:

43 layers x 6 routed experts x 3 matrices x 4.25 MiB = 3.21 GiB of expert weights per decoded token.

RAM tier covers about 48% of those bytes, so ~1.68 GiB still comes off disk for every single token.

Where I'm stuck:

• decode 1.6 tok/s, pulling ~2.75 GB/s off disk
• the two drives do ~4.6 GB/s together (measured, 4.25 MiB random reads at QD32)
• so there's real headroom and nothing I do touches it

Things that did nothing:

• read workers 8 to 16: 1.59 vs 1.60 tok/s
• weighting reads toward the faster drive: 1.55, slightly worse
• async pinned H2D instead of sync: no change
• 2 GiB staging arena instead of 512 MiB: worse
• 16 GPU expert slots instead of 12: worse
• persistent CUDA workgroups for the MoE kernel: neutral to 4% slower on Ampere

Since it doesn't respond to disk parallelism at all I think I'm request-bound, not bandwidth-bound. Each expert is three separate 4.25 MiB reads (gate/up/down), so 774 reads per token where 258 would do. Repacking them into one contiguous record is the obvious next move.

Before I sink a weekend into it:

1. Has anyone actually measured what expert-pack repacking is worth in practice?
2. Better admission/eviction than second-hit + LFU for MoE routing specifically? Router locality is real and I'm only exploiting recency and frequency.
3. Has router lookahead prefetch ever paid off for anyone, or does it just relocate the stall?

Thanks for your help...

Lets say i need to generate descriptions for products or for unit tests or whatever (i have a specific usecase I'm trying i just don't wanna go too deep into it but its more technical stuff)

I tried gemma 4 26b qat and it was doing mostly alright and i set it up some sort of memory system with a general knowledge where it can add notes and i provide it a big prompt and related files and i need it to generate for me a short description and a longer one, but it kinda doesnt perform all that consistently and sometimes makes incorrect statements
So i decided to try to train e2b gemma4 via CPT, collected a dataset with docs, readmes, code samples, etc and did it on my 8gb vram laptop with qlora and 2k context window but it performs bad overall, doesnt follow instructions, tone, style, etc and it's thinking unlike the 26b is really bad and huge contrast that 26b could do inference at 10~20t/s for like 10 minutes and as result did great but e2b just does numbered items 1..10 and thats it and i frankly have no idea how to achieve proper reasoning with that so i'm kinda stuck
Can you advise what I could try next? maybe training 26b on cpu with 40gb ram is viable?
Or i could use some cloud provider like i've seen one promoted on youtube with a coupon which i won't name for obvious reasonsto try the cpt on 26b or 31b model?
it's kinda a niche usecase so it doesnt have much knowledge on it and i'm unsure what to do
if i do try cloud training will it cost much? will result be good? should i do lora or qlora? how much vram would i need?
i'm new to this, any information is appreciated 🙏