Local Qwen - pipeline nocturn $0 cu LLM local

Problema și motivația

Lucrând zi de zi cu modele lingvistice mari, am observat o categorie întreagă de muncă utilă, dar prea costisitoare ca să o fac manual și prea repetitivă ca să merite tokeni plătiți: să verific dacă regulile dintr-un proiect mai au sens, să curăț note de memorie prea lungi, să extrag lecțiile durabile din transcriptele unei zile de lucru, să scanez surse pentru idei, să caut cod mort sau referințe care nu mai există. Fiecare task în parte este mic. Împreună, ar consuma ore și un buget real de API dacă le-aș rula pe modele de tip cloud plătite.

Soluția a fost să mut toată această muncă auxiliară pe un model local care rulează gratuit peste noapte, când nici eu, nici GPU-ul nu suntem ocupați. Hardware-ul este un singur sistem AMD Ryzen AI Max+ 395 cu 128 GB de memorie unificată; modelul ocupă în jur de 20 GB pe GPU. Pentru că inferența este locală, costul marginal al unei nopți de procesare este, practic, zero. Asta schimbă complet calculul: când o operațiune nu costă nimic, merită să o rulezi în fiecare noapte, chiar dacă produce valoare doar o dată din zece.

Arhitectura: cum funcționează

Inima sistemului este un orchestrator de tip cron care parcurge un DAG de 42 de job-uri, definit ca o listă ordonată (_JOB_ORDER) plus un registru de funcții (_JOB_MAP). Ordinea contează: rularea începe cu un job de auto-verificare a infrastructurii și a lanțurilor de inferență, apoi trece prin igienă de memorie și reguli, extragere de lecții, scanare de surse, deep-read, dosare REPA pe articole, generare de idei, audituri de cod și specificații, sinteze de optimizare și, la final, digestul de dimineață, verificarea și consolidarea rapoartelor.

Pornirea are două căi. Prima este un task în Windows Task Scheduler care se declanșează la ora 03:00 indiferent dacă sesiunea mea de lucru este deschisă; runner-ul așteaptă ca sistemul să fie inactiv înainte să înceapă. A doua este un hook pe evenimentul de trimitere a unui mesaj: când scriu "going to sleep", "off to bed" sau "goodnight", hook-ul pornește runner-ul manual. Modelul nu este lansat automat de runner; LM Studio îl ține rezident la adresa 127.0.0.1:1234, expunând atât API-ul compatibil OpenAI, cât și endpoint-ul nativ Anthropic.

Fiecare job își scrie rezultatul ca fișier Markdown datat în REPORTS/qwen_nightly/. Un generator separat compilează toate aceste rapoarte într-un singur dashboard HTML cu file, servit la un URL fix și reîmprospătat automat la fiecare 300 de secunde. Dashboard-ul are o filă per job, fiecare cu badge-uri de prospețime (verde pentru azi, portocaliu cu numărul de zile pentru conținut vechi), astfel încât un raport vechi nu este niciodată prezentat ca fiind curent.

Modelul și deciziile tehnice cheie

Modelul ales este Qwen3.6-35B-A3B, o arhitectură de tip mixture-of-experts, în cuantizarea IQ4_XS. Alegerea a venit dintr-un harness de benchmark propriu, care a comparat mai multe variante de cuantizare pe viteză, consum de memorie și calitatea raționamentului; IQ4_XS a câștigat cu un echilibru bun între cei trei factori și un context generos de tokeni, suficient pentru a digera transcripte întregi de sesiune. Pentru că hardware-ul are un singur GPU, o regulă fermă interzice încărcarea unui al doilea model lingvistic în paralel; singura excepție este modelul de embedding bge-m3, care trebuie să rămână rezident pentru că alimentează un daemon vectorial separat.

O decizie de proiectare importantă a fost ca local Qwen să fie strict un job de noapte. În timpul zilei, clasele de task uri auxiliare (rezumate, deduplicare, extragere de câmpuri, primele schițe) sunt rutate către lane-uri gratuite de tip cloud, ca NVIDIA NIM, cloud-Qwen sau OpenRouter, pentru a nu bloca GPU-ul când am nevoie de el. Modelul local intervine doar prin job-ul de noapte, care îl folosește exact când nimic altceva nu rulează.

Detalii de inginerie notabile

Cea mai instructivă problemă tehnică a fost o trunchiere subtilă. La început, job-ul de rescriere a memoriei producea doar 4 din 20 de rezultate corecte; restul erau cioturi de 7 caractere. Cauza, descoperită printr-o investigație scurtă, a fost că serverul de inferență nu separa blocul de raționament think într-un câmp dedicat, ci îl îngrămădea în conținutul răspunsului. Sub limita de tokeni, raționamentul de la început supraviețuia, dar răspunsul propriu-zis, aflat la final, era tăiat. Soluția a avut două părți: clientul curăță blocurile think din conținut înainte de a calcula răspunsul, tratând un think deschis fără închidere ca răspuns gol (un eșec onest, nu gunoi), iar prompturile de sistem ale job-urilor care cer ieșire scurtă includ instrucțiunea explicită de a nu emite deloc taguri think. Directiva /no_think nu funcționa pe această combinație de model și server; instrucțiunea explicită a fost singura supresie fiabilă.

Anti-fragilitatea este construită în mai multe straturi. Un watchdog de tip kill-on-resume monitorizează activitatea sesiunii mele: dacă reîncep să lucrez peste noapte, watchdog-ul oprește procesarea și eliberează GPU-ul în aproximativ 30 de secunde, plus impune un buget maxim de timp pe rulare. Un lock cooperativ pe GPU serializează accesul la singura placă, respectând regula de a nu rula două modele simultan. Un cache de deduplicare pe URL-uri, persistent între nopți, evită re-procesarea acelorași surse. Filozofia de execuție este ca o eroare într-un job să nu oprească rularea: job-urile ulterioare continuă, iar un consumator de tip barieră așteaptă doar producătorii care chiar au rulat.

Pentru a dovedi că sistemul chiar funcționează, am scris un verificator separat cu trei semnale live: dacă modelul este rezident, dacă ultima rulare s-a încheiat cu starea complete (nu cu eșec la lansare) și cât de proaspătă este cea mai recentă ieșire. Verdictul este WORKING doar dacă ultima rulare a fost completă și ieșirea este recentă. Acest verificator a apărut tocmai pentru că, la un moment dat, lansarea modelului eșua la fiecare iterație din cauza unui parametru greșit de evicție, în timp ce semnalele superficiale păreau în regulă. Pe lângă el, un job de noapte de tip verifier folosește un lane gratuit de tip cloud pentru a revizui rapoartele înainte de digest, un job de telemetrie urmărește tendințele de durată și erori între nopți, iar un job dedicat verifică prospețimea backup-urilor și prezența fișierelor critice.

Costul și optimizările

Inferența locală este gratuită; singurele costuri posibile sunt apelurile auxiliare opționale, cum ar fi o pre-scanare plătită care se declanșează doar în prezența unui fișier explicit de aprobare. Asta menține costul unei nopți între 0,05 și 0,15 dolari. Pe lângă bani, sistemul își optimizează și propria muncă: un scheduler opțional de DAG poate paraleliza job-urile care nu au nevoie de GPU, după ce fiecare job a fost clasificat ca fiind dependent sau independent de GPU. Mai multe job-uri sunt dedicate chiar îmbunătățirii continue: un audit determinist de optimizare, o sinteză LLM peste rezultatele lui, un swarm de optimizare pe mai mulți agenți gratuiți și un audit rotativ de reguli care dă mereu de lucru nou modelului local.

Rezultatul și starea curentă

De la prima rulare reală, sistemul a generat peste 4.200 de rapoarte advisory, cu fișiere datate care merg de la sfârșitul lui mai până la mijlocul lui iunie 2026. Codul s-a maturizat dintr un set inițial de 5 job-uri la un DAG de 42, susținut de zeci de scripturi specializate. Principiul fundamental a rămas neschimbat de la început: totul este strict consultativ. Niciun job nu scrie peste fișierele de memorie, reguli sau cod fără aprobare umană; rezultatele ajung într-un dashboard, iar eu decid ce merită aplicat. Local Qwen este, în esență, un coleg de noapte care lucrează gratuit, nu obosește niciodată și nu apasă niciodată singur butonul de publicare.