Ich möchte Codex langfristig zumindest teilweise durch eine lokale KI ersetzen. Die Motivation dahinter ist für mich inzwischen ziemlich klar: Ich möchte weniger von externem Kontingent abhängig sein, bestimmte Daten innerhalb meiner eigenen Infrastruktur verarbeiten können und vor allem die Möglichkeit bekommen, Agenda-Aufgaben auf Rechenleistung abarbeiten zu lassen, die mir selbst gehört. Schwieriger ist die nächste Frage, denn ein Rechner, auf dem irgendein lokales Sprachmodell startet, erfüllt diese Anforderungen noch lange nicht.
Ein echter Codex-Ersatz müsste in meinem Alltag deutlich mehr können als nur Code erzeugen. Er muss größere Repositories verstehen, Dateien selbstständig verändern, Werkzeuge benutzen, Builds starten, Tests ausführen, Fehler analysieren und über längere Aufgaben hinweg stabil arbeiten können. Zusätzlich möchte ich mehrere Arbeitsstränge parallelisieren und langfristig möglicherweise unterschiedliche Modelle für Umsetzung und Testing einsetzen.
Damit verändert sich die Frage nach der Hardware erheblich. Ich suche keinen Rechner für gelegentliche lokale KI-Experimente, sondern perspektivisch eine technische Grundlage für einen Teil meines agentischen Entwicklungsprozesses.
Genau deshalb habe ich die Hardware bisher auch noch nicht einfach gekauft. Ein zu kleiner Rechner würde mein eigentliches Ziel verfehlen, während eine sehr teure Maschine wenig sinnvoll wäre, wenn sie für meinen späteren Workflow an der falschen Stelle dimensioniert ist.
Das Modell allein bestimmt die Hardware noch nicht
Bei lokalen KI-Systemen wird verständlicherweise sehr viel über die Größe der Modelle gesprochen. Ein größeres Modell benötigt mehr Speicher und Rechenleistung, und daraus lässt sich relativ schnell eine Wunschliste für die Hardware ableiten. Für meinen konkreten Einsatz reicht diese Betrachtung allerdings nicht aus, weil nicht nur das Modell selbst, sondern die gesamte Arbeitsweise berücksichtigt werden muss.
Ein Coding-Agent verarbeitet nicht einfach eine einzelne Frage und erzeugt danach eine Antwort. Er analysiert Dateien, baut Kontext auf, führt Werkzeuge aus, interpretiert deren Ergebnisse und startet anschließend möglicherweise die nächste Modellabfrage. Währenddessen müssen Repository, Entwicklungswerkzeuge, Datenbanken oder Testumgebungen ebenfalls Ressourcen bekommen.
Hinzu kommt meine zunehmend parallele Arbeitsweise. Wenn Agenda langfristig mehrere unabhängige Aufgaben freigeben kann, möchte ich nicht zwangsläufig warten, bis Aufgabe A vollständig abgeschlossen ist, bevor Aufgabe B überhaupt beginnen darf.
Mein Hardwarebedarf wird deshalb eher durch den gewünschten Arbeitsdurchsatz bestimmt als allein durch die Frage, welches einzelne Modell theoretisch gestartet werden kann.
Grafikspeicher ist wichtig, aber nicht die einzige Größe
Für leistungsfähige lokale Modelle ist verfügbarer GPU-Speicher offensichtlich ein zentraler Faktor. Passt ein Modell nicht sinnvoll in den verfügbaren Speicher, müssen Teile ausgelagert oder stärker quantisiert werden, was wiederum Auswirkungen auf Geschwindigkeit und teilweise auf die nutzbare Modellqualität haben kann.
Für mich wäre es deshalb wenig attraktiv, Hardware exakt so zu dimensionieren, dass ein gewünschtes Modell gerade eben läuft. Ein Entwicklungsrechner sollte Reserven besitzen, weil neben dem Modell weitere Komponenten Speicher benötigen und ich langfristig nicht jede neue Möglichkeit sofort an einer harten technischen Grenze scheitern lassen möchte.
Gleichzeitig darf ich mich aber nicht von möglichst großen Speicherzahlen allein leiten lassen. Wenn eine sehr teure Konfiguration nur deshalb gekauft wird, weil theoretisch ein deutlich größeres Modell geladen werden kann, dieses Modell in meinem realen Coding-Workflow aber kaum zusätzlichen Nutzen bringt, wäre die Investition schlecht verteilt.
Entscheidend ist am Ende, welche Modellklasse meine tatsächlichen Aufgaben zuverlässig erledigt.
Das kann ich sinnvoll erst beurteilen, wenn ich lokale Modelle gegen reale Codex-Aufgaben teste.
Hauptspeicher wird bei agentischer Arbeit ebenfalls wichtig
Neben der GPU spielt für meinen geplanten Aufbau auch normaler Arbeitsspeicher eine größere Rolle, als es ein reiner Chatbetrieb vermuten lässt. Mehrere Agenten können parallel Repositories analysieren, Builds ausführen, Entwicklungswerkzeuge starten und Testumgebungen verwenden.
Bei einem .NET-/Blazor-Projekt kommen möglicherweise gleichzeitig Compiler, Testprozesse, lokale Dienste und Datenbanken hinzu. Wenn daneben noch Container oder virtuelle Umgebungen laufen, kann ein System mit knapper RAM-Ausstattung schnell anfangen, Ressourcen gegeneinander auszuspielen.
Ich möchte die Maschine deshalb nicht als reine KI-Appliance betrachten, auf der ausschließlich das Modell läuft. Sie soll eine tatsächliche Arbeitsmaschine beziehungsweise ein Agentenhost sein, auf dem die KI ihre Werkzeuge in einer realistischen technischen Umgebung benutzen kann.
Das erhöht die Anforderungen an Hauptspeicher und CPU, selbst wenn die eigentliche Modellinferenz hauptsächlich auf der GPU stattfindet.
CPU-Leistung bleibt relevant
Es wäre ebenfalls zu einfach, den gesamten Rechner nur rund um die GPU zu planen. Ein erheblicher Teil agentischer Softwareentwicklung besteht aus Arbeiten, die gar nicht vom Modell selbst ausgeführt werden.
Ein Repository muss durchsucht werden, Builds laufen, Tests werden gestartet, Pakete verarbeitet, Dateien verändert und möglicherweise mehrere Container betrieben. Gerade wenn mehrere Agenten parallel arbeiten, können solche CPU-Aufgaben gleichzeitig auftreten.
Damit brauche ich keinen Prozessor, dessen einzige Aufgabe darin besteht, die GPU irgendwie mit Daten zu versorgen. Ich möchte ausreichend Reserven, damit ein Build nicht plötzlich den gesamten Arbeitsfluss ausbremst, nur weil parallel bereits eine zweite Aufgabe Tests ausführt.
Meine gesamte Automatisierungskette lebt davon, dass die verschiedenen technischen Schritte ohne permanente manuelle Begleitung ineinandergreifen. Wenn jede Modellantwort schnell ist, anschließend aber ein Build oder Testlauf die Maschine vollständig blockiert, habe ich den Flaschenhals lediglich verschoben.
Speicherplatz ist ebenfalls mehr als nur Platz für Modelle
Lokale KI-Modelle benötigen viel Speicherplatz, aber auch dieser Punkt geht bei meinem geplanten System darüber hinaus. Mehrere Versionen beziehungsweise Quantisierungen können parallel interessant sein, weil ich möglicherweise unterschiedliche Modelle für unterschiedliche Aufgaben vergleichen möchte.
Dazu kommen Repositories, Build-Artefakte, Docker-Images, Paket-Caches und gegebenenfalls lokale Datenbanken. Mit Git Worktrees kann dieselbe Codebasis außerdem mehrfach in getrennten Arbeitsständen vorhanden sein, wenn mehrere Codex- beziehungsweise spätere lokale Agentenaufgaben parallel bearbeitet werden.
Gerade schnelle temporäre Daten sollten nicht ständig an der Grenze eines kleinen Systemlaufwerks operieren müssen. Für mich gehört ausreichend schneller SSD-Speicher deshalb genauso zur Planung wie GPU und RAM.
Ein KI-Entwicklungsrechner ist damit im Grunde eine ziemlich leistungsfähige allgemeine Workstation mit einem besonders starken Schwerpunkt auf Modellinferenz.
Parallelität macht die Planung deutlich schwieriger
Eine Aufgabe gleichzeitig lokal auszuführen wäre vergleichsweise einfach zu planen. Interessanter wird die Hardwarefrage für mich dadurch, dass genau das nicht meinem langfristigen Arbeitsmodell entspricht.
Bei meinen Überlegungen zu agentischen und Multi-Agent-Systemen möchte ich unterschiedliche Rollen und Aufgaben voneinander trennen. Eine KI könnte implementieren, während eine andere Testfälle erzeugt oder eine zweite unabhängige Agenda-Aufgabe an einem getrennten Worktree arbeitet.
Ob all diese Arbeiten tatsächlich gleichzeitig ein großes Modell benötigen, ist noch offen. Wahrscheinlich lässt sich ein Teil mit kleineren Modellen oder zeitlich versetzten Inferenzschritten abbilden. Trotzdem möchte ich die Architektur nicht von Anfang an so knapp dimensionieren, dass Parallelität praktisch ausgeschlossen ist.
Genau hier wird die Hardwareentscheidung teuer, denn doppelte oder dreifache Agentenkapazität bedeutet nicht automatisch nur einen entsprechend kleinen Aufpreis. GPU-Speicher, Rechenleistung, Kühlung und Stromversorgung wachsen schnell in Bereiche, bei denen die wirtschaftliche Abwägung gegenüber externen Diensten relevant wird.
Ich brauche wahrscheinlich nicht für jede Aufgabe dasselbe Modell
Ein möglicher Ausweg liegt darin, nicht sämtliche Agenten mit dem jeweils größten verfügbaren Modell zu betreiben. Viele Aufgaben benötigen möglicherweise gar nicht dieselbe Denkleistung.
Eine komplexe Architekturänderung könnte ein sehr leistungsfähiges Coding-Modell benötigen, während ein Agent, der Statusinformationen aus Agenda verarbeitet oder einfache Änderungen klassifiziert, mit deutlich weniger Ressourcen auskommt. Auch bei Tests kann es sinnvoll sein, bewusst ein anderes Modell einzusetzen, um zumindest einen Teil der gemeinsamen Fehlerannahmen zu vermeiden.
Die Unabhängigkeit meiner automatisierten Tests ist ohnehin eines meiner offenen Themen. Ein lokaler Rechner könnte mir langfristig ermöglichen, unterschiedliche Modelle für Entwicklung und Prüfung miteinander zu kombinieren, sofern die Hardware genügend Flexibilität besitzt.
Das spricht für einen Aufbau, der nicht nur ein einziges Modell möglichst effizient betreibt, sondern verschiedene Lastprofile verkraften kann.
Stromverbrauch gehört zur wirtschaftlichen Betrachtung
Wenn der Rechner später regelmäßig oder sogar über längere Zeiträume automatisierte Aufgaben bearbeitet, wird der Energieverbrauch zu einem echten Kostenfaktor. Ein leistungsfähiges System, das nur gelegentlich für eine halbe Stunde benutzt wird, ist wirtschaftlich anders zu bewerten als eine Maschine, auf der Agenda regelmäßig mehrere Stunden am Tag Aufgaben abarbeiten lässt.
Dabei spielt nicht nur die maximale Leistungsaufnahme eine Rolle. Interessant ist genauso, wie effizient ein System bei den tatsächlichen Modellen arbeitet und wie viel Energie im Leerlauf beziehungsweise bei leichteren Aufgaben benötigt wird.
Gerade bei eigener Hardware darf ich den Vergleich mit externem Codex deshalb nicht auf Kaufpreis gegen monatliches Kontingent reduzieren. Die wirtschaftliche Frage „eigener KI-Rechner oder weiter Codex bezahlen?“ muss später Anschaffung, Nutzung, Energie, Wartung und tatsächliche Produktivität gemeinsam betrachten.
Erst dann lässt sich sinnvoll beurteilen, ob sich der lokale Betrieb für mich wirklich rechnet.
Lautstärke und Abwärme sind keine Nebensachen
Bei sehr leistungsfähiger Hardware wird schnell nur über Benchmarks gesprochen, obwohl der Rechner später irgendwo real stehen muss. Hohe Leistungsaufnahme bedeutet entsprechende Abwärme, und diese Wärme muss wiederum mit Kühlung aus dem Gehäuse transportiert werden.
Wenn ein System unter längerer KI-Last dauerhaft sehr laut wird, kann das relevant sein, sobald es in einem normalen Arbeitsumfeld steht. Umgekehrt kann ein eigener Technikraum oder ein geeigneter Serverstandort andere Prioritäten erlauben.
Für mich gehört diese Frage deshalb bereits in die Planung. Ein Rechner, der technisch perfekt ist, aber im praktischen Alltag stört oder zusätzliche Infrastruktur für Kühlung benötigt, kann am Ende eine schlechtere Lösung sein als eine geringfügig langsamere, aber angenehm betreibbare Konfiguration.
Lokale KI bedeutet schließlich auch, die physische Infrastruktur selbst zu besitzen.
Aufrüstbarkeit ist für mich wichtiger als ein perfekter heutiger Rechner
Die Entwicklung lokaler Modelle bewegt sich schnell, und genau deshalb halte ich es für riskant, einen Rechner ausschließlich für einen einzelnen heutigen Modellstand zu planen. In einigen Monaten können andere Quantisierungen, neue Modellarchitekturen oder bessere Agentenwerkzeuge das sinnvolle Hardwareprofil bereits verändern.
Ich möchte deshalb möglichst eine Plattform, bei der zumindest einige Komponenten später sinnvoll erweitert werden können. Zusätzlicher RAM oder SSD-Speicher sollte kein grundsätzliches Problem darstellen, und auch bei der übrigen Auslegung möchte ich unnötige Sackgassen vermeiden.
Eine spätere GPU-Aufrüstung ist technisch und wirtschaftlich eine eigene Frage, aber selbst dort ist es hilfreich, wenn Gehäuse, Stromversorgung und Kühlung nicht bereits bei der ersten Konfiguration exakt an ihrer Grenze liegen.
Für mich ist Flexibilität an dieser Stelle wertvoller als die letzten Prozent Benchmarkleistung zum Kaufzeitpunkt.
Der Rechner darf nicht selbst zur neuen Dauerbaustelle werden
Mein Wunsch nach lokaler KI entsteht unter anderem aus dem Bedürfnis nach mehr Kontrolle und weniger Abhängigkeit. Es wäre ziemlich widersinnig, wenn ich dafür eine Maschine aufbaue, deren Administration anschließend so viel Zeit verbraucht, dass der eigentliche Produktivitätsgewinn wieder verschwindet.
Treiber, Modellserver, Agentenlaufzeit, Updates und Monitoring müssen natürlich gepflegt werden. Trotzdem möchte ich den Aufbau so weit wie möglich standardisieren und automatisieren, damit aus dem KI-Rechner nicht das nächste Hobbyprojekt entsteht, das ständig Aufmerksamkeit verlangt.
Gerade als Einzelunternehmer ist diese Betrachtung wichtig. Infrastruktur, die mir Arbeit abnehmen soll, darf nicht gleichzeitig dauerhaft neue operative Arbeit erzeugen.
Ein etwas weniger exotischer Aufbau mit guter Softwareunterstützung kann deshalb für mich wertvoller sein als eine theoretisch maximale Konfiguration, deren Betrieb ständig Sonderwissen verlangt.
Die endgültige Hardware werde ich deshalb nicht nur anhand von Datenblättern auswählen
Bevor ich tatsächlich eine größere Summe investiere, möchte ich möglichst realistisch wissen, welche Leistung ich für meine Aufgaben benötige. Dazu gehören nicht nur synthetische Modellbenchmarks, sondern echte Arbeitsaufträge aus meinen Projekten.
Wie lange benötigt ein lokales Modell für eine typische Agenda-Aufgabe?
Kann es Kosmos ausreichend gut analysieren?
Wie zuverlässig läuft ein längerer agentischer Auftrag?
Wie schnell sind Builds und Testschleifen?
Wie verhält sich die Maschine, wenn zwei Arbeiten parallel stattfinden?
Und wie groß ist der qualitative Abstand zu Codex bei genau den Tätigkeiten, die ich heute regelmäßig ausführe?
Diese Fragen sind für mich wesentlich aussagekräftiger als die Information, wie viele Tokens pro Sekunde ein Modell unter idealen Bedingungen produziert.
Mein Ziel ist keine maximale KI-Maschine, sondern ein sinnvoller Agentenhost
Das verändert auch meine Vorstellung vom idealen Rechner. Ich suche nicht den schnellsten theoretisch denkbaren lokalen KI-PC und auch kein System, mit dem ich vor allem möglichst große Modelle demonstrieren kann.
Ich möchte eine Maschine, auf der meine tatsächliche Arbeitsweise sinnvoll funktioniert.
Sie soll genügend Modellleistung besitzen, um einen erheblichen Teil meiner Codex-Aufgaben übernehmen zu können, gleichzeitig Builds, Tests und Werkzeuge ohne Engpässe ausführen und langfristig mehrere agentische Arbeitsstränge unterstützen. Sie muss ausreichend Speicher besitzen, gut betreibbar bleiben und darf wirtschaftlich nicht so weit aus dem Rahmen fallen, dass externe Dienste offensichtlich die bessere Lösung bleiben.
Das ist eine ziemlich andere Anforderung als „Welchen PC brauche ich für lokale KI?“.
Für mich lautet die eigentliche Frage:
Welche Hardware brauche ich, damit meine lokale KI nicht nur beeindruckend aussieht, sondern tatsächlich jeden Tag Arbeit für mich erledigt?
Genau daran werde ich die spätere Kaufentscheidung messen. Und wenn ich den Rechner irgendwann tatsächlich aufgebaut habe, wird der interessante Teil erst beginnen: Dann kann ich reale Agenda-Aufgaben lokal und über Codex gegeneinander antreten lassen und zum ersten Mal belastbar sehen, wie viel meiner heutigen Cloud-gestützten Entwicklung sich wirklich auf eigene Hardware verlagern lässt.