Startseite / Artikel / LLMOps für kleine Sprachmodelle: Servierungsframeworks und Produktionsleitfäden

LLMOps für kleine Sprachmodelle: Servierungsframeworks und Produktionsleitfäden

Warum SLMs bei Kosten und Privatsphäre gewinnen, wie sich vLLM, SGLang, TGI, llama.cpp, Ollama, WebLLM, ONNX und TensorRT-LLM vergleichen lassen, sowie wie man sie in der Produktion quantifiziert, bewertet und einsetzt.

4127 Wörter

Praktische LLMOps für kompakte Sprachmodelle: Wann lokale oder gerätebasierte Inferenz den State-of-the-Art-APIs überlegen ist, welche Bereitstellungsstacks zu welchen Hardware-Beschränkungen passen und wie man sie nach dem ersten erfolgreichen Aufruf stabil hält.

Einführung

Zwischen dem Ansatz „Das größte Modell für alles feinabstimmen“ und „Ein Modell mit weniger als einer Milliarde Parametern auf einem Smartphone ausführen“ haben sich die Prioritäten in der Produktion verschoben. Viele Aufgaben – wie Intent-Klassifizierung, Tool-Routing, strukturierte Extraktion oder RAG-Re-Ranking – benötigen keine hochleistungsstarken Modelle, sobald ein solides SLM quantifiziert und gut bereitgestellt wird.

Das Problem: Ein SLM ohne Bereitstellungsstrategie ist lediglich ein Checkpoint auf der Festplatte. Seine Nutzung in der Produktion wirft Fragen zu GPU-Memory-Verbrauch, Batching, Quantisierungsqualität, Rollback-Mechanismen und Bewertungsmethoden auf, die in klassischen MLOps-Leitfäden kaum behandelt werden.

Ein Modell, das man nicht einsetzen, überwachen oder zurücksetzen kann, ist kein Produktivressourcen – es ist eine Belastung mit attraktiven Vergleichswerten.

Dieser Leitfaden behandelt nacheinander das Problem, die verfügbaren Frameworks sowie ein Playbook für die Produktivumsetzung. Der Prozess ist kontinuierlich: Ein Checkpoint wird erst dann zu einer nutzbaren Funktion, nachdem er die Tests zur Bereitstellung, Bewertung und Betriebsfähigkeit bestanden hat.

Das Problem: Warum „größere Modelle“ nicht mehr die Standardlösung sind

1. Kosten und Latenz nehmen im großen Maßstab zu

Das Senden einer einfachen Anfrage zur Ticket-Klassifizierung an ein 70B-Modell verschwendet Kapazitäten. Zusätzliche Parameter erbringen Funktionen, die man vielleicht gar nicht benötigt, während gleichzeitig die GPU-Zeit und die Latenz bei hoher Konkurrenz zunehmen. Im Produktionsmaßstab dominieren diese Kosten.

2. Datenlast und Datenschutz zwingen zur Inferenz am Edge

Im Gesundheitswesen, in der Finanzbranche sowie bei Endgeräte-basierten Anwendungen können Rohtexte oft nicht an eine API Dritter übermittelt werden. Ein SLM, der in wenige Gigabyte RAM passt, kann direkt neben den Daten – auf lokalen GPUs, Laptops oder Handys – betrieben werden und somit die Residenzanforderungen erfüllen, die ein Cloud-Modell nicht kann.

3. Die Bereitstellungsinfrastruktur weist eigene Ausfallmöglichkeiten auf

Der Modellbetrieb versagt anders als bei gewöhnlichen Anwendungsfehlern: Durch Fragmentierung des GPU-Speichers durch naive KV-Cache-Verwaltung, Ausfall des Scheduler bei plötzlichem Traffic-Anstieg, Inkonsistenzen bei der Quantisierung, die leise zu einer Qualitätsminderung führen, sowie sogenannte „Cold Starts“, die nach einer Skalierung auf Null die vereinbarten Leistungsstandards überschreiten.

4. LLMOps ist eine eigenständige Disziplin im Vergleich zu MLOps

Klassische MLOps gehen von relativ stabilen Strukturen und deterministischen Ergebnissen aus. LLMOps hingegen berücksichtigen nicht-deterministische Texte, Versionen von Prompts und Tools, Token-Ökonomien sowie Sicherheitsfilter. Regression bedeutet nicht mehr nur „Genauigkeit um 2 % gesunken“ – es kann auch „Nichtbeachtung des JSON-Schemas“ oder „Einbruch der p95-Token pro Sekunde nach einem Treiberupdate“ bedeuten.

Was ist LLMOps und wie unterscheidet es sich von MLOps?

LLMOps befasst sich damit, wie Teams Sprachmodelle in laufenden Systemen bereitstellen, hosten, überwachen und verbessern – mit derselben operativen Sorgfalt wie bei jedem anderen kritischen Service.

Während MLOps prüft, ob die Genauigkeit nachgelassen hat, fragt LLMOps außerdem:

Wird die GPU-Memory unter Konkurrenzbedingungen effizient genutzt?
Bleibt das quantisierte Ergebnis für diese Aufgabe ausreichend genau?
Sind die Versionen von Prompts/Tools festgelegt und rollbar?

Kann der Datenverkehr zwischen Modellen ohne Neuschreiben am Client umgeleitet werden?

Geben die Protokolldaten Aufschluss über den Tokenkosten und die Latenz pro Route?

Der Rest dieses Leitfadens beantwortet diese Fragen speziell für SLMs.

Das Landschaftsbild der SLM-Implementierungsframeworks

Was die reine GPU-Leistung angeht, ist vLLM eine gängige Wahl für hohe Anfragenraten, da es über eine mit OpenAI kompatible API auf NVIDIA- oder AMD-GPUs verfügt. SGLang ist konkurrenzfähig, wenn die Wiederverwendung von Präfixen und strukturierte Generierung wichtig sind. Hugging Face TGI eignet sich für Teams, die bereits auf den Hub und Helm-Charts standardisiert sind.

Auf der mobilen Seite läuft llama.cpp / GGUF auf CPUs, Apple Silicon sowie vielen Consumer-GPUs. Ollama bündelt diese Technologien zu einer zweikommandigen Lösung für den lokalen Einsatz. LM Studio bietet eine Desktop-GUI zur Bewertung. MLC-LLM / WebLLM werden für Browser und Mobilgeräte kompiliert. ONNX Runtime GenAI ist für Windows/NPU sowie unternehmensspezifische ONNX-Standards konzipiert. TensorRT-LLM + Triton zielt auf maximale Leistung in NVIDIA-Geräten durch vorabige Kompilierung ab.

Jede dieser Lösungen wandelt Checkpoints in Antworten um; sie unterscheiden sich in ihren Hardware-Anforderungen, den Rechenoperationen sowie dem Konzept der Parallelisierung.

Erfassende Einblicke in Frameworks

vLLM

vLLM hat PagedAttention populär gemacht, wodurch der KV-Cache ähnlich wie virtuelle Speicher verwaltet wird, sodass parallele Verarbeitungen weniger GPU-RAM verbrauchen. Kontinuierliches Batching hält die Auslastung hoch.

# Install vLLM
pip install vllm

# Serve using VLLM
vllm serve Qwen/Qwen2.5–1.5B-Instruct - port 8000 # fully OpenAI-compatible endpoint


# Make Request
curl http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

# Python Script for vllm

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5–1.5B-Instruct",
    messages=[{"role": "user", "content": "Summarize LLMOps in one sentence."}],
)
print(resp.choices[0].message.content)

Am besten geeignet für: Hoch-QPS-Backends sowie RAG-Dienste, die OpenAI-kompatible Endpunkte benötigen. Vorteile: Durchsatz, Modellabdeckung, Quantisierungsformate (AWQ/GPTQ/FP8). Nachteile: GPU-orientiert; erfordert weiterhin Orchestrierung für Hochverfügbarkeit.

SGLang

SGLang basiert auf RadixAttention, um Präfixcaches bei verwandten Anfragen zu teilen – besonders nützlich für Agentenzyklen mit wiederholten Systemanfragen – und bietet eine sgl.function DSL für strukturierte Generierung.

# Installation
pip install "sglang[all]"

# SGLang launch server
python -m sglang.launch_server \
 - model-path Qwen/Qwen2.5–1.5B-Instruct \
 - port 30000


# CURL Request
curl http://localhost:30000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

import sglang as sgl

@sgl.function
def classify(s, ticket):
  s += sgl.user(f"Classify this support ticket as billing/technical/other: {ticket}")
  s += sgl.assistant(sgl.gen("label", max_tokens=8))

sgl.set_default_backend(sgl.RuntimeEndpoint("http://localhost:30000"))
state = classify.run(ticket="My invoice charged me twice this month")
print(state["label"])

Am besten geeignet für: Agenten-Pipelines sowie eingeschränkte JSON-Ausgaben. Vorteile: Wiederverwendung von Präfixen, strukturierte Ausgaben. Nachteile: Kleineres Ökosystem als vLLM; ausschließlich GPU-basiert.

Hugging Face Text Generation Inference (TGI)

TGI integriert sich in das Hub-Ecosystem durch eine für Docker/Kubernetes geeignete Verpackung.

docker run - gpus all -p 8080:80 \
-v $PWD/data:/data \
ghcr.io/huggingface/text-generation-inference:latest \
 - model-id microsoft/Phi-3.5-mini-instruct \
 - quantize bitsandbytes-nf4

from huggingface_hub import InferenceClient
client = InferenceClient("http://localhost:8080")
print(client.text_generation("Explain quantization in one line.", max_new_tokens=64))

Am besten geeignet für: auf Hub ausgerichtete Teams sowie regulierte Systemlandschaften, die einen unterstützten Bereitstellungsweg benötigen. Vorteile: Integration in Hub, Quantisierungsoptionen, Helm-Unterstützung. Nachteile: Einige Workloads bevorzugen weiterhin vLLM wegen der höheren Durchsatzrate; beobachten Sie im Laufe der Zeit die Lizenzbedingungen.

llama.cpp / GGUF

Entwickelt, um LLaMA auf der CPU eines MacBook zu betreiben, bildet llama.cpp dank GGUF-Quantisierung die Grundlage für viele lokale/edge-basierte SLM-Lösungen.

# macOS: brew install llama.cpp   |   or build from source:
# git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp && cmake -B build && cmake --build build

# Pull a quantized SLM straight from Hugging Face and serve an OpenAI-compatible endpoint
llama-server -hf Qwen/Qwen2.5-0.5B-Instruct-GGUF:Q4_K_M \
    --port 8090 -c 4096 -ngl 999   # -ngl offloads layers to GPU if available (Metal/CUDA)

curl http://localhost:8090/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"What is GGUF?"}]}'

Am besten geeignet für: CPU-Server, Apple Silicon sowie Pi/edge-Geräte ohne CUDA. Vorteile: Portabilität, ausgereifte Quantisierungsstufen, MIT-Lizenz. Nachteile: Die gleichzeitige Durchsatzrate liegt hinter GPU-basierten Lösungen zurück.

Ollama

Ollama umhüllt llama.cpp in ein „Pull-and-Run“-Entwicklererlebnis mit einer lokalen HTTP-API.

ollama pull qwen2.5:1.5b
ollama run qwen2.5:1.5b "Write a haiku about model quantization"

import requests
r = requests.post("http://localhost:11434/api/chat", json={
  "model": "qwen2.5:1.5b",
  "messages": [{"role": "user", "content": "Give me 3 LLMOps metrics to track"}],
  "stream": False,
})
print(r.json()["message"]["content"])

Am besten geeignet für: lokale Entwicklung, Prototypen sowie Selbsthosting in kleinen Teams. Vorteile: gute Entwicklererfahrung und Standardeinstellungen. Nachteile: nicht für hochparallele Produktionsumgebungen konzipiert.

LM Studio

Eine Desktop-GUI zu ähnlichen lokalen Engines zum Durchsuchen, Herunterladen und Chatten – zusätzlich ein mit einem Klick verfügbarer OpenAI-kompatibler Server für Demonstrationen. Ideal zur Bewertung vor der Erstellung von Bereitstellungsanleitungen; kein Infrastrukturkomponenten für Skalierung.

MLC-LLM / WebLLM

Basiert auf Apache TVM: MLC kompiliert Modelle für verschiedene Backend-Systeme; WebLLM läuft vollständig im Browser.

pip install mlc-llm

mlc_llm chat HF://mlc-ai/Qwen2.5-1.5B-Instruct-q4f16_1-MLC

// WebLLM: fully in-browser inference, no backend server
import * as webllm from "@mlc-ai/web-llm";

const engine = await webllm.CreateMLCEngine("Qwen2.5-1.5B-Instruct-q4f16_1-MLC");
const reply = await engine.chat.completions.create({
  messages: [{ role: "user", content: "Explain WebGPU inference simply." }],
});
console.log(reply.choices[0].message.content);

Am besten geeignet für: Mobile-Apps, clientseitige Inferenz unter Wahrung der Privatsphäre sowie Offline-Funktionen. Vorteile: Kompilierung für verschiedene Ziele; kein Server erforderlich für WebLLM. Nachteile: Komplexität bei der Kompilierung; Einschränkungen durch die Browser-Hardware.

ONNX Runtime GenAI

Microsofts GenAI-API erweitert ONNX Runtime um Funktionen für autoregressive Generierung sowie Verwaltung von KV-Caches über Windows DirectML und NPUs.

pip install onnxruntime-genai

python -c "
import onnxruntime_genai as og
model = og.Model('phi-3.5-mini-onnx-directml')
tokenizer = og.Tokenizer(model)
tokens = tokenizer.encode('Explain ONNX Runtime GenAI briefly.')
params = og.GeneratorParams(model)
params.set_search_options(max_length=200)
generator = og.Generator(model, params)
generator.append_tokens(tokens)
while not generator.is_done():
    generator.generate_next_token()
print(tokenizer.decode(generator.get_sequence(0)))
"

Am besten geeignet für: Windows-eigene Apps sowie Unternehmen, die den ONNX-Standard nutzen. Vorteile: Portierbarkeit nach der Exportierung. Nachteile: Schwierigkeiten bei der Konvertierung; kleinere Community im Vergleich zu PyTorch-basierten Engines.

NVIDIA TensorRT-LLM + Triton Inference Server

TensorRT-LLM führt im Voraus Kompilierungen mit verschmolzenen Kernen durch; Triton ermöglicht die Verwaltung mehrerer Modelle gleichzeitig.

# Build a TensorRT-LLM engine for a small model (simplified)
trtllm-build --checkpoint_dir ./qwen2.5-1.5b-checkpoint \
    --output_dir ./qwen2.5-1.5b-engine \
    --gemm_plugin float16

# Serve via Triton
tritonserver --model-repository=/models

Am besten geeignet für: maximale Durchsatzraten in NVIDIA-Systemen sowie Anwendungen mit kritischen Latenzanforderungen. Vorteile: Höchste Leistung nach der Kompilierung. Nachteile: Die Engines sind spezifisch für bestimmte SKU-Modelle und Formate; Neu-Kompilierungen sind nach Änderungen am Hardware-Profil oder in Batch-Scenarios erforderlich.

Framework auswählen: Ein Entscheidungshilfe

Ein mentaler Modell: Drei Fragen statt einer Funktionsliste

Frage 1: Wo muss das Modell physisch ausgeführt werden? Browser oder Telefon ohne Netzwerkverbindung → WebLLM/MLC. CPU/Apple/edge ohne CUDA → llama.cpp/Ollama. Erst danach sollten GPU-basierte Engine für Rechenzentren in Betracht gezogen werden.

Frage 2: Dient dies der Produktivnutzung oder der explorativen Nutzung? Explorative Nutzung → LM Studio oder Ollama. Produktions-API → vLLM/SGLang/TGI/TensorRT, abhängig von der nächsten Frage.

Frage 3 (nur GPU-Produktion): Wie sieht das Traffic-Muster aus und wie hoch ist das Budget für die Ingenieurarbeit? Unabhängige, einmalige Bearbeitungen → vLLM als Standard. Sehr repetitive Agenten-Strukturen / strukturierte Ausgaben → SGLang. Maximale NVIDIA-Optimierung mit Plattform-Investitionen → TensorRT-LLM + Triton. Komfort bei Hub/Helm-Anwendungen → TGI.

Komprimierte Übersicht:

Maximale Durchsatzrate der GPU-API → vLLM (oder SGLang bei repetitiven/agentbasierten Anwendungen)
Absoluter NVIDIA-Höchstwert mit Kompilierbudget → TensorRT-LLM + Triton
CPU/Apple/Edge-Geräte → llama.cpp; DX-Wrapper → Ollama
Browser/Offline-Klienten → WebLLM/MLC
Windows/NPU/ONNX-Standard → ONNX Runtime GenAI
Bewertung per Klick → LM Studio

Unternehmensweite Agentensysteme im Vergleich zu allen anderen Lösungen

Einzelne Anfragen und Antworten profitieren von kontinuierlichem Batching in vLLM. Unternehmensagenten rufen das Modell oft dutzende Male pro Aufgabe auf – zur Planung, Auswahl von Werkzeugen, Beobachtung oder Neuplanung – weshalb Präfix-Caching und strukturierte Ausgaben eine zentrale Rolle spielen. Solche Implementierungen kommen häufig auf SGLang oder TensorRT-LLM + Triton auf selbst gehosteten GPUs zum Einsatz, wobei TGI eine Alternative darstellt, wenn die Integration in den Hub mehr Gewicht hat als die maximale Durchsatzleistung.

Mehrfachnutzer-Agentenplattformen benötigen außerdem Quoten pro Benutzer, Nachverfolgung aller Aktionen über Werkzeugaufrufe sowie eine klare Rücksetzung von Prompt- und Modellpaaren – das sind LLMOps-Probleme, die über jeden einzelnen Engine hinausgehen.

Führer zur Produktivumsetzung

Das Laufenlassen einer Lösung macht nur etwa ein Fünftel der Arbeit aus. Der Rest besteht darin, sie korrekt, kostengünstig und sicher zu halten.

Betrachten Sie Quantisierung, Registry, Bewertung, Canary-Tests und Routing als einen Kreislauf, den jede Modellversion durchläuft:

1. Quantisierungsstrategie. In vielen Produktionsumgebungen für SLMs wird standardmäßig AWQ-4bit oder GGUF Q4_K_M verwendet – bei sorgfältiger Bewertung liegen die Ergebnisse in der Regel nur wenige Prozent abseits der FP16-Metriken – und es muss überprüft werden, dass der gewählte Engine das Format unterstützt. Quantisierung ist keine einmalige Umwandlung; sie endet an einer Bewertungsstelle, nicht beim Konvertierungsbefehl.

2. Modellversionierung und Registry. Feinabstimmungen sowie quantisierte Modelle sollten als unveränderliche, versionierte Objekte behandelt werden – sie dürfen niemals direkt überschrieben werden. MLFlow, Hugging Face Hub-Repos mit Digests oder eine interne OCI-Registry für Modelle funktionieren alle, sofern die Digests in den Deploy-Manifesten festgelegt sind.

3. Bewertungsregeln. Für die jeweilige Aufgabe sollte eine „goldene“ Metrikenliste aufrechterhalten werden: Klassifizierungs-F1-Wert, Genauigkeit bei der Extraktion von Feldern, Gültigkeitsrate des Schemas, Richtigkeit von Ablehnungen sowie Latenzbudgets. Der Übergang in die Produktionsumgebung sollte blockiert werden, wenn diese Regeln nicht erfüllt sind – auch dann nicht, wenn die Demoversionen besser aussehen.

4. Servier-Topologie. Trennen Sie bei Bedarf die CPU-basierten Tokenisierer/Vorverarbeitungsschritte von den GPU-Arbeitern; skalieren Sie automatisch je nach Warteschlangentiefe und GPU-Nutzung, nicht nur nach RPS. Halten Sie einen „warmen“ Pool bereit, falls Kaltstarts die SLOs verletzen.

5. Überwachbarkeit. Exportieren Sie die Anfragedauer, die Anzahl der eingehenden/Ausgehenden Tokens, die Cache-Erfolgsraten, die Batch-Größe sowie die Zahlen zu Out-of-Memory-Fällen und Wiederholungsversuchen. Entnehmen Sie Beispiele für Anfragen sorgfältig unter Berücksichtigung der Datenschutzrichtlinien.

6. Rollbacks. Verwenden Sie ein Blue/Green- oder Canary-Modellkonzept basierend auf dem Modellzusammenfassung sowie der Anfrageversion als Ganzes. Kehren Sie sofort zu beiden Versionen zurück, wenn die Qualität plötzlich abfällt.

7. A/B-Testing und Mehr-Modell-Routing

Routen Sie nach Aufgabe: SLMs für Klassifizierung und Extraktion; größere Modelle für offene Generierungsanfragen. Leiten Sie vor dem Umstieg Testverkehr an die Alternativmodelle um. Erfassen Sie den Kosten pro erfolgreich abgeschlossener Aufgabe – nicht nur die Anzahl der Tokens –, damit ein günstigeres Modell, das zweimal versucht, nicht fälschlicherweise als Sieger gilt.

Feature Flags sollten Client-Routen mit benannten Modell-Endpunkten hinter dem Gateway verbinden, damit Änderungen keine App-Veröffentlichungen erfordern.

Domain-Szenarien

Konsumenten-/Mobile Apps

Bevorzugen Sie SLMs vor Ort oder in der Nähe des Geräts mithilfe von MLC/WebLLM oder GGUF auf den Gerätetreibern. Planen Sie den Speicherbedarf sorgfältig; streamen Sie Tokens für eine gute Benutzererfahrung; halten Sie einen Cloud-Notfallplan für schwierige Abfragen bei klarer Einwilligung bereit.

Weitere Bereiche (Support-Copiloten, interne RAG-Systeme, Edge-Gateways) folgen demselben Muster: Zuerst die Hardware-Voraussetzungen berücksichtigen, anschließend den Engine-Typ und schließlich die Quantisierungs- sowie Evaluierungslogik.

Fehlkonzepte

Veröffentlichung von FP16-Modellen „aus Gründen der Qualität“, ohne eine quantisierte Baseline im echten Einsatz zu testen
Verwendung von Ollama/LM Studio-Topologien für hochwertige Produktionssysteme mit hohem QPS ohne einen für Konkurrenzfähigkeit konzipierten Server-Engine
Überschreiben der Modelldateien direkt vor Ort, wodurch Rollbacks unmöglich werden

Bewertung ausschließlich anhand von „Vibe Checks“ statt anhand von hochwertigen Ergebnissen.
Ignorieren des KV-Caches sowie von Batch-Metriken, bis in der Produktion die GPU-Ressourcen erschöpft sind.
Anderungsanfragen an die Prompts als kostenlos betrachten, während Modelle festgelegt werden – oder umgekehrt.

Kernpunkte

SLMs sind vorteilhaft, wenn die Aufgaben begrenzt sind, die Daten das System nicht verlassen dürfen oder Budgetbeschränkungen hinsichtlich Kosten und Latenz frontier-Modelle ausschließen.
LLMOps erweitert MLOps um Aspekte wie Effizienz bei der Bereitstellung, Präzision bei der Quantisierung, Versionierung von Prompts und Tools sowie Token-Ökonomie.
Wählen Sie Engine entsprechend der Einsatzumgebung (Gerät/CPU/GPU), des Entwicklungsstadiums (Erkundung vs. Bereitstellung) sowie der Verkehrsmuster (einzelfallbasiert vs. agiert).
Erfolg in der Produktion folgt einem Zyklus: Quantisieren → Registrieren → Bewertung → Testbetrieb → Beobachten → Rücksetzen.
Kombinieren Sie stabile Modelldarstellungen mit einer Türklingel-basierten Routing-Logik, damit Kunden stabil bleiben, während sich die Backend-Systeme weiterentwickeln.

Referenzen

Konsultieren Sie die offizielle Dokumentation jedes Projekts bezüglich der Installationsflags und Versionspins: vLLM, SGLang, Hugging Face TGI, llama.cpp, Ollama, LM Studio, MLC-LLM/WebLLM, ONNX Runtime GenAI sowie NVIDIA TensorRT-LLM/Triton. Hardware-Anleitungen von NVIDIA und Apple Metal-Dokumentationen ergänzen die READMEs der Engines bei der Anpassung von Batch-Größen und Quantisierungen.

Halten Sie ein internes Runbook bereit, in dem festgehalten wird, welche Verarbeitungsmethoden mit welchen „Golden Sets“ auf welchen GPU-Modellen verwendet wurden – dieses Dokument macht die Übersichtsanleitung zu einer nutzbaren Plattform.

Anhang: Betrieb von SLMs von Woche Zwei bis Woche Zwanzig

Nach dem ersten erfolgreichen curl-Aufruf an einen lokalen Server tauchen die schwierigen Fragen auf: Wer ist für den Notdienst zuständig, wie werden CUDA-Driver-Updates geplant, und was passiert, wenn eine Marketingkampagne die QPS über Nacht verdreifacht? Beantworten Sie diese Fragen schriftlich, bevor das erste Canary-Release erfolgt.

Die Kapazitätsplanung für SLMs benötigt weiterhin Puffer für das Wachstum des KV-Caches im Zusammenhang mit der Kontextlänge. Ein 1,5-Billionen-Model, das bei einer Kontextlänge von 2k winzig erscheint, kann den Speicher belasten, wenn Clients Fenster mit 32k Kontextlänge öffnen. Der p95-Wert der Kontext-Token sollte getrennt von der Anfragenrate erfasst werden.

Sicherheitsüberprüfungen sollten die Lieferkette der Modelle abdecken: Prüfung von Checksummen bei der Herunterladung, Bestimmung, wer im Registry veröffentlichen darf, sowie Überprüfung, ob Systemanfragen mit sensiblen Daten jemals in Client-Pakete gelangen. Gerätebasierte Modelle benötigen genauso sorgfältige Aktualisierungsprozesse wie die Veröffentlichung von mobilen Apps.

Kostenanalysen sollten die Gesamtbetriebskosten vergleichen: Mietkosten für GPUs, Zeitaufwand der Entwickler für die Neukompilierung mit TensorRT sowie Qualitätsprobleme durch aggressive Quantisierung. Manchmal ist ein etwas größeres 8-Bit-SLM günstiger als ein winziges Modell, das zu manuellen Eingriffen zwingt.

Die Schulung des Teams ist wichtig. Bieten Sie Anwendungsentwicklern einen einfachen Weg: eine Helm-Chart oder ein Compose-File, eine standardmäßige OpenAI-kompatible Basis-URL sowie bereits vorbereitete Dashboards. Bieten Sie ML-Entwicklern ebenfalls einen einfachen Weg, um Digests zu veröffentlichen, die die erforderlichen Prüfungen bestehen. Die meisten Fehler entstehen bei der Abstimmung zwischen diesen Gruppen.

Zuletzt sollte man vierteljährlich anhand von Daten die Versuchung eines „größeren Modells“ überprüfen. Wenn der goldene Score eines SLM stagniert, während die Benutzeraufgaben schwieriger werden, sollte man gezielt upgraden – schrittweise und nach festgelegten Routen – anstatt das gesamte System über Nacht zu ersetzen. LLMOps für SLMs bedeutet genauso sehr Zurückhaltung wie Beschleunigung.

Operative Anmerkung: Speichern Sie in Lockfiles die genauen Versionen der CUDA-Stacks fest und notieren Sie neben jedem erfolgreichen Canary-Test die Treiberversion, damit bei Störungen Regressionen in den Software- und Firmware-Ebenen präzise eingegrenzt werden können.

Betriebshinweis: Legen Sie in den Lockfiles die genauen Wheel-Versionen für CUDA-Stacks fest und notieren Sie neben jeder erfolgreichen Canary-Version die Treiberversion, damit Regressionen während von Vorfällen zwischen Software- und Firmware-Ebenen eingegrenzt werden können.

Betriebshinweis: Legen Sie in den Lockfiles die genauen Wheel-Versionen für CUDA-Stacks fest und notieren Sie neben jeder erfolgreichen Canary-Version die Treiberversion, damit bei Incidenzen Regressionen in den Software- und Firmware-Ebenen gezielt untersucht werden können.

Alle Artikel Brief senden