KI-Training & LLM-Optimierung in Kilchberg ZH

Zuerst legen wir fest, welche Eingaben auftreten, welches Ergebnis gebraucht wird und woran sich ein Fehler erkennen lässt. Ein begrenzter Versuch zeigt, was ein geeignetes Basismodell bereits erreicht. Daraus entstehen die nächsten Schritte für Training, Optimierung und Einbindung. Klare Regeln und eine menschliche Freigabe bleiben dort erhalten, wo die Aufgabe sie braucht.

Gute Trainingsbeispiele bilden die tatsächliche Aufgabe ab: typische Formulierungen, Sprachen, gewünschte Ausgabeformate und schwierige Randfälle. Wir bereinigen und strukturieren diese Daten, prüfen widersprüchliche Antworten und trennen Trainings-, Validierungs- und Testdaten. Inhaltlich nahezu gleiche Beispiele gehören nicht auf beide Seiten eines Tests.

Mit LoRA werden zusätzliche Adapter eines vorhandenen Sprachmodells trainiert. So lässt sich dessen Verhalten auf eine klar umrissene Aufgabe abstimmen. Die Auswahl des Basismodells, der Trainingsdaten und der Einstellungen richtet sich nach dem gewünschten Ergebnis und dem verfügbaren Speicher.

Wir vergleichen das Basismodell und den trainierten Adapter anhand zurückgehaltener Beispiele. Entscheidend sind fachlich richtige Ergebnisse, gültige strukturierte Ausgaben und ein verlässlicher Umgang mit unvollständigen oder mehrdeutigen Eingaben. Auch bisher funktionierende Fälle werden erneut geprüft, damit eine Verbesserung nicht unbemerkt andere Fähigkeiten verschlechtert.

• Aufgabenspezifische Qualitätskriterien und Fehlerfälle
• Getrennte Prüfungen nach Sprache und Eingabetyp
• Vergleich mit dem Basismodell und früheren Adapterständen

Die Gewichte eines Sprachmodells lassen sich mit weniger Bits darstellen. Dadurch sinkt ihr Speicherbedarf und ein Modell kann auf kleinere Geräte passen. Wie sich die gewählte Quantisierung auf Ergebnisqualität und Geschwindigkeit auswirkt, prüfen wir mit der tatsächlichen Anwendung. Auch Laufzeitspeicher und Kontext müssen neben den Gewichten auf dem Gerät Platz finden.

Beim schrittweisen Erzeugen einer Antwort speichert ein Transformer bereits berechnete Schlüssel- und Wertzustände im KV-Cache. So müssen frühere Tokens nicht für jeden neuen Schritt vollständig neu verarbeitet werden. Bei langen Kontexten kann dieser Zwischenspeicher erheblich wachsen.

Eine passende KV-Cache-Quantisierung kann den Speicher dieser Zustände senken. Sie betrifft einen anderen Teil des Systems als die Quantisierung der Modellgewichte. Unterstützung, Qualitätsfolgen und zusätzlicher Rechenaufwand hängen von Modell und Laufzeit ab und werden gesondert bewertet.

Gleiche Anweisungen oder ein unveränderter Dokumentanfang tauchen oft in vielen Anfragen auf. Präfix-Caching verwendet dafür bereits berechnete KV-Zustände erneut. Das spart Arbeit beim Einlesen der Eingabe, dem Prefill, und kann die Wartezeit bis zur ersten Ausgabe verkürzen.

Wiederverwendet wird nur ein exakt passender Token-Anfang mit passender Modell-, Adapter-, Tokenizer- und Cache-Konfiguration. Ein ähnlicher Text genügt nicht. Wir prüfen Cache-Treffer und neue Eingaben getrennt; die Geschwindigkeit beim anschliessenden Erzeugen neuer Tokens ist eine eigene Messgrösse.

Manche wiederkehrenden Aufgaben erlauben, ein geprüftes Ergebnis direkt aus einem Anwendungscache zu liefern. Ein passender Treffer spart dann den gesamten Modellaufruf. Gespeichert wird dabei die fertige Antwort oder strukturierte Ausgabe; beim Präfix-Caching werden dagegen interne Rechenzustände wiederverwendet.

Der Cache muss Eingabe, Kontext, Datenstand und Zugriffsrechte berücksichtigen. Ändern sich Daten, Modell oder Regeln, werden betroffene Ergebnisse ungültig. Welche Resultate überhaupt gespeichert werden dürfen und wie lange, gehört zum Entwurf der Anwendung.

Training und Inferenz werden mit dem Verhalten der Anwendung verbunden: Modell und Adapter laden, Ausgaben prüfen, lange Vorgänge abbrechen und Fehler verständlich behandeln. Für die lokale Umsetzung auf dem Mac arbeiten wir mit MLX. Modellversionen, Aktualisierung und Speichergrenzen gehören ebenso dazu wie die Bedienung.

In Swiftli Smart HR übersetzen eigene Sprachadapter Eingaben in strukturierte Planungsbedingungen. Unser Entwicklungsbericht vom August 2026 beschreibt den Wechsel zu einem quantisierten Modell, die vier Sprachadapter und die Prüfung der Modell-Lieferkette. Er benennt auch den damaligen Stand und offene Arbeit.

Wir bewerten Qualität und Reaktionszeit gemeinsam auf der vorgesehenen Hardware. Die Zeit bis zum ersten ausgegebenen Token, kurz TTFT, zeigt einen anderen Teil des Ablaufs als die Decode-Rate beim Erzeugen weiterer Tokens. Hinzu kommen die Zeit bis zum brauchbaren Ergebnis und der maximale Speicherbedarf.

Vergleiche verwenden dokumentierte Modell- und Adapterstände, Quantisierung, Eingabelängen und Cache-Zustände. Ein frischer Start und eine wiederholte Anfrage werden getrennt gemessen. So wird sichtbar, welche Optimierung Ihrer Aufgabe tatsächlich hilft.