Schlank, sicher, performant: Bestandsaufnahme eines ThinkPads unter Arch Linux

Wer einen Rechner dauerhaft laufen lässt und gleichzeitig lokale Modelle darauf betreibt, kennt die Versuchung: irgendwo eine Schraube drehen, irgendwas abschalten, irgendwas nachinstallieren. Ich habe es umgekehrt gemacht. Erst gemessen, alles nur lesend, nichts verändert. Dieser Text ist die Bestandsaufnahme, Stand September 2026, aufgenommen auf meinem ThinkPad.

Die Maschine

Ein ThinkPad mit Intel Core i7-8565U, acht Threads, 15 GB RAM, Intel UHD 620 ohne dedizierte Grafikkarte, Arch Linux mit Kernel 7.2.6. Auf der Prozessorseite gibt es AVX2, aber kein AVX-512. Das ist genau die Klasse Hardware, auf der lokale Inferenz interessant wird, weil sie ohne Beschleuniger auskommen muss.

Wichtig für alles Weitere: Der Rechner läuft als Arbeits- und Server-Maschine gleichzeitig. Der Desktop ist ständig offen, im Hintergrund laufen Dienste, und wenn ein Modell geladen ist, konkurrieren alle drei um denselben Speicher.

Wo der Speicher wirklich hingeht

Der erste Blick gilt dem Gesamtbild. Im Leerlauf standen rund 11 GB als verfügbar zur Verfügung, der Rest war Cache, nicht Verbrauch. Als Swap läuft zram mit zstd-Kompression, also komprimierter Speicher im RAM statt einer Auslagerungsdatei auf der Platte. Im Messlauf wurden aus 1 GB hineingeschriebenen Daten rund 300 MB komprimiert belegt, ein Verhältnis von ungefähr drei zu eins.

Das ist die erste Erkenntnis der Bestandsaufnahme: Die Speicherkonfiguration war schon richtig. Wer hier noch eine Swap-Partition auf die NVMe legt, gewinnt nichts, sondern verliert Latenz und Schreiblast.

Der größte Einzelverbraucher im Leerlauf war nicht der Desktop, sondern der Dateiindexer von KDE: rund 680 MB für einen Volltextindex über das gesamte Home-Verzeichnis, das zu großen Teilen aus einem 72-GB-Arbeitsverzeichnis besteht. Für die Suche in Dateien brauche ich diesen Dauerindex nicht, weil fd und ripgrep dieselbe Frage in Millisekunden direkt beantworten, ohne etwas im Hintergrund zu halten. Das ist der klassische Fall: eine Komponente, die für einen Komfortfall gebaut ist und dabei dauerhaft Speicher bindet.

Zweiter Fund: zwei Prozesse einer Browser-Automatisierung, die seit einer früheren Sitzung weiterliefen, ohne dass gerade etwas automatisiert wurde. Keine Autostart-Unit, sondern ein Leck. Solche Funde sind der Grund, warum ich vor dem Optimieren erst inventarisiere.

Der eigentliche Engpass

Im Leerlauf war die Maschine entspannt. Interessant wird es, sobald ein Modell lädt. Der Speicherbedarf beim Betrieb eines lokalen Modells ist nicht das Modell selbst, sondern der Zwischenspeicher für den Kontext. Der wächst mit jeder zusätzlichen Textmenge, die das Modell gerade verarbeiten muss.

Daraus folgen die drei Hebel, die tatsächlich etwas bringen, alle reversibel und alle ohne neue Software:

Der erste ist die Quantisierung dieses Zwischenspeichers. Wird er mit geringerer Genauigkeit gehalten, sinkt der Speicherbedarf deutlich, bei moderatem Qualitätsverlust. Der zweite ist die Kontextlänge: Der Standardwert ist meist großzügiger gewählt, als die eigene Nutzung verlangt. Der dritte ist die Thread-Zahl. Bei acht Threads sollte die Inferenz nicht zwingend alle acht belegen, weil der Desktop daneben noch arbeiten will; in der Regel ist eine Stelle unter dem Maximum der bessere Kompromiss.

Dasselbe gilt fürs Thermostat. Die Temperatur war unter Last und im Leerlauf unauffällig, Lüfter im Leerlauf aus, thermald und die Sensor-Auslese aktiv. Deshalb steht hier keine Drosselungsempfehlung: Wenn die Werte stimmen, ist jeder Eingriff an den Leistungszuständen ein Risiko ohne Gewinn.

Timer, Logs, Ballast

Auf dem System liefen 21 Systemd-Timer für Benutzerprozesse, der Großteil davon für dieselbe Automatisierung. Timer selbst kosten keinen Speicher, aber sie können sich überlappen: drei Jobs in derselben Minute bedeuten drei Prozesse gleichzeitig, die um dieselbe CPU konkurrieren, gerade wenn ein Modell läuft. Die Abhilfe kostet nichts und ist sofort umkehrbar: Startzeiten versetzen, damit die Last verteilt anfällt statt in Stößen.

Ähnlich unspektakulär ist die Log-Frage. Ohne Rotation wachsen Protokolldateien über Monate unbegrenzt. Eine einfache Regel, die eine Datei ab einer Größenschwelle wegpackt, verhindert das ohne jede weitere Abhängigkeit.

Container und Paket-Isolation habe ich ebenfalls durchgezählt. Es lief genau ein Container, für die lokale Suche, ohne Rückstände und ohne Build-Cache. Dafür kostet die Container-Laufzeit selbst Startzeit. Für einen einzigen Dienst ist das eine bewusste Entscheidung, kein Fehler, aber man sollte sie kennen. Ähnlich bei den isolierten Anwendungen: gut drei Gigabyte Datenbestand für 14 Anwendungen, darunter mehrere Browser, die sich Aufgaben teilen. Hier ist die Konsolidierung der ehrlichere Weg als jede Cache-Kosmetik.

Aufgeräumt war an anderer Stelle dagegen schon alles: keine verwaisten Pakete, keine Reste entfernter Virtualisierungswerkzeuge, keine zurückgebliebenen Anwendungsprofile. Ein einzelnes Kommandozeilen-Werkzeug blieb bewusst liegen, obwohl die zugehörige grafische Anwendung entfernt wurde. Auch das ist ein Ergebnis: nicht alles, was übrig ist, ist Müll.

Dateien lesbar machen, ohne die Cloud

Der zweite Schwerpunkt war Offline-Arbeit an Dokumenten. Die Frage: Wie kommt der Text aus einem PDF, einem Word-Dokument, einem Scan oder einer Audiodatei heraus, ohne dass irgendetwas nach außen geht? Die Antwort war kürzer als erwartet, weil die meisten Werkzeuge bereits installiert sind.

Was fehlte, war ebenfalls unaufgeregt nachinstallierbar, ausschließlich aus dem offiziellen Paketbestand: Werkzeuge für alte Word- und RTF-Dateien, für OpenDocument ohne die große Suite und für HTML als Text. Nur ein E-Book-Konverter liegt außerhalb der offiziellen Paketquellen und ist damit nachrangig, weil er für die eigentliche Aufgabe, Text herauszuziehen, nicht gebraucht wird.

Praktisch dazu gehört eine Gewohnheit, die ich inzwischen fest eingebaut habe: Zu jeder Konvertierung wird ein Beipackzettel geschrieben, mit Quelldatei, Prüfsumme, verwendetem Werkzeug samt Version, Zeitstempel und der Prüfsumme des Ergebnisses. Damit lässt sich später belegen, dass ein Text tatsächlich aus der Datei stammt, die behauptet wird, und mit welchem Werkzeug er erzeugt wurde. Das kostet drei Standardbefehle und erspart die Frage, welcher der fünf Entwürfe denn nun der weiterverarbeitete war.

Reversibel zuerst

Wenn ich aus so einer Bestandsaufnahme Maßnahmen ableite, gibt es eine feste Reihenfolge. Zuerst die Eingriffe, die nichts kosten und sofort rückgängig zu machen sind: Startzeiten versetzen, Log-Rotation, einen Prozess beenden, der ohnehin nicht gebraucht wird. Danach die Änderungen, die man messen muss und nur mit vorheriger Sicherung angeht, etwa das Zurückschreiben freigewordenen Platzes in einer Datenbank. Und am Ende, wenn überhaupt, die Änderungen an der Struktur, weil sie die Wirkung haben, die man am schlechtesten vorhersagen kann.

Der Maßstab für jede einzelne Maßnahme war derselbe: Was kostet sie, was bringt sie, und wie komme ich zurück, wenn ich falsch liege. Eine Optimierung, für die es keine Rückkehr gibt, ist keine Optimierung, sondern ein Umbau.

Was dabei herauskommt

Der Rechner war nicht kaputt und nicht überladen. Die Speicherkonfiguration war bereits richtig gewählt, die Thermalwerte waren unauffällig, aufgeräumt war ebenfalls. Die Funde lagen woanders: bei einem Dauerindex, den man durch zwei Kommandozeilenwerkzeuge ersetzt, bei Prozessleichen, bei der Verteilung von Lastspitzen und bei der Frage, wie viel Kontext ein Modell tatsächlich braucht.

Genau das ist der Punkt. Wer schlank, sicher und schnell will, muss nicht jeden Dienst abschalten, sondern wissen, welcher Dienst was kostet. Diese Liste kennt niemand aus dem Handbuch. Man bekommt sie nur, wenn man den eigenen Rechner einmal in Ruhe vermisst, alles andere stehen lässt und erst danach entscheidet.