KI ohne Cloud: ein Sprachmodell auf einer Notebook-Grafik

Ein Brief vom Arzt kommt in den Scanner. Ich drücke die Taste, und eine Weile später brummt das Handy: „Paperless: verarbeitet“, darunter ein Titel, der Absender, die Art des Dokuments und ein Link. Eingetippt habe ich davon nichts. Irgendetwas hat den Brief gelesen, erkannt, von wem er kommt, und ihn in mein Archiv einsortiert.

Wie der Brief vom Scanner ins Archiv kommt, habe ich in Teil 3 erzählt. Das Archiv heißt Paperless, ein Programm, das gescannte Post speichert und durchsuchbar macht. Offen geblieben ist dort, wer den Brief eigentlich liest. Davon handelt dieser Text.

Ein Sprachmodell, aber zu Hause

Gelesen hat den Brief ein Sprachmodell. Das ist ein Programm, das mit riesigen Mengen Text trainiert wurde und dadurch Text verstehen und schreiben kann, dieselbe Art Technik, die hinter den bekannten KI-Chats steckt. Gibt man ihm einen Brief und fragt „Wer hat das geschickt?“, antwortet es mit dem Absender.

Die bequeme Lösung wäre, den Brief an eines der großen Modelle im Internet zu schicken, in die „Cloud“. Genau dort will ich so einen Brief aber nicht haben, einen Kontoauszug oder Steuerbescheid erst recht nicht. Ein Cloud-Modell wäre vermutlich klüger, keine Frage. Aber nur wenn das Modell bei mir zu Hause läuft, liest niemand sonst meine Post mit.

Dazu kommt eine zweite Regel. Die Abläufe, die mit dem Modell sprechen, protokollieren nur Dinge wie die Nummer des Dokuments, nie den Brieftext.

Mein Modell hat zwei Nutzer. Der eine ist die automatische Kette, die neue Briefe einsortiert und am Ende mein Handy brummen lässt. Der andere bin ich selbst, wenn ich mit dem Modell chatten will, so wie mit den bekannten KI-Chats im Browser. Bevor ich zeige, wie beide zum Modell kommen, ein Blick auf den Rechner, auf dem es läuft.

Ein Grafikchip ohne eigenen Speicher

Ein Sprachmodell rechnet vor allem eines: sehr viele einfache Multiplikationen auf einmal. Das kann ein Grafikchip, kurz GPU, viel besser als der normale Prozessor, weil er für Bilder genau solche Rechnungen parallel erledigt. Deshalb laufen Sprachmodelle am liebsten auf Grafikkarten.

Eine große Grafikkarte habe ich nicht. Mein Arbeitsplatzrechner ist ein Mini-PC mit einem Ryzen 7 7840HS, einem Prozessor, der sonst in Notebooks steckt. In diesem Prozessor ist ein kleiner Grafikchip gleich mit eingebaut, eine Radeon 780M. So etwas heißt integrierte Grafik. Sie hat keinen eigenen Speicher, sondern teilt sich die 50 GB Arbeitsspeicher mit dem restlichen System.

Damit das Modell auf diesem Chip läuft, braucht es ein Programm, das die Modelldatei lädt und Fragen beantwortet. Bei mir ist das llama.cpp, ein freies Programm, das Sprachmodelle auf gewöhnlicher Hardware ausführt. Man kann es sich wie einen Schalter in einer Behörde vorstellen: Andere Programme stellen ihm über das Netzwerk eine Frage, und es reicht die Antwort des Modells zurück. Es spricht dabei dieselbe Sprache wie die Schnittstelle von OpenAI, deshalb können viele fertige Werkzeuge ohne Umbau mit ihm reden.

Wie Chat und Kette den Rechner erreichen

Die übrigen Dienste meines Homelabs laufen nicht auf dem Arbeitsplatzrechner, sondern auf einem eigenen Server. Dort hat jeder Dienst seine eigene virtuelle Maschine, kurz VM, also einen eigenen kleinen Rechner, der nur als Software existiert. Drei davon spielen hier mit. paperless-01 ist die VM mit dem Archiv. n8n-01 ist die VM mit n8n, einem Werkzeug, in dem man Abläufe aus Bausteinen zusammensteckt. Dort läuft die Kette, die neue Briefe einsortiert. Und openwebui-01 ist die VM mit Open WebUI, einer Chat-Seite für den Browser.

Alle drei reden mit dem Modell über NetBird. Das ist ein verschlüsseltes privates Netz zwischen meinen Geräten, wie ein Tunnel, in den niemand von außen hineinschauen kann. Teil 2 erklärt es genauer. Das Bild zeigt beide Wege.

Links der Chat: Ich öffne die Seite im Browser, Open WebUI leitet meine Frage an llama.cpp weiter. Die VM dafür ist winzig, zwei Kerne und 2 GB Arbeitsspeicher, denn das Modell selbst liegt ja nicht dort. Rechts die Kette: Paperless meldet einen neuen Brief an n8n, und n8n stellt dem Modell nacheinander seine Fragen. Den grauen Pfeil erkläre ich weiter unten, er gehört zu den Dingen, die nicht geklappt haben.

Auf dem Server selbst steht das Modell nicht, weil dessen älterer Grafikchip gleichzeitig sein einziger Bildschirmanschluss ist und sich schlecht an eine VM weiterreichen lässt. Bleibt die Frage, ob der kleine Chip im Arbeitsplatzrechner überhaupt reicht.

Viele Experten, wenig Arbeit

Um das zu beantworten, braucht es zwei Begriffe. Parameter sind die Zahlen, in denen das Modell beim Training sein Wissen abgelegt hat, eine riesige Sammlung von Zahlen. Mein Modell hat 30 Milliarden davon. Und ein Token ist das Stück Text, in dem ein Modell liest und schreibt, meist ein Wortteil. Bei meinen Briefen sind 24.000 Zeichen grob 7.000 Token.

Ein klassisches Modell geht für jedes einzelne Token durch alle seine Parameter. Bei einem Grafikchip ohne eigenen Speicher ist das der Engpass: Rechnen könnte er schneller, aber er wartet darauf, dass die Zahlen aus dem Arbeitsspeicher herbeikommen. Je mehr Parameter pro Token, desto länger dauert jedes Wort.

Mein Modell, Qwen3-30B-A3B, ist anders gebaut. Es ist ein „Mixture of Experts“, eine Mischung aus Fachleuten. Stell dir eine Firma mit vielen Abteilungen vor, deren Empfang jede Frage nur an die zwei, drei Abteilungen weitergibt, die sich damit auskennen. So ähnlich wählt das Modell für jedes Token nur einen kleinen Teil seiner Parameter aus, rund 3 Milliarden, dafür steht „A3B“ im Namen. Im Speicher liegen trotzdem alle 30 Milliarden, gelesen wird pro Token aber nur etwa ein Zehntel.

Wie viel das ausmacht, habe ich im August ausprobiert, mit einem klassischen Modell ähnlicher Größe auf demselben Chip. Die Zahl für mein Modell stammt aus dem Protokoll von llama.cpp seit September:

Beim klassischen Modell dauerte eine kurze Antwort von 100 Token rund 45 Sekunden. Man schaut dem Text zu wie einem Fax. Mein jetziges Modell ist mehr als zehnmal so schnell, obwohl es insgesamt größer ist.

Damit die 30 Milliarden Zahlen in den Speicher passen, sind sie gröber gespeichert, ähnlich wie ein stärker komprimiertes Foto. Die Datei ist so nur 18,6 GB groß.

Und im Alltag? Seit dem Umzug Anfang September zeigt das Protokoll 862 Anfragen. Eine typische Anfrage dauert 19 Sekunden, die längste brauchte knapp 80. Für einen Brief, auf den niemand ungeduldig wartet, reicht das.

Zwei Plätze am Tisch

Schnell genug für einen Brief also. Aber was passiert, wenn ich chatte, während gerade ein Brief einsortiert wird?

Dafür noch ein Begriff. Der Kontext ist alles, was das Modell bei einer Anfrage auf einmal im Blick hat: meine Anweisung, den Brieftext und seine eigene Antwort. llama.cpp reserviert dafür Platz im Arbeitsspeicher. Bei mir sind das 32.768 Token, aufgeteilt in zwei gleich große Plätze, auf Englisch „Slots“, mit je 16.384 Token. Jeder Platz bearbeitet genau eine Anfrage, wie zwei Stühle an einem Beratungstisch. Kommt eine dritte, wartet sie, bis ein Stuhl frei wird.

Früher war der Kontext viermal so groß, aber der Speicher ist knapp, also habe ich gekürzt. Gefehlt hat nichts, die längste Anfrage im Protokoll war 6.626 Token lang.

Doppelt so schnell wird es dadurch nicht, die beiden teilen sich ja denselben Chip. Allein schreibt eine Anfrage im Median 19 Token pro Sekunde, zu zweit 15. Dafür hält eine lange Anfrage nicht mehr alle anderen auf.

Dazu kommt eine Schutzleine. Länger als 1.024 Token darf keine Antwort werden, bei meinem Tempo ist also nach rund einer Minute Schluss. Warum mir das so wichtig ist, zeigt weiter unten die erste Geschichte.

Wählen, nicht erfinden

Im Chat darf das Modell plaudern. In der Kette nicht. Wenn es dort einen Absender nennt, muss es einer sein, den mein Archiv schon kennt. Paperless nennt Absender übrigens „Korrespondenten“. Ohne Regel hätte ich nach einem Monat „Stadtwerke“, „Stadtwerke GmbH“ und „Stadwerke“ als drei verschiedene Korrespondenten.

Deshalb bekommt das Modell in der Kette ein Formular vor die Nase. Technisch ist das ein JSON-Schema. JSON ist ein einfaches Textformat für Daten mit Feldnamen und Werten, etwa {"correspondent": "Unbekannt"}. Das Schema ist die Vorlage dazu: Es legt fest, welche Felder es gibt und welche Werte erlaubt sind. Bei der Frage nach dem Korrespondenten sieht der wichtige Teil so aus:

{"correspondent": {"type": "string",
                   "enum": ["<Korrespondent 1>", "<Korrespondent 2>", "…", "Unbekannt"]}}

enum ist die Liste der erlaubten Antworten. Die Kette holt sie bei jedem Brief frisch aus Paperless.

Das eigentlich Schöne passiert in llama.cpp. Das Programm achtet beim Schreiben jedes einzelnen Tokens darauf, dass die Antwort noch zum Schema passt, und lässt alles andere gar nicht erst zu. Das Modell kann also keinen Korrespondenten erfinden, der nicht auf der Liste steht, und auch keinen höflichen Satz davor schreiben. Es darf wählen, aber nicht erfinden. Passt nichts, bleibt „Unbekannt“ stehen, und das sehe ich.

Zur Sicherheit prüft n8n die Antwort danach noch einmal. Ist sie leer oder unlesbar, bricht der Ablauf mit einer Fehlermeldung ab, statt den Brief still als „Unsortiert“ abzulegen. Einen Fehler in n8n finde ich. Einen falsch einsortierten Brief vielleicht nie.

Was nicht geklappt hat

So glatt lief es natürlich nicht von Anfang an.

Aus der Praxis: Paperless bringt selbst eine KI-Funktion mit, die zu jedem Dokument Vorschläge macht. Das war mein erster Versuch: 64 Zeitüberschreitungen, kein einziger Erfolg. Paperless schickt dem Modell den Brief, alle Schlagworte, alle Korrespondenten und ähnliche Dokumente, zusammen rund 5.000 Token, und erwartet eine Antwort in einem festen Format. Das kleinere Modell, das ich damals hatte, schrieb stattdessen freien Text, über 4.000 Token und fünf Minuten lang. Paperless gab nach zwei Minuten auf, der Platz blieb trotzdem belegt. Mit dem jetzigen Modell und der Antwortgrenze kamen die Vorschläge dann in 56 Sekunden. Im Browser war aber auch das zu langsam: Jedes Dokument, das ich öffnete, fragte das Modell, beide Plätze waren dauernd belegt, und irgendwann scheiterte sogar das Speichern. Seitdem ist die Funktion aus, das ist der graue Pfeil im ersten Bild, und die KI arbeitet nur noch im Hintergrund über n8n.

Aus der Praxis: Bevor ein Sprachmodell einen Brief lesen kann, muss aus dem gescannten Bild erst Text werden. Das nennt man Texterkennung oder OCR. Auch die sollte eigentlich KI werden, mit einem Modell namens PaddleOCR-VL, das eine Seite als Bild versteht. Es braucht aber einen Grafikchip von Nvidia und läuft auf meinem AMD-Chip schlicht nicht. Eine ältere Variante, die nur auf dem Prozessor rechnet, belegte bei jedem Brief fast acht der sechzehn Rechenkerne, das war zu viel. Ich bin zu Tesseract zurück, der Texterkennung, die Paperless schon mitbringt. Für gedruckte Briefe reicht ihr Text dem Sprachmodell völlig.

Eine Grenze bleibt trotzdem. Das Modell läuft auf genau einem Rechner. Ist der aus, gibt es keine Antworten, und es passt immer nur ein großes Modell in den Speicher. Eine VM auf dem Server, die ein kleineres Modell nur mit dem Prozessor rechnet, steht als Option im Plan. Gebaut habe ich sie nicht, und ob sie schnell genug wäre, weiß ich ehrlich gesagt nicht.

Was ich mitnehme

• Auf einem kleinen Grafikchip bremst der Speicher. Ein Modell, das pro Token nur wenige Parameter braucht, ist dort ein Vielfaches schneller.
• Feste Plätze und eine Grenze für die Antwortlänge kosten kaum etwas und verhindern, dass eine verirrte Anfrage alle anderen blockiert.
• Mit einer Vorlage, einer Liste und einer Prüfung danach wird aus einem plaudernden Modell ein Werkzeug, auf das ich mich verlasse.
• Ein langsames Modell gehört in den Hintergrund, nicht dorthin, wo jemand auf einen Klick wartet.

Wenn das Handy also das nächste Mal brummt, weiß ich, wer den Brief gelesen hat: ein Grafikchip aus der Notebook-Klasse, ein paar Fachleute im Modell und eine Liste, die keine Ausreden zulässt. Wie der Brief überhaupt zum Text wird und was die Kette danach mit Absender, Schlagworten und Titel anstellt, steht in Teil 3.