Welche KI-Modelle passen in Ihren RAM?

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 ausreichender Reserve in den Speicher passen. Dieser Beitrag beschreibt die dafür erforderlichen Berechnungen. Die Installation einer Runtime ist eine separate Aufgabe. Sie wird in der Anleitung zum Betrieb von Ollama auf einem VPS beschrieben.

Zwei Speicheranforderungen bestimmen die Antwort. Die Gewichte sind die festen Kosten. Sie werden durch die Parameteranzahl und die Quantisierung festgelegt. Das Kontextfenster verursacht laufende Kosten. Diese werden häufig erst bemerkt, wenn ein Modell, das gestern noch geladen wurde, 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 als der Trainingspräzision zu speichern. Dadurch sinkt die Genauigkeit geringfügig, während der Speicherbedarf stark abnimmt. 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 betreibt fast niemand die veröffentlichte Präzision auf einem VPS. Diese Quantisierungen werden Sie tatsächlich antreffen, mit ihrer realen durchschnittlichen Bitzahl 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.
• Q5_K_M speichert etwa 5.7 Bit, also ungefähr 0.71 GB pro Milliarde.
• Q4_K_M speichert etwa 4.8 Bit, also ungefähr 0.6 GB pro Milliarde.

Verwenden Sie 0.6 GB pro Milliarde Parameter als Richtwert. Q4_K_M ist die sinnvolle Standardeinstellung auf einem System mit knappem Arbeitsspeicher: Der Qualitätsverlust gegenüber 8 Bit ist bei den meisten Aufgaben gering, und die Datei ist nahezu halb so groß. Unterhalb von 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 Modellklasse, 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 Gewichtsspalte 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 benötigt 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 im aktuellen Gespräch speichert) ist der zweite Kostenfaktor. Er wird beim Laden des Modells reserviert, anhand der angeforderten Kontextlänge dimensioniert und wächst linear mit dieser Länge.

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

Bei Ollamas standardmäßiger Kontextlänge belegt dieses 8B-Modell einen halben Gigabyte für den Cache. Bei 8192 Tokens belegt es 1 GB. Bei der vom Modell-Card angegebenen Kontextlänge von 128k 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 selbst. Grouped Query Attention verhindert, dass die Kosten pro Token annähernd so schnell wachsen wie die Anzahl der Parameter.

Ollamas standardmäßige Kontextlänge beträgt auf einem Server, der nur die CPU verwendet, 4096 Tokens. Ist eine GPU vorhanden, wählt Ollama den Standardwert stattdessen anhand des VRAM: 32k bei 24 bis 48 GiB und 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 zur Kontextlänge erläutert.

Es gibt zwei Möglichkeiten, den Cache wieder zu verkleinern. Fordern Sie die benötigte Kontextlänge an und nicht die vom Modell-Card angegebene Länge, da die meisten Chat- und Coding-Aufgaben mit 8k bis 32k auskommen. Oder quantisieren Sie den Cache selbst auf 8 Bit. Dadurch halbiert sich seine Größe, allerdings kann die Erinnerung an Inhalte in 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 danach. Dieser Standardwert passt für einen Laptop, ist aber für einen Server ungeeignet. Dort verursacht die erste Anfrage nach jeder Leerlaufphase erneut die Ladezeit.

ollama ps
ollama stop qwen3:4b

ollama ps zeigt, welche Modelle resident sind. Die Spalte SIZE gibt an, wie viel Speicher ein Modell belegt. Die Spalte UNTIL zeigt, wann es abläuft. Um ein Modell dauerhaft im Speicher zu halten, setzen Sie OLLAMA_KEEP_ALIVE=-1 am Dienst. Der Wert 0 entlädt das Modell, sobald jede 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 Eingabeaufforderung und führen Sie ollama ps zehn Minuten später erneut aus. Das Modell wird weiterhin aufgeführt. 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 für das Modell plus Ihre Anwendung, nicht nur für das Modell. Ein Modell im Speicher festhalten beschreibt den Kompromiss gegenüber der Latenz eines Kaltstarts.

Was auf einem 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 Größenklasse. Betrachten Sie diese Angaben als Beispiele für die Größe, nicht als Empfehlungen. Die Modellnamen ändern sich alle paar Monate. Die Berechnung bleibt gleich.

Rechnen Sie mit ungefähr 6 bis 14 Token pro Sekunde. Solche kleinen Modelle eignen sich gut für eng umrissene Aufgaben: Klassifizierung, Extraktion von Tags, kurze Zusammenfassungen und die Anpassung eines Absatzes an einen vorgegebenen Schreibstil. Bei mehrstufigem Reasoning und bei Code, der sich über mehrere Dateien erstreckt, sind sie schwach. Das lässt sich durch Prompting nicht beheben.

Der typische Fehler in dieser Größenklasse ist die Auslagerung. Wenn das Modell nicht in den Arbeitsspeicher passt, verweigert Linux das Laden nicht. Stattdessen lagert es Speicher auf die Festplatte aus. Da für jedes generierte Token alle Gewichte einmal gelesen werden, sinkt die Generationsgeschwindigkeit auf mehrere Sekunden pro Token. Beobachten Sie free -h sowie die Spalten si und so von vmstat 1, während das Modell antwortet. Werte ungleich null für 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 nutzbar. Auf 8 GB können Sie ein 7B- oder 8B-Modell mit 4 Bit und etwa 4.8 GB Gewichten bei einem 8k-Kontext 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 verwenden, wenn Sie den Speicher lieber für höhere Präzision als für eine größere Parameteranzahl einsetzen.

Der Engpass ist die Geschwindigkeit. Ein 8B-Modell erzeugt auf der CPU etwa 3 bis 7 Tokens pro Sekunde. Ein 14B-Modell erzeugt etwa 1.5 bis 3.5 Tokens pro Sekunde. Menschen lesen ungefähr 5 bis 10 Tokens pro Sekunde. Ein 8B-Modell auf einem CPU-VPS fühlt sich daher wie ein langsamer Schreibautomat an. Für einen Hintergrundprozess ist das in Ordnung, für einen interaktiven Chat wird es anstrengend. Gemessene Durchläufe von Qwen 3 mit 8B und größeren Modellen auf einem VPS zeigen, wie das in der Praxis aussieht.

Was auf einer VPS mit 32 bis 64 GB 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 GB oder 64 GB problemlos. Ein 70B-Modell mit 4 Bit benötigt etwa 42 GB. Damit braucht es 64 GB, bevor überhaupt Cache hinzukommt.

Betrachten Sie anschließend die Geschwindigkeit realistisch. Ein 32B-Modell auf der CPU erreicht etwa 0.6 bis 1.5 Token pro Sekunde. Ein 70B-Modell erreicht 0.2 bis 0.5 Token pro Sekunde. Eine Antwort mit 500 Token benötigt bei diesem 70B-Modell etwa zwanzig Minuten. Diese Modelle eignen sich für Stapelverarbeitung. Sie können ihnen über Nacht eine Warteschlange mit Dokumenten übergeben. Dann spielt die Geschwindigkeit keine große Rolle. Hinter einer Chat-Oberfläche ist sie dagegen sehr wichtig.

Mixture-of-Experts-Routing verändert diese Berechnung. Es ist das einzige Architekturdetail, das Sie sich genauer ansehen sollten. Ein MoE-Modell verarbeitet jedes Token nur mit einem 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 Ausgaben nahezu mit der Geschwindigkeit eines dichten 3B-Modells. Der Grund ist, dass jedes Token nur die aktiven Experten abruft. Auf einem System mit 32 GB 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. Deshalb 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 Shared-VPS erreicht über seine vCPUs realistisch 10 bis 25 GB pro Sekunde. Ein Modell mit 4.8 GB erreicht damit 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. Es handelt sich nicht um einen Benchmark für eine bestimmte Maschine. Ihr Wert hängt von der Speichergeneration, der Anzahl der Speicherkanäle auf dem Host und der Anzahl der Nachbarn ab, die um die Bandbreite konkurrieren. Messen Sie Ihren eigenen Wert 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 Lauf 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 von vCPUs bringt schnell keinen weiteren Vorteil, weil die zusätzlichen Kerne ab ungefähr 8 Kernen auf den Speicher warten, statt Berechnungen auszuführen. Bei einem Shared-Tarif liefert derselbe Befehl außerdem je nach Stunde unterschiedliche Werte. Das liegt an der CPU-Steal-Time durch einen ausgelasteten Nachbarn und nicht an einer fehlerhaften 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. In diesem Bereich liegt eine GPU am deutlichsten vorn. Eine CPU benötigt Minuten, um ein langes Dokument zu lesen. Eine GPU benötigt dafür Sekunden. Diese Grenze erreichen Sie zuerst, wenn Sie einen Coding-Agent auf ein von Ihnen gehostetes Modell ansetzen, weil bei jeder Runde der Dateikontext und die Tool-Definitionen erneut gesendet werden, bevor auch nur ein Antwort-Token zurückkommt.

Was sich beim Hinzufügen einer GPU ändert

Die Berechnung ändert sich nicht, nur der Speicherpool, auf den sie angewendet wird. VRAM ist eine harte 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 praxisgerechten 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 und zusätzlichem Spielraum 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 seiner Spalte PROCESSOR, zum Beispiel 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, arbeitet daher wesentlich näher an der CPU-Geschwindigkeit als an der GPU-Geschwindigkeit. Wenn Sie eine nicht beabsichtigte Aufteilung sehen, verringern Sie zuerst die Kontextlänge. Meist hat der Cache den Ausschlag gegeben.

Parallelität ist ein weiterer Grund, die Kapazität größer zu dimensionieren. Die Gewichte werden zwischen gleichzeitigen Anfragen gemeinsam genutzt. Jede aktive Anfrage benötigt jedoch einen eigenen KV-Cache. Zehn gleichzeitige Benutzer eines 8B-Modells mit einem Kontext von 8k 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 Obergrenze 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 einem GPU-VPS und API-Tokens enthält diese Zahlen.

Was Sie nicht selbst hosten können

Hier gibt es zwei verschiedene Grenzen. Es ist hilfreich zu wissen, an welcher Sie scheitern.

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 um diese Modelle herum selbst hosten: die Oberfläche, die Retrieval-Schicht, die Agenten-Schleife und die Logs. Das Modell selbst bleibt eine entfernte API. Ob Sie Claude selbst hosten können erläutert das vollständig.

Die zweite Grenze sind Open Weights, 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 Spezialhardware erforderlich. Die monatliche Miete dafür kostet deutlich mehr, als die meisten Menschen in einem Jahr für API-Tokens ausgeben. Welche Voraussetzungen das Self-Hosting eines Modells der Kimi-Klasse erfordert beschreibt den tatsächlichen Bedarf.

Die ehrliche Grenze zwischen beiden Fällen lautet: Hosten Sie selbst, wenn die Auslastung konstant ist und die Daten Ihren Server nicht verlassen sollen. Kaufen Sie Tokens, wenn die Auslastung stark schwankt oder Sie tatsächlich die Antwortqualität eines Frontier-Modells benötigen.

Prüfen Sie Ihre Ressourcen vor der Auswahl

free -h
nproc
lscpu | grep 'Model name'

Planen Sie anhand der Spalte available von free -h, nicht anhand der Spalte total, da 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. Das Ergebnis ist die maximale Parameteranzahl in Milliarden, die Sie bei 4 Bit unterbringen können. Ziehen Sie anschließend den KV-Cache für den tatsächlich gewünschten Kontext ab. Der verbleibende Wert ist Ihre Antwort. Im Gegensatz zu einer Liste mit Modellnamen veraltet er nicht.

FAQ

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

Für die Gewichte bei 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 funktioniert ein Tarif mit 8 GB, 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 über viele vCPUs verfügt?

Die Generierung wird durch die Speicherbandbreite begrenzt, nicht durch die Anzahl der Kerne. 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. Eine weitere häufige Ursache ist Swap. Wenn vmstat 1 während der Antwort des Modells 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 gelesen. Das ist deutlich langsamer, als es zunächst den Anschein hat.

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

Ja. Der Speicherbedarf steigt 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, während 131072 Tokens 16 GB benötigen. 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 von Ihnen gesendete Prompt nur 200 Tokens lang ist.

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

Verwenden Sie das kleinere Modell mit 4 Bit. Die Qualität nimmt von 8 Bit bis 4 Bit nur langsam und unterhalb von 4 Bit schnell ab. 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 das Problem leicht fälschlicherweise Ihrem Prompt zuschreiben. Betrachten Sie 4 Bit als Untergrenze und ändern Sie stattdessen die Parameteranzahl.

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

Nicht auf einem gewöhnlichen VPS. Die leistungsfähigsten Open-Weight-Modelle verfügen über 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 für ein gutes 8B- bis 32B-Modell für eine bestimmte Aufgabe. Ein kleines, eng abgegrenztes und gut promptendes Modell kann dabei häufig mit einem allgemeinen Modell mithalten. Wenn Sie Frontier-Qualität benötigen, vergleichen Sie die API-Kosten mit den Hardwarekosten, bevor Sie sich für eine der beiden Optionen entscheiden.