Hybrid LoRA KI
Wie ein Cloud-Modell und ein lokales Modell am eigenen Arbeitsplatz zusammenarbeiten und wie sich das lokale Modell per LoRA anpassen lässt. Konzept, Arbeitsweisen und typische Fehlerquellen, ohne technische Details.
Worum es geht
Wer heute mit KI arbeitet, steht vor einer Grundsatzfrage: Nutze ich ein großes Modell in der Cloud, das viel kann, aber Geld kostet und Daten nach außen schickt? Oder ein kleineres Modell auf dem eigenen Rechner, das nichts kostet und alles im Haus lässt, aber weniger leistet?
Die Antwort dieses Artikels lautet: beides, und zwar in einer festen Arbeitsteilung. Das ist der hybride Ansatz. Ein leistungsstarkes Cloud-Modell übernimmt die anspruchsvolle Arbeit. Ein lokales Modell erledigt die einfachen Aufgaben. Und eine kleine Vermittlungsschicht sorgt dafür, dass jede Anfrage beim richtigen Modell landet.
Der Artikel beschreibt das Konzept, die Arbeitsweisen und die typischen Fehlerquellen. Er verzichtet bewusst auf Befehle und Konfigurationsdetails. Diese stehen im technischen Handbuch.
Die beiden Partner
Das lokale Modell läuft vollständig auf dem eigenen Rechner. Es braucht viel Arbeitsspeicher, aber keine Verbindung nach außen. Es antwortet in gemächlichem Tempo, kostet pro Anfrage nichts und eignet sich für Routine: Texte zusammenfassen, übersetzen, umformulieren, einfache Erklärungen liefern, Beispieldaten erzeugen.
Das Cloud-Modell ist das eigentliche Arbeitspferd für alles, was Verstand verlangt: Architekturentscheidungen, schwierige Fehlersuche, mehrstufiges Nachdenken, sicherheitsrelevanter Code. Es wird über ein Abonnement genutzt, nicht über eine Abrechnung pro Anfrage. Jede Nutzung zählt aber auf das Kontingent des Abos.
Der entscheidende Kniff: Das Cloud-Modell kann dem lokalen Modell Teilaufgaben übergeben. Es formuliert einen Auftrag, schickt alles Nötige mit, bekommt das Ergebnis zurück und prüft es. Das lokale Modell sieht dabei weder Dateien noch den bisherigen Gesprächsverlauf. Es bekommt nur das, was ihm ausdrücklich gegeben wird.
Vier Betriebsarten im Chat
Die Oberfläche bietet vier Modi. Der Verlauf bleibt beim Umschalten erhalten, und jede Antwort zeigt, welches Modell sie geschrieben hat.
- Automatik. Das lokale Modell schätzt zuerst ein, wie schwer eine Anfrage ist, auf einer Skala von leicht bis schwer. Bis zu einer einstellbaren Schwelle antwortet es selbst. Darüber geht die Anfrage an das Cloud-Modell. Wer mit einer lokalen Antwort unzufrieden ist, kann sie mit einem Klick nachträglich an das Cloud-Modell weiterreichen. Diese Einstufung geschieht bewusst lokal, damit für die Entscheidung nichts den Rechner verlässt.
- Lokal. Nur das gewählte lokale Modell. Kostenlos, offline, mit optionalem ausführlichem Nachdenken vor der Antwort.
- Hybrid. Das Cloud-Modell antwortet und delegiert einfache Teile an das lokale Modell. Diese Delegationen sind in der Antwort sichtbar und lassen sich aufklappen.
- Nur Cloud. Das Cloud-Modell allein, ohne Delegation.
Faustregel: Automatik als Standard für den Alltag, Hybrid für konzentrierte Arbeit an einem Projekt, Lokal für schnelle Fragen und Experimente.
Drei Wege, den Entwicklungsassistenten zu starten
Der gleiche Gedanke gilt für die Arbeit im Terminal mit dem Entwicklungsassistenten.
- Hybrid ist die empfohlene Arbeitsweise. Das Cloud-Modell führt und entscheidet selbst, was es abgibt. Gezielt anstoßen lässt sich das mit Formulierungen wie „Lass das lokale Modell das übersetzen“.
- Nur lokal startet den Assistenten mit dem lokalen Modell. Das ist offline und kostenlos, taugt aber nur für einfache Aufgaben. Einige Warnmeldungen beim Start sind hier normal und kein Fehler.
- Direkter Chat mit dem lokalen Modell, ganz ohne Entwicklungsassistenten, für schnelle Fragen.
Eine wichtige Gewohnheit: Den Assistenten immer aus einem Projektordner starten, nie aus dem Home-Verzeichnis. So bleibt der Kontext auf das Projekt beschränkt.
Alles wird protokolliert
Jede Antwort, egal von welchem Modell, landet automatisch als Notiz im persönlichen Wissensspeicher, sortiert nach Modell und Datum und mit Verweis auf das Projekt. Damit geht keine Antwort verloren, und Ergebnisse lassen sich später wiederfinden, vergleichen und weiterverwenden.
Eigene Modelle anpassen
Der zweite große Baustein ist das Training. Lokale Modelle lassen sich mit eigenen Beispielen auf einen gewünschten Stil oder ein Antwortformat einstellen. Das Ergebnis ist kein neues Modell, sondern ein kleiner Aufsatz, ein Adapter, der sich auf das Grundmodell legt und im Chat zu- oder abschaltbar ist. Das Verfahren heißt LoRA (Low-Rank Adaptation): Die Gewichte des Grundmodells bleiben unverändert, trainiert werden nur wenige kleine Zusatzmatrizen. Auf dem Mac übernimmt das Apples Framework MLX, das den gemeinsamen Speicher von Prozessor und Grafikeinheit direkt nutzt.
Der Ablauf hat vier Schritte auf einer Seite:
- Trainingsdaten anlegen. Beispielpaare aus Frage und gewünschter Antwort, einzeln eingetippt oder in großer Zahl eingefügt. Die Seite warnt, wenn die Daten zu wenige, zu ähnlich, zu kurz oder doppelt sind.
- Training starten. Grundmodell, Name und Stärke wählen. Drei Stufen stehen bereit: schonend, standard, kräftig. Die Seite berechnet die technischen Parameter selbst und zeigt den Speicherbedarf.
- Verlauf beobachten. Fortschritt, Restzeit und zwei Kurven: der Fehler auf den Trainingsdaten und der Fehler auf zurückgehaltenen Prüfdaten. Steigt die zweite Kurve wieder, hat das Modell begonnen, auswendig zu lernen. Die Seite warnt dann und nennt den besseren Abbruchpunkt.
- Testen. Dieselbe Frage an das Original und an die angepasste Version. Am aufschlussreichsten sind Fragen, die nicht in den Trainingsdaten vorkommen.
Die wichtigste Lektion beim Training: Zu wenige oder zu gleichförmige Beispiele lassen das Modell kollabieren. Es verliert sein Wissen und wiederholt nur noch das gelernte Muster. Abhilfe: mehr und abwechslungsreichere Daten, ein sanfteres Training oder weniger Durchgänge. Als Richtwert gelten einige Hundert bis Tausend Beispiele, davon ein Zehntel als Prüfdaten.
Grenzen, die man kennen sollte
- Speicher. Modelle und Training konkurrieren um denselben Arbeitsspeicher. Zwei große Modelle gleichzeitig passen gerade noch. Während eines Trainings sollte nichts anderes Großes laufen.
- Zuverlässigkeit. Das lokale Modell folgt Werkzeuganweisungen weniger verlässlich als das Cloud-Modell. Es sollte keine Dateien löschen oder verschieben.
- Wartezeit. Die Anweisungen des Entwicklungsassistenten sind lang. Jede lokale Antwort braucht deshalb einige Sekunden Anlauf.
- Größe. Modelle über einer bestimmten Größe passen nicht mehr auf die Grafikeinheit und sind damit unbrauchbar.
Zusammenfassung für die Praxis
| Aufgabe | Richtiger Partner |
|---|---|
| Zusammenfassen, übersetzen, umformulieren | lokal |
| Boilerplate, Testdaten, einfache Erklärungen | lokal |
| Architektur, schwieriges Debugging | Cloud |
| Mehrstufiges Nachdenken, sicherheitskritischer Code | Cloud |
| Stil oder Format dauerhaft anpassen | lokales Modell trainieren |
Der hybride Ansatz spart Abo-Kontingent, hält Routinedaten im Haus und nutzt das teure Modell dort, wo es den Unterschied macht. Wer die Arbeitsteilung einmal verinnerlicht hat, arbeitet schneller und günstiger als mit einem Modell allein.
Granaria AC · Curriculum-Version v1-2026-08-20 · Der Granaria-Kompetenznachweis ist eine prüfbare Compliance-Dokumentation nach Art. 4 VO (EU) 2024/1689, kein amtliches Zertifikat. · Zertifikat prüfen
