# Elibereaza-ti dragonul: deploy, servire si partajare
Ember e antrenat, testat si cuantizat. Lectia finala este despre a-l lasa sa zboare in lumea reala: servirea lui ca aplicatie cu care uneltele tale pot vorbi, mentinerea lui sanatos in timp si — daca alegi — partajarea lui cu comunitatea. Aici un proiect de antrenare devine un sistem functional.
## Optiunea 1: Ollama — Ember ca serviciu local
Ollama transforma un fisier GGUF intr-un model servit local cu un API compatibil OpenAI. Creeaza un `Modelfile` langa GGUF-ul tau:
```
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
```
Observa ca system prompt-ul este **exact cel din datele tale de antrenare** — de asta a insistat lectia 4 pe system prompt-uri identice byte cu byte. Apoi:
```bash
ollama create ember -v ./Modelfile
ollama run ember
```
Ollama expune si `http://localhost:11434/v1/chat/completions` — un endpoint compatibil OpenAI. Orice unealta, script sau aplicatie care vorbeste API-ul OpenAI poate acum folosi Ember schimband un singur URL. Modelul tau, masina ta, cost zero per token.
## Optiunea 2: LM Studio — Ember cu carlinga
Pune GGUF-ul in folderul de modele al LM Studio si primesti o interfata de chat prietenoasa, controale de sampler si propriul server API local — alegerea confortabila daca preferi butoane in loc de terminale, si cel mai usor mod de a-i face demo cu Ember unui coleg non-tehnic.
Pro Tip
Setarile de servire conteaza la fel de mult ca antrenarea. Pastreaza temperatura joasa (0.3–0.5) pentru un asistent de suport — ai antrenat disciplina in ponderi; nu lasa un sampler fierbinte sa o scuture inapoi afara. Si seteaza o limita de context rezonabila: Ember raspunde la tichete, nu are nevoie de 128k tokeni de istoric.
## Conectarea lui Ember intr-un flux de lucru real
Cu un endpoint compatibil OpenAI, integrarea e un singur apel HTTP:
```python
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"]
```
De aici, tiparele pe care le stii deja din dezvoltarea web preiau controlul: un formular de helpdesk care schiteaza raspunsuri cu Ember, un bot de Slack, un job batch care pre-clasifica tichetele peste noapte. Si aminteste-ti promisiunea din lectia 2 — **aici intra RAG in joc**: recuperezi datele reale ale comenzii clientului din baza ta de date, le lipesti in prompt si lasi modelul tau fine-tuned pe voce-si-disciplina sa le prezinte. Comportament fine-tuned + fapte recuperate este combinatia de nivel productie.
## Publicarea pe Hugging Face (optional, eleganta)
Daca dataset-ul tau nu contine nimic privat, publicarea modelului inapoi catre comunitate este felul in care ecosistemul deschis de care tocmai ai beneficiat continua sa existe:
```bash
pip install huggingface_hub
hf auth login
hf upload your-username/ember-4b-support ./ember-gguf
```
Publica GGUF-ul (cel mai util pentru altii), sau doar adapterele LoRA (minuscule — cateva sute de MB), sau ambele. Scrie un model card sincer: modelul de baza, marimea si natura dataset-ului, la ce e bun, la ce *nu* e. Cele mai bune model card-uri se citesc ca al tau card de obiectiv din lectia 2 — pentru ca asta si sunt.
Nota sincera
Inainte sa publici, reciteste checklist-ul de confidentialitate din lectia 4 cu ochi proaspeti. Ponderile fine-tuned pot scurge date de antrenare — cercetatorii extrag in mod curent exemple cuvant cu cuvant din modele publicate. Daca datele tale au venit de la clienti reali, publica reteta (baza + hiperparametri + exemple sintetice), nu ponderile. Cand ai dubii, tine dragonul acasa.
## Mentinerea dragonului sanatos
Un model in productie nu e gata — se desincronizeaza de realitate pe masura ce produsele, politicile si clientii tai se schimba. Bucla de mentenanta e chiar acest curs in miniatura:
1. **Colecteaza** intrebarile reale la care Ember a raspuns prost (utilizatorii tai iti vor spune cu placere)
2. **Adauga** versiunile corectate in dataset — cate 20–50 de exemple noi odata
3. **Reantreneaza** acelasi pipeline (acum e o singura comanda), incrementeaza versiunea: ember-v4, v5…
4. **Ruleaza din nou acelasi set de test** — suita ta de regresie — inainte sa inlocuiesti modelul servit
5. La fiecare 6–12 luni, ia in calcul mutarea pe cel mai nou model mic — modelele de baza se imbunatatesc rapid, iar dataset-ul tau iti cara toata munca mai departe
Concept
Observa care e adevaratul tau activ: dataset-ul, nu ponderile. Ponderile sunt artefacte compilate; dataset-ul e cod sursa. Model de baza nou? Recompilezi. Tehnica mai buna? Recompilezi. Pazeste dataset-ul in version control ca pe bijuteriile coroanei care este.
Incearca
Livreaza bucla completa cap-coada: serveste Ember-ul tau cuantizat cu Ollama, apeleaza-l dintr-un script Python de 10 linii si raspunde la o intrebare reala din cazul tau de utilizare. Apoi ia-ti un moment — un model pe care tu l-ai antrenat, pe masina ta, tocmai a raspuns cu vocea ta printr-un API. Asta e intreaga promisiune a acestui curs, livrata.
## Unde sa zbori mai departe
- **Scaleaza baza**: ruleaza din nou pipeline-ul pe un model 8B–14B (matematica lectiei 7 spune ca masina ta poate)
- **Adauga RAG cum trebuie**: baza de date vectoriala + retrieval in fata endpoint-ului lui Ember
- **Incearca function calling**: fine-tune pe iesiri structurate de apeluri de unelte — acelasi pipeline, dataset nou
- **Automatizeaza bucla**: reantrenare + evaluare in fiecare noapte, ca dragonul sa se hraneasca singur
Checkpoint
Ember e in productie in spatele unui API real, ai o bucla de mentenanta cu un set de test de regresie si stii ca dataset-ul e activul care supravietuieste fiecarei versiuni de model. Curs complet — nu mai esti cineva care foloseste modele AI. Esti cineva care le antreneaza.