Inférence locale et hybride

Tous les prompts n'ont pas besoin d'un modèle de pointe hébergé dans le centre de données de quelqu'un d'autre. Bromure Agentic Coding peut exécuter des modèles de codage à poids ouverts directement sur le GPU de votre Mac avec le framework MLX d'Apple — aucun aller-retour vers le cloud, aucune facture au jeton, et aucun code qui quitte la machine. Un espace de travail peut s'exécuter entièrement sur l'appareil, continuer à utiliser le cloud avec un filet de sécurité sur l'appareil, ou combiner les deux, agent par agent.

L'inférence locale est un choix propre à chaque espace de travail, orthogonal à Fusion : Fusion décide combien de modèles répondent à un prompt, tandis que le routage décide quel backend y répond. Ce chapitre explique où s'exécute l'inférence, comment fonctionnent le catalogue de modèles et les téléchargements, les trois modes de routage et le moteur de politique hybride, comment pointer un agent individuel vers un modèle local, et comment observer le comportement du moteur. La référence champ par champ des réglages de ce volet se trouve dans Réglages Modèles locaux.

Remarque : Tout ce qui est décrit ici s'exécute sur l'hôte Mac, pas à l'intérieur de la VM. Virtualization.framework ne donne à l'invité Linux aucun accès au GPU, à Metal ou à MLX, si bien que l'inférence sur l'appareil doit se produire sur macOS et être atteinte depuis l'invité à travers la frontière du fil. Apple Silicon (M1 ou plus récent) est requis — la même exigence que l'application elle-même.

Où s'exécute l'inférence

Le moteur est intégré à l'application ; il n'y a rien à installer, aucun environnement Python, et aucun serveur externe tel qu'Ollama, LM Studio ou une instance vLLM auto-hébergée à cibler. Lorsqu'une session a besoin d'inférence sur l'appareil, l'application démarre un moteur MLX privé et y raccorde l'agent invité.

Le processus enfant du moteur

Le moteur MLX s'exécute comme un processus enfant supervisé du propre binaire de l'application (bromure-cli model _mlx-engine), pas à l'intérieur de l'application elle-même. Il s'agit d'une isolation délibérée : charger un modèle trop volumineux pour la mémoire du Mac ne tue que le processus enfant du moteur, jamais l'application ni ses VM en cours d'exécution. Le parent redémarre automatiquement un moteur qui a planté, jusqu'à trois fois ; au-delà, il abandonne avec la ligne de journal engine child crashed repeatedly — giving up (a model likely OOMs this Mac). L'enfant est tué lorsque l'application se ferme, et tout orphelin laissé par un plantage brutal est récupéré au lancement suivant.

Un seul moteur dessert tous les espaces de travail ouverts. Il se lie à un port de bouclage attribué par le noyau sur 127.0.0.1 — jamais 0.0.0.0, et jamais le classique 11434 (ce port est laissé libre pour qu'une installation distincte d'Ollama ou de LM Studio continue de fonctionner). Il charge plusieurs modèles en parallèle sous un budget mémoire correspondant à la mémoire unifiée de l'hôte moins 16 Go (avec un plancher de 8 Go), chargeant chaque modèle paresseusement à la première utilisation et évinçant celui utilisé le moins récemment lorsque le budget est serré. Ouvrir ou fermer un espace de travail reconfigure le moteur en cours d'exécution à chaud via un point de terminaison d'administration — sans redémarrage.

Pendant que le moteur chauffe, les fenêtres de session affichent une pastille de statut indiquant Démarrage du moteur local… qui disparaît dès que le moteur répond à une sonde de disponibilité.

Comment l'invité atteint le moteur

Les agents dans la VM ne dialoguent jamais directement avec le moteur. Ils ciblent l'hôte synthétique https://bromure.llm — un nom sans DNS réel — et le proxy MITM côté hôte l'intercepte, applique la même analyse d'injection de prompt et la même capture de trace qu'il applique au trafic cloud, puis transmet la requête au moteur sur l'hôte. L'inférence locale n'est donc jamais un angle mort : elle franchit la même frontière du fil et atterrit dans la même piste d'audit qu'un appel à Anthropic.

Les agents sont épinglés à un nom de modèle sentinelle, bromure-local, que l'hôte remappe vers le modèle actuellement actif de l'espace de travail. Changer le modèle actif est un remappage côté hôte sans redémarrage de l'agent — l'agent continue de demander bromure-local et obtient simplement un modèle différent derrière.

Remarque : Un modèle dont l'architecture n'est pas encore prise en charge par le moteur MLX échoue avec une erreur claire et permanente — « son architecture … n'est pas encore prise en charge par le moteur sur l'appareil — choisissez un autre modèle » — renvoyée comme une erreur client afin que l'agent ne la réessaie pas en boucle.

Le catalogue de modèles

Le catalogue est une liste sélectionnée de modèles MLX pré-convertis, chacun vérifié pour ce qui compte le plus en codage agentique : les modèles quantifiés brisent fréquemment l'appel d'outils, aussi chaque entrée du catalogue porte-t-elle un badge de vérification de l'appel d'outils. Les entrées enregistrent également une taille de téléchargement et une exigence minimale de mémoire unifiée, que le volet transforme en une barrière d'adéquation à la RAM.

Un catalogue de base est fourni avec l'application afin que le volet fonctionne hors ligne dès le premier jour. Au lancement, l'application récupère un catalogue actualisé depuis https://dl.bromure.io/mlx/catalog.json ; un manifeste plus récent remplace intégralement le catalogue de base (il n'est pas fusionné). Un modèle retiré du catalogue publié disparaît de la liste — sauf si vous l'avez déjà installé, auquel cas il subsiste comme extra installé.

Modèles fournis dans le catalogue de base

Le catalogue intégré est un ensemble de modèles de codage Qwen3 répartis sur plusieurs paliers de mémoire. Tous les quatre sont vérifiés pour l'appel d'outils :

Le modèle à 8 milliards de paramètres s'exécute sur n'importe quel Mac pris en charge ; le modèle mélange d'experts à 480 milliards de paramètres nécessite une machine de 512 GB (un M3 Ultra) et n'est pas marqué comme recommandé pour cette raison. Un catalogue actualisé peut ajouter des versions plus récentes ou plus volumineuses sans mise à jour de l'application.

Les badges et la barrière d'adéquation à la RAM

Chaque ligne du volet (et chaque ligne de bromure-cli model catalog) porte deux badges :

• Un palier de taille — S pour les modèles nécessitant 16 GB ou moins, M jusqu'à 32 GB, L jusqu'à 64 GB, XL au-delà.
• Un verdict d'adéquation par rapport à la mémoire unifiée de votre Mac : Convient, Juste, ou Ne convient pas. « Convient » exige le minimum du modèle plus 16 GB de marge pour l'OS et tout le reste ; « Juste » signifie qu'il se charge avec peu de marge ; « Ne convient pas » signifie que le minimum du modèle dépasse votre mémoire. Les lignes « Ne convient pas » sont grisées et ne peuvent être ni sélectionnées ni téléchargées.

Par exemple, le modèle Qwen3 8B (minimum de 16 GB) affiche Juste sur un Mac de 16 GB et Convient sur 32 GB ou plus ; Qwen3-Coder 30B-A3B (minimum de 32 GB) affiche Convient à partir de 48 GB.

Utiliser un modèle en dehors du catalogue

Le catalogue est un menu sélectionné, pas une clôture. Tout dépôt Hugging Face déjà au format MLX peut être récupéré par son nom org/repo depuis la ligne de commande (voir Référence en ligne de commande) ; un tel modèle est traité comme non testé — il ne comporte aucune garantie d'appel d'outils ni aucune assurance d'adéquation à la RAM. Les dépôts au format GGUF sont rejetés d'emblée, car GGUF est la voie d'Ollama et de llama.cpp, pas de MLX :

That's a GGUF (Ollama/llama.cpp) model — Bromure serves MLX weights only.

Télécharger et stocker des modèles

Les poids sont récupérés directement depuis huggingface.co par un téléchargeur intégré en Swift pur — pas de Python, pas de mlx_lm.convert, aucune conversion d'aucune sorte. Le téléchargeur lit la liste de fichiers du dépôt depuis l'API Hugging Face, transmet en flux chaque fichier de poids vers un fichier temporaire .partial, puis le renomme atomiquement à sa place ; la documentation, les images et tout fichier GGUF présent dans le dépôt sont ignorés. Avant de commencer, une vérification préalable de l'espace disque échoue rapidement plutôt que de remplir votre disque :

Not enough disk space: 40 GB free, but about 270 GB is needed.

Où résident les modèles

Les poids téléchargés atterrissent dans une disposition plate, par dépôt, sous votre répertoire Application Support :

~/Library/Application Support/BromureAC/models/<org>--<name>/

Chaque répertoire contient le config.json du modèle, ses fragments .safetensors et son tokenizer. Les téléchargements sont un effet de bord global, partagé entre tous les espaces de travail — récupérer un modèle une fois le rend disponible pour chacun d'eux. Les modèles précédemment mis en cache par d'autres outils dans ~/.cache/huggingface/hub sont migrés une fois dans ce répertoire, par liens physiques, de sorte que rien n'est téléchargé deux fois.

États de téléchargement dans le volet

Le contrôle d'action de chaque ligne de modèle reflète son état :

Comme le téléchargeur est reprenable à la granularité du fichier, un téléchargement interrompu n'a jamais à recommencer de zéro, et un téléchargement partiel n'est jamais confondu avec une installation opérationnelle — un fichier sentinelle en cours le marque jusqu'à ce que le dernier octet arrive.

Astuce : Le premier modèle que vous téléchargez est automatiquement défini comme modèle actif de l'espace de travail, de sorte qu'un nouvel espace de travail passe de « aucun modèle local » à « prêt à servir » en un seul clic.

Activer les modèles locaux pour un espace de travail

Ouvrez l'espace de travail dans le navigateur d'espaces de travail, cliquez sur Modifier l'espace de travail, et sélectionnez le volet Modèles locaux (l'icône de processeur menthe). Le volet démarre sous la forme d'un simple interrupteur ; le sélecteur de mode et la liste de modèles n'apparaissent qu'une fois l'inférence locale activée.

1. Activez Activer les modèles locaux (« Exécuter un modèle de codage sur ce Mac plutôt que dans le cloud. »). Cela éloigne le routage de l'espace de travail du Cloud ; le désactiver à nouveau rétablit le Cloud.
2. Choisissez un Mode :
   • Local — toujours sur l'appareil conserve chaque requête sur ce Mac. Comme le note le volet, les réponses sont privées mais plus lentes, et limitées par le modèle que vous pouvez faire tenir en mémoire.
   • Hybride — cloud, repli sur le local envoie les requêtes au cloud comme d'habitude et se replie sur le modèle sur l'appareil uniquement lorsque le cloud est injoignable — vitesse et qualité du cloud, avec un filet de sécurité local.
3. Dans la liste de modèles — intitulée Modèles · N GB de mémoire unifiée, où N est la mémoire de votre Mac — Téléchargez un modèle, puis sélectionnez-le comme actif avec le bouton radio à sa gauche. Les lignes grisées nécessitent plus de mémoire que celle dont dispose votre Mac.
4. Cliquez sur Enregistrer.

Le mode de routage et la sélection du modèle actif persistent lorsque vous enregistrez ; les téléchargements, étant globaux, ont lieu immédiatement, que vous enregistriez ou non. Si les modèles que vous sélectionnez nécessitaient ensemble une mémoire proche ou supérieure à celle de votre Mac — le moteur les dessert en parallèle, si bien que leur mémoire s'additionne — le volet affiche un avertissement et vous demande d'en retirer un ou de choisir des modèles plus petits.

La liste complète des champs et des valeurs par défaut se trouve dans Réglages Modèles locaux.

Routage : Cloud, Local et Hybride

Le routage est le choix de premier niveau, propre à chaque espace de travail, du backend qui dessert le trafic LLM d'un agent. Il a trois valeurs :

Sélectionner Local ou Hybride engage automatiquement la voie d'interception MITM — vous n'actionnez jamais d'interrupteur séparé pour cela. Chaque tour de conversation traité est étiqueté dans la trace avec un marqueur de backend ayant répondu enregistrant quel backend a répondu : cloud ou local-<model>. Vous pouvez le lire dans l'Inspecteur de traces pour confirmer, tour par tour, où une session hybride est réellement allée.

Le routage est un réglage par défaut propre à chaque espace de travail défini dans le volet, mais il peut aussi être modifié sur une VM en cours d'exécution depuis la ligne de commande avec bromure-cli vm routing (voir Référence en ligne de commande).

Remarque : Le routage local redirige vers le moteur le trafic d'un agent destiné aux hôtes Anthropic et OpenAI (et à la sentinelle bromure.llm). Il ne détourne pas un agent qui est lui-même déjà épinglé à un véritable identifiant cloud — par exemple, un agent Claude sur abonnement partageant un espace de travail conserve son vrai trafic cloud. Pour forcer un agent spécifique en local indépendamment du routage de l'espace de travail, utilisez son propre mode d'authentification Modèle local, ci-dessous.

La politique de repli hybride

Hybride n'est pas un simple interrupteur mais un petit moteur de politique, réglé pour ne jamais briser une trajectoire de codage en changeant de modèle en cours de route. Chaque décision est prise à une frontière de session et devient ensuite persistante — une fois qu'une conversation est routée vers un backend, elle y reste pour le reste de cette session (la garde de cohérence).

Ce qui déclenche un repli vers le local

Pour une nouvelle session, la première règle qui correspond l'emporte, dans cet ordre : une session persistante déjà épinglée, un budget de jetons cloud épuisé, un cloud en mauvaise santé (la barrière de santé), une attribution par ratio de répartition, et sinon le cloud. Pendant une requête déjà en vol vers le cloud, deux choses forcent une reprise immédiate sur le modèle local, épinglant la session en local pour toute sa durée :

• Erreurs dures — une connexion refusée ou expirée, ou un HTTP 429, 529 ou 5xx du fournisseur.
• Un délai souple manqué — aucun premier jeton dans le budget TTFT (5 secondes par défaut).

En dessous se trouve une barrière de santé conservatrice : le cloud est marqué en mauvaise santé après au moins trois échecs dans les dix dernières requêtes environ, ou lorsque la moyenne mobile pondérée exponentiellement du TTFT dépasse 8 secondes, et il ne récupère qu'après trois sondes propres et rapides. Tant que le cloud est en mauvaise santé, les nouvelles sessions vont directement en local sans que chacune paie d'abord la pénalité du délai souple. Les backends ne sont jamais mis en course l'un contre l'autre — il n'y a ni couverture spéculative ni double dépense ; le repli ne se déclenche qu'après un vrai déclencheur.

Les boutons réglables

Trois boutons sont exposés, et uniquement via la ligne de commande sur une VM en cours d'exécution (voir Référence en ligne de commande). Ils persistent par espace de travail mais sont ignorés sauf si le routage est Hybride :

Les rouages internes de la barrière de santé (le seuil EWMA de 8 secondes, la fenêtre d'échecs et le nombre de sondes de récupération) sont fixes et non réglables par l'utilisateur.

Les modèles locaux comme backend d'agent

Le routage est un axe à l'échelle de l'espace de travail, mais vous pouvez aussi pointer un seul agent vers le moteur local, en laissant le reste de l'espace de travail sur le cloud. Dans l'onglet Agents de l'espace de travail, chaque agent — Claude Code, Codex ou Grok — dispose d'un sélecteur de mode d'authentification dont les options incluent Modèle local. Choisissez-le, sélectionnez un modèle installé, et cet agent s'exécute entièrement contre le moteur sur l'appareil avec de fausses clés cloud que le moteur ignore ; le MITM applique les mêmes protections qu'au trafic cloud.

Cela rend possibles les espaces de travail mixtes — par exemple, Claude Code sur un abonnement aux côtés de Codex sur un modèle local. Le routage Local à l'échelle du profil ne détourne jamais le vrai trafic d'un agent cloud, et le mode Local par agent ne déborde jamais sur les autres. Lorsque vous activez ou désactivez l'inférence locale dans le volet Modèles locaux, l'application maintient automatiquement le mode d'authentification de chaque agent en phase.

Les modèles locaux dans Fusion

Un modèle local est aussi un participant valide dans Fusion, la fonction de synthèse multi-modèles, et il peut y jouer l'un de deux rôles :

• Comme jambe. Cochez Modèle local sous Modèles à fusionner et sélectionnez un modèle installé ; sa réponse provisoire rejoint le panneau aux côtés de Claude, Codex et Grok. Comme il s'exécute sur votre Mac, c'est une jambe supplémentaire capable à coût marginal nul.
• Comme juge. Choisissez Local comme fournisseur de juge Fusion pour exécuter l'étape d'analyse et de synthèse entièrement sur l'appareil, en gardant toute l'étape de jugement hors du cloud.

Les deux rôles nécessitent au moins un modèle local téléchargé ; d'ici là, les lignes correspondantes du volet Fusion sont grisées avec une indication d'en télécharger un ici d'abord. Consultez Fusion pour le flux de travail complet du panneau.

Réparation des appels d'outils

Le mode de défaillance dominant des modèles quantifiés en usage agentique est l'émission d'un appel d'outil sous forme de texte brut au lieu d'un appel structuré que l'agent peut exécuter. Un proxy de réparation se place devant le moteur — l'invité et la voie locale du MITM pointent tous deux vers lui, pas vers le moteur nu — et sauve ces cas de manière transparente.

Pour chaque réponse, il met la sortie en mémoire tampon et réanalyse les nombreuses formes ad hoc dans lesquelles un modèle pourrait laisser fuir un appel, notamment :

<function name="write_file" arguments='{…}'>
<tool_call>{…}</tool_call>
[{"name": "…", "parameters": {…}}]

ainsi que le format natif <function=Name><parameter=k>v</parameter></function> de Qwen3-Coder et le format de canaux de Gemma. Il synthétise de véritables blocs d'utilisation d'outils à partir de ce qu'il trouve et réémet le message sous forme de SSE conforme au protocole, dans la forme de fil native de l'agent. Il détecte aussi un préambule bloqué — où le modèle narre une action (« Maintenant je vais créer le fichier : ») puis termine son tour sans jamais appeler l'outil — et relance jusqu'à deux fois pour récupérer l'appel manquant. Un rappel du format d'outil est ajouté au prompt système chaque fois que des outils sont déclarés.

La réparation est toujours active pour l'inférence locale et ne nécessite aucune configuration. Les problèmes du moteur sont convertis en corps d'erreur natifs au fil, de sorte que l'agent affiche la vraie raison plutôt qu'une défaillance générique, par exemple :

Local inference engine unreachable (starting up, reloading a model, or stopped) — retry in a moment.

Surveiller le moteur

Deux fenêtres sous le menu Window vous permettent d'observer l'inférence sur l'appareil sans ouvrir Console.app.

Métriques d'inférence

Window → Inference Metrics… ouvre un panneau de télémétrie en direct (titre de fenêtre Inference Metrics), coiffé du libellé Inférence locale et de l'adresse de bouclage du moteur. Il analyse les métriques Prometheus du moteur en cartes — Decode tok/s, Prefill tok/s, Running, Waiting, In flight, Avg latency, Cache hit, Metal mem, Gen tokens et Prompt tokens — plus une liste Loaded models et une section dépliable All metrics avec le tableau brut.

La fenêtre interroge toutes les 5 secondes, et seulement tant qu'elle est ouverte. Les taux de décodage et de préremplissage sont par conception des ratios cumulés sur toute la durée de vie, si bien qu'ils se lisent comme des moyennes stables plutôt que comme des écarts par seconde saccadés. Lorsque le moteur est hors service, le panneau affiche engine not reachable, et pendant une génération longue il peut afficher brièvement engine busy (timed out).

Journal du moteur d'inférence

Window → Inference Engine Log… ouvre un suivi en direct (titre de fenêtre Inference Engine Log) de la sortie du processus enfant du moteur ainsi que des événements de cycle de vie du parent — chargements de modèles, « serving », statistiques par requête, et tout OOM, plantage, redémarrage ou erreur de chargement. Les lignes sont codées par couleur (rouge pour les échecs, vert pour les événements sains, orange pour les avertissements, bleu pour le travail en cours). La barre d'outils propose un champ Filter…, une case Auto-scroll, Copy et Clear ; lorsque rien ne s'est encore produit, elle affiche No inference-engine activity yet. Le tampon est un anneau en mémoire plafonné à 5 000 lignes, et chaque ligne est aussi reflétée vers la sortie d'erreur standard de l'application, de sorte que lancer bromure-cli depuis un terminal vous en donne une copie durable.

Référence en ligne de commande

Les commandes de modèle et de routage dialoguent avec l'API de contrôle de l'application en cours d'exécution, donc l'application (ou son agent) doit être en cours d'exécution. Les commandes qui agissent sur une VM spécifique prennent un argument <vm> en fin, qui est un identifiant de VM ou un nom d'espace de travail. Les valeurs par défaut persistantes propres à chaque espace de travail se modifient dans les volets de l'interface décrits ci-dessus ; ces commandes agissent sur une session en direct. Consultez Automatisation et CLI pour l'ensemble de commandes environnant.

Gestion des modèles :

bromure-cli model catalog [--all] [--offline]
bromure-cli model pull <catalog-id | org/repo>
bromure-cli model ls
bromure-cli model use <catalog-id | org/repo> <vm>
bromure-cli model rm <catalog-id | org/repo>

Routage et politique hybride pour une VM en cours d'exécution :

bromure-cli vm routing cloud|local|hybrid <vm>
bromure-cli vm hybrid budget <tokens> <vm>
bromure-cli vm hybrid ttft <seconds> <vm>
bromure-cli vm hybrid split <0-100> <vm>
bromure-cli vm fusion enable|disable <vm>

vm routing définit le mode de backend ; les trois boutons vm hybrid règlent la politique de repli (et ne mordent que lorsque le routage est Hybride). vm fusion engage le panneau multi-modèles orthogonal et est documenté dans Fusion.

Commandes de diagnostic internes

Ces sous-commandes cachées existent pour le développement et le dépannage et ne font pas partie du flux de travail quotidien. Le processus enfant du moteur lui-même est lancé par l'application comme bromure-cli model _mlx-engine --config <path>.

Commande	Objectif
bromure-cli model _mlx-serve <repo>	Démarre le serveur MLX en cours de processus pour un modèle et bloque, en affichant son port et sa clé pour un test avec curl.
bromure-cli model _mlx-selftest <repo>	Charge un modèle, génère une fois, et affiche le TTFT et le débit de décodage en tok/s.
bromure-cli model _repair-serve --engine-port <port>	Exécute le proxy de réparation d'appels d'outils de manière autonome contre un moteur en cours d'exécution.
bromure-cli model _tc-test <path>	Exécute le sauvetage d'appels d'outils sur un fichier texte enregistré pour vérifier l'extraction d'appels ayant fuité.
bromure-cli model _spec-bench <main-repo> --draft <draft-repo>	Compare le décodage spéculatif désactivé et activé pour une paire de modèles.

Attentes de performance

L'inférence sur l'appareil échange la vitesse contre la confidentialité et le coût, et l'échange est réel — ajustez vos attentes en conséquence :

• Le débit évolue avec le modèle et la puce. Un petit modèle tel que Qwen3 8B est vif sur n'importe quel Mac pris en charge ; les grandes versions à mélange d'experts sont plus lentes et nécessitent bien plus de mémoire. La fenêtre Métriques d'inférence montre les taux réels de décodage et de préremplissage sur votre matériel — le chiffre honnête sur lequel planifier.
• La première requête paie un chargement de modèle. Un moteur froid affiche Démarrage du moteur local… pendant qu'il chauffe ; les gros poids prennent un temps réel à charger en mémoire avant l'apparition du premier jeton. Les requêtes suivantes sautent cette étape.
• Les boucles d'agent multi-tours deviennent moins coûteuses après le premier tour. Le moteur conserve un cache KV de préfixe par conversation (jusqu'à quatre emplacements de session par modèle), de sorte que chaque tour d'agent ne préremplit que les nouveaux jetons plutôt que toute la transcription — et une chaîne latérale n'évince pas le cache de la conversation principale.
• La génération est sérialisée. Le moteur exécute une génération à la fois, si bien que plusieurs sessions occupées partagent le GPU plutôt que de s'exécuter réellement en parallèle.
• Les modèles de raisonnement pensent en silence. Pour les modèles qui émettent un bloc <think>, le bloc est toujours retiré avant que la réponse n'atteigne l'agent — vous obtenez la qualité sans l'encombrement de la transcription.

Astuce : Si un modèle local semble lent ou se bloque, ouvrez d'abord la fenêtre Journal du moteur d'inférence : les chargements de modèles, les évictions, les redémarrages OOM et les erreurs d'architecture non prise en charge y apparaissent tous en texte clair, ce qui est plus rapide que de deviner du côté de l'agent.