Ein Sprachmodell mit Hunderten Milliarden Parametern passt auch in quantisierter Form oft nicht in den Speicher eines gewöhnlichen Rechners. Das Projekt WiCi versucht, diese Grenze mit einer anderen Speicheraufteilung zu verschieben: Seine offene Laufzeit InferSSD hält die Gewichte der nur bei Bedarf benötigten Modellteile auf einer NVMe-SSD und lädt sie während der Inferenz nach. Die erste öffentliche Version 0.1.0 erschien am 30. Oktober; Version 0.1.1 vom 31. Oktober behebt ein Problem bei der Installation aus dem Quellcode unter Linux mit neueren CUDA-Toolkits.
Warum eine SSD hier helfen kann
InferSSD richtet sich an Mixture-of-Experts-Modelle (MoE). Bei ihnen entscheidet ein Router für jedes Token, welche sogenannten Experten an der Berechnung beteiligt sind. Nicht alle Experten müssen deshalb zugleich im schnellen Speicher liegen. InferSSD baut auf llama.cpp auf, liest die Gewichte aus GGUF-Dateien und verwaltet die benötigten Experten über SSD, Arbeitsspeicher und gegebenenfalls Grafikspeicher. Ein Cache vermeidet erneute Lesezugriffe, wenn ein Experte wieder gebraucht wird. Die gemeinsam genutzten Modellteile, der Attention-Bereich und der mit dem Gespräch wachsende KV-Cache benötigen weiterhin Arbeitsspeicher oder VRAM. Die SSD ersetzt also nicht den gesamten Modellspeicher. Auf Macs mit Metal berechnet nach der Architekturbeschreibung die CPU die ausgewählten Experten, während die GPU die übrigen dafür vorgesehenen Schichten ausführt; unter Linux mit CUDA kommt eine zusätzliche GPU-Cache-Ebene hinzu.
Das Projekt nennt derzeit zwei getestete GGUF-Konvertierungen: DeepSeek-V4.1-Flash-1017 und Muse-Spark-Open. Diese Modelle sind nicht neu durch InferSSD entstanden; neu ist die öffentlich verfügbare Laufzeit für ihre speichergestützte Ausführung. Das Repository bietet neben einem Terminal-Client einen Browser-Chat und eine OpenAI-kompatible API. Die unterstützten Download-Referenzen sind zunächst auf die beiden getesteten Modell-Repositories begrenzt; lokale GGUF-Dateien können Entwickler separat angeben.
Die Geschwindigkeit bleibt die entscheidende Frage
In den Messungen des Projekts verarbeitet ein System mit RTX 5090, 32 GB Arbeitsspeicher, 32 GB VRAM und einer über PCIe 5.0 angebundenen SSD den DeepSeek-Testprompt mit 164,5 Token pro Sekunde und erzeugt anschließend 7,27 Token pro Sekunde. Gemessen wurde bei der Ausgabe über die Token 129 bis 256; die Bezeichnung „4K“ beschreibt eine Prompt-Klasse und keine feste Kontextlänge. Auf demselben Rechner weist die Tabelle für die getestete llama.cpp-Konfiguration 8,06 Token pro Sekunde beim Einlesen und 0,867 bei der Ausgabe aus. Die Zahlen stammen von den Entwicklern und sind noch kein unabhängiger Leistungsvergleich.
Entscheidend für die Praxis ist, wie schnell ein konkreter Rechner Antworten ausgibt, nicht allein, ob sich die Gewichte überhaupt laden lassen. Auch die Werte verschiedener Konfigurationen lassen sich nicht auf eine einzelne Optimierung zurückführen: Cache-Größe, Batch-Einstellungen und Ausführungsweg beeinflussen das Ergebnis. Die Methodendokumentation unterscheidet zudem aktuelle zusammengefasste Ergebnisse von älteren Einzelläufen. Vergleiche mit anderen Laufzeiten sollten daher denselben Modellstand, dieselbe Quantisierung und dieselben Eingaben verwenden.
Was Entwickler einplanen müssen
Der derzeit angebotene Installer baut die Laufzeit aus dem Quellcode; fertige Binärpakete gibt es laut Schnellstart-Anleitung noch nicht. Der dokumentierte Installationspfad unterstützt Apple-Silicon-Macs mit Metal und Linux-Rechner mit Nvidia-GPU und CUDA. Windows ist im Repository noch als in Arbeit gekennzeichnet. Unter Linux kommen unter anderem liburing-Header und eine geeignete Laufzeitumgebung hinzu. Wer den getesteten DeepSeek-GGUF herunterlädt, muss laut Schnellstart rund 473 GiB Speicherplatz allein für dessen Dateien vorsehen; ein zusätzliches, optionales Expertenpaket benötigt weitere rund 269 GiB. Bei der ersten Ausführung vermisst die Software außerdem den Rechner und richtet ihre Speicheraufteilung ein.
Für Entwickler, die große Modelle lokal erproben wollen, ist InferSSD vor allem dann interessant, wenn eine schnelle SSD vorhanden ist, aber RAM und VRAM für sämtliche Gewichte nicht ausreichen. Für einen Dienst mit mehreren gleichzeitigen Nutzern fehlen damit noch keine Lasttests: Die veröffentlichten Durchsatzwerte beschreiben bestimmte Testaufbauten, nicht automatisch das Verhalten unter konkurrierenden Anfragen. Zudem ist die getestete DeepSeek-GGUF-Fassung eine Textkonvertierung und enthält nach der Formatdokumentation nicht alle Module des veröffentlichten Originalmodells. Wer Bildverarbeitung oder identische Ausgaben zum Original erwartet, muss diese Unterschiede berücksichtigen. Die Apache-2.0-Lizenz von InferSSD ersetzt außerdem nicht die jeweiligen Lizenzen der Modellgewichte.
Fazit
InferSSD macht eine konkrete technische Möglichkeit für lokale KI nutzbar: Bei MoE-Modellen können selten benötigte Experten auf der SSD bleiben, während der Rechner nur den aktuellen Arbeitssatz vorhält. Die Veröffentlichung senkt damit die Speicherhürde für sehr große offene Gewichte. Ob sich daraus ein brauchbarer Arbeitsablauf ergibt, hängt weiterhin von SSD, CPU, GPU, Cache-Verhalten und dem gewünschten Antworttempo ab. Wer die Laufzeit einsetzen will, sollte sie mit dem eigenen Modell und eigenen Prompts messen, bevor er aus den veröffentlichten Benchmarks eine Betriebsentscheidung ableitet.