Lokale LLM.
Passend dimensioniert.
Vom passenden Modell bis zum betreuten KI-Dienst: DAXS plant lokale LLM-Infrastruktur, prüft Hardware unter realer Last und integriert die Lösung in Ihre bestehende IT.
Ein KI-Server beginnt mit dem Lastprofil.
Ein lokales Sprachmodell kann interne Texte aufbereiten, Codeentwürfe unterstützen oder als Teil einer Wissenssuche arbeiten. Für eine brauchbare Lösung müssen Modellqualität, zulässige Datenwege und die erwartete Nutzung zusammenpassen. DAXS nimmt diese Anforderungen auf, plant die Infrastruktur und übernimmt Installation, Integration sowie den vereinbarten Betrieb – gemeinsam mit Ihrer IT oder als abgegrenzten Leistungsbaustein.
Aufgabe und Qualität
Welche Fragen, Sprachen, Dokumente oder Codeaufgaben soll die Lösung beherrschen? Ein kurzer Chat und eine Analyse langer Unterlagen verlangen unterschiedliche Modelle und Kontexte.
Nutzung und Wartezeit
Wie viele Anfragen kommen gleichzeitig? Wie schnell muss die erste Reaktion beginnen, und wie lange darf eine vollständige Antwort dauern? Gelegentliche Einzelanfragen und ein dauerhaft genutzter Teamdienst brauchen andere Reserven.
Daten und Betrieb
Welche Quellen und Funktionen sind freigegeben? Wo dürfen Modell, Suchindex, Protokolle und Sicherungen liegen? Wer betreut Updates und Fehler, und welcher Rückweg wird benötigt?
Anwendung, Inferenz und Betrieb sauber verbinden.
Die Benutzeroberfläche ist nur ein Teil. Davor liegen Identitäts- und Zugriffskontrollen; dahinter arbeiten Inferenzdienst, Modellablage und gegebenenfalls Wissenssuche oder Unternehmensschnittstellen. Beobachtung, Updates und Wiederherstellung gehören in denselben Plan.
Die Zeichnung zeigt eine mögliche Architektur, kein tatsächliches Kundennetz. Ein Reverse Proxy kann TLS und den Eingang absichern. Die Anwendung muss trotzdem Benutzerrechte durchsetzen. Modell-APIs werden auf die benötigten Netze und Funktionen begrenzt; ein erreichbarer Inferenzport ist noch kein fertiger Unternehmensdienst.
Mehr als die Größe der Modelldatei.
Für die Auswahl betrachten wir Gewichte, Laufzeitbedarf, Kontext, Parallelität und den gesamten Datenweg. Eine GPU kann genügend Speicher haben und für die gewünschte Antwortzeit trotzdem ungeeignet sein. Umgekehrt kann ein kleineres, gut ausgewähltes Modell die Aufgabe wirtschaftlicher lösen.
| Baustein | Was wir prüfen | Warum es zählt |
|---|---|---|
| GPU und VRAM | Architektur, Treiber, Inferenzbackend, unterstützte Rechenformate, Speichergröße und Bandbreite. | Gewichte und KV-Cache brauchen Platz. Rechenleistung und Speichertransfers beeinflussen verschiedene Arbeitsphasen; ein beworbener TOPS-Wert allein beschreibt die Anwendung nicht. |
| Eine oder mehrere GPUs | Modellaufteilung, Verbindung zwischen GPUs, PCIe-Anbindung, Energie und Kühlung. | VRAM wird nicht automatisch zu einem frei nutzbaren gemeinsamen Speicher. Aufteilung und Synchronisierung müssen vom gewählten Stack unterstützt werden; zusätzliche GPUs können neue Engpässe schaffen. |
| CPU und System-RAM | Runtime, Tokenisierung, Datenaufbereitung, parallele Prozesse sowie gegebenenfalls CPU-Inferenz oder Offloading. | Auslagerung kann ein Modell ausführbar machen, verändert aber das Leistungsprofil. Transfers zwischen RAM und GPU können die Antwort verlangsamen. Auch ein GPU-Server braucht passende CPU- und RAM-Reserven. |
| NVMe und Speicher | Modellstände, Ladezeiten, Suchindex, Importdaten, Protokolle, freie Kapazität und Sicherungen. | Schnelle NVMe-SSDs helfen beim Modellladen und bei bestimmten Datenoperationen. Die Token-Erzeugung eines vollständig im GPU-Speicher liegenden Modells wird vor allem durch Rechen-, Speicher- und Laufzeitfaktoren bestimmt. |
| Netz und Versorgung | Anbindung, erlaubte Datenwege, Platz, Strombedarf, Abwärme und Wartungszugang. | Die beste einzelne Rechenkomponente hilft wenig, wenn der Dienst unter realer Last thermisch, organisatorisch oder im Datenzugriff begrenzt wird. |
Eine Rechenhilfe – keine Kaufempfehlung.
Die reine Gewichtsuntergrenze lässt sich grob mit Parameterzahl × Bit pro Gewicht ÷ 8 einordnen. Ein hypothetisches Modell mit acht Milliarden Parametern und vier Bit pro Gewicht ergibt rechnerisch vier Gigabyte, also rund 3,73 GiB.
Dazu kommen Quantisierungsmetadaten, gegebenenfalls höher aufgelöste Modellteile, KV-Cache, Arbeitsbereiche und die Runtime. Dieser Wert sagt deshalb ausdrücklich nicht, welche VRAM-Kapazität für Ihre Anwendung genügt. Bei Modellen mit Expertenarchitektur müssen zudem aktive Rechenanteile und insgesamt vorzuhaltende Gewichte unterschieden werden.
Eine kurze Antwort ist ein anderer Test als ein Teamdienst.
Das Kontextfenster umfasst die Informationen, die ein Modell für eine Anfrage berücksichtigen kann. Dazu gehören je nach Anwendung Anweisungen, Gesprächsverlauf, abgerufene Dokumentteile und die geplante Ausgabe. Ein nominell großes Kontextfenster garantiert weder passende Hardware noch zuverlässig genutzte Informationen.
KV-Cache
Der Key-Value-Cache hält Zwischenzustände der Aufmerksamkeit bereit. Sein Bedarf hängt unter anderem von Modellarchitektur, Datentyp, tatsächlich belegtem Kontext und gleichzeitig aktiven Sequenzen ab. Mehr Kontext und mehr Parallelität erhöhen häufig den Speicherbedarf deutlich.
Prefill und Decode
Beim Prefill verarbeitet das Modell den Eingabekontext; beim Decode entstehen weitere Tokens. Beide Phasen belasten die Hardware unterschiedlich. Lange Dokumente können die Zeit bis zum ersten Token erhöhen, auch wenn die anschließende Ausgabe flüssig erscheint.
Batching und Warteschlange
Gemeinsame Verarbeitung kann den Gesamtdurchsatz erhöhen. Gleichzeitig können einzelne Benutzer länger warten. Reservierte Kapazität, Warteschlangen, Limits und eine passende Planung der Parallelität gehören deshalb zum Entwurf.
Wir messen den tatsächlichen Anwendungsfall.
Ein Pilot umfasst typische kurze und lange Anfragen sowie gleichzeitige Zugriffe. Dabei betrachten wir Time to First Token, vollständige Antwortzeit, Ausgaberate, Warteschlange, Fehlerrate und Speicherbelegung. Tokens pro Sekunde werden nur zusammen mit Modellstand, Quantisierung, Kontext, Last und Messbedingungen sinnvoll vergleichbar.
Der Stack folgt dem Modell und der Nutzung.
Ollama, llama.cpp und vLLM sind mögliche Bausteine. Auswahl und Konfiguration richten sich nach Modellunterstützung, Hardware, gewünschter Parallelität, Betrieb und Integration. Wir prüfen den konkreten Versionsstand, statt einen allgemeinen Installationsbefehl zur Produktionsarchitektur zu erklären.
Ollama
Ein möglicher Einstieg für Modellverwaltung und lokale Bereitstellung. Modellablage, freigegebene Modelle, Kontext, Parallelität und die Absicherung des Dienstes müssen zur Umgebung passen.
llama.cpp
Ein flexibler Baustein für passende Modelle auf unterschiedlichen CPU-/GPU-Backends, mit quantisierten Formaten und Serverbetrieb. Hardwareunterstützung, Aufteilung und tatsächlich benötigte API-Funktionen werden praktisch geprüft.
vLLM
Eine Option für geeignete serverseitige Inferenz- und Lastprofile. Scheduling, KV-Cache, Batching und gegebenenfalls mehrere GPUs werden gemeinsam abgestimmt. Höherer Gesamtdurchsatz ist nicht mit kürzerer Wartezeit jeder einzelnen Anfrage gleichzusetzen.
Container, virtuelle Maschine oder eigener Host?
Container können Softwarestände reproduzierbar bündeln. Eine virtuelle Maschine kann die Umgebung zusätzlich organisatorisch und technisch abgrenzen. Der geeignete Weg hängt von Gerätedurchreichung, Treibern, Wartung und den vorhandenen Betriebsverfahren ab. Eine kompatible API erleichtert die Anbindung, ersetzt aber keinen Funktionstest mit Ihrer Anwendung.
Wann passt Proxmox mit GPU-Passthrough?
GPU-Passthrough weist eine geeignete physische GPU einer virtuellen Maschine zu. Dafür müssen unter anderem Plattform und Firmware, IOMMU-Gruppen, Host- und Gasttreiber sowie das Verhalten beim Zurücksetzen des Geräts passen. Wir prüfen die konkrete Kombination vor einer Zusage.
Eine zugewiesene GPU ist nicht automatisch flexibel zwischen mehreren VMs teilbar. vGPU und direkte Durchreichung sind unterschiedliche Konzepte mit eigenen Voraussetzungen und gegebenenfalls Lizenzbedingungen. Auch Wartung, Sicherung und ein möglicher Hostwechsel brauchen einen passenden Ablauf; eine pauschale Live-Migrationszusage wäre unangebracht.
Infrastruktur und Virtualisierung · Proxmox-Migration einordnen
Das passende Modell muss die Aufgabe bestehen.
Wir vergleichen Modelle mit freigegebenen Beispielen aus dem späteren Einsatz: etwa deutschsprachigen Fachfragen, Dokumentauszügen, mehrsprachigen Anfragen oder einer konkreten Skriptaufgabe. Ein Coding-Modell und ein Embedding-Modell erfüllen unterschiedliche Aufgaben. Für eine Wissenssuche müssen Suche, Embeddings und Antwortmodell zusammenpassen.
Quantisierung reduziert häufig den Speicherbedarf. Auswirkungen auf Antwortqualität, Werkzeugaufrufe und Geschwindigkeit werden am gewählten Format geprüft. Ein größeres Modell ist nicht automatisch die bessere oder wirtschaftlichere Wahl. Ebenso wenig belegt ein langer maximaler Kontext, dass das Modell jede darin enthaltene Information zuverlässig verwendet.
- Lizenz: gewählte Modellgewichte, kommerzielle Nutzung, Weitergabe und notwendige Hinweise konkret prüfen; ein einfacher Download ersetzt diese Prüfung nicht.
- Version: Modell, Quantisierung, Tokenizer und Laufzeit nachvollziehbar festhalten.
- Abnahme: fachliche Eignung, unzulässige Antworten, Sprachqualität und Fehlerfälle mit einem wiederholbaren Fragenbestand prüfen.
- Änderungen: neue Modellstände zuerst testen, einen brauchbaren Rückweg erhalten und Suchindizes bei geänderten Embeddings passend neu erzeugen.
Lokal, extern oder in einer passenden Kombination.
Eigene Hardware kann bei geeigneter Auslastung, klaren Datenanforderungen und vorhandenem Betriebsrahmen sinnvoll sein. Ein externer Dienst kann bei schwankender Nutzung, besonderen Modellfähigkeiten oder geringer eigener Betriebskapazität besser passen. Hybrid verbindet gezielt abgegrenzte Aufgaben und Datenwege.
Der Vergleich umfasst Anschaffung beziehungsweise Nutzung, Strom und Kühlung, Lizenzen, Integration, Updates, Betreuung, Reserve und Ausfallfolgen. Lokale Verarbeitung ist keine automatische Sicherheits- oder DSGVO-Garantie: auch Modelle, Embeddings, Telemetrie, Updates, externe Werkzeuge und Protokolle müssen zum vereinbarten Datenkonzept passen.
Wir planen zuerst einen überschaubaren Pilot mit messbaren Anforderungen. Aus dessen Ergebnis entsteht die Entscheidung für Ausbau, Anpassung oder eine einfachere Alternative. Weitere Grundlagen finden Sie unter Cloud & SaaS.
Ein betreuter Dienst braucht nachvollziehbare Zuständigkeiten.
DAXS kann Hardware und Software planen, installieren, an vorhandene Identitäten und Anwendungen anbinden und den vereinbarten laufenden Betrieb übernehmen. Dazu gehören Erreichbarkeit und Ressourcenbeobachtung, Versionspflege, Fehlerbehandlung und Dokumentation. Welche Verfügbarkeit und Reaktionswege benötigt werden, wird konkret vereinbart.
Wir legen fest, welche Konfigurationen, Anwendungskomponenten, Indexdaten und gegebenenfalls angepassten Modelle gesichert werden. Wiederbeschaffbare Modellgewichte und schützenswerte betriebliche Daten haben unterschiedliche Sicherungsanforderungen. Ein Wiederherstellungstest gehört zum passenden Betriebskonzept.
Anforderungsaufnahme, Architekturvorschlag, Modell-/Lasttest, dokumentierte Datenwege und eine nachvollziehbare Empfehlung für Hardware, Betriebsform und nächste Integrationsschritte.
Das klären wir im Gespräch.
Wie viel VRAM braucht ein lokales LLM?
Das hängt von Modell und Quantisierung, Runtime, Kontext sowie gleichzeitigen Anfragen ab. Die Modelldatei allein reicht als Grundlage nicht. Wir testen die gewünschte Aufgabe einschließlich langer Anfragen und Lastspitzen, bevor wir eine konkrete Ausstattung empfehlen.
Ist eine zweite GPU automatisch schneller?
Nein. Der gewählte Stack muss die Aufteilung unterstützen. Verbindungen zwischen den GPUs, Synchronisierung und Modellarchitektur beeinflussen das Ergebnis. Mehr Speicher kann die Ausführung ermöglichen, ohne jede einzelne Antwort zu beschleunigen.
Kann ein vorhandener Proxmox-Server genutzt werden?
Das kann passen, wenn Hardware, IOMMU-Gruppen, Treiber und GPU-Durchreichung geeignet sind. Zusätzlich müssen Reserven für andere Dienste und die Abläufe für Wartung, Sicherung und Wiederherstellung stimmen. Wir prüfen die vorhandene Plattform konkret.
Werden interne Dokumente in das Modell trainiert?
Für eine Wissenssuche ist das häufig nicht erforderlich. RAG sucht passende, zugelassene Dokumentteile und gibt sie als Kontext an das Modell. Eine Anpassung der Modellgewichte ist eine andere Maßnahme und wird getrennt begründet.
Wann ist ein externer Dienst wirtschaftlicher?
Bei geringer oder stark schwankender Nutzung, besonderen Modellanforderungen oder fehlender Betriebskapazität kann ein externer Dienst besser passen. Wir vergleichen Kosten, Datenwege, Qualität und Betrieb über den geplanten Nutzungszeitraum.
Modelle, Last und Kosten gemeinsam beobachten.
Neben GPU-Auslastung und Antwortzeit betrachten wir die Kosten pro brauchbarer Aufgabe. Ein Modellupdate erhält vor dem Einsatz einen Vergleich mit dem freigegebenen Testbestand. Fehlerraten, Warteschlangen, Speichergrenzen und Ausfälle brauchen benannte Verantwortliche und einen Rückweg. Ein externer Ersatzdienst kommt nur infrage, wenn Datenklasse und Freigabe ihn erlauben.
Besprechen wir Ihren Anwendungsfall.
Was soll einfacher werden, welche Daten sind beteiligt und welche Systeme sind bereits vorhanden? Daraus entwickeln wir einen sinnvollen Einstieg und einen überschaubaren nächsten Schritt.