Hardware & gemessene Latenz

Jeder Wert hier nennt die Hardware, auf der er gemessen wurde, und Hochrechnungen sind als solche gekennzeichnet.

Alle Messungen basieren auf demselben Referenzdatensatz aus 50 Fotos mit identischen Prompts. Die vollständige Methodik, Konfidenzintervalle und die Testläufe selbst stehen in eval/BASELINE.md und eval/PERFORMANCE.md.

Profile

Beide lite-Varianten laufen auf der CPU. quality läuft ebenfalls auf der CPU, allerdings sehr langsam, und ist eigentlich ein GPU-Profil.

quality auf einer GPU: gemessen

Beide Zeilen: Qwen3-VL-8B-Instruct Q4_K_M + F16 mmproj, 8192 Kontext, Bilder auf 896 px herunterskaliert, llama.cpp llama-server b10380, gemietete Pods, 50 Fotos. Beide enthält etwa 0,35 bis 0,6 s Netzwerk- und Proxy-Umlaufzeit, die bei einem Container auf deiner eigenen Maschine entfallen. Lokales Serving ist also schneller als diese Zahlen, nicht langsamer. Genauigkeit beim selben Durchlauf: 72.8 % Recall der Kernbestandteile bei null Halluzinationen über die 50 Teller hinweg, statistisch nicht vom Cloud-Frontier-Modell zu unterscheiden, das openplate standardmäßig nutzt.

Jede Karte mit rund 24 GB in dieser Leistungsklasse reicht aus. Das haben wir gemessen; kleinere Karten haben wir nicht getestet.

VRAM-Untergrenze. Die Gewichte betragen 4,68 GiB (Q4_K_M) + 1,08 GiB (F16-Vision-Tower) = 5.8 GiB, und der gemessene Gesamtarbeitsspeicher bei 8192 Kontext mit 2 Slots lag bei 6.3 GB. Eine Eine Karte der 12-GB-Klasse sollte ausreichen und eine 8-GB-Karte sind also denkbar, aber knapp (du würdest wahrscheinlich den Kontext reduzieren oder Teile des Modells auslagern). Das ist reine Arithmetik, kein getesteter Wert: 24 GB ist die einzige Groesse, die wir gemessen haben. Wenn du 12 GB testest und es funktioniert, ist das eine nützliche Information.

Die eigentliche Variable ist die Speicherbandbreite, nicht das VRAM

Die Generierungsgeschwindigkeit bei einer einzelnen Anfrage ist bandbreitenbegrenzt: Jeder Token durchläuft den gesamten aktiven Gewichtssatz. Die beiden gemessenen Karten liegen beide ungefähr bei Klasse um 1.000 GB/s (RTX 4090 ≈ 1008 GB/s, RTX 3090 ≈ 936 GB/s), und ihre gemessenen p50-Werte spiegeln das wider: 0,94 s gegenüber 1,72 s.

Hochrechnung, keine Messung: Eine Klasse um 300 GB/s-Karte (L4 und der inferenzfaehige Teil der meisten Workstation-Karten) hat ungefaehr dreimal weniger Bandbreite als die 3090, was sie bei hochgerechnet 4 bis 6 s pro Scan einordnet. Das ist aus der 3090-Zeile hochgerechnet, nicht gemessen, und reale Zahlen fallen meist schlechter aus als eine lineare Skalierung.

CPU: gemessen

Host fuer jede untenstehende Zeile: AMD Ryzen 9 7940HS, 14 Threads, keine GPU (-ngl 0), llama.cpp llama-server, 8192 Kontext, dieselben 50 Fotos.

lite: die Zeile für deine Planung. Gemessen am 2026-08-13 ueber den ausgeliefert-Dienst: genau dieser Code, seine 896-px-Herunterskalierung, seine Grammatik, sein Output-Mapping, 50/50 Bildern, 0 Fehler, sequentielle Anfragen ueber Loopback.

Quelle: eval/runs/2026-08-13-lite-cpu-v3/results.json. Dieser Durchlauf maß ausschließlich Latenz: Die Genauigkeit wurde nicht bewertet. Der Recall-Wert von lite stammt aus einem andere-Durchlauf (2026-08-12: 62.1 % Core-Item-Recall, weshalb lite als Untergrenze für ressourcenbeschränkte Self-Hoster dokumentiert ist und nicht als Flaggschiff). Zwei Durchläufe, zwei Zahlen, getrennt aufgeführt.

Die Latenz wächst mit dem Teller und mit den Threads. Was ein Scan kostet, richtet sich nach der Länge seines Prompts, den Tokens, die das Modell für dieses Foto liest, und der Prompt war für ein komplettes Frühstück viermal länger als für einen einfachen Teller. Zwei Scans, gemessen über den mitgelieferten Dienst auf demselben CPU-Modell in einer virtuellen Maschine mit 6 vCPUs und den standardmäßigen 4 Threads (2026-09-27):

Plane auf einem normalen CPU-Rechner also etwa 5 Sekunden bis zu einer Minute pro Teller ein: das untere Ende mit vielen Threads und einem einfachen Teller, das obere Ende mit wenigen Threads und einem voll belegten Teller. Das sind zwei Einzelscans, keine Verteilung.

quality auf derselben CPU: ≈94 s / Teller (p50, 2026-08-12), gemessen unter einer früheren, gesprächigeren Pipeline bei voller Bildauflösung und nicht erneut unter der ausgelieferten Pipeline gemessen, betrachte dies daher als Obergrenze. quality ist ein GPU-Profil.

RAM (gemessener RSS): lite 1.55 GB, quality 6.31 GB.

Der CPU-Durchsatz steigt bei Nebenläufigkeit nicht. Gemessen: Zwei gleichzeitige Anfragen kosten das 0,75- bis 0,83-Fache derselben zwei nacheinander ausgeführten Anfragen, ein Durchsatzgewinn von 1,2 bis 1,3× bei 2-fachem Fan-Out, vollständig bezahlt mit Latenz pro Anfrage (eine einzelne Anfrage 2,5 s; zwei parallele Anfragen je 3,7 s). Plane Kapazitäten so, als liefe das System rein seriell.

Minimale CPU-Hardware für lite: Mindestens 8 moderne Kerne mit AVX2, 4 GB freier Arbeitsspeicher (1,55 GB für das Modell, Puffer für alles andere), etwa 3 GB Festplattenspeicher (1,96 GiB an Gewichten plus das Image, etwa 1 GB). 8 Threads statt 14 verdoppeln die Latenz pro Teller ungefähr. Keine GPU, kein CUDA, kein externer Aufruf, verifiziert durch scripts/smoke-lite.sh, das das CPU-Image baut, ohne GPU startet und ein echtes Foto durchleitet.

Standardmäßig keine Latenzobergrenze

LATENCY_CEILING_MS ist standardmäßig 0, also deaktiviert. Ein System, das ab einem bestimmten Schwellenwert Last abwirft, würde Anfragen ablehnen, die es problemlos verarbeiten könnte, und auf einer CPU dauert ein Scan legitimerweise Sekunden bis Minuten. Die passende Benutzererfahrung ist asynchron: Foto machen, Telefon wegstecken, der Teller ist analysiert, sobald du wieder hinsiehst. Was auf der CPU nicht funktioniert, ist eine Live-Vorschau, die sich beim Ausrichten des Motivs neu aufbaut.

Wenn du auf deinem System eine Begrenzung wünschst, setze LATENCY_CEILING_MS=10000, damit der Dienst Aufträge ablehnt, die er nicht innerhalb von zehn Sekunden abschließen kann. Die meisten Self-Hoster sollten den Wert deaktiviert lassen.