Wer im Jahr 2023 oder 2024 ernsthaft versucht hat, ein eigenes LoRA-Modell zu trainieren – sei es mit kohya_ss, Axolotl oder einer anderen PEFT-basierten Toolchain – weiß, dass zwischen Theorie und Praxis oft eine tiefe Schlucht liegt. Auf dem Papier klingt es simpel: Ein Basismodell laden, eigene Trainingsdaten vorbereiten, die Parameter anpassen, und los geht’s. In der Realität endet es häufig in einem Dschungel aus Python-Versionen, CUDA-Fehlern, inkonsistenten Bibliotheken und fehlerhaften Speicherformaten. Man wechselt zwischen safetensors, ckpt, GGUF oder neuerdings MLX, ohne immer zu wissen, welches Format gerade kompatibel ist – und warum nicht. Selbst kleine Änderungen im Setup können ganze Trainingsläufe zum Absturz bringen, und wer ein Modell in einer anderen Umgebung verwenden will, steht oft vor der nächsten Konvertierungsrunde.
Gerade in dieser Situation beginnt man, die wahre Bedeutung des Begriffs „Low-Rank Adaptation“ zu verstehen: Nicht nur, weil man Modelle in niedrigem Rang anpasst, sondern weil man selbst demütig wird – gegenüber der Komplexität dieser Systeme. Und doch ist genau diese Methode heute der Schlüssel, um große Sprachmodelle effizient, ressourcenschonend und domänenspezifisch anzupassen.
Nun betritt Claris mit FileMaker 2025 die Bühne – ein Umfeld, das bislang für ganz andere Dinge bekannt war: Datenbanklösungen, Geschäftsprozesse, klar strukturierte Workflows.
Und plötzlich taucht dort ein Scriptstep auf, der schlicht „Fine-Tune Model“ heißt. Ein Befehl, der das Wort „LoRA“ in einem Atemzug mit „FileMaker“ nennt. Wer die letzten Jahre mit klassischen LoRA-Trainings verbracht hat, reibt sich da unweigerlich die Augen. Denn die Frage liegt auf der Hand: Kann das wirklich funktionieren – und wenn ja, auf welchem Niveau?
Diese Neugier ist berechtigt. Denn während man früher stundenlang in der Kommandozeile hantierte, bietet FileMaker nun die Aussicht auf ein Training „per Klick“ – direkt in einer Umgebung, die ohnehin die Daten enthält, mit denen man trainieren will. Ein Paradigmenwechsel also: weg vom experimentellen Labor hin zum produktiven Werkzeugkasten. Aber natürlich bleibt Skepsis angebracht. Denn so charmant diese Vorstellung ist – die eigentliche Frage lautet: Was geschieht dabei technisch? Handelt es sich um ein echtes, vollwertiges LoRA-Feintuning, oder um eine abstrahierte, vereinfachte Variante? Und wie unterscheiden sich die Ergebnisse qualitativ von einem Training, das man mit klassischen Methoden durchführt?
Bevor man das beurteilen kann, lohnt sich ein kurzer Blick zurück – auf das Prinzip selbst, auf die Idee hinter LoRA, die uns erlaubt hat, große Modelle auf kleinem Raum neu zu denken.
Zu den neuen KI-Funktionen aus FileMaker 2025 hat Markus Schall auf seiner Website einen separaten Artikel veröffentlicht. Im folgenden Artikel geht es nun um LoRA Feintuning eines Sprachmodells direkt aus FileMaker heraus. In einem nächsten Artikel werden wir beschreiben, wie ein Sprachmodell in der Praxis mit FileMaker trainiert werden kann.
Was ist LoRA überhaupt? – Ein kurzer Rückblick auf das Prinzip
LoRA steht für Low-Rank Adaptation, und dieser Name beschreibt das Verfahren präzise. Es handelt sich um eine Technik, bei der ein großes neuronales Netz nicht vollständig neu trainiert, sondern nur in bestimmten Gewichtsmatrizen in komprimierter Form angepasst wird. Konkret werden einige Schichten des Modells mit kleinen, zusätzlichen Matrizen versehen, die sogenannte „Adapter“ bilden. Diese Adapter lernen während des Feintunings neue, aufgabenspezifische Muster, ohne die ursprünglichen Modellgewichte zu verändern. Das hat zwei große Vorteile: erstens spart es Speicher und Rechenleistung, zweitens bleibt das Basismodell unverändert – man kann also mehrere Feintunes auf derselben Grundlage erstellen, kombinieren und bei Bedarf auch wieder entfernen.
Diese Idee entstand ursprünglich aus der Not heraus. Vollständiges Feintuning war schlicht zu teuer. Ein Modell mit mehreren Milliarden Parametern neu zu trainieren, erfordert nicht nur leistungsstarke Hardware, sondern auch gewaltige Datenmengen und präzise Steuerung. LoRA dagegen brachte eine pragmatische Lösung: Anstatt das gesamte Netz zu verändern, optimiert man nur eine Handvoll Zusatzgewichte – meist ein bis zwei Prozent des Gesamtvolumens. Damit wurde Feintuning plötzlich für Einzelanwender, Start-ups und Forschungsgruppen realistisch.
Im Grunde ist LoRA ein Symbol für den Wandel, den die KI-Entwicklung durchlaufen hat. Während man früher von Grund auf neu trainierte, spricht man heute von Adaptation: vorhandenes Wissen anpassen, statt neues Wissen zu erzwingen. Es ist das maschinelle Pendant zu dem, was man im menschlichen Lernen als Erfahrung bezeichnen könnte – das Modell lernt, sich in einer neuen Umgebung zurechtzufinden, ohne seine Identität zu verlieren.
Ein weiterer Vorteil von LoRA ist seine Modularität. Einmal trainiert, kann ein LoRA-Adapter wie ein Zusatzmodul geladen oder entladen werden. So entstehen spezialisierte Varianten eines Basismodells – beispielsweise ein Chatmodell, das sich auf medizinische Texte spezialisiert, eines für juristische Sprache, oder eines, das den Stil eines bestimmten Unternehmens abbildet. In der Praxis hat sich das Verfahren sowohl bei Text- als auch bei Bildmodellen etabliert, wobei die zugrunde liegenden Prinzipien gleich bleiben: kleine, differenzierte Anpassungen statt großer, globaler Eingriffe.
Doch auch wenn das Verfahren selbst elegant ist, bleibt seine Umsetzung anspruchsvoll. Die Trainingsumgebung, die Datenvorbereitung und die richtigen Hyperparameter entscheiden über Erfolg oder Misserfolg. Genau hier zeigt sich der entscheidende Unterschied zwischen den klassischen Open-Source-Toolchains wie Axolotl, LLaMA-Factory oder kohya_ss und der neuen, integrierten Lösung in FileMaker 2025. Beide verwenden dieselbe mathematische Idee – aber sie betten sie in völlig unterschiedliche technische und konzeptionelle Kontexte ein.
Und genau das ist der Punkt, an dem unser Vergleich ansetzt: beim Versuch, zwei Welten zu verstehen, die dieselbe Sprache sprechen, aber ganz verschieden denken.
Der klassische Weg – LoRA-Training mit kohya_ss und PEFT
Wer den klassischen Weg des LoRA-Trainings gegangen ist, kennt das Ritual: Zuerst die Installation von Python, dann die richtige Version von PyTorch, anschließend die passenden NVIDIA-Treiber – und am Ende steht immer dieselbe Unsicherheit, ob alles miteinander harmoniert. Kohya_SS, ursprünglich für das Training visueller Modelle konzipiert, wurde in den letzten Jahren zu einer Art Universallösung für alle, die LoRA-Adapter erstellen wollten, egal ob für Bilder oder Text. Unter der Haube nutzt das System dieselben Prinzipien wie die PEFT-Bibliothek von Hugging Face – nur in einer komfortableren grafischen Oberfläche.
Der Ablauf folgt immer demselben Muster. Man beginnt mit einem Basismodell, etwa einem Llama- oder Mistral-Derivat. Danach werden die Trainingsdaten vorbereitet – meist in Form von JSONL-Dateien mit Rollenstrukturen („user“ und „assistant“), manchmal aber auch als einfache Frage-Antwort-Listen. Anschließend müssen die Parameter definiert werden: Lernrate, LoRA-Rang, Adapter-Layer, Batch-Größe, Optimizer, Zielverzeichnisse. Schon diese Phase trennt die Bastler von den Geduldigen, denn jede dieser Einstellungen kann über Erfolg oder Fehlschlag entscheiden.
Was folgt, ist die eigentliche Trainingsphase – oft begleitet von einem Gefühl zwischen Hoffnung und Skepsis. Während die GPU stundenlang rechnet, beobachtet man neugierig die Verlustkurve, und doch weiß man nie genau, ob das Ergebnis am Ende wirklich besser ist als zuvor. Manchmal endet das Training mit einer Fehlermeldung, manchmal mit einer Datei, die sich später nicht mehr laden lässt. Und wenn es gelingt, wartet die nächste Herausforderung: das fertige Modell in ein Format zu bringen, das sich in anderen Umgebungen nutzen lässt. Ein Adapter, der als safetensors vorliegt, muss oft noch zu GGUF oder MLX konvertiert werden – je nach Zielplattform. Dabei gehen gelegentlich Tensoren verloren, und wer Pech hat, steht wieder am Anfang.
Trotz all dieser Hürden besitzt der klassische Weg einen gewissen Reiz. Er ist ehrlich, transparent, und man spürt bei jedem Schritt, was im Hintergrund geschieht. Man sieht die Gewichte, man kann Parameter einzeln verändern, man hat die volle Kontrolle. Und genau das war lange Zeit der Charme dieser Welt: Sie belohnte diejenigen, die sich durch den Dschungel kämpften. Wer das erste Mal ein eigenes LoRA-Modell erfolgreich trainiert hatte, fühlte sich, als hätte er einen Gipfel bestiegen.
Doch irgendwann stellt sich die Frage, ob dieser Aufwand noch zeitgemäß ist. Denn das Ziel bleibt dasselbe – ein Modell zu schaffen, das sich an eine spezifische Sprache, einen Stil oder ein Aufgabenfeld anpasst. Die Methode ist solide, aber der Weg dorthin oft beschwerlich. Und so wächst der Wunsch nach einer Umgebung, in der all das nicht mehr Wochenend-Projekt, sondern Arbeitswerkzeug ist.
FileMaker 2025 – LoRA-Feintuning per Script
Mit FileMaker 2025 hat Claris nun genau diesen Schritt gewagt – und ihn, man darf es so sagen, mit einer gewissen Eleganz vollzogen. Zum ersten Mal erscheint in einer klassischen Business-Datenbank ein Befehl, der den Namen „Fine-Tune Model“ trägt. Hinter diesem schlichten Ausdruck verbirgt sich eine Idee, die bemerkenswert ist: Das LoRA-Training, bisher ein Thema für Spezialisten, wird direkt in den alltäglichen Arbeitsfluss integriert.
Technisch geschieht dies über den sogenannten AI Model Server, der lokal auf Apple-Silicon-Systemen läuft und auf Apples MLX-Framework aufsetzt. Dieses System übernimmt sämtliche Rechenschritte – vom Laden des Basismodells bis zum Erstellen des Adapter-Layers. Der Anwender muss lediglich festlegen, welche Daten trainiert werden sollen, und kann dies auf zwei Arten tun: entweder über eine bestehende FileMaker-Tabelle – etwa eine Sammlung von Kundenanfragen, Support-Dialogen oder Textfragmenten – oder über eine externe JSONL-Datei im Chat-Format. Damit entfällt die aufwendige Datenvorbereitung außerhalb des Systems; man arbeitet direkt mit den Datensätzen, die ohnehin im Unternehmen vorhanden sind.
Auch die Parameterwahl ist deutlich entschlackt. Statt zwanzig Stellschrauben gibt es nur wenige, aber entscheidende – max_steps, learning_rate, batch_size, und lora_layers. Die restlichen Werte sind in der Engine sinnvoll vorbelegt. Diese Reduktion ist kein Nachteil, sondern Ausdruck einer klaren Design-Philosophie: FileMaker soll keine Forschungsplattform werden, sondern ein Werkzeug, das reproduzierbare, stabile Ergebnisse liefert.
Das Feintuning selbst läuft dann wie jeder andere Scriptbefehl: Der Anwender ruft „Fine-Tune Model“ auf, übergibt den Modellnamen und den Speicherort, und FileMaker übergibt den Rest an den AI Model Server. Das Training findet vollständig lokal statt – ohne Cloud, ohne fremde API, ohne Datenschutzrisiko. Das Ergebnis ist ein neues Modell mit dem Präfix fm-mlx-, das direkt innerhalb der FileMaker-Umgebung für Textgenerierung, Klassifikation oder Dialogfunktionen genutzt werden kann.
Deutlich einfacherer Ablauf des LoRA Tranings mit FileMaker
Wer die klassische LoRA-Erfahrung hinter sich hat, wird beim ersten Durchlauf wahrscheinlich stutzen: kein Terminal, keine Logflut, keine kryptischen Fehlermeldungen. Stattdessen ein sauberer Fortschrittsbalken und ein reproduzierbares Resultat. Natürlich kann man kritisieren, dass man weniger Kontrolle hat – kein Zugriff auf exotische Optimizer, keine Experimente mit QLoRA oder Layer-Freezing –, doch gerade das ist der Punkt. Claris richtet sich nicht an Forscher, sondern an Anwender, die mit ihren eigenen Daten produktiv arbeiten wollen.
Damit verschiebt sich der Charakter des LoRA-Trainings grundlegend. Aus einem experimentellen Vorgang wird ein planbarer Prozess. Unternehmen können künftig ihre eigenen internen Sprachmodelle anpassen, ohne die Infrastruktur selbst betreiben zu müssen. Die Daten bleiben im Haus, die Abläufe sind dokumentiert, und die Ergebnisse lassen sich wie jede andere FileMaker-Komponente versionieren und automatisieren.
Natürlich bleibt auch hier Skepsis erlaubt. Noch ist der AI Model Server an Apple-Silicon gebunden, und noch fehlen tiefergehende Parameterzugriffe. Aber der Weg ist klar: Wo früher Wochen an Setup vergingen, genügen jetzt Minuten. Und wo man früher mühselig zwischen Speicherformaten wechselte, genügt heute ein Scriptbefehl.
Damit hat FileMaker etwas geschafft, was in der KI-Szene selten vorkommt: Es hat nicht versucht, „mehr“ zu machen, sondern „weniger“ – und das auf eine Weise, die die eigentliche Stärke der Plattform unterstreicht. Struktur statt Chaos, Integration statt Fragmentierung.
Praxisvergleich – MLX-LoRA vs. PEFT-LoRA
Wenn man die beiden Ansätze nebeneinanderstellt, fällt zunächst auf, dass sie im Kern dasselbe tun – ein bestehendes Sprachmodell mithilfe zusätzlicher Adaptergewichte anpassen. Doch der Weg dorthin könnte kaum unterschiedlicher sein. Während die Open-Source-Welt LoRA als flexibles Baukastensystem begreift, sieht Claris es als Bestandteil eines klar umrissenen Workflows. Die einen experimentieren mit jeder Komponente, die anderen integrieren sie nahtlos in eine geschlossene Umgebung.
Der klassische PEFT-Ansatz (Parameter-Efficient Fine-Tuning) – etwa über Axolotl, LLaMA-Factory oder kohya_ss – erlaubt es, jedes Detail des Trainingsprozesses zu steuern. Man kann gezielt festlegen, welche Schichten angepasst werden, welche Lernraten verwendet, wie Gradienten behandelt, wie Speicher gespart oder Batch-Größen variiert werden. Diese Freiheit ist mächtig, aber sie verlangt Fachkenntnis und Fingerspitzengefühl. Schon kleine Fehler in der Konfiguration führen zu unbrauchbaren Modellen oder nicht-konvergierenden Läufen. Der Nutzen liegt im wissenschaftlichen Charakter: Wer verstehen will, warum ein Modell sich so verhält, findet hier den besten Zugang.
Ganz anders FileMaker 2025. Dort wird LoRA nicht als Forschungswerkzeug verstanden, sondern als betriebliche Funktion – ein Teil eines Systems, das Informationen verarbeitet, statt sie zu erforschen. Der neue Scriptbefehl abstrahiert viele technische Details, ohne die Grundidee zu verfälschen. Das Feintuning läuft im Hintergrund auf dem AI Model Server, gesteuert durch ein paar einfache Parameter. Alles, was zuvor in YAML-Dateien oder Shell-Befehlen stand, wird in ein vertrautes FileMaker-Skript gegossen. Das Ergebnis ist weniger spektakulär, aber stabiler – ein reproduzierbarer Prozess, der sich dokumentieren, automatisieren und in Unternehmenslogik einbinden lässt.
Man könnte den Unterschied so beschreiben: Der klassische Weg ist wie das Schrauben an einem Motor, bei dem jede Dichtung sichtbar und jede Einstellung manuell ist. FileMaker dagegen hat den Motor verkleidet und einen Startknopf daneben gesetzt. Das Ergebnis mag für Bastler weniger aufregend sein, aber es startet zuverlässig.
Was die Ergebnisse betrifft, so hängt die Qualität in beiden Fällen von denselben Faktoren ab: der Güte der Daten, der Angemessenheit der Lernrate und dem Basismodell. Unterschiede entstehen eher durch den Charakter der Umgebung als durch die Methode selbst. FileMaker arbeitet naturgemäß in geschlossenen Datensätzen – also typischerweise anwendungs- oder unternehmensspezifischen Korpora. Das bedeutet: sauberere, aber kleinere Datenmengen. In der Open-Source-Welt dagegen werden meist große, gemischte Datensätze genutzt, oft von unterschiedlichster Herkunft. Daraus können einerseits robustere, andererseits inkonsistentere Ergebnisse entstehen.
So ergibt sich ein klarer Befund: FileMaker liefert in kürzerer Zeit ein stabil nutzbares Modell, während PEFT-basierte Trainings mehr Potenzial, aber auch mehr Unsicherheit bieten. Wer also einen reproduzierbaren Prozess will, der sich in den Arbeitsalltag integrieren lässt, findet in FileMaker eine unerwartet reife Lösung. Wer hingegen experimentieren, verstehen und über die Grenzen der Standardparameter hinausgehen will, bleibt in der Open-Source-Welt besser aufgehoben.
Qualitätsunterschiede – Was wirklich zählt
Bei allen Diskussionen über Frameworks, Formate und Befehle darf man eines nicht übersehen: Die Qualität eines LoRA-Feintunings wird nicht durch das Werkzeug bestimmt, sondern durch das, was man ihm füttert. Ein sauber strukturierter Datensatz, der klar formulierte Prompts und realistische Antworten enthält, wirkt stärker auf das Endergebnis als jede Lernrate oder Batch-Größe. Das gilt sowohl für FileMaker-Trainings als auch für PEFT-basierte Läufe.
Dennoch lohnt sich ein Blick auf die Unterschiede, die indirekt Einfluss auf die Qualität haben. In der klassischen Umgebung arbeitet man meist mit größeren Datenmengen, was eine gewisse Varianz mit sich bringt. Modelle, die auf solchen Datensätzen trainiert werden, neigen dazu, breiter, aber weniger präzise zu antworten. Sie entwickeln oft eine gewisse „Sprachbreite“, die in generischen Anwendungen beeindruckend ist, in spezialisierten Umfeldern aber zu Beliebigkeit führen kann. FileMaker dagegen fördert das Gegenteil: Hier werden Daten gezielt ausgewählt, kuratiert, oft direkt aus einer Tabelle, die den realen Geschäftskontext widerspiegelt. Dadurch entsteht eine natürliche Fokussierung – das Modell lernt nicht alles, sondern das, was relevant ist.
Gekapselter Prozess sorgt für bessere Stabilität
Ein weiterer Punkt ist die Reproduzierbarkeit. Klassische LoRA-Trainings laufen meist in Umgebungen, die sich durch Versionsupdates, GPU-Treiber oder Bibliotheksänderungen schnell verändern. Ein Training, das heute funktioniert, kann morgen schon fehlschlagen. FileMaker bricht mit dieser Unsicherheit, indem es den gesamten Prozess kapselt. Der AI Model Server nutzt eine klar definierte MLX-Laufzeit, die weder vom Anwender noch von der Internet-Verbindung abhängt. Das führt zwar zu weniger Flexibilität, aber auch zu mehr Stabilität – und genau das ist in produktiven Szenarien entscheidend.
Auch die Bewertung der Ergebnisse unterscheidet sich. In der Open-Source-Welt misst man Qualität häufig mit quantitativen Metriken – Perplexity, Accuracy, BLEU-Score. FileMaker dagegen arbeitet stiller: Das Ergebnis zeigt sich im Alltag, wenn ein System auf interne Fragen plötzlich präziser reagiert, oder wenn ein automatisch erzeugter Text natürlicher klingt. Es sind qualitative, erfahrungsbasierte Unterschiede – die Art, wie ein Modell auf vertraute Begriffe reagiert, wie es unternehmensspezifische Tonalität aufnimmt oder wie es bei Fachbegriffen weniger „halluziniert“.
Schließlich darf man auch den zeitlichen Faktor nicht unterschätzen. Ein PEFT-Training mit Axolotl oder kohya_ss kann leicht viele Stunden oder gar Tage beanspruchen, inklusive Vorbereitung und Nachbearbeitung. Das FileMaker-Training dagegen lässt sich in Minuten auslösen und parallel zu anderen Aufgaben ausführen. Diese Geschwindigkeit verändert die Art, wie man mit KI-Systemen arbeitet: Aus einem technischen Projekt wird ein alltäglicher Vorgang.
Im Ergebnis zeigt sich, dass der qualitative Unterschied weniger in der Modellleistung als in der Verfügbarkeit und Nutzbarkeit liegt. FileMaker-LoRAs sind oft kleiner, fokussierter, stabiler – und genau das macht sie wertvoll für reale Arbeitsprozesse. PEFT-LoRAs können dagegen tiefgreifender, anpassungsfähiger und im Grenzfall leistungsfähiger sein, wenn sie richtig trainiert werden. Es ist, als würde man eine Präzisionsmaschine mit einem Universallabor vergleichen: Beide haben ihre Berechtigung, doch sie dienen unterschiedlichen Zwecken.
Und vielleicht liegt genau darin die Lehre dieser neuen Entwicklung – dass Qualität nicht allein aus Zahlen besteht, sondern aus Verlässlichkeit, Klarheit und der Fähigkeit, Wissen in einen geordneten Rahmen zu bringen. FileMaker 2025 zeigt, dass auch in einer Welt, die von Experimenten überquillt, manchmal die besonnene, integrierte Lösung die besseren Ergebnisse hervorbringt.
Portabilität und Zukunftsfähigkeit – Zwischen Welten
Wenn man sich heute die Landschaft der Modellformate ansieht, fühlt man sich fast an die frühen Computerjahre erinnert, als jedes System seine eigene Sprache sprach. Was früher Diskettenformate waren, sind heute Tensorformate: GGUF, safetensors, ckpt, MLX. Jedes Framework, jede Engine scheint ihre eigene Logik zu pflegen. Und so wie man früher beim Wechsel von Windows zu Mac noch Adapterkabel brauchte, braucht man heute Konvertierungsskripte – mal von MLX zu GGUF, mal umgekehrt.
FileMaker 2025 setzt hier bewusst einen Punkt. Der neue AI Model Server nutzt ausschließlich MLX als Backend – das Framework, das Apple für sein eigenes Silicon entwickelt hat. MLX ist noch jung, aber konzeptionell stark: Es erlaubt Training, Inferenz und LoRA-Feintuning in einem konsistenten Speicherformat, optimiert für die neuronalen Kerne der M-Chips. Die Entscheidung von Claris, dieses System zu übernehmen, ist also kein Zufall. Sie folgt der Philosophie, eine stabile, kontrollierte Umgebung zu schaffen, die vollständig lokal betrieben werden kann.
Das hat Folgen für die Portabilität. Ein LoRA-Modell, das man in FileMaker trainiert, trägt automatisch den Präfix fm-mlx- und lässt sich direkt in der MLX-Laufzeit verwenden. Wer es dagegen in einer anderen Umgebung – etwa in LM Studio, Ollama oder llama.cpp – nutzen möchte, muss den Umweg über eine Konvertierung gehen. Diese ist technisch möglich, aber noch nicht trivial. Zwar gibt es erste Tools, die MLX-Modelle nach GGUF übertragen können, doch noch fehlt eine standardisierte Brücke. Der Grund liegt weniger in der Mathematik als in der Organisation: MLX ist Apple-zentrisch, GGUF dagegen Community-getrieben. Beide Systeme entwickeln sich rasant, aber unabhängig voneinander.
In der Praxis bedeutet das: Wer mit FileMaker arbeitet, bleibt zunächst innerhalb eines geschlossenen, aber stabilen Ökosystems. Für viele Anwendungsfälle ist das kein Nachteil – im Gegenteil. Die Sicherheit, dass ein Modell in derselben Umgebung trainiert, gespeichert und genutzt wird, hat Vorteile, die weit über technische Bequemlichkeit hinausgehen. Sie betrifft Fragen der Nachvollziehbarkeit, Datensouveränität und Langlebigkeit. Denn während Open-Source-Frameworks oft in kurzen Innovationszyklen leben, steht FileMaker traditionell für Beständigkeit. Modelle, die heute trainiert werden, werden auch in zwei oder drei Jahren noch in derselben Form lauffähig sein – und das ist im Unternehmenskontext ein Wert, der kaum zu überschätzen ist.
Trotzdem wird der Wunsch nach Austauschbarkeit bleiben. Es wäre denkbar – und langfristig fast unvermeidlich –, dass Claris künftig Exportfunktionen anbietet, etwa nach GGUF oder ONNX. Damit ließen sich Modelle auch außerhalb der FileMaker-Welt einsetzen, ohne ihren Kern zu verlieren. Ebenso wahrscheinlich ist, dass MLX selbst stärker in die Open-Source-Welt hineinwächst und damit die Barrieren zwischen Apple- und Non-Apple-Umgebungen langsam verschwinden.
Für den Moment aber steht FileMaker auf einem klar definierten Fundament: Stabilität vor Vielfalt, Einfachheit vor Überfrachtung. Es ist eine Entscheidung, die nicht jedem gefallen wird, die aber auf lange Sicht Sinn ergibt. Denn in einer Welt, in der alles gleichzeitig möglich ist, bekommt das, was verlässlich funktioniert, wieder Gewicht.
Fazit – Vom Experiment zum Werkzeug
Am Ende bleibt die Erkenntnis, dass FileMaker 2025 mit seinem LoRA-Befehl nicht einfach eine neue Funktion eingeführt hat, sondern ein Signal gesetzt hat. Ein Signal dafür, dass KI-Training kein Spezialistenprivileg mehr ist, sondern Teil normaler Geschäftsprozesse werden kann. Die Integration von LoRA in ein System, das seit Jahrzehnten für Stabilität, Nachvollziehbarkeit und Benutzerfreundlichkeit steht, markiert einen Wendepunkt – nicht in der Forschung, sondern in der Praxis.
Das klassische LoRA-Training, ob mit kohya_ss oder PEFT, wird seinen Platz behalten. Es bleibt das Reich der Entwickler, Forscher und Bastler – jener, die verstehen wollen, wie sich Modelle im Detail verhalten, die jede Gewichtsmatrix einzeln betrachten möchten. Diese Offenheit hat ihren Wert, sie ist die Grundlage für Fortschritt. Doch der Preis dafür ist Aufwand, Unsicherheit und eine gewisse Fragilität.
FileMaker dagegen wählt den anderen Weg: Es reduziert die Komplexität auf das Wesentliche und überführt ein kompliziertes Verfahren in eine wiederholbare Routine. Das Feintuning wird zum Scriptbefehl, das Modell zum Teil einer Datenbank, die KI zum Werkzeug unter vielen. Damit wird die Technologie nicht kleiner, sondern greifbarer. Sie verliert ihren experimentellen Charakter und gewinnt an Alltagstauglichkeit.
Der qualitative Unterschied zeigt sich nicht in der Rechenleistung oder im Parameterumfang, sondern in der Haltung. Während viele KI-Plattformen den Anwender mit Optionen überfluten, geht Claris einen stilleren Weg – den Weg der Integration. Alles geschieht dort, wo die Daten ohnehin liegen. Das ist kein technologischer Trick, sondern Ausdruck einer Philosophie: Prozesse gehören zusammen, nicht nebeneinander.
Vielleicht ist das der eigentliche Fortschritt – dass aus der ständigen Suche nach neuen Möglichkeiten endlich wieder ein Werkzeug geworden ist, das man versteht, bedienen und kontrollieren kann. FileMaker 2025 bringt LoRA dorthin, wo es hingehört: in die Hände derer, die mit Daten arbeiten, nicht nur in die Labore derer, die sie erforschen.
Und so schließt sich der Kreis: Vom chaotischen Terminalfenster über die ersten experimentellen Feintunes bis hin zum Scriptbefehl, der dasselbe leistet – nur sauber, strukturiert und nachvollziehbar. Ein leiser, aber bedeutender Wandel. Denn manchmal verändert sich die Welt nicht durch das, was neu erfunden wird, sondern durch das, was endlich einfach funktioniert.
In einem nächsten Artikel werden wir beschreiben, wie ein Sprachmodell in der Praxis anhand eines Beispielscripts mit FileMaker trainiert werden kann.
Häufig gestellte Fragen
- Was genau ist LoRA und wofür wird es beim Training von Sprachmodellen eingesetzt?
LoRA steht für Low-Rank Adaptation. Es ist ein Verfahren, bei dem nur ein kleiner Teil der Modellparameter angepasst wird, um ein großes Sprachmodell an spezifische Aufgaben oder Schreibstile anzupassen. Statt Milliarden von Gewichten zu verändern, werden zusätzliche, kleine Matrizen („Adapter“) trainiert. Das spart Speicher, Zeit und Rechenleistung. Das Basismodell bleibt dabei unverändert, was LoRA-Modelle besonders flexibel und ressourcenschonend macht. - Was unterscheidet ein FileMaker-LoRA-Training von einem klassischen PEFT-Training mit Axolotl oder kohya_ss?
Im Kern gar nicht so viel – beide nutzen dieselbe mathematische Idee. Der Unterschied liegt in der Umgebung. PEFT-Trainings werden in offenen Frameworks mit vielen Stellschrauben durchgeführt, meist über Python-Bibliotheken. FileMaker dagegen integriert das Verfahren in seinen AI Model Server. Das Training läuft lokal über MLX auf Apple-Silicon-Systemen und wird per Script gesteuert. Der Fokus liegt hier auf Stabilität und Integration statt auf Forschungsfreiheit. - Was ist der AI Model Server in FileMaker 2025?
Der AI Model Server ist eine lokale Komponente, die Textmodelle bereitstellt, trainiert und ausführt – vollständig auf Apple-Silicon-Hardware. Er bildet das technische Fundament für alle KI-Funktionen in FileMaker, darunter Textgenerierung, Embedding und Fine-Tuning. Damit kann ein Unternehmen KI-Modelle nutzen, ohne Daten an externe Clouds zu übertragen. - Wie läuft ein LoRA-Training in FileMaker 2025 konkret ab?
Der Anwender ruft im Script den neuen Befehl Fine-Tune Model auf. Als Eingabe dient entweder eine Tabelle in der FileMaker-Datenbank (z. B. mit Prompts und Antworten) oder eine externe JSONL-Datei mit Chat-Struktur. Das Training startet dann lokal über den AI Model Server. Nach Abschluss wird ein neues Modell mit dem Präfix fm-mlx-… erzeugt, das sofort in Scripts oder Layouts verwendet werden kann. - Welche Parameter lassen sich beim FileMaker-Training einstellen?
FileMaker erlaubt gezielt wenige, aber entscheidende Parameter:
– max_steps – Anzahl der Trainingsschritte
– learning_rate – Lernrate
– batch_size – Größe der Trainingsbatches
– lora_layers – Anzahl der Adapter-Layer
Damit wird das Training übersichtlich gehalten, ohne die Gefahr fehlerhafter Konfigurationen. - Welche Vorteile hat das Training über FileMaker gegenüber klassischen Tools?
Der größte Vorteil liegt in der Integration. Man arbeitet direkt mit den Daten, die ohnehin im System vorhanden sind, und spart sich Setup, Umgebungsvariablen, Paketinstallationen oder GPU-Konfigurationen. Zudem bleibt alles lokal und reproduzierbar. Für Unternehmen ist das ein entscheidendes Argument – Datenschutz, Nachvollziehbarkeit und einfache Wartung. - Ist FileMaker-LoRA qualitativ schlechter als ein PEFT-LoRA?
Nicht grundsätzlich. Die zugrundeliegende Methode ist identisch. Unterschiede entstehen durch Datensatzgröße, Parameterwahl und Evaluierung. FileMaker setzt auf stabile Defaults und strukturierte Datensätze, während PEFT-Setups mehr experimentellen Spielraum bieten. In vielen Fällen erzielt FileMaker sogar konsistentere Ergebnisse, weil weniger Variablen fehleranfällig sind. - Kann man mit FileMaker auch größere Basismodelle trainieren, z. B. Llama 3 oder Mistral?
Ja, solange das Basismodell im MLX-Format vorliegt und vom AI Model Server unterstützt wird. FileMaker ist auf textbasierte Modelle optimiert, die lokal auf Apple-Silicon-Chips laufen. Sehr große Modelle sind allerdings durch RAM- und GPU-Kapazität begrenzt – meist eignen sich Modelle bis etwa 8 – 14 Milliarden Parameter. - Kann ich ein mit FileMaker trainiertes Modell außerhalb von FileMaker verwenden?
Derzeit nur mit Einschränkungen. Das Modell liegt im MLX-Format vor und ist direkt für den AI Model Server vorgesehen. Für den Export in andere Formate (z. B. GGUF, ONNX) gibt es erste Konvertierungstools, aber sie sind noch experimentell. Claris könnte diese Funktion in Zukunft offiziell unterstützen. - Welche Hardwarevoraussetzungen gibt es für das Training in FileMaker?
Ein Mac mit Apple-Silicon-Chip (M1, M2, M3 oder neuer) ist erforderlich. Das Training nutzt die Neural Engine und GPU-Einheiten des Chips. Intel-Macs werden nicht unterstützt. Für größere Datensätze empfiehlt sich mindestens 16 GB RAM, besser 32 GB oder mehr. - Wie steht es um Datenschutz und Sicherheit beim FileMaker-Training?
Das Training findet vollständig lokal statt. Keine Daten werden an Dritte übertragen, keine Cloud-API wird verwendet. Für Unternehmen, die mit vertraulichen oder personenbezogenen Daten arbeiten, ist das ein entscheidender Vorteil gegenüber externen KI-Diensten. - Kann ich in FileMaker mehrere Modelle gleichzeitig betreiben?
Der AI Model Server unterstützt derzeit ein Modell gleichzeitig. Man kann jedoch beliebig viele Feintunes erstellen und bei Bedarf laden oder entladen. Diese Begrenzung dient der Stabilität und Planbarkeit des Systems. - Wie groß ist der Unterschied im Trainingsaufwand zwischen FileMaker und klassischem LoRA?
Er ist erheblich. Während ein klassisches PEFT-Setup oft Stunden oder Tage an Vorbereitung braucht – Installation, Abhängigkeiten, Testläufe –, ist FileMaker in wenigen Minuten startklar. Der Trainingsprozess selbst läuft ebenfalls schneller, weil MLX auf Apple-Silicon sehr effizient arbeitet. Das spart Zeit und Nerven, auch wenn man etwas Kontrolle einbüßt. - Welche Arten von Textdaten eignen sich für das Training am besten?
Ideal sind strukturierte, dialogähnliche Daten: Kundenanfragen, Supportgespräche, interne Wissensdatenbanken, FAQs oder Fachtexte. Wichtig ist, dass die Daten klar formuliert sind und ein wiedererkennbares Muster haben. LoRA lernt nicht „Inhalte“, sondern sprachliche und kontextuelle Strukturen – Qualität schlägt Quantität. - Wie lässt sich die Qualität eines FileMaker-LoRA-Modells bewerten?
Nicht mit abstrakten Metriken, sondern im praktischen Einsatz. Man prüft, ob das Modell konsistent auf interne Fragen reagiert, ob es Fachbegriffe korrekt verwendet und ob die Tonalität dem gewünschten Stil entspricht. FileMaker erlaubt einfache Vergleichstests, etwa durch Skripte, die Prompts an unterschiedliche Modelle senden und die Antworten speichern. - Kann man ein FileMaker-LoRA-Modell wieder löschen oder überschreiben?
Ja. Fine-Tuned-Modelle lassen sich in der Admin-Konsole des AI Model Servers verwalten, löschen oder ersetzen. Da die Basismodelle unverändert bleiben, ist das Risiko minimal. Man kann jederzeit neu trainieren, ohne den Ausgangspunkt zu verlieren. - Wie verhält sich FileMaker im Vergleich zu Cloud-Feintunings bei OpenAI oder Anthropic?
FileMaker bietet lokale Kontrolle, während Cloud-Dienste meist serverseitig trainieren und Ergebnisse über API zurückliefern. Der Nachteil der Cloud: hohe Kosten, eingeschränkter Datenschutz und kein direkter Zugriff auf das Modell. FileMaker schafft das Gegenteil – volle Datenhoheit, keine Abhängigkeit von Dritten, aber eben auf Apple-Hardware beschränkt. - Wie stabil ist MLX als Plattform für LoRA-Training?
MLX ist noch jung, aber technisch ausgereift. Es wurde von Apple speziell für neuronale Netze auf M-Chips entwickelt und bietet eine erstaunlich hohe Performance bei geringer Energieaufnahme. In Verbindung mit FileMaker wirkt es wie eine solide Basis für lokale KI-Anwendungen, auch wenn es derzeit noch weniger Community-Support gibt als bei PyTorch. - Wird FileMaker künftig auch den Export in offene Formate unterstützen?
Das ist wahrscheinlich. Claris hat in den letzten Jahren mehrfach betont, offene Standards langfristig unterstützen zu wollen. Ein Export nach GGUF oder ONNX wäre der logische nächste Schritt, um FileMaker-Trainings in externe Umgebungen (z. B. LM Studio oder Ollama) zu integrieren. Noch ist das nicht offiziell angekündigt, aber technisch machbar. - Lohnt sich der Umstieg auf FileMaker-LoRA für erfahrene PEFT-Anwender?
Das hängt vom Ziel ab. Wer tief forschen, Metriken vergleichen oder eigene Architekturen testen will, bleibt besser bei Axolotl oder LLaMA-Factory. Wer dagegen stabile, wiederholbare Trainings in einer kontrollierten Umgebung braucht – etwa für interne Assistenten, Fachsprache oder Prozessautomation – wird in FileMaker eine bemerkenswert elegante Lösung finden.
Markus Schall entwickelt seit 1994 individuelle Datenbanken, Schnittstellen und Geschäftsanwendungen auf Basis von Claris FileMaker. Er ist Claris-Partner, FMM-Award-Gewinner 2011 und Entwickler der ERP-Software gFM-Business. Zudem ist er Buchautor und Gründer des M. Schall Verlags.
