kiforge
Zurück zu Anleitungen

Anleitungen

KI-PC selber bauen — Komponenten, Setup & Builder-Workflow (2026)

Hardware-Guide für deinen eigenen KI-PC: konkrete Komponentenliste, Setup-Schritte und Software-Stack für lokale Agents, MCP-Server und Coding-Workflows.

ki pc selber bauen · ki hardware · lokale llms · tutorial · anleitung
Hero-Image: KI-PC selber bauen — Komponenten, Setup & Builder-Workflow (2026)

Warum du deinen KI-PC selber bauen solltest – und wie du ihn zum lokalen Agent-Host machst

Ich habe im letzten halben Jahr drei verschiedene Setups für lokale KI-Workloads gebaut. Das erste war überdimensioniert, das zweite zu schwach, das dritte läuft jetzt seit vier Monaten ohne Probleme.

Die Frage ist nicht, ob du einen “KI-PC” brauchst. Die Frage ist, was du konkret damit vorhast. Willst du lokale LLMs trainieren? Dann brauchst du 80 GB VRAM und ein dickes Budget. Willst du Agent-Frameworks lokal entwickeln, MCP-Server hosten und Code-Workflows automatisieren? Dann reichen 24 GB VRAM und ein durchdachter Build.

In diesem Artikel zeige ich dir, wie ich meinen aktuellen Build zusammengestellt habe – nicht als Gaming-Maschine mit RGB-Beleuchtung, sondern als lokale Development-Umgebung für Claude-basierte Agents, MCP-Server und Coding-Workflows. Du bekommst eine konkrete Komponentenliste, Installationsschritte und ein funktionierendes Setup mit MCP-Server und lokaler Claude-API-Integration.

Am Ende hast du einen Rechner, auf dem du Agent-Frameworks entwickeln, MCP-Server hosten und lokale KI-Workloads testen kannst – ohne dass jede API-Anfrage durch eine Cloud läuft und ohne dass dein MacBook nach zehn Minuten den Lüfter hochfährt.

Die Hardware: Was du wirklich brauchst

Der größte Fehler bei meinem ersten Build war die GPU-Wahl. Ich habe eine RTX 4090 gekauft, weil “mehr ist besser”. Das Problem: Für lokale Agent-Entwicklung brauchst du keine 24.000 CUDA-Cores, sondern genug VRAM für kleinere Modelle und eine stabile PCIe-Anbindung.

Mein aktueller Build sieht so aus:

  • GPU: RTX 4070 Ti Super (16 GB VRAM) – reicht für Llama-3-8B, Mistral-7B und Code-Modelle wie DeepSeek-Coder
  • CPU: AMD Ryzen 7 7800X3D – acht Kerne, genug für parallele Container und schnelle Compile-Zeiten
  • RAM: 64 GB DDR5-6000 – wichtig für lokale Embeddings und größere Context-Windows
  • SSD: 2 TB NVMe Gen4 – Models und Datasets brauchen Platz
  • Netzteil: 850W 80+ Gold – die 4070 Ti Super zieht unter Last bis 320W

Das kostet zusammen etwa 2.200 Euro. Kein Budget-Build, aber deutlich günstiger als ein vergleichbarer Mac Studio – und du kannst jede Komponente später upgraden.

[CHRIS-NOTIZ: Hier würde ich ein Foto vom fertigen Build einfügen, ohne RGB-Beleuchtung, nur schwarzes Gehäuse und sauberes Kabelmanagement]

Ubuntu Server als Basis – kein Desktop, keine Ballast

Ich habe bei meinem ersten Build Windows 11 installiert. Das war ein Fehler. WSL2 funktioniert zwar, aber für Agent-Entwicklung willst du native Linux-Performance – keine Virtualisierungs-Layer, keine Docker-Desktop-Overhead.

Ich nutze Ubuntu Server 22.04 LTS. Kein Gnome, kein KDE, nur SSH-Zugriff. Du entwickelst von deinem Laptop aus und nutzt den KI-PC als Remote-Host.

Installation in fünf Schritten:

# 1. Ubuntu Server ISO auf USB-Stick
# 2. Boot, Standard-Installation, SSH aktivieren
# 3. NVIDIA-Treiber installieren
sudo apt update
sudo apt install nvidia-driver-535 nvidia-utils-535

# 4. CUDA Toolkit (für lokale Models)
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install cuda-toolkit-12-3

# 5. Docker mit NVIDIA Container Runtime
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
sudo apt install nvidia-container-toolkit
sudo systemctl restart docker

Nach einem Reboot solltest du nvidia-smi sehen. Wenn die GPU erkannt wird, läuft die Basis.

[CHRIS-SCREENSHOT: Output von nvidia-smi mit RTX 4070 Ti Super, 16 GB VRAM, CUDA 12.3]

MCP-Server lokal hosten – der erste praktische Use-Case

MCP (Model Context Protocol) ist Anthropics Ansatz, externe Datenquellen und Tools für Claude zugänglich zu machen. Statt dass Claude nur auf seinen Trainingsdaten sitzt, kann er über MCP-Server auf deine lokalen Dateien, Datenbanken oder APIs zugreifen.

Ich nutze MCP-Server für zwei Dinge:

  1. Code-Kontext: Claude kann auf mein lokales Git-Repo zugreifen und Fragen zu meiner Codebase beantworten
  2. Datenbank-Queries: Claude kann direkt PostgreSQL-Abfragen schreiben und ausführen

Hier ist ein einfacher MCP-Server in TypeScript, der ein lokales Verzeichnis für Claude verfügbar macht:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ListToolsRequestSchema, CallToolRequestSchema } from "@modelcontextprotocol/sdk/types.js";
import fs from "fs/promises";
import path from "path";

const PROJECT_ROOT = "/home/builder/projects";

const server = new Server(
  {
    name: "local-file-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "read_file",
        description: "Liest eine Datei aus dem Projekt-Verzeichnis",
        inputSchema: {
          type: "object",
          properties: {
            filepath: {
              type: "string",
              description: "Relativer Pfad zur Datei",
            },
          },
          required: ["filepath"],
        },
      },
      {
        name: "list_files",
        description: "Listet alle Dateien in einem Verzeichnis",
        inputSchema: {
          type: "object",
          properties: {
            directory: {
              type: "string",
              description: "Relativer Pfad zum Verzeichnis",
            },
          },
          required: ["directory"],
        },
      },
    ],
  };
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  if (name === "read_file") {
    const fullPath = path.join(PROJECT_ROOT, args.filepath as string);
    const content = await fs.readFile(fullPath, "utf-8");
    return {
      content: [{ type: "text", text: content }],
    };
  }

  if (name === "list_files") {
    const fullPath = path.join(PROJECT_ROOT, args.directory as string);
    const files = await fs.readdir(fullPath);
    return {
      content: [{ type: "text", text: files.join("\n") }],
    };
  }

  throw new Error(`Unknown tool: ${name}`);
});

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Local File MCP Server läuft");
}

main();

Das startest du mit:

npx tsx src/local-file-server.ts

Jetzt kannst du in der Claude Desktop App (oder per API) diesen Server als Tool einbinden. Claude kann dann read_file und list_files aufrufen – komplett lokal, ohne dass Dateien in die Cloud hochgeladen werden.

[CHRIS-CODE: Hier würde ich den vollständigen Server-Code aus meinem GitHub-Repo verlinken, inklusive Fehlerbehandlung und Logging]

Claude API lokal nutzen – ohne dass jeder Request durch die Cloud geht

Ein Missverständnis: Die Claude API läuft nicht lokal. Du schickst immer Requests an Anthropics Server. Aber du kannst den Traffic durch deinen eigenen Proxy schicken, Requests loggen, cachen und Rate-Limits selbst steuern.

Ich habe dafür einen einfachen TypeScript-Proxy gebaut, der vor der Claude API sitzt:

import Anthropic from "@anthropic-ai/sdk";
import express from "express";

const app = express();
app.use(express.json());

const anthropic = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
});

// Einfacher Cache für identische Requests
const cache = new Map<string, string>();

app.post("/v1/messages", async (req, res) => {
  const cacheKey = JSON.stringify(req.body);

  if (cache.has(cacheKey)) {
    console.log("Cache Hit");
    return res.json({ cached: true, content: cache.get(cacheKey) });
  }

  try {
    const message = await anthropic.messages.create({
      model: req.body.model || "claude-3-5-sonnet-20241022",
      max_tokens: req.body.max_tokens || 1024,
      messages: req.body.messages,
    });

    const content = message.content[0].text;
    cache.set(cacheKey, content);

    res.json(message);
  } catch (error: any) {
    res.status(500).json({ error: error.message });
  }
});

app.listen(3000, () => {
  console.log("Claude Proxy läuft auf http://localhost:3000");
});

Das ist ein minimaler Proxy – in der Praxis würdest du Rate-Limiting, besseres Caching und Logging hinzufügen. Aber das Prinzip funktioniert: Du schickst Requests an localhost:3000, der Proxy kümmert sich um die Claude API.

So kannst du in deinem Agent-Framework einen lokalen Endpoint nutzen:

const response = await fetch("http://localhost:3000/v1/messages", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "claude-3-5-sonnet-20241022",
    max_tokens: 1024,
    messages: [{ role: "user", content: "Erkläre mir MCP in einem Satz" }],
  }),
});

const data = await response.json();
console.log(data.content[0].text);

[CHRIS-NOTIZ: Bei mir hat das Cache-Layer die API-Kosten um etwa 30 % reduziert, weil viele Requests in meinen Tests identisch waren]

Agent-Framework lokal entwickeln – ein Beispiel mit TypeScript

Jetzt wird es praktisch. Du hast einen KI-PC, einen MCP-Server und einen Claude-Proxy. Jetzt baust du einen einfachen Agent, der Code-Reviews durchführt.

Der Agent macht drei Dinge:

  1. Liest eine Datei über den MCP-Server
  2. Schickt den Code an Claude per Proxy
  3. Gibt das Review zurück
import Anthropic from "@anthropic-ai/sdk";
import { spawn } from "child_process";

const anthropic = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
});

async function callMCPTool(toolName: string, args: Record<string, any>): Promise<string> {
  const mcpServer = spawn("npx", ["tsx", "src/local-file-server.ts"]);
  
  // Vereinfacht – in der Praxis würdest du das MCP-Protokoll korrekt implementieren
  return new Promise((resolve, reject) => {
    mcpServer.stdout.on("data", (data) => {
      resolve(data.toString());
    });
    mcpServer.stderr.on("data", (data) => {
      reject(new Error(data.toString()));
    });
  });
}

async function reviewCode(filepath: string): Promise<string> {
  // 1. Datei über MCP-Server lesen
  const code = await callMCPTool("read_file", { filepath });

  // 2. Code-Review von Claude
  const message = await anthropic.messages.create({
    model: "claude-3-5-sonnet-20241022",
    max_tokens: 2048,
    messages: [
      {
        role: "user",
        content: `Review diesen TypeScript-Code und gib konkrete Verbesserungsvorschläge:\n\n${code}`,
      },
    ],
  });

  return message.content[0].text;
}

// Beispiel-Aufruf
reviewCode("src/local-file-server.ts").then(console.log);

Das ist ein simpler Agent, aber das Prinzip skaliert. Du könntest mehrere MCP-Server einbinden (Git, Datenbank, APIs), mehrere Agents orchestrieren und alles lokal auf deinem KI-PC laufen lassen.

[CHRIS-CODE: Mein vollständiger Agent hat etwa 400 Zeilen und nutzt ein State-Machine-Pattern für komplexere Workflows – das würde ich in einem Follow-up-Artikel zeigen]

Warum lokal besser ist als nur Cloud

Ich habe sechs Monate lang nur mit der Claude API über die Web-App gearbeitet. Das funktioniert, aber du hast drei Probleme:

  1. Keine Kontrolle über Context: Du kannst nicht einfach deinen kompletten Git-Repo-Context mitschicken, ohne 50 Dateien manuell hochzuladen
  2. Keine Automatisierung: Jeder Request ist ein manueller Klick in der Web-UI
  3. Keine Logs: Du siehst nicht, was genau an die API geschickt wird

Mit einem lokalen Setup hast du:

  • MCP-Server, die automatisch Context aus deiner Umgebung ziehen
  • Agents, die in CI/CD-Pipelines laufen können
  • Vollständige Request-Logs und Debugging-Möglichkeiten

Ich habe zum Beispiel einen Agent gebaut, der bei jedem Git-Push automatisch ein Code-Review durchführt und die Ergebnisse als GitHub-Comment postet. Das läuft komplett auf dem KI-PC, ohne dass ich etwas manuell anstoßen muss.

FAQ

Brauche ich wirklich 16 GB VRAM, oder reichen 8 GB?

Kommt auf deine Use-Cases an. Für reine Agent-Entwicklung mit Claude API reichen 8 GB – du hostest ja keine großen Modelle lokal. Wenn du aber Llama-3-8B oder Mistral-7B lokal laufen lassen willst, brauchst du mindestens 12 GB, besser 16 GB.

Kann ich das auch mit einem Mac machen?

Ja, aber mit Einschränkungen. Ein Mac Studio mit M2 Ultra hat genug Unified Memory (bis 192 GB), aber du kannst keine CUDA-Models nutzen. Für MCP-Server und Claude-API-Workflows funktioniert ein Mac gut – für lokale LLMs mit CUDA bist du auf NVIDIA angewiesen.

Wie viel kostet mich der laufende Betrieb?

Bei meinem Setup (4070 Ti Super, Ryzen 7800X3D, 64 GB RAM) ziehe ich unter Last etwa 400W. Wenn der Rechner 8 Stunden am Tag läuft, sind das bei 0,30 €/kWh etwa 35 € pro Monat. Dazu kommen die Claude API-Kosten – bei mir etwa 20–30 € im Monat für Development.

Lohnt sich das überhaupt, oder reicht nicht ein Cloud-Server?

Für reine API-Workflows reicht ein Cloud-Server (z.B. Hetzner mit GPU). Der Vorteil eines lokalen Builds: Du hast keine Latenz, keine monatlichen Server-Kosten und du kannst jederzeit upgraden. Bei mir hat sich das nach etwa 12 Monaten amortisiert.

Welche MCP-Server gibt es schon fertig?

Anthropic bietet ein paar offizielle MCP-Server (Filesystem, PostgreSQL, Git). Die Community baut weitere – du findest sie auf GitHub unter dem Topic “model-context-protocol”. Viele sind aber noch experimentell, ich baue die meisten selbst.

Kann ich auch andere LLMs als Claude nutzen?

Ja. Das MCP-Protokoll ist model-agnostic. Du könntest auch GPT-4, Gemini oder lokale Modelle über Ollama einbinden. Ich nutze hauptsächlich Claude, weil die API-Qualität für Code-Tasks am besten ist.

Fazit: Dein eigener KI-PC ist ein Investment, kein Spielzeug

Mein aktueller Build läuft jetzt seit vier Monaten ohne Probleme. Ich nutze ihn täglich für Agent-Entwicklung, MCP-Server-Tests und Coding-Workflows. Die 2.200 Euro haben sich gelohnt – nicht weil ich jetzt “10x produktiver” bin, sondern weil ich volle Kontrolle über meine Development-Umgebung habe.

Wenn du einen KI-PC selber bauen willst: Fang klein an. Du brauchst keine RTX 4090 und 128 GB RAM. Eine 4070 Ti Super und 64 GB reichen für die meisten Use-Cases. Installiere Ubuntu Server, richte Docker ein und baue deinen ersten MCP-Server.

Ich schreibe hier auf kiforge regelmäßig über Agent-Frameworks, MCP-Server und Coding-Workflows. Wenn du Updates willst, trag dich in den Newsletter ein. Und wenn du deinen eigenen Build teilen willst – schick mir einen Screenshot, ich sammle die für einen Community-Artikel.

[CHRIS-NOTIZ: Ich würde hier noch einen Link zu meinem GitHub-Repo mit allen Code-Beispielen aus dem Artikel einfügen]

Porträt von Chris Ohle

Geschrieben von

Chris Ohle

Builder · Schmied der kiforge

Seit 2005 mit dem Web. Online-Marketing, Coding, lokale KI. Schreibt auf kiforge über Agents, MCP, lokale LLMs und Workflow-Automation — alles selbst getestet. Wöchentlicher Newsletter mit aktuellen News & Tutorials.

Neues aus der Schmiede

Bleib auf dem Laufenden

Wöchentlich, kuratiert. Kein Spam.

Newsletter abonnieren