Open-Weight-Modelle · Anwendungen · Evaluation
KI bauen.
Ergebnisse prüfen.
Ich entwickle Werkzeuge und Anwendungen mit Open-Weight-Modellen. Hier dokumentiere ich, was funktioniert, wo Grenzen liegen und welche Entscheidungen ich daraus ableite.
Beiträge
Experimente, Ergebnisse und die Entscheidungen dahinter.
Ein Sprachmodell liest keinen Text, sondern Zahlen. In diesem Beitrag zeige ich, wie der selbst gebaute Byte-Level-BPE-Tokenizer von nlm einen echten Satz Schritt für Schritt in Token-IDs übersetzt — und wieder verlustfrei zurück.
nlm ist ein kleines, eigenes GPT-ähnliches Sprachmodell für englische Kindergeschichten. In diesem Beitrag erkläre ich, warum ich es von Grund auf baue, auf CPU trainiere und seine Grenzen öffentlich dokumentiere.
An zehn hypothetischen Aufgaben rechne ich API-Kosten, menschlichen Prüfaufwand, Tokenverbrauch, Erfolgsquote und Bearbeitungszeit durch. So wird nachvollziehbar, wie die Kosten pro erfolgreich erledigter Aufgabe entstehen.
Ein niedriger Tokenpreis macht noch kein wirtschaftliches KI-System. An einem hypothetischen E-Mail-Workflow zeige ich, wie Kosten, Erfolgsquote, menschliche Prüfung und Laufzeit gemeinsam bewertet werden können.
Derselbe Text kann je nach Tokenizer unterschiedlich viele Tokens benötigen. An einem Thai-Satz vergleiche ich fünf Tokenizer und zeige, was die Unterschiede für Kontextfenster, Kosten und Modellauswahl bedeuten.
Projekte
Entwicklungen mit nachvollziehbaren Ergebnissen.
nlm
Was passiert technisch wirklich, wenn man ein Sprachmodell nicht nutzt, sondern von der Tokenisierung bis zum Transformer selbst baut – und ohne GPU trainiert?
Ein Transformer-Sprachmodell (~10,66 Mio. Parameter) von Grund auf selbst implementiert und auf CPU trainiert: eigener BPE-Tokenizer, eigene Attention- und Feed-Forward-Schichten, kein Framework, das die Architektur übernimmt. Entwicklung und Trainingsfortschritt werden parallel in einem öffentlichen Build-Log dokumentiert.
Phrom
Sind meine GitHub Issues bereit fürs Refinement – und welche Lücken sollte ich vorher schließen?
Read-only CLI, die GitHub Issues gegen ein transparentes Regelwerk prüft, lokale KI-Checks über Ollama ergänzt und Verbesserungsentwürfe zur manuellen Prüfung erzeugt. Der Product Owner entscheidet, nichts wird automatisch geändert.
Über mich
Ich bin Marius Kalder. Zehn Jahre Erfahrung an der Schnittstelle von Produktstrategie und Engineering — von Anforderungsanalyse und Architekturentscheidungen bis zur Umsetzung auf eigener Infrastruktur.
Mich interessiert nicht nur, ob ein Modell antwortet, sondern ob seine Antwort für eine konkrete Aufgabe brauchbar ist.
Beratung
Ihr arbeitet an einer ähnlichen Aufgabe? Ich unterstütze bei der Bewertung und Integration von KI-Anwendungen.
Kontakt aufnehmen