Das Publikum begrüßen und das Thema einordnen: Was gewinnen wir durch lokale Modelle, welche Abstriche machen wir, und wie wird daraus ein brauchbares System für ernsthafte Softwareentwicklung? Die praktische Leitfrage lautet: Kann ein Modell auf unserer eigenen Hardware ein echtes Full-Stack-Feature umsetzen und nachweisen, dass es funktioniert? Den Einstieg kurz halten. Überleitung: Warum spielt es für ein Unternehmen überhaupt eine Rolle, wo die Inferenz stattfindet?
Veranstaltung: entwickler Summit, Berlin, 17. September 2026. Vortrag: „Lokale LLMs: Sind sie den Aufwand wert?“ Referent: Rainer Hahnekamp, Soverius AI. Zeitfenster: 09:00–09:30.
Quellen:
- https://entwickler.de/entwickler-summit/#programm
- https://entwickler.de/wp-content/uploads/2026/04/ES25_Logo_Wortmarke_weiss.png
Rainer und Soverius AI kurz vorstellen. Soverius entwickelt KI-Systeme für den produktiven Einsatz in Anwendungsteams. Die drei verbundenen Schwerpunkte sind agentische Anwendungen, agentisches Software-Engineering sowie lokale und souveräne KI.
Die Zusammenarbeit kann mit einem Onboarding-Workshop beginnen. Im Projektengineering entwickeln wir das System gemeinsam mit dem Kundenteam. Beratung kann die Zusammenarbeit nach der Auslieferung langfristig fortsetzen. Kunden können einzelne Angebote nutzen oder uns über den gesamten Weg einbinden.
Dieser Vortrag verbindet lokale und souveräne KI mit agentischem Software-Engineering: Können lokale Modelle ernsthafte Entwicklungsarbeit übernehmen, und welche technischen Kontrollen machen das praktikabel? Die Vorstellung unter 90 Sekunden halten. Überleitung: die vier Teile des Vortrags zeigen.
Agenda
LOKALE MODELLE
FÜR KI-GESTÜTZTES
CODING
01
WARUM
Warum lokale Modelle?
02
WIE
llama.cpp + Gemma 4
03
DEMO
Capstone
04
PROBLEME
Geschwindigkeit und Qualität
GESCHWINDIGKEIT
Hardware
QUALITÄT
Loop / Graph Engineering
3
Den vierteiligen Ablauf vorstellen. Zuerst klären wir, warum Unternehmen lokale Modelle erwägen. Dann zeigen wir das lokale Coding-Setup mit llama.cpp und Gemma 4. Die Capstone-Aufgabe demonstriert den gesamten Aufbau an einem anspruchsvollen Full-Stack-Feature. Abschließend folgen die beiden praktischen Probleme: Geschwindigkeit und Hardware sowie Qualität durch Evaluation, Kontrollschleifen und Engineering rund um das Modell. Überleitung: die Gründe für lokale Modelle.
Warum lokale Modelle?
LOKALE MODELLE
FÜR KI-GESTÜTZTES
CODING
01
WARUM
Warum lokale Modelle?
02
WIE
llama.cpp + Gemma 4
03
DEMO
Capstone
04
PROBLEME
Geschwindigkeit und Qualität
GESCHWINDIGKEIT
Hardware
QUALITÄT
Loop / Graph Engineering
4
Das erste Kapitel eröffnen. Die praktischen Gründe für den lokalen Betrieb sind Kostenkontrolle, Datenschutz und Unabhängigkeit.
Semi-autonome Loops
Automatisch Gesamtansicht − + Zoom folgt dem Ablauf
Was passiert, wenn solche Loops auf lokalen Modellen laufen?
5
Warum lokal?
Gründe für lokale Modelle €
Kostenkontrolle Datenschutz Unabhängigkeit 6
Die drei wesentlichen Gründe sind Kostenkontrolle, Datenschutz und Unabhängigkeit. Wenn die Hardware vorhanden ist, fällt für zusätzliche lokale Token keine Anbietergebühr an. Kostenlos ist die Inferenz deshalb nicht: Hardware, Strom, Betrieb und Engineering verursachen weiterhin Kosten.
Lokale Inferenz kann Quellcode, Prompts, Zwischenergebnisse und abgerufenen Kontext innerhalb einer vom Unternehmen kontrollierten Grenze halten. Sie reduziert außerdem die Abhängigkeit von externen Anbietern und Änderungen ihrer Bedingungen, Verfügbarkeit oder Modellversionen. Überleitung: die Komponenten unseres lokalen Coding-Setups.
Icons: Lucide, ISC-Lizenz.
Quellen:
- https://lucide.dev/
Setup und Konfiguration
LOKALE MODELLE
FÜR KI-GESTÜTZTES
CODING
01
WARUM
Warum lokale Modelle?
02
WIE
llama.cpp + Gemma 4
03
DEMO
Capstone
04
PROBLEME
Geschwindigkeit und Qualität
GESCHWINDIGKEIT
Hardware
QUALITÄT
Loop / Graph Engineering
7
Das Setup-Kapitel eröffnen. Die drei erforderlichen Komponenten vorstellen und anschließend direkt zur Live-Demo übergehen.
Demo: lokale Inferenz 9
Die Demo soll den Aufbau verständlich machen. Sie ist kein Benchmark-Nachweis. Den bereits laufenden Inferenzprozess, das geladene Modell und den lokalen Endpunkt zeigen. Über den Coding-Agent eine kleine Frage zum Repository stellen und die Zuständigkeiten erläutern: Der Agent sendet einen Prompt, llama.cpp führt die Inferenz aus, das Modell liefert Token zurück.
Eine Aufnahme oder Screenshots bereithalten, falls das Laden zu lange dauert. Die Capstone-Aufgabe nicht als erste Demo verwenden. Eine kurze Frage mit rein lesendem Zugriff reicht. Überleitung: Mit dem konkreten Setup nun die vollständige Full-Stack-Aufgabe zeigen.
Die Capstone-Aufgabe
LOKALE MODELLE
FÜR KI-GESTÜTZTES
CODING
01
WARUM
Warum lokale Modelle?
02
WIE
llama.cpp + Gemma 4
03
DEMO
Capstone
04
PROBLEME
Geschwindigkeit und Qualität
GESCHWINDIGKEIT
Hardware
QUALITÄT
Loop / Graph Engineering
10
Zur Übersicht zurückkehren und die Demo hervorheben. Vor der Capstone-Aufgabe erklären, wie wir das Modell bewerten: den Zielkonflikt zwischen Qualität und Datensouveränität sichtbar machen, mit der Porsche-Analogie die benötigte Spitzenleistung hinterfragen und die Mindestanforderungen festlegen. Anschließend die Aufgabe zeigen, an der wir diese Anforderungen prüfen.
Qualität und Datensouveränität
Datensouveränität
Qualität
Lokale Modelle
Hohe Qualität Datensouveränität Frontier-Modelle
Maximale Qualität Keine volle Datensouveränität
Geschwindigkeit ist eine Frage des Hardwarebudgets. Leistungsfähige lokale Hardware kann mit Cloud-Inferenz mithalten.
11
Die beiden Positionen sind qualitative Einordnungen, keine gemessenen Datenpunkte. Lokale Modelle können hochwertige Entwicklungsarbeit leisten, während Modellausführung und Daten auf kontrollierter Infrastruktur bleiben. Frontier-Modelle bieten weiterhin Spitzenleistung. Geschlossene, beim Anbieter betriebene Modelle liefern unter dieser Definition jedoch keine vollständige Datensouveränität.
Verträge, regionales Hosting und technische Kontrollen können Datenschutz und Governance verbessern. Das Unternehmen kontrolliert damit aber nicht den gesamten Inferenz-Stack. Die Kreise haben bewusst keine exakten Koordinaten: Modelle, Aufgaben und Betriebsformen unterscheiden sich.
Geschwindigkeit getrennt betrachten. Die Geschwindigkeit lokaler Inferenz hängt wesentlich von Hardwarekapazität und Budget ab. Mit ausreichend leistungsfähigen Beschleunigern und einer vergleichbaren Modellkonfiguration kann ein lokales System Latenz oder Durchsatz einer Cloud-Inferenz erreichen. Überleitung: Braucht jede Softwareaufgabe die maximale Modellleistung?
Der Porsche-Test
Brauchen wir für jede Fahrt die volle Leistung? Die meisten Softwareaufgaben erreichen nie die Autobahn ohne Tempolimit und Baustelle.
Das Auto als Analogie verwenden, nicht als Beweis. Ein Sportwagen kann extrem schnell sein, aber die meisten Fahrten führen nie auf eine freie Autobahn ohne Tempolimit. Jedes System auf das seltene theoretische Maximum auszulegen, kann unnötig sein, wenn der Alltag eine niedrigere, klar definierte Anforderung stellt.
Softwareaufgaben unterscheiden sich stark. Manche brauchen tatsächlich das stärkste verfügbare Modell: neuartige Fehleranalyse, unklare Anforderungen oder die Erkundung eines großen Repositories. Viele Routineänderungen sind enger begrenzt und leichter zu prüfen. Die Frage lautet deshalb: Welches Modell erfüllt die Anforderungen unserer Arbeit zuverlässig? Überleitung: diese Anforderungen festlegen.
Mindestvoraussetzungen
Mindestvoraussetzungen statt Benchmark Mindestanforderung
Modell A
Modell B
Modell C
Kriterien ✓ Funktioniert mit Coding-Agents
✓ Bewältigt long-running tasks
✓ Mindestens 128K Token Kontext
13
Wir erstellen keine universelle Rangliste. Wir definieren Aufgaben, die unsere Arbeit abbilden, und eine Schwelle für eine akzeptable Umsetzung. Jedes Modell, das diese Schwelle wiederholt überschreitet, wird zum Kandidaten.
Für diesen Vortrag bedeutet ernsthafte Entwicklungsarbeit: Das Modell funktioniert mit einem Coding-Agent, bleibt bei längeren Aufgaben effektiv und bietet mindestens 128K Token Kontext. Darin müssen Repository-Informationen, Instructions, geladene Skills, Tool-Ergebnisse und Prüfnachweise Platz finden. 128K ist unser praktischer Mindestwert, kein allgemeiner Standard.
Benchmark-Ergebnisse hängen außerdem von Runtime, Agent und Workflow ab. Darauf kommen wir später zurück. Ein einzelner Erfolg ist ein Hinweis und keine dauerhafte Eigenschaft des Modells. Überleitung: die Anforderungen auf die Capstone-Aufgabe anwenden.
The Capstone Prompt
/goal
In my holidays overview I want a German vocabulary trainer, similar to the existing quiz feature. For destinations in German-speaking places (currently Lübeck and Vienna) users should be able to practice a few basic German words before they travel: the holiday card shows an icon when a vocabulary test is available, and opening it lets the user translate words.
Do a full-stack implementation (backend + frontend) following the structure and conventions of the existing quiz feature (architecture, feat folder, backend entity/repository/controller). The app must be accessible, and the accessible names below are required. Create and run e2e tests for the feature.
Acceptance Criteria
1 Successful Verification
- The frontend build check is pnpm ng build --optimization false.
- Start any required application dependencies using the project's existing setup, then start the backend with ./gradlew bootRun.
- Wait for the backend to become ready and verify that both the existing /heartbeat and /holiday endpoints respond successfully. Starting the process alone is not sufficient.
- Start the frontend on port 4200 and run the vocabulary feature's e2e tests with the project's Playwright setup.
- If compilation, application startup, an endpoint request, or an e2e test fails, diagnose the failure, fix the implementation, and repeat the relevant checks. Do not finish while a required check is failing.
- Stop all application processes and temporary services that you started after verification, including when a check fails.
2 Vocabulary Data
- A vocabulary test consists of exactly 5 words. Each is an English word the user must translate into German.
- Use exactly these 5 English -> German pairs, stored verbatim (capitalization and umlauts matter):
squirrel -> Eichhörnchen
turtle -> Schildkröte
refrigerator -> Kühlschrank
toothbrush -> Zahnbürste
Germany -> Deutschland
- The same 5 words are used for every destination that offers the test. Seed this data (e.g. a Flyway migration) for the German-speaking destinations Lübeck and Vienna.
3 Discovery on the Holiday Card
- A destination that has vocabulary data shows a vocabulary icon/link on its holiday card in the holidays overview, exactly like the quiz icon. Drive this off the presence of vocabulary data — do NOT hardcode a list of cities.
- The control is an accessible link with the accessible name "Vocabulary Test".
- Destinations without vocabulary data must not show it.
4 The Vocabulary Test
- Opening the "Vocabulary Test" link shows the 5 questions and a status area. Navigation, dialog, or inline panel — your choice.
- For each question, show the English word and provide a free-text input for the German translation. Each input's accessible name must contain its English word (e.g. an input labelled "squirrel"), so every input is individually identifiable regardless of order or layout.
- A status area shows three counts, each exposed with exactly these accessible names (value included): "Unanswered: N", "Correct: N", "Incorrect: N".
- The three counts are mutually exclusive and always sum to 5. Initial state: Unanswered: 5, Correct: 0, Incorrect: 0.
5 Answering
- An answer is evaluated when the user leaves (blurs) a non-empty input. There is no submit button — the counts update live on blur.
- Blurring an empty input does nothing; the question stays unanswered.
- Comparison is exact and case- and umlaut-sensitive: the typed text must exactly equal the stored German word. "Kühlschrank" is correct; "kühlschrank", "Kuhlschrank", and "Kühlschrank " are all incorrect. No trimming or normalization.
- Once a non-empty input has been evaluated it is locked (cannot be edited again). The counts update accordingly: Unanswered decreases by 1, and Correct or Incorrect increases by 1.
15
Die Folie zeigt die deutsche Übersetzung des einzelnen Capstone-Prompts. Befehle, Datenwerte und vorgeschriebene Accessible Names entsprechen dem Original. Nicht jede Zeile vorlesen.
Zuerst zeigen, dass das Ziel ein sichtbares Feature beschreibt und die bestehende Full-Stack-Architektur vorgibt. Dann den deterministischen Abschlussnachweis hervorheben: Frontend bauen, Backend starten, Bereitschaft abwarten, zwei Endpunkte prüfen, Frontend starten und Playwright ausführen.
Daten, Accessible Names und Interaktionsregeln sind bewusst exakt festgelegt. Dazu gehören die fünf Übersetzungen, die direkte Auswertung beim Verlassen eines Feldes und der Vergleich mit Groß-/Kleinschreibung. Der Prompt prüft damit auch Repository-Erkundung, Architekturtreue, Barrierefreiheit, Datenmigration, End-to-End-Integration sowie die Fähigkeit, die eigene Arbeit zu prüfen und zu korrigieren. Das gesamte Feature und die Abschlussnachweise werden in einem Prompt verlangt. Überleitung: Inferenztempo und die dafür erforderliche Hardware.
Geschwindigkeit: Hardware
LOKALE MODELLE
FÜR KI-GESTÜTZTES
CODING
01
WARUM
Warum lokale Modelle?
02
WIE
llama.cpp + Gemma 4
03
DEMO
Capstone
04
PROBLEME
Geschwindigkeit und Qualität
GESCHWINDIGKEIT
Hardware
QUALITÄT
Loop / Graph Engineering
16
Das erste praktische Problem eröffnen: Geschwindigkeit. Erklären, wie CPU, RAM, Massenspeicher, GPU und VRAM Machbarkeit und Geschwindigkeit beeinflussen. Dann konkrete Hardwareklassen zeigen. Von der physischen Kapazität zu Einsatzbereichen, Modellarchitektur, Inferenzphasen, Quantization und Inference Engines übergehen. Gemeinsam bestimmen diese Entscheidungen, was lokal laufen kann und wie schnell es läuft.
Inferenz auf CPU und GPU
CPU 1× Rechenleistung Intel Core i9-14900K
Festplatte oder SSD ≈0,1–7 GB/s BarraCuda HDD Swap · Keine Berechnung
Arbeitsspeicher ≈90–100 GB/s Dual-Channel DDR5-5600
Möglich Oft zu langsam
GPU ≈30–100× Rechenleistung RTX 4070 Super – RTX 5090
VRAM ≈500–1.800 GB/s GDDR6X – GDDR7
Praxistauglich Meist 5–10× schneller
17
Ein Modell kann auf eine Festplatte oder SSD passen, aber der Datenträger berechnet das Modell nicht. Die Bandbreite reicht von etwa 0,1 bis 0,2 GB/s bei einer normalen Festplatte über etwa 0,5 GB/s bei einer SATA-SSD bis zu rund 7 GB/s bei einer schnellen Consumer-NVMe-SSD.
llama.cpp kann die Modelldatei per Memory Mapping einbinden. Das Betriebssystem lädt die benötigten Speicherseiten in den RAM. Ist das Modell größer als der verfügbare RAM, müssen Seiten immer wieder geladen und verworfen werden. Dieses Swapping kann die Inferenz extrem verlangsamen.
CPU und Arbeitsspeicher können das Modell ohne GPU ausführen. 90 bis 100 GB/s stehen für ein normales Desktop-System mit Dual-Channel-DDR5. Die CPU bildet die Referenz mit einfacher Rechenleistung. GPU und VRAM sind der bevorzugte Weg, weil beide Komponenten schneller sind. Geeignete Consumer-GPUs erreichen etwa 500 bis 1.800 GB/s Speicherbandbreite. Ihr paralleler Matrixdurchsatz kann ein Vielfaches einer Desktop-CPU betragen.
Diese beiden Verhältnisse nicht miteinander multiplizieren. Jede Phase wird durch ihre langsamere Ressource begrenzt. Als Faustregel ist vollständige GPU-Inferenz bei der Token-Generierung oft fünf- bis zehnmal schneller als CPU-Inferenz. Beim Verarbeiten des Prompts kann der Unterschied größer sein. Die genaue Geschwindigkeit hängt von Modell, Quantization, Hardware und Runtime ab.
Unified-Memory-Systeme teilen einen Speicherpool zwischen CPU und GPU. Auch dort bestimmen Speicherbandbreite und GPU-Rechenleistung die nutzbare Geschwindigkeit.
Referenzhardware für die Bandbreiten:
- Intel Core i9-14900K mit Dual-Channel-DDR5-5600: 89,6 GB/s, gerundet etwa 90 GB/s.
- NVIDIA GeForce RTX 4070 SUPER: 504 GB/s.
- NVIDIA GeForce RTX 5090: 1.792 GB/s.
- Seagate BarraCuda ST2000DM008: bis zu 220 MB/s.
- Samsung 870 EVO: bis zu 560 MB/s.
- Samsung 990 PRO: bis zu 7.450 MB/s.
Überleitung: drei konkrete Hardwareklassen für lokale Inferenz.
Quellen:
- https://www.seagate.com/files/www-content/product-content/barracuda-fam/barracuda-new/en-us/docs/100817550L.pdf
- https://semiconductor.samsung.com/news-events/news/samsung-introduces-latest-in-its-worlds-best-selling-consumer-sata-ssd-series-the-870-evo/
- https://download.semiconductor.samsung.com/resources/brochure/990_PRO_Series_Brouchure_Web_Version_1.0.pdf
- https://www.intel.com/content/www/us/en/products/sku/236773/intel-core-i9-processor-14900k-36m-cache-up-to-6-00-ghz/specifications.html
- https://www.nvidia.com/en-us/geforce/graphics-cards/40-series/rtx-4070-family/
- https://www.nvidia.com/en-sg/geforce/graphics-cards/50-series/rtx-5090/
- https://github.com/ggml-org/llama.cpp
Hardware für lokale Inferenz
Einsteiger
RTX PRO 4000 24 GB VRAM ≈ 2.500 € pro GPU
Mac Studio 36–512 GB Unified Memory ab 2.999 €
Ambitionierte
ASUS Ascent GX10
128 GB Unified Memory
≈ 4.850 € pro System
Enterprise
RTX PRO 6000 Blackwell
96 GB VRAM pro GPU
≈ 17.700 € pro GPU
Beispielkonfigurationen, keine Kaufempfehlungen.
18
Die Beispiele zeigen Optionen für lokale Inferenz und sind keine vollständige Kaufberatung. Die erste Spalte enthält bewusst zwei Ansätze. Die NVIDIA RTX PRO 4000 Blackwell ist eine separate GPU mit 24 GB GDDR7-VRAM und 672 GB/s Speicherbandbreite. 24 GB sind ein möglicher Einstieg für quantisierte Coding-Modelle. Welche Modelle tatsächlich passen, hängt auch von Kontext und KV Cache ab. „Consumer“ beschreibt hier die Größe des Setups. RTX PRO gehört zu NVIDIAs professioneller Produktreihe. Rund 2.500 € aus österreichischen Händlerangeboten kaufen nur die GPU, keinen vollständigen Rechner.
Der Mac Studio ist die integrierte Alternative. Die Konfigurationen der übernommenen Folie verwenden M5 Max oder M5 Ultra mit 36 bis 512 GB Unified Memory. 512 GB ist das konfigurierbare Maximum. M5 Max reicht von 36 bis 128 GB, M5 Ultra von 96 bis 512 GB. Die genannten österreichischen Einstiegspreise betragen 2.999 € beziehungsweise 6.599 €. Laut der zugrunde liegenden Ankündigung soll die 512-GB-Option Ende Oktober 2026 verfügbar werden; ihr endgültiger Preis war noch nicht ausgewiesen. Unified Memory wird zwischen CPU und GPU geteilt und ist nicht unmittelbar mit dediziertem VRAM gleichzusetzen. Die größeren Konfigurationen können sehr große quantisierte Modelle aufnehmen. Der Mac Studio ist eine Produktfamilie mit unterschiedlichen Kapazitäten.
Die mittlere Klasse bildet der ASUS Ascent GX10. Sein NVIDIA GB10 Grace Blackwell Superchip verwendet 128 GB kohärenten LPDDR5x-Unified-Memory. Das bietet deutlich mehr Modellkapazität als eine 24-GB-GPU. Die Speicherbandbreite von 273 GB/s liegt jedoch unter der leistungsfähiger separater GPUs. Die übernommenen österreichischen Händlerpreise beginnen für das 1-TB-System bei etwa 4.850 €. ASUS hatte ursprünglich 3.499 € als unverbindliche Preisempfehlung angekündigt. Verfügbarkeit und Straßenpreise sind deshalb relevant.
Die Enterprise-Klasse verwendet RTX PRO 6000 Blackwell GPUs mit jeweils 96 GB GDDR7-ECC-Speicher. Die übernommenen österreichischen Angebote für die NVIDIA Workstation Edition beginnen bei rund 17.700 € pro Karte. Drei Karten bedeuten damit bereits über 50.000 € allein für GPUs. Mehrere Karten erhöhen Kapazität und Durchsatz. Sie bilden für ein Modell aber nicht automatisch einen gemeinsamen Speicherpool. Die Runtime muss das Modell aufteilen oder replizieren; die Verbindung zwischen den Karten spielt ebenfalls eine Rolle.
Alle Preise sind gerundete Momentaufnahmen vom 7. September 2026. Überleitung: von den Rechnern zu den Modellgrößen und Einsatzbereichen.
Quellen:
- https://www.nvidia.com/en-us/products/workstations/professional-desktop-gpus/rtx-pro-4000/
- https://geizhals.at/nvidia-rtx-pro-4000-blackwell-900-5g147-2570-000-a3488409.html
- https://www.apple.com/at/newsroom/2026/08/apple-introduces-new-mac-studio-with-m5-max-and-m5-ultra/
- https://www.apple.com/at/mac-studio/specs/
- https://www.asus.com/networking-iot-servers/desktop-ai-supercomputer/ultra-small-ai-supercomputers/asus-ascent-gx10/
- https://www.idealo.at/preisvergleich/OffersOfProduct/208466423_-ascent-gx10-asus.html
- https://www.nvidia.com/en-us/products/workstations/professional-desktop-gpus/rtx-pro-6000-family/
- https://geizhals.at/nvidia-rtx-pro-6000-blackwell-workstation-edition-900-5g144-2500-000-a3476784.html
- https://www.apple.com/v/mac-studio/specs/b/images/specs/hero__d0yd117u6qy6_large_2x.jpg
- https://dlcdnwebimgs.asus.com/gain/c66958f8-57de-4563-b0db-bd317bfaf1f3/w800
Einsatzbereiche
Modellgröße nach Einsatzbereich
Parameterlog. Skala
10T
1T
100B
10B
1B
Gemma 4 E2B 5,1B gesamt
Gemini Nano ≈2–4B
Browser / Embedded Modelle laufen im Browser
Gemma 4 12B 11,95B gesamt
Qwen3-Coder 30,5B gesamt
24-GB-Klasse Consumer-GPU oder Laptop
Nemotron 3 Super 120B gesamt
Qwen3.8 Flash Next 180B gesamt
128-GB-Klasse 4-Bit-Workstation oder DGX Spark
DeepSeek V4 Flash 284B gesamt
GLM-5.3 753B gesamt
Kimi K3 2,8T gesamt
Open-Weight-Rechenzentrum Systeme mit mehreren Beschleunigern
Gemini ≈3,0T
GPT-6 ≈3,8T
Grok ≈3,9T
Claude ≈6T
Geschlossene Frontier-Modelle Betrieb beim Anbieter
Einsatzbereich
Werte geschlossener Modelle sind Schätzungen aus öffentlichen Benchmark-Daten [1][2]. Parameterzahlen sind nicht offengelegt. Typischer Fehler: Faktor ≈2.
19
Die Grafik von links nach rechts lesen. Die horizontale Achse zeigt fünf Einsatzbereiche. Die vertikale Achse ist logarithmisch: Jeder große Schritt bedeutet zehnmal so viele Gesamtparameter. So bleiben Modelle von wenigen Milliarden bis mehreren Billionen Parametern auf einer Folie lesbar. Der Abstand zeigt ein Verhältnis, keine einfache Differenz. B steht in den Modellbezeichnungen für Milliarden, T für Billionen.
Gemma 4 E2B und Gemini Nano zeigen zwei Wege für kleine Modelle auf Endgeräten. Gemma 4 E2B ist ein Open-Weight-Checkpoint mit 2,3B effektiven und einschließlich der schichtspezifischen Embeddings 5,1B Gesamtparametern. Die Grafik verwendet 5,1B, weil ihre Achse Gesamtparameter zeigt. E bedeutet „effective“.
Googles ursprünglicher Gemini-1-Bericht nennt zwei Nano-Modelle mit 1,8B und 3,25B Parametern, jeweils auf 4 Bit quantisiert. Die für die Folie verwendete Chrome-Dokumentation beschreibt hardwareabhängige Varianten mit etwa 2B und 4B. Chrome kann nach einer Prüfung des Geräts die passende Variante herunterladen. Welche Variante installiert ist, kann sich mit Browser-Updates ändern und lässt sich unter chrome://on-device-internals prüfen.
Herunterladbar bedeutet nicht Open Weights. Chrome lädt, aktualisiert und entfernt das Modell als Browserkomponente. Eine Webanwendung nutzt die Prompt API, erhält aber keine Gewichtsdateien zur Weitergabe, Inspektion oder Ausführung in einer anderen Inference Engine. Gemma wird von Google gesondert als offene Modellfamilie geführt. Gemini Nano läuft lokal und wird heruntergeladen, ist aber nicht im selben Sinn ein Open-Weight-Modell wie Gemma, Llama oder Qwen.
Gemma 4 12B hat 11,95B Parameter und ist für Laptops, Desktops und kleine Server positioniert. Qwen3-Coder 30B-A3B kann bei starker Quantization in die 24-GB-Klasse passen. Sein nativer Kontext umfasst 262.144 Token. Auf einer 24-GB-Maschine ist in der Praxis meist ein kürzerer Kontext nötig, weil auch der KV Cache Speicher beansprucht.
Die 128-GB-Klasse zeigt zwei Beispiele. NVIDIA Nemotron 3 Super hat 120B Gesamtparameter, davon 12B aktiv, und bis zu 1M Kontext. Sein NVFP4-Checkpoint zielt auf Blackwell-Hardware und ist damit für Systeme der DGX-Spark-Klasse relevant.
Qwen3.8-Flash-Next ist der knappste Kandidat dieser Gruppe. Hugging Face nennt insgesamt 180B Parameter: ein Sprachmodell mit 125B, davon 6B aktiv, außerdem 51B für N-Gramm-Embeddings und 4B für Multi-Token-Prediction. Eine einfache 4-Bit-Schätzung ergibt etwa 90 GB allein für die Gewichte. Das native Kontextfenster beträgt 262.144 Token. Auf 128 GB muss der praktische Kontext verkürzt oder der Cache quantisiert werden, damit Gewichte, KV Cache und Runtime gemeinsam passen. Es handelt sich um 4-Bit-Kandidaten, keine garantierten Konfigurationen.
DeepSeek V4 Flash hat 284B Gesamtparameter und aktiviert 13B pro Token. GLM-5.3 hat insgesamt 753B. Kimi K3 hat insgesamt 2,8T und aktiviert 104B pro Token.
Die Anbieter legen die Parameterzahlen von Claude Fable 5.1, GPT-6 Astra, Grok 4.6 und Gemini 3.8 Flash nicht offen. Die Grafik zeigt eigene Berechnungen, keine Herstellerangaben. Grundlage ist das öffentliche Frontier Parameter Model [1]. Es schätzt eine parameteräquivalente Größe aus Checkpoints bekannter Größe, Veröffentlichungsdatum und Artificial Analysis Intelligence Index. Kimi K3 mit veröffentlichten 2,78T bildet einen Anker. Die veröffentlichte Formel dieses Zweigs lautet: P = 2.780T × 10^(0.045205959 × (AA − 57.112339) − 0.350927951 × Alter in Jahren). Die verwendeten Scores und Daten ergeben 6,12T für Fable 5.1, 3,82T für Astra, 3,93T für Grok 4.6 bei AA 61 und Veröffentlichung am 12. August sowie 3,04T für Gemini 3.8 Flash bei AA 59 und Veröffentlichung am 2. September. Die Folie rundet diese Werte.
Das Verfahren rekonstruiert keine tatsächlichen proprietären Gewichte und verrät weder Architektur noch aktive Parameter. Die Rücktests melden einen medianen Fehler nahe Faktor 2 und konservativ etwa Faktor 3 für einen neuen Modellentwickler [3]. Grok 4.6 baut auf Grok 4.5 auf; Gemini 3.8 Flash ist auf Geschwindigkeit und Kosteneffizienz ausgelegt. Post-Training und Serving können die Leistungsfähigkeit steigern, ohne die Gewichte proportional zu vergrößern. Die vier Werte dienen einer einheitlichen grafischen Einordnung und eignen sich nicht zur Hardwaredimensionierung.
Quellen:
- https://ai.google.dev/gemma/docs/core/model_card_4
- https://huggingface.co/google/gemma-4-E2B
- https://deepmind.google/gemini/gemini_1_report.pdf
- https://developer.chrome.com/docs/ai/understand-built-in-model-management
- https://developer.chrome.com/docs/ai/get-started
- https://ai.google.dev/
- https://huggingface.co/nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4
- https://huggingface.co/Qwen/Qwen3.8-Flash-Next
- https://github.com/anpaure/frontier-model-sizes#live-factor-models
- https://artificialanalysis.ai/models/
- https://artificialanalysis.ai/articles/grok-4-6-benchmarks-and-analysis/
- https://artificialanalysis.ai/articles/gemini-3-8-flash
- https://github.com/anpaure/frontier-model-sizes/blob/main/MODEL_READINESS.md#precision
- https://x.ai/news/grok-4-6
- https://blog.google/innovation-and-ai/models-and-research/gemini-models/3-8-flash-and-3-8-flash-cyber/
- https://openai.com/index/gpt-6-astra/
- https://www.anthropic.com/claude/fable
- https://huggingface.co/google/gemma-4-12B
- https://huggingface.co/Qwen/Qwen3-Coder-30B-A3B-Instruct
- https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash
- https://huggingface.co/zai-org/GLM-5.3
- https://huggingface.co/moonshotai/Kimi-K3
Die Gemma-4-Familie
Dense Gleicher Pfad für jedes Token Mixture of Experts Router wählt Experten aus
Parameter insgesamt
30B 20B 10B 0
E2B 5,1B gesamt Dense
E4B 8B gesamt Dense
26B-A4B 25,2B gesamt MoE
E Kerngröße ohne große Embedding-Tabellen
A Pro Token vom Router ausgewählte Parameter
20
Gemma 4 ist eine Familie. Die lineare vertikale Skala zeigt die Gesamtparameter: Ein Balken mit 5,1B ist etwa ein Sechstel so hoch wie einer mit 30,7B. Blau und Grün unterscheiden die Architektur. Bei den blauen Dense-Modellen folgt jedes Token demselben Netzwerkpfad. Grün markiert Mixture of Experts: Ein Router wählt pro Token nur einen Teil der Experten aus.
„Effective“ und „active“ klingen ähnlich, bezeichnen aber unterschiedliche Mechanismen. Bei E2B und E4B steht E für „effective“. Diese Dense-Modelle enthalten große Embedding-Tabellen pro Schicht. Sie müssen gespeichert werden, werden pro Token aber nur durch schnelle Lookups angesprochen. Google beschreibt deshalb den Rechenkern mit 2,3B beziehungsweise 4,5B effektiven Parametern. Die vollständig gespeicherten Modelle enthalten 5,1B beziehungsweise 8B.
Bei 26B-A4B bedeutet A „active“. Das vollständige MoE-Modell hat 25,2B Parameter. Pro Token wählt der Router in jeder MoE-Schicht acht Experten aus 128 sowie einen gemeinsamen Experten. Rund 3,8B Parameter nehmen an der Berechnung teil. Für schnelle Inferenz müssen trotzdem alle 25,2B Parameter in den Speicher passen.
12B und 31B sind Dense-Modelle mit 11,95B und 30,7B Parametern. Alle fünf sind multimodal. E2B und E4B unterstützen 128K Kontext, die übrigen Varianten 256K. Parameterzahl ist nur ein Einflussfaktor: Quantization, Kontextgröße und Architektur bestimmen den tatsächlichen Speicherbedarf und die Geschwindigkeit.
Quellen:
- https://ai.google.dev/gemma/docs/core/model_card_4
Speicherbedarf
Empfohlen Vollständig im VRAM
Einflussfaktoren Modellgröße Quantisierung KV Cache Kontextgröße Betriebsspeicher
21
Das empfohlene Ziel ist, die gesamte Inferenzlast im GPU-Speicher zu halten. So müssen während der Token-Generierung keine Modelldaten zwischen Datenträger, RAM und VRAM verschoben werden.
Mit der Modellgröße beginnen. Quantization bestimmt den Speicher für Gewichte einschließlich Skalen und Metadaten. Der KV Cache kommt hinzu und wächst mit der Kontextgröße. Seine genaue Größe hängt auch von Architektur, Cache-Präzision und Batch-Größe ab. Betriebsspeicher umfasst Inference Engine, temporäre Rechenpuffer und Overhead der Speicherverwaltung.
Reserve lassen, statt die beworbene VRAM-Kapazität vollständig zu verplanen. Bei Unified Memory teilen sich CPU und GPU einen Speicherpool. Bandbreite, Zuweisungsgrenzen und Betriebssystem reduzieren weiterhin den für das Modell verfügbaren Anteil. Überleitung: Quantization verändert den größten Teil der Rechnung, den Gewichtsspeicher.
Das Prinzip der Quantisierung
‹ Ⅱ Pause › 0:00.0 / 0:06.4 ↻ Neustart
Ursprünglicher Bereich 0–100
0 100
18
47
83
÷ 10, dann runden
Quantisierter Bereich 0–10
18 2
47 5
83 8
Rekonstruiert × 10
20 Δ −2
50 Δ −3
80 Δ +3
Δ = Original − rekonstruiert
22
Mit einem bewusst einfachen Beispiel beginnen. Die ursprünglichen Werte liegen zwischen 0 und 100. Wir wählen die Skala 10, teilen jeden Wert durch 10 und runden auf die nächste ganze Zahl. Aus 18 wird 2, aus 47 wird 5, aus 83 wird 8. Gespeichert wird einer von elf ganzzahligen Werten statt der feineren Ausgangszahl.
Für eine ungefähre Rekonstruktion multiplizieren wir wieder mit 10. Das ergibt 20, 50 und 80. Wir definieren Δ = Original − rekonstruiert. Damit ergeben sich 18 − 20 = −2, 47 − 50 = −3 und 83 − 80 = +3. Dieser Quantisierungsfehler entsteht, weil die beim Runden verlorene Information nicht exakt wiederhergestellt werden kann.
Echte Modell-Quantization kann unterschiedliche Skalen und Nullpunkte für Tensoren, Kanäle oder Gruppen verwenden. Manche Verfahren kalibrieren anhand von Daten oder behandeln wichtige Gewichte gesondert. Die Animation erklärt das Grundprinzip, kein bestimmtes Dateiformat. Überleitung: den Zusammenhang zwischen Bitzahl und Gewichtsspeicher zeigen.
Die passende Quantisierung
Qualität höhere Genauigkeit
Speicher- und Dateigröße kleiner größer
Lokaler Sweet Spot
Q2 Notlösung
Q3 wenig Speicher
Q4 Standardstart
Q5/6 konservativ
Q8 referenznah
BF16 Referenzgröße
Faustregel Mit Q4 starten. Bei Qualitätsproblemen höher gehen.
23
Die Grafik zeigt eine praktische Richtung, keine universelle Benchmark-Kurve. Von Q2 zu Q8 oder BF16 steigen meist Dateigröße und Speicherbedarf, während mehr vom Verhalten des Referenzmodells erhalten bleibt. Der genaue Qualitätsunterschied hängt von Modell, Quantisierungsverfahren, Kalibrierungsdaten, Runtime und Aufgabe ab. Q4 oder Q5 bezeichnen Formatfamilien, kein einheitliches Verfahren.
Eine gut unterstützte Q4-Quantization ist oft ein sinnvoller Start. Zu Q5 oder Q6 wechseln, wenn das Modell bequem passt und die Evaluation relevante Qualitätsverluste zeigt. Unter Q4 nur gehen, wenn das Modell sonst nicht in den Speicher passt. Starke Quantization kann Reasoning und Coding-Zuverlässigkeit beeinträchtigen.
Q8 bleibt oft nahe an der Referenz, spart aber deutlich weniger Speicher als Q4. BF16 steht hier für die höherpräzise Referenz. Immer die konkrete Modelldatei qualifizieren, nicht allein das Label. Überleitung: Videocodecs zeigen, wie Kompressionsverfahren über Generationen besser werden können.
Videokompression im Zeitverlauf
1993 MPEG-1 ≈ 600 MB 1995 MPEG-2 / H.262 ≈ 300 MB 2003 H.264 / AVC ≈ 150 MB 2013 H.265 / HEVC ≈ 75 MB 2018 AV1 ≈ 60 MB 2020 H.266 / VVC ≈ 38 MB
24
Das wiederholte Bild ist Absicht: Wir vergleichen die Datenmenge für einen ungefähr gleichen wahrgenommenen Bildeindruck. Die Dateigrößen sind ein veranschaulichendes Beispiel für eine Minute 1080p-Video. Angenommen werden 80 Mbit/s für MPEG-1, 40 für MPEG-2, 20 für H.264, 10 für HEVC, 8 für AV1 und 5 für VVC.
Dateigröße = Bitrate × 60 Sekunden ÷ 8. Daraus ergeben sich etwa 600, 300, 150, 75, 60 und 37,5 MB. Das sind keine Messungen eines universellen Benchmarks. MPEG-1 wurde für CIF- oder SIF-Auflösungen der Video-CD-Zeit entwickelt. Sein 1080p-Wert ist eine gedankliche Extrapolation.
Die späteren Werte veranschaulichen die dokumentierten Fortschritte: H.264 kann vergleichbare Qualität bei ungefähr halber MPEG-2-Bitrate liefern; HEVC strebt eine weitere Halbierung an. AV1 erschien 2018 als offener, lizenzgebührenfreier Codec. Praxistests zeigen deutliche Einsparungen gegenüber H.264 und VP9. VVC zielt auf etwa die halbe HEVC-Bitrate.
Tatsächliche Größen hängen von Inhalt, Encoder, Profil, Einstellungen und Qualitätsziel ab. Neuere Codecs können mehr Rechenleistung brauchen. Die Analogie zur Modell-Quantization: Bessere Algorithmen können mehr nutzbare Qualität in einer kleineren Darstellung erhalten. Daraus folgt nicht, dass jedes neuere Verfahren oder jedes quantisierte Modell besser ist. Das konkrete Artefakt muss weiterhin mit unseren Aufgaben getestet werden.
Quellen:
- https://mpeg.chiariglione.org/standards/mpeg-1/video.html
- https://www.itu.int/rec/T-REC-H.262-199507-S/en
- https://www.itu.int/rec/T-REC-H.264-200305-P
- https://www.itu.int/net/pressoffice/press_releases/2013/01.aspx
- https://aomedia.org/press%20releases/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/
- https://engineering.fb.com/2018/04/10/video-engineering/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/
- https://www.hhi.fraunhofer.de/en/departments/vca/technologies-and-solutions/h266-vvc/vvc-overview.html
Prefill und Decoding ohne KV Cache
‹ Ⅱ Pause › 0:00.0 / 0:18.5 ↻ Neustart
Prefill Rechenleistung limitiert
Decode Berechnet Kontext neu
Nutzereingabe Tool-Antwort Thinking
Bitte erstelle eine getestete Komponente
mit unserem bestehenden Signal Store
und ergänze die Backend Integration
Vorhergesagtes Token Hier das fertige Ergebnis
Hier das fertige
Eingabe Hier das fertige
25
Diese erste Animation nimmt bewusst an, dass es keinen KV Cache gibt. Beim Prefill durchläuft die gesamte Eingabe alle Transformer-Schichten; das Modell sagt das erste neue Token voraus. Dieses Token wird anschließend Teil der Eingabe.
Ohne gespeicherte Keys und Values benötigt die nächste Vorhersage einen weiteren Durchlauf über die gesamte Sequenz. Die Animation bewegt die vollständige, wachsende Sequenz Schicht für Schicht durch das Modell. Erst danach entsteht das nächste Token.
Die Modellparameter werden dabei nicht jedes Mal neu in das Modell verschoben. Sie bleiben im Speicher, und die Berechnung liest sie bei jedem Durchlauf erneut. Mit wachsender Sequenz wird die wiederholte Verarbeitung des gesamten Kontexts immer aufwendiger. Überleitung: Der KV Cache vermeidet einen großen Teil dieser Wiederholung.
KV Cache während der Inferenz
‹ Ⅱ Pause › 0:00.0 / 0:12.5 ↻ Neustart
Prefill Baut den Cache auf
Decode Nutzt den Cache erneut
Nutzereingabe Tool-Antwort Thinking KV Cache
Bitte erstelle eine getestete Komponente
mit unserem bestehenden Signal Store
und ergänze die Backend Integration
Vorhergesagtes Token Hier das fertige Ergebnis
Hier das fertige
Eingabe Hier das fertige
26
KV steht für Key-Value. Der Rahmen ist eine Verständnishilfe: Der Cache speichert nicht die hier gezeigten Token-Beschriftungen. Beim Prefill berechnet jede Transformer-Schicht Key- und Value-Tensoren für die Eingabe-Token und speichert sie im KV Cache.
Beim Decoding ergänzt das Modell die Tensoren des neuen Tokens und verwendet die vorhandenen Tensoren wieder. Es muss dadurch nicht bei jeder Vorhersage die gesamte vorherige Sequenz neu berechnen. Das macht autoregressives Decoding praktikabel.
Der Cache wächst dennoch mit Tokenzahl, Schichtzahl, Attention-Struktur, Batch-Größe und Cache-Präzision. Bei langen Kontexten kann er erheblich VRAM beanspruchen. Überleitung: die Komponenten auf zwei konkrete Speicherplanungen anwenden.
Speicherbedarf: Gemma 4 26B-A4B IT QAT UD-Q4_K_XL von unsloth · 3,8B aktiv / 25,2B gesamt · ein Inferenz-Slot · F16 KV Cache
Modellgröße KV Cache Runtime
Speicher in VRAM / Unified Memory (GiB)
0 4 8 12 16 20 22
16,72 GiB 13,27 GiB Modell
1,45 GiB KV
2 GiB Runtime
64K 17,97 GiB 13,27 GiB Modell
2,70 GiB KV
2 GiB Runtime
128K 20,47 GiB 13,27 GiB Modell
5,20 GiB KV
2 GiB Runtime
256K
Kontextgröße
Alle 25,2B Parameter müssen in den Speicher passen. Summen enthalten 2 GiB Runtime-Reserve.
27
Dies ist eine Kapazitätsschätzung für das angegebene quantisierte Gemma-4-26B-A4B-Artefakt. Die Gewichtsdatei bleibt für jede Kontextgröße bei 13,27 GiB. A4B bedeutet, dass pro Token etwa 3,8 Milliarden der insgesamt rund 25,2 Milliarden Parameter aktiv sind. Das kann Rechenaufwand sparen, macht das Modell aber nicht zu einem 4B-Modell beim Speicherbedarf. Alle Expertengewichte müssen im Speicher liegen.
Der F16 KV Cache wächst von 1,45 GiB bei 64K auf 2,70 GiB bei 128K und 5,20 GiB bei 256K. Die Runtime-Schätzung liegt zwischen 1 und 2 GiB. Die angezeigten Summen verwenden konservativ 2 GiB: 16,72, 17,97 und 20,47 GiB.
Die tatsächliche Zuweisung hängt von Runtime, Backend, Batch-Einstellungen und Modelldatei ab. Vor einer Zusage die Startprotokolle prüfen. Überleitung: mit dem Dense-Modell Qwen 3.8 27B vergleichen.
Speicherbedarf: Qwen 3.8 27B UD-Q4_K_XL von unsloth · 27B Dense · 16 KV-Schichten · ein Inferenz-Slot · F16 KV Cache
Modellgröße KV Cache Runtime
Speicher in VRAM / Unified Memory (GiB)
0 6 12 18 24 30 36
22,39 GiB 16,39 GiB Modell
4,00 GiB KV
2 GiB Runtime
64K 26,39 GiB 16,39 GiB Modell
8,00 GiB KV
2 GiB Runtime
128K 34,39 GiB 16,39 GiB Modell
16,00 GiB KV
2 GiB Runtime
256K
Kontextgröße
Hybride Architektur: 16 von 64 Schichten vergrößern den KV Cache. Summen enthalten 2 GiB Runtime-Reserve.
28
Die Schätzung verwendet das von unsloth veröffentlichte UD-Q4_K_XL-Artefakt mit 17,6 GB dezimal beziehungsweise 16,39 GiB. Qwen 3.8 27B hat 64 Schichten, davon 16 mit vollständiger Attention, vier KV-Heads und eine Head-Dimension von 256.
Mit F16-Keys und -Values beträgt der wachsende KV Cache 4 GiB bei 64K, 8 GiB bei 128K und 16 GiB beim nativen Kontext von 256K. Mit 2 GiB Runtime-Reserve ergeben sich 22,39, 26,39 und 34,39 GiB.
Der Vision-Projector ist nicht enthalten. Tatsächliche llama.cpp-Zuweisungen, Zustands-Checkpoints und Batch-Einstellungen können zusätzliche Reserve erfordern.
Quellen:
- https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/blob/main/Qwen3.8-27B-UD-Q4_K_XL.gguf
- https://huggingface.co/Qwen/Qwen3.8-27B
- https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/config.json
Qualität: Loop / Graph Engineering
LOKALE MODELLE
FÜR KI-GESTÜTZTES
CODING
01
WARUM
Warum lokale Modelle?
02
WIE
llama.cpp + Gemma 4
03
DEMO
Capstone
04
PROBLEME
Geschwindigkeit und Qualität
GESCHWINDIGKEIT
Hardware
QUALITÄT
Loop / Graph Engineering
29
Das zweite praktische Problem eröffnen: Qualität. Das Modell wird Fehler machen. Der umgebende Workflow muss seine Ergebnisse bewerten und die Kontrolle behalten. Zeigen, wie begrenzte Modellsessions, deterministische Validierung, unabhängige Reviews und neue Korrekturversuche die Zuverlässigkeit verbessern.
Das umgebende System
Engineering rund um das Modell Modelle machen Fehler. Das umgebende System muss sie erkennen und die Kontrolle behalten.
Jeden Modelldurchlauf begrenzen und extern prüfen, damit interne Loops den Workflow nicht blockieren.
Eine gut strukturierte Codebasis gibt dem Modell verlässliche Muster vor.
Projektspezifische Instructions und Skills vermitteln Angular, Spring, Playwright und die Projektkonventionen.
Lokale Inferenz rund um die Uhr ermöglicht Loop / Graph Engineering mit unabhängigen Reviews und wiederholter Validierung.
30
Keine Perfektion vom Modell erwarten. Das umgebende System muss Fehler erkennen und die Kontrolle behalten.
Erstens: Jeden Modelldurchlauf begrenzen und außerhalb der Modellsession prüfen. Kleinere lokale Modelle können ihre eigene Verifikation beginnen, Prüfungen endlos wiederholen und die Kontrolle nicht zurückgeben. Dann kann der äußere Agent-Loop nicht fortfahren. Externe Builds, Tests und Browserprüfungen liefern ein unabhängiges Ergebnis. Der orchestrierende Workflow entscheidet über den nächsten Schritt.
Zweitens: Mit einer gut strukturierten Codebasis beginnen. Das Modell orientiert sich an der vorhandenen Anwendung. Klare Architektur, einheitliche Konventionen und guter bestehender Code liefern verlässliche Muster.
Drittens: Wissen über die konkrete Anwendung in Instructions und wiederverwendbaren Skills festhalten. Allgemeine Angular-Hinweise sind nur der Anfang. Der Agent braucht auch die Spring-Muster, Playwright-Konventionen und weiteren Regeln des Projekts.
Schließlich den Betriebsvorteil lokaler Inferenz nutzen. Das Modell kann kontinuierlich laufen. Ein Workflow kann dadurch mehr Zeit für eine Aufgabe aufwenden, unabhängige Review-Agents einsetzen und wiederholt validieren. Bei Frontier-Modellen können dieselben Durchläufe schwerer zu rechtfertigen sein, weil sie Anbieter-Token und Kontingent verbrauchen. Die Strukturierung in begrenzte Modellsessions, Tools, Reviews und Validierungsschritte ist Loop / Graph Engineering. Überleitung: den konkreten Loop zeigen.
Ein praktischer Einstieg
Q4-quantisiert Gemma 4
+
24 GB VRAM
Ein Einstieg ins lokale KI-gestützte Coding
32
Die praktische Antwort auf die Titelfrage: Gemma 4 26B-A4B ist mit der zuvor gezeigten Q4-Quantization ein Einstieg in lokales Coding. Unsere Planung für Modell, F16 KV Cache und Runtime liegt bei rund 18 GiB für 128K Kontext und 20,5 GiB für 256K. Daraus ergibt sich die 24-GB-Hardwareklasse als Einstieg.
Die tatsächliche Speicherzuweisung hängt von Runtime und Einstellungen ab. Deshalb Startprotokolle prüfen. Größere Open-Weight-Modelle, darunter DeepSeek, bleiben interessant. Sie benötigen aber mehr Hardware und eine eigene Qualifikation. Für ein erstes System mit Gemma 4 beginnen und einen kontrollierten Agent-Loop darum aufbauen.
Vielen Dank
Fragen? Lokale Modelle für KI-gestütztes Coding
Dein Feedback zum Vortrag Dem Publikum danken. Der QR-Code öffnet https://soverius.ai. Die Abschlussfolie nach den Fragen sichtbar lassen.
Quellen:
- https://soverius.ai
Claude Code
llama.cpp
Gemma 4
