Holo-3.1-0.8B: Wie viel VRAM wird benötigt?

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

Holo-3.1-0.8B hat 1,0B Parameter. Bei Q4_K_M und einem Kontext von 8.192 Tokens benötigt eine einzelne GPU 2,2 GiB verfügbaren Speicher, damit das Ergebnis „passt“ lautet.

Werte aktualisiert am 19. Okt. 2026

Wichtige Fakten

GGUF-Dateien und benötigter Speicher

Alle Quantisierungen stammen aus einem GGUF-Repository in einer festgelegten Revision: mradermacher/Holo-3.1-0.8B-i1-GGUF@f8bb63f

Kleinste GPU für jede Quantisierung

GPUs, die Holo-3.1-0.8B ausführen können

„Passt“ bedeutet: Die standardmäßige --fit-Ladeprüfung von llama.cpp würde alle Layer auf der GPU platzieren. Unsere Schätzung der Puffer von llama.cpp, plus deren Fehlermarge, plus die Reserve von 1 GiB pro Karte bei llama.cpp liegt innerhalb des als verfügbar gezählten Speichers. Es ist keine Zusage, dass der Spitzenspeicherbedarf während der Generierung passt. Wie Ergebnisse bestimmt werden

GPUs ohne Einschätzung

• 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.
• 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.

Die Geschwindigkeitsobergrenze ergibt sich aus der Speicherbandbreite geteilt durch die pro erzeugtem Token gelesenen Bytes. Sie ist eine theoretische Obergrenze; öffentliche llama.cpp-Benchmarks erreichen typischerweise etwa die Hälfte bis vier Fünftel davon, kleine Modelle und Mixture-of-Experts-Modelle oft weniger. Öffentliche Benchmarks

Originalgewichte

Die originalen Gewichtsdateien des Modells (safetensors, gezählt wie in der Methodik beschrieben) umfassen insgesamt 2,1 GiB. Sie werden nur zur Referenz aufgeführt; jede Schätzung auf dieser Seite bezieht sich auf die oben genannten GGUF-Dateien, ausgeführt mit llama.cpp. Hcompany/Holo-3.1-0.8B · Methodik

Quellen

• Hugging Face: Hcompany/Holo-3.1-0.8B@72da4c5
• Hugging Face (GGUF): mradermacher/Holo-3.1-0.8B-i1-GGUF@f8bb63f
• Methodik (llama.cpp 5aeac37a)