Welche KI-Modelle passen in Ihren VPS-Arbeitsspeicher?

Welche KI-Modelle Sie selbst hosten können

Welche KI-Modelle Sie selbst hosten können, wird durch eine Zahl bestimmt: den Arbeitsspeicher des Servers. Die Modellfamilie und das Framework sind weit weniger wichtig als die Frage, ob die Gewichte mit ausreichend Reserve in den Arbeitsspeicher passen. Dieser Beitrag erklärt die dafür notwendige Berechnung. Die Installation einer Runtime ist ein separater Arbeitsschritt. Sie wird in der Anleitung zum Betrieb von Ollama auf einem VPS beschrieben.

Zwei Speicheranforderungen bestimmen das Ergebnis. Die Gewichte sind der feste Anteil. Er wird durch die Parameteranzahl und die Quantisierung bestimmt. Das Kontextfenster verursacht den laufenden Speicherbedarf. Diesen Bedarf vergessen viele, bis ein Modell, das gestern noch geladen werden konnte, heute nicht mehr geladen werden kann.

Die Größenberechnung: Bits pro Parameter

Eine Modelldatei besteht fast vollständig aus Gewichten. Jedes Gewicht wird mit einer bestimmten Anzahl von Bits gespeichert. Quantisierung bedeutet, die Gewichte mit weniger Bits zu speichern, als bei ihrem Training verwendet wurden. Das kostet etwas Genauigkeit, spart aber viel Speicher. Die Größe ergibt sich direkt daraus:

weights in GB = (parameters in billions x bits per weight) / 8

Modelle werden mit 16 Bit veröffentlicht. Das entspricht 2 GB pro Milliarde Parameter. Deshalb verwendet fast niemand die Veröffentlichungspräzision auf einem VPS. Diese Quantisierungen werden Sie in der Praxis antreffen, mit ihrer tatsächlichen durchschnittlichen Bitanzahl pro Gewicht:

• Q8_0 speichert etwa 8.5 Bit pro Gewicht, also ungefähr 1.1 GB pro Milliarde Parameter.
• Q6_K speichert etwa 6.6 Bit, also ungefähr 0.83 GB pro Milliarde Parameter.
• Q5_K_M speichert etwa 5.7 Bit, also ungefähr 0.71 GB pro Milliarde Parameter.
• Q4_K_M speichert etwa 4.8 Bit, also ungefähr 0.6 GB pro Milliarde Parameter.

Verwenden Sie 0.6 GB pro Milliarde Parameter als Richtwert. Q4_K_M ist auf einem speicherbegrenzten System die sinnvolle Standardeinstellung: Der Qualitätsverlust gegenüber 8 Bit ist bei den meisten Aufgaben gering, und die Datei ist fast halb so groß. Unter 4 Bit nimmt der Verlust schnell zu. Ein auf 2 Bit komprimiertes 70B-Modell liefert daher in der Regel schlechtere Antworten als ein 32B-Modell mit 4 Bit aus derselben Generation. Wenn der Speicher knapp ist, wählen Sie eine kleinere Größenklasse, bevor Sie unter 4 Bit gehen.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

Die Spalte für die Gewichte oben basiert auf der Regel von 0.6 GB pro Milliarde Parameter. Tatsächliche GGUF-Dateien liegen innerhalb weniger Prozent dieses Werts, weil die Embedding- und Ausgabeschichten mit höherer Präzision als der Rest gespeichert werden. Ein 3B-Modell mit 4 Bit benötigt etwa 1.8 GB. Ein 8B-Modell benötigt 4.8 GB. Ein 32B-Modell benötigt 19.2 GB, und ein 70B-Modell 42 GB.

Warum die Kontextlänge mehr RAM kostet als die Gewichte

Der KV-Cache (Key-Value-Cache, der Attention-Zustand, den das Modell für jedes Token der aktuellen Unterhaltung speichert) ist der zweite Kostenfaktor. Er wird beim Laden des Modells reserviert, auf die angeforderte Kontextlänge ausgelegt und wächst linear mit dieser Länge.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Beim Standardkontext von Ollama belegt dieses 8B-Modell einen halben Gigabyte für den Cache. Bei 8192 Tokens belegt es 1 GB. Beim Kontext von 128k, den die Modellkarte angibt, belegt es 16 GB. Das ist mehr als das Dreifache der Gewichte. Beim 70B-Modell ist es umgekehrt: Sein Cache belegt bei 128k 40 GB und damit weniger als die Gewichte. Grouped Query Attention verhindert, dass die Kosten pro Token annähernd so schnell wie die Parameteranzahl wachsen.

Ollamas Standardkontextlänge beträgt auf einem Server ohne GPU 4096 Tokens. Wenn eine GPU vorhanden ist, wählt Ollama den Standardwert anhand des VRAM: 32k zwischen 24 und 48 GiB sowie 256k ab 48 GiB. Erhöhen Sie den Wert mit der Variable OLLAMA_CONTEXT_LENGTH auf dem Server. Prüfen Sie anschließend in der Spalte CONTEXT von ollama ps, welchen Wert ein laufendes Modell tatsächlich erhalten hat. Die Speicherberechnung hinter dieser Einstellung wird im Beitrag zu num_ctx und Kontextlänge ausführlich hergeleitet.

Es gibt zwei Möglichkeiten, den Cache wieder zu verkleinern. Fordern Sie den benötigten Kontext an, statt den von der Modellkarte angegebenen Kontext zu verwenden. Die meisten Chat- und Coding-Aufgaben passen in 8k bis 32k. Oder quantisieren Sie den Cache selbst auf 8 Bit. Dadurch halbiert sich seine Größe, allerdings kann die Erinnerung an Inhalte bei langen Kontexten abnehmen.

Ein residentes Modell bleibt im RAM, bis es entladen wird

Ollama hält ein Modell nach der letzten Anfrage 5 Minuten im Speicher und entlädt es anschließend. Diese Standardeinstellung ist für einen Laptop geeignet, aber für einen Server ungünstig. Nach jeder Leerlaufphase muss die erste Anfrage erneut die Ladezeit abwarten.

ollama ps
ollama stop qwen3:4b

ollama ps listet die residenten Modelle auf. Die Spalte SIZE zeigt, wie viel Speicher das Modell belegt. Die Spalte UNTIL zeigt, wann es entladen wird. Um ein Modell dauerhaft im Speicher zu halten, setzen Sie OLLAMA_KEEP_ALIVE=-1 für den Dienst. Der Wert 0 entlädt das Modell, sobald die jeweilige Antwort abgeschlossen ist.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Senden Sie eine Anfrage und führen Sie ollama ps zehn Minuten später erneut aus. Das Modell wird weiterhin aufgelistet. Genau darum geht es: Es belegt diesen RAM unabhängig davon, ob es gerade verwendet wird. Ein fest im Speicher gehaltenes Modell ist keine freie Kapazität. Auf einem VPS mit 16 GB belegt ein 8B-Modell bei einem Kontext von 8k ungefähr 6 GB, solange der Dienst läuft. Dimensionieren Sie den Server daher nach dem Modell und Ihrer Anwendung, nicht nur nach dem Modell. Ein Modell im Speicher halten erläutert den Zielkonflikt zwischen Speicherbelegung und Kaltstartlatenz.

Was auf einer 4-GB-VPS läuft

Reservieren Sie etwa 1 GB für das Betriebssystem und den Model-Server. Damit bleiben ungefähr 3 GB. Das entspricht einem 1B- bis 4B-Modell mit 4 Bit und dem standardmäßigen Kontext von 4096 Token. Im August 2026 gehören Llama 3.2 mit 3B, Qwen 3 mit 1.7B und 4B sowie die kleinen Gemma- und Phi-Releases in diese Klasse. Betrachten Sie diese Angaben als Größenbeispiele, nicht als Empfehlungen. Die Namen ändern sich alle paar Monate. Die Berechnung bleibt unverändert.

Rechnen Sie mit ungefähr 6 bis 14 Token pro Sekunde. So kleine Modelle eignen sich gut für eng begrenzte Aufgaben: Klassifizierung, Extraktion von Tags, kurze Zusammenfassungen und das Umschreiben eines Absatzes in einem vorgegebenen Schreibstil. Bei mehrstufigem logischem Schlussfolgern und bei Code, der sich über mehrere Dateien erstreckt, sind sie schwach. Das lässt sich durch noch so viele Prompts nicht beheben.

Das typische Problem in dieser Größenklasse ist Swap. Wenn das Modell nicht in den Arbeitsspeicher passt, verweigert Linux das Laden nicht. Stattdessen lagert es Speicher auf die Festplatte aus. Da bei der Generierung eines einzelnen Tokens jedes Gewicht einmal gelesen wird, fällt die Generierung auf mehrere Sekunden pro Token ab. Überwachen Sie free -h sowie die Spalten si und so von vmstat 1, während das Modell antwortet. Werte ungleich null bei Swap-In und Swap-Out während der Generierung bedeuten, dass das Modell für den Plan zu groß ist.

Was auf einem VPS mit 8 bis 16 GB läuft

Hier wird ein selbst gehostetes Modell allgemein nützlich. Auf 8 GB können Sie ein 7B- oder 8B-Modell mit 4 Bit und etwa 4.8 GB Gewichten sowie einem Kontext von 8k ausführen. Auf 16 GB können Sie ein 13B- oder 14B-Modell mit 4 Bit und etwa 8.4 GB ausführen. Alternativ können Sie ein 8B-Modell mit 8 Bit betreiben, wenn Sie den Arbeitsspeicher lieber für höhere Präzision als für mehr Parameter einsetzen.

Der Nachteil ist die Geschwindigkeit. Ein 8B-Modell erzeugt auf der CPU etwa 3 bis 7 Token pro Sekunde. Ein 14B-Modell erreicht etwa 1.5 bis 3.5 Token pro Sekunde. Menschen lesen ungefähr 5 bis 10 Token pro Sekunde. Ein 8B-Modell auf einem CPU-VPS fühlt sich daher an, als würden Sie einer langsamen Schreibkraft zusehen. Für einen Hintergrundprozess ist das in Ordnung. Für interaktiven Chat ist es anstrengend. Gemessene Läufe von Qwen 3 mit 8B und größeren Modellen auf einem VPS zeigen, wie das in der Praxis aussieht.

Was auf einem VPS mit 32 bis 64 GB RAM läuft

Ein 32B-Modell mit 4 Bit benötigt etwa 19.2 GB. Damit passt es mit einem kurzen Kontext in einen Tarif mit 32 GB und läuft auf 48 oder 64 GB problemlos. Ein 70B-Modell mit 4 Bit benötigt etwa 42 GB. Dafür sind 64 GB erforderlich, bevor überhaupt Cache hinzukommt.

Lesen Sie anschließend die Geschwindigkeit realistisch ein. Ein 32B-Modell erreicht auf der CPU etwa 0.6 bis 1.5 Token pro Sekunde, ein 70B-Modell etwa 0.2 bis 0.5. Eine Antwort mit 500 Token von diesem 70B-Modell dauert ungefähr 20 Minuten. Bei diesem Tempo bricht die Anfrage normalerweise ab, bevor das Modell fertig ist, weil zuvor ein Client- oder Proxy-Timeout vor Ollama ausgelöst wird. Daher stammt der Fehler context deadline exceeded. Diese Tools sind für die Stapelverarbeitung ausgelegt. Wenn Sie ihnen über Nacht eine Warteschlange mit Dokumenten übergeben, spielt die Geschwindigkeit keine Rolle. Wenn Sie sie hinter einer Chat-Oberfläche einsetzen, ist sie sehr wichtig.

Mixture-of-Experts-Routing verändert diese Berechnung. Es ist das einzige Architekturd_detail, das Sie sich merken sollten. Ein MoE-Modell leitet jedes Token nur durch einen kleinen Teil seiner Gewichte. Ein Modell mit insgesamt 30B Parametern und 3B aktiven Parametern pro Token benötigt den Speicher eines 30B-Modells und erzeugt Ergebnisse fast mit der Geschwindigkeit eines dichten 3B-Modells. Der Grund ist, dass jedes Token nur die aktiven Experten verarbeitet. Auf einem System mit 32 GB RAM ist ein MoE-Modell dieser Größe wesentlich besser nutzbar als ein dichtes 30B-Modell. Die wichtigste Regel lautet: Die Gesamtzahl der Parameter bestimmt den Speicherbedarf, die Zahl der aktiven Parameter bestimmt die Geschwindigkeit.

Wie schnell ist die Inferenz auf der CPU wirklich?

Für die Generierung eines Tokens muss jedes aktive Gewicht einmal aus dem Speicher gelesen werden. Das lässt sich nicht vermeiden. Daher wird die Generierungsgeschwindigkeit auf einer CPU durch die Speicherbandbreite und nicht durch die Anzahl der Kerne bestimmt. Die Obergrenze ergibt sich aus einer Division: nutzbare Speicherbandbreite geteilt durch die Größe der Gewichte in Byte. Ein kleiner gemeinsam genutzter VPS erreicht über seine vCPUs realistisch 10 bis 25 GB pro Sekunde. Ein Modell mit 4.8 GB erreicht daher höchstens etwa 2 bis 5 Tokens pro Sekunde.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Das sind Bereiche, die häufig für gewöhnliche VPS-Hardware genannt werden, kein Benchmark eines bestimmten Systems. Ihr Wert hängt von der Speichergeneration, der Anzahl der Speicherkanäle auf dem Host und davon ab, wie viele Nachbarn um die Ressourcen konkurrieren. Messen Sie den Wert auf Ihrem eigenen System mit einem beliebigen Modell-Tag, das Sie bereits verwenden:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Die nach dem Ende der Antwort ausgegebene Zusammenfassung endet mit einer Zeile, die eval rate: ... tokens/s enthält. Das ist Ihre Generierungsgeschwindigkeit. Ignorieren Sie den ersten Durchlauf einer Sitzung, weil load duration in derselben Zusammenfassung auch das Lesen der Gewichte vom Datenträger umfasst. Tokens pro Sekunde korrekt messen beschreibt, wie Sie einen vergleichbaren Wert ermitteln.

Hier überraschen zwei Ergebnisse viele Nutzer. Das Hinzufügen weiterer vCPUs hilft schnell nicht mehr, weil die zusätzlichen Kerne ab ungefähr 8 Kernen auf den Speicher warten, statt Berechnungen auszuführen. Bei einem gemeinsam genutzten Tarif liefert derselbe Befehl außerdem von Stunde zu Stunde unterschiedliche Werte. Das ist CPU-Steal-Time durch einen ausgelasteten Nachbarn und kein Fehler in Ihrer Konfiguration.

Das Lesen Ihres Prompts ist eine andere Aufgabe als das Generieren der Antwort. Die Prompt-Verarbeitung ist rechengebunden. Sie skaliert daher mit der Anzahl der Kerne. Hier liegt eine GPU besonders deutlich vorn. Ein langes Dokument benötigt auf einer CPU Minuten zum Einlesen, auf einer GPU dagegen Sekunden. Das ist die erste Grenze, auf die Sie stoßen, wenn Sie einen Coding-Agent auf ein von Ihnen gehostetes Modell ansetzen. Denn bei jedem Durchlauf werden der Dateikontext und die Tool-Definitionen erneut gesendet, bevor auch nur ein Token der Antwort zurückkommt.

Was sich mit einer GPU ändert

Die Berechnung ändert sich nicht, nur der Pool, auf den sie angewendet wird. VRAM ist eine feste Grenze. Ermitteln Sie daher vor dem Mieten, was hineinpasst:

• 8 GB VRAM reichen für ein 7B- oder 8B-Modell mit 4 Bit und einem kurzen Kontext.
• 16 GB reichen für ein 14B-Modell mit 4 Bit und einem praxisnahen Kontext oder für ein 8B-Modell mit 8 Bit.
• 24 GB reichen für ein 32B-Modell mit 4 Bit, wenn der Kontext kurz bleibt.
• 48 GB und mehr reichen für ein 70B-Modell mit 4 Bit sowie zusätzlichem Platz für Cache und parallele Anfragen.

Wenn ein Modell nicht hineinpasst, teilt Ollama es auf: Einige Layer laufen auf der GPU, der Rest auf der CPU. ollama ps meldet diese Aufteilung in der Spalte PROCESSOR, beispielsweise als 78%/22% CPU/GPU. Betrachten Sie das als Warnung, nicht als Funktion. Die CPU-Hälfte bestimmt das Tempo, weil jedes Token weiterhin auf diese Layer wartet. Ein Modell, bei dem ein Viertel der Layer auf der CPU läuft, erreicht daher eher CPU- als GPU-Geschwindigkeit. Wenn eine nicht beabsichtigte Aufteilung angezeigt wird, verringern Sie zuerst die Kontextlänge. Meist war es der Cache, der die Grenze überschritten hat.

Parallelität ist ein weiterer Grund, größer zu dimensionieren. Die Gewichte werden zwischen gleichzeitigen Anfragen gemeinsam verwendet. Jede aktive Anfrage benötigt jedoch ihren eigenen KV-Cache. Zehn gleichzeitige Benutzer eines 8B-Modells mit 8k-Kontext benötigen daher zusätzlich zu den Gewichten das Zehnfache von 1 GB Cache. Gleichzeitige Benutzer mit einem selbst gehosteten Modell bedienen zeigt, wo diese Grenze liegt.

Ob sich das Mieten einer GPU lohnt, ist ebenfalls eine Rechenfrage. Entscheidend ist, wie viele Tokens Sie tatsächlich pro Monat erzeugen. Der Break-even zwischen einer GPU-VPS und API-Tokens enthält diese Zahlen.

Was Sie nicht selbst hosten können

Hier gibt es zwei unterschiedliche Grenzen. Es hilft, zu wissen, an welcher Sie gerade anstoßen.

Die erste Grenze sind geschlossene Gewichte. Kommerzielle Frontier-Modelle werden nicht veröffentlicht. Daher gibt es keine Datei zum Herunterladen, und mehr RAM ändert daran nichts. Sie können alles darum herum selbst hosten: die Benutzeroberfläche, die Retrieval-Schicht, die Agentenschleife und die Logs. Das Modell selbst bleibt eine entfernte API. Ob Sie Claude selbst hosten können erläutert das ausführlich.

Die zweite Grenze sind offene Gewichte, die schlicht zu groß sind. Die größten offenen Releases verwenden Mixture-of-Experts-Architekturen mit insgesamt Hunderten Milliarden Parametern. Für sie gilt dieselbe Regel: Ein Modell mit insgesamt 400B Parametern benötigt bei 4 Bit allein für die Gewichte etwa 240 GB, noch ohne Cache. Dafür ist spezialisierte Hardware erforderlich. Wenn Sie diese monatlich mieten, kostet das deutlich mehr, als die meisten Menschen innerhalb eines Jahres für API-Tokens ausgeben. Welche Voraussetzungen das Self-Hosting eines Modells der Kimi-Klasse erfordert erläutert den tatsächlichen Bedarf. Dieselbe Trennung zeigt sich auch in der eigenen Bibliothek von Ollama: GLM 5.2 ist dort nur als Cloud-Modell aufgeführt, während ein deutlich kleineres Schwestermodell tatsächlich auf einen VPS heruntergeladen werden kann.

Die klare Abgrenzung lautet: Hosten Sie selbst, wenn die Auslastung gleichmäßig ist und die Daten Ihren Server nicht verlassen sollen. Kaufen Sie Tokens, wenn die Auslastung stoßweise anfällt oder Sie tatsächlich die Antwortqualität eines Frontier-Modells benötigen.

Prüfen Sie die verfügbaren Ressourcen, bevor Sie sich entscheiden

free -h
nproc
lscpu | grep 'Model name'

Planen Sie anhand der Spalte available für free -h, nicht anhand der Spalte total, weil total auch den Speicher enthält, den das System bereits verwendet. Ziehen Sie etwa 1 GB für das Betriebssystem und den Model-Server ab. Teilen Sie den verbleibenden Wert durch 0.6, um die größte Parameteranzahl in Milliarden zu berechnen, die Sie mit 4 Bit speichern können. Ziehen Sie anschließend den KV-Cache für den tatsächlich gewünschten Kontext ab. Das verbleibende Ergebnis ist Ihre Antwort. Im Gegensatz zu einer Liste von Modellnamen veraltet es nicht.

FAQ

Wie viel RAM benötige ich für ein 8B-Modell?

Für die Gewichte bei einer 4-Bit-Quantisierung benötigen Sie etwa 4.8 GB. Hinzu kommen der KV-Cache für die gewünschte Kontextlänge sowie ungefähr 1 GB für das Betriebssystem und den Model-Server. Bei einem Kontext von 8192 Tokens benötigt der Cache zusätzlich etwa 1 GB. Damit ist ein Tarif mit 8 GB geeignet, ein Tarif mit 4 GB jedoch nicht. Wenn Sie den vom Model-Card angegebenen vollständigen Kontext von 128k nutzen möchten, benötigt der Cache allein 16 GB. Sie benötigen dann einen Tarif mit 32 GB.

Warum ist mein Modell langsam, obwohl der VPS genügend vCPUs hat?

Weil die Generierung durch die Speicherbandbreite und nicht durch die Anzahl der Kerne begrenzt wird. Für jedes Token muss der gesamte aktive Gewichtssatz aus dem RAM gelesen werden. Sobald einige Kerne die Speicherkanäle auslasten, warten die übrigen Kerne nur noch. Eine weitere häufige Ursache ist Swap. Wenn vmstat 1 während der Antwortgenerierung einen Wert ungleich null für si und so anzeigt, passen die Gewichte nicht in den RAM. Ein Teil jedes Tokens wird dann vom Datenträger bereitgestellt. Das ist deutlich langsamer, als die scheinbare Auslastung vermuten lässt.

Benötigt ein längeres Kontextfenster tatsächlich mehr Speicher?

Ja. Der Speicherbedarf wächst linear mit der Token-Anzahl. Ein typisches 8B-Modell benötigt etwa 128 KiB KV-Cache pro Token. 8192 Tokens benötigen daher 1 GB, 131072 Tokens dagegen 16 GB. Der Cache wird beim Laden des Modells reserviert und nicht erst, wenn die Konversation wächst. Ein Kontext von 128k reserviert diesen Speicher daher sofort, auch wenn jeder gesendete Prompt nur 200 Tokens lang ist.

Sollte ich ein großes Modell mit 2 Bit oder ein kleineres mit 4 Bit ausführen?

Verwenden Sie das kleinere Modell mit 4 Bit. Die Qualität sinkt von 8 Bit bis 4 Bit nur langsam, unterhalb von 4 Bit jedoch schnell. Ein auf 2 Bit komprimiertes 70B-Modell liefert daher normalerweise schlechtere Antworten als ein 32B-Modell mit 4 Bit aus derselben Modellgeneration. Starke Quantisierung zeigt sich eher durch Wiederholungen und nicht befolgte Anweisungen als durch eine Fehlermeldung. Dadurch lässt sich die Ursache leicht dem Prompt zuschreiben. Betrachten Sie 4 Bit als Untergrenze und ändern Sie stattdessen die Parameteranzahl.

Kann ich ein Modell selbst hosten, das ähnlich leistungsfähig wie die großen kommerziellen Modelle ist?

Nicht auf einem gewöhnlichen VPS. Die leistungsfähigsten Open-Weight-Modelle haben Hunderte Milliarden Parameter. Bei 4 Bit benötigen sie bereits mehr als 200 GB RAM, bevor der KV-Cache berücksichtigt wird. Die leistungsfähigsten kommerziellen Modelle werden überhaupt nicht verteilt. Gewöhnliche Hardware eignet sich gut dafür, ein gutes 8B- bis 32B-Modell für eine bestimmte Aufgabe auszuführen. Ein kleines, eng begrenztes und gut formuliertes Modell erreicht dabei oft die Leistung eines allgemeinen Modells. Wenn Sie Frontier-Qualität benötigen, vergleichen Sie die API-Kosten mit den Hardwarekosten, bevor Sie eine der beiden Optionen kaufen.