Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

CPU-Inferenz und Orchestrierung

-Übersicht

CPU-Instances sind eine erstklassige Rechenoption für eine Vielzahl von KI-Workloads auf Amazon EKS. Von kleinen Sprachmodellen (SLMs) und klassischer ML-Inferenz bis hin zu Daten-Pipelines und Agenten-Orchestrierung bieten CPUs ein hervorragendes Preis-Leistungs-Verhältnis, eine breite Kapazitätsverfügbarkeit und die vertraute Kubernetes-Scheduling-Semantik.

CPU und GPU ergänzen sich und sind nicht wettbewerbsfähig. Mit zunehmender Komplexität agentischer KI-Pipelines wächst auch die Oberfläche der CPU-Arbeitslast: Jeder Inferenzaufruf ist von der Ausführung von Tools, der Kontext-Assemblierung, der Vektorsuche, den Leitplanken und der Orchestrierungslogik umgeben, die alle auf der CPU ausgeführt werden. Wir empfehlen, Architekturen zu entwerfen, die beide Rechenarten bewusst nutzen und jeden Workload der Stufe zuordnen, auf der er das beste Preis-Leistungs-Verhältnis bietet.

Nicht jeder Workload benötigt eine GPU. Routing, Klassifizierung, Abruf, Einbettung, Orchestrierung und ein wachsender Anteil der Inferenz von Sprachmodellen laufen alle effektiv auf der CPU. Current-generation CPU-Instanzen auf arm64 und x86 bieten ein hervorragendes Preis-Leistungs-Verhältnis für ML-Inferenz. In Kombination mit der Knotenkonsolidierung von Karpenter, der ereignisgesteuerten Skalierung von KEDA und der quantisierten Modellbereitstellung entsteht so ein produktionsreifer Stack, den Plattformteams auch ohne umfassende GPU-Kenntnisse einsetzen können.

Dieser Leitfaden richtet sich an:

Was du lernen wirst:

Warum CPUs für KI-Workloads?

KI-Pipelines für die Produktion verteilen die Arbeit auf viele Rechenebenen. CPUs kümmern sich um Routing, Klassifizierung, Abruf, Orchestrierung und einen wachsenden Anteil an Inferenzen. Current-generation CPU-Instances bieten ein gutes Preis-Leistungs-Verhältnis und die vertraute Kubernetes-Planung, was sie zu einer praktischen Option für viele KI-Workloads macht.

Drei Faktoren machen CPUs für diese Workloads attraktiv:

Verfügbarkeit von Kapazitäten

GPU-Instanzen erfordern häufig Kapazitätsreservierungen Wochen im Voraus. CPU-Instances sind in allen AWS-Regionen ohne spezielle Geräte-Plugins, ohne DRA-Konfiguration und ohne MIG-Partitionierung allgemein verfügbar. Wenn Sie schnell skalieren müssen, ist die CPU-Kapazität die am leichtesten verfügbare Option.

Wirtschaftswissenschaften

Current-generation CPU-Instances bieten ein hervorragendes Preis-Leistungs-Verhältnis für ML-Inferenz. Für Teams, die FinOps Reviews durchführen oder Multi-Tenant-Cluster verwalten, ist der Kostenunterschied zwischen CPU und GPU erheblich, insbesondere bei quantisierten SLMs, bei denen die GPU-Beschleunigung zu sinkenden Renditen führt. Wir empfehlen ein Benchmarking der verfügbaren Instance-Familien (Graviton, AMD, Intel), um die besten Kosten pro Token für Ihren Workload zu ermitteln.

Einfache Bedienung

CPU-Pods verwenden das standardmäßige Kubernetes-Scheduling (requests,limits, Knotenaffinität, Topologieverteilung). Keine Geräte-Plugins, keine benutzerdefinierten Scheduler, keine Ressourcentypen. nvidia.com/gpu Teams, die KI-Workloads ohne fundierte GPU-Kenntnisse ausführen möchten, können die Produktion auf der CPU schneller erreichen.

Wachsende CPU-Oberfläche in behördlichen Pipelines

In agentischen KI-Pipelines ist jeder GPU-Inferenzaufruf von CPU-Arbeit umgeben: Ausführung von Tools, Kontexterstellung, Vektorsuche, Einbettung von Lookups, Leitplanken, Antwortvalidierung, Speicherverwaltung und Orchestrierungslogik. Da die Agenten immer komplexer werden (mehr Tools, längere Ketten, mehrstufiges Denken), nehmen diese CPU-Workloads superlinear zu. Protokolle wie MCP (Model Context Protocol) verstärken dies noch weiter: Jeder Aufruf des MCP-Tools löst den Datenabruf, die Transformation und die Formatierung aus, die vollständig auf der CPU ausgeführt werden.

CPU im Vergleich zu GPU/Trainium: Wann sollte man sich für jedes Modell entscheiden

Entscheidungsrahmen für die Arbeitslast

Die Auswahl der richtigen Rechenleistung für einen KI-Workload hängt von vier Dimensionen ab:

Verwenden Sie die folgende Tabelle als Entscheidungsmatrix.

Schneller Benchmark-Workflow

Bevor Sie sich für eine Instance-Familie entscheiden, empfehlen wir, einen strukturierten Benchmark durchzuführen, bei dem Ihre möglichen CPU-Familien (arm64 und x86) anhand einer einzigen vergleichbaren Metrik verglichen werden: Kosten pro 1.000 Abfragen bei Ihrer angestrebten p95-Latenz. Stellen Sie einen Knoten pro Familie mit identischer Modellkonfiguration (gleiche Quantisierung, gleiche Kontextgröße, Thread-Anzahl) bereit, testen Sie jeden Knoten und vergleichen Sie ihn. Wenn eine CPU-Instance Ihrem p95-SLO entspricht, wird sie sich wahrscheinlich in Bezug auf die Kosten durchsetzen. Wenn sie knapp daneben liegt, probieren Sie die neueste Generation dieser Familie aus, bevor Sie zur GPU wechseln. Wenn die Latenz bei Ihrem Parallelitätsziel immer noch zu hoch ist, ist dies das Signal, die Arbeitslast auf die GPU zu verlagern.

Produktionsmuster

Muster 1: Agentic AI — SLM Pre-Filter auf CPU mit LLM-Eskalation

Die meisten Agenten-Workflows führen dieselben engen Muster wiederholt aus: die Anfrage klassifizieren, ein Tool auswählen, strukturierte Daten extrahieren, eine Antwort validieren. Für diese Aufgaben ist kein 70B-Parametermodell erforderlich.

Untersuchungen zu SLMs (AR Xiv:2506.02153) haben gezeigt, dass Modelle mit 10B-Parametern, wenn sie auf eine Domäne spezialisiert sind, großen LLMs bei eingeschränkten Teilaufgaben entsprechen oder diese übertreffen können, während sie gleichzeitig effizient auf der CPU mit deutlich geringeren Kosten und Latenz ausgeführt werden. Wenn ein Modell auf eine bestimmte Domäne abgestimmt wird, kann es aufgrund seines geringeren Platzbedarfs genauer und kostengünstiger sein als die Verwendung eines Allzweck-LLMs.

Bei diesem Muster verarbeitet ein SLM auf der CPU die meisten Anfragen durchgängig. Eine Routing-Schicht (die ebenfalls auf der CPU ausgeführt wird) leitet nur wirklich komplexe Fälle an ein LLM weiter. GPU-hosted

Komponenten, die auf einer CPU laufen:

Komponenten auf GPU/Trainium:

Warum dieses Muster funktioniert: In vielen Arbeitsabläufen von Agenturen können 60-80% der Anfragen von einem SLM klassifiziert oder extrahiert werden. Mit jedem LLM-Aufruf, den Sie vermeiden, vermeiden Sie auch die damit verbundene CPU-Arbeit, wie das Zusammenstellen eines großen Kontextfensters, das Ausführen von Leitplanken bei einer langen Antwort und die Verwaltung komplexer Zustände. Die CPU-Ebene wird unabhängig von der GPU-Ebene skaliert.

Zu den CPU-Workload-Kategorien in einer typischen Agent-Pipeline gehören: Ausführung von Tools (MCP-Serveraufrufen, API-Aufrufe, Datenbankabfragen), Kontext-Zusammenstellung, Vektorsuche und Einbettung von Lookups, Orchestrierung und Planungslogik, Leitplanken und Sicherheitsfilterung, Validierung und Formatierung von Antworten, Speicher- und Statusverwaltung für Agenten und. logging/observability

Dieses Muster eignet sich auch für einen Feinabstimmungszyklus: Sammeln Sie Domänendaten auf CPU-Knoten, optimieren Sie die GPU und stellen Sie das quantisierte Modell dann zur Inferenz wieder auf der CPU bereit, und das zu wesentlich geringeren Kosten als bei einem LLM-Endpunkt. Untersuchungen von LoRa Land (ar Xiv:2405.00732) zeigen, dass fein abgestimmte 7B-Modelle bei den meisten getesteten domänenspezifischen Aufgaben besser abschneiden, sodass der Pfad „Feinabstimmung eines kleinen Modells und Ausführung GPT-4 auf der CPU“ für viele Anwendungsfälle in der Produktion geeignet ist.

Muster 2: CPU-Modellfarm High-Density

ML-Pipelines für die Produktion setzen routinemäßig Hunderte oder Tausende kleinerer Modelle ein: Einbettungen, Empfehlungen, Klassifikatoren, Punktezähler und BERT-based Computer-Vision-Modelle. Diese Modelle sind individuell leicht und werden teuer, wenn jedem Modell eigene GPU-Ressourcen zugewiesen werden.

Wir empfehlen CPU-Serving mit hoher Dichte (Bin-Packaging mehrerer Modelle pro Knoten mit TorchServe oder Triton auf der CPU), wobei Karpenter den Knotenlebenszyklus und die KEDA-Skalierung bei beobachteter Last verwaltet.

Dieses Muster lässt sich natürlich auch auf RAG-Architekturen übertragen: Das Einbetten, Generieren, Aufteilen von Dokumenten und das Abrufen OpenSearch aller Dateien laufen kostengünstig auf CPU-Knoten ab, wobei die Ergebnisse nur für den letzten Generierungsschritt an ein LLM weitergeleitet werden. GPU-hosted Die CPU-Farm kümmert sich um das Volumen, die GPU um die Komplexität.

Für regulierte Branchen (Finanzdienstleistungen, Gesundheitswesen, Behörden) ist dieses Muster besonders überzeugend: Hunderte von Spezialmodellen werden in VPC auf CPU ausgeführt, mit vollständigen Prüfprotokollen und Daten, die das Konto nie verlassen. Die Konformitätsanforderungen für selbstverwaltete Inferenzen stehen naturgemäß im Einklang mit dem Kostenvorteil von CPUs für Modelle unter 8 GB.

Bewährte Methoden zur Optimierung

Quantisierung

Es ist nicht praktikabel, ein 7B-Modell mit voller BF16 auf der CPU laufen zu lassen; es mit Q4-Quantisierung auszuführen ist praktikabel und kostengünstig. Zu verstehen, warum Quantisierung bei CPUs hilft, ist der Schlüssel zu guten Infrastrukturentscheidungen.

Warum Quantisierung für die CPU-Inferenz wichtig ist. CPU-Inferenz ist an die Speicherbandbreite gebunden, nicht an die Rechenleistung. Während der Dekodierungsphase (Generierung von Tokens nacheinander) werden für jedes erzeugte Token die gesamten Gewichtungen des Modells aus dem RAM gelesen. Die CPU verbringt die meiste Zeit damit, darauf zu warten, dass Daten aus dem Speicher eintreffen, und nicht damit, zu rechnen. Ein 7B-Modell bei BF16 ist ungefähr 14 GB groß; bei Q4_K_M schrumpft es auf etwa 4 GB. Da der Engpass darin besteht, dass Bytes vom RAM zu den CPU-Kernen verschoben werden, liest ein 3,5-mal kleineres Modell 3,5-mal schneller, was fast direkt zu einer 3,5-mal schnelleren Token-Generierung führt. Aus diesem Grund ist die Quantisierung mit Abstand die wirkungsvollste Optimierung für CPU-Inferenz und der Grund, warum neuere CPU-Generationen mit mehr Speicherkanälen selbst bei gleicher Taktrate schnellere Inferenzen erzeugen.

Wir empfehlen, Ihre Inferenz-Engine mit architekturoptimierten Backends (ARM NEON/SVE2 für arm64, AVX-512/AMX für x86) zu erstellen, die Thread-Anzahl gleich der vCPU-Anzahl einzustellen und die Quantisierungsformate Q4_K_M oder Q8_0 auszuwählen.

Bei Modellen unter 2B gewinnt die CPU beim Preis-Leistungs-Verhältnis im Vergleich zur GPU. Diese Modelle sind klein genug, dass die GPU-Beschleunigung nur minimale Vorteile bietet, während die Kosten pro Stunde deutlich höher sind. Wenn Ihr Workload ein Sub-2B-Modell verwenden kann, ist CPU der empfohlene Standard.

Architecture-specific Optimierungen: Auf Arm64 unterstützen Graviton-Instances der aktuellen Generation SVE2. Erstellen Sie Ihre Inferenz-Engine mit der entsprechenden Flagge für Ihr Ziel. -march Auf x86 unterstützen AMD EPYC-Instances AVX-512, und Intel Xeon-Instances fügen AMX für die Matrixbeschleunigung hinzu. Da Inferenz an die Speicherbandbreite gebunden ist, ermöglichen neuere CPU-Generationen mit mehr DDR5-Speicherkanälen sogar bei gleicher Taktrate schnellere Inferenzen. Bei der Auswahl der Instance-Typen sollten Sie der Speicherbandbreite Vorrang vor der Anzahl der Kerne einräumen.

Größe des Kontextfensters: Bei Klassifizierungs- und Routing-Workloads liegen die Eingaben in der Regel unter 200 Tokens und die Ausgaben bei 2-3 Tokens. Durch die Einstellung eines kleinen Kontextfensters (z. B. 512 Token) anstelle der Standardeinstellung 2048 wird die Speicherauslastung im KV-Cache reduziert und die Latenz pro Anfrage verbessert. Erhöhen Sie das Kontextfenster nur, wenn Ihre Eingaben wirklich lang sind.

Flash Attention: Aktivieren Sie Flash Attention, wenn Ihre Inferenz-Engine dies unterstützt. Flash Attention reduziert den Speicherverbrauch für die Aufmerksamkeitsberechnung, indem die Materialisierung der vollständigen Aufmerksamkeitsmatrix vermieden wird. Bei der CPU ist der Vorteil geringer als bei der GPU, aber er hilft immer noch bei längeren Eingaben.

Bin-packing für dichtes Servieren

Bei klassischen ML- und Embedding-Modellen (in der Regel jeweils <500 MB) ist das Ziel eine maximale Pod-Dichte pro Knoten bei stabiler Latenz am Ende. Zwei Dinge bestimmen, ob Sie das erreichen: genaue Ressourcenanfragen und kontrolliertes Threading.

Basieren Sie requests auf der beobachteten p50-p90-Nutzung unter realistischer Last. Verwenden Sie Goldlöckchen, VPA-Empfehlungen oder Prometheus-Histogramme aus einem Belastungstest. Die Standardwerte sind fast immer in beide Richtungen falsch.

ML-Bibliotheken (PyTorchONNX Runtime, MKL, OpenBLAS) erzeugen so viele Threads, wie sie vCPUs auf dem Knoten sehen können, nicht die CPUs, die dem Pod zugewiesen sind. Auf einem dichten Knoten mit 20 Pods versucht jeder Pod, 32 Threads zu erzeugen. Der Knoten stürzt beim Kontextwechsel und bei p99-Latenzspitzen aus. Korrigieren Sie das explizit:

env:
  - name: OMP_NUM_THREADS
    value: "2"          # match your cpu request (2000m = 2 threads)
  - name: MKL_NUM_THREADS
    value: "2"
  - name: OPENBLAS_NUM_THREADS
    value: "2"
  - name: INTRA_OP_NUM_THREADS    # PyTorch / ONNX Runtime
    value: "2"
  - name: NUM_INTER_THREADS
    value: "1"          # keep inter-op parallelism minimal

Stellen Sie jeden Wert gleich oder niedriger als Ihre CPU-Anfrage ein. Für Pods mit mehr als 4 Kernen beginnt der Benchmark bei 2-4 Threads. Viele kleine Modelle schneiden aufgrund der Cache-Effizienz mit weniger Threads besser ab. Wenn Sie HPA mit vielen dünnen Pods verwenden, gewinnen 1-2 Threads pro Pod fast immer.

Terminplanung und Kostenoptimierung

Durch die Kombination zweier Methoden lassen sich die Kosten für CPU-Inferenzen deutlich reduzieren: Spot-Instances mit Karpenter-Konsolidierung und Multi-Arch-Container-Images.

Die Konsolidierung von Karpenter eignet sich gut für CPU-Inferenzen, da zustandslose Inferenz-Pods hinter einer Warteschlange oder einem Load Balancer Unterbrechungen problemlos tolerieren. Richten Sie die Konsolidierung so ein, dass sie auf nicht ausgelastete Knoten reagiert, und achten Sie auf ein Budget, das gleichzeitige Unterbrechungen begrenzt (z. B. 20% der Knoten gleichzeitig), um Kapazitätseinbußen beim Herunterfahren zu vermeiden. Mit den nodePool Spezifikationen von Karpenter können Sie Spot und On-Demand Kapazität in einem einzigen Pool kombinieren, wobei Spot die bevorzugte Option und als Ausweichlösung ist. On-Demand

Das Erstellen von Multi-Arch-Images (arm64und) ermöglicht weitere Möglichkeitenamd64. Da beide Architekturen verfügbar sind, kann Karpenter je nach Preis und Verfügbarkeit in Echtzeit aus der gesamten Palette von Instance-Familien (Graviton, AMD, Intel) auswählen. Dies ist besonders nützlich für Spot-Workloads, bei denen die Diversifizierung der Instance-Typen und Architekturen die Häufigkeit von Unterbrechungen reduziert. Verwenden Sie docker buildx eine CI-Pipeline mit plattformübergreifenden Builds, um ein einziges Manifest zu erstellen, das beide Architekturen abdeckt.

Optimierung des Container-Starts

Wenn Karpenter einen neuen Knoten bereitstellt (Hochskalierung, Spot-Ersatz), muss die Container-Laufzeit das Inferenz-Image abrufen, bevor der Pod gestartet werden kann. Bei Inferenzbildern mit mehreren GB kann dies den Start des Pods um 30-60 Sekunden verlängern.

Wir empfehlen, Bottlerocket als Knotenbetriebssystem für Inferenz-Workloads in Kombination mit dem SOCI-Snapshotter im Parallelmodus zu verwenden. pull/unpack SOCI ersetzt die standardmäßige sequentielle Ebenenextraktion durch parallel, blockbasierte Downloads, wodurch die Abrufzeiten für große Bilder erheblich reduziert werden. Es sind keine Änderungen an Ihren Container-Images erforderlich.

Ausführliche Anleitungen zur Konfiguration finden Sie im Abschnitt Leistung dieses Handbuchs, in dem die SOCI-Konfiguration, das Pre-Pulling von EBS-Snapshots und die Cache-Strategien für die Container-Runtime behandelt werden.

Beobachtbarkeit

Ohne Beobachtbarkeit auf der Modellebene skalieren Sie blind. Wir empfehlen, Prometheus-Metriken für jeden Inferenzservice verfügbar zu machen und sie zur Steuerung der KEDA-Skalierung und der operativen Dashboards zu verwenden.

Die meisten Inferenzserver (llama.cpp, vLLM, Triton) stellen Metriken an einem Endpunkt zur Verfügung. TorchServe Prometheus-compatible /metrics Die Namen der Metriken variieren je nach Server, aber die Konzepte sind dieselben.

Die wichtigsten Kennzahlen für die Instrumentierung:

Autoscaling: Skalieren Sie nach der Tiefe der Warteschlange, nicht nach der CPU-Auslastung

Die CPU-Auslastung ist eine Messgröße für die Sättigung. Sie nimmt ihren Höhepunkt zu, nachdem sich die Latenz bereits verringert hat. Bis die nutzungsbasierte Autoskalierung reagiert, warten die Benutzer bereits.

Die Warteschlangentiefe (Anfragen deferred/waiting) ist ein Frühindikator. Sie steigt, bevor die Latenz abnimmt, da Anfragen erst dann in die Warteschlange gestellt werden, wenn alle Verarbeitungssteckplätze belegt sind. Durch die Skalierung der Warteschlangentiefe werden neue Replikate bereitgestellt, während die vorhandenen weiterhin normal reagieren.

KEDA unterstützt die Kombination mehrerer Metriken zu einer einzigen Skalierungsformel mithilfe von scalingModifiers (erfordert KEDA 2.12+). Das empfohlene Muster für Inferenz-Workloads besteht darin, eingehende Anfragen mit Anfragen in der Warteschlange zu kombinieren, wobei die Queue-Metrik stark gewichtet wird:

advanced:
  scalingModifiers:
    formula: "running + (waiting * 10)"
    target: "25"
    activationTarget: "5"

Die Formel running + (waiting * 10) bedeutet, dass selbst 3 Anfragen in der Warteschlange die kombinierte Metrik auf 55 erhöhen und damit deutlich über dem Ziel von 25 liegen. Die Skalierung setzt ein, bevor die Latenz nachlässt. Der Wert activationTarget von 5 verhindert, dass Rauschen unnötige Scale-from-Null-Ereignisse auslöst.

Bewertung der Modellqualität für Workloads CPU-First

Die Bereitstellung eines quantisierten SLM auf der CPU ist eine Kosten- und Latenzentscheidung. Es ist nur sinnvoll, wenn das Modell immer noch korrekte, nützliche Ergebnisse für Ihre Arbeitslast liefert.

Kleinere Modelle oder Quantisierung senken die Rechenkosten, können aber die Qualität beeinträchtigen. Die Auswirkungen sind unterschiedlich. Die Workloads, die auf der CPU gut funktionieren (Klassifizierung, Extraktion, Routing, Zusammenfassung, Einbettungen), behalten bei richtiger Quantisierung und Eingabeaufforderung oft eine gute Qualität im B-7B 3-Bereich.

Was muss bewertet werden

Verschiedene Workloads verschlechtern sich auf unterschiedliche Weise:

Ein praktischer Bewertungsablauf

Wir empfehlen, vor der Produktion eine Qualitätsprüfung durchzuführen, ähnlich wie Sie vor der Auswahl eines Instance-Typs einen Auslastungstest durchführen würden. Der Workflow besteht aus vier Phasen:

Wie kann die Qualität wiederhergestellt werden

Wenn das Modell schlecht abschneidet, probieren Sie die folgenden Schritte in der Reihenfolge ihres Aufwands aus:

Referenzen