Ternary Bonsai 2 27B : parité entre WebGPU et les environnements natifs pour l'inférence IA locale

Pourquoi Ternary Bonsai 2 27B change la question de l'IA locale dans le navigateur par rapport au natif

Ternary Bonsai 2 27B est intéressant parce qu'il apparaît dans plus d'une catégorie d'environnement d'exécution. La sortie de Prism ML du 17 septembre décrit un checkpoint ternaire de classe 27B basé sur Qwen3.8, un format à 1,76 bits effectifs et une empreinte de modèle annoncée à 5,9 Go. La collection Hugging Face associée pointe vers des artefacts natifs comme GGUF et MLX. Le Space WebGPU ajoute une voie navigateur.

Ce mélange change la question. La question utile n'est plus : "Ce modèle peut-il s'exécuter localement ?" Elle devient : "Quelles parties de l'expérience locale survivent au passage d'un environnement natif à un environnement navigateur ?"

C'est un seuil plus étroit et plus utile. Une démonstration dans le navigateur ne prouve pas la parité avec CUDA ou MLX sur le débit, la longueur de contexte, la prise en charge des fonctionnalites, le comportement mémoire, la journalisation ou la répétabilité. Elle prouve qu'il existe assez de surface d'artefacts publics pour tester correctement la limite.

Cet article n'est pas une reprise de l'ancien test d'acceptation sur appareil de Bonsai 1 par Optijara. L'article de juillet examinait l'acceptation de première génération sur appareil. Bonsai 2 demande une lecture de parité d'environnement : téléchargement, cache, configuration de l'adaptateur WebGPU, compilation des shaders ou des kernels, chargement du modèle, prefill, decode, comportement du contexte, limites texte et image, et répétabilité face aux voies natives. Pour les équipes qui comparent le comportement de fichiers quantifiés entre environnements, le guide de migration des recettes de quantification et des cartes de disposition GGUF par tenseur est le meilleur compagnon.

WebGPU dans le navigateur est une experience produit avant d'être une histoire de benchmark. Il peut offrir un moyen a faible friction de laisser une partie prenante toucher un modèle local. Il peut aussi masquer les détails exacts dont un évaluateur serieux a besoin. Traitez-le comme un environnement avec ses propres modes de défaillance, pas comme une enveloppe plus jolie autour de l'inférence native.

Un garde-fou de plus. Les chiffres de performance natifs de Prism, les publications de la communauté et les réactions rapides aux démonstrations sont des signaux de découverte utiles. Ils ne sont pas des preuves de benchmark interchangeables. Optijara n'a pas exécuté de benchmark indépendant pour cet article. Tous les tests ci-dessous sont des plans de mesure proposés, pas des résultats revendiqués.

La carte des artefacts : ce que chaque source peut prouver

La première tâche consiste à séparer les preuves des suppositions. La page de sortie peut etablir l'annonce, le positionnement du modèle et les affirmations de l'éditeur. La collection Hugging Face peut montrer le regroupement des artefacts publics. Les fiches de modèle individuelles peuvent montrer les fichiers propres à un environnement, les licences, les revisions et les notes d'utilisation. L'arborescence et le README du Space WebGPU peuvent montrer ce que l'artefact navigateur expose dans le code ou l'interface. Aucune de ces sources, seule, ne prouve que chaque capacité du modèle arrive dans le navigateur.

C'est important parce qu'une empreinte de poids de 5,9 Go n'est pas la mémoire maximale. Ce n'est pas la taille du cache navigateur. Ce n'est pas la surcharge de transfert, le cache des shaders, l'allocation de tampons temporaires ou la survie de l'onglet sous pression. L'exécution dans le navigateur peut demander de la mémoire de travail supplémentaire pendant le téléchargement, la compilation, l'exécution et la réhydratation du cache. Les environnements natifs exposent souvent des rapports mémoire, des contrôles de quantification et des journaux plus clairs.

La même prudence s'applique aux affirmations sur le contexte long et le multimodal. Si une famille de modèles ou une architecture mentionne un contexte long ou la vision, cela ne signifie pas que la démo WebGPU prend en charge l'entrée image ou une longueur maximale de contexte pratique. Les limites mémoire du navigateur, le comportement de l'adaptateur GPU, la pression du cache et la construction du prompt ont tous leur mot à dire.

Carte de parité navigateur vers natif

La carte de parité navigateur vers natif utilise cinq dimensions : disponibilité des artefacts, chemin de demarrage, chemin des tokens, surface fonctionnelle et enveloppe d'exploitation. L'objectif n'est pas de couronner WebGPU, MLX ou CUDA. L'objectif est d'arreter de traiter "s'exécute dans le navigateur" comme une réponse oui ou non.

WebGPU peut suffire pour une démonstration, un parcours pédagogique, une évaluation interne ou un prompt local leger où la vitesse de configuration compte plus que l'instrumentation approfondie. Il est particulierement utile quand une équipe veut que des personnes voient une voie de modèle local sans installer d'environnements natifs.

Les voies natives restent importantes quand l'équipe a besoin de benchmarks répétables, de contrôles matériels explicites, d'un meilleur profilage, d'une automatisation de type serveur, de suites d'évaluation plus longues ou de comparaisons attentives entre fichiers quantifiés. MLX est la voie naturelle pour Apple Silicon. CUDA et GGUF sont la voie d'évaluation poste de travail et serveur.

{
  "framework": "Browser-to-Native Parity Map",
  "dimensions": ["artifact_availability", "startup_path", "token_path", "feature_surface", "operating_envelope"],
  "claim": "Parity is workload-specific and must be measured separately for browser WebGPU, MLX, and CUDA or GGUF paths.",
  "benchmark_status": "proposed_test_plan_only"
}

Mesurer séparément le demarrage et la génération de tokens

Une comparaison equitable des environnements Bonsai 2 commence par séparer le demarrage de la génération. Le téléchargement lors de la première visite, le rechargement avec cache, l'initialisation de l'adaptateur WebGPU, la compilation des shaders, le chargement du modèle, la latence du premier token, la vitesse de prefill, la vitesse de decode, la pression mémoire et la stabilite de l'onglet sont des événements distincts. Les fondre dans un score "cela semblait rapide" fait disparaitre le vrai goulot d'etranglement.

Ne comparez pas un chiffre natif de l'éditeur, une anecdote de vitesse sur les réseaux sociaux et une impression de démo navigateur comme s'il s'agissait du même benchmark. Ils peuvent utiliser des matériels, longueurs de prompt, paramètres de contexte, fichiers quantifiés, versions de navigateur et etats de warmup différents.

Un rapport utile doit inclure le pack de prompts exact, la revision du modèle, le commit de l'environnement, le système d'exploitation, l'adaptateur GPU, la version du navigateur, le fichier quantifie, la longueur de contexte et les paramètres de décodage. Si ces détails manquent, le résultat peut rester intéressant, mais il ne doit pas guider une décision d'adoption.

La parité fonctionnelle depasse la sortie texte

La génération de texte est généralement la première cible de parité parce qu'elle est visible et facile a tester. Mais la parité texte n'est pas la parité complete du modèle. Les équipes doivent aussi vérifier le comportement JSON structuré, la reutilisation du contexte multi-tour, le resume de longs documents, le comportement de refus si pertinent et la variance entre executions répétées.

La prise en charge de la vision a besoin de sa propre preuve. Si une famille de modèles complete ou une documentation mentionne une capacité multimodale, l'artefact navigateur à encore besoin d'une preuve dans l'interface et le code avant que quelqu'un affirme la prise en charge de l'entrée image. Les libellés utiles sont pris en charge, partiellement pris en charge, non pris en charge ou inconnu jusqu'àu test.

Le contexte long merite la même discipline. Une affirmation de contexte au niveau de l'architecture ne signifie pas qu'un onglet de navigateur peut traiter le contexte maximal avec une mémoire, une latence et une stabilite acceptables. Pour Bonsai 2, la meilleure question opérationnelle n'est pas "quel est le contexte théorique ?" C'est "quelles longueurs de prompt restent stables et utiles dans cet environnement sur cet appareil ?"

Cette formulation est moins spectaculaire, mais elle aide les équipes à éviter de livrer une supposition de démo comme promesse produit.

Une matrice pratique de tests par appareil et flux de travail

Les équipes doivent évaluer Bonsai 2 sur plusieurs appareils et flux de travail, pas avec un seul prompt favorable. La matrice ci-dessous est un plan proposé, pas un résultat de benchmark d'Optijara.

La suite de prompts doit inclure une instruction courte, un résumé de long document, une sortie JSON structurée, un test de reutilisation du contexte multi-tour, une vérification d'entrée image seulement si l'artefact la prend en charge, et une vérification de rechargement du cache. Notez réussite, prudence ou échec. "Prudence" est utile quand un environnement fonctionne pour du texte court mais echoue sur un contexte long, nécessite un flag de navigateur spécifique ou se comporte differemment après un rechargement à chaud.

Erreurs courantes lors du test de l'IA locale navigateur face aux environnements natifs

La première erreur consiste à traiter la taille de téléchargement comme une exigence mémoire. L'empreinte indiquée par l'éditeur est un fait d'artefact de modèle, pas une enveloppe d'exécution complete. Mesurez la mémoire maximale, la taille du cache, les tampons temporaires et le comportement de défaillance.

La deuxième erreur consiste à traiter le débit natif comme un débit navigateur. Les chiffres CUDA ou MLX natifs ne se transferent pas automatiquement a WebGPU. Mesurez chaque environnement sur sa propre voie.

La troisième erreur consiste à traiter la prise en charge en démo comme une prise en charge complète du modèle. Un Space navigateur peut exposer la génération de texte tout en laissant l'entrée image, le contexte complet ou les contrôles avancés non pris en charge. Inspectez les fichiers, l'interface et le comportement réseau avant de formuler des affirmations.

La quatrième erreur consiste à supposer que l'IA locale dans le navigateur est privée par défaut. L'exécution locale peut encore impliquer des endpoints de récupération, un comportement de stockage, des service workers, de la télémétrie ou des appels de dépendances. Inspectez le chemin réseau. Deconnectez le réseau après le chargement à chaud et observez ce qui fonctionne encore.

La cinquième erreur consiste à utiliser un seul prompt comme benchmark. Une instruction polie unique peut masquer des problemes de contexte, de structuré, de décodage et de stabilite. Utilisez une suite de prompts et conservez les entrées exactes sous contrôle de version.

Mises en garde et compromis opérationnels

L'IA locale orientée navigateur peut réduire la friction de configuration, mais elle ne supprime pas le travail d'implémentation. La sécurité et la confidentialite demandent toujours une revue de code, une inspection réseau, une revue du cache, une revue des dépendances et des tests de comportement hors ligne.

La performance varie selon le navigateur, le pilote, l'adaptateur GPU, la mémoire de l'appareil, l'état thermique et le rythme de mise à jour de l'environnement. La reproductibilité est plus difficile quand le navigateur fait partie de l'environnement d'exécution. Une mise à jour du navigateur, une mise à jour du pilote, un changement de compilateur de shaders ou une invalidation du cache peut changer l'expérience.

Les voies natives demandent plus de configuration, mais elles donnent souvent aux équipes un contrôle plus fort sur les versions, les journaux, le profilage et l'automatisation. La maintenance est le coût cache. Si une équipe livre de l'IA navigateur comme outil interne, quelqu'un est responsable de la compatibilité navigateur, des mises à jour d'artefacts de modèle, de l'invalidation du cache et des notes de support pour les appareils non pris en charge. Si une équipe livre des flux natifs, quelqu'un est responsable de l'installation de l'environnement, des pilotes, des fichiers quantifiés et des contraintes matérielles. Aucune voie n'est gratuite.

Guide de décision : WebGPU, MLX, CUDA ou voie mixte

Choisissez WebGPU navigateur quand l'objectif est une démonstration a faible friction, un parcours pédagogique, un pilote interne ou une voie d'évaluation où les utilisateurs peuvent accepter des limites fonctionnelles explicites. C'est une bonne première experience quand l'équipe veut tester l'intérêt avant d'installer des piles natives.

Choisissez MLX quand le public d'évaluation est principalement sur Apple Silicon et que l'équipe a besoin d'une intégration native, de répétabilité et d'une caracterisation des appareils Apple. MLX est aussi utile quand la voie navigateur fonctionne mais n'expose pas assez d'observabilite pour une comparaison serieuse.

Choisissez CUDA ou GGUF quand l'équipe a besoin d'une évaluation de type poste de travail ou serveur, d'une instrumentation plus profonde, d'une comparaison de quantification, de suites de prompts plus longues ou de tests de performance contrôles. Cette voie a un coût de configuration plus élevé, mais c'est généralement la voie la plus solide pour une mesure répétable.

Utilisez plusieurs environnements quand Bonsai 2 apparaîtra dans plus d'un contexte. Une démo navigateur peut aider les parties prenantes a comprendre l'expérience. MLX peut accompagner les ordinateurs portables des développeurs Apple. CUDA ou GGUF peut ancrer une évaluation contrôlée. C'est là que la carte de parité navigateur vers natif gagne son utilite : elle transforme le choix d'environnement en test d'acceptation documente plutôt qu'en debat sur les titres de lancement.

Pour les équipes qui ont besoin d'un plan de test neutre, Optijara peut aider à définir la suite de prompts, la matrice d'environnements, les champs de mesure et les notes d'adoption sans supposer à l'avance que le navigateur, MLX ou CUDA est la bonne réponse.