Vier Schichten für lokale SLMs: Ein neues Framework ordnet den AI-Stack

Vier Schichten für lokale SLMs: Das neue Framework im Überblick

Ein neuer Leitfaden strukturiert den lokalen AI-Stack für Small Language Models (SLMs) in vier Schichten. Das Framework ist konzeptionell, kein offizielles Produkt, und soll Entwicklern helfen, die passenden Werkzeuge für ihre Hardware und ihren Workflow auszuwählen. Als SLMs gelten dabei offene Modelle mit etwa 1 bis 14 Milliarden Parametern, die auf Consumer-Hardware mit 8 bis 24 GB VRAM oder auf Apple Silicon laufen. Die erste Schicht, die Engine-Ebene, umfasst Ollama, LM Studio und llama.cpp. Alle drei basieren auf derselben Inference-Engine, unterscheiden sich aber in Bedienung und Integration. Die zweite Schicht bilden Hochdurchsatz-Serving-Engines wie vLLM und SGLang, die für produktive Workloads mit vielen gleichzeitigen Anfragen ausgelegt sind. Die dritte Schicht ist der komplette Stack: LocalAI bündelt mehrere Backends für Text, Bild, Sprache und mehr hinter einer API. Die vierte Schicht betrifft die Evaluierung: Bench360 integriert System- und Task-spezifische Metriken, um lokale LLM-Inferenz zu bewerten. Das Framework ordnet damit erstmals die wichtigsten Tools systematisch ein und macht die Auswahlentscheidung nachvollziehbar.

Inference-Engines im Vergleich: Ollama, LM Studio und llama.cpp

Ollama, LM Studio und llama.cpp teilen sich eine Gemeinsamkeit: Alle drei nutzen die llama.cpp Inference Engine. Ollama bündelt einen eingebetteten Build, LM Studio einen eigenen Build, und llama.cpp ist die Engine selbst. Bei gleichem Seed und gleichen Parametern liefern die drei identische Token-für-Token-Ausgaben. Die Unterschiede liegen im Workflow. Ollama bietet eine REST API, eine Modellbibliothek mit vorkonfigurierten Quantisierungen und einen Ein-Befehl-Start. LM Studio setzt auf eine grafische Oberfläche und bündelt ebenfalls einen llama.cpp-Build. llama.cpp erfordert manuelle Kompilierung und bietet maximale Kontrolle über Quantisierung und Multi-GPU-Setups. Die Wahl ist damit eine Frage des Arbeitsstils, nicht der Modellqualität: Ollama eignet sich für die meisten Nutzer, LM Studio für GUI-orientierte, llama.cpp für jene, die jede Einstellung selbst festlegen wollen.

Hochdurchsatz-Serving: vLLM und SGLang für produktive Workloads

Für produktive Workloads mit vielen gleichzeitigen Anfragen sind vLLM und SGLang ausgelegt. vLLM nutzt PagedAttention, um den KV-Cache-Speicher zu optimieren und so hohen Durchsatz zu erreichen. Das Verfahren zahlt sich besonders aus, wenn der Speicher die Batch-Größe begrenzt. SGLang setzt auf RadixAttention: Ein Radix-Baum speichert KV-Cache-Präfixe, die bei geteilten Präfixen wiederverwendet werden. Das bringt Vorteile bei Multi-Turn-Chats, Agenten-Schleifen oder langen festen System-Prompts, in denen viele Anfragen denselben Präfix teilen. Bei einzigartigen Prompts ist der Gewinn dagegen gering. Welche Engine schneller ist, hängt also vom Verkehrsmuster ab: SGLang gewinnt bei wiederholten Präfixen, vLLM bei einmaligen Anfragen oder wenn der Speicher der Engpass ist.

LocalAI und Bench360: Kompletter Stack und Evaluierung

LocalAI ist ein MIT-lizenzierter, komposabler lokaler AI-Stack. Er stellt OpenAI-kompatible, Anthropic-kompatible und Responses-APIs bereit und lädt separate Backends für Sprache, Bild, Video, Sprache, Embeddings, Reranking und Agenten. Damit eignet er sich für Betreiber, die eine breite lokale API über viele Modelltypen hinweg benötigen, nicht für Nutzer, die nur ein einzelnes Chat-Modell ausführen wollen. Bench360 ist ein Benchmark-Framework, das System- und Task-spezifische Metriken für lokale LLM-Inferenz integriert. Es erlaubt Nutzern, eigene Aufgaben und Datensätze zu definieren und automatisch Modelle, Engines und Quantisierungsstufen in verschiedenen Szenarien zu testen – vom Einzelstream bis zum Server-Betrieb. Erfasst werden unter anderem Latenz, Durchsatz, Energieverbrauch und Task-Metriken wie ROUGE oder F1.

Der Widerspruch: Gleiche Engine, unterschiedliche Leistung?

Ein Widerspruch zieht sich durch die Bewertung der drei Engines. Eine Position besagt, dass Ollama, LM Studio und llama.cpp identische Token-für-Token-Ausgaben liefern und die Wahl daher nur eine Frage des Workflows sei. Eine andere Position berichtet von messbaren Leistungsunterschieden, wobei llama.cpp die höchste Leistung biete. Der Widerspruch löst sich auf, wenn man die Ursache betrachtet: Die Unterschiede entstehen durch Overhead und Implementierungsdetails der Wrapper Ollama und LM Studio, nicht durch die zugrunde liegende Engine selbst. llama.cpp als direkter Zugriff auf die Engine hat weniger Overhead, während die Wrapper zusätzliche Prozesse und Abstraktionsschichten mitbringen. Die Token-Ausgabe bleibt gleich, aber Durchsatz und Latenz können variieren.

Grenzen kleiner Modelle: Fehlerhafte Tool-Calls unter 7B

Eine klare Grenze zeigt sich bei Tool-Calls: Modelle mit weniger als 7 Milliarden Parametern erzeugen oft fehlerhafte Aufrufe, unabhängig davon, welches Agenten-Framework sie einbindet. Größere Modelle sind in der Regel zuverlässiger. Die Zuverlässigkeit von Tool-Calls ist damit eine Eigenschaft des Modells, nicht des umgebenden Harness. Für Anwendungen, die auf strukturierte Tool-Nutzung angewiesen sind, sind Modelle unter 7B Parametern daher nur eingeschränkt geeignet.