Kalosm : modèles pré-entraînés locaux en Rust, avec génération structurée

Le problème : faire cohabiter plusieurs modalités sans quitter Rust

Un développeur Rust qui veut un chatbot local, une transcription audio et une segmentation d'image doit aujourd'hui assembler trois piles différentes : un binding pour llama.cpp, un autre pour whisper.cpp, un troisième pour un modèle de vision. Chacune a ses formats de poids, ses conventions de tokenisation et son propre cycle de publication. Kalosm prend le pari inverse : une seule crate d'interface, kalosm, avec des fonctionnalités activables par modalité, et un catalogue de modèles déclaré dans le README. Le public visé est clair : des équipes qui écrivent des applications de bureau ou des outils internes en Rust et qui refusent d'envoyer leurs données à une API distante. Le README mentionne aussi le cas des modèles distants, mais l'argument du projet est bien l'exécution locale. Ce n'est pas une plateforme de service : il n'y a pas de serveur à déployer, seulement des crates à lier.

Deux projets dans un même dépôt : kalosm et Fusor

Le dépôt contient deux ensembles distincts. interfaces/kalosm expose l'API que vous utilisez : Llama, Mistral, Phi, Whisper, Segment Anything et Bert, chacun avec sa taille annoncée et ses indicateurs de quantification et d'accélération GPU. fusor/fusor est décrit comme le backend d'inférence local utilisé par les crates de modèles de Kalosm. Fusor charge des modèles au format GGUF et s'appuie sur un compilateur à e-graphs pour fusionner des chaînes d'opérations en un noyau unique, sans que l'auteur du modèle ait à écrire de code de shader. L'exemple donné dans le README est une fonction qui calcule 1 + exp(-x) et que le compilateur peut réduire à un seul noyau. Cette séparation a une conséquence pratique : quand vous liez kalosm, vous dépendez indirectement d'un composant dont le README dit lui-même qu'il est encore tôt dans son développement et non prêt pour la production. C'est un choix architectural assumé, pas un détail de documentation.

La génération structurée, mécanisme central du projet

C'est la partie la plus intéressante et la plus spécifique. Kalosm ne se contente pas de parser la sortie du modèle après coup : il contraint la génération. Le README indique que le projet utilise un moteur de parsing et un sampler maison, avec une accélération sensible à la structure, et affirme que la génération contrainte est plus rapide que la génération de texte non contrôlée. Vous annotez un type Rust avec #[derive(Parse, Schema)], puis vous décrivez chaque champ par un attribut : #[parse(pattern = "[A-Z][a-z]{2,10} [A-Z][a-z]{2,10}")] pour un nom, #[parse(range = 1..=100)] pour un âge, #[parse(pattern = "[A-Za-z ]{40,200}")] pour une description. L'exemple du README crée un modèle avec Llama::phi_3(), construit une tâche avec model.task(...).typed(), puis récupère un [Character; 10] directement depuis le flux. Le gain est net : plus besoin d'écrire un validateur JSON ni de relancer le modèle quand la sortie est malformée. Le README précise qu'au-delà des expressions régulières, on peut fournir sa propre grammaire pour cibler du JSON, du HTML ou du XML. Ce qui n'est pas documenté dans le matériel fourni : le coût exact de cette contrainte sur des grammaires profondes, et la façon dont le sampler se comporte quand plusieurs champs ont des motifs incompatibles.

Mise en route : les commandes réellement documentées

Le quickstart du README tient en cinq étapes. Créez le projet avec cargo new kalosm-hello-world, entrez dans le dossier, puis ajoutez les dépendances avec cargo add kalosm --features llama et cargo add tokio --features full. Le code minimal utilise use kalosm::language::*;, construit le modèle avec Llama::phi_3().await?, ouvre un chat avec model.chat().with_system_prompt("You are a pirate called Blackbeard"), puis boucle sur chat(&prompt_input("\n> ")?).to_std_out().await?. L'exécution se fait avec cargo run --release. Notez deux points. D'abord, la fonctionnalité llama est obligatoire pour cet exemple : sans elle, Llama n'existe pas. Ensuite, le mode release n'est pas cosmétique, un modèle de plusieurs gigaoctets compilé en debug serait inutilisable. Les autres exemples cités dans le README se trouvent dans interfaces/kalosm/examples : chat-mistral-2.rs, chat-phi-3.rs, transcribe.rs, segment-image.rs, semantic-search.rs, context_extraction.rs, chunking.rs et crawl.rs. Ce sont des fichiers du dépôt, pas des recettes à recopier de mémoire.

Les utilitaires autour du modèle, et ce qu'ils impliquent

Kalosm ne s'arrête pas à l'inférence. Le README liste trois familles d'utilitaires. La première concerne le contexte : extraire du texte depuis txt, html, docx, md et pdf, le découper en morceaux, puis rechercher les passages pertinents via des intégrations de base vectorielle, avec Bert comme modèle d'embedding. La deuxième couvre la transcription audio depuis un microphone ou un fichier, avec Whisper, dont la taille annoncée va de 20 Mo à 1 Go. La troisième est le crawl et le scraping de pages web, avec un exemple dédié. Pris ensemble, ces briques dessinent une chaîne RAG complète en local : vous aspirez des documents, vous les découpez, vous les indexez, vous interrogez un LLM contraint par un type Rust. C'est une proposition cohérente. Mais chaque brique ajoute une dépendance et un modèle à télécharger, et le README ne donne aucune indication sur le stockage requis une fois les poids récupérés. Prévoyez de vérifier ce point vous-même avant de dimensionner une machine.

Fusor : la limite à prendre au sérieux

Le README place un avertissement en tête de la section Fusor : le projet est encore tôt dans son développement et n'est pas prêt pour la production. Ce n'est pas une formule de prudence juridique, c'est une déclaration sur l'état du code. Comme Fusor est le backend d'inférence utilisé par les crates de modèles de Kalosm, la limite remonte jusqu'à l'API de haut niveau. Concrètement, si vous rencontrez un résultat numérique étrange, un plantage ou une lenteur inattendue, la cause peut se situer sous l'interface que vous appelez, dans le compilateur à e-graphs ou dans les noyaux générés. Cela ne disqualifie pas Kalosm pour un prototype, un outil interne ou une démonstration. Cela le disqualifie pour un service où une erreur d'inférence a un coût. Le README ne fournit ni tableau de compatibilité des GPU, ni liste de modèles validés par plateforme, ni chiffres de performance. Toute décision de déploiement devra donc s'appuyer sur vos propres mesures, pas sur la documentation.

Face à llama.cpp lié directement

L'alternative la plus directe est d'utiliser llama.cpp via un binding Rust et de gérer vous-même le reste. La différence n'est pas une question de vitesse d'inférence, puisque Kalosm s'appuie sur un runtime qui charge des GGUF, le même format que llama.cpp. La différence porte sur ce qui vient après le modèle. Avec un binding direct, vous obtenez du texte brut et vous écrivez le parsing, la validation et la relance en cas de sortie invalide. Avec Kalosm, la contrainte est intégrée à la génération via #[derive(Parse, Schema)] et les attributs #[parse(...)]. Vous payez cette commodité par une dépendance à une API en évolution, dont la version publiée la plus récente listée ici est kalosm-0.4.0, datée du 9 février 2025, après kalosm-0.3.0 en août 2024 et 0.2.0 en septembre 2023. Le rythme est irrégulier. Pour un projet qui doit rester stable pendant des années, un binding direct vous donne un contrôle total sur la version du moteur ; pour un projet qui veut un type Rust rempli par le modèle sans code de validation, Kalosm fait gagner du travail réel.

Coût de maintenance, licence et points à vérifier

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et d'état des modifications. Le README ne signale aucune clause additionnelle et aucun changement de licence entre les versions. Rien dans le matériel fourni ne permet de savoir si les poids des modèles téléchargés relèvent d'une licence distincte de celle du code, et c'est un point à contrôler séparément, modèle par modèle, avant toute distribution. Sur la maintenance, le dépôt n'est pas archivé et le dernier push listé est daté du 8 septembre 2026. La version 0.4.0 est sortie en février 2025, soit un écart notable entre les deux. Cela signifie que la branche main peut contenir des API absentes de la version publiée sur crates.io, et que lire les exemples du dépôt ne garantit pas qu'ils compilent contre la version que vous avez ajoutée avec cargo add. Le premier réflexe utile est donc de comparer les exemples visés avec l'état de la version publiée, puis de figer la dépendance dans Cargo.toml plutôt que de suivre main.

Conclusion éditoriale

Kalosm convient aux projets Rust qui doivent faire tourner un LLM, Whisper ou Segment Anything en local, et surtout à ceux qui veulent contraindre la sortie du modèle à un type Rust via #[derive(Parse, Schema)]. Il ne convient pas si vous avez besoin d'un backend d'inférence stable en production : le README qualifie Fusor de non prêt pour la production. Avant d'adopter, vérifiez que la fonctionnalité dont vous dépendez est couverte par la version 0.4.0 et non par une API de main, puis testez le temps de compilation de kalosm avec --features llama sur votre machine.

Sources officielles

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