Unsere lokale Infrastruktur für AI Agents: Einleitung
Large Language Models (LLM) dominieren seit über vier Jahren die (Berichterstattung in der) IT Branche. Seit 2025 heißt der Trend "Agentic AI". Währenddessen warten Unternehmen noch auf einen nachweisbaren Return on Investment Fehler Erfahrungen bei der Anwendung von KI Agenten machen.
In diesem Artikel beschreiben wir unser Minimum Viable Product (MVP), mit dem wir den Einsatz von GenAI und KI Agenten auf eigener Infrastruktur für sensible Daten evaluieren.
Inhaltsverzeichnis
- Motivation und Zielsetzung
- Komponenten und Anforderungen
- Lösungsansatz
- Zusammenfassung
- Nächste Schritte
Motivation und Zielsetzung
Zum ersten Mal, seit "Agentic AI" ein Ding geworden ist, arbeiten wir wieder in großen Softwareentwicklungsprojekten, wo unsere Arbeit von der Unterstützung durch AI Agents profitieren könnte. Derartiger Einsatz von AI ist nicht unumstritten: während manche von x-facher Beschleunigung der Velocity berichten, sprechen andere von Glücksspiel, Sicherheitsrisiko und sinkender Wartbarkeit.
In den einschlägigen Communities auf Reddit oder Hacker News findet man derzeit praktisch täglich einen neuen Thread darüber, wie AI Agents das Leben des Posters vollkommen verändert haben und er nur mehr auf Aruba Cocktails trinkt, während seine Agents im Stundentakt Software-Unicons aus dem Boden stampfen. Die Stimmung in den Kommentaren ist dann oft etwas differenzierter.
Wir möchten uns nun selber ein Bild davon machen, was es heißt, AI Agents in der Softwareentwicklung einzusetzen. Unser Augenmerk liegt dabei darauf, die Kontrolle über die Datenverarbeitung zu behalten.
Unser Ziel: ein MVP für LLM-Infrastruktur, die uns bei vollständiger Kontrolle über die Datenverarbeitung den Einsatz von AI Agents ermöglicht
Das ist bei Drittanbietern, ungeachtet deren AGBs, grundsätzlich nicht gegeben. Wenn wir die Vertraulichkeit von Quellcode und Architektur(dokumentation) sicherstellen wollen, brauchen wir also wohl oder übel unsere eigene Infrastruktur.
Komponenten und Anforderungen
Unser Ziel ist eine minimale Infrastruktur, die von uns kontrolliert wird und es uns erlaubt, KI-Inferenz mit LLMs durchzuführen. Dazu braucht es vier Komponenten.
-
Rechenleistung für KI-Inferenz (aka Server).
Um eine LLM für Inferenz zu betreiben, braucht es Rechenleistung (no na ned). Die Hardwareanforderungen für KI-Inferenz betreffen vornehmlich Grafikkarten-Ressourcen: Grafikkarten (GPU) sind durch ihre Architektur besser für Inferenz geeignet, als das traditionelle Duo von Prozessor (CPU) und Systemarbeitsspeicher (RAM). Den Flaschenhals für Inferenz stellt üblicherweise der Arbeitsspeicher der GPU (VRAM) dar. Vereinfacht gesagt: je mehr VRAM, desto komplexer das LLM, das effizient auf der Hardware ausgeführt werden kann. Im Gegensatz zu traditionellen Anwendungsservern, wo CPU und RAM das Maß der Dinge sind, suchen wir eine Maschine, die uns möglichst viel VRAM bietet. -
Laufzeitumgebung, um LLMs auszuführen (aka Model Runner).
Neben der in Punkt 1 gelisteten Rechenleistung benötigt KI-Inferenz auch noch die Software, um ein LLM auszuführen: einen Model Runner. Unsere Anforderung ist, dass der Model Runner auf Linux ausgeführt werden kann und die Hardware unterstützt, die wir als Server auswählen. Wir haben noch kein Konzept davon, wie wir LLMs in unseren Softwareentwicklungsprozess integrieren wollen. Deswegen suchen wir eine weit verbreitete Lösung, die uns viele Integrationsmöglichkeiten bietet. Der Model Runner soll einfach zu konfigurieren sein, weil das Betreiben einer eigenen LLM für uns Neuland ist. -
Netzwerkanbindung, um Daten zwischen LLM und Konsument auszutauschen (Verbindung).
Haben wir Hard- und Software, um ein LLM auszuführen, müssen wir noch (sicher) darauf zugreifen können. Wird das LLM auf dem Arbeitsgerät lokal ausgeführt, ist dieser Schritt trivial. Läuft es auf einem Remote-Server, setzen wir voraus, dass die ausgetauschten Daten (unsere Prompts und die Antwort darauf) für Dritte nicht einsehbar sind. -
Integration in die Arbeitsumgebung (Benutzeroberfläche).
Nachdem wir ein LLM ausführen und darauf zugreifen können, müssen wir es noch in unsere Arbeitsprozesse integrieren. Dies geschieht üblicherweise über eine graphische Benutzeroberfläche; derzeit meist in Form eines Chat-UIs. Dabei wollen wir zwei Anwendungsfälle abdecken: den integrierten Einsatz in einer Entwicklungsumgebung sowie ein eigenständiges Interface für Prompts unabhängig von einem spezifischen Softwareprojekt.
Lösungsansatz
Server
Unsere Arbeitsgeräte sind "klassische" Laptops mit Spezifikationen aus der Pre-GenAI Ära. Soll heißen: ungeeignet, um LLMs vollständig lokal auszuführen. Daher benötigen wir neue Hardware.
Bevor wir uns diese neue Hardware beschaffen, müssen wir uns wie immer die grundsätzliche Frage stellen: On Premise oder Cloud? Da wir vornehmlich daran interessiert sind, zu experimentieren, erscheint die Investition in eigene Hardware unverhältnismäßig (insbesondere im Angesicht der Hype-bedingten Hardwarepreise). Wir mieten also einen Server.
Wir mieten einen Root-Server mit 20GB VRAM für 184€ / Monat bei unserem bestehenden Hosting-Provider.
Der Hosting-Provider unseres Vertrauens betreibt seine Server in Deutschland, ist ISO-zertifiziert (ja, wir wissen: über deren Wert kann man streiten) und bietet leistbare GPU-Server an. Das erfüllt unsere Anforderungen, deswegen haben wir nicht lange bezüglich der Anbieter recherchiert. Wir mieten einen Root-Server mit folgenden Spezifikationen:
- GPU: NVIDIA RTX 4000 SFF Ada-Generation (20GB VRAM)
- RAM: 64GB DDR4
- CPU: Intel Core i5-13500
- SSD: 2x 1.92TB NVMe
Die Hardware ist (für Inferenz) nicht besonders üppig dimensioniert, aber wir wollen zu Beginn nur ein MVP. Kostenpunkt: 184 Euro pro Monat (zzgl. USt.).
Model Runner
Da wir Modelle auf einem Server ausführen, suchen wir eine Lösung, die ohne graphische Benutzeroberfläche administriert werden kann und eine Schnittstelle für Remote-Verbindung ermöglicht. Software wie LM Studio, die LLMs lokal ausführen und via GUI gesteuert werden, fallen damit weg.
Aus der Menge an verbleibenden Lösungen stechen drei große Namen hervor, die gut integrierbare APIs bieten: Ollama, llama.cpp und vLLM.
Wir verwenden Ollama (ohne deren Cloud-Angebote) um LLMs auszuführen.
Wir sehen von vLLM und llama.cpp ab, da beide augenscheinlich hohe Komplexität in der initialen Konfiguration aufweisen. Um erste Erfahrungen zu sammeln, erscheint uns die Lernkurve hier zu steil.
Ollama wurde gestartet, um diese Einstiegshürde zu senken. Unter der Haube verwendet Ollama llama.cpp, kapselt jedoch dessen Konfiguration ab und beschränkt sich auf einfaches Setup mit wenig Konfigurationsnotwendigkeit. Das bietet weniger Spielraum zur Optimierung und Anpassung, ist aber perfekt für unseren Einstieg.
Verbindung
Ollama öffnet ab Werk eine HTTP API, die von anderen Anwendungen konsumiert werden kann. Per Default horcht diese auf Port 11434 von localhost.
Das bringt uns nun im Remote-Server-Betrieb zuerst einmal herzlich wenig. Wir haben zwei Möglichkeiten, auf die Ollama API zuzugreifen: entweder wir machen die API öffentlich, oder wir stellen eine Verbindung her, die es uns erlaubt, die Adresse localhost:11434 (aus Sicht unseres Servers) zu erreichen.
Wir verwenden SSH Tunneling, um sicher auf die Ollama-API unseres Servers zugreifen zu können
Die API öffentlich zu exponieren macht ein Fass mit Sicherheitsproblemen auf. Diese abzudichten ist uns für ein MVP zu mühsam. Stattdessen verwenden wir SSH Port Forwarding, um Netzwerkverkehr von einem spezifischen Port unserer persönlichen Rechner via einen verschlüsselten Tunnel auf den lokalen Ollama-Port des Servers zu leiten. Diese Variante bietet eine sichere Verbindung bei geringem zusätzlichen Konfigurationsaufwand und hohem Komfort bei der späteren Integration mit Werkzeugen auf unseren Rechnern.
Integration
Die Verwendung von Ollama und dessen HTTP API bietet uns eine Vielzahl von Integrationsmöglichkeiten auf unseren Arbeitsgeräten.
Zum Einstieg möchten wir KI Agenten bzw. LLM auf zwei Arten in unsere Arbeitsprozesse integrieren: einerseits in unserer Entwicklungsumgebung (IDE), wo AI Agents direkten Zugriff auf unsere Codebasis erhalten, und andererseits als das von ChatGPT, Claude oder Le Chat gewohnte Chat-Interface für allgemeine Fragestellungen.
Wir werden Cline als Plugin verwenden, um unsere AI Agents in den Entwicklungsprozess zu integrieren.
Weil wir unsere gewohnte Entwicklungsumgebung (zumindest vorläufig) noch weiter verwenden wollen, bedienen wir uns Plugins, um AI Agents in unsere IDE zu holen. Die Auswahl ist groß. Jeder LLM-Anbieter bringt mittlerweile eine eigene Oberfläche heraus, um LLMs zu Agenten zu machen. Unsere Wahl fällt, in Ermangelung umfangreicher Erfahrung, mehr oder weniger willkürlich auf Cline. Die Konfigurierbarkeit von Cline scheint einsteigerfreundlich und die Meinungen zum Tool sind generell positiv.
Für ein alleinstehendes Chat Interface starten wir mit AnythingLLM.
Als alleinstehendes Chat-Interface erscheint AnythingLLM attraktiv, weil der Quellcode offen ist, es bekannte Features aus gängigen Interfaces bietet und dabei einfach zu installieren scheint.
Zusammenfassung
In diesem Beitrag haben wir unseren Plan für ein Minimum Viable Product einer lokalen LLM-Infrastruktur beschrieben. Unser Ziel ist es, AI Agents in unseren Softwareentwicklungsprozess zu integrieren - bei vollständiger Kontrolle über die Datenverarbeitung.
Unser Ansatz besteht aus vier Komponenten: einem gemieteten GPU-Server, Ollama als Model Runner, SSH-Tunneling für sichere Remote-Verbindung und einer Kombination aus Cline sowie AnythingLLM für die Arbeitsumgebung.
Diese Infrastruktur ermöglicht es uns, mit KI-Agenten zu experimentieren, ohne sensible Daten an Drittanbieter preiszugeben oder in teure Hardware zu investieren. Die Kosten von 184€/Monat sind für ein MVP vertretbar und bieten uns die Flexibilität, verschiedene Einsatzszenarien zu evaluieren.
Nächste Schritte
Das war natürlich erst der Anfang. Im nächsten Beitrag zeigen wir euch, wie wir diesen Plan in die Tat umsetzen. Bleibt dran!