- Zusammenfassung der Frage und Antworten aus dem Reddit-Subreddit /r/ollama
- Als Systemadministrator einer Kanzlei mit rund 300 Beschäftigten möchte der Fragesteller allen Mitarbeitenden ein KI-basiertes Tool zum Schreiben und Korrigieren von Dokumenten ähnlich wie ChatGPT bereitstellen
- Zum Schutz sensibler Informationen wie PII wird erwogen, statt externer Dienste ein LLM direkt auf internen Servern zu hosten (mit Zugriffskontrollen wie Login, 2FA, VPN usw.)
- Zentrale Fragen
- Kann ein selbst aufgebauter LLM-Server in der Praxis tatsächlich mehr als 300 Nutzer unterstützen?
- Es wurde angenommen, dass ein paar PCs mit GPUs ausreichen könnten – ist das in Wirklichkeit massiv unterschätzt?
- Kann die Erstellung und Verwaltung von Benutzern zu einer großen Belastung werden?
- Gibt es wichtige Aspekte, die übersehen wurden?
- Da der Fragesteller kein LLM-Experte ist, bittet er um realistische Einschätzungen zu Skalierbarkeit, Betriebsaufwand und Umsetzbarkeit
Zusammenfassung der wichtigsten Antworten
1. Grenzen bei Hardware, Leistung und Kosten
- Wenn man ein Niveau wie bei kommerziellen Modellen (z. B. ChatGPT) erwartet, ist ein teurer GPU-Cluster im Bereich von mehreren hunderttausend Dollar nötig (Schätzungen: $200,000~$1,000,000+)
- Skaliert man auf Open-Source-Modelle (ca. 30B bis 70B Parameter) herunter, muss man Leistungseinbußen bei Latenz und Ergebnisqualität in Kauf nehmen. Selbst 10 bis 40 gleichzeitige Nutzer können dann schon die Grenze sein
- Empfehlung: zunächst von weniger als 10 gleichzeitigen Nutzern ausgehen und dann schrittweise durch zusätzliche Server erweitern
- Im Vergleich zu einer lokalen Umgebung kann das Mieten von GPU-Ressourcen in der Cloud wirtschaftlicher und flexibler sein
2. Empfehlung für PoC (Pilot) und schrittweises Vorgehen
- Empfohlen wird ein PoC (Pilot) mit einem Server und einer GPU; erst nach Messung realer Nutzungsszenarien und Last sollte skaliert werden
- Bei vielen gleichzeitigen Anfragen ist ein Queue-System zwingend erforderlich; die tatsächliche Parallelität könnte eher bei 10 bis 30 Nutzern liegen als bei 300
- Kurzfristig sind Experimente mit kleinen Modellen (3B bis 13B Parameter) plus Workstation realistisch
3. Cloud-, Hybrid- und Alternativoptionen
- Vorgeschlagen wird eine Cloud-basierte LLM-Lösung (API, VPS, Azure, AWS Bedrock usw.), gekoppelt mit eigener Infrastruktur in einer hybriden Architektur, die zu den Sicherheitsanforderungen passt
- Beim Self-Hosting sind Sicherheits-, Leistungs- und Kostenaufwand hoch; in der Praxis können ChatGPT Enterprise/Teams, Microsoft Copilot Studio und ähnliche kommerzielle Lösungen effizienter sein
- Sicherheitsanforderungen bei der Verarbeitung juristischer Daten und PII müssen zwingend geprüft werden
4. Weitere Betriebs-, Verwaltungs- und Technikthemen
- Benutzerverwaltung/Authentifizierung: lässt sich über AD-Integration, OAuth oder eigene Authentifizierung vereinfachen
- Modellauswahl/Tuning: empfohlen wird das Testen mittelgroßer Open-Source-Modelle passend zum realen Einsatzzweck (Dokumentkorrektur usw.), etwa LLama, Deepseek, Gemma oder Qwen
- Zusätzliche Lösungen wie RAG, Caching oder Load Balancing sollten ebenfalls geprüft werden
- Nötig sind eine klare Definition realer Nutzungsszenarien und ein PoC, um Budget und ROI belastbar zu validieren
Zusammenfassung repräsentativer Antworten
ithkuil
- Im Vergleich zu kommerziellen Modellen ist der Leistungsunterschied bei Open-Source-Modellen groß; für eine Größenordnung von 300 Nutzern könnte Hardware im Wert von mehreren hunderttausend Dollar nötig sein
- Gleichzeitig könne man auf Fortschritte bei Hardware und Open Models in den nächsten zwei Jahren hoffen
SlimeQ
- Empfehlung: klein mit einer Instanz plus Warteschlange starten und bei wachsender Nutzung schrittweise ausbauen
- Dass alle 300 Personen gleichzeitig arbeiten, sei unrealistisch; die Skalierung sollte auf Basis realer Nutzung erfolgen
Ok-Internal9317
- Tatsächlich könnten gleichzeitig weniger als 10 Nutzer aktiv sein; dann könnten 4 bis 5 GPUs ausreichen
- Langfristig könnten API-Kosten wirtschaftlicher sein als eigene Hardware
dyoh777
- Mit Ollama+WebUI lässt sich schnell eine Demo bauen, entscheidend ist aber die Modellqualität
careful-monkey
- Ein Mac Studio mit viel RAM kann kleinere Modelle betreiben, mit etwa 20 Token/s
tshawkins
- Empfiehlt SaaS-basierte Lösungen wie Microsoft Copilot Studio, integriert in die Power Platform
roman_fyseek, Cergorach, Space__Whiskey
- VRAM-Grenzen der Modelle: 1 Sitzung = 1 GPU, daher würden für 300 gleichzeitige Nutzer im Extremfall 300 GPUs benötigt
- Realistisch sind Begrenzungen bei gleichzeitigen Verbindungen, Caching und hybride Architekturen nötig
Siderox, SandboChang, unrulywind
- Empfehlung: mit einem kleinen Server als PoC experimentieren (z. B. 1 bis 2 Nutzer pro Modell, Eignung für den realen Arbeitsalltag prüfen) und dann schrittweise erweitern
- Budget und ROI sollten nach Definition realer Szenarien und Benchmarks überprüft werden
Little_Marzipan_2087, morosis1982, Daemonero
- Cloud-GPU-Miete ist günstig und gut skalierbar und eine häufig genutzte Lösung
- Angesichts von Betriebs- und Wartungsaufwand wird Cloud-Nutzung eher empfohlen als Hardwareinvestitionen
CtiPath, alew3, faldore, Wheynelau
- Empfohlen werden leistungsfähige Open-Source-Frameworks für LLM-Server wie vLLM, OpenWebUI, TGI, sglang
- Empfohlen wird eine Architektur mit Queue plus Load Balancer
Sonstiges
- Sicherheits- und Rechtsthemen: Auch bei Cloud-Nutzung müssen Datenstandort, Verschlüsselung und Compliance gründlich geprüft werden
- Genannt wurden verschiedene Hardwareoptionen wie Mac Studio, RTX 6000 Pro, 4090 usw.
- Mit Caching, RAG, Kontextbegrenzung und Offloading lässt sich die Last eventuell reduzieren
Fazit
- Ein selbst gehosteter LLM-Server sollte realistisch mit einem kleinen Pilotprojekt (PoC) beginnen, um tatsächliche Nutzerzahl, Anforderungen, Leistung und Kosten schrittweise zu validieren
- Eine gleichzeitige Verarbeitung von 300 Nutzern bringt erhebliche Hardware- und Betriebskosten mit sich; je nach Einsatzzweck und Budget können Cloud-, Hybrid- oder kommerzielle Lösungen besser geeignet sein
- Entscheidend ist letztlich eine Gesamtbetrachtung von Sicherheit, Kosten, Nutzererfahrung und Wartbarkeit
6 Kommentare
Ich glaube, Sie haben den erforderlichen Denkfähigkeitsbereich für die Aufgaben dieser 300 Nutzer etwas zu breit angesetzt. Wenn wirklich alles abgedeckt werden soll, von ganz allgemeinem Alltagswissen bis hin zu Fachartikeln oder fortgeschrittenen Themen, ist dieser Ansatz nachvollziehbar. Wenn man aber das tatsächliche Niveau der zu verarbeitenden Aufgaben betrachtet, dürfte in den meisten Fällen ein 30B-Modell mit angebundenem RAG ausreichen. Ist der Umfang nicht vielleicht zu groß geworden, weil Sie sämtliche Gewichte der zugrunde liegenden Open-Source-Modelle hochgezogen und sich für höhere Denkfähigkeit zu stark auf deren Funktionen gestützt haben?? Außerdem scheint es sinnvoll zu sein, unmittelbar verarbeitbare Aufgaben sowie Dokumentensuche und -exploration als getrennte Funktionen zu behandeln.
Auch beim KV-Cache für die gleichzeitige Verarbeitung von 300 Nutzern könnte der angesetzte Token-Bereich vielleicht zu hoch sein — wenn man pro Nutzer etwa 20.000 quantisierte Tokens ansetzt, sollte das mit genügend Spielraum nutzbar sein... ??
Wenn es sich bei diesen 300 Personen nicht gerade um promovierte Forschende handelt, die wissenschaftliche Arbeiten verfassen, könnte man das erforderliche Denk-Niveau eher auf Oberstufenschüler-Niveau (14–30B) ansetzen und den Prozess so konfigurieren, dass verschiedene interne Dokumente über eine RAG-Logik mit passendem CoT durchsucht werden. Dann könnte daraus vermutlich ein Pilotprojekt zu vertretbaren Kosten werden.
Auch ich entwickle aus Bedarf eine RAG-Lösung und setze dafür die angeblich so schwer zu bekommenden vier H100-GPUs ein. Wenn man aber nicht nur die direkte Hardware-Investition, sondern auch Stromkosten, diverse Kühlungslösungen usw. berücksichtigt, denke ich immer wieder, dass es viel besser wäre, einfach eine API aufzurufen.
Ich habe anfangs ebenfalls mit Ollama getestet, dann festgestellt, dass damit nicht einmal drei gleichzeitige Nutzer ordentlich abgedeckt werden, und bin sofort zu vLLM gewechselt, um irgendwie eine RAG-Lösung zusammenzustellen. Aber schon dafür muss ich bei der Annahme von 10 gleichzeitigen Nutzern fast zwei H100-GPUs voll auslasten. Auch Embedding- und Suchaufgaben laufen bei mir über vLLM, und selbst mit vier H100-GPUs ist es wirklich knapp. Und das, obwohl eine Karte etwa 90 GB VRAM hat.
Natürlich kenne ich mich mit AI nicht besonders gut aus, und weil ich einfach etwas für die Abteilung gebraucht habe und dabei irgendwie die internen Sicherheitsvorgaben einhalten musste, probiere ich es eher mit dem Kopf durch die Wand ... aber ich frage mich wirklich, ob das so richtig ist. War es ChatGPT Enterprise? Das halte ich wirklich für extrem preiswert.
Mit einer verdammt starken Maschine zu einem verdammt guten Preis dürfte das wohl gehen? Eine verdammt große Kanzlei würde so etwas wahrscheinlich einfach kaufen. Aber dann liefe das Ding wie eine Fabrikmaschine 24 Stunden am Tag, lol.
Jemand, der nur an den Porsche-Preis denkt und Unterhaltskosten, Spritkosten, Versicherung usw. überhaupt nicht berücksichtigt.
Bei Diensten wie Chatbots, bei denen eine Streaming-Funktion bereitgestellt werden muss, scheint sich bei gleichzeitiger Verarbeitung die Prefill-Arbeit bis auf das Decoding auszuwirken. Deshalb wirkt es aus Sicht der Nutzer so, als würde die Leistung stark einbrechen, selbst wenn ausreichend VRAM vorhanden ist.
Ich habe Optionen im Zusammenhang mit Chunked Prefill sowie die in vLLM experimentell bereitgestellte Funktion „Disaggregated Prefilling“ ausprobiert. Trotzdem tritt weiterhin das Phänomen auf, dass bereits laufende Antworten ins Stocken geraten und immer wieder abbrechen, sobald neue Anfragen eingehen. Daher würde mich aus der Sicht eines Einsteiger-Entwicklers interessieren, ob es abgesehen davon, die Zahl der GPUs oder Nodes zu erhöhen, einen effizienteren Ansatz gibt.
Letztlich hängt es ganz vom Einzelfall ab!