vLLM ці TensorRT-LLM: пераможцу мяняюць прэфікс, чарга і налады

Паміж vLLM і TensorRT-LLM няма пераможцы для любой нагрузкі. Калі сэрвісу патрэбны хуткі першы токен падчас усплёску запытаў, адзін рухавік можа мець перавагу; калі галоўная мэта — выпуск токенаў за секунду, лідар можа змяніцца. Вынік залежыць ад мадэлі, GPU, даўжыні агульнага прэфікса, паралельнасці і таго, што менавіта вымяраюць.

Пры выбары трэба супаставіць час да першага токена, тэмп далейшай генерацыі і прапускную здольнасць на тым патоку запытаў, які чакае сервер. Паўторны сістэмны промпт дае магчымасць выкарыстоўваць KV-кэш, але карысць ад яго залежыць ад свабоднай памяці і ад таго, як запыты трапляюць у чаргу. Нават замеры на адной H100 могуць адказваць на розныя пытанні.

На адной H100 лідар змяняецца разам з метрыкай

У PrefixBench-H100 абодва серверы апрацоўвалі ўзгодненыя запыты з Qwen2-7B-Instruct на адной H100 NVL; пры агульным прэфіксе ў 4096 токенаў медыянны час да першага токена, або TTFT, для аднаго актыўнага запыту склаў каля 42 мс у vLLM і 52 мс у TensorRT-LLM, а пры ўсплёску да 32 адначасовых запытаў — каля 759 і 319 мс адпаведна. Пры той жа паралельнасці vLLM выдаваў 1444 выходныя токены за секунду супраць 523 у TensorRT-LLM. Аднак верхні перцэнтыль TTFT у гэтым усплёску склаў 1,30 с у vLLM і 1,58 с у TensorRT-LLM: перавага па медыяне не азначала перавагі для павольнейшых запытаў.

Гэта розныя ўласцівасці аднаго разгортвання. Медыянны TTFT паказвае, калі пачынаецца тыповы адказ, верхні перцэнтыль — што адбываецца з запытамі ў хвасце размеркавання, а токены за секунду — колькі працы сервер выконвае ў цэлым. Для чата з патрабаваннем хуткага пачатку адказу і для пакетнай генерацыі гэтыя паказчыкі маюць розную вагу.

У даследаванні TensorRT-LLM працаваў праз PyTorch-бэкэнд. Затрымка ў чарзе вымяралася непасрэдна для vLLM, але супастаўных лічыльнікаў планавальніка ў выкарыстанай версіі TensorRT-LLM не было. Таму тлумачэнне змены лідара розніцай у планаванні запытаў застаецца абгрунтаванай інтэрпрэтацыяй, а не цалкам вымеранай прычынай для абодвух сервераў.

Прэфікс паскарае адказ, пакуль яго ёсць дзе захоўваць

Калі некалькі запытаў пачынаюцца аднолькавымі токенамі, сервер можа паўторна выкарыстаць разлічаны для іх KV-стан замест новай апрацоўкі ўсёй пачатковай часткі. Найбольш прыкметны эфект чакаецца пры доўгай агульнай інструкцыі або паўторным шаблоне запыту. Пры кароткім ці ўвесь час зменлівым пачатку ўваходу магчымасцей для такога паўторнага выкарыстання менш.

У эксперыменце з невялікім наборам паўторных прэфіксаў эфектыўнасць кэша ў двух рухавікоў была блізкай нават пры росце паралельнасці. Калі ж набор прэфіксаў перавысіў ёмістасць KV-кэша, доля траплянняў знізілася ў абодвух. Такім чынам, важная не толькі даўжыня аднаго промпта: трэба ўлічваць, колькі розных прэфіксаў адначасова прэтэндуе на памяць і як часта кожны з іх вяртаецца.

Большая мадэль займае больш памяці вагамі і пакідае менш месца для KV-стану. Доўгі кантэкст і шмат актыўных запытаў таксама павялічваюць патрэбу ў ім. Вынік на невялікай мадэлі з кэшам, які свабодна змяшчае ўсе паўторы, таму не апісвае разгортванне, дзе прэфіксы пастаянна выцясняюць адзін аднаго.

Чарга вызначае, калі затрымка становіцца прыкметнай

Аднолькавая колькасць запытаў можа прыйсці раўнамерна або адным кароткім усплёскам. У першым выпадку сервер паступова запаўняе актыўную партыю; у другім запыты адразу спаборнічаюць за вылічэнні і месца ў кэшы. Менавіта таму паралельнасць без апісання моманту паступлення запытаў не задае поўнай нагрузкі.

У PrefixBench пры раўнамерным паступленні запытаў vLLM утрымліваў ніжэйшую затрымку першага токена, у тым ліку для павольнейшых адказаў, чым TensorRT-LLM у пратэставанай канфігурацыі. Гэты рэжым быў ідэалізаваны: інтэрвалы паміж запытамі былі роўнымі. Рэальны паток можа ўключаць кароткія згушчэнні, таму для сэрвісу з няроўным трафікам асабліва істотныя абодва замеры — стабільны паток і ўсплёск.

Чаму іншы тэст на H100 дае іншы адказ

Аўтар практычнага тэсту GPT-OSS-120B атрымаў прыкладна на 70–80% большую паслядоўную прапускную здольнасць vLLM на сваёй H100 PCIe. У апісанні названыя вобраз vLLM nightly, TensorRT-LLM 1.2.0rc2 і графікі для кантэксту ў 512 і 1024 токены. Гэта карыснае назіранне пра канкрэтную звязку абсталявання, мадэлі, версій і спосабу запуску.

Яго працэнт нельга паставіць у адзін рад з лічбамі PrefixBench як паўтор таго ж эксперыменту. Там выкарыстоўваліся іншая мадэль і варыянт H100, а вынікі падзяляліся паводле характару паступлення запытаў і метрыкі. Нават калі абодва тэсты вымяраюць токены за секунду, розная даўжыня ўваходу або выхаду змяняе суадносіны часу на апрацоўку промпта і генерацыю.

Якія ўмовы робяць параўнанне супастаўным

Аснова сумленнага замеру — адны і тыя ж вагі мадэлі, токенізатар, фармат промпта і дакладнасць вылічэнняў. Трэба зафіксаваць версіі рухавікоў, GPU, даступную памяць, межы кантэксту і налады KV-кэша. Інакш розніцу, выкліканую квантаваннем ці абмежаваннем памяці, лёгка памылкова прыпісаць самому серверу.

Наступная ўмова — адзін набор запытаў з вядомымі даўжынямі ўваходу і выхаду. Кароткае пытанне, доўгі дакумент і паўторны сістэмны промпт ствараюць розную працу нават пры аднолькавай сярэдняй даўжыні. Для нагрузкі з агульным прэфіксам варта асобна фіксаваць долю ўваходных токенаў, сапраўды атрыманых з кэша, а таксама стан кэша перад замерам.

Нарэшце, патрэбныя аднолькавыя правілы падачы трафіку: частата паступлення, ліміт адначасовых запытаў, працягласць замеру і аднолькавы пункт назірання за затрымкай. Калі адзін вынік атрыманы ўнутры рухавіка, а другі — кліентам праз HTTP, у іх розны склад вымеранага часу. Параўнанне налад па змаўчанні паказвае кошт хуткага запуску; асобнае параўнанне наладжаных канфігурацый — вынік пасля працы над прадукцыйнасцю.

Метрыкі і складанасць налады

Дакументацыя бенчмарка vLLM вызначае TTFT як час ад адпраўкі запыту да першага атрыманага фрагмента адказу, а ITL — як інтэрвал паміж наступнымі фрагментамі. Яна адрознівае ITL ад сярэдняга часу на выходны токен, TPOT: калі адзін фрагмент змяшчае некалькі токенаў, паказчыкі могуць разысціся. Дакументацыя таксама папярэджвае, што паўторны запуск на тым самым серверы можа скарыстацца ўжо запоўненым прэфіксным кэшам і завысіць прапускную здольнасць.

Кіраўніцтва TensorRT-LLM апісвае trtllm-bench з рэжымамі вымярэння прапускной здольнасці і затрымкі, падрыхтоўку набору запытаў і асобны шлях для OpenAI-сумяшчальнага сервера. У ім таксама тлумачыцца, чаму для ўзнаўляльных вынікаў трэба кантраляваць стан GPU. Выбар інструмента замеру вызначае, ці ацэньваецца сам рухавік, ці шлях запыту да кліента.

Складанасць налады мае практычную цану: час на падрыхтоўку аднолькавага набору запытаў, падбор параметраў памяці і партый, праверку кэша ды паўтор пасля абнаўлення версіі. Перавага ў хуткасці карысная толькі ў той канфігурацыі, якую каманда здольная стабільна падтрымліваць. Асобна варта глядзець на медыяну і верхнія перцэнтылі затрымкі: добры сярэдні паказчык можа схаваць запыты, якія доўга чакаюць у чарзе.

Матрыца выбару

• Інтэрактыўны сэрвіс з доўгім паўторным прэфіксам. Прыярытэт — TTFT пры рэальнай долі траплянняў у кэш; ITL паказвае, ці застаецца далейшы адказ плаўным.
• Кароткія ўсплёскі трафіку. Параўноўваць трэба медыяну і верхнія перцэнтылі TTFT разам з часам чакання ў чарзе. Лідар па медыяне можа мець іншы вынік у хвасце размеркавання.
• Раўнамерны паток. Важныя частата паступлення запытаў і затрымка пры ёй, а не толькі максімальная паралельнасць, дасягнутая ў кароткім тэсце.
• Пакетная генерацыя. Галоўным паказчыкам становяцца завершаныя запыты або выходныя токены за секунду пры дапушчальнай затрымцы і пасільных наладах.

Калі памяць абмежаваная або мадэль павялічваецца, у кожным з гэтых сцэнарыяў асобным крытэрыем становіцца ёмістасць KV-кэша. Менавіта яна вызначае, ці захоўваецца карысць ад паўторных прэфіксаў пры патрэбнай нагрузцы.

Чытайце таксама:

• Чарга на мяжы пераедзе ў праграму — але платформы яшчэ не названыя
• Docker ці Podman: rootless не вызначае пераможцу па хуткасці
• Hugging Face ці GitHub Models: вялікія вагі мяняюць правілы сховішча