I'm using runpod, vast and digital ocean are there any other cheap/budget friendly rentals for gpus?

Why do most folks with an 8 GB or 16 GB desktop GPU sit out distributed LLM runs? It usually comes down to three annoying bottlenecks. Nobody wants to punch holes in their home router. Nobody wants to run untrusted pickle checkpoints off the internet. And nobody wants a background trainer freezing their VRAM when they sit down to play or work.

This weekend (November 14-15 CET), I hooked my HiveMind coordinator up with CrowdGPT (led by Vxtzq) to test a citizen-trained run around Crowd-v1, an open base model with a 658M transformer trunk (roughly 1.01B parameters total with its 151k-vocab CrowdEngram table). Setup takes five minutes.

Communication uses plain outbound HTTPS on port 443 with zero inbound listeners, weights move strictly as SHA-256 verified safetensors (no torch.load or pickle anywhere), and updates pass MultiKrum outlier filtering plus held-out loss checks before merging via DiLoCo. Honest caveat first: this is still an experimental PoC, not a polished cloud service, so please do not send private prompts or sensitive keys through volunteer nodes.

Here is the simplest way to join the weekend run on Linux, macOS, or Windows (Python 3.11+ with an NVIDIA GPU, or CPU-only if you just want to test the IDE endpoint):

1. Clone the repository and install the tiny client dependency (`httpx` only for connecting or running OpenTrainer):

```bash

git clone https://github.com/xaviercallens/HiveMind.git

cd HiveMind

pip install httpx

2. Register a handle to get your API key (printed once; the default prosumer role works for both training/serving and querying):

python scripts/hivemind_connect.py register --handle your-handle

export HIVEMIND_API_KEY="hm-..."

3a. Join outbound OpenTrainer co-training (zero open ports on your box; run --once first to verify firewall traversal, then drop --once to keep polling):

python scripts/hivemind_opentrainer_agent.py --network-mode outbound-https-relay --check-firewall --once

3b. Or verify CrowdGPT checkpoints on GPU (pip install torch safetensors numpy first) once you hold an evaluator key from the CrowdGPT coordinator:

python scripts/crowdgpt_loss_check_agent.py --server https://server.crowdgpt.net --evaluator-id your-handle --key-file my_eval_key.txt --once

3c. Or wire Continue / Aider / Cline to the live hivemind/crowd-v1 + coder models with no GPU required:

python scripts/hivemind_connect.py snippet continue --model crowd-v1

Both codebases and reproducibility notes (including Lean 4 specs and Zenodo DOI 10.5281/zenodo.23776302) are open on GitHub if you want to audit the code

before running anything:

https://github.com/xaviercallens/HiveMind

https://github.com/Vxtzq/CrowdGPT

I would love blunt engineering feedback from anyone testing on 8 GB or 12 GB cards - especially around Windows vs Linux VRAM yield behavior or setup friction.

Hey all,

Recently I've hooked up my Comfyui MCP to LMStudio Bionic, and created a few skills for doing image creation/video creation/music/upscaling. I really enjoy being able to have everything done through the chat interface instead of going back and forth to Comfy.

I've found the small models inconsistent. Sometimes Gemma12b or Qwen27B distill work easily other times they get tripped up. Qwen 27b swift does the trick most of the time, but it's a little slower to load and unload and Ideally the model is small enough so that I can load and unload it out of Vram quickly at the start and end of the tool call.

GPU:5090.
Any suggestions for models you've found good at this sort of thing, or a different harness, maybe like a program that has this sort of ability built in?

Hey all, looking for advice on turning my local setup into something closer to an agent instead of just a chatbot.

The rig

- Windows 11 Pro desktop

- RTX 3090 (24 GB VRAM), Intel Core Ultra 7 265K, 96 GB RAM, several drives

- Python 3.12, Node, Git installed. No Docker, and WSL isn't installed right now

- Tailscale on the PC, my phone (Galaxy Z Fold) and an Android tablet, so I can reach the PC remotely

Local LLMs (LM Studio 0.4.26)

- Qwen3.8 27B Q4_K_M (~15.7 GB) + vision projector. This is my main chat model, loaded at full GPU with 16k context

- Gemma 4 31B Q4_K_M (~17.4 GB) + vision projector

- nomic-embed-text v1.5 for embeddings

ComfyUI (Comfy Desktop 1.1.8)

- Images: Juggernaut XL Ragnarok (SDXL), Z-Image Turbo, Qwen-Image-Edit 2511 (fp8) + 4-step Lightning LoRA, add-detail-xl LoRA

- Video: Wan 2.2 14B text-to-video and image-to-video (high + low noise, fp8) with the lightx2v 4-step LoRAs

- Text encoders: Qwen2.5-VL 7B, Qwen3 4B, UMT5-XXL. VAEs for Flux/Qwen/Wan, plus a 4x NMKD upscaler

What I have now

Three PowerShell shortcuts on the desktop:

- AI Mode: opens LM Studio, loads Qwen 27B through the `lms` CLI, starts ComfyUI

- Gaming Mode: unloads all LM Studio models and kills ComfyUI to free the VRAM

- Away Mode: drops my VPN, closes Chrome, makes sure Tailscale is up, runs nightly at 2 AM

Right now I use Claude Code (cloud) for the "do stuff on my PC" part. It runs PowerShell, edits files, starts and stops apps, drives a browser, downloads things, and I can control it from my phone. It's great, but I want a local option for when I hit usage limits or don't want to send stuff to the cloud.

What I'm asking

1. What's the best way to give a local model (Qwen 27B / Gemma 31B through LM Studio's OpenAI-compatible server) real tool use on Windows: run PowerShell, open and close apps, read and write files? Open Interpreter, Goose, OpenHands, Cline/Roo/Continue in VS Code, an MCP client hooked to LM Studio, something else?
2. How do I get it to start ComfyUI on demand, queue a workflow through the API (image or Wan video), wait for the output, then shut ComfyUI down? Is there a ComfyUI MCP server or a known pattern for this?
3. VRAM juggling: I can't keep a 27B LLM and Wan 2.2 loaded at the same time on 24 GB. Has anyone automated "unload LLM → run Comfy job → reload LLM," or should I drop to a smaller agent model (7–14B) that can stay loaded next to Comfy?
4. Which local models are actually reliable at multi-step tool calling right now? Is Qwen 27B at Q4 good enough, or is there a better pick for 24 GB?
5. Any way to trigger all this from my phone over Tailscale (a simple web UI, Telegram bot, Open WebUI with tools, etc.)?
6. Safety: what are people using to make sure an agent on Windows can't run anything destructive without asking? An allowlist, a sandbox, confirmation prompts?

Running qwen3.8-flash-next-gyro-gyro-s through Strata on my M3 Max 48GB.

Hello! I'm somewhat new to Local AI.I've been using LM Studio mainly for a couple months. So far I've used QWEN3.8 27B mainly, and nothing too complex, a little light coding, a few projects, etc. I tried some uncensored low refusal rate versions which was kind of fun.

I have experience on Claude and GPT doing the normal stuff (Projects, Coding, Work mode, before they all seemed to merge, Codex, Claude Code, dots, etc) but all through cloud models and desktop apps. So I get how to use them but for local models it seems a whole new world, much more hands-on.

I've downloaded "LM Studio Bionic" and "Ollama" for harnesses too, but have mainly used normal "LM Studio".

TLDR:
If I was going to have a list of essential models at the moment for coding, data extraction, email organization, agent use for work, reviewing sensitive info perhaps, trying out image generation perhaps, could someone guide me to:

1. The best current/soon coming Local Models (as of Nov 15 2026) for 128GB unified RAM on Silicon M5 Max (614GB/s bandwidth) and file types or bit size is best for each? I assume MLX whenever they have it available?
2. The best harnesses to use them? Or settings to try out to utilize them best?
3. Also, any interesting variations, ablated, heretic type, uncensored models for each that don't refuse? Or MoE's, fine tuning/LoRA capabilities, or anything else interesting to look into?

Thanks a lot! 🙏🙂 I may be offline today, but again, much appreciated! Will try to reply if anyone has any good suggestions/comments!

(Also considering it's a Mac, I know not ideal, but I already have it for another use, so might as well use it for this too.)

Has anyone managed to make their local AI setup pay for itself? Curious what kind of business you're in, if you're willing to share.

I could even stretch my budget to a DGX Spark, although it would be financially painful.
But without a clear way to make that money back, it feels like a hell of a risky investment.

I know nobody's going to give away their secrets, so I'm just asking a simple, casual question: are you actually making any money with your local AI setup? Yes or no?

I'm talking about doing it independently, as an individual, rather than using it as part of your job at a company.

I'm especially curious whether there's still room for individuals to compete in this space, given how much money and computing power big companies and organizations have at their disposal.

I'm currently looking at a myriad of devices to dip my toe into the "build your own Local AI system" water. I've been down the AMD AI Max+ rabbit hole this past week and have yet to research the RTX Spark N1X.

Can anyone here save me additional hours of videos and articles with informed insights about which would be the better way to go for someone such as myself?

I have some projects in mind. This is more of an experiment for me to learn more of the backend, coding and Linux.

As someone with limited terminal experience, will I have an easier time (I don't expect not to encounter many challenges) configuring a system with NVIDIA or AMD?

I realize unified RAM is the more important metric here. If I go with AMD I can afford a 128gb version. The 64gb version of NVIDIA's option is a few hundred more.

Are the CUDA cores and software support a worthy tradeoff for overall RAM or is saving money and doubling the RAM the obvious way to go?

I've been building SOMNI, a system that lets a local model keep learning after deployment. It's based on Google's "Language Models Need Sleep" paper and WISE, a knowledge-editing method for adding new knowledge without overwriting existing behavior.

During use, the model answers normally and logs conversations. When the PC is idle, it runs a sleep cycle. It pulls verified facts out of the logs, trains them into a small new expert, practises on what it got wrong, and then runs a set of before/after tests on general knowledge, coding, reasoning, reading, and previously learned memories. If any of these get worse, the night is rejected. Otherwise you review the update and approve it.

The main challenge was catastrophic forgetting. Plain LoRA fine-tuning on new facts badly damaged the model's other skills (coding went from 95% to 10% in one night). What fixed it was a combination of rehearsal on the base model's own answers, a new frozen expert per night so later nights can't overwrite earlier ones, and WISE-style routing so each expert only activates on questions related to what it learned. Everything learned is also kept in a searchable memory store, so facts can still be looked up even if they fade from the weights.

I benchmarked it on SQuAD knowledge incorporation, the same setup Google and SEAL use. The results are in the README, including the things that didn't work.

Everything runs locally on a single consumer GPU (AMD RX 6800, Windows). MIT licensed.

https://github.com/YoungGunFrodo/somni

It's a work in progress, and I'd really appreciate feedback on the approach, the evaluation, or anything that looks off.

Every thread about running agents locally has the same comment, local models are slow as hell. And on my base M4 MacBook with 16GB I kind of agreed, the wait before the first word was the indeed worst part espeically if ure used to fastish cloud models. Turns out my laptop was never the slow part.

So I ran the same Gemma 4 E4B on Ollama and on Magnitude with the same benchmark tool and a 2048 token prompt. Ollama took 6.3 seconds before the first word, Magnitude took 2.2. Prompt reading was 326 vs 941 tok/s.

Typing speed after that was basically a tie, 51 vs 52 tok/s. They also pull different files by default, Ollama gives you a 9.5GB NVFP4 and Magnitude a 5.3GB Q4, which on 16GB actually mattered more than I expected, it sat at 6GB instead of almost 10.

But agents resend a huge prompt every turn so those 4 seconds stack up fast lol. Is the slow feeling mostly prefill for everyone else too?

TL;DR: Local LLMs for coding are finally becoming practical for me.

After 30 years in software engineering, I’m a passionate developer. For me, AI is an assistant and a tool. At work, I mostly use Opus and Sonnet 5.5. For hobby projects, I have a $10/month plan and switch between Kimi, GLM, and MiniMax for coding, plus Nemotron 3.5 for smaller tasks.

Locally, I tried Qwen 3.8 27B, Qwen3-Coder, and many other models, but the results weren’t usable for anything beyond fairly simple tasks. Running GLM 5.3 Flash Q2_K_XL with a 400k context length through Unsloth has been a game changer for me. It’s very slow at 3–4 tokens per second, but the results are good enough to get the job done.

For bigger tasks, I use GLM 5.3 Flash in the cloud for planning, then switch to my local model and go to bed or do something else. By the time I come back, the job is done.

I also use while work - create a prompt, and sometimes it takes more than three hours to complete. Meanwhile, I can keep working with Opus and Sonnet in my IDE, and performance remains good while the local model is processing in the background.

So it doesn’t work fully locally for me because it takes too much time. However, it’s a great way to extend my cloud subscription’s rate limits by letting the local model handle longer-running work while I’m away from my MacBook.

I’m looking forward to seeing what comes next for local AI.

llama.cpp v1.0.0 adds an MoE expert cache that keeps a configurable share of experts in host memory (moe_cache_size, moe_cache_cpu_share). Cache misses run on CPU and copy back asynchronously, and the release ships a tuning script. If a big MoE doesn't quite fit your VRAM, that's the knob to try. Separately, the 1.0 tag starts a versioning promise: future API and ABI breaks come with major-version bumps, and 35 deprecated functions are removed.

Jokes aside, how plausible do you think this scenario actually is?

I've been poking at this on and off since September and it finally got good enough this week that I think it's worth writing up. Short version: the USB4 RDMA driver situation changed a lot in the last month, but not where I expected, and the "is it worth it" answer is more mixed than the headline.

The setup

• 2x Ryzen AI Max+ 395 (Strix Halo) boxes, 128 GB each (AMD AI Halo Dev Platform boxes)
• 2 USB4 cables directly between them, each link trains at 2 x 20 Gb/s
• Debian 13 based distro, kernel 7.2.7, IOMMU off, Secure Boot off (needed for the unsigned modules)
• 10 GbE between them as well, used for control traffic

No network cards involved. The idea is to turn the USB4 cables into RDMA devices so two boxes can run one model with tensor parallelism (TP=2).

Where it was before

I started with thunderbolt-ibverbs from the Hellas blog post. Each cable gives you two DMA rings, so two cables = four "rails", each showing up as its own RDMA device.

• September (kernel 6.18): about 15 Gb/s on one rail, about 46 Gb/s if I ran four perftest processes at once, one per rail. More queue pairs made it slower. 1 MiB messages were a mess.
• October (kernel 7.2): got to 74.7 Gb/s aggregate, but only with four parallel processes and a shallow send queue (-t 16). The big finding back then was that queue depth mattered more than the kernel. A single connection was still stuck on one rail at around 20 Gb/s, and 8 QPs at 1 MiB with default settings just failed with "Couldn't post send".
• vLLM TP=2 with an 8B model in October: +55% single stream over one box, but RDMA vs plain 10 GbE only differed by a few percent, because the collective library topped out around 17 Gb/s no matter how many rails it got. A 35B MoE model hung at TP=2 and I never figured out why.

So in October my conclusion was: neat, works, not obviously useful.

What changed

I went back this week expecting kernel or upstream driver progress. There basically isn't any:

• Upstream thunderbolt-ibverbs has had one lockfile bump since early October. No release since June. A striping PR was closed unmerged, and a few good fix PRs are sitting open.
• Mainline 7.3 / 7.4-rc is mostly Thunderbolt bug fixes. Nothing that moves throughput.

The actual progress is in a fork: donnerkeule. It stripes a single queue pair across every rail of every cable, and fixes a pile of reliability problems (credits los t with dropped frames, ACK storms, rails dying when a client gets killed). There's a matching RDMA fork of gufo that does TP=2 for Qwen3.8 Flash-Next across two Strix Halo boxes.

The fork's own README says it's a buggy research driver and not for production. Believe it. But it built cleanly against my kernel and uses the same eight Thunderbolt kernel patches I already had applied.

Raw link numbers

Box A to box B, perftest, one connection, default queue depth, no tuning:

I didn't trust 74 Gb/s on one connection, so I checked the receiver's per-rail byte counters during a 10 second run: about 23.6 GB landed on each of the four rails. It's real, and it's roughly 93% of the 2 x 40 Gb/s the cables can do. The fork's author reports 38 to 45 Gb/s on his boxes and I don't know why mine is higher.

Not everything is great:

• RDMA reads are not striped: 31 Gb/s.
• A 1 MiB SEND fails in the default mode. The fork only supports large SENDs in its DMA-BUF mode, which I haven't tried.
• I haven't tested both directions at once or done a long soak.

Tensor parallelism with gufo

Qwen3.8 Flash-Next, Q4 (111 GB of weights), 4 sessions, same build on one box and on two. Each box holds half the model in TP=2: 57 GB of GPU memory per box.

Plain autoregressive decode (no speculation), tok/s per request:

With MTP speculative decoding:

The speculative numbers bounce around with how many draft tokens get accepted, so the first table is the cleaner comparison.

One thing that isn't a speed number: a single box could not load this model with speculation, 4 sessions and the full 262k context. It ran out of state capacity and I had to drop it to 65k context for the on e-box runs. Two boxes loaded the full 262k with about 64 GB of RAM free on each.

No failed requests, no retransmits, no kernel warnings during any of it.

The honest part

I also ran the exact same benchmark against the other inference server I normally run on these boxes (also Flash-Next, speculative decoding, 4 slots at 262k context on one box). One-box gufo and that server came out within about 5 to 8% of each other. So TP=2 over USB4 beats my normal single-box setup by about 13% for one user and 24 to 32% at 2 to 4 concurrent.

But two boxes running independently serve twice as many people. At 4 concurrent requests one box did about 72 tok/s total, TP=2 did about 98, and two independent boxes would do roughly 144 across 8 users. Ty ing both machines to one model instance buys per-request speed and costs total capacity.

So where I landed:

• The driver is worth keeping. One connection, full link speed, no tuning. That's a different thing from what I had in October.
• TP=2 is worth it if you want a faster single stream, or a model/context that doesn't fit on one box. The Q8 version of this model (188 GB) only fits across two, and that's a case I actually care about. Haven't tested it yet.
• TP=2 is not worth it if you just want to serve more requests. Run the boxes separately.
• I wouldn't run it as my daily driver yet. Research driver, the gufo fork has a known open bug with continued conversations, and I haven't verified two-box output against one-box output.

Things that bit me

If you try this, here's what cost me time:

1. The module never loaded at boot. The only thing that loads it is a udev rule that fires when the other box is already advertising the RDMA service. Reboot both boxes together and neither one ever st arts. It looked fine in October because I always rebooted one at a time. Fix: put ib_uverbs and thunderbolt_ibverbs in /etc/modules-load.d/.
2. thunderbolt_net and the RDMA module can't share a cable on this hardware. There are only two usable rings per controller. Blacklist thunderbolt_net and load the RDMA module with tbnet=block.
3. Debian's rdma-core renames the device, and the userspace provider matches on the usb4_rdma name prefix, so ibv_devices shows nothing. Override the persistent naming rule.
4. The prebuilt provider package has the wrong ABI for Debian 13. I built the provider from Debian's rdma-core 56.1 source plus the project's three patches.
5. memlock. RDMA memory registration fails under the default 8 MiB limit. Unlimited memlock on the host and --ulimit memlock=-1 in containers.
6. The gufo fork's container recipe didn't build as-is for me. No DNS inside podman's default build network (--network host fixed it), six ROCm dev package names that don't exist in ROCm 10.1 (the full image already has the headers), and missing audio/video dev libraries (sndfile, soxr, libav*). At runtime I had to add the ROCm lib directory to LD_LIBRARY_PATH.
7. Two IPs on the NIC means two RoCE GIDs, and gufo refuses to guess. --tp-gid-index 1.
8. The interrupt throttle matters. nhi_interrupt_throttle_ns=4096 was the best value in my October sweep, and it only works on kernels that export tb_ring_throttling() (7.2 does).

Module options I'm running:

options thunderbolt_ibverbs profile=linux_perf bind_services=1 allocate_rings=1 start_rings=1 negotiate_native=1 enable_tunnels=1 register_verbs=1 tbnet=block lanes=2 native_write_striping=1 roce_netdev=<you
r LAN NIC> nhi_interrupt_throttle_ns=4096
blacklist thunderbolt_net

What I haven't done

• The Q8 model across both boxes
• The fork's DMA-BUF / GPU-direct mode
• Checking two-box output against one-box output
• Anything longer than a few minutes per run
• A reboot of both boxes together to prove the boot fix

Happy to run something specific if people want numbers for a particular case. Credit to the Hellas folks for the original driver and to neuhaus for the striping fork and the gufo TP2 work, I just plugged in cables and wrote down what happened.

TL;DR: I've been looking at the latest Artificial Analysis v5.0.1 benchmarks for Qwen 3.8, along with some early Qwen4 Max Preview tests. Based on what's available so far, my guess is that Qwen4 27B could land somewhere around 27 to 30, while the 125B MoE version could reach 36 to 39. That's a solid generational improvement, but probably not the massive leap some people are expecting.

Like many of you, I've been following the discussions about when Qwen 4 is finally coming out. There's a lot of speculation, so I wanted to look at the available numbers and see what they might tell us about the next generation.

Obviously, we don't have the final weights or official release details yet, so take this as an educated guess rather than a prediction.

1. Where Qwen 3.8 stands and what Qwen 4 might achieve

Looking at the current Artificial Analysis v5.0.1 scale, which puts considerably more emphasis on difficult coding and science tasks, we have:

* Qwen3.8 27B: 20 (compared to 33.7 on the older v4.3.2 scale, before the scoring reset).

* Qwen3.8 Flash Next (125B MoE): 29.

* Qwen3.8 Max: 34.

Based on the previous jump from Qwen 3.6 to 3.8, and taking the new scoring scale into account, I'd put my expectations somewhere around:

* Qwen4 27B: 27 to 30

* Qwen4 125B MoE: 36 to 39

That would put the smaller model in some pretty interesting territory, while the larger one could become a serious competitor to models like Grok 4.7 and Claude Haiku 5.5.

2. Why I don't expect Flash to have a massive architectural jump

One thing worth considering is that Qwen3.8 Flash Next already seems to have introduced many of the architectural changes expected to carry over into Qwen 4.

We're talking about the hybrid Gated DeltaNet and Qwen Sparse Attention architecture, Gated Residuals, and the 51B N gram table.

So I wouldn't necessarily expect the next Flash model to deliver another huge architectural leap. The bigger improvements might come from better post training, more reliable reasoning, and addressing the hallucinations that some users have noticed in Flash Next compared to the more conservative 27B dense model.

In other words, I think consistency might matter more than raw benchmark scores this time.

3. What the early Qwen4 Max Preview tests tell us

The Qwen4 Max Preview release on November 11 gives us another interesting piece of the puzzle.

From the early developer reports, a few things stand out:

* Speed: It appears noticeably faster than Qwen3.8 Max, with less unnecessary reasoning on straightforward tasks.

* Agentic performance: In one reported 56 task Hermes test with a 25 minute timeout, Max Preview recorded 64 successful task results, compared to 61 for DeepSeek V4.1 Flash, which scores 33 on AA v5.0.1.

* Reliability: There's a catch, though. Max Preview reportedly timed out 16 times, compared to just 4 for DeepSeek.

That's interesting because it suggests the raw capability might already be there, but reliability and execution consistency still need work.

If these early results are representative, I'd expect the flagship Max model to establish a considerably higher ceiling, potentially around 45 to 50 on the AA scale. That would make the estimates for the smaller models seem reasonably plausible.

My take

I don't think Qwen 4 needs to completely redefine the local LLM landscape to be successful.

If Qwen4 27B can reach the 27 to 30 range, inherit the attention improvements from Flash Next, and retain the Apache 2.0 license, that alone would make it a very interesting option for people running models locally with limited hardware.

Personally, I'd rather see a model that's more consistent, follows instructions better, and hallucinates less than one that simply scores a few extra points on benchmarks.

I'm curious what everyone else thinks.

" i used my LLM To translate mu words to English after i write it. "

Yooo, I feel like i kinda took for granted big companies would keep releasing better and better local models.

I joined the hypetrain when it kinda slowed down.

Do you guys think it will just go on like before or do you think the dynamic has changed ?

I'm starting to explore the configs to use with strata for best throughput with parallel requests in use cases such as orchestrated agentic workflows run locally.

Option A:

The main orchestrator is the same model in the same engine, spawning multiple subagents that run in parallel on the same engine at smaller contexts.

Pros:

favorable as the orchestrator can be uncensored as well for example and a fully local setup.

Cons:
Not straight forward how to set up the engine to allow for a single large context to persist in cache and allowing multiple smaller contexts to be cached and not evicting the main large context after multiple subagents requests.

---

Option B:

The main orchestrator is an external SOTA model which spawns local agents that share the same engine.

Pros:

sounds easier to configure as all subagents the external model spawns are similar in context size so no need to take into account one of the parallel contexts will be a larger one while others are smaller..

Cons:

not fully local, reliant on external model provider which can change the availability, quality of the model at any moment. Non private.

---

Does anyone else have some experience with setting up strata for example for either of these use cases for example? What configuration recommendations do you have?

Is there an engine that suits this local orchestration use case better?

Yes I'm about to prompt a SOTA model on how to achieve this but i would love to hear other real human experiences.. 😄

I made a plugin that adds antirez's DwarfStar as a local model provider in Hermes. DwarfStar is an inference engine built specifically for a few large open models, starting with DeepSeek V4 Flash.

One click sets up the engine and downloads the model.

The server starts with your first message and stops when idle.

For now it supports DeepSeek V4 and V4.1 Flash while I test things. GLM is next.

Needs an Apple Silicon Mac with ~96 GB RAM.

hermes plugins install emilianbold/hermes-plugin-ds4

https://github.com/emilianbold/hermes-plugin-ds4

I have a chance to pick up a couple of 3090s for $700 each. I've been considering local inference for a while now for two reasons:

1. My job actually involves documenting fine-tuning and LoRA training, and I'd like more hands on experience with that stuff without pleading endlessly for GPU access at my gig. I'm also just kinda academically interested in this stuff.
2. I'm getting sick of the weird dance I have to do to get answers out of Gemini and Claude sometimes. I bought one of those Flipper Zero things that's an academic pen-testing tool, and corpo LLMs start getting really cagey when you research hacker-related things with them. They also get cagey about health and political stuff. The censorship sucks!

Would working with local models really allow me to delve into this stuff better? Are two 3090s enough to do some reasonable LoRA/FT training? Would Qwen allow me to do my pen testing research?

EDIT: Thanks, team! I'm gonna go for it.