Otabek’s I/O

#startup

"Hozir startupda nimalar qilayabman?" eng ko'p so'ralgan savollardan.

Dropbox'da ishlab yurgan paytlarim kichik experiment qilgandik. Mendagi savol quyidagicha:

Nimaga biz kichik, efficient va biror tor yo'nalishdagi modellarni ko'paytirib, ularni CPU da yuritishni o'rniga, general modellarni bilimini (weight) kengaytirib ularni ko'p train qilib, hozirda qimmat bo'layotgan GPU larda yuritishimiz kerak?

GPU va CPU o'rtasida ba'zi katta farqlar bor, ammo bu degani modellarni CPU da yaxshi va effektiv yurita olmaymiz degani emas. CPU dagi eng katta ustunlik bu xotirada. Ya'ni siz 256GB RAM istasangiz undan kattaroq qilib ishlatsangiz bo'ladi ammo bu GPUda bu limit 80GB (H100).

CPU va RAM o'rtasida gaplashish tezligi ~60-100 GB/s, GPU esa ~1000-2200 GB/s ga teng. Modellar ma'lumotlar va juda ko'p compute (xisob-kitob) dan iborat. Shuning uchun ham hozircha buni yaxshiroq algoritmlari topilmagan. Ammo bu degan bunday algoritmlar topilmaydi degani emas.

Qiyin muammo ustida ishlayabman, ammo har kuni nimadir o'rgatadigan muammo ustida ishlayabman.

Sizga sovg'am bor.

Bugun yakshanba, dam olish kuni. Algoritmlar bo'yicha bir paytlar o'tgan jonli darslarimni sizga o'rganishga bermoqchiman. Yana bunday darslarni o'tish uchun vaqt va sharoit topilishi bilan bularni yanada yaxshiroq qilishga harakat qilamiz.

1. Algoritmlarga kirish
2. Diskret Matematika
3. Array & Strings
4. Recursion
5. Stack & Queue
6. Graph
7. Tree
8. Deque
9. Linked List
10. Sorting
11. Hash Table
12. Searching
12. Sorting 2-qism
13. Dynamic Programming
14. Greedy Algorithms

Darslar yoqgan bo'lsa va fikringiz bo'lsa bemalol donat qilishingiz va fikringizni qoldirishingiz mumkin.

Next token prediction (LLM) is not intelligence.

Prove me I am wrong.

Dropbye!

Bugun mana salgina kam bo'lib qolgan sarguzashtga yakun yasayadik. Corporate job bilan hayrlashib, startup olamiga to'liq qadam qo'yayabman.

Oldinda nima kutib turibdi aniq bilmayman, lekin limitlarimni sinab ko'rmoqchiman. Ha aytgancha, Big Tech offer'lar 9-oy valid, B plan ham bor, lekin bunga muhtoj bo'lmaymiz deb umid qilamiz. Let's build something great together!!!

Goodbye Dropbox. It's been a pleasure journey with you.

Dropbox dan o'rgangan eng muhim 2ta narsam haqida

Computer Networking
Istalgan kompaniya katta trafik bilan ishlashni boshlaganda bu mavzu haqida ko'proq o'rganadi. Bir hamkasbim boomerang-hire bo'ldi, kecha gaplashib qoldik. U borgan startup kompaniya AI uchun infrastruktura qilar ekan va ko'p AI coding qilishar ekan. Eng yomon tomoni hech kim efficiency haqida o'ylamaydi, duch kelgan narsani yozib yuboraveradi deydi. Tushuntirishga harakat qildim nega buncha ko'p tizimda kamchiliklar va outage bo'lishini, lekin quloq solmadi deydi. AI tez kod yozib beradi, jarayonni tushunadigan dasturchilar endi ko'proq qadirlanishini isboti. Networking'ga keladigan bo'lsa, AI uchun klusterlarni va GPU larni bir-biri bilan samarali gaplashishi uchun tarmoqni tizim dizayn qilishadi va barcha keyslarga solib test qilib ko'rishadi (simulyatsiya). Keyin eng yaxshisini olib ishlatishadi. Internet networking siz mavjud bo'lmasdi, bundan buyog'iga ham Network injenerlarga talab kuchayib boraveradi (hardware va software da ham).

Communication
Senior bo'lib ishlab yurgan paytlarimda menejerim menga ko'proq Staff engineer bilan ishlashni, unga yaqinroq bo'lishni maslahat bergandi. Shu maslahatiga quloq solib Staff bo'ldim. Chunki undan ko'p bilmlar o'rgandim. 1:1 meeting qilsak ham hech qachon berilgan mavzudamas, boshqa mavzular to'g'risida ko'proq gaplashardik. Shundan keyin har bir system design qilinishi, research qilinishi kerak bo'lgan joylarda birga ishlashni boshladik. Uni kompaniyadagi 7 yillik tajribasini bir qismi menda bo'lgani uchun ham meni promote qilishdi. Ha undan hamma ko'proq ma'lumot olib qolishga harakat qilishdi, ammo ketishiga oz qolganda. Menda bu narsa ancha erta boshlangandi. Staff bo'lganimdan keyin kod yozishdan ko'ra ko'proq boshqa jamoalar bilan ishlash, o'z jamoamga ko'proq o'rgatish va ulardan ham fikrlar olib ular bilan birga o'sishni o'rgandim. Qisqasi yaxshiroq va ko'proq komunikatsiya qilishni o'rgandim.

Eng kattalari shular bo'ldi, qolganlari IaC, Distributed Systems, Platform Engineering, AI/ML va Data Center lar haqida bo'lgan.

Elon aka bergan ish taklifiga rad javobim qattiq ta’sir qilibdi, tweet yozibdi.

O’zi yozsa o’ylab ko’raman )

Alright, hey @grok cancel all meetings. I am building startup. Founder mode is on.

"Nima pozitsiya?" savoliga javob: Bilmayman, menga "Member of Technical Staff @ x.ai" deyishdi.

Sizga hech kim aytmagan sirni aytaman

Gigant kompaniyalarda sizga birinchi o’t yoqib, keyin o’chirishga ruxsat bor. Ammo hamma ishga kirganlar buni qilib bo’lmaydi deb, qandaydir yozilmagan qoidalarga amal qilishga harakat qilishadi )

LLM vs RLM

LLM qurish biz o‘ylaganchalik qiyin ish emas ekan. Uni mashq qildirish, unga sifatli ma’lumotlar topish, deploy qilish, monitoring qilish va h.k.z.lar qilish qiyin. Yaqinda Attention mexanizmi haqida yozgandim. Aynan o‘sha mexanizm kontekstni (context) boshqaradi. Kontekstni tushunish uchun u doim ortga qarab yuradi. Ya’ni model chapdan-o‘ngga qarab shunchaki o‘qib ketmaydi, balki ushbu gapdagi qaysi so‘z menga bu so‘zni yaxshiroq tushunishimga yordam beradi degan savol bilan yurish qiladi va so'zlar bilan aloqa xaritasi yasaydi, uni GPU'dagi VRAM (Video RAM)da KV Cache ga saqlaydi .

Nima uchun modellarda 128k - 256k ba’zan 1M context limit bor? Sababi oddiy matematika, Quadratic Complexity. Huddi tepada aytganimdek, agar ba’zimda 5 ta odam bo‘lsa, ular bir-birlari bilan oson gaplasha olishadi. Agar 100 ta odam bo‘lsa 100 000 ta kombinatsiya, 1 000 000 odam bo‘lsa ehheeeee. Undan tashqari VRAM buncha katta ma’lumotlar saqlashi qiyinlashib boradi.

LLM lar uchun har bir token (so‘z) boshqa token’larga qarashi kerak context da qolishi uchun. Matn hajmi ikki baravar oshsa, hisoblash (computational work) ishi ikki baravar emas, to‘rt baravar oshadi, insane.

Bu muammoni yechish uchun kodlarni indekslash kabi yechimlar chiqgan. Ammo ularni biznesi uzoqqa bormaydi deb o‘ylayman. Shaxsan o‘zim ishda RLM ya’ni Recursive Language Model qurish jarayonida qatnashib ko‘rdim. Large Language Modellardan farqi shundaki, u rekursiv o‘zini-o‘zi chaqira oladi, ammo nega? Context muammosini yechish uchun. Decomposer mexanizmi ya'ni LLM ortidagi "Divide-and-conquer" algoritmi.

LLM:
• katta prompt bersangiz, prompt o‘rtasiga yetganda boshini unutib qo‘yishi mumkin
• prompt dagi barcha narsaga diqqat (attention) qilmoqchi bo‘ladi
• Internal weight ga asoslanib ishlaydi (trainingdagi ma’lumotlar bilan)

RLM:
• Faqat kichik va kerakli parchaga (snippet) diqqat qiladi. Keyingi bo‘lakga o‘tish uchun recursion ishlatadi.
• Controller mexanizmi orqali katta topshiriqni kichik bo‘laklarga bo‘lib kerak paytda o‘zini-o‘zi chaqira oladi kerakli parcha bilan. 
• 1M matn uchun "filter" yozib kerakli qismini o‘qiy oladi.

RLM bilan 10M context gacha bemalol chiqsa bo‘lar ekan. To‘liq test qilib production da yuritib ko‘rilmagan, ammo eksperiment sifatida qilingan ishni bo‘lishdim. Bu kompaniya siri emas, ochiq manba. Sirli tomonlar hozircha "miyada" 😅

#experience

Dropbox Dash jamoasi bilan 4 oy ishladim (Tour of Duty). Va RAG haqida va uni katta masshtabda yuritish (running at scale) haqida juda ko'p o'rgandim.

Agar RAG qurayotgan bo'lsangiz va write/read amallari soni juda ko'p bo'lsa siz qurayotgan RAG katta ehtimollik bilan kengaya olmaydi va juda ko'p alaqsiraydi (hallucination). Vector database kichik bo'lsa kNN qidiruvi ishlashi mumkin. Agar ma'lumot bo'laklar hajmi 80k-100k dan oshsa juda katta kechikish (latency) sodir bo'ladi. Sababi so'rov (query) va har bir vector o'rtasidagi masofani xisoblash qimmatlashib va og'irlashib ketadi.

Buni qanday yechish mumkin? kNN o'rniga ANN algoritmlaridan foydalanish kerak, misol uchun HNSW (Hierarchical navigable small world) indekslari. Eng katta trade off, 100% to'g'ri ma'lumot emas, balkim 99.5% - 99.9% foiz aniqlikda ma'lumotlarni topa olasiz. Xisoblash (Computing) hali ham qimmat xisoblanadi garchi ba'zilar buni hozir amal qilmaydigan ta'rif deyishsada. Agar ana katta kompaniyalar aytishayabdi desangiz, Cloud narxi nega tushmayabdi? Xullas tushundingiz menimcha.

PDF kabi xujjatlarni qanday qilib saqlaydi va ulardan qanday ma'lumot qidiradi deysizmi? Bu yerda ham shunday trade off qilinadi. Vector Quantization ya'ni rasmlarni sifatini tushurish degani, compression. High-precision floating point raqamlar saqlashdan ko'ra, ularni round qilib saqlaysiz simple cluster'larga.

Ba'zan alaqsirashga (hallucination) sabab "The Context Window Paradox" bo'ladi va uni "Lost in the Middle" muammosi deb ataymiz. Ya'ni "promptda ko'proq ma'lumot bersang, yaxshiroq natija olasan" degan gaplar noto'g'ri. Buni ko'pincha Attention modellar qanday ishlashini bilmaydiganlar aytadi. Chunki bu model diqqatini (attention) buzadi. Ya'ni prompt o'rtasiga borib model ma'lumotni yo'qotadi. Buning uchun "Re-ranking layer" yechimlari mavjud. Xullas LLMga berishdan oldin, vector db dan olingan ma'lumot bo'laklarni (chunk) cross-encoder'ga berasiz va re-rank qilingan top 3-5 tasini yuborasiz LLMga.

Bizda ham RAG qurayotganlar ko'payabdi, balkim foydasi tegar : )

50ta tizim dizayn intervyularidan o'rganganlarim shu bo'ldi

Tizim dizayni intervyularidan o'rganganlarim, xatolarim va ularni yaxshilash haqida yozdim. Big Tech'ni crack qilishni istaganlar uchun maxsus.

Batafsil

#5MinuteTopic

Platform vs DevOps Engineer

O‘tgan galgi streamda Platform Engineer vs DevOps Engineer nima farqi bor deb so‘rashgandi. Keyinroq shuni o‘zimga yozishni va ko‘rishganda so‘rashni boshlashdi. Bu yerda bu ikkisini farqi haqida gaplashamiz. Infrastruktura tomonda ishlaganim uchun bu haqda o‘rganishga va amaliy sinab ko‘rishga muvaffaq bo‘la oldim. 

DevOps Engineer bu to‘liq texnik emas balkim qaysidir darajada madaniyatni ham tatbiq etuvchi rol hisoblanadi. Siz developer’lar va operations team’ni bog‘lovchi inson bo‘lishingiz kerak. Texnik tomondan to‘g‘ri siz CI/CD (continuous delivery / continuous deployment), Kubernetes, Jenkins, Git, Networking, Security va Cloud yechimlar haqida bilishingiz kerak bo‘ladi. Bu sizda mijozlarga dasturchilar qurgan dasturni to‘g‘ri yetkazib berishdek mas’uliyatni shakllantiradi. Ammo, tasavvur qiling qaysidir dasturchi yoki jamoa biror yangi loyiha qilsa va DevOps jamoasi band bo‘lsa butun process to‘xtab qoladi degani. Bu muammoni yechish uchun esa Platform Engineer sohasi shakllangan.

Platform Engineer bu IDP (Internal Developer Platform) quruvchi injener hisoblanadi. Endi siz DevOps engineer bo‘shashini kutmaysiz, chunki siz uchun platforma qurilgan. Siz bir nechta tugmalarni bosish va dokumentatsiyada ko‘rsatilgandek qoida yozishni o‘rganish orqali o‘zingiz bemalol operate (harakat) qila olasiz degani. Ya’ni dasturchilar uchun o‘ziga-o‘zi xizmat ko‘rsatuvchi platforma degani bu, ajoyib-a? Endi jamoada hamma Terraform, AWS, K8S ni bilishi shart emas. Ular platformaga kiradi va qoida yozishni o‘rganib shunchaki o‘zlariga-o‘zlari xizmat ko‘rsata olishadi. 

DevOps uchun mijozlar bu haqiqiy mijozlardir. Platform Engineer uchun mijozlar bu dasturchilardir. Siz "I will write a Jenkins pipeline for the team" dan "I will build a template in the IDP so any team can spin up a secure pipeline in 3 clicks without asking me" ga o‘tasiz.

Biz SRE haqida gaplashmadik, bu umumman alohida mavzu.

Serverlarga xakkerlar xujum qiladi.

Menga esa mushugim Mimi 🐈

Express Networking 3 modul, "Serverga xujum qilamiz" darsini yozish jarayonidan lavha

Senior dasturchi bo’lish uchun yo’l xaritasi tuzdik:

🔗 youtube.com/@otabekswe

Build your first model postidan keyin AI/ML o’rganish bo’yicha savollar va maslahat so'rashlar yanada ko'paydi. Hozir trendda bo'lgani uchun bo'lsa kerak. Qisqacha tajribam haqida aytib beray.

2-yil oldin o’sha ilmiy ishni (research paper) o’qib hech narsa tushunmagandim. Bu ilmiy ish haqida Andrej Karpathy juda zo’r video darslik chiqargan. Yaqinda (o’tgan yili) amaliy tarzda, videolarga qaramasdan kichik progress qila oldim.

Generative Pre-trained Transformers (GPT) qurishni va transformer’lar hozirgi LLMlarni kengaya olishidagi o’rnini, attention mexanizmi haqida ko’plab o’rganasiz.

Bundan oldin Recurrent Neural Network (RNN) va LSTM degan modellardan foydalanishgan. Muammo, ular juda sekin, kengayishga qiyin va unutuvchan bo’lgan. Model promptni so’zma-so’z o'qiydigan bo'lgan, agar gap uzun bo’lsa gapni boshini unutib qo’yardi.

Transformer’lar esa bunga ajoyib yechim berishadi. Ular so’zma-so’z o’qish o’rniga butun gapni bittada o’qiydi. Va Self-Attention mexanizmi orqali gapdagi so’zlar bir-biriga qanday bog’liqligi borligini xisoblab ko’radi.

Misol uchun “I didn't eat the food on the table because it wasn’t delicious” gapidagi “it” nimani bildirayotganini bilishingiz kerak. Bu yerda u ovqatga "food"ga nisbatan kelayabdi, "table" so'ziga emas.

Xullas bu model tezroq LLMlarni train qilishga va kengaya olishiga sababchi bo’lgan. Xullas qisqasi transformer gapni “Attention” mexanizmi orqali outputga aylantirishini yaxshilab tushunib olasiz. Balkim keyingi eng zo'r GPT modellarni siz qurarsiz, who knows.

Attention is all you need

Oddiy dasturchi emas, o’z ishini maromiga yetkazib, oshig’i bilan qiladigan inson sifatida shakllaning. Mavzularni “ish topish” uchun emas, sohaga yangilik qilish va katta muammolarni tushunish, ularni yecha olish uchun o’rganing.

Faqat gap yoki taklif emas, sizga darslik ham bermoqchiman. HTTP ni ishlatib serverlar qurasizu lekin, uni ostidagi jarayonni tushunmasligingiz mumkin. Ammo bugundan bular o’zgarishini va bunga o’z xissam qo’shilishini istayman.

Hech bir qurgan loyiham cho’ntagim uchun qilinmagan. Bo’lmasa bu blogni ham tekinga o’qimasdingiz, men otabek.io ni palon pulga sotib olmasdim. Tajribalar oddiydir lekin bular men uchun bir qiyinchilik ortidagi hikoyalar. (Siz shunday emassiz lekin shunday fikrlaydiganlar yetarlicha ekan)

• HTTPni 0dan quramiz - Go dasturlash tilida
• HTTPni 0dan quramiz - Python dasturlash tilida

yoki

• otabek.io/lectures

Faqat Java/Node.js yo’q ekan demang. O’rganing va qiling, omad : )

Bu bilmni ulashing, zora ko’plab dasturchilarga qiziqish uyg’otishda foydamiz tegsa

#experience

Yillar davomida o’rgangan ba’zi bilmlarimdan:

- Abstraksiya funksiya yoki servis qanday ishlashiga emas, nima bersangiz nima olishingiz mumkinligiga diqqatingizni qaratadi. Bu ba’zan sizga tizimni murakkabligini soddaroq tushinb qurishga yordam qilsa, ba’zan sizga qimmatga tushishi mumkin. On-call, o’zbek tilida navbatchilik deymiz. Infra, cloud jamoalarda ishlaydiganlar odatda buni yaxshi bilishadi. Aynan navbatchilik paytida bizga yoqmaydigan fundamental “algoritmlar”, “data structure”, “low-level”, “matematika”, “networking”, “database”, “operating systems” va h.k.z bilmlar juda kerak bo’lishini ko’p guvohi bo’lasiz. Insonlar mukammallikdan uzoq bo’lgani kabi, ular yozgan dasturlar, kodlar, kitoblar va asarlar ham huddi shunday ekan.

- Kod yozishdan ko’ra ko’proq kodni o’chirish qiyinroq va ko’proq xavfsizlik keltirar ekan. Shu paytgacha 20 238 qator kod o’chirdim. Jamoa bu ishimdan juda hursand bo’ldi. Pul, asab va energiya tejadik. Qanday? Endi bu servis hech qachon buzilmaydi, biz uni soatlab “nima bo’ldi ekan?” deb kuzatmaymiz/tuzatmaymiz. Ota-bobolarimiz aytganidek “eng yaxshi kod bu yozilmagan kod”.

- Yiqilishdan qo’rqmaydiganlar ko’p yutar ekan. Qiziqishlarim menga juda qimmatga tushgan. Dadam olib bergan o’sha $500 lik kompyuterni chuqalab $50 ga sotganimiz, startup quraman deb cloudga to’lagan oxirgi $4000 pulim, system dizayni amaliyot qilib o’rganaman deb ketkazilgan vaqt (20ta kitob o’qib yodlash mumkin edi bu vaqtga), production’da qilingan xatolik va eksperimentlar, ehh gapirsa tugamaydigandek. Lekin barchasi Otabekni shu yergacha kelishiga o’z xissasini qo’shgan. Dastur muammosiz ishlasa o’smaysiz. Istalgan kompaniya ham shuncha odamni bekorga ishlatmaydi. Xatolar va muammolar bizni bor qilib turibdi, buzishdan qo’rqmang. Ammo buzg’unchi bo’lmang.

- Yaxshi do’stlar ortdiring va qiymat bering. Blog yozib ham do’st orttirish mumkin ekan. Hozirda minglab do’slarim (sizlar) shu blogimni foydasi bor deb o’qishadi. Ba’zilar “qiziqshim oshadi sizni blogizni o’qisam” desa, yana ba’zilar “senior bo’lishda/ishga kirishimda yordam qildi blogingiz” deydi. Ha “nima deyabsan o’zing tushunayabsanmi?” deydiganlar ham topiladi. Ammo foydasi tegayabdi, shunisidan xursandman.

Xullas qisqacha shular.

Vohid aka bilan podkastda intervyu haqida gaplashgandik va F5 kompaniyasi intervyusidan yiqilib, Networking'ni N harfini bilmasligimni bilgandim deb aytgan edim. O'sha intervyudan juda ko'p (rostan ham ko'p) xulosa va tajriba olganman.

Express Networking kursida bular haqida bo'lishib borayabman. Sizga yana bir ajoyib mavzuni o'rgatib va F5 kompaniyasiga bo'lgan intervyudan yiqilganimdan olgan tajribamni bo'lishishga qaror qildim. Bu darsni ham bepul ko'rishingiz mumkin.

Bu darsda sizga nslookup va dig kabi dasturlarni RFC o'qib qurishni amaliy o'rgatib kod yozib berganman.

👉 42.uz/course/express-networking/udp-tezkor-kuryer

Internet ortidagi mo'jizani o'zingiz tushunib, va o'rgangan bilmlar asosida ularni qayta ixtiroq qilishni istaysiz. Ammo qayerdan boshlashni bilmaysizmi?

- DNS query
- HTTP protokoli
- Xavfsiz va tezkor API
- Sniffing tool (hacking uchun)
- Speedbumper
- Proxy (Nginx ga o'xshagan)
- Ngrok (Tunneling service)
- Real-time tizimlar (oz resurs, ko'p connection)
- ... va h.k.z larni 0dan quramiz (kutubxonalarsiz)

Bu yerdan boshlasangiz bo'ladi: 42.uz/course/express-networking

Hacking va Security bo'limida o'rgatilgan barcha bilm va amaliyotlarni faqat yaxshi yo'lda sarflaysiz deb umid qilaman

Lectures

Barcha ochiq ma'ruzalarimni videolarini shu yerda kuzatsangiz bo'ladi.

Batafsil 👉 otabek.io/lectures