Chunked prefill кезек әділдігін қалай өзгертеді

Ұзын құжат чаттың жұмысын сирек бірден және анық бұзады. Ол әдетте ондаған пайдаланушы жауаптың жалғасын күтіп тұрған сәтте келеді де, GPU-ға үздіксіз жұмыстың жеткілікті үлкен бөлігін береді. Соның салдарынан чат жауапты үзіп-үзіп бере бастайды немесе бірінші токенге дейін ұзақ үнсіз қалады.

Chunked prefill дәл осы кезек мәселесін шешеді. Ол үлкен промптты бастапқы өңдеуді бөліктерге бөліп, жоспарлаушыға осы бөліктердің арасында ашық диалогтардың decode жұмысын орындауға мүмкіндік береді. Бірақ чанк өлшемі әмбебап баптау емес. Кішкентай бөлік интерактивтілікті жиі қорғайды, үлкен бөлік файлды жылдамырақ өткізеді, ал тым кішкентай бөлік GPU мен жоспарлаушыны үйлестіру жұмысына артық уақыт жұмсатуы мүмкін.

Аралас қызметте орташа жылдамдықты да, GPU-дың әдемі көрінетін жүктемесін де оңтайландыру жеткіліксіз. Кім күте алатынын алдын ала шешу керек: қысқа чаттағы пайдаланушы ма, жүз беттік PDF импорттаушысы ма, әлде екеуі де әртүрлі, өлшенетін уәделер шегінде ме.

Prefill және decode GPU-дың әртүрлі жұмысын бөлісуге таласады

Prefill кіріс токендері бойынша KV cache құрады. Ұзын құжат үшін бұл үлкен есептеу міндеті болуы мүмкін: модель бірінші токенді шығармас бұрын бүкіл контексті бір рет өңдеуі керек. Decode басталып қойған жауаптарды әр итерацияда бір немесе бірнеше токеннен жалғастырады және жиналған KV cache-ті оқуға көбірек тәуелді.

Бұл фазалардың бейіні әртүрлі, бірақ ортақ GPU пулында олар бір жоспарға таласады. Егер сервер ұзын prefill-ді толық іске қосса, чаттағы жаңа қысқа реплика үлкен есептеу іске қосылуы аяқталғанша күтуі мүмкін. Ал prefill-ді шексіз ұсақтаса, ұзын файл көп кідіріп, бір іске қосуға келетін пайдалы жұмыс азаяды.

vLLM құжаттамасы бұл айырбасты тікелей сипаттайды: chunked prefill қосылғанда жоспарлаушы алдымен күтіп тұрған decode сұрауларын орналастырады, содан кейін қалған prefill бюджетін береді. Егер промпт max_num_batched_tokens мәніне сыймаса, сервер оны бөліктерге бөледі. Құжаттама авторлары қарама-қарсы әсерлерді де көрсетеді: кіші бюджет inter-token latency көрсеткішін жақсартады, ал үлкен бюджет жаңа сұраулардың time to first token мәніне көмектеседі.

Мұнда екі нәрсе жиі шатастырылады. Чанк өлшемі құжат өлшеміне тең емес. vLLM-дегі max_num_batched_tokens - жоспарланған бір итерацияға арналған токен бюджеті. Оған decode және бір немесе бірнеше prefill бөліктері кіруі мүмкін. Ұзын сұраудың нақты бөлік ұзындығы осы бюджеттің бос қалған бөлігіне және батчтың сол сәттегі құрамына байланысты.

Әділдікті бір орташа кідіріспен өлшеу мүмкін емес

Кезек әділдігі дегеніміз - жұмысы аз сұраулар бір ауыр көршісінің кесірінен кездейсоқ жазаланбауы және ауыр сұраудың кезекте мәңгі қалмауы. Бұл барлық сұрау бір уақытта аяқталуы керек дегенді білдірмейді. Чат пен құжат жүктеуі әртүрлі жұмыс атқарады, сондықтан олардың күту талаптары да бөлек болуы тиіс.

Чат үшін екі метрика пайдалы. TTFT, time to first token, пайдаланушының жауап басталғанша қанша күтетінін көрсетеді. ITL, inter-token latency, кейінгі токендер арасындағы үзілістерді көрсетеді. Қызметтің орташа TTFT көрсеткіші жақсы болып, жауаптың ортасында пайдаланушыларды ұзақ күттіре беруі мүмкін. Ағындық интерфейс үшін ITL-дің P95 және P99 мәндері әдетте орташа көрсеткіштен маңызды.

Ұзын файл үшін бірінші токенге дейінгі уақытты, толық prefill уақытын және кірісті өңдеудің пайдалы жылдамдығын өлшеңіз:

prefill throughput = кіріс токендерінің саны / кезекке қойылған сәттен KV cache дайын болғанға дейінгі уақыт

Бұл жылдамдықты генерациядағы секундына токендер санымен алмастырмаңыз. Файл қысқа қорытынды шығаруы мүмкін, бірақ оған өте үлкен prefill қажет болады. Тек output tokens per second көрсеткішін өлшесеңіз, ұзын құжаттарды импорттау іс жүзінде тоқтап қалғанын байқамайсыз.

Соңында кезекте күту уақытын модельдің жұмыс уақытынан бөлек есептеңіз. TTFT өскенде бұл үш түрлі ақауды білдіруі мүмкін: сұрау кезек салдарынан GPU-ға кірмеді, prefill ұзақ орындалды немесе KV cache сыймай, сервер ығыстыруды не preemption-ді бастады. Бұл жағдайлардың әрқайсысына басқа әрекет қажет.

Кішкентай чанк чатты қорғайды, бірақ тегін емес

Токендердің шағын бюджеті бір prefill іске қосуының GPU-ды ұстап тұратын уақытын шектейді. Сондықтан decode келесі итерацияда орынға жиірек ие болып, чаттағы жауап бірқалыпты жүреді. Құжаттармен бәсекелестік кезінде бұл ITL-дің ұзын құйрығын қысқартады.

Баға үш бөліктен тұрады. Біріншіден, ұзын сұрау жоспарлаудың көбірек циклінен өтеді. Екіншіден, әр іске қосуда prefill токендері тым аз қалса, сервер ірі матрицалық операцияларды нашар пайдаланады. Үшіншіден, decode үздіксіз келіп тұрса, prefill бюджеттен тек ұсақ бөліктер алуы мүмкін. Құжат кезектен жоғалмайды, бірақ оның аяқталуы созыла береді.

Үлкен бюджет кері көрініс береді. Ол жаңа үлкен сұраудың TTFT көрсеткішін және файл жүктеу жылдамдығын айтарлықтай жақсарта алады, өйткені сервер бір іске қосуда көбірек кіріс токенін өңдейді. Бірақ осындай іске қосу едәуір уақыт алса, пайдаланушылар ITL-дің секіргенін көреді. Дауыстық көмекші немесе операторлық чат үшін бұл құжатты фондық режимде баяу импорттаудан да жаман болуы мүмкін.

«Жадқа сыйған ең үлкен мәнді қойыңыз» деген кеңес аралас жүктеме үшін дұрыс емес. Жад KV cache сыятынын көрсетеді. Әділдікті бір сұрау класының екіншісі кезекке қайта келгенше қанша жұмыс орындай алатыны анықтайды.

Эксперимент сұрауларды соқтығыстыруы керек, оларды орташа есептемеуі керек

Chunked prefill-ді бос сервердегі жалғыз сұраумен емес, екі ағынның бәсекесі арқылы тексеріңіз. Бірінші ағын чаттарды имитациялайды: қысқа контекст, қысқа жауап және тұрақты келіп түсетін сұраулар. Екінші ағын ұзын құжаттарды береді, олардың бір бөлігі әдеттегі RAG контекстіңізден айтарлықтай ұзын болуы тиіс.

Модельді, кванттауды, GPU-ды, контекст шегін, sampling параметрлерін және бір уақытта қосылған клиенттер санын бекітіңіз. Бір тест барысында тек токен бюджетін және ұзын prefill-ге қатысты ережелерді өзгертіңіз. Модельді, cache policy параметрін және чанк өлшемін қатар өзгертсеңіз, нәтиже ештеңені түсіндірмейді.

Тесттің ең аз матрицасы мынадай:

Барлық құжатқа бірдей сұрауларды қолданбаңыз. Нақты кезекте ауыр құйрық болады: орташа контексттер көп, өте ұзындары аз болады. Кемінде үш топ жасаңыз: мысалы, чатқа арналған қысқа сұрау, әдеттегі RAG контексті және үлкен құжат. Токенизатор қажетті ұзындықты берсе, мазмұнды қайталанатын бейтарап мәтінмен толтыруға болады. Жоспарлаушыны өлшеу үшін мәтіннің мағынасы емес, токендердегі бақыланатын ұзындық қажет.

Алдымен chunked prefill өшірілген немесе қозғалтқыш мүмкіндік берсе, бөлшектеу барынша үлкен етіп қойылған базалық тест жүргізіңіз. Ол decode кезегін беру мүмкіндігі жоқ head-of-line blocking жағдайының қалай көрінетінін көрсетеді. Кейін оны бірнеше бюджетпен салыстырыңыз. Бір ғана жеңімпазды іздемеңіз: чат SLO талабын орындай алмайтын шекті табу керек.

Сервердің қысқаша есебін ғана емес, сұрау оқиғаларын да журналдаңыз

Клиент және сервер жағында timestamps қажет. Клиент жіберу уақытын, бірінші алынған токенді, әр келесі токенді және жауаптың аяқталуын жазуы тиіс. Сервер метрикаларында кезек, белсенді sequence саны, KV cache қолданылуы және scheduler итерациясының ұзақтығы болуы керек.

Төмендегі жазба үлгісін JSON Lines ретінде сақтауға ыңғайлы. Ол нақты SDK-ға тәуелді емес және кейін TTFT, ITL мен толық өңдеу уақытын қайта есептеуге мүмкіндік береді.

{
  "request_id": "chat-00421",
  "class": "chat",
  "prompt_tokens": 420,
  "requested_output_tokens": 160,
  "sent_at_ms": 1730000000000,
  "first_token_at_ms": 1730000000840,
  "finished_at_ms": 1730000006420,
  "output_tokens": 147,
  "inter_token_ms_p95": 54
}

Құжат үшін class мәнін document етіп өзгертіп, қозғалтқыш немесе қабат бере алса, prefill_ready_at_ms параметрін сақтаңыз. Егер бере алмаса, TTFT-ті таза prefill деп көрсетпеңіз. Есепте метриканы нақты атаңыз: «құжаттың бірінші шығыс токеніне дейінгі уақыт». Оның құрамына кезек, prefill және ең аз генерация кіреді.

Жиынтық кестеде әр тест үшін кемінде мына жолдар болуы керек:

• Чаттар үшін TTFT-дің P50, P95 және P99 мәндері.
• Чаттар үшін ITL-дің P50, P95 және P99 мәндері.
• Құжаттар үшін толық уақыттың P50 және P95 мәндері.
• Құжаттардың секундына кіріс токендері.
• Құжаттар кезегі бос емес болған уақыттың үлесі.

Соңғы жол маңызды. Егер GPU үнемі дерлік бос емес болып, құжаттар кезегі өсіп жатса, сіз жоғары жүктемені тапқан жоқсыз. Интерактивті сұраулар фондық жұмыстан қалған бюджетті жүйелі түрде тартып алатын режимді таптыңыз.

GPU жүктемесі себепті көрсетеді, қызмет сапасын емес

Орташа GPU utilization диагностикалық белгі ретінде пайдалы, бірақ қорытынды метрика ретінде әлсіз. GPU-ды ұзын prefill-мен толықтай дерлік бос емес ұстап, чат жұмысын бұзуға болады. Кішкентай чанк салдарынан орташа жүктемені азайтып, пайдаланушыларға уәде етілген кідірісті сақтауға да болады. Таңдау мониторинг панеліндегі ең үлкен санға емес, өнімнің құнына байланысты жасалуы керек.

Бақылауды кемінде төрт графикке бөліңіз: utilization, GPU жады, KV cache usage және бір scheduler iteration ұзақтығы. Бюджет азайғанда ITL жақсарып, итерация ұзақтығы қысқарса, бұл күтілетін нәтиже. Егер сонымен бірге құжаттар кезегі күрт өссе, қазіргі чат қарқыны үшін тым кішкентай бөлік таңдадыңыз.

Жадты есептеуден бөлек бақылаңыз. Chunked prefill ұзын сұраудың соңғы KV cache көлемін азайтпайды. Prefill аяқталғаннан кейін де құжат генерациясы біткенше немесе қозғалтқыш sequence-ті босатқанша жадта орын алады. Үлкен контекст жиі preemption-ге әкелсе, чанк өлшемін азайту ITL-ді тегістеуі мүмкін, бірақ жад тапшылығын жоймайды.

Бір қарағанда түсініксіз тағы бір жағдай бар: GPU utilisation төмендейді, ал latency нашарлайды. Әдетте бұл белсенді сұраулар аз кезде тым ұсақ гранулярлықтың белгісі. Әр раундта пайдалы жұмыс аз болады, батчтар толмайды, жоспарлаушы басқаруды жиірек береді. Мұндай жағдайда бәсекелес сұрауларды қосу қызметті емдемейді, тек нашар параметрді жасырады.

Ұзын prefill-ді шектеу қарапайым FCFS-тен маңызды

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

vLLM chunked prefill үшін жеке параметрлер береді: long_prefill_token_threshold, ішінара өңделетін prefill-дердің ең көп саны және бір уақытта өңделетін ұзын prefill саны. Құжаттамада max_long_partial_prefills мәнін max_num_partial_prefills мәнінен төмен қою кей жағдайда қысқа промпттардың ұзындардан озып, latency көрсеткішін жақсартатыны тікелей айтылған.

Ортақ пулға арналған практикалық саясат әдетте былай көрінеді:

1. «Ұзын» промпт шегін модельдің контекст терезесіне емес, нақты кірістердің таралуына қарап анықтаңыз.
2. Алғашқы тестте бір уақытта орындалатын ұзын partial prefill санын біреумен шектеңіз.
3. Жад пен модель мүмкіндік берсе, бірнеше қысқа prefill-дің параллель орындалуына рұқсат етіңіз.
4. Тұрақты жоғары чат жүктемесі кезінде құжаттардың аш қалмайтынын тексеріңіз.
5. Егер аш қалса, чанк өлшемін максимумға жай ғана өсірмей, оларға уақыт квотасын, жеке кезекті немесе жеке пулды бөліңіз.

Бұл аяқталу уақыты бәріне тең болады деген уәде емес. Бұл бір ауыр санаттың есептеу ресурстарын бақылаусыз басып алуына жол бермейтін ереже. Fairness-Aware and Latency-Controllable Scheduling for Chunked-Prefill LLM Serving атты жақында шыққан зерттеу де осындай қорытындыға келеді: статикалық бюджет пен қатаң FCFS кідірістің болжанбайтын құйрығын және starvation жағдайын туғызады, сондықтан басымдық жинақталған күту уақытын және қалған prefill көлемін ескеруі тиіс.

Бір мысал аңғал баптаудың қай жерде бұзылатынын көрсетеді

Бір GPU пулы бар деп елестетіңіз. Онда әрқайсысы қысқа жауап ағынын беретін 30 чат жұмыс істеп тұр. Содан кейін үлкен промпты бар құжат келеді. Үлкен бюджет кезінде сервер құжат prefill-інің негізгі бөлігін жақын итерацияларға қояды. Келесі жоспарлау кезінде decode басымдыққа ие болады, бірақ пайдаланушылар ағымдағы итерацияның созылғанын көріп үлгерді. Decode кезегі ресми түрде бұзылмаса да, олардың ITL көрсеткіші өседі.

Енді бюджетті күрт азайтыңыз. Чаттар токендерді бірқалыпты шығара бастайды. Бірақ decode-тен кейін құжатқа аз ғана қалдық қалады. Жаңа чаттар үздіксіз келсе, бұл қалдық үнемі аз болады да, құжат бірнеше минут күтуі мүмкін. Дашбордта чат өте жақсы көрінеді, ал файл жүктеу операциясы жасырын шексіз кезекке айналады.

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

Мұны prefill және decode фазаларын әртүрлі GPU-ға бөлумен шатастырмаңыз. Бөлек пулдар фазалар арасындағы тікелей бәсекені жояды, бірақ бағыттау мен KV cache тасымалдаудың жаңа құнын тудырады. P/D-Serve зерттеуі дәл осындай бөлуді әртүрлі фазаларды масштабтау тәсілі ретінде қарастырады, оны кезек саясатының автоматты баламасы деп есептемейді. Бір ортақ пулда дұрыс бапталған chunked prefill көбіне қарапайым алғашқы қадам болып қала береді.

Басқа кластердің чанк өлшемін өз кластеріңізге көшірмеңіз

2048, 8192 немесе 16384 сандары модельсіз, GPU-сыз, жауап ұзындығы мен жүктеме құрамынсыз ештеңе білдірмейді. vLLM-дің қазіргі құжаттамасында тек бағдарлар берілген: 2048 сияқты кіші мәндер ITL-ді жақсартады, ал үлкен GPU мен шағын модельдерде максималды өткізу қабілеті үшін 8192-ден жоғары мәндер ұсынылады. Бұл іздеу бағыты, дайын production конфигурациясы емес.

Алдымен өнімдік шектеуді таңдаңыз. Мысалы, құжаттар қатар өңделіп жатқанда чаттың P95 ITL көрсеткіші шектен аспауы, ал құжаттың толық уақытының P95 мәні фондық операция үшін қолайлы болып қалуы керек. Содан кейін чат SLO талабын ұстайтын ең үлкен бюджетті табыңыз. Мұндай таңдау әдетте ойланбай таңдалған өте кішкентай чанкке қарағанда құжаттарға көбірек пайдалы өткізу қабілетін береді.

Бір API арқылы әртүрлі модельдерге қызмет көрсетсеңіз, әр маңызды «модель плюс GPU» жұбын бөлек тестілеңіз. AI Router қолданбалық OpenAI үйлесімді шақыруды өзгертпей, қажетті модельге бағыттауға мүмкіндік береді, бірақ кезек параметрлері мен latency нәтижелері нақты inference қозғалтқышы мен жабдыққа тиесілі.

Бюджетті таңдағаннан кейін релиз процесіне регрессиялық тест қосыңыз. Жаңа жүйелік промпт қосу, tool calling функциясын іске қосу немесе модельді ауыстыру кіріс ұзындығын өзгертеді. Кешегі токендер таралуы үшін орынды болған баптау, құйрық көрсеткіштерін ешкім бақыламаса, ұзақ үзілістердің көзіне тез айналады.

Баптау аш қалуды тексергеннен кейін ғана дайын болады

Chunked prefill-ді қосу мақсаты ауыстырып-қосқыштың өзі емес, басқарылатын бәсеке болуы керек. Жақсы нәтиже қарапайым көрінеді: қысқа чаттар жүктеме кезінде TTFT және ITL көрсеткіштерін сақтайды, құжаттар алға жылжуын жалғастырады, ал GPU тым ұсақ итерациялардан үнемі босап қалмайды.

Тек әдеттегі режимді емес, ең нашар жағдайды да тексеріңіз. Ұзақ чат ағынын іске қосып, үлкен файлдар кезегін қосыңыз да, ең ескі құжатты бақылаңыз. Егер оның кезекте тұрған жасы шексіз өссе, саясатыңыз чатты қорғайды, бірақ әділ емес. Кезек ережесін, бір уақытта орындалатын ұзын prefill санын немесе пул архитектурасын түзетіңіз. Мұны чанк өлшемінің өзі шеше алмайды.