Ember ist trainiert, getestet und quantisiert. Die letzte Lektion handelt davon, ihn in der echten Welt fliegen zu lassen: ihn als App servieren, mit der deine Tools reden koennen, ihn ueber die Zeit gesund halten und — wenn du willst — ihn mit der Community teilen. Hier wird aus einem Trainingsprojekt ein funktionierendes System.
Option 1: Ollama — Ember als lokaler Service
Ollama verwandelt eine GGUF-Datei in ein lokal serviertes Modell mit OpenAI-kompatibler API. Erstelle ein Modelfile neben deinem 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
Beachte: Der System-Prompt ist exakt der aus deinen Trainingsdaten — deshalb hat Lektion 4 auf Byte-identischen System-Prompts bestanden. Dann:
ollama create ember -v ./Modelfile
ollama run ember
Ollama exponiert ausserdem http://localhost:11434/v1/chat/completions — einen OpenAI-kompatiblen Endpoint. Jedes Tool, Skript oder jede App, die die OpenAI-API spricht, kann Ember jetzt nutzen, indem sie eine URL aendert. Dein Modell, deine Maschine, null Kosten pro Token.
Option 2: LM Studio — Ember mit Cockpit
Wirf das GGUF in LM Studios Modellordner und du bekommst eine freundliche Chat-UI, Sampler-Regler und einen eigenen lokalen API-Server — die bequeme Wahl, wenn du Buttons Terminals vorziehst, und der einfachste Weg, Ember einem nicht-technischen Kollegen zu demonstrieren.
Profi-Tipp
Serving-Einstellungen zaehlen genauso viel wie Training. Halte die Temperature niedrig (0,3–0,5) fuer einen Support-Assistenten — du hast Disziplin in die Gewichte trainiert; lass sie dir nicht von einem heissen Sampler wieder herausschuetteln. Und setz ein vernuenftiges Kontext-Limit: Ember beantwortet Tickets, es braucht keine 128k Tokens Historie.Ember in einen echten Workflow einbinden
Mit einem OpenAI-kompatiblen Endpoint ist die Integration ein einziger HTTP-Call:
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"]
Ab hier uebernehmen die Muster, die du schon aus der Webentwicklung kennst: ein Helpdesk-Formular, das mit Ember Antwortentwuerfe schreibt, ein Slack-Bot, ein Batch-Job, der ueber Nacht Tickets vorklassifiziert. Und denk an das Versprechen aus Lektion 2 — hier kommt RAG dazu: Hole die echten Bestelldaten des Kunden aus deiner Datenbank, fuege sie in den Prompt ein und lass dein fine-getuntes Stimme-und-Disziplin-Modell sie praesentieren. Fine-getuntes Verhalten + abgerufene Fakten ist die Production-Grade-Kombination.
Auf Hugging Face teilen (optional, mit Stil)
Wenn dein Datensatz nichts Privates enthaelt, ist das Zurueckgeben deines Modells an die Community der Grund, warum das offene Oekosystem, von dem du gerade profitiert hast, weiter existiert:
pip install huggingface_hub
hf auth login
hf upload your-username/ember-4b-support ./ember-gguf
Veroeffentliche das GGUF (am nuetzlichsten fuer andere), oder nur die LoRA-Adapter (winzig — ein paar hundert MB), oder beides. Schreib eine ehrliche Model Card: Basismodell, Groesse und Art des Datensatzes, was es gut kann, was es nicht kann. Die besten Model Cards lesen sich wie deine Ziel-Karte aus Lektion 2 — weil sie eine sind.
Ehrlicher Hinweis
Lies vor dem Veroeffentlichen die Privacy-Checkliste aus Lektion 4 mit frischen Augen. Fine-getunte Gewichte koennen Trainingsdaten leaken — Forscher extrahieren routinemaessig woertliche Beispiele aus veroeffentlichten Modellen. Wenn deine Daten von echten Kunden stammen, veroeffentliche das Rezept (Basis + Hyperparameter + synthetische Beispiele), nicht die Gewichte. Im Zweifel: Behalte den Drachen zu Hause.Den Drachen gesund halten
Ein deploytes Modell ist nicht fertig — es driftet aus dem Takt mit der Realitaet, waehrend sich deine Produkte, Richtlinien und Kunden aendern. Die Wartungsschleife ist einfach dieser Kurs in Miniatur:
- Sammle die echten Fragen, die Ember schlecht beantwortet hat (deine Nutzer sagen es dir gern)
- Ergaenze korrigierte Versionen im Datensatz — 20–50 neue Beispiele auf einmal
- Retrainiere dieselbe Pipeline (es ist jetzt ein Befehl), zieh die Version hoch: ember-v4, v5…
- Fahre dasselbe Test-Set erneut — deine Regressions-Suite — bevor du das servierte Modell austauschst
- Erwaege alle 6–12 Monate ein Rebase auf das neueste kleine Modell — Basismodelle verbessern sich schnell, und dein Datensatz traegt deine ganze Arbeit weiter
Konzept
Sieh genau hin, was dein echtes Asset ist: der Datensatz, nicht die Gewichte. Gewichte sind kompilierte Artefakte; der Datensatz ist Quellcode. Neues Basismodell? Neu kompilieren. Bessere Technik? Neu kompilieren. Huete den Datensatz in der Versionskontrolle wie die Kronjuwelen, die er ist.Probier es aus
Liefere die volle Schleife Ende-zu-Ende: Serviere dein quantisiertes Ember mit Ollama, ruf es aus einem 10-Zeilen-Python-Skript auf und beantworte eine echte Frage aus deinem tatsaechlichen Use Case. Dann halt kurz inne — ein Modell, das du trainiert hast, auf deiner Maschine, hat gerade in deiner Stimme ueber eine API geantwortet. Das ist das ganze Versprechen dieses Kurses, eingeloest.Wohin als Naechstes fliegen
- Die Basis skalieren: Fahre deine Pipeline auf einem 8B–14B-Modell erneut (die Mathematik aus Lektion 7 sagt, deine Maschine kann das)
- RAG richtig ergaenzen: Vektordatenbank + Retrieval vor Embers Endpoint
- Function Calling probieren: strukturierte Tool-Call-Ausgaben fine-tunen — dieselbe Pipeline, neuer Datensatz
- Die Schleife automatisieren: naechtliches Retraining + Eval, damit der Drache sich selbst fuettert