Entscheidungsprotokoll für lokale Inferenz: Von der VRAM-Grenze zur Validierung der Netzwerkisolierung

Definition des Speicherbudgets: Gewichte, KV-Cache und Overhead

Der erste Schritt im Protokoll besteht darin, den tatsächlichen Speicherbedarf eines Modells zu bestimmen, der sich nicht nur auf die quantisierten Parameter beschränkt. Der gesamte erforderliche Speicher ist die Summe von vier unabhängigen Komponenten: den Modellgewichten, dem Key-Value-Cache (KV-Cache), den transienten Aktivierungen und dem Overhead des Inferenz-Frameworks.

Ein häufiger Fehler ist die Anwendung eines festen Aufschlags von 20 % auf die Gewichte, was ungenau ist, da diese Komponenten unterschiedlich skalieren. Beispielsweise belegen die Gewichte eines Modells mit 7 Milliarden Parametern bei der Quantisierung Q4_K_M etwa 4,9 GB (0,61 Byte pro Parameter, nicht 0,5 wie die vereinfachte 4-Bit-Formel nahelegt). Hinzu kommt der KV-Cache, der linear mit der Kontextlänge wächst. Für einen Kontext von 8.000 Tokens kann der KV-Cache je nach Aufmerksamkeitsarchitektur (GQA oder MHA) und Cache-Präzision (FP16 oder FP8) zwischen 1 und 2 GB zusätzlichen Speicher erfordern.

Die Speicherplanung sollte die Gewichte und die übrigen Anforderungen der Ausführung getrennt betrachten. Eine Datei kann auf den Datenträger passen, ohne dass die vorgesehene Inferenz vollständig in den verfügbaren GPU-Speicher passt. Kontext und Laufzeit gehören deshalb zur Prüfung derselben Konfiguration. Eine Schätzung dient der Vorauswahl, ersetzt aber nicht die Beobachtung des tatsächlichen Speicherbedarfs. Ebenso sollte ein einzelner erfolgreicher Aufruf nicht mit der Stabilität unter allen späteren Lastbedingungen verwechselt werden.

Für eine nachvollziehbare Entscheidung müssen die Annahmen der Schätzung sichtbar bleiben. Die gewählte Quantisierung, die Kontextlänge und die für die Anwendung relevante Last beschreiben unterschiedliche Teile des Bedarfs. Ändert sich eine dieser Bedingungen, kann eine frühere Messung ihre Aussagekraft verlieren. Der Vergleich sollte daher den Aufbau festhalten, unter dem er durchgeführt wurde. Das erlaubt es, einen Engpass gezielt zu untersuchen, statt aus einer unzureichenden Konfiguration auf die grundsätzliche Eignung oder Nichteignung des Modells zu schließen.

Auswahl der Quantisierung: Effektive Präzision vs. nominale Bits

Die Auswahl der Quantisierung sollte auf den effektiven Bits basieren, nicht auf dem Dateinamen. GGUF-Formate mischen Präzisionen: Q4_K_M entspricht etwa 4,9 effektiven Bits (0,61 Byte/Parameter), während Q8_0 8,5 Bits (1,06 Byte/Parameter) sind. Die Annahme von 4,0 Bits für Q4 führt zu einer Unterschätzung der Gewichte um etwa 20 %, was zu einer unzureichenden Hardwareauswahl führen kann.

Die Qualitätsdegradation variiert je nach Aufgabe. Q4_K_M bietet ein akzeptables Gleichgewicht für die meisten allgemeinen Anwendungsfälle, mit einer geschätzten Qualitätsverlust von 1 % bis 3 % im Vergleich zu FP16. Q5_K_M ist empfehlenswert, wenn zusätzliche VRAM verfügbar ist und höhere Präzision bei Reasoning oder Code erforderlich ist. Q8_0 kommt der Originalqualität nahe, verdoppelt aber den Speicherverbrauch im Vergleich zu Q4, weshalb es nur in High-End-Hardware oder für kritische Evaluierungsaufgaben sinnvoll ist.

Der Name eines Quantisierungsformats ist kein vollständiger Speicherbericht. Gemischte Präzisionen und zusätzliche Informationen sind ein Grund, tatsächliche Dateigröße und effektiven Bedarf statt nur einer nominalen Bitzahl zu betrachten. Gleichzeitig beantwortet eine kleinere Datei nicht die Qualitätsfrage. Die für das Projekt wichtigen Aufgaben müssen geprüft werden, insbesondere wenn Reasoning oder Code verwendet werden sollen. Ein beobachteter Kompromiss zwischen Speicher und Qualität gilt zunächst für diese Aufgaben und lässt sich nicht ohne Weiteres auf alle Ausgaben des Modells übertragen.

Die im Text genannten Größenordnungen des Qualitätsverlusts sind Orientierungen und keine zugesicherten Werte. Eine Prüfung sollte daher nicht lediglich bestätigen, dass das Modell startet, sondern die Antworten anhand der vorgesehenen Aufgaben beurteilen. Unterschiedliche Präzisionsstufen können unter denselben Kriterien verglichen werden. Dabei bleiben Speicherbedarf, Qualität und Laufzeit eigenständige Messgrößen. Mehr verfügbarer Speicher macht eine höhere Präzision nicht automatisch notwendig; weniger Speicher rechtfertigt umgekehrt keine unzureichende Qualität für die tatsächliche Anwendung.

Konfiguration des Inferenz-Runtimes: Ollama, LM Studio oder vLLM

Die Auswahl des Inferenz-Engines hängt von der Arbeitslast ab. Für einen einzelnen Benutzer auf einem Desktop-PC sind Ollama und LM Studio (basierend auf llama.cpp) in der Leistung vergleichbar und bieten eine OpenAI-kompatible API auf dem Localhost. Ollama sticht durch seine Benutzerfreundlichkeit und die Modellverwaltung mit einem einzigen Befehl hervor, während LM Studio eine umfassendere grafische Oberfläche für Experimente bietet.

Für Produktionsumgebungen mit mehreren gleichzeitigen Benutzern ist vLLM überlegen, da es paginierte Aufmerksamkeit und kontinuierliches Batching verwendet. In Concurrent-Benchmarks kann vLLM unter hoher Last bis zu 44-mal mehr Tokens pro Sekunde liefern als llama.cpp. Für einen einzelnen Benutzer ist der Unterschied jedoch minimal, daher sollte die Auswahl die Auditierbarkeit und die Integration in den bestehenden Workflow priorisieren.

Bei der Laufzeitwahl sind Bedienung, Integration und Durchsatz getrennte Anforderungen. Eine grafische Oberfläche kann zu einem anderen Arbeitsablauf passen als ein Dienst für viele gleichzeitige Anfragen. Der beschriebene Durchsatzvergleich mit vLLM bezieht sich auf die genannten Testbedingungen, nicht auf jede mögliche Installation. Für die eigene Entscheidung sollte der Aufbau wiederholbar sein und die benötigten Einstellungen nachvollziehbar machen. Weder ein bekanntes Werkzeug noch eine bestimmte API-Schnittstelle ersetzt die Prüfung, ob die Anwendung mit der gewählten Konfiguration tatsächlich funktioniert.

Ein einfacher Funktionstest hat einen engeren Zweck als eine vollständige Leistungsbewertung. Er kann zeigen, ob eine Anfrage unter der verwendeten Konfiguration verarbeitet wird und ob die Antwort in der vorgesehenen Anwendung ankommt. Daraus lässt sich noch keine Aussage über alle Lasten, Antwortzeiten oder Fehlersituationen ableiten. Solche weiteren Fragen sollten als eigene Prüfungen benannt werden. Diese Trennung verhindert, dass ein erfolgreicher Start des lokalen Dienstes als Beleg für seine allgemeine Produktionsreife dargestellt wird.

Audit der Netzwerkisolierung: Validierung der Privatsphäre

Die Netzwerkisolierung ist eine Sicherheitsstrategie, die darin besteht, das Netzwerk in unabhängige Segmente zu unterteilen, um unbefugten Zugriff oder Datenlecks zu verhindern. Im Kontext der lokalen Inferenz ist das Ziel sicherzustellen, dass der Inferenzprozess keine unbefugten ausgehenden Verbindungen herstellt und die Daten innerhalb der vom Operator kontrollierten Jurisdiktion bleiben.

Um die Isolierung empirisch zu überprüfen, sollten Traffic-Monitoring-Tools wie Wireshark oder tcpdump verwendet werden, um die Verbindungen des Inferenzprozesses zu erfassen. Zusätzlich können Firewall-Regeln konfiguriert werden, um den gesamten ausgehenden Traffic zu blockieren, mit Ausnahme der erforderlichen Verbindungen (falls vorhanden). In Unternehmensumgebungen entspricht dies den Praktiken der verwalteten Netzwerkisolierung, bei der der ausgehende Zugriff über Private Endpoints und Service Tags gesteuert wird.

Lokale Ausführung und Netzwerkisolierung sind unterschiedliche Eigenschaften. Der Ort der Inferenz allein beantwortet nicht, welche Verbindungen die beteiligten Programme tatsächlich aufbauen oder welche Daten sie austauschen. Die Isolierung muss deshalb anhand der vorgesehenen Umgebung geprüft werden und darf nicht aus dem Wort lokal abgeleitet werden. Auch die Integrität heruntergeladener Artefakte ist eine eigene Frage. Ein passender Hash kann die Dateigleichheit bestätigen, aber keine allgemeine Aussage über Datenschutz, Sicherheit oder Ausgabequalität des gesamten Systems liefern.

Validierung der Artefakt-Integrität und Smoke-Test

Bevor das Modell in den Workflow integriert wird, ist es entscheidend, die Integrität des heruntergeladenen Artefakts zu überprüfen. Dies umfasst den Vergleich der Prüfsumme (Checksum) der GGUF- oder Safetensors-Datei mit der vom Anbieter oder der Community veröffentlichten Version. Eine Abweichung deutet auf mögliche Beschädigung oder Manipulation der Datei hin.

Nach der Validierung der Integrität muss ein minimaler Smoke-Test durchgeführt werden: Eine einfache Antwort generieren, um zu bestätigen, dass das Modell korrekt in den Speicher geladen wird und kohärente Ausgaben erzeugt. Dieser Test sollte in einem netzwerkisolierten Umfeld durchgeführt werden, um das Privacy-Audit nicht zu gefährden. Wenn der Test fehlschlägt, muss die Kompatibilität zwischen Quantisierung, Runtime und Hardware überprüft werden, bevor fortgefahren wird.

Eine belastbare Auswahl hält fest, welche Anforderungen der lokale Aufbau erfüllen soll und was die Prüfung tatsächlich gezeigt hat. Speichergrenzen, Quantisierung, Laufzeit und Isolation sind dabei miteinander verbunden, ersetzen einander aber nicht. Wenn eine Konfiguration einen benötigten Punkt nicht erfüllt, sollte die Ursache beschrieben und eine Alternative unter denselben Kriterien untersucht werden. Auf diese Weise bleibt der Vergleich an der Aufgabe orientiert, ohne einen einzelnen Benchmark oder eine erfolgreiche Demonstration als universelle Empfehlung für jede Hardware und jeden Einsatz zu behandeln.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.