KI Lokal (Ollama, Opencode, HA-MCP)

Hi,

habe folgendes Setup:

  • M3 Pro mit 18GB RAM
  • HAOS auf Proxmox
  • Ollama, Opencode, HA-MCP lokal am Macbook laufen
  • Modell: qwen2.5-coder:14b

Hat jemand etwas ähnliches? Welches Modell nutzt ihr?

Ich möchte kein Daten in die Cloud laden, daher mein Versuch. Obwohl die Verbindung von Opencode über HA-MCP nach Homeassistant funktioniert, scheitere ich teilweise an den Tool aufrufen. Context ist auf 24k gestellt.

Ich hätte versucht ein Dashboard zum Thema PV zu erstellen. Leider habe ich es bis jetzt nur geschafft, dass er mir ein neues, leeres Dashboard erstellt. Hat schon jemand mehr Erfolg mit so einem “schwachen“ Setup?

Willkommen hier bei uns!
Ich habe Ollama mit OpenWebUi und OpenRouter mit dem Qwen3.5 9b auf einem NAS mit Proxmox als LXC laufen mit 64GB RAM!
Ollama sind 32GB zugeteilt!

Hi! Auch ein „herzliches Willkommen“ von mir! :waving_hand:

Dein Setup ist eigentlich super, aber du läufst hier vermutlich in ein physikalisches Speicher-Limit deines M3 Pro (18 GB RAM). 18 GB ist da halt echt nicht wirklich viel! :woman_shrugging:

Wenn du ein 14B-Modell nutzt und den Kontext auf 24k aufbläst, explodiert der RAM-Bedarf für den Chat-Verlauf (KV-Cache). Dein Mac muss dann im Hintergrund auf die SSD auslagern/swappen. Dadurch gerät das Modell ins Stocken und verliert die Präzision, die für fehlerfreie MCP-Tool-Aufrufe nötig ist – deshalb bleibt das Dashboard leer.

Zwei Tipps, um das zu lösen:

  1. Kontext reduzieren: Stelle den Kontext testweise von 24k auf 12k runter. Das entlastet den RAM massiv und reicht für die PV-Entitäten meist völlig aus. Nicht zu viel in den Kontext packen, eher „Step by Step“!
  2. Wechsel auf oMLX (MLX-Framework): Da du auf Apple Silicon unterwegs bist, arbeitet das Apple-eigene MLX-Framework viel ressourcenschonender als Ollama/llama.cpp. Es verwaltet den Speicher bei großen Kontexten deutlich effizienter. oMLX bietet dir ebenfalls eine API, die du einfach in Opencode einbinden kannst (passende Modelle gibt es bei der mlx-community auf Hugging Face z. B. Qwen2.5-Coder-14B-Instruct-4bit-mlx. Kannst du in oMLX einfach direkt runterladen!)

Probier mal, den Kontext zu senken oder (besser!) auf MLX umzusteigen – dann sollten auch die komplexeren Tool-Aufrufe für das Dashboard stabil durchlaufen!

Hier findest du noch andere Settings!

Hallo, kurzes Update. Ich hab einiges probiert und konnte dabei feststellen, dass OMLX schneller läuft, aber mehr RAM benötigt und teilweise crasht wenn der RAM ausgeht. Ollama ist stabiler und unterstützt mittlerweile auch mlx somit ist der Unterschied, bei meinen Anwendungen, egal. Weiters stockte Opencode mit OMLX öfters und erst nach einer Nachfrage “ob er fertig sei, sagte er nein und arbeitete weiter“. Dieses Verhalten konnte ich mit Ollama nicht feststellen. Da lief alles geschmeidiger. Die nächste Tage darf ich ein M5 Pro mit 48GB RAM testen. Bin schon gespannt auf die Unterschiede :wink:

1 „Gefällt mir“

Ja Ollama hat vor kurzem das MLX Framework eingeführt (seit ca. 1-2 Wochen). Werde daher auch nochmal Ollama testen, wobei mir bei omlx auch das Web-Dashboard echt gut gefällt. Das fehlt doch bei ollama und man muss mehr mit der Konsole arbeiten, oder nicht?

Aktuell nutze ich gemma4-26b-a4b-4bit auf meinem Mac mit 32GB RAM. Das läuft für den Alltag zuverlässig mit omlx und liefert auch wirklich gute Ergebnisse bei ziemlicher flotter Antwort. Zudem kann ich den Mac auch weiterhin nutzen, weil noch Reserven beim RAM vorhanden sind.

Bei qwen3.6-27b habe ich, wie du schon beschrieben hast, auch ein paar Mal feststellen können, dass das LLM bei langen Aufgaben einfach aus dem RAM aussteigt und neu geladen werden muss. Dachte nur nicht, dass es an omlx liegt. Muss ich auf jeden Checken. Hätte schon gerne qwen3.6-27b für den daily usecase.

Auf deinen Bericht zum M5 mit 48GB RAM bin ich gespannt. 48-64GB sollte schon ganz gut für den Alltag nutzbar sein.

Entweder mit der Konsole oder ich habe auch OpenWebUI installiert!

Wie wählt Ihr Eure Modelle aus? Bis jetzt hab ich immer ChatGPT gefragt, welches Modell ich wählen soll.

„try and error!“ kommt halt immer darauf an was du vor hast!?

Ich teste immer wieder verschieden und schaue welche am vernünftigsten für meine Anwendungen laufen! Bei mir laufen die alle lokal am NAS!

Im Prinzip soll es über ha-mcp mein Homeassistant verwalten. Fehler prüfen, Automationen und Dashboards erstellen, … Bin noch ganz am Anfang mit dem Thema und das würd schon mal reichen. Soweit ich gelesen habe, ist dann die Tool-Nutzung sehr wichtig, da der ha-mcp schon sehr viel mitbringt. Zusätzlich sollen auch die Home Assistant Agent Skills mit eingebunden werden, damit es “runder“ läuft.

Das meint Chatgpt: “Für ein MacBook M5 Pro mit 48 GB und HA-MCP würde ich Qwen3-Coder 30B A3B nehmen, weil du damit die beste Balance aus Codequalität, Agentenfähigkeit und Tool-Nutzung bekommst.”

Gibts ein Grund warum du dann nicht einfach hosted-LLMs wie Claude nutzt? Wenn du sowieso nur MCP willst, kriegt man da wohl die beste Performance raus

Meine Daten sollen mein Netzwerk nicht verlassen. Bin vielleicht über vorsichtig…

1 „Gefällt mir“

Das ist schon verständlich. Aus dem selben Grund mache ich soetwas auch nicht. Wäre gerade für komplexere Aufgaben aber vermutlich die performanteste Wahl - beim Smart Home würde ich aber auch nicht alles reinlassen :slight_smile:

@Hannes1 Ich wähle meine LLM danach aus, wieviel in Speicher passt und dann teste ich die Modelle einfach durch. Danach entscheide ich, welche verbleiben und welche nicht.

Schaue mal hier ins Thema, dort haben wir einige Modelle zusammengetragen und auch wie man sie schnell mal testen kann. Die LLM gibt es ja dann immer in verschiedenen Ausführungen (ja nach Hardware). Aber die Qwen Modelle sind schon echt gut. Gemma4 würde ich gleich danach oder teilweise auch auf eine Stufe stellen. Aktuell teste ich mal Qwopus3.6-27B-v1-preview-MLX-4bit. Das ist etwas kleiner wie Qwen3.6-27B und hat MLX was für Mac User immer besser ist.

Zum Thema nicht das Haus verlassende Daten. Ich mache das öfter so, dass ich meine HA Frage extern stelle und dann intern die Antwort manuell einpflege. So muss keiner die Sensoren kennen und die KI füllt sie mit Platzhaltern. So kann mich sich auch Dashboard-Cards, Automatisierungen, Blueprints und Co erstellen lassen. (Das Ergebnis wird gerade bei Blueprints mit Cloud LLM eindeutig besser sein)

Ich nutze übrigens auch meinem Hermes Agenten zusammen das HA CLI Tool für die Integration und nicht HA-MCP. Beide Projekte sind sehr ähnlich vom Funktionsumfang, ich mag aber cli und daher hat mir das mehr zugesagt. Hermes kann das dann auch einfach selber mit erstelltem Langzeittoken in HA installieren. GitHub - balloob/home-assistant-build-cli · GitHub

Update:

  • M5 Pro mit 48GB RAM

  • HAOS auf Proxmox

  • Ollama, ClaudeCode, HA-MCP lokal am Macbook laufen

  • Modell: qwen3.6:27b-mlx

Keine Agenten, Skills oder dergleichen. Einfach nur installiert und Ursprungsprompt eingefügt. 55min später war alles fertig. Design ist natürlich noch nicht perfekt, aber es hat genau so funktioniert wie ich es mir erwartet habe. Ich wußte zwar dass RAM das Zauberwort ist, aber ich dachte es handelt sich um “Ausführung gut” und “nicht so gut”. In Wirklichkeit ist es aber funktioniert oder funktioniert nicht.

Ich werde das gleiche nochmals mit Opencode und dem gleichen Modell testen, zwecks Unterschiede. Danach probiere ich noch andere Modelle immer mit dem gleichen Prompt. Modellempfehlungen zum testen oder was würde Euch interessieren?

1 „Gefällt mir“

Moin, ja RAM/VRAM ist der entscheidende Faktor bei lokalen LLM. Je mehr um so besser und um so besser die Ergebnisse. Ich habe einen Beitrag geschrieben mit den von mir getesteten Modellen, kannst du ja gerne mal schauen. Probiere auf jeden Fall auch Qwen3.6-35B-A3B-UD-MLX-4bit. Läuft mit 48GB wunderbar und hast noch Reserven zum Arbeiten auf dem Mac.

Super Danke. Werd mir mal Qwen3.6-35B-A3B-UD-MLX-4bit vornehmen.