Qısa cavab: Süni intellekt modelinin tətbiqi xidmət nümunəsini (real vaxt, toplu, yayım və ya kənar) seçmək, sonra isə bütün yolu təkrarlana bilən, müşahidə edilə bilən, təhlükəsiz və geri qaytarıla bilən etmək deməkdir. Hər şeyi versiyalaşdırdığınız və istehsalat kimi faydalı yüklərdə p95/p99 gecikməsini qiymətləndirdiyiniz zaman, əksər "noutbukumda işləyən" nasazlıqları kənara qoyursunuz.
Əsas nəticələr:
Yerləşdirmə nümunələri: Alətlərə başlamazdan əvvəl real vaxt, toplu, yayım və ya kənar seçimlərini edin.
Təkrarlana bilmə: Driftin qarşısını almaq üçün modeli, xüsusiyyətləri, kodu və mühiti versiyalaşdırın.
Müşahidə olunma: Gecikmə quyruqlarını, səhvləri, doyma və məlumat və ya çıxış paylanmalarını davamlı olaraq izləyin.
Təhlükəsiz tətbiqlər: Avtomatik geri qaytarma hədləri ilə kanareyka, mavi-yaşıl və ya kölgə testlərindən istifadə edin.
Təhlükəsizlik və məxfilik: Avtorizasiya, sürət limitləri və sirrlərin idarə edilməsini tətbiq edin və jurnallarda PII-ni minimuma endirin.
Bundan sonra oxumaq istəyə biləcəyiniz məqalələr:
🔗 AI performansını necə ölçmək olar
Etibarlı süni intellekt nəticələri üçün metrikləri, etalonları və real dünya yoxlamalarını öyrənin.
🔗 Süni intellektlə tapşırıqları necə avtomatlaşdırmaq olar
Təkrarlanan işləri tapşırıqlar, alətlər və inteqrasiyalardan istifadə edərək iş axınlarına çevirin.
🔗 Süni intellekt modellərini necə sınaqdan keçirmək olar
Modelləri obyektiv şəkildə müqayisə etmək üçün qiymətləndirmələr, məlumat dəstləri və balların dizaynı.
🔗 AI ilə necə danışmaq olar
Daha yaxşı suallar verin, kontekst yaradın və daha aydın cavablar alın.
1) “Yerləşdirmə” əslində nə deməkdir (və niyə bu, sadəcə bir API deyil) 🧩
İnsanlar "modeli yerləşdirin" dedikdə, bunlardan hər hansı birini nəzərdə tuta bilərlər:
-
Tətbiqin real vaxt rejimində nəticə çıxara bilməsi üçün son nöqtəni ortaya qoyun ( Vertex AI: Modeli son nöqtəyə yerləşdirin , Amazon SageMaker: Real vaxt rejimində nəticə çıxarın )
-
Verilənlər bazasında proqnozları yeniləmək üçün hər gecə toplu qiymətləndirməni işə salın ( Amazon SageMaker Batch Transform )
-
Axın nəticəsi (hadisələr daim gəlir, proqnozlar daim çıxır) (Bulud Məlumat Axını: tam bir dəfə və ən azı bir dəfə, Bulud Məlumat Axını axın rejimləri)
-
Kənar yerləşdirmə (telefon, brauzer, quraşdırılmış cihaz və ya “zavoddakı o kiçik qutu”) (LiteRT cihaz üzərində nəticə çıxarma, LiteRT icmalı)
-
Daxili alət yerləşdirilməsi (analitiklə əlaqəli istifadəçi interfeysi, noutbuklar və ya planlaşdırılmış skriptlər)
Beləliklə, yerləşdirmə "modeli əlçatan etmək"dən daha az və daha çox aşağıdakı kimidir:
-
qablaşdırma + xidmət + miqyaslandırma + monitorinq + idarəetmə + geri qaytarma (Mavi-Yaşıl Yerləşdirmə)
Bu, sanki restoran açmaq kimidir. Əlbəttə ki, əla yemək bişirmək vacibdir. Amma yenə də binaya, işçilərə, soyuducuya, menyulara, təchizat zəncirinə və dondurucuda ağlamadan nahar tələsikliyini idarə etməyin bir yoluna ehtiyacınız var. Mükəmməl bir metafora deyil... amma başa düşürsünüz. 🍝
2) “Süni İntellektual Modelləri Necə Yerləşdirmək Olar”ın yaxşı versiyasını nə təşkil edir? ✅
"Yaxşı yerləşdirmə" ən yaxşı şəkildə darıxdırıcıdır. Təzyiq altında proqnozlaşdırıla bilən şəkildə davranır və belə olmadıqda, onu tez bir zamanda diaqnoz edə bilərsiniz.
"Yaxşı" adətən belə görünür:
-
Təkrarlana bilən qurğular
Eyni kod + eyni asılılıqlar = eyni davranış. Qorxunc "noutbukumda işləyir" abu-havası yoxdur 👻 (Docker: Konteyner nədir?) -
Aydın interfeys müqaviləsi
Girişlər, çıxışlar, sxemlər və kənar hallar müəyyən edilmişdir. Saat 2-də sürpriz tiplər yoxdur. (OpenAPI: OpenAPI nədir?,JSON Sxemi) -
Reallıqla uyğunlaşan performans.
Gecikmə və məhsuldarlıq istehsala bənzər aparat və real yüklərlə ölçülür. -
Dişlərlə monitorinq.
Hərəkəti tetikləyən metriklər, qeydlər, izlər və sürüşmə yoxlamaları (yalnız heç kimin açmadığı tabloslar deyil). (SRE Kitabı: Paylanmış Sistemlərin Monitorinqi) -
Təhlükəsiz yayım strategiyası:
Kanareyka və ya mavi-yaşıl, asan geri qaytarılma, dua tələb etməyən versiyalaşdırma. (Kanareyka Buraxılışı, Mavi-Yaşıl Yerləşdirmə) -
Xərclər barədə məlumatlılıq
“Sürətli” hesab telefon nömrəsi kimi görünənə qədər əladır 📞💸 -
Təhlükəsizlik və məxfilik
Sirlərin idarə edilməsi, giriş nəzarəti, PII idarəetməsi, audit edilə bilmə kimi sahələrdə inkişaf etdirilir. (Kubernetes Sirləri, NIST SP 800-122)
Əgər bunları ardıcıl olaraq edə bilirsənsə, artıq əksər komandalardan irəlidəsən. Düzünü desək.
3) Düzgün yerləşdirmə modelini seçin (alətləri seçməzdən əvvəl) 🧠
Real vaxt API nəticəsi⚡
Ən yaxşı nə vaxt:
-
istifadəçilərə ani nəticələr (tövsiyələr, saxtakarlıq yoxlamaları, söhbət, fərdiləşdirmə) lazımdır
-
qərarlar sorğu zamanı verilməlidir
Diqqət tədbirləri:
-
p99 gecikməsi orta səviyyədən daha vacibdir (Ölçəkdəki Quyruq, SRE Kitabı: Paylanmış Sistemlərin Monitorinqi)
-
Avtomatik miqyaslama diqqətli tənzimləmə tələb edir (Kubernetes Horizontal Pod Autoscaling)
-
Soyuq başlanğıclar gizli ola bilər... pişiyin stəkanı masadan itələməsi kimi (AWS Lambda icra mühitinin həyat dövrü)
Toplu hesablama 📦
Ən yaxşı nə vaxt:
-
Proqnozlar gecikdirilə bilər (gecəlik risk qiymətləndirməsi, satış proqnozu, ETL zənginləşdirilməsi) (Amazon SageMaker Batch Transform)
-
xərc səmərəliliyi və daha sadə əməliyyatlar istəyirsiniz
Diqqət tədbirləri:
-
məlumatların təzəliyi və doldurulması
-
xüsusiyyət məntiqini təlimlə uyğun saxlamaq
Axın nəticəsi 🌊
Ən yaxşı nə vaxt:
-
hadisələri davamlı olaraq emal edirsiniz (IoT, klik axınları, monitorinq sistemləri)
-
ciddi sorğu-cavab olmadan demək olar ki, real vaxt rejimində qərarlar istəyirsiniz
Diqqət tədbirləri:
-
exactly-once vs at-least-once semantikası (Cloud Dataflow: exactly-once vs at-least-once)
-
dövlət idarəetməsi, təkrar cəhdlər, qəribə dublikatları
Kənarların yerləşdirilməsi 📱
Ən yaxşı nə vaxt:
-
Şəbəkə asılılığı olmadan aşağı gecikmə (LiteRT cihazda nəticə çıxarma)
-
məxfilik məhdudiyyətləri
-
oflayn mühitlər
Diqqət tədbirləri:
-
model ölçüsü, batareya, kvantlaşdırma, aparat parçalanması (Təlim sonrası kvantlaşdırma (TensorFlow Model Optimallaşdırması))
-
yeniləmələr daha çətindir (təbiətdə 30 versiya istəmirsiniz...)
Əvvəlcə nümunəni, sonra yığını seçin. Əks halda, kvadrat modeli dəyirmi işləmə müddətinə məcbur edəcəksiniz. Və ya buna bənzər bir şey. 😬
4) Modelin istehsalla təmasda qalması üçün qablaşdırılması 📦🧯
Əksər "asan yerləşdirmələrin" səssizcə öldüyü yer budur.
Hər şeyin versiyası (bəli, hər şey)
-
Model artefaktı (çəkilər, qrafik, tokenizator, etiket xəritələri)
-
Xüsusiyyət məntiqi (transformasiyalar, normallaşdırma, enkoderlər)
-
Nəticə kodu (əvvəlcədən/sonrakı emal)
-
Ətraf mühit (Python, CUDA, sistem kitabxanaları)
İşləyən sadə bir yanaşma:
-
modelə buraxılış artefaktı kimi yanaşın
-
versiya etiketi ilə saxlayın
-
model kartı kimi metaməlumat faylı tələb olunur: sxem, metriklər, təlim məlumatlarının anlıq qeydləri, məlum məhdudiyyətlər (Model Hesabatı üçün Model Kartları)
Qablar kömək edir, amma onlara sitayiş etməyin 🐳
Konteynerlər əladır, çünki onlar:
-
asılılıqları dondurmaq (Docker: Konteyner nədir?)
-
quruluşları standartlaşdırmaq
-
yerləşdirmə hədəflərini sadələşdirin
Amma yenə də idarə etməlisiniz:
-
əsas şəkil yeniləmələri
-
GPU sürücülərinin uyğunluğu
-
təhlükəsizlik skanlaması
-
şəkil ölçüsü (heç kim 9GB "salam dünyası"nı sevmir) (Docker qurmağın ən yaxşı təcrübələri)
İnterfeysi standartlaşdırın
Giriş/çıxış formatınızı əvvəlcədən müəyyənləşdirin:
-
Sadəlik üçün JSON (yavaş, lakin dostcasına) (JSON Sxemi)
-
Performans üçün Protobuf (Protokol Buferlərinə Baxış)
-
şəkillər/səs üçün fayl əsaslı yükləmələr (üstəgəl metaməlumatlar)
Zəhmət olmasa, girişləri doğrulayın. Yanlış girişlər "niyə cəfəngiyat qaytarır" biletlərinin əsas səbəbidir. (OpenAPI: OpenAPI nədir?,JSON Sxemi)
5) Xidmət seçimləri - “sadə API”-dən tam model serverlərə qədər 🧰
İki ümumi marşrut var:
Seçim A: Tətbiq serveri + nəticə çıxarma kodu (FastAPI üslubunda yanaşma) 🧪
Modeli yükləyən və proqnozları qaytaran bir API yazırsınız. (FastAPI)
Müsbət cəhətləri:
-
özelleştirmek asandır
-
daha sadə modellər və ya erkən mərhələli məhsullar üçün əladır
-
sadə autentifikasiya, marşrutlaşdırma və inteqrasiya
Mənfi cəhətləri:
-
performans tənzimləməsinə (toplama, yivləmə, GPU istifadəsi) sahibsiniz
-
Bəzi təkərləri yenidən ixtira edəcəksən, bəlkə də əvvəlcə pis
Seçim B: Model server (TorchServe / Triton üslubunda yanaşma) 🏎️
Aşağıdakıları idarə edən ixtisaslaşmış serverlər:
-
paralellik (Triton: Paralel Model İcrası)
-
çoxlu model
-
GPU səmərəliliyi
-
standartlaşdırılmış son nöqtələr (TorchServe sənədləri, Triton Inference Server sənədləri)
Müsbət cəhətləri:
-
qutudan daha yaxşı performans nümunələri
-
xidmət və biznes məntiqi arasında daha təmiz ayrılıq
Mənfi cəhətləri:
-
əlavə əməliyyat mürəkkəbliyi
-
konfiqurasiya... duş temperaturunu tənzimləmək kimi qəribə hiss oluna bilər
Hibrid model çox yaygındır:
-
nəticə çıxarma üçün model server (Triton: Dinamik toplama)
-
Avtorizasiya, sorğu formalaşdırması, biznes qaydaları və sürət məhdudiyyəti üçün nazik API şlüzü (API Şlüzün azaldılması)
6) Müqayisə Cədvəli - yerləşdirməyin məşhur yolları (səmimi əhval-ruhiyyə ilə) 📊😌
Aşağıda insanların süni intellekt modellərini necə yerləşdirməyi öyrənərkən istifadə etdikləri variantların praktik bir təsviri verilmişdir .
| Alət / Yanaşma | Tamaşaçı | Qiymət | Niyə işləyir |
|---|---|---|---|
| Docker + FastAPI (və ya oxşar) | Kiçik komandalar, startaplar | Sərbəst | Sadə, çevik, çatdırılma sürətli - hər miqyaslama problemini "hiss edəcəksiniz" (Docker, FastAPI) |
| Kubernetes (Özün Hazırla) | Platforma komandaları | İnfra-asılı | Nəzarət + ölçeklenebilirlik… həmçinin, çoxlu düymələr, bəziləri lənətə gəlmişdi (Kubernetes HPA) |
| İdarə olunan ML platforması (bulud ML xidməti) | Daha az əməliyyat istəyən komandalar | Ödənişinizi istədiyiniz kimi edin | Daxili yerləşdirmə iş axınları, monitorinq qarmaqları - bəzən həmişə aktiv olan son nöqtələr üçün baha başa gəlir (Vertex AI yerləşdirməsi, SageMaker real vaxt nəticəsi) |
| Serversiz funksiyalar (işıq çıxarışı üçün) | Hadisəyə əsaslanan tətbiqlər | İstifadəyə görə ödəniş | Sürətli tıxac üçün əladır - amma soyuq başlanğıclar və model ölçüsü gününüzü korlaya bilər 😬 (AWS Lambda soyuq başlanğıclar) |
| NVIDIA Triton Nəticə Serveri | Performansa yönəlmiş komandalar | Pulsuz proqram təminatı, infrastruktur xərcləri | Əla GPU istifadəsi, toplu yükləmə, çoxmodel - konfiqurasiya səbr tələb edir (Triton: Dinamik toplu yükləmə) |
| TorchServe | PyTorch-a ağırlıq verən komandalar | Pulsuz proqram təminatı | Layiqli standart xidmət nümunələri - yüksək miqyaslı üçün tənzimləmə tələb oluna bilər (TorchServe sənədləri) |
| BentoML (qablaşdırma + porsiya) | ML mühəndisləri | Pulsuz nüvə, əlavələr fərqlidir | Hamar qablaşdırma, gözəl geliştirici təcrübəsi - yenə də infrastruktur seçimlərinə ehtiyacınız var (yerləşdirmək üçün BentoML qablaşdırma) |
| Ray Serve | Paylanmış sistemlər üzrə mütəxəssislər | İnfra-asılı | Üfüqi şəkildə miqyaslanır, boru kəmərləri üçün yaxşıdır - kiçik layihələr üçün "böyük" hiss olunur (Ray Serve sənədləri) |
Cədvəl qeydi: “Pulsuz” real həyat terminologiyasıdır. Çünki heç vaxt pulsuz deyil. Yuxunuz olsa belə, həmişə bir yerdə bir hesab olur. 😴
7) Performans və miqyaslanma - gecikmə, məhsuldarlıq və həqiqət 🏁
Performans tənzimləməsi yerləşdirmənin bir sənətkarlığa çevrildiyi yerdir. Məqsəd "sürətli" deyil. Məqsəd ardıcıl olaraq kifayət qədər sürətlidir.
Əhəmiyyətli olan əsas ölçülər
-
p50 gecikməsi: tipik istifadəçi təcrübəsi
-
p95 / p99 gecikməsi: qəzəb yaradan quyruq (Miqyasda Quyruq, SRE Kitabı: Paylanmış Sistemlərin Monitorinqi)
-
ötürmə qabiliyyəti: saniyədə sorğular (və ya generativ modellər üçün saniyədə tokenlər)
-
səhv nisbəti: açıq-aydındır, amma bəzən yenə də nəzərə alınmır
-
Resurs istifadəsi: CPU, GPU, yaddaş, VRAM (SRE Kitabı: Paylanmış Sistemlərin Monitorinqi)
Çəkmək üçün ümumi qollar
-
birləşdirin
. Məhsuldarlıq üçün əladır, həddindən artıq çox istifadə etsəniz, gecikməyə zərər verə bilər. (Triton: Dinamik toplulaşdırma) -
Kvantlaşdırma
Aşağı dəqiqlik (INT8 kimi) nəticə çıxarmağı sürətləndirə və yaddaşı azalda bilər. Dəqiqliyi bir qədər azalda bilər. Bəzən təəccüblü deyil. (Təlim sonrası kvantlaşdırma) -
Kompilyasiya/optimallaşdırma
ONNX ixracı, qrafik optimallaşdırıcıları, TensorRT kimi axınlar. Güclüdür, lakin ayıklama kəskinləşə bilər 🌶️ (ONNX, ONNX Runtime model optimallaşdırmaları) -
Keşləmə
Girişlər təkrarlanırsa (və ya yerləşdirmələri keşləyə bilərsinizsə), çox qənaət edə bilərsiniz. -
Avtomatik miqyaslama
CPU/GPU istifadəsinə, növbə dərinliyinə və ya sorğu tezliyinə görə miqyaslanır. Növbə dərinliyi az qiymətləndirilir. (Kubernetes HPA)
Qəribə, lakin doğru bir məsləhət: istehsalata bənzər faydalı yük ölçüləri ilə ölçün. Kiçik sınaq faydalı yükləri sizə yalan danışır. Onlar nəzakətlə gülümsəyirlər və sonra sizə xəyanət edirlər.
8) Monitorinq və müşahidə - kor-koranə uçmayın 👀📈
Model monitorinqi sadəcə iş vaxtının monitorinqi deyil. Bilmək istəyirsiniz, əgər:
-
xidmət sağlamdır
-
model özünü aparır
-
məlumatlar sürüşür
-
Proqnozlar daha az etibarlı hala gəlir (Vertex AI Model Monitorinqinə ümumi baxış, Amazon SageMaker Model Monitor)
Nə izlənilməlidir (minimum uyğun dəst)
Xidmət sağlamlığı
-
sorğu sayı, səhv dərəcəsi, gecikmə paylanmaları (SRE Kitabı: Paylanmış Sistemlərin Monitorinqi)
-
doyma (CPU/GPU/yaddaş)
-
növbə uzunluğu və növbədəki vaxt
Model davranışı
-
giriş xüsusiyyət paylanmaları (əsas statistika)
-
yerləşdirmə normaları (yerləşdirmə modelləri üçün)
-
çıxış paylanmaları (etimad, sinif qarışığı, bal diapazonları)
-
Girişlərdə anomaliya aşkarlanması (zibil daxil olur, zibil xaric olur)
Məlumat sürüşməsi və konsepsiya sürüşməsi
-
Drift xəbərdarlıqları tətbiq oluna bilən olmalıdır (Vertex AI: Monitor xüsusiyyəti əyri və sürüşmə, Amazon SageMaker Model Monitor)
-
xəbərdarlıq spamından qaçın - bu, insanlara hər şeyi görməməzlikdən gəlməyi öyrədir
Qeydiyyat, amma "hər şeyi əbədi olaraq qeyd et" yanaşması deyil 🪵
Qeyd:
-
sorğu ID-ləri
-
model versiyası
-
sxem doğrulama nəticələri (OpenAPI: OpenAPI nədir?)
-
Minimal strukturlaşdırılmış faydalı yük metaməlumatları (xam PII deyil) (NIST SP 800-122)
Məxfiliklə bağlı diqqətli olun. Qeydlərinizin məlumat sızmasına çevrilməsini istəmirsiniz. (NIST SP 800-122)
9) CI/CD və yayım strategiyaları - modellərə real buraxılışlar kimi yanaşın 🧱🚦
Etibarlı yerləşdirmələr istəyirsinizsə, bir boru kəməri qurun. Hətta sadə bir dənə belə.
Möhkəm bir axın
-
Əvvəlcədən emal və sonrakı emal üçün vahid testlər
-
Məlum giriş-çıxış "qızıl dəst" ilə inteqrasiya testi
-
Yük testinin əsas xətti (hətta yüngül olanı belə)
-
Artefakt (konteyner + model) qurun (Docker-in ən yaxşı təcrübələrini qurmaq)
-
Səhnələşdirməyə yerləşdirin
-
Kanareykanın kiçik bir hissəyə buraxılması (Kanareykanın buraxılması)
-
Tədricən yüksəlin
-
Əsas hədlərdə avtomatik geri qaytarma (Mavi-Yaşıl Yerləşdirmə)
Ağlınızı qoruyan yayma nümunələri
-
Canary: əvvəlcə 1-5% trafikə qədər buraxın (Canary Release)
-
Mavi-yaşıl: yeni versiyanı köhnə versiya ilə birlikdə işlədin, hazır olduqda çevirin (Mavi-Yaşıl Yerləşdirmə)
-
Kölgə testi: yeni modelə real trafik göndərin, lakin nəticələrdən istifadə etməyin (qiymətləndirmə üçün əladır) (Microsoft: Kölgə testi)
Və son nöqtələrinizi və ya marşrutunuzu model versiyasına görə versiyalaşdırın. Gələcəkdə sizə təşəkkür edəcəksiniz. Hazırkı versiyada da sizə təşəkkür edəcəksiniz, amma səssizcə.
10) Təhlükəsizlik, məxfilik və “xahiş edirəm məlumat sızdırmayın” 🔐🙃
Təhlükəsizlik çağırılmamış qonaq kimi gec gəlməyə meyllidir. Onu tez dəvət etmək daha yaxşıdır.
Praktik yoxlama siyahısı
-
Doğrulama və avtorizasiya (modeli kim çağıra bilər?)
-
Qiymət məhdudlaşdırılması (sui-istifadə və təsadüfi fırtınalardan qorunmaq) (API Gateway throttling)
-
Sirlərin idarə edilməsi (kodda açar yoxdur, konfiqurasiya fayllarında da açar yoxdur...) (AWS Secrets Manager, Kubernetes Secrets)
-
Şəbəkə nəzarətləri (özəl alt şəbəkələr, xidmətdən xidmətə siyasətlər)
-
Audit qeydləri (xüsusilə həssas proqnozlar üçün)
-
Məlumatların minimuma endirilməsi (yalnız lazım olanları saxlayın) (NIST SP 800-122)
Model şəxsi məlumatlara toxunarsa:
-
redakt və ya heş identifikatorları
-
Xam yüklərin qeydiyyatından çəkinin (NIST SP 800-122)
-
saxlama qaydalarını müəyyən edin
-
sənəd məlumat axını (darıxdırıcı, lakin qoruyucu)
Həmçinin, təcili inyeksiya və çıxış sui-istifadəsi generativ modellər üçün əhəmiyyətli ola bilər. Əlavə edin: (LLM Tətbiqləri üçün OWASP Top 10, OWASP: Təcili inyeksiya)
-
giriş dezinfeksiya qaydaları
-
çıxış filtrləməsi lazım olduqda
-
alət çağırışı və ya verilənlər bazası əməliyyatları üçün mühafizə rayları
Heç bir sistem mükəmməl deyil, amma onu daha az kövrək edə bilərsiniz.
11) Ümumi tələlər (yəni adi tələlər) 🪤
Budur klassiklər:
-
Təlim-xidmət əyriliyi
Əvvəlcədən emal təlim və istehsal arasında fərqlənir. Birdən dəqiqlik azalır və heç kim bunun səbəbini bilmir. (TensorFlow Məlumatlarının Doğrulanması: təlim-xidmət əyriliyini aşkar edin) -
Sxem təsdiqlənməsi yoxdur.
Yuxarı axındakı bir dəyişiklik hər şeyi pozur. Həmişə yüksək səslə də olmur... (JSON Sxemi, OpenAPI: OpenAPI nədir?) -
İstifadəçilər qəzəbli olduqları zaman quyruq gecikməsini nəzərə almamaq p99-dur. ( The Quyruq at Miqyas )
-
Qiymət GPU son nöqtələrinin boş işləməsini unutmaq
, evinizdəki bütün işığı yandırmaq kimidir, amma lampalar puldan ibarətdir. -
Geriyə çəkilmə planı yoxdur.
“Biz sadəcə yenidən yerləşdirəcəyik” plan deyil. Bu, trençkot geyinmək ümididir. (Mavi-Yaşıl Yerləşdirmə) -
Yalnız işləmə müddətinin monitorinqi
Model səhv olduqda xidmət işlək vəziyyətdə ola bilər. Bu, mübahisəsiz olaraq daha pisdir. (Vertex AI: Monitor xüsusiyyəti, əyrilik və sürüşmə, Amazon SageMaker Model Monitor)
Əgər bunu oxuyursunuzsa və "bəli, biz bunlardan ikisini edirik" deyə düşünürsünüzsə, kluba xoş gəlmisiniz. Klubda qəlyanaltılar və yüngül stress var. 🍪
12) Xülasə - Süni intellekt modellərini ağlını itirmədən necə yerləşdirmək olar 😄✅
Süni intellekt əsl məhsula çevrildiyi yerdir. Bu, cazibədar deyil, amma etibar qazanıldığı yerdir.
Qısa xülasə
-
Əvvəlcə yerləşdirmə modelinizə qərar verin (real vaxt, toplu, yayım, kənar) 🧭 (Amazon SageMaker Batch Transform, Cloud Dataflow yayım rejimləri, LiteRT cihazda nəticə)
-
Təkrar istehsal üçün paket (hər şeyi versiyalaşdırın, məsuliyyətlə konteynerləşdirin) 📦 (Docker konteynerləri)
-
Performans ehtiyaclarına əsasən xidmət strategiyasını seçin (sadə API və model server) 🧰 (FastAPI, Triton: Dinamik toplama)
-
Yalnız ortalamaları deyil, p95/p99 gecikməsini ölçün 🏁 (Miqyasdakı Quyruq)
-
Xidmət sağlamlığı və model davranışı üçün monitorinq əlavə edin 👀 (SRE Kitabı: Paylanmış Sistemlərin Monitorinqi, Vertex AI Model Monitorinqi)
-
Kanareyka və ya mavi-yaşıl ilə təhlükəsiz şəkildə yayın və geri qaytarmağı asanlaşdırın 🚦 (Kanareyka Buraxılışı, Mavi-Yaşıl Yerləşdirmə)
-
İlk gündən təhlükəsizlik və məxfilik şəraitində bişirin 🔐 (AWS Secrets Manager, NIST SP 800-122)
-
Darıxdırıcı, proqnozlaşdırıla bilən və sənədləşdirilmiş saxlayın - darıxdırıcı gözəldir 😌
Bəli, süni intellekt modellərini necə yerləşdirmək olar, əvvəlcə alovlu boulinq topları ilə hoqqabazlıq etmək kimi hiss oluna bilər. Amma kanalınız sabitləşdikdən sonra qəribə dərəcədə məmnunedici olur. Sanki nəhayət, dağınıq bir çekmece təşkil etmək kimi... yalnız çekmece istehsal trafikidir.
Real dünya nümunəsi: Dəstək bileti çeşidləmə modelinin tətbiqi
Ssenari
Həftədə 12 dəstək agenti və təxminən 900 müştəri bileti olan uydurma, lakin real SaaS şirkəti təsəvvür edin. Komanda, insan agenti cavab verməzdən əvvəl daxil olan biletləri kateqoriya, təcililik və təklif olunan marşrutlaşdırmaya görə təsnif etmək üçün süni intellekt modeli istəyir.
Bu, tam avtomatlaşdırılmış dəstək botu deyil. Model müştərilərə cavab göndərmir. Sadəcə biletləri daha sürətli yönləndirməyə, riskli halları qeyd etməyə və agentlərə daha təmiz bir başlanğıc nöqtəsi verməyə kömək edir.
Burada ən yaxşı yerləşdirmə modeli adətən real vaxt API nəticəsidir. Hər yeni bilet yardım masasına daxil olur, süni intellekt xidməti onu bir neçə yüz millisaniyə ərzində qiymətləndirir və yardım masası proqnozlaşdırılan kateqoriyanı, prioriteti, etibarlılıq balını və model versiyasını saxlayır.
Köməkçinin nəyə ehtiyacı var
Faydalı girişlər:
bilet mövzusu
bilet gövdəsi
müştəri planının növü
hesab bölgəsi
məhsul sahəsi, əgər artıq məlumdursa
son 30 gün ərzində əvvəlki bilet sayı
Faydalı qaydalar:
Əgər xam müştəri mesajları şəxsi məlumatlar ehtiva edirsə, heç vaxt qeyd etməyin
ödəniş mübahisələrini, hüquqi təhdidləri, hesab silmə tələblərini və təhlükəsizlik problemlərini insan baxışına göndərin
yalnız etibarlılıq müəyyən edilmiş bir həddən, məsələn, 0.85-dən yuxarı olduqda avtomatik marşrutlaşdırma
model versiyasını hər proqnozla saxlayın
model xidməti yavaş və ya əlçatan deyilsə, əl ilə çeşidlənməyə geri dönüş
Nümunə təlimat
Siz dəstək bilet çeşidləmə köməkçisisiniz. Hər bileti bir kateqoriyaya təsnif edin: Ödəniş, Giriş, Xəta Hesabatı, Xüsusiyyət Sorğusu, Hesab Ləğvi, Təhlükəsizlik və ya Digər.
Kateqoriyanı, təcililik səviyyəsini, etibarlılıq balını, qısa səbəbi və tövsiyə olunan dəstək növbəsini qaytarın.
Çatışmayan faktları uydurmayın. Əgər cəzada hüquqi, təhlükəsizlik, ödənişin uğursuzluğu, hesabın silinməsi və ya müştərinin qəzəbli ifadələri varsa, onu insan tərəfindən yoxlanılması üçün işarələyin.
Əgər etibarlılıq 0,85-dən aşağıdırsa, tövsiyə olunan növbə kimi "Əl ilə Baxış" qaytarın.
Nümunə çıxışı
Zəif çıxış:
Kateqoriya: Xəta
Prioriteti: Yüksək
Dəstəyə göndərin.
Daha yaxşı çıxış:
Kateqoriya: Giriş
Təcililik: Orta
Etibarlılıq: 0.91
Tövsiyə olunan növbə: Hesaba Giriş
Səbəb: Müştəri parolunu sıfırladıqdan sonra hesabına daxil ola bilmir. Heç bir təhlükəsizlik təhdidi və ya ödəniş problemi qeyd edilməyib.
İnsan tərəfindən yoxlama tələb olunur: Xeyr
Model versiyası: ticket-triage-v1.3
Daha yaxşı nəticəni yoxlamaq daha asandır, çünki ona etibarlılıq balı, marşrutlaşdırma qərarı, səbəb və model versiyası daxildir.
Bunu necə sınaqdan keçirmək olar
Modelə canlı trafik göndərməzdən əvvəl, real, lakin anonimləşdirilmiş biletlərdən ibarət kiçik bir "qızıl dəst" yaradın.
Sadə bir test dəsti aşağıdakıları əhatə edə bilər:
50 ödəniş bileti
50 giriş bileti
50 səhv hesabatı
30 ləğv tələbi
20 təhlükəsizlik həssas bilet
20 qarışıq və ya qarışıq kateqoriyalı bilet
Sonra yoxlayın:
Model insan rəyçisi ilə eyni kateqoriyanı seçirmi?
Təhlükəsizlik, hüquqi və ləğv biletlərini düzgün şəkildə artırırmı?
Etibarlılıq aşağı olduqda "Əl ilə nəzərdən keçirmə" qaytarırmı?
p95 gecikməsi komandanın hədəfi altında qalırmı?
Model əlçatan olmadıqda xidmət təhlükəsiz şəkildə sıradan çıxırmı?
Tətbiq üçün əvvəlcə kölgə testindən istifadə edin. Yeni modelə real biletlər göndərin, lakin hələlik proqnozlarından istifadə etməyin. Bir neçə gün ərzində onun çıxışını normal insan triajı ilə müqayisə edin. Nəticələr sabitdirsə, əvvəlcə 5%, sonra 25%, sonra isə 100% kanareyka buraxılışına keçin.
Nəticə
İş axınından istifadə etməzdən əvvəl və sonra 100 nümunə biletin vaxtına əsaslanan illüstrativ nəticə:
Əl ilə çeşidləmə müddəti hər bilet üçün 6 dəqiqədən 1 dəqiqə 40 saniyəyə düşdü
Komanda 100 biletlə təxminən 7,2 saat qənaət etdi
220 biletli qızıl dəstdə insan rəyçisi ilə kateqoriya razılaşması 87% təşkil etmişdir
20 təhlükəsizliyə həssas test biletinin 100%-i insan tərəfindən nəzərdən keçirilməyə göndərildi
p95 gecikməsi istehsala bənzər yüklərdə 480 ms idi
p99 gecikməsi 910 ms idi
Köhnə model son nöqtəsi kanareyka buraxılışı zamanı aktiv qaldığı üçün geri qaytarma müddəti 2 dəqiqədən az idi
Bu rəqəmlər universal etalonlar deyil. Bunlar komandanın zamanlama triaj tapşırıqları, proqnozları etiketlənmiş test dəsti ilə müqayisə etmək və son nöqtəni real bilet yükləri ilə yükləmə testi etməklə təkrarlaya biləcəyi nümunə ölçmələrdir.
Nə səhv gedə bilər
Ən böyük risk modelə həddindən artıq etibar etməkdir. “Aşağı təcililik” işarəsi ilə qeyd olunan bilet, xüsusən də müştəri qeyri-müəyyən yazırsa, ciddi təhlükəsizlik problemi yarada bilər.
Digər ümumi səhvlər:
real müştəri biletləri ilə uyğun gəlməyən cilalanmış test biletlərindən istifadə etməklə
şəxsi məlumatlarla tam müştəri mesajlarını qeyd etmək
model versiyasını hər proqnozla saxlamıram
Etibarlılıq aşağı olduqda belə, hər bileti avtomatik yönləndirmək
əl ilə ehtiyat növbəsini unutmaq
orta gecikməni ölçmək, lakin p95 və p99-u nəzərə almamaq
dəstək qrupu növbələrini dəyişdirdikdən sonra köhnə kateqoriyaların modeldə qalmasına icazə vermək
Praktik yemək
Yaxşı bir süni intellekt yerləşdirməsi böyük bir başlanğıc tələb etmir. Bir dar iş axını, bir aydın interfeys, bir qızıl test dəsti və bir təhlükəsiz geri dönüş yolu ilə başlayın. Əgər model riski gizlətmədən vaxta qənaət edirsə, miqyaslandırmağa dəyər bir yerləşdirməniz var.
Tez-tez verilən suallar
Süni intellekt modelini istehsalda tətbiq etmək nə deməkdir
Süni intellekt modelinin yerləşdirilməsi adətən proqnozlaşdırma API-sinin ifşasından daha çox şey tələb edir. Praktikada, bu, modeli və onun asılılıqlarını qablaşdırmanı, xidmət nümunəsinin (real vaxt, toplu, axın və ya kənar) seçilməsini, etibarlılıqla miqyaslandırılmasını, sağlamlığın və sürüşmənin monitorinqini və təhlükəsiz yayma və geri qaytarma yollarının qurulmasını əhatə edir. Möhkəm yerləşdirmə yük altında proqnozlaşdırıla bilən dərəcədə sabit qalır və bir şey səhv getdikdə diaqnoz edilə bilən qalır.
Real vaxt, toplu, yayım və ya kənar yerləşdirmə arasında necə seçim etməli
Proqnozların nə vaxt lazım olduğuna və altında işlədiyiniz məhdudiyyətlərə əsasən yerləşdirmə modelini seçin. Real vaxt API-ları gecikmənin vacib olduğu interaktiv təcrübələrə uyğundur. Toplu qiymətləndirmə gecikmələr məqbul olduqda və xərc səmərəliliyi potensialı olduqda ən yaxşı işləyir. Axın, xüsusən çatdırılma semantikası çətinləşdikdə, davamlı hadisə emalına uyğundur. Kənar yerləşdirmə oflayn əməliyyat, məxfilik və ya ultra aşağı gecikmə tələbləri üçün idealdır, baxmayaraq ki, yeniləmələri və aparat dəyişikliyini idarə etmək çətinləşir.
"Noutbukumda işləyir" yerləşdirmə xətalarının qarşısını almaq üçün hansı versiyanı seçməliyəm
Versiya yalnız model çəkilərindən daha çoxdur. Tipik olaraq, versiyalaşdırılmış model artefaktı (tokenizatorlar və ya etiket xəritələri daxil olmaqla), əvvəlcədən emal və xüsusiyyət məntiqi, nəticə çıxarma kodu və tam işləmə mühiti (Python/CUDA/sistem kitabxanaları) istəyəcəksiniz. Modeli etiketlənmiş versiyaları və sxem gözləntilərini, qiymətləndirmə qeydlərini və məlum məhdudiyyətləri təsvir edən yüngül metaməlumatları olan bir buraxılış artefaktı kimi qəbul edin.
Sadə FastAPI tipli xidmət və ya xüsusi model server ilə yerləşdirmək
Sadə bir tətbiq serveri (FastAPI üslubunda bir yanaşma) erkən məhsullar və ya sadə modellər üçün yaxşı işləyir, çünki marşrutlaşdırma, təsdiqləmə və inteqrasiya üzərində nəzarəti özündə saxlayırsınız. Model serveri (TorchServe və ya NVIDIA Triton üslubunda) qutudan daha güclü toplaşma, paralellik və GPU səmərəliliyi təmin edə bilər. Bir çox komanda hibrid üzərində işləyir: nəticə çıxarmaq üçün model server və təsdiqləmə, sorğu formalaşdırma və sürət limitləri üçün nazik bir API təbəqəsi.
Dəqiqliyi pozmadan gecikməni və ötürmə qabiliyyətini necə artırmaq olar
Kiçik testlər yanılda biləcəyi üçün real yüklü istehsala bənzər aparatlarda p95/p99 gecikməsini ölçməklə başlayın. Ümumi təsirlərə toplulaşdırma (daha yaxşı ötürmə qabiliyyəti, potensial olaraq daha pis gecikmə), kvantlaşdırma (daha kiçik və daha sürətli, bəzən orta dəqiqliklə kompromislər), kompilyasiya və optimallaşdırma axınları (ONNX/TensorRT kimi) və təkrarlanan girişləri və ya yerləşdirmələri keşləmə daxildir. Növbə dərinliyinə əsaslanan avtomatik miqyaslama quyruq gecikməsinin yuxarıya doğru sürünməsinin qarşısını ala bilər.
"Son nöqtə bitdi"dən başqa hansı monitorinqə ehtiyac var?
İşləmə müddəti kifayət deyil, çünki proqnozlaşdırma keyfiyyəti azalarkən xidmət sağlam görünə bilər. Ən azı, sorğu həcmini, səhv nisbətini və gecikmə paylanmalarını, üstəgəl CPU/GPU/yaddaş və növbə vaxtı kimi doyma siqnallarını izləyin. Model davranışı üçün giriş və çıxış paylanmalarını əsas anomaliya siqnalları ilə birlikdə izləyin. Səs-küylü xəbərdarlıqlar əvəzinə hərəkəti tetikləyən sürüşmə yoxlamaları və sorğu ID-lərini, model versiyalarını və sxem doğrulama nəticələrini əlavə edin.
Yeni model versiyalarını necə təhlükəsiz şəkildə tətbiq etmək və tez bir zamanda bərpa etmək olar
Tam buraxılışlar kimi modellərə əvvəlcədən emal və sonrakı emalı sınaqdan keçirən, inteqrasiya yoxlamalarını "qızıl dəst"ə qarşı aparan və yük bazası yaradan CI/CD boru kəməri ilə yanaşın. Yayımlar üçün kanareyka tədricən trafik buraxır, mavi-yaşıl isə dərhal geri qayıtmaq üçün köhnə versiyanı aktiv saxlayır. Kölgə testi istifadəçilərə təsir etmədən yeni modeli real trafikdə qiymətləndirməyə kömək edir. Geri qayıtma ikinci dərəcəli mexanizm deyil, birinci dərəcəli mexanizm olmalıdır.
Süni intellekt modellərini necə yerləşdirməyi öyrənərkən ən çox rast gəlinən tələlər
Təlim-xidmət əyriliyi klassik haldır: əvvəlcədən emal təlim və istehsal arasında fərqlənir və performans sakitcə pisləşir. Digər tez-tez rast gəlinən problem sxem validasiyasının olmamasıdır, burada yuxarı axın dəyişikliyi girişləri incə şəkildə pozur. Komandalar həmçinin quyruq gecikməsini az qiymətləndirir və orta göstəricilərə həddindən artıq diqqət yetirir, xərcləri gözardı edir (boş GPU-lar tez bir zamanda əlavə olunur) və geri qayıtma planlaşdırmasını atlayırlar. Yalnız işləmə müddətini izləmək xüsusilə risklidir, çünki "yuxarı, lakin səhv" aşağıdan daha pis ola bilər.
İstinadlar
-
Amazon Veb Xidmətləri (AWS) - Amazon SageMaker: Real vaxt nəticəsi - docs.aws.amazon.com
-
Amazon Veb Xidmətləri (AWS) - Amazon SageMaker Batch Transform - docs.aws.amazon.com
-
Amazon Veb Xidmətləri (AWS) - Amazon SageMaker Model Monitoru - docs.aws.amazon.com
-
Amazon Veb Xidmətləri (AWS) - API Gateway sorğusunun azaldılması - docs.aws.amazon.com
-
Amazon Veb Xidmətləri (AWS) - AWS Secrets Manager: Giriş - docs.aws.amazon.com
-
Amazon Veb Xidmətləri (AWS) - AWS Lambda icra mühitinin həyat dövrü - docs.aws.amazon.com
-
Google Cloud - Vertex AI: Modeli son nöqtəyə yerləşdirin - docs.cloud.google.com
-
Google Cloud - Vertex AI Model Monitorinqinə ümumi baxış - docs.cloud.google.com
-
Google Cloud - Vertex AI: Monitor funksiyası əyrilik və sürüşmə - docs.cloud.google.com
-
Google Cloud Bloqu - Dataflow: tam bir dəfə və ən azı bir dəfə yayım rejimləri - cloud.google.com
-
Google Cloud - Cloud Dataflow axın rejimləri - docs.cloud.google.com
-
Google SRE Kitabı - Paylanmış Sistemlərin Monitorinqi - sre.google
-
Google Araşdırma - Ölçüdəki Quyruq - research.google
-
LiteRT (Google AI) - LiteRT icmalı - ai.google.dev
-
LiteRT (Google AI) - LiteRT cihazda nəticə çıxarmaq - ai.google.dev
-
Docker - Konteyner nədir? - docs.docker.com
-
Docker - Docker ən yaxşı təcrübələrini qurur - docs.docker.com
-
Kubernetes - Kubernetes sirləri - kubernetes.io
-
Kubernetes - Üfüqi Pod Avtomiqyaslama - kubernetes.io
-
Martin Fowler - Canary Release - martinfowler.com
-
Martin Fowler - Mavi-Yaşıl Yerləşdirmə - martinfowler.com
-
OpenAPI Təşəbbüsü - OpenAPI nədir? - openapis.org
-
JSON Sxemi - (sayta istinad edilib) - json-schema.org
-
Protokol Buferləri - Protokol Buferlərinə Baxış - protobuf.dev
-
FastAPI - (sayta istinad edilib) - fastapi.tiangolo.com
-
NVIDIA - Triton: Dinamik Batching və Paralel Model İcrası - docs.nvidia.com
-
NVIDIA - Triton: Paralel Model İcrası - docs.nvidia.com
-
NVIDIA - Triton Inference Server sənədləri - docs.nvidia.com
-
PyTorch - TorchServe sənədləri - docs.pytorch.org
-
BentoML - Yerləşdirmə üçün qablaşdırma - docs.bentoml.com
-
Ray - Ray Serve docs - docs.ray.io
-
TensorFlow - Təlimdən sonrakı kvantlaşdırma (TensorFlow Model Optimallaşdırması) - tensorflow.org
-
TensorFlow - TensorFlow Məlumatlarının Doğrulanması: təlimə xidmət edən əyriliyi aşkar edin - tensorflow.org
-
ONNX - (sayta istinad edilib) - onnx.ai
-
ONNX Runtime - Model optimallaşdırmaları - onnxruntime.ai
-
NIST (Milli Standartlar və Texnologiya İnstitutu) - NIST SP 800-122 - csrc.nist.gov
-
arXiv - Model Hesabatı üçün Model Kartları - arxiv.org
-
Microsoft - Kölgə testi - microsoft.github.io
-
OWASP - LLM Tətbiqləri üçün OWASP-ın Ən Yaxşı 10-luğu - owasp.org
-
OWASP GenAI Təhlükəsizlik Layihəsi - OWASP: Sürətli Enjeksiyon - genai.owasp.org