Uzziniet kā novērst datu sastrēgumus starp CPU un GPU lai paātrinātu meklēšanas procesu un uzlabotu Agentic RAG sistēmu veiktspēju.
Paplašinātās ģenerēšanas tehnoloģijas jeb RAG (Retrieval-Augmented Generation) ir kļuvušas par standartu modernu mākslīgā intelekta lietotņu izstrādē. Tomēr, pārejot no vienkāršiem jautājumu-atbilžu rīkiem uz autonomiem aģentiem (Agentic RAG), izstrādātāji saskaras ar nopietnu problēmu, kas ir sistēmas latentums un ātrdarbība. Kad AI aģentam ir jāveic vairāki meklēšanas cikli pēc kārtas, pat dažu milisekunžu aizture katrā solī var radīt pamanāmu dīkstāvi gala lietotājam.
Kā savā analītiskajā rakstā skaidro Towards Data Science autors, viens no lielākajiem vājajiem punktiem šādās sistēmās ir pastāvīgā datu ceļošana starp centrālo procesoru (CPU) un grafisko procesoru (GPU). Šo parādību mēdz dēvēt par datu lēkāšanu jeb "bouncing off the GPU".
Kāpēc tradicionālais meklēšanas solis bremzē sistēmu
Parastā RAG darba plūsmā lietotāja vaicājums vispirms tiek pārveidots par vektoru (embedding), izmantojot GPU. Pēc tam šis vektors tiek salīdzināts ar datubāzē esošajiem dokumentu vektoriem, lai atrastu līdzīgākos (Top-K atlase). Problēma rodas brīdī, kad pati meklēšanas un kārtošanas operācija tiek nodota CPU vai neefektīviem GPU algoritmiem, kas liek lielu apjomu datu kopēt atpakaļ uz sistēmas operatīvo atmiņu (RAM).
Šāda datu kopēšana pāri PCIe kopnei rada milzīgu sastrēgumu. Lai gan tīmekļa vietnēm mēs bieži izmantojam rīkus, lai pārbaudītu un optimizētu lapas ielādes ātrumu, mākslīgā intelekta infrastruktūrā šo ātrdarbību mēra milisekundēs starp procesoru un videoatmiņu. Katrs datu pārsūtīšanas cikls samazina sistēmas efektivitāti.
Risinājums: GPU-Resident Top-K atlase
Lai atrisinātu šo problēmu, inženieri izstrādā specializētus CUDA kodolus (CUDA kernels), kas ļauj visu Top-K meklēšanas procesu veikt tieši grafiskā procesora atmiņā (GPU-resident). Tas nozīmē, ka dati vispār nepamet īpaši ātro GPU videoatmiņu (VRAM).
Izmantojot šādu pieeju, tiek panākta maksimāla paralēlo skaitļošanas jaudu izmantošana. Zemāk redzamajā tabulā ir apkopotas galvenās atšķirības starp abām metodēm.
| Parametrs | Tradicionālā RAG meklēšana | GPU-Resident RAG (Ar CUDA kodolu) |
|---|---|---|
| Datu atrašanās vieta | Lēkā starp CPU un GPU | Pilnībā atrodas GPU atmiņā |
| Latentums (aizture) | Augsts (PCIe kopnes dēļ) | Ypač zems (tuvs teorētiskajam minimumam) |
| Mērogojamība | Samazinās, pieaugot datu apjomam | Saglabājas augsta, pateicoties paralēlumam |
| Aparatūras izmantošana | CPU un GPU dīkstāve gaidīšanas laikā | Pilna un efektīva GPU noslodze |
Sarežģītās mākslīgā intelekta sistēmās reālais pudeles kakls gandrīz nekad nav pašu aprēķinu veikšanas ātrums, bet gan laiks, kas nepieciešams datu pārvietošanai uz vietu, kur šie aprēķini var notikt.
Pielāgota CUDA koda integrācija
Lai izveidotu šādu risinājumu, izstrādātāji raksta zema līmeņa C++ un CUDA kodu, kas tiek tieši integrēts tādās sistēmās kā PyTorch. Šāds kodols ir optimizēts konkrētam GPU pavedienu (threads) izkārtojumam, ļaujot veikt miljoniem vektoru salīdzināšanu acumirklī.
Zemāk ir redzams vienkāršots konceptuāls piemērs tam, kā tiek izsaukts pielāgots CUDA paplašinājums Python vidē:
import torch
import custom_gpu_search
# Pieņemam, ka query un database_vectors jau atrodas GPU atmiņā
query = torch.randn(1, 1536, device="cuda")
database_vectors = torch.randn(100000, 1536, device="cuda")
# Veicam meklēšanu, nepārsūtot datus uz CPU
top_k_indices, top_k_scores = custom_gpu_search.top_k_resident(
query,
database_vectors,
k=10
)Secinājumi uzņēmumiem
Uzņēmumiem, kas plāno ieviest sarežģītas AI aģentu sistēmas ražošanas vidē, ir jāsaprot, ka infrastruktūras efektivitāte būs noteicošais faktors klientu apmierinātībai. Pāreja uz pilnībā GPU bāzētiem meklēšanas procesiem ir loģisks solis, lai samazinātu ekspluatācijas izmaksas un nodrošinātu tūlītējas atbildes, padarot mākslīgā intelekta asistentus patiesi noderīgus un ātrdarbīgus ikdienas biznesa procesos.
