p99 құлдырамайтын инференс үшін CPU және NVMe offload

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

Инференс үшін CPU және NVMe offload-ты сыйымдылықты болжамдылыққа айырбастау деп қарастырған жөн. GPU мен CPU арасындағы байланыс жылдам әрі бәсекелестік қатаң бақыланса, RAM жұмыс деңгейі бола алады. NVMe күйді алдын ала жүктеуге немесе қайта пайдалануға болатын кезде суық деңгей ретінде жарайды, бірақ генерация цикліндегі HBM-нің байқалмайтын кеңейтімі бола алмайды.

Салмақтар мен KV-cache кідірістің әртүрлі түрлерін тудырады

Салмақтарды және KV-cache-ті көшіру әртүрлі OOM мәселелерін шешеді, сондықтан бір параметр екіншісін алмастырмайды. Модельдің әр өтуінде салмақтар қажет. KV-cache тарих ұзындығына, белсенді тізбектер санына, attention қабаттарының санына, KV-heads санына және сақтау дәлдігіне қарай өседі.

Салмақтардың бір бөлігі RAM-да қалса, GPU оларға әр forward pass кезінде жүгінеді. Қазіргі vLLM конфигурациясында --cpu-offload-gb параметрі UVA және хосттың pinned memory жадын қолданады. Құжаттама бұл режимге CPU мен GPU арасында жылдам байланыс қажет екенін ашық ескертеді, өйткені параметрлердің бір бөлігі әр forward pass сайын жұмыс барысында пайдаланылады. Негізгі қауіп TPOT пен ITL-ге тиеді: декодер деректерді қайта-қайта күтуге мәжбүр болады.

KV-cache басқаша жұмыс істейді. Prefill аяқталғаннан кейін онда өңделген токендерге арналған K және V мәндері сақталады. Белсенді сессияға қажет блоктар VRAM-нан шығарылса, тарихқа назар аударуды жалғастырмас бұрын оларды қайтару керек. Кідіріс cache miss-тен кейінгі нашар TTFT немесе ұзақ жауап кезіндегі ITL секірісі ретінде көрінуі мүмкін. vLLM-де CPU KV буферінің көлемі --kv-offloading-size арқылы бөлек беріледі. Tensor parallelism кезінде бұл TP рангтері бойынша жиынтық көлем, әр картадағы көлем емес. Осы айырмашылықты шатастыру төрт GPU-ға 64 GiB бөлуді жоспарлап, оны бүкіл процеске бөлуге әкелуі мүмкін.

Offload-пен жиі шатастырылатын тағы бір нысан бар, ол сақталған префикс. Prefix caching немесе host-memory prompt cache бірдей жүйелік нұсқауды қайта prefill етпеуге көмектеседі. Бұл пайдалы, бірақ кез келген белсенді сессияны RAM немесе SSD-ден ауыртпалықсыз декодтауға болады дегенді білдірмейді. Оның деректерді уақытында алуға қойылатын талаптары басқа.

NVMe decode контурында тұрмауы керек

NVMe-ді суық KV блоктарын сақтау және префикстерді қайта пайдалану үшін қолдануға болады, бірақ әр decode қадамына SSD-ден синхронды оқу кідіріс құйрығын дерлік кездейсоқ нәтижеге айналдырады. Тіпті жылдам жергілікті жинақтауыш кезектерін файлдық жүйемен, журналдармен, модельдерді жүктеумен және көрші контейнерлермен бөліседі. Бұлттағы виртуалды диск темір сипаттамаларында көрінбейтін тағы бір қабат қосады.

Мәселе SSD-нің HBM-нен баяу екенінде емес. Бұл түсінікті. Мәселе түйіршіктілікте: decode бір-біріне тәуелді көптеген қысқа қадамнан тұрады. Суық KV блогының бір miss-і тізбекті кідіртуі мүмкін, ал жоспарлаушы сол кезде басқа сұрауларға қызмет көрсетуді жалғастырады. Пайдаланушы орташа баяу жауапты емес, мәтін беріліп қойғаннан кейінгі ұзақ кездейсоқ үзілісті көреді.

NVMe үшін екі орынды режим бар.

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

Интерактивті ассистентке NVMe сәйкес көлемді сыйғыза алатындықтан ғана 128k контекст уәде етпеңіз. Уәде нақты сұраулар қоспасындағы p99 TTFT және p99 ITL-ге сүйенуі керек. Өнімге байқалмайтын үзілістерсіз ағынды мәтін қажет болса, SSD дайындық пен қалпына келтіру деңгейі болып қалады, ыстық циклдің бөлігіне айналмайды.

Алдымен нақты не сыймайтынын есептеңіз

Offload-ты VRAM-ның бір көрсеткішімен баптауға болмайды. Жадты салмақтарға, тұрақты жұмыс буферлеріне, графтар мен уақытша тензорларға, KV-cache-ке, фрагментация қорына және batch шегіндегі бос орынға бөліп қарау керек. Модель салмағы тек төменгі шекті көрсетеді.

KV-cache-ті жуық бағалау үшін мына өрнекті қолданыңыз:

KV bytes ≈ tokens × layers × kv_heads × head_dim × 2 × bytes_per_element

2 көбейткіші K және V мәндерін білдіреді. GQA кезінде kv_heads саны attention-heads санынан аз, сондықтан формулаға модель карточкасындағы бірінші санды қоя салуға болмайды. Квантталған KV-cache үшін FP16-дағы екі байттың орнына scale және block metadata ескерілген нақты элемент өлшемін алыңыз. Дәл сан қозғалтқыш пен кванттау схемасына байланысты, бірақ қателіктің реті үтірден кейінгі үшінші таңбадан маңызды.

Іске қоспай тұрып жасайтын пайдалы есептің мысалы: 32 қабат, 8 KV-head, head_dim=128 және FP16 кезінде бір токен шамамен 128 KiB KV-cache алады. 32 768 токендік контекст бір тізбекке шамамен 4 GiB қажет етеді. Осындай сегіз қатар сессия шамамен 32 GiB сұрайды, бұл ішкі блоктарды туралау мен жоспарлаушы қорын есептемегендегі мән. Модель сыйып, сервис тек ұзын чаттарда құласа, салмақтарды CPU-ға көшіру дұрыс мәселені шешпейді.

API-ге шын мәнінде қандай контекст келетінін де тексеріңіз. Команда 32k синтетикалық токенді сынауы мүмкін, ал production-да оған үлкен жүйелік нұсқау, құралдар шақыруының тарихы, RAG құжаттары және сәтсіз retry-ден кейін қайталанған тарих қосылады. Кірістегі токендер санағын жауап ұзындығымен және модель маршрутының идентификаторымен бірге журналға жазыңыз.

p99-ды орташа жылдамдық емес, көшіру кезегі бұзады

Орташа throughput offload-тың жарамдылығын көрсетпейді. Ол бірнеше сұрау хост жадын, DMA-ны немесе KV блогының босауын күтіп тұрғанда да қалыпты болып қалуы мүмкін. Жүктеме аз кезде мұндай күту сирек кездеседі. Бәсекелестік өскенде олар жинақталады.

Төрт қарапайым чат 2k токенмен және 48k токендік бір сұрау 1000 токен генерациялап жатыр деп елестетіңіз. Ұзын сессия GPU-ға сыйған кезде ол жадты көп алады, бірақ өзін болжамды ұстайды. Оның KV мәндері RAM-ға ығыстырылғаннан кейін әр блокты қайтару PCIe үшін offload жасалған салмақтарға қатынаспен және жаңа сұраулардың prefill көшірмелерімен бәсекелеседі. Егер сол хост контейнер журналдарын NVMe-ге шығарып жатса, үшінші кезек пайда болады. Орташа TPOT жаман көрінбеуі мүмкін, ал p99 ITL он есеге өсуі ықтимал.

Бұл сценарийді бір сұраудан тұратын тест ұстай алмайды. Кемінде төрт кесінді қажет:

• кезексіз offload-тың таза құнын көру үшін бір сұрау;
• 2, 4, 8 және өнімдік шекке дейінгі тұрақты бәсекелестік;
• генерация ұзындығы бірдей болғандағы қысқа және ұзын контекст;
• ұзын сұраулар аз, бірақ тұрақты үлес құрайтын аралас профиль.

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

vLLM құжаттамасындағы bench serve --request-rate пен --max-concurrency параметрлерін бөледі: біріншісі сұраулардың келуін, екіншісі нақты орындалып жатқан сұраулар санын шектейді. Бұл --request-rate inf арқылы әдемі нәтиже алудан гөрі, артық жүктемені сынау үшін қажет айырмашылық.

Үш жад деңгейін бір профильмен сынаңыз

Салыстыру барлық нұсқаға бірдей кіріс, шығару ұзындығы, sampling баптаулары, бәсекелестік шегі және қыздыру берілгенде ғана мәнді. Кванттауды, batch көлемін және offload-ты бір уақытта өзгертпеңіз. Әйтпесе жадты қай ымыра сатып алғанын, ал кідірісті қайсысы нашарлатқанын білмейсіз.

Төменде бір модель мен бір GPU конфигурациясына арналған ең аз матрица берілген. Ол әмбебап сандарды бермейді, бірақ деградацияның дәл сіздің жабдығыңызда қалай көрінетінін көрсетеді.

Әр нұсқа үшін 2k, 8k, 32k және өнімдегі контекстің ең жоғары ұзындығында тест жүргізіңіз. Генерация ұзындығы, мысалы, 256 немесе 512 токен болып тұрақты болуы керек. ignore_eos тек синтетикалық тестке қажет, өйткені ерте EOS салыстыруды бұзбауы тиіс.

Онлайн тесті іске қосу үлгісі:

vllm bench serve \\
  --backend openai-chat \\
  --base-url http://127.0.0.1:8000 \\
  --endpoint /v1/chat/completions \\
  --model local-model \\
  --dataset-name random \\
  --random-input-len 8192 \\
  --random-output-len 256 \\
  --num-prompts 160 \\
  --request-rate 2.0 \\
  --max-concurrency 8 \\
  --ignore-eos \\
  --percentile-metrics ttft,tpot,itl,e2el

Күтілетін нәтижеде тек throughput емес, P99 TTFT, P99 TPOT және P99 ITL блоктары да болуы керек. vllm bench serve осы форматты өзі шығарады. Шикі JSON нәтижелерін және драйвер, CUDA, қозғалтқыш, модель мен tokenizer нұсқаларын сақтаңыз. vLLM жаңартылғаннан кейін бұл ақпаратсыз CSV файлдарын салыстырудың мәні жоқ.

Синтетика production трассаларын алмастырмайды. Одан кейін тесті сұрау ұзындығының жасырын бөліністерінде, нақты tool calling үлгілерінде және қайталанатын префикстердің нақты үлесінде қайталаңыз. Бірақ алдымен синтетикалық матрица қажет. Ол мәселенің қай жерде басталатынын жылдам көрсетеді.

RAM offload үшін PCIe мен NUMA-ны тексеру қажет

CPU RAM кідірісі бірдей бірыңғай ресурс емес. Екі сокетті серверде GPU бір NUMA түйініне байланып, процесс, pinned memory немесе NVMe үзілістері басқа түйінде орналасуы мүмкін. Мұндайда деректер жолы процессорлар арасындағы шинадан өтеді де, жетіспейтін миллисекундтар тек жүктеме кезінде байқалады.

Тест алдында топологияны бекітіңіз:

nvidia-smi topo -m
numactl --hardware
lspci -tv

nvidia-smi topo -m нәтижесінде әр GPU-дың CPU мен көрші GPU-ларға дейінгі жолына назар аударыңыз. numactl --hardware нәтижесінде процесс орналасатын жадтың қай NUMA түйініне тиесілі екенін тексеріңіз. Сервер сипаттамасындағы PCIe Gen5 атауына қарап жылдамдық туралы қорытынды жасамаңыз: карта жол саны аз слотта тұруы немесе желі картасы мен жинақтауышпен root complex бөлісуі мүмкін.

CPU affinity мен процестің memory policy параметрін GPU-ға жақын түйінге байланыстырыңыз. Бұл мәңгілік баптау емес, гипотезаны тексеру үлгісі:

numactl --cpunodebind=0 --membind=0 \\
  vllm serve local-model --cpu-offload-gb 12

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

Pinned memory әдетте GPU-мен жылдам алмасу үшін қажет. NVIDIA page-locked memory хост пен құрылғы арасындағы тасымалдаудың ең жоғары өткізу қабілетін беретінін жазады, бірақ жадты қажетсіз бекітпеуге кеңес береді. Инференсте бұл екі есе маңызды: шамадан тыс pinning файл кэшіне және суық NVMe деңгейіне қалатын кәдімгі RAM көлемін азайтады. ОС жад тапшылығын сезіне бастағанда offload-тың пайдасы тез жоғалады.

Салмақтар мен KV offload-ына ортақ лимит қоймаңыз

CPU offload салмақтары мен KV-cache offload-ын қатар қолдануға болады, бірақ бұл негізгі режим емес, соңғы амал. Екі ағын да RAM-ды, CPU мен GPU өткізу қабілетін және ОС-тың жадқа бөлетін ресурсын пайдаланады. Бір лимитті «қалғанынан» белгілеу жүйені ұзын сұраулардың алғашқы топтамасына дейін ғана тұрақты етіп көрсетеді.

Бюджеттерді қағазда да, конфигурацияда да бөліңіз. ОС-қа, page cache-ке, журналдарға, tokenizer workers-ке, желі стекіне және күтпеген жүктеме секірісіне RAM қалдырыңыз. Қалған көлемнің бәрін pinned memory-ге бермеңіз. CPU offload салмақтарын модельді іске қосуға дейінгі шағын жетіспеушілік ретінде белгілеңіз, GPU-ды виртуалды түрде екі есе ұлғайту мүмкіндігі ретінде емес. KV үшін жеке көлем және қатар орындалатын тізбектер санына жеке лимит қойыңыз.

vLLM-де бұл механизмдер шынымен бөлінген: --cpu-offload-gb салмақтарды offload етуге, ал --kv-offloading-size таңдалған backend арқылы KV-cache-ті CPU-ға көшіруге жауап береді. Бұл тәуелсіз өнімділікке кепілдік бермейді. Бірақ конфигурацияның өзінде жад шығынының екі түрлі себебін араластырмауға мүмкіндік береді.

«RAM арзан болғандықтан, үлкен offload қойыңыз, қозғалтқыш өзі реттейді» деген кеңес жиі айтылады. SLO үшін бұл нашар тәсіл. Жоспарлаушы қолжетімді жадты тиімді толтыра алады, бірақ қай пайдаланушы сценарийі 500 мс сирек үзілісті көтеретінін, қайсысы көтермейтінін білмейді. Лимит DIMM-нің ең үлкен көлеміне емес, рұқсат етілген p99-ға сүйенуі керек.

KV дәлдігін азайту оны көшіруден жиі тиімді

Мәселе дәл KV-cache көлемінде болса, модель мен қозғалтқыш сапаны қабылдауға болатын деңгейде берсе, алдымен кэш дәлдігін азайтуды қарастырған жөн. Бұл ыстық деректер көлемін кішірейтіп, ығыстыру ықтималдығын төмендетеді. RAM offload-тан айырмашылығы, квантталған KV есептеуге жақын қалады және әр miss кезінде қосымша DMA кезегін тудырмайды.

Тек жалпы benchmark сапасын тексермеңіз. Ұзын контекстке сезімтал тапсырмаларды алыңыз: келісімшарттағы шартты табу, кесте жолдарын салыстыру, көп қадамды tool calling, алаңдататын фрагменттері бар құжат бойынша сұраққа жауап беру. FP16 KV мен таңдалған схемадағы дұрыстықты салыстырыңыз. Модель алыс контекстегі бөлшектерді сенімді түрде жоғалта бастаса, жад үнемі шынайы үнем емес.

llama.cpp CUDA және басқа backend-терде K-cache кванттауын қолдайтынын бөлек көрсетеді, ал өнімділік құжаттамасы GPU қолданылса да CPU ағындарының параметрлері жылдамдықты шектеуі мүмкін екенін еске салады. Бұл маңызды ескерту: KV көлемін азайту CPU-ды тексеру қажеттілігін жоймайды. Сығылған кэш VRAM үнемдеуі мүмкін, бірақ prefill, көшірмелер және сұрауларға қызмет көрсету үшін хост бәрібір пайдаланылады.

Көп сервис үшін тиімді рет мынадай: қажетсіз тарихты қысқарту, қайталанатын префикстерге prefix caching қосу, KV quantization-ды бағалау, ұзын сессиялардың бәсекелестігін шектеу, содан кейін ғана KV-ды RAM-ға көшіру. Бұл жалаушалар жиынтығы аса әсерлі көрінбеуі мүмкін, бірақ p99-ды әдетте бақылауда ұстайды.

NVMe-нің суық келісімшарты болуы керек

NVMe қоссanız, оның жүйедегі рөлін келісімшарт ретінде сипаттаңыз. Дискіге қандай деректер түседі? Олар қашан суық деп есептеледі? Қайтарылғанша сұрау генерацияны жалғастыра ала ма? Файлдарды кім тазартады? Диск толса немесе процесс қайта іске қосылса не болады? Бұл сұрақтарға жауап болмаса, архитектура емес, файлдық жүйеге деген үміт қана бар.

Практикалық келісімшарт мынадай болуы мүмкін: белсенді интерактивті тізбектердің ыстық KV-ы тек VRAM-да тұрады; RAM жақында ығыстырылған блоктарға арналған шектеулі резервті сақтайды; NVMe тек жаңа жұмыс кезеңі басталғанға дейін қайтаруға болатын префикстер мен күйлерді ұстайды; miss кезінде интерактивті жол префиксті қайта есептейді немесе тапсырманы асинхронды режимге ауыстырады. Сирек жағдайда бұл TTFT-ті арттыруы мүмкін, бірақ жауаптың ортасында мәтінді үзбейді.

Үш бөлек сигналды бақылаңыз: құрылғы кідірісі, кезек тереңдігі және cache hit пайызы. Жылдам орташа read peak prefill-пен қабаттасқан сирек құйрықтық оқулар кезінде жүйені құтқармайды. Бір NVMe-ге модель файлдарын, дерекқор журналдарын және cold KV-ды аралас жүктемені өлшемей орналастырмаңыз. Каталогтар бөлек болғанымен, жинақтауыштағы кезек ортақ.

Деректерді жергілікті орналастыру және модель маршруттарын басқару маңызды командалар үшін AI Router сыртқы OpenAI үйлесімді шлюз бола алады, ал инференстің hot path бөлігін контекст пен кезекке арналған ашық лимиттермен ұстаған жөн. Offload data residency, аудит немесе PII бүркемелеу талаптарын жоймайды: ол белгілі бір сәтте тензорлардың физикалық қайда жатқанын ғана өзгертеді.

Шешім деградация шегіне қарай қабылданады

Offload тестінің сәтті нәтижесі «D нұсқасы жылдамырақ» деген жауаппен бітпейді. Ол контекст ұзындығы мен бәсекелестіктің қай шегінде p99 TTFT немесе p99 ITL SLO-ға сыймайтынын көрсетуі керек. Өнімге не істеу керегін тек содан кейін шешуге болады.

Егер CPU offload бір сұрауда p99-ды аздап өсіріп, бірақ 8 сұрау қатар орындалғанда күрт нашарласа, оны кезегі бар ішкі міндеттерге және бөлек пулға қалдыруға болады. Егер RAM KV-offload 8k кезінде p99-ды ұстап, 32k кезінде бұзылса, барлығына ортақ max_model_len орнына ұзын сессияларға жеке лимит қойыңыз. NVMe қайталанатын префикс кезінде ғана пайдалы болса, оны префикс кэші ретінде рәсімдеңіз, VRAM кеңейтімі деп атамаңыз.

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