Apertus AI v1.5 70B mit Vision, Tool Calling und bis zu 229k Tokens Kontext auf einer einzelnen NVIDIA RTX PRO 6000 Blackwell

Die Swiss AI Initiative ist die nationale KI-Initiative der Schweiz: eine Zusammenarbeit der ETH Zürich und der EPFL Lausanne. Die Modelle werden auf dem Supercomputer “Alps” am Swiss National Supercomputing Centre (CSCS) in Lugano trainiert.

Apertus v1.5 70B wurde soeben veröffentlicht und bringt genau das, was ein Modell im Arbeitsalltag nützlich macht: Vision Input (Diagramme, Screenshots, gescannte Dokumente), natives Tool Calling im strukturierten OpenAI-Format und ein Kontextfenster, das von 65k auf 262k Tokens gewachsen ist. Die offizielle Referenz zum Ausführen setzt auf zwei NVIDIA H200-Rechenzentrums-GPUs, aber eine quantisierte Version serviert 192k Tokens komfortabel auf einer einzelnen NVIDIA RTX PRO 6000 Blackwell, mit einem gemessenen Maximum von 229k, wenn nahezu die gesamten 96 GiB der Karte genutzt werden.

Compliance by Design

Apertus ist für transparenten, prüfbaren Betrieb unter europäischen Regulierungsanforderungen konzipiert, mit offenen Gewichten, Trainingsdokumentation, Data-Governance-Offenlegungen und EU AI Act Transparenzunterlagen. Für Organisationen unter dem EU AI Act ist das ein anderer Ausgangspunkt als eine proprietäre Black-Box.

Apertus ist nicht nur open weights. Es ist so aufgebaut, dass auch Legal- und Compliance-Teams es abzeichnen können. Das Modell wird ausschliesslich auf öffentlich verfügbaren Daten trainiert, wobei maschinenlesbare Opt-Outs von Websites, wo möglich, sogar retroaktiv respektiert werden. Personenbezogene Daten werden vor dem Training herausgefiltert, und wörtliches Memorieren von Trainingsdaten wird technisch unterdrückt. Gewichte, Daten, Rezepte und die für den EU AI Act erforderliche Transparenzdokumentation werden alle unter Apache 2.0 veröffentlicht.

Das Problem

Das Modell wird als rund 145 GB (135 GiB) BF16 Gewichte ausgeliefert. Die offizielle Referenz zum Ausführen setzt auf zwei Rechenzentrums-NVIDIA H200 GPUs: NVLink-Boards, der ganze Maschinenraum. Genau diese Abhängigkeit soll On-Premise KI vermeiden.

Die Lösung

Wir haben eine in der Praxis erprobte dreistufige Mixed-Precision Quantisierung entwickelt, die Apertus v1.5 70B mit einem 192k-Kontextprofil auf einer einzelnen NVIDIA RTX PRO 6000 Blackwell (96 GB VRAM) ausführt, der GPU der Wahl für Enterprise On-Premise Inferenzserver. Bei einem Bruchteil der Hardwarekosten decodiert die Kompression 55% schneller und verwendet 32% weniger Gewichtsspeicher als die FP8-Variante.

TL;DR: Einfach ausführen

Wir veröffentlichen den 48 GiB NVFP4 Checkpoint auf Hugging Face und das temporäre vLLM Build-Rezept auf GitHub. Bis Apertus 1.5 in einem nativen vLLM Release landet, ist der passende Container als onpremai/vllm-apertus-1p5 auf Docker Hub erhältlich. Sie brauchen nur einen Rechner mit einer NVIDIA RTX PRO 6000 Blackwell (96 GB), NVIDIA Treibern und Docker mit dem NVIDIA Container Toolkit:

docker pull onpremai/vllm-apertus-1p5:latest

docker run --gpus all -v /path/to/model:/model \
  onpremai/vllm-apertus-1p5:latest \
  --model /model \
  --served-model-name apertus-v1.5-70b \
  --host 0.0.0.0 --port 8080 \
  --dtype auto \
  --chat-template /model/chat_template.jinja \
  --tool-call-parser apertus --enable-auto-tool-choice \
  --reasoning-parser apertus

Nach etwa drei Minuten haben Sie einen OpenAI-kompatiblen Endpunkt auf Port 8080. Sie können mit Text, Tools oder Bildern über die Standard-Chat-Completions-API kommunizieren:

# 3. Anfrage senden
curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "apertus-v1.5-70b",
    "messages": [{"role": "user", "content": [
      {"type": "text", "text": "Was zeigt dieses Diagramm?"},
      {"type": "image_url", "image_url": {"url": "data:image/png;base64,..."}}
    ]}]
  }'

Jeder OpenAI-kompatible Client funktioniert unverändert: LangChain, das openai Python SDK oder ein Gateway wie LiteLLM davor (siehe unser LLM API Standards Guide). Der Rest dieses Artikels beschreibt das vollständige Rezept dahinter.

Ressourcen: NVFP4 Gewichte und Model Card · FP8 Referenz-Checkpoint · Docker Build Source · Docker Hub Image

Was Quantisierung ist und warum sie kein einfacher Knopfdruck ist

Ein 70B-Modell in BF16 speichert jedes Gewicht in 16 Bit: 2 Bytes x 70 Milliarden, plus Embeddings, insgesamt 135 GiB bevor auch nur ein Token Ihrer Anfrage verarbeitet wird. Quantisierung speichert diese Gewichte in weniger Bits (8 oder sogar 4) und skaliert sie so, dass die Matrixmultiplikationen trotzdem ungefähr stimmen. Weniger Speicher, weniger Speicherdurchsatz, schnelleres Decoding.

Das “ungefähr” ist, wo die Ingenieursarbeit steckt. Drei Dinge machen Apertus schwieriger zu quantisieren als einen gewöhnlichen Llama-Abkömmling:

1. Es ist kein Llama-Klon. Apertus verwendet die xIELU-Aktivierungsfunktion und ein Non-Gated MLP; es gibt kein gate_proj Modul. Gängige Quantisierungswerkzeuge hardcodieren LLaMAs Modullayout und sind bei Apertus auf zwei verschiedenen Code-Pfaden abgestürzt, bevor wir Workarounds eingebaut haben.

2. Einige Schichten verstärken Quantisierungsrauschen. xIELU quadriert seinen Input, daher wird 4-Bit-Rauschen im Attention-Pfad downstream verstärkt. In unseren früheren Experimenten mit dem 8B-Modell führte die Quantisierung von Attention auf 4 Bit zu NaN Logits, einem völlig zerstörten Modell. Attention braucht eine sanftere Behandlung.

3. Der Wortschatz ist enorm. Apertus v1.5 hat ein Vokabular von 266.752 Tokens, weil Bilder als diskrete Tokens im selben Raum wie Text dargestellt werden (131k Vision-Tokens + Text + Sonderzeichen). Die damit verbundenen Embedding- und Output-Layer sind qualitätskritisch und überproportional empfindlich.

Ein naives “quantisiere alles auf 4 Bit” führt also entweder zu einem Absturz oder einem lobotomierten Modell. Die Antwort ist, verschiedene Schichten unterschiedlich zu behandeln.

Das Dreistufen-Rezept

Der Grossteil der Gewichte wird auf NVFP4 komprimiert, NVIDIAs 4-Bit Gleitkommaformat, das nativ auf der Blackwell GPU-Architektur beschleunigt wird. Die rauschempfindlichen Attention-Layer bleiben bei FP8, und die fragilsten Teile bleiben unangetastet bei BF16. Vision und Tool Calling bleiben intakt.

Mit anderen Worten: Wir haben jede Schichtengruppe so aggressiv quantisiert, wie sie es verträgt, und nicht mehr:

Der KV-Cache (der Speicher, der mit der Kontextlänge wächst) läuft ebenfalls in FP8, was die Anzahl gleichzeitiger Unterhaltungen auf der Karte verdoppelt: Der KV-Pool fasst 207.760 Tokens, ein Budget von 192k Tokens Kontext auf einer einzelnen Karte.

Zwei Details gefallen uns besonders:

• Die komplette Zwei-Pass-Konvertierung dauerte rund 3,4 Minuten: 1,9 Minuten für die NVFP4-MLP-Quantisierung und 1,3 Minuten für die FP8-Attention-Quantisierung. Kein Kalibrierungsdatensatz, keine Cloud GPU-Miete, kein Verschieben von Gewichten. Die Quantisierung streamt die Safetensors-Shards, ohne das vollständige Modell zu laden, was eine Konvertierung eines 135 GiB Modells auf einem Rechner mit 64 GB RAM ermöglicht.
• Sie ist reproduzierbar: Das Rezept ist ein kurzes Python-Skript, das die Open-Source-Bibliothek llm-compressor verwendet.

Ergebnisse

Gemessen auf einer NVIDIA RTX PRO 6000 Blackwell (96 GB), vLLM, identische Prompts:

Kontext, genau: Mit FP8 KV-Cache bei 90% GPU-Speicherauslastung stellt das Modell einen 207.760-Token KV-Pool bereit und läuft mit einem 192k max-model-len Profil komfortabel. Bei einer Auslastung von 95% unterstützt ein gemessenes 229k-Profil, lässt aber praktisch keinen operativen Spielraum. Das volle native 262.144-Token Fenster passt nicht auf eine einzelne 96 GiB Karte. Der FP8-Kontext wurde nicht mit der gleichen Methodik erschöpfend profiliert; nach dem Laden der Gewichte bleiben rund 14 GiB übrig, was Kontext und multimodalen Spielraum deutlich einschränkt.

Performance und Qualität

Der 48 GiB NVFP4 Checkpoint decodiert 55% schneller als die 71 GiB FP8 Variante (30,7 vs 19,8 TPS) und verwendet 32% weniger Gewichtsspeicher.

Auf MMLU erreichte FP8 72,05% und NVFP4 71,26%. Das ist ein absoluter Unterschied von 0,79 Punkten, oder 1,1% relativ. Der aggregierte Unterschied liegt innerhalb der kombinierten statistischen Unsicherheit dieser Durchläufe. Praktisch behält der 48 GiB Checkpoint rund 99% der FP8 Benchmark-Qualität bei, während er 32% weniger Gewichtsspeicher verwendet und 55% schneller decodiert. Der Tradeoff ist ein kleiner, gemessener MMLU-Unterschied von 0,8 Punkten.

Frühere RC-Regressionstests zeigten zudem 93,7% Token-Übereinstimmung und eine mediane Top-10-Verteilungsabweichung von 0,018 gegenüber FP8. Diese Zahlen waren eine nützliche technische Validierung des Quantisierungsrezepts, aber der oben stehende MMLU-Vergleich ist das stärkere Publikationsergebnis für den Checkpoint der offiziellen Release.

Multistream-Durchsatz

Wir haben NVFP4 und FP8 auf einer einzelnen RTX PRO 6000 Blackwell in Bezug auf Generationsdurchsatz, Prefill-Durchsatz und maximale Time-to-First-Token (TTFT) verglichen. Jede Parallelitätsstufe sendet 10 Anfragen mit zufälligen 200-Wort-Prompts (~270 Input-Token) und generiert 200 Ausgabe-Token pro Anfrage. Die Generationsgeschwindigkeit ist completion_tokens / wall_time, der Prefill-Durchsatz prompt_tokens / wall_time. Die genauen Zahlen stehen in der Anhang-Tabelle.

Die beiden Diagramme unten visualisieren dieselben Daten: zuerst den Generationsdurchsatz, dann den Prefill-Durchsatz.

NVFP4 übertrifft FP8 beim Generationsdurchsatz über den gesamten Bereich um etwa 4% bis 55% (55% bei Parallelität 1, 37% bei Parallelität 8, 4% bei Parallelität 48). Der NVFP4-Prefill-Durchsatz liegt konstant 11% bis 15% tiefer, und die NVFP4-max-TTFT ist 14% bis 17% höher, was die zusätzliche Decodiergeschwindigkeit auf Kosten eines etwas langsameren Prefills widerspiegelt. Ab Parallelität 56 und darüber gleichen sich die beiden Formate beim Generationsdurchsatz an, da die Speicherbandbreite der Karte erreicht wird. Die Rohwerte für jede Parallelitätsstufe finden sich in der Anhang-Tabelle.

Eine Karte statt zwei, mit niedrigerer bewerteter GPU-Leistung

Die Zwei-H200-Referenz hat eine GPU-Boardleistung von 2 x 600 W = 1.200 W (H200 NVL) bis 2 x 700 W = 1.400 W (H200 SXM). Die NVIDIA RTX PRO 6000 Blackwell ist mit 600 W Gesamt-Boardleistung angegeben: eine Karte statt zwei, mit ungefähr halb so hoher bewerteter GPU-Leistung. Der Vergleich basiert auf der von NVIDIA angegebenen Boardleistung, nicht auf gemessener Steckdosenleistung. Die tatsächliche Systemenergie hängt von Auslastung, CPUs, Kühlung und Netzteilwirkungsgrad ab.

Und es ist kein “läuft, aber langsam”-Kompromiss: Weil die LLM-Decoding-Geschwindigkeit durch die Speicherbandbreite begrenzt ist, decoden kleinere Gewichte schneller. Unser quantisiertes Modell generiert im Einzelstream 30,7 Tokens/s gegenüber 19,8 Tokens/s für die FP8-Version desselben Modells auf derselben Karte.

Bei derselben 600 W GPU-Leistungsaufnahme impliziert der Durchsatzunterschied rund 35% weniger Energie pro generiertem Token. Die tatsächliche Energieverwendung hängt von gemessener Boardleistung und Workload ab.

Ein Community-Vorhaben: vom Release zum lauffähigen Modell

Ein Modell allein reicht nicht. Der Grund, warum Apertus 1.5 heute reibungslos auf einer einzigen Workstation GPU läuft, ist ein verteilter, ehrenamtlicher Aufwand über Open-Source-Projekte, Organisationen und individuelle Mitwirkende hinweg.

Das schwierigste Stück war der Serving-Stack. Standard vLLM verstand Apertus’ Emu3.5 Vision-Encoder und multimodalen Tokenizer nicht. blancsw bei Infomaniak hat Monate damit verbracht, die multimodale Pipeline so zu refactorisieren, dass die Encoder GPU-nativ innerhalb des vLLM-Workers laufen, mit sauberer CPU/GPU-Trennung, dynamischem Batch-Padding und eigenständigen Tokenizern. Dieses GPU-native Design macht Single-Card-Serving überhaupt erst praktikabel, weil der vLLM-Speicher-Profiler die Encoder endlich sehen kann.

Darauf aufbauend hat Anunay-Yadav die Apertus 1.5 Unterstützung in das Haupt-vLLM-Repository als Apertus1p5ForConditionalGeneration gebracht, mit korrekter Architekturregistrierung, dem apertus Tool-Parser und dem Reasoning-Parser. Um diesen Kern herum haben individuelle Mitwirkende die Bausteine ergänzt, die den Alltag zuverlässig machen: der ApertusToolParser von blancsw für natives Tool Calling, der Reasoning-Parser von AryanAhadinia, ein Double-BOS-Token-Fix von robmsmt, die ursprüngliche Text-only-vLLM-Integration mit xIELU und QK-Norm von EduardDurech und AllenHaoHuang sowie ein Weight-Loading-Fix für eigene XIELU-Buffer von nathanrchn. Cyrilvallez bei Swiss AI hielt die HuggingFace-Transformers-Integration durchgehend synchron.

Besonderer Dank gilt Oleg Lavrovsky für das Fördern und Koordinieren des Apertus-Community-Ökosystems über GitHub, HuggingFace und die Entwickler-Community. Seine Arbeit, Mitwirkende zu vernetzen, den Upstream-Fortschritt zu verfolgen und frühes Feedback zur Entwicklung des Tool-Parsers zu geben, war entscheidend für diese Zusammenarbeit.

Auch das Quantisierungsrezept ist Community-Tooling. Der llm-compressor von Neural Magic verwandelt den 135 GiB BF16 Checkpoint in das 48 GiB NVFP4 Modell, um das es in diesem Beitrag geht, und wir haben das llmapibenchmark-Tool verwendet, um Durchsatz und Latenz bei realistischer Parallelität zu validieren.

Mehrere dieser Korrekturen wurden direkt in die offizielle v1.5 Version übernommen, sodass Tool Calling und Chat-Template-Verarbeitung für alle funktionieren, die das Modell herunterladen. Open Source funktioniert, wie vorgesehen.

Dank an blancsw und Infomaniak für den GPU-nativen Zweig, an Anunay-Yadav für das Upstream-Bringen und an alle anderen, die mitgeholfen, gedebuggt, reviewed und getestet haben.

Das grosse Ganze: Souveräne KI in Reichweite

Vor einem Jahr bedeutete “ein 70B multimodales Modell ausführen” einen Multi-GPU-Rechenzentrumsknoten. Heute läuft das beste offene Schweizer Modell auf einer einzigen Karte, die Sie in einen Server unter Ihrem Schreibtisch einbauen können: souverän, vom Netzwerk trennbar, mit Vision, Tool Calling und einem 192k-Kontextprofil (229k gemessenes Maximum), bei ungefähr halbierter bewerteter GPU-Leistung gegenüber der Referenz, rund 35% weniger Energie pro generiertem Token als die FP8-Alternative und 99% der FP8-MMLU-Qualität in einem 48 GiB Checkpoint.

Das Gewichtsrezept, die Zahlen und die Korrekturen sind öffentlich. Wenn Sie die offizielle Apertus v1.5 Version herunterladen, funktioniert Tool Calling bereits ohne zusätzliche Anpassungen, teilweise wegen des in diesem Beitrag beschriebenen Roundtrips. Das ist die leise Superkraft offener Modelle: Die Bereitstellungsprobleme aller werden zu den Korrekturen aller.

Dank an Infomaniak / @blancsw für die GPU-native Apertus vLLM Arbeit und an das Apertus-Team für die schnelle Übernahme während des Release-Zyklus.

Anhang

Multistream-Durchsatz-Daten

Gemessen auf einer NVIDIA RTX PRO 6000 Blackwell (96 GB), vLLM, identische Prompts. Jede Parallelitätsstufe sendet 10 Anfragen mit zufälligen 200-Wort-Prompts (~270 Input-Token) und generiert 200 Ausgabe-Token pro Anfrage. Die Generationsgeschwindigkeit ist completion_tokens / wall_time, der Prefill-Durchsatz prompt_tokens / wall_time.