Stack-ul complet al unui sistem AI: de la hardware la utilizator

120–150 de minute · +60–90 de minute pentru exerciții · Nivel: începător · Recomandat înainte: Lecțiile 1 și 2

Lecția pe scurt

Întrebarea centrală: atunci când un utilizator adresează o cerere unui agent AI și primește un răspuns, câte componente diferite au fost necesare pentru ca acel lucru să fie posibil și ce responsabilitate are fiecare?

În Lecția 1 am separat concepte care sunt confundate frecvent — algoritm, model, automatizare, workflow, agent și autonomie. În Lecția 2 am intrat în interiorul agentului: obiectiv, observație, stare, alegerea acțiunii, instrumente, feedback, oprire, LLM și harness. Acum facem un pas înapoi și privim întregul sistem tehnic în care toate acestea pot funcționa.

Un agent nu „plutește” într-un nor abstract numit AI. Chiar și cel mai simplu agent are nevoie de un calculator fizic, de un sistem de operare, de software care să execute codul, de date, de permisiuni și de o interfață prin care cineva îi dă o sarcină. Dacă agentul folosește un model local, mai apar fișierele modelului, software-ul care le încarcă și, uneori, drivere și biblioteci care permit folosirea unui GPU. Dacă modelul este apelat printr-un serviciu extern, acele straturi nu dispar: sunt administrate de altcineva.

Scopul lecției nu este să instalezi toate tehnologiile pe care le vom numi și nici să alegi acum „stack-ul perfect”. Scopul este mai important: să poți privi orice produs sau diagramă și să întrebi „ce responsabilitate îndeplinește această componentă?”. Când știi să pui această întrebare, devine mult mai greu să confunzi un model cu un server de model, un driver cu CUDA, un container cu o politică de securitate sau un API cu agentul care îl folosește.

La finalul lecției vei putea

1. să urmărești o cerere de la utilizator până la hardware și înapoi, identificând straturile prin care trece;
2. să explici diferența dintre CPU, RAM, stocare, GPU și VRAM fără să le tratezi ca pe o listă de specificații;
3. să separi sistemul de operare, kernelul, driverul și platforma de accelerare;
4. să explici de ce Python, PyTorch, un fișier GGUF, Ollama și un agent sunt obiecte tehnice diferite;
5. să deosebești modelul, artefactul modelului, runtime-ul de inferență și serverul de model;
6. să plasezi controllerul agentului, instrumentele, datele, starea și mecanismele de securitate în locul potrivit;
7. să diferențiezi logurile, metricile, urmele de execuție, testele și evaluările;
8. să explici ce se schimbă și ce nu se schimbă când sistemul rulează local, în cloud, hibrid sau la marginea rețelei (edge);
9. să descrii compatibilitatea ca proprietate a întregului sistem, nu ca proprietate izolată a unei singure componente;
10. să reconstruiești din memorie harta stack-ului și să justifici relațiile dintre straturi.

1. Ce înseamnă un stack și de ce contează

Începem prin a separa două idei care par asemănătoare, dar nu sunt: lista produselor pe care le folosim și harta responsabilităților care trebuie îndeplinite.

Imaginează-ți că deschizi o pagină web, scrii „rezumă acest contract” și primești un răspuns. Din exterior vezi doar două lucruri: o interfață și textul final. Din interior, însă, pot exista zeci de operații: browserul trimite o cerere, aplicația identifică utilizatorul, salvează documentul, agentul¹ decide ce informații îi trebuie, un parser extrage textul, un model este apelat, rezultatul este verificat, starea⁴ este actualizată, iar sistemul înregistrează ce s-a întâmplat.

Sub toate acestea există alte responsabilități pe care utilizatorul nu le vede: procese care rulează în sistemul de operare, memorie alocată, fișiere citite de pe SSD, trafic de rețea, eventual operații executate pe GPU¹⁹. Dacă modelul rulează pe un server al altui furnizor, acele componente nu au dispărut. Ele se află doar în infrastructura furnizorului.

De aceea, în această lecție folosim stack-ul ca pe o hartă a responsabilităților. Întrebarea utilă nu este „ce produs avem aici?”, ci „ce trebuie să facă această parte a sistemului?”. Același produs poate acoperi mai multe responsabilități, iar aceeași responsabilitate poate fi împărțită între mai multe produse.

O analogie utilă: o clădire în care etajele depind unele de altele

Gândește-te la o clădire. Un birou elegant de la etajul zece nu poate exista fără structură de rezistență, electricitate, apă, lifturi, acces și întreținere. Totuși, faptul că există instalația electrică nu îți spune ce activitate se desfășoară în birou. Fiecare nivel are altă responsabilitate.

Un stack software funcționează asemănător. Hardware-ul¹⁷ oferă resurse fizice. Sistemul de operare le organizează. Driverul²² permite folosirea corectă a unui dispozitiv. Runtime-ul¹⁰ execută un anumit tip de program. Un server de model²⁹ face modelul accesibil. Controllerul¹² agentului¹ decide ce acțiune urmează. Instrumentele⁵ modifică sau interoghează lumea din afara modelului. Interfața permite utilizatorului să formuleze obiectivul.

1.1 Ce se schimbă atunci când modelul este local sau găzduit de altcineva

Dacă rulezi un model pe propriul calculator, tu vezi și administrezi o parte mare din stack: modelul ocupă spațiu pe SSD, runtime-ul¹⁰ îi alocă RAM sau VRAM²⁰, driverul²² trebuie să funcționeze, iar sistemul de operare trebuie să poată vedea dispozitivul de calcul.

Dacă aplicația ta apelează un model printr-un API⁹ găzduit de altă companie, propriul calculator nu trebuie să încarce acel model. Totuși, undeva există în continuare servere, memorie, sisteme de operare, drivere²² și software de inferență. Furnizorul le operează pentru tine. În schimb, tu rămâi responsabil de propriile date, de logica agentului¹, de permisiunile instrumentelor⁵ și de ceea ce faci cu răspunsul primit.

2. Harta completă: paisprezece responsabilități, șase zone ușor de reținut

Harta tehnică a lecției enumeră paisprezece straturi. Le păstrăm pe toate, dar le grupăm în șase zone pentru ca harta să poată fi înțeleasă înainte de a fi memorată.

În tabelul următor, fiecare rând răspunde la o întrebare diferită. Prima coloană spune ce întrebare trebuie să poți pune. A doua numește responsabilitatea tehnică. A treia oferă un exemplu concret. Nu citi tabelul ca pe o listă de produse pe care trebuie să le instalezi; citește-l ca pe o listă de funcții care trebuie să fie îndeplinite undeva în sistem.

Cum citești harta: dacă înlocuiești un produs, de obicei nu elimini responsabilitatea. De exemplu, dacă nu mai rulezi modelul local și folosești un API⁹ extern, responsabilitățile 1–7 există în continuare, dar o parte dintre ele sunt administrate de furnizor. Dacă un produs acoperă mai multe rânduri, rândurile nu se contopesc conceptual: trebuie să știi în continuare ce face produsul în fiecare rol.

3. Zona I — fundația fizică: CPU, RAM, stocare, GPU, VRAM și rețea

Hardware-ul¹⁷ stabilește limitele fizice ale sistemului: câtă putere de calcul avem la dispoziție, câtă informație putem păstra activă, cât de repede putem încărca fișiere și ce volum de trafic putem transfera. Specificațiile nu aleg însă arhitectura în locul nostru.

3.1 CPU, RAM și stocare — resursele generale ale sistemului

CPU¹⁸ — procesorul general care nu dispare atunci când apare GPU-ul¹⁹

CPU¹⁸ vine de la central processing unit. Este procesorul general al calculatorului. Sistemul de operare, aplicația agentului¹, parsarea JSON, accesul la fișiere, multe interogări de baze de date, apelurile de rețea și o parte din pregătirea datelor sunt executate de CPU chiar și într-un sistem care folosește un GPU¹⁹ pentru inferență.

Un GPU¹⁹ foarte puternic nu face CPU-ul¹⁸ inutil. Imaginează-ți un restaurant cu o bucătărie industrială extraordinară, dar cu o singură persoană care primește comenzile, verifică ingredientele și duce farfuriile. Dacă acea parte este lentă, bucătăria poate sta degeaba. Într-un sistem AI, blocajul poate fi modelul, dar poate fi la fel de bine citirea de pe disc, pregătirea datelor, rețeaua sau logica aplicației.

RAM — memoria de lucru a programelor aflate în execuție

RAM este memoria de lucru rapidă a calculatorului. Când pornești o aplicație, o parte din codul și datele ei ajung în RAM. Spre deosebire de SSD sau hard disk, conținutul RAM nu este conceput pentru a rămâne după oprirea alimentării.

Într-un sistem AI local, RAM-ul poate fi ocupat de sistemul de operare, browser, runtime-ul¹⁰ Python, baze de date, indecși de documente, fișiere temporare, procesele agentului¹ și, în unele configurații, o parte din model. Dacă RAM-ul este insuficient, sistemul poate deveni foarte lent sau poate refuza alocări noi.

Stocarea — ceea ce trebuie să supraviețuiască opririi

SSD-ul sau hard disk-ul păstrează datele în mod persistent: cod, modele descărcate, baze de date, documente, imagini, loguri, rezultate de evaluare și imagini de container³⁴. Un fișier de model mare poate avea de la câteva sute de megabytes la zeci sau sute de gigabytes, iar colecțiile de date pot depăși cu mult dimensiunea modelului.

Nu contează numai capacitatea. Viteza de citire influențează cât de repede poate fi încărcat un model sau un set de date. Într-un sistem care pornește modelul o singură dată și apoi îl ține în memorie, viteza SSD-ului poate conta mai mult la pornire decât după aceea.

3.2 GPU și VRAM — calcul paralel și memorie aflată lângă accelerator

GPU¹⁹ vine de la graphics processing unit. Deși aceste procesoare au fost dezvoltate pentru grafică, structura lor este potrivită și pentru executarea în paralel a unui număr foarte mare de operații numerice. Rețelele neuronale folosesc intens astfel de operații, motiv pentru care GPU-urile au devenit importante pentru antrenare și inferență.

VRAM²⁰ este memoria direct disponibilă unui GPU¹⁹ discret. Acolo pot sta ponderile²⁵ modelului, reprezentări intermediare și cache-uri folosite în timpul generării. Cantitatea necesară nu depinde doar de „numărul de parametri” al modelului. Contează precizia numerică sau cuantizarea²⁷, lungimea contextului, numărul cererilor simultane, arhitectura modelului și tipul sarcinii.

Un model care încape tehnic în memorie nu este neapărat practic. Poate răspunde foarte lent, poate lăsa prea puțină memorie pentru un context mai lung sau poate servi un singur utilizator în condiții acceptabile, dar nu zece simultan.

3.3 Rețeaua — comunicarea dintre componente

Rețeaua contează imediat ce o parte a stack-ului se află în altă parte: model prin API⁹, bază de date aflată la distanță, stocare comună, senzori, aplicație mobilă sau mai multe servere. Lățimea de bandă, latența și disponibilitatea rețelei pot deveni parte din experiența utilizatorului.

„Local” nu înseamnă întotdeauna „fără rețea”. Un agent¹ poate rula fără internet și totuși să comunice prin rețeaua internă cu un NAS, un senzor, un alt computer sau un server al companiei.

Tabelul următor nu compară „care componentă este mai importantă”, ci arată ce problemă rezolvă fiecare resursă. Citește fiecare rând pornind de la simptomul pe care l-ai putea vedea într-un sistem real.

Concluzia: performanța este rezultatul unui traseu complet. Când un sistem este lent, nu începe diagnosticul cu presupunerea „modelul este prea mare”. Mai întâi identifică etapa în care apare întârzierea.

4. Zona II — de la hardware la software: sistem de operare, kernel, drivere și accelerare

Hardware-ul¹⁷ există fizic, dar aplicațiile nu îl controlează direct după bunul plac. Între program și dispozitive există straturi care organizează accesul, împart resursele și traduc cererile software în operații pe hardware.

4.1 Sistemul de operare și kernelul — cine administrează resursele și mediază accesul la hardware

Sistemul de operare — administratorul resurselor calculatorului

Sistemul de operare este software-ul de bază care organizează procesele, memoria, fișierele, utilizatorii, dispozitivele, rețeaua și permisiunile. Ubuntu și Kubuntu sunt sisteme Linux; ele folosesc același nucleu Linux, dar pot avea interfețe grafice și pachete implicite diferite.

Pentru un agent¹ software, sistemul de operare contează foarte concret. El decide în ce folder poate scrie procesul, ce dispozitive vede, ce porturi de rețea poate deschide, ce utilizator îl execută și ce alte procese există. Lecțiile următoare vor intra mult mai adânc în aceste concepte; aici trebuie doar să vezi locul lor în hartă.

Kernelul²¹ — partea privilegiată care mediază accesul la hardware¹⁷

Kernelul²¹ este nucleul privilegiat al sistemului de operare. O aplicație obișnuită nu comunică direct, fără intermediere, cu controlerul SSD, placa de rețea sau memoria fizică. Ea cere sistemului de operare operații controlate, iar kernelul gestionează accesul la resurse.

Această separare este importantă și pentru securitate. Dacă orice proces ar putea citi memoria oricărui alt proces sau ar controla orice dispozitiv fără reguli, izolarea dintre aplicații ar dispărea. Autoritatea reală a agentului¹ nu este determinată doar de prompt³; ea depinde și de drepturile procesului în sistemul de operare.

4.2 Driverul — legătura dintre sistemul de operare și un dispozitiv

Un driver²² este software-ul care permite sistemului de operare să comunice corect cu o anumită categorie de hardware¹⁷. Pentru GPU¹⁹-uri poți întâlni, de exemplu, drivere NVIDIA, driverul Linux amdgpu pentru hardware AMD sau drivere Intel.

Un driver²² funcțional nu înseamnă automat că ai instalat toate instrumentele⁵ pentru dezvoltare GPU¹⁹. De exemplu, sistemul poate vedea un GPU și îl poate folosi pentru afișarea desktopului, chiar dacă nu ai instalat un pachet complet de dezvoltare (toolkit) pentru calcul sau un framework de machine learning.

4.3 Platforma de accelerare — software-ul care folosește eficient hardware-ul specializat

O platformă de accelerare²³ este un ansamblu de runtime-uri¹⁰, compilatoare, biblioteci și instrumente⁵ care fac posibilă folosirea unui accelerator pentru calcule generale. CUDA este platforma NVIDIA pentru calcul paralel pe GPU¹⁹-uri compatibile. ROCm este stack-ul software AMD pentru calcul accelerat pe GPU-uri compatibile. Alte ecosisteme au alte căi, cum ar fi Metal în ecosistemul Apple sau tehnologii Intel specifice platformei.

Nu trebuie să înveți acum API⁹-urile acestor platforme. Ideea de reținut este relația dintre straturi: driverul²² face dispozitivul utilizabil de sistem; platforma de accelerare²³ oferă mecanisme prin care software-ul de calcul poate folosi dispozitivul eficient; framework-ul sau runtime-ul de inferență²⁸ folosește acele mecanisme pentru model.

GPU fizic
   ↓
driver compatibil
   ↓
platformă / biblioteci de accelerare
   ↓
framework sau runtime de inferență
   ↓
modelul executat

Tabelul următor este construit pentru una dintre cele mai frecvente confuzii de început: toate componentele par „software pentru GPU¹⁹”, dar fiecare răspunde la altă întrebare. Coloana din mijloc spune ce face componenta; ultima coloană arată ce concluzie nu avem voie să tragem doar din existența ei.

Cum interpretezi tabelul: într-un incident real, întrebarea „unde se rupe lanțul?” este mai bună decât „de ce nu merge AI-ul?”. Dacă sistemul de operare nu vede GPU-ul¹⁹, problema este mai jos decât PyTorch. Dacă PyTorch vede acceleratorul, dar modelul nu se încarcă, cauți mai sus: artefact²⁶, memorie, format sau runtime¹⁰.

5. Zona III — software-ul care execută aplicația și calculele modelului

Acum urcăm un nivel. Sistemul de operare poate rula procese și poate vedea hardware-ul¹⁷; următoarea întrebare este ce mediu execută codul aplicației și ce biblioteci implementează operațiile matematice folosite de modele.

5.1 Limbaj, runtime, dependențe și mediu virtual

În laboratoarele anterioare ai folosit Python și un mediu virtual. Aici le plasăm pe amândouă în hartă. Codul Python al agentului¹ este un set de instrucțiuni; runtime-ul¹⁰ Python este software-ul care le interpretează și le execută. Pachetele instalate pentru proiect sunt dependențe: cod de care aplicația depinde pentru anumite funcții.

Un agent¹ nu trebuie să fie scris în Python. Poate fi scris în TypeScript, JavaScript, Rust, Go, Java, C# sau alt limbaj. Alegerea limbajului schimbă ecosistemul de pachete și modul de deployment³³, dar nu schimbă responsabilitățile pe care le presupune un agent.

Un proiect reproductibil trebuie să poată răspunde la întrebări simple: ce versiune de limbaj folosește? ce pachete și versiuni cere? ce variabile de mediu trebuie definite? ce comandă pornește serviciul? ce comandă rulează testele? Fără aceste informații, „merge la mine” nu este o descriere tehnică suficientă.

Mediul virtual Python nu este o mașină virtuală și nu este un sandbox⁷

Un mediu virtual Python izolează în principal interpretorul și pachetele Python ale proiectului. Dacă două proiecte au nevoie de versiuni diferite ale aceleiași biblioteci, mediile virtuale reduc conflictul.

El nu creează însă un sistem de operare separat și nu reprezintă o barieră serioasă de securitate. Un program din mediul virtual poate avea, în limitele utilizatorului care îl execută, acces la fișiere, rețea și alte resurse ale sistemului. De aceea nu trebuie confundat cu o mașină virtuală, un container³⁴ configurat restrictiv sau un sandbox⁷ de execuție.

5.2 Tensorul — forma de date pe care framework-urile ML o manipulează masiv

Un tensor²⁴ este, în termeni practici, o structură multidimensională de numere. Un singur număr poate fi privit ca tensor cu zero dimensiuni; o listă de numere ca tensor cu o dimensiune; un tabel ca tensor cu două dimensiuni; un lot de imagini poate necesita și mai multe dimensiuni.

În rețele neuronale, ponderile²⁵, embeddings, imaginile transformate numeric și multe rezultate intermediare sunt reprezentate ca tensori²⁴. Framework-urile ML oferă operații eficiente pentru prelucrarea acestor structuri și pentru a executa aceleași calcule pe CPU¹⁸ sau pe acceleratoare compatibile.

5.3 Framework-uri și biblioteci ML — unde sunt implementate operațiile numerice

PyTorch, TensorFlow și JAX sunt exemple de software pentru calcul numeric și machine learning. Ele pot ajuta la definirea, antrenarea și executarea modelelor, folosind operații pe tensori²⁴ și mecanisme de diferențiere/optimizare.

Acestea nu sunt, prin simplul fapt că există, framework-uri de agenți¹. PyTorch poate calcula ieșirea unei rețele neuronale, dar nu stabilește automat obiectivul agentului, nu decide ce instrument⁵ de business este permis și nu cere aprobarea unui om înainte de o plată. Aceste responsabilități apar mai sus în stack.

Biblioteci de suport — piesele specializate care fac execuția eficientă

În jurul framework-urilor există numeroase biblioteci cu roluri mai înguste. NumPy oferă structuri și operații numerice generale. Biblioteci precum cuDNN oferă primitive optimizate pentru anumite operații neuronale pe hardware¹⁷ NVIDIA. Tokenizer-ele transformă textul în identificatori de tokeni, iar bibliotecile de comunicație pot coordona calcule distribuite pe mai multe acceleratoare.

Nu trebuie să memorezi aceste nume acum. Lecția importantă este diferența de scară: o bibliotecă oferă de regulă o capacitate reutilizabilă, un framework organizează un ansamblu mai larg de dezvoltare, iar un engine/runtime¹⁰ execută un anumit tip de sarcină. Marketingul nu folosește aceste cuvinte perfect consecvent, deci verificăm responsabilitatea reală.

Tabelul următor răspunde la o întrebare foarte practică: când vezi un nume într-un tutorial, la ce nivel trebuie să-l plasezi? Exemplele sunt intenționat contrastante ca să nu tratăm toate „tehnologiile AI” ca aceeași categorie.

Observația importantă: cuvântul „framework” nu garantează că două produse sunt din aceeași categorie. Trebuie să adaugi mereu întrebarea „framework pentru ce?”.

6. Zona IV — modelul nu rulează singur: artefact, cuantizare, runtime de inferență și server de model

Aceasta este una dintre cele mai importante distincții ale lecției. În limbaj obișnuit spunem adesea „rulez modelul”, dar tehnic sunt implicate mai multe obiecte diferite: modelul ca arhitectură și ansamblu de capacități, fișierele care conțin parametrii și software-ul care știe să le încarce și să execute inferența.

6.1 Artefactul modelului — ponderi, format, model card și licență

Modelul și artefactul²⁶ modelului nu sunt același lucru

În Lecțiile 1 și 2 am folosit cuvântul model pentru componenta care transformă o intrare în ieșire. Când ajungem la infrastructură, trebuie să separăm această idee de fișierele concrete stocate pe disc.

Un artefact²⁶ de model este ansamblul de fișiere care păstrează ceea ce trebuie încărcat pentru a folosi un model antrenat. Poate conține ponderile²⁵ învățate, configurația arhitecturii, vocabularul și regulile tokenizerului, șablonul de conversație, informații despre cuantizare²⁷, configurația componentelor de preprocesare pentru imagini sau audio și documente precum model card sau licență.

Ponderile²⁵ (weights) sunt valorile numerice ajustate în timpul antrenării. Ele nu sunt un program care se execută singur. Sunt date numerice pe care un software compatibil le citește și le folosește în operațiile definite de arhitectură.

Formatul fișierului nu este familia modelului

Vei întâlni formate precum Safetensors, GGUF, ONNX sau checkpoint-uri specifice unui framework. Aceste nume descriu modul în care datele modelului sunt împachetate sau reprezentate pentru anumite ecosisteme; nu descriu automat ce știe modelul.

De aceea propoziția „folosesc un GGUF” este incompletă. GGUF spune ceva despre formatul artefactului²⁶ și despre ecosistemele care îl pot încărca. Nu spune ce familie de model este, câți parametri are, în ce limbi este bun, ce licență are sau cât de bine rezolvă sarcina ta.

Tabelul următor separă patru întrebări pe care începătorii le comprimă frecvent într-una singură. Fiecare rând descrie altă proprietate a aceluiași sistem.

Concluzia: o descriere tehnică bună poate conține toate cele patru răspunsuri. Dacă lipsește unul dintre ele, nu presupune că restul poate fi dedus din numele unui singur produs.

Model card și licență — faptul că poți descărca fișierele nu înseamnă că le poți folosi oricum

Repository-ul unui model poate include un model card, adică documentația care descrie scopul modelului, datele sau procedurile de antrenare cunoscute, limitări, evaluări și recomandări de utilizare. Calitatea acestor documente variază, dar ele sunt primul loc în care cauți informații despre model înainte să îl integrezi.

Licența este o problemă separată de performanță. Faptul că ponderile²⁵ pot fi descărcate nu înseamnă automat că orice utilizare comercială, redistribuire sau modificare este permisă. Pentru un produs real verifici textul licenței aplicabile artefactului²⁶ și componentelor software din jur.

6.2 Cuantizarea — mai puțini biți pentru reprezentarea valorilor

Cuantizarea²⁷ (quantization) reduce precizia numerică folosită pentru a reprezenta anumite valori ale modelului. Scopul practic este de obicei reducerea memoriei și, în anumite condiții, creșterea vitezei. Compromisul este că reprezentarea mai puțin precisă poate modifica rezultatele, iar metodele de cuantizare nu sunt toate echivalente.

Ca intuiție aritmetică, dacă am păstra 7 miliarde de valori la 16 biți fiecare, doar acele valori ar necesita aproximativ 14 GB. La 4 biți, aceeași socoteală brută ar fi aproximativ 3,5 GB. În practică există metadate, alte structuri și memorie temporară, deci aceste numere nu sunt o promisiune de consum total. Ele arată doar de ce precizia numerică influențează atât de mult dimensiunea.

Eticheta „4-bit” nu este suficientă pentru o comparație serioasă. Două metode de cuantizare²⁷ la același număr nominal de biți pot avea calitate, viteză și compatibilitate diferite.

6.3 Runtime-ul de inferență — software-ul care încarcă artefactul și execută modelul

Un runtime de inferență²⁸ este software-ul care încarcă artefactul²⁶ modelului, pregătește intrarea numerică, alocă memorie, execută operațiile modelului și transformă ieșirea în forma pe care aplicația o poate folosi.

În cazul unui LLM², un runtime¹⁰ poate participa la pași precum: încărcarea ponderilor²⁵, tokenizarea intrării, gestionarea cache-ului de atenție, executarea operațiilor pe CPU¹⁸/GPU¹⁹, alegerea tokenilor conform parametrilor de generare și decodarea lor în text. Unele detalii pot fi împărțite între biblioteci, dar responsabilitatea generală rămâne aceeași: permite executarea inferenței.

Exemple de runtime-uri¹⁰ sau motoare de inferență includ llama.cpp, ONNX Runtime, OpenVINO și execuția oferită de framework-uri. Un produs poate include intern un astfel de runtime și să ascundă complexitatea.

6.4 Serverul de model — menține modelul disponibil și îl expune altor aplicații

Un server de model²⁹ este un proces care păstrează unul sau mai multe modele disponibile și acceptă cereri printr-o interfață, adesea HTTP. Avantajul este că aplicația agentului¹ nu trebuie să implementeze singură încărcarea modelului. Ea trimite o cerere și primește un răspuns.

Produse precum Ollama sau vLLM pot îndeplini roluri de rulare și servire a modelelor, cu scopuri și niveluri de optimizare diferite. Asta nu le transformă automat în agenți¹. Serverul răspunde atunci când este apelat; controllerul¹² agentului decide dacă, când și de ce trebuie apelat modelul.

6.5 Inferență locală versus inferență la distanță (remote)

Când modelul rulează local, tu administrezi mai multe straturi: fișiere, memorie, runtime¹⁰, eventual driver²² și accelerator. Poți obține funcționare offline și control direct asupra datelor, dar îți asumi întreținerea și limitele hardware-ului¹⁷.

Când modelul este oferit prin API⁹ găzduit la distanță, furnizorul administrează hardware-ul¹⁷ și servirea modelului. Pentru aplicația ta, componenta devine o dependență de rețea: trebuie să gestionezi autentificarea, depășirile timpului de așteptare (timeout-urile), limitele, costurile și politica de date. Niciuna dintre variante nu este automat mai ieftină, mai sigură sau mai rapidă pentru orice sarcină.

Comparația de mai jos nu încearcă să declare un câștigător. Ea arată ce responsabilitate se mută și ce compromis apare. Aceeași aplicație poate chiar folosi ambele variante pentru sarcini diferite.

Regula de decizie: alegerea are sens numai după ce cunoști volumul de lucru, sensibilitatea datelor, necesarul de latență, bugetul, conectivitatea și cine poate întreține sistemul.

7. Zona V — deasupra modelului: controllerul agentului, instrumentele și datele

Aici legăm Lecția 3 de Lecția 2. Modelul produce ieșiri când este apelat; agentul¹ este sistemul care urmărește un obiectiv, păstrează stare⁴, alege acțiuni și interpretează feedbackul.

7.1 Controller, orchestrator și harness — cine coordonează pașii agentului

În Lecția 2 am numit această responsabilitate componentă de control sau controller¹². Aici îi vedem locul în stack: se află deasupra modelului și a instrumentelor⁵ și le coordonează pentru atingerea obiectivului.

Controllerul¹² poate încărca obiectivul, păstra starea⁴, pregăti cererea către model, verifica răspunsul, selecta un instrument⁵, cere aprobarea unui om, înregistra rezultatul și testa condițiile de oprire. Unele sisteme fac aceste lucruri prin cod Python simplu; altele folosesc framework-uri, motoare de workflow⁶ sau aplicații complete.

Un controller¹² poate fi determinist, cum a fost agentul¹ de factură din laboratorul Lecției 2, sau poate consulta un model pentru anumite decizii. Într-o arhitectură hibridă, codul poate păstra regulile de siguranță, iar modelul poate interpreta limbajul sau propune opțiuni.

Orchestrator, harness¹³, runtime¹⁰ de agent¹ și workflow⁶ engine — termeni care se pot suprapune

În industrie vei întâlni termeni precum orchestrator, agent¹ runtime¹⁰, agent harness¹³, workflow⁶ engine sau framework de agenți. Nu presupune că sunt sinonime perfecte. Un produs poate coordona doar apeluri de model și instrumente⁵; altul poate gestiona și persistența stării⁴, cozi, programări, canale de mesagerie, aprobări și deployment³³.

Metoda sigură este aceeași ca în întreaga lecție: înlocuiește eticheta cu o listă de responsabilități. „Ce stare⁴ păstrează? Ce poate executa? Cine validează? Cine reia după eroare? Unde sunt permisiunile?”

7.2 Instrumente, API-uri și MCP — cum ajunge agentul dincolo de model

Un model nu are prin el însuși acces la baza de date, calendar, fișiere sau senzori. Instrumentele⁵ expun capabilități precise pe care controllerul¹² le poate apela. Un instrument bun are un scop îngust, intrări clare, ieșiri previzibile, erori explicite și limite de autoritate.

calculeaza_total_factura(linii)
cauta_in_manual(intrebare)
citeste_senzor(id_senzor, interval)
creeaza_draft_email(destinatar, subiect, continut)

Un API⁹ este o convenție prin care două componente software schimbă cereri și răspunsuri. Un instrument⁵ poate apela un API existent, dar instrumentul și API-ul nu sunt obligatoriu același lucru: instrumentul poate adăuga validare, limite și o interfață mai îngustă peste acel API.

MCP — Model Context Protocol este un standard deschis pentru conectarea aplicațiilor AI la capabilități externe printr-o arhitectură client–server. În ecosistemul MCP vei întâlni în special tools, resources și prompts. Pentru această lecție este suficient să îl plasezi la stratul de integrare: nu este model, nu este GPU¹⁹ și nu este definiția agentului¹. Lecțiile ulterioare vor aborda protocoalele și integrările mai practic.

7.3 Date, stare, memorie și retrieval — patru probleme diferite

În produsele AI, termenul „memory” este folosit foarte larg. Pentru proiectare, este mai sigur să separăm cel puțin patru categorii.

Datele sursă sunt informațiile primite din exterior: contracte, facturi, senzori, fișiere, baze de date. Starea⁴ agentului¹ spune unde a ajuns execuția curentă: obiectiv, pași făcuți, rezultate, aprobări, erori, condiție de oprire. Datele persistente ale aplicației trebuie să rămână disponibile și după încheierea rulării: conturi, preferințe, istorice, configurații. Retrieval-ul caută și aduce în context informațiile relevante atunci când sunt necesare.

Aceste categorii se pot stoca în aceeași bază de date, dar nu devin același lucru doar pentru că sunt stocate împreună.

Tabelul următor pornește de la întrebarea „ce anume vrem să păstrăm și pentru cât timp?”. A doua coloană explică rolul, iar a treia urmărește un singur exemplu — analiza unui contract — ca să nu rămânem la enumerări abstracte.

De ce contează separarea: politicile de încredere și retenție pot fi diferite. Documentul sursă poate fi neverificat; starea⁴ derivată trebuie să spună clar cine a calculat-o; datele persistente pot necesita ștergere la cerere; retrieval-ul trebuie să indice sursa informației recuperate.

Istoria conversației nu este automat memorie de încredere

Dacă salvezi fiecare mesaj la nesfârșit, nu obții automat „memorie bună”. Poți păstra greșeli, instrucțiuni temporare, date sensibile sau conținut ostil¹⁶ introdus printr-un document. O arhitectură matură decide ce poate fi păstrat, cât timp, cu ce proveniență și dacă informația trebuie verificată înainte să influențeze o acțiune viitoare.

8. Zona VI — cum ținem sistemul sub control: securitate, observabilitate, interfață și deployment

Până acum am construit drumul tehnic de la hardware¹⁷ la model și agent¹. Dar un sistem real mai are nevoie de patru lucruri: să știe cine face cererea și ce are voie să facă, să poată explica ce s-a întâmplat, să ofere o interfață și să fie menținut într-un mediu de rulare concret.

8.1 Identitate, autorizare și secrete: „cine ești?” nu este aceeași întrebare cu „ce ai voie?”

Identitatea răspunde la întrebarea „cine face această cerere?”. Poate fi un utilizator, un serviciu, o aplicație sau un proces. Exemplele tehnice includ conturi de sistem de operare, conturi de serviciu, identități OAuth, certificate sau alte mecanisme de autentificare.

Autorizarea răspunde la altă întrebare: „ce are voie să facă identitatea respectivă?”. Un utilizator poate avea voie să citească facturi, dar nu să le șteargă; un agent¹ poate avea voie să creeze un draft, dar nu să-l trimită; un proces poate scrie numai într-un anumit folder.

Secretele sunt informații sensibile folosite pentru autentificare sau criptografie: chei API⁹, parole, chei private, tokenuri de acces. Ele nu ar trebui scrise direct în cod și nici salvate în repository-ul Git. Faptul că un fișier este „ascuns” prin nume nu îl face sigur.

Guvernanța: regulile organizației care stau deasupra unei singure cereri

Guvernanța stabilește reguli precum ce clase de date pot fi procesate, cât timp sunt păstrate, ce furnizori de model sunt acceptați, ce acțiuni necesită aprobare umană, cine răspunde pentru deciziile finale și cum este gestionat un incident. Codul poate implementa o parte dintre aceste reguli, dar originea lor este organizațională și juridică, nu neuronală.

Într-un produs real, „agentul¹ poate, din punct de vedere tehnic,” și „organizația permite” trebuie să fie tratate ca două condiții distincte. Autoritatea tehnică trebuie configurată astfel încât să respecte politica stabilită.

8.2 Sandbox, container și mașină virtuală: forme diferite de izolare

Un sandbox⁷ urmărește să limiteze ce poate accesa și modifica un proces sau codul pe care îl execută. Poate restricționa fișiere, rețea, dispozitive, procese sau credențiale.

Un container³⁴ împachetează aplicația împreună cu fișierele și dependențele necesare și rulează procesul într-un mediu izolat la nivel de sistem de operare. Containerele sunt excelente pentru reproducibilitate și separare operațională, dar un container configurat cu privilegii largi, volume sensibile sau rețea deschisă nu devine automat un sandbox⁷ sigur.

O mașină virtuală poate oferi o separare mai puternică deoarece rulează propriul sistem de operare invitat deasupra unui hipervizor. Și aici configurația contează; niciun cuvânt — container³⁴, VM, sandbox⁷ — nu înlocuiește analiza permisiunilor reale.

8.3 Observabilitatea: cum răspundem la „ce s-a întâmplat?” fără să ghicim

Observabilitatea³¹ este capacitatea de a înțelege comportamentul unui sistem din informațiile pe care acesta le emite. Pentru un agent¹, observabilitatea este esențială deoarece o sarcină poate trece prin model, instrumente⁵, baze de date, aprobări și servicii diferite.

Nu este suficient să știm că „răspunsul final a fost greșit”. Vrem să putem reconstrui traseul: ce cerere a primit agentul¹, ce instrument⁵ a apelat, ce rezultat a primit, dacă a existat o eroare, dacă a reîncercat și de ce s-a oprit.

Loguri

Un log este o înregistrare a unui eveniment. De exemplu: „a fost apelat instrumentul⁵ X”, „baza de date a răspuns cu eroare”, „sistemul a intrat în starea⁴ waiting_for_approval”. Logurile sunt utile pentru detalii discrete, dar o colecție mare de linii de log fără legături între ele poate fi greu de urmărit.

Metrici

O metrică³² este o măsurătoare numerică urmărită în timp: cereri pe minut, latență mediană, procent de erori, utilizare GPU¹⁹, memorie ocupată, număr de intervenții umane sau cost mediu pe sarcină. Metricile răspund bine la întrebări despre tendințe și sănătatea generală a sistemului.

Urme de execuție

O urmă de execuție (trace) leagă operațiile care aparțin aceleiași cereri sau sarcini. Dacă un utilizator trimite o întrebare și sistemul cheamă controllerul¹², modelul, un instrument⁵ de căutare și baza de date, trace-ul le poate reuni într-o singură succesiune cronologică.

Teste și evaluări

Testele verifică de obicei comportamente deterministe: o funcție respinge date invalide; aprobarea este obligatorie înainte de o acțiune; o limită de pași oprește bucla. Evaluările măsoară calitatea componentelor probabilistice sau a rezultatului end-to-end: a ales instrumentul⁵ corect? răspunsul este susținut de dovezi? a îndeplinit sarcina?

Un test trecut nu dovedește că răspunsurile modelului sunt bune. O demonstrație impresionantă nu dovedește că regulile de siguranță sunt corecte. Avem nevoie de ambele.

Tabelul următor pornește de la întrebarea pe care vrem să o investigăm. Astfel vedem de ce logurile, metricile, trace-urile, testele și evaluările sunt complementare, nu cinci denumiri pentru aceeași activitate.

Lectura corectă: observabilitatea³¹ îți spune ce a făcut sistemul; testele și evaluările te ajută să judeci dacă ceea ce a făcut corespunde cerințelor. În practică, datele se pot susține reciproc: o evaluare eșuată poate fi investigată printr-un trace.

8.4 Interfața: partea vizibilă nu este întregul sistem

Interfața poate fi un terminal, o pagină web, un chat, o aplicație mobilă, voce, e-mail, un endpoint³⁰ API⁹, un eveniment de la un senzor sau o sarcină programată. Ea primește obiectivul și prezintă rezultatul, dar nu ne spune singură nimic despre calitatea arhitecturii din spate.

O interfață bună arată și starea⁴ operațională. Utilizatorul trebuie să poată diferenția „finalizat”, „aștept informații”, „aștept aprobare”, „blocat”, „eșuat” sau „expirat”. Un spinner care se rotește la nesfârșit ascunde exact informația de care utilizatorul are nevoie.

8.5 Deployment și operațiuni: unde rulează sistemul și cine îl menține

Deployment³³ înseamnă aducerea aplicației într-un mediu în care poate fi utilizată și menținerea ei acolo. Același cod poate rula pe laptopul dezvoltatorului, pe un server al companiei, în cloud, într-un cluster sau pe un dispozitiv din teren.

Local

Sistemul rulează pe calculatorul utilizatorului sau în rețeaua locală. Poate oferi funcționare offline și control direct asupra fișierelor, dar utilizatorul/organizația întreține hardware¹⁷, actualizări, backup și securitate.

Cloud

Sistemul rulează pe infrastructură închiriată sau servicii gestionate. Poți obține rapid resurse mari și servicii administrate, dar apar costuri recurente, dependență de rețea, contracte de date și responsabilități de integrare.

Hibrid

Responsabilitățile sunt împărțite. De exemplu, documentele pot rămâne local, în timp ce anumite fragmente aprobate sunt trimise către un model găzduit la distanță. Sau controllerul¹² poate rula în cloud, dar instrumentul⁵ care citește un senzor să ruleze în rețeaua fabricii. Flexibilitatea adaugă însă complexitate de rutare, sincronizare și securitate.

Edge

Edge³⁵ înseamnă că procesarea se face aproape de locul în care apar datele sau acțiunea: fabrică, vehicul, punct de lucru, stație de pompare, cameră, gateway de senzori. Acolo pot exista constrângeri de energie, conectivitate și robustețe care nu apar pe un server dintr-un centru de date.

Un sistem edge³⁵ poate trebui să continue când internetul cade, să consume puțină energie, să păstreze date local și să sincronizeze mai târziu. Din acest motiv, un model mai mic sau reguli deterministe pot fi mai potrivite decât un model maxim ca dimensiune.

9. Exemplu complet — urmărim o singură cerere prin întregul stack

Listele de straturi devin utile abia când poți urmări un eveniment real prin ele. Vom folosi aceeași cerere de la început până la sfârșit și vom arăta, pentru fiecare etapă, cine are responsabilitatea și ce informație trece mai departe.

Scenariul este deliberat simplu. Un utilizator încarcă un contract și cere:

„Găsește termenul de reziliere din acest contract și pregătește un răspuns pentru cealaltă parte. Nu trimite nimic.”

Important: această propoziție conține deja trei lucruri diferite. Există un obiectiv — găsește termenul; o sarcină de generare — pregătește un răspuns; și o limită de autoritate — nu trimite nimic. Stack-ul trebuie să transporte și să respecte toate trei.

Pasul 1 — Interfața primește cererea și fișierul

Pagina web sau aplicația primește textul utilizatorului și contractul. În acest punct nu s-a făcut încă inferența. Interfața verifică lucruri de bază precum dimensiunea fișierului și tipul de conținut acceptat și trimite cererea către aplicație.

Ce trebuie să înțelegi: interfața este poarta de intrare. Nu este modelul și nu ar trebui să fie singurul loc unde sunt impuse regulile de securitate, deoarece cererile pot ajunge la aplicația de server (backend) și prin alte căi.

Pasul 2 — Aplicația identifică utilizatorul și creează identitatea cererii

Backend-ul verifică cine este utilizatorul, ce drepturi are și poate atribui un identificator unic cererii. Acest ID va fi util ulterior pentru a lega loguri și trace-uri.

Ce trebuie să înțelegi: înainte ca agentul¹ să „gândească”, sistemul poate aplica reguli deterministe despre cine are voie să folosească funcția și ce date poate vedea.

Pasul 3 — Contractul este păstrat ca dată sursă

Fișierul original este salvat într-un loc permis. Textul poate fi extras într-o formă separată pentru analiză, dar documentul sursă rămâne distinct de notele și concluziile agentului¹.

Legătura cu Lecția 2: exact cum factura nu avea voie să pretindă că totalurile au fost deja verificate, contractul nu are voie să devină automat „adevărul interpretat”. Agentul¹ produce stare⁴ derivată separat.

Pasul 4 — Controllerul¹² creează starea⁴ sarcinii

Controllerul¹² transformă cererea într-o stare⁴ de lucru. O reprezentare simplificată poate arăta astfel:

{
  "obiectiv": "găsește termenul și pregătește un draft",
  "autoritate": "draft_only",
  "pasi_finalizati": [],
  "surse_gasite": [],
  "stop_reason": null
}

Valoarea draft_only este mai importantă decât pare: ea permite controllerului¹² să verifice ulterior că un instrument⁵ de trimitere nu poate fi executat în această sarcină.

Pasul 5 — Instrumentele⁵ de document și retrieval găsesc pasajele relevante

Un parser extrage textul. Un mecanism de căutare poate identifica pasajele care conțin termeni precum reziliere, notificare, încetare sau termen. Dacă documentul este lung, acest pas reduce informația trimisă modelului la fragmentele relevante.

Ce trebuie să înțelegi: modelul nu trebuie să fie baza de date. Instrumentele⁵ pot furniza informație exactă și citabilă, iar modelul o poate interpreta.

Pasul 6 — Controllerul¹² cheamă serverul de model²⁹

Controllerul¹² pregătește o cerere care conține instrucțiunea și pasajele relevante. Dacă modelul este local, cererea poate merge către un server de model²⁹ de pe aceeași mașină. Dacă este găzduit la distanță, traversează rețeaua către furnizor.

Serverul de model²⁹ nu știe automat politica de business „nu trimite”. El primește date și produce o ieșire conform interfeței sale. Autoritatea operațională rămâne la aplicație/controller¹².

Pasul 7 — Sub API⁹, runtime-ul¹⁰ încarcă/execută modelul pe hardware¹⁷

La nivelul inferior, runtime-ul¹⁰ transformă intrarea în forma necesară modelului, folosește artefactul²⁶ și execută operațiile pe CPU¹⁸/GPU¹⁹ prin stack-ul software compatibil. Dacă modelul este deja încărcat, ponderile²⁵ pot rămâne în memorie între cereri.

Acesta este punctul în care straturile „invizibile” utilizatorului devin active: driver²², biblioteci de accelerare, RAM/VRAM²⁰, CPU¹⁸/GPU¹⁹ și stocare.

Pasul 8 — Ieșirea modelului este validată înainte de a deveni rezultat

Codul poate verifica dacă răspunsul citează pasajul identificat, dacă a păstrat distincția dintre fapt și interpretare și dacă rezultatul este un draft, nu o afirmație falsă că mesajul a fost trimis.

Dacă modelul generează un format invalid, controllerul¹² poate cere o corectare, poate aplica un parser sau poate opri sarcina în loc să execute o acțiune bazată pe date greșite.

Pasul 9 — Starea⁴ și auditul păstrează ceea ce trebuie reconstruit

Sistemul poate înregistra pasajele recuperate, versiunea modelului, versiunea promptului, rezultatele instrumentelor⁵, starea⁴ finală și motivul opririi. Nu este necesar și nici sigur să copieze întregul contract confidențial în fiecare linie de log.

Pasul 10 — Utilizatorul vede rezultatul și limita de autoritate

Interfața afișează termenul identificat, pasajul care îl susține și draftul de răspuns. Trebuie să existe și un mesaj clar: „Nu a fost trimis niciun mesaj.”

Astfel, interfața nu oferă doar conținut; comunică și starea⁴ operațională.

Pasul 11 — Observabilitatea³¹ leagă traseul

Dacă utilizatorul semnalează o problemă, trace-ul poate arăta: cerere primită → document extras → căutare executată → model apelat → validare → rezultat afișat. Dacă pasul de căutare a selectat clauza greșită, nu mai trebuie să presupunem că „LLM-ul² a halucinat”; vedem unde a apărut eroarea.

10. Cinci profiluri de stack care pot fi toate corecte

Nu există o combinație universală de produse. Același obiectiv general poate fi implementat cu stack-uri foarte diferite, în funcție de volum, date, conectivitate, buget și cine operează sistemul.

laptop existent
→ Ubuntu/Kubuntu
→ Python + mediu virtual
→ controller determinist
→ instrumente locale
→ stare JSON
→ CLI
→ teste + trace JSONL

stație de lucru (workstation) cu CPU/GPU
→ Linux + driver compatibil
→ runtime / server de model local
→ artefact model descărcat
→ controller Python
→ instrumente locale
→ SQLite/PostgreSQL
→ interfață locală
→ loguri + evaluări

laptop de dezvoltare
→ aplicație server în Python/TypeScript
→ controller de agent
→ API către un model găzduit
→ bază de date gestionată
→ stocare de fișiere
→ aplicație web
→ loguri și metrici cloud

server dedicat cu GPU
→ Linux + drivere validate
→ server privat de model
→ identitate internă
→ controller + instrumente restricționate
→ baze de date private
→ loguri de audit
→ aprobare umană

cluster de acceleratoare
→ orchestrare containere
→ servere de inferență
→ gruparea cererilor în loturi (batching) și rutarea lor
→ ajustarea automată a capacității (autoscaling)
→ stocare distribuită
→ telemetrie și alerte
→ planificare de capacitate

11. Compatibilitatea este o proprietate a sistemului, nu a unei singure componente

Multe erori de instalare apar atunci când fiecare componentă pare corect configurată atunci când este verificată separat, dar combinația de versiuni și hardware¹⁷ nu este suportată.

Compatibilitatea poate depinde simultan de sistem de operare, kernel²¹, arhitectura CPU¹⁸, modelul exact al GPU¹⁹-ului, driver²², versiunea platformei de accelerare²³, versiunea Python, varianta compilată (build) a framework-ului, arhitectura modelului, formatul artefactului²⁶ și runtime-ul¹⁰ ales.

De aceea o frază precum „am eroare CUDA²³” este prea vagă. Pentru diagnostic avem nevoie de contextul complet.

Sistem de operare: versiunea exactă
Kernel: versiunea exactă
Arhitectură CPU: x86_64 / ARM64 / alta
GPU: modelul exact
Driver: versiunea exactă
Python: versiunea exactă
Framework/runtime: versiunea exactă
Artefact model: repository + revizie/fișier
Comanda: comanda exactă
Eroarea: mesajul complet

11.1 Graful de dependențe: relațiile sunt mai importante decât lista

O listă de tehnologii spune ce există; un graf de dependențe arată cine depinde de cine. Pentru depanare, a doua reprezentare este mult mai utilă.

Aplicația agentului
├── depinde de pachete Python
├── apelează API-ul serverului de model
├── apelează PostgreSQL
└── scrie telemetrie

Serverul de model
├── încarcă artefactul modelului
├── depinde de runtime/biblioteci
└── poate depinde de driver + platformă GPU

Dacă baza de date cade, nu are sens să reinstalezi driverul²² GPU¹⁹. Graful te ajută să limitezi zona de căutare.

11.2 Version pinning: reproducibilitate, nu îngheț permanent

Version pinning³⁶ înseamnă să înregistrezi versiuni exacte sau intervale permise pentru dependențe. Acest lucru face proiectul mai reproductibil: altă persoană poate reconstrui un mediu asemănător celui testat.

Versiunile fixate nu trebuie însă uitate pentru totdeauna. Apar actualizări de securitate și compatibilitate. Pinning³⁶-ul reduce variația necontrolată; nu elimină nevoia unui proces de actualizare.

12. Ce trebuie să existe și ce poate fi administrat de altcineva

Un serviciu gestionat poate ascunde un strat din vedere, dar nu poate șterge responsabilitatea arhitecturală. În această secțiune separăm „trebuie să existe undeva” de „trebuie să îl operez eu”.

Fiecare rând răspunde la două întrebări: responsabilitatea este necesară pentru tipul respectiv de sistem și, dacă da, poate fi delegată operațional unui furnizor? Ultima coloană arată ce responsabilitate rămâne totuși la echipa care construiește produsul.

Concluzia: externalizarea schimbă cine operează stratul. Nu elimină nevoia de cerințe, limite, contracte, permisiuni și planuri pentru eșec.

13. Greșeli frecvente când citim un stack AI

Cele mai multe confuzii nu vin din lipsă de inteligență, ci din folosirea unui singur cuvânt pentru obiecte aflate pe straturi diferite. În fiecare exemplu de mai jos corectăm nu doar termenul, ci și întrebarea pe care trebuie să o pui.

Fiecare card pornește de la o propoziție pe care o spune des cineva care învață. Citește-o, încearcă să vezi singur problema, apoi citește explicația.

13.1 Confuzii între model, artefact, runtime și agent

./src/lesson02_invoice_agent.py --input data/inbox/invoice_complete.json --trace-file logs/lesson02/complete.jsonl | jq '{status, actions_taken}'
{
  "status": "waiting_for_review",
  "actions_taken": [
    "calculate_totals",
    "prepare_review_package",
    "wait_for_human_review"
  ]
}

13.2 Confuzii de infrastructură și securitate

lspci | grep -i -E "vga|nvidia|3d"
00:02.0 VGA compatible controller: Intel Corporation Crystal Well Integrated Graphics Controller (rev 08)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X] (rev 83)

git log -p -- app.py | grep "API_KEY"
-API_KEY="sk-demo-1234"
+API_KEY="sk-demo-1234"

jq '{step, action: .selected_action, status: .status_after_action}' logs/lesson02/complete.jsonl
{
  "step": 1,
  "action": "calculate_totals",
  "status": "running"
}
{
  "step": 2,
  "action": "prepare_review_package",
  "status": "running"
}
{
  "step": 3,
  "action": "wait_for_human_review",
  "status": "waiting_for_review"
}

13.3 Confuzii de proiectare și alegerea produselor

grep -r -o '"customer": {[^}]*}' data/inbox/ | head -2
data/inbox/invoice_untrusted_totals.json:"customer": {"name": "Demo Client SRL", "tax_id": "RO87654321"}
data/inbox/invoice_approved.json:"customer": {"name": "Demo Client SRL", "tax_id": "RO87654321"}

14. Găsește greșeala — reclama „LocalGenius Pro face totul”

Exercițiul următor folosește același model ca în Lecțiile 1–2: citim o afirmație de marketing propoziție cu propoziție și verificăm ce strat este descris corect și unde sunt amestecate responsabilități.

15. De la hartă la proiectare: descrie stack-ul înainte să alegi produsele

Acum folosim harta pentru o sarcină practică: descriem ce are nevoie sistemul înainte de a decide ce produse cumpărăm sau instalăm. Este acceptabil ca unele răspunsuri să fie „nu este ales încă”.

Fișa de proiectare a stack-ului

Pentru un agent¹ pe care vrei să-l construiești, răspunde pe rând. Fiecare întrebare elimină alegeri nepotrivite mai târziu.

Șablonul de completat

Copiază șablonul într-un fișier text și completează fiecare câmp cu răspunsul tău din cardurile de mai sus.

SCOPUL SISTEMULUI
Cine îl folosește și ce rezultat concret trebuie să obțină?

VOLUMUL DE LUCRU
Text, imagini, audio, video, senzori, simulare sau combinație?

CLASIFICAREA DATELOR
Publice, interne, confidențiale, personale, reglementate, critice?

INTERFAȚA
CLI, web, chat, API, voce, job programat, eveniment de senzor?

CONTROLUL AGENTULUI
Ce pași sunt deterministici? Ce decizii pot folosi un model?

CERINȚELE MODELULUI
Local sau găzduit la distanță? Ce limbi? Ce context? Ce licență? Ce modalități?

INSTRUMENTE
Ce poate citi? Ce poate scrie? Ce poate executa?

STARE ȘI STOCARE
Ce se păstrează în timpul rulării? Ce rămâne după aceea?

SECURITATE
Identitate, permisiuni, secrete, rețea, sandbox, aprobări?

OBSERVABILITATE
Ce loguri, metrici, trace-uri, teste și evaluări sunt necesare?

DEPLOYMENT
Local, cloud, hibrid, edge, on-premise?

CAPACITATE
Câți utilizatori? Ce latență? Ce volum? Ce disponibilitate?

PLAN DE EȘEC
Ce se întâmplă dacă modelul, rețeaua, baza de date sau instrumentul nu răspunde?

DECIZII NEÎNCHEIATE
Ce alegere trebuie amânată până când avem dovezi?

16. Exerciții practice

lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Crystal Well Integrated Graphics Controller (rev 08)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X] (rev 83)

17. Quiz cu răspunsuri explicate

Întrebările verifică relațiile dintre straturi, nu memorarea numelor comerciale. Înainte să deschizi răspunsul, încearcă să formulezi o explicație completă: ce strat este implicat, ce responsabilitate are și cu ce nu trebuie confundat?

which python3
/usr/bin/python3
source .venv/bin/activate
which python3
/home/ana/ai-agents-zero-to-expert/.venv/bin/python3

18. Recapitulare

Dacă această lecție a funcționat, nu trebuie să memorezi paisprezece produse. Trebuie să poți reconstrui relația dintre responsabilități și să recunoști termenii noi când apar în documentație.

18.1 Harta într-o singură pagină

Vocabular esențial

Recitește definițiile după parcurgerea lecției — acum fiecare termen are context. Sunt grupate în patru familii: termenii moșteniți din Lecțiile 1–2, apoi cele trei familii noi ale lecției. Apasă pe numărul de lângă un termen ca să ajungi la explicația lui; butonul Înapoi al browserului te duce înapoi unde citeai.

Vocabular din Lecțiile 1–2

Hardware și sistem

Model și inferență

Operare și observabilitate

19. Referințe și aprofundare

Sursele de mai jos susțin definițiile și exemplele tehnice principale. Documentația produselor se schimbă; pentru instalări și compatibilitate folosește întotdeauna documentația curentă a versiunii pe care o instalezi.

• NVIDIA, CUDA Programming Guide — platforma și modelul de programare CUDA²³.
• AMD, What is ROCm? — runtime-uri¹⁰, compilatoare, biblioteci și instrumente⁵ din stack-ul ROCm²³.
• PyTorch, Get Started Locally — diferențierea platformelor de calcul CPU¹⁸/CUDA²³/ROCm și instalarea framework-ului.
• Ollama, API documentation — interfața de rulare/integrare a modelelor.
• vLLM, OpenAI-Compatible Server — servirea modelelor prin HTTP.
• Model Context Protocol, documentația MCP — clienți, servere și capabilități precum tools/resources/prompts.
• OpenTelemetry, Observability Primer — loguri, metrici³², traces și instrumentare.
• Docker, What is an image? și documentația despre containere³⁴ — împachetarea aplicațiilor și dependențelor.
• Krizhevsky, Sutskever, Hinton (2012), ImageNet Classification with Deep Convolutional Neural Networks — utilizarea GPU¹⁹ în antrenarea unei rețele profunde de referință.
• Linux Kernel²¹ Documentation, Introduction — context despre kernelul Linux și dezvoltarea sa.

20. Ce urmează

Lecția 3 a construit harta pe care o vom folosi pentru restul cursului. Acum poți vedea de ce nume precum Ollama, Hugging Face, LangGraph, MCP, CUDA²³ sau OpenShell nu pot fi comparate direct până când nu știm cărui strat îi aparțin și ce responsabilitate îndeplinesc.

Următoarea lecție — Product-name decoder — folosește această hartă pentru a plasa produse și proiecte concrete în straturile potrivite și pentru a corecta diagrame intenționat greșite. Scopul nu va fi să alegem un „câștigător”, ci să învățăm să citim numele comerciale fără să pierdem arhitectura din vedere.