AI ინფრასტრუქტურა და GPU აუზები

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

Production-AI არ არის „ერთი მოდელი ერთ სერვერზე“, არამედ მტევანი GPU კვანძებიდან, ზოგადი ამაჩქარებლის ტყვიები, ერთიანი სერვინგი, მონაცემები/იხვები, დაკვირვება და ღირებულების კონტროლი. IGaming- ისთვის ეს კრიტიკულია რეალურ დროში: ანტიფროდი, პერსონალიზაცია, ჩატის ბოტები, LLM თანაშემწეები, თამაშების/აქციების რეკომენდაციები. ძირითადი აგურები: Kubernetes/Slurm დაგეგმვისთვის, სამუშაო დატვირთვის იზოლაცია, მაღალსიჩქარიანი ქსელი (100/200/400G RDMA- ით), სწრაფი საცავი, სექსუალურ MLOps და რკინაბეტონის SLO.

1) არქიტექტურული რუკა

1. გაანგარიშების კასეტა: GPU nods (A/H კლასები, AMD/ROCm, Intel Gaudi და ა.შ.), CPU nods prejection/fices.

2. ქსელი: 100G + Ethernet/IB, RDMA (RoCEv2), NCCL ტოპოლოგია, QoS.

3. საცავი: ობიექტი (S3.) განაწილებულია POSIX (Ceph/მაკიაჟი), ადგილობრივი NVMe-scratch.

4. მონაცემები/ფიჩები: fichestor (online/offline), ვექტორული BD (ANN), ქეში (Redis), რიგები.

5. ML პლატფორმა: არტეფაქტებისა და მოდელების რეესტრი, payplines (CI/CD), ვერსიების კონტროლი, ფიჩები, როგორც კოდი.

6. მომსახურების ფენა: Triton/KServe/vLLM/text-generation-inference (TGI), A/B/canari deploy, მანქანის რემონტი.

7. ჰოვერნანსი და უსაფრთხოება: PII, საიდუმლოებები, აუდიტი, ექსპორტის პოლიტიკა, წონის ლიცენზია/დათასი.

• ონლაინ სკორინგი (p95-50-150 ms) - ანტიფროდიული, რეკომენდაციები, რანჟირება.
• LLM სერვინგი (p95-200-800 ms 128-512 ნიშნისთვის) - ჩატი/აგენტები/მინიშნებები.
• პაკეტის ანალიტიკა/გადამზადება - ღამის ფანჯრები, ოფლაინ მეტრიკა.
• Fintuning/ადაპტაცია - პერიოდულად, პრიორიტეტით დაბალია, ვიდრე ონლაინ.

2) GPU აუზები და დაგეგმვა

ტყვიის მოდელი

Pul „Serving“: მოკლე მოთხოვნები, მაღალი ბატჩინგი, მკაცრი SLO.
აუზი „ტრენინგი/თამაში“: გრძელი ჯობი, განაწილებული ტრენინგი (DDP).
აუზი „R & D/ექსპერიმენტები“: კვოტები/ლიმიტები, ნებადართულია.
აუზი „CPU/Pre-/Post-processing“: ნორმალიზაცია, ტოკენიზაცია, rerank CPU- ზე.

დაგეგმვა

Kubernetes (+ device-plugin, NodeFeatureDiscovery, taints/tolerations, PriorityClass, PodPriority/Preemption).
Slurm (ხშირად HPC ტრენინგისთვის) - შეგიძლიათ აურიოთ K8s- ს ინდივიდუალური ვარჯიშების საშუალებით.
Fair Share და კვოტები: namespace კვოტები GPU, CPU, მეხსიერება; „ბანკები“ GPU საათები; ლიმიტები ნეიმსპასის/პროექტის მიხედვით.

GPU განლაგება

MIG (Multi-Instance GPU): ამაჩქარებლის დაჭრა იზოლირებულ სლაისებზე (სერვინგის/მულტფილმის ტენანტობისთვის).
MPS: SM ბურთი მცირე დავალებებისთვის (ჩარევის მონიტორინგი).
NVLink/PCIe: გაითვალისწინეთ ტოპოლოგია პოდიუმზე (Topology Aware Scheduling).

yaml apiVersion: v1 kind: Pod metadata:
annotations:
scheduling. k8s. io/group-name: "ai-serving"
spec:
nodeSelector: { gpu-pool: serving }
tolerations: [{ key: "gpu", operator: "Exists", effect: "NoSchedule" }]
priorityClassName: ai-serving-critical

3) ქსელი და ინტერკულტურული შესრულება

RDMA (RoCEv2) NCCL all redus- ისთვის; ECN/PFC კონფიგურაცია, ტრაფიკის კლასების იზოლაცია.
ლოკალიზაცია: ტრენინგი ერთი „ქარხნის“ შიგნით (pod/host/ოპტიკა), სერვინგი - მომხმარებელთან უფრო ახლოს (edge/რეგიონი).
კონგესტის კონტროლი: პროფილები, jumbo frames, pin-ning ინტერფეისები.

4) საცავი და მონაცემები

წონის/არტეფაქტების საცავი: ობიექტი (ვერსია, immutability).
Datasets/fichi: Lakehouse (Delta/Iceberg/Hudi) + ოფლაინ-შუამავალი; ონლაინ ბიულეტენი (მილიწამური SLA).
ვექტორული BD (ANN): Faiss/ScaNN/ამაჩქარებლები, ან ვექტორული ვექტორული ძრავები; შარდვა, HNSW/IVF, რეპლიკაცია.
ადგილობრივი NVMe ქეში: წონის/ემბედინგის დათბობა ცივი დაწყებისთვის.

5) მოდელების სერვინგი

ჩარჩოები

Triton Inference Server (მულტიმოდელი, მულტიმედიური, დინამიური ბრძოლა).
KServe (K8S-national, autoscaling HPA/KPA, კანარი).
vLLM/TGI LLM ტოკენიზაციისა და მაღალი ხარისხის დეკოდიზაციისთვის (paged-attention, KV ქეში ოფლიანობა).
ONNX Runtime/TensorRT-LLM - შედგენისა და აჩქარებისთვის.

ოპტიმიზაცია

რაოდენობრივი: INT8/FP8/INT4 (გადატვირთული/კალიბრაცია, AWQ/GPTQ) - ინტერნეტით ფრთხილად, გაზომეთ ხარისხი.
გრაფიკის შედგენა: TensorRT, TorchInductor/XLA, fused-kernels.
Batching/mikrobatching: დინამიური და სტატიკური; для LLM — continuous batching.
KV ქეში: შარინგი მოთხოვნებს შორის, ოფლიანობა CPU/NVMe- სთვის გრძელი კონტექსტებით.
სპეკულაციური დეკოდირება: დრაფტის მოდელი + გადამოწმება ტოქსინის გამოხატვის დაჩქარების მიზნით.
ნიშნების/კონტექსტის ლიმიტები, ადრეული გაჩერება, გაჩერებული სიტყვები, დრო-ბუდეტი თხოვნისთვის.

დისლოკაციის პოლიტიკა

A/B, კანარი, shadow - ლატენტობის/ხარისხის/ბიზნეს მეტრიკის შედარება.
ცისფერი მწვანე - დასრულების გარეშე.
როლბეკი SLO/შეცდომებისთვის.

6) ტრენინგი/fintuning

DDP/FSDP/ZeRO: განაწილებული მეხსიერება/გრადიენტები, NVLink/ტოპოლოგიის აღრიცხვა.
Chekpoints: Acremental/სრული, სიხშირე vs I/O.
Mixed Precision: bf16/fp16 + loss scaling; სტაბილურობის პროფილირება.
Dataset-sharding: ერთიანი გამეორება, კვანძების რეპლიკაცია.
პრიორიტეტები: შეფერხებული ჯობი სერვინგის სასარგებლოდ.
Autonomous plines: Data - train - eval - Region- ის პოპულარიზაცია gate კრიტერიუმების შესაბამისად.

7) MLOps და პლატფორმა

მოდელების რეესტრი: ვერსიები, ხელმოწერები, დამოკიდებულება, ლიცენზია/სასწორის გამოყენების უფლება.
CI/CD მოდელები: ტესტები თავსებადობის, შესრულების რეგრესიის, quality gates, უსაფრთხო deple.
Fichestor: ოფლაინ/ონლაინ თანმიმდევრულობა (feature parity), TTL და backfill.
Data/Model Lineage: კვალი Dataset- დან ანგარიშამდე/ექსპერიმენტამდე.
ინდუსტრიული/შაბლონების კატალოგი LLM- სთვის (ვერსია).

8) დაკვირვება და SLO

• ლატენტობა p50/p95/p99, tokens/s, batch occupancy, queue wait, GPU-util/SM occupancy, მეხსიერება, შეცდომები.
• LLM სპეციფიკა: წვდომის/გამომუშავების ნიშნები, პასუხის საშუალო სიგრძე, ლიმიტებზე უარის თქმის წილი, ქეში-ჰიტ KV.
• ხარისხი: ავტომატური რეგრესიული ტესტები (ოფლაინ), ონლაინ ტელემეტრია (შინაარსის დროშები, ტოქსიკურობა, ოქროს ნიმუშებზე გაცემის სიზუსტე).
• ბიზნეს SLO: პერსონალიზაციის კონვერტაცია, ანტიფროდის სიზუსტე, გამართვა.

ალერტები: p99/რიგის ზრდა, tokens/s ვარდნა, batch-fill დეგრადაცია, VRAM/PCIe-throttle ამოწურვა, უარის თქმის ზრდა.

9) უსაფრთხოება, შესაბამისობა და კონფიდენციალურობა

PII/findanes: რეგიონების გამოთვლისა და მონაცემების სეგმენტი, დასვენების/ტრანზიტის დაშიფვრა, ტოკენიზაცია.
საიდუმლოებები/გასაღებები: KMS/საიდუმლო მენეჯერი; შენახვა სურათებში/კოდში.
LLM გამომავალი პოლიტიკოსები: უსაფრთხოების ფილტრები, red-teaming, სარეკლამო/პასუხების ჟურნალები (ანონიმიზაციით).
ლიცენზიები: დანაკარგების/წონის ლიცენზიების შესაბამისობა; „no-redistribute „/კომერციული შეზღუდვები.
ტენიანობის იზოლაცია: namespace-RBAC, ქსელები, MIG სლაიდები, ლიმიტები და კვოტები.

10) ღირებულება და ძაფი

კაპასიტის დაგეგმვა: დატვირთვის პროფილები (RPS, ნიშნები/წმ), ტურნირებისა და კამპანიების „კუდები“.
სარეზერვო/Spot: შერეული აუზები (აღდგენილი + spot/preemptible) დავალებების ხელახალი წარმოებით და შემოწმებით.
ავტო სკეიტი: HPA/KPA RPS/queue depth/GPU-util; „თბილი დასაწყისი“ გაცხელებული მასშტაბებით.
სამოდელო ზოოპარკი: შეამცირეთ ვარიანტების რაოდენობა; გამოიყენეთ ადაპტაცია (LoRA/PEFT) სრული დუბლირების ნაცვლად.
ქეში: ემბედინგი/ძვირადღირებული მოთხოვნების შედეგები, KV ქეში LLM- სთვის.
ტოქსინების ოპტიმიზაცია: მრეწველების შეკუმშვა, რეპროდუქციული-აუგმენტირებული თაობა (RAG), rerank თაობამდე.

11) მულტირეგიონი, HA და DR

Active/Active Serving უფრო ახლოს არის მომხმარებელთან, გლობალური როუტინგი.
სასწორის და ძაფების რეპლიკაცია მთლიანობის შემოწმებით; გაათბეთ ქეში გამოშვებებზე.
DR გეგმა: AZ/რეგიონის დაკარგვა, სარეზერვო აუზზე ევაკუაცია, ცენტრალიზებული კატალოგიდან დამოკიდებულების კონტროლი.
Chaos დღეები: GPU-nods/ქსელის დომენების/საცავების უკმარისობის ტესტები.

12) კონფიგურაციის შაბლონები (კონცეფციები)

text dynamic_batching {
preferred_batch_size: [4, 8, 16, 32]
max_queue_delay_microseconds: 2000
}
instance_group { count: 2 kind: KIND_GPU }

yaml spec:
predictor:
canaryTrafficPercent: 20 model:
modelFormat: { name: triton }
resources:
limits: { nvidia. com/gpu: "1" }

--tensor-parallel-size 2
--max-num-seqs 512
--gpu-memory-utilization 0. 9
--enforce-eager

13) LLM სპეციფიკა: RAG და საძიებო წრე

ინდექსაცია: ჩანკინგი, ემბედინგი, ANN შარდვა 'tenant/locale'.
რერანკი: მსუბუქი მოდელი CPU/GPU სლაიდზე სიზუსტის გასაზრდელად.
Cash prompts/კონტექსტები: dedup, canonicalization.
ციტირების/პასუხისმგებლობის პოლიტიკა მგრძნობიარე დომენებისთვის (ICC/წესები).

14) განხორციელების სია

1. დააფიქსირეთ SLO (p95 latency/tokens/s, წვდომა) და დატვირთვის პროფილები.
2. დაალაგეთ მტევანი აუზზე (serving/train/R & D), შეიყვანეთ კვოტები/პრიორიტეტები.
3. ჩართეთ RDMA/NCCL და ტოპოლოგიურად ინფორმირებული დაგეგმვა.
4. შენახვის პარამეტრები: სასწორები, თარიღები, შუახნის (ონლაინ/ოფლაინ), ვექტორული BD.
5. შეარჩიეთ Serving Steak (Triton/KServe/vLLM), დაამატეთ batching/KV ქეში/რაოდენობრივი რაოდენობა.
6. მოდელების დაზუსტების რეესტრი, CI/CD, კანარი/shadow deple.
7. დაკვირვება: სისტემური + ბიზნეს მეტრიკა, თვისებები, ტრეკინგი.
8. შეიყვანეთ უსაფრთხოების პოლიტიკა/PII, ლიცენზია, აუდიტი.
9. ოპტიმიზაცია მოახდინეთ TCO: აღდგენა + spot, სკეიტი, ქეში, PEFT სრული კლონების ნაცვლად.
10. მოამზადეთ HA/DR და გაატარეთ თამაშის დღე.

15) ანტიპატერები

„ერთი დიდი GPU ყველაფრისთვის“ ტყვიებისა და პრიორიტეტების გარეშე.
დინამიური ბატარეის და KV ქეშის ნაკლებობა LLM- სთვის არის p99 აფეთქება და ღირებულება.
ტრენინგი და სერვინგი ერთ აუზზე, პრემიის გარეშე - SLO ინციდენტები.
ხარისხის/უსაფრთხოების ნულოვანი ტელემეტრია - უხილავი დეგრადაცია და რისკები.
ცენტრალიზებული მონოლიტი არ არსებობს fichestor/Research მოდელების გარეშე.
წონის/მონაცემების ლიცენზიების უგულებელყოფა.

შედეგები

წარმატებული AI ინფრასტრუქტურა არის GPU აუზები ჭკვიანი დაგეგმვით, მაღალი ქსელი და რეგულარული საცავი, ეფექტური სერვინინგი (ტრამპინგი, ქეში, რაოდენობრივი, შედგენა), სექსუალურ MLOps და მკაცრი SLO. უსაფრთხოებასთან/PII- სთან, მრავალ რეგიონულ HA/DR- სთან და გააზრებულ ფინფსთან ერთად, პლატფორმა იძლევა სტაბილურ p99, კონტროლირებად $/თხოვნას და ახალი მოდელების სწრაფ დანერგვას - ანტიფროდიდან პერსონალიზაციამდე და LLM თანაშემწეებამდე.