Die MLOps-Landschaft, insbesondere im Hinblick auf Modellbereitstellung, -bedienung und -inferenz, hat in den letzten paar Jahren eine wirklich beeindruckende Transformation durchlaufen. Während wir uns in 2026 einpendeln, hat sich die Rhetorik von der ambitionierten "KI für alle" zu einem bodenständigen, praktischen Fokus auf Effizienz, Kosteneffektivität und den robusten Umgang mit zunehmend komplexen Modelltypen, insbesondere Large Language Models (LLMs) und generativer KI, verschoben. Ich habe mich intensiv mit diesen Updates auseinandergesetzt und freue mich, zu teilen, was wirklich einen Unterschied macht und wo die rauen Kanten noch liegen.
Die Kernherausforderung bleibt bestehen: Wie bringen wir Modelle von der Experimentierphase in die Produktion, bedienen Millionen von Anfragen zuverlässig, erschwinglich und mit minimalem operativen Aufwand? Die "jüngsten Entwicklungen" sind nicht nur inkrementell; sie stellen eine deutliche Reifung der Werkzeuge und eine klare Reaktion auf die realen Anforderungen von Unternehmen dar, die KI skalieren.
Die neue Grenze des generativen KI-Servings mit KServe
Das ist wirklich beeindruckend, denn KServe, ein Cloud Native Computing Foundation (CNCF) Incubating-Projekt, hat sich schnell zu einem Eckpfeiler für das Servieren sowohl traditioneller prädiktiver Modelle als auch der aufkommenden Klasse generativer KI-Workloads entwickelt. Die Veröffentlichungen von KServe v0.13 (Mai 2024) und v0.15 (Mai 2025) markieren einen entscheidenden Wandel und führen eine erstklassige Unterstützung für LLMs und ihre einzigartigen Serving-Herausforderungen ein.
Eine der wirkungsvollsten Ergänzungen ist die robuste vLLM Backend-Unterstützung. vLLM, bekannt für seine hohe Durchsatzrate und geringe Latenz bei der LLM-Inferenz, ist jetzt nahtlos in KServe integriert. Das bedeutet, dass wir vLLMs optimierte Aufmerksamkeitsmechanismen, wie PagedAttention, direkt in einer Kubernetes-nativen Serving-Umgebung nutzen können. KServe v0.15 verbesserte dies weiter mit verteiltem KV-Cache mit LMCache, was für die Verarbeitung längerer Sequenzlängen und die Reduzierung redundanter Berechnungen über Anfragen hinweg entscheidend ist.
Betrachten Sie die Bereitstellung eines großen Sprachmodells mit KServe unter Verwendung des vLLM-Backends. Die InferenceService YAML-Datei ermöglicht nun die Angabe der vllm-Laufzeit, komplett mit Ressourcenlimits und speziellen Konfigurationen. Sie können diesen JSON Formatter verwenden, um Ihre Struktur zu überprüfen, wenn Sie diese Konfigurationen zwischen Formaten konvertieren.
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: llama-7b-vllm
spec:
predictor:
model:
modelFormat:
name: vllm
args:
- "--model=/mnt/models/Llama-2-7b-chat-hf"
- "--max-model-len=2048"
- "--gpu-memory-utilization=0.9" # Allocate 90% of GPU memory for KV cache
resources:
limits:
cpu: "4"
memory: 32Gi
nvidia.com/gpu: "1" # Assuming a single GPU per replica
requests:
cpu: "2"
memory: 16Gi
nvidia.com/gpu: "1"
autoscaler:
minReplicas: 0 # Scale to zero for cost efficiency
maxReplicas: 5
scaleTarget: 100 # Target 100 concurrent requests per replica
metricType: "RPS" # Request Per Second or Concurrency
Erweiterte Traffic-Verwaltung und Skalierung
Das Argument gpu-memory-utilization ist hier entscheidend. Im Gegensatz zu traditionellen prädiktiven Modellen ist der KV (Key-Value)-Cache-Verbrauch von LLMs dynamisch und hängt von der Sequenzlänge ab. Das proaktive Zuweisen von Speicher dafür ermöglicht es vLLM, GPU-Ressourcen effektiver zu verwalten, was zu einem höheren Durchsatz führt. Darüber hinaus ist die Integration mit KEDA (Kubernetes Event-Driven Autoscaling) in v0.15 für LLM-spezifische Metriken ein Game-Changer für die Kostenoptimierung. Wir können jetzt basierend auf tatsächlichen Token-Generierungsraten oder Prompt-Verarbeitungsverzögerungen skalieren, anstatt nur auf generischer CPU/Speicher, und sicherstellen, dass Ressourcen nur dann verbraucht werden, wenn sie tatsächlich benötigt werden, und sogar während Leerlaufzeiten auf Null heruntergefahren werden.
KServe v0.15 führte auch die erste Unterstützung für Envoy AI Gateway ein, das auf Envoy Gateway basiert und speziell für die Verwaltung des generativen KI-Traffics entwickelt wurde. Dies ist eine robuste Lösung für erweiterte Traffic-Verwaltung, Token-Ratenbegrenzung und vereinheitlichte API-Endpunkte, die für komplexe LLM-gestützte Anwendungen immer wichtiger werden.
Performance-Kraftpakete: Triton Inference Server und ONNX Runtime
Wenn es um reine Inferenzleistung geht, setzen NVIDIA's Triton Inference Server und die ONNX Runtime weiterhin Maßstäbe. Ihre jüngsten Updates unterstreichen das unermüdliche Streben nach geringerer Latenz und höherem Durchsatz, insbesondere für Deep-Learning-Workloads.
NVIDIA Triton Inference Server hat durchweg seine Fähigkeiten in MLPerf Inference Benchmarks unter Beweis gestellt und erreicht selbst mit seinen funktionsreichen, produktionsreifen Serving-Funktionen eine nahezu identische Leistung wie Bare-Metal-Übermittlungen. Die Veröffentlichungen von 2025 haben entscheidende Verbesserungen mit sich gebracht. Darauf habe ich gewartet: Die OpenAI-kompatible API-Frontend ist von Beta auf eine stabile Version übergegangen. Das bedeutet, dass Sie Modelle jetzt über Triton mit einer API bedienen können, die OpenAI's API widerspiegelt, was die Client-seitige Integration vereinfacht und eine einfachere Migration oder Multi-Modell-Orchestrierung ermöglicht.
Darüber hinaus führte Triton 25.12 Multi-LoRA-Unterstützung für das TensorRT-LLM-Backend und das Feld max_inflight_requests für die Modellkonfiguration ein. Multi-LoRA ist entscheidend für Unternehmen, die viele feinabgestimmte LLMs bereitstellen, bei denen das Laden eines vollständigen Modells für jeden LoRA-Adapter speicherverboten ist. Tritons Fähigkeit, LoRA-Gewichte effizient auszutauschen oder zu kombinieren, verbessert die GPU-Auslastung drastisch und reduziert die Kaltstartzeiten für verschiedene LLM-Anwendungen. Diese Verlagerung hin zu containerisierter Effizienz spiegelt breitere Infrastrukturtrends wider, wie sie sich zeigen, wie Podman und containerd 2.0 Docker in 2026 ersetzen.
Um Triton mit einem optimierten ONNX-Backend auszuführen, zum Beispiel für ein Computer-Vision-Modell:
# Pull the latest Triton container with the desired CUDA version
docker pull nvcr.io/nvidia/tritonserver:25.12-py3
# Assuming your ONNX model is in /path/to/model_repository/my_onnx_model/1/model.onnx
# and has a config.pbtxt in /path/to/model_repository/my_onnx_model/config.pbtxt
docker run --gpus=all -it --rm -p 8000:8000 -p 8001:8001 -p 8002:8002 \
-v /path/to/model_repository:/models \
nvcr.io/nvidia/tritonserver:25.12-py3 tritonserver --model-repository=/models \
--log-verbose=1 --log-info=1 --log-warn=1
Die Vielseitigkeit von ONNX Runtime
In der Zwischenzeit beeindruckt die ONNX Runtime weiterhin mit ihrer plattformübergreifenden Portabilität und erheblichen Leistungssteigerungen. Jüngste Benchmarks haben gezeigt, dass die Konvertierung von Modellen in ONNX und deren Bedienung mit der ONNX Runtime einen bis zu 9-fach höheren Durchsatz im Vergleich zum nativen PyTorch-Serving erzielen kann, selbst auf CPUs. Das ist nicht nur theoretisch; es ist eine praktische, zugängliche Optimierung für eine Vielzahl von Modellen, von klassischem ML (scikit-learn, LightGBM) bis hin zu Deep Learning. Seine "Execution Providers" (z. B. CUDA, ROCm, OpenVINO, NNAPI) ermöglichen es ihm, auf bestimmte Hardware-Beschleuniger zuzugreifen und ein konsistentes Leistungsprofil über verschiedene Bereitstellungsziele hinweg bereitzustellen, von Cloud-GPUs bis hin zu Edge-Geräten.
Serverless Inference: Reift, nicht nur Hype
Das Versprechen von Serverless Inference war verlockend, und im Jahr 2025 begann es wirklich zu reifen, insbesondere mit der entscheidenden Ergänzung der GPU-Unterstützung. Microsoft Azure enthüllte im Dezember 2024 serverless GPUs in Azure Container Apps, die NVIDIA A100- und T4-GPUs nutzen. Dies ist ein bedeutender Durchbruch. Historisch gesehen war der GPU-Zugriff eine große Einschränkung für Serverless-Plattformen aufgrund der spezialisierten Hardware und des Initialisierungsaufwands. Der Schritt von Azure ermöglicht das Ausführen von GPU-beschleunigten Inferenz-Workloads – denken Sie an Computer Vision, komplexe NLP – ohne die Last des Infrastrukturmanagements.
Der Kernreiz von Serverless bleibt bestehen: Pay-per-Use, automatische Skalierung von Null auf viele Instanzen und Abstraktion der Infrastruktur. Die Realitätsprüfung zeigt jedoch weiterhin Herausforderungen, insbesondere Kaltstartlatenz. Obwohl kontinuierlich Anstrengungen unternommen werden, um dies zu reduzieren, führen große KI-Modelle neue Komplexitäten ein, da das Laden von Multigigabyte-Modellen in Beschleuniger Zeit in Anspruch nimmt. Für Anwendungen mit strengen Anforderungen an geringe Latenz bei ersten Anfragen ist dies ein wichtiger Aspekt.
Cloud Native Evolution: SageMaker und Vertex AI's neuestes Arsenal
Die großen Cloud-Anbieter verbessern ihre MLOps-Plattformen aggressiv und konzentrieren sich auf Effizienz, Kosten und generative KI.
Amazon SageMaker hat kritische Updates für seine Inferenzfunktionen veröffentlicht. Im Dezember 2024 erhielt der Inferenzoptimierungstoolkit für generative KI erhebliche Verbesserungen. Dazu gehört die Out-of-the-Box-Unterstützung für spekulative Dekodierung, die die Inferenz deutlich beschleunigen kann, indem zukünftige Token vorhergesagt werden. Darüber hinaus wurde die Unterstützung für FP8 (8-Bit-Gleitkomma) hinzugefügt, wodurch die Modellgröße und die Inferenzlatenz reduziert werden, insbesondere für GPUs.
SageMaker's CustomOrchestrator
Was ich besonders praktisch fand, ist die Verbesserung des SageMaker Python SDK (Juni 2025) für das Erstellen und Bereitstellen komplexer Inferenz-Workflows. Die neue Klasse CustomOrchestrator ermöglicht Entwicklern die Definition komplexer Inferenzsequenzen mit Python und ermöglicht die Bereitstellung mehrerer Modelle innerhalb eines einzigen SageMaker-Endpunkts. Das bedeutet, dass Sie ein Vorverarbeitungsmodell, ein Kerninferenzmodell und ein Nachverarbeitungsmodell haben können, die alle als eine logische Einheit orchestriert und bedient werden.
# Simplified conceptual example for SageMaker CustomOrchestrator
from sagemaker.model import Model
from sagemaker.predictor import Predictor
from sagemaker.workflow.components import CustomOrchestrator
# Define your individual models
model_a = Model(image_uri="my-preprocessing-image", model_data="s3://...")
model_b = Model(image_uri="my-llm-inference-image", model_data="s3://...")
# Define the orchestration logic
class MyInferenceWorkflow(CustomOrchestrator):
def __init__(self, name, model_a, model_b):
super().__init__(name=name)
self.model_a = model_a
self.model_b = model_b
def handle_request(self, request_body):
# Invoke model_a
processed_data = self.model_a.predict(request_body)
# Invoke model_b with processed_data
final_prediction = self.model_b.predict(processed_data)
return final_prediction
# Deploy the orchestrated endpoint
workflow = MyInferenceWorkflow(name="my-complex-ai-endpoint", model_a=model_a, model_b=model_b)
predictor = workflow.deploy(instance_type="ml.g5.2xlarge", initial_instance_count=1)
Google Cloud's Vertex AI setzt seine rasante Entwicklung fort. Die Updates vom August 2025 brachten erhebliche Verbesserungen, insbesondere im Bereich der generativen KI. Die Gemini 2.5 Flash und Pro Modelle wurden im Juni 2025 allgemein verfügbar (GA) und bieten leistungsstarke LLMs direkt über Vertex AI-Endpunkte. Für kostengünstige Bereitstellungen führte Vertex AI im Juli 2025 flex-start VMs für Inferenz-Jobs ein. Angetrieben von Dynamic Workload Scheduler bieten diese VMs erhebliche Rabatte für kurzfristige Workloads und eignen sich ideal für Batch-Inferenz oder sporadische High-Volume-Aufgaben, bei denen ein sofortiger Start nicht oberste Priorität hat.
Über das Modell hinaus: Erweiterte Beobachtbarkeit und Drift-Erkennung
Die Bereitstellung eines Modells ist nur die halbe Miete; die Aufrechterhaltung seiner Leistung in der Produktion ist die andere. Die MLOps-Landschaft in 2025-2026 betont stark Echtzeitüberwachung und fortschrittliche Drift-Erkennung. Es geht nicht mehr nur um Ressourcenmetriken; es geht darum, das Modellverhalten in der Wildnis zu verstehen.
Wir sehen eine Verlagerung hin zu ausgefeilteren Techniken zur Erkennung von Datadrift (wenn Live-Daten von Trainingsdaten abweichen) und Modelldrift (wenn die Modellleistung im Laufe der Zeit abnimmt). Tools wie Evidently AI bieten detaillierte Metriken und Visualisierungen, während Plattformen wie Prometheus und Grafana zur Einrichtung von Echtzeit-Alerts verwendet werden. Moderne Systeme verfolgen jetzt:
- Verschiebungen der Verteilung der Eingabemerkmale: Erscheinen neue Kategorien? Hat sich der Mittelwert/Median numerischer Merkmale signifikant verändert?
- Verschiebungen der Verteilung der Vorhersagen: Wird das Modell selbstbewusster (oder weniger)? Verändern sich die Häufigkeiten seiner Ausgabeklassen?
- Konzeptdrift: Die zugrunde liegende Beziehung zwischen Eingabemerkmalen und der Zielvariable ändert sich, was eine erneute Schulung des Modells erfordert.
BentoML: Der Packaging & Serving Unifier
Ich bin schon lange ein Fan von BentoML wegen seines pragmatischen Ansatzes für das Modell-Serving, und seine kontinuierliche Weiterentwicklung macht es für viele zu einem unverzichtbaren Werkzeug. BentoML 1.0 festigte wirklich seine Vision als offene Plattform, die das ML-Modell-Serving vereinfacht. Die Kerninnovation ist der BentoML Runner, eine Abstraktion, die speziell für die Parallelisierung von Modellinferenz-Workloads entwickelt wurde. Er übernimmt die Komplexität des adaptiven Batchings, der Ressourcenallokation (CPU/GPU) und der Skalierung von Inferenz-Workern unabhängig von der Vor- und Nachverarbeitungslogik.
Hier ist ein einfaches BentoML-Servicebeispiel:
# my_service.py
import bentoml
from bentoml.io import JSON
from pydantic import BaseModel
class InputData(BaseModel):
feature_a: float
feature_b: float
@bentoml.service(
resources={"cpu": "2", "memory": "4Gi"},
traffic={"timeout": 60}
)
class MyClassifier:
def __init__(self):
self.model_runner = bentoml.sklearn.get("my_model:latest").to_runner()
@bentoml.api(input=JSON(pydantic_model=InputData), output=JSON())
def classify(self, input_data: InputData) -> dict:
input_array = [[input_data.feature_a, input_data.feature_b]]
prediction = self.model_runner.predict.run(input_array)
return {"prediction": prediction.tolist()}
Architekturen für Kosteneffizienz bei der Inferenz
Mit der Skalierung von KI-Bereitstellungen ist die Kostenoptimierung zu einem zentralen Thema in MLOps für 2025-2026 geworden. Es geht nicht nur darum, die billigste Cloud-Instanz auszuwählen; es geht um eine intelligente Architektur. Mehrere Trends konvergieren hier:
- Serverless Scaling to Zero: Plattformen wie Azure Container Apps mit serverless GPUs und KServe's KEDA-Integration ermöglichen es Diensten, während Leerlaufzeiten auf Null herunterzufahren.
- Optimierte Modellformate: Die Leistungssteigerungen von ONNX Runtime führen direkt zu Kosteneinsparungen, indem sie einen höheren Durchsatz pro Instanz ermöglichen.
- Multi-Modell-Endpunkte: Cloud-Plattformen wie Amazon SageMaker mit seinem
CustomOrchestratorermöglichen es mehreren Modellen, sich die gleichen zugrunde liegenden Rechenressourcen (z. B. eine einzelne GPU) zu teilen. - Spezialisierte VM-Typen: Vertex AI's flex-start VMs bieten kostengünstige Optionen für nicht-latenzkritische Inferenz-Jobs, indem sie ungenutzte Kapazitäten nutzen.
Experten-Einblick: Die bevorstehende Verlagerung zu Agentic AI und Federated Inference
Mit Blick auf die Zukunft wird die nächste bedeutende Verschiebung in MLOps-Bereitstellungen durch den Aufstieg der Agentic AI vorangetrieben. Da Modelle nicht nur vorhersagen, sondern auch planen, argumentieren und mit Tools interagieren können, werden die Inferenzmuster dynamischer und zustandsbehafteter. Dies erfordert neue Ansätze für Zustandsverwaltung, Orchestrierung und Beobachtbarkeit. Das Debuggen agentischer Systeme erfordert eine Token-Level-Inspektion und -Verfolgung über mehrere Modellaufrufe hinweg, um zu verstehen, warum ein Agent eine bestimmte Entscheidung getroffen hat.
Gleichzeitig wird Federated Inference langsam, aber stetig an Bedeutung gewinnen, insbesondere in datenschutzsensiblen Bereichen wie Gesundheitswesen und Finanzen. Anstatt Daten zu zentralisieren, um Inferenz durchzuführen, wird das Modell näher an den Daten bereitgestellt und lokal inferiert. Dies wird die Grenzen des Edge-Deployments verschieben und neue Sicherheits- und Governance-Paradigmen für die verteilte Modellausführung erfordern.
Fazit: Navigation in der Produktions-KI-Landschaft
Das letzte Jahr oder die letzten zwei Jahre waren aufregend für MLOps-Praktiker. Wir haben gesehen, wie Modell-Serving-Frameworks wie KServe und BentoML deutlich reifer geworden sind und die Komplexität der generativen KI mit Funktionen wie vLLM-Integration und KV-Caching direkt angehen. Performance-Champions wie NVIDIA Triton und ONNX Runtime liefern weiterhin beeindruckende Geschwindigkeitssteigerungen, während Cloud-Plattformen hochspezialisierte Tools für die LLM-Optimierung liefern. Obwohl es immer noch knifflige Stellen wie Kaltstarts für serverless GPUs gibt, ist der Weg zu effizienter, skalierbarer und beobachtbarer Produktions-KI klarer denn je.
Quellen
Dieser Artikel wurde vom DataFormatHub Editorial Team veröffentlicht, einer Gruppe von Entwicklern und Datenbegeisterten, die sich dafür einsetzen, Datentransformationen zugänglich und privat zu machen. Unser Ziel ist es, hochwertige technische Einblicke neben unserer Suite von datenschutzorientierten Entwicklerwerkzeugen bereitzustellen.
🛠️ Zugehörige Tools
Entdecken Sie diese DataFormatHub-Tools, die sich auf dieses Thema beziehen:
- JSON Formatter - Formatieren Sie Modellkonfigurationen
- CSV to JSON - Bereiten Sie Trainingsdaten vor