KI & LLM 8 Min Lesezeit

AI-Agenten selbst hosten 2026 – Frameworks & Setup

Q: Wie verhindere ich, dass Agenten unkontrolliert Token verbrennen?

Drei Limits gehören in jede Produktionskonfiguration: max_iter pro Agent (8 bis 12), maximaler Kontext pro Call (32k), und ein Tagesbudget pro Nutzer. Zusätzlich hilft ein Timeout von 300 Sekunden pro Task – Endlosschleifen laufen sonst stundenlang.

Warum AI-Agenten selbst hosten?

Ein AI-Agent ist mehr als ein Chatbot: Er plant Aufgaben, ruft Tools auf, schreibt Code, liest Dateien und arbeitet in Schleifen, bis ein Ziel erreicht ist. Genau diese Schleifen erzeugen aber ein Problem, wenn sie gegen eine Cloud-API laufen: Kosten und Datenhoheit. Ein Agent, der pro Task 40.000 Token verbraucht, ist bei 500 Tasks am Tag schnell bei 20 Millionen Token täglich – bei einem Output-Preis von 8 bis 15 US-Dollar pro Million Token sind das mehrere hundert Euro im Monat.

Selbst hosten heißt 2026 nicht mehr, ein Modell von Grund auf zu trainieren. Es heißt: offene Gewichte (Qwen3, Llama 4, Mistral, GPT-OSS) auf eigener GPU betreiben, das Agent-Framework als Container daneben stellen und die Tool-Ausführung sauber sandboxen. Die Inferenzqualität offener 30B-Modelle liegt bei strukturierten Agent-Tasks inzwischen auf dem Niveau der kommerziellen Mittelklasse von 2024.

Dazu kommen drei harte Argumente: Latenz (kein Rate-Limit, kein Netzwerk-Roundtrip), Compliance (DSGVO, keine Datenübermittlung in Drittländer) und Vorhersagbarkeit (fixe Monatskosten statt variabler Token-Rechnung). Wer Agenten produktiv für interne Prozesse einsetzt, fährt ab etwa 30 Millionen Token pro Monat mit eigener Hardware günstiger.

Hardware: Was braucht ein Agent-Stack 2026?

Die Faustregel lautet: VRAM entscheidet, nicht Rohleistung. Ein 32B-Modell in Q4-Quantisierung braucht rund 20 GB VRAM plus 4 bis 8 GB für den KV-Cache bei 32k Kontext. Ein 70B-Modell in Q4 liegt bei 42 bis 48 GB. Für Agenten ist der Kontext wichtig, weil Tool-Definitionen, Dateiinhalte und Zwischenergebnisse den Prompt schnell auf 15.000 Token und mehr aufblähen.

Hardware	VRAM	Realistisches Modell	Preis (ca.)
RTX 4090	24 GB	Qwen3-32B Q4, 16k Kontext	1.900 €
RTX 5090	32 GB	Qwen3-32B Q8 / Llama-4-Scout Q4	2.400 €
RTX 6000 Ada	48 GB	70B Q4, 64k Kontext	6.800 €
Mac Studio M4 Max	128 GB unified	120B Q4, langsam aber viel Kontext	4.700 €
Hetzner GEX44	20 GB (RTX 4000 Ada)	32B Q4	184 €/Monat
Hetzner GEX130	48 GB (RTX 6000 Ada)	70B Q4	630 €/Monat

Wer nicht kaufen will, mietet. Ein dedizierter GPU-Server bei Hetzner ist in wenigen Minuten provisioniert und kostet bei 20 GB VRAM weniger als ein halber Arbeitstag Entwicklerzeit. Für Produktionsagenten mit mehreren parallelen Sessions lohnt sich Tensor-Parallelität über zwei Karten – vLLM skaliert linear bis etwa vier GPUs, danach wird der All-to-All-Overhead spürbar.

Beim RAM gilt: mindestens 64 GB, besser 128 GB. Das Agent-Framework, Vektor-Datenbank, Redis und Observability-Stack laufen parallel. Eine NVMe mit 2 TB ist Pflicht, weil Modell-Gewichte allein 40 bis 80 GB belegen und Container-Images für Sandboxing viel Platz fressen.

Die wichtigsten Frameworks im Vergleich

Der Framework-Markt hat sich 2026 konsolidiert. Übrig geblieben sind fünf bis sechs ernsthafte Kandidaten, die sich nach Kontrollbedarf unterscheiden lassen.

Framework	Sprache	Multi-Agent	Persistenz	Lernkurve
LangGraph	Python/TS	Graph, explizit	Checkpointer (Postgres/Redis)	mittel–hoch
CrewAI	Python	Crews & Flows	SQLite/Postgres	niedrig
AutoGen (AG2)	Python/.NET	GroupChat	Memory-Stores	mittel
OpenHands	Python	Delegation	Session-Filesystem	niedrig
Dify	Python/TS	Workflow-Graph	Postgres	sehr niedrig
n8n	TypeScript	Node-Workflow	Postgres	sehr niedrig

LangGraph ist die Wahl, wenn du Kontrolle über jeden Zustandsübergang brauchst. Der Agent ist ein gerichteter Graph mit Knoten für LLM-Calls, Tool-Ausführung und Human-in-the-Loop-Freigaben. Der Checkpointer erlaubt es, einen Lauf nach einem Crash exakt an der letzten Node fortzusetzen – bei langen Coding-Agenten Gold wert.

CrewAI ist schneller zum Ergebnis: Rollen, Tasks und Delegation werden deklarativ beschrieben. Für Content-Pipelines, Recherche-Agenten und Report-Generierung reicht das meist. AutoGen glänzt bei Dialogen zwischen spezialisierten Agenten (Coder, Reviewer, Tester). OpenHands ist ein fertiger Coding-Agent – du startest ihn als Container und gibst ihm ein Repository.

Dify und n8n sind keine Bibliotheken, sondern Plattformen mit Weboberfläche. Wer Agenten in bestehende Business-Prozesse einbettet und Kollegen ohne Python-Kenntnisse einbinden will, fährt damit besser als mit handgeschriebenem Code.

Setup 1: Ollama als lokales LLM-Backend

Für Entwicklung und kleine Last ist Ollama der schnellste Weg. Installation auf Ubuntu 24.04:

curl -fsSL https://ollama.com/install.sh | sh
systemctl enable --now ollama

# Modell ziehen (32B, Q4, ca. 20 GB)
ollama pull qwen3:32b

# Für Netzwerkzugriff aus Containern freigeben
sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=0.0.0.0:11434"
# Environment="OLLAMA_KEEP_ALIVE=30m"
# Environment="OLLAMA_NUM_PARALLEL=4"
sudo systemctl restart ollama

OLLAMA_KEEP_ALIVE=30m verhindert, dass das Modell nach fünf Minuten aus dem VRAM geworfen wird – bei Agenten mit vielen kurzen Calls ist das der wichtigste Performance-Hebel überhaupt. OLLAMA_NUM_PARALLEL=4 erlaubt vier gleichzeitige Requests, kostet aber KV-Cache pro Slot.

Test mit Tool-Calling, denn genau das unterscheidet Agenten von Chatbots:

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3:32b",
  "messages": [{"role":"user","content":"Wie ist das Wetter in Berlin?"}],
  "tools": [{
    "type":"function",
    "function":{
      "name":"get_weather",
      "description":"Wetter für eine Stadt",
      "parameters":{"type":"object",
        "properties":{"city":{"type":"string"}},
        "required":["city"]}
    }
  }],
  "stream": false
}'

Kommt im Response ein tool_calls-Array zurück, ist das Modell agententauglich. Achte auf die Durchsatzrate: Auf einer RTX 5090 laufen 32B-Q4-Modelle bei etwa 45 bis 60 Token/s Output – für Agenten mit langen Ketten ist das die harte Grenze.

Setup 2: vLLM für Produktion

Sobald mehrere Nutzer oder parallele Agent-Sessions bedient werden, wechselst du zu vLLM. Der PagedAttention-Scheduler erhöht den Durchsatz gegenüber Ollama um den Faktor drei bis acht, weil der KV-Cache nicht fragmentiert.

docker run --gpus all --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3-32B \
  --quantization awq \
  --gpu-memory-utilization 0.92 \
  --max-model-len 32768 \
  --enable-auto-tool-choice \
  --tool-call-parser hermes \
  --served-model-name agent-model

Die beiden Flags --enable-auto-tool-choice und --tool-call-parser sind entscheidend: Ohne sie liefert vLLM Tool-Aufrufe nur als Text, und das Framework muss selbst parsen – fehleranfällig und langsam. Der Parser muss zum Modell passen (hermes für Qwen, llama3_json für Llama 4, mistral für Mistral).

Der Endpunkt ist OpenAI-kompatibel, du kannst also jeden Client auf http://localhost:8000/v1 zeigen lassen. Für zwei GPUs ergänzt du --tensor-parallel-size 2; bei mehr als vier Karten wird der Gewinn durch NVLink-Bandbreite begrenzt.

Setup 3: LangGraph-Agent mit Docker Compose

Ein vollständiger Stack besteht aus Modell-Server, Agent-Service, Postgres für Checkpoints und Redis für den Task-Queue. So sieht eine produktionsnahe docker-compose.yml aus:

services:
  vllm:
    image: vllm/vllm-openai:latest
    command: ["--model","Qwen/Qwen3-32B","--max-model-len","32768",
              "--enable-auto-tool-choice","--tool-call-parser","hermes"]
    deploy:
      resources:
        reservations:
          devices: [{driver: nvidia, count: 1, capabilities: [gpu]}]
    volumes: ["hf:/root/.cache/huggingface"]
    ports: ["8000:8000"]

  agent:
    build: ./agent
    environment:
      OPENAI_BASE_URL: http://vllm:8000/v1
      OPENAI_API_KEY: dummy
      POSTGRES_URI: postgresql://agent:secret@postgres:5432/agent
      REDIS_URL: redis://redis:6379
    depends_on: [vllm, postgres, redis]
    ports: ["8080:8080"]

  postgres:
    image: postgres:17
    environment: {POSTGRES_USER: agent, POSTGRES_PASSWORD: secret, POSTGRES_DB: agent}
    volumes: ["pgdata:/var/lib/postgresql/data"]

  redis:
    image: redis:7-alpine
    command: ["redis-server","--appendonly","yes"]

volumes: {hf: {}, pgdata: {}}

Der Agent selbst ist in LangGraph erstaunlich kompakt. Wichtig ist der Checkpointer, damit ein Lauf nach einem Neustart fortgesetzt werden kann:

from langgraph.graph import StateGraph, END
from langgraph.checkpoint.postgres import PostgresSaver
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool

@tool
def read_file(path: str) -> str:
    """Liest eine Datei aus dem Workspace."""
    with open(f"/workspace/{path}") as f:
        return f.read()[:20000]

llm = ChatOpenAI(model="agent-model",
                 base_url="http://vllm:8000/v1",
                 api_key="dummy",
                 temperature=0.1)
llm_with_tools = llm.bind_tools([read_file])

def agent_node(state):
    return {"messages": [llm_with_tools.invoke(state["messages"])]}

builder = StateGraph(dict)
builder.add_node("agent", agent_node)
builder.set_entry_point("agent")
builder.add_conditional_edges("agent",
    lambda s: "tools" if s["messages"][-1].tool_calls else END)
builder.add_node("tools", ToolNode([read_file]))
builder.add_edge("tools", "agent")

with PostgresSaver.from_conn_string(POSTGRES_URI) as cp:
    cp.setup()
    graph = builder.compile(checkpointer=cp)

Der temperature=0.1-Wert ist kein Zufall: Agenten brauchen deterministische Tool-Aufrufe. Bei Werten über 0.4 steigt die Rate ungültiger JSON-Argumente messbar an.

CrewAI und AutoGen in der Praxis

CrewAI reduziert den Setup-Aufwand drastisch. Ein Recherche-Crew mit zwei Rollen braucht keine 30 Zeilen:

from crewai import Agent, Task, Crew, LLM

llm = LLM(model="openai/agent-model",
          base_url="http://vllm:8000/v1",
          api_key="dummy")

researcher = Agent(role="Rechercheur",
    goal="Fakten zu {thema} sammeln",
    backstory="Analytischer Recherche-Spezialist",
    llm=llm, max_iter=8, allow_delegation=False)

writer = Agent(role="Redakteur",
    goal="Fakten zu einem Report verdichten",
    backstory="Technischer Redakteur",
    llm=llm)

crew = Crew(agents=[researcher, writer], tasks=[
    Task(description="Recherchiere {thema}", agent=researcher,
         expected_output="Stichpunktliste mit Quellen"),
    Task(description="Schreibe 800 Wörter", agent=writer,
         expected_output="Markdown-Report")])
print(crew.kickoff(inputs={"thema": "GPU-Hosting 2026"}))

max_iter=8 ist eine harte Kostenbremse. Ohne dieses Limit drehen Agenten bei unklaren Zielen gerne 30 Runden – und verbrauchen dabei mehr Token als der gesamte Rest des Tages. Setze max_iter und max_rpm immer explizit.

AutoGen eignet sich für Review-Schleifen. Ein GroupChat mit Coder, Reviewer und einem UserProxyAgent, der Code im Docker-Container ausführt, findet Fehler zuverlässiger als ein einzelner Agent. Der Preis: Jede Runde ist ein vollständiger LLM-Call mit dem gesamten bisherigen Verlauf im Kontext.

Tool-Integration und Sandboxing

Sobald ein Agent Shell-Befehle oder Code ausführen darf, ist Sandboxing nicht optional. Prompt Injection über eine gelesene Webseite oder Datei kann sonst beliebige Befehle auf dem Host auslösen.

Docker mit restriktiven Flags: --read-only --cap-drop=ALL --security-opt=no-new-privileges --network=none --memory=2g --pids-limit=256
gVisor oder Firecracker: eigener Kernel-Namespace, deutlich stärkere Isolation als Standard-runc, etwa 5 bis 15 % Performance-Verlust
Egress-Filtering: Ausgehender Traffic nur über einen Proxy mit Allowlist – verhindert Datenabfluss über curl
Kurzlebige Container: ein Container pro Task, danach docker rm -f. Keine Persistenz zwischen Läufen
Tool-Allowlist: Nur explizit registrierte Tools sind aufrufbar, kein generisches execute_shell

Ein Sandbox-Runner in Compose sieht so aus:

docker run --rm \
  --network=none --read-only \
  --tmpfs /tmp:rw,size=512m \
  --cap-drop=ALL --security-opt=no-new-privileges \
  --memory=2g --cpus=2 --pids-limit=256 \
  -v /srv/agent-workspace:/workspace:rw \
  python:3.12-slim python /workspace/task.py

Für Dateisystem-Zugriffe gilt das Prinzip der minimalen Rechte: Der Agent sieht genau ein Workspace-Verzeichnis, niemals /etc, ~/.ssh oder Docker-Socket. Ein gemounteter Docker-Socket ist gleichbedeutend mit Root auf dem Host.

Observability mit Langfuse

Ohne Tracing debuggst du Agenten blind. Langfuse ist selbst hostbar und läuft in vier Containern:

git clone https://github.com/langfuse/langfuse.git
cd langfuse
docker compose up -d
# UI auf http://localhost:3000

Die Anbindung an LangGraph erfolgt über einen Callback-Handler. Damit siehst du jeden LLM-Call mit Prompt, Antwort, Token-Zahl, Latenz und Kosten:

from langfuse.langchain import CallbackHandler

handler = CallbackHandler()
graph.invoke({"messages": [("user", "Analysiere das Log")]},
             config={"callbacks": [handler],
                     "configurable": {"thread_id": "run-42"}})

Die wichtigsten Metriken im Betrieb: Token pro Task (steigt bei Kontext-Wachstum schnell um Faktor 5), Tool-Fehlerrate (über 10 % deutet auf ein zu schwaches Modell oder unklare Tool-Beschreibungen hin), Schleifenlänge (mehr als 15 Iterationen bedeutet meist ein unerreichbares Ziel) und Time-to-first-token (bei vLLM unter 400 ms erstrebenswert).

Ergänzend lohnt ein Prometheus-Exporter für GPU-Auslastung und VRAM. Ein Agent, der plötzlich dreimal so lange braucht, hat oft nur ein anderes Modell in den VRAM gedrängt und swappt jetzt gegen System-RAM.

Sicherheit, Kostenkontrolle und Recht

Drei Risiken dominieren den Betrieb: Prompt Injection, unbegrenzte Kosten und Datenschutz. Gegen Injection hilft Instruction-Hierarchy – System-Prompts haben Vorrang, Inhalte aus Tools werden als Daten markiert und nie als Anweisung interpretiert. Zusätzlich: Tool-Aufrufe mit Seiteneffekten (E-Mail senden, Dateien löschen, Geld überweisen) immer über Human-in-the-Loop freigeben.

Kostenkontrolle bei selbst gehosteten Modellen ist einfacher als bei APIs, aber nicht trivial. Setze harte Limits: maximaler Kontext pro Call (z. B. 32k), maximale Iterationen pro Task (10), maximaler Token-Verbrauch pro Nutzer und Tag. Ein Budget-Check im Agent-Graph vor jedem LLM-Call kostet nichts und verhindert Endlosschleifen.

Posten	Lokal (RTX 5090)	Hetzner GEX44	Cloud-API
Anschaffung	2.400 €	0 €	0 €
Monatlich fix	~15 € Hosting	184 €	0 €
Strom (24/7, 0,30 €/kWh)	~95 €	inklusive	—
100 Mio. Token/Monat	0 €	0 €	~600 €
Break-even	~4 Monate	~5 Monate	—

Rechtlich gilt: Bei eigener Hardware verlassen personenbezogene Daten das Haus nicht. Betreibst du den Agenten für Kunden, brauchst du trotzdem ein Verzeichnis der Verarbeitungstätigkeiten, eine Löschfrist für Konversationslogs und – bei Modellen mit offenen Gewichten – einen Blick auf die Lizenz. Apache-2.0 (Qwen3, Mistral) ist unkritisch, Llama-Community-Lizenzen haben Schwellenwerte ab 700 Millionen monatlichen Nutzern.

Skalierung, Reverse Proxy und Betrieb

Ein einzelner Agent-Service reicht bis etwa 20 gleichzeitige Sessions. Danach skalierst du horizontal: mehrere Agent-Container hinter Traefik oder Caddy, gemeinsamer Postgres-Checkpointer, Redis als Queue. Der Modell-Server bleibt der Flaschenhals und wird zuletzt skaliert.

# /etc/caddy/Caddyfile
agent.hostazar.example {
    reverse_proxy agent:8080
    encode zstd gzip
    header {
        Strict-Transport-Security max-age=31536000
        X-Content-Type-Options nosniff
    }
}

Für den Modell-Server setzt du --max-num-seqs passend zum VRAM. Bei 32 GB und 32k Kontext sind acht parallele Sequenzen realistisch; mehr führen zu VRAM-Fragmentierung und OOM-Kills. Überwache das mit nvidia-smi dmon -s mu.

Backups betreffen nur Postgres (Checkpoints, Traces) und die Workspace-Volumes. Modell-Gewichte lassen sich jederzeit neu ziehen – sie gehören nicht ins Backup. Ein pg_dump per Cron in ein S3-kompatibles Bucket kostet bei 20 GB Datenvolumen unter 2 € im Monat.

Für Updates gilt: Modell-Server und Agent-Framework getrennt deployen. Ein neues Modell bedeutet oft andere Tool-Call-Parser und damit andere Antwortformate – teste mit einer Canary-Instanz auf zehn Prozent des Traffics, bevor du umschaltest.

FAQ

Welches Modell eignet sich 2026 am besten für selbst gehostete Agenten?

Für 24 GB VRAM ist Qwen3-32B in Q4-Quantisierung der beste Kompromiss aus Tool-Calling-Zuverlässigkeit und Geschwindigkeit. Mit 48 GB VRAM nimmst du ein 70B-Modell in Q4 – die Fehlerrate bei mehrstufigen Tool-Aufrufen sinkt deutlich. Modelle unter 14B Parameter brechen bei Agenten mit mehr als drei Tools regelmäßig ein.

Reicht Ollama für den produktiven Betrieb?

Für einzelne Nutzer und Entwicklung ja. Sobald mehrere Agent-Sessions parallel laufen, ist vLLM durch PagedAttention drei- bis achtmal durchsatzstärker. Der Umstieg ist einfach, weil beide eine OpenAI-kompatible API anbieten – du änderst nur die Base-URL.

Wie verhindere ich, dass Agenten unkontrolliert Token verbrennen?

Drei Limits gehören in jede Produktionskonfiguration: max_iter pro Agent (8 bis 12), maximaler Kontext pro Call (32k), und ein Tagesbudget pro Nutzer. Zusätzlich hilft ein Timeout von 300 Sekunden pro Task – Endlosschleifen laufen sonst stundenlang.

Ist selbst hosten günstiger als eine Cloud-API?

Ab etwa 30 bis 50 Millionen Token pro Monat ja. Darunter ist die API meist billiger, weil du keine 2.400 € Hardware und keinen Administrationsaufwand trägst. Bei einer gemieteten GPU (184 €/Monat) liegt der Break-even bei rund 30 Millionen Token monatlich.

Welche Lizenzfragen muss ich bei offenen Modellen beachten?

Apache-2.0-Modelle wie Qwen3 und Mistral sind kommerziell uneingeschränkt nutzbar. Llama-Modelle haben eine Community-Lizenz mit Namensnennungspflicht und einer Nutzerschwelle ab 700 Millionen monatlich aktiven Nutzern. Prüfe die Lizenz vor dem Produktivbetrieb, nicht danach.