Gemma 4 als lokales Modell in Codex CLI ausführen

(blog.danielvaughan.com)

40 Punkte von GN⁺ 16 일 전 | 6 Kommentare | Auf WhatsApp teilen

Gemma 4 wurde statt in der Cloud in einer lokalen Codex-CLI-Umgebung ausgeführt, um die Leistung und Stabilität bei Tool-Aufrufen zu prüfen; dabei bestätigten sich Vorteile bei Kosten und Privatsphäre gegenüber GPT-5.4
Auf einem Mac (M4 Pro) mit 24 GB mit 26B MoE und auf einem NVIDIA GB10 mit 128 GB mit 31B Dense wurde dieselbe Codegenerierungsaufgabe jeweils mit llama.cpp und Ollama ausgeführt, um die Leistung je nach Setup zu vergleichen
Die Erfolgsquote bei Tool-Aufrufen stieg von 6,6 % auf 86,4 %, was die praktische Nutzbarkeit lokaler Modelle belegt; in der GB10-Umgebung wurde eine vollständige Codegenerierung erreicht
Der Mac zeigte eine 5,1-fach höhere Token-Generierungsgeschwindigkeit, benötigte aber wegen Speichergrenzen und Quantisierungseinstellungen mehrere Wiederholungen; der GB10 war langsamer, schaffte es jedoch im ersten Versuch
Insgesamt zeigt sich, dass auch lokale Modelle Code auf Praxistauglichkeitsniveau erzeugen können; empfohlen wird ein hybrider Ansatz mit lokalem, datenschutzorientiertem Arbeiten und Auslagerung komplexer Aufgaben in die Cloud

Motivation für den Wechsel zu lokalen Modellen

Das Kostenproblem: Codex CLI wurde täglich in mehreren Sitzungen, teils parallel, ausgeführt, wodurch sich API-Kosten aufsummierten
Die Privatsphäreanforderung: Manche Codebasen dürfen nicht an externe Server übertragen werden
Der Bedarf an Stabilität: Cloud-APIs bergen Risiken wie Throttling, Ausfälle und Preisänderungen
Der frühere Grund gegen lokale Modelle war fehlendes Tool Calling; der Kernwert von Codex CLI besteht darin, dass das Modell Dateien lesen, Code schreiben, Tests ausführen und Patches anwenden kann
Frühere Gemma-Generationen lagen im tau2-bench-Benchmark für Function Calling bei 6,6 % (93 Fehlschläge in 100 Versuchen), während Gemma 4 31B auf 86,4 % sprang und damit überhaupt erst testenswert wurde

Einrichtung auf dem Mac

Begonnen wurde mit Ollama, doch in v0.20.3 trat bei Gemma 4 ein Streaming-Bug auf, bei dem Antworten für Tool Calling fälschlich als reasoning output statt im tool_calls-Array geroutet wurden
Bei Gemma 4 auf Apple Silicon kam es bei Prompts ab etwa 500 Tokens zu einem Flash-Attention-Freeze; da der System-Prompt von Codex CLI etwa 27.000 Tokens umfasst, war das praktisch unbrauchbar
Nach dem Wechsel zu llama.cpp und der Installation per Homebrew waren für den funktionierenden Server-Befehl 6 zentrale Flags nötig
- -np 1: Beschränkung auf 1 Slot; mehrere Slots vervielfachen den Speicherbedarf des KV-Caches
- -ctk q8_0 -ctv q8_0: KV-Cache-Quantisierung, wodurch der Speicherbedarf von 940 MB auf 499 MB sank
- --jinja: zwingend erforderlich für das Tool-Calling-Template von Gemma 4
- In -m musste der GGUF-Pfad direkt angegeben werden; bei Verwendung des Flags -hf wurde automatisch ein 1,1-GB-Vision-Projector heruntergeladen, was zu OOM-Abstürzen führte
In der Codex-CLI-Konfiguration war web_search = "disabled" zwingend, da Codex CLI sonst den Tool-Typ web_search_preview sendet, den llama.cpp ablehnt

Einrichtung auf dem GB10

vLLM 0.19.0 war gegen PyTorch 2.10.0 kompiliert, doch CUDA-fähiges PyTorch für aarch64 Blackwell (compute capability sm_121) gab es nur als 2.11.0+cu128; dadurch trat wegen ABI-Inkompatibilität ein ImportError auf
Wurde llama.cpp mit CUDA aus dem Quellcode gebaut, liefen Kompilierung und Benchmarks zwar durch, aber der von Codex CLI mit wire_api = "responses" gesendete Nicht-Function-Tool-Typ wurde von llama.cpp abgelehnt
Mit Ollama v0.20.5 funktionierte es; der auf Apple Silicon auftretende Streaming-Bug ließ sich auf NVIDIA nicht reproduzieren
- Nach ollama pull gemma4:31b wurde Port 11434 per SSH-Tunnel an den Mac weitergeleitet (weil der --oss-Modus von Codex CLI nur localhost prüft)
- Mit codex --oss -m gemma4:31b funktionierten sowohl Textgenerierung als auch Tool Calling direkt im ersten Versuch
Das Mac-Setup nahm den Großteil eines Nachmittags in Anspruch, das GB10-Setup einschließlich Modelldownload nur etwa 1 Stunde

Benchmark-Ergebnisse

Alle drei Konfigurationen erhielten dieselbe Aufgabe: Mit codex exec --full-auto die Python-Funktion parse_csv_summary schreiben, inklusive Fehlerbehandlung, Tests erstellen und ausführen
GPT-5.4 (Cloud): erzeugte Code mit Type Hints, sauberem Exception Chaining, Erkennung von Booleschen Typen und ordentlichen Helper-Funktionen; bestand alle 5 Tests im ersten Versuch, war in 65 Sekunden fertig und benötigte keine Nacharbeit
GB10 31B Dense: ohne Type Hints oder Bool-Erkennung, aber mit robuster Fehlerbehandlung und ohne Dead Code; bestand alle 5 Tests im ersten Versuch nach 3 Tool-Aufrufen, benötigte 7 Minuten
Mac 26B MoE: hinterließ Dead Code in der Implementierung, schrieb zunächst eine Schleife zur Typinferenz und ließ sie stehen, um darunter mit dem Kommentar „Actually, let's simplify“ neu zu beginnen; für die Testdatei waren 5 Versuche nötig
- Jedes Mal trat ein anderer Heredoc-Fehler auf: filerypt → file_path, encoding=' 'utf-8' (eingefügtes Leerzeichen), fileint(file_path) usw.
- Für eine Aufgabe, die der GB10 in 3 Schritten abschloss, waren 10 Tool-Aufrufe nötig
- Dieses Ergebnis bezieht sich auf die 24-GB-Q4_K_M-Codex-CLI-Umgebung und ist kein allgemeines Urteil über Gemma 4 auf Apple Silicon

Geschwindigkeitsanalyse: Warum der Mac schneller war als erwartet

Mit llama-bench wurden beide Maschinen bei identischer Kontextlänge gemessen; der Mac war bei der Token-Generierung 5,1-mal schneller als der GB10
Beide Systeme verfügen über 273 GB/s LPDDR5X Speicherbandbreite, und Token-Generierung ist speicherbandbreitenlimitiert
- 31B Dense liest pro Token alle 31,2 Milliarden Parameter (ca. 17,4 GB)
- 26B MoE aktiviert pro Token nur 3,8 Milliarden Parameter (ca. 1,9 GB)
- Bei gleicher Bandbreite erreichte der Mac 52 tok/s, der GB10 10 tok/s
Auch die Prompt-Verarbeitung war entgegen der Erwartung auf dem Mac konkurrenzfähig: bei 8K Kontext 531 tok/s auf dem Mac gegenüber 548 tok/s auf dem GB10; die spärliche Aktivierung des MoE wirkt sich auch hier positiv aus

Zentrale Erkenntnis: Wichtiger als Token-Geschwindigkeit ist die Erfolgsquote im ersten Versuch

Der Mac war bei der Token-Generierung zwar 5,1-mal schneller, die gesamte Abschlusszeit war jedoch nur um 30 % kürzer (4 Min. 42 Sek. vs. 6 Min. 59 Sek.)
Ursache für den Zeitunterschied waren Wiederholungen: 10 Tool-Aufrufe statt 3, 5 Fehlschläge beim Schreiben der Tests und Dead Code, den das Modell nicht bereinigte
Das Cloud-Modell belegt dies noch deutlicher: am schnellsten, mit minimalem Token-Verbrauch, ohne Reparaturdurchlauf, 5/5 in 65 Sekunden abgeschlossen
Trotzdem sind lokale Modelle praktisch nutzbar; auf beiden Maschinen wurde funktionierender Code erzeugt, der die Tests bestand
Der Qualitätssprung von Gemma 3 (6,6 % Tool Calling) zu Gemma 4 (86,4 %) ist der entscheidende Wendepunkt; der Übergang von „funktioniert nicht“ zu „funktioniert“ macht lokales agentisches Coding praxisfähig
Ein Vorbehalt zum Mac-Ergebnis: Q4_K_M war auf einer 24-GB-Maschine die höchste Quantisierung, die in den Speicher passte; auf Apple-Silicon-Systemen mit mehr RAM könnten höhere Quantisierungen zu anderen Ergebnissen führen
Ein hybrider Ansatz ist möglich: mit codex --profile local Routinearbeiten und datenschutzsensible Aufgaben lokal bearbeiten, für komplexe Aufgaben den Cloud-Standard verwenden; der Wechsel ist dank des Profilsystems von Codex CLI nur ein Flag

Praktische Tipps für das Setup

Apple Silicon: Ollama war mit Gemma 4 nicht nutzbar; empfohlen wird llama.cpp + --jinja
- In einem Codex-CLI-Profil web_search = "disabled" setzen
- Den GGUF-Pfad direkt mit -m angeben, -hf nicht verwenden
- Kontext auf 32.768 setzen (der System-Prompt von Codex CLI benötigt mindestens 27.000 Tokens)
- KV-Cache-Quantisierung: -ctk q8_0 -ctv q8_0
NVIDIA GB10: Ollama v0.20.5 war der erste stabil funktionierende Weg; codex --oss -m gemma4:31b verwenden, bei einem entfernten Rechner Port 11434 per SSH tunneln
In den Provider-Einstellungen muss stream_idle_timeout_ms auf mindestens 1.800.000 gesetzt werden, da auf dem Mac ein einzelner Tool-Calling-Zyklus 1 Min. 39 Sek. dauerte und die Sitzung sonst wegen des Standard-Timeouts beendet wurde
Es wird empfohlen, die llama.cpp-Version festzunageln; zwischen Builds wurde ein 3,3-facher Geschwindigkeitsabfall beobachtet, sodass Benchmarks sich über Nacht ändern können

6 Kommentare

tsboard 15 일 전

Ich habe in unserer Firma ausprobiert, Gemma4-31B mit zwei H100s zu betreiben.

Die Antwortqualität ist durchaus ordentlich, und Koreanisch beherrscht es gut.
Es trifft auch gute Entscheidungen bei der Tool-Ausführung und fasst die Ergebnisse nach der Ausführung gut zusammen.
Aber das ist natürlich nur auf dem Niveau von „erstaunlich, wenn man bedenkt, dass es sich um 31B Parameter handelt!“, und im Vergleich zu Modellen mit deutlich mehr Parametern (z. B. MiniMax-M2.5) ist die Gesamtqualität der Antworten tatsächlich schwächer.

Insgesamt scheint Gemma4 völlig auszureichen, wenn man ein kleines und schnelles Modell möchte. Ich bin von GPT-OSS-120B → Qwen3.5-35B-A3B inzwischen bei Gemma4-31B gelandet und war damit ziemlich zufrieden. Ich werde wohl vorerst dabei bleiben.

kaydash 15 일 전

Krass, man kann also keine Websuche verwenden! Geht das auch nicht, wenn man searxng konfiguriert?

ysm0622 15 일 전

https://github.com/ysm-dev/skills/blob/main/skills/web-search/SKILL.md

Versuchen Sie stattdessen mal, diesen Skill zu verwenden, hehe

yangeok 16 일 전

Ich würde gern prüfen, ob es auch auf Koreanisch gut funktioniert.

GN⁺ 16 일 전

Hacker-News-Kommentare

Gemma 4 26B zeigte unter Modellen mit ähnlicher Parametergröße eine wirklich außergewöhnliche Leistung.
In internen Benchmarks erzielte es ähnliche Werte wie GPT 5.2 und Gemini 3 Pro Preview, war aber bei agentischem Coding und nicht auf Coding bezogenen Entscheidungsaufgaben schwächer.
Bei Tool-Nutzung, iterativer Verbesserung und dem Umgang mit großen Kontexten fielen die Werte ab, und gerade in Situationen, in denen Tools nötig waren, sank die Leistung sogar.
Vermutlich ist das Modell auf gängige Harnesses oder Benchmarks überangepasst. Trotzdem ist die Geschwindigkeit auf einem Macbook der M-Serie beeindruckend.
Die Benchmarks sind auf gertlabs.com einsehbar.
- In meinem „Hello World“-Test ist es durchgefallen.
  Die Aufgabe war, einen „1-dimensionalen Bin-Fitting-Rechner als einzelne Webseite zu implementieren“; Qwen3.5, Nematron, Step 3.5 und gpt-oss kamen durch, Gemma aber nicht.
- Insgesamt ist es ein gutes Open-Weights-Modell.
  Auf meinem M5 machte es allerdings häufiger einfache Coding-Fehler als GPT-OSS. Insgesamt liegt es aber auf einem ähnlichen Niveau.
- Ich fand es überraschend, dass Gemma 31B schlechter abschnitt als 26B-A4B.
Jemand meinte, das Ergebnis „Modellqualität ist wichtiger als Token-Geschwindigkeit“ sei überraschend.
Eigentlich klingt das ziemlich offensichtlich. Statt die Kontextgröße auf 32k zu begrenzen, kann man mit der Option --cpu-moe auch MoE-Berechnungen auf die CPU auslagern.
- Ich denke, die Token-Geschwindigkeit beeinflusst letztlich nur die Zeit bis zur Erledigung.
- Es fühlt sich an wie Kaffee trinken, wenn man müde ist. Man ist immer noch müde, bewegt sich aber nur „schneller“.
- Aus Sicht von jemandem, der Codex täglich nutzt, ist es viel wichtiger, dass das Modell nicht in nutzlose Schleifen gerät, als dass es schnell ist.
  Wenn nur die Token-Geschwindigkeit hoch ist, wird am Ende bloß die Zahl an „AI-Slop-Codebasen“ explodieren.
Ich probiere derzeit auf einem M3 Ultra (48 GB RAM) mit LM Studio und Opencode google/gemma-4-26b-a4b aus.
Ich musste den Kontext auf 65536 erhöhen, aber es funktioniert gut. Auch mit Zed und ACP lässt es sich leicht integrieren.
Ich nutze es hauptsächlich für einfache Code-Reviews oder zum Generieren von Frontend-Code.
- Ich habe ein ähnliches Setup. pi-coding-agent ist einen Versuch wert.
  System-Prompt und Tool-Overhead liegen unter 2k Tokens, daher ist die Prefill-Latenz deutlich kürzer.
- Ich nutze es auf einer AMD RX7900XTX (24 GB VRAM) mit vier parallelen Chats und 512K Kontext.
  Die Geschwindigkeit liegt bei etwa 100 t/s und ist fast unmittelbar, und ich nutze Claude Code immer seltener.
- Ich habe die MLX-Version auf einem M1 Macbook in XCode integriert laufen lassen, aber bei kleineren iOS-Codebasen blieb sie zwischendurch hängen.
  Als Chatbot war es in Ordnung, für die XCode-Integration aber ungeeignet.
- Ich habe die vollständige 31B-Version auf einer Runpod-GPU ausprobiert und war beeindruckt.
  Aktuell nutze ich über die Google API 1500 kostenlose Anfragen pro Tag.
- Ich nutze dasselbe Setup auf einem M4 Max (64 GB) MacBook Pro.
  Vor dem Update auf LM Studio 0.4.11+1 funktionierte Tool-Calling nicht, jetzt läuft es sowohl mit Codex als auch mit Opencode gut.
Die Aussage „Lokale Modelle können kein Tool-Calling“ ist falsch.
Ich nutze Tool-Calling lokal schon seit zwei Jahren, und dass Gemma3 nur eine Erfolgsquote von 7 % beim Tool-Calling haben soll, ergibt keinen Sinn.
Selbst mit Llama3.3 kam ich auf mindestens 75 %.
- Über diesen Satz war ich auch überrascht. Wahrscheinlich hat der Autor zum ersten Mal ein lokales Modell ausprobiert.
  Übermäßig stark quantisierte Modelle wie Gemma 4 gguf Q4 (16 GB) verlieren viel Leistung.
- Trotzdem stimmt es, dass der Unterschied in den Tau-Function-Calling-Benchmarks zwischen Gemma 3 und 4 groß ist.
- Der ganze Beitrag wirkte wie automatisch von einer KI erzeugt.
  Wenn man GB10-Hardware hat, würde ich ein Setup mit spark-vllm-docker oder die optimierte Version von Qwen 3.5 122B A10B empfehlen. Mit etwa 50 tk/s ist das ziemlich schnell.
Ich bin von einem M4 Pro (24 GB) auf einen M5 Pro (48 GB) umgestiegen, und dasselbe Gemma 4 MoE (Q4) war bei t/s achtmal schneller.
Auch die Ladegeschwindigkeit von der SSD in den Speicher hat sich verdoppelt.
- Wenn genug RAM vorhanden ist, würde ich empfehlen, direkt Q8_0 zu verwenden. Abgesehen vom initialen Laden ist es nicht langsam, und die Qualität ist nahezu gleich.
  Man sollte prüfen, ob die MLX-Version verwendet wird. Die Community-Quantisierungsversion von mlx-lm wurde kürzlich korrigiert.
  Auf meinem M1 Macbook mit 16 GB war es schwierig, aber auf einem AMD Framework 13 mit 64 GB RAM läuft es selbst nur auf der CPU ausreichend schnell.
  Die Prompt-Cache-Funktion ist nützlich, wenn große System-Prompts eingefügt werden.
Es wurde die Idee eines Harnesses vorgeschlagen, das lokale Hardware rund um die Uhr laufen lässt, Experimente mit Modellen wie Gemma 4 automatisiert und wichtige Entscheidungen an Claude Opus delegiert.
Dabei führt das lokale Modell kleine Experimente und POCs aus und bittet Opus um Hilfe, wenn es nicht weiterkommt.
So kann man Prompt Caching vollständig kontrollieren, wodurch die Kosten fast bei null liegen.
- Nico Bailon, ein Mitentwickler der Erweiterung für Marios Pi Coding Agent, versucht etwas Ähnliches.
  Siehe das Demo-Video und das Repository pi-model-switch.
Für Coding bringt Quantisierung unterhalb von Q6_K nichts.
Bei noch niedrigerer Quantisierung steigt die Code-Fehlerrate stark an.
- Die meisten wissen das nicht. Wichtiger als die Anzahl der Tokens ist die Qualität der Tokens.
  Solange es der Speicher zulässt, sollte man eine möglichst hohe Quantisierung verwenden.
Es wäre gut, einen Qualitätsvergleich nach Quantisierungsmethode wie Q4_K_M, Q8_0 und Q6_K zu sehen. Das wäre nützlicher als bloße tok/s-Werte.
Mich interessiert ein Vergleich zwischen Qwen3.5 und Gemma 4.
Besonders das Modell Qwen3.5-27B-Claude-4.6-Opus ist auf Tool-Calling spezialisiert und wurde bereits über 500.000 Mal heruntergeladen.
- Ich schaue mir den von Jackrong veröffentlichten Fine-Tuning-Guide an. Selbst die Notebook-Beispiele sind gut aufbereitet.
- Ich habe selbst auf DGX Spark getestet, bin am Ende aber wieder bei Gemma 4 gelandet.
  Bei den Qwen-Modellen kamen während der Orchestrierung zu häufig Anfragen zur Fehlerbehebung, was die Produktivität senkte.
  Ich habe es mit den Gewichten für Ollama betrieben.
- Die Behauptung, ein einzelner Entwickler habe mehr Leistung herausgeholt als ein großes Forschungslabor, erscheint mir etwas zweifelhaft.
  Die aktuelle Version ist Qwopus3.5-27B-v3.
Ich habe Gemma 4 einige Tage benutzt; es ist schnell und intelligent, aber die Probleme bei der Tool-Nutzung bestehen weiter.
Die Produktivität ist weniger durch die Geschwindigkeit als durch die begrenzte Intelligenz eingeschränkt. Es gerät oft in Schleifen.
Es wäre gut, wenn solche Situationen erkannt würden und das Modell ein intelligenteres Modell um „Hilfe bitten“ könnte.
Inzwischen arbeite ich eher als Agenten-Orchestrator denn als Coder. Ich lasse mehrere Agenten parallel laufen und koordiniere sie.
- Google hat kürzlich chat_template.jinja und tokenizer_config.json für gemma-4-31B-it ausgetauscht.
  Angeblich wurden damit Probleme beim Tool-Calling behoben, daher sollte man das Modell aktualisieren.

boolsee 15 일 전

Mit ollama lässt sich eine lokale LLM-Konfiguration zwar einfach aufsetzen, aber offenbar ist die Wahrscheinlichkeit hoch, dass Tool-Aufrufe je nach Open-Source-Modell fehlschlagen. Das liege wohl an einer Kombination aus lockeren internen Vorgaben in ollama und Parser-Problemen bei modellabhängigen Tool-Aufrufen.
Das eigentliche Grundproblem von Local LLMs ist jedoch, dass für den Betrieb mittelgroßer bis großer Modelle teure Hardware nötig ist. Ein Mac Studio mit 32 GB kostet etwa im mittleren 300er-Bereich, ein GB10 ungefähr 500 bis 600, sodass die Anschaffung für Privatpersonen als Hobby(?) eher belastend ist. Für Local LLMs bleiben kleine Modelle, und für mittelgroße bis große Modelle gibt es außer der Cloud kaum eine Alternative.