Kunning AI va GPU yangiliklari

GPU watts — butun server sarfi emas

Fakt: NVIDIA nvidia-smi’dagi Average/Instantaneous Power Draw’ni rozetkadan butun server oladigan quvvat emas, GPU platasining umumiy quvvati deb belgilaydi. GPU ko‘rsatkichlarini qo‘shib, tugunning to‘liq energiya sarfi deb olish xato: CPU, RAM, disklar, ventilyatorlar va quvvat bloklaridagi yo‘qotishlar bu o‘lchovdan tashqarida qoladi.

Nega muhim: bir xil o‘lchov chegarasisiz GPU’larni watts bo‘yicha solishtirish inference xarajati hisobini buzishi mumkin.

Uch qadam: 1. O‘z tuguningizda nvidia-smi -q -d POWER -l 1 ni ko‘ring. Maydon nomi va GPU’ni yozib oling: Average Power Draw — oxirgi soniyadagi o‘rtacha, Instantaneous — oxirgi o‘lchov. Tugatish: Ctrl+C. Mavjud bo‘lmagan N/A’ni nolga almashtirmang. 2. Butun server uchun kirishdagi energiyani mos metered PDU yoki hisoblagich orqali o‘lchang. Shu tugunning barcha elektr ta’minoti liniyalarini hisobga oling; qo‘shni serverlarni qo‘shmang. Boshlang‘ich va yakuniy kWh ko‘rsatkichlari hamda test vaqtini saqlang. 3. Konfiguratsiyalarda bir xil so‘rovlar to‘plamini bajaring: model, precision, context, concurrency va sifat mezonlari bir xil bo‘lsin. Faqat GPU’ning joriy watts qiymatini emas, muvaffaqiyatli bajarilgan to‘plamga ketgan kWh va latency’ni solishtiring.

Tuzoq: o‘rtacha qiymatni tez-tez so‘rash uni cho‘qqilar o‘lchoviga aylantirmaydi. Test ishlash xarajatini baholashga foydali, ammo elektr ta’minoti va sovitishning muhandislik hisobini almashtirmaydi. Average Power Draw Ampere’da, GA100’dan tashqari, va yangiroq GPU’larda qo‘llanadi; maydonlar mavjudligi qurilmaga bog‘liq.

Loyiha sayti: https://verum-ai.uz

Источник / Manba · NVIDIA: https://docs.nvidia.com/deploy/nvidia-smi/

Gemma 3n E4B: «4B» — modelning to‘liq hajmi emas

Google Gemma 3n’ning to‘liq relizini 26.06.2025 da chiqargan. Bu deployment tahlili, bugungi yangilik emas. E2B/E4B’da Base va Instruct variantlari bor; matn, rasm, video va audio qabul qilib, matn qaytaradi. Context — 32K, ochiq vaznlar — Gemma shartlari asosida.

Fakt: google/gemma-3n-E4B-it taxminan 8B parametrga ega, E esa effective degani. 4B darajasidagi xotira sarfiga parametrlarni maxsus joylashtirish, jumladan Per-Layer Embeddings (PLE)’ni acceleratordan tashqariga chiqarish orqali erishiladi. E4B nomining o‘zi runtime’da bu optimizatsiyani yoqmaydi.

Nega muhim: GPU’ni «4B × son hajmi» bo‘yicha tanlash xavfli: vaznlar, KV cache va multimodal qismlar uchun xotirani kam baholash mumkin.

Uch qadam: 1. Aniq checkpoint, runtime versiyasi, dtype/quantization va kerakli kirishlarni belgilang: faqat matnmi yoki ovoz/rasm ham bormi? 2. Tanlangan backend hujjatlaridan PLE offload/caching qo‘llanishini va modullar amalda qayerda joylashganini tekshiring. Oddiy device_map="auto" maxsus PLE optimizatsiyasi isboti emas. 3. Maqsadli konfiguratsiyada avval yuklashdan keyin, so‘ng haqiqiy context va concurrency’da peak VRAM, host RAM hamda latency’ni o‘lchang. GPU’ni model nomiga emas, shu testga qarab, zaxira bilan tanlang.

Tuzoq: offload parametrlarni o‘chirmaydi — yuk VRAM’dan tashqariga ko‘chadi. Bu o‘lchovlar fine-tuning emas, inference uchun. Har qanday runtime’ga mos universal minimal VRAM va’da qilinmaydi.

Loyiha sayti: https://verum-ai.uz

Источники / Manbalar · Google: https://ai.google.dev/gemma/docs/gemma-3n https://huggingface.co/google/gemma-3n-E4B-it

AI CSV tayyorladi — fayl hali xavfsiz degani emas

Fakt: CSV «matnli katak» turini saqlamaydi. Excel yoki LibreOffice Calc = bilan boshlangan qiymatni formula deb qabul qilishi mumkin. CSV qo‘shtirnoqlari buning oldini olmaydi. AI hisobotga mijoz izohlari yoki veb ma’lumotlarini qo‘shsa, ular bilan formula injection ham kirishi mumkin.

Nima qilish kerak: 1. Spreadsheet’da ochishdan oldin faylni o‘qish vositasi bor AI’dan CSV’ni ma’lumot sifatida tahlil qilishni so‘rang. Encoding va delimiter’ni ko‘rsating; asl fayl o‘zgarmasin. «Fayl xavfsiz» degan gap emas, «qator → ustun → shubhali boshlanish» hisoboti kerak. 2. Har bir ajratilgan katak boshini tekshiring: = + - @, tab, CR/LF va belgilarning to‘liq kenglikdagi variantlari. Bular tekshiruv signali, hujum isboti emas: manfiy sonlar ham ro‘yxatga tushishi mumkin. 3. Kerakli dastur uchun matn sifatida import usulini kelishib oling. Avval alohida, zararsiz =1+1 misolida sinang: qiymat hisoblanmasdan matn bo‘lib qolishi kerak. Saqlab, qayta ochgandan keyin ham tekshiring; shubhali asl faylni sinovda ishlatmang.

Tayyor prompt: CSV’ni formulalarni bajarmasdan va spreadsheet’da ochmasdan formula injection uchun tekshir. CSV-parser ishlat, shubhali kataklar koordinatalari va sabablarini sanab ber. Avtomatik tuzatma. [Dastur va versiya] uchun matnli import usuli va alohida zararsiz test taklif qil.

Ehtiyot bo‘ling: barcha dasturlar uchun universal CSV tozalash usuli yo‘q. OWASP’ga ko‘ra, Excel saqlash va qayta ochishda himoya qo‘shtirnoqlari/escape-belgilarini olib tashlashi mumkin. «Apostrof qo‘shdik» — kafolat emas.

Manba: https://community.owasp.org/attacks/CSV_Injection Verum-AI sayti: https://verum-ai.uz

CUDA OOM: faqat GiB sonini emas, tarixni saqlang

Fakt: PyTorch xotira ajratish tarixi va stack traces bilan memory snapshot saqlay oladi. Visualizer’da OOM hodisasini xato paytidagi allocator holati bilan solishtirish mumkin. Bu bitta «VRAM band» ko‘rsatkichidan foydaliroq: xotira bloklari qayerdan kelgani ko‘rinadi.

Uch qadam: 1. Inference yoki training’dan qisqa, qayta takrorlanadigan bo‘lak ajrating. PyTorch/CUDA versiyalari, batch size va kirish uzunligini saqlang. Yozishni OOM’dan keyin emas, muammoli qismdan oldin yoqing. 2. Quyidagi o‘ramni test skriptiga qo‘shing. run_your_code() o‘rniga o‘z funksiyangizni yozing. finally exception bo‘lganda ham snapshot saqlashga urinadi. Saqlash muvaffaqiyatli bo‘lsa, dastlabki OOM yuqoriga uzatiladi: import torch m = torch.cuda.memory m._record_memory_history() try: run_your_code() finally: m._dump_snapshot("oom_snapshot.pickle") m._record_memory_history(enabled=None) 3. https://pytorch.org/memory_viz ni ochib, o‘z snapshot’ingizni tashlang. Allocator State History’da OOM’ni tanlang, band va bo‘sh bloklar hamda stack traces’ni tekshiring. Topilgan sababni tuzatib, ayni testni takrorlang. Hujjatga ko‘ra, visualizer brauzerda lokal ishlaydi va snapshot’ni serverga yuklamaydi.

Cheklov: snapshot butun VRAM’ni emas, PyTorch allocator xotirasini ko‘radi: masalan, NCCL ajratmalarining bir qismi ko‘rinmaydi. Pastki chiziqli API’ni o‘z versiyangizda tekshiring; misol PyTorch 2.8 hujjatiga asoslangan. Jarayon avariya bilan tugasa, finally bajarilmasligi mumkin. Snapshot’da yo‘llar va stack traces bor — tekshirmasdan tarqatmang.

Loyiha sayti: https://verum-ai.uz

Источник / Manba · PyTorch: https://github.com/pytorch/pytorch/blob/v2.8.0/docs/source/torch_cuda_memory.md

Qwen3.6-27B: agentni qayta mulohaza yuritishga majburlamang

Qwen/Alibaba modelni 22.04.2026 da chiqardi: dense 27B, Apache 2.0 litsenziyali ochiq weights; matn, rasm va video → matn. Native context — 262 144 tokens. Bu bugungi yangilik emas, amaliy tahlil.

Fakt: Qwen3.6 oldingi xabarlardagi reasoning’dan foydalanishga o‘rgatilgan. preserve_thinking bu bloklarni chat template’da saqlaydi; odatda faqat oxirgi foydalanuvchi so‘roviga tegishli thinking qoladi. Ko‘p bosqichli coding’da bu takroriy mulohazani kamaytirishi mumkin, ammo tezlashish kafolatlanmaydi.

Qo‘llash: 1. Self-hosted API uchun modelni qo‘llovchi runtime tanlang: model card vLLM ≥0.19.0 yoki SGLang ≥0.5.10 ni tavsiya qiladi. 2. Tarixga faqat yakuniy matnni emas, reasoning_content bilan assistant messages’ni qaytaring. Flag o‘chirilgan tarixni tiklamaydi. 3. OpenAI Python SDK’da uzating: extra_body={"chat_template_kwargs":{"preserve_thinking":True}} 4. Bir coding-senariyni flag bilan va flagsiz solishtiring: testlar muvaffaqiyati, jami tokens, latency va peak VRAM.

GPU: faqat til qismining BF16, quantization’siz weights’i uchun hisobimiz — taxminan 54 GB. Vision, KV cache va runtime qo‘shimcha xotira talab qiladi; bu GPU uchun minimal talab emas. Uzunroq tarix ham context va xotira sarflaydi.

Cheklov: sozlama aynan shu model va mos API uchun. Rasmiy SWE-bench Verified’dagi 77,2 — ishlab chiquvchi bahosi, sizning repository’ingiz uchun natija va’dasi emas.

https://verum-ai.uz da GPU va ochiq modellar taqdim etilgan; aynan shu checkpoint mavjudligini alohida aniqlang. Manbalar: https://huggingface.co/Qwen/Qwen3.6-27B https://qwen.ai/blog?id=qwen3.6-27b

AI «eng so‘nggi 10 buyurtma»ni topdimi? LIMIT saralamaydi

Fakt: PostgreSQL’da LIMIT 10 satrlar sonini cheklaydi, ammo eng yangilarini tanlamaydi. ORDER BY bo‘lmasa, tartib kafolatlanmaydi. Faqat sana bo‘yicha saralash ham sanalar teng bo‘lsa noaniqlik qoldiradi. Shunda AI’ning ishonarli javobi noto‘g‘ri buyurtmalarga asoslanishi mumkin.

Uch qadam: 1. «Eng so‘nggi» nimani anglatishini belgilang: yaratilgan yoki o‘zgartirilgan vaqt. Misolda bu created_at; id — buyurtmaning noyob kaliti. 2. AI’dan to‘liq tartib va bo‘sh sanalar qoidasini belgilashni so‘rang. PostgreSQL uchun: SELECT id, created_at FROM orders ORDER BY created_at DESC NULLS LAST, id DESC LIMIT 10; Sana bir xil bo‘lsa, kattaroq id yuqorida turadi. Sanasiz satrlar oxirga tushadi, eng yangi hisoblanmaydi. 3. Hisobotdan oldin so‘rovni test ma’lumotlarida tekshiring: teng sanalar, NULL va vaqt tartibisiz kiritilgan satrlar. Faqat satrlar sonini emas, aniq ID’larni oldindan belgilangan kutilgan ro‘yxat bilan solishtiring.

Tayyor prompt: PostgreSQL’da «eng so‘nggi 10 buyurtma» uchun SQL’ni tekshir. Yangilik mezoni — created_at; id noyob. Aniq ORDER BY belgilab, NULL’ni oxirga qo‘y. Teng sanalar, NULL va aralash kiritish bilan testlar qo‘sh. Ularni bajarib, kutilgan va haqiqiy ID’larni ko‘rsat; bajara olmasang, ochiq ayt. Production’ni o‘zgartirma.

Cheklov: bu joriy ma’lumotlar tartibi, muzlatilgan snapshot emas. Yangi yozuvlar OFFSET sahifalarini siljitishi mumkin. JOIN’dan keyin natijada id noyobligicha qolganini tekshiring.

Verum AI: https://verum-ai.uz

Источники / Manbalar · PostgreSQL: https://www.postgresql.org/docs/18/queries-limit.html https://www.postgresql.org/docs/18/queries-order.html

torch.compile: birinchi so‘rov — butun ish tezligi emas

Fakt: torch.compile model ilk marta bajarilganda kompilyatsiyaga vaqt sarflaydi, keyin imkon qadar tayyor koddan foydalanadi. Shuning uchun bitta sekin birinchi so‘rov GPU yoki compiled-model eager’dan sekinligini isbotlamaydi. Ammo qisqa vazifaning umumiy vaqtidan startni chiqarib tashlash ham noto‘g‘ri.

Uch qadam: 1. Model va weights, GPU, PyTorch/CUDA versiyalari, dtype, batch va kirish o‘lchamlarini qayd eting. Eager va compiled’ni bir xil ma’lumotda solishtiring; natijalar mosligini tegishli sonli xatolik chegarasi bilan tekshiring. 2. Birinchi bajarilish vaqtini va kechikish barqarorlashguncha warmup’dan keyingi seriyani alohida yozing. CUDA chaqiruvini wall-clock bilan o‘lchashda torch.cuda.synchronize() ni taymerdan oldin va hisoblashdan keyin, taymerni to‘xtatishdan avval bajaring. Compile cache oldindan to‘lganmi, belgilang: yangi process har doim sovuq cache degani emas. 3. Warmup’dan keyingi chaqiruvlar medianasini va start bilan birga haqiqiy seriyangizning to‘liq vaqtini solishtiring. Doimiy ishlaydigan server uchun steady state muhim; bir martalik vazifada esa kompilyatsiya tugashgacha o‘z xarajatini qopladimi, shuni tekshiring.

Tuzoq: yangi kirish o‘lchamlari recompilation keltirib chiqarishi mumkin. Bir shape’da warmup qilish boshqasida ayni kechikishni kafolatlamaydi. Tutorial’dagi tezlashish sizning modelingiz uchun va’da emas; bitta o‘lchov asosida GPU sotib olmang.

Loyiha sayti: https://verum-ai.uz

Источники / Manbalar · PyTorch: https://docs.pytorch.org/tutorials/intermediate/torch_compile_full_example.html https://docs.pytorch.org/docs/main/user_guide/torch_compiler/torch.compiler_troubleshooting.html

Voxtral Realtime: kamroq kechikish — har doim ham aniqroq matn emas

Mistral AI Voxtral Mini 4B Realtime 2602’ni 04.02.2026’da chiqardi: oqimli nutq → matn, ochiq BF16 weights, Apache 2.0; API — GA holatida. Bu batch uchun Mini Transcribe V2 ham, oddiy chatbot ham emas.

Fakt: transcription delay modelga nutq davomini eshitish uchun vaqt beradi. Ishlab chiquvchining FLEURS testlarida o‘rtacha WER 480 ms’da 8,72%, 960 ms’da 7,70%: pastroq — yaxshiroq. Xatolar juda qisqa kutishdan kelayotgan bo‘lsa, yangi GPU olishga shoshilmang.

Qo‘llash: 1. Lokal vLLM’da tavsiya etilgan 480 ms va temperature=0.0’dan boshlang. Model card BF16 uchun ≥16 GB xotirali bitta GPU’ni ko‘rsatadi; bu bir nechta parallel oqim sig‘ishiga kafolat emas. 2. Model konfiguratsiyasi nusxasidagi tekken.json’da "transcription_delay_ms": 480 o‘rniga 960 yozing va service’ni qayta ishga tushiring. Ikkala rejimni shaxsiy ma’lumotlardan tozalangan, qo‘lda transkript qilingan bir xil yozuvlarda sinang. WER, ism va sonlarni solishtiring. 3. Kerakli parallel oqimlar sonida nutqdan matngacha kechikish va peak VRAM’ni o‘lchang. Qisqa sessiyalar uchun --max-model-len kamayishini alohida sinang: default 131072 taxminan 3 soatga mo‘ljallangan; kichikroq limit oldindan hisoblangan RoPE frequencies uchun xotirani kamaytiradi.

Tuzoq: 480 ms ilovaning to‘liq kechikishiga va’da emas: tarmoq, navbat va hisoblash ham bor. E’lon qilingan 13 tilda rus tili bor, o‘zbek tili yo‘q; undagi sifatni alohida sinash kerak. Loyiha sayti: https://verum-ai.uz

Источники / Manbalar · Mistral AI: https://huggingface.co/mistralai/Voxtral-Mini-4B-Realtime-2602 https://docs.mistral.ai/models/voxtral-mini-transcribe-realtime-26-02

AI uchun PDF: qora to‘rtburchak hali o‘chirish emas

Fakt: Adobe redaction — tanlangan matn va rasmlarni o‘chirish — hamda sanitization: metadata va ichki kontent kabi yashirin ma’lumotlarni tozalashni ajratadi. Rekvizitlarni shakl bilan yopish yetarli emas: asl kontent PDF ichida qolib, AI qayta ishlashiga tushishi mumkin.

Yuklashdan oldin uch qadam: 1. Lokal nusxa yarating. Acrobat Pro’da All tools → Redact a PDF → Redact text and images ni oching. Vazifa uchun kerak bo‘lmagan F.I.Sh., hisob raqamlari, imzolar va boshqa sirlarni faqat birinchi sahifada emas, barcha joylarda belgilang. 2. Apply ni bosing, yashirin ma’lumotlarni o‘chirishni (sanitize) yoqing va yangi nom bilan saqlang. Joylarni belgilashning o‘zi yetmaydi: o‘zgarishlarni qo‘llash va saqlash kerak. Asl faylni himoyalangan saqlash joyida qoldiring. 3. Aynan yakuniy faylni qayta oching. Sahifalarni ko‘zdan kechiring; o‘chirilgan parchalarni lokal qidirish va nusxalash orqali tekshiring. Metadata va ilovalarni ham tekshiring. Tashqi AI’ga faqat tekshirilgan nusxani, tashkilot qoidalari ruxsat bersagina yuboring.

Xato: qidiruv hech narsa topmagani xavfsizlik isboti emas: skanda matn qatlami bo‘lmasligi, qolgan kontekstdan esa shaxsni tanib olish mumkin. «Shaxsiy ma’lumotlarni hisobga olma» degan so‘rov ularni yuborishni bekor qilmaydi. Qo‘llangan va saqlangan redaction qaytarilmaydi; bu misoldagi vosita — Acrobat Pro.

Loyiha sayti: https://verum-ai.uz

Источники / Manbalar · Adobe: https://helpx.adobe.com/acrobat/desktop/protect-documents/redact-pdfs/redact.html https://helpx.adobe.com/acrobat/desktop/protect-documents/redact-pdfs/redacting-sanitizing.html

T.Limit pasaysa, GPU albatta soviyotgan bo‘lmaydi

Fakt: nvidia-smi’dagi T.Limit — GPU’ning o‘z harorati emas, maksimal ish haroratigacha qolgan zaxira, graduslarda. Zaxira qancha kamaysa, issiqlik chegarasi shuncha yaqin. NVIDIA bo‘yicha, 0 °C yoki undan pastda GPU qizish sababli chastotalarini o‘zgartirishi mumkin.

Nega muhim: bu yerda «gradus kamroq — yaxshiroq» qoidasi teskarisiga ishlaydi. T.Limit’ni GPU Current Temp bilan adashtirsangiz, inference paytidagi issiqlik cheklovini o‘tkazib yuborishingiz mumkin.

Uch qadam: 1. Mavjud sensorlarni ko‘ring: nvidia-smi -q -d TEMPERATURE GPU Current Temp mutlaq haroratini GPU T.Limit Temp nisbiy zaxirasidan ajrating. T.Limit qo‘llansa, ayrim harorat chegaralari ham unga nisbatan ko‘rsatiladi. 2. Odatdagi yuklama paytida harorat va chastota cheklanishi sabablarini kuzating: nvidia-smi -q -d TEMPERATURE,PERFORMANCE -l 2 Bu har ikki soniyada tekshiradi; to‘xtatish — Ctrl+C. Zaxira kamayishini SW Thermal Slowdown / HW Thermal Slowdown va so‘rovlar kechikishi bilan solishtiring. 3. Zaxira nolga yaqinlashib, thermal slowdown faol bo‘lsa, server yo‘riqnomasi bo‘yicha sovitishni tekshiring: kiruvchi havo harorati, airflow va ventilyatorlar holati. Tuzatgach, batch va power limit’ni o‘zgartirmasdan ayni workload’ni takrorlang.

Xato: T.Limit barcha GPU’larda mavjud emas. N/A — qo‘llab-quvvatlanadigan ko‘rsatkich yo‘q, harorat nol degani emas. Bitta o‘lchov sekinlashish sababini isbotlamaydi; bu yerdagi nol darhol o‘chishni anglatmaydi.

Loyiha sayti: https://verum-ai.uz

Источник / Manba · NVIDIA: https://docs.nvidia.com/deploy/nvidia-smi/

Qwen3-TTS: bitta ovoz namunasini qayta ishlayvermang

Qwen (Alibaba Cloud) oilani 22.01.2026’da chiqargan. Bu yerda — Qwen3-TTS-12Hz-0.6B-Base: ochiq weights, Apache 2.0, matn + ovoz namunasi → nutq. Bu mavjud speech LM, bugungi yangilik ham, oddiy chatbot ham emas; oilada 1.7B-versiyalar ham bor.

Fakt: SDK create_voice_clone_prompt orqali namuna ovozining belgilarini bir marta ajratib, keyingi gaplarda ishlatadi. Har so‘rovda bir xil namunani qayta tayyorlash shart emas; nutqning o‘zi baribir generatsiya qilinadi.

Uch qadam: 1. O‘z ovozingiz yoki egasi aniq ruxsat bergan ovoz yozuvi va uning aniq transkriptini oling. qwen-tts orqali aynan Base’ni yuklang; rasmiy misolda CUDA va BF16 ishlatilgan. 2. Yuklangan modelda prompt’ni bir marta yarating: p = model.create_voice_clone_prompt(ref_audio="ref.wav", ref_text=transcript, x_vector_only_mode=False) Har yangi gap uchun uni uzating: wavs, sr = model.generate_voice_clone(text=line, language="Russian", voice_clone_prompt=p) 3. Bir xil gaplarda warmup’dan keyingi vaqt va peak VRAM’ni ref_audio’ni qayta ishlash usuli bilan solishtiring. GPU’ni faqat «0.6B» emas, haqiqiy uzunlik va concurrency bo‘yicha tanlang. Bu inference, fine-tuning emas.

Cheklovlar: x_vector_only_mode=True transkript talabini olib tashlaydi, ammo ovoz o‘xshashligini pasaytirishi mumkin. E’lon qilingan 10 tilda rus tili bor, o‘zbek tili yo‘q. Model card’da minimal VRAM va yagona text context limiti ko‘rsatilmagan. Seed-TTS test-en’dagi WER 1.32 — ishlab chiquvchi natijasi, sizning yozuvlaringiz uchun kafolat emas. Voice prompt’ni maxfiy ma’lumot sifatida saqlang.

Loyiha sayti: https://verum-ai.uz

Источники / Manbalar · Qwen: https://github.com/QwenLM/Qwen3-TTS https://huggingface.co/Qwen/Qwen3-TTS-12Hz-0.6B-Base

AI GitHub issues’ni sanayapti — PR’larni ham qo‘shmadimi?

Fakt: GitHub REST’dagi GET /repos/{owner}/{repo}/issues endpoint’i issues bilan birga pull requests’ni ham qaytaradi. PR pull_request kaliti borligi orqali aniqlanadi. AI javobdagi elementlarni shunchaki sanasa, ochiq vazifalar hisobotidagi son ortib ketishi mumkin.

Uch qadam 1. Qamrovni belgilang: aniq repository va ochiq vazifalar uchun state=open. Bu ko‘rsatkichni hafta davomida yaratilgan vazifalar soni bilan almashtirmang. 2. Link: rel="next" orqali barcha sahifalarni oling. Keyin pull_request kaliti yo‘q yozuvlarni qoldiring. Sarlavhadagi «PR» yoki «bug» so‘zidan ko‘ra kalitning mavjudligi muhim. 3. id bo‘yicha takrorlarni olib tashlang, natijani kod bilan sanang va kiritilgan issues havolalarini saqlang. Chiqarib tashlangan PR soni va tekshiruv vaqtini alohida ko‘rsating. Biror sahifa olinmasa, natijani to‘liq deb bermang — yetishmovchilikni ayting.

Tayyor prompt OWNER/REPO’dagi ochiq issues’ni PR’siz GitHub REST API orqali sana. Barcha sahifalarni ol, pull_request kaliti bor yozuvlarni chiqar, id bo‘yicha takrorlarni olib tashla. Son, issues havolalari, chiqarilgan PR soni va tekshiruv vaqtini ber. Repository’ni o‘zgartirma. Ma’lumot to‘liq bo‘lmasa yoki API ishlamasa, ayt; yakunni o‘ylab topma.

Cheklov: issue har doim xato emas: g‘oya yoki savol ham bo‘lishi mumkin. Bugs hisoboti uchun alohida qoida, masalan aniq label belgilang; label yo‘qligi nuqsonlar yo‘qligini isbotlamaydi.

Loyiha sayti: https://verum-ai.uz

Источники / Manbalar · GitHub: https://docs.github.com/en/rest/issues/issues#list-repository-issues https://docs.github.com/en/rest/using-the-rest-api/using-pagination-in-the-rest-api

Checkpointing: tekshiruv o‘tdi — gradients to‘g‘rimi?

Fakt: PyTorch activation checkpointing’da use_reentrant=False bo‘lsa, determinism_check="default" qayta hisoblangan tensors’ning shape, dtype va device’ini saqlanganlari bilan solishtiradi. U sonli qiymatlarni solishtirmaydi.

Nega muhim: fine-tuning’da VRAM tejash training’ni sezdirmay o‘zgartirmasligi kerak. Blokni qayta hisoblash o‘zgargan global o‘zgaruvchiga bog‘liq bo‘lsa, tensors o‘lchamlari bir xilligi gradients ham bir xil degani emas.

Uch qadam 1. Checkpointing’siz qisqa etalon forward + backward bajaring. Loss va gradients’ni saqlang; hozircha optimizer step bajarmang. 2. Xuddi shu weights va batch bilan, bir xil dtype va model rejimida checkpointing’ni yoqib takrorlang. Har bir sinov oldidan bir xil RNG state’ni tiklang va gradients’ni tozalang. 3. Loss va har bir o‘qitiladigan parametr gradients’ini torch.testing.assert_close bilan solishtiring. grad is None holatlari mosligini alohida tekshiring; tolerances’ni o‘z precision’ingizga moslang. Shundan keyingina peak VRAM va step vaqtini solishtiring.

Tuzoq: debug=True xato xabarlariga operatsiyalar izini qo‘shadi, sonlarni tekshirmaydi. Bitta muvaffaqiyatli batch barcha kirishlar uchun kafolat emas. Bu training to‘g‘riligini tekshirish, model weights’ini kichraytirish usuli emas.

Loyiha sayti: https://verum-ai.uz

Источник / Manba · PyTorch: https://docs.pytorch.org/docs/stable/checkpoint.html

AI vaqtni o‘girdimi yoki faqat belgisini almashtirdimi?

Fakt: Python’da dt.astimezone(tz) vaqtni boshqa timezone’ga o‘girib, ayni lahzani saqlaydi. dt.replace(tzinfo=tz) esa soatni qayta hisoblamay, faqat timezone ma’lumotini almashtiradi. Ularni adashtirish hodisani hisobotning boshqa kuniga kiritishi mumkin.

Uch qadam 1. Faylni qayta ishlashdan oldin manba va hisobot timezone’ini belgilang. Boshlang‘ich vaqtda offset bo‘lmasa va uning mintaqasi noma’lum bo‘lsa, AI uni server sozlamalaridan taxmin qilmasin. 2. Lahzasi allaqachon aniqlangan vaqt uchun local = dt.astimezone(target_tz) ishlating. O‘quv misoli: 2026-10-03T00:30:00+00:00 → 2026-10-03T05:30:00+05:00. replace orqali 00:30:00+05:00 chiqardi — bu boshqa lahza. 3. dt.timestamp() == local.timestamp() ekanini tekshiring. Yarim tun yaqinida sana almashadigan test qo‘shing; kun bo‘yicha faqat hisobot timezone’iga o‘girgandan so‘ng guruhlang.

Tayyor prompt Python-hisobotda vaqt o‘girilishini tekshir. Lahzani astimezone bilan saqla, replace(tzinfo=...) bilan almashtirma. Noma’lum timezone’ni muammo deb belgilagin. Timestamp tengligi va sana almashishi testlarini ko‘rsat. Asl faylni o‘zgartirma.

Tuzoq: naive datetime uchun astimezone tizim timezone’ini taxmin qiladi. replace mahalliy soatga aniq ma’lum timezone’ni biriktirish uchun mos, ammo mintaqalar orasida o‘girish uchun emas. Misoldagi doimiy offset DST bor hududlar qoidalarini almashtirmaydi.

Loyiha sayti: https://verum-ai.uz

Источник / Manba · Python: https://docs.python.org/3.11/library/datetime.html#datetime.datetime.astimezone

DDP: ortiqcha almashinuvni emas, gradients’ni jamlang

Fakt: PyTorch’da ddp.no_sync() DDP jarayonlari orasida gradients sinxronizatsiyasini vaqtincha o‘chiradi. Ular lokal jamlanadi va context’dan tashqaridagi birinchi forward + backward’da sinxronlanadi. Blok ichida forward ham, backward ham bo‘lishi kerak: faqat backward’ni o‘rash yetmaydi.

Nega muhim: gradient accumulation’da har bir microbatch’dan so‘ng gradients almashish shart emas. Tezlikni aynan almashinuv cheklasa, bu multi-GPU training’dagi aloqa xarajatlarini kamaytirishi mumkin.

Qo‘llash — 3 qadam: 1. Bitta optimizer step uchun har bir rank’da bir xil hajmdagi K ta microbatch tayyorlang. Oyna boshida optimizer.zero_grad() chaqiring. Loss bir xil sondagi elementlar bo‘yicha o‘rtacha bo‘lsa, har bir loss’ni K ga bo‘ling. 2. Dastlabki K−1 microbatch uchun forward va backward’ni with ddp.no_sync(): ichida bajaring. Oxirgi forward + backward — blokdan tashqarida, keyin bitta optimizer.step(). Microbatch’lar orasida gradients’ni tozalamang; oyna chegaralari barcha ranks’da mos bo‘lsin. 3. no_sync’siz jamlash bilan solishtiring: ma’lumotlar, effective batch va optimizer bir xil bo‘lsin. Gradients yaqinligini va qizdirishdan keyin to‘liq optimizer step vaqtini tekshiring — faqat bitta microbatch vaqtini emas.

Xato: valid tokens soni turlicha bo‘lsa, K ga oddiy bo‘lish loss vaznlarini noto‘g‘ri belgilashi mumkin. no_sync model weights’ini GPU’lar orasida taqsimlamaydi va tezlashishni kafolatlamaydi. Bu inference emas, DDP training usuli. Loyiha sayti: https://verum-ai.uz

Источник / Manba · PyTorch: https://docs.pytorch.org/docs/stable/generated/torch.nn.parallel.DistributedDataParallel.html

ChatGPT havolasi qidiruvda yo‘q — demak, maxfiymi?

Fakt: OpenAI yozishicha, shared links sahifalari qidiruv tizimlarida indekslash uchun mo‘ljallanmagan, lekin bu havolani maxfiy qilmaydi. Kirish huquqi bor oluvchi uni boshqalarga yuborishi mumkin. Qidiruvda yo‘qligi — kirish huquqi tekshirilganini anglatmaydi.

Mijozga yuborishdan oldin uch qadam:

1. Natijaning ichki yozishmalarsiz, uzatish uchun alohida versiyasini tayyorlang. Sirlar va keraksiz shaxsiy ma’lumotlarni AI’ga yuklashdan oldin olib tashlang; ism va rekvizitlarni shartli belgilar bilan almashtiring.

2. Share oynasida aynan nimalar kiritilganini tekshiring: faqat oxirgi javobni emas, balki sharing variantingizda mavjud bo‘lsa, tarix, tasvir va fayllarni ham. Tayyor havolani mo‘ljallangan oluvchi huquqlariga ega alohida sessiyada oching.

3. Kirish faqat belgilangan odamlarga kerak bo‘lsa, tekshirilgan natijani shunday huquqlar o‘rnatilgan, foydalanishga ruxsat etilgan saqlash tizimi orqali uzating. «Havolani faqat o‘zimiz bilamiz» — kirish cheklovi emas.

Oldindan tozalangan matn uchun tayyor prompt: Tashqi oluvchi uchun versiya tayyorla. Boshqa xabarlardan ma’lumot qo‘shma. Odamlar yoki tashkilotni tanib olish mumkin bo‘lgan qismlarni belgilab, shaxssizlantirilgan almashtirishlarni taklif qil. Natijani kafolatlangan anonim deb atama. Hech narsa yuborma.

Tuzoq: shared content tarkibi va kirish account/workspace hamda havola turiga bog‘liq. Shaxsiy ChatGPT qoidalarini Enterprise’ga ko‘chirmang. AI tekshiruvi maxfiylikni qo‘lda tekshirish o‘rnini bosmaydi.

Loyiha sayti: https://verum-ai.uz

Источник / Manba · OpenAI: https://help.openai.com/en/articles/7925741-chatgpt-shared-links-faq

DDP: shuffle=True, lekin ma’lumotlar tartibi takrorlanyaptimi?

Fakt: PyTorch DistributedSampler’da set_epoch(epoch) chaqirilmasa, hatto shuffle=True bo‘lsa ham har epoch’da bir xil tartib ishlatiladi. Bir nechta GPU ma’lumot uzatish mantiqini tuzatmaydi: training davom etadi, ammo kutilgan yangi aralashtirish bo‘lmaydi.

Uch qadam 1. Har bir DDP jarayonida shuffle=True bilan DistributedSampler ishlating. Seed barcha ranks uchun bir xil bo‘lsin. Sampler’ni DataLoader’ga bering; DataLoader’ning o‘zida shuffle=False belgilang.

2. Har epoch boshida, iterator yaratilishidan va batches bo‘yicha sikldan oldin chaqiring: for epoch in range(start_epoch, n_epochs): sampler.set_epoch(epoch) for batch in loader: train_step(batch) Bu sozlangan DDP training loop parchasi, to‘liq ishga tushirish kodi emas.

3. Kichik test dataset’da ikki epoch uchun har bir rank bo‘yicha sample IDs ketma-ketligini yozib oling. Epoch raqami barcha jarayonlarga uzatilganini tekshiring; training tiklanganda saqlangan epoch raqamlanishini davom ettiring.

Cheklov: shuffle=False bo‘lsa, bu chaqiruv aralashtirishni yoqmaydi. Sampler dataset hajmi doimiy, indekslar va ma’lumotlar mosligi barqaror bo‘lishini nazarda tutadi. Bu tartibni tuzatishdir, GPU tezligi yoki sifat oshishi va’dasi emas.

Loyiha sayti: https://verum-ai.uz

Источник / Manba · PyTorch: https://docs.pytorch.org/docs/stable/data.html#torch.utils.data.distributed.DistributedSampler

DeepSeek-OCR 2: so‘zlar o‘qildi, jadval esa yo‘qoldimi?

Bu DeepSeek’ning «rasm + prompt → matn» uchun ochiq vision-language modeli, litsenziyasi Apache 2.0. Ilmiy ish 28.01.2026 da chop etilgan: bugungi reliz emas.

Fakt: rasmiy misolda ikki rejim ajratilgan: Free OCR. — layout’siz, <|grounding|>Convert the document to markdown. — hujjatni belgilash bilan chiqarish uchun. Keyin jadval satrlari va ustunlari kerak bo‘lsa, GPU’ni almashtirishdan oldin prompt’ni tekshiring.

Uch qadam: 1. Jadval va ikki ustunli bitta sahifani oling. Tuzilmani saqlab ajratish uchun aniq Python satri: prompt = "<image>\n<|grounding|>Convert the document to markdown. " Taqqoslash uchun: prompt = "<image>\nFree OCR. ". Bu yerda \n — yangi satr. 2. Ikki sinovda rasm va sozlamalarni o‘zgartirmang. Ishlab chiquvchi misolida: base_size=1024, image_size=768, crop_mode=True. Faqat so‘zlar borligini emas, ustunlar tartibi va har bir summa o‘z satriga tegishliligini tekshiring. 3. Ommaviy ishlovdan oldin maqsadli sahifalarda batch=1 bilan vaqt va peak VRAM’ni o‘lchang. Misol NVIDIA GPU va BF16’dan foydalanadi; README universal minimal VRAM’ni ko‘rsatmaydi. Weights hajmini butun inference talabi deb olmang.

Cheklov: to‘g‘ri prompt kataklar to‘g‘riligini kafolatlamaydi. Summalar va birlashtirilgan kataklarni asl nusxa bilan tekshiring. Bu qo‘llash yo‘riqnomasi, bizning benchmark emas.

Verum AI: https://verum-ai.uz

Manbalar / Источники: https://github.com/deepseek-ai/DeepSeek-OCR-2 https://arxiv.org/abs/2601.20552

AI LEFT JOIN yozdi — mijozlar qayerga yo‘qoldi?

Fakt: SQL’da LEFT JOIN’dan keyingi WHERE o.status = 'paid' sharti mos buyurtmasi yo‘q satrlarni olib tashlaydi. Barcha mijozlar va ularning yonida faqat to‘langan buyurtmalar kerak bo‘lsa, status filtri ON tarkibida bo‘lishi kerak. Aks holda hisobot mijozlarni sezdirmay yo‘qotadi.

Uch qadam 1. Maqsadni belgilang: «barcha mijozlar, jumladan to‘langan buyurtmasi yo‘qlar ham». Bu «faqat to‘lovi bor mijozlar» degani emas. 2. AI’dan quyidagicha so‘rov tuzishni so‘rang: SELECT c.id, o.id AS order_id FROM customers c LEFT JOIN orders o ON o.customer_id = c.id AND o.status = 'paid'; 3. Uch holatni tekshiring: buyurtmasiz mijoz, faqat to‘lanmagan buyurtmali mijoz va to‘langan buyurtmali mijoz. Hammasi qolishi kerak; dastlabki ikkitasida order_id NULL bo‘ladi. Keyin mijozga ikkinchi to‘langan buyurtma qo‘shing: bu yerda unga ikkita satr chiqishi normal.

Tayyor prompt SQL’ni tekshir: barcha customers va faqat status='paid' bo‘lgan orders kerak. Mos buyurtmasi yo‘q mijozlarni yo‘qotma. ON/WHERE filtrlarini va to‘rtta testni tekshir: buyurtmasiz, faqat unpaid, bitta paid, ikkita paid. Kutiladigan satrlarni ko‘rsat; bazani o‘zgartirma.

Tuzoq: WHERE’ga OR o.id IS NULL qo‘shish faqat to‘lanmagan buyurtmalari bor mijozni saqlab qolmaydi. Barcha filtrlarni ON’ga avtomatik ko‘chirmang: avval kerakli natijani aniqlang. Bitta mijoz har doim bitta satr degani emas.

Loyiha sayti: https://verum-ai.uz

Источник / Manba · PostgreSQL: https://www.postgresql.org/docs/current/queries-table-expressions.html

MIG: qo‘shni xotira bo‘sh, sizda esa CUDA OOM?

Fakt: NVIDIA MIG har bir GPU Instance (GI) uchun sig‘imi va bandwidth’i cheklangan alohida xotira resurslarini ajratadi. Boshqa GI’dagi bo‘sh VRAM vazifangizga avtomatik berilmaydi. Shuning uchun GPU tanlashda butun kartaning xotirasi emas, sizga ajratilgan profil muhim.

Uch qadam 1. Ishga tushirish muhitida nvidia-smi -L bajaring. MIG UUID va profil nomini yozib oling; ularni ajratilgan qurilma bilan solishtiring. Container bu ma’lumotlarni yashirsa, administratordan so‘rang. 2. Aynan o‘z qurilmangizdagi mavjud xotirani tekshirib, kerakli context va batch size bilan odatiy inference’ni sinang. Faqat vaznlarni emas, KV cache va vaqtinchalik buffers’ni ham hisobga oling. Model yuklangani so‘rov ham xotiraga sig‘ishini kafolatlamaydi. 3. Xotira yetmasa, avval context yoki batch size’ni kamaytiring. Bu vazifa talablariga zid bo‘lsa, kattaroq GI yoki butun GPU so‘rang. Qo‘shni bo‘limning bekor turishi limitingizni oshirmaydi.

Muhim: GI va Compute Instance (CI) bir xil emas. Bitta GI ichidagi bir nechta CI uning xotirasini bo‘lishadi; har bir CI’ni alohida VRAM zaxirasi deb hisoblamang. MIG taqsimotini o‘zgartirishni administrator bilan kelishing, ishlayotgan serverda ko‘r-ko‘rona bajarmang.

Loyiha sayti: https://verum-ai.uz

Источники / Manbalar · NVIDIA: https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/concepts.html https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/mig-device-names.html