Mwongozo wa Ukubwa wa Lenovo LLM
Mipango / Utekelezaji

Mfumo Kamili wa Ukubwa wa LLM

Miundo Kubwa ya Lugha (LLMs) imeleta mapinduzi katika nyanja ya uchakataji wa lugha asilia, kuwezesha matumizi kama vile ukuzaji wa maandishi, uchanganuzi wa hisia na tafsiri ya lugha. Hata hivyo, mahitaji ya kimahesabu ya kuendesha miundo hii yanaweza kuwa makubwa, na kuifanya kuwa changamoto kwa wasanifu wa suluhisho kubuni na kusanidi mifumo inayokidhi mahitaji ya wateja wao.
Ili kukabiliana na changamoto hii, Mwongozo huu wa Ukubwa wa LLM umeundwa ili kukupa uelewa mpana wa jinsi LLM zinavyofanya kazi, mahitaji yao ya kimahesabu, na vipengele muhimu vinavyoathiri utendakazi wao. Lengo la mwongozo huu ni kukupa maarifa na zana zinazohitajika ili kutathmini mahitaji ya wateja, kubuni mifumo yenye uwezo, na kuwasilisha utumaji wa LLM kwa ufanisi haraka na kwa usahihi.

mwongozo, aliongoza kutoka Ukubwa wa Maoni ya NVIDIA ya LLM, itashughulikia mada muhimu kama vile kanuni ya msingi ya kukadiria mahitaji ya kumbukumbu ya GPU kwa uelekezaji na mafunzo/kurekebisha vizuri, kukusanya mahitaji kutoka kwa wateja, kuelewa vigezo na vipimo vya utendakazi, na kukadiria jumla ya gharama ya umiliki. Kwa kufuata mwongozo huu, utaweza kuabiri mandhari changamano ya LLM na kuwapa wateja wao masuluhisho yaliyoboreshwa ambayo yanakidhi mahitaji yao mahususi.
Katika mwongozo huu wote, tutatoa mfano wa vitendoampkanuni, kanuni, na miongozo ya kusaidia wasanifu wa suluhisho kukadiria mahitaji ya hesabu kwa hali mbalimbali za LLM. Pia tutajadili umuhimu wa kuelewa mahitaji ya wateja, kama vile modeli, idadi, ukubwa wa tokeni, na mahitaji ya muda wa kusubiri na jinsi mambo haya yanavyoathiri muundo na utendaji wa mfumo.
Katika sehemu inayofuata, tutaanzisha "Sheria ya Kidole" kwa kukadiria mahitaji ya kumbukumbu ya GPU, tukianza na kuelekeza. Hii itakupa njia rahisi na faafu ya kukadiria mahitaji ya chini zaidi ya kumbukumbu ya GPU kwa kuendesha LLM katika mazingira ya uzalishaji.

Kanuni ya kidole gumba

Kanuni ya kidole gumba hutoa mbinu iliyorahisishwa ya kukadiria mahitaji ya hesabu ya kuendesha Miundo Kubwa ya Lugha (LLMs). Sehemu hii inaangazia vipengele muhimu vinavyoathiri mahitaji ya kumbukumbu ya GPU na hutoa fomula za kukadiria kwa haraka mahitaji ya chini ya kumbukumbu ya kukatiza na kurekebisha/mafunzo.

Kuelekeza
Ukaguzi unarejelea mchakato wa kutumia LLM iliyofunzwa kutoa maandishi au kutabiri data mpya, isiyoonekana. Ili kukadiria mahitaji ya chini kabisa ya kumbukumbu ya GPU kwa kuelekeza, tunaweza tumia fomula ifuatayo:
M =P*Z* 1.2

Wapi:

• M = kumbukumbu ya GPU iliyoonyeshwa kwa Gigabytes
• P = Mfano (parameter) ukubwa katika Mabilioni
• Z = Kipengele cha quantization katika Byte (1 Byte = 8 bits) - tazama hapa chini
• 1.2 = Inawakilisha 20% ya ziada ya kupakia data ya ziada kwenye kumbukumbu ya GPU

Sababu ya quantization Z inatofautiana kulingana na usahihi uliotumiwa:

• INT4: = 0.5
• FP8/INT8: = 1
• FP16: = 2
• FP32: = 4

Kwa mfanoample, ili kukadiria mahitaji ya chini ya kumbukumbu ya GPU kwa kuendesha Llama 3.1 yenye vigezo bilioni 70 kwa ujazo wa 16-bit (FP16), tunaweza kuunganisha thamani kama ifuatavyo:
M = 70 ∗ 2 ∗ 1.2 = 168 GB

Fomula hii hutoa njia ya haraka na rahisi ya kukadiria mahitaji ya chini kabisa ya kumbukumbu ya GPU kwa uhakiki, kuruhusu wasanifu wa suluhisho kubuni mifumo inayokidhi mahitaji ya wateja wao.

Urekebishaji Mzuri/Mafunzo
Kurekebisha au kutoa mafunzo kwa Muundo Kubwa wa Lugha (LLM) kunahitaji rasilimali nyingi zaidi za hesabu kuliko uelekezaji. Mahitaji ya chini ya kumbukumbu ya GPU kwa urekebishaji/mafunzo mazuri yanaweza kukadiriwa kwa kutumia fomula ifuatayo:
Jumla = (Z + 12 + Z) baiti/kigezo = P (2Z+12) kumbukumbu ya GB inahitajika
Wapi:

• P = Mfano (parameter) ukubwa katika mabilioni
• Z = Kipengele cha ujazo katika Baiti (Baiti 1 = biti 8)

Walakini, fomula hii hutoa makadirio ya hali ya juu, kwani inadhania kuwa vigezo kamili vya mfano, hali ya kiboreshaji, na gradient zimehifadhiwa kwenye kumbukumbu. Katika mazoezi, mbinu kama Marekebisho ya Kiwango cha Chini (LoRA) na LoRA Iliyokadiriwa (QLORA) inaweza kupunguza kwa kiasi kikubwa mahitaji ya kumbukumbu.
Ili kukupa wazo bora, hapa kuna baadhi ya makadirio ya mahitaji ya kumbukumbu ya GPU kwa kusawazisha LLM kwa kutumia mbinu tofauti na usahihi:

Jedwali 1. Ulinganisho wa mahitaji ya VRAM kwa ukubwa tofauti wa mfano na mbinu za kurekebisha vizuri

Mbinu	Usahihi	7B	13B	30B	70B	110B
Imejaa	16	67GB	125GB	288GB	672GB	1056GB
LoRA	16	15GB	28GB	63GB	146GB	229GB
QLoRA	8	9GB	17GB	38GB	88GB	138GB
QLoRA	4	5GB	9GB	20GB	46GB	72GB

Kama unavyoona, kutumia LoRA au QLoRA kunaweza kupunguza mahitaji ya kumbukumbu kwa 75-90% ikilinganishwa na mbinu kamili ya kurekebisha. Hii ni kwa sababu mbinu hizi huhifadhi tu vigezo vilivyorekebishwa na si modeli nzima, na hivyo kusababisha uhifadhi mkubwa wa kumbukumbu.
Wakati wa kuunda mifumo ya kurekebisha vizuri/kufunza LLMs, ni muhimu kuzingatia mbinu mahususi na usahihi unaotumika, pamoja na ukubwa wa kielelezo, ili kuhakikisha kuwa mfumo huo unakidhi rasilimali zinazohitajika za kukokotoa. Kwa kutumia mbinu kama vile LoRA au QLoRA, wasanifu wa suluhisho wanaweza kubuni mifumo bora na ya gharama nafuu inayokidhi mahitaji ya wateja wao.

Kukusanya mahitaji

Ili kuamua kwa usahihi usanidi wa mfumo muhimu kwa utumiaji wa Mfano wa Lugha Kubwa (LLM), ni muhimu kukusanya mahitaji maalum kutoka kwa mteja. Mahitaji haya yatasaidia kukadiria utendakazi wa makisio na kuhakikisha mfumo unatimiza malengo yanayohitajika.

Taarifa tano zifuatazo zinapaswa kukusanywa kabla ya kukadiria utendaji wa makisio:
1. Uteuzi wa Mfano:
Tambua muundo wa LLM unaokusudiwa kutumika katika mradi huu. Ukubwa wa muundo huathiri haswa utendakazi wa makisio, huku miundo mikubwa ikiwa polepole na ghali zaidi. Kumbuka kuwa miundo midogo inaweza kuwa na ubora bora kwa kazi mahususi huku ikipunguza gharama za uelekezaji. Kwa hiyo, inashauriwa kuchunguza mifano ndogo pia. Kuelewa sifa za mtindo uliochaguliwa kutasaidia katika kukadiria rasilimali za hesabu zinazohitajika.
Wakati wa kukusanya mahitaji ya kesi ya matumizi ya LLM, ni muhimu kuzingatia urefu wa tokeni ya ingizo, ambayo ni mojawapo ya vipengele vya kubainisha utendakazi wa modeli. Dirisha la muktadha, linalofafanuliwa kama jumla ya tokeni za pembejeo na matokeo, ina jukumu kubwa katika mchakato huu. Miundo mipya, kama vile Llama 3.1, inasaidia madirisha makubwa ya muktadha wa hadi tokeni 128,000.

2. Ishara za Kuingiza:
Amua wastani wa idadi ya tokeni katika kidokezo cha LLM, ikijumuisha:

• Agizo la mfumo
• Muktadha
• Agizo la mtumiaji

Kwa mifano ya lugha ya Kiingereza, tokeni moja ni takriban 0.75 ya neno. Ikiwa ni pamoja na vidokezo vya mfumo na muktadha katika hesabu ya tokeni huhakikisha kwamba mlolongo mzima wa ingizo unazingatiwa wakati wa kukadiria utendakazi.
Ili kukokotoa kwa usahihi hesabu ya tokeni za ingizo, jumuisha vipengele vyote vinavyochangia, kama vile vidokezo vya mfumo (maelekezo maalum), hati zilizorejeshwa (katika Urejeshaji mabomba ya Kizazi Kilichoongezeka), na historia ya gumzo (mazungumzo ya awali). Kila moja ya vipengele hivi huhesabu kwa bajeti ya juu ya ishara ambazo zinaweza kupitishwa kwenye mfano.
Urefu mkubwa wa ingizo unaweza kuathiri utendakazi wa makisio, maneno yanapobadilishwa kuwa upachikaji na akiba ya KV hukua mara nne. Programu kama vile mabomba ya RAG zinaweza kuhitaji urefu mkubwa wa ingizo, hivyo kusababisha kuongezeka kwa muda wa ishara ya kwanza kwa sababu ya kiasi kikubwa cha data inayochakatwa.
Tutachunguza kwa kina tokeni na athari zake kwenye muda wa kusubiri baadaye katika karatasi hii, tukichunguza jinsi zinavyoathiri utendakazi wa LLM na ni mambo gani yanayozingatiwa ni muhimu kwa utendakazi bora wa muundo.

3. Tokeni za Pato:
Anzisha wastani wa idadi ya tokeni katika tokeo la LLM. Hii ni muhimu kwa sababu kutengeneza tokeni nyingi kunahitaji rasilimali na wakati wa kukokotoa zaidi. Kuelewa ukubwa unaotarajiwa wa pato kutasaidia katika kubuni mfumo ambao unaweza kushughulikia upitishaji unaohitajika bila kuathiri muda au ubora.

4. Wastani wa Maombi kwa Sekunde (RPS):
Ili kuhakikisha utendakazi bora na matumizi bora ya rasilimali, bainisha idadi ya kilele cha maombi ambayo mfumo unapaswa kushughulikia kwa sekunde. Unapopima ukubwa wa uwekaji kwenye majengo, ni muhimu kukokotoa kwenye kilele cha matumizi, badala ya wastani wa matumizi.
Ili kuhesabu utofauti wa ruwaza za ombi, tunatumia asilimia 95 ya Poisson PPF (uwezekano wa kukokotoa pointi) ya wastani wa RPS (maombi kwa sekunde). Mbinu hii husaidia kutambua kiwango cha juu zaidi cha mzigo unaotarajiwa, huturuhusu kubuni mfumo ambao unaweza kushughulikia mahitaji ya kilele bila kutumiwa chini katika vipindi visivyo vya kilele.
Mchakato unahusisha kupata wastani wa kiwango cha ombi kutoka kwa mteja na kukokotoa kiwango cha juu zaidi cha ombi kwa kutumia asilimia 95 ya usambazaji wa Poisson. Njia hii hutoa uwakilishi sahihi zaidi wa mahitaji ya mfumo, kwani inazingatia utofauti wa asili katika mifumo ya ombi. Ni muhimu sana kutambua kwamba ikiwa mfumo haufanyi kazi kwa kiwango cha juu, gharama inayofaa kwa kila tokeni inaweza kuongezeka kwa kiasi kikubwa.

5. Mahitaji ya Kuchelewa:
Kuelewa malengo ya muda wa kusubiri na mipaka ya mteja, ikiwa ni pamoja na:

1. Ucheleweshaji wa ishara ya kwanza: Wakati inachukua kwa modeli kutoa toni ya kwanza ya majibu.
2. Muda wa kusubiri wa ishara ya mwisho: Jumla ya muda inachukua kwa mtindo kutoa jibu zima.

Muda wa kusubiri ni jambo muhimu katika programu nyingi, kwani ucheleweshaji wa juu unaweza kuathiri vibaya uzoefu wa mtumiaji. Kuzuia kwa muda wa chini wa tokeni ya kwanza (TTFT) kunaweza hamper throughput, ikimaanisha kuwa uwezo wa mfumo wa kuchakata maombi mengi kwa wakati mmoja utaathiriwa.
Kwa hivyo, ni muhimu kuweka usawa kati ya muda wa kusubiri na matokeo kulingana na mahitaji mahususi ya mteja.
Mahitaji haya ni muhimu kwa kukadiria utendakazi wa makisio, kupima mfumo, na kuhakikisha kuwa inakidhi matarajio ya mteja. Kwa kukusanya maelezo haya, utaweza kuelewa vyema mahitaji ya mteja na kubuni usanidi unaofaa wa mfumo unaosawazisha utendakazi, gharama na ubora. Katika sehemu zinazofuata, tutachunguza kwa kina baadhi ya mahitaji haya na kuchunguza jinsi yanavyoathiri uwekaji wa LLM.

Upigaji mbizi wa Kiufundi: Kuelewa LLMs

Katika sehemu hii, tutachunguza utendakazi tata wa Miundo Kubwa ya Lugha (LLMs) kwa kuangazia vipengele vyake vya kiufundi. Tutachunguza stages ya utekelezaji wa LLM, elewa vipimo muhimu vya kipimo, na uangalie mbinu zinazoharakisha uhakiki.

Mbili StagUtekelezaji wa LLM: Jaza mapema dhidi ya Kusimbua
Miundo Kubwa ya Lugha (LLMs) ni mifumo changamano inayohusisha s nyingitagza kuchakata ili kutoa majibu ya maandishi yanayofanana na ya binadamu. Kuelewa haya stages inasaidia katika kuboresha utendakazi, kupunguza muda wa kusubiri, na kuboresha matumizi ya jumla ya mtumiaji. Katika sehemu hii, tutazingatia mbili za msingitages ya utekelezaji wa LLM: Jaza awali na Kusimbua.

Jaza awali Stage
Jaza awali stage inarejelea muda unaochukua kwa LLM kuchakata kidokezo cha ingizo cha mtumiaji na kutoa tokeni ya kwanza ya matokeo, ambayo ni takriban sawa na neno. Hii stage inajumuisha hatua zifuatazo:

1. Inapakia kidokezo cha mtumiaji: Ingizo la mtumiaji linapokelewa na kupakiwa kwenye mfumo.
2. Kuweka akiba ya KV: Wakati wa stage, LLM hujaza akiba yake ya Thamani-Muhimu (KV) na taarifa kutoka kwa tokeni za ingizo. Akiba hii inatumika kuhifadhi na kurejesha data husika ya muktadha mahususi.
3. Omba mapokezi kwa tokeni ya kwanza : Muda unaochukua kwa LLM kuchakata kidokezo cha ingizo na kutoa tokeni ya kwanza.

Jaza awali stage kimsingi inafungamana na hesabu, kumaanisha kuwa utendakazi wake unategemea sana rasilimali za hesabu zinazopatikana. Muda inachukua kukamilisha hilitage inategemea tu idadi ya ishara za pembejeo, na kuifanya kuwa mchakato unaotabirika na thabiti.

Kusimbua Stage
Kusimbua stage, pia inajulikana kama kizazi au upanuzi, ni pale LLM inapozalisha tokeni za majibu moja baada ya nyingine, ikijengwa juu ya tokeni ya awali ya pato inayotolewa wakati wa Jaza awali s.tage. Hii stage inahusisha:

1. Muda wa kusubiri wa tokeni baina ya ishara: Muda unaochukua ili kuzalisha kila tokeni inayofuata baada ya ya kwanza.
2. Uzalishaji wa ishara kwa ishara: LLM huzalisha tokeni za majibu neno baada ya neno, kwa kutumia muktadha na taarifa iliyokusanywa wakati wa Jaza awali s.tage.
3. Utegemezi wa tokeni za kuingiza na kutoa : Muda wa kusubiri wa tokeni hutegemea idadi ya tokeni na idadi ya tokeni zinazotolewa.

Tofauti na Jaza awali stage, Uamuzi kwa kawaida hufungamana na kumbukumbu, kumaanisha kuwa utendakazi wake unachangiwa pakubwa na upatikanaji wa rasilimali za kumbukumbu. LLM inapozalisha tokeni zaidi, inahitaji kumbukumbu zaidi kuhifadhi na kudhibiti muktadha unaokua, ambao unaweza kusababisha kuongezeka kwa muda wa kusubiri.

Vipimo vya Upimaji wa Maelekezo ya LLM

Wakati wa kutathmini utendakazi wa Miundo Kubwa ya Lugha (LLMs), metriki kadhaa muhimu hutumiwa kupima kasi ya makisio. Hizi ni pamoja na:

• Muda wa Tokeni ya Kwanza (TTFT): Muda unaochukua kuchakata ingizo na kutoa tokeni ya kwanza.
• Inter-token Latency (ITL): Muda unaochukua ili kuzalisha kila tokeni inayofuata baada ya ya kwanza, pia inajulikana kama Time Per Output Token (TPOT).
• Muda wa Kuchelewa Kuisha hadi Mwisho (E2E) : Jumla ya muda inachukua kuchakata kidokezo na kutoa tokeni zote, kutoka kwa ingizo hadi pato.

Vipimo hivi hutoa maarifa kuhusu utendakazi wa modeli, kusaidia kutambua vikwazo na kuongeza kasi ya uelekezaji.

Inflight batching
Upangaji wa ndege (IFB) ni mbinu maalum inayotumiwa wakati wa makisio ya Muundo Kubwa wa Lugha (LLM) ili kupata usawa kati ya kumbukumbu ya GPU na kukokotoa utumiaji, hatimaye kupunguza muda wa kusubiri. Njia hii ni nzuri sana katika uelekezaji wa kurudisha nyuma kiotomatiki, ambapo LLM hutengeneza tokeni kwa mfuatano, ikitegemea tokeni zilizotengenezwa hapo awali kutoa zinazofuata.
IFB inaruhusu mfuatano katika s mbalimbalitages (kujazwa awali na kusimbua) kuchakatwa ndani ya kundi moja bila kungoja maombi yote yakamilike kabla ya kutambulisha mapya. Mbinu hii inatoa faida kadhaa muhimu:

• Ukubwa wa Bechi ya Mara kwa Mara: IFB huwezesha ukubwa wa bechi karibu mara kwa mara kwa kila kizazi cha tokeni, na hivyo kusababisha matumizi ya juu zaidi ya GPU.
• Utekelezaji wa Haraka Huanza: Maombi mapya yanaweza kuanza kutekelezwa kwa haraka zaidi nafasi zinapopatikana, kwani kipanga ratiba husubiri tu kizazi kijacho cha tokeni badala ya kukamilika kwa maombi ya sasa.

TensorRT-LLM hujumuisha Ukusanyaji wa Inflight maalum ili kuboresha matumizi ya GPU wakati wa huduma ya LLM. Kipengele hiki:

• Hubadilisha maombi yaliyokamilishwa katika kundi.
• Huondoa maombi baada ya alama ya Mwisho wa Mfuatano (EoS) na kuingiza maombi mapya.
• Huboresha utumaji, muda hadi tokeni ya kwanza, na matumizi ya jumla ya GPU.

Zaidi ya hayo, IFB imeunganishwa kwa urahisi katika mazingira ya nyuma ya TensorRT-LLM Triton na inaweza kudhibitiwa kupitia Kidhibiti Kundi cha TensorRT-LLM. Ikiunganishwa na mbinu zingine kama vile kusawazisha utendakazi unaofungamana na kumbukumbu na hesabu, usimbaji wa vipande vipande, usimbuaji wa kubahatisha, na uchache, IFB huongeza upitishaji wa LLM, na kuifanya kuwa chombo muhimu kwa uelekezaji bora wa LLM.

Usambamba wa Tensor
Usambamba wa Tensor (TP) ni mbinu inayotumiwa katika Muundo wa Lugha Kubwa (LLM) ili kusambaza mzigo wa kukokotoa kwenye GPU nyingi. Njia hii inahusisha kugawanya muundo mmoja kwenye GPU kadhaa, ambayo inategemea sana ubadilishanaji wa data unaofaa kati ya GPU hizi. TP ni ya manufaa hasa kwa miundo mikubwa ambapo mahitaji ya kumbukumbu yanazidi uwezo wa GPU moja.

Sifa Muhimu za Usambamba wa Tensor:

• Muda wa Muda wa Chini lakini Muda wa Kupitisha wa Chini: Ingawa TP inaweza kupunguza muda wa kusubiri kwa kusawazisha ukokotoaji, inaweza pia kusababisha upitishaji wa jumla wa chini kutokana na uendeshaji unaohusishwa na mawasiliano baina ya GPU.
• Mahitaji ya Miundo Kubwa zaidi: Kwa miundo mikubwa zaidi kama LLaMa-70B, uwiano wa tensor wa angalau 2 (TP >= 2) unahitajika. Hii inahakikisha kwamba muundo unaweza kugawanywa vya kutosha kwenye GPU nyingi ili kutoshea ndani ya kumbukumbu inayopatikana na rasilimali za hesabu.
• Pendekezo kwa Seva zinazowezeshwa na NVLink: Wakati TP inazidi 2, NVIDIA inapendekeza sana kutumia seva zinazowezeshwa na NVLink kwa makisio. NVLink hutoa muunganisho wa upelekaji data wa juu, wa hali ya chini ambao huboresha kwa kiasi kikubwa uhamishaji wa data kati ya GPU ikilinganishwa na miunganisho ya jadi ya PCIe.

Kuelewa vigezo

Vigezo ni muhimu katika kupanga ukubwa na kuchagua usanidi unaofaa kwa wateja, wanapotathmini ulinganifu kati ya vipimo muhimu kama vile matokeo, muda wa kusubiri na kiwango cha ombi. Kuelewa vigezo hivi husaidia kubainisha usanidi bora wa modeli ya lugha kubwa (LLM), kuruhusu maamuzi sahihi kuhusu mahitaji ya maunzi na programu.

Mapitio dhidi ya Muda wa Kuchelewa
Katika muktadha wa uelekezaji wa LLM, kufikia usawa kati ya matokeo na latency ni muhimu. Utumaji hurejelea idadi ya maombi ambayo yanaweza kuchakatwa kwa kila wakati wa kitengo, wakati muda wa kusubiri ni wakati unaochukuliwa kushughulikia ombi moja kutoka mwanzo hadi mwisho.

Ushindani:
Kuanzisha vikomo vya kusubiri kunaweza kupunguza upitishaji unaopatikana. Kinyume chake, vizuizi vya kupumzika vya kupumzika vinaweza kusababisha upitishaji wa juu zaidi. Kuelewa kesi za utumiaji wa wateja hutoa makadirio ya tokeni za ingizo, tokeni za matokeo, na wastani wa maombi kwa kila wakati wa kitengo, kuruhusu pendekezo la maunzi mahususi yanayolingana na upitishaji unaohitajika huku ikidumisha muda unaohitajika.
Kuchanganya maombi mengi ili kuongeza utumaji kunaweza kuanzisha ucheleweshaji, na kuongeza muda wa kusubiri kwa maombi ya mtu binafsi. Uelekezaji wa LLM unahusisha awamu mbili - kujaza mapema (kuchelewa kwa juu, faida kutoka kwa usindikaji sambamba) na kusimbua (kuchelewa kwa chini, matumizi ya chini ya kompyuta).

Athari za Kiutendaji:

1. Utumiaji wa Juu: Inafaa kwa utumaji wa kiwango kikubwa na idadi kubwa ya maombi.
2. Muda wa Muda wa Muda wa Chini: Muhimu kwa maombi ya majibu ya wakati halisi, kama vile AI ya mazungumzo au mifumo ingiliani.

Kwa kuelewa na kudhibiti mabadiliko ya muda wa kusubiri, mifumo ya uelekezaji ya LLM inaweza kuboreshwa ili kukidhi mahitaji mahususi ya programu. Kwa uwekaji alama maalum, zana kama GenAI-Perf na NVIDIA inaweza kutoa maarifa muhimu katika utendakazi wa muundo fulani kwenye mfumo.

Ili kujifunza jinsi ya kutafsiri grafu za benchmark, angalia mada mwishoni mwa hati hii, Maelezo ya Ziada - Kusoma grafu kwa ukubwa.

Kuelewa Ukubwa wa Kiwango cha Juu, Upatanisho, Kiwango cha Ombi na Upitishaji
Inaweza kupata utata kidogo kushughulikia jargons zote, kwa hivyo hebu tuchambue kila dhana ili kufafanua uhusiano wao na umuhimu katika tathmini ya mfumo.

Ukubwa wa Kundi la Max
Kigezo cha max_batch_size kina majukumu mawili: moja wakati wa kujenga injini na lingine wakati wa kukimbia.

1. Muundo wa Injini: Mpangilio huu unahakikisha kwamba mfumo unaotokana, na uwezo wake wa saizi fulani ya kundi, inafaa ndani ya kumbukumbu inayopatikana. Kimsingi ni juu ya kupanga uwezo ili kuzuia maswala ya kumbukumbu wakati wa utekelezaji.
2. Muda wa utekelezaji: Mipangilio hii huamua ni maombi mangapi yanaweza kuunganishwa pamoja kabla ya kuchakatwa. Muda wa utekelezaji max_batch_size lazima iwe chini ya au sawa na max_batch_size ya muda wa kujenga. Mchanganyiko halisi wa maombi katika hali halisi huathiriwa na parameter hii, inathiri moja kwa moja ufanisi na utendaji.

Ukubwa wa Batch na Concurrency

• Concurrency (C) < Max Batch Size (MBS) : Wakati idadi ya maombi kwa wakati mmoja ni chini ya kiwango cha juu cha bechi, injini kwa kawaida huchakata bechi zenye ukubwa unaolingana na kiwango cha sarafu. Hii inamaanisha kuwa kuna nafasi zisizolipishwa zinazopatikana katika kila kundi, kwani si nafasi zote zinazowezekana kwenye kundi zimejazwa.
• Concurrency (C) >= Ukubwa wa Juu wa Kundi (MBS) : Ikiwa sarafu inalingana au inazidi kiwango cha juu zaidi cha bechi, basi bechi huwa zimejaa, zikichakatwa kwa kiwango cha juu zaidi. Foleni ya maombi mapya itaanza kukua, ikiwa na wastani wa ukubwa wa C – MBS, huku maombi yanayoingia yakisubiri bechi za awali zikamilike.

Uwiano na Kiwango cha Ombi kama Kipimo cha Matokeo
Ili kupima utendaji wa mfumo kwa ukamilifu, fikiria:

• Utumaji: Idadi ya maombi ambayo mfumo unaweza kushughulikia kwa kila wakati wa kitengo.
• Muda wa Kuchelewa Mwishoni-Mwisho: Jumla ya muda unaochukuliwa ili ombi lishughulikiwe kuanzia mwanzo hadi mwisho.
• Concurrency: Idadi ya maombi ambayo yanaweza kushughulikiwa kwa wakati mmoja.

Mfumo ulio na upatanifu wa juu na muda wa kusubiri wa hali ya juu unaweza kufikia matokeo sawa na mfumo ulio na sarafu ya chini lakini ukawiaji wa chini. Hata hivyo, mwisho ni bora zaidi kwa sababu hujibu kwa haraka maombi ya mtu binafsi.
Kwa hivyo, kutumia "maombi kwa dakika" (au kipimo sawa na wakati) kama kipimo cha msingi cha mifumo ya kupima ukubwa na kujadili utendakazi na washikadau hutoa uwiano. view ya uwezo wa mfumo. Husaidia kuangazia mahitaji ya upatanifu na muda wa kusubiri, ikitoa picha wazi ya kile ambacho mfumo unaweza kushughulikia kwa ufanisi.

Ulinganifu na Kiwango cha Ombi kama Kigezo cha Kuingiza Data
Kwa vipimo sahihi vya kasi (mapitio), ni muhimu kudumisha saizi ya bechi ya injini kutoka kwa mzunguko mmoja wa uchakataji hadi mwingine.

• Kutumia Concurrency Kama Ingizo: Mbinu hii inahakikisha kwamba ukubwa wa kundi unaendelea kuwa thabiti, ikitoa vipimo vya kuaminika.
• Kuweka Kiwango cha Ombi kama Kigezo cha Kuingiza Data : Hili linaweza kuwa tatizo kwa sababu ikiwa kiwango cha ombi kinazidi utumaji wa mfumo, foleni itaendelea kukua, na hivyo kuongeza muda wa kusubiri. Kinyume chake, kuweka kiwango cha ombi chini ya utumaji wa mfumo kunamaanisha kuwa sio nafasi zote zinazopatikana zinatumika, na kusababisha utendakazi wa chini.

Mapendekezo

1. Tumia Concurrency na Ukubwa wa Tokeni kama Vipimo vya Kuingiza Data : Hii inaruhusu majaribio yanayodhibitiwa ambayo yanaweza kusisitiza mfumo kwa mipaka yake au kupima uwajibikaji wake chini ya mizigo nyepesi.
2. Tumia Kiwango cha Ombi kama Kipimo cha Matokeo : Inatoa maarifa kuhusu ni maombi mangapi ambayo mfumo unaweza kushughulikia ndani ya muda uliowekwa, kuonyesha uwezo na ufanisi wake.

Kwa kudhibiti vigezo hivi na kuzingatia vipimo sahihi, makampuni ya biashara yanaweza kubuni mifumo bora zaidi ambayo inasawazisha matokeo, muda wa kusubiri na utumiaji wa rasilimali kwa ufanisi.

Jumla ya Gharama ya Umiliki: Cloud vs On-prem

Uwasilishaji wa Muundo wa Lugha Kubwa (LLM) unakuwa muhimu kwa biashara za kisasa. Kuna chaguzi mbili kuu: msingi wa wingu na msingi. Tutachunguza manufaa na vikwazo vya kila chaguo ili kukusaidia kufanya uamuzi sahihi.

Usambazaji Kulingana na Wingu
Utumiaji wa msingi wa wingu hutoa mfano wa "kulipa-unapoenda", ambapo unalipa tu rasilimali zinazotumiwa.
Hata hivyo, kuna baadhi ya mapungufu ya kuzingatia:

• Usalama wa Data: Isipokuwa leseni ya kiwango cha biashara imenunuliwa, data yako inaweza kutumika kufunza miundo ya siku zijazo, ambayo inaweza kusababisha uvujaji wa data.
• Kutokuwa na uhakika wa Bei: Bei zinaweza kubadilika, na una udhibiti mdogo juu ya muundo, ambao unaweza usiruhusu urekebishaji mzuri au ubinafsishaji.
• Udhibiti Mdogo: Una udhibiti mdogo juu ya kusubiri na upitishaji wa vidokezo.

Gharama ya utumiaji kulingana na wingu kwa kawaida huhesabiwa kulingana na tokeni za pembejeo na utoaji, kwa bei isiyobadilika kwa kila tokeni. Kwa mfanoampHata hivyo, tokeni milioni moja za pembejeo zinaweza kugharimu $15, huku tokeni milioni moja zikigharimu $60.
Ili kukadiria gharama, unaweza kutumia calculator ambayo inazingatia idadi ya tokeni za pembejeo na pato.

Usambazaji wa Majumba
Usambazaji kwenye uwanja unahitaji uwekezaji mkubwa wa mapema lakini hutoa faida kadhaa:

• Udhibiti Kamili: Una udhibiti kamili juu ya mfumo, kuruhusu mabadiliko kama inahitajika.
• Gharama nafuu: Utumiaji usiobadilika ukiwa karibu na uwezo wake, upelekaji kwenye eneo unaweza kuwa wa gharama nafuu baada ya muda mrefu.
• Usalama: Data yako ni salama, na una udhibiti kamili juu ya mfumo.

Gharama zinazohusiana na uwekaji kwenye majengo ni pamoja na:

1. Ununuzi wa Seva ya GPU: Bei ya kununua seva ya GPU, ambayo inatofautiana kulingana na maunzi na aina ya mfumo.
2. Gharama za Kituo cha Data: Gharama zinazohusiana na umeme, nafasi ya kukodisha, wafanyikazi, na gharama zingine.
3. Ada za Leseni: Ada ya kila mwaka ya leseni kwa huduma zozote za ziada kwa mfano, NVAIE

Ili kupata gharama kwa kila Vidokezo vya 1M (simu):

wapi

• Z = Gharama kwa kila Vidokezo vya 1M
• C = Jumla ya Gharama ya Prem wastani wa mwaka mmoja
• X = Vidokezo kwa sekunde (kupitia) kwenye mfumo

Ulinganisho wa Usambazaji wa Wingu na Juu ya Nguzo
Ili kufanya ulinganisho wa haki kati ya wingu na uwekaji wa juu ya majengo, tunadhani kuwa:

1. Miundo iliyotumwa kwenye majukwaa yote mawili ni sawa katika ubora.
2. Muda wa kusubiri na upitaji unaopatikana kwenye majukwaa yote mawili ni sawa.

Tunaweza kulinganisha gharama za on-prem kwa kila vidokezo vya 1M na gharama za wingu kwa kila vidokezo vya 1M ili kupata ulinganisho wa haki. Tunaweza hata kujua kwa tokeni ya pembejeo na gharama ya tokeni kwa on-prem.

Muhtasari wa gharama
Kwa kumalizia, chaguzi zote mbili za uwekaji msingi wa wingu na za msingi zina faida na mapungufu yao.
Usambazaji kulingana na wingu hutoa suluhu inayoweza kunyumbulika na hatari lakini inaweza kuathiri usalama na udhibiti wa data. Usambazaji wa uwanjani hutoa udhibiti kamili na usalama lakini unahitaji uwekezaji wa mapema.
Kwa muda mrefu, sehemu ya mapumziko inafikiwa ambapo uwekaji kwenye eneo una maana ya kifedha kuliko matukio ya wingu.

Pendekezo
Wakati wa kuamua kati ya uwekaji wa msingi wa wingu na uwekaji kwenye majengo, zingatia yafuatayo:

• Usalama wa data: Ikiwa ndio kipaumbele chako cha juu, utumiaji wa tovuti ni bora zaidi.
• Uwezo: Ikiwa unahitaji kuongeza kasi, utumiaji wa msingi wa wingu unaweza kufaa zaidi.
• Bajeti: Ikiwa bajeti ni jambo la kusumbua, upelekaji kwenye majengo unaweza kuwa wa gharama nafuu kwa muda mrefu.

Hatimaye, uamuzi unategemea mahitaji yako maalum na vipaumbele.

Hitimisho
Kwa kumalizia, kukadiria kwa usahihi mahitaji ya utendaji na hesabu ni muhimu wakati wa kubuni mifumo ya utumiaji wa Muundo Kubwa wa Lugha (LLM). Ili kufanikisha hili, kusanya mahitaji mahususi kutoka kwa wateja, ikiwa ni pamoja na uteuzi wa modeli, urefu wa tokeni ya pembejeo, ukadiriaji, na mahitaji ya muda wa kusubiri. Kanuni na miongozo iliyotolewa, kama vile "Sheria ya Kidole" ya kukadiria mahitaji ya kumbukumbu ya GPU, hutumika kama zana muhimu kwa wasanifu wa utatuzi wa kutathmini kwa haraka na kubuni mifumo inayoweza kukidhi matakwa ya wateja.
Kwa kuzingatia vipengele muhimu kama vile ukubwa wa muundo, usahihi na ujazo, unaweza kuboresha usanidi wa mfumo ili kusawazisha utendakazi na gharama. Zaidi ya hayo, mbinu kama vile Marekebisho ya Kiwango cha Chini (LoRA) na Quantized LoRA (QLoRA) zinaweza kupunguza kwa kiasi kikubwa mahitaji ya kumbukumbu wakati wa urekebishaji na mafunzo, kuwezesha masuluhisho ya ufanisi zaidi na ya gharama nafuu.
Mwongozo huu wa Ukubwa wa Uingizaji wa LLM huwezesha maarifa na utaalam unaohitajika ili kuangazia mazingira changamano ya LLM, kuwasilisha utumaji kwa mafanikio, na kutoa masuluhisho yaliyolengwa ambayo yanakidhi mahitaji ya kipekee ya wateja wao. Kwa kufuata miongozo hii na mbinu bora zaidi, unaweza kuhakikisha utendakazi bora zaidi, kupunguza gharama, na kuendeleza mafanikio ya biashara katika uga unaoendelea kwa kasi wa kuchakata lugha asilia.

Taarifa ya Ziada - Kusoma grafu kwa ukubwa

Grafu kulingana na data ya benchmark kutoka NVIDIA NIMs inaonekana kama hii:

Kielelezo cha 5: SampGrafu ya Le throughput vs First Token Latency ya muundo wa Llama 3 8B yenye ingizo 2000 na tokeni 2000 za matokeo
Grafu wasilianifu hukuruhusu kuchagua miundo, vifaa, mchanganyiko wa tokeni ya ingizo +, kipimo cha mhimili wa X na matokeo ya mhimili wa Y. Kwa mhimili wa X tunaweza kuwa na vigezo vya ingizo kama TTFT, TTLT, au ITL kwa tokeni. Kwa mhimili wa Y tuna vigezo vya kutoa kama vile vidokezo kwa sekunde kwa kila mfumo au tokeni_za_kwa kila sekunde kwa kila mfumo au kwa kila mfano wa GPU.
Mzeeampukubwa wa:
Mteja anataka tokeni ya 2000 in, 2000 out na modeli ya llama3 8B na anataka TTFT chini ya sekunde 1. Kwa kutumia vizuizi tunapata nukta kwenye grafu iliyo kushoto ya 1 sec TTFT (FTL), ingeonekana kama hii:

Hii inakuambia kuwa mfumo mmoja wa 8xH100 utaweza kushughulikia hadi watumiaji 400 wanaotumia wakati mmoja (kilele) wakati wa kutumia TRT-LLM. Walakini, tunaona kuwa hii ina muda wa kusubiri kwa jumla zaidi ya sekunde 38. Iwapo tunataka muda wa kusubiri wa muda wa chini zaidi (wacha tuseme chini ya sekunde 20), itatubidi tutoe dhabihu matokeo, kurekebisha mhimili wa X kama latency jumla (TTLT), tunayo:

Hapa tuna uhakika na watumiaji 100 wanaotumia wakati mmoja na 358ms TTFT na chini ya miaka 20 TTLT. Kama tunavyoona, kuweka vizuizi vya kusubiri huathiri pakubwa upitishaji na upatanishi wa kiwango cha juu.
Ili kutekeleza alama kwenye mfumo wako mwenyewe, rejelea NIM ya NVIDIA ya Mwongozo wa Kuweka alama wa LLM kutumia GenAIPerf kupata vipimo vya LLM.

Waandishi
Sachin Gopal Wani ni Mwanasayansi wa Data wa AI huko Lenovo, anayeshughulikia maombi ya mwisho hadi mwisho ya Kujifunza kwa Mashine (ML) kwa wateja tofauti, na kukuza mfumo wa NewTalk AI. Alihitimu kutoka Chuo Kikuu cha Rutgers kama medali ya dhahabu aliyebobea katika Kujifunza kwa Mashine, na amepata Scholarship ya JN Tata.
David Ellison ni Mwanasayansi Mkuu wa Takwimu wa Lenovo ISG. Kupitia Vituo vya Ugunduzi vya AI vya Lenovo vya Marekani na Ulaya, anaongoza timu inayotumia mbinu za kisasa za AI kutoa suluhu kwa wateja wa nje huku akiunga mkono ndani mkakati wa jumla wa AI kwa Kikundi cha Suluhu za Miundombinu ya Ulimwenguni Pote. Kabla ya kujiunga na Lenovo, aliendesha kampuni ya kimataifa ya uchambuzi wa kisayansi na vifaa na kufanya kazi kama Mwanasayansi wa Data kwa Huduma ya Posta ya Marekani. Kabla ya hapo, alipokea PhD katika Uhandisi wa Biomedical kutoka Chuo Kikuu cha Johns Hopkins. Ana machapisho mengi katika majarida ya kiwango cha juu ikiwa ni pamoja na mawili katika Kesi za Chuo cha Kitaifa cha Sayansi.

Familia za bidhaa zinazohusiana

Familia za bidhaa zinazohusiana na hati hii ni zifuatazo:

• Akili Bandia

Matangazo
Lenovo haiwezi kutoa bidhaa, huduma, au vipengele vilivyojadiliwa katika hati hii katika nchi zote. Wasiliana na mwakilishi wako wa karibu wa Lenovo kwa maelezo kuhusu bidhaa na huduma zinazopatikana katika eneo lako kwa sasa. Rejeleo lolote la bidhaa, programu au huduma ya Lenovo halikusudiwi kutaja au kudokeza kuwa ni bidhaa, programu au huduma hiyo ya Lenovo pekee ndiyo inayoweza kutumika. Bidhaa, programu au huduma yoyote inayolingana kiutendaji ambayo haikiuki haki yoyote ya uvumbuzi ya Lenovo inaweza kutumika badala yake. Hata hivyo, ni wajibu wa mtumiaji kutathmini na kuthibitisha utendakazi wa bidhaa, programu au huduma nyingine yoyote. Lenovo inaweza kuwa na hataza au maombi ya hataza yanayosubiri kushughulikia mada iliyofafanuliwa katika waraka huu. Utoaji wa hati hii haukupi leseni yoyote ya hataza hizi. Unaweza kutuma maswali ya leseni, kwa maandishi, kwa:

Lenovo (Merika), Inc.
Hifadhi ya Maendeleo ya 8001
Morrisville, NC 27560
Marekani
Makini: Mkurugenzi wa Lenovo wa Leseni

LENOVO IMETOA TANGAZO HILI "KAMA LILIVYO" BILA UDHAMINI WA AINA YOYOTE, AMA WAZI AU INAYODHANISHWA, PAMOJA NA, LAKINI SI KIKOMO KWA, DHAMANA ILIYOHUSISHWA YA KUTOKUKUKA, UUZAJI AU KUFAA KWA MADHUMUNI. Baadhi ya mamlaka haziruhusu kanusho la dhamana za wazi au zilizodokezwa katika shughuli fulani, kwa hivyo, taarifa hii inaweza isikuhusu wewe.
Maelezo haya yanaweza kujumuisha makosa ya kiufundi au makosa ya uchapaji. Mabadiliko yanafanywa mara kwa mara kwa habari iliyo hapa; mabadiliko haya yatajumuishwa katika matoleo mapya ya uchapishaji. Lenovo inaweza kufanya maboresho na/au mabadiliko katika bidhaa na/au programu/programu zilizofafanuliwa katika chapisho hili wakati wowote bila taarifa.

Bidhaa zilizofafanuliwa katika hati hii hazikusudiwa kutumika katika uwekaji au programu zingine za usaidizi wa maisha ambapo utendakazi unaweza kusababisha majeraha au kifo kwa watu. Taarifa iliyo katika hati hii haiathiri au kubadilisha vipimo au dhamana za bidhaa za Lenovo. Hakuna chochote katika hati hii kitakachofanya kazi kama leseni ya moja kwa moja au inayodokezwa au malipo chini ya haki za uvumbuzi za Lenovo au wahusika wengine. Taarifa zote zilizomo katika waraka huu zilipatikana katika mazingira maalum na zinawasilishwa kama kielelezo. Matokeo yaliyopatikana katika mazingira mengine ya uendeshaji yanaweza kutofautiana. Lenovo inaweza kutumia au kusambaza taarifa yoyote unayotoa kwa njia yoyote ambayo inaamini inafaa bila kukutwika wajibu wowote.
Marejeleo yoyote katika chapisho hili kwa yasiyo ya Lenovo Web tovuti zimetolewa kwa urahisi tu na hazitumiki kwa njia yoyote kama uidhinishaji wa hizo Web tovuti. Nyenzo kwenye hizo Web tovuti sio sehemu ya vifaa vya bidhaa hii ya Lenovo, na matumizi ya hizo Web tovuti ziko katika hatari yako mwenyewe. Data yoyote ya utendaji iliyomo humu ilibainishwa katika mazingira yaliyodhibitiwa. Kwa hiyo, matokeo yaliyopatikana katika mazingira mengine ya uendeshaji yanaweza kutofautiana kwa kiasi kikubwa. Huenda baadhi ya vipimo vilifanywa kwenye mifumo ya kiwango cha maendeleo na hakuna hakikisho kwamba vipimo hivi vitakuwa sawa kwenye mifumo inayopatikana kwa ujumla. Zaidi ya hayo, baadhi ya vipimo vinaweza kuwa vilikadiriwa kwa njia ya ziada. Matokeo halisi yanaweza kutofautiana. Watumiaji wa hati hii wanapaswa kuthibitisha data inayotumika kwa mazingira yao mahususi.

© Hakimiliki Lenovo 2025. Haki zote zimehifadhiwa.

Hati hii, LP2130, iliundwa au kusasishwa tarehe 24 Januari 2025.
Tutumie maoni yako kwa mojawapo ya njia zifuatazo:
Tumia Mtandaoni Wasiliana nasi tenaview fomu inayopatikana kwa: https://lenovopress.lenovo.com/LP2130
Tuma maoni yako kwa barua-pepe kwa: maoni@lenovopress.com
Hati hii inapatikana mtandaoni kwa https://lenovopress.lenovo.com/LP2130.

Alama za biashara
Lenovo na nembo ya Lenovo ni chapa za biashara au chapa za biashara zilizosajiliwa za Lenovo nchini Marekani, nchi nyingine, au zote mbili. Orodha ya sasa ya chapa za biashara za Lenovo inapatikana kwenye Web at https://www.lenovo.com/us/en/legal/copytrade/.
Masharti yafuatayo ni chapa za biashara za Lenovo nchini Marekani, nchi nyingine, au zote mbili: Lenovo®
Majina mengine ya kampuni, bidhaa, au huduma yanaweza kuwa alama za biashara au alama za huduma za wengine.

Mwongozo wa Ukubwa wa Lenovo LLM

Nyaraka / Rasilimali

Mfumo Kamili wa Ukubwa wa Lenovo LLM [pdf] Mwongozo wa Mtumiaji Mfumo wa Ukubwa wa LLM, Ukubwa wa LLM, Mfumo Kamili, Mfumo

Marejeleo

• Mwongozo wa Mtumiaji