Lokale LLMs für Code und UI Engineering betreiben

Warum lokale Inferenz die Kostenrechnung verändert

Eine Entwicklerin oder ein Entwickler bittet einen KI-Assistenten, einen Fehler zu untersuchen, den Code zu ändern und die Tests auszuführen. Der erste Versuch scheitert, also probiert es der Assistent erneut. Aus einer einfachen Anfrage wird ein langer Austausch von Code, Protokollen und Anweisungen. Über ein ganzes Engineering-Team hinweg kann diese wiederholte Arbeit die KI-Nutzung so teuer machen, dass Menschen beginnen, sie zu rationieren.

Ein offenes Modell auf einer selbst kontrollierten Infrastruktur zu betreiben, bietet einen anderen Weg, diese Last zu steuern. Das Team übernimmt Verantwortung für Dienst und Kapazität, gewinnt aber mehr Kontrolle darüber, wo die Inferenz stattfindet und wie sie bezahlt wird. Revolut zeigt, wie das im großen Maßstab aussehen kann.

Auf der AI Engineer NYC im Oktober 2026 beschrieb David Abitbol von Revolut, wie rund 2.000 Engineers mit selbst gehosteten GLM-Modellen versorgt werden. Er berichtete von Inferenzkosten in Höhe von ungefähr einem Zehntel der vorherigen Anthropic- und OpenAI-Rechnung sowie Verbesserungen von etwa 60 % bei der Coding-Zeit und 70 % bei der Lead Time. Dabei handelte es sich um interne Beobachtungen, nicht um eine kontrollierte Studie oder eine Zusage vergleichbarer Einsparungen an anderer Stelle. Für GLM 5.3 setzte seine Bereitstellung 56 NVIDIA-B200-GPUs ein. Frontier-Dienste blieben für Ausnahmefälle verfügbar; Bildverständnis wurde an dafür geeignete Modelle weitergeleitet. [1]

Das ist gemeinsam genutzte Infrastruktur in erheblichem Maßstab. Ein lokales Modell kann ebenso auf einer einzelnen Workstation laufen, während eine Unternehmensbereitstellung einen internen Server oder dedizierte gemietete GPUs nutzen kann. Self-hosted bedeutet nicht zwangsläufig On-Premises oder offline. Entscheidend ist, wo das Modell läuft, welche Systeme die Daten erhalten und wer sie kontrolliert.

Mit einem messbaren Pilotprojekt beginnen

Für ein kleineres Team würden wir mit einigen wiederkehrenden Aufgaben beginnen: einen unbekannten Service verstehen, einen klar begrenzten Fehler beheben, einen vorhandenen Screen erweitern und Tests für die Änderung schreiben. Verwenden Sie reale Beispiele aus den eigenen Repositories. Bewerten Sie das Ergebnis nach Korrektheit, Prüfaufwand und verstrichener Zeit. Ein Modell mit einem beeindruckenden ersten Entwurf kann noch immer teuer sein, wenn eine Entwicklerin oder ein Entwickler den Nachmittag mit Reparaturen verbringt.

Ein praxisnaher Pilot kann Ollama mit einem offenen Coding-Modell wie Qwen3-Coder 30B kombinieren. Das aktuelle Ollama-Paket Q4_K_M ist ungefähr 19 GB groß. Das ist der Modelldownload, nicht der vollständige Speicherbedarf: Runtime und Arbeitskontext benötigen zusätzlichen Platz. Verstehen Sie dies als gut zugängliches Beispiel für eine Evaluation, nicht als Behauptung, es sei das stärkste verfügbare Modell. [2]

Dimensionieren Sie die Maschine für den vorgesehenen Kontext und die Zahl gleichzeitiger Nutzer. Zum Kontext gehören Anweisungen, Code, Gesprächsverlauf und Tool-Ergebnisse, mit denen das Modell während einer Anfrage arbeiten kann. Längere Kontexte verbrauchen Speicher; ein Modell, das bei kurzem Kontext passt, kann mit der für einen Coding-Agenten benötigten Einstellung langsam werden oder ausfallen. Testen Sie auf vorhandener Hardware oder mit einer kurzen GPU-Miete, bevor Sie sich auf Hardware festlegen.

Ollama und OpenCode richtig konfigurieren

Nachdem Ollama und OpenCode installiert sind, konfigurieren Sie den Ollama-Server für die lokale Nutzung. Setzen Sie OLLAMA_NO_CLOUD=1 und starten Sie den Dienst neu. Ollamas aktuelle OpenCode-Integrationsanleitung verlangt mindestens 64K Kontext. Setzen Sie deshalb OLLAMA_CONTEXT_LENGTH=65536 in derselben Service-Umgebung und prüfen Sie, ob die Maschine diese Einstellung zuverlässig trägt. Die Variablen gehören in die Umgebung des laufenden Servers; sie nur in einem unabhängigen Terminal zu setzen, konfiguriert einen bestehenden Dienst nicht neu. [3, 4]

Laden Sie das Modell aus einem separaten Arbeits-Branch im Projektverzeichnis herunter und starten Sie den Coding-Agenten:

ollama pull qwen3-coder:30b
ollama launch opencode

Den Agenten in einem echten Repository testen

Wählen Sie das heruntergeladene lokale Modell im Launcher. OpenCode unterstützt außerdem eine manuelle Konfiguration über Ollamas lokale API unter http://localhost:11434/v1. Binden Sie den Pilot-Endpunkt an die lokale Maschine. Prüfen Sie vor der Nutzung vertraulichen Codes, ob optionale externe Provider, Web-Tools und Telemetrie der vorgesehenen Datenrichtlinie entsprechen; Ollamas Cloud-Funktionen zu deaktivieren, regelt nicht jede Komponente im Umfeld. [3, 4, 5]

Beginnen Sie mit einer Aufgabe, die sich schnell verifizieren lässt. Lassen Sie den Agenten einen fehlschlagenden Test erklären, eine kleine Änderung vorschlagen und die relevanten Checks ausführen. Prüfen Sie, ob er Tools zuverlässig aufruft, die richtigen Dateien bearbeitet und stoppt, wenn ein Befehl fehlschlägt. Eine Coding-Frage beantworten zu können, ist nur ein Teil der wirksamen Arbeit in einem Repository.

Geben Sie dem Agenten einen kurzen Projektleitfaden mit Build-Befehlen, Architekturkonventionen, wichtigen Verzeichnissen und Tests. Lassen Sie ihn relevanten Code und Dokumentation bei Bedarf abrufen. Für den ersten Pilot ist dies ein sinnvollerer Investitionspunkt als Fine-Tuning. Koppeln Sie den Dokumentzugriff an die Berechtigungen der Nutzer und behandeln Sie Anweisungen in Tickets, Quellcodekommentaren oder abgerufenen Seiten als nicht vertrauenswürdige Inhalte.

Für UI Engineering eine visuelle Feedbackschleife ergänzen

UI Engineering benötigt eine zusätzliche Feedbackschleife. Ein Textmodell kann Komponenten und CSS erzeugen, aber die Beurteilung einer gerenderten Oberfläche verlangt Bildverständnis oder andere Inspektionswerkzeuge. Ein lokales Vision-Language-Modell wie Qwen3-VL ist ein möglicher Kandidat für die Screenshot-Interpretation; seine Fähigkeiten müssen an den eigenen Oberflächen getestet werden. [6]

Nehmen wir ein Kundenportal mit einem neuen Screen für Kontoeinstellungen. Geben Sie dem Agenten vorhandene Komponenten, Design-Tokens, Validierungsregeln und Beispiele benachbarter Screens. Starten Sie anschließend die Anwendung und prüfen Sie das Ergebnis in Desktop- und Mobilgrößen. Eine praktikable Abfolge ist:

• Die Änderung mit den vorhandenen Komponenten und Konventionen des Projekts umsetzen.
• Die Anwendung mit synthetischen Daten starten und die relevanten User Journeys durchlaufen.
• Screenshots aufnehmen und DOM, Konsolenfehler sowie Netzwerkfehler prüfen.
• Mit einem Vision-Modell visuelle Probleme identifizieren und den Coding-Agenten Korrekturen vorschlagen lassen.
• Die Checks erneut ausführen und Code sowie Oberfläche durch einen Menschen prüfen lassen.

Mehr als den Screenshot validieren

Playwright kann Screenshots aufnehmen und mit freigegebenen Baselines vergleichen. Halten Sie die Testumgebung konsistent, weil sich das Rendering zwischen Betriebssystemen und Browsern unterscheidet. [7] Ergänzen Sie Prüfungen für Tastaturnavigation, Fehlerzustände, lange Beschriftungen und schmale Screens. Ein visueller Vergleich belegt nicht, dass ein Formular die richtigen Daten übermittelt, und die Freigabe der eigenen Ausgabe durch ein Modell darf niemals der Akzeptanztest sein.

Wenn das Team zusätzlich ein gehostetes Vision-Modell nutzt, machen Sie diesen Pfad ausdrücklich sichtbar. Screenshots können Kundendaten oder interne Produktdetails enthalten. Ein lokales Coding-Modell in Kombination mit einem externen Screenshot-Dienst ist ein hybrider Workflow und muss beim Datenschutz auch als solcher bewertet werden.

Aus dem Pilot einen verlässlichen Dienst machen

Sobald mehrere Entwicklerinnen und Entwickler vom Pilot abhängen, braucht der Dienst eine verantwortliche Person. Eine gemeinsam genutzte Bereitstellung benötigt authentifizierten Zugriff, Kapazitätsmanagement, Monitoring und einen Wiederherstellungsplan. vLLM ist eine mögliche Serving-Option; es stellt kompatible APIs bereit und unterstützt Bereitstellungsmuster, die über eine einzelne GPU hinauswachsen können. Verifizieren Sie die genaue Kombination aus Modell und Agent, einschließlich Tool-Aufrufen, Streaming und Bildeingaben. API-Kompatibilität allein beweist nicht, dass der gesamte Workflow funktioniert. [8]

Messen Sie, wie lange Nutzer auf den Beginn einer Antwort warten, wie oft Anfragen in einer Queue landen und wie lange abgeschlossene Aufgaben dauern. Berücksichtigen Sie die langsamsten typischen Anfragen, nicht nur Durchschnittswerte. Halten Sie das Kontextfenster passend zur Arbeitslast und bewerten Sie Prefix Caching, das Berechnung wiederverwenden kann, wenn Anfragen mit demselben Material beginnen. [9] Diese Einstellungen brauchen Lasttests mit mehreren aktiven Agenten; eine schnelle Demonstration mit einem Nutzer sagt wenig über ein ausgelastetes Team aus.

Schützen Sie den Dienst durch die umgebende Infrastruktur. Verwenden Sie ein authentifiziertes Gateway und private Netzwerkregeln und geben Sie nur die benötigten Endpunkte frei. Die vLLM-Dokumentation warnt ausdrücklich, dass allein die API-Key-Option nicht jeden Endpunkt absichert. Wenn Kunden oder Teams starke Isolation benötigen, verwenden Sie getrennte Serving-Instanzen sowie getrennte Repository- und Retrieval-Berechtigungen. [10]

Führen Sie Agenten in eingeschränkten Entwicklungsumgebungen mit den für ihre Aufgabe nötigen Berechtigungen aus. Halten Sie Produktionszugangsdaten außer Reichweite und behalten Sie normale Review- und Release-Kontrollen bei. Protokollieren Sie genug, um Fehler untersuchen zu können, ohne unnötig Quellcode, Secrets oder personenbezogene Daten in Logs aufzubewahren. Fixieren Sie Modell-, Quantisierungs- und Serving-Versionen, führen Sie das Evaluationsset vor Upgrades erneut aus und behalten Sie eine bekannte funktionierende Konfiguration für ein Rollback.

Akzeptierte Arbeit und Gesamtkosten messen

Die wirtschaftliche Entscheidung muss Hardwaremiete oder Abschreibung, Strom, Hosting, Wartung, Engineering-Support und die Nutzung externer Modelle einbeziehen. Teilen Sie diese Kosten durch Arbeit, die das Review besteht. Generierte Tokens oder vorgeschlagene Änderungen zu zählen, belohnt Aktivität, selbst wenn das Ergebnis ersetzt werden muss.

Niedrigere Token-Kosten führen außerdem nicht unmittelbar zu niedrigeren Projektbudgets. Anforderungen, Integration, Tests und Freigabe benötigen weiterhin Zeit. Verfolgen Sie während des Piloten Prüfaufwand und entwichene Fehler gemeinsam mit der Lieferzeit. Wenn die Codegenerierung schneller wird, während die Review-Queue wächst, hat das Team den Engpass verschoben, nicht beseitigt.

Ein vierwöchiger Evaluationsplan

Für eine erste Evaluation würden wir vier Wochen einplanen, sofern geeignete Hardware und Repository-Zugriff bereits verfügbar sind. Nutzen Sie die erste Woche, um Baseline-Aufgaben festzulegen und Modelle zu vergleichen. Binden Sie in der zweiten Woche eine kleine Gruppe von Engineers an. Ergänzen Sie in der dritten die UI-Inspektionsschleife und testen Sie gleichzeitige Nutzung. Vergleichen Sie in der vierten Woche akzeptierte Arbeit, Gesamtkosten und Feedback der Entwicklerinnen und Entwickler. Ein breiterer Produktiv-Rollout kann länger dauern, besonders wenn Zugriffskontrollen und Infrastruktur beschafft werden müssen.

Unsere Empfehlung bei TechHub lautet, nur dort zu erweitern, wo die Evidenz es trägt. Behalten Sie die Aufgaben bei, die das lokale Modell zuverlässig erledigt, verbessern Sie schwache Teile des Workflows und halten Sie für schwierige Fälle eine freigegebene Alternative bereit. Die Investition verdient ihren Platz, wenn Engineers nützliche Arbeit mit weniger Wartezeit und Nacharbeit erledigen können – zu Kosten, die das Unternehmen erklären kann.

Quellen

Primärquellen und offizielle Dokumentation, geprüft am 4. November 2026. Die Revolut-Zahlen werden dem Sprecher zugeschrieben. Das vorgeschlagene Setup, die Evaluationsmethode und der vierwöchige Pilot sind Empfehlungen für Leserinnen und Leser, keine Beschreibung der internen Implementierung von Revolut.