Inhaltsverzeichnis

1. Einführung

2. Hardware

3. Inferenz

4. Testen

5. Benchmarking

6. Software und Tooling

7. Fazit

Einführung

basebox AI bietet Enterprise-KI-Systeme sowohl für Cloud- als auch für On-Premises-Deployments. Viele regulierte Branchen erfordern, dass KI-Services vollständig vor Ort betrieben werden, was die nachfragebasierte Skalierung schwieriger macht als in der Cloud. Dies schafft eine einzigartige Herausforderung: LLMs benötigen leistungsstarke GPUs und erhebliche Rechenressourcen, aber On-Premises-Deployments müssen oft innerhalb fester Hardware-Beschränkungen arbeiten und häufig vollständig offline funktionieren. Dieser Artikel beleuchtet einige der Herausforderungen beim Betrieb von On-Premise-KI-Services, präsentiert konkrete Benchmarks, diskutiert einige unserer Erkenntnisse und zeigt zusätzliche Tools, die wir entwickelt haben.

Hardware

LLMs benötigen leistungsfähige GPUs mit beträchtlichem Videospeicher (VRAM) für akzeptable Performance, außer bei sehr kleinen Modellen. Einer der Hauptanbieter von GPUs, NVIDIA, bietet zwei verschiedene Kategorien: Consumer-Grade GeForce RTX-Karten und Enterprise-Grade-Optionen wie die RTX A6000 (Workstation) oder H100/L40S (Rechenzentrum). Die Planung der Hardware-Anforderungen hängt von mehreren Faktoren ab. Als allgemeine Richtlinie wird jedoch empfohlen, das System horizontal skalierbar zu gestalten. Dies ermöglicht es, bei Bedarf später weitere GPUs hinzuzufügen. Wichtige Faktoren, die die Gesamtleistung des Systems beeinflussen, sind:

• Modellgröße: Grob gesagt gibt es kleine Modelle, mittelgroße Modelle und große Modelle – ausgedrückt in der Anzahl der Parameter (z.B. 8B, 70B, 405B); Modelle können mit verschiedenen Quantisierungen laufen (vereinfacht gesagt kann man sich das als "Präzision" vorstellen). Mit mehreren Erstellern, Typen, Größen und Quantisierungsformaten wächst die Anzahl verfügbarer Modelle exponentiell. Die HuggingFace-Plattform ist zum Hauptknotenpunkt für Modelle geworden, um sie zu veröffentlichen, zu durchsuchen, zu suchen, herunterzuladen und sogar auszuführen. Die meisten Open-Source-Inferenz-Engines unterstützen verschiedene Modellarchitekturen und -formate.

• Kontextgröße: Kontext wird oft in Bezug auf Input-Token und Output-Token diskutiert. Wenn Benutzer planen, große Textmengen oder große Dateien an Modelle zu senden und umfangreiche Modellantworten erwarten, steigen Speicher- und Rechenanforderungen. Inferenz-Engines begrenzen die maximal unterstützten Input-Token und geben schnell Fehler aus oder stürzen ab, wenn sie die Hardware-Kapazitäten überschreiten.

• Gleichzeitige Benutzer: Ob 1 Benutzer oder 8 Benutzer gleichzeitig mit LLM-Services interagieren, macht einen Unterschied. Mehr gleichzeitige Benutzer können zu einem erheblichen Engpass werden, da Speicher- und Rechenanforderungen schnell steigen. Inferenz-Engines haben interne Mechanismen, um Anfragen zu bündeln und in Warteschlangen einzureihen. Je nach Arbeitsbelastung können Benutzer des Systems längere Wartezeiten für Antworten erleben (oder im schlimmsten Fall stürzt das System ab).

Diese Faktoren sind alle voneinander abhängig. Zum Beispiel könnten weniger leistungsstarke GPUs kleinere Modelle mit größeren Kontextgrößen ausführen; leistungsstärkere GPUs könnten mittelgroße Modelle mit größeren Kontextgrößen, aber begrenzter Anzahl gleichzeitiger Benutzer ausführen. Die umfangreiche und leider etwas "unübersichtliche" Modelllandschaft und die oben genannten Faktoren machen es schwierig, eine Zauberformel und konkrete Zahlen zu finden. Wie wir später sehen werden, geht nichts über tatsächliches Testen und Benchmarking konkreter Modelle auf konkreter Hardware mit einer konkreten Inferenz-Engine.

Die gute Nachricht ist: 1) High-End-GPUs werden billiger, wenn neuere High-End-GPUs veröffentlicht werden, und Modellarchitekturen werden effizienter; 2) KI-Arbeitslasten können immer noch auf CPUs ausgeführt werden und nicht alle Komponenten benötigen zwangsläufig teure GPUs. Ein Beispiel für eine solche Komponente ist ein System für Retrieval-Augmented Generation (RAG). Ein RAG-System ist im Kern ein Informationsabrufsystem ("Suchmaschine"), heute typischerweise ein Hybridsystem, in dem klassische Volltextsuche auf semantische Suche trifft. RAG-Systeme werden oft für die Dokumentenverarbeitung verwendet, um LLM-Kontextgrößenbeschränkungen zu umgehen, das Halluzinationsproblem zu reduzieren und KI-Services mit Daten zu versorgen, die nicht Teil ihrer Trainingsdaten waren (z.B. Firmeninterna). Die Vektoren für die semantische Suche werden mit kleineren und günstigeren "Embedding-Modellen" berechnet und laufen gut auf Multi-Core-CPUs. (RAG-Systeme können immer noch von GPUs profitieren, wenn höhere Leistung benötigt wird oder teurere Operationen wie Vision-Modelle als Teil einer Embedding-Pipeline ausgeführt werden sollen.)

Inferenz

Die wohl wichtigste Komponente eines lokalen KI-Systems ist die Komponente, die tatsächlich LLMs ausführt, die Inferenz-Engine. Es gibt eine Reihe von Open-Source-Projekten, und nicht alle scheinen für On-Premise- und Enterprise-Nutzung geeignet zu sein. Zum Beispiel fanden wir in frühen Tests heraus, dass das beliebte Ollama-Projekt für persönliche und Heimnutzung geeignet ist, aber weniger für Produktionsdeployments, da Leistung und Skalierbarkeit nicht mit anderen Projekten mithalten können und bestimmte Enterprise-Features fehlen. In jüngerer Zeit gab es Community-Diskussionen bezüglich Attributionspraktiken zum Llama.cpp-Projekt – Organisationen, die Ollama bewerten, sollten diese Community-Dynamiken als Teil ihrer Bewertung berücksichtigen.

Was sind also die Hauptkriterien, nach denen wir gesucht haben?

• Produktionsreife: Deploybar auf benutzerdefinierter Hardware mit mindestens NVIDIA-Unterstützung (AMD-Unterstützung existiert oft, ist aber generell weniger ausgereift), klare Lizenzierung und gebaut für die Bewältigung von Arbeitslasten jenseits der Einzelbenutzer-Heimnutzung; bewährt in realen Produktionsdeployments

• Support und Community: Wichtig, da sich die Landschaft schnell entwickelt, mit neuen Modellen und Architekturen, die ständig veröffentlicht werden; dies würde auch kleinere Projekte mit weniger Akzeptanz, kleineren Communities, weniger realer Nutzung und insgesamt höherem Risiko der Aufgabe ausschließen

• Modellunterstützung: Die bekannten state-of-the-art Open-Source-Modelle müssen unterstützt werden, mit Flexibilität, verschiedene Varianten in verschiedenen Formaten und Quantisierungen auszuführen (vor-quantisierte und on-the-fly quantisierte Formate); idealerweise werden multimodale und Vision-Modelle unterstützt, wenn dieser Anwendungsfall wichtig ist

• Leistung: Die Engine sollte state-of-the-art Leistung mit den neuesten algorithmischen Entwicklungen und Optimierungen rund um Modellarchitekturen und deren Hardware-Nutzung unterstützen (dies umfasst Ansätze wie Flash Attention/Paged Attention, Tensor Parallelism, Continuous Batching, etc.). Ein Schlüsselfaktor für On-Premise-LLMs ist, wie Inferenz-Engines Benutzeranfragen zu GPUs bündeln. Durch die gemeinsame Verarbeitung mehrerer Anfragen erreichen GPUs höheren Durchsatz, aber dies kann die Antwortlatenz erhöhen, da Anfragen warten müssen, bis der Batch gefüllt ist. Das richtige Gleichgewicht zwischen Batching und Latenz ist besonders wichtig für größere oder komplexere Modelle und beeinflusst direkt die reale Leistung und Benutzererfahrung.

• Schnittstellen: APIs müssen OpenAI-kompatibel sein, zumindest auf grundlegendem Niveau, wo typische Chat-Interaktion zwischen Benutzern und "Assistenten"-Rollen unterstützt wird; das LLM-Ökosystem dreht sich um diesen De-facto-Standard, daher würde fehlende Unterstützung die Integration komplizierter und zeitaufwändiger machen

• Offline-Modus: Essentiell für On-Premise-Deployments in regulierten Branchen; Startup und Laufzeitausführung müssen ohne aktive Internetverbindung funktionieren, wo vorab heruntergeladene Modelle von der Festplatte geladen werden

• Docker-Unterstützung: Da die Inferenz-Engine möglicherweise als Teil eines größeren containerisierten Systems laufen muss, ist eine offizielle Docker-Deployment-Option nicht zwingend erforderlich, aber definitiv ein Vorteil (es ist auch erwähnenswert, dass NVIDIA GPU-Passthrough mit Docker unter Linux funktioniert, aber nicht unter macOS aufgrund von Plattformbeschränkungen)

• Andere "Enterprise-Features", zum Beispiel: Monitoring und Integration mit beliebten Systemen wie OpenTelemetry/Prometheus; strukturierte Ausgaben zur Steuerung von Modellantworten; Ausführung von Adaptern für benutzerdefinierte fine-getunete Modelle

Zwei Engines, die die oben genannten Kriterien größtenteils erfüllen, sind vLLM und TGI (Text Generation Inference). Erstere wird oft von Cloud-Anbietern verwendet, letztere wurde von Hugging Face vorangetrieben und wird in ihrer eigenen Infrastruktur verwendet. TGI schlägt ein gutes Gleichgewicht zwischen Produktionsreife, Leistung (oft getestet als schneller als vLLM) und Enterprise-Features. vLLM kommt mit mehr Konfigurationsoptionen, auf Kosten von mehr Gesamtkomplexität im Management. Die nächsten Abschnitte konzentrieren sich auf unsere Nutzung von TGI und zeigen einige reale Benchmarks.

Testen

Das Testen von Inferenz-Engines stellt eine praktische Herausforderung dar: Die meisten Teams haben keinen Zugang zu mehreren GPU-Konfigurationen für die Bewertung. Ohne ein Rack voller H100s zur Verfügung zu haben, benötigen Sie einen kosteneffizienten Ansatz, der das Lernen aus begrenztem Hardware-Zugang maximiert.

• Smoke Testing: Dies ist ein grundlegender Test, bei dem Sie die Inferenz-Engine und das Modell starten und sehen, ob es korrekt startet und bereit ist, über seine API aufgerufen zu werden. Eine unserer Erkenntnisse hier ist, dass dies unvorhersagbar ist, d.h. verschiedene Versionen von Modellen und verschiedene Quantisierungen können laufen oder auch nicht, selbst wenn alle Konfigurationen korrekt zu sein scheinen. Wir haben einen internen Katalog von Modellen gepflegt, die wir getestet haben, und die wichtigen Parameter (verfügbarer VRAM, Quantisierung, maximale Eingabelänge) für jedes Modell aufgezeichnet. Wenn Modelle nicht laufen, enthalten Fehlerausgaben und offene Issue-Tracker oft einige Hinweise.

• Leistungstests: Ist die Leistung akzeptabel beim Streaming von Antworten über die API? Wie bereits erwähnt, hängt die Leistung stark von verfügbarem VRAM, Kontextgrößen und gleichzeitigen Benutzern ab. Dies wird am besten mit Benchmark-Tools gemessen, die reale Arbeitslasten simulieren und relevante Metriken end-to-end messen (siehe nächster Abschnitt). Insbesondere sollten sowohl Latenz (Zeit bis zum ersten Token) als auch Durchsatz (Token pro Sekunde) verfolgt werden, da Batching- und Concurrency-Einstellungen diese Ergebnisse erheblich beeinflussen können.

• Qualitätstests: Die Messung der Qualität in LLMs ist notorisch schwierig aufgrund ihres nicht-deterministischen Verhaltens und Problemen wie Halluzinationen. Während hochquantisierte Modelle möglicherweise schnellere Leistung bieten, führen sie oft zu höherer "Perplexität" – was bedeutet, dass das Modell "verwirrter" erscheint – und benutzerseitige Parameter wie "Temperatur" können die Ausgabe erheblich beeinflussen. Innerhalb der KI-Community wächst die Erkenntnis, dass die Nützlichkeit traditioneller "Evals" (LLM-Bewertungen) begrenzt ist. Methoden wie "LLM as Judge" (Verwendung von LLMs zur Bewertung anderer LLM-Ausgaben) können ihre eigenen Verzerrungen einführen. Selbst wenn Modelle in automatisierten Tests gut abschneiden, können sie immer noch mit bestimmten Prompts in der realen Nutzung kämpfen, abhängig vom Bereich. Daher bleibt menschliche Überprüfung essentiell. Der Testprozess kann halbautomatisiert werden, mit Prompts und Kontext, die über spezialisierte Tools an die API geliefert werden, und Antworten, die sowohl für automatisierte als auch für menschliche Bewertung gesammelt werden. Tools wie Promptfoo helfen, diesen Prozess zu rationalisieren und unterstützen auch sicherheitsbezogene Tests.

Wie testen Sie all das oben Genannte, wenn Sie zufällig keine Anzahl teurer H100-, L40S-Maschinen besitzen? Eine wachsende Anzahl von Hosting-Services bietet Zugang zu On-Demand-GPUs, die stundenweise abgerechnet werden – nur wenn die Maschine tatsächlich in Gebrauch ist. Die Bedingungen der Anbieter sind manchmal unklar bezüglich der Abrechnung von Maschinen, wenn sie nicht in Gebrauch sind, daher lohnt es sich zu überprüfen, ob die stündliche Abrechnung immer noch gilt, wenn Maschinen ausgeschaltet sind. Das kann immer noch teuer werden, aber wenn Sie vorher planen, was zu tun ist, und die Zeit begrenzen, in der die Maschine an ist, scheint es akzeptabel. Für uns war das Verfahren oft: Fernstart der Maschine, Einloggen und Durchführung Ihrer Tests, die Maschine wieder in den Ruhezustand versetzen. Wiederholen für bedeutende Änderungen wie Inferenz-Engine-Updates, neue Modelle oder verschiedene GPUs und darauf abzielen, Teile des Prozesses zu automatisieren, während Sie voranschreiten.

Benchmarking

Benchmark-Zahlen sollten immer mit Vorsicht genossen werden, da sich Testumgebung, Parameter und Eingaben oft so stark unterscheiden, dass sie direkte Vergleiche weniger aussagekräftig machen. Die Idee hier ist, Ihnen einen groben Eindruck davon zu geben, was Sie erwarten können, wenn Sie beliebte Modelle auf beliebten professionellen GPUs ausführen. Typischerweise gemessene Metriken umfassen Latenz und Durchsatz, oder, wie sie von Endbenutzern wahrgenommen werden, in Bezug auf "Zeit bis zum ersten Token" und "Token pro Sekunde". Um diese Zahlen zu messen, haben wir sowohl TGIs eigenes Benchmarking-Tool als auch ein internes Tool verwendet.

Wir haben TGI mit seinem Standard-Backend und den Llama- und Qwen-Modellen in verschiedenen Größen und in vor-quantisierten und on-the-fly quantisierten Varianten ausgeführt. Dies schließt das GGUF-Modellformat aus, wie es von Llama.cpp/ollama verwendet wird. (Das Llama.cpp-Backend für TGI führt zusätzliche Build-Komplexitäten ein, da es mit nativen CPU-Anweisungen auf den Zielmaschinen kompiliert werden sollte – On-Premise-Deployment würde noch herausfordernder werden, daher haben wir vorerst nicht in die Unterstützung dessen geschaut.)

Unser Testing wurde mit TGI Version 3.3.0 über drei verschiedene (einzelne!) GPU-Konfigurationen durchgeführt: NVIDIA H100 80GB HBM3, NVIDIA L40S 46GB und NVIDIA RTX A6000 48GB. Wir haben ein benutzerdefiniertes Benchmark-Tool entwickelt, das versucht, tatsächliche Nutzungsmuster unter verschiedenen Lastbedingungen zu simulieren, indem es:

• Anfragen gegen den OpenAI API-kompatiblen Chat-Completion-Endpunkt durchführt

• Gleichzeitige Benutzer über einen konfigurierbaren Zeitraum hochfährt

• Zwischen verschiedenen Prompt-Szenarien rotiert: "Best-Case"-Szenarien verwenden reguläre kleine Prompts mit niedrigen Token-Ausgabewerten und wenigen gleichzeitigen Benutzern, während "Worst-Case"-Szenarien große Prompts aus einer Prompts-Datei (Buchkapitel, die zusammengefasst werden sollen) mit hohen Ausgabe-Token-Werten und mehr gleichzeitigen Benutzern verwenden

• Eine Reihe von Metriken misst; hier berichten wir nur über End-to-End-Metriken, wie sie von Benutzern wahrgenommen werden, einschließlich Zeit bis zum ersten Token (TTFT) und Token pro Sekunde; (die berichteten Token-Metriken sind nur Annäherungen, gemessen von einem Standard-Tokenizer)

Zum Beispiel sieht TGIs Benchmark-Tool so aus:

Unser Benchmark-Tool gibt einen Bericht wie diesen aus:

Ergebniszusammenfassung

NVIDIA H100 80GB HBM3

Hardware-Konfiguration:

• Ubuntu 22.04.5 LTS, Intel CPU (16 Kerne), 196GB RAM

• NVIDIA H100 80GB HBM3

Die H100 zeigt gute Leistung für einzelne Nutzer mit dem 70B-Modell und erreicht 131ms Zeit bis zum ersten Token. Bei 4 gleichzeitigen Nutzern und großen Kontexten sinkt die Leistung erheblich auf 38,97s TTFT, was die Speicherbeschränkungen bei schweren gleichzeitigen Arbeitslasten widerspiegelt.

NVIDIA L40S 46GB

Hardware-Konfiguration:

• Ubuntu 22.04.5 LTS, AMD CPU (48 Kerne), 283GB RAM

• NVIDIA L40S 46GB

Die L40S bewältigt verschiedene Modellgrößen effektiv. Die 8B-Modelle liefern 73,92 Token/Sekunde, während das 32B-Modell 34,06 Token/Sekunde für einzelne Benutzer erreicht. Unter gleichzeitiger Last sinkt der Durchsatz erheblich – das 32B-Modell fällt auf 6,28 Token/Sekunde bei 4 Benutzern.

NVIDIA RTX A6000 48GB

Hardware-Konfiguration:

• Ubuntu 22.04.5 LTS, Intel CPU (48 Kerne), 125GB RAM

• NVIDIA RTX A6000 48GB

  Model	Quantisierung	Max Input Tokens	Scenario	Gleichzeitige Nutzer	TTFT	Tokens/sec	Max Output Tokens
  Llama 3.1 8B	EETQ (8-bit)	32,000	Best Case	1	262ms	81.01	1,024
  Llama 3.1 8B	EETQ (8-bit)	64,000	Worst Case	4	6.06s	20.21	8,000
  Llama 3.1 8B	EETQ (8-bit)	64,000	Worst Case	8	2.11s	30.40	8,000
  Llama 3.3 70B	AWQ	8,000	Best Case	4	117ms	19.41	1,024
  Qwen 2.5 14B	GPTQ Int-8	32,000	Best Case	1	85ms	46.30	1,024
  Qwen 2.5 14B	GPTQ Int-8	32,000	Worst Case	4	17.54s	10.04	8,000

Die RTX A6000 zeigt gute Leistung bei 8B-Modellen und erreicht 81,01 Token/Sekunde. Der 8-Nutzer-Test mit Llama 3.1 8B erzielte einen besseren Durchsatz als der 4-Nutzer-Test (30,40 vs 20,21 Token/Sekunde), was auf eine effizientere Stapelverarbeitung bei höherer Parallelität hindeuten könnte. Das 70B-Modell läuft, erfordert jedoch ein reduziertes Kontextfenster von 8.000 Token.

Wichtige Erkenntnisse

Modellgröße vs. Leistung: Kleinere Modelle (8B Parameter) liefern durchgängig 2-4x höheren Durchsatz als ihre größeren Gegenstücke über alle Hardware-Konfigurationen hinweg — ein kritischer Faktor für Szenarien mit gleichzeitigen Nutzern. Die 14B-Modelle bieten eine gute Balance zwischen Fähigkeiten und Leistung, während 70B-Modelle eine sorgfältige Berücksichtigung der Grenzen gleichzeitiger Nutzer erfordern.

Quantisierungsauswirkungen: AWQ- und EETQ-Quantisierungstechniken ermöglichen es größeren Modellen, auf weniger leistungsfähiger Hardware zu laufen und dabei akzeptable Leistung zu erhalten. GPTQ Int-8 zeigt gute Ergebnisse für mittelgroße Modelle. Die Auswirkung der Quantisierung auf die Antwortqualität und "Perplexität" muss letztendlich durch menschliche Überprüfung bewertet werden.

Skalierung gleichzeitiger Nutzer: Alle Konfigurationen zeigen erhebliche Leistungseinbußen bei steigender Anzahl gleichzeitiger Nutzer, insbesondere bei großen Kontextfenstern. Dies unterstreicht die Bedeutung einer ordnungsgemäßen Kapazitätsplanung für Produktionsbereitstellungen. Zu beachten ist, dass Mixture-of-Experts-Modelle (wie DeepSeek) tendenziell größere Stapelgrößen benötigen, um eine effiziente GPU-Auslastung zu erreichen, was die Latenz in Szenarien mit geringer Parallelität oder vor Ort weiter erhöhen kann.

Hardware-Überlegungen: Während die H100 die beste Rohleistung bietet, stellen die L40S und RTX A6000 kostengünstigere Alternativen für viele Anwendungsfälle dar, insbesondere beim Betrieb angemessen dimensionierter Modelle mit geeigneter Quantisierung. (Als Randnotiz: Mit der jetzt verfügbaren H200 sind die H100-Preise gefallen.)

Software und Werkzeuge

Die Benutzeroberfläche für die Interaktion mit LLM-Diensten ist ein wichtiger Teil eines KI-Systems. Obwohl einige quelloffene, einsatzbereite Chat-Benutzeroberflächen existieren, ist die Wahrscheinlichkeit hoch, dass sie Ihnen nicht gut dienen und Sie am Ende vorgefertigte Lösungen stark modifizieren müssen, um die verschiedenen Anforderungen zu erfüllen. Unternehmensumgebungen haben oft spezifische Anforderungen bezüglich Sicherheit und Zugriffskontrolle, Compliance und Integration in bestehende Systeme. Sie möchten möglicherweise auch Organisationen ermöglichen, ihre eigenen domänenspezifischen LLM-Apps zu erstellen und anzupassen und sie anderen Einheiten zugänglich zu machen.

Für basebox war es wesentlich, die verschiedenen Komponenten, die wir benötigen, mit ihren Abhängigkeiten über Docker zu betreiben. Die Herausforderung besteht darin, dass Sie ein lokal verteiltes System mit all seinen Komplexitäten verwalten müssen, wenn Komponenten miteinander interagieren und die Verarbeitung größtenteils asynchron erfolgt. Darüber hinaus stellen On-Premises-Bereitstellungen zusätzliche Herausforderungen bezüglich Installation, Hardware- und Software-Kompatibilität und Diagnose oder Offline-Fähigkeiten dar. Hier kommen maßgeschneiderte Werkzeuge ins Spiel. Für basebox ist der Bedarf an solchen Werkzeugen organisch als Teil des Entwicklungsprozesses entstanden, zum Beispiel:

• bbsetup: ein Terminal-UI-Installer, der Administratoren durch den Vor-Ort-Installationsprozess führt und mit vorverpackten Standardmodellen geliefert wird

• basecheck: ein Diagnosewerkzeug, das Hardware-Fähigkeiten, Software-Anforderungen und Konnektivität wie GPU-Treiber, Docker, Ports, Internet- und SMTP-Server-Konnektivität, Proxy-Einstellungen überprüft

• mget: ein Kommandozeilen-Tool und eine Integrationsbibliothek, die Modelldateien basierend auf einer deklarativen Beschreibung effizient herunterlädt und verwaltet

• lgen: ein Lizenzgenerierungs-Kommandozeilen-Tool und eine Integrationsbibliothek zur Kontrolle der erlaubten Anzahl von Nutzern, Token-Budgets, Ablaufzeiten

• ragsrv: ein offline- und CPU-kompatibles RAG-System mit Dokumentverarbeitungs-Pipelines, hybrider Volltext- und semantischer Suche, APIs und Webhooks

Fazit

On-Premise-KI-Bereitstellungen erfordern eine sorgfältige Balance: Feste GPU-Investitionen müssen sich schnell entwickelnde Modelle ohne die Skalierungsflexibilität der Cloud unterstützen. Unsere Erfahrung mit basebox zeigt, dass es keine Einheitslösung gibt — Hardware- und Modellentscheidungen hängen vollständig von spezifischen Arbeitslasten ab und müssen durch systematische Tests validiert werden. Mit reiferen Inferenz-Engines und besseren Werkzeugen wird On-Premise-KI für Organisationen mit regulatorischen oder Datensouveränitätsanforderungen zunehmend praktikabel.