Vor etwa einem halben Jahr habe ich mich schon einmal mit dem Thema „LLMs in Home Assistant“ beschäftigt. Zu diesem Zeitpunkt bin ich zu dem Ergebnis gekommen, dass mit der mir zu diesem Zeitpunkt zur Verfügung stehenden Hardware (eine RX 5700XT mit 8GB VRAM) ein sinnvolles Setup mit einem lokalen LLM in Home Assistant nicht möglich war, weshalb ich letzten Endes bei GPT-OSS-120B über die OVH-API hängen geblieben bin. Dieses Setup funktionierte zwar grundsätzlich zufriedenstellend, aber dennoch hat mich das Thema „Lokale KI“ nicht mehr losgelassen.

Die Hauptprobleme der RX 5700XT lassen sich effektiv zurückführen auf zu wenig VRAM und zu geringe KI-Leistung bzw. wenig Unterstützung für moderne APIs wie ROCm. Bereits im letzten Artikel habe ich die These aufgestellt, dass man für eine wirklich nutzbare lokale KI eine Grafikkarte mit moderner Architekur bzw. API-Support und mindestens 12 GB VRAM benötigt.

Als mir dann vor einigen Wochen eine AMD Radeon RX 7900GRE mit Instabilitätsproblemen beim Spielen zum Testen angeboten wurde, musste ich es natürlich damit ausprobieren – denn schließlich ist die 7900GRE ganze zwei Generationen jünger und bietet zudem 16 GB VRAM. Die gute Nachricht vorweg: auch bei einem mehrstündigen VRAM-Stresstest und Tests mit llama-bench lief die Karte stabil, KI-Inferenz ist offenkundig ein völlig anderes Lastprofil als Gaming. Das hat mich an sich auch wenig verwundert, denn die zuvor getestete RX 5700XT hatte ein sehr ähnliches Problem gezeigt, weshalb ich sie überhaupt erst als LLM-Karte evaluiert hatte.

Die RX 7900GRE wanderte also in meinen TrueNAS Scale Server um dort als KI-Beschleuniger für HA zu dienen. Um meine Erfahrungen damit, die letztendlich verwendete Konfiguration (und ob ich damit so zufrieden war, dass dieses Mal alles lokal geblieben ist) soll es im Folgenden gehen.

Zunächst vorweg nochmal die Dinge, die sich nicht verändert haben: Die von mir genutzte LLM-Integration in Home Assistant ist immer noch „Local OpenAI LLM“ über HACS, welche auch seit meinem letzten Artikel weiter entwickelt wurde. Zusätzlich verwende ich nach wie vor „Tools for Assist„. Neu hinzugekommen ist lediglich eine MCP-Integration für SearXNG, damit das LLM wirklich das Web durchsuchen und nicht nur SearXNG-Snippets abrufen kann, aber das wäre eher ein Thema für einen separaten Beitrag.

Ein erster Test der Karte mit dem zuvor auf der 5700XT getesteten Meta Llama 3.1 8B Instruct offenbarte bereits eine um ein vielfaches höhere Geschwindigkeit: statt bis zu 30 Sekunden (gelegentlich sogar mehr) liefen Prompts jetzt in knapp 5 Sekunden durch. Bei der Gelegenheit habe ich mit llama-bench auch noch Vulkan gegen ROCm getestet, wobei ROCm in jedem Szenario schneller war, weshalb ich die folgenden Tests alle nur noch mit ROCm durchgeführt habe.

Denn Meta Llama 3.1 8B Instruct ist zwar kein per se schlechtes Modell, aber es ist doch mittlerweile 2 Jahre alt und die Welt hat sich selbstverständlich weitergedreht. Das von mir auch in der Vergangenheit getestete Quen3-8B ist zwar etwa ein Jahr jünger, aber dennoch mittlerweile ebenfalls überholt. Auf der Suche nach einem neueren Modell zum Testen bin ich dann auf diesen Post von simon42 gestoßen. Sein Hardwaresetup ist zwar etwas anders, da er die Modelle auf zwei APUs mit Unified RAM testet. Grundsätzlich sollte eine 16-GPU alles und mehr schaffen, was ein PC mit einer APU und 16GB RAM schafft – und bei diesen Modellen nennt er gemma4:12b-it-qat als klaren Testsieger. Als zweites interessantes Modell listet er noch lfm2.5:8b, welches durch seine „Mixture of Experts“ Architektur deutlich schneller sein soll. Beide performen auf seinem Intel Lunar Lake System zwar sehr langsam, aber eine dedizierte Grafikkarte sollte da ja nochmal in einer anderen Liga spielen, weshalb ich beide ausprobiert habe.

Die neu getesteten Modelle

LFM 2.5 8B Q5 hat mich beim ersten Test erstmal richtig positiv überrascht, und zwar mit der Geschwindigkeit. Mit der 7900GRE waren hier Antwortzeiten von zwei Sekunden oder gar schneller drin, im Benchmark erreichte das Modell sogar die dreifache Geschwindigkeit von Quen3. Wer von seinem Modell nur das Schalten von Entitäten erwartet, der kann hier möglicherweise bereits aufhören zu lesen und sollte zuerst genau dieses Modell testen. Allerdings: für höhere Ansprüche stellte sich LFM als weniger geeignet heraus und antwortete auf Wissensfragen häufig mit „ich habe keinen Zugriff auf“, obwohl das SearXNG Tool vorhanden und im System Prompt auch genannt war. Mit „Benutze die Websuche“ konnte man LFM zwar dazu bringen, es dennoch zu benutzen, aber das ist eigentlich nicht Sinn der Sache. Außerdem antwortete LFM auf die Frage „Sind gerade noch Lampen eingeschaltet“ mit einer Liste aller Lampen und der philosophischen Aussage „Alle Lampen sind entweder eingeschaltet oder ausgeschaltet, je nach aktuellem Zustand“. Danke, Konfuzius 😀

Gemma 4 12b it-qat eine Variante von Gemma 4, die speziell für Tool-Calling trainiert wurde (das „it“ steht für „Instruction-Tuned“). Zusätzlich sorgt das so genannte „Quantization-Aware Training“ dafür, dass der Qualitätsverlust durch Quantisierung reduziert werden soll. Für Home Assistant eignet sich diese Variante sehr gut, da Tool-Calling eine zentrale Aufgabe des LLMs ist, um Entitäten zu steuern oder Dinge im Internet nachzschauen. Anders als bei LFM 2.5 handelt es sich um ein „Dense-Model“, das heißt dass alle 12 Milliarden Parameter ständig aktiv sind, was die Geschwindigkeit verringert. Unterm Strich bewegen sich Antwortzeiten des Modells bei mir zwischen 4 und 10 Sekunden, je nachdem wie viele Toolcalls notwendig sind – mehrere Toolcalls verlängern natürlich die Ausführungszeit. Wichtig anzumerken ist hier, dass 10 Sekunden eher die Ausnahme sind, in der Regel liegt das Modell bei um 5 Sekunden. Das macht es zwar deutlich langsamer als LFM 2.5, aber dafür ist Gemma 4 auch sehr viel intelligenter.

Besonders beeindruckt hat mich, als ich das Modell nach dem nächsten Abholtermin für Papiermüll gefragt habe. Daraufhin fragte Gemma zunächst wie gewünscht den Abfallkalender in HA ab, allerdings stellt die Kalender-Abfrage in HA standardmäßig zunächst nur den nächsten Termin bereit und lässt sich per entsprechendem Suchbefehl auf maximal eine Woche ausdehnen. Da der Termin hier nicht dabei war, beschloss das Modell also kurzerhand, den Abfallkalender für meinen Wohnort im Internet zu suchen und mir darüber eine Antwort zu geben. Genau dieses agentische Verhalten ist es, was den Sprachassistenten erst richtig intelligent macht. Auch Fragen wie „ist irgendwo noch Licht an?“ beantwortet Gemma zuverlässig. Ebenfalls ist die Ausdrucksweise von Gemma, denn im Gegensatz zu Qwen oder LFM leistet es sich keine holprigen Formulierungen, sondern spricht natürlich klingendes und korrektes Deutsch.

Wenig überraschend ist damit meine Wahl letztendlich auf Gemma gefallen – gelegentlich längere Antwortzeiten fallen für mich deutlich weniger ins Gewicht, wenn man dafür ein Sprachmodell erhält, welches einen zuverlässig versteht und auch (fast immer) das tut, was man von ihm möchte.

Die Konfiguration von Llama und Home Assistant

Die 7900 GRE wird als verhältnismäßig moderne GPU nativ in allen modernen Linux-Systemen unterstützt und spricht auch nativ ROCm, quasi AMDs CUDA-Äquivalent. Für meinen TrueNAS Scale Server macht es das sehr einfach, da die GPU nativ von Containern bzw. Apps benutzt werden kann. Man braucht also keine VMs, muss sich nicht mit PCIe-Passthrough herumschlagen und kann die Karte theoretisch für mehrere Apps verwenden (z.B. auch für Transcoding).

Die TrueNAS Scale App für Llama wurde als Custom App über YAML (Discover Apps -> More Options -> Install via YAML) eingerichtet. Meine Konfiguration findet ihr hier:

services:
  llama:
    image: ghcr.io/ggml-org/llama.cpp:server-rocm
    restart: unless-stopped

    devices:
      - /dev/kfd:/dev/kfd
      - /dev/dri/renderD128:/dev/dri/renderD128

    environment:
      GPU_MAX_HW_QUEUES: "1"

    volumes:
      - /mnt/POOL/DATASET/models:/models:ro

    ports:
      - "8080:8080"

    command:
      - -m
      - /models/gemma-4-12b-it-qat-q4_0.gguf
      - --alias
      - gemma4-12b
      - -ngl
      - "99"
      - -c
      - "32768"
      - -ctk
      - q8_0
      - -ctv
      - q8_0
      - --host
      - 0.0.0.0
      - --port
      - "8080"
      - --jinja
      - -rea
      - "off"
      - --temp
      - "0.2"
      - --top-p
      - "0.9"
      - --top-k
      - "40"
      - --api-key
      - REPLACE_WITH_API_KEY

Wichtig sind vor allem folgende Punkte:

Damit sollte euer LLM dann bereits laufen und kann zu HA hinzugefügt werden. Legt dazu in der Local OpenAI LLM Integration einen neuen Dienst an und gebt als Server URL die IP-Adresse eures Servers und den Port 8080 an (z.B. http://192.168.1.30:8080/v1). Als Server Type wählt llama.cpp und stellt sicher, dass euer API-Key korrekt ist.

Anschließend habt ihr die Möglichkeit, euren Systemprompt zu konfigurieren. Da ich das LLM gerne auch für einfache Rechercheaufgaben bzw. Wissensfragen verwende empfiehlt es sich hier, das Modell anzuweisen, spezifische Daten und Fakten immer im Internet nachzuschlagen. Relevant ist das auch fürs Wetter – die Integration kann dem Modell die lokale Wettervorhersage aus HA zur Verfügung stellen, aber logischerweise immer nur für den Wohnort. Das LLM muss also den Unterschied zwischen „Wetter am Wohnort“ und „Wetter anderswo“ kennen. Mein Systemprompt (ohne Anspruch darauf, vollständig oder perfekt zu sein) sieht folgendermaßen aus:

You are a voice assistant for Home Assistant.

Always answer in natural, idiomatic German. Be friendly, direct, and conversational.

VOICE OUTPUT:
Your final response is spoken aloud directly by a text-to-speech system.
Output exactly one plain-text paragraph using normal spoken sentences.
Never use Markdown, headings, lists, bullet points, tables, or visual formatting.
Do not copy formatting from tool results.
Rewrite structured information as natural spoken German sentences.
For numerical ranges, use "von ... bis" instead of hyphens.
Keep answers concise but complete. Prefer short, clear explanations over lengthy ones.

ACCURACY AND TOOL SELECTION:

Before answering any factual question, decide whether external verification is required.

Answer directly without web research when explaining common knowledge, basic science, familiar concepts, or approximate everyday quantities.

You MUST call searxng_web_search BEFORE answering questions about specific real-world facts, including names, locations, measurements, dates, records, rankings, local information, or current events.

This requirement applies even if you believe you already know the correct answer. Do not substitute internal knowledge for a mandatory tool call.

Examples of correct behavior:

User: "Warum schwimmt Eis auf Wasser?"
Action: Answer directly using internal knowledge.

User: "Was ist der Unterschied zwischen Natron und Backpulver?"
Action: Answer directly using internal knowledge.

User: "Was ist das höchste Gebäude in München?"
Action: Call searxng_web_search before answering.

User: "Wie hoch ist der CN Tower?"
Action: Call searxng_web_search before answering.

User: "Welche gesetzlichen Feiertage gelten bei uns?"
Action: Call searxng_web_search before answering.

User: "Hat der Europapark morgen geöffnet?"
Action: Call searxng_web_search, then verify opening hours with web_url_read.

User: "In welchem Jahr wurde Schloss Neuschwanstein erstmals für Besucher geöffnet?"
Action: Call searxng_web_search before answering.

User: "Wann wurde die erste elektrische Straßenbahn in Deutschland eröffnet?"
Action: Call searxng_web_search before answering.

Important: Historical dates and years are specific factual claims. Always verify them through web research, even when the answer seems familiar. Never estimate or guess an exact year.

Never invent factual details. If reliable information cannot be found, acknowledge uncertainty.

Do not treat your own previous answers as verified facts.

LOCATION CONTEXT:
The user's home location is [HEIMARTORT EINFÜGEN] in the district of [LANDKREIS EINFÜGEN].
The local timezone is Europe/Berlin.

When the user says "hier", "bei uns", "in der Nähe", "in meiner Umgebung", or asks about local matters without specifying a location, use the home location as the default geographical reference.

This applies to local businesses, events, public holidays, regulations, transport, and other location-dependent information.

If the user explicitly mentions another location, use that location instead.

The home location is not necessarily the user's current physical location. Do not claim to know the user's live location unless it has been provided by an appropriate tool.

For specific local facts, use web research as required by the accuracy rules. Never invent nearby places or local details.

If the intended location is ambiguous and important to the answer, ask for clarification.

WEB RESEARCH:
Use searxng_web_search first.

For simple, stable facts, reliable search-result snippets may be sufficient.

For time-sensitive information, exact measurements, records, rankings, conflicting results, or questionable claims, verify the answer by opening a relevant source with web_url_read.

Prefer official or authoritative sources for exact and current facts. Wikipedia is useful for established general knowledge.

If sources disagree, do not confidently present an unverified claim.

Never claim to have verified information online unless you actually used the relevant tools.

After every tool result, decide whether further research is necessary before giving your final answer.

HOME ASSISTANT:
Use the available Home Assistant tools to obtain device states and perform requested actions.
Never invent device states or claim an action succeeded without confirmation from the relevant tool.

WEATHER:
For weather without a specified location, use the weather tool.
For weather at a specific location, use web research instead.

DATES AND EVENTS:
For questions about upcoming events, use the current local date and time as reference.
Compare every candidate date with the current date.
Never present a past event as an upcoming event.
If available results only contain past dates, continue researching.
If a current or future date cannot be verified, say so clearly.

Der Prompt ist auf Englisch, da dieser von der Integration in den auf Englisch gehaltenen Prompt mit den HA-Entitäten eingebettet wird. Darunter könnt ihr noch eure Tool Provider konfigurieren, meine kommen aus „Tools for Assist“ sowie einem MCP-Server für SearXNG, da dieses dem LLM auch erlaubt, Webseiten zu öffnen statt nur SearXNG-Snippets auzugeben wie das Websuche Tool der „Tools for Assist“ Integration. Verwendet ihr letzteres nicht, könnt ihr natürlich auch den entsprechenden Block aus dem Systemprompt entfernen.

Der Prompt ist eher umfangreich und enthält konkrete Beispiele, weil das in meiner mehrwöchigen Nutzung die Anzahl an Fehlern bzw. Halluzinationen bei der Websuche deutlich verringert hat. Stellt auch sicher, dass die Temperature hier korrekt gesetzt ist, da dieser Wert möglicherweise den Wert in eurem Container überschreiben kann – ich verwende wie gesagt den Wert 0,2. Date/Time context injection sollte auf „Tool Result“ stehen.

Unter „Request Body Parameters“ habe ich noch „cache_prompt · {{ true }}“ gesetzt, damit der Prompt immer gecached wird. Ob das wirklich immer funktioniert kann ich nicht beurteilen, aber meistens ist die Performance sehr gut.

Wenn ihr häufig Wissensfragen an das Modell stellt und freststellt, dass es gelegentlich immer noch Fakten erfindet anstatt im Internet nachzusehen kann Thinking helfen – es macht aber natürlich auch die Antworten langsamer. Thinking könnt ihr direkt über die HA-Integration aktivieren, mit dem Chat Template Argument „enable_thinking · {{ true }}“. Damit Gemma nicht zu lange denkt, lässt sich unter Request Body Parameters ein Token-Budget einstellen. Ich habe es mit „thinking_budget_tokens · {{ 64 }}“ auf 64 Tokens gesetzt, was auf meiner 7900 GRE etwa einer Sekunde entspricht. Das ist wenig, aber gerade genug damit das Modell ziemlich zuverlässig feststellt, ob es etwas weiß, im Internet nachsehen sollte oder (und das ist besonders wichtig) es die Frage nicht eindeutig zuordnen kann.

Das Problem: die Integration übergibt diese Parameter jedes Mal neu an Llama, also auch nach jedem Toolcall. Für meine Zwecke reicht es jedoch in der Regel, wenn das LLM einmal zu Beginn nachdenkt. Das ist möglich, erfordert aber einen minimalen Eingriff in die Integration. Dazu habe ich die Datei /config/custom_components/local_openai/entity.py mithilfe von nano über die Terminal-App bearbeitet. Sucht in der Datei nach der Methode _run_agent_loop() und fügt unmittelbar nach der Zeile for iteration in range(MAX_TOOL_ITERATIONS): folgendes ein:

# Allow thinking only on the first LLM call.
# Disable thinking when processing tool results.
if iteration > 0:
    extra_body = model_args.setdefault("extra_body", {})
    kwargs = extra_body.setdefault("chat_template_kwargs", {})
    kwargs["enable_thinking"] = False
    extra_body["thinking_budget_tokens"] = 0

Achtet dabei auf korrekte Einrückung. Nach dem Speichern müsst ihr einmal HA Core neustarten, damit die Modifikation aktiv wird. Achtung: Ein Update der Local OpenAI LLM Integration kann diese Modifikation wieder überschreiben! Es ist aktuell jedoch der einfachste Weg, das so umzusetzen. Diese Änderung und Thinking im Allgemeinen sind aber optional – wenn ihr dem Modell gar keine Wissensfragen stellen wollt müsst ihr das nicht machen.

Konfiguration von Whisper und Wyoming

Damit läuft Gemma auf der GPU und kann in HA angesprochen werden. Ein weiteres Thema verbleibt jedoch, und zwar Speech-to-Text, wofür HA in der Regel Whisper über das Wyoming Protokoll verwendet. Zuvor lief das bei mir auf der CPU, was jedoch auch bei Verwendung des Modells „small-int8“ stets mit einer Latenz von ca. 4-5 Sekunden verbunden war. Das Modell „base-int8“ ist zwar schneller, aber versteht gesprochene Befehle dafür deutlich schlechter. Da die 7900 GRE mehr als genug VRAM mitbringt, kann sie zusätzlich zu Llama aber auch noch Whisper ausführen, ich habe mich gleich für das Modell „ggml-large-v3-turbo“ entschieden, welches nochmal deutlich zuverlässiger funktioniert als „small-int8“. Auch Whisper kann als Custom-App in TrueNAS Scale ausgeführt werden, allerdings gibt es hier leider kein fertiges ROCm-Image, weshalb man sich dieses zunächst selber bauen muss. Legt dafür in einem entsprechenden Dataset (z.B. /mnt/POOL/DATASET/whisper-build/Dockerfile) ein Dockerfile an:

FROM rocm/dev-ubuntu-24.04:7.2.4-complete

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
      build-essential \
      cmake \
      git \
      ca-certificates && \
    rm -rf /var/lib/apt/lists/*

WORKDIR /opt/whisper.cpp

RUN git clone --depth 1 --branch v1.9.4 \
    https://github.com/ggml-org/whisper.cpp.git .

ARG AMDGPU_TARGETS=gfx1100

RUN HIPCXX="$(hipconfig -l)/clang" \
    HIP_PATH="$(hipconfig -R)" \
    cmake -S . -B build \
      -DCMAKE_BUILD_TYPE=Release \
      -DGGML_HIP=ON \
      -DAMDGPU_TARGETS="${AMDGPU_TARGETS}" \
      -DWHISPER_BUILD_TESTS=OFF \
      -DWHISPER_BUILD_SERVER=ON && \
    cmake --build build \
      --target whisper-server -j 4

EXPOSE 8910

ENTRYPOINT ["/opt/whisper.cpp/build/bin/whisper-server"]

Das könnt ihr mit nano über SSH oder das Web-UI-Terminal von TrueNAS Scale machen. Anschließend müsst ihr das Image noch bauen:

docker build \
  --build-arg AMDGPU_TARGETS=gfx1100 \
  -t local/whisper-rocm:v1.9.4 \
  /mnt/POOL/DATASET/whisper-build

Das dauert dann einen Moment. Anschließend könnt ihr dann in TrueNAS die Custom App für Whisper und die Wyoming-Bridge anlegen:

devices:
  - /dev/kfd:/dev/kfd
  - /dev/dri/renderD128:/dev/dri/renderD128

environment:
  GPU_MAX_HW_QUEUES: "1"

volumes:
  - /mnt/POOL/DATASET/models:/models:ro

command:
  - -m
  - /models/ggml-large-v3-turbo.bin
  - --host
  - 0.0.0.0
  - --port
  - "8910"
  - -l
  - de
  - --flash-attn

depends_on:
  - whisper

ports:
  - "10300:10300"

command:
  - --uri
  - tcp://0.0.0.0:10300
  - --api
  - http://whisper:8910/inference
  - --debug

Theoretisch ließe sich die Wyoming-Bridge auch in einen zusätzlichen Container auslagern, aber so hat es den Vorteil, dass der Traffic zwischen Whisper und der Bridge den Container nicht verlassen muss, was potenzielle Fehlerquellen reduziert. Wichtig: auch hierfür muss in euerem verwendeten Dataset natürlich bereits das Whisper-Modell liegen.

Beachtet auch hier wieder den Parameter GPU_MAX_HW_QUEUES: "1". Wie oben schon geschrieben ist dies ein Workaround für einen aktuellen ROCm Bug, bei dem zwei aktive ROCm Anwendungen auf der selben GPU dazu führen, dass diese nie heruntertaktet und im Leerlauf in meinem Fall 60-70 Watt mehr als normal verbraucht (normal für die 7900 GRE sollten 10-15 Watt sein). Da Whisper und Llama in der HA Pipeline normalerweise nie gleichzeitig angesprochen werden, sollte das keinen weiteren Einfluss haben.

Anschließend müsst ihr Whisper bzw. die Wyoming-Bridge noch in HA über die Integration „Wyoming Protocol“ inzufügen.

In meinem Fall mit der RX 7900 GRE funktioniert das hervorragend: mit ROCm beträgt die Whisper-Latenz trotz des größeren Modells im Schnitt nur noch 0,5 Sekunden. Kommandos, die über die HA Intent Engine verarbeitet werden, funktionieren damit quasi sofort und die Gesamtlatenz fällt natürlich auch entsprechend wenn man das LLM verwendet.

Fazit

Bin ich mit diesem Setup endlich soweit, dass ich die vollständig lokale Haus-KI über HA Voice als Alltagstauglich einstufe? Kurz und knapp: Ja.

Die Kombination aus Gemma 4 12b it-qat und Whisper mit large-v3-turbo versteht gesprochene Anweisungen zuverlässig und setzt diese zumindest in meinem mittlerweile mehrwöchigen Test auch zuverlässig um. Auch die Latenz ist endlich in einem erträglichen Bereich – 0,5s STT-Latenz ist quasi nicht wahrnehmbar, und die LLM-Latenz von im Schnitt 5 Sekunden ist damit in einem Bereich, mit dem ich gut leben kann.

Der VRAM-Verbrauch mit Gemma und Whisper lag mit einer Kontextgröße von 65.536 bei etwa 11 GB, grundsätzlich sollte dieses Setup also auch für 12-GB Karten funktionieren. Falls es knapp wird, könnte man ein kleineres Whisper-Modell versuchen, ich habe mich auch primär deswegen für Large entschieden, weil auf der 16-GB Karte noch großzügig VRAM frei war.

Mit 4 GB freiem VRAM kann die RX 7900 GRE zusätzlich auch noch weitere Aufgaben wie beispielsweise Media-Transcoding wahrnehmen, da diese in der Regel nicht besonders viel VRAM benötigen und auch andere Teile der GPU auslasten als der LLM-Server. Das muss ich aber im Detail noch testen.

Auf jeden Fall läuft meine HA-KI nun endlich wirklich vollständig lokal, und das wird dieses Mal auch so bleiben.