Jeudi, 16 h 40, un projet de contrat est ouvert dans une fenêtre. Vous aimeriez qu'une IA resserre la formulation, mais le document ne doit pas quitter votre portable, et vous ne savez pas lequel des centaines de modèles ouverts de Hugging Face tiendrait seulement dans 16 Go de mémoire. Et vous n'avez aucune envie de passer la soirée dans un terminal pour le découvrir.
Un seul groupe dans la barre latérale pour tout ce que vous faites avec des modèles ouverts
Local Model est la partie d'osFoundry consacrée aux modèles à poids ouverts qui tournent sur du matériel que vous contrôlez. Elle apparaît dans la barre latérale de l'application de bureau comme une catégorie à part, divisée en trois sous-titres : Run (Explore, Providers, Servers, Playground, Deployments, Cloud GPU, GPU Endpoints), Build (My Models, Datasets, Training, Quantize, Notebooks) et Measure (Eval, Benchmarks, Safety). Si vous avez déjà utilisé Ollama ou LM Studio, la partie Run vous semblera familière : trouver un modèle, le télécharger, discuter avec. La différence, c'est que le même groupe permet aussi de réduire un modèle, de le fine-tuner sur vos propres exemples et de le tester avec vos propres questions, si bien que toute la vie d'un modèle reste dans une seule application. L'inférence en local s'appuie sur un serveur llama.cpp intégré, donc rien à installer à côté. Ce guide couvre les neuf écrans que la plupart des gens utilisent : Explore, Servers, Playground, My Models, Datasets, Training, Quantize, Eval et Benchmarks.
Premier aperçu d'Explore
C'est par Explore que la plupart des gens commencent, et sa disposition montre la logique de toute la catégorie : votre machine d'abord, les modèles ensuite.
- Le panneau Filters à gauche regroupe les tâches Hugging Face (Text Generation, Summarization, Translation, Embeddings, plus les groupes Multimodal, Vision et Audio) et propose un champ de recherche.
- Le bandeau du haut lit votre machine avant d'afficher quoi que ce soit. Dans l'exemple ci-dessus, il indique 16 Go de mémoire unifiée, environ 12 Go utilisables pour un modèle, environ 9 Go libres à cet instant, et précise que les estimations supposent Q4_K_M et un contexte de 4K.
- Chaque carte de modèle porte un badge de compatibilité : vert Fits, orange Tight, rouge Too big, chacun avec une estimation de la mémoire. Rien n'est masqué ; les modèles qui tiennent sont simplement listés en premier.
- Les boutons Providers et My Registry en haut à droite mènent aux fournisseurs d'API cloud et aux modèles que vous avez déjà.
- Un clic sur une carte ouvre sa fiche, où Install Locally télécharge une version du modèle, généralement un GGUF quantifié correspondant au badge.
Trois personnes, trois usages
Une développeuse indépendante avec un seul portable
Maya développe des projets perso sur un MacBook de 16 Go. Elle veut un modèle local pour rédiger ses messages de commit et de courtes notes, surtout pour pouvoir travailler hors ligne dans le train.
Elle ouvre Explore, filtre sur Text Generation et ignore tout ce qui a un badge rouge. Deux candidats sont en vert, elle installe donc les deux avec Install Locally. Puis elle ouvre Playground, tape un prompt et ajoute les deux modèles comme panneaux. Playground envoie le même prompt à deux à quatre modèles en même temps et affiche les réponses côte à côte, avec le temps jusqu'au premier token et le nombre de mots sous chaque panneau.
Plus tard, elle trouve un modèle qui lui plaît mais qui n'existe qu'en fichier F16 pleine précision. Environ 15 Go, trop gros pour son portable. Dans Quantize, elle le sélectionne sous "The model to shrink", choisit Q4_K_M, le niveau que l'application recommande à la plupart des gens, et lance l'opération. Le llama-quantize intégré réécrit le fichier sur sa machine ; rien n'est envoyé.
Dans l'exemple ci-dessus, le résultat fait 4.58 GiB, soit 3.3 fois moins que l'original. Avant de s'y fier, elle clique sur Measure quality, qui compare le nouveau fichier à l'original et remplit les colonnes "same top token" et KLD moyenne du tableau Compare, puis sur Measure speed pour les tokens par seconde. Un clic sur Try it in Playground le remet à côté des deux autres. Elle termine la soirée avec un modèle qui tient, des chiffres qui montrent ce que la réduction a coûté, et aucun historique de terminal.
Une petite équipe avec un poste fixe puissant
Une agence de quatre personnes a au bureau un poste fixe avec beaucoup de mémoire et plusieurs portables légers. Les gros modèles ne tiennent que sur le poste fixe, mais tout le monde veut s'en servir.
Sur le poste fixe, quelqu'un ouvre Servers, sélectionne This Mac et va dans l'onglet Access. Il coche "Allow access from other devices on the local network (LAN)" et active Remote Access. Le panneau liste alors tous les modèles locaux que la machine va servir. Sous Device keys, il clique sur New key, lui donne le nom du portable d'un collègue et clique sur Create key ; chaque clé peut être révoquée individuellement, et une clé limitée à l'inférence peut exécuter des modèles sans accéder aux sessions d'agents.
Sur chaque portable, le collègue ouvre Servers, clique sur Add Server, saisit l'adresse du poste fixe, colle la clé et utilise Test Connection. Une fois connecté, les modèles du poste fixe apparaissent dans le sélecteur de modèles du portable comme n'importe quel autre. L'application signale elle-même que ce trafic passe en HTTP non chiffré : c'est donc prévu pour des réseaux de confiance, comme le LAN du bureau.
Quelqu'un ouvre ensuite Benchmarks, clique sur New Benchmark, choisit le modèle et garde la suite Quick. Le test enregistre les tokens par seconde, le temps jusqu'au premier token et la latence, ce qui permet à l'équipe de savoir si le modèle partagé est assez rapide pour s'en servir pendant les appels ou seulement pour des traitements de nuit. Si c'est lent, Servers propose aussi un onglet Config où l'on peut définir un petit modèle brouillon sous Speculative Decoding, puis cliquer sur Restart now et relancer le benchmark pour comparer.
L'équipe se retrouve avec une machine qui fait le gros du travail, une clé par portable qu'on peut retirer sans déranger les autres, et une réponse mesurée à la question « est-ce assez rapide ? ».
Un responsable des opérations qui ne code pas
Ken gère le service client d'une petite boutique en ligne. Il a deux questions : quel modèle lit correctement les totaux des factures, et un modèle peut-il apprendre à répondre avec le ton de la boutique ?
Pour la première, il va dans Eval et clique sur Custom Benchmark. Il le nomme, colle dix factures avec le total attendu pour chacune, garde Exact Match et clique sur Create Benchmark. Ensuite, New Eval Run : il coche deux modèles de son ordinateur, coche son benchmark et clique sur Start Evaluation. Les questions sont envoyées à chaque modèle sur sa propre machine.
Dans cet exemple, un modèle obtient 90 et l'autre 70, et la colonne Diff affiche l'écart de 20 points. C'est un résultat sur ses propres documents, pas le classement de quelqu'un d'autre.
Pour la question du ton, il rassemble quelques centaines d'anciens messages clients avec les réponses que l'équipe a réellement envoyées, une paire par ligne. Dans Datasets, il peut importer ce fichier, ou chercher des données publiques via l'onglet Hub, puis utiliser "Use for Training" pour le transmettre. Dans Training, il clique sur New Job et passe les quatre étapes : Base Model, Dataset, Config et Review. Sous Training Target, il choisit Local (This Device), que l'écran décrit comme exécuté sur le GPU de l'appareil et gratuit, avec LoRA comme méthode.
Après Start Training, la tâche affiche sa loss pendant l'exécution. Une fois terminée, l'adaptateur entraîné apparaît dans My Models à côté du modèle de base dont il est issu, et "Chat with your model" sur l'exécution terminée le prépare pour le runtime local afin qu'il puisse lui poser une question dans Playground. Il repart avec un petit modèle privé et un benchmark qu'il peut relancer chaque fois qu'il envisage un nouveau modèle.
Où Local Model passe le relais
La catégorie ne vit pas en vase clos. Les modèles que vous installez ou connectez apparaissent dans la même liste de modèles que celle du chat : un modèle local peut donc répondre à une conversation normale ou être comparé dans Playground à un modèle cloud que vous avez ajouté sous Providers. Depuis Explore, "Use in Notebook" ouvre un notebook JupyterLab configuré pour ce modèle, en local ou sur une instance hébergée. Quand un modèle a besoin d'un vrai GPU plutôt que de votre portable, Deployments et Cloud GPU prennent le relais et le placent sur un endpoint managé. Avant qu'un modèle ne soit exposé aux clients, Safety exécute des suites de tests red team contre un modèle déployé. La page sur l'inférence locale détaille le moteur embarqué, et la page sur le fine-tuning LoRA couvre la partie entraînement.
Les premières questions qu'on nous pose
Faut-il un GPU ou un PC gamer ?
Non. Un portable récent suffit pour les petits et moyens modèles ; les badges d'Explore vous disent ce que votre machine peut accueillir avant de télécharger. Un poste fixe plus puissant ou un serveur distant élargit simplement la liste.
Est-ce que quelque chose part dans le cloud ?
L'inférence locale, Quantize et l'entraînement local tournent sur votre machine. L'entraînement sur Cloud GPU, les endpoints Cloud GPU et Providers sont les parties qui font appel à des services externes, et les écrans l'indiquent, par exemple "Managed cloud GPU · needs credits" dans la boîte de dialogue d'entraînement.
Quelle différence entre Eval et Benchmarks ?
Eval note la qualité des réponses à partir de questions que vous définissez. Benchmarks mesure la vitesse et la mémoire : tokens par seconde, temps jusqu'au premier token et latence.
Où trouver l'application ?
Local Model fonctionne dans l'application de bureau, disponible sur osfoundry.io/fr/download.
Top comments (0)