Белсенді сұрауды GPU репликалары арасында миграциялауға бола ма?

Белсенді генерацияны шлюзде сол prompt пен сол модель бар болғаны үшін басқа GPU репликасына адал түрде көшіру мүмкін емес. Decode басталғаннан кейін бастапқы репликада сұрауға тән жеке күй пайда болады: өңделген контекстің KV cache-і, тізбектегі позиция, сэмплер күйі және кей конфигурацияларда speculative decoding күйі. Бұл реплика жоғалса, жаңа реплика келесі токеннің қандай болуы керегін білмейді.

Сондықтан белсенді сұрау миграциясы бір механизм емес, екі түрлі режимді білдіруі керек: бірінші токен жіберілгенге дейін есептеуді қайталау немесе басталып кеткен ағынды дұрыс аяқтау. Бұл шекараны автоматты retry арқылы жасыру көбіне одан да жаман ақауға әкеледі: пайдаланушы қайталанған үзінді, толық емес JSON немесе бір әрекетке берілген екі түрлі жауап алады.

Decode-ті нақты сұраудың күйінсіз жалғастыру мүмкін емес

Prefill-тен кейін қозғалтқыш әр attention қабаты үшін кілттер мен мәндерді KV cache-ке орналастырады. Decode осы cache-ті пайдаланып, бүкіл контексті қайта өңдемей келесі токенді есептейді. Бұл request_id арқылы қалпына келтіруге болатын модельдің ортақ суреті емес. Бұл нақты воркердің жадындағы нақты тізбекке тиесілі өзгермелі күй.

Шын мәнінде жалғастыру үшін жаңа реплика кемінде мына деректердің келісілген суретін алуы керек:

• қабылданған және генерацияланған барлық токендердің KV cache-і;
• нақты позиция мен attention маскалары;
• сэмплер параметрлері мен кездейсоқ сандар генераторының күйі;
• салмақтар, токенизатор, чат шаблоны және қосылған адаптерлер идентификаторлары;
• speculative decoding жұмыс істесе, draft-модельдің күйі.

Осы бөліктердің біреуі жоғалса да, «жалғастыру» жаңа іске қосуға айналады. Кейде жаңа іске қосу сырттай ұқсас көрінеді, әсіресе temperature=0 болып, жауап қысқа болса. Бірақ бұл кепілдік емес. Параллель орындау, әртүрлі ядролар, кванттау, қозғалтқыштың әртүрлі нұсқалары және MoE маршрутизациясы команда детерминизм күтетін жағдайда да токен таңдауын өзгертуі мүмкін.

vLLM құжаттамасында automatic prefix caching префиксі сәйкес келетін жаңа сұраулар үшін KV cache-ті қайта пайдалану ретінде сипатталады. Бұл қайталама prefill үшін пайдалы, бірақ тірі тізбекті воркерлер арасында көшірумен тең емес. Құжаттамада және SGLang RFC материалдарында KV cache-ті қашықтан әрі иерархиялық сақтау бөлек қарастырылады, себебі бір воркердің жергілікті cache-і қалған пулға өздігінен қолжетімді емес.

API-де, журналдарда және пайдаланушы интерфейсінде генерацияны қайталауды «жалғастыру» деп атамаңыз. Бұл кейін даулы төлемді, құрал шақыруын немесе толық емес құрылымдық жауапты талдау қажет болған жерде келісімшартты бұлыңғыр етеді.

Қайталама prefill клиентке бірінші токен жіберілгенге дейін ғана қауіпсіз

Шлюз басқа репликада prefill әрекетін қайталай алады, егер екі нәрсені білсе: бастапқы воркер сұрауды енді орындамайды және клиент нәтижеден бір де бір үзінді алмаған. Бұл сәтте қайталау кідірісті өзгертеді, бірақ сұраудың сырттай байқалатын мағынасын өзгертпейді.

Шекара ішкі генерация фактісімен емес, жеткізу фактісімен анықталуы керек. Воркер он токенді есептеп қойған болуы мүмкін, бірақ шлюз клиент сокетіне бірінші SSE event жазбаған. Мұндайда қайталауға болады. Керісінше, бір ғана жіберілген delta автоматты retry әрекетін қауіпті етеді, тіпті воркер одан кейін бірден істен шықса да.

Фазаны HTTP статусынан бөлек сақтау пайдалы:

{
  "request_id": "req_01J...",
  "phase": "prefill",
  "attempt": 1,
  "first_delta_sent": false,
  "model_revision": "model-x@sha256:...",
  "retry_budget": 1
}

Бірінші үзінді жіберілгеннен кейін шлюз ауысуды бекітеді:

{
  "request_id": "req_01J...",
  "phase": "decode",
  "attempt": 1,
  "first_delta_sent": true,
  "delivered_output_tokens": 37
}

Бұл журнал әдемі observability панелі үшін қажет емес. Ол апат кезінде нақты сұраққа жауап береді: роутер сол кірісті басқа репликаға жіберуге құқылы ма? Егер first_delta_sent=false болса, құқылы. Егер true болса, сұраудың толық күйін берудің тексерілген механизмі жоқ жағдайда шлюз ағынды қатемен аяқтауы керек.

Бұл белгіні status=200 мәнімен алмастыруға болмайды. Streaming HTTP кезінде сервер 200 тақырыптарын жіберіп, кейін мазмұны бар бірінші chunk-ке дейін істен шығуы мүмкін. Сондай-ақ ол бірінші chunk-ті прокси буферіне жазуы мүмкін, бірақ тізбектің келесі бөлігіндегі үзіліс салдарынан клиент оны көрмейді. «Клиент ештеңе алған жоқ» деген қатаң кепілдік үшін роутер телеметриясының өзі жеткіліксіз. Көп жүйеге консервативті ереже жеткілікті: downstream қосылымына бірінші жазудан кейін retry тыйым салынады.

Ақау себебін баяу жауаптан ажырату керек

Жоғалған әр heartbeat GPU репликасы жоғалды дегенді білдірмейді. Қысқа таймаут бойынша автоматты failover жиі екі белсенді әрекет жасайды: ескі реплика кідірістен шығып, жұмысын жалғастырады, ал жаңа реплика сұрауды қайталайды. Идемпотентті емес tool call кезінде бұл мәтін мәселесі емес, бизнестегі қосарланған әрекетке айналады.

Роутер кемінде төрт жағдайды ажыратуы керек.

1. Реплика анық істен шықты. Процесс аяқталды, оркестратор pod жоғалғанын хабарлады, upstream қосылымы жабылды. Бірінші токенге дейін сұрауды қайталауға болады.
2. Шлюз бен реплика арасындағы желі үзілді. Реплика decode әрекетін жалғастыруы мүмкін. Сұрауды тек расталған cancel-ден кейін немесе бастапқы әрекеттің нәтижені жариялауға құқығы қалмайтын қатаң lease мерзімі біткен соң қайталауға болады.
3. Репликаға артық жүктеме түсті. Ұзақ prefill, кезек немесе үлкен batch жинау ақауға тең емес. Жұмсақ latency таймауты бойынша көшіру жүктемені арттырып, пулды толық істен шығаруы мүмкін.
4. Клиентке downstream қосылымы үзілді. Нәтиже енді қажет емес, бірақ upstream GPU-ды пайдаланып тұруы мүмкін. Шлюз бастапқы воркерге cancel жіберіп, слотты босатуы керек, қосалқы әрекетті іске қоспауы тиіс.

Ішкі lease бұл схеманы басқаруға мүмкіндік береді. Роутер әрекетке идентификатор және жариялау мерзімін береді. Воркер әр жіберілетін chunk алдында lease әлі жарамды екенін тексеруге міндетті. Ауысу кезінде роутер ескі әрекеттің lease-ін қайтарып алып, жаңасын жасайды. Бұл жоғалған токендерді қайтармайды, бірақ екі репликаның бір пайдаланушы ағынына қатар жазу ықтималдығын азайтады.

Cancel жіберуді cancel дәлелімен шатастырмаңыз. Жүктемесі жоғары воркерге жіберілген HTTP cancel сұрауы жетпеуі немесе тым кеш жетуі мүмкін. Жүйе растау алғанша немесе lease мерзімі біткенше ескі сұрауды ықтимал түрде тірі деп санау керек.

Prefix cache қайталауды қысқартады, бірақ сессияны көшірмейді

Жаңа реплика ортақ префикстің KV cache-ін таба алса, қайталама prefill міндетті түрде қымбат болмайды. Жүйелік prompt, құралдар сипаттамасы, қауіпсіздік саясаты және ұзақ тарихтың бастапқы бөлігі әрекеттер арасында жиі бірдей болады. Префикс кэші тек жетіспейтін соңғы бөлікті есептеуге мүмкіндік береді.

Бірақ осыдан жиі қате қорытынды жасалады: «distributed KV cache бар болса, decode-ті миграциялауға болады». Ортақ cache әдетте кіріс тізбегінің аяқталған немесе қайта пайдалануға жарамды блоктарын индекстейді. Белсенді decode әр токеннен кейін тізбекті өзгертеді. Оның cache-і сұрауға бекітілуі, GPU жадында орналасуы, нақты attention backend форматына ие болуы және модельдің құрылғыларға бөлінуіне тәуелді болуы мүмкін.

SGLang prefill/decode disaggregation және осы рөлдер арасында KV cache беруді тікелей дамытып жатыр. Оның roadmap материалдарында агенттік сценарийлердегі ортақ префикстер үшін delta KV беру сипатталған, ал релиздерде decode-side prefix cache бөлек аталады. Бұл орындау архитектурасын жеделдету, decode воркері жауап ортасында істен шыққанда оны үзіліссіз өткеру туралы уәде емес.

Cache тасымалды деп есептемей тұрып, оның үйлесімділігін тексеріңіз. Модель атауының сәйкес келуі жеткіліксіз. Мыналар бірдей болуы керек:

• салмақтар нұсқасы мен кванттау форматы;
• tokenizer және chat template қолдану ережелері;
• attention архитектурасы және KV cache dtype;
• tensor parallelism, pipeline parallelism және блоктар layout-ы;
• LoRA-адаптерлер жиыны мен олардың реті.

Кемінде бір параметр өзгеше болса, cache-ті «сәті түссе» деп араластыруға болмайды. Cache қатесі баяу prefill-тен де қауіпті: ол нанымды, бірақ қате жауап қайтаруы мүмкін. SGLang жария есептерінде блок шекарасындағы KV cache бүлінуінің мысалы бар, онда temperature=0 кезінде бірдей prompt әртүрлі тізбек берген. Бұл cache дұрыстығын тек latency оңтайландыруы емес, ақауға төзімділік тесттерінің бір бөлігі деп санауға жақсы себеп.

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

Клиент жауаптың аяқталғанын, әрекетті қайталауға болатынын және көрсетілген мәтінмен не істеу керегін болжап отырмауы керек. OpenAI-үйлесімді SSE форматы интеграцияға ыңғайлы, бірақ өзі N токенінен генерацияны сенімді жалғастыру механизмін бермейді.

Decode кезіндегі ақаудан кейін шлюз ағынды нақты себеппен жабуы керек. Егер формат соңғы қызметтік оқиғаға мүмкіндік берсе, онда request_id, partial_output=true, retryable=false және себеп коды болуы қажет. Қосылым физикалық түрде үзілсе, клиент желі қатесін көреді. Мұндайда деректер жиыны сұрау журналында қолжетімді болуы немесе клиенттің қайталама сұрауына қосылуы керек.

Келісімшартты былай көрсетуге болады:

{
  "error": {
    "code": "upstream_decode_interrupted",
    "message": "Генерация прервана после отправки части ответа",
    "request_id": "req_01J...",
    "partial_output": true,
    "delivered_output_tokens": 37,
    "retryable": false
  }
}

Мұндағы retryable=false пайдаланушы берілуі керек дегенді білдірмейді. Ол шлюздің бастапқы сұрауды байқатпай қайталауға құқығы жоқ екенін көрсетеді. Пайдаланушы клиенті «Жалғастыру» әрекетін ұсынып, көрсетілген мәтінмен жаңа сұрау жасай алады. Чат үшін бұл орынды жол. JSON жауабы үшін клиент көбіне жартылай объектіні тастап, сол кіріспен, бірақ жаңа логикалық әрекет ретінде генерацияны қайта сұрауы керек.

Жаңа мәтінді ескі мәтінмен роутер жағында біріктірмеңіз. Қайталау сол үзіндіден басталғандай көрінсе де, тыныс белгілеріндегі, tool call немесе жабылатын жақшадағы айырмашылық нәтижені сенімсіз етеді. Бұл әсіресе structured output кезінде қауіпті: JSON-ның алғашқы 90 пайызы дұрыс көрінуі мүмкін, ал қайталанған бір кілт объектіні жарамсыз жолға айналдырады.

Сұраудың идемпотенттілігі мен әрекеттің идемпотенттілігі бір нәрсе емес

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

Үш нысанды ажырату керек:

• пайдаланушының логикалық сұрауы, мысалы «төлем тапсырмасын құрастыр»;
• нақты реплика мен lease-ке байланыстырылған инференс әрекеті;
• сыртқы әрекет, мысалы функция шақыру, хат жіберу немесе ақша есептен шығару.

Таза text completion үшін шлюз бірінші токенге дейін әрекетті қайталай алады. Құралдары бар агенттік сұрау үшін ережелер қатаңырақ. Егер воркер құралды шақырып үлгеріп, соңғы мәтінге дейін істен шықса, құрал жағында қайталануды болдырмайынша бүкіл сұрауды қайталауға болмайды. Әйтпесе модель өтінімді екінші рет жасап, хабарлама жіберіп немесе операция орындауы мүмкін.

Құрал GPU әрекетінен емес, логикалық әрекеттен алынған жеке idempotency key қабылдауы керек. Мысалы:

logical_request_id = req_01J...
tool_call_id = call_07
idempotency_key = req_01J...:call_07

Failover-ден кейін жаңа воркер call_07 бұрын орындалғанын біліп, екінші рет шақырудың орнына алдыңғы нәтижені ала алады. Бұл болмаса, тіпті мінсіз KV cache миграциясы да жүйені қайталанатын әрекеттерден қорғай алмайды.

Күйді тасымалдау алдын ала жобаланған үйлесімділік болғанда ғана орынды

Кейде decode-ті жалғастыру мүмкін. Ол үшін қозғалтқыштан ақылды болуға кенет шешім қабылдайтын жалпы роутер емес, inference runtime-ның өз протоколы қажет. Ол KV блоктарын, тізбек метадеректерін және sampler state мәнін алдын ала үйлесімді түйіндер арасында беруі немесе репликациялауы, сурет шекарасын бекітуі және жалғасып жатқан decode-пен жарыспай қалпына келуі керек.

Бұл қымбат. Ұзақ контекстің KV күйін беру желі, жад және келісімділікті бақылауды талап етеді. Әр жаңа токенді синхронды репликациялау latency-дің ең сезімтал бөлігіне қосымша жұмыс жүктейді. Асинхронды репликация жоғалу терезесін қалдырады: primary токендерді клиентке жіберіп үлгерді, ал standby тиісті суретті әлі алған жоқ.

Сондықтан төрт сұраққа жауап бермейінше «GPU құлағанда жалғастыруды» SLA-ға қоспаңыз:

1. Репликалар арасында нақты қандай деректер және қашан беріледі, сурет қашан консистентті болып саналады?
2. Модель нұсқалары, cache layout, адаптерлер және decode параметрлері бірдей ме?
3. Failover-ден кейін роутер ескі әрекеттің токен жариялауына қалай тыйым салады?
4. Тест токен циклі бойынша әр нүктеде ақау болғанда қайталанулар мен өткізіп алулардың жоқтығын қалай дәлелдейді?

Олардың кез келгеніне жауап «әдетте жұмыс істеуі керек» дегенге келсе, жалғастыру жоқ. Бұл best-effort қайталау ғана, оны сенімділік ретінде көрсетуге болмайды.

Роутер саясаты қысқа әрі қатаң болуы керек

Жақсы failover саясаты әр ақаудан retry шығаруға тырыспайды. Ол қауіпті әрекеттерге тыйым салып, рұқсат етілген бірнеше ауысуды ғана қалдырады.

on_upstream_failure:
  before_first_delta:
    require: [source_attempt_fenced, retry_budget_available]
    action: retry_prefill_on_healthy_replica
    max_attempts: 2

  after_first_delta:
    action: terminate_stream
    client_error: upstream_decode_interrupted
    automatic_retry: false

  uncertain_source_liveness:
    action: fence_source_attempt
    wait_for: cancel_ack_or_lease_expiry
    then: retry_only_if_no_delta_was_sent

max_attempts: 2 әмбебап сан емес. Ол саясаттың құрылымын көрсетеді: retry үшін бюджет болуы керек. Әйтпесе GPU-лардың жаппай істен шығуы қалған репликаларда қайталанатын prefill тасқынына айналады. Роутер тапшы есептеу қуатын бәрібір іске аспайтын сұрауларды қайталауға жұмсайды.

Ұзақ сұраулар үшін қайталау құнына қарай маршрут қосыңыз. Қайталама prefill токендер немесе уақыт бойынша белгіленген шектен асып кетсе, шлюз әрекетті бастамай тұрып басқарылатын қате қайтара алады. Бұл байқатпай созылған кідіріске қарағанда жағымсыз, бірақ бір минут күтіп, кейін екінші жүктемесі жоғары репликадан 504 алғаннан адалырақ.

Тек pod restart емес, токендер арасындағы ақауды да тестілеу керек

«Воркерді қайта іске қостық, сервис қайта жауап берді» деген тексеріс тірі ағындар туралы ештеңе айтпайды. Роутер шешімі өзгеретін нүктелерде процесті тоқтататын fault-injection тесті қажет.

Ең аз сценарийлер жиыны мынадай:

1. Бірінші downstream byte жазылмай тұрып, prefill кезінде репликаны тоқтату. Күтілетін нәтиже: қайталама әрекеттен кейін бір толық жауап.
2. Токен есептелгеннен кейін, бірақ SSE оқиғасы жіберілмей тұрып репликаны тоқтату. Күтілетін нәтиже: қайталауға болады, клиент үзіндіні көрмейді.
3. Бірінші жіберілген delta-ден кейін бірден репликаны тоқтату. Күтілетін нәтиже: ағын қатемен аяқталады, екінші генерация басталмайды.
4. Процесті тірі қалдырып, шлюз бен реплика арасындағы желіні үзу. Күтілетін нәтиже: ескі әрекет fence алады немесе lease мерзімін күтеді, қайталану болмайды.
5. Құрал шақырылғаннан кейін репликаны тоқтату. Күтілетін нәтиже: жаңа іске қосу әрекетті екінші рет орындамайды.

Тек HTTP кодын тексермеңіз. Тест request_id бойынша chunk тізімін, әрекеттер санын, upstream cancel фактісін, құрал журналдарын және екі attempt_id бір уақытта жарияламағанын салыстыруы керек. Кіріс, seed, модель нұсқасы және оқиғалар трассасын сақтаңыз, әйтпесе сирек кездесетін ақауды қайта шығару мүмкін болмайды.

AI Router клиенттер үшін OpenAI-үйлесімді келісімшартты сақтай алады, бірақ ішкі маршрутизация base_url мен модель атауынан көбірек дерек сақтауы керек: ағын фазасын, әрекет идентификаторын, lease-ті және бірінші жеткізу шекарасын. Бұл деректерсіз failover болжам күйінде қалады.

Инфрақұрылым тек сұрауды қайталай алса, пайдаланушыға үзіліссіз жалғастыруды уәде етпеңіз. Бірінші токенге дейін prefill әрекетін жылдам қайталап, одан кейінгі үзіліс туралы анық хабарлау әлдеқайда сенімді. Бұл ереже модельдер, GPU және inference runtime ауысса да жұмыс істейді, өйткені ол клиенттің нені көріп үлгергеніне негізделген.