LLM инференсі үшін GPU қажеттілігі: қуатты есептеу

Неліктен GPU‑ны «көзбен бағалаудың» орнына есептеу керек

GPU‑ны «көзбен» сатып алу көбіне екі нәтижемен аяқталады: немесе сіз бос тұрған аппаратқа артық төлейсіз, немесе «жетпейтіндей» алып, тез арада кезектерге ұшырайсыз. LLM инференсі үшін бұл айқынырақ көрінеді: қолданушылар жауапты дереу күтеді, және аз ғана кешігу де «қызмет баяу» деген әсер қалдырады.

Қуат жетіспегенде деградация әдетте бір жолмен жүреді. Алдымен жауап уақыты өседі, содан кейін таймауттар басталады, кейін жауап ұзындығына немесе сұраныстар санына шектеулер енгізіледі. Нәтижесінде команда өніміне емес, өрт сөндіруге емес уақыт жұмсайды, ал бизнес «вчера работало, сегодня медленно» дегенді еститін болады.

Инференс оқу процесінен өзгеше: жүктеме жиі және шағын сұраныстар түрінде келеді және адамдардың мінезіне байланысты. Оқыту әдетте «пачкалармен» жоспарланып ұзақ жүреді, ал инференс ағынмен өмір сүреді: көп қысқа сұраныстар, болжамсыз шыңдар және тұрақты кешігу талабы. Сондықтан «жай ғана қуаттырақ алу» әрқашан нәтиже бермейді. Маңыздысы — қанша токен/сек қажет екенін және қандай одновременность болатынын түсіну.

Жақсы жаңалық: негізгі көрсеткіштерді сатып алудан бұрын өлшеуге болады. LLM инференсі үшін GPU қажеттілігін бағалау үшін бірнеше сан жинап, қарапайым есеп жүргізу жеткілікті.

Әдетте алдын ала қаралады:

• шыңды одновременность (нақты қанша сұраныс бірден жасалады);
• промпт пен жауаптың орташа және p95 ұзындығы (токендерде);
• рұқсат етілген кешігу (мысалы, «алғашқы токен 1–2 секунд ішінде»);
• «ауыр» сұраныстардың үлесі (ұзын контекст, ұзын жауаптар).

Мысал: сатып алу бөлімі үшін ішкі ассистент. Әдетте 5–10 адам белсенді, бірақ айдың соңында 30 адам бір уақытта жазып, әрқайсысы ұзын мәтіндер береді. Егер GPU «впритык» таңдалған болса, айдың соңында кезек пайда болады да адамдар қолмен жұмысқа қайта оралады.

Мұндай сценарийлерге инфрақұрылым жоспарлағанда, пилот пен тестке өлшенетін метрикаларды енгізіңіз: бұл конфигурацияны болжаудан арзанға түседі.

Есептеулер үшін қажетті терминдер

Көп қателік формулалардан емес, терминдерді әркім әртүрлі түсінетінінен басталады.

Токендер — модель сұраныс пен жауапты бөлетін мәтін бөліктері. Есептеуде маңыздысы – бөліну:

• енгізу токендері (prompt, жүйелік нұсқаулар мен әңгіме тарихын қоса алғанда);
• шығу токендері (модель генерациялайтын нәтиже).

Енгізу контекстті өңдеу уақытына және жад талаптарына әсер етеді, ал шығу көбінесе GPU‑ның генерацияға қанша уақыт жұмсайтынын анықтайды.

Екі жиі шатастырылатын көрсеткіш:

• Пропускная способность (tokens/sec) — жүйе қанша токенді секундына өңдей/генерациялай алатынын көрсетеді. Бұл «барлығы қанша» туралы.
• Задержка (latency) — сұраныстан бастап алғашқы сөзге дейін және толық жауапқа дейін өтетін уақыт. Бұл бір қолданушы үшін «қаншалықты тез» туралы.

Келесі — одновременность. «Бір уақытта қолданушылар» мен «бір уақытта генерацияланатын сұраныстар» бірдей емес. Қолданушы жауапты оқып, ойланып, теріп жатады, сол уақытта GPU бос тұруы мүмкін. Жоспарлауда маңыздысы — шынайы бір уақытта параллель генерацияланатын сұраныстар саны (және олардың қаншасы ауыр).

LLM контекстінің ұзындығы — модель «басында ұстайтын» токендер саны: ағымдағы сұраныс плюс тарих, құжаттар, нұсқаулар. Контекст ұзаған сайын VRAM тұтынысы өседі және жылдамдық төмендеуі мүмкін. Типтік қателік: барлығымыз жылдамдықты қысқа сұраныстарда өлшейміз, ал шын мәнінде чат тарихы мен бірнеше бет мәтін қосылады.

Соңында, шыңдар мен резерв. Шың — сұраныстар кенет көп болатын қысқа кезең. Резерв — кезек пен кешігу өсуінен сақтану үшін қалдырылатын ресурстар мөлшері.

Есеп жүргізу үшін бастапқы деректерді не жинау керек

Айына қанша қолданушы бар сияқты көрсеткіштер орнына «бір уақытта қанша адам сұрау жібереді» дегенді өлшеу керек, әйтпесе есептің нәтижесі жиі дұрыс болмайды.

Сұраныстарды символдар емес, токендермен өлшеңіз. Орташа мән ғана емес, хвосттарды (p90/p95) білу маңызды: дәл сол ұзын сұраныстар кезектер тудырады.

Минималды жинақ (жақсысы — логтар немесе пилот арқылы):

• шыңдағы сұраныстар/сек және шыңды одновременность (шынайы қанша диалог бір уақытта жауап генерациялайды);
• енгізу мен шығудың орташа және p90/p95 ұзындықтары (токендерде);
• кешігу талаптары: алғашқы токенге дейін уақыт (TTFT) және толық жауапқа дейін уақыт;
• өнімде қандай контекст рұқсат етілген және шын мәнінде қолданылады;
• жүктеме профилі: бірқалыпты ағын ба, әлде қысқа шыңдар бар ма.

Мысал: ішкі қолдау ассистенті. Қалыпты сағатта 30 оператор жұмыс істейді, бірақ бір уақытта 6–8 адам жазатын болады, ал жаңарту шыққанда — 15. 30‑ды «бір уақытта» деп алу артық сатып алуға әкеледі; 6‑ны үнемі деп алу кезектерге әкеледі.

Токендер және одновременность бойынша қадамдық модель

«Қолданушылар саны» орнына шыңдағы токен/сек жылдамдығын және нақты одновременностьті есептеген оңай. Бұл модель ашық және пилотта тексеру оңай.

Есеп қадамдары

1) Шын генерациялар бойынша шыңды бағалаңыз.

Қанша сұраныс бірден жауап генерациялайды — бұл онлайн қолданушылар санынан әдетте аз.

2) Бір сұраныс үшін жылдамдық мақсатты орнатыңыз.

Бір сұранысқа қанша output tokens/sec қажет екенін анықтап, оны одновременностьке көбейтіңіз.

Мысал: 15 одновременных сұраныс × 40 ток/с = 600 output ток/с шыңда.

Енгізу токендерін бөлек есептеңіз: инпут префиллге уақыт «жейді» және ұзын контекст кезінде кешігуді елеулі түрде әсер етеді. Практикалық бөлініс:

• генерация жүктемесі (output ток/с),
• плюс префиллдің үлесі (input токендер × сұраныстар/сек),
• плюс жүйелік промпт, форматтау, қауіпсіздік және маршрутизацияға кеткен шығындар.

Қолданба шығындары әдетте тағы 10–25% алады.

3) Токен/с‑ті GPU‑ға өлшеу арқылы аударыңыз.

Сіздің модельді, контекст ұзындығын және баптауларды (квантование, батч, параллелизм) ескеріп тест өткізіп, бір GPU‑ның қандай токен/сек көрсететінін анықтаңыз.

Негізгі формула:

GPU_қажет = (қажетті токен/сек) / (бір GPU‑ның өлшенген токен/сек)

4) Орташадан гөрі кешігулердің «хвостын» тексеріңіз.

Тек орташаға емес, p95‑ке қараңыз. Егер p95 шыңда құлдырап жатса — резерв қосып тестті қайталаңыз.

Контекст ұзындығы жады мен жылдамдыққа қалай әсер етеді

Контекст ұзындығы — бұл модель жауап жазғанда ескеретін барлық мәтін: ағымдағы сұраныс, әңгіме тарихы және тіркелген материалдар. Контекст ұзаған сайын әр сессияға қажет жады өседі және бірдей GPU‑да жылдамдық төмендейді.

Негізгі себеп — KV cache («кілттер мен мәндердің кэші»). Генерацияның әр қадамына контекст токендері бойынша ішкі мәліметтер сақталады — бұл кэш VRAM‑да орналасады және контекст ұзындығы мен одновременных сессиялар саны бойынша шамамен сызықты өседі. Сондықтан үлкен контекст екі жақтан соғады: VRAM тез таусылады және tokens/sec есептеу көлемінің өсуінен төмендейді.

Жоспарлау үшін қорытынды: құжаттағы максималды контекстті «құжаттағыдай» алып, оның тегін деп ойлау болмайды. Жұмыс лимитін нақты қолданушылар мінезіне қарай таңдаған дұрыс.

Жақсы амал:

• қанша сұраныстың шынымен ұзын тарихты қажет ететінін қараңыз;
• қандай кешігуге дайын екеніңізді шешіңіз.

Егер 90% чат 2–4 мың токенге сияды, ал сирек жағдайларда 16–32 мыңға дейін жетсе — бәріне максимум ұстаудың қажеті жоқ.

Қолданушылар жиі ұзын құжат жіберсе, көмектесетін шаралар: әдепкі бойынша контекст шектеу, тарихты қысқарту (соңғы хабарлар және қысқаша резюме), RAG (қажет үзінділерді тарту), сондай‑ақ «жылдам чаттар» мен «ауыр талдаулар» үшін ағындарды бөлу.

Жоспарлау үшін бірнеше сценарийді есептеңіз: мысалы, «чат 4k контекст» және «құжаттар 16k», әрқайсына сұраныстар үлесін және мақсатты параллельділік қойыңыз.

Шыңдарға резерв қалай қалдыру және артық төлемдемеу

Орташа мән бойынша есептесеңіз, жүйе маңызды сәттерде (сменаның басталуы, ай соңындағы есеп, массовые обращения) құлдырайды: қолданушы орташа жылдамдықты емес, шыңдағы кешігуді көреді.

Практикалық әдіс: p95 (және критикалық сервистер үшін p99‑ға жақын) бойынша шыңды есептеп, анық резерв қосыңыз. Модельде бұл былай болады: барлық одновременных сұраныстар үшін токен/сек шыңын алып, бір GPU‑ның көрсеткішіне бөліп, резерв коэффициентін көбейтесіз.

Резерв жиі таңдалады:

• +20–30%: жүктеме бірқалыпты, шыңдар сирек, қысқа кезек қабылданады;
• +40–60%: шыңдар жиі, тұрақты UX маңызды;
• +80–100%: «толқындар» (кампаниялар, маусымдықтық), кенеттен үлкен өсім мүмкін;
• қосымша +30–50%: егер алдағы 6–12 айда қолданушылар өсуі күтілсе.

Кезектеудің көмегі бар, бірақ шегі бар. Кезектің UX‑ке зиян келтіретін белгілері:

• бірінші токенге күту тұрақты түрде 1–2 секундтан асады;
• жауаптар ырғақты шығады, генерация жылдамдығы секіріп тұрады;
• сұраныстар таймаутқа түседі;
• қолданушылар сұрақты қайталап жібереді, шыңды ушықтырады.

Сонымен бірге резервті деградацияға да ескеріңіз: жаңартулар, қызметтердің қайта іске қосылуы, фондық тапсырмалар (логтау, қауіпсіздік) және күтпеген ұзын диалогтар. Егер тоқтап қалу қымбат болса, N+1 стратегиясы жиі тиімді: бір артық GPU немесе узел резерв ретінде болсын.

Есепті елеулі өзгертетін факторлар

Токен/сек және одновременность бойынша мұқият модель де практикада өзгеруі мүмкін.

Квантование әдетте бір GPU‑да сұраныс тығыздығын арттырады және жады талаптарын төмендетеді, бірақ кейде жауап сапасын нашарлатады. Сапа төмендесе, қолданушылар жиірек анықтау сұрайды, жүктеме өседі.

Батчинг (сұраныстарды «пачкаға» біріктіру) пропускную способность арттырады, бірақ әр қолданушы үшін кешігуді көбейтуі мүмкін. Жылдам бірінші токен қажет чатты тез жауап беретіндей ету үшін агрессивті батчинг сезімталдықты нашарлатуы ықтимал.

Модель өлшемі мен тапсырма түрі де профильді өзгертеді: чат үшін тұрақты төмен кешігулер маңызды, суммаризация үшін жалпы токен/сек мәні маңызды, RAG — қосымша CPU, RAM және диск жүктемесін қосады.

Параллелизм: екінші GPU қашан керек

Модель бір ускорительге сыймаса, параллелизм және бірнеше GPU қажет.

• Бір GPU: модель сыйып, шыңдағы өнімділік жетеді.
• Екі және одан көп GPU: модель бір GPU‑ға сыймайды немесе өте жоғары одновременностьті өңдеу керек.
• Түрлі GPU‑ларды әртүрлі ағындарға бөлу: «жылдам» және «ауыр» сұраныстар үшін бөлек кезектер.

GPU сыртындағы тар жерлерді ұмытпаңыз: CPU сұраныстарды дайындау мен кезектерге, RAM — кэш пен RAG деректеріне, дискілер — модельдер мен индекстерді жүктеуге әсер етеді. Инференсте түйіннің бүкіл құрамын теңестіру маңызды.

GPU таңдау кезінде жиі кездесетін қателіктер

Ең жиі қате — қуатты «қолданушылар саны бойынша» есептеу, ал неше мәтін нақты генерацияланатынын ескермеу. Екі өнімде бірдей 200 белсенді қолданушы болуы мүмкін, бірақ бірінде жауап 2–3 сөйлем, ал екіншісінде бетке тең — GPU қажеттігі бірнеше есеге өзгереді.

Екінші қателік — орташа мен шыңды шатастыру. Орташаға сүйенсеңіз, шыңда кезек пен шағым аласыз; шыңға ғана сатып алсаңыз — артық төлейсіз. Алдын ала шешіңіз: шыңда не істейтініңіз — аз ғана кезекке рұқсат бересіз бе, жауап ұзындығын шектейсіз бе, әлде приоритеттер енгізесіз бе.

Үшінші — тек "токен/сек"-ке қарап, контекст пен KV cache‑ты ұмыту. GPU қысқа сұраныстарда жылдам болуы мүмкін, бірақ жадыға урасу немесе ұзын диалогтарда қатты баяулау мүмкін.

Тағы бір проблема — платформа толық тексерілмейді. Кедергілер болуы мүмкін:

• сұраныстарды дайындауда CPU;
• түйіндер арасындағы желі;
• модельдер мен логтауға арналған дискілер;
• сервер мен драйвер баптаулары.

Соңында, пилотты өткізбеу жиі кездесетін қате. Тіпті 1–2 апталық тест нақты промпттармен және шектеулермен адал метрикалар береді: p95 кешігулер, шынайы tokens/sec және жады тұтыну. Бұрынғысыз оңай «впритык» сатып алып немесе пайдаланылмайтын резерв үшін артық төлеу қаупі жоғары.

Сатып алу немесе сервиске тапсырыс берерде қысқа чек-лист

GPU таңдамас бұрын немесе сервис бюджетін есептегенде нақты жүктемені емес, «орташа температураны» есептемегеніңізге көз жеткізіңіз.

Жүктеме және шыңдар

• Шыңды одновременное пайдалану болжамы бар (орташа ғана емес, p95/p99 көрсеткіштері).
• Сұраныстар профилі анық: қанша қысқа сұрақ және қанша ұзын диалог шыңда.
• «Оқиғалық» шыңдар ескерілген (есеп күні, рассылка, кампания, семестрдің басталуы).

Токендер, контекст және қолданушы күтулері

• Кіріс (prompt) және шығыс (жауап) орташа және p95 ұзындықтары токендерде белгілі.
• Контекст лимиті мен ұзын диалогтарға саясат анықталған: тарихты қысқарту, резюме жасау, «ұзын режим».
• Целевые кешігулер анық: TTFT және толық жауапқа уақыт.
• Кезек рұқсат етіледі ме: мысалы, «шыңда 5 секундқа дейін күту қабылданады».
• Жүктеме өсуі мен сервис операцияларына резерв қосылған: модель жаңартулары, A/B тесттер, мониторинг, узел сәтсіздігіне резерв.

Практикалық тәсіл: бір типтік сценарий (қолдау чаты) және бір ауыр (ұзын құжат). Егер конфигурация екеуін де қажетті кешігумен және шың резервімен тартады — қателесуге мүмкіндігіңіз азаяды.

Егер инференс өз площадкада жоспарланса, GPU‑дан тыс шектеулерді алдын ала тексеріңіз: желі, CPU, дискілер, отказоустойчивость және 24/7 қолдау.

Қарапайым сценарий бойынша есеп мысалы

Ішкі чат‑ассистентті мысалға алайық: регламенттерді табуға, IT сұрақтарына жауап беруге және құжаттарды қысқаша қорытындылауға көмектеседі. Мұнда шыңдағы тұрақтылық маңызды.

Шығу деректері:

• компанияда 400 қызметкер;
• шыңда бір уақытта белсенділері 8% = 32 адам;
• орташа сұраныс: 120 токен, орташа жауап: 220 токен;
• мақсатты кешігу: жауап шамамен 6 секундта генерациялансын.

Шыңдағы генерация жылдамдығын есептейміз:

32 * 220 / 6 ≈ 1170 токен/сек.

Егер конфигурация нақты профильге сәйкес 1200 токен/сек берсе, сіз мақсатқа жақынсыз. Егер 800 токен/сек берсе, орташа генерация уақыты 32 * 220 / 800 = 8.8 секундқа айналады. Шыңда адамдар күтіп, қайта сұрай бастайды — кезек жылдам өседі.

Егер контекст екі есеге ұзарса

Мысалы, ұзын құжаттар салдарынан орташа prompt 120‑дан 240 токенге көтерілсе, формулаға бұл тікелей көрінбеуі мүмкін, бірақ практикада өнімділіктің бір бөлігі жоғалады және жадыға тезірек урасады: ұзын контекст жылдамдықты төмендетеді және батчты шектейді.

Егер контексттің екі еселенуі нәтижесінде жылдамдық 25% төмендесе, 1200 токен/сек → 900 токен/сек болады, және шыңдағы кешігу шамамен 7.8 секундқа өседі.

«Жаман күнге» резерв

«Жаман күн» — бұл одновременных көбеюі (мысалы, 8% орнына 12%) және жауаптардың ұзаруы (мысалы, 220 орнына 300 токен). Онда қажеттілік:

48 * 300 / 6 = 2400 токен/сек.

Көбінесе есептік шыңға 1.3–1.7× резерв қосу ақылды, ал критикалық сервистер үшін қосымша узел ойластыру керек.

Келесі қадамдар: пилот, тексеру және платформа таңдау

Қағаздағы есептен кейін оны нақты жүктеменде тексеріңіз. Ағымдағы өнімнен 1–2 апта лог жинаңыз (немесе пилот өткізіңіз), сол арқылы шынайы tokens/sec, кешігулер мен ұзын диалогтардың үлесін көресіз. Көбінесе дәл сирек, бірақ ауыр сұраныстар орташа көрсеткішті бұзады.

Үш профиль үшін есеп жасаңыз: әдеттегі күн, шың және бір жылға болжау. Пилотта жүктеме генераторын қолдануға болады: одновременность, промпт пен жауап ұзындығын беріп, кешігулерді өлшейсіз.

Тек GPU‑ны ғана емес, түйіннің толық құрамын тексеріңіз. Тар жерлері CPU, RAM, желі, диск, сондай‑ақ салқындату мен қуат болуы мүмкін (GPU ұзақ жүктемеде тұрақты жиілік ұстай алуы үшін).

Іске асыруға мониторингті алдын ала даярлаңыз: tokens/sec метрикалары, кешігудің өсуі бойынша алертер, VRAM толымдылығы бақылауы, модель мен драйвер жаңартуларының кестесі.

Егер толықтай жеткізу және енгізу қажет болса, кейде системный интеграторды қосу ыңғайлы: ол түйінді (GPU, CPU, RAM, желі, охлаждение) сіздің жүктеме профиліңізге сай жинақтайды. Мысалы, GSE.kz Қазақстанда өндіруші және системный интегратор ретінде серверлік бөлік пен 24/7 қолдауды қамтамасыз ете алады, бұл инференс критикалық сервис болғанда эксплуатацияны жеңілдетеді.