Google Gemma 4 lokal mit der Headless-CLI von LM Studio und Claude Code ausführen

 (ai.georgeliu.com)
17 Punkte von GN⁺ 23 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Gemma 4 unterstützt dank einer Mixture-of-Experts-Architektur, bei der nur ein Teil der Parameter aktiviert wird, leistungsstarke Inferenz auch auf Hardware mit geringerer Ausstattung
  • LM Studio 0.4.0 führt die neue Headless CLI (llmster) ein, mit der sich Modelle ohne Desktop-App herunterladen, laden, für Chats nutzen und als API-Server ausführen lassen
  • Über eine OpenAI- und Anthropic-kompatible API lässt sich Gemma 4 als lokaler Server bereitstellen und Claude Code als vollständig offline nutzbarer Code-Assistent verwenden
  • Durch feines Hardware-Tuning wie Kontextlänge, GPU-Offloading und parallele Anfragen lassen sich Leistung und Speichereffizienz anpassen
  • Lokale Inferenz auf Basis von MoE-Modellen ermöglicht schnelle Code-Reviews und Prompt-Tests ohne API-Kosten und entwickelt sich zur Schlüsseltechnologie für den Aufbau einer Offline-AI-Umgebung für Entwickler

Google Gemma 4 lokal ausführen — Integration mit der neuen Headless-CLI von LM Studio und Claude Code

  • Warum lokale Ausführung wichtig ist

    • Cloud-AI-APIs haben Einschränkungen bei Kosten, Rate Limits, Datenschutz und Netzwerklatenz
    • Für schnelle, iterative Arbeiten wie Code-Reviews, Entwürfe oder Prompt-Tests ist die lokale Ausführung von Modellen vorteilhaft
    • Lokale Ausführung bietet die Vorteile 0 API-Kosten, keine externe Datenübertragung und jederzeitige Verfügbarkeit

    • Gemma 4** nutzt eine Mixture-of-Experts-(MoE)-Architektur, bei der in einem 26B-Modell nur 4B Parameter aktiviert werden, wodurch auch auf schwächerer Hardware eine hohe Leistung möglich ist**

      • Auf einem M4 Pro MacBook (48GB) wurden 51 Token pro Sekunde gemessen, innerhalb von Claude Code ist es etwas langsamer

  • Die Gemma-4-Modellfamilie

    • Google veröffentlicht Gemma 4 in vier Modellfamilien, optimiert für unterschiedliche Hardware
    • Die E-Serie (E2B, E4B) verwendet Per-Layer Embeddings und unterstützt Audioeingaben (Spracherkennung und Übersetzung)
    • Das 31B-Dense-Modell erreicht 85,2 % bei MMLU Pro und 89,2 % bei AIME 2026
    • Das 26B-A4B-Modell aktiviert von 128 Experten nur 8 (3,8B Parameter) und liefert dadurch Qualität auf 10B-Niveau zu Kosten auf 4B-Niveau
    • Mit 82,6 % bei MMLU Pro, 88,3 % bei AIME und Elo 1441 liegt es nahe am 31B-Dense-Modell und konkurriert mit 400B+-Modellen
    • Mit Unterstützung für 256K Kontext, Vision-Eingaben, Function Calling und Inferenzmodus-Einstellungen eignet es sich gut für lokale Inferenz

  • Wichtige Änderungen in LM Studio 0.4.0

    • Mit der Einführung von llmster als eigenständiger Inferenz-Engine ist eine vollständige Ausführung per CLI ohne Desktop-App möglich

      • Über die lms-CLI lassen sich Modelle herunterladen, laden, für Chats nutzen und als Server starten
      • Wichtige Funktionen:
      • llmster daemon: verwaltet Modellladen und Inferenz im Hintergrund
      • Verarbeitung paralleler Anfragen: mehrere Requests gleichzeitig durch Continuous Batching
      • Stateful REST API: hält den Gesprächsverlauf über den Endpunkt /v1/chat
      • MCP-Integration: lokaler Support für das Model Context Protocol

  • Installation und Modelldownload

    • Installationsbefehl: 
      curl -fsSL https://lmstudio.ai/install.sh | bash
    • Daemon starten: lms daemon up
    • Runtime aktualisieren: lms runtime update llama.cpp, lms runtime update mlx
    • Gemma-4-26B-Modell herunterladen: lms get google/gemma-4-26b-a4b
    • Die Standard-Quantisierung ist Q4_K_M (17.99GB)
    • Nach dem Download mit lms load google/gemma-4-26b-a4b laden

  • Verwaltung lokaler Modelle

    • Installierte Modelle anzeigen: lms ls
    • Die Beispielausgabe enthält viele MoE-Modelle, darunter Gemma 4, Qwen 3.5 und GLM 4.7 Flash
    • MoE-Modelle ermöglichen effiziente Inferenz, da nur ein Teil der aktiven Parameter verwendet wird

  • Chat-Ausführung und Leistung

    • Chat starten: lms chat google/gemma-4-26b-a4b --stats
    • Beispielausgabe: 
      Tokens/Second: 51.35
Time to First Token: 1.551s
    • 51 tok/sec und 1,5 Sekunden bis zur ersten Antwort sind schnell genug für interaktive Nutzung

  • Modellstatus und Speicher prüfen

    • Geladene Modelle anzeigen: lms ps
    • Beispiel: 17.99GB Speichernutzung, 48K Kontext, 2 parallele Requests, TTL von 1 Stunde
    • Wichtige Felder in der JSON-Ausgabe (lms ps --json | jq):
      • "architecture": "gemma4"
      • "quantization": {"name": "Q4_K_M", "bits": 4}
      • "vision": true, "trainedForToolUse": true
      • "maxContextLength": 262144, "parallel": 2

  • Speicherabschätzung nach Kontextlänge

    • Mit der Option --estimate-only lässt sich der Speicherbedarf vorhersagen
    • Das Basismodell benötigt etwa 17.6GiB, bei jeder Verdopplung des Kontexts kommen 3 bis 4GiB hinzu
    • Für 48K Kontext werden etwa 21GiB benötigt, bei 256K sind es 37.48GiB
    • Beispielbefehl: 
      lms load google/gemma-4-26b-a4b --estimate-only --context-length 48000
    • Die lineare Beziehung zwischen Kontextlänge und Speicherbedarf ist hilfreich für die Kapazitätsplanung

  • Lade-Tuning je nach Hardware

    • Kontextlänge

      • Innerhalb des verfügbaren Speichers einstellen, nachdem der Bedarf des Betriebssystems (4 bis 6GB) berücksichtigt wurde
      • Beispiel: lms load google/gemma-4-26b-a4b --context-length 128000

    • GPU-Offloading

      • Apple Silicon hat eine Unified-Memory-Architektur, mit --gpu=1.0 kann die gesamte GPU genutzt werden
      • Auf NVIDIA-Systemen lässt sich die Nutzung innerhalb der VRAM-Grenzen mit Werten wie --gpu=0.5 aufteilen

    • Parallele Anfragen

      • Continuous Batching verarbeitet mehrere Requests gleichzeitig
      • In der GUI lässt sich Max Concurrent Predictions einstellen (Standard: 4)
      • Für Gemma 4 sind auf einem 48GB-System 48K Kontext und 2 parallele Requests angemessen

    • TTL-basiertes automatisches Entladen

      • Mit --ttl 1800 wird das Modell nach 30 Minuten Inaktivität automatisch entladen
      • Standard ist 1 Stunde, mit 0 oder -1 lässt sich dies deaktivieren

    • Standards pro Modell speichern

      • In der Desktop-App lassen sich unter My Models → Settings icon Standardwerte für GPU, Kontext und Flash Attention speichern

    • Speculative Decoding

      • Bei MoE-Modellen ineffizient, für Gemma 4 wird Deaktivierung empfohlen
      • Mixtral-Tests zeigten +39 % bei Code-Aufgaben, aber -54 % bei Mathematikaufgaben

    • Flash Attention

      • Unterstützt lange Kontexte durch geringeren KV-Cache-Speicherbedarf
      • Auf Apple Silicon spart die Aktivierung Speicher

  • Die Desktop-App von LM Studio

    • Die GUI visualisiert Serverstatus, Modellladen, API-Endpunkte und Log-Streams
    • Einschließlich Anthropic-Protokoll (POST /v1/messages)
    • Mit Vision-Funktionen ist auch Bildanalyse möglich
    • Beispiel: Bei der Analyse eines Timezone-Scheduler-Bildes wurden 504 Token mit 54.51 tok/sec erzeugt
    • Laut Systemmonitor:
      • Speichernutzung 46.69GB/48GB, Swap 27.49GB
      • GPU-Auslastung 90 %, CPU 91°C, GPU 92°C
      • Leistungsaufnahme 23.56W (CPU 11.06W, GPU 13.32W)
    • Dank Unified-Memory-Architektur entfällt das Kopieren von Daten zwischen CPU und GPU

  • Das Modell als API-Server bereitstellen

    • Server starten: lms server start
    • OpenAI-kompatible API: http://localhost:1234/v1
    • Anthropic-kompatibler Endpunkt: POST /v1/messages
    • Port ändern: --port 8080
    • JIT-Modellladen lädt das Modell bei Anfragen automatisch und entlädt es nach Ablauf der TTL wieder
    • Echtzeit-Log-Stream: lms log stream --source model --stats
    • Zugriff ist auch von anderen Geräten im Netzwerk möglich, API-Token-Authentifizierung wird unterstützt

  • Integration mit Claude Code

    • Über einen Anthropic-kompatiblen Endpunkt lässt sich Claude Code mit einem lokalen Modell ausführen
    • In ~/.zshrc die Funktion claude-lm hinzufügen: 
      export ANTHROPIC_BASE_URL=http://localhost:1234
export ANTHROPIC_MODEL="gemma-4-26b-a4b"
...
claude "$@"
    • Alle Modellaufrufe von Claude Code (Opus, Sonnet, Haiku) werden an Gemma 4 weitergeleitet
    • Es wird eine Umgebung mit 48K Kontext, 8K Token Ausgabelimit und nur lokaler Nutzung eingerichtet
    • Mit claude-lm ist ein vollständig offline nutzbarer Code-Assistent möglich
    • Die Geschwindigkeit ist geringer als in der Cloud, aber gut geeignet für Code-Reviews, kleinere Änderungen und explorative Arbeit

  • Wichtige Erkenntnisse

    • MoE-Modelle sind der Schlüssel für lokale Inferenz: Gemma 4 26B-A4B liefert Qualität auf 10B-Niveau zu Kosten auf 4B-Niveau
    • Ein Headless-Daemon ermöglicht einen vollständig CLI-basierten Workflow
    • Die Kontextlänge ist der wichtigste Faktor für den Speicherverbrauch
    • Mit --estimate-only lässt sich OOM vermeiden
    • Über einen Anthropic-kompatiblen Endpunkt kann Claude Code lokal vollständig offline betrieben werden

  • Einschränkungen

    • lms chat zeigt den Modellnamen nicht direkt an
    • Der Standard von 48K Kontext ist konservativ; bei ausreichend Speicher ist eine Erweiterung empfehlenswert
    • Die lokale Ausführung von Claude Code ist kein vollständiger Ersatz für die Anthropic-API und bei großen Aufgaben eingeschränkt
    • Auf 48GB-Systemen kommt es zu Speicherdruck und Swap-Nutzung, empfohlen werden 64GB oder mehr

  • Nächste Schritte

    • Geplant sind Vergleichstests mit Qwen 3.5 35B, GLM 4.7 Flash und Nemotron 3 Nano
    • Zusammenfassung des Ablaufs: 
      curl -fsSL https://lmstudio.ai/install.sh | bash
lms daemon up
lms get google/gemma-4-26b-a4b
lms chat google/gemma-4-26b-a4b --stats
    • Für die Claude-Code-Integration die Funktion claude-lm hinzufügen und anschließend claude-lm ausführen
    • Geeignet für den Aufbau lokaler AI-Workflows und die Integration in Web-Apps sowie Entwicklerumgebungen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 23 일 전
Hacker-News-Kommentare

  • Man kann lokale LLMs direkt mit dem llama.cpp server betreiben und sie in Claude Code oder anderen CLI-Agenten nutzen.
    Es wurde ein vollständiger Einrichtungsleitfaden zusammengestellt, der das Testen aktueller Open-Weight-LLMs wie Gemma4 auf einem M1 Max MacBook mit 64 GB zeigt.
    Das 26BA4B-Modell war auf dieser Hardware am interessantesten und zeigte mit 40 tok/s eine fast doppelt so hohe Token-Generierungsgeschwindigkeit wie Qwen3.5 35BA3B.
    Die tau2-Bench-Ergebnisse lagen jedoch unter denen der Qwen-Varianten (68 % vs. 81 %), weshalb es für komplexe, toolzentrierte Aufgaben wohl ungeeignet ist.

    • Ich frage mich, ob es in Claude Code keine Probleme mit Spezifikationskonflikten zwischen Anthropic und OpenAI gab.
      Ich nutze mlx_vlm und vMLX, bekomme in Claude Code aber einen 400 Bad Request.
      Ich würde gern wissen, ob es mit llama-server solche Probleme nicht gab.

  • Es fühlt sich so an, als hätten lokale Modelle inzwischen die Phase bloß „gerade so machbar“ verlassen und seien bei angenehm nutzbar angekommen.
    Besonders der headless LM Studio-Workflow ist beeindruckend. Er macht lokale Inferenz in echten Tools nutzbar.
    Ich entwickle einen Open-Source-CLI-Coding-Agenten namens cloclo, der verschiedene Backends wie LM Studio, Ollama, vLLM, Jan und llama.cpp unterstützt.
    Lokale Modelle kommen der idealen Kombination immer näher: privat und günstig für den Alltag, Cloud-Modelle für Aufgaben mit hoher Leistung.

    • Ich frage mich, worin sich cloclo von pi-mono unterscheidet.

  • Der Kernpunkt hier ist weniger Gemma 4 selbst als vielmehr, dass Harness und Modell vollständig voneinander getrennt wurden.
    Claude Code, OpenCode, Pi und Codex funktionieren alle mit beliebigen Backends.
    Das heißt, Coding-Agenten werden zunehmend zu einer verallgemeinerten Schicht, und der Wettbewerb verlagert sich auf Modellqualität und Kosten.
    Für Nutzer ist das gut, für Unternehmen, die vom Harness abhängig waren, eher bedrohlich.

    • Ich denke eher das Gegenteil. Modelle werden austauschbarer, und Harness und Tooling sind der eigentliche Schlüssel zu realen Leistungssteigerungen.
      Zum Beispiel hieß es auch im Beitrag “Improving 15 LLMs at Coding in One Afternoon”, dass allein ein anderer Harness schon große Verbesserungen gebracht habe.
    • Tatsächlich konnte man Claude Code oder OpenCode auch direkt mit einem lokalen HTTP-Endpunkt verbinden.

  • Mit dem Befehl ollama launch claude --model gemma4:26b lässt es sich einfach starten.

    • Wenn man die Größe des context window nicht erhöht, funktioniert die Tool-Calling-Funktion nicht.
    • Erstaunlich ist, dass es so einfach funktioniert, wenn nur ollama und claude installiert sind.
    • Bei mir hat es allerdings nicht funktioniert. Claude geriet in eine Endlosschleife und antwortete nicht.
      Nemotron, glm und qwen 3.5 liefen gut, nur gemma machte Probleme.

  • Dieser Ansatz könnte auch für die Automatisierung von Websoftware-Tests nützlich sein.
    Selenium oder Puppeteer brechen leicht, wenn sich das Webdesign nur ein wenig ändert.
    Solche Modelle könnten sich dagegen an Änderungen anpassen und so flexiblere Tests ermöglichen.
    Besonders kleine Modelle scheinen dafür bereits ausreichend zu sein.

  • MoE spart in der Praxis kein (V)RAM.
    Alle Gewichte müssen im Speicher resident sein, auch wenn pro Inferenz nur ein Teil davon genutzt wird.
    Deshalb verbessert sich tok/s, aber der VRAM-Verbrauch bleibt gleich.

    • Das hat mich anfangs auch verwirrt. Inaktive Experten überspringen zwar die Berechnung, bleiben aber dennoch im Speicher geladen.
      Diese Visualisierung war hilfreich, um das zu verstehen.
    • In einigen Inferenz-Engines kann man einen Teil der Experten in den CPU-RAM auslagern.
      Zum Beispiel lässt sich ein 35B-Parameter-MoE mit einer Kombination aus 12 GB VRAM-GPU und 16 GB RAM betreiben.
    • Man muss nicht alle Gewichte gleichzeitig im Speicher halten.
      Man kann nur die benötigten Teile nachladen und austauschen – aus RAM, von der Festplatte oder über das Netzwerk.
      MoE reduziert die Datenmenge, die für den nächsten Inferenzschritt ausgetauscht werden muss.

  • Ich nutze Claude Code als Hauptschnittstelle für wiederkehrende Aufgaben in Datenpipelines.
    Konkret geht es darum, regulatorische Offenlegungen von Behörden (XBRL) zu normalisieren und über REST und MCP bereitzustellen.
    Interessant an MCP ist, dass man Tools deklarativ definiert, statt den Client direkt aufzurufen, und das Modell entscheidet selbst, wann es sie aufruft.
    Eine Anfrage wie „Vergleiche den Verschuldungstrend dieses Unternehmens über zehn Jahre mit dem Branchendurchschnitt“ wird dann automatisch in die passende Sequenz von Tool-Aufrufen zerlegt.
    Bei der interaktiven Nutzung von MCP ist Latenz allerdings deutlich kritischer.
    Eine Antwortzeit von zwei Sekunden ist in Skripten okay, unterbricht aber den Gesprächsfluss.
    Deshalb habe ich häufig genutzte Tabellen im Speicher gecacht und Antworten unter 100 ms erreicht.
    Ich frage mich, ob andere ähnliche Latenzschwellen erlebt haben.

    • Ich finde MCP auch nützlich, aber der Token-Verbrauch kann hoch werden.
      In einfachen Implementierungen verbraucht es gegenüber derselben Funktionalität leicht zehntausende Tokens mehr.
      Es gibt einen Erklärartikel von Anthropic, aber der ist schon etwas älter.
    • Nach meiner Erfahrung sind 300–500 ms pro Tool-Aufruf die natürliche Obergrenze.
      Darüber werden mehrstufige Ketten träge, und das Modell fügt unnötige Schlussfolgerungen hinzu, wodurch der Kontext aufbläht.
      Neben Caching war es auch effektiv, die Anzahl der Roundtrips zu reduzieren, indem mehrere Daten auf einmal zurückgegeben wurden.

  • Es wird gezeigt, wie man Gemma 4 26B unter macOS als lokale Inferenz für Claude Code einrichtet.

    • Ich finde, das ist eine hervorragende Zusammenfassung.

  • In Zukunft könnten große AI-Labore vielleicht auch lokale LLMs parallel betreiben, um Cloud-Last zu reduzieren, und nur schwere Berechnungen in der Cloud ausführen.

    • Ich frage mich allerdings, ob das nicht ihrem Geschäftsmodell widersprechen würde.

  • Ich würde gern wissen, wie gut das Gemma-4-Modell bei agentischem Coding tatsächlich funktioniert und wie der reale Eindruck davon ist.