geisten journal

Zur News-Übersicht

Der teuerste Fehler in vielen LLM-Projekten ist nicht das falsche Modell. Es ist der automatische Griff zur GPU.

Tech

Viele Unternehmen starten ihre LLM-Architektur mit der falschen Grundannahme: dass produktive Systeme automatisch GPUs und komplexe RAG-Infrastruktur brauchen. In vielen dokumenten- und wissenslastigen B2B-Szenarien ist heute das Gegenteil plausibel: kleine Modelle mit langem Kontext, klare Wissensstruktur, CPU-optimierte Inferenz und lokale Verarbeitung liefern oft die vernünftigere Kombination aus Kostenkontrolle, Latenz, Datenschutz und Wartbarkeit.

Tiny models, big impact - geisten

Wer komplexe Themen wirklich verstehen will, lernt nicht Seite für Seite eines Buches auswendig. Man arbeitet mit Orientierung: Kapitel, Begriffe, Verweise, Pfade. Erst die Struktur macht Wissen benutzbar. Manche Menschen bauen sich dafür sogar einen Gedankenpalast, also eine räumliche Gedächtnisstruktur. Die psychologische Literatur beschreibt diese Methode als Method of Loci oder Memory Palace und zeigt, dass räumliche Ordnung beim Erinnern tatsächlich wirksam sein kann (Ondřej, 2025).

Genau daran scheitern viele LLM-Projekte in Unternehmen. Hier wird oft mit der Holzhammer-Methode gearbeitet: Informationen werden aufwendig vektorisiert und wie in einer Suchmaschine organisiert, in der Hoffnung, dass das Modell sich den Rest schon zusammensetzt. Das Problem ist aber oft nicht zu wenig Rechenleistung. Das Problem ist schlechte Wissensorganisation.

Gerade im Jahr 2026 ist diese Sicht deutlich realistischer geworden. Es sind interessante Modelle und Methoden erschienen, die eine solche hierarchische Organisation von Wissen auch auf gewöhnlicher CPU-Hardware praktikabel machen. Kleine Qwen3.5-Modelle bringen lange Kontextfenster mit (Qwen3.5-0.8B, Qwen3.5-2B, Qwen3.5-4B), und Werkzeuge wie llama.cpp oder OpenVINO helfen dabei, diese Modelle lokal und effizient auf CPUs zu betreiben (llama.cpp, OpenVINO Weight Compression).

Struktur schlägt Infrastruktur

Für viele Unternehmensanwendungen geht es nicht um offenes Weltwissen, sondern um Handbücher, Richtlinien, Spezifikationen, Verträge oder interne Prozessdokumentation. Das ist begrenztes Domänenwissen. Und begrenztes Domänenwissen braucht oft keine schwere GPU-Architektur, sondern vor allem Ordnung.

Der bessere Weg ist einfach. Erst kommt die Struktur. Dann kommen die Details. Die Dokumente werden nicht nur in kleine Stücke zerlegt. Sie werden geordnet. Nach Typ. Nach Produktlinie. Nach Version. Nach Kapitel. Nach Abschnitt.

Danach werden größere Textblöcke kurz zusammengefasst. Aus diesen Kurztexten entsteht eine Karte. Diese Karte zeigt dem Modell, wo es suchen muss und in welchem Zusammenhang ein Abschnitt steht.

Bei einer Anfrage läuft das Modell nicht blind durch den ganzen Bestand. Es liest zuerst die Karte. Dann wählt es den passenden Pfad. Erst danach lädt es die wichtigen Detailstellen.

Genau dafür sind kleine Modelle gut geeignet. Sie müssen hier nicht alles wissen. Sie müssen vor allem sauber folgen. Sie müssen Kategorien erkennen, Pfade wählen und gezielt weiterlesen. Sogar ein kleines Modell wie Qwen 0.8B kann das oft gut. Es ist schnell. Es ist günstig. Und es reicht aus, wenn die Struktur stimmt.

Genau dafür gibt es inzwischen belastbare Forschung. RAPTOR von Sarthi et al. zeigt den Nutzen rekursiver Zusammenfassungen in Baumstrukturen (arXiv). Hierarchical Context Pruning von Zhang et al. zeigt, dass große Kontexte durch hierarchisches Verdichten und Beschneiden besser nutzbar werden (arXiv). Der gemeinsame Punkt ist einfach: Erst ein Inhaltsverzeichnis macht einen großen Wissensraum benutzbar.

HCMP: Hierarchische Struktur statt Vektor-Rauschen

Im Folgenden verwende ich dafür die Kurzbezeichnung HCMP, Hierarchical Context-Map-Prompt. Der Kern ist einfach. Die Struktur kommt zuerst. Die Details kommen später.

Das Wissen wird zuerst geordnet. Danach wird daraus eine Karte gebaut. Diese Karte ist ein kompakter Meta-Index. Er kann vorher erzeugt werden. Das kann auch mit einem größeren Modell geschehen. Diese Arbeit muss nicht bei jeder Anfrage neu passieren.

Im Einsatz wird die Anfrage dann klein gehalten. Das Modell liest zuerst die Karte. Es sucht den passenden Bereich. Erst dann lädt es die wenigen Stellen nach, die wirklich gebraucht werden. So bleibt der Prompt fokussiert. Und so bleibt auch der Kontext kleiner.

HCMP Ablaufdiagramm

Der Nutzen liegt genau dort. Kleine Modelle müssen nicht den ganzen Wissensraum auf einmal verarbeiten. Sie folgen einem Pfad durch den Meta-Index. Dadurch reicht oft schon ein kleines Modell aus. Es muss nicht alles wissen. Es muss nur die Struktur lesen, den richtigen Pfad wählen und dann die passenden Details auswerten. Beim Menschen ist es ähnlich. Auch wir wissen oft nicht jede Seite auswendig. Aber wir wissen, wo wir suchen müssen und wie der Weg durch das Wissen aussieht.

Genau das ist die Kernaussage. Eine hierarchische Struktur kann Promptgröße und Kontext klein genug halten, damit auch kleine Modelle qualitativ gut arbeiten. Und wenn weniger irrelevantes Material im Kontext liegt, sinkt oft auch das Halluzinationsrisiko.

Klassisches RAG versus HCMP

Variable Klassisches RAG HCMP (Qwen + Map)
Synthese-Qualität Fragmentierte Fakten-Inseln Kohärente Gesamtzusammenhänge
Halluzinations-Risiko Hoch (Kontext-Fragmentierung) Deutlich reduziert (Grounding durch Map)
Recheneffizienz Mittel (Vektor-DB Overhead) Maximal (Direktzugriff CPU)
Deployment Komplex (Infrastruktur-Stack) Instant (Inference-Engine)

Präzision statt Rauschen

Kleine Modelle scheitern oft nicht an zu wenig Wissen. Sie scheitern an zu viel schlechtem Kontext.

Wenn zu viele halbrelevante Fragmente im Prompt liegen, steigt die Fehlerquote. Dann entstehen glatte, aber falsche Antworten. Eine hierarchische Kontextkarte senkt genau diesen Druck. Das Modell sieht zuerst die Ordnung. Erst danach sieht es die Details.

Das ist auch praktisch wichtig. Ein Servicetechniker braucht nicht drei ähnliche Textstellen aus verschiedenen Revisionen. Er braucht die richtige Stelle aus dem richtigen Dokument. Eine Wissenskarte hilft dabei. Sie liefert einen lesbaren Pfad statt einer bloßen Ähnlichkeit.

Wichtig bleibt aber auch. Langer Kontext allein reicht nicht. Lost in the Middle zeigt, dass Modelle in langen Kontexten Relevantes übersehen können (arXiv). The Power of Noise zeigt, dass irrelevante Dokumente die Qualität schnell verschlechtern (arXiv). Die Schlussfolgerung ist einfach. Nicht mehr Kontext ist besser. Besser ist gezielter Kontext.

Schluss

Der eigentliche Paradigmenwechsel liegt nicht in neuer Hardware, sondern in besserer Architektur. Wer ein LLM zuverlässig auf Standard-CPUs betreiben kann, senkt Kosten, hält Latenz niedrig und gewinnt mehr Kontrolle über Daten und Betrieb. Gerade für Mittelstand, Industrie und regulierte Branchen in Europa ist das oft die vernünftigere Lösung.

Das ist aber kein Dogma. GPUs bleiben sinnvoll für hohen Durchsatz, große Modelle, multimodale Systeme und sehr harte Latenzanforderungen. Auch HCMP ist kein Wundermittel. Schlechte Dokumentstruktur bleibt schlechte Dokumentstruktur.

Die wichtige Aussage ist deshalb enger. Viele produktive LLM-Systeme brauchen keine GPU, wenn Modellwahl, Quantisierung, Kontextarchitektur und Betriebsumgebung zusammenpassen. Wer dokumentenlastige, sensible oder klar begrenzte Wissensdomänen erschließen will, sollte deshalb nicht mit der GPU beginnen. Sondern mit der Struktur.

Ich unterstütze Unternehmen bei genau dieser Übersetzung in die Praxis: bei der Auswahl, Optimierung und produktiven Nutzung von LLMs, die effizient auf CPUs laufen, mit Fokus auf niedrige Infrastrukturkosten, geringe Latenz, Datenschutz sowie Edge- und On-Prem-Betrieb. Für viele Organisationen im DACH-Raum ist das nicht die sparsame Alternative, sondern die professionellere.

Referenzen

Wenn Sie ein lokales oder CPU-effizientes LLM-System für Wissensarbeit, Dokumentation oder sensible Datenprozesse aufbauen möchten, sprechen Sie uns gerne an: info@geisten.com