Meta's Llama 4 Scout, das im April 2025 veröffentlicht wurde, ist ein universelles Sprachmodell mit 17 Milliarden Parametern, das leistungsstarke Schlussfolgerungen für ein breiteres Anwendungsspektrum ermöglicht – einschließlich solcher, die ohne GPUs laufen. Dieser Blogbeitrag konzentriert sich auf Benchmarking von Llama 4 Scout auf reinen CPU-Systemen und behandelt folgende Themen: Token pro Sekunde Latenz pro Token Schnelle und effiziente Bearbeitung Quantisierungstechniken Architekturspezifische Optimierung für x86, ARM und RISC-V (RV64) Konvertierung in das GGUF-Format für eine effiziente Bereitstellung Warum Benchmarking auf der CPU? Während die meisten LLMs auf GPUs eingesetzt werden, ist die Inferenz ausschließlich auf der CPU oft notwendig für: Edge-Geräte Cloud-VMs ohne GPU-Zugriff Offene Hardware-Ökosysteme (z. B. RISC-V) Kostenbewusste Implementierungen Das macht Llama 4 Scout zu einem aussichtsreichen Kandidaten, insbesondere mit quantisierten Varianten. Wichtige Benchmark-Kennzahlen Tokens/Sek. Gesamtdurchsatz, entscheidend für lange Abschlüsse Latenz/Token Zeit, ein Token zu generieren; wichtig für Chats Empfindlichkeit gegenüber der Größe der Eingabeaufforderung Wie sich die Inferenzgeschwindigkeit bei längeren Eingaben verschlechtert Speichernutzung Der RAM-Bedarf entscheidet darüber, ob das Modell überhaupt ausgeführt werden kann. Warum Quantisierung unerlässlich ist Die Quantisierung reduziert den Speicher- und Rechenaufwand großer Modelle. Llama 4 Scout, quantisiert auf int4 oder int8, läuft problemlos auf CPUs mit 8–16 GB RAM. Nutzen: Auswirkungen auf Llama 4 Scout Speichereinsparung: Von 34 GB → ~5–7 GB (int4) Beschleunigung: Bis zu 3-mal schneller als float16 Hardwarekompatibilität: Ermöglicht ARM- und RV64-CPUs die Ausführung von Inferenzprozessen. Tools wie ggml, llama.cpp und MLC unterstützen quantisierte Llama 4-Modelle, einschließlich CPU-Backends. Architekturspezifische Leistungsüberlegungen 🔹 x86-64 (Intel, AMD) Vektorunterstützung: AVX2 oder AVX-512 bevorzugt. Threading: Ausgereifte OpenMP- und NUMA-Unterstützung Leistung: Hoch; gut optimiert für Lama-Modelle ARM (Graviton, Apple Silicon, Neoverse) Vektor-ISA: NEON (128 Bit) auf allen, SVE/SVE2 auf neueren Chips Threading: Erfordert aufgrund von Kernheterogenität eine Feinabstimmung. Quantisierung: NEON verarbeitet int8 und int4 effizient. Tipp: Verwenden Sie taskset und numactl, um Threads für eine optimale Leistung zu fixieren. RISC-V (RV64 mit RVV) Vektor-ISA: RISC-V Vector Extension (RVV), variable Breite Quantisierung: Unerlässlich; float32-Modelle sind auf RV64-Edge-Geräten unpraktisch. Werkzeuge: Die Unterstützung für llama.cpp ist experimentell, aber im Aufbau. Bei RV64 sind Speicherlayout und cachefreundliche Quantisierung aufgrund der begrenzten Bandbreite von entscheidender Bedeutung. Beispielhafte Schlussfolgerungsergebnisse (hypothetisch) Architektur Modellvariante Promptgröße Tokens/Sek. RAM-Nutzung x86_64 Lama 4 Scout int4 512 11.2 ~6,5 GB ARM Neoverse Lama 4 Scout int4 512 8,7 ~6,5 GB RISC-V RV64 Lama 4 Scout int4 512 3.2 ~6,5 GB Diese Ergebnisse setzen Multithread-CPU-Inferenz mit quantisierten Gewichten unter Verwendung von llama.cpp oder ähnlichem voraus. Vom Rohmodell zu GGUF: Warum und wie? Um Meta Llama 4 Scout effizient auf reinen CPU-Systemen auszuführen, insbesondere mit Tools wie llama.cpp, muss das Modell im GGUF-Format vorliegen. Warum zu GGUF wechseln? GGUF (Grokking GGML Unified Format) ist ein kompaktes, speicheroptimiertes Modelldateiformat, das für die CPU- und Edge-Inferenz entwickelt wurde und Folgendes verwendet: llama.cpp mlc-llm text-generation-webui GGUF-Vorteil: Nutzen Speichereffizient: Speichert quantisierte Gewichte und Metadaten. Schnelle Ladezeiten: Keine Notwendigkeit, Konfigurationen erneut zu tokenisieren oder zu parsen Metadaten erhalten: Tokenizer, Vokabular, Modelltyp enthalten Vereinfachte Nutzung: Eine einzige Datei, die mit vielen Tools verwendet werden kann. Wie man Llama 4 Scout in GGUF umwandelt Laden Sie das Rohmodell (HF-Format) herunter Besorgen Sie sich das Originalmodell von Hugging Face (z. B. meta-llama/Meta-Llama-4-Scout-17B). Installieren Sie die Transformer und die llama-cpp-python-Tools. pip install transformers huggingface_hub git clone https://github.com/ggerganov/llama.cppcd llama.cppmake Führen Sie das GGUF-Konvertierungsskript aus. Aus dem Verzeichnis llama.cpp/scripts: python convert.py \ --outfile llama4-scout.gguf \--model meta-llama/Meta-Llama-4-Scout-17B \ --dtype q4_0 3. Laden Sie es in Ihr Inferenztool. Nach der Konvertierung kann die .gguf-Datei direkt ausgeführt werden: ./main -m llama4-scout.gguf -p "Hello, world" GGUF + Quantisierung = CPU-Superkräfte Die Konvertierung in GGUF ermöglicht die Quantisierung während der Konvertierung: q4_0, q4_K, q5_1 und q8_0 werden unterstützt Sie reduzieren die Größe drastisch – von ~34 GB → ~5–7 GB für q4 Es gewährleistet Kompatibilität mit CPU-SIMD-Befehlen wie AVX, SVE oder RVV. Auf RISC-V- oder ARM-Boards mit begrenztem Speicher ist GGUF + int4 oft die einzige Möglichkeit, Llama 4 Scout überhaupt zum Laufen zu bringen. Profi-Tipp: GGUF-Umrechnungsoptionen Sie können die Konvertierungseinstellungen feinabstimmen: --vocab-type zur Anpassung der Tokenizer-Struktur --trust-remote-code, falls das Hugging Face-Repository benutzerdefiniertes Laden verwendet. --quantisieren Sie q4_K für eine bessere int4-Genauigkeit Schlussbetrachtung Metas Llama 4 Scout ist einer der praktischsten Open-Source-LLMs für CPU-Inferenz im Jahr 2025. Mit Quantisierung und SIMD-fähigem Einsatz kann er folgende Aufgaben erfüllen: Edge-Anwendungen (IoT, Telefone) Souveräne Rechenplattformen (RISC-V) Cloud-native Umgebungen ohne GPUs Wenn Sie daran interessiert sind, die Grenzen offener LLMs auf CPU-Architekturen auszuloten, ist Llama 4 Scout einer der besten Ausgangspunkte.

In der Welt des Site Reliability Engineering (SRE) zählen Vertrauen, Wissen und die Umsetzung mehr als alles andere. Als unser Team die Möglichkeit erhielt, einen der führenden Kunden im Bereich der Inferenzsysteme zu betreuen, war uns bewusst, dass der Wettbewerb hart sein würde. Viele etablierte und deutlich größere Unternehmen bewarben sich um dasselbe Projekt. Wir sahen dies jedoch als Chance zu beweisen, dass Expertise, Engagement und der richtige Ansatz Größe und Umfang überwiegen können. Obwohl wir ein relativ kleines Unternehmen sind, konnten wir etwas Einzigartiges bieten: fundierte Benchmarking-Expertise und Branchenkenntnisse , die genau auf die Bedürfnisse des Kunden zugeschnitten waren. Unsere Fähigkeit, komplexe Systeme schnell zu verstehen, Zusammenhänge im Rechenzentrumsbetrieb herzustellen und Lösungen zu entwickeln, hob uns von der Konkurrenz ab. Diese Expertise, kombiniert mit unserer Anpassungs- und Lernbereitschaft, ermöglichte es uns, den Auftrag zu gewinnen und die Verantwortung für den L1-Support ihrer Systeme zu übernehmen – eine Aufgabe, die für ihre Geschäftskontinuität entscheidend ist. Frühe Lernkurve: Aufbau einer soliden Grundlage für SRE Die ersten Monate waren nicht einfach. Wie bei jedem komplexen System erforderte die Infrastruktur zur Gewährleistung der Verfügbarkeit von uns einen steilen Lernprozess. Wir mussten schnell begreifen: Wie Incident-Workloads in der Produktion funktionieren. Die architektonischen Bausteine innerhalb des Inferenz-Ökosystems. Die Hosting-Mechanismen, einschließlich der Struktur der Rechenzentren des Kunden. Die verschiedenen Arten, wie das System ausfallen könnte, und die potenziellen Auswirkungen jedes Ausfallmodus. Jede Schicht bot neue Lernmöglichkeiten. Wir vertieften uns darin, nicht nur zu verstehen, was schiefgelaufen war, sondern auch warum. Langsam, aber stetig wuchs unser Wissen. Jeder Vorfall wurde zu einer Fallstudie, und jede Interaktion mit den Ingenieuren des Kunden erweiterte unser Verständnis. Dies war das Fundament, auf dem unser weiterer Erfolg aufbaute. Vom Schatten zum Hauptverantwortlichen: Der Übergang zur Verantwortung Anfangs arbeiteten wir im 24/7-Schichtbetrieb und begleiteten die Ingenieure des Kunden, die als Hauptansprechpartner fungierten. Bei jedem Vorfall berieten wir uns stundenlang mit dem Team und analysierten jeden Aspekt des Problems. Von den Ursachen bis hin zu den Lösungsschritten stellten wir sicher, dass wir das Problem nicht nur lösten, sondern auch seine architektonischen Auswirkungen verstanden. Dieser Ansatz ermöglichte uns einen umfassenden Überblick über das System. Wir erkannten Abhängigkeiten, Eskalationswege und die entscheidende Bedeutung der Minimierung von Ausfallzeiten , insbesondere da die Endkunden des Auftraggebers strenge SLAs hatten. Ein paar Wochen später kehrten sich die Rollen um. Wir übernahmen die primäre Rufbereitschaft , während die Ingenieure des Kunden in eine unterstützende Funktion wechselten. Dies war ein entscheidender Moment für uns – er bewies das Vertrauen, das der Kunde in unsere Fähigkeiten setzte. Ab diesem Zeitpunkt übernahmen wir die Verantwortung für Vorfälle, analysierten Abhängigkeiten und eskalierten diese bei Bedarf an höherrangige Teams (L2/L3). Dank unserer zeitnahen und korrekten Eskalationen konnte der Kunde in mindestens zwei kritischen Fällen SLA-Verletzungen vermeiden. Indem wir die Ausfallzeiten während dieser Vorfälle deutlich reduzierten, demonstrierten wir unsere Fähigkeit, nicht nur zu reagieren, sondern auch die Geschäftskontinuität zu gewährleisten . Innovation: Entwicklung von Dashboards und Überwachungstools Nachdem wir uns in unsere Aufgaben eingearbeitet hatten, erkannten wir, dass die vorhandenen Tools für die von uns angestrebte proaktive Überwachung und Berichterstattung nicht ausreichten. Um diese Lücke zu schließen, ergriffen wir die Initiative und entwickelten individuelle Dashboards , die Transparenz und umsetzbare Erkenntnisse lieferten. Schicht-Dashboard : Zeigt in Echtzeit die aktuell diensthabenden Techniker, offene Probleme, gelöste Fälle und Eskalationen an. Incident-Dashboard : Zeigte Trends bei Vorfällen auf Tages-, Modell- und Rechenzentrumsebene – und entwickelte sich so zu einem unverzichtbaren Werkzeug für die wöchentliche Analyse. Wöchentliches Übersichts-Dashboard : Automatisch generierte detaillierte Berichte über die Vorfälle der vergangenen Woche, einschließlich Eskalationsdaten und Problemmuster. Diese Tools gehörten ursprünglich nicht zum Leistungsumfang, wir waren jedoch überzeugt, dass sie einen Mehrwert bieten würden. Im Laufe der Zeit wurden sie zu einem integralen Bestandteil des wöchentlichen Analyseprozesses des Kunden, vereinfachten dessen Arbeitsabläufe und verbesserten die Entscheidungsfindung. Kontinuierliches Lernen und Anpassung an Veränderungen Prognosemanagementsysteme sind von Natur aus dynamisch. Wöchentliche Bereitstellungen, neue Modelle und ständige Aktualisierungen sorgten dafür, dass die Umgebung nie statisch war. Wir haben Prozesse eingerichtet, um mit diesen Veränderungen Schritt zu halten und sicherzustellen, dass unser Wissen stets aktuell ist. Regelmäßige Kurzbesprechungen, Review-Meetings und Wissensaustausch mit den Ingenieuren des Kunden wurden zu einem festen Bestandteil unserer Routine. Dieser kollaborative Ansatz sorgte für die Abstimmung beider Seiten und ermöglichte es uns, schnell auf Änderungen in Protokollen, Architektur oder Bereitstellungsmethoden zu reagieren. Innerhalb von 5–6 Monaten hatten wir uns von einem Team, das sich erst einarbeiten musste, zu einem selbstbewussten, vertrauenswürdigen Partner entwickelt, der in der Lage war, L1-Aufgaben selbstständig zu übernehmen und gleichzeitig wertschöpfende Innovationen zu liefern. Herausforderungen und deren Bewältigung Die Reise verlief nicht ohne Herausforderungen. Wir stießen auf Folgendes: Neue Arten von Vorfällen : Jedes Mal, wenn wir mit etwas Neuem konfrontiert wurden, dokumentierten wir das Problem und die Lösungsschritte und bauten so ein Repository für zukünftige Referenzzwecke auf. Häufige Bereitstellungen : Dies erforderte von uns, agil zu bleiben und unsere Prozesse wöchentlich anzupassen. Mehrere Modelle und neue Rechenzentren : Zusätzliche Komplexität bei Überwachung und Störungsbehebung. Störungsspitzen : Gelegentlich kam es während einer einzigen 8-Stunden-Schicht zu einer Häufung von Störungen. Unsere Bereitschaftstechniker bewältigten diese Situationen ruhig, priorisierten die Probleme, eskalierten sie gegebenenfalls und stellten die Systemstabilität sicher. Jede Herausforderung war eine Gelegenheit, unsere Prozesse zu verfeinern, unser Wissen zu vertiefen und den Mehrwert für den Kunden zu steigern. Fazit: Eine Reise des Vertrauens und der Wertschätzung Rückblickend entwickelte sich das anfängliche Konkurrenzangebot an größere Marktteilnehmer zu einer bemerkenswerten Reise voller Vertrauen, Wachstum und Erfolg. Innerhalb weniger Monate wandelten wir uns von Beobachtern zu Hauptverantwortlichen für die Systemzuverlässigkeit . Unsere Beiträge gingen über den Rahmen der L1-Unterstützung hinaus: Durch effektives Störungsmanagement und rechtzeitige Eskalation konnten wir Ausfallzeiten reduzieren. Wir haben maßgeschneiderte Dashboards entwickelt, die Transparenz, Überwachung und Berichterstattung verbesserten. Wir haben einen Prozess des kontinuierlichen Lernens und Anpassens eingerichtet, um mit den dynamischen Entwicklungen Schritt halten zu können. Wir haben die Bearbeitung von Vorfällen dokumentiert und standardisiert, wodurch zukünftige Lösungen schneller und zuverlässiger werden. Am wichtigsten war, dass wir für unseren Kunden zu einem vertrauenswürdigen Partner wurden – nicht nur zu einem Support-Team. Unsere Entwicklung hat gezeigt, dass Größe kein Hindernis darstellt, wenn Expertise, Engagement und Innovationskraft zusammenkommen. Diese Erfolgsgeschichte beweist die Widerstandsfähigkeit, Lernfähigkeit und den unbedingten Willen unseres Teams, Mehrwert zu schaffen. Sie unterstreicht, dass in der heutigen schnelllebigen Technologielandschaft Zuverlässigkeit und Vertrauen die Grundpfeiler jeder erfolgreichen Partnerschaft sind.

DLRM steht für Deep Learning Recommendation Model. Es handelt sich um eine von Facebook AI (Meta) entwickelte neuronale Netzwerkarchitektur für personalisierte Empfehlungssysteme im großen Maßstab. DLRM findet breite Anwendung in realen Projekten, in denen personalisierte Empfehlungen oder Ranking-Vorhersagen benötigt werden. DLRM ist speziell für die Vorhersage der Klickrate (CTR) und für Ranking-Aufgaben konzipiert. Beispiele: Online-Werbung, E-Commerce-Empfehlungen, Ranking von Social-Media-Feeds, Streaming-Dienste, Online-Marktplätze und Kleinanzeigen usw. DLRM-Funktionen: DLRM-Installationsoptionen: Installieren Sie Original Facebook DLRM (PyTorch) mit Git und Python. Installieren Sie DLRM mit TorchRec Installieren Sie NVIDIA DLRM DLRM in Docker installieren (nur CPU oder GPU) Welche Beziehung besteht zwischen DLRM und PyTorch? DLRM basiert auf PyTorch. PyTorch dient als grundlegendes Deep-Learning-Framework, das jede Komponente innerhalb von DLRM antreibt. PyTorch ist das Framework; DLRM ist das Modell DLRM ist kein Framework, sondern eine spezifische neuronale Netzwerkarchitektur, die von Meta (Facebook) für groß angelegte Empfehlungssysteme entwickelt wurde. PyTorch bietet: DLRM verwendet diese Werkzeuge, um seine dichten MLPs, Einbettungstabellen und Merkmalsinteraktionsschichten zu konstruieren. PyTorch-Installationsoptionen: PyTorch kann je nach Umgebung, Hardware und Arbeitsablauf auf verschiedene Arten installiert werden. Installation via pip (am häufigsten und einfachsten) Installation via Conda (Am besten geeignet für GPU-Umgebungen) Installation via Docker (Isoliert & Produktionsfreundlich) Installation aus dem Quellcode (Für Entwickler und benutzerdefinierte Builds) PyTorch-Installation in der Cloud Installation über Paketmanager (eingeschränkte Betriebssystemunterstützung) PyTorch-Installation via Docker: Die Installation von PyTorch über Docker ist eine der zuverlässigsten und unkompliziertesten Methoden, eine Deep-Learning-Umgebung einzurichten. Anstatt Python-Versionen, CUDA-Toolkits, cuDNN-Bibliotheken und Systemabhängigkeiten manuell zu verwalten, bietet Docker einen vorkonfigurierten Container, in dem alles sofort einsatzbereit ist. Durch das Herunterladen eines offiziellen PyTorch-Images – entweder nur für die CPU oder mit CUDA-Unterstützung – erhalten Sie eine isolierte und reproduzierbare Umgebung, die auf jedem Rechner identisch läuft. Kurzanleitung 1. Ein Bild auswählen Nur CPU: docker pull pytorch/pytorch:latest GPU (CUDA 11.8 Beispiel): docker pull pytorch/pytorch:latest-cuda11.8-cudnn8-runtime 2. Führen Sie den Container aus CPU: docker run -it pytorch/pytorch:latest bash GPU (mit NVIDIA Container Toolkit): docker run -it --gpus all pytorch/pytorch:latest-cuda11.8-cudnn8-runtime bash 3. Überprüfen Sie den Inhalt des Behälters. python3 -c "import torch; print(torch.__version__); print('cuda:', torch.cuda.is_available ())" Wie kann man DLRM in einem PyTorch-Docker-Container ausführen? PyTorch-Docker-Image herunterladen Starten Sie den Container Abhängigkeiten installieren (innerhalb des Containers) DLRM-Repository klonen DLRM ausführen DLRM-Befehl: Für den effektiven Einsatz von DLRM ist es wichtig, die wichtigsten Befehlszeilenoptionen zu verstehen, die das Laden von Daten, die Modellarchitektur, die Trainingskonfiguration und die Leistungsoptimierung steuern. DLRM akzeptiert eine Vielzahl von Parametern, mit denen sich alles von der Batchgröße bis zu den Einbettungsdimensionen konfigurieren lässt. Diese Optionen lassen sich in vier Hauptkategorien einteilen: Datenoptionen Schulungsmöglichkeiten Optionen für die Modellarchitektur System-/Leistungsoptionen Häufig verwendeter DLRM-Befehl: python dlrm_s_pytorch.py \     --data-generation=synthetic \     --mini-batch-size=2048 \     --learning-rate=0.01 \     --arch-sparse-feature-size=16 \     --arch-mlp-bot="13-512-256-64-16" \     --arch-mlp-top="512-256-1" \     --print-freq=10 Abschluss Die Verwendung von PyTorch-Docker-Containern zum Ausführen von DLRM (Deep Learning Recommendation Model) bietet eine optimierte, konsistente und reproduzierbare Umgebung auf verschiedenen Hardwareplattformen. Docker beseitigt Abhängigkeitskonflikte, vereinfacht die Einrichtung und gewährleistet die nahtlose Bereitstellung des exakten Software-Stacks – PyTorch-Version, Bibliotheken und Optimierungen. Kurz gesagt, bietet PyTorch Docker + DLRM einen zuverlässigen, flexiblen und effizienten Weg zum Trainieren. Bewertung und Implementierung von Empfehlungsmodellen mit minimalem Aufwand.

Dieser Blogbeitrag vergleicht die Leistung zweier führender Anbieter: AWS Graviton4 (basierend auf AWS r8g-Instanzen) und Google Axion (basierend auf GCP Axion-Instanzen). Beide basieren auf der fortschrittlichen Arm Neoverse-V2-Architektur. Wir untersuchen ihre Performance anhand von Valkey 8.0.1, einem gängigen In-Memory-Datenspeicher. Die Konkurrenten: AWS Graviton4 und Google Axion AWS Graviton und Google Axion repräsentieren die neueste Generation ARM-basierter Serverprozessoren von Amazon und Google. Beide nutzen die Arm Neoverse-V2 CPU-Architektur, die speziell für Cloud Computing, maschinelles Lernen und High-Performance Computing (HPC) entwickelt wurde. Diese maßgeschneiderten Chips bieten im Vergleich zu herkömmlichen x86-basierten Alternativen eine überlegene Leistung und Energieeffizienz. Der Benchmark: Valkey 8.0.1 Für einen aussagekräftigen Vergleich wählten wir Valkey 8.0.1, einen leistungsstarken Open-Source-In-Memory-Datenspeicher. Valkey ist ein Fork von Redis und wird häufig für Caching, Sitzungsverwaltung und Echtzeitanalysen eingesetzt. Dadurch eignet es sich hervorragend, um die Verarbeitungs- und Speicherkapazität dieser Instanzen zu testen. Unser Benchmark-Setup wurde so konfiguriert, dass ein fairer Vergleich gewährleistet ist. Valkey-Serverkerne: Der Valkey-Server war auf die Kerne 2 bis 7 festgelegt. Anfrageparameter: Jedes Experiment umfasste 100 Millionen parallele Anfragen, 256 Clients und eine Nutzlastgröße von 1024 KiB. Leistungskennzahlen: Wir konzentrierten uns auf zwei Schlüsselkennzahlen: Anfragen pro Sekunde (RPS) für den Durchsatz und P99-Latenz (das 99. Perzentil) für die Reaktionsfähigkeit. Experiment 1: Netzwerkleistung Im ersten Experiment wurde die Leistung getestet, wenn die Valkey-Client- und Serverinstanzen auf separaten Hosts innerhalb desselben Clusternetzwerks liefen. Dieses Szenario verdeutlicht die Effizienz der zugrundeliegenden Netzwerkvirtualisierung und -verbindungen, die für viele verteilte Workloads entscheidend sind. IRQ-Pinning: Für diesen Test haben wir IRQ-Pinning auf den Kernen 0 und 1 verwendet. Dadurch werden bestimmte CPU-Kerne für die Bearbeitung von Netzwerk-Interrupts reserviert, wodurch verhindert wird, dass diese die Arbeitslast des Valkey-Servers beeinträchtigen und eine stabilere und genauere Messung der Netzwerkleistung gewährleistet wird. Verteilte Anwendung AWS r8g Instanzergebnisse GCP Axion-Instanzergebnisse SET RPS 925.860 790.020 P99-Latenz einstellen 0,431 ms 0,655 ms RPS ERHALTEN 941.802 870.920 P99-Latenz abrufen 0,415 ms 0,543 ms In diesem netzwerkintensiven Test übertrafen die AWS r8g-Instanzen GCP Axion sowohl bei SET- als auch bei GET-Operationen durchweg, mit höherem Durchsatz und geringerer P99-Latenz. Dies deutet darauf hin, dass die Netzwerkfunktionen des AWS Nitro Systems, die eng mit dem Graviton4-Prozessor integriert sind, einen deutlichen Vorteil für verteilte, netzwerksensitive Anwendungen bieten. Experiment 2: Leistung auf demselben Host Im zweiten Experiment wurde die reine Rechenleistung bewertet, indem sowohl der Valkey-Client als auch der Server auf demselben Host ausgeführt wurden. Dieser Test minimiert den Netzwerk-Overhead und konzentriert sich auf die CPU- und Speicherleistung. Anwendung auf demselben Host AWS r8g-Instanzergebnisse: GCP Axion-Instanzergebnisse: SET RPS 1.024.894 894.262 P99-Latenz einstellen 0,407 ms 0,367 ms RPS ERHALTEN 1.060.186 942.720 P99-Latenz abrufen 0,359 ms 0,303 ms Die Ergebnisse zeigen hier ein differenzierteres Bild. Während AWS r8g-Instanzen erneut einen höheren Gesamtdurchsatz (RPS) erzielten, wiesen die GCP Axion-Instanzen eine geringere P99-Latenz sowohl für SET- als auch für GET-Operationen auf. Dies deutet darauf hin, dass die Architektur von AWS zwar auf maximalen Durchsatz optimiert sein mag, Googles Design jedoch die niedrige Latenz priorisiert – ein zentrales Merkmal des Befehlsausführungsmodells von Valkey. Schlussfolgerung und Analyse Die Benchmark-Ergebnisse zeichnen ein klares Bild: Bei dieser spezifischen Arbeitslast sind die AWS Graviton4-basierten r8g-Instanzen hinsichtlich des Rohdurchsatzes führend, während die Google Axion-Instanzen sich durch geringe Latenz auszeichnen. AWS r8g (Graviton4): Die höhere RPS in beiden Experimenten deutet darauf hin, dass die AWS-Implementierung stark für parallele und hochdurchsatzfähige Workloads optimiert ist, wahrscheinlich aufgrund einer engen Integration mit dem AWS Nitro System. GCP Axion: Die niedrigere P99-Latenz im Test auf demselben Host ist ein aussagekräftiger Indikator. Sie deutet darauf hin, dass Googles Axion-Prozessor über ein effizienteres Kerndesign oder eine optimierte Cache-Struktur verfügt, was insbesondere bei Workloads mit hohen Anforderungen an niedrige Latenzzeiten von Vorteil ist.

LLMs werden besser und kleiner Betrachten wir Llama als Beispiel. Die rasante Entwicklung dieser Modelle verdeutlicht einen wichtigen Trend in der KI: die Priorisierung von Effizienz und Leistung. Als der Llama 2 70B im August 2023 auf den Markt kam, galt er als erstklassiges Einsteigermodell. Seine enorme Größe erforderte jedoch leistungsstarke Hardware wie den NVIDIA H100-Beschleuniger. Knapp neun Monate später präsentierte Meta den Llama 3 8B, ein Modell, das um fast das Neunfache verkleinert wurde. Dadurch konnte er mit kleineren KI-Beschleunigern und sogar optimierten CPUs betrieben werden, was die Hardwarekosten und den Stromverbrauch drastisch reduzierte. Beeindruckenderweise übertraf der Llama 3 8B seinen größeren Vorgänger in Genauigkeitstests. Setup-Details Getestet mit llama.cpp auf Maschine: Gv4 r8g.24xlarge Betriebssystem: Ubuntu 2204 Kernel: 6.8.AWS Modell: Meta-Llama-3.1-8B-Instruct- Q8_0.gguf Testdurchlauf nproc x nthreads x bs [1-32] Grafiken mit Beobachtungen, die Vorteile hervorheben Die Token-Generierung erfolgt autoregressiv und reagiert sehr empfindlich auf die benötigte Ausgabelänge. ARM-Optimierungen helfen hier bei größeren Batchgrößen und steigern den Durchsatz um mehr als das Doppelte. Abschluss Für Meta-Llama-3.1-8B-Instruct- Q8_0.gguf kann Graviton4 161 Token pro Sekunde generieren, was 102.486 Token pro Dollar entspricht.

Das Fuzzing von RISC-V-Compilern wie GCC und LLVM ist eine unerlässliche Methode, um die Korrektheit und Sicherheit des gesamten auf dieser Architektur basierenden Software-Ökosystems zu gewährleisten. Dabei geht es nicht darum, Schwachstellen im kompilierten Code zu finden, sondern vielmehr darum, Fehler im Compiler selbst aufzudecken, die zu fehlerhafter Codegenerierung, unerwartetem Verhalten oder sogar ausnutzbaren Sicherheitslücken führen könnten. Warum Compiler-Fuzzing eine einzigartige Herausforderung darstellt Das Fuzzing von Compilern unterscheidet sich vom Fuzzing typischer Anwendungen. Anstatt einem Programm zufällige Daten zuzuführen, generiert man zufälligen, aber syntaktisch korrekten Quellcode, der dem Compiler übergeben wird. Ein einfacher Fuzzer, der lediglich Bytes verändert, erzeugt schnell Code, der nicht einmal geparst werden kann, und übersieht so tieferliegende Fehler. Das Hauptziel des Compiler-Fuzzings ist die Erkennung zweier Haupttypen von Fehlern: Abstürze und Panikzustände: Der Fuzzer generiert Code, der während der Kompilierung zum Absturz, zum Hängenbleiben oder zu einem schwerwiegenden Fehler des Compilers führt. Dies deutet auf einen Compilerfehler hin, der behoben werden muss. Fehlkompilierungen: Dies ist die gefährlichste Art von Fehlern. Der Compiler kompiliert den getesteten Code zwar erfolgreich, der generierte Maschinencode (RISC-V-Assembler) ist jedoch fehlerhaft. Dies kann zu unbemerkten Datenbeschädigungen, Sicherheitslücken oder unvorhersehbarem Programmverhalten führen. Um solche Fehler zu finden, ist eine Technik namens differentielles Fuzzing erforderlich . Die Leistungsfähigkeit des differentiellen Fuzzing für RISC-V-Compiler Differential Fuzzing ist eine außerordentlich leistungsstarke Technik zum Auffinden von Fehlkompilierungen in RISC-V-Compilern. So funktioniert es: Ein Fuzzer, oft ein Programm, das gültigen C- oder C++-Code generiert (wie z. B. csmith), erzeugt ein einzigartiges Programm. Dieses Programm wird von mindestens zwei verschiedenen Compilern (z. B. GCC und LLVM) oder mit unterschiedlichen Optimierungsflags (z. B. -O0 und -O3) kompiliert. Die kompilierten Binärdateien werden anschließend ausgeführt und ihre Ausgaben verglichen. Stimmen die Ausgaben nicht überein, bedeutet dies, dass mindestens einer der Compiler einen Kompilierungsfehler aufweist. Der Fuzzer speichert diesen spezifischen Quellcode dann als Testfall zur Analyse durch einen Entwickler. Diese Methode nutzt im Prinzip ein „Testorakel“, um Fehler automatisch zu identifizieren, ohne dass die korrekte Ausgabe vorher bekannt sein muss. Dies ist ein Hauptgrund dafür, dass so viele Compilerfehler sowohl in GCC als auch in LLVM gefunden wurden. Wichtige Werkzeuge und Repositories für das Fuzzing von RISC-V-Compilern Während viele der zuvor erwähnten Allzweck-Fuzzer (wie AFL++) zum Fuzzing des Quellcodes eines Compilers verwendet werden können, sind oft spezialisierte Werkzeuge erforderlich, um gültigen RISC-V-spezifischen Code effektiv zu generieren und zu testen. csmith: Dies ist ein bekannter, randomisierter Testfallgenerator für C-Programme. Er erzeugt komplexen, gültigen C-Code, der sich ideal für differentielle Tests von C-Compilern wie GCC und LLVM eignet. Obwohl er nicht RISC-V-spezifisch ist, ist er ein unverzichtbarer Bestandteil des Workflows zum Fuzzing des RISC-V-Backends jedes C-Compilers. GitHub-Repository: https://github.com/csmith-project/csmith RISCV-DV: Dieses von der RISC-V-Community gepflegte Tool dient primär der Designverifikation von RISC-V-Prozessoren, kann aber auch zur Generierung komplexer Befehlssequenzen für das Testen von Compiler-Backends verwendet werden. Es ist hochgradig konfigurierbar und kann spezifische ISA-Erweiterungen ansprechen. GitHub-Repository: https://github.com/google/riscv-dv IRFuzzer: Ein spezialisierter Fuzzer für das LLVM-Backend . Anstatt C/C++-Quellcode zu generieren, erzeugt er die LLVM-Zwischenrepräsentation (IR). Dadurch kann er die Backend-Codegenerierung direkt testen, ohne sich um Frontend-Fehler kümmern zu müssen. Dies ist ein sehr gezielter Ansatz, um Probleme im RISC-V-Codegenerator von LLVM zu finden. GitHub: Als Recherchetool findet man häufig Ressourcen auf arXiv und Universitätswebseiten. Die Suche nach „IRFuzzer“ auf GitHub führt zu verwandten Projekten. RISCV-Vector-Intrinsic-Fuzzing (RIF): Ein spezieller Fuzzer, der mithilfe der RISC-V Vector Extension (RVV)-Intrinsics Zufallscode generiert. Dies ist unerlässlich, um zu überprüfen, ob Compiler wie GCC und LLVM diesen komplexen und leistungskritischen Teil der RISC-V-ISA korrekt implementieren. GitHub-Repository: https://github.com/sifive/riscv-vector-intrinsic-fuzzing Patrick-rivos/compiler-fuzz-ci: Dieses GitHub-Repository bietet ein hervorragendes Beispiel für eine Continuous-Integration-Umgebung (CI) zum Fuzzing von RISC-V-Compilern. Es zeigt, wie man Tools wie csmith mit einer CI-Pipeline kombiniert, um GCC und LLVM automatisch zu fuzzing und Fehler zu melden. GitHub-Repository: https://github.com/patrick-rivos/compiler-fuzz-ci Das Fuzzing von RISC-V-Compilern ist eine fortlaufende und entscheidende Aufgabe. Es stellt sicher, dass die Softwareentwickler darauf aufbauend zuverlässig, sicher und korrekt auf die zugrunde liegende Hardware übersetzt wird, wodurch das gesamte RISC-V-Ökosystem gestärkt wird.