Serie: KI-Technologie aus China KI-Offensive von China: Implementierung der Open-Weight-Modelle

Anbieter zum Thema

CHINABRAND Consulting Ltd Ndl. München

FIS Informationssysteme und Consulting GmbH

Kendox AG

Yorizon GmbH & Co. KG

Mithilfe der Open-Weight-Modelle wie GLM 5.2 wird der lokale Betrieb leistungsfähiger chinesischer KI für europäische Unternehmen technisch möglich. Die Modellgewichte können heruntergeladen, in einer eigenen oder vertrauenswürdigen Infrastruktur bereitgestellt und mit internem Wissen verbunden werden.

Bei der Implementierung der Open-Weight-Modelle ist zu berücksichtigen, dass zwischen dem erfolgreichen Test im Labor und einem belastbaren System ein erheblicher Integrationsaufwand liegt. Ein Open-Weight-Modell ist keine fertige Geschäftsanwendung. Wer lediglich Gewichte auf einen GPU-Server lädt und eine Chatoberfläche davorsetzt, produziert einen Demonstrator und keine produktionsreife Plattform. Die Implementierung sollte deshalb nicht beim Modell beginnen, sondern beim Anwendungsfall. Danach folgen Architektur, Datenanbindung, Sicherheitsmodell, Evaluierung und Betrieb. Diese Reihenfolge verhindert die häufigsten Fehler wie überdimensionierte Infrastruktur, unklare Verantwortlichkeiten und Agenten mit zu weitreichenden Berechtigungen. Acht Schritte sind für die erfolgreiche Implementierung der Open-Weight-Modelle erforderlich:

1. Mit einem begrenzten Anwendungsfall starten

Der erste Schritt ist die Auswahl einer Aufgabe, deren Nutzen und Risiko sich messen lassen. Geeignet sind Prozesse mit klaren Eingaben, überprüfbaren Ergebnissen und begrenzten Folgen eines Fehlers, beispielsweise die Suche in Wartungsdokumentationen, die Klassifikation interner Anfragen oder die Unterstützung bei der Codeanalyse. Ungeeignet für den Einstieg sind Anwendungen, die Produktionsanlagen steuern, Zahlungen auslösen oder Personalentscheidungen vorbereiten. Je schwerer ein Ergebnis zu überprüfen ist, desto riskanter wird das Pilotprojekt.

Vor der technischen Umsetzung benötigt jeder Anwendungsfall ein kurzes Profil. Welche Aufgabe soll das System lösen? Welche Daten darf es verwenden? Wie wird die Qualität gemessen? Welche Fehler sind tolerierbar? Wer trägt die fachliche Verantwortung? Und unter welchen Bedingungen wird der Betrieb gestoppt?

2. Open-Weight-Modelle: Nicht automatisch das größte Modell wählen

GLM 5.2 ist auf lange, mehrstufige Aufgaben, Coding und Werkzeugnutzung ausgelegt. Seine Größe stellt jedoch hohe Anforderungen an Speicher, Beschleuniger und verteilte Inferenz. Der Hersteller nennt unter anderem vLLM und SGLang als unterstützte Laufzeitumgebungen. Solche Frameworks können das Modell über mehrere GPUs verteilen und eine OpenAI-kompatible Schnittstelle bereitstellen.

Für viele Aufgaben ist ein Flaggschiffmodell dennoch nicht die wirtschaftlichste Wahl. Ein kleineres Modell kann bei Klassifikation, Extraktion oder standardisierten Antworten ausreichen. Entscheidend sind Tests mit repräsentativen Unternehmensdaten sowie Kriterien wie Latenz, Durchsatz, Speicherbedarf und Betriebsaufwand.

Quantisierte Varianten können die Hardwareanforderungen reduzieren, verändern aber möglicherweise Qualität oder Stabilität. Auch lange Kontextfenster sind kein Freifahrtschein. Je mehr Dokumente ungefiltert in einen Prompt gelangen, desto höher werden Kosten, Latenz und das Risiko, dass wichtige Informationen im Kontext untergehen.

3. Open-Weight-Modelle: Passende Zielarchitektur definieren

Eine belastbare Unternehmensarchitektur trennt mindestens fünf Ebenen: Modellserver, Integrationsschicht, Wissenszugriff, Werkzeugausführung und Benutzeranwendung. Das Modell sollte nicht direkt aus jeder Anwendung angesprochen werden. Eine zentrale Integrationsschicht übernimmt Authentifizierung, Kontingente, Protokollierung, Prompt-Vorlagen, Modellrouting und Sicherheitsregeln. Dadurch lassen sich die Open-Weight-Modelle austauschen, ohne alle Fachanwendungen neu zu entwickeln. Ein interner Dienst kann je nach Aufgabe zwischen GLM 5.2, einem kleineren lokalen Modell und einem freigegebenen Cloudmodell wählen.

Ebenso wichtig ist die Trennung von Entwicklungs-, Test- und Produktionsumgebung. Modellgewichte, Container und Konfigurationen dürfen nicht ungeprüft aus einem Entwicklernotebook in die Produktion übernommen werden. Produktive Artefakte müssen versioniert, geprüft und über einen kontrollierten Freigabeprozess verteilt werden.

4. Unternehmenswissen über RAG anbinden

Für die meisten Implementierungen ist Retrieval-Augmented Generation sinnvoller als sofortiges Fine-Tuning. Bei RAG sucht das System zunächst relevante Informationen in einer freigegebenen Wissensbasis und übergibt nur die gefundenen Ausschnitte an das Modell. So lassen sich Handbücher, Richtlinien, technische Spezifikationen oder Tickets nutzen, ohne das Grundmodell neu zu trainieren.

Die Qualität einer RAG-Anwendung hängt von der Aufbereitung der Dokumente ab. Veraltete Versionen, fehlende Metadaten und schlechte Segmentierung führen zu unzuverlässigen Antworten. Dokumente benötigen Eigentümer, Gültigkeitsangaben und Zugriffsrechte. Ein Modell darf keine Information finden, die der Benutzer im Quellsystem nicht sehen dürfte. Antworten sollten Fundstellen ausweisen. Das erleichtert die fachliche Prüfung und macht sichtbar, ob eine Aussage auf Unternehmenswissen oder auf den allgemeinen Modellparametern beruht. Für sensible Anwendungen kann das System angewiesen werden, ohne geeignete Quelle keine definitive Antwort zu geben.

Serie: KI-Technologie aus China

KI-Offensive von China in der Kreislaufwirtschaft – Teil 27