Zaposleni CXMT-a: nakon doseljenja u Hefei zapošljavaju kao ludi, inženjeri sa platom preko dvadeset hiljada juana mesečno nailaze u masama, kirije u okolini skočile su za čak 50% (sa pitanjima o Agentu)

Naišao sam na jednu ovakvu priču, prilično zanimljivu.

Nakon što se CXMT doselio u Hefei, nekada zabačena četvrt se razbudila. U najžestocnijem trenutku zapošljavali su kao ludi — gomila inženjera sa platom od dvadeset i više hiljada juana navalila je unutra, pa su stanovi, naselja i tržni centri u okolini zajedno proleteli, a kirije skočile za čak 50%.

Može se zamisliti koliko su u eri AI-ja deficitarna dva resursa — računska snaga i AI talenti.

Kao domaći lider u DRAM-u (dinamičkoj memoriji sa proizvoljnim pristupom), CXMT se našao tačno na raskrsnici domaće rupe u ponudi, širenja kapaciteta i tehnološke nadogradnje, pa ga smatraju jednim od najvećih dobitnika zlatne staze AI memorije.

PS: DRAM je poluprovodnička memorija koja uglavnom služi za privremeno čuvanje programa i podataka koji se trenutno izvršavaju na računaru ili telefonu.

Istražio sam umesto vas — CXMT zaista poslednjih dana jako intenzivno regrutuje istraživačko-razvojne ljude iz pravca AI Agent-a, a pozicije su uglavnom koncentrisane u sedištu u Hefeju i u Šangaju.

CXMT sam po sebi ne pravi Agent-e, ali će širenje Agent-a na veliko indirektno povećati dve vrste potreba za memorijom.

Cloud Agent-i povlače DDR5 (sinhrona dinamička memorija pete generacije sa duplom brzinom prenosa podataka, trenutno najnovija generacija standarda glavne memorije kod glavnih računara i servera), a Agent-i na uređaju povlače LPDDR5X (unapređena verzija memorije pete generacije sa niskom potrošnjom i duplom brzinom prenosa, čip glavne memorije visokih performansi i ultra niske potrošnje, namenjen pametnim telefonima, tankim laptopima i mobilnim AI uređajima).

Lanci zadataka Agent-a su duži, kontekst veći, pozivi alata učestaliji, a konkurentnost veća. Težine modela uglavnom stoje u HBM-u (High Bandwidth Memory, memorija velike propusnosti), ali server i dalje traži velike količine DRAM-a za raspoređivanje i predobradu zahteva, radno stanje Agent-a, rezultate RAG pretrage, istovar KV Cache-a, keširanje podataka, konkurentne zadatke više Agent-a, baze podataka i servise alata.

Ako ste neko ko veruje u trud, veruje u proces, veruje u korak po korak i veruje da u eri AI-ja može da uzme svoj deo kolača, ovaj hardcore materijal sa intervjua nadam se da ćete pažljivo pročitati.

(Tekst je prilično opsežan, garantujem da ćete naučiti jako puno. Vežite sigurnosne pojaseve, krećemo.)

content

PaiCLI Agent o kome je reč u tekstu već je open source na GitHub-u, postoji i verzija u Go-u: https://github.com/itwanger/PaiCLI-Python

01. Kakva je veza između Memory-ja u Agent sistemu i DRAM-a u hardveru računara?

Stari Vang namesti naočare i prelista biografiju. „Da odmah krenem sa jednim osnovnim. Kakva je veza između Memory-ja u Agent sistemu i DRAM-a u hardveru računara?”

„DRAM je fizički medij za skladištenje — čita i piše po adresama, a kad nestane struje, podaci nestaju. Ne zanima ga sadržaj koji je uskladišten; samo upisuje na zadanu adresu i čita sa zadate adrese.”

„Agent Memory je softverski apstraktni sloj — pretraga po semantici, uz mogućnost trajnog upisivanja na disk ili u bazu. Njega zanima 'šta zapamtiti i kada se toga setiti'.”

„Kolika memorijska letvica stoji na matičnoj ploči, tolika je i veličina DRAM-a. Kapacitet Agent Memory-ja ograničava context window, ali činjenično pamćenje može da se smesti na disk i po potrebi povrati i ubaci u kontekst.”

02. Zašto KV Cache naglo zauzima VRAM i memoriju kad se kontekst velikog modela produži?

„KV Cache je centralni keš prilikom zaključavanja u Transformeru. Za svaki novi token model mora da pregleda Key i Value vektore svih prethodnih tokena da izračuna attention. Kad bi se svaki put računalo iznova, količina računanja rasla bi sa kvadratom dužine sekvence. KV Cache kešira već izračunate Key i Value vektore, pa novi token računa samo svoj Query i sa njim radi attention nad keširanim Key i Value.”

„Zauzeće je veliko jer zapremina KV Cache-a raste srazmerno dužini sekvence.”

„Konkretno, veličina KV Cache-a jednaka je: 2, puta broj slojeva modela, puta broj KV glava, puta dimenzija po glavi, puta dužina sekvence, puta batch size, i puta broj bajtova po elementu.”

„Uzmi model sa 70B parametara. Pretpostavi 80 slojeva, optimizaciju GQA (Grouped Query Attention, grupisani query attention), 8 KV glava, 128 dimenzija po glavi i 2 bajta po elementu u BF16 (poluprecizni floating point). KV Cache jednog tokena zauzima oko 320KB. Pri kontekstu od 4K to je oko 1.3GB, a na 128K odleti na oko 40GB — gotovo koliko same težine modela.”

„Ako se istovremeno opslužuje više korisnika, svaki ima svoj nezavisni KV Cache — pomnoži to još sa batch size-om. Zato u scenariju dugog konteksta i visoke konkurentnosti KV Cache postaje najveći potrošač VRAM-a i memorije.”

03. Kada je zaključavanje velikog modela usko grlo računske snage, a kada propusnosti memorije?

Stari Vang podigne šoljicu čaja i otpije gutljaj. „Nastavljajući na prethodno pitanje — usko grlo zaključavanja nije stalno isto. Kada se zapne na računskoj snazi, a kada na propusnosti?”

„Prva faza zove se Prefill — obrada celog prompta koji je korisnik uneo. U toj fazi svi tokeni paralelno računaju množenja matrica, gustina računanja je vrlo visoka, pa iskorišćenost računske snage GPU-a može da dostigne preko 90%. Usko grlo je računska snaga — brzinu te faze određuje sposobnost GPU-a za floating point računanje.”

„Druga faza zove se Decode — izlazni tokeni se generišu jedan po jedan. Za svaki generisani token ceo KV Cache mora da se pročita iz VRAM-a za računanje attention-a, a računanja se proizvede samo za jedan token. Računanja malo, prenošenja podataka mnogo — GPU najveći deo vremena čeka da podaci stignu iz VRAM-a. Tada je usko grlo propusnost memorije.”

„U jednoj rečenici: u Prefill fazi sporo se računa, u Decode fazi sporo se čita.”

04. Zašto konkurentno pokretanje više Agent-a lakše dovodi do OOM-a?

„Razlog je što svaki Agent ima svoj nezavisni memorijski trošak — N Agent-a u konkurentnosti znači N puta više.”

„Jedan Agent u radu održava bar tri skupa podataka: context window trenutnog razgovora, keš rezultata poziva alata i istorijske informacije povraćene iz baze pamćenja.”

„Problem kod više Agent-a u konkurentnosti je što se ti troškovi ne dele. Svaki Agent ima svoju istoriju razgovora, svoje rezultate poziva alata, svoje stanje zadatka. Makar je system prompt isti i keš se može deliti, dinamički generisani delovi se ne mogu ponovo iskoristiti.”

05. Kako slojevito organizovati radno, epizodičko i dugoročno pamćenje Agent-a?

Stari Vang spusti šoljicu i prelista poleđinu biografije. „Ispričaj svoje razumevanje slojeva pamćenja Agent-a. Radno, epizodičko, dugoročno — kako se dele?”

„Radno pamćenje odgovara trenutnom context window-u. Sadržaj trenutnog razgovora, system prompt, rezultati poziva alata — sve je tu.”

„Epizodičko pamćenje čuva logove ranijih interakcija. Na primer šta je prošle nedelje razgovarano sa korisnikom, koji su zadaci ranije izvršavani, šta je uspelo, a šta palo. Indeksira se po vremenu i scenariju, pa se po potrebi povrati i ubaci u radno pamćenje.”

„Semantičko pamćenje je zapravo baza znanja. Korisnički priručnici, dokumentacija proizvoda, znanje iz domena — iseče se na komade i napravi vektorski indeks. Pretraga je po semantičkoj sličnosti, za razliku od epizodičkog pamćenja koje se pretražuje po vremenu.”

„Proceduralno pamćenje čuva veštine i obrasce izvršavanja. Datoteke sa definicijama Skill-ova, šabloni workflow-a, uobičajene sekvence operacija — to je znanje 'kako se stvari rade', a ne 'šta se zna'.”

„PaiCLI za sada ima prva dva sloja: kratkotrajno pamćenje razgovora i dugoročno pamćenje činjenica. Činjenice se trajno upisuju u lokalne datoteke i dostupne su kroz sesije. Epizodičko i proceduralno pamćenje su zasad implicitni — istorija razgovora po prirodi sadrži ranije interakcije, a Skill datoteke po prirodi jesu proceduralno pamćenje.”

Zašto ne staviti celo pamćenje u context window?

„Dva razloga.”

„Prvo, context window ima gornju granicu.”

„Drugo, razređivanje pažnje. Što je kontekst kod Transformer-a duži, pažnja se po pojedinačnom tokenu više razliva. Kad se nagura previše nebitnih informacija, model lakše previdi ono stvarno važno. Poenta slojevitosti je da radno pamćenje zadrži samo informacije najpotrebnije trenutnom zadatku, a sve ostalo da se povlači po potrebi.”

06. Šta od Agent podataka odgovara Redis-u, vektorskoj bazi, relacionoj bazi i objektnom skladištu?

„Redis odgovara za stanje sesije i kratkotrajni keš. Trenutni ID sesije Agent-a, istorija poslednjih nekoliko krugova razgovora, privremeni rezultati poziva alata — ti podacima se često pristupa i kratko žive. Redis brzo čita i piše, a TTL (automatski istek) mehanizam sam čisti istekle podatke. Stanje sesije PaiCLI-ja stoji upravo u Redis-u, uz automatski istek od 7 dana.”

„Vektorska baza odgovara za semantičko pamćenje. Dokumenti baze znanja se iseku na komade, napravi im se vektorski indeks, pa se korisničko pitanje pretražuje po sličnosti. Ono što pretraga po ključnim rečima ne nađe, semantička pretraga nađe. PaiCLI koristi hibridnu pretragu u Elasticsearch-u — BM25 podudaranje ključnih reči i vektorska semantička pretraga rade paralelno, a rezultati se spajaju i rangiraju.”

„Relaciona baza odgovara za strukturirane biznis podatke. Informacije o korisnicima, zapisi izvršenih zadataka, audit logovi, rezultati evaluacije — ti podaci traže transakcije i složene upite. Audit log Agent-a je naročito važan — ko je u koje vreme pozvao koji alat, kakav je bio rezultat, da li je prošlo kroz ručno odobrenje — sve to mora biti sledljivo.”

„Objektno skladište odgovara za velike datoteke i dugoročnu arhivu. Dokumenti koje su korisnici otpremili, izveštaji koje je Agent generisao, sirovi logovi istorije razgovora — količina podataka je velika, ali se retko pristupa. Objektno skladište ima veliki kapacitet i nisku cenu, pa odgovara za slaganje hladnih podataka na disk.”

07. Kako dizajnirati kompresiju konteksta da duži rad Agent-a ne znači i veću potrošnju Token-a?

Stari Vang baci pogled na sat, a prsten na domalom prstu bljesnu. „Upravljanje kontekstom je pitanje koje se pri inženjerstvu Agent-a ne može zaobići. Ispričajte kako vi radite kompresiju.”

„Ideja je — ono blisko se čuva celo, ono daleko se sažima.”

„Poslednjih N krugova razgovora ostaju netaknuti, ni slovo se ne dira. PaiCLI podrazumevano čuva poslednja 3 kruga. Jer ono što je korisnik nedavno rekao najverovatnije je direktno vezano za trenutni zadatak, a kompresija bi izgubila ključne informacije.”

„Starije poruke ispred njih idu u Map-Reduce sažetak. Svakih 5 poruka čini grupu, za svaku grupu LLM generiše po jedan sažetak, pa se svi sažeci spajaju u jedan zbirni. Zbirni sažetak plus originalna tri poslednja kruga zamenjuju nekadašnju kompletnu istoriju.”

„Okida se kada zauzeće tokena dostigne oko 70% budžeta. Ne sme se čekati da se skoro napuni, jer kompresija sama poziva LLM za sažimanje i troši i tokene i vreme. Sa rezervom se sve sredi mirno.”

„Jedan detalj pri sažimanju je vrlo važan: razlikovati privremene informacije i stabilne činjenice. Privremeni zahtev poput 'korisnik mi je rekao da napišem funkciju za sortiranje' posle kompresije može da se odbaci. Ali stabilne činjenice poput 'putanja projekta je /Users/xxx/project' ili 'korisnik preferira TypeScript' moraju ostati. Modul za kompresiju u PaiCLI-ju pravi tu razliku — privremeno se filtrira, a stabilno se izdvaja i smešta u dugoročno pamćenje.”

Zašto ne prosto odseći stare poruke?

„Odsecanje je najjednostavnije rešenje, ali lako gubi informacije.”

„Zamisli da je Agent u 3. krugu sa korisnikom potvrdio važnu odluku u dizajnu, a da se u 20. krugu ta poruka odsekla. Agent je zaboravio odluku. Sažetak bar zadrži semantiku ključne informacije — detalji se zamute, ali osnovni zaključak ostaje.”

„Naravno, ako poziv LLM-a za sažetak padne, PaiCLI se degradira na obično odsecanje.”

08. Koje probleme rešavaju kvantizacija, paginacija i istovar KV Cache-a?

„Kvantizacija rešava problem 'jedan KV je prevelik'. Spuštanjem KV Cache-a sa BF16 na INT8 svaki element pada sa 2 bajta na 1, pa se zauzeće VRAM-a prepolovi. INT8 kvantizacija je skoro bez gubitka, uticaj na kvalitet generisanja je mali. Spuštanjem na INT4 može se opet prepoloviti, ali gubitak preciznosti postaje primetan — odgovara scenarijima sa nižim zahtevima za kvalitet.”

„Paginacija rešava problem fragmentacije memorije. Tradicionalno se za svaku sekvencu unapred alocira jedan neprekidni blok VRAM-a za KV Cache, ali se dužina sekvence unapred ne zna — alociraš previše, rasipa se; premalo, ne staje. PagedAttention u vLLM-u seče KV Cache na stranice fiksne veličine i alocira ih po potrebi, bez zahteva za neprekidnim skladištenjem — kao virtuelna memorija sa paginacijom u operativnom sistemu. Prednost je što više sekvenci može deliti stranice sa istim prefiksom, pa se na primer deo sa system promptom čuva samo jednom.”

„Istovar (offloading) rešava problem 'ne staje u VRAM'. KV Cache koji trenutno ne treba prebaci se na SSD, pa se vrati kad zatreba. Suštinski se kapacitet kupuje latencijom — odgovara offline zadacima sa izuzetno dugim kontekstom.”

09. Kako dugotrajni Agent postiže trajnost stanja i oporavak od prekida?

„Preko mehanizma snapshot-a.”

„Ideja je po jedan snapshot pre i posle svakog kruga izvršavanja. Pre-turn snapshot čuva trenutno stanje pre poziva LLM-a, a post-turn snapshot se asinhrono čuva po završetku kruga.”

„Snapshot čuva kompletno radno stanje Agent-a: istoriju razgovora, sadržaj pamćenja, napredak zadatka, rezultate poziva alata, do kog je koraka stigao. Tek sve to zajedno može potpuno rekonstruisati stanje Agent-a pre prekida.”

„PaiCLI koristi lokalni sistem datoteka — u direktorijumu projekta postoji namenski direktorijum za snapshot-e. Može i baza podataka, zavisi od okruženja deployment-a.”

„Pri oporavku se nađe poslednji kompletan post-turn snapshot, učita se, preskoče završeni koraci i nastavi se od sledećeg zakazanog koraka. Ako je Agent pao usred upisa post-turn snapshot-a tog kruga, vraća se na pre-turn snapshot i taj krug se izvršava ponovo.”

Zašto se ne koriste transakcije baze za doslednost?

„Transakcija baze pokriva atomičnost jednog ili više redova podataka. Ali stanje Agent-a se proteže kroz istoriju razgovora, skladište pamćenja, napredak zadatka i rezultate poziva alata, koji mogu biti razasuti po različitim skladištima. Distribuirana transakcija preko više skladišta je preskupa; snapshot radi potpuno čuvanje i pri oporavku potpuno učitavanje, što je na kraju jednostavnije i pouzdanije.”

10. Ako Agent-u naglo poraste latencija, koje indikatore od Token-a, VRAM-a, memorije i poziva alata pratiti?

Stari Vang vrati biografiju na prednju stranu i doda je. „Poslednje pitanje, više iz praktičnog održavanja. Agent je odjednom usporio — kako istražuješ?”

„Gleda se kroz četiri dimenzije.”

„U dimenziji Token-a prvo se proveri broj ulaznih tokena. Ako je ulaznih tokena u poslednjim krugovima naglo poraslo, kontekst se naduva — možda kompresija nije okinuta, a možda je neki poziv alata vratio gomilu podataka bez odsecanja. Zatim se proveri stopa pogodaka Prompt Cache-a; pad stope znači da svaki zahtev ponovo računa ceo kontekst, pa latencija i trošak rastu istovremeno.”

„U dimenziji VRAM-a i memorije gledaju se zauzeće KV Cache-a i dubina batch reda. Kad zauzeće KV Cache-a priđe gornjoj granici VRAM-a, novi zahtevi mogu samo da čekaju u redu da se stari oslobode, pa latencija prirodno raste. Što se memorije tiče, gleda se rezidentni memorijski otisak procesa — ako stalno raste i ne pada, moguće je curenje memorije ili kontekst nekog Agent-a koji se stalno naduvava bez kompresije.”

„U dimenziji poziva alata prate se tri indikatora: trajanje pojedinačnog poziva, ima li timeout retry-a i da li je učestalost poziva neobično porasla. Audit log PaiCLI-ja beleži ime, parametre, trajanje i status rezultata svakog poziva alata, pa se iz loga jednim pogledom vidi koji je alat usporio celinu.”

„U sistemskoj dimenziji gledaju se iskorišćenost GPU-a i mrežna latencija. Iskorišćenost na maksimumu znači da računske snage ponestaje; niska iskorišćenost uz visoku latenciju znači da usko grlo nije u računanju, nego u prenosu podataka ili čekanju u redu. Ako Agent poziva spoljne API-je, i kolebanje mrežne latencije zaslužuje pažnju.”

Kako upisati PaiCLI u biografiju?

Naziv projekta: PaiCLI — komandna alatka, terminalni AI Agent

Kratak opis: terminalni Agent u Javi, po uzoru na Claude Code; podržava tri režima izvršavanja — ReAct, Plan-and-Execute i Multi-Agent Team — a poseduje višekružne razgovore, pretragu koda, pozive alata, kompresiju konteksta i oporavak stanja i druge sposobnosti.

Tehnološki stek: Java 21 + Spring AI + Redis + Elasticsearch + MCP protokol

Ključne odgovornosti:

• dizajnirao i implementirao dvoslojnu arhitekturu pamćenja Agent-a: kratkotrajno pamćenje čuva kontekst trenutne sesije i dinamički se obrezuje po budžetu tokena, a dugoročno pamćenje se trajno upisuje u lokalne datoteke i pretražuje po težini vremenskog opadanja i semantičke povezanosti, pa se korisničke preferencije i informacije o projektu koriste kroz sesije
• implementirao Map-Reduce mehanizam kompresije konteksta: čuva se poslednja 3 potpuna kruga razgovora, starije poruke se sažimaju u grupama po 5 i spajaju, prag okidanja je na 70% budžeta tokena, a uz izdvajanje činjenica se filtriraju privremeni zahtevi i zadržavaju stabilne informacije, što omogućava dugotrajan rad Agent-a
• izgradio pre-turn/post-turn snapshot sistem koji čuva kompletno radno stanje Agent-a pre i posle poziva LLM-a u svakom krugu (istoriju razgovora, pamćenje, napredak zadatka, rezultate poziva alata), podržava nastavak izvršavanja iz poslednjeg validnog snapshot-a i omogućava automatsko vraćanje nakon greške
• dizajnirao strategiju izolacije resursa u Multi-Agent Team režimu: svaki Worker održava sopstvenu istoriju razgovora i skup alata, a gornja granica konkurentnosti (podrazumevano 2 Workera) sprečava da se memorija više Agent-a sabere u OOM
• postavio strukturirani sistem audit logova koji beleži ime, parametre, trajanje, status odobrenja i rezultat izvršavanja svakog poziva alata, uz automatsko maskiranje osetljivih informacija poput API Key-a i Token-a, što podržava istraživanje latencije i bezbednosni audit

Kraj

Nekad su se na intervjuima pričale napamet naučene lekcije, konkurentnost, middleware. Sad se priča kako optimizovati KV Cache, kako slojevito organizovati pamćenje Agent-a, kako komprimovati kontekst koji se naduo.

Struktura znanja se menja, ali jezgro inženjerske sposobnosti ostaje isto — ko ume da sistem učini stabilnim, problem razmisli do kraja i rešenje pretoči u kod, taj je deficitaran.

Napred, prijatelji.

Vidimo se u sledećem.