Kalosm: lokale Modelle in Rust mit erzwungener Ausgabestruktur

Sechs Modalitäten, ein Crate-Namensraum

Das Problem, das Kalosm adressiert, ist die Klebearbeit zwischen Modell-Bindings. Wer in Rust ein Sprachmodell einbinden will, landet üblicherweise bei einer Crate für llama.cpp, einer weiteren für Whisper, einer dritten für Embeddings, und jede bringt eigene Tensor-Typen, eigene Fehlertypen und eigene Ladekonventionen mit. Kalosm setzt stattdessen auf einen gemeinsamen Einstiegspunkt: use kalosm::language::*;, danach folgen Modelle wie Llama::phi_3() oder Mistral. Die README listet sechs Modellfamilien mit Modality, Größenbereich, Quantisierung und GPU-Beschleunigung: Llama von 1b bis 70b, Mistral 7 bis 13b, Phi 2b bis 4b, Whisper von 20MB bis 1GB, Segment Anything von 50MB bis 400MB und Bert von 100MB bis 1GB. Für jede Zeile verweist die Tabelle auf eine Beispieldatei im Verzeichnis interfaces/kalosm/examples, etwa chat.rs, transcribe.rs, segment-image.rs und semantic-search.rs. Die Zielgruppe sind damit Rust-Entwickler, die Inferenz lokal oder gegen einen entfernten Endpunkt betreiben wollen und keine Python-Laufzeit dazwischen schalten möchten. Wer nur ein einzelnes Modell braucht, ist mit einem schmaleren Binding besser bedient; der Nutzen von Kalosm entsteht aus der Kombination mehrerer Modalitäten im selben Prozess.

Structured Generation als Kernentscheidung

Der technisch interessanteste Teil ist nicht die Modellliste, sondern die Einschränkung der Ausgabe. Kalosm erzeugt Text nicht frei und parst anschließend, sondern schränkt den Sampler während der Generierung ein. Die README beschreibt das als eigenen Parser-Engine und Sampler mit structure-aware acceleration und behauptet, strukturierte Generierung sei dadurch schneller als unkontrollierte Textgenerierung. Diese Aussage stammt aus der Projektdokumentation; unabhängige Messwerte liegen in dem Material nicht vor, und ich habe sie nicht nachgeprüft. Der Mechanismus ist an einem Typ festgemacht. Aus einem gewöhnlichen Rust-Struct wird per #[derive(Parse, Schema)] ein Generierungsziel, dessen Felder Attribute wie #[parse(pattern = "[A-Z][a-z]{2,10} [A-Z][a-z]{2,10}")] oder #[parse(range = 1..=100)] tragen. Das Beispiel definiert Character mit name, age und description und fordert anschließend ein Array der Länge 10 an: let characters: [Character; 10] = stream.await.unwrap();. Die Einschränkung wirkt also auf Zeichenebene, nicht auf der Ebene eines JSON-Schemas, das nachträglich validiert würde. Die README nennt zusätzlich eigene Grammatiken als Alternative zu regulären Ausdrücken und nennt JSON, HTML und XML als mögliche Zielstrukturen. Für Anwendungen, die Modellausgaben direkt weiterverarbeiten, ist das der eigentliche Grund, Kalosm statt eines generischen Bindings zu wählen.

Fusor: Compiler statt handgeschriebener Shader

Unter der Modell-API liegt ein zweites Projekt im selben Repository. Fusor wird in der README als compiler-backed runtime für quantisierte ML-Inferenz auf CPUs und WebGPU-Aktivatoren beschrieben und lädt GGUF-Modelle. Die Idee: Operationen werden nicht als feste Kernel implementiert, sondern als Ausdrücke formuliert und von einem E-Graph-Compiler zu optimierten Kernels verschmolzen. Das Beispiel in der README ist eine Funktion exp_add_one, die 1. + (-tensor).exp() berechnet und laut Dokumentation in einen einzigen Kernel kompiliert werden kann. Modellautoren sollen dadurch keinen Shader-Code schreiben müssen. Wichtiger als die Idee ist der Reifegradhinweis, den die README selbst gibt: Fusor sei noch früh in der Entwicklung und nicht für den Produktionseinsatz bereit. Das ist eine ungewöhnlich deutliche Selbsteinschätzung und sollte bei der Bewertung stärker wiegen als die Modelltabelle. Wenn Kalosms Modell-Crates auf Fusor als lokalen Inferenz-Backend aufsetzen, erbt jede Anwendung diese Einschränkung, unabhängig davon, wie stabil die öffentliche Kalosm-API wirkt.

Vom leeren Verzeichnis zum Chatbot

Der Einstieg ist in der README als Fünf-Schritt-Ablauf dokumentiert. Nach der Rust-Installation per rustup wird ein Projekt angelegt, danach die Abhängigkeiten ergänzt: cargo add kalosm --features llama und cargo add tokio --features full. Die Feature-Auswahl ist dabei nicht optional, sondern bestimmt, welche Modellfamilien überhaupt kompilierbar sind; wer Whisper nutzen will, braucht ein anderes Feature als llama. Der Beispielcode in main.rs erzeugt das Modell mit Llama::phi_3().await?, hängt einen System-Prompt an und betreibt eine Schleife über prompt_input("\n> "), deren Ausgabe per to_std_out() auf die Konsole gestreamt wird. Gestartet wird mit cargo run --release. Der Release-Hinweis ist bei lokaler Inferenz kein Detail: Debug-Builds von Rust sind für rechenintensive Schleifen ungeeignet. Bemerkenswert ist, dass die README für den vollständigen Einstieg auf die Projektwebsite floneum.com/kalosm verweist und die Beispiele im Repository als zweite Quelle nennt. Wer den Ablauf nachbaut, sollte mit dem Chat-Beispiel beginnen und erst danach auf strukturierte Generierung wechseln, weil dort zusätzliche Typableitung und Fehlerbehandlung hinzukommen.

Kontext, Audio und Crawling als Beigabe

Neben den Modellen listet die README drei Hilfsbereiche. Erstens Kontextverarbeitung: Extrahieren aus txt, html, docx, md und pdf, Aufteilen in Chunks und anschließendes Suchen über Vektor-Datenbank-Integrationen, demonstriert in context_extraction.rs, chunking.rs und semantic-search.rs. Zweitens Transkription aus Mikrofon oder Datei, gezeigt in transcribe.rs. Drittens Crawling und Scraping von Webseiten in crawl.rs. Diese Teile sind für Retrieval-Pipelines relevant, weil sie die Schritte zwischen Dokument und Prompt abdecken, ohne dass eine separate Python-Toolchain nötig wird. Die README beschreibt die Bereiche jedoch nur als Aufzählung mit Verweisen auf Beispiele; Details zu Chunking-Strategien, unterstützten Vektor-Datenbanken oder Formatgrenzen stehen dort nicht. Wer eine dieser Funktionen einplanen will, muss die jeweilige Beispieldatei lesen, bevor er Aufwand kalkuliert. Das ist kein Mangel der Bibliothek, aber ein Mangel der Dokumentation, den man beim Einstieg einpreisen sollte.

Wo Kalosm die falsche Wahl ist

Drei Grenzen lassen sich aus dem Material ableiten. Die erste betrifft die Plattform: WebGPU-Beschleunigung wird über Fusor beschrieben, und Fusor ist laut README nicht produktionsreif. Wer eine stabile GPU-Pipeline für den Einsatz braucht, verlässt sich auf einen als früh markierten Bestandteil. Die zweite betrifft die Struktur der Ausgabe. Erzwungene Grammatiken garantieren die Form, nicht die inhaltliche Korrektheit. Ein mit #[parse(range = 1..=100)] erzeugtes Alter ist syntaktisch gültig, aber deshalb nicht wahr. Anwendungen, die Fakten aus der Ausgabe ableiten, brauchen weiterhin eine Prüfschicht. Die dritte betrifft die Abdeckung: Die Tabelle nennt sechs Modellfamilien, und die Feature-Flags in cargo add kalosm --features llama zeigen, dass die Auswahl beim Kompilieren festgelegt wird. Ein Modell, das nicht in dieser Liste steht, lässt sich nicht einfach über dieselbe API anbinden. Wer ein aktuelles oder spezialisiertes Modell außerhalb dieser Familien benötigt, ist mit einem direkteren Binding besser bedient.

Der Vergleich mit llama.cpp-Bindings

Die naheliegende Alternative ist ein Rust-Binding direkt auf llama.cpp, etwa über eine Crate, die nur Llama- und Mistral-Gewichte lädt und die Sampling-Schleife offenlegt. Der Unterschied liegt nicht in der Inferenzgeschwindigkeit, sondern in der Zuständigkeit. Ein solches Binding überlässt dem Anwender die Token-Auswahl, die Prompt-Formatierung und jede Einschränkung der Ausgabe; Kalosm nimmt ihm das ab und liefert dafür eine feste API-Form mit Modellkonstruktoren wie Llama::phi_3(). Umgekehrt gilt: Wer eigene Sampler-Strategien braucht oder auf eine Modellarchitektur zielt, die Kalosm nicht auflistet, muss bei einem schlanken Binding bleiben oder die Einschränkung umgehen. Ein zweiter Unterschied ist die Breite. Ein llama.cpp-Binding deckt Text ab; für Transkription und Bildsegmentierung braucht man zusätzliche Crates mit eigenen Typen. Kalosm zieht diese unter use kalosm::language::* zusammen, was den Code kürzer macht, aber auch bedeutet, dass die Abhängigkeitskette mit der Zahl der genutzten Modalitäten wächst.

Versionen, Lizenz und Pflegeaufwand

Das Repository steht unter Apache-2.0, was die kommerzielle Nutzung und Weitergabe erlaubt, solange Lizenz- und Urheberrechtshinweise erhalten bleiben. Das ist keine Rechtsberatung, und die Modellgewichte selbst fallen nicht unter diese Lizenz; deren Bedingungen hängen vom jeweiligen Modell ab und sind in diesem Material nicht aufgeführt. Wer Llama, Mistral oder Phi ausliefert, muss die Lizenz des Gewichts separat prüfen. Bei den Versionen ist der Abstand auffällig: v0.2.0 erschien im September 2023, kalosm-0.3.0 im August 2024, kalosm-0.4.0 im Februar 2025. Der letzte Push ins Repository datiert auf September 2026, es liegen also Aktivität und ein größerer Versionssprung zwischen den Releases. Das Muster deutet auf seltene, dafür größere Veröffentlichungen hin. Für Anwender heißt das: Ein Upgrade von 0.3 auf 0.4 kann mehr als nur Fehlerkorrekturen enthalten, und die Abhängigkeit von tokio sowie die Feature-Flags in Cargo.toml sollten bei jedem Sprung neu geprüft werden. Wer auf eine feste Version pinnt, reduziert dieses Risiko, verliert aber Modellunterstützung, die erst in späteren Releases ergänzt wurde.

Redaktionelles Fazit

Wer in Rust eine lokale Pipeline aus Sprachmodell, Transkription und Embeddings braucht und die Ausgabe per #[derive(Parse, Schema)] an einen Typ binden will, findet in Kalosm eine zusammenhängende API statt sechs einzelner Bindings. Wer Produktionsreife für Bildverarbeitung oder GPU-Inferenz sucht, sollte zuerst den Reifegradhinweis zu Fusor im Repository lesen und die eigenen Zielmodelle gegen die Tabelle in der README prüfen.

Offizielle Quellen

1. floneum/kalosm on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases