Homelab

The stack is wired end to end. A message from Telegram on my phone reaches OpenClaw on the cluster, which either answers conversationally or delegates a coding task across containers to Pi, which runs it against a 27B model on the RTX 5060 Ti and writes files to disk – no cloud AI anywhere in the path. The last post closed the loop. This post is the step back: what did I actually build, how close does it get to the Claude products I was trying to approximate, and where does it fall short.

This is the anchor post for the Proxmox Local AI Lab series. If you have read none of the other posts, start here : it explains what the lab is, why it exists, and where each piece is documented. If you really want to read them all — not sure why you would do this to yourself — but this is the map you can come back to.

Once OpenClaw is running and pointing at the local inference endpoint, the next step is giving it a way to receive messages. OpenClaw supports multiple messaging channels natively – Telegram, Signal, Discord, and others. This post covers Telegram : getting a bot token, connecting the channel, pairing it to your account, and trying it out.

Container 110 (Pi Coding Agent) and container 111 (OpenClaw) are both running. The question now is how OpenClaw routes a coding task to Pi and gets the result back.

Pi’s integration interface is RPC over stdin/stdout — it’s designed to be driven as a subprocess, not called over a network. OpenClaw lives in a separate container. Separate containers don’t share a process space, so “spawn Pi as a subprocess” doesn’t work out of the box.

The last two posts got the inference layer and the gateway running. CT 100 is serving Qwopus at 44 T/s with MTP speculative decoding active. CT 101 is serving Gemma 4 E4B at 51 T/s. CT 111 (OpenClaw) is routing Telegram messages to the AMD container and responding.

At this point in the series, the inference layer is done. CT 100 is running llama-server on the RTX 5060 Ti at 26 T/s. CT 101 is running llama-server on the RX 6650 XT at 51 T/s. Both expose OpenAI-compatible endpoints on the local network.

The cluster is up. IOMMU groups are sorted — each GPU is in its own group, PCI IDs documented, ACS override confirmed working.

Before running an install script, I want to spend a few paragraphs on the inference runtime decision. The straight version : llama.cpp wins for this setup, and the reasons are specific to this hardware and model combination — not a generic preference. If you want to skip ahead to the build, jump to Prerequisites. If you want to learn why, continue reading here.

This one is a short detour from the AI workload series. I want to run a Minecraft Java Edition server on the homelab — for LAN play with my daughter. Her machine is a Lenovo 500W Gen 3 on Linux (ZorinOS) ; mine is a MacBook Pro. The first question : where does a Minecraft server belong in a three-node Proxmox cluster, and how do I stand it up without it touching the AI workloads on pve1?

The previous post covered why I wanted local AI at all. This one is about how the cluster is actually designed — and then the hands-on build. I’ll talk through design decisions alongside the setup.

Using this post to think-out why I am building a local AI lab on Proxmox before I get into any of the how. The guiding question is simple : after a couple of years using the first wave of recent AI/LLM products — ChatGPT, Gemini, CoPilot, Perplexity — and a year of running against AI build tools and agentic harnesses — Google AI Studio, Vertex AI, Gemini Live, Claude Cowork, Claude Code, Codex, Cursor, hosted Frontier models to do even more work — what is the actual problem a local stack solves for me, and what is it not going to solve?