Lokale KI zum Schutz sensibler Informationen

LLMs und Agentic Coding

Wer einmal eine Programmieraufgabe mithilfe eines Coding-Agenten gelöst hat, merkt sofort: Von nun an will man nicht mehr ohne arbeiten. Mit etwas Übung entsteht aus wenigen Anforderungen schnell lauffähiger Code. Tests mit bestehendem Quellcode zeigen, dass Coding-Agenten auch bei Wartung und Weiterentwicklung viele Aufgaben angenehmer und schneller erledigen lassen. 

Die Leistungsfähigkeit der Agenten beruht hauptsächlich auf großen Sprachmodellen (LLMs): Das gewählte Modell erhält die relevanten Code-Snippets sowie fachliche Anforderungen, um diese im Sinne der Aufgabe zu verarbeiten. Der größte Vorteil entsteht dabei im Zusammenspiel mit den jeweils modernsten, größten, auf Coding trainierten LLMs. Dafür geeignete Hardware-Ressourcen findet man fast ausschließlich in der Cloud – direkt beim Urheber oder in leicht abgewandelter Form bei alternativen KI-Providern. Dabei sind die Urheber der LLMs darauf angewiesen, die bereitgestellten Informationen für das Training ihrer nächsten Modellgeneration zu nutzen – ein Wettlauf um die beste KI, in dem jeder Datensatz zählt. Was aber geschieht, wenn ein Projekt diesen freizügigen Umgang mit teils sensiblen Informationen nicht zulässt?

KI-unterstützte Entwicklung ohne Cloud

Wir bei Accso haben uns das Ziel gesetzt, AI-Native zu arbeiten: Coding-Agenten sollen ganz selbstverständlich an unseren Projekten mitentwickeln. In vielen Kundenprojekten gibt es allerdings harte Datenschutz- und Compliance-Anforderungen – sprich: Informationen des Projekts dürfen den geschützten Raum nicht verlassen. Cloud-basierte LLMs sind damit oft keine Option.

Die Alternative: Wir oder unsere Kunden betreiben die LLMs selbst. Wenn wir ausschließen wollen, dass Agenten die Projektinformationen in die Cloud schicken, müssen wir klären:

• Welche LLM-Größen sind lokal realistisch?
• Reicht das für Agentic Coding oder nur für Code Completion?
• Wo liegen Engpässe: RAM, Bandbreite, Kontextgröße, Tool-Aufrufe?

Voraussetzungen für Agentic Coding

Klassische Code Completion ist relativ genügsam: ein kleineres Modell, das viel Code gesehen hat, einige tausend Tokens Kontext – fertig. Für Agentic Coding liegen die Anforderungen deutlich höher. Das ist qualitativ etwas anderes als „geben Sie mir bitte die nächsten 20 Zeilen Code".

Der Agent muss:

• Projektstrukturen verstehen (Monorepos, Microservices, Build-Systeme)
• Coding Conventions, Frameworks und Plattformen kennen
• fachliche Anforderungen zumindest grob verstehen
• nicht nur „nebenher" arbeiten, sondern:
• Dateien lesen/verändern
• Verzeichnisse durchsuchen
• Builds und Tests starten
• weitere Tools z.B. via MCP aufrufen.

Für diese vielfältigen Aktivitäten der Coding-Agenten sind anspruchsvolle Tool-Aufruf-Zyklen zwischen Agenten und LLM notwendig – teils mit großem Kontext (Quellcode-Dateien, Dokumentation, Logs, Chat-Historie) oder Retries, wenn etwas nicht klappt. Das erhöht die Komplexität enorm.

LLM-Grundlagen: Größe, Quantisierung, Formate

Möchte man diese Abläufe nun auf eigener Hardware abbilden, statt wie gewohnt in der Cloud, braucht es gewisse Voraussetzungen. Damit wir die Hardware-Frage sinnvoll diskutieren können, kurz der technische Unterbau:

Parametergrößen und Arbeitsspeicher: das „B“ im Namen

LLMs werden grob über die Anzahl ihrer Parameter klassifiziert – namentlich erkennbar an Bestandteilen wie „-7B“, „-14B“, „-32B“ etc. Die Anzahl Parameter bietet ein Maß für die Menge abrufbaren Wissens. Das „B" steht dabei für das englische „Billion", also Milliarden Parameter. Gängige Größen sind dabei 7B bis hin zu 70B+. Außerdem gibt es so genannte Mixture-of-Experts-Modelle (MoE), bei denen zu einem Zeitpunkt nur Teile der insgesamt verfügbaren Parameter aktiv sind (bspw. „-30b-4e“).

Guides von Herstellern wie Apple betonen: Die eigentliche Limitierung beim lokalen Einsatz ist, wie viele dieser Parameter inklusive Quantisierung mit der verfügbaren Speichermenge sinnvoll verarbeitet werden können.

Die Originale der Sprachmodelle verwenden meist 16 Bit pro Parameter („FP16"). Daraus resultiert folgende Daumenregel für den Bedarf an Arbeitsspeicher:

• 1B Parameter → ca. 2 GB für die reinen Gewichte
• 8B → ca. 16 GB
• 30B → ca. 60 GB

Bei leistungsstarken Modellen fällt der Speicherbedarf für die ausführende Software und unterstützende Funktionen kaum ins Gewicht.

Quantisierung: RAM und Rechenleistung sparen zum Preis der Qualität

Um solche Modelle auf „normaler" Hardware zu betreiben, wird quantisiert. Quantisierung ermöglicht, das in den Parametern verkörperte Wissen mit weniger Speicherbedarf und Rechenleistung zu nutzen – zum Preis einer schlechteren Qualität der Antworten. Die Gewichte werden von z. B. 16 Bit auf 4–8 Bit komprimiert. MLX und andere Frameworks unterstützen entsprechende Verfahren und bieten quantisierte Varianten vieler gängiger Modelle an.

Beispiel:

• 16 Bit → 2 Byte pro Gewicht
• 4 Bit → 0,5 Byte pro Gewicht

Damit reduziert sich der Speicherbedarf eines 1B-Modells von ca. 2 GB auf ca. 0,5 GB.
Der Preis dafür:

• etwas schlechtere Genauigkeit
• mehr Grammatik- und Logikfehler
• erhöhte Halluzinationstendenz

Für einfache Code Completion kann ein gut quantisiertes 7–14B-Code-Modell absolut ausreichend sein; für komplexe Agenten-Aufgaben beeinträchtigen sprachliche Fehler in der Ausgabe eines LLMs die Zuverlässigkeit der Werkzeugaufrufe. Teils kann man kleine Modelle aber mit strikten Vorgaben zur Zusammenarbeit mit dem Agenten „überreden", wo große LLMs selbstständig das korrekte Format wählen.

Model-Formate und Inferenz-Runtimes

Aber nicht nur der Speicherbedarf der Parameter allein bestimmt das Verhältnis von Leistung zu Hardware-Ressourcen. Die Anwendung der Parameter – „Inferenz" genannt – benötigt Rechenleistung entsprechend der Anzahl und Größe der Parameter. Viele Parameter hoher Genauigkeit bedeuten einen hohen Bedarf an parallel arbeitenden Rechenkernen. Dabei können CPUs, GPUs und NPUs (Neural Processing Units) kombiniert werden. Je nach Art der eingesetzten Hardware ermöglichen herstellerspezifische Formate der LLMs die beste Ausnutzung der Hardware.

Die Gewichte eines LLMs liegen in unterschiedlichen Formaten vor – je nach Runtime, Anwendungsfall und Hardware-Stack:

• GGUF – das Format rund um llama.cpp, optimiert für eine angepasste Nutzung verfügbarer CPU/GPU-Kerne
• MLX – Apples eigenes Format bzw. Stack für Apple Silicon, nutzt Unified Memory und GPU/NPU effizient
• PyTorch/Transformers-Checkpoints – generisches Format, auf dem Frameworks wie vLLM oder Text Generation Inference (TGI) aufsetzen
• NVIDIA-optimierte Formate – z. B. TensorRT-LLM-Engines, hochoptimiert für NVIDIA-GPUs, Tensor Cores und CUDA
• AMD-Stack – mit ROCm, vLLM/TGI, die speziell für AMD Instinct und Radeon Pro optimiert sind

Mit den verschiedenen Softwareprodukten für LLM-Inferenz lässt sich aus jeder Hardware das jeweilige Optimum an KI-Leistung herauszuholen. Dabei kommt es allerdings auf die richtige Kombination von LLM-Version und Größe, Kodierung, Quantisierung und Engine an. Denn Architekturmerkmale der LLMs und die verwendete Quantisierung erfordern eine entsprechende Unterstützung. Open Weight Modelle sind in verschiedenen Varianten, Größen und Kodierungen verfügbar. Je nach Anwendungsfall und eingesetzter Hardware lässt sich mit Größe und Kodierung die verfügbare Hardware ausnutzen. Daneben gilt es, für jedes Sprachmodell eine geeignete Kombination von Parametern und Engine zu finden, um die erwartbare Performance zu erreichen.

Hardware-Bedarfe der Coding-Modelle: von Completion bis Agent

Nachdem wir das Basiswissen für die benötigte Hardware geschaffen haben, widmen wir uns nun den Bedarfen der für Code Completion und Agentic Coding benötigten Modelle. 

Code Completion mit kleinen Code-Modellen (<10B)

Nahezu jeder große Anbieter (OpenAI, Google, Anthropic, Qwen, Mistral, …) bietet Varianten seiner Modelle an, die explizit auf Code trainiert bzw. feinjustiert wurden. Das macht Sinn: Programmiersprachen sind streng strukturiert; das hilft den Modellen, korrekten Code zu generieren.

Für reine Code Completion reichen oft Modelle mit 3–7B Parametern:

• speziell auf Code trainiert („Coder", „Code", „Instruct"-Varianten)
• mit moderatem Kontext (8–16k Tokens)
• aggressiv quantisiert (4–6 Bit), um sie lokal schnell genug laufen zu lassen

Das KI-Plugin Continue.dev lässt sich mit verschiedenen Modellen für unterschiedliche Aufgaben konfigurieren. So kann man bei Code Completion Performance gewinnen und Speicher sparen.

Agentic Coding braucht mehr „Gehirn“ und mehr Kontext

Sobald wir aber einen Coding Agent mit der passenden Hardware ausstatten wollen, der Aufgaben selbstständig löst, kippt die Anforderung:

• Weltwissen über Frameworks, Tools, Patterns, typische Fehlerbilder
• Bessere Planung und „Multi-Step Reasoning"
• Großes Kontextfenster: gleichzeitiger Blick auf Lösungsstrategien, Prompt, Quellcode, Kommando-Ausgaben, Chat-Historie

Das heutige Angebot an Open Weight LLMs bietet auch für Coding Agents geeignete Kandidaten. Je nach verfügbarer Hardware bemisst sich das erreichbare Potential. Zu beachten sind die grundsätzliche Eignung für Coding, für Werkzeug-Aufrufe und für genügend große Kontexte. Gegenüber den Frontier Models in der Cloud stellen lokale Lösungen immer einen Kompromiss dar. Allerdings dürften sich Hardware-Investitionen im Vergleich zu Cloud-basierten Lösungen in vielen Fällen rechnen.

LLMs und Agentic Coding: Tool-Calling-Qualität

Mit dem Einsatz von LLMs für Coding Agents kommt eine weitere Abhängigkeit hinzu: Coding Agents bieten dem LLM Werkzeuge an, deren Aufrufe das LLM formuliert. LLMs sind für diese Qualifikation speziell trainiert. In der Praxis funktionieren Kombinationen von LLM und Coding Agent unterschiedlich gut. Größere Modelle beherrschen Werkzeugaufrufe typischerweise zuverlässiger als kleine, einige Agenten führen Tool-Aufrufe zuverlässiger durch als andere. In manchen Fällen hilft die Konfiguration des Sprachmodells für strukturierte Antworten.

Fazit

Mit der passenden Hardware lässt sich die benötigte Performance der LLMs sicherstellen, auch wenn ein großes Kontextfenster aktuell die Auswahl noch sehr einschränkt. Ständig kommen neue, leistungsfähigere Modelle heraus, die die zu beobachtenden Unzulänglichkeiten perspektivisch durch neue Features und LLMs beseitigen werden.

Nach unzähligen Recherchen bietet Accso heute schon seinen Kunden angepasste, lokale KI-Lösungen an und befreit sie damit von der Sorge, die sensible Daten zur Verarbeitung mit KI in die Cloud senden zu müssen. Lokale KI-Lösungen bieten einen wichtigen Beitrag zur Digitalen Souveränität und zum Datenschutz. Nebenbei lässt sich mit lokalen Lösungen der Strombedarf senken – Stichwort Green IT. Mit dem Angebot lokaler KI-Lösungen unterstreicht Accso sein Engagement für nachhaltige IT-Lösungen.

Sie möchten Agentic Coding in Ihrem Unternehmen einsetzen, haben aber Datenschutz- oder Compliance-Anforderungen? Sprechen Sie uns an. Wir beraten Sie gerne zu lokalen KI-Lösungen und unterstützen Sie bei der Implementierung datenschutzkonformer Entwicklungsumgebungen.