Lokales LLM für mehrere Benutzer: Hardware, Kosten und Lastverteilung

Wie betreibt man ein lokales LLM für mehrere Benutzer? Für einen einzelnen Arbeitsplatz genügt häufig eine leistungsfähige Workstation. Sobald zehn oder zwanzig Mitarbeitende gleichzeitig mit derselben KI arbeiten, verändert sich die Planung grundlegend. Modellgewichte, Kontextfenster, KV-Cache, parallele Anfragen, Antwortgeschwindigkeit und Warteschlangen konkurrieren um dieselben Ressourcen.

Für ein selbst betriebenes Large Language Model fallen üblicherweise keine nutzungsabhängigen Gebühren eines Modell-API-Anbieters an. Dafür trägt das Unternehmen die Kosten für Hardware, Strom, Kühlung, Ausfallsicherheit, Administration und Updates. Bei mehreren Benutzern entscheidet daher die gesamte Inferenzarchitektur über Qualität und Wirtschaftlichkeit.

In diesem Leitfaden erklären wir, wie ein lokales LLM im Unternehmen geplant wird, wie Gewichtespeicher und verfügbare Hardware bei 8B-, 14B-, 32B- und 70B-Modellen zusammenpassen und wie Ollama, vLLM, Warteschlangen sowie dynamische Lastverteilung zusammenspielen. Außerdem zeigen wir, wann lokale Verarbeitung sinnvoll ist und wann eine hybride Verbindung mit Cloud-Modellen bessere Ergebnisse liefert.

Was „lokales LLM“ im Unternehmen bedeutet

Ein lokales LLM läuft auf Infrastruktur, die das Unternehmen selbst betreibt oder exklusiv kontrolliert. Das kann ein Server im eigenen Gebäude, ein Rechner im Rechenzentrum oder eine private Cloud-Instanz sein. Entscheidend ist der definierte Datenpfad: Eingaben und Antworten werden nicht automatisch an eine öffentliche Modell-API übertragen.

Eine produktive lokale KI besteht aus mehreren Ebenen:

1. Modell: Das trainierte Sprachmodell verarbeitet Prompts und erzeugt Tokens.
2. Inference Server: Software wie Ollama oder vLLM lädt das Modell, verwaltet Speicher und beantwortet Anfragen.
3. Anwendung: Chat-Oberfläche, Wissenssuche, AI Agents und Schnittstellen machen das Modell für Mitarbeitende nutzbar.
4. Betrieb: Identitäten, Rollen, Monitoring, Protokollierung, Updates, Backups und Ausfallsicherheit halten das System kontrollierbar.

Ein Modell auf einer Grafikkarte ist damit nur ein Baustein. Für den Unternehmensbetrieb müssen Benutzer getrennt authentifiziert, Berechtigungen geprüft, Dokumente sicher verwaltet und Anfragen priorisiert werden. Bei kritischen Abläufen kommen Freigaben und nachvollziehbare Prozessprotokolle hinzu.

Warum mehrere Benutzer die Hardwareplanung verändern

Die Aussage „20 Benutzer greifen auf die KI zu“ beschreibt die Last noch nicht ausreichend. Zwanzig registrierte Nutzer können über den Tag verteilt nur wenige kurze Fragen stellen. Sie können aber auch gleichzeitig umfangreiche Verträge, Reports oder technische Dokumentationen auswerten.

Für die Kapazitätsplanung sind diese Werte wichtiger:

• aktive Benutzer während der stärksten 15 Minuten;
• gleichzeitig laufende Anfragen;
• durchschnittliche und maximale Eingabelänge;
• gewünschte Länge der Antworten;
• Zahl der Modellaufrufe pro Aufgabe;
• Bild-, Audio- oder Dokumentverarbeitung;
• gewünschte Zeit bis zum ersten Token;
• benötigte Tokens pro Sekunde je Benutzer;
• zulässige Wartezeit in der Queue.

Interaktive und asynchrone Aufgaben

Ein Chat muss schnell reagieren, weil der Benutzer auf die Antwort wartet. Eine nächtliche Dokumentenklassifikation darf Aufgaben dagegen nacheinander abarbeiten. Beide Prozesse können dasselbe Modell verwenden, benötigen jedoch unterschiedliche Prioritäten und Serviceziele.

Eine praxistaugliche Architektur trennt deshalb häufig:

• interaktive Queue: kurze, sichtbare Benutzeranfragen mit hoher Priorität;
• Batch-Queue: größere Analysen, Importe und Hintergrundaufgaben;
• kritische Prozesse: reservierte Kapazität für zeitabhängige Unternehmensabläufe.

Ohne diese Trennung kann ein einziger großer Import die Antwortzeiten für das gesamte Team verschlechtern.

VRAM, Quantisierung und KV-Cache verständlich erklärt

Modellgewichte bilden den Grundbedarf

Die Parameterzahl gibt einen ersten Hinweis auf den Speicherbedarf. Ein Modell mit acht Milliarden Parametern wird häufig als 8B-Modell bezeichnet. Werden die Gewichte mit 16 Bit gespeichert, benötigen sie rechnerisch ungefähr zwei Byte pro Parameter. Acht Milliarden Parameter entsprechen damit rund 16 GB, bevor weitere Speicheranteile hinzukommen.

Quantisierung reduziert die Genauigkeit der Zahlendarstellung und dadurch den Speicherbedarf:

• FP16 oder BF16: ungefähr zwei Byte pro Parameter;
• 8 Bit: ungefähr ein Byte pro Parameter;
• 4 Bit: rechnerisch ungefähr ein halbes Byte pro Parameter.

Metadaten, Skalen, Runtime-Overhead und Modellarchitektur sorgen dafür, dass reale Dateien und der tatsächliche VRAM-Verbrauch von dieser einfachen Rechnung abweichen. Der Qualitätsverlust durch Quantisierung hängt zusätzlich vom Modell, dem Verfahren und der Aufgabe ab. Deshalb sollte immer die konkrete Modellvariante getestet werden.

Der KV-Cache wächst während der Nutzung

Während ein Modell Text verarbeitet, speichert es Zwischeninformationen zu den bisherigen Tokens im Key-Value-Cache, kurz KV-Cache. Dieser Speicher beschleunigt die weitere Generierung. Sein Bedarf wächst mit:

• der Kontextlänge;
• der Zahl gleichzeitiger Sequenzen;
• der Modellarchitektur und Zahl der Layer;
• der Präzision des KV-Caches;
• dem verwendeten Inferenzsystem.

Hier liegt einer der häufigsten Planungsfehler. Ein quantisiertes Modell passt bei einem einzelnen kurzen Prompt bequem in den VRAM. Mit acht parallelen Sitzungen und langen Dokumenten kann der zusätzliche Cache die verfügbare Reserve aufbrauchen.

Ollama weist ausdrücklich darauf hin, dass der benötigte Speicher mit OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH skaliert. Vier parallele Anfragen mit jeweils 8.000 Tokens ergeben in dieser Ollama-Planungsregel eine Gesamtkontext-Zuordnung von 32.000 Tokens. Das ist eine Speicherannahme und kein Durchsatz- oder Benutzerbenchmark. Ollama verwendet für den KV-Cache standardmäßig f16. Mit aktiviertem Flash Attention benötigt q8_0 laut Dokumentation ungefähr die Hälfte und q4_0 ungefähr ein Viertel dieses Cache-Speichers; der mögliche Qualitätsverlust hängt vom Modell, der Aufgabe und der Kontextlänge ab.

Kontextfenster bewusst begrenzen

Ein großes technisch mögliches Kontextfenster muss nicht für jede Aufgabe vollständig reserviert werden. Kurze E-Mails, Klassifikationen und strukturierte Extraktionen benötigen weniger Kontext als eine Analyse mehrerer Verträge.

Die aktuelle Ollama-Dokumentation verwendet je nach verfügbarem VRAM unterschiedliche Standardwerte: unter 24 GiB 4K, zwischen 24 und 48 GiB 32K und ab 48 GiB 256K Kontext. Diese Vorgaben können sich mit Versionen ändern. Ein höherer Wert erhöht den Speicherbedarf und sollte zum tatsächlichen Prozess passen.

Modellgrößen und Speicherbedarf für 8B, 14B, 32B und 70B

Die folgende Tabelle nennt konkrete Q4_K_M-Artefakte aus der offiziellen Ollama-Modellbibliothek. Die Downloadgröße ist kein vollständiger VRAM-Bedarf. Inferenz-Runtime, temporäre Berechnungen, KV-Cache, Kontext und parallele Sequenzen kommen hinzu. Die Werte sind daher prüfbare Beispiele für Gewichtedateien und keine Hardware- oder Leistungszusage.

Stand der Modellartefakte: 6. September 2026. Andere Modelle und Quantisierungsformate haben andere Größen.

Die Speicherrechnung vor dem Hardwarekauf

Die theoretische Untergrenze der reinen Gewichte lässt sich als Parameterzahl × Bits pro Gewicht ÷ 8 berechnen. Für 8 Milliarden Parameter bei 4 Bit sind das 4 Milliarden Byte, also etwa 4 GB. Dass das genannte Qwen3-Artefakt 5,2 GB groß ist, zeigt bereits den Unterschied zwischen der vereinfachten Rechnung und einer konkreten Modellversion. Für die Hardwareentscheidung werden anschließend gemessener Runtime-Bedarf, KV-Cache je Kontext und Sequenz, Parallelität sowie eine Betriebsreserve addiert.

Ein Modellartefakt sollte möglichst vollständig in den vorgesehenen GPU-Speicher passen. Ollama lädt ein Modell nach eigener Dokumentation bevorzugt auf eine einzelne GPU, wenn es dort vollständig Platz findet, und verteilt es sonst über die verfügbaren GPUs. vLLM empfiehlt ebenfalls eine einzelne GPU, wenn das Modell einschließlich der nötigen Speicheranteile passt. Wie viele Benutzer damit eine akzeptable Antwortzeit erhalten, muss ein Lasttest mit dem gewählten Modell, der Quantisierung und echten Prompt-Längen zeigen.

Ein Q4_K_M-Artefakt mit 43 GB kann in einer Konfiguration mit 48 GB VRAM ein Kandidat sein, bietet rechnerisch jedoch nur rund 5 GB Abstand zur Dateigröße. Daraus folgt keine Zusage, dass ein 70B-Modell mit gewünschtem Kontext und parallelen Sitzungen vollständig auf dieser GPU läuft. Mehr VRAM oder mehrere GPUs schaffen Speicherraum; Durchsatz und Latenz hängen zusätzlich von Hardware, Engine, Interconnect und Lastprofil ab.

Mehrere GPUs

Mehrere GPUs können auf verschiedene Weise eingesetzt werden:

• Tensor Parallelism: Teile einzelner Rechenoperationen werden über mehrere GPUs verteilt.
• Pipeline Parallelism: Modellschichten laufen auf unterschiedlichen GPUs oder Nodes.
• Data Parallelism: Mehrere Kopien oder Instanzen bearbeiten verschiedene Anfragen.
• Mehrere Modellpools: Separate GPUs bedienen unterschiedliche Modellklassen oder Prioritäten.

Für hohe Verfügbarkeit kann ein zweiter Server wertvoller sein als jede GPU im selben Gehäuse. Fällt ein einzelner großer Rechner aus, steht sonst die gesamte lokale KI still.

CPU-Inferenz und Unified Memory

Modelle können auch vollständig oder teilweise im Arbeitsspeicher laufen. Das ermöglicht große Modelle auf Systemen ohne entsprechende GPU, ist bei interaktiver Mehrbenutzernutzung jedoch häufig langsamer. Systeme mit Unified Memory können viel gemeinsamen Speicher bereitstellen. Durchsatz, Speicherbandbreite, Softwareunterstützung und Skalierbarkeit müssen trotzdem im realen Einsatz geprüft werden.

Ollama, vLLM und andere Serving-Schichten

Ollama für Piloten und überschaubare Installationen

Ollama macht das Laden und Bereitstellen lokaler Modelle sehr einfach. Es stellt eine HTTP-API bereit, verwaltet Modellversionen und nutzt verfügbare GPU-Beschleunigung. Für einen Pilot, eine interne Entwicklerumgebung oder einen begrenzten Benutzerkreis ist das oft der schnellste Einstieg.

Ollama kann mehrere Modelle laden und Anfragen an ein Modell parallel verarbeiten, wenn ausreichend RAM oder VRAM vorhanden ist. Laut aktueller FAQ steht OLLAMA_NUM_PARALLEL standardmäßig auf 1; der benötigte Speicher skaliert mit Parallelität und Kontextlänge. Reicht der Speicher für ein weiteres Modell nicht aus, werden neue Anfragen in Reihenfolge eingereiht. Überschreitet die Queue den konfigurierten Grenzwert, antwortet der Server mit HTTP 503. OLLAMA_MAX_QUEUE begrenzt die Warteschlange und hat laut Dokumentation derzeit den Standardwert 512. Diese Standardwerte sind Konfigurationen, keine Zusage für eine bestimmte Nutzerzahl.

Wichtige Einstellungen sind:

• OLLAMA_MAX_LOADED_MODELS für gleichzeitig geladene Modelle;
• OLLAMA_NUM_PARALLEL für parallele Requests pro Modell;
• OLLAMA_MAX_QUEUE für wartende Anfragen;
• OLLAMA_CONTEXT_LENGTH für die Kontextgröße;
• OLLAMA_KEEP_ALIVE für die Verweildauer im Speicher;
• OLLAMA_KV_CACHE_TYPE für die Quantisierung des KV-Caches.

vLLM für höheren Durchsatz

vLLM richtet sich stärker an produktives Serving mit hohem Durchsatz. Continuous Batching bündelt laufend neue Anfragen, während PagedAttention den KV-Cache effizient verwaltet. OpenAI-kompatible Endpunkte erleichtern die Einbindung vorhandener Anwendungen.

Für größere Modelle unterstützt vLLM Tensor- und Pipeline-Parallelismus über mehrere GPUs. Data Parallelism kann zusätzliche Replikate bereitstellen und Anfragen verteilen. Bei mehreren Nodes kommen Netzwerk, Clusterverwaltung und gemeinsame Konfiguration als weitere Betriebsebenen hinzu. Beim Start meldet vLLM die verfügbare GPU-KV-Cache-Kapazität in Tokens und eine daraus geschätzte maximale Parallelität für die konfigurierte Sequenzlänge. Diese Laufzeitwerte sind ein Ausgangspunkt für den Lasttest und ersetzen keine Messung mit dem eigenen Anfrageprofil.

Weitere Optionen

Je nach Hardware und Anwendung kommen außerdem llama.cpp, Hugging Face Text Generation Inference, NVIDIA NIM oder spezialisierte Inferenzplattformen infrage. Die Auswahl sollte anhand derselben Testfälle erfolgen. Ein theoretisch schneller Server hilft wenig, wenn das benötigte Modellformat, die Authentifizierung oder das Monitoring nicht zur vorhandenen Umgebung passen.

Warteschlangen, Parallelität und dynamische Lastverteilung

Eine produktive LLM-Lastverteilung besteht aus mehr als einem Round-Robin-Verteiler. Die einzelnen Anfragen unterscheiden sich stark in Prompt-Länge, gewünschter Antwort, Modell und Priorität. Ein intelligenter Router berücksichtigt daher:

• gewünschtes Modell und verfügbare Instanz;
• freie VRAM- und KV-Cache-Kapazität;
• aktuelle Queue-Länge;
• Priorität und zulässige Wartezeit;
• Datenklasse und erlaubte Verarbeitungsumgebung;
• Fallback auf ein anderes lokales oder freigegebenes Cloud-Modell.

Eine robuste Architektur kann so aufgebaut sein:

TTFT steht für „Time to First Token“. Für interaktive Chats ist diese Kennzahl häufig wichtiger als die gesamte Laufzeit. Bei Hintergrundaufgaben zählt dagegen der Gesamtdurchsatz aller verarbeiteten Tokens.

Praxisbeispiel für 20 gleichzeitige Benutzer

Ein Unternehmen mit 80 Mitarbeitenden stellt 20 Personen einen gemeinsamen KI-Arbeitsplatz bereit. Sie bearbeiten E-Mails, interne Richtlinien, Besprechungsnotizen und vertrauliche Dokumente. Während einer typischen Spitze laufen acht Anfragen gleichzeitig.

Ein mögliches Konzept:

• Ein 8B- oder 14B-Modell übernimmt Klassifikation, Extraktion und kurze Standardantworten.
• Ein 32B-Modell bearbeitet anspruchsvollere interne Analysen.
• Ein Router wählt Modell und Inferenzserver anhand der Aufgabe.
• Interaktive Anfragen erhalten eine höhere Priorität als große Hintergrundjobs.
• Dokumente werden über eine lokale Wissenssuche in relevante Abschnitte zerlegt.
• Freigegebene komplexe Aufgaben können an ein Cloud-Modell übergeben werden.
• Kritische Aktionen benötigen eine menschliche Bestätigung.

Die genaue Hardware lässt sich aus diesem Szenario noch nicht ableiten. Zuerst müssen Prompt-Längen, Antwortlängen, Qualitätsanforderungen und Spitzenlast gemessen werden. Ein Test mit echten Dokumenten zeigt beispielsweise, ob ein 14B-Modell zuverlässig genug ist oder ob bestimmte Aufgaben ein größeres Modell benötigen.

Welche Werte sollte ein Pilot messen?

• Zeit bis zum ersten Token;
• Tokens pro Sekunde pro Benutzer und insgesamt;
• 95. Perzentil der Antwort- und Wartezeit;
• VRAM- und RAM-Auslastung;
• Queue-Länge und abgewiesene Requests;
• GPU-Auslastung und Leistungsaufnahme;
• Qualität je Modell und Aufgabenklasse;
• Fehlerquote und nötige manuelle Korrekturen.

Ein Durchschnittswert kann Lastspitzen verdecken. Das 95. Perzentil zeigt, wie lange fast alle Benutzer höchstens warten und macht Engpässe besser sichtbar.

Lokales LLM und DSGVO

Lokale Verarbeitung kann Datenschutz und Vertraulichkeit deutlich erleichtern, weil sensible Inhalte die kontrollierte Infrastruktur nicht verlassen müssen. Automatische DSGVO-Konformität entsteht dadurch jedoch nicht. Auch ein interner KI-Server verarbeitet personenbezogene Daten und benötigt ein dokumentiertes Schutzkonzept.

Zu prüfen sind insbesondere:

• Zweck und Rechtsgrundlage der Verarbeitung;
• Datenminimierung und zulässige Eingaben;
• Benutzeridentitäten, Rollen und Berechtigungen;
• Speicherung von Prompts, Antworten und Dokumenten;
• Lösch- und Aufbewahrungsfristen;
• Protokollierung ohne unnötige sensible Inhalte;
• Schutz vor unbefugtem Netzwerkzugriff;
• Modell- und Softwareupdates;
• Backup, Wiederherstellung und Incident Response;
• Lizenzbedingungen der eingesetzten Modelle.

Ein ungeschützter Ollama-Port im Firmennetz ist keine Benutzerverwaltung. Vor den Inferenzserver gehören Authentifizierung, TLS, Rate Limits und eine fachliche Rechteprüfung. Netzwerksegmente und Firewalls begrenzen zusätzlich, welche Systeme ein Agent erreichen darf.

Weitere Hinweise findest du in Welche KI ist DSGVO-konform? und Was passiert mit meinen Daten bei KI-Tools?.

Kostenrechnung: lokales Modell gegen API-Nutzung

Ein lokales Modell hat keine Rechnung pro verarbeitetem API-Token. Seine Nutzung ist trotzdem nicht kostenlos. Die relevante Kennzahl ist die Total Cost of Ownership über einen realistischen Zeitraum.

Zur lokalen TCO gehören:

• Anschaffung oder Miete der Server und GPUs;
• Speicher, Netzwerk und Ersatzkomponenten;
• Strom und gegebenenfalls zusätzliche Kühlung;
• Rechenzentrum, Rack oder Cloud-GPU;
• Monitoring, Backups und Sicherheitswerkzeuge;
• Einrichtung, Updates und Fehlerbehebung;
• Ausfallreserve und Wiederherstellung;
• Tests neuer Modelle und laufende Qualitätssicherung.

Eine einfache monatliche Rechnung kann so aufgebaut werden:

• Hardwareabschreibung: Anschaffungspreis geteilt durch 36 Monate;
• Energie: durchschnittliche Leistungsaufnahme in kW × Betriebsstunden × Strompreis;
• Betrieb: interne oder externe Arbeitsstunden × Vollkostensatz;
• Infrastruktur: Netzwerk, Backup, Housing und Softwarelizenzen;
• Risikoreserve: Ersatzteile, Ausfälle und Kapazitätsspitzen.

Rechenbeispiel mit offengelegten Annahmen

Das folgende Beispiel dient ausschließlich dazu, die Methode nachvollziehbar zu machen. Es verwendet keine Marktpreise und keinen gemessenen Verbrauch eines konkreten Servers.

• Hardware: angenommene 12.000 Euro ÷ 36 Monate = 333,33 Euro pro Monat;
• Energie: angenommene 0,70 kW × 730 Stunden × 0,30 Euro/kWh = 153,30 Euro pro Monat;
• Betrieb: angenommene 8 Stunden × 90 Euro Vollkostensatz = 720 Euro pro Monat;
• Infrastruktur: angenommene 150 Euro für Backup, Netzwerk und Software pro Monat;
• Reserve: angenommene 10 Prozent der monatlichen Hardwareabschreibung = 33,33 Euro.

Unter diesen Annahmen beträgt die lokale Monats-TCO 1.389,96 Euro. Steuern, Finanzierung, zusätzliche Kühlung, Ausfallzeiten und Ersatzhardware sind in diesem Beispiel nicht enthalten. Vor einer Entscheidung werden alle Annahmen durch Angebote, gemessene Leistungsaufnahme und den tatsächlichen Betriebsaufwand ersetzt.

Bei einer Cloud-API werden stattdessen Eingabe-, Ausgabe- und gegebenenfalls Cache-Tokens, Werkzeuge, Storage sowie Plattformkosten erfasst. Kleine Modelle sind über APIs häufig sehr günstig. Eine lokale Installation kann sich wirtschaftlich lohnen, wenn Auslastung, Datenschutz, Latenz oder Modellkontrolle den zusätzlichen Betrieb rechtfertigen.

Warum geringe Auslastung lokale Systeme teuer macht

Ein eigener GPU-Server verursacht Kosten, auch wenn er nur wenige Stunden produktiv rechnet. Hohe und gut planbare Auslastung verbessert die Wirtschaftlichkeit. Für seltene komplexe Aufgaben kann eine API günstiger sein, während häufige sensible Routineaufgaben lokal verarbeitet werden.

Hybrides Modellrouting in der Praxis

Viele Unternehmen erzielen mit einer hybriden Architektur die beste Balance. Lokale und externe Modelle werden nach klaren Regeln kombiniert:

• sensible Klassifikation und Extraktion laufen lokal;
• interne Wissenssuche bleibt in der kontrollierten Umgebung;
• allgemeine, freigegebene Aufgaben nutzen kostengünstige Cloud-Modelle;
• komplexe Analysen erhalten gezielt ein leistungsfähigeres Modell;
• ein Fallback übernimmt, wenn ein lokaler Server ausgelastet oder nicht verfügbar ist.

AI Cowork kann für Unternehmen ab 10 Mitarbeitenden ohne feste Obergrenze als gemeinsame Arbeits- und Steuerungsebene über diesen Modellen liegen. Mitarbeitende wählen keinen technischen Endpoint. Das System ordnet den Auftrag ein und berücksichtigt Datenklasse, Qualität, Kosten und aktuelle Verfügbarkeit. Lokale LLMs, Cloud-Modelle, Firmenwissen und Prozesswerkzeuge erscheinen für den Benutzer in einer einheitlichen Oberfläche.

Wir haben in lokalen LLM-Projekten erlebt, dass diese Trennung den Betrieb erheblich vereinfacht. Kleine Modelle übernehmen wiederkehrende Aufgaben mit hohem Volumen. Größere lokale oder externe Modelle werden nur eingesetzt, wenn ihre Qualität gebraucht wird. Dadurch muss die gesamte Infrastruktur nicht für jeden denkbaren Spitzenfall dimensioniert werden.

Wie daraus ein integriertes Unternehmenssystem entsteht, zeigt unsere Übersicht zu KI-Systemen und vernetzten AI Agents.

Lokal, Cloud oder hybrid: eine Entscheidungsmatrix

Häufige Fehler bei lokalen LLM-Servern

1. Nur die Modellgröße betrachten: Kontext und Parallelität benötigen zusätzlichen VRAM.
2. Mit einem Demo-Prompt dimensionieren: Kurze Einzeltests bilden echte Dokumente und Lastspitzen nicht ab.
3. CPU-Offloading als Standard einplanen: Das Modell läuft, die Antwortzeit kann für Teams trotzdem unbrauchbar werden.
4. Alle Aufgaben an ein großes Modell senden: Kleine Modelle sind für viele Routinearbeiten schneller und effizienter.
5. Keine Prioritätsklassen verwenden: Batch-Jobs blockieren dann interaktive Nutzer.
6. Den Inferenzserver direkt freigeben: Authentifizierung, Rollen und Rate Limits fehlen.
7. Ausfallsicherheit vergessen: Eine einzelne Workstation wird zum zentralen Risiko.
8. Nur Strom und Hardware rechnen: Administration, Monitoring und Qualitätssicherung werden unterschätzt.

So planst du den Pilotbetrieb

1. Drei bis fünf Aufgaben auswählen: Verwende echte Dokumente und unterschiedliche Schwierigkeitsgrade.
2. Qualität messbar machen: Definiere korrekte Ergebnisse, akzeptable Fehler und manuellen Korrekturaufwand.
3. Zwei Modellgrößen vergleichen: Häufig liefert ein kleineres Modell bereits ausreichende Qualität.
4. Kontext realistisch wählen: RAG und gute Dokumentaufteilung reduzieren unnötig große Prompts.
5. Parallelität simulieren: Teste typische und maximale gleichzeitige Anfragen.
6. Grenzfälle provozieren: Volle Queue, Modellwechsel, Serverneustart und Ausfall eines Workers gehören zum Test.
7. Kosten vollständig erfassen: Hardware, Energie, Betrieb und Alternativkosten werden gemeinsam betrachtet.
8. Nach vier bis sechs Wochen entscheiden: Erst reale Nutzung zeigt, ob lokal, Cloud oder hybrid langfristig passt.

Häufige Fragen zu lokalen LLMs für mehrere Benutzer

Fazit: Kapazität folgt der tatsächlichen Nutzung

Ein lokales LLM für mehrere Benutzer ist technisch gut umsetzbar. Die richtige Hardware ergibt sich aus Modell, Kontext, Parallelität, Qualitätsanspruch und gewünschter Reaktionszeit. Parameterzahl und Dateigröße liefern nur den Ausgangspunkt.

Für viele Unternehmen ist ein gestufter Aufbau sinnvoll: Ein kleines oder mittleres lokales Modell übernimmt klar definierte Aufgaben, eine Queue kontrolliert Spitzen und ein Router wählt für anspruchsvolle Fälle eine passende Alternative. So muss lokale Hardware nicht für jede seltene Ausnahme überdimensioniert werden.

Wenn du prüfen möchtest, wie lokale LLMs, Cloud-Modelle und Firmenwissen in einem gemeinsamen System zusammenspielen können, kannst du dir AI Cowork unverbindlich ansehen. Mit einigen realen Aufgaben und einem typischen Lastprofil lässt sich die geeignete Architektur deutlich zuverlässiger bestimmen als anhand allgemeiner Hardwarelisten.

Quellen und weiterführende Informationen

Die technischen Aussagen zu Ollama, vLLM, Quantisierung, Modellartefakten und Kontext wurden zuletzt am 6. September 2026 anhand der folgenden offiziellen Quellen geprüft. Konkrete Leistungs- und Kostenzahlen im Artikel sind entweder als Anbieterwert oder als Rechenbeispiel mit Annahmen gekennzeichnet.

• Ollama: FAQ zu Parallelität, Queue, mehreren GPUs und KV-Cache
• Ollama: Kontextlänge und VRAM
• Ollama: unterstützte GPU-Hardware
• Ollama-Modellbibliothek: Qwen3-Artefakte und Dateigrößen
• Ollama-Modellbibliothek: Llama-3.3-Artefakte und Dateigrößen
• vLLM: Parallelism and Scaling
• vLLM: Quantisierung und Hardwareunterstützung
• vLLM: OpenAI-kompatibler Server
• Hugging Face: Quantisierung von Modellen
• llama.cpp: lokale Inferenz und Modellformate
• Europäische Kommission: Grundsätze der DSGVO

Über den Autor

Peter Krause

KI-Berater, Buchautor & Gründer

Über Peter Krause LinkedIn KI-Buch