WeClone: Ein digitaler Zwilling aus dem eigenen Chatverlauf, mit LoRA auf Qwen2.5-VL-7B
🚀 One-stop solution for creating your AI twin from chat history 💡 Fine-tune LLMs with your chat logs to capture your unique style, then bind to a chatbot to bring your digital self to life.
Auf einen Blick
- Was ist das?
- WeClone verbindet Chat-Export, Datenaufbereitung, LoRA-Fine-Tuning über LLaMA Factory und Bot-Anbindung zu einer Pipeline. Der Nutzen steht und fällt mit Datenmenge, Datenqualität und einer GPU, die mindestens 16 GB VRAM für den 7B-Standardfall bereitstellt.
- Für wen ist es gedacht?
- Wer bereits eine Telegram-Historie mit Text und Bildern besitzt, mindestens 16 GB VRAM für die LoRA-Konfiguration stellen kann und mit der AGPL-3.0 als Projektlizenz leben kann, findet in WeClone eine zusammenhängende Pipeline statt einzelner Skripte. Wer auf WhatsApp, Discord oder Slack als Datenquelle angewiesen ist, sollte warten: Diese Spalten stehen in der README durchgehend auf dem Baustein-Symbol.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem WeClone löst und für wen es gedacht ist
Ein Chatverlauf enthält Stil, Wortwahl, wiederkehrende Floskeln und die Art, wie jemand auf bestimmte Reize reagiert. Diese Information steckt in Textform vor, ist aber für ein Modell nicht direkt nutzbar. WeClone setzt genau an dieser Lücke an: Die README beschreibt das Projekt als Komplettlösung, die Chat-Export, Vorverarbeitung, Modelltraining und Deployment abdeckt. Der Adressat ist damit nicht das Forschungsteam, das eine neue Trainingsmethode sucht, sondern eine Person mit vorhandener Chat-Historie und Zugang zu einer GPU.
Der Umfang der Datenquellen ist dabei eng gefasst. Die Tabelle in der README listet für Telegram Text, Bilder, Standort und Dateien als unterstützt, Sticker werden laut Tabelle zu Emoji konvertiert, Sprache, Video, Links, Zitate und Weiterleitungen stehen auf nicht unterstützt. WhatsApp, Discord und Slack sind in derselben Tabelle durchgehend als geplant markiert. Wer also glaubt, aus einem Discord-Export direkt starten zu können, wird in der aktuellen Fassung nicht bedient.
Bemerkenswert ist der Hinweis, dass Windows nicht streng getestet wurde und WSL als Laufzeitumgebung empfohlen wird. Das ist keine Randnotiz, sondern bestimmt, auf welcher Maschine das Projekt realistisch betrieben wird.
Der Ablauf: Export, Filter, LoRA, Bot
Die Pipeline besteht aus vier Stufen, die über eine gemeinsame Konfigurationsdatei zusammengehalten werden. Zuerst steht der Export der Chatdaten, für Telegram inklusive Bildmaterial. Danach folgt die Vorverarbeitung, zu der laut Funktionsliste ein Filter für private Informationen gehört. Diese Stufe ist der Punkt, an dem die Datenmenge typischerweise schrumpft, denn ein Filter, der Telefonnummern, Adressen und ähnliches entfernt, trifft auch harmlose Nachrichten.
Die Trainingsstufe nutzt LLaMA Factory als Backend. Standardmodell ist Qwen2.5-VL-7B-Instruct, trainiert wird per LoRA im SFT-Schritt. Die README weist ausdrücklich darauf hin, dass auch andere von LLaMA Factory unterstützte Modelle und Methoden verwendet werden können. Das ist der architektonisch wichtigste Punkt: WeClone implementiert kein eigenes Trainingsverfahren, sondern legt eine Datenaufbereitung und eine Konfigurationsschicht um ein bestehendes Framework.
Die letzte Stufe bindet das Ergebnis an einen Chatbot. Für Deployment listet die README Telegram, Discord, Slack sowie den persönlichen WeChat-Account über openclaw-weixin als unterstützt, WhatsApp dort ebenfalls als geplant. Der Datenfluss ist damit unidirektional und offline: Es gibt keinen laufenden Abgleich mit neuen Nachrichten, das Modell wird auf einem festen Stand eingefroren.
Inbetriebnahme: uv, settings.jsonc und der CUDA-Check
Die Einrichtung beginnt mit einem Klon des Repositories und einer virtuellen Umgebung über uv. Die README nennt Python 3.12 als Zielversion und den Befehl uv venv .venv --python=3.12, gefolgt von der Aktivierung über source .venv/bin/activate, unter Windows .venv\Scripts\activate. Die Abhängigkeiten werden mit uv pip install --group main -e . installiert, also als editierbare Installation mit der Dependency-Gruppe main.
Vorausgesetzt wird CUDA ab Version 12.6. Die README enthält ein eigenes Kapitel zum Umgebungssetup und verlangt dort ausdrücklich diese Mindestversion. Anschließend wird die Konfigurationsvorlage kopiert: cp examples/tg.template.jsonc settings.jsonc. Der Name der Vorlage verrät bereits, dass der Telegram-Pfad der ausgearbeitete ist.
Alle Trainings- und Inferenzeinstellungen liegen laut README gebündelt in settings.jsonc. Das ist praktisch für den Einstieg, weil es nur eine Datei zu bearbeiten gibt, bedeutet aber auch, dass es keine Trennung zwischen Experimentier- und Produktivkonfiguration gibt. Wer mehrere Modelle oder Datenstände parallel testen will, muss die Datei kopieren und verwalten. Die README beschreibt außerdem einen Test, mit dem geprüft wird, ob die CUDA-Umgebung von PyTorch erkannt wird; der genaue Befehl ist im vorliegenden Material abgeschnitten, sodass er hier nicht wiedergegeben werden kann.
VRAM-Bedarf: die eigentliche Eintrittsbarriere
Die Hardwaretabelle in der README ist die nützlichste Einzelinformation des Projekts. Für den Standardfall LoRA in 16-Bit-Präzision nennt sie 16 GB VRAM beim 7B-Modell, 32 GB beim 14B-Modell und 160 GB beim 70B-Modell. Volles Fine-Tuning in bf16 oder fp16 beginnt bei 120 GB für 7B und erreicht 1200 GB für 70B. QLoRA senkt den Bedarf deutlich: 6 GB bei 4-Bit für 7B, 4 GB bei 2-Bit.
Diese Zahlen sind Schätzungen der README, keine gemessenen Werte aus einem Benchmark, und sie skalieren nach der Formel x GB pro Modellgröße in der Spalte xB. Wer ein 14B-Modell mit LoRA trainieren will, braucht also eine Karte mit 32 GB, was den Kreis der realistisch verfügbaren Hardware stark einschränkt.
Wichtiger als die Tabelle ist der qualitative Hinweis direkt darüber: Die Leistung des 7B-Modells wird als durchschnittlich bezeichnet, Modelle mit 14B oder mehr Parametern liefern laut README bessere Ergebnisse. Damit steht der Nutzer vor einem Zielkonflikt, den das Projekt nicht auflöst. Der Standardpfad ist auf Hardware ausgelegt, die viele noch besitzen, liefert aber nach Aussage der eigenen Dokumentation nur mittelmäßige Resultate. Wer bessere Ergebnisse will, muss die Hardware aufrüsten und gleichzeitig mehr und sauberere Daten liefern.
Wo WeClone an seine Grenzen stößt
Die README formuliert die wichtigste Einschränkung selbst: Die Wirksamkeit des Fine-Tunings hängt stark von Modellgröße sowie Menge und Qualität der Chatdaten ab. Das ist keine Bescheidenheitsfloskel, sondern beschreibt einen realen Fehlermodus. Ein Chatverlauf mit überwiegend kurzen Antworten, viele Emojis, wenige vollständige Sätze: Daraus lässt sich ein Tonfall lernen, aber keine belastbare Persönlichkeit.
Hinzu kommt die Filterstufe. Sie ist als Schutz gedacht, entfernt aber zusammen mit privaten Informationen auch Kontext. Ob der verbleibende Rest für ein Training ausreicht, lässt sich erst nach dem Lauf beurteilen, und die README gibt keine Mindestmenge an Nachrichten an, unterhalb derer das Training sinnlos wäre. Diese Zahl fehlt, und sie ist diejenige, die eine Adoption am stärksten steuern würde.
Ein zweiter Grenzfall ist die Plattformwahl. Wer primär über WhatsApp kommuniziert, kann WeClone derzeit nicht als Datenquelle nutzen, weil diese Spalte in der README als geplant geführt wird. Auch der Hinweis auf die schnelle Iterationsphase und die Formulierung, die aktuelle Leistung repräsentiere nicht das Endergebnis, gehört in diese Kategorie: Das Projekt befindet sich nach eigener Darstellung in Bewegung, was Schnittstellen und Konfigurationsschlüssel betreffen kann.
LLaMA Factory als Alternative und was der Unterschied ist
Die naheliegende Alternative ist LLaMA Factory selbst, das WeClone im Trainingsschritt ohnehin verwendet. Wer bereits Trainingsdaten im passenden Format hat, kann dort direkt einsteigen und auf die gesamte Modellunterstützung des Frameworks zugreifen, ohne die WeClone-Schicht dazwischen. Der Unterschied liegt nicht im Training, sondern davor und danach: WeClone liefert den Export aus Telegram, die Filterung privater Informationen und die Anbindung an einen laufenden Bot. LLaMA Factory liefert nichts davon.
Die Entscheidung hängt damit am eigenen Ausgangspunkt. Wer einen sauberen, bereits aufbereiteten Datensatz besitzt und nur trainieren will, gewinnt durch WeClone wenig und übernimmt zusätzlich eine weitere Konfigurationsschicht in settings.jsonc. Wer dagegen mit einem rohen Telegram-Export dasteht und am Ende einen antwortenden Bot betreiben will, spart durch WeClone die Arbeit an genau den beiden Enden, die LLaMA Factory offen lässt.
Ein zweiter Vergleichspunkt ist der Betrieb. WeClone bindet das trainierte Modell an Chat-Plattformen, für WeChat über openclaw-weixin. Wer das Modell stattdessen über eine eigene API ausliefern will, ist mit dem Framework allein oder mit einem eigenen Serving-Aufbau besser bedient, weil er dann keine der Bot-Integrationen mitpflegen muss.
Lizenz und Pflegeaufwand
WeClone steht unter AGPL-3.0. Das ist eine Copyleft-Lizenz mit Netzwerkkklausel: Wer eine modifizierte Version als über ein Netzwerk erreichbaren Dienst betreibt, muss nach dem üblichen Verständnis dieser Lizenz den Quellcode der eigenen Änderungen unter derselben Lizenz verfügbar machen. Für jemanden, der den Bot privat im kleinen Kreis laufen lässt, ist das praktisch selten ein Thema. Für jemanden, der darauf ein Produkt aufbauen will, ist es das sehr wohl. Eine Rechtsberatung ist das hier nicht, und die Lizenz sollte im Zweifel von jemandem geprüft werden, der dazu befugt ist.
Hinzu kommt die Abhängigkeitskette. WeClone setzt auf LLaMA Factory, auf PyTorch mit CUDA 12.6 oder neuer und auf uv als Paketmanager. Jede dieser Komponenten bewegt sich, und ein Upgrade der einen kann die andere brechen. Die Versionshistorie im Material zeigt Releases im Abstand von mehreren Monaten, zuletzt v0.3.03 im Januar 2026. Ein sprunghafter Release-Zyklus ist das nicht, was für Stabilität spricht, aber auch bedeutet, dass Fehlerkorrekturen nicht schnell nachkommen.
Das Modell selbst ist ein weiterer Pflegeposten. Ein einmal trainiertes LoRA-Adapterset veraltet nicht, aber es bildet auch nur den Datenstand zum Trainingszeitpunkt ab. Wer den Zwilling aktuell halten will, muss den Export wiederholen, den Filter erneut laufen lassen und neu trainieren. Die README beschreibt keinen inkrementellen Weg dafür.
Redaktionelles Fazit
Wer bereits eine Telegram-Historie mit Text und Bildern besitzt, mindestens 16 GB VRAM für die LoRA-Konfiguration stellen kann und mit der AGPL-3.0 als Projektlizenz leben kann, findet in WeClone eine zusammenhängende Pipeline statt einzelner Skripte. Wer auf WhatsApp, Discord oder Slack als Datenquelle angewiesen ist, sollte warten: Diese Spalten stehen in der README durchgehend auf dem Baustein-Symbol. Vor dem Training ist zu prüfen, ob der eigene Export tatsächlich als Telegram-Ergebnis vorliegt und ob der Filterlauf die eigenen Nachrichten nicht auf einen zu kleinen Rest zusammenstreicht, denn die README nennt als Faustregel selbst, dass ein 7B-Modell nur durchschnittliche Ergebnisse liefert.
Community-Notizen