GPU бос тұрса да, head of line әсері latency-ді бұзады

Ұзын сұрау тест стендінде сирек қауіпті көрінеді. Ол тек өзі баяу жауап береді. Продакшнда мұндай сұрау өзінен кейін келген ондаған қысқа сұрауды кідіртуі мүмкін. Бұл кезде GPU бос тұрмайды, ал орташа кідіріс айтарлықтай өзгермейді. Head of line әсері дегеніміз осы: кезектің басындағы жұмыс одан кейінгі жұмыстың қанша күтетінін анықтайды.

LLM сервисінде мәселе prefill кезеңіне байланысты одан да жағымсыз. Модель алғашқы шығыс токенін бермей тұрып, кіріс контекстінің бәрін өңдеуі керек. Бірнеше бет келісімшарт, құралдармен жұмыс істейтін агент тарихы немесе үлкен JSON қысқа пайдаланушы сұрауына қарағанда әлдеқайда көп есептеуді талап етеді. Егер барлық сұрау FIFO қағидасымен бір ағынға түссе, қысқа сұрау өз жұмысы үшін емес, бөтен контекст үшін күтеді.

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

Head of line әсері алғашқы токенге дейін басталады

LLM инференсінде head of line әсері көбіне ұзын prefill артында қалған қысқа сұраулардың TTFT көрсеткішінің нашарлауынан байқалады. TTFT, яғни time to first token, сұрауды қабылдаудан бастап алғашқы токенді жібергенге дейінгі уақытты өлшейді. Оның құрамына кезекте күту, кірісті өңдеу, батчқа қосылу және желі жолының шағын бөлігі кіреді.

Бұл метриканы генерацияның толық ұзақтығымен шатастырмаңыз. Интерактивті чат пайдаланушысы жауаптың басын қолайлы уақытта көрсе, ұзын жауапты күте алады. Ал құжат өңдегеннен кейін жауапты толық беретін API үшін қатаң TTFT қажет болмауы мүмкін, бірақ аяқталу мерзімі болжамды болуы керек. Бұл режимдерді бір ғана latency санымен сипаттау мүмкін емес.

Сұраудың екі бөлек кезеңі бар:

• Prefill кіріс токендерін модель арқылы өткізіп, KV cache жасайды. Кіріс параллель өңделетіндіктен, бұл кезең GPU есептеулерін әдетте жақсы жүктейді.
• Decode шығыс токендерін бір-бірден қосады. Мұнда белсенді батч көлемі, KV cache үшін қолжетімді жад және токендер арасындағы уақыт, яғни TPOT маңыздырақ.

DistServe авторлары осы SLO көрсеткіштерін тікелей бөледі: TTFT prefill кезеңіне, ал TPOT decode кезеңіне жатады. Бұл жұмыстың құндылығы әр сервиске дереу бөлек GPU қажет дегенінде емес. Ол екі режимді бір жүктеме ретінде қарастыру әдетінен бас тартуға көмектеседі. Prefill мен decode-ты бірге орындау өзара кедергі туғызады, ал параллельділіктің бір ортақ лимиті қай көрсеткішті нашарлататыныңызды таңдауға мәжбүр етеді.

Кезек сыртта, API шлюзінің ішінде немесе инференс қозғалтқышының өзінде болуы мүмкін. Пайдаланушы айырмашылықты көрмейді. Ол «төлем мәртебесі қандай?» деген қысқа сұраудың кейде бірнеше секундтан кейін ғана жауап бере бастағанын байқайды, себебі оның алдында «180 бет сканнан реквизиттерді шығару» тапсырмасы келген.

Промпттың орташа ұзындығы кінәліні жасырады

Кіріс токендерінің орташа саны кезекті басқару үшін дерлік пайдасыз. Ол есепке ыңғайлы сұраққа жауап береді, бірақ жоспарлағыштың негізгі сұрағына жауап бермейді: нақты сұрау келесі жұмыс класына жол бергенге дейін prefill бюджетін қанша уақыт ұстайды?

Әр endpoint, tenant және тапсырма түрі бойынша input_tokens үлестірімін есептеңіз. Таңдалған уақыт аралығы үшін кемінде p50, p90, p95, p99 және максимум қажет. Содан кейін сол бакеттерге TTFT көрсеткішін салыстырыңыз. Әдетте екі жағдайдың бірі көрінеді:

1. Қысқа сұраулардың өзі жылдам, бірақ ұзын кірістер пайда болған кезде олардың p95 TTFT көрсеткіші бірге өседі.
2. Ұзын сұраулар трафиктің аз бөлігін құрайды, бірақ prefill уақытының шамадан тыс үлкен үлесін жұмсайды.

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

HTTP body көлемін промпт ұзындығының орнына қолданбаңыз. Base64 тіркемелері, бос орындар, JSON құрылымы және токенизатор ерекшеліктері байт санын нашар болжамшы етеді. Сұрауды токенизациядан кейін жіктеңіз немесе модельге сәйкес токенизатор арқылы жібермес бұрын токен санын бағалаңыз. Бір маршрут әртүрлі модельдерге қызмет көрсетсе, бағалауды әр модельдер тобы үшін бөлек сақтаңыз.

Аналитикалық қоймада минуттық терезелер бойынша мынадай кесте құру пайдалы:

класс        сұраулар  p50 input  p95 input  p95 queue  p95 TTFT   бас тарту
interactive  12 400   420        1 100      180 мс      720 мс     3,1%
document     380      18 600     47 900     4 900 мс    8 200 мс   0,4%
agent        1 900    3 100      12 400     1 600 мс    3 100 мс   8,7%

Мұндай пішіндегі сандар API latency жалпы p95 көрсеткішінен маңыздырақ. Олар әртүрлі жұмыс түрлерімен не болып жатқанын көрсетеді. Егер interactive және document бір кезекте отырса, бірінші жол көбіне өзінің жүктемесінен емес, басқа жұмыстан нашарлайды.

Тағы бір жағымсыз жағдай агент сұрауларына қатысты. Бірінші шақыру кезінде кіріс көлемі қалыпты болуы мүмкін, бірақ бірнеше tool call-дан кейін тарих пен құрал нәтижелері контексті үлкейтеді. Тек endpoint-ті журналдасаңыз, «тұрақсыз чатты» көресіз. Қадам нөмірін, тарих көлемін және tool output көлемін жазсаңыз, себептің болжамды екенін көресіз.

Бос GPU бос кезек дегенді білдірмейді

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

Head of line әсерін зерттеу үшін сұрау трассасына бес уақыт белгісін қосыңыз:

{
  "request_id": "r_7f31",
  "class": "interactive_short",
  "input_tokens": 684,
  "max_output_tokens": 320,
  "accepted_at": "2026-07-23T10:14:01.184Z",
  "prefill_started_at": "2026-07-23T10:14:02.016Z",
  "first_token_at": "2026-07-23T10:14:02.441Z",
  "completed_at": "2026-07-23T10:14:05.920Z",
  "finish_reason": "stop"
}

Бұл өрістерден араластырмау керек үш сан шығады:

• queue_ms = prefill_started_at - accepted_at;
• prefill_to_first_token_ms = first_token_at - prefill_started_at;
• generation_ms = completed_at - first_token_at.

queue_ms өссе, admission ережелерін, кезек ретін, бәсекелес кластарды және capacity жетіспеуін тексеріңіз. Екінші көрсеткіш кезек тұрақты кезде өссе, кіріс ұзындығын, модельді, контекст терезесін, prefix cache пен батч параметрлерін тексеріңіз. Мәселе үшінші көрсеткіште болса, decode, шығыс лимиті, sampling және KV cache қысымын қараңыз.

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

Continuous batching қажет, бірақ ол әділдікке кепілдік бермейді. Hugging Face құжаттамасында бұл генерацияның әр қадамында батчты қайта жоспарлау, бос орындарды жаңа сұраулармен бірден толтыру тәсілі ретінде сипатталады. Бұл GPU қолданылуын арттырады, бірақ admission саясаты және бір сұраудың бір итерацияда қоса алатын жұмыс көлемі кідірістің шегін бәрібір анықтайды.

Бір үлкен prefill жүйені әдеттегі жолмен блоктайды

Бір inference пулын және FIFO кезегін елестетіңіз. 09:00:00 кезінде оған 42 000 кіріс токені бар құжатты қорытындылау тапсырмасы келеді. 80 миллисекундтан кейін әрқайсысы 300-800 токен болатын алты қысқа сұрау түседі: оператор чаты, мекенжайды тексеру, ішкі база бойынша іздеу және пайдаланушыға жауап.

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

Ең жаманы, өнім тек max_output_tokens мәнін шектеп, кіріс көлемін шектемеген кезде болады. Команда жауаптар қысқа, сондықтан жүктеме бақылауда деп ойлайды. Кейін клиент CRM экспортын, ұзын хат алмасуды немесе тазаланбаған HTML жібереді. Модель 100 токен ғана шығаруы мүмкін, бірақ алдымен ондаған мың токенді оқуы керек.

Бұл ақауды тексеру оңай. Қысқа класс үшін p95 TTFT уақыт қатарын алыңыз да, онда input_tokens интерактивті трафиктің p99 мәнінен жоғары болған сұрауларды белгілеңіз. Егер TTFT шыңдары ұзын кірістер келген терезелерде пайда болса, FIFO head of line әсерін тудырып тұр. Мінсіз корреляцияны күтпеңіз: белсенді decode, қолжетімді жад және параллельділік нәтижеге әсер етеді. Бірақ қысқа сұраулар ұзын кірістер келген минуттарда нашарласа, маршрутты өзгертуге бұл жеткілікті негіз.

Мәселені «ең қысқалары бірінші» деген қарапайым ережемен шешу мүмкін емес. Тұрақты чат трафигі бар кезде бұл ереже құжаттарды шексіз кейінге ысыруы мүмкін. Ол клиенттерді ұзындық бағасын әдейі төмендетуге де ынталандырады. Жұмыс кластарын, сұраудың кезектегі жасын және фондық жұмысқа арналған шектеулі бюджетті анықтайтын саясат қажет.

Кезектерді пайдаланушыға берілген уәде бойынша бөліңіз

Жақсы кезек схемасы endpoint атауына емес, пайдаланушының күтуіне сүйенеді. Чат, синхронды форма тексеруі және оператор интерфейсінде жұмыс істейтін агент алғашқы токенді жылдам беруі керек. Түнгі жіктеу, архивті қорытындылау және құжаттар кезегін өңдеу жүйе тапсырма күйін адал көрсетсе, кідіріске шыдайды.

Көпшілік командаға үш класс жеткілікті:

• interactive_short: қысқа контекст, ағынды жауап, қатаң TTFT;
• interactive_long: кірісі үлкен агент немесе талдау сұрауы, бірақ пайдаланушы оны интерфейсте күтеді;
• batch_long: құжаттар және бірден басталуды талап етпейтін жаппай операциялар.

Класты модель атымен жасамаңыз. Бір модель чатқа да, пакет өңдеуге де қызмет көрсете алады, ал жылдамдықтары әртүрлі екі модельдің пайдаланушыға берген уәдесі бірдей болуы мүмкін. Маршрут кіріс токендерінің бағасын, рұқсат етілген шығысты, streaming режимін, tenant басымдығын және deadline-ды ескеруі керек.

Шлюз деңгейіндегі ережелер мынадай болуы мүмкін:

classes:
  interactive_short:
    when:
      streaming: true
      input_tokens_lte: 4000
      max_output_tokens_lte: 1200
    ttft_target_ms: 1200
    concurrency_share: 0.60

  interactive_long:
    when:
      streaming: true
      input_tokens_lte: 24000
    ttft_target_ms: 5000
    concurrency_share: 0.25

  batch_long:
    when:
      streaming: false
    admission: rate_limited
    concurrency_share: 0.15
    max_wait_ms: 180000

Бұл нақты қозғалтқыштың конфигурациясы емес. Бұл gateway бөлек кезектерге, пулдарға немесе admission лимиттеріне айналдыруы тиіс келісім. Мұндағы жиі қате, background класына үнемі 15% беру. Түнде бұл capacity-ді бос қалдырады, ал күндіз құжаттарға бәрібір тым көп ресурс беруі мүмкін. Бос қуатты қарызға алу тәсілін қолданыңыз: batch бос ресурсты алады, бірақ интерактивті кезек пайда болғанда оны босатады.

Клиенттер арасындағы әділдік бөлек қосылады. Мыңдаған ұзын құжаты бар бір tenant бүкіл batch_long класын толтырып, басқаларды тіпті фондық өңдеусіз қалдырмауы керек. Кілтке арналған қатар сұраулар лимиті, уақыт аралығына арналған token budget және weighted fair queue жарайды. Токендерді ескермейтін сұрау лимиті бір алып prompt-тан нашар қорғайды.

AI Router бірыңғай OpenAI-үйлесімді endpoint қажет командалар үшін осындай саясаттың нүктесі бола алады. Бағыттауға дейінгі жіктеу барлық кідірісті бір model server ішінде емдеуге тырысқаннан пайдалырақ. Бөлек кілттік rate limit пен сұрау аудиті қай класс пен қай клиент шекті өсіретінін тексеруге көмектеседі, бірақ класс ережелерін бәрібір команданың өзі белгілеуі керек.

Chunked prefill блоктауды қысқартады, бірақ бағасы бар

Chunked prefill ұзын кірісті бөліктерге бөліп, жоспарлағышқа олардың арасына басқа жұмысты енгізуге мүмкіндік береді. 32 000 токенді бір ұзын бөлікпен өңдеудің орнына, қозғалтқыш бірнеше фрагментті өңдеп, басталып қойған сұраулардың decode кезеңін қатар жүргізіп, жаңа қысқа prefill сұрауларын қабылдай алады.

vLLM құжаттамасында бұл нақты сипатталған: chunked prefill үлкен prefill тапсырмаларын кішірек бөліктермен өңдеп, оларды decode-пен араластыруға мүмкіндік береді. Батчтағы токен лимитіне сыймайтын сұрау автоматты түрде бөлінуі мүмкін. Бұл дөрекі блоктаудан қорғайды, бірақ өлшемей тұрып chunk-ты өте кішкентай етуге себеп емес.

Кішкентай фрагмент жоспарлағышқа ауысу үшін көбірек нүкте береді. Сонымен бірге жоспарлау шешімдерінің санын көбейтіп, орындау тиімділігін төмендетуі мүмкін. Үлкен фрагмент есептеу тығыздығын жақсы сақтайды, бірақ қысқа сұраулар қайтадан ұзын жұмыстың кепіліне айналады. Sarathi-Serve дәл осы компромисті сипаттайды: олардың chunked prefill тәсілі белсенді decode-ты тоқтатпай жаңа сұрауларды қосатын жоспар жасайды, алайда фрагмент өлшемі latency мен throughput арасындағы тепе-теңдік параметрі болып қалады.

Chunk size өзгерісін орташа throughput бойынша емес, SLO кестесімен тексеріңіз:

Тұрақты сұрау санымен жасалған бір сынаққа қарап қорытынды жасамаңыз. Нақты қоспаны қайталаңыз: қысқа ағынды сұраулар, бірнеше ұзын құжат, max_output_tokens үлестірімі, клиенттің бас тартуы және burst түрінде келу. Әйтпесе head of line әсері мүлде жоқ әдемі синтетикалық батчты оңтайландырасыз.

SLO тұрақты түрде қақтығысса, бөлек пулдар қажет

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

DistServe prefill мен decode-ты дәл олардың өзара әсерін жою үшін әртүрлі GPU-ларға толық бөлуді ұсынады. Бұл жай параметр емес, қуатты архитектуралық шешім. Оны себепсіз көшірмеңіз: ол күйді тасымалдауды, бөлек масштабтауды және істен шығатын нүктелердің көбеюін талап етеді.

Алдымен радикалдығы төмен схемадан бастаңыз:

1. Интерактивті кезекке жеке concurrency лимиті мен token budget беріңіз.
2. Batch-ті тек бос capacity-де немесе бөлек репликада іске қосыңыз.
3. Синхронды API үшін кіріс токендерінің қатаң шегін қойыңыз.
4. Шектен асқан құжаттарды күйі мен дайын болғандағы нәтижесі бар асинхронды тапсырмаға ауыстырыңыз.
5. Клиент ажыраса немесе deadline өтсе, pending сұраулардан бас тартыңыз.

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

Контексті шектеу тағы бір GPU қосудан пайдалырақ болуы мүмкін

Head of line әсерінің үлкен бөлігін жоюдың ең арзан жолы, интерактивті бағытқа бақыланбайтын контексті қабылдамау. Көп қосымша ағымдағы жауапқа қажет мөлшерден әлдеқайда көп нәрсені модельге жібереді: толық хат алмасу, іздеудің барлық нәтижесі, қайталанатын нұсқаулар, сүзілмеген кестелер және құралдардың толық жауаптары.

Кіріс бюджетін API келісімінің бөлігіне айналдырыңыз. Мысалы, интерфейстік агентке 12 000 кіріс токеніне дейін рұқсат беріңіз. Retrieval бұдан көп қайтарса, ранжировщик қажетті үзінділерді таңдауы керек. Tool үлкен құжат қайтарса, агентке бүкіл шикі мәтін емес, қысқаша мазмұн немесе келесі нысаналы сұрауға арналған сілтеме идентификаторы беріледі. Егер тапсырма файлды толық оқуды қажет етсе, ол interactive_long немесе batch_long класына ауысады.

Prefix caching контекстің басы шынымен бірдей болғанда ғана көмектеседі. Ол ортақ жүйелік нұсқауға, өзгермейтін саясаттар жиынына немесе бірдей шаблонға тиімді. Бірақ әр сұрау жаңа ұзын тарих пен бірегей іздеу нәтижелерін әкелсе, бұл мәселені шешпейді. Cache hit кезінде TTFT қысқарғанын кезек сау деген дәлел ретінде қабылдамаңыз: қызу уақытта cache miss ескі мәселені қайтарады.

Сонымен қатар max_output_tokens мәнін шектеңіз. Ұзын шығыс ең алдымен decode пен KV cache-ке қысым түсіреді, бірақ белсенді тізбектер ұзақ өмір сүретіндіктен, жаңа prefill үшін орын азайып, кезек өседі. Кіріс және шығыс бюджеттері бірге жұмыс істеуі керек.

Сұраулардың максимумын емес, пайдалы өткізу қабілетін өлшеңіз

Егер интерактивті сұраулардың жартысы мақсатты уақыттан кеш жауап бере бастаса, секундына түсетін сұраулардың ең көп саны LLM API сапасы туралы аз айтады. Goodput, яғни өз SLO шегінде қажетті жұмысты аяқтаған сұраулар санын есептеген пайдалырақ. Чат үшін бұл әдетте TTFT пен қолайлы TPOT жиынтығы. Document класы үшін тапсырманың дайын болу мерзімі, нәтиженің дұрыстығы және шексіз қайталап жіберулердің болмауы маңызды.

Қарапайым ескерту ережесін орнатыңыз: жалпы кезек өскенде ғана емес, ұзын pending сұраулар бар кезде қысқа кластың p95 queue_ms мәні өз бюджетінен асқанда да хабарлама беріңіз. Екінші ескерту input_tokens p99 өскенде іске қосылуы керек. Ол агент релизінен кейінгі регрессияны пайдаланушылар шағымданбай тұрып жиі көрсетеді.

Осыдан кейін өзгерістерді бір-бірден тексеріңіз. Алдымен кластарды бөліңіз, содан кейін chunked prefill қосыңыз, кейін кіріс лимиттерін баптаңыз, тек содан соң бөлек репликалар қосыңыз. Бәрін бір уақытта өзгертсеңіз, SLO-ны нақты не ұстап тұрғанын, ал не тек GPU шығынын арттырғанын білмейсіз.

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