AI modeli lokal testdə 200 millisaniyəyə cavab verir. Production-a çıxandan sonra isə eyni endpoint bəzən iki saniyə gözlədir, GPU boş görünür, queue böyüyür və autoscaler gec ayılır. Tanış mənzərədir. Modelin sürətli olması, onu təqdim edən sistemin də sürətli olması demək deyil.
Yüksək trafikli AI inference servisində əsas sual budur: dəyişkən yükü qəbul edib GPU-nu səmərəli işlədərkən latency-ni necə nəzarətdə saxlamaq olar? Cavab bir komponentdə deyil. Trafikin girişindən model cavabına qədər bütün yol eyni latency büdcəsini bölüşür.
Request yolu əvvəlcədən məhdudlaşdırılmalıdır
İstifadəçi request-i əvvəlcə gateway-ə çatır. Burada autentifikasiya, request ölçüsü, rate limit və ümumi deadline yoxlanır. Sonra sorğu modelə uyğun queue-ya düşür, scheduler uyğun request-ləri batch edir, inference instance hesablamanı aparır, nəticə post-processing mərhələsindən keçib geri qayıdır.
Diaqram — orijinal məqalədə
Bu axında API gateway həddən artıq böyük input-u və icazəsiz trafiki erkən kəsir. Model queue ani sıçrayışı yumşaldır, amma sonsuz anbar deyil. Batch scheduler eyni modelə gedən uyğun sorğuları qruplaşdırır. Deadline bitibsə, artıq istifadəçiyə faydası qalmayan işi GPU-ya ötürmək əvəzinə timeout cavabı qaytarılır.
Queue üçün həm maksimum uzunluq, həm də maksimum gözləmə vaxtı təyin edilməlidir, çünki əks halda servis overload zamanı cavab vermək əvəzinə köhnə request-ləri yığır. GPU yüz faiz işləyə bilər, lakin istifadəçilər çoxdan cavab gözləməkdən vaz keçiblər.
Bu, faydalı iş deyil.
Batching throughput verir, pulsuz deyil
GPU bir neçə input-u birlikdə emal edəndə çox vaxt resursdan daha yaxşı istifadə edir. NVIDIA Triton-un dynamic batching mexanizmi ayrı inference request-lərini serverdə bir batch daxilində birləşdirir. Burada iki tənzimləmə bir-birinə qarşı işləyir: böyük batch throughput-u yüksəldə bilər, batch-in dolmasını gözləmək isə latency-yə əlavə olunur.
Ona görə max_batch_size rəqəmi GPU yaddaşına sığan ən böyük ədəd kimi seçilmir. Real input ölçüləri ilə sınaq aparılır, sonra p95 və p99 latency büdcəsi aşılmadan ən yaxşı throughput verən nöqtə götürülür. Mətn generasiyasında prompt uzunluqlarının kəskin fərqlənməsi işi daha da qəlizləşdirir. Qısa request uzun request-in arxasında ilişə bilər; uzunluğa görə ayrı queue-lar və ya scheduler siyasəti burada kömək edir.
Batching stateless modellərdə daha rahatdır. Request-lər arasında vəziyyət saxlayan modeldə ardıcıllıq və eyni instance-a yönləndirmə ayrıca qorunmalıdır; hər modeli eyni queue və batch konfiqurasiyasına salmaq rahat görünsə də workload-lar eyni davranmır.
Autoscaling hansı siqnalı görməlidir?
CPU əsasında autoscaling klassik web tətbiqində məntiqli başlanğıcdır. GPU inference servisində isə CPU aşağı olduğu halda queue sürətlə böyüyə bilər. Kubernetes Horizontal Pod Autoscaler resource metric-lərlə yanaşı custom və external metric-lərdən də istifadə edə bilir. Bu imkan queue dərinliyi, queue-da gözləmə müddəti və aktiv inference sayı kimi siqnalları scaling qərarına qatmağa şərait yaradır.
Tək GPU utilization da yetərli deyil. Yüz faiz utilization yaxşı batching nəticəsi ola bilər; eyni göstərici boğulmuş sistem də göstərə bilər. Fərqi queue açır. Queue yaşı və p99 latency artırsa, əlavə capacity lazımdır, queue boş və latency normaldırsa yüksək utilization öz-özlüyündə qəza siqnalı sayılmır.
Yeni replica saniyələr içində hazır olmaya bilər. Yol uzundur: image çəkilir, model faylı endirilir, çəkilər CPU və ya GPU yaddaşına yerləşdirilir, bəzən warmup inference işləyir. Scaling siyasəti bu başlanğıc vaxtından daha gec reaksiya verirsə, pik yük artıq queue-nu doldurmuş olacaq; minimum isti capacity və proqnozlaşdırılan trafik üçün əvvəlcədən scale-out buna görə vacibdir.
Model yüklənərkən health check-ləri ayırmaq lazımdır. Kubernetes startup probe tətbiqin başlanğıcını tamamlamasına vaxt verir; readiness uğursuz olduqda Pod-a trafik göndərilmir, liveness isə bərpa olunmayan vəziyyətdə restart qərarı üçündür. Eyni endpoint-i üçünə də bağlamaq modelin gec yükləndiyi anda boş yerə restart dövrəsi yarada bilər.
Overload nasazlığa çevrilməzdən əvvəl kəsilməlidir
Hər downstream çağırışın deadline-ı ümumi request deadline-dan qısa olmalıdır. Vaxt məhduddur. Pre-processing 300 ms, inference 900 ms, post-processing 200 ms gözləyirsə, gateway-də 1 saniyəlik timeout qoyub möcüzə gözləmək alınmayacaq. Büdcə komponentlər arasında açıq bölünür və qalan vaxt request-lə birlikdə ötürülür.
Retry yalnız keçici xəta və idempotent əməliyyat üçün düşünülməlidir. Kor retry təhlükəlidir. Eyni ağır inference request-i bir neçə client eyni anda dərhal təkrar göndərsə, kiçik nasazlıq ikinci trafik dalğasına çevrilir. AWS-in backoff və jitter izahında təsadüfi gecikmənin rəqabət aparan retry-ları zamana yaydığı göstərilir; limitli cəhd sayı, exponential backoff və jitter birlikdə işləyir, deadline bitəndən sonra isə retry dayandırılır.
Backpressure də məhz burada işə düşür. Queue limiti dolanda gateway yeni işi 429 və ya 503 ilə rədd edir, client isə Retry-After siyasətinə uyğun davrana bilər. Bu cavab xoş deyil, amma on saniyə susub sonra timeout verməkdən daha dürüstdür. Prioritetli workload varsa, məsələn interaktiv sorğu və gecəlik batch işi, onların queue və capacity payları ayrılır.
Model versiyası da production vahididir
Model çəkisi, tokenizer, preprocessing kodu və runtime konfiqurasiyası birlikdə versiyalanmalıdır. Paket bütövdür. Tək model faylını dəyişmək kifayət etmir; tokenizer uyğunsuzluğu servis işlək görünərkən səssiz keyfiyyət itkisi yarada bilər. Deployment əvvəlcə kiçik trafik payına açılır, texniki metriklərlə yanaşı modelə aid göstəricilər də müqayisə edilir.
Burada rollback yalnız container image-i geri çevirmək deyil. Köhnə model artefaktı və onun bütün asılılıqları əlçatan qalmalıdır. Stateful söhbət axınında model versiyasını request ortasında dəyişmək mümkün deyilsə, session routing qaydası da rollout planına daxil edilir.
Müşahidə ediləbilənlik request sərhədində qalmamalıdır. Gateway, queue, scheduler, inference və post-processing eyni trace daxilində görünəndə vaxtın harada itməsi aydınlaşır. OpenTelemetry context propagation trace məlumatını proses və şəbəkə sərhədlərindən keçirərək çağırışları əlaqələndirir. Trace üzərində model adı və versiyası, batch ölçüsü, queue gözləməsi, input ölçüsü və nəticə statusu faydalıdır; prompt, şəxsi məlumat və credential isə telemetry-yə yazılmamalıdır.
İzlənəcək əsas paylanmalar end-to-end p50/p95/p99 latency, queue wait, inference müddəti və batch ölçüsüdür. Bunlara throughput, reject sayı, timeout, retry, GPU yaddaşı və model yükləmə vaxtı əlavə olunur. Orta rəqəm aldadır. İstifadəçilərin ən çox şikayət etdiyi quyruq gecikməsini çox rahat gizlədir.
Capacity testi də tək sabit request sürəti ilə aparılmır. Ani burst, müxtəlif input uzunluğu, model rollout-u, bir GPU-nun itməsi və downstream yavaşıması ayrıca sınanır. Məqsəd sistemin maksimum neçə request qəbul etdiyini tapmaq deyil; latency büdcəsini qoruyaraq hansı yükə qədər faydalı cavab verdiyini görməkdir.
Tez-tez verilən suallar
AI inference servisi hansı metriklə miqyaslanmalıdır?
Tək CPU istifadəsi kifayət etmir. Queue dərinliyi, gözləmə vaxtı, p95/p99 latency, aktiv sorğu sayı və GPU utilization birlikdə izlənməlidir.
Dynamic batching həmişə latency-ni azaldır?
Xeyr. Batching throughput-u artıra bilər, lakin batch toplamaq üçün verilən gecikmə request latency-sinə əlavə olunur. Parametrlər latency büdcəsinə görə ölçülməlidir.
Model yüklənərkən readiness niyə vacibdir?
Proses işlək görünsə də model çəkiləri hələ yaddaşa yüklənməmiş ola bilər. Readiness uğurlu olmayana qədər instance-a trafik göndərilməməlidir.
Mənbələr
- NVIDIA Triton Inference Server — Dynamic Batching
- Kubernetes — Horizontal Pod Autoscaling
- Kubernetes — Liveness, Readiness, and Startup Probes
- OpenTelemetry — Context propagation
- AWS Architecture Blog — Exponential Backoff And Jitter
Bu yazı süni intellekt köməyi ilə yazılıb, faktları və mənbələri yoxlanılıb.
Top comments (0)