Ember est entraine, teste et quantize. La derniere lecon consiste a le laisser voler dans le monde reel : le servir comme une app avec laquelle tes outils peuvent parler, le garder en bonne sante dans le temps, et — si tu le choisis — le partager avec la communaute. C'est ici qu'un projet d'entrainement devient un systeme qui fonctionne.
Option 1 : Ollama — Ember comme service local
Ollama transforme un fichier GGUF en modele servi localement avec une API compatible OpenAI. Cree un Modelfile a cote de ton GGUF :
FROM ./ember-q4_k_m.gguf
SYSTEM """You are Ember, the support assistant for Nordlys Shop. Friendly and precise. Structure: short answer, explanation, next step. Never invent order details."""
PARAMETER temperature 0.4
Remarque que le prompt system est exactement celui de tes donnees d'entrainement — c'est pour ca que la lecon 4 insistait sur des prompts system identiques a l'octet pres. Ensuite :
ollama create ember -v ./Modelfile
ollama run ember
Ollama expose aussi http://localhost:11434/v1/chat/completions — un endpoint compatible OpenAI. N'importe quel outil, script ou app qui parle l'API OpenAI peut maintenant utiliser Ember en changeant une seule URL. Ton modele, ta machine, zero cout par token.
Option 2 : LM Studio — Ember avec un cockpit
Depose le GGUF dans le dossier de modeles de LM Studio et tu obtiens une interface de chat conviviale, des controles de sampling et son propre serveur d'API local — le choix confortable si tu preferes les boutons aux terminaux, et la facon la plus simple de faire une demo d'Ember a un collegue non technique.
Astuce Pro
Les reglages de service comptent autant que l'entrainement. Garde une temperature basse (0,3–0,5) pour un assistant de support — tu as entraine la discipline dans les poids ; ne laisse pas un sampler trop chaud la faire ressortir. Et fixe une limite de contexte raisonnable : Ember repond a des tickets, il n'a pas besoin de 128k tokens d'historique.Brancher Ember dans un vrai workflow
Avec un endpoint compatible OpenAI, l'integration tient en un appel HTTP :
import requests
def ask_ember(question: str) -> str:
r = requests.post("http://localhost:11434/v1/chat/completions", json={
"model": "ember",
"messages": [{"role": "user", "content": question}],
})
return r.json()["choices"][0]["message"]["content"]
A partir de la, les patterns que tu connais deja du developpement web prennent le relais : un formulaire de helpdesk qui redige des brouillons de reponses avec Ember, un bot Slack, un job batch qui pre-classe les tickets de la nuit. Et souviens-toi de la promesse de la lecon 2 — c'est ici que le RAG entre en scene : recupere les vraies donnees de commande du client dans ta base de donnees, colle-les dans le prompt, et laisse ton modele fine-tune, avec sa voix et sa discipline, les presenter. Comportement fine-tune + faits recuperes, c'est le combo de niveau production.
Partager sur Hugging Face (optionnel, classe)
Si ton dataset ne contient rien de prive, republier ton modele vers la communaute est ce qui fait vivre l'ecosysteme ouvert dont tu viens de profiter :
pip install huggingface_hub
hf auth login
hf upload your-username/ember-4b-support ./ember-gguf
Publie le GGUF (le plus utile aux autres), ou juste les adaptateurs LoRA (minuscules — quelques centaines de Mo), ou les deux. Ecris une model card honnete : modele de base, taille et nature du dataset, ce qu'il fait bien, ce qu'il ne fait pas. Les meilleures model cards se lisent comme ta fiche d'objectif de la lecon 2 — parce qu'elles n'en sont qu'une.
Note honnete
Avant de publier, relis la checklist de confidentialite de la lecon 4 avec un oeil neuf. Des poids fine-tunes peuvent faire fuiter des donnees d'entrainement — les chercheurs extraient couramment des exemples mot pour mot de modeles publies. Si tes donnees viennent de vrais clients, publie la recette (base + hyperparametres + exemples synthetiques), pas les poids. Dans le doute, garde le dragon a la maison.Garder le dragon en bonne sante
Un modele deploye n'est pas termine — il se desynchronise de la realite a mesure que tes produits, tes politiques et tes clients changent. La boucle de maintenance, c'est simplement ce cours en miniature :
- Collecte les vraies questions auxquelles Ember a mal repondu (tes utilisateurs te le diront avec plaisir)
- Ajoute des versions corrigees au dataset — 20 a 50 nouveaux exemples a la fois
- Re-entraine avec le meme pipeline (c'est une seule commande maintenant), incremente la version : ember-v4, v5…
- Refais tourner le meme jeu de test — ta suite de regression — avant de remplacer le modele servi
- Tous les 6 a 12 mois, envisage de rebaser sur le plus recent petit modele — les modeles de base s'ameliorent vite, et ton dataset transporte tout ton travail avec lui
Concept
Remarque quel est ton vrai actif : le dataset, pas les poids. Les poids sont des artefacts compiles ; le dataset, c'est le code source. Nouveau modele de base ? Recompile. Meilleure technique ? Recompile. Garde le dataset sous controle de version comme le joyau de la couronne qu'il est.Essaie
Livre la boucle complete de bout en bout : sers ton Ember quantize avec Ollama, appelle-le depuis un script Python de 10 lignes, et reponds a une vraie question de ton cas d'usage reel. Puis prends un instant — un modele que tu as entraine, sur ta machine, vient de repondre avec ta voix via une API. C'est toute la promesse de ce cours, tenue.Ou voler ensuite
- Monte en taille de base : relance ton pipeline sur un modele 8B–14B (le calcul de la lecon 7 dit que ta machine le peut)
- Ajoute du vrai RAG : base de donnees vectorielle + retrieval devant l'endpoint d'Ember
- Essaie le function calling : fine-tune des sorties structurees d'appels d'outils — meme pipeline, nouveau dataset
- Automatise la boucle : re-entrainement + eval chaque nuit, pour que le dragon se nourrisse tout seul