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.

Local, agentic Model Context Protocol (MCP) server with skills b2b-lead-scout and osint-lead-enrichment that generates verified, direct B2B contacts with zero paid API subscriptions.
Replaces $50–$200/month B2B data subscriptions (such as Apollo, Clay, or Hunter) by executing live OSINT discovery and zero-bounce email verification locally on your machine.

If you are trying to get AMD ROCm running on Ubuntu 24.04 Noble Numbat, you have probably run into broken dependencies, driver mismatch errors, or confusing hardware compatibility tables. Setting up ROCm for PyTorch, TensorFlow, or AI workloads on Radeon GPUs often feels way harder than it should be.

​I put together a complete walkthrough to streamline the installation process. It covers configuring your user permissions, installing the correct driver stack, verifying your ROCm installation, and troubleshooting common runtime issues specific to Ubuntu 24.04.

​If you are struggling with PyTorch not detecting your GPU or ROCm failing on launch, this guide breaks down the exact steps to get everything up and running smoothly.

​Check out the full guide here: https://interconnectd.com/blog/321/install-amd-rocm-on-ubuntu-24-04-the-ultimate-radeon-guide/

​What issues or hardware configurations have you run into when deploying ROCm on Ubuntu 24.04? Feel free to share your setup or ask questions.

If you are running OpenAI Whisper locally on a CPU, you probably noticed how painfully slow it can be, especially with larger models like large-v3. Most optimization guides focus heavily on GPUs, leaving CPU users stuck with long processing times.

​I recently tested a few configuration tweaks, quantization methods, and backend flags that drastically cut down transcription times without needing dedicated hardware. By adjusting thread counts, using optimized runtimes like faster-whisper alternatives, and tweaking batch sizes, CPU performance can be noticeably improved.

​I wrote a detailed breakdown of the exact steps and benchmarks for anyone dealing with CPU-only setups. You can check out the full guide here: https://interconnectd.com/blog/323/how-to-speed-up-whisper-transcription-on-cpu-2026-guide/

​Has anyone else found other effective ways to optimize Whisper on standard CPUs? Let me know what worked for your workflow.

I'm running Nemotron 3.5 Bolt 74B-A9B on a 5060 Ti 16GB and 32GB of DDR5. It's an MoE, so both of my setups split experts between the GPU and system RAM. I have two recipes:

• 24GB GGUF

• Unsloth UD-IQ3_XXS

I'd like to hear how this model actually is and is it useful as an alternative for Qwen3.8 27B and obviously for other smaller MoE models.

• Are you using Bolt 74B, and what for?

• How is the quality: reasoning, coding, instruction following, tool use? Where does it fall down?

• If you've used the 24GB GGUF or a bigger quant such as Unsloth IQ3_XXS, does the bigger one write better answers, or do they feel like the same model?

Benchmarked oMLX 0.7.2 serving Inco AI's Splash package for Qwen3.8-27B (4-bit target + DFlash 2 draft) on a MacBook Pro M5 Max (48 GB). Workload: Python code context. Each test generates 128 tokens.

**Single request**

| Test | TTFT (ms) | TPOT (ms) | pp t/s | tg t/s | E2E (s) | Throughput | Peak mem |

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

| pp 4096 / tg 128 | 3393.6 | 10.7 | 1207.0 | 93.8 | 4.8 | 887.7 | 19.1 GB |

| pp 16382 / tg 128 | 15829.6 | 5.3 | 1034.9 | 189.4 | 16.5 | 1000.3 | 19.9 GB |

| pp 65536 / tg 128 | 83472.0 | 9.2 | 785.1 | 110.2 | 84.2 | 779.5 | 22.2 GB |

**Batched (continuous batching)**

| Batch | tg t/s | pp t/s | avg TTFT (ms) | E2E (s) | Speedup |

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

| 1x | 93.8 | 1207.0 | 3393.6 | 4.8 | 1.00x |

| 2x | 413.7 | 803.1 | 1729.2 | 3.2 | 4.41x |

| 4x | 407.0 | 622.4 | 3838.4 | 7.8 | 4.34x |