Eigene Hardware, eigene Fragestellungen
Unsere Ausgangsfrage war konkret: Kann ein lokal betriebenes Modell eine Entwicklungsaufgabe über mehrere Dateien hinweg bearbeiten, Tests auswerten und seine Lösung selbst verbessern? Dafür haben wir auf unserer DGX Spark eine getrennte Forschungsumgebung aufgebaut. Sie gibt uns Raum, neue Modelle und Werkzeuge ausführlich auszuprobieren, ohne dafür produktive Kundensysteme anzufassen.
Die Spark hat 128 GB gemeinsamen System- und Grafikspeicher. Damit konnten wir auch ein Modell mit rund 27 Milliarden Parametern in BF16 betreiben, ohne seine Gewichte zusätzlich zu quantisieren. Neben solchen Qualitätstests interessieren uns längere Arbeitsläufe: Was gelingt einem Agenten, wenn eine Aufgabe nicht nach wenigen Minuten beendet sein muss?
So arbeiten Modell, Agent und Werkzeuge zusammen
Unser weiterentwickelter Aufbau verband Qwen 3.8 27B auf der Spark mit OpenCode als Coding-Agent. SGLang stellte das Modell über eine API bereit. OpenCode bearbeitete damit Dateien, führte Tests aus und gab deren Ergebnisse für den nächsten Arbeitsschritt an das Modell zurück.
Codex unterstützte die Versuchssteuerung und Auswertung. Wir kombinierten also lokale Inferenz mit weiteren Entwicklungswerkzeugen; die begleitende Arbeit schloss auch Cloud-Werkzeuge ein. Die Coding-Vergleiche selbst liefen mit synthetischen Daten, vorgegebenem Arbeitsumfang und ohne Zugriff auf produktive Kundensysteme.
OpenCode, Codex CLI und Claude Code mit demselben Modell
Für einen frühen Vergleich haben wir alle drei Coding-Agenten mit demselben lokalen Qwen-3.6-Modell und einem Kontextfenster von 65.536 Tokens getestet. Drei Aufgaben mit jeweils drei Wiederholungen ergaben neun Läufe pro Agent. Dazu gehörten Daten-Normalisierung, zusammenhängende SQLite- und API-Logik sowie ein Import, der bei Fehlern keine halbfertigen Änderungen hinterlassen durfte.
Alle 27 Läufe bestanden die sichtbaren Tests, 19 auch unsere unabhängigen Prüfungen. Diese untersuchten etwa, ob ein Datenbestand nach einem fehlgeschlagenen Import unverändert blieb. So konnten wir unterscheiden, welche Lösungen auch über den vorgesehenen Normalfall hinaus funktionierten.
| Coding-Agent | Sichtbare Tests | Zusätzliche Prüfungen |
|---|---|---|
| OpenCode | 9 von 9 Läufen | 7 von 9 Läufen |
| Codex CLI | 9 von 9 Läufen | 7 von 9 Läufen |
| Claude Code | 9 von 9 Läufen | 5 von 9 Läufen |
Verglichen wurden Coding-Agenten mit demselben lokalen Modell, nicht die Modelle von OpenAI und Anthropic. Die Ergebnisse gelten für diese interne Aufgabenserie und die vorgegebenen Tests und Arbeitsgrenzen.
Welche Modelle wir erprobt haben
In der ersten Modellreihe haben wir Qwen 3.6, Gemma 4 und GPT-OSS 120B mit denselben drei Agenten und Aufgaben untersucht. Die Tabelle zeigt die Ergebnisse der jeweils getesteten Modellkonfiguration, nicht das Potenzial einer Modellfamilie unter allen denkbaren Einstellungen.
| Modellkonfiguration | Vollständig bestanden |
|---|---|
| Qwen 3.6 · Q4_K_M | 19 von 27 Läufen |
| Gemma 4 26B A4B IT · Q4_K_M | 10 von 27 Läufen |
| GPT-OSS 120B · MXFP4 | 7 von 27 Läufen |
Interne Coding-Aufgaben mit sichtbaren und unabhängigen Prüfungen. Modellarchitektur, Präzision und Zusammenspiel mit dem Agenten unterscheiden sich; die Zahlen isolieren keinen einzelnen Einflussfaktor.
- Qwen 3.6: zwei Präzisionsstufen im Vergleich
- Mit OpenCode kamen Q4 und Q8 jeweils auf sieben bestandene von neun Läufen. Q8 benötigte im Mittel rund 63 % mehr Zeit. Die höhere Präzision brachte bei diesen Aufgaben keinen Qualitätsgewinn.
- Qwen 3.8 27B: die Grundlage unserer weiteren Experimente
- Qwen 3.8 mit BF16-Gewichten wurde unsere bevorzugte Kombination mit OpenCode. In der ersten Ollama-Serie bestanden sieben von neun Läufen; zwei erreichten das Zeitlimit. Ein zusätzlicher Versuch ohne dieses Limit löste auch die anspruchsvolle Import-Aufgabe und bestand die unabhängigen Prüfungen.
Ollama für den Einstieg, SGLang für gezielte Experimente
Mit Ollama konnten wir lokale Modelle anbinden und erste Coding-Aufgaben bearbeiten. SGLang gab uns anschließend mehr Einfluss auf Kontextlänge, Speicheraufteilung und die Verarbeitung großer Eingaben. Wir betrieben den Modellserver in Docker und hielten unterschiedliche Versuchskonfigurationen getrennt fest.
So konnten wir mit demselben Modell sowohl das native Kontextfenster von 262.144 Tokens als auch eine experimentelle Erweiterung auf bis zu eine Million Tokens erproben. Dabei ging es um die Bearbeitung einzelner umfangreicher Aufgaben, nicht um möglichst viele gleichzeitige Anfragen.
300.000 Tokens lesen und einer Aufgabe zwei Stunden geben
In einem synthetischen Text mit 300.090 Eingabe-Tokens fand das Modell gezielt Informationen am Anfang, in der Mitte und am Ende wieder. Dafür brauchte es rund neun Minuten. Der Versuch zeigte, dass diese umfangreiche Eingabe verarbeitet werden konnte; eine umfassende Prüfung des Millionen-Token-Kontexts steht noch aus.
Bei einer anspruchsvollen Coding-Aufgabe zu Datenversionen und konsistenten API-Änderungen arbeitete der Agent gut zwei Stunden an seiner Lösung. Danach bestanden alle sieben sichtbaren und sechs unabhängigen Tests. Ein vorheriger Lauf mit kleinerem Ausgabebudget war nicht bis zur Umsetzung gekommen. Für uns ist das ein Ansatz für weitere Versuche: längere Aufgaben mit ausreichend Raum für Analyse, Werkzeugaufrufe und Korrekturen bearbeiten lassen.
Pocket Universe: aus einem Satz wird eine interaktive Welt
Mit „Pocket Universe“ haben wir anschließend eine offenere Idee erprobt: Ein Satz beschreibt eine Welt, die im Browser als interaktive Partikellandschaft entsteht. Zeit und Schwerkraft lassen sich verändern, Bewegungen mit Maus oder Touch beeinflussen. So wurde aus einer sprachlichen Vorstellung eine Oberfläche, mit der man spielen und experimentieren kann.
Qwen entwickelte den Anwendungscode über OpenCode. Codex half bei Steuerung und Prüfung des Entwicklungsprozesses. Innerhalb der entstandenen Anwendung hat das Sprachmodell eine andere Aufgabe: Es liefert eine strukturierte Weltbeschreibung. Die Anwendung validiert diese Daten und setzt sie mit ihrer eigenen Canvas-Engine um. Modellantworten werden dort nicht als ausführbarer Code übernommen.
Der Forschungsprototyp verbindet KI, Bedienung und Visualisierung in einer Anwendung. Automatisierte Tests und unser Review zeigten zugleich, welche Teile noch überarbeitet werden müssen. Für uns ist er eine praktische Grundlage, um die Zusammenarbeit von Sprachmodell und individuell entwickelter Oberfläche weiter zu untersuchen.
Als Nächstes: Modelle mit weiteren Systemen verbinden
Wir wollen die Forschungsumgebung um ein Gateway für den Zugriff auf unterschiedliche Modelle und eine Queue für längere Aufträge erweitern. Damit lässt sich untersuchen, wie Anwendungen Aufgaben an lokale Modelle übergeben und die Ergebnisse weiterverarbeiten können, etwa bei der Aufbereitung von Dokumenten oder bei Hintergrundprozessen. Diese geplanten Erweiterungen verbinden die bisherigen Modelltests mit Fragen der Anwendungsintegration.
Was davon in die Entwicklung von KI-Anwendungen einfließt
Unsere Versuche im August 2026 reichen vom Modellvergleich bis zum interaktiven Prototyp. Wir führen diese Forschung und Entwicklung weiter: mit eigenen Aufgaben, unterschiedlichen Werkzeugen und einer Prüfung der tatsächlich entstandenen Ergebnisse.
Diese Erfahrung nutzen wir, wenn wir KI-Funktionen für Websites, Portale und Fachanwendungen entwickeln. Wir können Modelle mit passenden Aufgaben erproben, Ergebnisse kontrolliert in eine Oberfläche übernehmen und die Verarbeitung mit vorhandenen Systemen verbinden. Ob das lokal, über einen Cloud-Dienst oder in einer Kombination geschieht, entscheiden wir nach den Anforderungen des jeweiligen Projekts.
Auf der DGX Spark können wir lokale KI über längere Aufgaben hinweg erproben und ihre Ergebnisse unabhängig prüfen. So entsteht praktische Erfahrung mit Modellen, Werkzeugen und Betrieb, auf die wir bei der Entwicklung von KI-Anwendungen zurückgreifen können.