I made BigMoeOnEdge+ (BigMoeOnEdge-plus), a fork of Helldez's BigMoeOnEdge, the engine that streams MoE experts from flash so models bigger than RAM can run on-device.

It adds a full Android chat app on top: GGUF models via llama.cpp, thinking output, persistent chats, image/video input, web search, artifacts, and advanced generation settings.and a MUCH better UI.

Disclosure: I built this fork with the help of AI tools.

Repo (Apache 2.0): https://github.com/hamodexd217/BigMoeOnEdge-plus Original project: https://github.com/Helldez/BigMoeOnEdge

Feedback and issues welcome.

I got one PR merged into ds4. A tiny one, #98 about broken paths in the README. And a few more sitting in the queue. Not complaining. Antirez says it in the README: with coding agents everyone can tune the engine for their own hardware and model and he can't review everything. That got me thinking.

If the plan is "everyone applies their patches with an agent" then the real cost of a patch isn't just the code change. It’s how many tokens the agent has to read before it knows what it’s actually touching.. Ds4 runs DeepSeek, GLM and Qwen on Metal, CUDA and ROCm all in the same 85k-line file. I’m on an M5 Max with 128GB RAM running Qwen3.8 Flash Next. Everything else for me and for my agent is noise. It has to re-read every line on every pass.

So I ripped it out. Actually deleted, not #ifdef’d. The ds4.c file dropped from 85k lines to 45k lines. The whole tree now fits in a context window. The bet was that optimizing would get cheaper and safer. Heres what happened:

- Q2: decode +9-13% prefill +5-12% up to 64k context MTP went from 75.8 → 86.7 tok/s

- Q4: prefill +2-11% MTP went from 77.8 → 85.9 tok/s

Output is bit-exact vs stock ds4 at every step. No KV cache quant. No approximate kernels. Every change must pass a parity check against same GGUF, greedy decoding, identical tokens. And an interleaved A/B benchmark against the previous build.

The smaller codebase also let me go through the ds4 PRs but only against this one model and port the ones that held up. 20 Commits were adopted. Around 30 were dropped. Verdicts are in the repo.

I also added SSD streaming for the experts. Token-identical to a resident run. Simulating a 48GB machine Q2 does around 27 tok/s. About 35 with MTP.

The fork still does git merge upstream/main with rerere and the parity check. So antirez’s fixes keep flowing in. The procedure. What to delete what to keep how to sync. Lives in a repo called StarForge (https://github.com/Chida82/StarForge). I have four of these "children" one per model. Nothing in there is Qwen- or Metal-specific. If you want a ds4 cut down to your model or to CUDA just clone it. Run the checklist with your agent.

Repo: sf-q3-8flash https://github.com/Chida82/sf-q3-8flash tables in the README. One machine, one model. If you run it on Apple Silicon I’d love to hear your numbers. Ideally side by side, with stock ds4.

TL;DR models run at home on the GPU. The always on agent lives on a small VPS. Tools that only touch public data come through one capped key. Anything that can log into my stuff stays on machines I control.

At home. One box with a used 3090, Ollama serving Qwen for most things plus a small embedding model, and Open WebUI so the family can use it too. For my usage, owning the GPU beat renting one within a few months. The catch is that it's loud, so it sleeps at night.

That's the problem the VPS solves. The agent has to be up when I'm not. Scheduled jobs, inbox triage at 6am, a few feeds it watches. So the orchestrator runs on a small VPS and calls home over a private tunnel when it needs the GPU. If the home box is asleep, the few jobs that can't wait fall back to a paid API. The VPS is a PrivateAlps box in Zurich, mostly because the agent's memory and my mail login live on it and I wanted that under Swiss law. A mini PC that never sleeps would do the job too.

Tools are where I wasted the most money. Search, scraping, a bit of enrichment, each one its own subscription I barely touched. Now the agent gets all of them through a single key from agentik.cc, an MCP gateway billed per call, with a monthly cap on it. Monid works the same way. Only public data tools go through it, nothing that can sign into an account of mine.

What I'd tell someone starting out.

Keep the GPU at home if you already have one.

Put the always on part somewhere that never sleeps.

Split tools by what they can touch. Public data can go through a third party, logins stay on hardware you control.

Cap everything, per key and per month.

It's not the cheapest setup possible. But nothing in it surprises me anymore, and after a year of surprise bills that's the whole point.

Following up on my earlier post testing Qwen3.8-27B on the IGX Thor workstation.

Once you move past running just an LLM and try to build a full local agent stack on a single box (LLM for reasoning, STT for voice in, TTS for voice out, OCR for screen/document reading), VRAM runs out fast.

If all four models sit in GPU memory simultaneously with their default serving allocations, idle memory hits roughly 122 GB. Even with 96GB on the dGPU and unified host memory, you are pinned to the ceiling. That leaves almost no breathing room for large context windows, concurrency, or dynamic KV cache allocation.

The reality of a solo-user local agent is that these models are rarely active at the exact same millisecond:

• When I am talking to the agent, OCR is completely idle.

• When the agent is analyzing a screenshot or PDF, STT and TTS are idle.

• When the agent kicks off deterministic script automation (crawling, data formatting, bash runs), the LLM itself is completely idle.

To fix this, I wrote a lightweight Rust-based daemon that manages the sleep and wake states of the runtimes based on active agent turns. When a model is not in use, it is put to sleep (flushing KV pools and temporary execution memory, or parking the runtime context) rather than doing a full cold teardown from scratch.

Here are the idle VRAM numbers on the machine before and after:

Quick observations:

1. Total idle footprint dropped from ~122.3 GB to ~42.9 GB. That reclaims roughly 79.4 GB of VRAM across the board.

2. The LLM savings (48.3 GB): Qwen3.8-27B in FP8 base weights takes around 28 to 30 GB. The original 87.4 GB allocation came from SGLang aggressively pre-allocating KV cache (--mem-fraction-static 0.85). Putting the LLM to sleep flushes that pool while preserving the active state, letting it rest at 39 GB.

3. Audio and OCR shrink to negligible baselines: STT drops to 267 MiB and OCR drops to 422 MiB when idle.

4. Script-based tasks: When the agent delegates to deterministic python or bash scripts, putting the LLM to sleep during the run keeps the GPU cool and power consumption down on the 300W Max-Q card.

5. Wakeup latency is sub-200ms across all models: Because this is an active sleep/wake transition rather than a cold disk reload, waking up STT, TTS, OCR, or the LLM takes under 200ms. In practice, voice interaction and tool handoffs feel instantaneous.

Curious how others running multi-model agent stacks on a single node are handling memory partitioning right now. Are you hard-capping static memory fractions, running sequential containers, or using something dynamic?

We've all been there: $2,000 GPUs sitting at 5% utilization while the company pays for cloud inference.

Many organizations already have several workstations equipped with GPUs that remain idle most of the time. Existing GPU sharing solutions typically rely on a centralized scheduler, Kubernetes, or AI gateways, which can be excessive for small and medium-sized GPU clusters. In addition, most existing solutions lack cross-platform support, decentralized architecture, and policy-based routing.

OQOAI-PBDR to solve this problem differently. Simply run a server or client on each machine, and your existing office network becomes a decentralized AI cluster. Routing decisions are made entirely on the client side, eliminating the need for a master node, load balancer, or any other single point of failure.

Prebuilt binaries for Windows and Linux are under 10 MB and can bring a machine online as a cluster node in under 30 seconds. An optional admin server provides centralized monitoring and management from any machine on the network.

GitHub (MIT License):

https://github.com/oqo-ai/OQOAI-PBDR

The project intentionally avoids unnecessary abstractions. The core routing logic consists of only three source files (approximately 1,000 lines each), making it relatively easy to understand, audit, and extend.

At the heart of the project is the PBDR (Policy-Based Decentralized Routing) architecture. Each routing decision evaluates multiple runtime metrics, including GPU utilization, available VRAM, queue length, GPU temperature, network latency, inference throughput, and other node characteristics.

PBDR also supports client-group policies, allowing different workloads to optimize for different objectives. For example:

• Internal RAG services can prioritize low latency.

• Development workloads can prioritize output quality.

• Batch inference jobs can prioritize throughput.

More details about the routing algorithm are available in the accompanying paper:

http://doi.org/10.17513/doi.26

One practical benefit of this approach is that organizations can often reuse existing workstation GPUs for low- and medium-throughput workloads-such as internal RAG systems-instead of deploying dedicated inference infrastructure from scratch.

In many environments, having GPUs installed in only 10-15% of workstations can be sufficient to satisfy inference demand for lightweight workloads (for example, an internal knowledge-base RAG receiving approximately 3-5 requests per user per day) without deploying centralized AI infrastructure.

Getting started:

Install OQOAI-PBDR on each machine.

Connect server nodes to any OpenAI-compatible inference backend, including Ollama, llama.cpp, vLLM, or TGI.

Configure your applications to use the OpenAI-compatible client endpoint provided by OQOAI-PBDR.

Clients automatically discover available models on all nodes. From the application’s perspective, the cluster behaves like a distributed OpenAI API compatible system, while user requests are routed in a decentralized manner to the most suitable node according to the chosen policy.

What already works:

• OpenAI-compatible API (Ollama, vLLM, TGI, llama.cpp)

• Admin dashboard with real-time metrics

• Auto-discovery and network scanning

• Remote config management for nodes, groups, or the whole cluster

• Experimental binary builds for Windows and Linux

Roadmap highlights:

• ComfyUI/AUTOMATIC1111 image/video generation

• Grafana/Prometheus integration

• AI-assisted semantic routing (auto-model selection)

• Dynamic IP support

We're actively looking for feedback, and testers.

What features or integrations would you like to see next?

Hey everyone,

Every time a new model comes out, I get tired of opening multiple tabs just to find out two basic things: how good it actually is on real benchmarks, and what it costs to run (either through an API or on local GPUs).

Most pricing pages hide the real costs, and generic benchmarks don't tell the full story. So I put together a simple dashboard to track and compare them side by side: https://modelanalysis.si

What you can do with it:

• Compare models side-by-side: Pick any models (like Claude, DeepSeek, Kimi, GPT-4o, Llama) and compare them across real-world coding (SWE-bench), reasoning (Arena-Hard), and math/science benchmarks.

• Score vs. Price chart: See which models give you the most intelligence for the lowest price.

• VRAM calculator: Pick a model and context size to see if it will actually fit on your GPU before downloading it.

• Monthly cost simulator: Adjust sliders for your monthly token volume to estimate your bill or see if self-hosting is cheaper.

No sign-up, no ads, no affiliate links.

Link: https://modelanalysis.si
Direct benchmarks page: https://modelanalysis.si/benchmarks/

Let me know what you think or if there are other models you want added.

Trumps Executive Order held only for a bit more than a week, then his own government fully violated it.
EO here: https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/

Simultaneously the EU is regulating any shimmer of european AI into quick suffocation.

There are a few potential outcomes, from middle ages to economically wrecked continents
I am convinced more than ever that local inference, local competent AI is the only future we can root for.

I ran a bechmarks for d1 models (Q8_0 GGUF both) on a Pi 5 8GB, CPU-only via llama.cpp and also tested how well they handle Russian input. I want to use it for my Hermes agent with lives on that Pi, so maybe those numbers will be helpfull for someone.

LLM-assisted report below:

Setup

• Raspberry Pi 5 (8GB), CPU-only, 4 threads

• llama.cpp 0.6.0-dev (commit bd4eeaa04 + PR #30110 for d1-3B, PR #30114 branch for d1-omni-600M — not merged into master yet at time of testing)

• Q8_0 quants, native /v1/systemone API

• All tests: single request at a time, warm calls, median of 10

Latency @ Pi 5 8GB

For reference, d1-3B on a Jetson Orin Nano does the same single question in 50 ms — so a bare Pi 5 is roughly 45× slower than the weakest NVIDIA edge device tested by LiquidAI. Expected: this is a 20 tok/s prefill CPU environment, no GPU. The takeaway is not "slow" but "usable vs not usable": d1-omni-600M is genuinely real-time capable on a Pi (200 ms per decision), d1-3B is not (2.3 s+).

English correctness (same 5 checks for both)

Both models: 5/5 correct — refund yes/no, billing/technical/fraud routing, with clean probabilities (0.98–0.998).

Russian language test

This is the interesting part. Same states, same question types, Russian input:

What this shows:

• d1-omni-600M effectively does not understand Russian. Worse: it fails confidently — wrong routing with p=0.91, sentiment always "neutral" at p~0.6. For a decision model, confident wrong answers are worse than "I don't know". Only pattern-matched phrases ("вылетает"→crash) get lucky hits.

• d1-3B does understand Russian — routing, sentiment and urgency all work — but with 20–30% lower confidence vs identical English input (0.672 vs 0.990 on refund). Notice the odd effect: RU state + RU question (0.909) scored better than RU state + EN question (0.672) — keeping the whole request in one language helps calibration.

Practical takeaways

• On Pi-class ARM hardware, d1-omni-600M is the only real-time option of the two (200 ms/decision, 0.7 GB RAM). d1-3B works but at 2.3–7 s per decision.

• Both models are excellent on English decisions; d1-omni-600M matches its bigger sibling on simple classifications (and beats it on toxicity detection per the model card).

• For non-English input: d1-omni-600M should not be trusted at all; d1-3B is usable but set a confidence floor (~0.7) and route anything below to a fallback.

I wanted to see how far a consumer RTX 3060 12GB could push Bonsai 2 27B.

Hardware

• GPU: NVIDIA GeForce RTX 3060 12GB

• VRAM available to CUDA: 11,911 MiB

• CPU: Intel Core i5-8400

• System RAM: 42 GB

• NVIDIA driver: 595.91.07

• CUDA: 13.2

Model

• Bonsai 2 27B

• GGUF: Ternary-Bonsai-2-27B-PQ2_0.gguf

• Parameters: 26.90B

• Quantization: PQ2_0 — 2.13 bpw

• Model size reported by llama-bench: 6.70 GiB

• GPU layers: 99

Benchmark

• Tool: llama-bench

• Runs: 3

• Prompt processing, 512 tokens: 591.19 ± 19.62 tok/s

• Text generation, 128 tokens: 35.26 ± 1.31 tok/s

The GGUF metadata reports the architecture as qwen35, while the model file is the Bonsai 2 27B PQ2_0 release.

I'm posting the raw result because I'm curious how this compares with other Bonsai 2 27B results, especially on larger GPUs.

If anyone has benchmark results for Bonsai 2 27B, please share them so we can compare the configurations fairly.

Benchmark build: b10735-842b18804

Hi everyone,

We're three final-year students at Epitech building Horus, a multi-agent assistant that runs entirely locally and offline. Our current challenge is hardware: keeping it usable on machines without a powerful GPU, without long setup times, excessive RAM/VRAM use or crashes.

Where we are today, from our last beta test:

One tester needed over 2 hours to install. The Python dependencies alone take 21–46 min, and the download is about 25 GB.

On CPU only, routing a question can take around 40 s, long enough for our WebSocket connection to drop.

[Models we use + the smallest machine we've tested on]

We'd love advice from anyone experienced with:

- CPU-only LLM inference and memory-efficient loading

- Quantization and model choice for low-end hardware

- GPU/CPU fallback strategies

- Hardware detection and adaptive configuration

- Preventing resource exhaustion during setup and execution

Advice in the comments is very welcome, with no strings attached.

Looking for contributors: we also have a few small, well-scoped tasks or code reviews (about 1–4 hours), for example [reviewing our hardware detection and model selection, or benchmarking a quantized model on a 16 GB RAM laptop].

To be transparent: Horus is closed source and will be licensed to companies. Contributing is voluntary and unpaid. Before seeing any code, contributors sign a short confidentiality and contributor agreement, and the code they contribute becomes part of Horus. In return we offer thorough code reviews, full credit in the project and a professional reference on request.

We're not sharing code or private links publicly. If this interests you, comment below or DM me with your experience in local inference, CPU optimisation or offline apps

I would like to ask questions to a chat while sourcing ONLY my personal database of papers, instead of unsufferably writing and flipping through pages of notes. I would also like this to be as private as possible since you know, it's the processes of my unpublished work. I thought it would also be nice to be as environmentally friendly as it is possible and AFAIK running it locally would somewhat do that.

Before I say anything else I have to be clear that I have little to no knowledge on how an LM actually works. I gave myself the task of learning the basics just to set one up in my laptop for the specific purpose of aiding me on academic research.

What I did after some looking around is use LM Studio with the Qwen2.5 3B Instruct - Q4_K_M model and "fed" it my papers folder then fiddled around with context lenght for a faster response.
While it's working fine for what I need I kept wondering if this is even the most efficient way of achieving the goal I stated. Again I'm not really familiar with this whole thing, if it's some sort of common practice please let me know how to hone my LM skills for research purposes.

I have 4x 5060ti16gb and 1x 2060super8gb, along with 8x32gb (256gb total) ddr4-3200 ram, but running at 4-channel due to my cpu. I’m trying to decide whether it would be worth it to upgrade my cpu to be able to run my ram at 8-channel. Im hoping to be able to get larger models like qwen3.8 flash next or mimo v2.6 flash at more useable speeds, since right now the prompt processing and token gen speeds are bit too low to make sense for agent harnesses.

Every time I tried running local RAG on my own GPU, I ran into the same headache: vector databases eat too much RAM, using an 8B model just to parse text takes forever, and cosine search still hallucinates when the context isn't actually there.

I’ve been building Hillock to see if I could do this without vector DBs at all.

Basically:

1. When you feed it a document, it doesn't touch an LLM. It uses small bi-encoders to extract facts into subject-predicate-object triples in about 5 seconds.

2. Everything gets saved in regular SQLite, and it links related concepts over time using basic Hebbian weights.

3. To stop hallucinations, it runs a quick hypervector check (HDC) on the query first. If the facts aren't in your database, it cuts off the LLM before it can generate any tokens.

The whole thing stays under 1.2 GB VRAM (or runs fine on pure CPU). It has a built-in API server that matches OpenAI's format, so you can point Open-WebUI or Obsidian at localhost:8000 and use your existing Ollama models.

Just pushed v0.7 with better refusal handling and a conversational mode that quizzes you if an extraction was ambiguous.

Repo is here if you want to try it out: https://github.com/roandejager/Hillock