Code-Completion-Server on-premise: kleine FIM-Modelle, Latenz und GPUs für Entwicklerteams

Vervollständigung ist eine eigene Last

Ein Code-Completion-Server für 100 bis 500 Entwickler betreibt ein kleines Fill-in-the-Middle-Modell (FIM) mit 1,5B bis 7B Parametern auf wenigen kleinen GPUs, getrennt von den Chat- und Agentenmodellen. Nach unserer Schätzung deckt ein 2U-Server mit vier NVIDIA RTX PRO 4500 Blackwell Server Edition die Spitzenzeit einiger hundert Entwickler ab, mit einem Modell der 1,5B-Klasse und kurzen Prompts.

Dimensioniert wird der Server danach, wie viele Anfragen pro Sekunde er innerhalb eines Latenzziels beantwortet; der Speicher ist selten die Grenze. Nach unserer Rechnung aus veröffentlichten Messungen startet eine RTX PRO 4500 Server Edition höchstens rund 10 Anfragen pro Sekunde für ein 4B-Modell mit Prompts von 1.024 Token.

Die Vervollständigung ergänzt Code, während jemand tippt. Die IDE-Erweiterung schickt den Code vor und nach dem Cursor, das Modell schreibt den Teil dazwischen, und der Vorschlag nützt nur, wenn er erscheint, bevor weitergetippt wird. Unser Leitfaden zum privaten Coding-Assistenten trennt die drei Lasten beim Programmieren und behandelt Chat und Agenten; unsere Seite zum Server für Coding-Agenten dimensioniert Agenten, deren Prompts auf Zehntausende Token anwachsen. Diese Seite behandelt die dritte Last.

Unsere Zusammenfassung der Lasten, wie in unseren Leitfäden zum Coding-Assistenten und zu Coding-Agenten beschrieben; Prompt- und Antwortlängen sind typische Größenordnungen, keine Messungen.

Modelle, die für Fill-in-the-Middle trainiert sind

Ein Vervollständigungsmodell muss für das FIM-Promptformat trainiert sein: Präfix, Suffix und eine Markierung für die Mitte. Die Erweiterung Continue, zitiert in unserem Leitfaden zum Coding-Assistenten, hält fest: „Most of the state-of-the-art autocomplete models are no more than 10b parameters“, und schlägt für den lokalen Einsatz Qwen2.5-Coder 1.5B vor.

Modellkarten, config.json-Dateien und Dateilisten auf Hugging Face (Summe der Safetensors-Dateien), gelesen am 24. Oktober 2026. Qwen2.5-Coder-7B: volle 131.072 Token mit YaRN, 32.768 in der Standardkonfiguration.

JetBrains beschreibt Mellum-4b-base als „tailored for code completion“, mit FIM-Prompts aus den Markierungen <fim_suffix>, <fim_prefix> und <fim_middle>; die Karte weist darauf hin, dass es ein Basismodell ist, das weiteres Fine-Tuning unterstützt, und eine Python-SFT-Variante ist veröffentlicht. Die Karten der Qwen2.5-Coder-Basismodelle empfehlen die Modelle für „fill in the middle tasks“ statt für Konversation. Qwen hält fest, dass FIM „is supported in every version of Qwen3-Coder“, wie unser Leitfaden zum Coding-Assistenten zitiert; das 30B-A3B-Modell kann also auf einer größeren Karte Chat und Vervollständigung aus einer Kopie bedienen.

Das neueste offene Modell von JetBrains, Mellum2.1-12B-A2.5B-Thinking, ist ein anderer Modelltyp. Seine Karte nennt es „a thinking model“ für agentische Arbeit in Repositorys und für schwierige Aufgaben in Programmierung, Mathematik und logischem Denken, und sie erwähnt Fill-in-the-Middle nicht. Betrachten Sie es als Kandidaten für Chat oder Agenten, nicht für die Inline-Vervollständigung. Zwei Modelle, die bei denselben Suchen auftauchen, haben Lizenzgrenzen: Qwen2.5-Coder-3B ist nur für nicht kommerzielle Nutzung lizenziert und Codestral 22B nur für den Einsatz außerhalb der Produktion, wie unser Leitfaden zum Coding-Assistenten darlegt.

Wie schnell ein Vorschlag sein muss

Die Wartezeit am Editor ist die Zeit bis zum ersten Token (TTFT) plus das Erzeugen des restlichen Vorschlags. TTFT umfasst Warteschlange und Einlesen des Prompts, wie unser Leitfaden zu LLM-Latenzzielen mit NVIDIAs Begriffen definiert. Für die Vervollständigung verwenden wir diese Beispielziele beim 95. Perzentil, unsere Werte für eine Dimensionierung und kein Standard: erstes Token innerhalb von 200 ms und ein vollständiger Vorschlag von rund 32 Token innerhalb von 600 ms, gemessen am Server.

StorageReview hat am 24. September 2026 Werte für einen einzelnen Nutzer mit einem kleinen dichten Modell auf beiden kleinen Rechenzentrumskarten veröffentlicht: Qwen3.5-4B in BF16 mit vLLM 0.24.0 in einem HPE ProLiant DL145 Gen11 mit einem AMD EPYC 8534P.

StorageReview, Edge-Review der RTX PRO 4500 im HPE ProLiant DL145 Gen11, 24. September 2026, gelesen am 24. Oktober 2026; TTFT von der kürzesten bis zur längsten Anfrageform (bis 1.024 Prompt-Token), Zeit je Token bei 256 Token Ein- und Ausgabe. Letzte Spalte: unsere Rechnung, längste TTFT plus 31 weitere Token.

Bei einem Nutzer erreicht die RTX PRO 4500 Server Edition das Beispielziel mit einem 4B-Modell, die L4 nicht. Ein kleineres Modell verkürzt beide Teile: Qwen2.5-Coder-1.5B hat 3,09 GB Gewichte gegenüber 8,04 GB bei Mellum-4b-base, und jedes erzeugte Token liest die Gewichte einmal.

Unsere Rechnung: Speicherbandbreite (300, 672 und 800 GB/s laut NVIDIAs Spezifikationen) ÷ je Token gelesene Gewichts-Bytes, eine Anfrage. Nach unserer Schätzung Obergrenzen; die gemessenen 12,4 ms je Token des 4B-Modells auf der 4500 Server Edition entsprechen 81 Token pro Sekunde.

Nach diesen Obergrenzen braucht ein 7B-Modell in BF16 für 31 Token mindestens 0,6 s auf einer RTX PRO 4500 Server Edition und 1,6 s auf einer L4, zusätzlich zum Einlesen des Prompts. Für eine L4-Flotte ist die 1,5B-Klasse die realistische Wahl; auf der RTX PRO 4500 Server Edition erreichen Modelle bis rund 4B das Beispielziel, und ein 7B-Modell passt dort, wo Vorschläge kürzer sind oder eine langsamere Antwort genügt.

Anfragen pro Sekunde: Das Einlesen des Prompts setzt die Grenze

Unter Last verbringt die Karte die meiste Zeit mit dem Einlesen von Prompts. StorageReviews Test enthält eine Anfrageform nahe an der Vervollständigung, 1.024 Prompt-Token und 32 Ausgabe-Token. Bei 32 gleichzeitigen Anfragen lieferte die RTX PRO 4500 Server Edition damit 11 Ausgabe-Token pro Sekunde je Nutzer, gegenüber 44 bis 53 bei den anderen Formen, und die L4 4,6, gegenüber 10 bis 18.

Aus den Werten für einen Nutzer folgt: Die RTX PRO 4500 Server Edition las 1.024 Prompt-Token in 99 ms, rund 10.000 Token pro Sekunde, die L4 in 219 ms, rund 4.700. Nach dieser Rechnung kann eine Karte höchstens rund 10 Vervollständigungs­anfragen zu 1.024 Token pro Sekunde starten und eine L4 rund 4,6. Der Lasttest stimmt damit überein: 32 Anfragen mit 11 Token pro Sekunde für 32 Token ergeben auf der 4500 rund 11 Anfragen pro Sekunde, auf der L4 4,6. Jede dieser Anfragen dauerte dann aber rund 3 Sekunden auf der 4500 und 7 auf der L4, weit außerhalb jedes Ziels für Vervollständigung; die innerhalb eines Latenzziels nutzbare Rate liegt also niedriger. Das sind unsere Ableitungen aus einem allgemeinen 4B-Modell; ein 1,5B-Modell liest einen Prompt nach Parameterzahl mit rund 40 Prozent des Rechenaufwands, was ein Test bestätigen muss.

Drei Stellschrauben bewegen die Rate stärker als die Karte:

1. Prompt-Länge. Die Erweiterung legt fest, wie viel Code rund um den Cursor sie schickt. Der halbe Prompt ist rund die halbe Einlesearbeit.
2. Prefix Caching. Aufeinanderfolgende Anfragen aus derselben Datei beginnen mit fast denselben Token, und das in vLLM standardmäßig aktive Prefix Caching nutzt bereits berechnete Blöcke wieder, solange sie im Speicher liegen. Wird jeder Entwickler zur selben Kopie geleitet, bleiben diese Blöcke auf einer Karte. Messen Sie die Trefferquote des Caches in einem Pilotbetrieb.
3. Modellgröße. Der Wechsel von einem 7B- auf ein 1,5B-Modell senkt Einlese- und Erzeugungsarbeit nach Parameterzahl auf rund ein Viertel bis ein Fünftel.

Zählen Sie für die Abschätzung Anfragen pro Sekunde. Als Beispielwerte, die Sie durch die Protokolle Ihres Gateways ersetzen: Tippen in der Spitzenzeit 20 Prozent von 500 Entwicklern und erzeugt jeder alle zwei Sekunden eine Anfrage, sind das 50 Anfragen pro Sekunde. Mit dem Planwert von rund der Hälfte der Obergrenze von 10 Anfragen für ein 4B-Modell sind das zehn Karten RTX PRO 4500 Server Edition, oder weniger mit einem 1,5B-Modell, kürzeren Prompts und einer guten Trefferquote des Prefix Caches. Wir dimensionieren Completion-Server aus Ihren Anfrageprotokollen und Ihrer Ziellatenz; schicken Sie uns die Zahl der Entwickler, die IDE-Erweiterung und die heutige Anfragerate, und unser Team antwortet mit Kartenzahl und Aufteilung.

Speicher je Karte und MIG-Hälften

Der KV-Cache je Vervollständigungsanfrage ist klein. Mit Schichten, KV-Heads und Head-Größe aus der jeweiligen config.json belegt eine Anfrage mit 2.048 Token bei Qwen2.5-Coder-1.5B 56 MiB und bei Qwen2.5-Coder-7B 112 MiB in 16 Bit. Mellum-4b-base nutzt volle Multi-Head-Attention, 24 KV-Heads in jeder der 30 Schichten, dieselbe Anfrage belegt dort 720 MiB.

Unsere Schätzungen nach der Regel für Nutzer je Karte, keine Messungen: gleichzeitige Anfragen zu 2.048 Token mit 16-Bit-KV-Cache, nutzbarer Speicher je Karte 17,2 GiB (L4, ECC an), 18,5 GiB (RTX PRO 4000) und 25,7 GiB (RTX PRO 4500 Server Edition) wie auf unseren Konfigurationsseiten.

Unsere Regel für Nutzer je Karte nimmt 90 Prozent des Speichers, den der Treiber meldet, und zieht je Karte 3 GiB für die Laufzeitumgebung ab; der Rest nimmt Gewichte und Cache auf, wie unser Leitfaden Wie viele Nutzer schafft eine RTX PRO 6000? herleitet. Bei den 1,5B- und 7B-Modellen fasst der Speicher weit mehr Anfragen, als die Karte rechtzeitig verarbeiten kann. Mellum-4b-base ist die Ausnahme: Mit 8K Kontext und vollem Cache verdoppelt ein FP8-Cache seine Zahl auf rund 51 Anfragen je RTX PRO 4500 Server Edition.

Die RTX PRO 4500 Server Edition lässt sich in zwei MIG-Instanzen zu 16 GB teilen, jede mit der Hälfte des Speichers und der Streaming-Multiprozessoren, wie unsere Seite zu vier RTX PRO 4500 Server Edition in 2U beschreibt. Ein 1,5B-Modell passt bequem in eine Hälfte, eine Karte kann also zwei unabhängige Engines betreiben, etwa die Vervollständigung für zwei Teams oder eine Produktions- und eine Testkopie. L4 und RTX PRO 4000 haben kein MIG.

Server für 100 bis 500 Entwickler

Die Vervollständigung skaliert über Kopien: eine Kopie je Karte oder je MIG-Hälfte, ein Load Balancer oder das Gateway verteilt die Anfragen. Keine Kopie wird auf mehrere Karten aufgeteilt, zwischen den Karten läuft also nichts über PCIe.

Unsere Schätzungen wie auf unseren Konfigurationsseiten zu vier und acht RTX PRO 4500 Server Edition, acht L4 und vier RTX PRO 4000: Leistungsaufnahme der Karten plus Prozessoren plus 15 Prozent für den Rest. Eine Messung am gelieferten System bestätigt sie.

Nach der Ableitung oben starten vier RTX PRO 4500 Server Edition mit einem 4B-Modell und Prompts von 1.024 Token bis zu rund 40 Anfragen pro Sekunde, acht L4 rund 37. Der L4-Server erreicht diesen Wert mit doppelt so vielen Karten und mit 1,3 Sekunden oder mehr je Vorschlag von 32 Token; für die Vervollständigung dimensionieren wir L4-Server deshalb mit Modellen der 1,5B-Klasse. Die RTX PRO 4500 Server Edition ist passiv gekühlt und läuft nur in einem Server, dessen Hersteller sie führt; unsere Seite zum Server mit 8× RTX PRO 4500 Server Edition nennt Gehäuse und Strom, und unsere Benchmarks der RTX PRO 4500 sammeln die veröffentlichten Ergebnisse.

Laufen Agenten neben der Vervollständigung, bekommt die Vervollständigung eigene Karten. Ein Agentenschritt mit einem Prompt von 32K Token belegt eine Karte für Sekunden, und eine Vervollständigungsanfrage, die dahinter wartet, verfehlt ihr Ziel. Ein Server mit vier RTX PRO 6000 Server Edition für Agenten und ein eigener Server mit vier RTX PRO 4500 Server Edition für die Vervollständigung halten beides getrennt, und unser Leitfaden zum Betrieb mehrerer Modelle auf einem GPU-Server behandelt Engines, die sich eine Maschine teilen.

Engines, Endpunkte und Messung

vLLM betreibt ein Modell je Instanz und stellt einen OpenAI-kompatiblen Completions-Endpunkt bereit; die Erweiterung baut den FIM-Prompt im Format des jeweiligen Modells. llama-server hat einen /infill-Endpunkt für FIM, und Ollama nimmt an seinem Completions-Endpunkt ein Suffix an, wie unser Leitfaden zum Coding-Assistenten mit den Mindestversionen festhält, die aktuelle Sicherheitshinweise beheben. Stellen Sie ein Gateway mit Schlüsseln und Protokollierung davor, wie in unserem Leitfaden zum LLM-Gateway mit Schlüsseln, Budgets und Protokollierung; seine Protokolle liefern die Anfragerate und Prompt-Länge, die Sie für die Dimensionierung brauchen.

Spekulatives Decoding verkürzt das Erzeugen für einen Nutzer und hilft am wenigsten, wenn eine Karte mit dem Einlesen von Prompts ausgelastet ist; unser Artikel zu Speculative Decoding on-premise erklärt, wann es sich lohnt. So messen Sie Ihren eigenen Server:

1. Zeichnen Sie einen Tag Vervollständigungs­anfragen am Gateway auf: Prompt-Länge, Antwortlänge und Zeitstempel.
2. Spielen Sie sie mit vllm bench serve bei steigenden Anfrageraten erneut ab.
3. Lesen Sie TTFT und Gesamtlatenz beim 95. Perzentil sowie die Trefferquote des Prefix Caches ab.
4. Nehmen Sie die höchste Rate, die Ihr Ziel erfüllt, als Kapazität je Kopie.

Modell, Gateway und Messung richten wir im Rahmen unseres Service Private AI/ML ein; beschreiben Sie Ihre Entwicklerwerkzeuge und die gewünschte Latenz, und wir schlagen einen Pilotbetrieb auf einer Karte vor.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team dimensioniert die Konfiguration für Ihre Last und Ihr Budget und antwortet innerhalb eines Werktages. Wir liefern die RTX PRO 4500 Blackwell Server Edition, die L4 und die RTX PRO 4000 und bauen KI-Server auf Bestellung mit vier oder acht Karten, vor der Lieferung montiert und getestet, auf Wunsch mit Betriebssystem, NVIDIA-Treiber, CUDA und Container-Laufzeit. Jede Komponente hat die Herstellergarantie, abgewickelt über uns, auf einem EU-Vertrag und einer Rechnung; Stückzahlen und Lieferzeit werden mit dem Angebot schriftlich bestätigt. Die Konfiguration mit vier Karten und die Bestellschritte stehen auf unserer Seite Server mit 4× RTX PRO 4500 Server Edition kaufen.

FAQ