3.8 KiB
Medium-Leistungsvergleich, 28.09.2026
Synthetische Textanfragen direkt an llama-server, je eine Aufwärmrunde plus drei Messungen: 87 Eingabe-Token, 256 Ausgabe-Token, Seed 1234, Temperature 1, Top-p 0,95, Top-k 20, Prompt-Cache aus. Keine Benutzerinhalte gelesen oder gespeichert.
| Aufbau | Ausgabe Token/s (Mittel) |
|---|---|
| Alter Medium-Container | 64,44 |
| Deck bisher, GPU-Limit 65 | 38,38 |
| Deck volle GPU, CPU-Budget 2 | 64,99 |
| Deck volle GPU, CPU-Budget 6 | 65,06 |
| Deck volle GPU, zurück auf CPU-Budget 2 | 65,03 |
Deck-Varianten mit identischem Build, gespeichertem Medium-Profil (160000 Kontext, 1 Slot, MTP2 / p-min 0,05, Split85:15) und identischen Requests. Änderung nur Speicherreserve/Offloading und danach CPU-Budget. Bei voller GPU-Ausführung keine CPU-Drosselereignisse während der Messungen. Der erste Versuch mit docker update --cpus 0 war kein verlässlicher Nachweis eines aufgehobenen Limits (weiterhin Drosselereignisse) und wird nicht als Vergleich verwendet. Der zweite Vergleich prüfte cpu.max ausdrücklich: 200000/100000 und 600000/100000.
Ursache: Die frühere Reserve max(1024 MiB, 5 Prozent) verhinderte volle GPU-Belegung knapp und reduzierte das Limit auf 65. Die Modellmetadaten enthalten 65 Blöcke einschließlich eines MTP-Blocks. Der geprüfte llama-model.cpp-Code legt bei begrenztem Offloading frühe Modellblöcke auf die CPU; die Ausgabeschicht liegt am Ende der GPU-Auswahl. Die erste Vermutung einer CPU-Ausgabeschicht war daher falsch. Mit max(512 MiB, 2,5 Prozent) besteht die Prognose einschließlich MTP-Kontext und alle Schichten passen. Das RAM-Limit und die übrigen Startparameter bleiben unverändert.
Kurzer Einzelnutzer-Test, keine Aussage zur Stabilität bei maximal gefülltem Kontext oder paralleler Last. Alter Router: 2 Slots, Vision-Projektor, anderer Build; kein ansonsten identischer Vergleich. Ursachennachweis daher durch die kontrollierten Deck-Varianten. Nach Abschluss: alter Medium-Container gestoppt, Deck läuft mit bisherigem Zwei-Kern-Limit, Testmodell entladen.
Prefill-Detailprüfung am 28.09.2026
Direkt am nativen /completion: synthetischer tokenisierter Text, exakt 512/4096/16384 Eingabe-Tokens, 32 Ausgabe-Tokens, Temperature 0, Seed 1234, cache_prompt=false. Je eine Aufwärmrunde und zwei Messungen pro Länge; alle Messungen cache_n=0. Keine Nutzerinhalte.
| Eingabe | Alter Router, 2 Slots | Deck, 1 Slot | Deck, 2 Slots mit Auto-Offload |
|---|---|---|---|
| 512 | 1076,5 | 1004,6 | 1081,7 |
| 4096 | 1928,2 | 1892,6 | 1350,6 |
| 16384 | 1947,7 | 1928,4 | 1294,0 |
Einheit: mittlere Prefill-Token/s. Deck 1 Slot vs. Alt: bei 4096 rund 1,8 %, bei 16384 rund 1 % weniger Durchsatz. Der große relative Unterschied der früheren 87-Token-Messung skaliert nicht mit der Eingabelänge. Durchschnittliche Zeitdifferenzen hier circa 34/40/84 ms. Ursache der kleinen Restdifferenz nicht isoliert bewiesen; Builds und Slotzahl unterscheiden sich weiterhin.
Wichtiger Störfaktor im kontrollierten Slotversuch: Decks Speicherprognose mit 2 Slots wählte GPU-Layerlimit 65 statt 999. Damit ist diese Variante kein reiner Slotvergleich; zusätzliche CPU-Auslagerung erklärt einen konkreten anderen Ausführungspfad. Gespeichertes Benutzerprofil bleibt bei 1 Slot unverändert. Deck CPU-Budget 2, Threads 6; während erster Messungen und Beginn des zweiten Versuchs nr_throttled=0. CUDA-Architekturen 120;86, Release, GGML_NATIVE=OFF, Flash Attention ON. Aktive Binärdatei 0.5.0-dev, Commit c2a9e16 (registrierter Build b11229).
Offizieller Versionsstand zur Abfrage: regulär v0.5.0 vom 23.09., Nightly b11236 vom 28.09. Die bisherige GUI akzeptierte keine v-Tags und fragte nur zehn jüngste Releases ab. Korrigiert: reguläres Latest explizit zuerst, v-Tags zulässig, Build_IS_DEV passend setzen. Keine neue llama.cpp-Version gebaut oder aktiviert.