Mein lokales Wissens-System läuft nicht auf einer Maschine, sondern auf zweien. Ein stromsparender Mac mini erledigt die leichte Dauerarbeit — das Finden. Ein KI-NAS mit Intel-Arc-Grafik wird nur bei Bedarf geweckt und übernimmt die schwere Rechenarbeit — das Antworten. Das Prinzip dahinter ist simpel und übertragbar: leichte Last billig im Dauerbetrieb halten, schwere Last nur dann wecken, wenn man sie wirklich braucht. Hier die Hardware, die echten Zahlen und ein ehrlicher Blick auf die Grenzen.
Zwei Arbeiten, die unterschiedlicher kaum sein könnten
Ein lokales RAG-System (Retrieval-Augmented Generation) zerfällt in zwei sehr verschiedene Aufgaben. Die erste ist das Finden: aus einer Frage die passenden Textstellen heraussuchen. Die zweite ist das Antworten: aus diesen Stellen einen sauberen Absatz formulieren.
Das Finden ist leicht. Es passiert ständig — bei jeder neuen oder geänderten Notiz, bei jeder Suchanfrage. Aber es kostet kaum Rechenleistung. Das Antworten ist das Gegenteil: Es passiert selten, nur wenn ich wirklich eine formulierte Antwort will. Dafür braucht es ein großes Sprachmodell und damit richtig Leistung.
Beides auf dieselbe Maschine zu legen wäre möglich, aber unklug. Entweder hätte ich einen ständig laufenden, stromhungrigen Server für die seltene schwere Last — oder eine zu schwache Maschine, die bei der Antwort einknickt. Die saubere Lösung: zwei Maschinen, jede für ihre Rolle.
Der Mac mini: das immer-an Arbeitstier
Die Dauerarbeit übernimmt ein Mac mini (M2 Pro). Er läuft ohnehin durch und ist im Leerlauf extrem genügsam. Auf ihm passieren zwei Dinge:
- Embeddings. Jede Notiz wird in Bedeutungsvektoren übersetzt — über das Modell bge-m3, das via Ollama lokal läuft. Das geschieht einmal beim Aufbau und danach nur noch für geänderte Dateien.
- Vektorsuche. Die eigentliche semantische Suche ist eine schlichte Rechnung mit numpy — die Frage gegen alle Vektoren, die nächsten Nachbarn zurück.
Beides erzeugt auf dem M2 Pro keine nennenswerte Dauerlast. Der Index aus dem Prototyp ist gerade einmal ~4 MB groß; die Suche läuft im Bruchteil einer Sekunde. Genau das ist die Definition von „leichte Arbeit, die man dauernd machen kann“: Sie stört den restlichen Betrieb nicht und kostet praktisch keinen Strom.
Das KI-NAS: das Kraftwerk auf Abruf
Die schwere Arbeit liegt auf einem Ugreen AI-NAS (Modell IDX6011PRO). Das Gerät hat eine Intel-Arc-iGPU, auf der die Inferenz über llama.cpp (SYCL-Backend) läuft. Hier wohnt das Sprachmodell — und hier passiert die einzige wirklich rechenintensive Arbeit der ganzen Kette.
Der entscheidende Trick steckt in der Wahl des Modells: Qwen3.5-35B-A3B. Das ist ein Mixture-of-Experts-Modell. Es hat zwar 35 Milliarden Parameter insgesamt, aktiviert aber pro Token nur etwa 3 Milliarden davon. Man kann es sich wie ein großes Team von Spezialisten vorstellen, von denen für jede Frage nur die wenigen passenden mitarbeiten, statt alle gleichzeitig.
Genau deshalb läuft so ein großes Modell überhaupt flott auf einer integrierten Grafik. Quantisiert mit Q4_K_M belegt es rund 22 GB und liegt komplett auf der GPU. Würde das Modell bei jedem Token alle 35 Milliarden Parameter durchrechnen, wäre die iGPU hoffnungslos überfordert. So aber bleibt der Aufwand pro Token überschaubar.
Und weil diese Maschine die Antwort nur selten liefern muss, wird sie auch nur bei Bedarf geweckt. Sie muss nicht durchlaufen — sie wartet, bis eine Frage kommt.
Ehrliche Performance: schnell genug, aber nicht aus dem Nichts
Ein Lauf im Detail: Eine formulierte Antwort dauerte ~37 Sekunden, das Modell schrieb dabei stabil mit ~22 Token pro Sekunde. Das ist ordentlich für eine integrierte Grafik — aber es lohnt sich, zu verstehen, warum es nicht schneller geht.
Der Engpass ist nämlich nicht die Rechenleistung. Die iGPU langweilt sich eher, als dass sie schwitzt. Der wahre Flaschenhals ist die Speicherbandbreite: Für jedes einzelne Token müssen die aktiven Modellgewichte aus dem Speicher gelesen werden, und genau dieses Lesen ist der limitierende Schritt. Die GPU rechnet nicht am Limit — sie wartet auf den Speicher.
Praktisch heißt das: Eine schnellere oder stärkere GPU würde hier wenig bringen, solange die Speicheranbindung gleich bleibt. Wer die Antwortzeit drücken will, muss am Speicher ansetzen, nicht an der Rechenleistung. Es ist ein gutes Beispiel dafür, dass „mehr Rechenpower“ nicht automatisch „schneller“ bedeutet — bei großen Sprachmodellen ist oft der Speicher der eigentliche Gegner.
Für meinen Anwendungsfall — eigene Notizen wiederfinden und zusammenfassen — sind 37 Sekunden völlig in Ordnung. Es ist kein Echtzeit-Chat, sondern eine durchdachte Antwort auf eine durchdachte Frage.
Der Stromverbrauch — und warum der Hybrid clever ist
Hier zeigt sich, warum die Zweiteilung energetisch Sinn ergibt. Das KI-NAS verbraucht im Leerlauf kaum etwas und zieht nur während der Inferenz spürbar mehr:
| Zustand des KI-NAS | Leistungsaufnahme |
|---|---|
| Leerlauf (idle, wartet auf Anfragen) | ~8 W |
| Inferenz (formuliert gerade eine Antwort) | ~19 W |
Die höhere Last von ~19 W fällt nur in den wenigen Sekunden an, in denen tatsächlich eine Antwort entsteht. Den Rest der Zeit dümpelt die Maschine bei ~8 W vor sich hin. Würde dieselbe Maschine die Dauerarbeit stemmen müssen — also ständig Embeddings und Suchen —, läge sie häufiger im oberen Bereich. So aber bleibt die teure Hardware fast immer im Spar-Zustand.
Der Mac mini wiederum ist als Dauerläufer von Haus aus auf Effizienz getrimmt und übernimmt die leichte Last, ohne dass sich das im Verbrauch groß bemerkbar macht. Die Rechnung geht auf: Die genügsame Maschine arbeitet ständig, die hungrige Maschine fast nie.
Das Prinzip, verallgemeinert
Was hier für ein RAG-System gilt, ist eigentlich eine allgemeine Bauregel für eigene Infrastruktur: Trenne leichte Dauerlast von schwerer Spitzenlast.
- Leichte Dauerlast lokal billig halten. Alles, was ständig passiert, gehört auf die genügsame, ohnehin laufende Maschine.
- Schwere Last nur bei Bedarf wecken. Die teure, stromhungrige Hardware schläft, bis sie wirklich gebraucht wird — und schläft danach wieder ein.
- Das richtige Modell schlägt die größere Maschine. Ein Mixture-of-Experts-Modell, das nur einen Bruchteil seiner Parameter aktiviert, macht aus einer integrierten Grafik ein brauchbares Sprach-Kraftwerk.
Die beiden Maschinen reden über Tailscale miteinander — ein privates Netz, in dem der Mac mini die Anfrage zustellt und die Antwort entgegennimmt. Aus zwei sehr unterschiedlichen Geräten wird so ein System, das sich wie eines anfühlt: leise, sparsam und trotzdem fähig, eine ganze Wissensbasis zu durchdenken.
Transparenzhinweis: Dieses Projekt ist selbst finanziert. Die genannten Werkzeuge (Ollama, bge-m3, Qwen, llama.cpp, numpy) sind quelloffen; die Hardware (Mac mini, Ugreen AI-NAS) habe ich selbst angeschafft. Es bestehen keine bezahlten Kooperationen mit den genannten Herstellern. Alle Zahlen stammen aus einem echten Testlauf am 17. Juni 2026.