Passende Sprachmodelle für die eigene Hardware finden

Wer Sprachmodelle lokal ausführen möchte, steht zunächst vor der Frage, welche Modelle auf der vorhandenen Hardware sinnvoll genutzt werden können. Neben der Größe des Modells spielen hierbei der verfügbare Speicher und die gewünschte Kontextgröße eine Rolle. Das Werkzeug llmfit hilft dabei, passende Modelle für den eigenen Rechner zu finden.

Die interaktive Oberfläche von llmfit

Dazu erkennt llmfit unter anderem den Prozessor, den Arbeitsspeicher sowie vorhandene Grafikkarten und deren Speicher. Auch der gemeinsam genutzte Speicher von Apple-Silicon-Systemen wird berücksichtigt. Auf dieser Grundlage bewertet das Werkzeug die Modelle aus seinem Katalog nach Speicherbedarf, geschätzter Geschwindigkeit, Qualität und Kontextgröße. Daneben wird eine passende Quantisierung ermittelt, bei welcher die Modellgewichte mit geringerer Genauigkeit gespeichert werden, um den Speicherbedarf zu reduzieren. Alternativ können auch andere Rechnerkonfigurationen hinterlegt werden.

Unter macOS kann llmfit über Homebrew installiert werden:

brew install llmfit

Nach der Installation kann das Werkzeug mittels:

llmfit

gestartet werden. Damit öffnet sich eine interaktive Oberfläche im Terminal. Im oberen Bereich werden die erkannten Hardwaredaten dargestellt. Darunter befindet sich eine Tabelle mit den bewerteten Modellen, einschließlich der geschätzten Geschwindigkeit in Tokens pro Sekunde und der empfohlenen Quantisierung. Für eine einfache tabellarische Ausgabe kann alternativ:

llmfit fit

genutzt werden. Empfehlungen lassen sich außerdem nach ihrem Einsatzzweck filtern. Wer beispielsweise ein Modell für die Softwareentwicklung sucht, kann die Ergebnisse als JSON ausgeben lassen:

llmfit recommend --json --use-case coding --limit 3

Die Geschwindigkeitsangaben sollten zunächst als Schätzungen verstanden werden. Für eine Messung über eine bereits laufende lokale Laufzeitumgebung, beispielsweise Ollama, steht das Subkommando:

llmfit bench

zur Verfügung. Damit kann die Einschätzung durch Messwerte auf dem eigenen Rechner ergänzt werden. Der Quelltext von llmfit ist auf GitHub zu finden. Lizenziert ist das Werkzeug unter der MIT-Lizenz und damit freie Software.

Fallout 1 und 2 unter macOS spielen

Die ersten beiden Fallout-Spiele lassen sich dank der Fallout Community Edition und der Fallout 2 Community Edition auch auf aktuellen Macs spielen. Dabei handelt es sich um Neuimplementierungen der ursprünglichen Spielengines, welche nativ auf Intel-Macs und Macs mit Apple Silicon laufen. Die Spieldaten der Originalspiele werden allerdings weiterhin benötigt.

Um die Einrichtung zu vereinfachen, habe ich zwei Installationsskripte geschrieben. Diese extrahieren die benötigten Daten aus den GOG-Offline-Installern, laden die aktuelle macOS-Version der jeweiligen Community Edition herunter und erstellen die passende Konfiguration. Anschließend wird das Spiel direkt gestartet.

Für Fallout 1 werden diese Dateien aus dem GOG-Offline-Installern erwartet:

setup_fallout_1.2_(27130).exe
setup_fallout_1.2_(27130)-1.bin

Für Fallout 2 sind es:

setup_fallout_2_1.02_gog_v1_(77792).exe
setup_fallout_2_1.02_gog_v1_(77792)-1.bin

Liegen die Skripte und Installationsdateien beispielsweise im Ordner Fallout innerhalb des Benutzerverzeichnisses, wird im Terminal zunächst in diesen gewechselt:

cd ~/Fallout
chmod +x install-fallout-1.sh install-fallout-2.sh

Anschließend kann Fallout 1 mit:

./install-fallout-1.sh

installiert werden. Für Fallout 2 lautet der entsprechende Aufruf:

./install-fallout-2.sh

Die Installation erfolgt unter /Applications/Fallout beziehungsweise /Applications/Fallout 2. Für diese Verzeichnisse und das Verzeichnis der Skripte müssen Schreibrechte vorhanden sein. Die Disk-Images der Community Editions werden automatisch heruntergeladen und eingebunden; ein manueller Download ist nicht notwendig.

Nach der Installation lassen sich die Spiele jederzeit über den Finder starten. Die Anwendungen heißen Fallout Community Edition.app und Fallout II Community Edition.app und befinden sich in den jeweiligen Installationsverzeichnissen. Die Installationsskripte stehen unter der MIT-Lizenz. Der Quelltext und die ausführliche Anleitung sind im GitHub-Repository zu finden.

Tool-Aufrufe unter OpenCode reparieren

Der Open-Source AI-Coding-Agent OpenCode lässt sich nicht nur mit den üblichen Cloud-Anbietern, sondern auch mit lokalen bzw. selbst gehosteten Sprachmodellen nutzen. Dazu kann beispielsweise Ollama über dessen OpenAI-kompatible API angebunden werden.

OpenCode Desktop unter macOS

In Verbindung mit bestimmten Modellen wie dem qwen3-coder:30b zeigte sich allerdings ein interessantes Problem. Tool-Aufrufe funktionieren nicht, da sie oft als Klartext ausgeben und nicht korrekt interpretiert werden. Probleme mit Tool-Aufrufen sind im OpenCode-Projekt bereits länger bekannt und diskutiert.

Ob das verwendete Modell grundsätzlich Tool-Aufrufe unterstützt, lässt sich mit:

ollama show qwen3-coder:30b

überprüfen. Unter Capabilities sollte hierbei unter anderem:

tools

aufgeführt sein. Ist dies der Fall und funktionieren die Werkzeuge in OpenCode trotzdem nicht zuverlässig, kann die Ursache im von Ollama verwendeten Kontextfenster liegen.

OpenCode benötigt für agentisches Arbeiten vergleichsweise viel Kontext. Neben der eigentlichen Unterhaltung befinden sich dort unter anderem der System-Prompt und die Beschreibungen der zur Verfügung stehenden Werkzeuge. Ist das Kontextfenster zu klein, können Tool-Aufrufe dadurch nicht mehr zuverlässig funktionieren. Auch die OpenCode-Dokumentation weist bei Problemen mit Tool Calls in Verbindung mit Ollama darauf hin, num_ctx zu erhöhen.

Wird Ollama allerdings über die OpenAI-kompatible Schnittstelle von OpenCode angesprochen, lässt sich num_ctx nicht ohne Weiteres zuverlässig über die OpenCode-Konfiguration setzen. Als Workaround kann deshalb ein eigenes Ollama-Modell mit fest eingestellter Kontextgröße angelegt werden. Dazu wird das gewünschte Modell zunächst gestartet:

ollama run qwen3-coder:30b

Anschließend wird die Kontextgröße gesetzt:

/set parameter num_ctx 131072

und die Konfiguration unter einem neuen Modellnamen gespeichert:

/save qwen3-coder:30b-128k
/bye

Damit existiert neben dem ursprünglichen Modell nun eine Variante, bei welcher das größere Kontextfenster fest hinterlegt ist. Die Größe muss nicht zwangsläufig 128K betragen. Für Tool-Aufrufe empfiehlt OpenCode eine Erhöhung in den Bereich von 16K bis 32K. Bei entsprechend verfügbarem Speicher kann für längere Coding-Sitzungen allerdings auch ein deutlich größeres Kontextfenster sinnvoll sein. In OpenCode muss anschließend das neu angelegte Modell konfiguriert werden:

nano ~/.config/opencode/opencode.json

Eine entsprechende Konfiguration kann beispielsweise wie folgt aussehen:

{
  "$schema": "https://opencode.ai/config.json",

  "provider": {
    "remote-ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Remote Ollama",

      "options": {
        "baseURL": "https://example.org/ollama/v1",

        "headers": {
          "Authorization": "Bearer secret-token-123"
        }
      },

      "models": {
        "qwen3-coder:30b-128k": {
          "name": "Qwen3 Coder 30B 128K",
          "tools": true,
          "limit": {
            "context": 131072,
            "output": 16384
          }
        }
      }
    }
  },

  "model": "remote-ollama/qwen3-coder:30b-128k"
}

Wichtig ist hierbei die Unterscheidung zwischen den beiden Konfigurationen. Mit:

"limit": {
  "context": 131072,
  "output": 16384
}

wird OpenCode mitgeteilt, welche Grenzen das Modell besitzt. Dadurch wird allerdings nicht die tatsächliche Kontextgröße gesetzt, diese wurde stattdessen im neuen Modell angelegt. Nach einem Neustart von OpenCode kann das Tooling beispielsweise mit:

Erstelle eine Datei todo.md mit exakt dem Inhalt ‚hello world‘.

getestet werden. Wird die Datei tatsächlich über die OpenCode-Werkzeuge angelegt, funktionieren die Tool-Aufrufe. Da sich OpenCode und die Anbindung lokaler Modelle derzeit schnell weiterentwickeln, kann es allerdings auch mit dieser Konfiguration zu Problemen mit Tool-Aufrufen kommen, die andere Ursachen haben.

CotEditor

Unter macOS habe ich seit Anbeginn der Zeit TextMate als Editor genutzt. Allerdings wird dieser augenscheinlich seit geraumer Zeit nicht mehr weiterentwickelt. Auf der Suche nach einer Alternative bin ich auf CotEditor gestoßen. Dabei handelt es sich um einen schlanken und nativen Texteditor. Er unterstützt Syntax-Highlighting für zahlreiche Programmiersprachen, leistungsfähige Suchfunktionen sowie die Bearbeitung großer Dateien ohne spürbare Verzögerungen.

Das Editorfenster von CotEditor

Der Editor kann über den AppStore bezogen werden. Er ist unter der Apache License lizenziert und damit freie Software; der Quellcode ist auf GitHub zu finden.

Emulatoren für SteamOS

Für Steam selbst existiert fast nur RetroArch als Emulationsplattform. Diese ist allerdings nicht unbedingt dafür bekannt besonders nutzerfreundlich zu sein. Während Distributionen wie Batocera eine Erfahrung wie aus einem Guss bieten, ist das für Emulation in SteamOS nicht der Fall. Abhilfe schafft hierbei EmuDeck. Dieses installiert ein Frontend als App, welche sich in den Gaming-Modus unter SteamOS integriert.

EmuDeck bzw. EmulationStation nach der Installation

Um EmuDeck zu installieren, muss in den Desktop-Modus des SteamOS gewechselt werden. Dort muss im Browser auf die EmuDeck-Webseite gewechselt werden und dort die Linux-Installation heruntergeladen werden. Diese startet nach der Ausführung den eigentlichen Installer. Hier kann das System wie gewünscht konfiguriert werden. Spätere Updates laufen dann ebenfalls über das Interface im Desktop-Modus. Nach der Installation kann wieder in den Gaming-Modus gewechselt werden.