Welcher VPS für KI: API oder Modell auf dem eigenen Server

Zwei Anforderungen, zwei Servergrößen

Die meisten Anwendungen, die „KI nutzen“ (Assistenten, Agenten, Zusammenfassungen, Datenextraktion, Suche in Dokumenten), rufen über eine API ein Modell auf, das sein Anbieter hostet. Gerechnet wird dort; Ihr Server bereitet die Anfrage vor, wartet auf die Antwort und verarbeitet sie. Er wird dann bemessen wie jede andere Webanwendung: nach seiner Sprache, seiner Datenbank und der Zahl gleichzeitiger Nutzer.

Der andere Fall ist das Modell, das auf dem Server selbst läuft, mit Ollama, llama.cpp oder einer Python-Bibliothek. Die Gründe sind bekannt: Daten, die auf Ihrer Infrastruktur bleiben, feste Kosten unabhängig von der Zahl der Anfragen, Hintergrundverarbeitung großer Datenmengen, ein spezialisiertes Modell. Dann muss das ganze Modell in den Arbeitsspeicher passen, und es bestimmt die Größe.

Per API: die Anwendung bemessen, nicht das Modell

Eine Anfrage an ein Modell per API dauert eine bis mehrere zehn Sekunden, vor allem wenn die Antwort fortlaufend übertragen wird (Streaming). In dieser Zeit rechnet Ihr Server fast nichts: er wartet. Entscheidend ist seine Fähigkeit, viele Anfragen in Wartestellung zu halten, ohne die übrigen zu blockieren:

• Ein asynchroner Server: Node.js, FastAPI mit Uvicorn oder asynchrone Gunicorn-Worker. Ein synchroner Worker, der 20 Sekunden auf eine Antwort wartet, ist für alle anderen Besucher blockiert.
• Eine Job-Queue für lange Verarbeitungen (Zusammenfassung eines Dokuments, Analyse eines Stapels): die Anfrage des Besuchers kehrt sofort zurück, ein Worker arbeitet im Hintergrund.
• Passend eingestellte Timeouts am Proxy: Nginx bricht standardmäßig eine Antwort ab, die länger als 60 Sekunden stumm bleibt (proxy_read_timeout).

Einzuplanen ist der Arbeitsspeicher der Anwendung und ihrer Datenbank: 4 GB decken eine Python- oder Node.js-Anwendung mit PostgreSQL zum Start ab. Eine gängige Konfiguration, ein Next.js-Frontend, eine FastAPI-Schnittstelle und eine PostgreSQL-Datenbank, die ein Modell per API aufrufen, passt in 6 bis 8 GB, den Build des Frontends inklusive.

Embeddings und Vektorsuche: der Speicher der Vektoren

Eine Anwendung, die in Ihren Dokumenten sucht (RAG, Retrieval-Augmented Generation), verwandelt jeden Abschnitt in einen Vektor und findet dann die, die einer Frage am nächsten liegen. Zwei Posten sind zu bemessen:

• Das Embedding-Modell, wenn es bei Ihnen läuft: gängige Modelle wiegen 100 MB bis 1,5 GB und rechnen problemlos auf dem Prozessor. all-MiniLM-L6-v2 zum Beispiel belegt weniger als 100 MB.
• Die Vektoren: mit pgvector belegt ein Vektor 4 Byte pro Dimension, plus 8. Eine Million Abschnitte mit 1.536 Dimensionen ergeben etwa 6 GB Daten, dazu kommt der HNSW-Index, der die Suche beschleunigt. Für schnelle Suchen müssen der Index und die abgefragten Vektoren in den Arbeitsspeicher passen.

Der Typ halfvec von pgvector speichert jede Dimension in 2 Byte statt 4: halber Speicherbedarf, bei einer Suchqualität, die sehr nahe bleibt.

Ein Modell auf dem Server: zuerst der Arbeitsspeicher

Ein Sprachmodell ist eine Datei mit Gewichten, die zum Antworten vollständig in den Arbeitsspeicher geladen wird. Ihre Größe hängt von der Zahl der Parameter und von der Quantisierung ab, der Genauigkeit, mit der jedes Gewicht gespeichert wird. Das GGUF-Format, das llama.cpp und Ollama verwenden, bietet Quantisierungen von 2 bis 16 Bit; die Variante Q4_K_M, um 4 Bit, ist der übliche Kompromiss zwischen Größe und Qualität.

Zu diesem Gewicht kommen zwei Posten hinzu:

• Der Kontext (der KV-Cache): jedes Token der laufenden Unterhaltung belegt Speicher. Für Llama 3.1 8B rechnen Sie mit etwa 128 KB pro Token bei 16-Bit-Genauigkeit, also 1 GB für einen Kontext von 8.000 Token, und ebenso viel für jede parallel verarbeitete Unterhaltung.
• Der Rest des Servers: System, Anwendung, Datenbank, wie bei jeder Webanwendung.

Beispiel. Llama 3.1 8B in 4 Bit, zwei gleichzeitige Unterhaltungen mit 8.000 Token und eine kleine Anwendung: 5 GB Modell, 2 GB Kontext, 2 GB für Anwendung und System, also 9 GB, und etwa 12 GB mit 25 % Reserve.

Auf dem Prozessor: was die Geschwindigkeit bestimmt

Um jedes Token zu erzeugen, liest das Modell alle seine Gewichte erneut aus dem Arbeitsspeicher. Auf dem Prozessor ist die Generierungsgeschwindigkeit daher eher durch die Speicherbandbreite begrenzt als durch die Zahl der Kerne: ein Modell von 5 GB kommt auf einer Maschine, die 25 GB pro Sekunde liest, auf höchstens etwa 5 Token pro Sekunde, noch bevor die Rechenzeit hinzukommt.

Zwei Phasen unterscheiden sich:

• Das Lesen der Frage (Prompt Processing) ist rechenintensiv: mehr vCPU machen es schneller, was bei langen Dokumenten zählt.
• Das Erzeugen der Antwort hängt vor allem von der Speicherbandbreite und der Modellgröße ab: ein halb so großes Modell antwortet etwa doppelt so schnell.

In der Praxis erzeugt ein Modell mit 7 bis 8 Milliarden Parametern in 4-Bit-Quantisierung auf einigen vCPU ein paar Token pro Sekunde. Das ist komfortabel für Hintergrundverarbeitung (Nachrichten einordnen, Felder aus einem Dokument extrahieren, nachts zusammenfassen, was tagsüber eingegangen ist) und für einen internen Assistenten. Interaktive Anwendungen in großem Maßstab und Modelle mit mehreren zehn Milliarden Parametern laufen auf Grafikkarten (GPU).

Die Messung entscheidet: llama-bench, das llama.cpp beiliegt, ermittelt die Geschwindigkeit beider Phasen auf Ihrem Server, für Ihr Modell.

llama-bench -m modell-Q4_K_M.gguf -p 512 -n 128

Die Festplatte: die Modelle, ihre Versionen, die Vektoren

Ein Modell belegt auf der Festplatte ungefähr so viel wie im Arbeitsspeicher: 5 GB für ein Modell mit 8 Milliarden Parametern in 4 Bit. Planen Sie Platz für zwei oder drei Modelle oder Versionen, die Vektorindizes, die Quelldokumente und die Datenbank ein. Eine NVMe-SSD lädt ein Modell beim Start des Dienstes in wenigen Sekunden, was bei jedem Neustart zählt.

Als Größenordnung: 50 GB für eine Anwendung, die ein Modell per API aufruft, 80 bis 120 GB, sobald ein Modell und seine Dokumente auf dem Server liegen.

Sicher einrichten

Mit Ollama gelingt der Start mit zwei Befehlen:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b

Ollama lauscht standardmäßig auf 127.0.0.1:11434, also nur vom Server selbst aus. Behalten Sie diese Einstellung bei: seine API verlangt keine Authentifizierung, und eine zum Internet offene Instanz bedient jeden, auf Kosten Ihrer Ressourcen. Ihre Anwendung auf demselben Server spricht lokal mit ihm; muss ein anderer Server es abfragen, gehen Sie über einen Proxy, der die Anfragen authentifiziert, oder über ein privates Netzwerk.

Stellen Sie anschließend die Kontextgröße (num_ctx) auf das ein, was Ihre Anfragen brauchen: sie ist es, die den belegten Speicher wachsen lässt, Unterhaltung für Unterhaltung.