LLMs 101: Ein praktischer Leitfaden (Ausgabe 2026)

Starten Sie mit der Schleife. Text wird zu Tokens. Tokens bewegen sich durch einen Transformer. Die Aufmerksamkeit entscheidet, welche früheren Tokens relevant sind. Die Laufzeitumgebung führt einen KV-Cache, damit das Modell nicht jedes Mal die gesamte Konversation neu berechnen muss. Dann wählt das Modell den nächsten Token aus und wiederholt den Vorgang.

Ein praktischer Leitfaden zur Funktionsweise von LLMs, wie Modelle 1 Token nach dem anderen denken und wie man sie lokal ausführt.

Sobald diese Schleife verstanden ist, werden die Hardware- und Software-Entscheidungen leichter nachvollziehbar. VRAM, Quantisierung, Kontextlänge, Chat-Templates, Decoding, RAG, Serving-Engines und die Modellauswahl ergeben sich alle aus denselben Mechanismen.

Beginnen Sie mit der Schleife: Tokens rein, Wahrscheinlichkeiten raus, immer ein nächster Token nach dem anderen. Die Gewichte sagen dem Modell, welche Muster es gelernt hat. Der Kontext sagt ihm, was es gerade betrachtet. Der KV-Cache ist der Arbeitsspeicher, der die Schleife nutzbar macht. Hardware, Laufzeitumgebungen und Modellauswahl ergeben nur Sinn, wenn man die Speicher-, Kontext- und Formatierungsregeln versteht, denen das Modell folgt.

Das Ziel ist es, die Mechanik lokaler LLMs zunächst intuitiv verständlich zu machen und Ihnen dann einen praktischen Einstieg in Hardware, Laufzeitumgebungen, Serving und die aktuelle LLM-Forschung (Stand 21. Mai 2026) zu geben.

Fokus

Dies ist ein modellzentrierter Leitfaden. Er beginnt mit der Mechanik: Inferenz, Tokens, Transformer, Aufmerksamkeit, KV-Cache, Prefill, Decode, Decoding-Steuerung, Modellpakete, Chat-Templates, Modelltypen, langer Kontext, RAG, Agents, Fine-Tuning und multimodale Modelle.

Danach geht es zur lokalen Bereitstellungsebene über: Was lokal wirklich bedeutet, Quantisierung, VRAM-Berechnung, Hardware-Stufen, Runtime-Optionen, Serving-Modi, Lizenzen, Modellauswahl, Datenschutz, Fehlerbehebung, Benchmarks, Einrichtungspfade und praktische Anwendungsfälle.

Diese Reihenfolge ist wichtig. Sie sollten verstehen, warum eine lange Eingabeaufforderung Speicher kostet, bevor Sie eine GPU auswählen. Sie sollten verstehen, warum Chat-Templates wichtig sind, bevor Sie ein Modell bewerten. Sie sollten verstehen, warum Decode sequentiell ist, bevor Sie sich um Tokens pro Sekunde kümmern.

Für den tiefergehenden Hardware- und Software-Pfad habe ich eine dreiteilige Serie zum Thema Self-Hosted LLMs / Local AI:

• Teil 1: GPU Memory Math für LLMs (Ausgabe 2026).
• Teil 2: Memory Bandwidth für Local AI Hardware (Ausgabe 2026).
• Teil 3: Inference Engines für LLMs & Local AI Hardware (Ausgabe 2026).

Die ersten beiden Teile erklären die Mathematik der Hardware-Kapazität und -Bandbreite. Der dritte Teil erklärt die Software-Ebene, die diese Hardware in nutzbare Inferenz verwandelt. Dieser Artikel gibt Ihnen zuerst die modellseitige Grundlage und verweist dann auf diese Bereitstellungsebenen zurück, sobald die Mechanik klar ist.

Was ein LLM eigentlich tut

Das Ausführen eines Modells wird Inferenz genannt. Bei einem standardmäßigen, nur aus Decodern bestehenden LLM ist die Inferenz dieselbe, immer wieder wiederholte Schleife:

1. Wandeln Sie Ihren Text in Tokens um.
2. Füttern Sie diese Tokens in das Modell.
3. Berechnen Sie Bewertungen für jeden möglichen nächsten Token.
4. Wählen Sie mit einer Decoding-Strategie einen Token aus.
5. Hängen Sie diesen Token an die Sequenz an.
6. Wiederholen Sie den Vorgang, bis das Modell anhält, der Benutzer es anhält oder ein Token-Limit erreicht ist.

Das Modell schreibt nicht die gesamte Antwort auf einmal. Es erzeugt einen Token nach dem anderen. Jeder neue Token wird Teil der Sequenz, die den nächsten Token beeinflusst.

Mathematisch gesehen ist das Modell eine erlernte Funktion:

f(theta, sequenz) -> Wahrscheinlichkeitsverteilung über next_token

Wobei:

• theta die Modellgewichte bedeutet.
• sequenz die Eingabeaufforderung plus die bisher erzeugten Tokens bedeutet.
• Logits die Rohbewertungen vor dem Softmax sind.
• Wahrscheinlichkeiten die normalisierten Bewertungen nach dem Softmax sind.
• Decoding diese Wahrscheinlichkeiten in einen ausgewählten Token umwandelt.

Aus diesem Grund wird die lokale Generierungsgeschwindigkeit in Tokens pro Sekunde gemessen. Ihr System führt wiederholt einen Vorwärtsdurchlauf durch, wählt oder sampelt einen Token, aktualisiert den KV-Cache und fährt fort.

Die Wahrnehmung spielt hier eine Rolle. Ein langer Prefill bedeutet eine lange Pause, bevor das erste Wort erscheint. Langsames Decode bedeutet, dass die Antwort langsam gestreamt wird. Lokale Entwickler konzentrieren sich oft auf die Decode-Geschwindigkeit, weil sie der Benutzer spürt, aber die Prefill-Zeit tut weh, wenn Sie ein 10.000-Token-Dokument einfügen.

Tokens

LLMs sehen Rohtext nicht als Wörter. Sie sehen Tokens: Kleine Textstücke, die intern als Ganzzahl-IDs repräsentiert werden.

Ein Token kann sein:

• Ein ganzes Wort: "Hallo"
• Ein Wortfragment: "Inter", "national", "isierung"
• Ein Satzzeichen
• Eine Zeichenkette mit führendem Leerzeichen
• Ein Byte-Level-Fallback
• Ein spezielles Steuerungsmarker wie <|user|>, <|assistant|>, oder

Der Tokenizer bildet Text auf Token-IDs und Token-IDs zurück auf Text ab. Übliche Tokenizer-Familien sind BPE-basierte Tokenizer und SentencePiece-basierte Tokenizer. Verschiedene Modellfamilien verwenden unterschiedliche Tokenizer, und das ist wichtig. Ein 4.000-Wörter-Dokument kann in einem Tokenizer 5.000 Tokens und in einem anderen 7.500 Tokens ergeben.

Auch die Vokabulargröße ist wichtig. Ein Tokenizer mit einem größeren Vokabular kann etwas Text in weniger Tokens komprimieren, verändert aber auch die Größe der Einbettungs- und Ausgabeprojektion. Dies ist ein Grund, warum Tokens pro Sekunde nicht perfekt über Modellfamilien hinweg vergleichbar sind.

Tokens sind wichtig, weil sie bestimmen:

• Wie viel Text in das Kontextfenster passt.
• Wie groß der KV-Cache wird.
• Wie viel Latenz Sie während der Eingabeaufforderungsverarbeitung zahlen.
• Ob mehrsprachiger oder code-lastiger Text effizient ist.
• Ob das Modell spezielle Chat-Marker korrekt sieht.

Das Kontextfenster eines Modells ist die maximale Anzahl von Tokens, die es gleichzeitig beachten kann. Im Jahr 2026 reichen übliche lokal lauffähige Modelle von 8K- und 32K-Kontexten bis zu 128K, 256K und sogar 1M-Token-Kontexten in serverbasierten Systemen.

Aber die unterstützte Kontextlänge ist nicht dasselbe wie ein günstiger, schneller oder gleich genauer Kontext. Ein Modell, das technisch 128K Tokens verarbeiten kann, kann bei 64K deutlich langsamer werden und bei 100K an Kohärenz verlieren. Testen Sie immer die Kontextlängen, die Sie tatsächlich verwenden möchten.

Tokens sind die Arbeitseinheit. Sobald Sie das verstanden haben, wirkt langer Kontext nicht mehr magisch, sondern wie eine Rechnung, die Sie abschätzen können.

Hilfreiche Übung: Probieren Sie meine Tokenizer-Demo-App aus, um in Echtzeit zu sehen, wie Text in Tokens zerlegt wird.

Transformer

Die meisten modernen LLMs basieren auf der Transformer-Architektur. Die meisten lokalen Chat-LLMs sind reine Decoder-Transformer: Sie sagen den nächsten Token voraus, während sie auf frühere Tokens zurückblicken.

Alles oberhalb dieses Punktes, einschließlich Tokens, Gewichten, Konfiguration und Chat-Templates, ist das Setup für die eigentliche darunterliegende Engine. Der Transformer ist das Skelett, das die Zahlen bewegt.

Eine vereinfachte Transformer-Schicht enthält:

1. Token-Embeddings: Token-IDs werden zu Vektoren.
2. Positionsinformationen: Das Modell benötigt die Token-Reihenfolge. Viele moderne LLMs verwenden RoPE (Rotary Position Embeddings), das die Position durch Rotation von Repräsentationen codiert.
3. Self-Attention: Jede Token-Repräsentation blickt auf frühere Token-Repräsentationen zurück und entscheidet, was wichtig ist.
4. MLP / Feed-Forward-Block: Eine dichte nichtlineare Berechnung, die Repräsentationen erweitert und komprimiert. Ein großer Teil der Parameter befindet sich hier.
5. Layer-Normalisierung und residuelle Verbindungen: Diese stabilisieren tiefe Netzwerke und helfen Informationen, durch viele Schichten zu fließen.
6. Ausgabeprojektion: Der finale Hidden State wird zu Logits über das Vokabular.

Stapeln Sie dieses Rezept dutzende oder hunderte Male und Sie erhalten ein Sprachmodell.

Transformer-Zusammenfassung: Tokens werden zu Vektoren, Aufmerksamkeit verbindet die Sequenz, MLPs formen die Repräsentation um, RoPE hält die Position gerade, und die finale Projektion verwandelt den letzten Hidden State in Logits für den nächsten Token.

Aufmerksamkeit

Aufmerksamkeit ist, wie ein Token entscheidet, welche früheren Tokens für die nächste Vorhersage wichtig sind. Sie ist auch einer der Gründe, warum lokale Inferenz so speichersensitiv ist.

Klassisches MHA (Multi-Head Attention) speichert separate Key/Value-Zustände für viele Köpfe. Es gibt dem Modell Flexibilität, macht aber den KV-Cache groß.

Moderne lokale Modelle verwenden oft effizientere Aufmerksamkeitsdesigns:

• MQA: Mehrere Query-Köpfe teilen sich einen Key/Value-Kopf. Es ist speichereffizient, kann aber weniger ausdrucksstark sein.
• GQA: Gruppen von Query-Köpfen teilen sich Key/Value-Köpfe. Es ist der übliche Mittelweg in vielen aktuellen lokalen Modellen.
• MHA: Vollständige Multi-Head Attention. Es kann leistungsstark sein, aber langer Kontext wird schnell teuer.

Moderne Kernel wie FlashAttention und SDPA-ähnliche Implementierungen reduzieren den Speicherverkehr der Aufmerksamkeit und halten die GPU besser ausgelastet. Eine Laufzeitumgebung mit guten Aufmerksamkeitskernels kann dramatisch schneller sein als eine ohne, selbst auf demselben Modell und derselben Hardware.

Aus diesem Grund können sich zwei 7B-Modelle bei langem Kontext sehr unterschiedlich verhalten. Die Parameteranzahl ist nicht die ganze Geschichte. Ein 7B-MHA-Modell mit 128K-Kontext kann eine 24-GB-GPU erschöpfen, während ein 7B-GQA-Modell mit demselben beworbenen Kontext mit Platzreserve passen kann.

Vergleichen Sie beim Modellvergleich nicht nur die Parameteranzahl, sondern auch den Aufmerksamkeitstyp, die KV-Köpfe, die Kontextlänge und die Runtime-Unterstützung.

KV-Cache

Der KV-Cache ist der Arbeitsspeicher des Modells während der Generierung. Er speichert Key/Value-Aufmerksamkeitszustände für frühere Tokens, damit das Modell nicht die gesamte Historie bei jedem generierten Token von Grund auf neu berechnen muss.

Ohne KV-Cache wäre die Generierung brutal ineffizient. Mit KV-Cache ist die Generierung nutzbar, aber der Cache verbraucht Speicher proportional zu:

Tokens x Schichten x kv_heads x head_dim x Genauigkeit x 2

Das x 2 steht für Keys und Values.

Eine nützliche Faustregel für ältere Llama-ähnliche 7B-MHA-Modelle ist etwa 0,5 MiB pro Token im FP16-KV-Cache. Das bedeutet, dass 4K Tokens etwa 2 GiB allein für den KV-Cache kosten können. Bei 32K Tokens könnten Sie 16 GiB nur für den KV-Cache benötigen.

Neuere GQA/MQA-Modelle reduzieren dies erheblich. Einige Laufzeitumgebungen unterstützen auch FP8- oder INT8-KV-Cache. Das ist oft die praktische Kompressionsuntergrenze, die ich für lokale Benutzer im Jahr 2026 empfehlen würde.

Behandeln Sie sub-8-Bit-KV-Cache nicht als Standard. Forschungssysteme wie KIVI, KVQuant und neuere komprimierte Cache-Kernel zeigen, dass 2-Bit- bis 4-Bit-KV mit sorgfältigen Algorithmen, Kalibrierung und benutzerdefinierten Kernels funktionieren kann. Das ist nicht dasselbe wie das beiläufige Aktivieren eines Q4-KV-Toggles in einer Desktop-Runtime. Unterhalb von 8 Bit sollten Sie aufwendig benchmarken, insbesondere für Codierung, Tool-Aufrufe, JSON, Langkontext-Retrieval und Aufgaben, bei denen exakte frühere Tokens wichtig sind.

Verwechseln Sie auch die KV-Cache-Quantisierung nicht mit spekulativem Decoding. DFlash und DDTree, oft informell zu DTree verkürzt, bekämpfen die Decode-Latenz, indem sie zukünftige Tokens entwerfen und verifizieren. Sie können die Geschwindigkeit verbessern, löschen aber nicht die Speicherrechnung des KV-Cache.

Aus diesem Grund kann ein Modell bei einer leeren Eingabeaufforderung passen, aber abstürzen, wenn Sie ein langes Dokument laden. Die Gewichte passen. Der Arbeitsspeicher tat es nicht.

Prefill und Decode

Die LLM-Inferenz hat zwei unterschiedliche Leistungsregime: Prefill und Decode.

Prefill verarbeitet die Eingabeaufforderung, die Sie dem Modell gegeben haben. Wenn Sie ein 20.000-Token-Dokument einfügen, muss das Modell diese 20.000 Tokens verarbeiten, bevor es den ersten Antwort-Token erzeugen kann. Prefill ist relativ parallelisierbar, sodass GPUs es effizient handhaben können, aber es kann trotzdem teuer sein.

Die Zeit, die Sie auf das Erscheinen des ersten Tokens warten, ist normalerweise die Prefill-Zeit.

Decode erzeugt neue Tokens einzeln. Jeder erzeugte Token hängt von der bisherigen Sequenz ab, daher ist Decode viel sequentieller. Hier kommt der Streaming-Tipp-Effekt her, und es ist normalerweise die Phase, die bestimmt, ob sich ein Modell schnell oder langsam anfühlt.

Lange Eingabeaufforderungen bestrafen Prefill. Lange Antworten bestrafen Decode. Lange Konversationen bestrafen beides, weil der KV-Cache wächst.

In einer Chat-Sitzung fügt jede Runde zum Cache hinzu. Wenn Sie eine Konversation auf 16K Tokens laufen lassen, zahlen Sie die Speicherkosten für alle 16K Tokens bei jedem neu generierten Token. Aus diesem Grund werden Chat-Oberflächen, die eine unendliche Historie behalten, irgendwann langsamer oder stürzen ab.

Decoding

Nachdem das Modell Logits erzeugt hat, hat es noch nichts geschrieben. Es hat nur jeden möglichen nächsten Token bewertet. Decoding ist die Strategie, die diese Bewertungen in einen tatsächlichen Token umwandelt, diesen Token an den Kontext anhängt und die Schleife wiederholt.

Die Laufzeitumgebung oder Inference Engine kann Tokens auf verschiedene Weise auswählen. Sie kann jedes Mal den Token mit der höchsten Wahrscheinlichkeit wählen. Sie kann aus einer eingeschränkten Menge wahrscheinlicher Tokens sampeln. Sie kann Wiederholungen bestrafen. Sie kann an einem Trennzeichen anhalten. Sie kann einen festen Seed verwenden, sodass dieselbe Eingabeaufforderung reproduzierbar reagiert.

Diese Entscheidungen ändern nicht die Modellgewichte, aber sie verändern die Stimme des Modells, seine Determiniertheit, Kreativität, sein Risikoprofil und seine Neigung zur Schleifenbildung.

Die wichtigen Stellschrauben beantworten drei praktische Fragen:

• Zufälligkeit: Wie viel Variation ist erlaubt?
• Tail-Reach: Wie weit in Tokens mit niedrigerer Wahrscheinlichkeit kann der Sampler gehen?
• Grenzen: Was verhindert Schleifen, Abschweifungen, Schema-Brüche oder ausufernde Ausgaben?

Für präzise Arbeiten beginnen Sie eng: niedrige Temperatur, kurze Max-Token-Limits, explizite Stop-Sequenzen und eingeschränktes Decoding, wenn die Ausgabe JSON oder einem Schema entsprechen muss. Für kreative Arbeiten geben Sie dem Sampler mehr Spielraum mit höherer Temperatur, Top-p und mehreren Kandidaten, die anschließend eingestuft werden. Für Codierung halten Sie den ersten Durchlauf konservativ, sampeln Sie Alternativen nur, wenn Sie absichtlich explorieren.

Gieriges Decoding ist nicht immer genauer. Es ist oft spröde. Ein gieriger Decoder kann in Schleifen stecken bleiben oder generische Antworten produzieren, weil er nie Alternativen erkundet. Für Evaluierungen verwenden Sie deterministische Einstellungen. Für Ideenfindung lassen Sie dem Modell Raum zum Atmen.

Was ein Modellpaket enthält

Ein ausführbares lokales LLM ist mehr als nur eine große Gewichtsdatei. Ein Modellpaket enthält normalerweise:

• Architektur/Konfiguration: Anzahl der Schichten, Hidden Size, Aufmerksamkeitstyp, RoPE-Einstellungen, Vokabulargröße, spezielle Tokens und Kontextlänge.
• Gewichte: Die gelernten Parameter, oft gespeichert als safetensors, GGUF, GPTQ, AWQ, EXL2 oder einem anderen laufzeitspezifischen Format.
• Tokenizer: Die Regeln, die Text in Token-IDs und Token-IDs zurück in Text umwandeln.
• Chat-Template: Das genaue Markup für System-, Benutzer-, Assistenten-, Tool- und Reasoning-Nachrichten.
• Generierungskonfiguration: Standardwerte für Temperatur, Top-p, Stop-Tokens, Wiederholungsstrafen und maximale Tokens.
• Lizenz und Model Card: Die rechtlichen und betrieblichen Anweisungen, wie das Modell verwendet werden kann.

Die Gewichte sind die größte Datei, aber sie sind nicht das gesamte Modell. Wenn der Tokenizer, die Konfiguration oder das Chat-Template falsch ist, können sich dieselben Gewichte defekt anfühlen.

Der Paketabschnitt sagt Ihnen, was zusammen reisen muss. Der nächste Abschnitt erklärt, warum das Chat-Template der Teil ist, den Leute am häufigsten kaputt machen.

Chat-Templates

Ein Chat-Modell wurde mit einem bestimmten Konversationsformat trainiert. Zum Beispiel könnte es so etwas erwarten:

<|system|> Sie sind ein hilfsbereiter Assistent. <|user|> Erklären Sie den KV-Cache. <|assistant|>

Ein anderes Modell könnte erwarten:

[BOS] [INST] Erklären Sie den KV-Cache. [/INST]

Ein anderes könnte ChatML-ähnliche Marker verwenden. Ein anderes könnte spezielle Reasoning-Tokens erfordern. Ein anderes könnte Tool-Call-XML- oder JSON-Wrapper benötigen.

Die Verwendung des falschen Formats kann zu Kauderwelsch, Rollenverwirrung, ignorierten Systemaufforderungen, wiederholten Eingabeaufforderungen, seltsamen Verweigerungen, kaputten Tool-Aufrufen, schlechten Benchmark-Ergebnissen und der Schlussfolgerung führen, dass das Modell dumm ist, obwohl das Template der eigentliche Fehler ist.

Bewährte Vorgehensweise:

• Verwenden Sie die apply_chat_template des Tokenizers, wenn Sie Transformers verwenden.
• Verwenden Sie modellspezifische Templates in Harbor-gestützten Frontends, llama.cpp, LM Studio, vLLM oder SGLang.
• Überprüfen Sie, ob das Modell Base, Instruct, Chat, Reasoning oder Tool-getuned ist.
• Stellen Sie sicher, dass BOS/EOS-Tokens korrekt sind.
• Halten Sie Systemaufforderungen kurz, es sei denn, sie müssen lang sein.
• Befolgen Sie für die Tool-Nutzung exakt das vom Modell/Runtime erwartete Schema.

Wenn Sie eine Anwendung erstellen, die es Benutzern erlaubt, Modelle zu wechseln, benötigen Sie auch Template-Wechsel. Ein Template-Format fest zu codieren und dann ein Modell zu laden, das ein anderes erwartet, ist eine häufige Quelle für schlechte lokale Modell-Evaluierungen.

Behandeln Sie das Template wie einen API-Vertrag. Wenn Sie es falsch machen, testen Sie nicht wirklich das Modell, von dem Sie glauben, dass Sie es testen.

Modelltypen

Nicht alle LLMs sind auf das gleiche Verhalten abgestimmt.

Für die meisten Benutzer sollte der Standardausgangspunkt ein aktuelles Instruct-/Chat-getuntes Modell in einer Größe sein, die bequem in den Speicher passt.

Beginnen Sie nicht mit einem Base-Modell, es sei denn, Sie wissen warum. Base-Modelle vervollständigen Ihre Eingabeaufforderung, anstatt sie zu beantworten. Sie sind nützlich für Forscher, Fine-Tuner und Leute, die benutzerdefinierte Pipelines bauen. Sie sind für alle anderen frustrierend.

Wenn Sie ein Base-Modell fragen: Was ist die Hauptstadt von Frankreich?, könnte es mit und wie hoch ist die Bevölkerungszahl von Paris? fortfahren, anstatt Paris zu antworten.

Der praktische Unterschied ist einfach:

• Base-Modell: Gut für Pretraining-Forschung, Fine-Tuning und benutzerdefinierte Pipelines.
• Instruct-Modell: Gut für die direkte Befolgung von Anweisungen.
• Chat-Modell: Gut für mehrrundige Dialoge mit Rollenformatierung.
• Reasoning-Modell: Gut, wenn die Aufgabe von zusätzlichen Denk-Tokens und Verifizierung profitiert.
• Tool-getuntes Modell: Gut, wenn strukturierte Aufrufe, JSON oder Funktionsnutzung wichtig sind.

Was lokal wirklich bedeutet

Ein lokales LLM ist ein Modell, dessen Gewichte und Inferenz-Laufzeitumgebung unter Ihrer Kontrolle sind. Sie entscheiden, welches Modell läuft, wie es läuft, welche Daten es sieht und was mit den Ausgaben passiert.

Diese Freiheit bringt Arbeit mit sich. Sie sind jetzt das Betriebsteam. Sie kümmern sich um Downloads, Updates, Kompatibilität, Speicherlimits und Sicherheit. Wenn etwas kaputt geht, gibt es kein Support-Ticket, das Sie einreichen können. Es gibt nur Sie, die Logs und die Dokumentation.

Lokal kann bedeuten:

• Ein 2B-Parametermodell, das auf einem Telefon läuft.
• Ein 7B- bis 14B-Modell, das auf einer Consumer-GPU läuft.
• Ein 30B- bis 70B-Modell, das auf einer High-End-Workstation läuft.
• Ein dünn besetztes MoE-Modell, das auf einer oder mehreren Rechenzentrums-GPUs läuft.
• Eine private Bereitstellung mit vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio oder einem benutzerdefinierten PyTorch-Stack.

Der entscheidende Punkt: Lokal bedeutet nicht automatisch offline, privat, sicher, günstig oder Open Source. Es bedeutet nur, dass Sie das Modell selbst ausführen. Eine lokale App kann trotzdem nach Hause telefonieren. Ein Modell kann offene Gewichte haben, aber nicht Open Source sein. Ein Modell kann lokal, aber unsicher zu laden sein. Ein quantisiertes Modell kann in den Speicher passen, aber schlecht antworten.

Der Kompromiss lohnt sich, wenn Sie Privatsphäre, niedrige Latenz, benutzerdefiniertes Verhalten, Offline-Betrieb oder Kostenkontrolle im großen Maßstab benötigen. Er lohnt sich nicht, wenn Sie die absolut beste Modellqualität benötigen und nicht die Hardware haben, um mitzuhalten. In diesem Fall ist eine gehostete API das richtige Werkzeug.

Lokale LLMs sind praktisch, wenn Sie eine Gleichung verstehen:

Erfolg mit lokalen LLMs = Modellpassung + korrektes Eingabeformat + gute Laufzeitumgebung + realistische Evaluierungen.

Alles andere sind Details. Die Details sind wichtig.

Quantisierung

Quantisierung speichert Gewichte in niedrigerer Präzision, um Speicher zu reduzieren und manchmal den Durchsatz zu verbessern.

Die Faustregel für 2026 für lokale Benutzer:

• FP16/BF16: Beste Qualität, wenn Speicher im Überfluss vorhanden ist. Verwenden Sie es als Basislinie für die Evaluierung.
• Q8 / INT8: Nahezu verlustfrei für viele Aufgaben, aber immer noch groß. Gut, wenn Sie VRAM haben und minimale Qualitätsverluste wünschen.
• Q6 / Q5: Exzellente Qualität mit moderaten Einsparungen. Dies ist ein starker Mittelweg.
• Q4: Der standardmäßige Consumer-Sweet-Spot für viele Chat- und Dokument-Workflows.
• Q3 / Q2: Nur, wenn Sie ein größeres Modell unterbringen müssen. Mathematik, Code, strukturierte Ausgaben und Tool-Nutzung verschlechtern sich zuerst.

Gewichtsquantisierung ist nicht dasselbe wie KV-Cache-Quantisierung. Gewichtsquantisierung verkleinert das Modell. KV-Cache-Quantisierung verkleinert den Live-Kontextspeicher.

Behandeln Sie für den KV-Cache FP16/BF16 als saubere Basislinie und FP8/INT8 als die praktische lokale Kompressionsuntergrenze. Unterhalb von 8 Bit ist es forschungslastig und workload-sensitiv. Verwenden Sie es nur, nachdem Sie die Qualität mit Ihren tatsächlichen Eingabeaufforderungen gemessen haben.

Quantisierungsfehler zeigen sich zuerst in Mathematik, mehrschrittigem Denken, Code-Korrektheit, Tool-Nutzungszuverlässigkeit, JSON/Schema-Einhaltung, subtiler Befehlsbefolgung und Langkontext-Retrieval.

Ein kleineres Modell mit höherer Präzision kann ein größeres Modell schlagen, das in zu wenige Bits gequetscht wurde. Beten Sie die Parameteranzahl nicht an. Ein 7B-Modell bei Q6 kann ein 13B-Modell bei Q2 bei Denkaufgaben schlagen, während es weniger Speicher verbraucht und schneller läuft.

Dateiformate und Ladesicherheit

safetensors ist ein sicheres Tensor-Serialisierungsformat, das entwickelt wurde, um Tensoren ohne Python-Pickle-Verhalten zu speichern. Verwenden Sie safetensors wann immer möglich, insbesondere für PyTorch/Transformers-Modelle.

Vermeiden Sie zufällige .bin-Dateien aus nicht vertrauenswürdigen Quellen. PyTorch-Pickle-basiertes Laden kann während der Deserialisierung beliebigen Code ausführen. Sicherheitsregel Nummer eins für lokale KI: Lassen Sie nicht zu, dass die Modelldatei eines Fremden zur Codeausführung eines Fremden wird.

GGUF ist das binäre Modellformat des llama.cpp-Ökosystems. Verwenden Sie GGUF, wenn Sie llama.cpp, CPU-Inferenz, Apple-Silicon-Inferenz, einfache lokale Server, portable quantisierte Modelle oder Desktop-Tools wie LM Studio wünschen.

ONNX ist nützlich für standardisierte Bereitstellung und hardwarespezifische Beschleunigung, insbesondere außerhalb des üblichen PyTorch-Stacks. Wenn Sie für Intel-NPUs, ARM-Geräte oder benutzerdefinierte Beschleuniger bereitstellen, ist ONNX oft der Weg des geringsten Widerstands.

TensorRT-LLM ist der leistungsstarke Inferenzpfad von NVIDIA für produktive GPU-Bereitstellungen. Es ist leistungsstark, aber komplexer als llama.cpp oder Harbor. Sie konvertieren normalerweise einen Checkpoint in TensorRT-Engines, was Zeit und GPU-Speicher kostet, aber sobald erstellt, einen hervorragenden Durchsatz liefert.

EXL2- / GPTQ- / AWQ-Formate sind in GPU-fokussierten lokalen Inferenz-Communities üblich, insbesondere um größere Modelle auf einzelne GPUs zu quetschen.

Die Wahl des Dateiformats ist nicht kosmetisch. Sie bestimmt, welche Laufzeitumgebungen das Modell laden können, welche Quantisierung Sie verwenden können und wie schnell es läuft.

Laufzeitumgebungen und Serving-Modi

Eine Laufzeitumgebung ist die Software, die das Modell lädt und die Inferenz durchführt. Im Jahr 2026 ist das Ökosystem der lokalen LLM-Laufzeitumgebungen ausgereift, nützlich und fragmentiert.

Für eine einzelne Person, die lokal experimentiert, beginnen Sie mit Harbor, LM Studio oder llama.cpp. Harbor ist die beste Wahl, wenn Sie einen vollständigen lokalen Stack mit Frontends, Backends und verbundenen Diensten wünschen. LM Studio ist der einfachste Desktop-zentrierte Pfad. llama.cpp ist das portable Low-Level-Arbeitstier.

Für ein Team oder einen privaten Dienst schauen Sie sich vLLM oder SGLang an. Für maximale NVIDIA-Produktionsleistung untersuchen Sie TensorRT-LLM. Für die Bereitstellung im Browser oder auf Mobilgeräten schauen Sie sich MLC oder WebLLM an.

Die Wahl der Laufzeitumgebung schließt Sie oft in ein Format-Ökosystem ein. llama.cpp bedeutet GGUF. vLLM und SGLang bedeuten normalerweise safetensors oder Hugging-Face-Checkpoints. TensorRT-LLM bedeutet ONNX oder optimierte Engines. Wählen Sie zuerst die Laufzeitumgebung und suchen Sie dann Modelle im richtigen Format.

Es gibt drei praktische Serving-Modi.

Einzelbenutzer-lokal bedeutet eine Desktop-App, einen CLI-Stack oder einen Kommandozeilen-Server für eine Person. Harbor, LM Studio, llama.cpp-Server, ExLlama/TabbyAPI und kleine Transformers-Skripte passen alle hier hinein. Das Ziel ist schnelle Iteration: Vergleichen Sie Verhalten, Geschwindigkeit, Speichernutzung und Eingabeformate, ohne eine Operationsplattform aufzubauen.

Team oder private API bedeutet einen OpenAI-kompatiblen Endpunkt auf einer Workstation oder einem Server. vLLM, SGLang, TensorRT-LLM und llama.cpp-Server tauchen hier auf, abhängig von Modellgröße und Durchsatzanforderungen. Sobald mehrere Personen oder Jobs ein Modell teilen, benötigen Sie Überwachung, Prompt-/Versionsverwaltung, Routing und realistische Latenzmessungen.

Die Bereitstellung im Produktionsbetrieb ist eine andere Aufgabe. Jetzt umfasst die Diskussion kontinuierliches Batching, Prefix Caching, spekulative Dekodierung, Paged Attention, Tensor-Parallelität, Pipeline-Parallelität, quantisiertes Serving, strukturierte Ausgaben, Lastausgleich, GPU-Auslastung, Latenz-Perzentile, Prompt Caching, Zugangskontrolle, Logging, Failover, Datenschutz und Kostenkontrollen.

Im Produktionsmaßstab ist Kann ich das Modell laden? die einfache Frage. Die schwierige Frage ist: Kann ich es unter echtem Traffic zuverlässig bedienen?

VRAM-Berechnung für lokale Modelle

Es gibt drei Hauptspeicherverbraucher:

1. Modellgewichte
2. KV-Cache
3. Laufzeit-Overhead

Die grobe Formel für den Gewichtsspeicher lautet:

Gewichtsspeicher ~= Parameter x Bytes pro Parameter

Nützliche Näherungen:

• FP16/BF16: Etwa 2 Bytes pro Parameter.
• INT8/Q8: Etwa 1 Byte pro Parameter.
• Q4: Etwa 0,5 Bytes pro Parameter, zuzüglich Format-Overhead.

Dann addiere:

• Laufzeit-Overhead: Framework-Puffer, CUDA-Overhead, Speicherfragmentierung und temporäre Tensoren.
• KV-Cache: Wächst mit jedem Token im aktiven Kontext.
• Batch-/Concurrency-Speicher: Jede gleichzeitige Anfrage benötigt ihren eigenen Cache.
• Vision-Encoder-Speicher: Bilder werden ebenfalls zu Token.
• Spekulativer Dekodierungsspeicher: Draft-Modelle, Draft-Heads oder zusätzliche Verifikationsstrukturen sind nicht umsonst.
• Adapter-Speicher: LoRA-Adapter sind klein, aber dennoch real.

MoE-Modelle fügen eine weitere Komplikation hinzu. Ein Modell aktiviert möglicherweise nur einen Bruchteil seiner Parameter pro Token, aber die inaktiven Experten müssen normalerweise trotzdem irgendwo im Speicher untergebracht werden. Aktive Parameter beeinflussen die Rechenkosten. Gesamtparameter beeinflussen immer noch das Laden und die Kapazitätsplanung.

Eine realistische Schätzung sieht so aus:

Gesamtspeicher = quantisierte_Gewichte + KV-Cache_für_Kontext + Laufzeit_Overhead + Batch-_oder_Concurrency_Overhead + Sicherheitsmarge

Hier ist die Falle: Ein 13B-Modell in Q4 passt vielleicht problemlos bei 8K-Kontext, scheitert dann aber bei 32K, weil der KV-Cache sich vervierfacht hat. Die Gewichte haben sich nicht geändert. Der Kontext schon.

Halte 10 bis 20 Prozent Spielraum frei. Eine VRAM-Auslastung von 99 Prozent ist eine Einladung zu Out-of-Memory-Fehlern und Fragmentierungsproblemen.

Hardware-Stufen in der Praxis

Dies sind praktische Faustregeln für 2026, unter Annahme von quantisierter Inferenz und sinnvollen Kontextlängen. Genaue Ergebnisse hängen von Laufzeit, Quantisierung, Modellarchitektur, Aufmerksamkeitstyp, Kontextlänge und Betriebssystem-/Treiber-Overhead ab.

Für die meisten ernsthaften lokalen Nutzer im Jahr 2026 ist 16 GB die minimale komfortable GPU-Stufe, 24 GB die beste Preis-Leistungs-Stufe für Enthusiasten und 48 GB+ die Stufe, auf der sich die stärkere lokale Welt eröffnet.

Die Leistung hängt von Speicherbandbreite, GPU-FLOPs, VRAM-Kapazität, KV-Cache-Größe, Aufmerksamkeitsimplementierung, Quantisierung, Batch-Größe, Prompt-Länge, generierter Länge und Laufzeit-Reife ab.

Decode ist oft speicherbandbreitenbegrenzt: Die GPU streamt wiederholt Gewichte, während sie relativ wenig Rechenarbeit pro Byte leistet. Prefill ist rechenintensiver, da es den Prompt parallel verarbeiten kann. Deshalb können zwei Karten mit derselben VRAM-Kapazität sehr unterschiedliche Token-Geschwindigkeiten haben, wenn eine eine viel höhere Speicherbandbreite hat.

Der schmerzhafteste lokale Aufbau ist einer, bei dem das Modell fast passt und Layer auf die CPU auslagert. Es mag technisch laufen, aber die Token-Geschwindigkeit kann einbrechen. CPU-Auslagerung ist für Experimente akzeptabel. Es ist keine Leistungsstrategie.

Ein passendes Modell auswählen

Die praktische Frage ist nicht Was ist das beste Modell? Sondern Was ist das kleinste Modell, das deine tatsächliche Aufgabe auf deiner Hardware gewinnt?

Beginne mit einem aktuellen Instruct-/Chat-Modell, das bequem mit der Kontextlänge passt, die du tatsächlich benötigst. Wenn du 8 GB bis 12 GB VRAM oder Unified Memory hast, fange klein an. Wenn du 16 GB bis 24 GB hast, teste zuerst Modelle der 7B- bis 14B-Klasse. Wenn du 48 GB oder mehr hast, werden größere dichte Modelle und MoE-Modelle realistisch.

Nutze diese Speicherprüfung, bevor du dich in einen Checkpoint verliebst:

Gewichte + KV-Cache + Laufzeit-Overhead <= 80 bis 90 Prozent des verfügbaren Speichers

Führe dann dieselben 20 bis 50 Prompts mit den Kandidaten durch. Beziehe deine tatsächlichen Aufgaben mit ein: Code-Bearbeitungen, Dokumenten-Q&A, JSON-Ausgabe, Zusammenfassungen, Tool-Aufrufe, langer Kontext oder was auch immer du wirklich brauchst. Miss Antwortqualität, Latenz, Speichernutzung, Vorlagenzuverlässigkeit und Fehlermodi.

Eine praktische Modellwahl läuft in der Regel auf fünf Prüfungen hinaus:

• Aufgabenpassung: Chat, Coding, Dokumente, Agenten, multimodal, Edge oder Feintuning.
• Speicherpassung: Gewichte, KV-Cache, Laufzeit-Overhead und Sicherheitsmarge.
• Schnittstellenpassung: Tokenizer, Chat-Vorlage, Stop-Token, Tool-Schema und Reasoning-Modus.
• Laufzeitpassung: Unterstützt deine Laufzeit diese Architektur, Quantisierung, Kontextlänge und Servicemodus gut?
• Lizenzpassung: Darfst du es dort nutzen, wo du es nutzen willst?

Leaderboards sind nützlich zur Entdeckung. Sie ersetzen keine eigene Evaluierung. Deine Arbeitslast ist der Benchmark, der zählt.

Für einen einfachen lokalen Assistenten wähle ein aktuelles 7B- bis 14B-Instruct-Modell, Q4/Q5-Quantisierung, die korrekte Chat-Vorlage, 8K bis 32K Kontext und Harbor, LM Studio oder llama.cpp. Priorisiere Reaktionsfähigkeit vor riesiger Größe.

Für einen lokalen Code-Assistenten wähle ein codefähiges 14B- bis 32B-Modell, wenn du genug VRAM hast. Verwende niedrige Temperatur, Repository-Retrieval, Testausführung und einen patchbasierten Workflow. Ein Code-Modell ohne Werkzeuge ist ein halbes Produkt.

Für einen privaten Dokumenten-Assistenten wähle ein starkes Instruct-Modell, ein lokales Embedding-Modell, einen Reranker, eine RAG-Pipeline, Zitierungsdurchsetzung und moderaten bis langen Kontext. Füge nicht einfach ein 200-seitiges PDF ein und hoffe auf das Beste.

Für einen Reasoning-Aufbau wähle ein reasoning-angepasstes Modell, budgetiere zusätzliche Token, verwende niedrige bis mittlere Temperatur, füge Verifikation hinzu und nutze Werkzeuge für Mathematik, Code oder Suche. Reasoning-Modelle verbrauchen mehr Token. Budgetiere entsprechend.

Für eine ressourcenarme Umgebung wähle ein 1B- bis 4B-Modell, Q4/Q5, kurze Prompts, strukturierte Aufgaben, Retrieval oder Tools und ein enges Ausgabeschema. Kleine Modelle werden nützlich, wenn die Aufgabe eingeschränkt ist.

Was die Geschwindigkeit bestimmt

Token pro Sekunde wird nicht durch eine Sache bestimmt. Es ist das Ergebnis von Modellgröße, Speicherbandbreite, Rechenleistung, Aufmerksamkeitskernen, Kontextlänge, Quantisierung, Batching und Laufzeitqualität.

Die wichtigsten Stellhebel sind:

• Speicherbandbreite: Decode streamt oft wiederholt Modellgewichte, daher dominiert die Bandbreite die Single-User-Token-Geschwindigkeit.
• GPU-FLOPs: Prefill und große Batches nutzen mehr parallele Rechenleistung, daher sind FLOPs dort wichtiger.
• VRAM-Kapazität: Wenn das Modell oder der KV-Cache auf die CPU ausgelagert wird, kann die Leistung einbrechen.
• Aufmerksamkeitsimplementierung: FlashAttention, SDPA, Paged Attention und laufzeitspezifische Kerne verändern sowohl Geschwindigkeit als auch Speicherverhalten.
• Quantisierung: Kleinere Gewichte reduzieren den Speichertransfer, aber aggressive Quantisierung kann die Qualität beeinträchtigen und manchmal Dequantisierungs-Overhead hinzufügen.
• Batch-Größe und Gleichzeitigkeit: Batching verbessert den Durchsatz, aber jede aktive Sequenz benötigt KV-Cache.
• Prompt-Länge: Lange Prompts erhöhen die Prefill-Zeit.
• Generierte Länge: Lange Antworten zeigen die Decode-Geschwindigkeit.
• Spekulative Dekodierung: EAGLE-artige Methoden, MTP, DFlash und DDTree können bei Unterstützung mehr als einen entworfenen Token pro Ziel-Pass verifizieren.

Der schmerzhafte Aufbau ist der „passt-fast“-Aufbau. Ein Modell, das Layer oder Cache auf die CPU auslagert, mag technisch laufen, aber die Token-Geschwindigkeit kann von brauchbar auf miserabel fallen.

Benchmarke die exakte Laufzeit, Quantisierung, Kontextlänge, Prompt-Form und Arbeitslast, die du verwenden willst. Eine BF16-Leaderboard-Zahl sagt dir nicht, wie sich dein lokaler Q4-Stack anfühlt.

Langer Kontext

Langer Kontext klingt magisch: 128K, 256K oder sogar 1M Token in einem Prompt. Es ist nützlich, aber es hat reale Kosten.

Mehr Kontext bedeutet mehr KV-Cache-Speicher, langsamere Prompt-Verarbeitung, mehr Aufmerksamkeitsarbeit, schwierigere Evaluierung und mehr Wege, auf denen irrelevanter Text das Modell ablenken kann. Die Qualität kann auch mit der Entfernung abnehmen. Ein Modell kann das Ende eines langen Dokuments gut verarbeiten, aber kritische Details übersehen, die nahe dem Anfang vergraben sind.

Verwende langen Kontext für gesamt Dokumentenanalyse, Codebasis-Ausschnitte, juristische oder technische Überprüfungen, Transkript-Zusammenfassungen, Multi-File-Reasoning und RAG-Ausweichlösung, wenn das Retrieval den Kontext verfehlt.

Behandle langen Kontext nicht als Ersatz für Retrieval. Es ist eine Ergänzung. Verwende RAG für große Korpora und langen Kontext für die final ausgewählten Beweise.

Praktische Gewohnheiten helfen:

• Setze kritische Anweisungen in die Nähe des Anfangs und des Endes.
• Verwende Abschnittsüberschriften und Trennzeichen.
• Bitte um Zitate, die an Quellblöcke gebunden sind.
• Komprimiere irrelevante Verläufe.
• Verwende Zusammenfassungsspeicher anstelle einer unendlichen Chat-Historie.

Betrachte langen Kontext als teure Aufmerksamkeit, nicht als kostenloses Notizbuch.

Multimodalität

Multimodale lokale Modelle akzeptieren Bilder und manchmal Audio oder Video zusätzlich zu Text. Moderne Ökosysteme mit offenen Gewichten integrieren diese Modelle zunehmend.

Die versteckten Kosten sind, dass Nicht-Text-Eingaben ebenfalls zu Token werden. Vision-Encoder verbrauchen Speicher. Bildausschnitte verbrauchen Kontext. Audio und Video können das Eingabebudget sprengen. Multimodale Vorlagen sind auch leichter falsch zu machen als reine Textvorlagen.

Ein einziges hochauflösendes Bild kann Tausende von Token im Kontextfenster verbrauchen. Wenn du ein multimodales Modell lokal betreibst, zähle Bild-Token genauso wie Text-Token. Sie stammen aus demselben Budget.

Kleine VLMs können visuelle Details halluzinieren. Die OCR-Zuverlässigkeit variiert. Diagramme und Tabellen sind immer noch schwierig. Für ernsthafte Dokumenten- oder Bild-Workflows evaluiere mit echten Beispielen. Vertraue keiner Demo eines einfachen Fotos, um die Rechnungsextraktionsqualität zu beweisen.

Die lokale Modelllandschaft 2026

Die Modelllandschaft ändert sich schnell. Stand 21. Mai 2026 sollten lokale LLM-Nutzer in Familien und Ökosystemen denken, nicht in einem einzigen besten Modell.

Qwen 3.5 / Qwen 3.6 ist eine wichtige Familie mit offenen Gewichten, weil sie den gesamten Stack abdeckt: Kleine Modelle für Laptops, dichte Mittelklasse-Modelle für Workstations, MoE-Modelle für Multi-GPU-Serving, FP8-Varianten, langer Kontext, mehrsprachige Arbeit, Codierung, Werkzeuge und agentische Workflows. Die praktische Schlussfolgerung ist einfach: Qwen ist eine starke Standardfamilie, wenn du ein Ökosystem möchtest, das Laptop-Experimente und ernsthaftes lokales Serving abdeckt.

Gemma 4 ist wichtig, weil Google DeepMind die Familie in Richtung nützlicher lokaler Bereitstellung drängt: Effiziente Edge-Modelle, größere dichte und MoE-Optionen, Multimodalität, langer Kontext bei den größeren Modellen, breite Sprachunterstützung, stärkeres Codierungs-/Agentenverhalten und Apache-2.0-Lizenzierung. Diese Kombination macht es testenswert, wenn kommerzielle Nutzung und geräteseitige Bereitstellung wichtig sind.

Kimi / Moonshot AI, GLM / Z.ai, DeepSeek, MiniMax und Mistral sind ebenfalls Kernfamilien, die man im Auge behalten sollte. Kimi ist relevant für langfristiges Codieren, multimodales Reasoning, Werkzeugnutzung und Agenten-Workflows. GLM ist wichtig für Codierungsagenten, langfristige Aufgaben, MoE-Systeme und bereitstellungsorientierte Modellveröffentlichungen. DeepSeek bleibt einflussreich aufgrund großer MoE-Systeme, Multi-head Latent Attention, DeepSeekMoE, FP8-Serving-Pfaden, spärlicher Aufmerksamkeit und Hochdurchsatz-Self-Hosting. MiniMax ist einen Blick wert für praktische Agenten-Workloads und inferenzeffiziente MoE-Modelle. Mistral ist immer noch relevant, weil seine Aufstellung Generalisten, Codierung, Reasoning, multimodale und spezialisierte Anwendungsfälle mit starker Bereitstellungsunterstützung abdeckt.

Nemotron 3 ist NVIDIAs offene Modellfamilie für produktionsreife Agentensysteme auf NVIDIA-Hardware. Die Familie umfasst Nano-, Super- und Ultra-Größen, verwendet hybride Mamba-Transformer-MoE-Designs und ist eng mit TensorRT-LLM, NIM, Dynamo, Blackwell NVFP4/FP8-Pfaden und Enterprise-Agenten-Bereitstellung verbunden. Betrachte es weniger als eine lockere Desktop-Chat-Familie und mehr als ein Signal dafür, wohin NVIDIA die Stacks für offene Gewichte führen möchte.

Open-Weight AI ist nicht länger nur Llama gegen den Rest. Du wählst ein Ökosystem: Gewichte, Lizenz, Tokenizer, Vorlage, Quantisierungen, Laufzeitunterstützung, Serving-Pfad, Community-Tools und Fehlermodi.

Das dichte Modell Qwen 27B

Qwen 3.5 / 3.6 27B (Dense) ist eine der praktischsten Optionen mit öffentlichen Gewichten für lokale Nutzer, die Wert auf Codierung, mehrsprachige Arbeit, Werkzeugnutzung, Denk-/Nicht-Denk-Modi und langen Kontext legen. Die Modellkarten von Qwen 3.5 27B und Qwen 3.6 27B beschreiben OpenAI-kompatible Serving-Pfade, Denkmodus-Standardwerte, Werkzeugnutzung und Kontextlängen von bis zu 262.144 Token, mit Erweiterung auf längeren Kontext durch YaRN in unterstützten Frameworks.

Qwen ist eine starke Standardwahl für ein 2x RTX 3090-Setup, wenn die Laufzeit korrekt für Codierung, Agenten oder mehrsprachige Abdeckung konfiguriert ist.

Inferenzforschung

Die Grenze im Jahr 2026 liegt nicht nur in der Modellqualität. Sie liegt auch in der Inferenzeffizienz. PagedAttention bekämpft KV-Cache-Speicherverschwendung beim Serving. FP8-KV-Cache ist jetzt ein praktisches Laufzeitfeature in Systemen wie vLLM. DFlash und DDTree erforschen spekulative Dekodierung mit Blockdiffusions-Draft-Modellen und Draft-Bäumen. NVFP4 ist ebenfalls einen Blick wert auf NVIDIA-Hardware, da es die praktische Bereitstellungsdiskussion für unterstützte Stacks verändert.

Einiges davon ist produktionsreif. Einiges ist noch Forschung. Einiges ist nur relevant, wenn deine Laufzeit es sauber unterstützt. Behandle Paper-Beschleunigungen nicht als Abhakpunkt in einer Desktop-App.

Fehlermodi und Lösungen

Die meisten lokalen LLM-Fehler sind nicht mysteriös. Sie kommen normalerweise von Speicherpassung, Formatierung, Laufzeitunterstützung, Dekodierungseinstellungen oder Retrieval-Qualität.

Out of Memory: Die Gewichte, der KV-Cache, der Laufzeit-Overhead oder die Batch-Größe passen nicht. Verwende ein kleineres Modell, reduziere den Kontext, verringere Batch/Gleichzeitigkeit, wähle eine bessere Quantisierung oder lasse mehr Spielraum.

Unsinn oder Rollenverwirrung: Die Chat-Vorlage, der Tokenizer, das BOS/EOS-Token, der Reasoning-Modus-Schalter oder das Tool-Schema ist falsch. Überprüfe die Modellkarte und die Laufzeitvorlage, bevor du die Modellqualität bemängelst.

Langsames erstes Token: Prefill ist teuer. Verkürze den Prompt, verwende Prefix Caching, verbessere das Retrieval, reduziere den Kontext oder verwende eine schnellere Laufzeit.

Langsames Streaming: Decode ist der Engpass. Überprüfe Speicherbandbreite, Quantisierung, CPU-Auslagerung, Aufmerksamkeits-Backend, Unterstützung für spekulative Dekodierung und ob das Modell einfach zu groß für die Hardware ist.

Schlechte Dokumentenantworten: Das Retrieval hat wahrscheinlich versagt. Überprüfe geparsten Text, Chunk-Grenzen, Metadaten, Top-k-Retrieval, Reranking und Zitierungsfundament.

Schlechte JSON- oder Tool-Aufrufe: Verwende niedrigere Temperatur, eingeschränkte Dekodierung, strengere Schemas, bessere Beispiele und ein für Werkzeugnutzung optimiertes Modell.

Wiederholungsschleifen: Reduziere Temperatur oder Top-p, füge Wiederholungsstrafen hinzu, überprüfe Stop-Token und stelle sicher, dass die Vorlage nicht dazu führt, dass das Modell seine eigene Antwort als neuen Prompt sieht.

Beginne mit den langweiligen Checks. Sie beheben mehr Probleme als das Austauschen des Modells.

Wie man den Stack erweitert

Anfänger: Einfachster nützlicher Aufbau

Verwende Harbor oder LM Studio, ein aktuelles 4B- bis 9B-Instruct-Modell, Q4-Quantisierung, 8K bis 32K Kontext und eine integrierte Chat-Oberfläche. Lade zwei oder drei Modelle derselben Größenklasse herunter und vergleiche sie mit denselben Prompts.

Ziel: Prompting lernen, Modelle vergleichen, Geschwindigkeit und Speicher verstehen und zunächst benutzerdefinierten Code vermeiden.

Fortgeschritten: Entwickler-Setup

Verwende llama.cpp oder Transformers, GGUF oder safetensors, einen OpenAI-kompatiblen lokalen Server, eine einfache RAG-Pipeline und einen kleinen Evaluierungssatz. Rufe deinen lokalen Server von einer echten Anwendung oder einem Skript aus auf, anstatt nur eine Chat-Oberfläche zu verwenden.

Ziel: Lokale Apps bauen, Retrieval testen, Qualität messen und von localhost aus serven.

Fortgeschritten: Privates Serving-Setup

Verwende vLLM oder SGLang, eine oder mehrere GPUs, eine OpenAI-kompatible API, Überwachung, Prompt-/Versionsverwaltung, eine Evaluierungssuite, RAG mit Reranking und Tool-Sandboxing.

Ziel: Echte Benutzer oder interne Workflows bedienen, Durchsatz und Latenz optimieren sowie Sicherheit und Beobachtbarkeit aufrechterhalten.

Experte: Maßgeschneiderte Optimierung

Verwende TensorRT-LLM, benutzerdefinierte Kerne, spezialisierte Laufzeiten, Quantisierungsexperimente, spekulative Dekodierung, Multi-GPU-Parallelität, Feintuning, Destillation und Produktionsevaluierungen.

Ziel: Ingenieurszeit gegen Inferenzeffizienz eintauschen, Kosten senken und Qualität im Maßstab verbessern.

Datenschutz ist nicht automatisch

Lokale LLMs verbessern den Datenschutz, da Prompts und Ausgaben auf deiner Hardware bleiben können. Aber lokal bedeutet nicht automatisch sicher.

Zu den Bedrohungen gehören bösartige Modelldateien, Pickle-basiertes Gewichtsladen, unvertrautes trust_remote_code, Prompt-Injection in abgerufenen Dokumenten, Missbrauch von Tool-Aufrufen, Leckage von Geheimnissen durch Logs, Telemetrie von Desktop-Apps, Browsererweiterungen oder Plugins, Modellhalluzinationen in sicherheitskritischen Umgebungen, Lizenzverletzungen und Datenkontamination während des Feintunings.

Eine funktionierende lokale KI-Sicherheitsbasis hat vier Gewohnheiten:

• Sorgfältig laden: Bevorzuge safetensors oder GGUF von seriösen Quellen, vermeide unvertraute .bin-Dateien und aktiviere trust_remote_code nicht leichtfertig.
• Mit Grenzen ausführen: Verwende einen unprivilegierten Benutzer, Container oder Sandboxen für Agenten und deaktiviere Netzwerkzugriff, wenn Offline-Datenschutz wichtig ist.
• Geheimnisse schützen: Halte Anmeldedaten aus Prompts und RAG-Indizes fern, überprüfe die Telemetrieeinstellungen der Desktop-App und validiere Tool-Aufrufe vor der Ausführung.
• Versionieren, was wichtig ist: Verfolge Modell-, Prompt-, Adapter-, Laufzeit- und Quantisierungsversionen und protokolliere genug für das Debuggen, ohne ein Datenschutzdesaster zu verursachen.

Lokale KI-Sicherheit besteht hauptsächlich aus langweiliger operativer Disziplin. So vermeidest du auch, einen zufälligen Checkpoint herunterzuladen, ihn als Root auszuführen und aus lokaler KI eine lokale Kompromittierung zu machen.

Benchmarks, die zählen

Benchmarke den Stack, den du tatsächlich betreiben wirst. Die BF16-Leaderboard-Punktzahl eines Modells ist nicht deine lokale Q4-Realität.

Messe Qualität, Latenz, Speicher, Zuverlässigkeit und Betriebspassung:

• Qualität: Korrektheit bei deinen tatsächlichen Aufgaben, nicht nur bei generischen Benchmarks.
• Latenz: Zeit bis zum ersten Token, Decode-Token pro Sekunde und End-to-End-Zeit.
• Speicher: Gewichtsspeicher, KV-Cache-Wachstum, Spitzen-VRAM und Spielraum unter Last.
• Formatierung: Korrektheit der Chat-Vorlage, JSON/Schema-Erfolg, Tool-Aufruf-Zuverlässigkeit und Stop-Token-Verhalten.
• Retrieval: Zitierungstreue, Antwortfundament, Verhalten bei fehlenden Beweisen und Auswirkung des Rerankers.
• Betrieb: Startzeit, Aufwärmverhalten, Absturzwiederherstellung, Protokollierung, Datenschutz und Versionsverfolgung.

Erstelle einen kleinen Evaluierungssatz mit 30 bis 100 repräsentativen Prompts. Enthalte erwartete Antworten oder Bewertungskriterien, Latenz- und Speichermessungen, Fehlerkategorien, RAG-spezifische Fundamentprüfungen, JSON-Compliance-Prüfungen, falls relevant, und menschliche Überprüfung für mehrdeutige Aufgaben.

Vergleiche dann Modelle. Lass nicht zu, dass ein Leaderboard deinen lokalen Stack für dich auswählt.

Codieren mit lokalen Modellen

Codieren ist einer der besten Anwendungsfälle für lokale LLMs, da Prompts oft privaten Code enthalten, Latenz wichtig ist, Iteration häufig ist, API-Kosten schnell steigen können und lokale Modelle in Editoren, Shells, grep, Testläufer und Patch-Workflows integriert werden können.

Der stärkste lokale Codierungsaufbau ist kein nackter Chatbot. Es ist ein codefähiges Instruct-Modell, verbunden mit gezieltem Repository-Kontext, Retrieval über die Codebasis, Dateipfaden, relevanten Ausschnitten, Testausführung und einer Patch-Schleife.

Halte die Dekodierung deterministisch oder bei niedriger Temperatur. Frage nach Patches anstelle von vagen Ratschlägen. Führe Tests automatisch aus. Behalte einen kleinen Evaluierungssatz mit echten Bugs und Aufgaben, damit du erkennen kannst, wann ein neues Modell tatsächlich besser ist.

Lass ein lokales Modell keine große Codebasis ohne Überprüfung umschreiben. Lokal macht einen Codierungsagenten nicht weise. Es macht den Kontext nur privat, die Schleife billiger und die Integration leichter kontrollierbar.

Lokale Agenten brauchen Leitplanken

Ein lokales LLM wird viel nützlicher, wenn es Werkzeuge verwenden kann: Dateisuche, Shell-Befehle, Browserautomatisierung, Datenbanken, Codeausführung, Kalender, Ticketsysteme, interne APIs, Vektordatenbanken, Hausautomatisierung, Robotik oder Edge-Geräte.

Werkzeugnutzung verändert das Sicherheitsmodell. Ein Chatbot, der halluziniert, ist nervig. Ein Agent mit Dateisystemzugriff kann Dinge löschen. Ein Agent mit Browserzugriff kann Geheimnisse preisgeben. Ein Agent mit Shell-Zugriff kann den Rechner schneller beschädigen, als du die Logs lesen kannst.

Lokale Agentensicherheit hat vier Ebenen. Beschränke den Agenten eng, indem du ihm nur die Verzeichnisse, APIs, Netzwerkzugriffe und Anmeldedaten gibst, die er tatsächlich benötigt. Schränke die Ausführung mit Sandboxen, Containern, Benutzern mit geringsten Privilegien, Bestätigungen für destruktive Aktionen und schema-validierten Tool-Argumenten ein. Behandle Eingaben als feindlich, da abgerufene Dokumente, Webseiten, Tickets und E-Mails Prompt-Injection enthalten können. Führe ein Audit-Trail, indem du Tool-Aufrufe, Modellversionen, Prompts und Genehmigungen protokollierst, ohne Geheimnisse in Logs zu dumpfen.

Strukturierte Ausgaben helfen, aber sie sind keine Sicherheitsgrenze. JSON-Schemas, eingeschränkte Dekodierung und Funktionssignaturen erleichtern die Validierung von Tool-Aufrufen. Sie beweisen nicht, dass das Modell die Anfrage verstanden, die sichere Aktion gewählt oder eingeschleuste Anweisungen vermieden hat.

Für ernsthafte Werkzeugnutzung setze Richtlinienprüfungen außerhalb des Modells.

RAG schlägt riesige Prompts

RAG steht für Retrieval-Augmented Generation. Anstatt alle Informationen in den Prompt zu stopfen, rufst du relevante Blöcke aus einer Wissensdatenbank ab und gibst nur diese Blöcke an das Modell.

Ein gutes lokales RAG-System umfasst in der Regel Dokumentenerfassung, Parsing, Chunking, Embeddings, einen Vektorindex, Retrieval, Reranking, Prompt-Konstruktion, Antwortgenerierung, Fundamentprüfungen und Evaluierung. Jede Stufe ist ein Fehlerpunkt.

Schlechtes Parsing verwandelt Tabellen in Müll. Schlechtes Chunking teilt die Antwort über Grenzen hinweg auf. Schlechtes Retrieval liefert irrelevante Absätze. Schlechtes Reranking vergräbt die richtige Antwort auf Rang 20. Ein gutes Modell kann nicht zuverlässig aus Beweisen antworten, die es nie erhalten hat.

Die meisten schlechten RAG-Systeme sind nicht wegen des LLMs schlecht. Sie sind schlecht wegen Chunking, Retrieval, Reranking und Evaluierung.

Die Chunking-Strategie ist der stille Killer. Blöcke fester Größe ohne Überlappung können Sätze teilen und Kontext verlieren. Semantisches Chunking oder hierarchisches Chunking mit Parent-Document-Retrieval funktionieren oft besser, aber es gibt keine universelle Antwort. Du musst Chunk-Größe, Überlappung und Teilungsregeln an deinen tatsächlichen Dokumenten evaluieren.

Ein guter Reranker kann mittelmäßiges Retrieval retten. Kein Reranker kann Blöcke reparieren, die die Antwort während der Erfassung verloren haben.

Dokumente und Wissensarbeit

Für private Dokumente glänzen lokale LLMs: Zusammenfassungen von Besprechungstranskripten, Vertragsprüfung, Q&A zu technischen Dokumentationen, Synthese von Forschungsnotizen, E-Mail-Entwürfe, Richtliniensuche, interne Support-Assistenten und Compliance-Workflows profitieren alle davon, Quellmaterial in der Nähe des Rechners oder der Organisation zu behalten, der es gehört.

Der Workflow ist einfach, aber unnachgiebig. Parse Dokumente sorgfältig, behalte Seiten- und Abschnittsmetadaten, chunk semantisch, verwende Embeddings und Reranker, bitte um Zitate, trenne Antwort von Quellen von allgemeinem Reasoning und evaluiere die Zitierungstreue.

Gehe nicht davon aus, dass das Modell weiß, was in deinen Dokumenten steht. Es weiß nur, was du in den Prompt oder in den Kontext abgerufen hast.

Für Besprechungstranskripte behalte Sprecherbezeichnungen und Zeitstempel. Für Vertragsprüfung chunk nach Klausel oder Abschnitt anstelle einer willkürlichen Token-Anzahl. Für Q&A zu technischen Dokumentationen füge Seitenzahlen oder Abschnittsanker in abgerufene Blöcke ein, damit das Modell Quellen genau zitieren kann.

Für die Dokumentenarbeit sind dein Parser und Retriever genauso wichtig wie das Modell.

Edge-Bereitstellung

Kleine Modelle werden zunehmend auf Telefonen, Laptops, Robotern, IoT-Gateways, Fabrikgeräten, Fahrzeugen, medizinischen Geräten, Offline-Feldausrüstung und Browser-Apps nützlich. Der Edge ist nicht nur eine kleinere Version der Workstation. Er hat andere Einschränkungen.

Edge-Deployment wird von wenig Arbeitsspeicher, geringer Leistung, thermischen Grenzen, unterbrochener Konnektivität, Datenschutzanforderungen, Echtzeit-Latenz, kleinen Kontextfenstern und vorhersagbarem Fallback-Verhalten bestimmt. Auf diesen Geräten schlägt ein kleines, zuverlässiges Modell ein großes, fragiles.

Ein praktisches Edge-Setup nutzt oft ein 0,5B- bis 4B-Modell, aggressive Gewichtsquantisierung, winzige Prompts, feste Schemata, toolgestützte Workflows, lokale Embeddings, Caching und keine unnötige Chathistorie.

Wenn die Verbindung abbricht, ist ein lokales Modell, das weiterarbeitet, wertvoller als ein größeres Modell, das ausfällt. Die Zukunft lokaler KI besteht nicht nur aus riesigen Workstation-Modellen. Es sind auch kleine Modelle, die in der Nähe der Daten nützliche Arbeit verrichten.

Ein Leitfaden für lokale LLMs

Nutzen Sie dies als letzte Prüfung, bevor Sie einem lokalen Modell für echte Arbeit vertrauen.

Auswählen und anpassen: Wählen Sie eine Modellfamilie, die zur Aufgabe passt, lesen Sie die Lizenz, bestätigen Sie die Hardware-Anforderungen, wählen Sie ein Quantisierungslevel und kalkulieren Sie den vollständigen Speicherbedarf. Hören Sie nicht bei der Gewichtsgröße auf. Berücksichtigen Sie KV-Cache, Laufzeit-Overhead, Batch-/Parallelverarbeitung und Sicherheitsmarge.

Laden und formatieren: Bevorzugen Sie Safetensors oder GGUF aus vertrauenswürdigen Quellen, vermeiden Sie ungeprüfte pickle-basierte Dateien, überprüfen Sie Tokenizer und Chat-Template, setzen Sie die Kontextlänge bewusst und wählen Sie Decoding-Parameter für die Aufgabe. Wenn das Template falsch ist, ist die Auswertung ungültig.

Evaluieren und betreiben: Testen Sie mit repräsentativen Prompts, messen Sie die Zeit bis zum ersten Token und die Decoding-Geschwindigkeit, verfolgen Sie den Spitzen-Speicherverbrauch, evaluieren Sie das Retrieval vor dem Hinzufügen von RAG, sandboxen Sie Tools vor dem Hinzufügen von Agents und führen Sie Feintuning erst durch, wenn einfachere Methoden versagen.

Versionieren Sie alles, was wichtig ist: Modell, Quantisierung, Laufzeit, Prompt, Chat-Template, Adapter, Embedding-Modell, Reranker, Evaluierungsset und Hardware-Profil. Lokale Systeme sind nur dann einfacher zu kontrollieren, wenn Sie reproduzieren können, was Sie ausgeführt haben.

Feintuning (Fine-Tuning)

Feintuning verändert das Modellverhalten durch Training auf zusätzlichen Daten. Für lokale Nutzer sind die wichtigsten Methoden LoRA und QLoRA.

LoRA friert das Basismodell ein und trainiert kleine, rangniedrige Adaptergewichte. Das reduziert die trainierbaren Parameter und ermöglicht die Verwaltung mehrerer leichter Adapter. QLoRA erweitert dies, indem es durch ein eingefrorenes, 4-Bit-quantisiertes Basismodell in LoRA-Adapter feintuned.

Führen Sie Feintuning durch, wenn Sie einen konsistenten Schreibstil, ein domänenspezifisches Ausgabeformat, wiederholtes Klassifikations- oder Extraktionsverhalten, Zuverlässigkeit des Tool-Call-Formats, eine spezialisierte Assistenten-Persönlichkeit, eine domänenspezifische Anpassung, die RAG nicht lösen kann, oder eine bessere Leistung kleiner Modelle bei einer engen Aufgabe benötigen.

Feintuning nicht zuerst. Versuchen Sie diese Reihenfolge: korrektes Chat-Template, besseres Prompting, besseres Modell, besseres Decoding, RAG, Reranking, Few-Shot-Beispiele, dann Feintuning.

Die meisten Probleme, die so aussehen, als ob das Modell meine Domäne nicht versteht, sind in Wirklichkeit: mein Prompt ist vage, mein Template ist falsch oder mein Retrieval ist defekt.

Ein guter Feintuning-Plan umfasst saubere Daten, Trainings-/Validierungs-/Testaufteilungen, Baseline-Evaluierungen, klares Zielverhalten, Sicherheitsprüfung, Überanpassungsprüfungen, Regressions-Evaluierungen, Adapter-Versionierung, Lizenzprüfung und einen Rückfallplan.

Offene Gewichte bedeutet nicht Open Source

Im Jahr 2026 wird der Begriff „offenes Modell“ oft schlampig verwendet. Sie sollten zwischen Open-Weight, Source-Available, Opensource und Local-Compatible unterscheiden.

Open-Weight bedeutet in der Regel, dass Sie die Gewichte herunterladen können. Es bedeutet nicht automatisch, dass Sie das Modell kommerziell nutzen, frei modifizieren, mit seinen Ausgaben trainieren, in beliebigem Umfang einsetzen oder die Namensnennungspflicht ignorieren können.

Source-Available bedeutet, dass Code oder Gewichte einsehbar sind. Es bedeutet nicht zwangsläufig, dass die Lizenz Opensource ist.

Opensource-KI-Modell ist eine stärkere Aussage. Die Opensource-KI-Definition der OSI behandelt ein KI-System als Architektur, Parameter/Gewichte, Inferenzcode sowie ausreichende Dateninformationen und Code, die zur Ableitung der Parameter verwendet wurden. Das ist eine deutlich höhere Hürde als „die Gewichte sind auf Hugging Face“.

Manche Lizenzen wirken erlaubend, enthalten aber Einschränkungen: kein wettbewerblicher Einsatz, kein Training auf Ausgaben, keine Bereitstellung über einer bestimmten Größenordnung, geografische Ausschlüsse, Namensnennungspflichten, Patentklauseln oder copyleft-ähnliche Verpflichtungen für Ableitungen.

Faustregel: Lesen Sie die Modellkarte und die Lizenz, bevor Sie ein Modell kommerziell nutzen. Ein Modell kann hervorragend, herunterladbar und lokal ausführbar sein und dennoch schlecht zu Ihren rechtlichen oder betrieblichen Anforderungen passen.

Glossar

Begriffe zu Modellen und Tuning

• Active Parameters: In einem MoE-Modell werden nur einige Parameter für ein bestimmtes Token verwendet. Ein Modell kann Hunderte Milliarden Gesamtparameter haben, aber weit weniger aktive Parameter pro Token.
• Adapter: Ein kleines, trainierbares Modul, das zu einem Basismodell hinzugefügt wird, oft durch LoRA.
• Base Model: Ein vortrainiertes Modell, das nicht speziell für Chat oder Befehlsbefolgung getuned wurde.
• Fine-Tuning: Zusätzliches Training, das das Modellverhalten für eine Ziel-Domäne oder einen Ausgabestil ändert.
• Instruct Model: Ein Modell, das darauf getuned wurde, Anweisungen zu befolgen.
• LoRA / QLoRA: Effiziente Feintuning-Methoden unter Verwendung rangniedriger Adapter, wobei QLoRA durch quantisierte Basismodelle trainiert.
• MoE: Mixture of Experts. Eine sparse Architektur, bei der nur ausgewählte Experten-Subnetzwerke pro Token aktiviert werden.
• Weights / Parameter: Die gelernten numerischen Werte innerhalb des Modells.

Inferenz-Mechanik

• BOS / EOS: Beginning-of-Sequence und End-of-Sequence-Token.
• Chat Template: Die Formatierung zur Darstellung von System-, Benutzer-, Assistenten- und Tool-Nachrichten.
• Context Window: Die maximale Anzahl an Token, die das Modell gleichzeitig verarbeiten kann.
• Decode: Die Phase, in der das Modell neue Token nacheinander generiert.
• DFlash: Ein 2026er Ansatz des spekulativen Decodings, der Blockdiffusion für paralleles Drafting nutzt.
• DDTree / DTree: Eine Methode des spekulativen Decodings, die einen Draft-Baum aus Blockdiffusionsverteilungen erstellt und effizient verifiziert.
• GQA / MQA: Aufmerksamkeitsvarianten, die die KV-Cache-Größe reduzieren und die Inferenzeffizienz verbessern.
• Inference: Das Ausführen des Modells zur Erzeugung von Ausgaben.
• KV Cache: Gespeicherte Key/Value-Aufmerksamkeitszustände für vorherige Token.
• Prefill: Die Phase, in der das Modell den Eingabe-Prompt vor der Generierung verarbeitet.
• RoPE: Rotary Position Embeddings, eine bei modernen LLMs übliche Methode zur Positionskodierung.
• Speculative Decoding: Eine Geschwindigkeitstechnik, bei der ein günstigerer Draft-Token vorschlägt und das Zielmodell diese verifiziert.
• Tokenizer: Die Komponente, die Text in Token-IDs umwandelt und zurück.
• Top-p / Top-k / Temperature: Sampling-Kontrollen für die Tokengenerierung.

Retrieval, Dateien und Serving

• AWQ: Activation-aware Weight Quantization.
• Embedding Model: Ein Modell, das Text in Vektoren für die Suche/Retrieval umwandelt.
• FP8 KV Cache: Ein praktischer 8-Bit-KV-Cache-Komprimierungsmodus, der in einigen Laufzeiten unterstützt wird.
• GGUF: Ein Modell-Dateiformat, das stark von llama.cpp verwendet wird.
• PagedAttention: Eine Speicherverwaltungstechnik für den KV-Cache, die von vLLM-ähnlichem Serving verwendet wird.
• Quantization: Reduzierung der numerischen Genauigkeit, um Speicher zu sparen und die Effizienz zu verbessern.
• RAG: Retrieval-Augmented Generation. Relevante externe Kontexte abrufen und dem Modell zur Verfügung stellen.
• Reranker: Ein Modell, das abgerufene Passagen nach Relevanz neu ordnet.
• Safetensors: Ein sichereres Tensor-Serialisierungsformat, das pickle-basierte Ausführungsrisiken vermeidet.

Schlusswort

Das lokale LLM-Ökosystem umfasst kompakte Edge-Modelle, starke 7B- bis 32B-Verbrauchermodelle, große Open-Weight-MoE-Systeme, multimodale Modelle, Langkontext-Modelle, lokale Reasoning-Modelle, ausgereifte Inferenz-Laufzeiten und zunehmend leistungsfähige private Serving-Stacks.

Aber die Grundlagen haben sich nicht geändert: Das Modell sagt jeweils ein Token voraus, Token sind keine Wörter, Gewichte sind nicht das gesamte Modell, Chat-Templates sind wichtig, der KV-Cache ist die versteckte Speicherrechnung, Quantisierung ist ein Kompromiss, langer Kontext ist nicht kostenlos, RAG-Qualität hängt vom Retrieval ab, Feintuning benötigt Evaluierungen und lokale Privatsphäre erfordert dennoch Sicherheitsdisziplin.

Sie brauchen keine Mythen, um lokale Modelle gut zu betreiben. Sie müssen wissen, was in den Speicher passt, welches Template das Modell erwartet, wie sich die Laufzeit verhält und ob Ihre Evaluierungen zu der Arbeit passen, die Ihnen wichtig ist.

Lokale LLMs sind meistens Speicher-Mathematik plus Formatierung plus Evaluierung. Wenn Sie das richtig hinbekommen, wird der Rest des Stacks viel einfacher zu durchschauen.

Bis zum nächsten Mal.

-Ahmad