Wie die Schätzungen entstehen

Diese Seite wurde automatisch von einer KI geschrieben und übersetzt und von Software anhand ihrer Quellen geprüft, ohne menschliche Bearbeitung. Die Spezifikationen stammen aus den angegebenen Quellen; Speicherbedarf und Geschwindigkeiten sind Schätzungen, die mit veröffentlichten Formeln berechnet wurden. Wie wir KI nutzen

Jede Zahl auf dieser Website ist entweder eine Spezifikation, in der zwei unabhängige offene Quellen übereinstimmen, oder das Ergebnis des unten beschriebenen deterministischen Codes. Derselbe Code läuft beim Erstellen der Seiten und in Ihrem Browser.

Werte aktualisiert am 19. Okt. 2026

Was modelliert wird

Modelliert wird: llama.cpp lädt eine GGUF-Datei, nur Text, alle Schichten auf der GPU, Flash Attention aktiviert, Micro-Batch 512, ein Nutzer. Bei mehreren Karten: identische Karten in einem Rechner mit der Standard-Schichtaufteilung von llama.cpp. Multimodale Modelle werden ohne ihren Vision-Projektor und ohne Bildverarbeitung berechnet.

Ollama und LM Studio verwenden llama.cpp, können aber andere Standardwerte nutzen. vLLM, MLX und Transformers belegen Speicher anders und werden nicht modelliert. Ein Ergebnis „Passt“ bedeutet nicht, dass ein bestimmter Treiber oder Back-End die Architektur oder Quantisierung des Modells unterstützt.

Formel, Term für Term

Für jede Karte d ist die Schätzung Q_d dieselbe Größe, die llama.cpp pro Gerät als Modell- + KV- + RS- + Compute-Puffer ausgibt. Die Schichten werden mit der Standardaufteilung von llama.cpp auf die Karten verteilt; das Eingabe-Embedding bleibt im Systemspeicher.

Q_d = W_d + KV_d + S_d + C_d
W_d = Σ_{il ∈ d} layer_bytes[il] + [d = N] × out_bytes
KV_d = Σ_{il ∈ d} (k_il + v_il) × b_kv × cells_il;   b_kv: F16 = 2, Q8_0 = 34/32, Q4_0 = 18/32
cells_full = ⌈ctx / 256⌉ × 256
cells_window = ⌈min(ctx, window × n_seq + 512) / 256⌉ × 256
S_d = Σ_{il ∈ d} state_il × 4 B × n_seq
M = (cells_full + cells_window) × 512 × 4 B
L = max(0,25 GiB, n_vocab × 512 × 4 B)
P = M + n_embd × 512 × 4 B
C_d = L + M                        (N = 1)
C_d = L + 3 × P                    (N > 1, d = N)
C_d = 0,25 GiB + 4 × P             (N > 1, d < N)

X = max_d (Q⁺_d ÷ 0,95 + 1 GiB)
Passt: ∀ d: Q⁺_d ÷ 0,95 + 1 GiB ≤ C_low
Passt nicht: Q⁻ ÷ 1,10 > C_high (N = 1);   Σ_d Q⁻_d ÷ 1,10 > N × C_high (N > 1)
Grenzwertig: sonst
C_low = G − D_card − U;   C_high = G
tok/s ≤ B ÷ (R + R_KV)

W_d

Gewichte auf Karte d: die Bytes der darauf platzierten Schichten, gelesen aus der GGUF-Tensortabelle, plus die Ausgabeschicht auf der letzten Karte.

KV_d

KV-Cache auf Karte d: K- und V-Elemente pro Token jeder Attention-Schicht auf der Karte, mal Bytes pro Element, mal Anzahl der zwischengespeicherten Zellen. Multi-head Latent Attention speichert nur K.

S_d

Rekurrenter Zustand: Zustand fester Größe von rekurrenten Schichten und Linear-Attention-Schichten (32 Bit), einer pro paralleler Sequenz.

C_d, L, M, P

Compute-Puffer: L ist der Logits-Puffer, M die Attention-Maske, P die Eingaben pro Kopie, die Pipeline-Parallelität bei mehreren Karten auf jeder Karte hält.

Q⁺

Q⁺: die Schätzung pro Karte, die für „Passt“ verwendet wird – 4 parallele Sequenzen (Standard von llama-server, -np auto), Schichten genau an einer Kartengrenze werden auf beiden Karten gezählt.

Q⁻

Q⁻: die Schätzung, die für „Passt nicht“ verwendet wird – 1 Sequenz, jede Schicht einmal gezählt, so wie der Quellcode sie zuweist.

X

X: der verfügbare Speicher pro Karte, der für „Passt“ benötigt wird. Die Seiten zeigen ihn als „Benötigter verfügbarer Speicher für Passt“ an.

G, N

G: der Nennspeicher einer Karte (die „24 GB“ des Herstellers werden als 24 GiB gerechnet); N: die Anzahl identischer Karten.

C_low

C_low: als verfügbar für „Passt“ gezählter Speicher — nomineller Speicher abzüglich der Differenz der Karte zwischen nominal und gemeldet (D_card) und der größten Start- und Laufzeitbelegung in den öffentlichen Logs des Profils (U), abgerundet auf ein Vielfaches von 64 MiB.

C_high

C_high: der gesamte Nennspeicher, verwendet für „Passt nicht“.

B, R, R_KV

B: Speicherbandbreite (Bytes pro Sekunde); R: pro erzeugtem Token gelesene Gewichts-Bytes (Nicht-Experten-Tensoren plus der Anteil der verwendeten Experten); R_KV: pro Token gelesene Bytes des KV-Cache.

Konstanten

Die Gewichte werden nicht aus Parameteranzahlen geschätzt: Die GGUF-Dateien jeder Quantisierung werden bei einer festgelegten Revision gelesen (Header und Tensor-Tabelle), und die Bytes jeder Schicht werden summiert. Tensoren, die llama.cpp im Systemspeicher hält (Eingabe-Embeddings), bleiben unberücksichtigt.

Passt, grenzwertig oder passt nicht

„Passt“ bedeutet nur Folgendes: Die standardmäßige --fit-Ladeprüfung von llama.cpp würde alle Layer auf die GPU legen. llama.cpp führt diese Prüfung beim Laden eines Modells durch (geschätzte Puffer plus eine Reserve von 1 GiB pro Karte dürfen den beim Start freien Speicher nicht überschreiten); diese Website berechnet sie mit denselben Pufferregeln neu und lässt Spielraum für Schätzfehler. Sie verspricht nicht, dass der Spitzenspeicher während der Inferenz (Speicherpools, lange Prompts und andere Laufzeitallokationen) hineinpasst.

Die Gold-Standard-Tests erlauben, dass die Schätzung bis zu 5% zu niedrig und bis zu 10% zu hoch ist; daher verwendet jede Seite der Entscheidung ihre eigene Grenze:

• Passt wenn auf jeder Karte Q⁺ ÷ 0,95 + 1 GiB höchstens C_low beträgt. Q⁺ geht von 4 parallelen Sequenzen aus.
• Passt nicht wenn Q⁻ ÷ 1,10 größer ist als der gesamte Speicher C_high (bei mehreren Karten: die Summe über alle Karten gegenüber N × C_high, weil das Standard-Verhalten von --fit die Aufteilung selbst anpasst).
• Grenzwertig dazwischen: Es kann passen oder nicht. Verkürzen Sie die Kontextlänge oder verwenden Sie eine niedrigere Quantisierung.
• Unbekannt wenn kein Laufprofil das Gerät abdeckt, bei Workstation- und Rechenzentrums-GPUs (ihre Speicherkonfiguration ist durch öffentliche Logs nicht belegt) oder wenn der als verfügbar gezählte Speicher unter 2 GiB liegt: Es wird nur X angezeigt, außerdem „Passt nicht“, wenn das Modell selbst für den gesamten Speicher zu groß ist.

X = das größte Q⁺ pro Karte ÷ 0,95 + 1 GiB ist der verfügbare Speicher, der für „Passt“ nötig ist. Die Seiten schreiben „Für Passt benötigter verfügbarer Speicher“ und nicht „mindestens“, weil ein grenzwertiges Ergebnis dieselbe Menge benötigt.

Tabellen prüfen die Quantisierungen von der höchsten zur niedrigsten bei der Standard-Kontextlänge. Eine Zeile zeigt entweder die höchste Quantisierung, die passt (mit X, der längsten Kontextlänge und der Obergrenze der Geschwindigkeit), oder – wenn keine passt – die höchste grenzwertige (mit X), oder – wenn alle zu groß sind – die niedrigste Quantisierung mit ihrem X.

Die längste Kontextlänge wird zwischen der Standard-Kontextlänge und dem Kleineren aus dem Maximum des Modells und der längsten durch gemessene Logs abgedeckten Kontextlänge gesucht (262.144 Zellen auf einer Karte, 131.072 auf mehreren). Wenn es dort immer noch passt, zeigen die Seiten „≥“ diesen Wert: Längere Kontextlängen wurden nicht geprüft.

Mehrere identische Karten werden nur berücksichtigt, wenn eine Karte nicht ausreicht, nur für Desktop-, Workstation- und Rechenzentrums-GPUs mit Laufprofil, und jede Anzahl von 2 bis 8 wird einzeln geprüft (eine zusätzliche Karte senkt die Last der am stärksten belasteten Karte nicht immer, und Pipeline-Parallelität fügt 4 Kopien der Layer-Eingaben hinzu). Die Seite nennt die kleinste Anzahl, die bei der standardmäßigen gleichmäßigen Aufteilung passt; sie ist kein Minimum, weil das Standard-Verhalten von --fit die Aufteilung anpassen kann und eventuell mit weniger Karten auskommt. Für Workstation- und Rechenzentrums-GPUs sowie für GPUs mit weniger als 2 GiB als verfügbar gezähltem Speicher gibt es nur „Passt auch auf 8 Karten nicht“ (oder keine Anzahl).

Laufprofile

Wie viel Speicher als verfügbar zählt, stammt ausschließlich aus öffentlichen llama.cpp-Logs: dem von jedem Gerät gemeldeten Gesamtspeicher, dem freien Speicher bei der --fit-Prüfung von llama.cpp und, sofern ausgegeben, dem nach einem Lauf nicht zugeordneten Speicher. D_card = Nennspeicher − gemeldeter Gesamtspeicher dieses GPU-Modells (der größte Wert, falls mehrere Logs vorliegen); U = der größte Wert aus Gesamt − frei bei der --fit-Prüfung und positivem nicht zugeordnetem Speicher nach einem Lauf, über alle gültigen Beobachtungen des Profils. Enthält ein Log nur eine Messung aus der Geräteliste, wird die größte im Profil beobachtete Differenz zwischen Geräteliste und Prüfung addiert. Beobachtungen werden ausgeschlossen, wenn ein Display angeschlossen ist, andere Programme die GPU bereits belegt haben, der freie Speicher den Gesamtspeicher übersteigt oder ein gemeinsam genutzter Server fremde Belegung hinzufügt. Ein Profil ohne genügend Beobachtungen liefert keine Bewertungen.

Consumer-GPUs ohne eigene Messung verwenden in der Standardkonfiguration die größte Differenz zwischen Nennspeicher und gemeldetem Gesamtspeicher, die bei Consumer- und Workstation-Karten gemessen wurde. Workstation- und Rechenzentrums-GPUs erhalten, gemessen oder nicht, weder „Passt“ noch „Grenzwertig“, weil öffentliche Logs ihre Speicherkonfiguration nicht zeigen (zum Beispiel ob ECC aktiv ist): Sie sind „Unbekannt“, außer das Modell ist selbst für den gesamten Speicher zu groß, und bei mehreren Karten wird nur „Passt auch auf 8 Karten nicht“ angegeben. Laptop-GPUs, Apple Silicon und andere Computer mit Unified Memory (gemeinsamer Speicher) haben in dieser Version kein Profil.

CUDA (NVIDIA)

llama.cpp, CUDA-Backend (dedizierte NVIDIA-GPU), alle Layer auf der GPU, Flash Attention an, Micro-Batch (-ub) 512, F16-KV-cache, Kontextlänge (-c) wie angezeigt; „Passt“ wird mit den 4 parallelen Sequenzen beurteilt, die llama-server standardmäßig nutzt (-np auto, einheitlicher KV-Cache), „Passt nicht“ mit 1 Sequenz; unbelastete GPU, ohne andere Programme, die ihren Speicher nutzen.

U = 2.112 MiB; D für Desktop-GPUs ohne eigene Messung = 1.054 MiB.

Nicht zugeordneter Speicher nach einem Lauf in diesen Logs: 236–2.050 MiB (4 Beobachtungen). Laufzeitallokationen sind nicht Teil von „passt“; U berücksichtigt sie nur als zusätzlichen Spielraum, nicht als Obergrenze.

D_card: Nennspeicher minus der von llama.cpp für dieses GPU-Modell gemeldeten Gesamtmenge (MiB).

GPU	D_card (MiB)
NVIDIA GeForce RTX 3060 12GB	251
NVIDIA GeForce RTX 3090	453
NVIDIA GeForce RTX 4060 Ti 16GB	5
NVIDIA GeForce RTX 4090	496
NVIDIA GeForce RTX 5060	484
NVIDIA GeForce RTX 5090	659
NVIDIA L4	2.098
NVIDIA RTX A4000	410
NVIDIA RTX PRO 6000 Blackwell Workstation Edition	1.054

Beobachtungen aus öffentlichen llama.cpp-Logs, mit den zitierten Logzeilen.

Gerät	Backend	Build	Nennwert	Gemeldete Gesamtmenge (MiB)	Frei beim Start (MiB)	Belegt vor dem Laden (MiB)	Nicht zugeordnet nach dem Lauf (MiB)	Quelle
NVIDIA GeForce RTX 3090 (x2, CUDA0)	CUDA	b11415	24 GB	24.575	23.054	1.522	—	llama.cpp issues/29811 Logzeilen 0.00.573.399 I common_memory_breakdown_print: | - CUDA0 (RTX 3090) | 24575 = 23054 + (21234 = 17721 + 2964 + 549) + -19713 | 0.00.573.400 I common_memory_breakdown_print: | - CUDA1 (RTX 3090) | 24575 = 23206 + (20693 = 18689 + 1453 + 549) + -19323 | 0.00.969.460 I common_params_fit_impl: - CUDA0 (NVIDIA GeForce RTX 3090): 24575 total, 21234 used, 1819 free vs. target of 1024
NVIDIA GeForce RTX 4090	CUDA	b10567 (d7fa69b7d)	24 GB	24.563	23.040	1.575	—	llama.cpp issues/27680 Logzeilen common_param: - CUDA0 : NVIDIA GeForce RTX 4090 (24563 MiB, 23040 MiB free) llama_prepare_model_devices: using device CUDA0 (NVIDIA GeForce RTX 4090) (0000:08:00.0) - 23040 MiB free load_tensors: offloaded 44/44 layers to GPU
NVIDIA GeForce RTX 4090 (x2, CUDA0)	CUDA	9293 (1acee6bf8)	24 GB	24.080	23.672	460	—	llama.cpp issues/23679 Logzeilen 0.00.205.036 I - CUDA0 : NVIDIA GeForce RTX 4090 (24080 MiB, 23672 MiB free) 0.00.283.679 I - CUDA1 : NVIDIA GeForce RTX 4090 (24080 MiB, 23672 MiB free) 0.00.691.813 I llama_prepare_model_devices: using device CUDA0 (NVIDIA GeForce RTX 4090) (0000:01:00.0) - 23672 MiB free
NVIDIA GeForce RTX 3090 (x8)	CUDA	build 1 (0f7fada) ≈ b9557	24 GB	24.123	23.858	317	—	llama.cpp issues/24608 Logzeilen 0.01.258.121 I - CUDA0 : NVIDIA GeForce RTX 3090 (24123 MiB, 23858 MiB free)
NVIDIA GeForce RTX 3090	CUDA	9274 (52fb93a)	24 GB	24.126	23.403	775	—	llama.cpp issues/23472 Logzeilen 0.00.797.657 I common_memory_breakdown_print: | - CUDA0 (RTX 3090) | 24126 = 23403 + (25610 = 15621 +
NVIDIA GeForce RTX 3060	CUDA	b7342	12 GB	12.037	—	270	270	llama.cpp issues/17931 Logzeilen llama_memory_breakdown_print: | - CUDA0 (RTX 3060) | 12037 = 4510 + ( 7256 = 1224 + 4662 + 1369) + 270 |
NVIDIA GeForce RTX 4090	CUDA	7474 (f9ec8858e)	24 GB	24.082	23.687	447	—	llama.cpp issues/18181 Logzeilen llama_params_fit_impl: - CUDA0 (NVIDIA GeForce RTX 4090) : 24082 total, llama_model_load_from_file_impl: using device CUDA0 (NVIDIA GeForce RTX 4090) (0000:82:00.0) - 23687 MiB free
NVIDIA GeForce RTX 5090	CUDA	8241 (62b8143ad)	32 GB	32.606	30.927	2.050	2.050	llama.cpp issues/20308 Logzeilen 0.18.828.015 I llama_model_load_from_file_impl: using device CUDA0 (NVIDIA GeForce RTX 5090) (0000:08:00.0) - 30927 MiB free 0.03.911.366 I llama_params_fit_impl: - CUDA0 (NVIDIA GeForce RTX 5090): 32606 total, 0.22.996.049 I load_tensors: offloaded 61/61 layers to GPU
NVIDIA GeForce RTX 4090	CUDA	8241 (62b8143ad)	24 GB	24.563	22.988	1.910	1.910	llama.cpp issues/20308 Logzeilen 0.18.828.027 I llama_model_load_from_file_impl: using device CUDA1 (NVIDIA GeForce RTX 4090) (0000:01:00.0) - 22988 MiB free 0.03.911.366 I llama_params_fit_impl: - CUDA1 (NVIDIA GeForce RTX 4090): 24563 total,
NVIDIA GeForce RTX 5090	CUDA	9692 (f3e182816)	32 GB	32.109	31.585	576	—	llama.cpp issues/24758 Logzeilen 0.01.070.150 I - CUDA0 : NVIDIA GeForce RTX 5090 (32109 MiB, 31585 MiB free) llama_prepare_model_devices: using device CUDA0 (NVIDIA GeForce RTX 5090) (0000:01:00.0) - 31583 MiB free
NVIDIA GeForce RTX 5060	CUDA	build 1 (fae3a28)	8 GB	7.708	7.573	187	—	llama.cpp issues/21984 Logzeilen CUDA0: NVIDIA GeForce RTX 5060 (7708 MiB, 7573 MiB free) Device 0: NVIDIA GeForce RTX 5060, compute capability 12.0, VMM: yes, VRAM: 7708 MiB | 0 N/A N/A 1448 G /usr/lib/xorg/Xorg 4MiB |
NVIDIA GeForce RTX 4060 Ti	CUDA	0.3.0-dev build 10672 (511f9c1)	16 GB	16.379	15.233	1.198	—	llama.cpp issues/27892 Logzeilen 0.00.590.294 I cmn common_param: - CUDA0 : NVIDIA GeForce RTX 4060 Ti (16379 MiB, 15233 MiB free) 0.01.250.688 I llama_prepare_model_devices: using device CUDA0 (NVIDIA GeForce RTX 4060 Ti) (0000:01:00.0) - 15233 MiB free 0.01.820.045 I load_tensors: offloaded 35/35 layers to GPU
NVIDIA GeForce RTX 3080 (20 GB variant)	CUDA	build 1 (234a6eb) ≈ B10733	20 GB	20.479	19.271	1.260	—	llama.cpp issues/28167 Logzeilen 0.00.239.888 I cmn common_param: - CUDA0 : NVIDIA GeForce RTX 3080 (20479 MiB, 19271 MiB free) using device CUDA0 (NVIDIA GeForce RTX 3080) (0000:09:00.0) - 19271 MiB free 0.01.318.328 I load_tensors: offloaded 37/37 layers to GPU
NVIDIA RTX PRO 6000 Blackwell Workstation Edition	CUDA	7474 (f9ec8858e)	96 GB	97.250	96.688	614	—	llama.cpp issues/18181 Logzeilen llama_params_fit_impl: - CUDA3 (NVIDIA RTX PRO 6000 Blackwell Workstation Edition): 97250 total, llama_model_load_from_file_impl: using device CUDA3 (NVIDIA RTX PRO 6000 Blackwell Workstation Edition) (0000:01:00.0) - 96688 MiB free
NVIDIA RTX A4000	CUDA	9890 (74976e1)	16 GB	15.974	15.791	235	—	llama.cpp issues/25594 Logzeilen 0.00.322.214 I cmn common_param: - CUDA0 : NVIDIA RTX A4000 (15974 MiB, 15791 MiB free) 0.01.255.214 I llama_prepare_model_devices: using device CUDA0 (NVIDIA RTX A4000) (0000:02:00.0) - 15791 MiB free
NVIDIA A100-SXM4-40GB	CUDA	8387 (45172df)	40 GB	40.444	39.968	528	—	llama.cpp issues/20761 Logzeilen ggml_cuda_init: found 1 CUDA devices (Total VRAM: 40444 MiB): Device 0: NVIDIA A100-SXM4-40GB, compute capability 8.0, VMM: yes, VRAM: 40444 MiB llama_model_load_from_file_impl: using device CUDA0 (NVIDIA A100-SXM4-40GB) (0000:41:00.0) - 39968 MiB free
NVIDIA L4	CUDA	b9036-b863d41c7	24 GB	22.478	22.286	244	236	llama.cpp pull/22546 Logzeilen Device 0: NVIDIA L4, compute capability 8.9, VMM: yes, VRAM: 22478 MiB llama_prepare_model_devices: using device CUDA0 (NVIDIA L4) (0000:00:03.0) - 22286 MiB free common_memory_breakdown_print: | - CUDA0 (L4) | 22478 = 22234 + (17095 = 8045 + 8242 + 808) + -16851 |

Vulkan (Intel)

llama.cpp, Vulkan-Backend (dedizierte Intel-GPU), alle Layer auf der GPU, Flash Attention an, Micro-Batch (-ub) 512, F16-KV-cache, Kontextlänge (-c) wie angezeigt; „Passt“ wird mit 4 parallelen Sequenzen beurteilt, „Passt nicht“ mit 1 Sequenz; unbelastete GPU. Es gibt noch nicht genug öffentliche Messungen, daher stützt sich kein Ergebnis auf dieses Profil.

U = 832 MiB; D für Desktop-GPUs ohne eigene Messung = 0 MiB.

D_card: Nennspeicher minus der von llama.cpp für dieses GPU-Modell gemeldeten Gesamtmenge (MiB).

GPU	D_card (MiB)
Intel Arc Pro B70	138

Beobachtungen aus öffentlichen llama.cpp-Logs, mit den zitierten Logzeilen.

Gerät	Backend	Build	Nennwert	Gemeldete Gesamtmenge (MiB)	Frei beim Start (MiB)	Belegt vor dem Laden (MiB)	Nicht zugeordnet nach dem Lauf (MiB)	Quelle
Intel Arc Pro B70	Vulkan	build_info: b8871-7fc1c4ef7	32 GB	32.630	31.861	769	—	llama.cpp issues/22275 Logzeilen 0.01.712.235 I llama_model_load_from_file_impl: using device Vulkan0 (Intel(R) Arc(TM) Pro B70 Graphics) (unknown id) - 31861 MiB free 0.10.080.962 I load_tensors: offloaded 31/31 layers to GPU

ROCm unter Linux (AMD)

llama.cpp, ROCm-Backend unter Linux (dedizierte AMD-GPU), alle Layer auf der GPU, Flash Attention an, Micro-Batch (-ub) 512, F16-KV-cache, Kontextlänge (-c) wie angezeigt; „Passt“ wird mit den 4 parallelen Sequenzen beurteilt, die llama-server standardmäßig nutzt (-np auto, einheitlicher KV-Cache), „Passt nicht“ mit 1 Sequenz; unbelastete GPU, ohne andere Programme, die ihren Speicher nutzen.

U = 1.216 MiB; D für Desktop-GPUs ohne eigene Messung = 144 MiB.

Nicht zugeordneter Speicher nach einem Lauf in diesem Log: 279 MiB (1 Beobachtung). Laufzeitallokationen sind nicht Teil von „passt“; U berücksichtigt sie nur als zusätzlichen Spielraum, nicht als Obergrenze.

D_card: Nennspeicher minus der von llama.cpp für dieses GPU-Modell gemeldeten Gesamtmenge (MiB).

GPU	D_card (MiB)
AMD Radeon Instinct MI50 (32GB)	16
AMD Radeon AI PRO R9700	144
AMD Radeon RX 6800	16
AMD Radeon RX 6900 XT	16
AMD Radeon RX 7800 XT	16
AMD Radeon RX 7900 XTX	16

Beobachtungen aus öffentlichen llama.cpp-Logs, mit den zitierten Logzeilen.

Gerät	Backend	Build	Nennwert	Gemeldete Gesamtmenge (MiB)	Frei beim Start (MiB)	Belegt vor dem Laden (MiB)	Nicht zugeordnet nach dem Lauf (MiB)	Quelle
AMD Radeon RX 7900 XTX	ROCm	version: 9744 (063d9c1)	24 GB	24.560	24.494	266	—	llama.cpp issues/24858 Logzeilen [44157] 0.00.063.214 I - ROCm0 : Radeon RX 7900 XTX (24560 MiB, 24494 MiB free) [44157] 0.00.668.217 I llama_prepare_model_devices: using device ROCm0 (Radeon RX 7900 XTX) (0000:0a:00.0) - 24346 MiB free [44157] 0.02.978.818 I load_tensors: offloaded 33/33 layers to GPU
AMD Radeon RX 7800 XT (x2, ROCm0)	ROCm	version: b8929-9d34231bb	16 GB	16.368	16.036	467	—	llama.cpp issues/22351 Logzeilen Device 0: AMD Radeon RX 7800 XT, gfx1101 (0x1101), VMM: no, Wave Size: 32, VRAM: 16368 MiB llama_model_load_from_file_impl: using device ROCm0 (AMD Radeon RX 7800 XT) (0000:01:00.0) - 16036 MiB free common_params_fit_impl: - ROCm0 (AMD Radeon RX 7800 XT): 16368 total, 10610 used, 5291 free vs. target of 1024
AMD Radeon RX 7900 XTX	ROCm	version: 9307 (549b9d8)	24 GB	24.560	24.510	1.135	—	llama.cpp issues/23934 Logzeilen 0.00.042.225 I - ROCm0 : AMD Radeon RX 7900 XTX (24560 MiB, 24510 MiB free) OS: Ubuntu 22.04.5 LTS Kernel: 6.8.0-117-generic
AMD Radeon RX 7900 XTX (x4)	ROCm	unknown	24 GB	24.560	24.510	1.135	—	llama.cpp issues/27021 Logzeilen - ROCm0 : Radeon RX 7900 XTX (24560 MiB, 24510 MiB free) - ROCm1 : Radeon RX 7900 XTX (24560 MiB, 24518 MiB free) - ROCm2 : Radeon RX 7900 XTX (24560 MiB, 24518 MiB free)
AMD Radeon AI PRO R9700 (x8)	ROCm	build 43 (5854625)	32 GB	32.624	32.534	1.175	—	llama.cpp issues/26208 Logzeilen 0.00.089.438 I cmn common_param: - ROCm0 : AMD Radeon AI PRO R9700 (32624 MiB, 32534 MiB free) 0.08.861.240 I load_tensors: offloaded 66/66 layers to GPU Host is a Debian 13 install with backports set to priority 500.
AMD Radeon AI PRO R9700	ROCm	build 10616 (45bfc6f91)	32 GB	32.624	32.538	1.171	—	llama.cpp issues/26208 Logzeilen [44399] 0.00.093.902 I cmn common_param: - ROCm0 : AMD Radeon Graphics (32624 MiB, 32538 MiB free) [44399] 0.00.093.904 I cmn common_param: - ROCm1 : AMD Radeon Graphics (32624 MiB, 32558 MiB free) [44399] 0.00.562.846 I common_memory_breakdown_print: | - ROCm0 (Graphics) | 32624 = 31454 + (18994 = 7216 + 9095 + 2682) + -17824 |
AMD Instinct MI50 32GB	ROCm	build 9943 (c15c5c77a)	32 GB	32.752	32.722	1.115	—	llama.cpp issues/25487 Logzeilen 0.00.046.167 I cmn common_param: - ROCm0 : AMD Instinct MI60 / MI50 (32752 MiB, 32722 MiB free) llama_prepare_model_devices: using device ROCm0 (AMD Instinct MI60 / MI50) (0000:43:00.0) - 32570 MiB free 0.13.494.533 I load_tensors: offloaded 49/52 layers to GPU
AMD Radeon RX 6800	ROCm	version: 746 (da296d6)	16 GB	16.368	—	660	—	llama.cpp issues/26038 Logzeilen | - ROCm0 (RX 6800) | 16368 = 15708 + (13826 = 13244 + 544 + 37) + -13166 | | - ROCm0 (RX 6800) | 16368 = 16010 + (13527 = 13244 + 245 + 37) + -13169 | GPU: AMD Radeon RX 6800
AMD Radeon Pro VII (x3)	ROCm	build: aa374175c (6969)	16 GB	16.368	—	279	279	llama.cpp issues/17058 Logzeilen llama_memory_breakdown_print: | memory breakdown [MiB] | total free self model context compute unaccounted | llama_memory_breakdown_print: | - ROCm0 ((TM) Pro VII) | 16368 = 10268 + (5820 = 5613 + 56 + 150) + 279 | llama_memory_breakdown_print: | - ROCm1 ((TM) Pro VII) | 16368 = 10250 + (5852 = 5336 + 54 + 461) + 265 |
AMD Radeon RX 6900 XT	ROCm	version: 9890 (74976e1)	16 GB	16.368	16.342	1.111	—	llama.cpp issues/25594 Logzeilen 0.00.322.247 I cmn common_param: - ROCm0 : AMD Radeon RX 6900 XT (16368 MiB, 16342 MiB free) 0.01.255.231 I llama_prepare_model_devices: using device ROCm0 (AMD Radeon RX 6900 XT) (0000:03:00.0) - 16342 MiB free 0.01.790.609 I load_tensors: offloaded 66/66 layers to GPU
AMD Radeon RX 7900 XTX	ROCm	version: 8707 (3bd9aa1)	24 GB	24.560	24.376	219	—	llama.cpp issues/22052 Logzeilen Device 0: AMD Radeon RX 7900 XTX, gfx1100 (0x1100), VMM: no, Wave Size: 32, VRAM: 24560 MiB llama_model_load_from_file_impl: using device ROCm0 (AMD Radeon RX 7900 XTX) (0000:c4:00.0) - 24376 MiB free llama_params_fit_impl: - ROCm0 (AMD Radeon RX 7900 XTX): 24560 total, 9473 used, 14868 free vs. target of 1024

Referenztests

Jeder Fall ist ein öffentliches llama.cpp-Log, das die Puffer pro Gerät ausgibt. Die GGUF-Dateien dieses Logs werden gelesen, die Puffer werden pro Grafikkarte mit der Kontextlänge, den Sequenzen, dem Micro-Batch und dem KV-Typ aus dem Log neu berechnet und mit Modell + KV + RS + Rechenpuffer für dieselbe Grafikkarte verglichen. 38 Fälle (50 Grafikkarten) laufen bei jedem Build als automatisierte Tests und müssen innerhalb von −5 % bis +10 % bleiben; der größte Fehler beträgt +8,85%.

Ausgeschlossene Logs und Gründe

• E04: Flash Attention war aus; diese Website modelliert Flash Attention als ein.
• E09: Lauf mit --swa-full, einem nicht standardmäßigen Sliding-Window-Cache.
• E16: Mehrere Sequenzen ohne einheitlichen KV-Cache; dieses Cache-Layout wird nicht modelliert.
• E32: Flash Attention war aus; diese Website modelliert Flash Attention als ein.
• E34: Flash Attention war aus; diese Website modelliert Flash Attention als ein.
• E42: Flash Attention war aus; diese Website modelliert Flash Attention als ein.

llama.cpp-Regeln nach Architektur

Wie jede Architektur ihren KV-Cache und ihren Zustand anlegt, ist aus dem llama.cpp-Quellcode im Commit 5aeac37a35 übernommen.

Quellen und wie Spezifikationen überprüft werden

• Websites der Hersteller werden nie abgerufen, weil deren Nutzungsbedingungen automatisierten Zugriff verbieten. Die Herstellerangabe stammt aus offenen Datensätzen, die zeilenweise auf ein Datenblatt des Herstellers verweisen (GetDeploying und Epoch AI, sofern das Datenblatt auf einer Domain des Herstellers oder auf einem Dokumenten-Host liegt, den der Hersteller selbst für seine Datenblätter nutzt), sowie aus der ROCm-Dokumentation von AMD. Diese Datenblatt-Links werden als „Herstellerangabe“ angezeigt und als von dieser Website nicht abgerufen gekennzeichnet. Datenblatt-Links gelten als die des Herstellers, wenn sie auf einer dieser Domains liegen (einschließlich Dokumenten-Hosts, die die Hersteller nutzen): amd.com, apple.com, dam-cdn.nvd.orangelogic.com, geforce.com, intel.com, nvdam.widen.net, nvidia.com
• Wikipedia dient als unabhängige Gegenprüfung. Die Fußnoten dort werden nicht als Quelle für einen Wert verwendet, da Fußnoten in Spalten und Produktnamen nicht erkennen lassen, woher ein bestimmtes Feld stammt.
• Die Stimme für die Herstellerangabe und die Stimme der Gegenprüfung müssen von verschiedenen Herausgebern stammen, die nicht aufeinander verweisen: Wenn die gegenprüfende Wikipedia-Seite (oder Datensatzzeile) den anderen Herausgeber zitiert, zählt sie als abgeleitet und nicht als zweite Stimme. Eine Quelle, die ohne Hinweis von einer anderen abschreibt, lässt sich anhand öffentlicher Belege nicht erkennen.
• Ein Wert wird angezeigt (two_source), wenn eine Stimme für die Herstellerangabe und eine unabhängige Gegenprüfung übereinstimmen und keine intakte Quelle widerspricht. Andernfalls lautet der Status „conflict“ (Quellen widersprechen sich), „single“ (keine Stimme für die Herstellerangabe oder keine unabhängige Gegenprüfung) oder „missing“.
• Zeilen, die ein offener Datensatz TechPowerUp zuschreibt (Epoch-AI-Zeilen, deren Datenblatt-Link auf techpowerup.com verweist), werden überhaupt nicht gelesen, da die Bedingungen von TechPowerUp abgeleitete Datensätze verbieten: Sie zählen weder als Stimme noch als Widerspruch.
• Übereinstimmung bedeutet: Speichergröße exakt gleich, Bandbreite innerhalb von 1 %, andere Zahlen innerhalb von 2 %, Text nach Normalisierung gleich.
• Angezeigt wird der Wert, den die meisten übereinstimmenden Quellen exakt angeben; die eigene Angabe und der Link jeder Quelle sind daneben aufgeführt. Wikipedia-Links zeigen auf die genau verwendete Revision.
• Computer mit Apple Silicon, DGX Spark und Strix Halo werden in dieser Version nicht veröffentlicht: Keine offene Quelle verweist zeilenweise auf ein Datenblatt des Herstellers für sie.
• Modelldaten stammen von Hugging Face in festgelegten Revisionen. Jedes Modell verwendet ein GGUF-Repository für alle seine Quantisierungen, ausgewählt nach einer festen Reihenfolge der Herausgeber; die Architektur wird aus dem GGUF-Header gelesen und, soweit die ursprüngliche config.json lesbar ist, mit ihr gegengeprüft.
• Originale Gewichte, nur zur Referenz angezeigt, zählen die safetensors-Dateien des Repositorys auf oberster Ebene und in model*-Ordnern: Mit einer model.safetensors.index.json zählen die darin genannten Dateien plus vollständige Sätze in anderen model*-Ordnern; ohne eine solche zählt jeder vollständige Satz, wobei eine zusammengeführte Datei und eine identische geteilte Kopie nur einmal gezählt werden. Andere Ordner (zum Beispiel separat gespeicherte Decoder), original/, consolidated*-Dateien, LoRA-Adapter sowie .bin- / .pt-Dateien werden nicht gezählt. Bilden die Dateien nicht einen eindeutigen Satz, wird keine Größe angegeben.

Parameterzahlen

Die Parameter werden aus der GGUF-Tensortabelle der gewählten GGUF-Datei gezählt: jeder Tensor, den llama.cpp lädt, einschließlich der Input-Embedding-Tabelle. Multi-Token-Prediction-Schichten (MTP / NextN), die llama.cpp standardmäßig nicht lädt, werden nicht mitgezählt; Modellseiten, die sie enthalten, geben deren Anzahl an. Aktive Parameter pro Token zählen die Nicht-Experten-Tensoren plus die verwendeten Experten (verwendete Experten ÷ Experten pro Schicht), aber nicht den Lookup im Input-Embedding, da pro Token nur eine Zeile davon gelesen wird. Verwendet ein Modell eine Matrix sowohl als Input-Embedding als auch als Ausgabeschicht (gekoppelte Embeddings), wird jedes Token mit der gesamten Matrix multipliziert, daher wird sie einmal gezählt, und zwar als Ausgabeschicht. Modellkarten zählen oft auch die Input-Embedding-Tabelle und die MTP-Schichten mit, daher können ihre Angaben deutlich höher ausfallen, besonders bei kleinen Mixture-of-Experts-Modellen mit großem Vokabular. Die Zählung des ursprünglichen Repositorys wird separat angezeigt.

Aktive Parameter werden nur für Mixture-of-Experts-Modelle angegeben, also für Modelle, deren GGUF-Header mehr als einen Experten pro Schicht aufführt. Ein Modell mit nur einem Experten pro Schicht (Expertenanzahl 1) ist dicht (dense): Jeder Parameter wird für jedes Token verwendet, daher wird keine separate Angabe zu aktiven Parametern gezeigt.

Die Parameteranzahl des ursprünglichen Repositorys selbst ist die Gesamtzahl, die Hugging Face für dessen safetensors-Gewichte angibt; manche Repositorys geben sie in ihren Metadaten falsch an. Sie wird nur angezeigt und in die Downloads aufgenommen, wenn sie bestätigt ist: Sie muss größer als 100M Parameter sein, innerhalb von 1 % der Parameteranzahlen pro Typ liegen, die Hugging Face aus den Gewichtsdateien des Repositorys ausliest, und bei Modellen mit einer GGUF-Datei zwischen dem 0,5-Fachen und dem 2,5-Fachen der GGUF-Anzahl liegen (das Original kann zusätzlich einen Vision- oder Audio-Encoder oder Multi-Token-Prediction-Schichten enthalten; die GGUF-Datei kann größer sein, wenn sie eine gekoppelte Einbettung (Tied Embedding) ein zweites Mal als Ausgabeschicht speichert). Bei Modellen ohne GGUF-Datei müssen die ersten beiden Prüfungen erfüllt sein. Andernfalls wird die Anzahl weggelassen.

Was jeder Status anzeigt

Geschwindigkeitsobergrenze

Das Erzeugen eines Tokens liest die aktiven Gewichte und den KV-Cache einmal, daher können Tokens pro Sekunde die Bandbreite geteilt durch die pro Token gelesenen Bytes nicht überschreiten. Bei Mixture-of-Experts-Modellen wird nur der Anteil der verwendeten Experten gezählt, ermittelt aus der GGUF-Tensor-Tabelle. Es ist eine theoretische Obergrenze; es wird keine Geschwindigkeit angegeben, wenn die Bandbreite nicht von zwei Quellen bestätigt ist.

Öffentliche Benchmarks

Gemessene llama.cpp-Geschwindigkeiten, die vom llama.cpp-Projekt in seinem Repository veröffentlicht wurden (llama-bench, am fixierten llama.cpp-Commit). Für die Maschinen in diesen Hinweisen (DGX Spark, Apple M2 Ultra) gibt es in dieser Version auf dieser Website keine Einstufungen; die Zahlen zeigen, wie die gemessene Geschwindigkeit im Vergleich zur Obergrenze der Bandbreite liegt und wie sie mit wachsendem Kontext sinkt: llama.cpp benches/ (5aeac37a)

Macs und andere Computer mit Unified Memory (gemeinsamer Speicher)

Bei diesen Computern kann die GPU nur einen Teil des Speichers nutzen, und die offenen Quellen dafür nennen keine Belege pro Wert. Sie werden in dieser Version nicht veröffentlicht; die Laufzeitprofile dafür werden aufbewahrt, bis die Quellen es erlauben.

Einheiten

Die hier berechneten Speichermengen sind in GiB angegeben (1.073.741.824 Bytes). Die „24 GB“ Videospeicher, die GPU-Hersteller angeben, sind 24 GiB. Hugging Face zeigt Dateigrößen in dezimalen GB an, daher erscheint eine 5,03-GB-Datei hier als 4,68 GiB. Die Bandbreite ist in GB/s angegeben (10⁹ Bytes pro Sekunde).

Aktualisierungen

Hugging Face wird alle 6 Stunden auf neue Modelle und neue GGUF-Dateien durchsucht; GPU-Spezifikationen werden täglich erneut überprüft.