1. Ein Gaming-Index, keine synthetische Punktzahl
Jedes Teil erhält einen relativen Gaming-Index. Prozessoren werden am Ryzen 7 9800X3D (= 100) bei 1080p mit einer Grafikkarte gemessen, die sie nicht begrenzt; Grafikkarten an der RTX 5090 (= 100) im nativen Rastern. Der Index stammt aus dem Katalog; fehlt er, greift eine kalibrierte Tabelle und erst als letzte Möglichkeit eine Schätzung aus PassMark-Werten.
Synthetische Punktzahlen werden nicht direkt verwendet, weil sie Teile fürs Spielen falsch ordnen: G3DMark setzt die RTX 5080 über die RTX 4090 und PassMark den Core Ultra 9 285K über den Ryzen 7 9800X3D.
Der Wert von 0 bis 100 auf den Vergleichsseiten ist eine normalisierte Form dieses Index. Er ist eine Position auf der Skala des Modells, kein Marktsegment: Eine Karte deutlich unter dem oberen Ende der Skala kann trotzdem ein High-End-Produkt sein.
2. Zwei Grenzen pro Spiel
Für jedes der 11 profilierten Spiele berechnet das Modell zwei Bildraten: die, die der Prozessor mit einer unbegrenzten Grafikkarte hält, und die, die die Grafikkarte mit einem unbegrenzten Prozessor hält. Die gelieferte Bildrate ist die kleinere der beiden, korrigiert um die Kapazität des Arbeitsspeichers.
CpuLimit = cpuRefFps × (CpuIndex / 100)^cpuIndexExponent × ThreadScaling × MemoryFactorGpuLimit = gpuRefFps × (GpuIndex / 100)^gpuIndexExponent × ResolutionFactor × VramFactorFPS = min(CpuLimit, GpuLimit) × RamCapacityFactorcpuRefFps, gpuRefFps und beide Exponenten werden pro Spiel an veröffentlichten Benchmarks angepasst (Abschnitt 9). ThreadScaling verteilt den Index je nach Kernzahl auf die Spielarten. MemoryFactor erfasst Takt, Generation und Kanalzahl des Speichers und wirkt nur auf die Grenze des Prozessors: In diesem Modell multipliziert ein einzelner Kanal sie mit 0.75, was die gelieferte Bildrate nur dort ändert, wo der Prozessor limitiert.
3. Auflösung, Grafikspeicher und Arbeitsspeicher
PixelRatio = (width × height) / (1920 × 1080)ResolutionFactor = 1 / (fixed + (1 − fixed) × PixelRatio^exponent)Ein Teil der GPU-Zeit eines Frames hängt nicht von der Pixelzahl ab: Befehlsübergabe, Geometrie oder Schattenkarten fester Größe. „fixed“ ist dieser Anteil pro Spiel, der Exponent beschreibt, wie der Rest skaliert. Ohne den festen Anteil würden E-Sport-Titel — an fast allen Messpunkten CPU-limitiert — so flach skalieren, dass eine RTX 5090 bei 8K absurde Bildraten hielte.
Jedes Spiel hat bei 1080p einen Grafikspeicher-Bedarf, der mit den Pixeln wächst. Reicht eine Karte nicht, wird nur das Defizit oberhalb von 1080p berechnet, weil der 1080p-Index bereits enthält, was eine kleine Karte dort verliert.
Arbeitsspeicher unter dem Zielwert eines Spiels kostet einen Auslagerungsabzug: klein zwischen Herstellerminimum und Zielwert, größer unterhalb des Minimums. Kapazität über dem Zielwert bringt nichts, deshalb liefern 32 GB und 64 GB hier dieselben FPS.
Upscaling und Frame Generation sind im Rechner optional. Upscaling senkt das Verhältnis der gerenderten Pixel und hebt nur die Grenze der Grafikkarte; Frame Generation wird über die Kosten jedes erzeugten Frames modelliert und bleibt aus der Ziel-FPS-Analyse ausgeschlossen. Die Vergleichsseiten und die veröffentlichte Genauigkeit nutzen keines von beiden.
4. Urteil, Prozentwert und Kaufempfehlung
Das Urteil vergleicht beide Grenzen über alle Spiele, jedes gewichtet nach seiner Relevanz bei der gewählten Auflösung. Das Modell berechnet, welcher Grafikindex diesen Prozessor ausgleichen würde und welcher Prozessorindex diese Grafikkarte, beide begrenzt auf das, was es zu kaufen gibt.
Der Prozentwert ist der Anteil der Bildrate, den eine realistische Änderung zurückholen würde: eine schnellere Grafikkarte, ein schnellerer Prozessor oder — wenn der Prozessor schon der schnellste erhältliche ist — eine höhere Auflösung, die die freie Kapazität in Bildqualität statt in Bilder steckt. Wenn nichts am Markt hilft, ist er 0%, deshalb gilt ein Spitzen-System bei 4K als ausgewogen, obwohl seine Grafikkarte voll ausgelastet ist.
Unter 15% gilt das Ungleichgewicht als normal. Die Auslastungsbalken zeigen den geschätzten Anteil der eigenen Grenze, den jedes Teil nutzt, keine gemessene Auslastung.
Die Vergleichsseiten nennen nur dann ein Teil zum Kauf, wenn es in derselben Kombination voll ausgelastet wird und mindestens 25% mehr Bilder bringt (Grafikkarte) bzw. 10% (Prozessor). Sonst sagt die Seite, dass kein Teil im Katalog diese Schwelle erreicht — was nicht heißt, dass sich das System nicht verbessern ließe.
5. Spielspezifische Kalibrierungen
Verschiedene Spiel-Engines beanspruchen die Hardware auf völlig unterschiedliche Weise. Unser FPS-Modell integriert Spielkategorien mit eigenen Leistungsprofilen:
- ●AAA-Titel (z. B. Cyberpunk 2077, Alan Wake 2): Hohe Anforderungen an die Grafik-Pipeline. Mit einem idealen Verhältnis programmiert, das hohe GPU-Leistung bevorzugt. Die Rendering-Grenzen reagieren stark auf den VRAM-Durchsatz.
- ●E-Sport/Competitive (z. B. Counter-Strike 2, Valorant): Geringe Grafik-Last, extrem hohe FPS-Ziele. Mit CPU-lastigem Verhältnis programmiert, bei dem Single-Thread-Takt und L3-Cache-Größe die maximal erreichbare Bildrate bestimmen.
- ●Hybrid-Competitive (z. B. Call of Duty: Warzone): Stark CPU-abhängig für Spieler-Tracking und Netzwerk-Updates, aber hohe Anforderungen an Speicherbandbreite und VRAM für riesige Multiplayer-Maps.
Engine-Version 2026.08 · letzte Überarbeitung von Modell und Texten: 2026-09-11 · Hardware-Katalog: 2026-08-19. Kalibriert an veröffentlichten FPS von Testredaktionen.
6. Das Zwei-Grenzen-Modell
Jedes Spiel wird durch zwei unabhaengige Grenzen beschrieben: die FPS, die allein die CPU halten kann, und die FPS, die allein die GPU halten kann. Die tatsaechlichen FPS sind der kleinere der beiden Werte.
Das ist kein Implementierungsdetail, sondern das, was Widersprueche verhindert. Das Bottleneck-Urteil und das FPS-Diagramm pro Spiel stammen aus denselben zwei Zahlen, sodass die Ueberschrift nicht CPU-Bottleneck sagen kann, waehrend das Diagramm ein GPU-limitiertes System zeigt. Viele Rechner der Branche berechnen beides getrennt und behaupten am Ende auf demselben Bildschirm das Gegenteil.
Daraus ergibt sich auch die im Ergebnis gezeigte Auslastung: Die Komponente, die die Bildrate bestimmt, arbeitet zu 100 %, die andere leistet genau den Anteil, den die Pipeline zulaesst. Deshalb erscheint bei 4K mit einer Spitzenkarte die GPU am Limit und die CPU im Leerlauf, waehrend die Kaufempfehlung dennoch nichts aendern lautet: eine schnellere GPU gibt es nicht zu kaufen.
7. Gemessener, nicht behaupteter Fehler
Die Engine wird gegen 69 Konfigurationen mit gemessenen, von Dritten veroeffentlichten FPS geprueft, per 5-facher Kreuzvalidierung: Fuer jede Gruppe wird die Engine nur mit den anderen vier neu kalibriert und sagt dann die ungesehene vorher.
Ergebnis und Grenzen stehen auf der Genauigkeitsseite, samt Aufschlüsselung nach Spiel und Auflösung. Es ist eine interne Validierung und vermutlich zu optimistisch: Die Startwerte jeder Neuanpassung wurden mit allen Referenzen gewonnen, und einen externen, eingefrorenen Satz gibt es noch nicht.
8. Was dieses Modell nicht leistet
- ●Vergleichsseiten und Genauigkeitswert gelten für native Auflösung. Upscaling (DLSS, FSR, XeSS) und Frame Generation sind im Rechner modellierte Optionen, ihr Fehler ist aber nicht validiert.
- ●Kein Raytracing. Es zu aktivieren verschiebt die Lastverteilung und kann das Urteil in manchen Titeln umkehren.
- ●Es schaetzt Mittelwerte, keine 1%-Lows. Ruckler haengen von Faktoren ab, die ein statisches Modell nicht erfasst.
- ●Keine Notebooks. Dieselbe GPU variiert je nach freigegebener Leistung um rund 30 %.
- ●Kuehlung, Mainboard-Qualitaet und eigene Power-Limits werden nicht modelliert.
- ●Die 11 Profilspiele sind eine Stichprobe, nicht der Steam-Katalog. Eine untypische Engine kann staerker abweichen.
Diese Grenzen werden veroeffentlicht, weil eine Schaetzung ohne erklaerten Geltungsbereich nicht ueberpruefbar ist, und ein nicht ueberpruefbares Werkzeug kein Vertrauen verdient.
9. Reproduzierbarkeit
Gemeinsame Koeffizienten und Spielwerte werden mit einem deterministischen Verfahren gegen die gemessenen Referenzen angepasst und anschliessend von Hand in den Code uebernommen. Dieser manuelle Schritt ist Absicht: Er erzwingt, dass jede Zahl im Verlauf ueberpruefbar bleibt, statt automatisch zu entstehen.
Die Anpassung ist zu physikalisch begruendeten Werten hin regularisiert, sodass ein von den Referenzen schwach identifizierter Parameter dort bleibt, wo die Physik ihn verortet, und sich nur bewegt, wenn die Daten es verlangen. Ohne das faende die Anpassung Werte, die die Referenzen um einen Zehntelpunkt verbessern und sonst schlecht generalisieren.