2026: Wie viel Arbeitsspeicher benötigt Qwen3.5 für die CPU-Bereitstellung? Erst das Modell berechnen, dann den Server wählen

Das Modell passt in den Speicher, aber die Antwort kommt unter Last zu spät?
Für die Qwen3.5-CPU-Bereitstellung gilt: Rechnen Sie zuerst quantisierte Gewichte, Kontext-Cache und Laufzeitumgebung zusammen und messen Sie den Spitzenverbrauch. CPU-only eignet sich für Tests, seltene Anfragen und Batch-Aufgaben, nicht als Ersatz für eine GPU bei hohem Durchsatz.

Dieser Leitfaden richtet sich an Entwickler und kleine Teams, die Qwen3.5 selbst betreiben und vor der Serverwahl den Arbeitsspeicherbedarf bestimmen möchten.
Er hilft dabei, Modellgröße, parallele Dienste und die tatsächliche CPU-Grenze getrennt zu beurteilen.

Zuletzt aktualisiert am 24.10.2026. Geprüft wurden die Angaben im offiziellen Qwen3.5-Repository, im Ollama-Modellverzeichnis und in der AMD-Spezifikation des EPYC 7543. Modell-Tags, Dateien, Lizenzangaben und unterstützte Laufzeitfunktionen können sich ändern; vor einer produktiven Bereitstellung sind die jeweils aktuellen Einträge zu prüfen.

Qwen3.5-CPU-Bereitstellung: Arbeitsspeicher zuerst kalkulieren

Eine Modellkarte oder ein Download-Eintrag liefert keine universelle Mindestgröße für den Server. Entscheidend sind die konkrete Modellvariante, die verwendete Quantisierung und die Betriebsart. Der erste Rechenschritt ergibt deshalb nur eine Untergrenze für die Gewichte:

Parameterzahl × Quantisierungsbitbreite ÷ 8 = grobe Speichergröße der Gewichte in Byte.

Die Division durch 8 wandelt Bit in Byte um. Ein Modell mit einer Parameterzahl von P und einer mittleren Quantisierungsbitbreite von b benötigt nach dieser Näherung P × b ÷ 8 Byte für die Gewichte. P und b müssen aus der tatsächlich gewählten Modellvariante und deren Datei- beziehungsweise Metadaten ermittelt werden. Die Formel ist eine Rechenhilfe, keine Zusage für den Speicherbedarf im Betrieb.

Ein quantisiertes Format kann zusätzliche Informationen und abweichende Blockstrukturen enthalten. Außerdem belegt ein gestarteter Inferenzprozess nicht ausschließlich Modellgewichte: Laufzeit, temporäre Puffer und Betriebssystem benötigen ebenfalls Speicher. Die auf der Festplatte angezeigte Dateigröße ist daher weder eine exakte RAM-Messung noch ein Beleg dafür, dass das Modell zusammen mit den übrigen Diensten stabil läuft.

Prüfen Sie die konkrete Qwen3.5-Variante im offiziellen Repository samt Modell- und Lizenzhinweisen sowie die aktuelle Auswahl im Ollama-Modellverzeichnis mit den dort aufgeführten Tags und Dateiinformationen. Verwechseln Sie verschiedene Tags nicht miteinander: Ein anderer Tag kann eine andere Quantisierung oder Datei bezeichnen. Prüfen Sie außerdem die Lizenz des konkreten Modells, bevor es in einem kommerziellen Dienst eingesetzt wird.

Kontext und Anfragen als eigene Speicherposten

Nach den Gewichten folgt der Kontext. Bei der Verarbeitung hält die Laufzeit Informationen zu bereits verarbeiteten Tokens vor; dazu gehört der KV-Cache. Ein größerer Kontext kann dessen Speicherbedarf erhöhen. Auch parallel bearbeitete Anfragen können zusätzlichen Cache und weitere Laufzeitressourcen beanspruchen. Eine feste Zuschlagszahl lässt sich ohne Modell, Laufzeit, Kontextvorgabe und Anfragemuster nicht seriös angeben.

Multimodale Eingaben können weitere Speicherpfade betreffen. Ob das in einer konkreten Konfiguration relevant ist, hängt von Modelltyp und unterstützter Implementierung ab. Nehmen Sie deshalb nicht an, dass ein Texttest automatisch den Speicherbedarf für jede Eingabeart abbildet. Ermitteln Sie zunächst, welche Eingaben die Anwendung tatsächlich zulässt und welche Funktionen die ausgewählte Laufzeit unterstützt.

Für einen belastbaren Test gehören drei Angaben ins Messprotokoll: die konkrete Modellvariante samt Quantisierung, die tatsächlich verwendete maximale Kontextlänge und das geplante Anfrageverhalten. Starten Sie dann mit einem repräsentativen Prompt, testen Sie den längsten vorgesehenen Eingabefall und beobachten Sie den Speicherverbrauch während der vollständigen Anfrage. Wenn die Anwendung mehrere gleichzeitige Aufträge zulässt, muss auch dieser Fall Teil der Messung sein.

Das Ergebnis zählt als Spitzenwert, nicht nur als Leerlaufwert nach dem Laden. Notieren Sie getrennt, was der Prozess dauerhaft belegt, welcher Höchstwert während der Generierung auftritt und ob der Wert mit längeren Eingaben oder weiteren Anfragen steigt. Ohne diese Trennung kann ein Server zunächst passend erscheinen und später unter einer realistischen Anfrage in Speicherdruck geraten.

CPU-Leistung und Arbeitsspeicherbandbreite

„Lässt sich laden?“ und „liefert die Anwendung rechtzeitig Antworten?“ sind verschiedene Prüfungen. Mehr Arbeitsspeicher kann verhindern, dass ein Modell an der Kapazität scheitert; er beschleunigt aber nicht automatisch die Berechnung. Für CPU-only-Inferenz sind unter anderem Prozessor, Speicherbandbreite, Quantisierung, Laufzeit und Promptlänge relevant. Eine allgemeine Angabe in Tokens pro Sekunde wäre ohne identische Testbedingungen nicht übertragbar.

Beim CloudUDP-Angebot kommt ein AMD EPYC 7543P mit 32 Kernen und 64 Threads zum Einsatz. Der Prozessor gehört zur Zen-3-Generation und unterstützt AVX2, jedoch kein AVX-512; die AMD-Produktangaben dienen hier als Spezifikationsquelle, nicht als Leistungstest für Qwen3.5. Das System verfügt über acht Speicherkanäle. Bei DDR4-3200 entspricht die theoretische Gesamtbandbreite rechnerisch 8 × 25,6 GB/s, also rund 204,8 GB/s. Das ist ein theoretischer Wert und kein gemessenes Ergebnis einer Inferenzanwendung.

Für die Softwareplanung heißt AVX2 statt AVX-512: Prüfen Sie, welche CPU-Kernel die ausgewählte Version Ihrer Inferenzsoftware auf dieser Prozessorarchitektur tatsächlich verwendet. Die Bezeichnung einer Quantisierung allein beweist nicht, dass der passende optimierte Kernel aktiv ist. Auch eine korrekte CPU-Erkennung sagt nichts darüber aus, ob die Antwortzeit für den späteren Dienst ausreicht.

Führen Sie einen reproduzierbaren Test mit derselben Laufzeit und denselben Serving-Einstellungen aus, die auch für den Betrieb vorgesehen sind. Das Server-Handbuch von llama.cpp beschreibt die Serverbetriebsart; dort können Sie nachvollziehen, welche Optionen für die konkrete Installation relevant sind. Protokollieren Sie Eingabelänge, Ausgabelänge, Zeit bis zur ersten Antwort, Gesamtdauer und den gemessenen Arbeitsspeicher. Diese Werte gehören zu genau dieser Testumgebung und dürfen nicht als allgemeine Qwen3.5-Leistungszusage gelesen werden.

Laufzeitumgebung und Begleitdienste

Ein Modellserver läuft selten allein. Betriebssystem, Container, API-Schicht, Warteschlange, Protokollierung und weitere Anwendungsdienste belegen jeweils Speicher. Wenn zusätzlich eine Vektordatenbank oder ein Suchdienst auf derselben Maschine läuft, muss deren Speicherbedarf im Betriebszustand erfasst werden. Bei einem selbst gehosteten KI-Stack können diese Dienste die verfügbare Reserve stärker verändern als eine kleine Anpassung der Modellparameter.

Trennen Sie die Messwerte nach Prozess oder Container. Eine Begrenzung für einen einzelnen Container ist nicht dasselbe wie eine ausgeschöpfte Gesamtkapazität des Servers. Die Docker-Dokumentation zu Container-Ressourcenbegrenzungen erläutert, wie Speichergrenzen die Wahrnehmung und das Verhalten eines Containers beeinflussen. Prüfen Sie bei einem Abbruch deshalb zunächst, ob ein Limit des Containers gegriffen hat, oder ob dem Host insgesamt Speicher fehlt.

Auf Linux können Angaben aus /proc helfen, Prozess- und Systemspeicher während eines Tests zu beobachten. Die Kernel-Dokumentation zum Dateisystem /proc beschreibt die dort bereitgestellten Schnittstellen. Halten Sie dabei eine konsistente Messmethode ein: Vergleichen Sie nicht unkommentiert den Containerwert aus einem Werkzeug mit dem Hostwert aus einer anderen Quelle.

Ein sinnvoller Ablauf lautet:

1. Erfassen Sie Modell-Tag, Quantisierung, Laufzeitversion und Startparameter.
2. Messen Sie den Speicherverbrauch des ruhenden Hosts und der dauerhaft laufenden Dienste.
3. Laden Sie das Modell und notieren Sie den zusätzlichen Verbrauch nach dem Laden.
4. Senden Sie repräsentative Anfragen mit der vorgesehenen Kontextlänge und erfassen Sie den Spitzenwert.
5. Wiederholen Sie die Prüfung mit der geplanten Zahl paralleler Anfragen und den tatsächlich genutzten Zusatzdiensten.
6. Prüfen Sie Protokolle und Containerlimits, wenn Prozesse beendet werden oder Antworten ausbleiben.
7. Wiederholen Sie den Test nach Änderungen an Modell, Quantisierung, Laufzeit oder Serving-Konfiguration.

Die Reserve ist kein beliebiger Prozentwert, sondern muss aus dem eigenen Betrieb abgeleitet werden. Wenn Wartungsaufgaben, automatische Aktualisierungen oder weitere Container während der Modellnutzung laufen, gehören sie ebenfalls in den Belastungstest. Die Systemkapazität sollte nicht allein anhand eines frisch gestarteten Hosts dimensioniert werden.

CPU-only für passende Arbeitslasten

CPU-only ist vor allem dann eine ernsthafte Option, wenn die Anwendung geringe oder planbare Nachfrage hat und die gemessene Antwortzeit den Zweck erfüllt. Beispiele sind Funktionsprüfungen, interne Experimente, gelegentliche Abfragen und Batch-Verarbeitung, bei der eine längere Laufzeit akzeptabel ist. Für diese Fälle kann ein Test auf dem Zielserver die Kaufentscheidung deutlich besser absichern als ein Vergleich von Modell-Dateigrößen.

Bei einer Online-Anwendung mit vielen gleichzeitig wartenden Nutzern ist ein einzelner erfolgreicher Test nicht ausreichend. Entscheidend sind die vereinbarte Antwortzeit, die Zahl der gleichzeitig angenommenen Anfragen und der Durchsatz unter anhaltender Last. Wenn diese Anforderungen deutlich über den gemessenen CPU-Werten liegen, behebt zusätzlicher RAM den Engpass nicht. Dann sollten Modellgröße, Anfrageverhalten, Architekturaufteilung und GPU-Ressourcen geprüft werden.

Häufige Fragen zur Speicherplanung

Wie wird der Speicherbedarf für Qwen3.5 auf einem reinen CPU-Server angesetzt?
Ausgangspunkt ist die konkrete Parameterzahl und Bitbreite der Quantisierung. Daraus lässt sich die grobe Größe der Gewichte berechnen; anschließend kommen Kontext-Cache, Laufzeit, Betriebssystem und alle Begleitdienste hinzu. Erst eine Messung mit realen Eingaben und der vorgesehenen Zahl gleichzeitiger Anfragen zeigt, ob die gewählte Konfiguration ausreichend ist.

Ist die Downloadgröße einer quantisierten Modelldatei gleich dem benötigten RAM?
Nein. Die Dateigröße beschreibt nicht automatisch alle zur Laufzeit belegten Speicherbereiche. Neben den Gewichten können Cache, Puffer und weitere Prozesse Speicher beanspruchen; außerdem können Dateiformat und Implementierung die Abweichung beeinflussen. Für die Entscheidung ist der gemessene Spitzenwert im vollständigen Anwendungsszenario maßgeblich, nicht allein die Downloadanzeige.

Was verändert eine längere Kontextlänge am Speicherbedarf?
Ein längerer Kontext kann mehr KV-Cache erfordern, und zusätzliche parallele Anfragen verändern den Ressourcenbedarf ebenfalls. Wie stark das ausfällt, ist modell- und laufzeitabhängig. Testen Sie daher mit der längsten Eingabe, die im Betrieb tatsächlich zugelassen wird, und prüfen Sie, ob die Anwendung gleichzeitige Aufträge puffert oder verarbeitet.

Wann passt CPU-only zu Qwen3.5?
Für Tests, seltene Interaktionen oder planbare Batch-Läufe kann CPU-only passen, sofern die gemessene Dauer für den Anwendungsfall akzeptabel ist. Sobald hohe Anfragezahlen, kurze Antwortzeiten oder dauerhaft hoher Durchsatz gefordert sind, reicht ein größerer RAM-Ausbau nicht als Ersatz für GPU-Rechenleistung. Vergleichen Sie die Messergebnisse mit den vorab definierten Anforderungen.

Entscheidungsmatrix für CPU-only und Serverkapazität

Verwenden Sie die Matrix nach einem Test mit der vorgesehenen Modellvariante, Quantisierung, Kontextlänge und Laufzeit. Sie ist ein konkretes Auswahlwerkzeug: Prüfen Sie zuerst den Speicher, dann die Antwortzeit und erst danach die Serveroption. Ein positives Ergebnis in einer Zeile ersetzt nicht die Prüfung der übrigen Zeilen.

Die Verzweigung ist absichtlich streng: Eine ausreichend große RAM-Konfiguration beweist nur, dass Speicher nicht der unmittelbare Engpass im getesteten Fall ist. Sie bestätigt weder eine bestimmte Tokenrate noch eine bestimmte Zahl gleichzeitiger Nutzer. Ebenso belegt eine einzelne schnelle Antwort nicht, dass der Dienst bei gleichzeitigen Anfragen stabil bleibt.

Vom Test zur Serverentscheidung

Vor der Bestellung sollte ein kurzes Prüfprotokoll vorliegen: konkreter Modell-Tag, Lizenzprüfung, Quantisierung, Kontextvorgabe, Laufzeit, gemessener RAM-Spitzenwert, Antwortzeit und parallel laufende Dienste. Fehlt ein Wert, ist die Konfiguration noch nicht ausreichend validiert. Ändert sich später eines dieser Elemente, insbesondere das Modell oder die Laufzeit, ist die Messung zu wiederholen.

Für den produktiven Betrieb ist außerdem zu klären, welche Dokumente und Eingaben die Anwendung verarbeitet und wer darauf zugreifen darf. Selbsthosting kann die Kontrolle über die eigene Infrastruktur verbessern, ersetzt aber keine Zugriffsregeln, Verschlüsselung, Datensicherung oder Prüfung der verwendeten Modelllizenz. Die Hinweise zu personenbezogenen Daten bei CloudUDP sollten zusammen mit den eigenen Datenschutz- und Sicherheitsanforderungen bewertet werden.

Bei der Kapazitätsplanung zählen sowohl der Modellprozess als auch die Dienste, die parallel betrieben werden sollen. Die CloudUDP-Produktübersicht führt die tatsächlich auswählbaren Speicherausstattungen und Systemkonfigurationen auf. Für die hier angebotenen AMD-Server sind 128 GB oder 256 GB DDR4-3200 ECC-RDIMM vorgesehen; die Speichergröße ist bei der Auswahl festzulegen und lässt sich nicht nachträglich durch zusätzliche Module erweitern. Diese Angaben sind Ausstattung, keine Aussage darüber, wie groß ein bestimmtes Qwen3.5-Modell sein darf oder wie schnell es laufen wird.

Auch der Speicherplatz ist getrennt vom Arbeitsspeicher zu bewerten. Die CloudUDP-Konfiguration umfasst zwei direkt angebundene NVMe-Laufwerke mit je 1 TB; die daraus verfügbare Rohkapazität ist nicht mit RAM gleichzusetzen und sagt nichts über die Größe des geladenen Modells im Arbeitsspeicher aus. Für eine belastbare Planung müssen Modellablage, Datenbestand, Protokolle und Sicherungskopien separat betrachtet werden. Die Produktübersicht nennt die tatsächlich angebotenen Optionen; Preise sind dort anhand der aktuellen Auswahl zu prüfen.

Wenn CPU-only nach einem vollständigen Test die geforderte Antwortzeit erreicht, kann ein exklusiver AMD-Server eine nachvollziehbare Grundlage für den längerfristigen Betrieb bieten: Es gibt keine konkurrierenden Mieter auf derselben Maschine, die CPU-Ressourcen stehen nicht als überbuchte VPS-Zuteilung zur Verfügung, und Speicher- sowie NVMe-Ausstattung lassen sich vorab anhand der Produktübersicht auswählen. Diese Punkte lösen jedoch weder einen zu hohen Modellbedarf noch eine zu langsame CPU-Inferenz. Wenn der Engpass die Rechenleistung ist, sollte zuerst eine GPU-Option geprüft werden; CloudUDP bietet keine GPU-Server an.

Sind die Messwerte tragfähig und passt eine der tatsächlich verfügbaren Speicherausstattungen zum zusammengefassten Bedarf, vergleichen Sie die Konfigurationen und Abrechnungszeiträume in der CloudUDP-Produktübersicht, bevor Sie die Bereitstellung festlegen. So beruht die Wahl auf einem gemessenen Qwen3.5-Betrieb und nicht auf der Annahme, dass eine große Modelldatei automatisch einen bestimmten RAM-Bedarf oder eine akzeptable CPU-Leistung bedeutet.

Häufig gestellte Fragen