Ein bekanntes Muster: Der Pilot mit lokaler KI läuft auf dem Laptop eines Entwicklers, Ollama ist in zehn Minuten installiert, die Antworten kommen fluessig. Dann soll das Ganze auf dreissig Kolleginnen und Kollegen ausgerollt werden, alle fragen zur selben Zeit, und ploetzlich hängt jede Anfrage. Das ist kein Bug. Es ist der Unterschied zwischen einem Werkzeug für einen Nutzer und einem Server für viele.
Wir haben Ollama zuletzt aus einem anderen Blickwinkel betrachtet, als aus dem Modell-Runner ein lokaler Agent wurde. Heute geht es nicht um neue Fähigkeiten, sondern um eine aeltere Frage, die im Mittelstand gerade praktisch wird: Was traegt lokale KI von einem Schreibtisch auf eine ganze Abteilung?
Der Sprung vom Pilot zur Belegschaft
Im Pilot testet meist eine Person. Sie tippt eine Frage, wartet auf die Antwort, tippt die nächste. Diese Sequenz aus Anfrage und Antwort ist genau das Szenario, in dem Ollama zu Hause ist. Einfache Installation, sinnvolle Voreinstellungen, es läuft auf einem Mac Studio genauso wie auf einer Workstation mit einer GPU.
Der Produktivbetrieb sieht anders aus. Zehn, zwanzig, fuenfzig Personen greifen über den Tag verteilt zu, oft in Wellen, etwa morgens beim Sichten der Post oder nachmittags vor Feierabend. Nicht die einzelne Antwort entscheidet dann, sondern wie viele Anfragen das System parallel bedient, ohne dass die Wartezeit unangenehm wird. Genau hier trennen sich die Werkzeuge.
Warum Ollama bei einem Nutzer glaenzt
Ollama ist dafuer gebaut, dass eine Anfrage nach der anderen sauber durchläuft. Für den Alltag eines einzelnen Nutzers ist das ideal. Es gibt keinen Grund, für einen Entwickler, der lokal an Code oder Texten arbeitet, etwas Komplizeres aufzusetzen. Wer lokale KI ausprobiert, sollte weiter mit Ollama oder LM Studio anfangen. Der Fehler entsteht erst, wenn man das Pilot-Setup unveraendert zum Abteilungsserver erklärt.
Der Grund liegt in der Architektur. Ollama verarbeitet Anfragen im Kern nacheinander. Kommen fuenf gleichzeitig, warten vier, während eine bedient wird. Bei einem Nutzer fällt das nie auf. Bei zwanzig wird die Wartezeit zum Engpass, und keine Tuning-Option holt heraus, was die Bauart nicht vorsieht.
Was die Red-Hat-Messung zeigt
Wie groß der Abstand unter Last wird, hat Red Hat im August 2025 in einem viel zitierten Benchmark gemessen und die Community hat die Richtung 2026 immer wieder bestaetigt. Auf derselben NVIDIA-A100-Karte, über Nebenläufigkeiten von einem bis 256 Nutzern, kam vLLM an der Spitze auf rund 793 Token pro Sekunde, Ollama auf etwa 41. Das ist rund das Neunzehnfache.
Diese Zahl wird oft ohne den entscheidenden Zusatz weitergereicht. Bei einem einzigen Nutzer landen beide laut derselben Messung in einem Bereich von etwa 130 bis 180 Token pro Sekunde, praktisch gleichauf. Der Abstand entsteht erst mit der Nebenläufigkeit: vLLMs Durchsatz stieg mit der Zahl der Nutzer weiter, Ollamas flachte fast sofort ab. Auch bei der Latenz zeigte sich das. Unter Volllast lag das 99. Perzentil bei vLLM laut Bericht bei rund 80 Millisekunden, bei Ollama bei rund 673.
Für die Praxis heißt das: Wer heute nur ein oder zwei Personen bedient, merkt zwischen den beiden kaum einen Unterschied. Wer eine Abteilung bedient, merkt fast nur noch den Unterschied.
Continuous Batching, der eigentliche Unterschied
Hinter der Zahl steckt eine Technik namens Continuous Batching, kombiniert mit einer speichereffizienten Verwaltung des sogenannten KV-Cache. Vereinfacht: vLLM steckt viele laufende Anfragen in einen gemeinsamen Verarbeitungsstrom auf der GPU und füllt frei werdende Rechenkapazitaet sofort mit der nächsten wartenden Anfrage. Statt einer Schlange, in der jeder einzeln vorrueckt, entsteht ein Fliessband, das nie leer steht.
Das erklärt auch, warum vLLM bei einem Nutzer keinen Vorsprung hat. Ein Fliessband mit einem einzigen Paket ist nicht schneller als ein Handgriff. Erst wenn viele Pakete zugleich unterwegs sind, spielt die Bauweise ihre Staerke aus. Deshalb ist die Wahl keine Frage von gut gegen schlecht, sondern von einem Nutzer gegen viele.
Ein Wort zur Hardware: vLLM entfaltet seinen Vorteil auf einer echten Server-GPU mit ausreichend Speicher, klassisch NVIDIA. Ollama läuft auch auf Apple Silicon und ist genau deshalb im Pilot so bequem. Wer den Produktivschritt plant, plant damit meist auch einen Hardware-Schritt.
Der Datenschutz ändert sich nicht
Wichtig für den Mittelstand unter DSGVO: An der Datenlage ändert der Wechsel nichts. Beide Werkzeuge betreiben das Modell lokal, die Anfragen verlassen das Haus nicht. Die Entscheidung zwischen Ollama und vLLM ist eine Frage des Betriebs und des Durchsatzes, keine Frage der Souveränität. Wer aus Datenschutzgruenden auf lokale Inferenz setzt, behaelt diesen Vorteil in beiden Fällen. Was das rechtlich rahmt, haben wir auf unserer Seite zur Datensouveraenitaet zusammengetragen.
Das ist eine gute Nachricht, denn sie trennt zwei Fragen sauber. Zuerst: Bleiben die Daten im Haus. Dann, und erst dann: Traegt die Technik die Zahl der Nutzer. Die erste Frage ist mit lokaler KI beantwortet, egal welches Werkzeug. Die zweite entscheidet über die Architektur.
Welches Werkzeug für welche Phase
Ein praktikabler Weg für einen Betrieb, der lokale KI ernst nimmt, sieht meist so aus:
- Pilot und Einzelplatz: Ollama oder LM Studio. Schnell aufgesetzt, gut zum Ausprobieren von Modellen und Abläufen, ideal auf einem vorhandenen Mac Studio.
- Kleines Team, wenige Gleichzeitige: Ollama kann reichen, wenn die Nutzung selten in Wellen kommt. Ehrlich prüfen, wann die Spitzen liegen.
- Abteilung oder ganzes Haus: vLLM auf einer dedizierten GPU, oder ein vergleichbarer Serving-Stack mit Batching. Hier zahlt sich die aufwendigere Einrichtung durch stabile Antwortzeiten aus.
Der Fehler, den wir am häufigsten sehen, ist nicht die falsche Werkzeugwahl im Pilot. Es ist der ausgebliebene Wechsel danach. Ein Setup, das für eine Person gedacht war, wird zur Abteilungsloesung erklärt, und dann sucht man den Fehler bei den Modellen, obwohl er in der Bauart des Servers liegt.
Für die Finanzierung des Hardware-Schritts lohnt in Deutschland ein Blick auf Foerderwege wie die Digitalisierungsprogramme der KfW oder regionale Zuschuesse, je nach Betriebsgroesse und Bundesland. Belastbare Aussagen dazu gehören aber in eine Einzelprüfung, nicht in einen Blogbeitrag.
Der Unterschied zwischen einem funktionierenden Pilot und einem funktionierenden Betrieb ist selten das Modell. Meist ist es die Schicht darunter, die entscheidet, ob zwanzig Menschen gleichzeitig arbeiten können.
Sie haben lokale KI im Pilot laufen und überlegen, wie der Schritt auf die ganze Belegschaft aussieht? Unser Pilotprojekt klaert Architektur, Hardware und Durchsatz an Ihrem echten Anwendungsfall, mit klaren Abnahmekriterien. Mehr zum Leistungsumfang auf der Seite lokale KI.
Häufige Fragen
Womit fängt man an, Ollama oder vLLM?
Mit Ollama. Für einen einzelnen Nutzer ist es ideal: einfache Installation, sinnvolle Voreinstellungen, und es läuft auf einem Mac Studio genauso wie auf einer Workstation. Für einen Entwickler, der lokal an Code oder Texten arbeitet, gibt es keinen Grund, etwas Komplizierteres aufzusetzen.
Wie groß ist der Unterschied unter Last?
Groß. Auf derselben NVIDIA-A100-Karte, über Nebenläufigkeiten von einem bis 256 Nutzern, kam vLLM an der Spitze auf rund 793 Token pro Sekunde, Ollama auf etwa 41. Bei einem einzigen Nutzer liegen beide laut derselben Messung bei etwa 130 bis 180 Token pro Sekunde, also praktisch gleichauf.
Worauf beruht der Unterschied?
Auf Continuous Batching, kombiniert mit einer speichereffizienten Verwaltung des KV-Cache. vLLM steckt viele laufende Anfragen in einen gemeinsamen Verarbeitungsstrom auf der GPU und füllt frei werdende Rechenkapazität sofort mit der nächsten Anfrage.
Ändert der Wechsel etwas am Datenschutz?
Nein. Beide Werkzeuge betreiben das Modell lokal, die Anfragen verlassen das Haus nicht. Die Entscheidung zwischen Ollama und vLLM ist eine Frage des Betriebs und des Durchsatzes, keine Frage der Souveränität.