Bolmo 1B Stage 1 et Bolmo 7B Stage 1 : protocole d’inférence locale pour évaluer la représentation par octets

Architecture par octets : de la tokenisation subword à l’encodage UTF-8

La plupart des modèles de langage actuels traitent des unités discrètes appelées tokens, produites par des méthodes de tokenisation subword comme BPE ou WordPiece. Cette approche est efficace, mais elle peut masquer des informations fines. C’est un enjeu pour les données scientifiques, le code ou les séquences biologiques, où le sens dépend parfois de caractères individuels. Bolmo, une famille de modèles développée par l’Allen Institute for AI (Ai2), traite directement les octets de l’encodage UTF-8 du texte, au lieu de s’appuyer sur un vocabulaire de fragments de mots propre à une langue ou à un domaine.

Ai2 décrit une conversion en deux étapes qui transforme des modèles subword existants en modèles opérant au niveau des octets, avec un budget d’entraînement supplémentaire limité. Le projet vise ainsi une représentation commune aux langues et aux systèmes d’écriture, et met en avant les tâches où la compréhension des caractères compte. Cela ne signifie toutefois pas que chaque modèle byte-level sera automatiquement plus robuste ou plus performant dans toute tâche : ces propriétés doivent être vérifiées avec les checkpoints et les données concernés.

Il faut également distinguer l’architecture des checkpoints précis. Le dépôt du projet répertorie Bolmo 1B Stage 1 à 1,5 milliard de paramètres et Bolmo 7B Stage 1 à 7,6 milliards. Il indique que l’étape 1 apprend les composants locaux liés à la représentation par octets, tandis que le modèle global reste gelé. Ces checkpoints ne doivent donc pas être confondus avec les versions ayant suivi l’entraînement de bout en bout de l’étape 2.

Une représentation par octets n’implique pas, à elle seule, une inférence plus rapide, une empreinte mémoire plus faible ou une meilleure qualité. Le nombre d’unités produites, la longueur des séquences, l’implémentation, la précision numérique et le matériel influencent tous les résultats. Le protocole ci-dessous vise donc à mesurer les coûts dans un environnement donné, plutôt qu’à déduire des performances à partir du seul choix de représentation.

Matériel et mémoire : ce que l’on peut estimer, et ce qui reste à mesurer

Les tailles publiées permettent de comparer l’ordre de grandeur des poids, mais pas de déterminer à elles seules la configuration matérielle requise pour une inférence efficace. Le dépôt d’Ai2 recense 1,5 milliard de paramètres pour Bolmo 1B Stage 1 et 7,6 milliards pour Bolmo 7B Stage 1. Les sources disponibles ne donnent pas de minimum vérifié de VRAM ou de RAM pour exécuter ces variantes, ni de seuil universel correspondant à une utilisation « efficace ».

Une estimation élémentaire de la mémoire des poids peut servir de point de départ : le nombre de paramètres multiplié par le nombre d’octets utilisé pour les stocker. À titre de calcul théorique, des poids en FP16 ou BF16 occupent environ deux octets par paramètre, contre environ quatre en FP32, avant prise en compte des autres allocations. Ce calcul n’est pas une spécification matérielle d’Ai2 et ne suffit pas à savoir si un modèle tiendra dans la mémoire disponible.

L’inférence réserve aussi de la mémoire pour les activations, le cache des clés et valeurs (KV cache), les buffers et les opérations temporaires. La longueur du contexte, le nombre de séquences traitées simultanément, la taille de sortie, la précision, la quantification et l’implémentation peuvent modifier sensiblement le pic observé. De plus, les séquences en octets peuvent contenir davantage d’unités que des séquences tokenisées subword équivalentes. Il faut mesurer ces effets avec les entrées et les paramètres réellement prévus pour le déploiement.

À capacité et précision identiques, le checkpoint de 7,6 milliards de paramètres aura une empreinte de poids plus élevée que celui de 1,5 milliard. Cela ne permet pas de fixer un chiffre de VRAM garanti pour l’un ou l’autre. Avant un achat ou une décision de déploiement, il faut charger le checkpoint ciblé sur le matériel envisagé, avec les mêmes longueurs de contexte et réglages que ceux de production, puis relever le pic de mémoire. Une mesure en RAM système est aussi utile si le chargement, le transfert ou l’exécution utilise la mémoire hôte.

Confidentialité et isolation des données sensibles

L’inférence locale peut réduire l’exposition des données en évitant de les envoyer à un service externe. Elle ne garantit pas automatiquement la confidentialité : celle-ci dépend aussi de la configuration du système, des journaux, des outils de surveillance, des permissions, des sauvegardes et des communications réseau. Une équipe qui traite des données sensibles doit vérifier que le modèle, ses dépendances et son pipeline restent dans le périmètre prévu, et que les entrées ne sont pas transmises ailleurs.

La représentation par octets évite de dépendre d’un vocabulaire subword pour représenter les caractères, mais elle ne supprime pas toute étape de prétraitement. Le texte doit toujours être encodé correctement, et les données doivent être traitées de façon cohérente entre la collecte, l’inférence et l’interprétation des sorties. L’intérêt pratique est de tester directement des entrées difficiles pour un tokenizer donné, notamment du texte multilingue, des caractères rares ou des séquences techniques.

La confidentialité et la qualité de représentation sont deux questions distinctes. Faire tourner un modèle en local peut répondre à une exigence de résidence des données, tandis que le choix d’une architecture byte-level peut être pertinent pour des entrées sensibles aux caractères. Ni l’un ni l’autre ne prouve que le modèle est adapté à la tâche. L’évaluation doit donc inclure des contrôles de sécurité et des tests fonctionnels séparés.

Pour rendre l’essai utile, préparez un jeu d’entrées autorisées qui reflète les cas attendus : plusieurs langues, signes diacritiques, caractères inhabituels, code ou formats techniques. Vérifiez que les entrées sont décodées comme prévu, que les sorties sont correctement interprétées et que les journaux ne contiennent pas de données qu’il ne faut pas conserver. Ces vérifications sont particulièrement importantes lorsqu’un modèle est intégré à une application interne.

Protocole de pilote : exécuter les modèles et mesurer les résultats

Un pilote pertinent compare les deux checkpoints dans des conditions documentées et reproductibles. Le dépôt officiel fournit des instructions d’installation et un exemple d’inférence avec Transformers. Il explique également que les checkpoints Hugging Face peuvent nécessiter le chargement de code de modèle distant avec l’option correspondante. Vérifiez les dépendances et les instructions actuelles du dépôt, puis consignez les versions installées, le matériel, le checkpoint exact et les paramètres utilisés.

Ne modifiez qu’un facteur à la fois. Commencez par charger chaque checkpoint séparément sur le même système, puis mesurez le temps de chargement et la mémoire occupée. Pour les essais de génération, utilisez le même ensemble d’entrées, le même contexte, le même nombre d’octets générés demandé et les mêmes paramètres de décodage, dans la mesure où ils sont applicables aux deux modèles. Effectuez plusieurs répétitions et distinguez le temps de chauffe des mesures après stabilisation.

La latence peut désigner plusieurs choses : le temps jusqu’au premier élément produit, le temps total de génération ou le délai par unité de sortie. Le throughput peut être exprimé en octets par seconde pour un modèle qui génère des octets, mais il faut aussi noter le nombre de caractères ou la taille du texte décodé afin de faciliter l’interprétation. Les tokens par seconde ne constituent pas nécessairement une unité comparable entre un modèle byte-level et un modèle subword.

Enregistrez le pic de VRAM et de RAM, la latence de premier résultat, la durée totale, le débit, la longueur de l’entrée et de la sortie, ainsi que les erreurs et les éventuels ralentissements. Mesurez les performances dans une configuration proche de la production : précision, quantification, taille de lot et limites de contexte comprises. Ne mélangez pas les mesures réalisées avec des réglages différents et ne tirez pas de conclusion sur la qualité à partir du seul débit.

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "allenai/Bolmo-1B-Stage1"  # Ou le checkpoint Bolmo 7B Stage 1
device = "cuda" if torch.cuda.is_available() else "cpu"

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    trust_remote_code=True,
).to(device)
tokenizer = AutoTokenizer.from_pretrained(
    model_id,
    trust_remote_code=True,
)

inputs = tokenizer(
    ["Texte d’essai à compléter : "],
    return_tensors="pt",
)["input_ids"].to(device)

with torch.inference_mode():
    output = model.generate(
        inputs,
        max_new_tokens=128,  # Nombre d’octets générés selon l’exemple du projet
        do_sample=False,
    )

print(tokenizer.decode(output[0], skip_special_tokens=True))

Limites des preuves et comparaison prudente

Les éléments primaires disponibles établissent l’existence des checkpoints Stage 1, leur nombre de paramètres, leurs modèles de base et la portée de cette étape d’entraînement. Le dépôt décrit l’étape 1 comme l’apprentissage des composants locaux de la représentation par octets avec le modèle global gelé. L’article original présente Bolmo et son approche de conversion en deux étapes. Ces éléments ne fournissent pas, à eux seuls, un tableau de prérequis matériels locaux ni une comparaison contrôlée de latence et de débit pour les deux checkpoints Stage 1.

Il faut donc éviter de présenter des estimations de VRAM comme des valeurs garanties ou de supposer que la taille des paramètres suffit à déterminer la mémoire nécessaire. De même, la description de l’architecture ne permet pas de conclure que le modèle de 7B sera meilleur en génération, ni que celui de 1B sera toujours plus rapide sur un appareil donné. Les performances dépendent de la tâche, des données, du matériel, de l’implémentation et des réglages.

La portée de l’étape 1 est aussi importante pour l’évaluation fonctionnelle : ses composants locaux ont été entraînés tandis que le modèle global est resté gelé. Les conclusions observées sur ce checkpoint ne doivent pas être attribuées automatiquement à un modèle ayant suivi l’étape 2, ni l’inverse. Une comparaison de qualité demanderait des tests adaptés à la tâche, une configuration équitable et des critères définis à l’avance.

L’article est accessible sous forme de prépublication sur arXiv et constitue une source primaire du travail. Les informations disponibles ici ne suffisent pas à établir le statut de publication évaluée par les pairs, une réplication indépendante ou une validation exhaustive des performances en déploiement local. Pour les besoins opérationnels, la meilleure démarche est de traiter les résultats publiés comme du contexte, puis de produire des mesures internes reproductibles et de consigner leurs limites.

Le rapport du pilote doit ainsi préciser ce qui a été mesuré, ce qui a été tenu constant et ce qui ne l’a pas été. Il doit distinguer l’empreinte des poids de la mémoire totale, la latence du débit et la capacité à traiter des caractères de la qualité globale des réponses. Sans ces distinctions, une comparaison de matériel ou de qualité risque de donner une impression de certitude que les preuves disponibles ne justifient pas.

Cadre de décision : choisir selon les contraintes du déploiement

Pour un premier tri, confrontez la taille des checkpoints aux contraintes de mémoire réellement mesurées sur l’appareil cible. Si le budget matériel est strict, commencez par tester Bolmo 1B Stage 1, sans présumer qu’il répondra au besoin fonctionnel. Si le cas d’usage exige de tester le checkpoint de 7,6 milliards de paramètres, vérifiez auparavant la mémoire disponible pour les poids et les allocations d’inférence, avec la longueur de contexte prévue.

Si la priorité est la confidentialité, examinez l’ensemble du chemin de données : chargement des modèles, appels réseau, télémétrie, journaux, fichiers temporaires et accès des utilisateurs. L’inférence locale peut contribuer à réduire les transferts externes, mais la propriété doit être confirmée par la configuration et les contrôles de sécurité de l’organisation. Le choix byte-level doit, lui, être justifié par les caractéristiques des entrées ou par des résultats de test, pas seulement par une promesse générale de robustesse.

Si l’enjeu principal est la latence, mesurez-la sur les requêtes typiques, en distinguant le délai initial du temps de génération et en fixant une définition commune du débit. Si l’enjeu est la qualité, évaluez des exemples représentatifs et des critères propres à la tâche ; ne déduisez pas cette qualité du nombre de paramètres ou de la représentation. Dans tous les cas, conservez les résultats séparés pour Stage 1 et Stage 2 lorsque les deux sont disponibles.

La décision finale doit refléter les compromis observés : mémoire, délai, débit, traitement des entrées ciblées, exigences d’isolation et complexité d’exploitation. Un pilote ne cherche pas à prouver qu’une architecture est meilleure en général, mais à déterminer si un checkpoint précis répond aux exigences d’un environnement précis. Cette distinction rend les conclusions plus utiles et plus faciles à reproduire.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.