Lokale KI: Hardwarebedarf für Modelle, Kontext und parallele Nutzung

Welche Aufgabe soll auf der Hardware laufen?

Schreibe zuerst die Komponenten deiner Anwendung auf. Ein Textmodell, eine Dokumentensuche und eine Telefonassistenz stellen unterschiedliche Aufgaben an die Umgebung. Bei Telefonie kommen beispielsweise Spracherkennung, Sprachausgabe und die Anbindung des Gesprächs hinzu.

Notiere pro Komponente Modell oder Dienst, genaue Version, Ausführungsort und erwartete Last. Prüfe, ob Dienste gleichzeitig dieselbe GPU oder denselben Arbeitsspeicher beanspruchen. Eine Angabe für das Sprachmodell allein ist keine Dimensionierung der Gesamtanwendung.

Wenn der Arbeitsablauf noch offen ist, beginne mit dem Entscheidungscheck für lokale KI im Unternehmen. Hardware lässt sich sinnvoll planen, sobald Eingaben, gewünschte Ergebnisse und Betriebsverantwortung feststehen.

Modellgewichte: eine nachvollziehbare Speicherrechnung

Für eine vereinfachte Rechnung gilt: Speicher der Gewichte in Byte = Anzahl gespeicherter Parameter × Bits je Parameter ÷ 8. Die folgenden Werte setzen genau acht Milliarden gespeicherte Parameter und ein einheitliches Speicherformat voraus. Ein GB bedeutet hier eine Milliarde Byte; ein GiB entspricht 1.073.741.824 Byte.

Das Beispiel ist eine Rechnung, kein bestimmtes Modell und kein Messwert. Es berücksichtigt weder Quantisierungs-Metadaten noch nicht quantisierte Schichten, Aktivierungen, Kontextspeicher oder Laufzeit-Overhead. Gerade bei quantisierten Modellen muss die reale Größe des gewählten Artefakts zusätzlich geprüft werden.

Was Quantisierung verändert

Quantisierung verwendet für Teile des Modells eine Darstellung mit geringerer Präzision. Die Transformers-Dokumentation zu bitsandbytes, Version 4.55.4 beschreibt beispielsweise quantisierte lineare Schichten und den Umgang mit anderen Speicherformaten. Die Präzision der gespeicherten Gewichte und die Präzision einer Berechnung müssen dabei nicht identisch sein.

Für die Auswahl brauchst du das konkrete Modellartefakt, das Quantisierungsverfahren und eine kompatible Laufzeit. Prüfe anschließend dieselben fachlichen Fragen wie mit der Vergleichskonfiguration. Eine kleinere Datei ist für sich genommen kein Nachweis gleicher Antwortqualität oder höherer Geschwindigkeit.

Kontext und Gleichzeitigkeit kommen zum Modell hinzu

Eine Anfrage enthält neben der eigentlichen Frage oft Systemanweisungen, Gesprächsverlauf und gefundene Dokumentabschnitte. Bei der Erzeugung kommen Ausgabetokens hinzu. Halte deshalb sowohl typische als auch längere Eingaben fest und plane die erwartete Antwortlänge mit ein.

Der KV-Cache speichert bei üblichen autoregressiven Transformer-Modellen bereits berechnete Schlüssel und Werte für die weitere Erzeugung. Seine Auslegung hängt von Modellarchitektur, Sequenzlänge, Parallelität und Speicherformat ab. Die Transformers-Dokumentation zum Caching erläutert dieses Prinzip.

Als konkretes Laufzeitbeispiel beschreibt vLLM 0.10.2, dass begrenzte Kontextlänge und maximale Batchgröße Speicher sparen können; CUDA-Graphen können zusätzlichen GPU-Speicher beanspruchen. Das sind Eigenschaften dieser dokumentierten Laufzeit, keine gemessene smao Kapazitätszusage.

Arbeitsblatt für die technische Dimensionierung

Fülle das Arbeitsblatt aus, bevor du aus einer Modellbeschreibung eine Hardwareempfehlung ableitest. Unbekannte Werte bleiben als Mess- oder Klärungsaufgabe stehen. Ein pauschaler Sicherheitsaufschlag würde ohne Lastprofil Genauigkeit vortäuschen.

Kapazität prüfen: Antwortzeit und Durchsatz getrennt betrachten

Lege vor dem Test fest, welche Wartezeit für deinen Arbeitsablauf akzeptabel ist. Erfasse Zeitpunkt des Eingangs, Beginn der Ausgabe, Abschluss und Fehler. Protokolliere auch, ob Anfragen warten müssen. Ein einzelner schneller Durchlauf sagt wenig über ein System aus, das gleichzeitig weitere Aufgaben bearbeitet.

Vergleiche nur Messreihen mit denselben Modellrevisionen, Laufzeiteinstellungen, Eingaben und Ausgabegrenzen. Beschreibe Aufwärmphase und Testdauer. Wiederhole die Versuche und behalte die Einzelwerte, damit ein Mittelwert langsame oder fehlgeschlagene Anfragen nicht verdeckt.

Für Telefonassistenz sollte die Abnahme den gesamten Gesprächsweg enthalten: vom Ende einer Äußerung bis zur hörbaren Antwort, einschließlich Spracherkennung, Wissenssuche und Sprachausgabe. Tokens pro Sekunde eines isolierten Textmodells lassen sich nicht unmittelbar in parallele Telefonate umrechnen.

• Konfiguration und Testdaten vor dem Lauf unverändert festgehalten.
• Einzelanfrage und vereinbarte gleichzeitige Last geprüft.
• Antwortbeginn, Abschluss, Fehler und Warteschlangen protokolliert.
• Speicherbedarf beim Laden und unter Last erfasst.
• Fachliche Qualität und menschliche Übergabe separat bewertet.

Was das für smao On Premises bedeutet

Für smao On Premises wird die Dimensionierung anhand der Zielumgebung und des Telefonprozesses vereinbart. Die Referenzbereitstellung nutzt Linux und Docker; daraus folgt keine allgemeine GPU-Mindestanforderung. Telefonie-Gateway, Netzwerk und Integrationen gehören zur projektbezogenen Prüfung.

Die Architekturseite beschreibt die Datenpfade und Betriebsmodelle. Für die Vorbereitung eines Projekts sind vorhandene Hardware, gewünschte Gleichzeitigkeit, Gesprächsablauf und angebundene Systeme hilfreicher als eine isolierte Modellgröße.

Rechenstand und Grenzen

Die Speicherwerte wurden aus der angegebenen Formel berechnet und auf zwei Dezimalstellen gerundet. Die verlinkten Versionsstände dienen als technische Referenzen; sie sind keine Aussage über die aktuelle smao Runtime-Version. Dieser Leitfaden enthält keine gemessenen Hardwareempfehlungen oder Zusagen zur Gesprächskapazität. Ein veröffentlichter Referenztest muss seine vollständige Konfiguration und Messmethode mitliefern.